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

Kevin Darbyshire-Bryant kevin at darbyshire-bryant.me.uk
Sat Feb 14 15:33:00 GMT 2015



> On 14 Feb 2015, at 14:47, Simon Kelley <simon at thekelleys.org.uk> wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> 
> 
>> On 12/02/15 12:01, Kevin Darbyshire-Bryant wrote:
>> 
>> 
>>> 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!?
>> 
> 
>> 
>>> 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.
>> 
>> 
> 
> If the device will always have NVRAM available in the form of a
> filesystem, then using a time stamp on that is the obvious way to go.
> The only disadvantage I can see is that some devices may have NVRAM,
> but not be able to use it to store a filesystem. I don't have the
> knowledge to be able to have a strong opinion on that.

I don't really have that knowledge either, I've experience with Broadcom router platforms running the likes of Tomato and/or Asuswrt.  These have had jffs filesystems from very early days (and I've not yet encountered a situation where the NVRAM has worn out either). 

> 
> Assuming we have a fileysystem, then the following algorithm would
> seem to work.
> 
> On startup, if the timestamp on a NVRAM file is in the future, disable
> time checking for DNSSEC. The first time the timestamp goes into the
> past, enable timestamp checking henceforward, and reset the timestamp
> on the file to "now"
> 
> That leaves only the case where at startup, the file doesn't exist. I
> think creating it and setting its mtime to 01-01-2015, then running
> the rest of the algorithm, will probably do in that case.
> 
> Extending dnssec-no-timecheck, to take a pathname to enable this mode
> seems a reasonable idea.

Sounds excellent. Is it worth being really clever and setting the default time to build time rather than 01-01-2015?  As a further wear protection effort, only update mtime on the existing file if the difference exceeds 1 day?  This would limit the amount of writes on process start (Asuswrt restarts dnsmasq for the most bizarre reasons)

> 
> So
> 
> - --dnssec-no-timecheck
> 
> works as before, with SIGHUP
> 
> - --dnssec-no-timecheck=/path/to/nvfilesystem
> 
> invokes the new behaviour.
> 
> How's that sound?

Really good!

And really appreciate your time & consideration of this.

Kevin

> 
> 
> Cheers,
> 
> Simon.
> 
> 
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> 
> iQIcBAEBCAAGBQJU32AYAAoJEBXN2mrhkTWi8VkQAImoX1tf0utktpqG7FIzFpI5
> YyqGseTFw+4PreofAatDTgKdpgqFPACUYfqoj+56Xbk2u4jUFoxfeUrSLQwQ9C75
> eXbvWynhul1omVZjB96yXDkpysxQ5yhajLk7cgmIYpX6HBOtng3TiAfUGRqUa7ny
> qTxo6Ap0Al3RKsilZCBTcw3/G5yJg/rQuQGsuL/66nLW/au5sORw2AP/K4EbRAID
> Iw4jjfAWc3I7TgPEc2AX6nxiaA0+B2Kl7Tw6VUnmjsEwAjhjNgIKEeDrlgwXxxih
> CvnnHT/GSA6Dxa7rqrhzZ3B5AQzfsrIxhZTqwU/hkibspBWwye/P1thLWV67pmlc
> /EKHQsRydqlCZL43Ji1hRVJlnycU26AzePi+u0EgdJ/ayt4hwZC78jiKRfGFrh4b
> 5BAR07qjO14ZlVmCUYeaS3eAi4OYtk017Pbosdhc6V5CsSn0rIyKJw4Ir2gfyFSl
> UvVbTFiSST0pp2cKJjYRZrgf/LfoGW/7Is21DcAZMn9LLGq8TTWt8ImA+cQWGg3f
> ItQqsgrKI/8J18ThcAJvZM2UyW119hSEy7iIpsaw1h2mB961X+q6GeW7tx47AuVy
> 9MpBfjNaS2LTaOClOceEFCLCtLpIlYL8WwnTnU+C4cVXp6dRyO/4B9SrSY2vD50i
> 3rPLTS626d2Zq0MnVYfk
> =96X2
> -----END PGP SIGNATURE-----
-------------- 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/20150214/b048a789/attachment.bin>


More information about the Dnsmasq-discuss mailing list