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: Michael Richardson <[email-masked]>
Date: Tue, 28 Oct 2003 20:04:32 -0500

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Samuel" == Samuel Weiler <[email-masked]> writes:
    Samuel> Yup -- we need to do that.  How's this: If you see the zero bit
    Samuel> set AND THE NSEC VALIDATES, treat this name as unsecured unless
    Samuel> you have evidence to the contrary (ie. a validated RRset)?

  This sounds like the minimum that we can do.

    Samuel> I think we can get away with putting this off -- we have the
    Samuel> extension mechanism in place and can deal with it later.  With
    Samuel> the current typecode burn rate, the current format will outlast a
    Samuel> resolver replacement cycle.  Maybe two.

    Samuel> But if folks really insist, let's get it done quickly.  I'm sure
    Samuel> we can settle on a format.  Can we get multiple interoperable
    Samuel> implementations out the door before Minneapolis?  Seriously -- I
    Samuel> want to get this rev out.  I suggest that the chairs decline the
    Samuel> change unless we have two pieces of interoperable code within
    Samuel> some short amount of time, perferably pre-MSP.

  Why do we need two interop's in order to publish 2535bis?

] Collecting stories about my dad: http://www.sandelman.ca/cjr/ |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian/notebook using, kernel hacking, security guy");  [

---

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.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 05 Nov 2003 19:11:01 +0000

> either format 0 or David's trivial optimization on format 0.

i very nearly agree, but if so then the draft needs an explaination
of the fact that no secured name can have more than 32000 type codes
in use.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 29 Oct 2003 13:23:16 -0500

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Michael" == Michael Graff <[email-masked]> writes:
    Michael> And here it is.  :)

  Thank you.
  I suggest that the working group adopt this document.

    Michael> F The encoding format used.  0 indicates a simple list of 16-bit
    Michael> type codes.  1 indicates a slightly compressed type code list.

    Michael> 6 - Format 1: compressed type code list

  Minimally complicated, sure. Probably really easy to implement.

  I'm not even sure it is worth it. Likely not even worth my words to 
ask if it is worth it. Just do it.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 28 Oct 2003 19:51:50 -0500

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "David" == David Blacka <[email-masked]> writes:
    David> At this point, having read through long threads discussion what we
    David> might have to do if RSA is broken, I am at a loss to understand
    David> why this issue hasn't been considered important.  Actually, I am
  
  Fatigue. It was my understanding that when this topic last came up,
that the WG was pretty exhausted about other things.

    David> Why not take a position?  I'll take a position: DNSSEC is not
    David> complete without the ability to handle types > 127.  Just because
    David> there aren't any now is no excuse. 
  
  I concur, and we should fix it.

    David> - use the remaining 7 bits in the first octet as a count of
    David> single-byte typecodes, called N.  The next N octets are an ordered
    David> list of 8-bit integers representing typecodes <= 255.  The
    David> remaining RDATA is an ordered list of 16-bit big-endian unsigned
    David> integers, each representing one type present.

  Works for me.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 5 Nov 2003 15:26:01 -0600

>     David> integers, each representing one type present.

Er, if we're going to change the format anyway, why not avoid having a 
flag bit?

---

From: Stephen Jacob <[email-masked]>
Date: Wed, 5 Nov 2003 14:09:28 -0800

> Er, if we're going to change the format anyway, why not avoid having a 

I have to say I dislike the scheme suggested above (David's).

With Michael Graff's format 1 (compressed), you get a homogenous
list of lists (with each sub-list having a 'header', for wont of a
better word). With David's scheme, you have a 'header' byte and then
a list in one format, followed by a list in a different format (so
the format of the data change part way through).

Michael's scheme makes more intuitive sense to me and doesn't seem
like it would be any burden on implementors. I tend to think that
his draft, with format 0 (uncompressed; list of 16-bit codes) removed
would be the best solution to the problem.

Regards,
sj
-- 
 Stephen Jacob | [email-masked] | +1 650 381 6051
 Nominum, Inc. | http://www.nominum.com/ | "Communication by Name"