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

[Kevin Darbyshire-Bryant]

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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4791 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20150209/1355144f/attachment.bin>