Subject: Re: Large typecodes and DNSSEC

From: "Olaf M. Kolkman" <[email-masked]>
Date: Tue, 4 Nov 2003 16:07:43 +0100

The discussion on this topic died out.

I think I can summarize that the WG seems to think that a
not-backward-compatible NSEC 'bitmap' is the thing to work toward.

To focus the discussion on one particular proposal I'd like to invite
comments on Michaels proposal (*) as is with one modifications: Drop
format 0.  Retain only "compressed" type lists (format 1).

This addresses Paul's worry about the data size limits and Andreas'
worry about the possibility that two different formats can be choosen
to calculate the same information resulting in possible RRSIG
ambiguities. (I hope I summarized that one correctly :-) )

What does the working group think? Any security issues that are opened
up by this change in representation? What are we missing?

--Olaf
  DNSEXT Co-Chair.

(*) Michaels proposal is in
http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg02005.html

PS.  As for 'silly state' we use the language as currently defined in
     proto-3 (2.3: "The type bitmap of every NSEC resource record in a
     signed zone MUST indicate the presence of both the NSEC record
     itself and its corresponding RRSIG record.", and 5.4 "Since a
     verified NSEC RR proves the existence of both itself and its
     corresponding RRSIG RR, a verifier MUST ignore the settings of
     the NSEC and RRSIG bits in an NSEC RR.")

     We asked for text to modify this it was not supplied so I
     consider this issue closed.  (see
     http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg01851.html)
     Lets stick to the issue at hand, the representation of the
     bitmap, not the semantics of the NSEC RR.

--
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: Samuel Weiler <[email-masked]>
Date: Tue, 4 Nov 2003 21:26:08 -0500 (EST)

I'm not moved by Paul's concern that the new and improved NSEC must be
able to list every typecode, and I'd still prefer the 16-bit list.

With this format, we run the risk that an implementer will assume
that, at least for the life of whatever piece of code he's writing,
there will never be types with non-zero prefixes (or even greater than
128) and optimize by not processing more than one block (or the
negative format).

That said...

In Micheal's draft, section 6.1 needs to make it clearer that the
count/high/data blocks can repeat -- now that's not obvious until the
example.  While the HIGH-ORDER description mentions increasing order,
it's not being completely clear that what's being sorted are
count/high/data blocks.

-- Sam

---

From: Matt Larson <[email-masked]>
Date: Wed, 5 Nov 2003 13:25:47 -0500

> format 0.  Retain only "compressed" type lists (format 1).

I agree with Sam's sentiments expressed in an earlier message and
propose the opposite: that we retain format 0 (simple 16-bit type
list) and drop format 1, which is clever but complicated.  It strikes
me as unnecessariy optimization.

> This addresses Paul's worry about the data size limits

I don't think this concern is realistic.  The protocol need not
accommodate an NSEC specifying every possible type.  There are similar
trade-offs elsewhere.  For example, the protocol currently allows 127
levels of name space depth and 63-octet labels, but places a realistic
limit of 255 characters on the length of a domain name.  Or: the
speedometer in my car goes up to 160 miles per hour but the tires
supplied by the manufacturer are not rated for that speed.

Real-world experience shows that the vast majority of names have just
a few types.  Format 0 would still accommodate the outliers by
allowing well over 32,000 types.  Let's not over-optimize and
over-complicate.

Matt

---

From: Rob Austein <[email-masked]>
Date: Wed, 05 Nov 2003 13:51:28 -0500

I think Matt's pegged it.  Format 1 is clever but more complicated
than the problem at hand seems to merit.  My preference would be
either format 0 or David's trivial optimization on format 0.