Subject: RE: WGLC on DNSSEC bis document set

From: Eastlake III Donald-LDE008 <[email-masked]>
Date: Thu, 22 Jan 2004 10:39:41 -0500

I think it is clear if you actually go look at the serial number arithmetic RFC;
however it would probably be helpful to change

   Signature Expiration and Inception field values are in POSIX.1 time
   format: a 32-bit unsigned number of seconds elapsed since 1 January
   1970 00:00:00 UTC, ignoring leap seconds, in network byte order.

to

   Signature Expiration and Inception field values are POSIX.1 time
   format modulo 2**32: the least significant 32-bits of the number of
   seconds elapsed since 1 January 1970 00:00:00 UTC, ignoring leap
   seconds, in network byte order.

Since I believe that signature validity periods will rarely be even as
long as one year, there is no need to waste bits by expanding these
fields to 64 bits or to lose the one second resolution by scaling them.
This is an instance where "serial number arithmetic" with a resolution
of one second works well.

Thanks,
Donald

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, January 22, 2004 2:32 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: WGLC on DNSSEC bis document set

records-06 3.1.5
	description of signature expiration/inception field is a bit confusing.
	for instance, when expiration is smaller than inception (like
	expiration = 1 and inception = 2^32 - 1), expiration field is not the
	number of seconds since 1970/1/1, but 2^32 more.

	what happens when 2^32 seconds have passed? (year 2106)
	maybe it's better to have these fields 64bit, or have scaling parameter
	like TCP window scaling option?

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: [email-masked]
Date: Fri, 23 Jan 2004 11:04:05 +0900 (JST)

> of one second works well.

	based on what i get from protocol-04 page 28, expiration/inception
	field will be compared to wall clock of resolver, therefore DNSSEC
	baesd on the current packet format will not work after year 2106.
	so i think it necessary to address "after year 2106" issue by some way.
	there are multiple possibilities:
	- expand the field to 64bits
	- scaling (trade lifetime with resolution)
	- anything else?

itojun

---

From: Samuel Weiler <[email-masked]>
Date: Fri, 23 Jan 2004 13:59:03 +0100 (CET)

Most of the items I found during my review of the DNSSECbis documents
were either omissions or editorial in nature.  I've included a summary
below.  I don't think any of these are major technical issues -- most
are matters which are well understood but incorrectly or inadequately
documented.  This message is intended mostly as a reference list.  I
suggest that we start separate threads for each issue that needs
discussion (such as the mnemonics message I just end).  For several of
these items, more extensive discussion has been sent to the editors'
list and many more minor nits have been sent to the editors.

In -protocol, the DS-13 resolver-side grandparent problem fixes are
missing.  Section 3.1.4.1 tells servers authoritative for both a zone
and its grandparent how to answer a DS query (with NODATA), and
section 4.2 tells resolvers to ask the parent zone for the DS, but it
doesn't tell resolvers how to find the parent zone.  RFC3658 section
2.1.2.2 has the needed closest encloser logic.

-protocol needs to discuss the safety property and the resolver-side
mandatory algorithm rules (per Mark Andrews' message).  I'll post more
about this in a separate thread.

The docs need to do a better job explaining the DNSKEY->DNSKEY
indirection.  Intro's diagram (DNSKEY->[DS->DNSKEY]*->RRset) misses it
entirely, as pointed out earlier.  Intro and/or protocol need to
explicitly say that having only a single DNSKEY in a zone works, and
there are times when the mention of SEP/ZSK/KSK is confusing and
perhaps misleading.

As my comments on -intro noted, there are some very messy editorial
changes that I think would be wise to complete before advancing that
document.

David Blacka found a problem with the canonical ordering section in
-records (good eye, David!)

In -records section 4, just as in the NSEC doc, "authoritative" is not
locally defined and may confuse readers.  -protocol section 2.2 does
the job admirably.  I suggest a direct reference from records section
4 to protocol section 2.2.

-protocol section 3.2.2 implies that the default is to ignore the CD
bit setting, which has the potential to deny data to clients that
specifically want unvalidated data.  The default should be to honor it
(and copy it to outgoing queries).  We can allow resolvers to un-set
the bit (with a MAY), but need to add lots of Security Considerations
text to explain how this might deny service to unsuspecting clients.
Furthermore, it should be clarified that a resolver MAY choose to set
CD even though the incoming query didn't set it (ie. if the resolver
is planning to do validation itself).  (Credit to Mark Andrews for
this last observation.)

-protocol sections 3.2.2 and 4.2 (and perhaps others) say one MUST do
something unless local policy is not to.  If it's reasonable for local
policy to override something, a 2119 MUST doesn't make much sense.
(Noticed by workshop participants.)

I posted a specific MUST/SHOULD concern to the list re: out-of-date
RRSIGs.

I previously observed that intro's security considerations doesn't say
enough about how DNSSEC can make the DNS more fragile.  protocol-05's
security considerations actually does that pretty well.  I'd like to
see more Security Considerations text across the board, but this
concern has been addressed.

And I just sent a note about mnemonics.

-- Sam