Re: [dnsext] SIG inception/expiration

[Mark Andrews <[e-mail]>]

In message <[e-mail]>, John Dicki
nson writes:
> 
> On 2 Jan 2012, at 14:03, Miek Gieben wrote:
> 
> > [ Quoting <[e-mail]> at 00:52 on Jan  3 in "Re: [dnsext] SIG inc..." ]
> >> 
> >> In message <[e-mail]>, Miek Gieben writes:
> >>> Hello list,
> >>> 
> >>> A recent dnssec-deployment discussion led to the question on why the
> >>> expiration/inception time in the RRSIG are in the "wrong" order.
> >> 
> >> Actually the order makes lots of sense.  Expiration time is almost
> >> always the critical value in a signature.  Inception time is almost
> >> always in the past.  One could completely remove inception time
> >> and still have secure signatures.
> > 
> > But was this the original reason to change the order?
> > 
> > And someone, not trained in the Jedi ways of DNSSEC, will look at an RRSIG 
> and
> > assume the first time stamp is the inception and the second one is expirati
> on.
> 
> That is true. I have often had to double check this order - I just remember t
> hat there is something funny with it now and always double check. 
> 
> I had always thought that, as Mark said, inception makes no difference to sec
> urity, and that perhaps there is no operational reason to use any value other
> than 0 for the inception. Setting it to zero would at least stop it standing
> out in the RRSIG. However, a quick re-read of 4034 3.1.5 reminds me that 

What I said is that it could be removed all together.  Given that it is there
it needs to be set appropriately.

>   The Signature Expiration and Inception field values specify a date
>    and time in the form of a 32-bit unsigned number of seconds elapsed
>    since 1 January 1970 00:00:00 UTC, ignoring leap seconds, in network
>    byte order.  The longest interval that can be expressed by this
>    format without wrapping is approximately 136 years.  An RRSIG RR can
>    have an Expiration field value that is numerically smaller than the
>    Inception field value if the expiration field value is near the
>    32-bit wrap-around point or if the signature is long lived.  Because
>    of this, all comparisons involving these fields MUST use "Serial
>    number arithmetic", as defined in [RFC1982].  As a direct
>    consequence, the values contained in these fields cannot refer to
>    dates more than 68 years in either the past or the future.
> 
> so I guess it does need to be set to something reasonable if you use very lon
> g validity periods or we are nearing 2106. However, it makes me wonder if the
> re is ever a reason to compare them, and if serial number arithmatic is actua
> lly meaningful here? 

Serial number arithmetic is important.

> John
> 
> 
> _______________________________________________
> dnsext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsext
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]                 INTERNET: [e-mail]
_______________________________________________
dnsext mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dnsext