Subject: [dnsext] SIG inception/expiration

From: Miek Gieben <[email-masked]>
Date: Mon, 2 Jan 2012 11:46:13 +0100

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.

I did some digging in the archives and the closest I found was this:

In the drafts leading up to RFC 2065, the SIG RDATA is defined:
http://tools.ietf.org/html/draft-ietf-dnssec-secext-00#section-5.1

In there it is: "time signed", "signature expiration"

And then in -02 (there is no -01)
http://tools.ietf.org/html/draft-ietf-dnssec-secext-02#section-4.1

It is: "signature expiration", "time signed". Where is stays up to RFC 2065.

In RFC 2535 "time signed" is renamed to "signature inception", but the
ordering isn't changed. So it's "signature expiration", "signature inception".

Does anybody know (remember?) why the switch was made during 
draft-ietf-dnssec-secext-00 and -02?

 grtz,

-- 
    Miek
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Mark Andrews <[email-masked]>
Date: Tue, 03 Jan 2012 00:52:27 +1100

> 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.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Miek Gieben <[email-masked]>
Date: Mon, 2 Jan 2012 15:03:38 +0100

[ Quoting <[email-masked]> at 00:52 on Jan  3 in "Re: [dnsext] SIG inc..." ]
> 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 expiration.

 grtz,

---

From: [email-masked]
Date: Mon, 2 Jan 2012 15:13:04 +0000

> assume the first time stamp is the inception and the second one is expiration.

it is possible to publish multiple sigs at the same time but covering different
intervals.  marks simplistic pov presumes that a sig is active when it appears.
as for ordering, Ed may chime in anyday now...

/bill

---

From: Edward Lewis <[email-masked]>
Date: Mon, 2 Jan 2012 19:13:34 -0500

>as for ordering, Ed may chime in anyday now...

Since you asked...the order was set before my time.  (DNSSEC was in 
discussion for about 2 years before I joined TIS.)  I don't know the 
rationale behind the ordering.  It does seem "odd" - but to me that's 
just the way it has always been.

Maybe Olafur, Brian, Donald, Jim Galvin and/or others (Gilmore?) might know.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

Vote for the word of the day:
"Papa"razzi - father that constantly takes photos of the baby
Corpureaucracy - The institution of corporate "red tape"
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Donald Eastlake <[email-masked]>
Date: Mon, 2 Jan 2012 20:42:23 -0500

I don't remember why it changed. One tends to think of the "logical"
order as being from-to. But I would note that, to put the most
critical information earliest, address fields are normally to-from,
that is, "destination-source". Perhaps it was changed in analogy to
that.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

On Mon, Jan 2, 2012 at 7:13 PM, Edward Lewis <[email-masked]> wrote:
> rationale behind the ordering.  It does seem "odd" - but to me that's just
> the way it has always been.
>

---

From: John Dickinson <[email-masked]>
Date: Tue, 3 Jan 2012 15:57:20 +0000

> assume the first time stamp is the inception and the second one is expiration.

That is true. I have often had to double check this order - I just remember that there is something funny with it now and always double check. 

I had always thought that, as Mark said, inception makes no difference to security, 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 

  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 long validity periods or we are nearing 2106. However, it makes me wonder if there is ever a reason to compare them, and if serial number arithmatic is actually meaningful here? 

John

---

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 03 Jan 2012 16:32:21 -0500

> It is: "signature expiration", "time signed". Where is stays up to RFC 2065.

I do not remember why/if the order was changed, but seem to recall that 
my first DNSSEC code written in fall 1994 (signer) did not inter operate 
with later code (resolver spring 1995) and the reason was the order 
change and I always coded from current drafts.

> draft-ietf-dnssec-secext-00 and -02?

No and I can not find version 01 anywhere.

	Olafur

---

From: [email-masked]
Date: Tue, 3 Jan 2012 22:03:24 +0000

> change and I always coded from current drafts.

	gahhh... should I pull out my code fm that era?

> No and I can not find version 01 anywhere.

	WDIFF sez:

http://ietfreport.isoc.org/cgi-bin/htmlwdiff?f1=..%2Fall-ids%2Fdraft-ietf-dnssec-secext-02.txt&f2=..%2Fall-ids%2Fdraft-ietf-dnssec-secext-01.txt

	this didn't change btwn 01 and 02...

WDIFF sez it didn't change btwn  00 and 01...

BUT....

00-01  has this identical text:

5.1 SIG RDATA Format		
		
The RDATA portion of a SIG RR is as shown below. The integrity of		
the RDATA information and that of the SIG RRs owner, type, and class		
are protected by the signature field.		
		
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3		
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		
| signer's name |		
/ /		
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		
| original TTL |		
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		
| time signed |		
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		
| signature expiration |		
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		
| sig length | /		
+-+-+-+-+-+-+-+-+ signature -+		
/ /		
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

01-02 has this identical text:

4.1 SIG RDATA Format		
		
The RDATA portion of a SIG RR is as shown below. The integrity of		
the RDATA information and that of the SIG RRs owner, type, and class		
are protected by the signature field.		
		
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3		
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		
| type covered | algorithm | labels |		
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		
| original TTL |		
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		
| signature expiration |		
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		
| time signed |		
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		
| key footprint | /		
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ signer's name /		
/ /		
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		
| signature /		
/ /		
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

--------------------------------------------------------------------------------

/bill

---

From: Mark Andrews <[email-masked]>
Date: Wed, 04 Jan 2012 12:29:22 +1100

In message <[email-masked]>, John Dicki
nson writes:
> 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.

> 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.

---

From: Miek Gieben <[email-masked]>
Date: Wed, 4 Jan 2012 08:48:08 +0100

[ Quoting <[email-masked]> at 22:03 on Jan  3 in "Re: [dnsext] SIG inc..." ]
> 	gahhh... should I pull out my code fm that era?

Why not? I'm curious.

Regards,
Miek