Subject: [dnsext] RRSIG inception/expiration times

From: Miek Gieben <[email-masked]>
Date: Tue, 21 Dec 2010 18:47:03 +0100

Hello,

I'm looking at the expiration- and inception timing parameters
in the RRSIG record. And I'm getting confused.

Consider these text from the relevant rfcs:

In rfc4034, section 3.1.5. "Signature Expiration and Inception Fields"

    The Signature Expiration and Inception fields specify a validity
    period for the signature.  The RRSIG record MUST NOT be used for
    authentication prior to the inception date and MUST NOT be used for
    authentication after the expiration date.

    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.

And rfc4035, section 5.3.1. "Checking the RRSIG RR Validity"

   o  The validator's notion of the current time MUST be less than or
      equal to the time listed in the RRSIG RR's Expiration field.

   o  The validator's notion of the current time MUST be
      greater than or equal to the time listed in the RRSIG RR's
      Inception field.

Both these values are absolute. In the rfcs there is text on how to deal
with serial arithmetic to compare these values, but nothing on how a
resolver must deal with them when the values themselves overflow the 32
bits.

So now I'm confused with how a resolver on a 64 bit (with a 64 bit time_t)
system has to cope with this. At some point in the future (granted this
will take a while), the local time of the resolver will be larger than the
32 bit value of the expiration field.

What should the resolver do?

o Discard the signature as invalid?
o Detect that this has happens and add 68 years to the time stamp?
o ...

Or am I not looking at the right rfcs?

Kind regards,

--
 Miek

---

From: Francis Dupont <[email-masked]>
Date: Tue, 21 Dec 2010 19:02:03 +0100

In your previous mail you wrote:

=> it is not serial arithmetic but standard 32 bit unsigned arithmetic.
And it should overflow in 2106 so the guy who should have to fix this
is likely not yet born.

=> stay in the 21th century (:-)?

Regards

[email-masked]

---

From: Miek Gieben <[email-masked]>
Date: Tue, 21 Dec 2010 19:08:19 +0100

[ Quoting Francis Dupont in "Re: [dnsext] RRSIG inception/expira"... ]
> And it should overflow in 2106 so the guy who should have to fix this

Ah, ok. Not our problem :-)

It *is* a good thing to have an end date for DNSSEC, so we are not
stuck forever with it...

grtz,

--
 Miek

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 21 Dec 2010 13:32:47 -0500

> It *is* a good thing to have an end date for DNSSEC, so we are not

Section 3.1.5 of RFC 4034 seems reasonably clear. You use ring
arithmetic. The idea is that, if you actually run into the time
ambiguity because you are trying to verify a signature more than N*68+
years (N>0) old, you will have changed keys by then and it won't be a
problem because the signature won't verify. DNSSEC is designed to
outlast the age of the universe. :-)

Thanks,
Donald

---

From: Miek Gieben <[email-masked]>
Date: Tue, 21 Dec 2010 19:46:37 +0100

[ Quoting Donald Eastlake in "Re: [dnsext] RRSIG inception/expira"... ]
> outlast the age of the universe. :-)

Ah, okay, now I see:

    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.

The key here is "all comparisons", including comparing with the local
time of the resolver.

grtz Miek