[Dnsmasq-discuss] dnssec-no-timecheck enhancement idea

[Kevin Darbyshire-Bryant]

> On 11 Feb 2015, at 22:02, Simon Kelley <simon at thekelleys.org.uk> wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> 
> 
>> On 09/02/15 18:28, Kevin Darbyshire-Bryant wrote:
>>> On 09/02/2015 16:02, Simon Kelley wrote:
>>> 
>>> 
>>>> On 09/02/15 13:21, Kevin Darbyshire-Bryant wrote:
>>>> Further to my previous email I've cobbled something together,
>>>> and it even appears to work.  There's quite a bit of coding
>>>> guesswork going on here and I really shouldn't be let anywhere
>>>> near a C compiler.  Either way a new option
>>>> '-dnssec_tvalid=integer' where integer is number of seconds
>>>> since 1970 (epoch)  is implemented. If current system clock
>>>> exceeds this time then dnssec timestamps will be checked, until
>>>> that time they are not.
>>> 
>>> 
>>> Answering your previous mail as well, I like this as an idea.
>>> 
>>> I think the original concept (date after an arbitrary, recent,
>>> time id better if the time really is arbitrary. Putting
>>> timestamps in the start-up infrastructure to pass to dnsmasq is a
>>> bit pointless: they won't be "better" than something compiled
>>> into dnsmasq, and they're a pain to generate (What's the command
>>> to spit out "now" in seconds since 1970?). A bit of makefile
>>> wizzardry could compile in "now" at build time, as another idea.
>>> 
>>> However it occurs to me that many of the platforms we're talking
>>> about here don't have an RTC, but they _do_ have non-volatile
>>> storage. How about storing "now" to NVRAM every hour, and using
>>> _that_ as the time which must be superceded?
>>> 
>>> 
>>> The second path is well on the way, BTW, I'm happy to take it and
>>> bash it into shape, once we agree on exactly what's needed.
>>> 
>>> 
>>> Cheers,
>>> 
>>> Simon.
>>> 
>> 
>> Hi Simon,
>> 
>> Hmmm, it's a 'difficult' one.  Building 'now' in at compile time
>> is certainly an option but it does assume that the firmware won't
>> at some stage in the future and boot up to a time that's then valid
>> by default. I was quite shocked to find the router I'm currently
>> fiddling with defaulted to December 2014!  And I get your point
>> that even providing a mechanism to pass a good 'valid' time is
>> itself built into the firmware....unless it's provided by an
>> additional config file in stored in NVRAM, which is the approach
>> I've taken.  I do wholeheartedly agree seconds since 1970 is arcane
>> to say the least and a way to automate that out has got to be a
>> good idea :-)
>> 
>> I like the idea of storing "now" in 'nvram' somehow very much.
>> There are a couple of thoughts on this, and I'm viewing this from
>> an Asus router 'asuswrt' perspective so may not be thinking of
>> other platform issues.  I've an NVRAM partition (using JFFS) which
>> uses a spare portion of flash memory as NVRAM.  Ideally you don't
>> want to write to this too often as it'll wear the flash out
>> prematurely.  I don't know what the dnssec signature validity
>> granularity is but would a daily update really be too infrequent?
>> Of course I can add a USB stick drive to the router and use that
>> (in fact I do) but this isn't a default option that say Asus could
>> put in, they'd have to point to JFFS by default.
>> 
>> My other thought relates to how this file gets created &
>> initialised. My head is hurting trying to think this through but
>> the case where the file exists is the most straightforward (compare
>> the time stored to "now" and if "now" greater then the clock has
>> hopefully been set and the file should be updated)  I think a
>> safeguard to creating the file in the first place needs
>> implementing, in essence something like seeing a significant time
>> jump forward (say a day) which indicates a clock set operation.
>> Fundamentally the idea of passing an option to a timestamp file
>> along with an update interval is really good.
>> 
>> Kevin
>> 
> 
> I think  we need to be careful to distinguish two different things here.
> 
> 
> There's the idea of saving a "last good time" in NVRAM so that we can
> sanity-check the kernel time, and not do time checks until it looks
> good. This is a roundabout way of getting information to dnsmasq that
> NTP is running, and avoids the chicken and egg that NTP needs to do DNS.

The principle I agree with.  I'm wondering about the mechanics of accessing this NVRAM 'last good time'.  Is this something you're thinking that dnsmasq should access & maintain, in which case a file stored in a non-volatile filesystem would be the most cross-platform method.  Or are you thinking the device OS should write a parameter into dnsmasq's config file at start (as I've cobbled together) ?

I have to say that I'd quite like dnsmasq to handle all the timestamp related stuff so  dnssec could simply be a case of throwing a switch and everything is handled automagically.  That might encourage home router manufacturers to include & enable by default. But what do I know!?

> 
> There's a second idea, which is to use the "last good time" as a proxy
> for "now". Ie always check DNSSEC key times, but use the last value
> written to NVRAM. That's probably good 99% of the time, but will break
> if you leave your router switched off for a couple of months. It will
> also likely break when you buy a new router and turn it on for the
> first time, which makes it not popular with router developers.

I'm not a fan of the 'proxy for now' idea for exactly the reasons you describe.  I think it better to wait for 'now' to really be after 'last good time', the implication is that NTP has done its stuff & sync'd the clock.  I would hope that NTP would be early on in the startup process so the exploit window narrow.

> 
> Cheers,
> 
> Simon.
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> 
> iQIcBAEBCAAGBQJU28s/AAoJEBXN2mrhkTWiizUP/jaXpF56B8xq0nUpsl2SZoeX
> xSnSJ2kMyhhvIMe/wfzbLE9QvFCTYeGi1YVP4Ip1xhDP/GU6QlNEJh0ud7s3DVsO
> GqpKVhNVHDIYpJ9XvVpjCBO5TEkH0uxD80USSSlryc5j2K6GTwxSjThpT+zBRUFf
> l+VhITCEX7496zY0SaQawmWEd+pPgoDqi7yXBJLUD+cGImjOKVsqkyoYMewELcKC
> 1aYpQXqcEGXJidGYz2bR1wImLae03xH8+rz9AjtIgcw7x+SaN/muhTyG3niZjn4P
> 5bWSbY9TD9bbUj0qj4zHkF8VaDExL5iNfx9c2kO0hyISxQOX2ZOOvgUVjBmBQAJs
> SludMTdNv3DP/q/s6z0F8DcxtgzzKaPCG6XIzEr+OfNJERqWIb7X15FjhL6RX17K
> mFvnSaj8drtIn4EaQfafPn/if7Kkqw4RbjrkN3dJSm68nTC6Tk9Ncln8AfEV8zOi
> PKHhOyp/YiMWssOyB7h5YgSZvKbi2SUeDPQ7zX8/2Jc6EV9X2eSs05K+4g8FMrGu
> SXL2SPhfooJ59rNAB18qEXOCMa1Ej+SJ2fu6brkm9+RrgCA44g37ykzNWURJaf9R
> F376A4zqkU8gwSvOHdIdmTjJi7ZTiVA1X+OrWmsl0cc2b8CtmqEJFBszv2rKXZ7P
> 1Q2pnSxxZIBklZLsTYD0
> =2Lzc
> -----END PGP SIGNATURE-----
> 
> _______________________________________________
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss at lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3089 bytes
Desc: not available
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20150212/084e01be/attachment.bin>