Subject: Large typecodes and DNSSEC

From: David Blacka <[email-masked]>
Date: Tue, 28 Oct 2003 14:02:41 -0500

Currently the NSEC record (nee NXT) can only support typecodes up to
127 (dnssec-records-05, section 4.1.2).  However, the type field in
DNS is actually 16 bits long.

While this situation has been true for as long as I've been looking at
DNSSEC, and presumably since its inception, this is an issue that
seems to have been totally ignored by this WG.

I would like to know:

  * How can we consider DNSSEC complete while it ignores 9 of the 16
    bits in the typecode field?

  * What happens when (or if), after this current DNSSEC spec is
    widely deployed, we want to define typecode 128?  Do we do another
    typecode rollover? Move the DO bit? add another EDNS flag?

In the current form, I feel that DNSSEC will artificially constrain
DNS typecodes to no larger than 127, simply because existing
implementations of DNSSEC-aware DNS software will not be able to
handler larger typecodes, and we all know how much of a PITA getting
everyone to roll out new DNS software is.

  * If the intention is the constrain the typecode field to 7
    effective bits, then please explain why.  Is the intent to reserve
    the remaining 65407 types for psuedo types?

  * Why haven't we already defined the alternate format of the NSEC
    typecode field?  Are we waiting for some future breakthrough that
    will allow us to handle these giant numbers between 128 and 65535?

This WG has spent a fair amount of time on other issues of forward
compatibility, but why not this?

-- 
David Blacka    <[email-masked]> 
Sr. Engineer    Verisign Applied Research

--
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: Rob Austein <[email-masked]>
Date: Tue, 28 Oct 2003 15:38:09 -0500

At Tue, 28 Oct 2003 14:02:41 -0500, David Blacka wrote:
>...

According to RFC 2335, which DNSSECbis hasn't changed in this regard,
we set bit zero of the typecode "bitvector" to one.  I put "bitvector"
in quotes because I strongly suspect that the actual representation at
that point would not be a bitvector.

I don't much like this either, but the WG has not chosen to rip the
covers off of this particular piece of 2535.

> everyone to roll out new DNS software is.

Fair point.

>     the remaining 65407 types for psuedo types?

I don't think there was any such intention.  For historical reasons
(having to do with the fact that DNS types and classes were only 8-bit
values in the earliest DNS specs), the typecodes allocated so far all
happen to fit the bitvector encoding hack proposed in the original
DNSSEC specs.  The WG chose to go for this hack.

>     will allow us to handle these giant numbers between 128 and 65535?

Ok, fair enough.  With the understanding that I am -not- taking a
position on whether the WG should do anything about this at this time,
here's a proposed encoding for you to use as a strawcritter.

- Bit zero of "bitvector" is a flag bit as described in RFC 2535 and
  DNSSECbis drafts

- Remainder of first octet of "bitvector" is a version number for this
  encoding format (unless somebody can think of a more important use
  for those seven bits).  This email message defines format zero (ie,
  all seven of those bits must be zero).

- Rest of "bitvector" is an ordered list of 16-bit bigendian unsigned
  integers.  Each integer represents one type present at the owner
  name.  The list must be sorted into ascending order (not strictly
  necessary, but might simplify some operations and is easy to do).

So the "bitvector" would be 2*N+1 octets for a name with N distinct RR
types.  Not a particularly compact encoding.  If the WG decides that
it's interested in this subject, somebody should do the numbers to see
what this does to typical response sizes, but recall that DNSSECbis
requires EDNS0, so we're not limited to 512-octet packets.

---

From: David Blacka <[email-masked]>
Date: Tue, 28 Oct 2003 16:47:45 -0500

> covers off of this particular piece of 2535.

I guess I'm in the position of arguing that it needs to.

> DNSSEC specs.  The WG chose to go for this hack.

At this point, having read through long threads discussion what we might 
have to do if RSA is broken, I am at a loss to understand why this issue 
hasn't been considered important.  Actually, I am at a loss to understand 
why it wasn't an issue in the first place.  It isn't like types where only 
8 bits then.

> here's a proposed encoding for you to use as a strawcritter.

Why not take a position?  I'll take a position: DNSSEC is not complete 
without the ability to handle types > 127.  Just because there aren't any 
now is no excuse.

>   all seven of those bits must be zero).

If you define format version, it will either be useless or near-useless due 
to the difficulty in globally updating DNS software.  Unless we go further 
and define good behavior for when a validator sees an NSEC format it 
doesn't recognize.  But I'm not exactly certain why we would need multiple 
formats anyway.  It isn't like we don't understand this namespace.

Here is an alternative strawcritter:

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

---

From: Paul Vixie <[email-masked]>
Date: Tue, 28 Oct 2003 21:51:12 +0000

> covers off of this particular piece of 2535.

and yet, can serious deployment (burning of roms containing the software)
begin without a defined solution for typecodes above 127?

> here's a proposed encoding for you to use as a strawcritter.

michael graff and i here at isc have also experimented with several
encodings that would support typecodes above 127.  is it time for a
bake-off?  perhaps so, if olaf is rattling the WGLC sabre...

---

From: Rob Austein <[email-masked]>
Date: Tue, 28 Oct 2003 17:07:07 -0500

At Tue, 28 Oct 2003 16:47:45 -0500, David Blacka wrote:
> Why not take a position?

Waiting to hear what other people have to say, for which reason I'll
shut up on this subject for a while after this message.

> list of 16-bit big-endian unsigned integers, each representing one type 

Your strawcritter is better than mine.

---

From: Paul Vixie <[email-masked]>
Date: Tue, 28 Oct 2003 22:10:46 +0000

i agree.  and just to make sure my position is unambiguously clear:

> ...  I'll take a position: DNSSEC is not complete without the ability
> to handle types > 127.  Just because there aren't any now is no excuse.

i agree with this too.

> Here is an alternative strawcritter:

sounds like a bakeoff is in order.  mister graff, you may fire when ready.

---

From: Samuel Weiler <[email-masked]>
Date: Tue, 28 Oct 2003 23:56:12 +0100 (CET)

<panic>
NOOOOOOOOOO!!!!!!!
</panic>

> ... having read through long threads discussion what we might
> have to do if RSA is broken, ...

We tackled "having space to deal with RSA being broken" even though
we don't have good alternatives to replace it.  We needed to make sure
that "safe" failure modes exist and that phase-in of a new algorithm
would be possible.

In this case, we already have a provision for dealing with bigger
typecodes.  We don't know how we'll deal with them, but at least the
provision is there.

> Unless we go further and define good behavior for when a validator
> sees an NSEC format it doesn't recognize.

Yup -- we need to do that.  How's this: If you see the zero bit set
AND THE NSEC VALIDATES, treat this name as unsecured unless you have
evidence to the contrary (ie. a validated RRset)?  Treating the entire
name as non-existing is too harsh.  This means that a name with that
bit set can have its RRs spoofed away, but at least bad data can't be
substituted.

Paul asks:
> can serious deployment (burning of roms containing the software)

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

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

-- Sam

---

From: David Blacka <[email-masked]>
Date: Tue, 28 Oct 2003 18:48:26 -0500

> that "safe" failure modes exist and that phase-in of a new algorithm

Yes, I agree.

> typecodes.  We don't know how we'll deal with them, but at least the

What provision? What we have now is an undefined format, which isn't worth 
anything.  What happens when a validator sees a NSEC record with bit 0 set 
to one?  Who knows? It is "undefined".

> bit set can have its RRs spoofed away, but at least bad data can't be

We could do this, and it would work.  It is why I mentioned this 
possibility in the first place.  And I think that defining a rule like 
this is maybe the minimum we can do right now.  But it would have to be 
defined in the DNSSECbis documents.  It currently isn't.

IMHO, it would be easier to define the alternative format than to work 
through the security implications of a NSEC RR with an unknown type 
format.  This isn't rocket science.  Honestly, I'm baffled that no one has 
handled this before now.

> replacement cycle.  Maybe two.

Well, we don't have the extension mechanism in place, which is partially my 
point.

While I may personally believe that we are likely to go through multiple 
flag-days with DNSSEC, it would be stupid to proceed with that 
expectation.  And who knows what the future "burn rate" on typecodes is?

> amount of time, perferably pre-MSP.

Yes, I apologize for not bringing this up three years ago.

I understand the desire for closure on DNSSEC, but I suggest that we not 
advance obviously deficient documents.

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Wed, 29 Oct 2003 12:00:26 +0100

> bake-off?  perhaps so, if olaf is rattling the WGLC sabre...

As the sabre is being polished we see yet another stain *sigh* (I am
tempted to use much bloodier metaphors, but refrain)

Sam wrote:
> I suggest that the chairs decline the change
>  amount of time, preferably pre-MSP.

Chairs can decline _topics_ out of scope e.g. if they have been
discussed at length and declined by the WG before. Hoping my memory is
not selective I think that this topic is _not_ out of scope.

We need specs, rather before than after IETF58. Running code as proof
of concept surely helps to convince the WG.

Remember, the RFC2535bis document-set is not intended to change the
protocol, it should only clarify, changes go through the IETF
seperatly. I think that we can argue that Sam's suggestion is actually
a clarification rather than a protocol change so that can go into the
documents directly, it describes what to do in the failure state, an
omission in 2535,

I'll be following this thread with this question in mind:
  Can the working group consent with Sam's clarification on how to
  handle when the validated NSEC zero bit is set or is there consent
  for alternative encoding.

-- Olaf 
   DNSEXT Co-Chair.

---

From: Matt Larson <[email-masked]>
Date: Wed, 29 Oct 2003 10:41:41 -0500

On Tue, 28 Oct 2003, David Blacka wrote:
> format.  This isn't rocket science.

I agree.  The incremental work of defining an encoding can't be much
more than punting with language about undefined states, treating as
unsecure, etc.

> advance obviously deficient documents.

What Dave said....  Let's define something (sounds like Mr. Graff has
a proposal already), put it in the docs and move on.

Matt

---

From: Michael Graff <[email-masked]>
Date: Wed, 29 Oct 2003 17:21:49 +0000

And here it is.  :)

   DNSEXT Working Group                                      Michael Graff
   INTERNET-DRAFT                                                      ISC
   <draft-graff-dnsext-nxt-extend.txt>                       October, 2003

                Extensions to NXT records for all rdata types

   Status of this Memo

      This document is an Internet-Draft and is in full conformance with
      all provisions of Section 10 of RFC2026.

      Internet-Drafts are working documents of the Internet Engineering
      Task Force (IETF), its areas, and its working groups.  Note that
      other groups may also distribute working documents as Internet-
      Drafts.

      Internet-Drafts are draft documents valid for a maximum of six months
      and may be updated, replaced, or obsoleted by other documents at any
      time.  It is inappropriate to use Internet-Drafts as reference
      material or to cite them other than as "work in progress."

      The list of current Internet-Drafts can be accessed at
      http://www.ietf.org/ietf/1id-abstracts.txt

      The list of Internet-Draft Shadow Directories can be accessed at
      http://www.ietf.org/shadow.html.

   Abstract

      This document specifies a format for NXT records which allows NXT
      records to specify any rdata type as covered by the NXT, rather than
      being limited to the first 127 types.

   1 - Rationale and Scope

   1.1. Currently, NXT records can only describe the first 127 rdata types
   (1 through 127.)

   1.2. Several rdata types are in use by vendors which cannot be covered
   by existing NXT records.  Additionally, the experimental range cannot be
   covered.

   Expires April 2004                                      FORMFEED[Page 1]

   INTERNET-DRAFT                   NXT-EXT                   October, 2003

   1.3. The DNS rdata code space usage is expected to grow.  Rolling out
   new formats for rdata types is difficult operationally.  Making the NXT
   record support the future is important before widespread deployment of
   DNSSEC prevents such extensions.

   1.4. The existing NXT record format allows for extension by setting bit
   0 to one.

   2 - Affected Protocol Elements

   2.1. Bit 0 of the first byte in the NXT record rdata indicates this is
   an extended NXT record.

   3 - Compatibility with existing servers

   3.1. Older servers will not understand this format.

   3.2. This extension uses the mechanism provided in the NXT rdata format
   of RFC2535.

   4 - Extended NXT rdata format

   4.1. The extended NXT rdata begins with the high order bit set in the
   first byte and the two low-order bits indicate which format the NXT data
   is encoded using.  All other bits MUST be set to zero.

          +---+---+---+---+---+---+---+---+
      0   | 1 | R | R | R | R | R | R | F | 8
          +---+---+---+---+---+---+---+---+

   R  Reserved bits.  MUST be set to 0 when transmitting to allow
      extensions.

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

   5 - Format 0: 16 bit type code list

   5.1. The data is a simple list of 16-bit type codes, listed in
   increasing value.

   Expires April 2004                                      FORMFEED[Page 2]

   INTERNET-DRAFT                   NXT-EXT                   October, 2003

          +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
      0   |                           RDATA_TYPE                          | 16
          +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

   RDATA_TYPE
      The 16-bit type codes defined in various RFCs.

   5.2.  For example, if a NXT contains SIG (24), NXT (30), A (1), TXT
   (16), MX (15), and type 0xff45 types, the 16-bit values will be encoded
   as:

            0x0001 0x000f 0x0010 0x0018 0x001e 0xff45

   6 - Format 1: compressed type code list

   6.1. This format uses a simple compression method to factor out the
   first 8 bits of a prefix code for a group of codes.  This is done by
   specifying a one-byte count, a one-byte prefix, and "count" bytes of
   low-order data.

          +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
      0   |             COUNT             |           HIGH-ORDER          | 16
          +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
          |       Data...          |    ...                 |
          +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

   COUNT
      This value indicates how many type codes follow which use the high-
      order value.  A count of 0 indicates that no "data" bytes follow but
      all 256 possible rdata type codes exist for this high-order value.
      Values between 1 and 128 indicate the types are present, and there
      are 1 to 128 octets that follow.  Values of 129 through 255 indicate
      that 256 - count octets follow, and they specify type codes NOT
      present.

   HIGH-ORDER
      The upper 8 bits of the type codes, listed in increasing value.

   Data
      "count" bytes to supply the low-order type code data, listed in
      increasing value.

   Expires April 2004                                      FORMFEED[Page 3]

   INTERNET-DRAFT                   NXT-EXT                   October, 2003

   6.2. For example, the coding for a record containing A, MX, TXT, SIG,
   NXT, and type 0xff45:

           0x05 0x00 0x01 0x0f 0x10 0x18 0x1e 0x01 0xff 0x45

   Expires April 2004                                      FORMFEED[Page 4]

   INTERNET-DRAFT                   NXT-EXT                   October, 2003

   7 - References

   [RFC1035]  P. Mockapetris, ``Domain Names - Implementation and
              Specification,'' RFC 1035, USC/Information Sciences
              Institute, November 1987.

   [RFC2535]  D. Eastlake, ``Domain Name System Security Extensions,'' RFC
              2535, IBM, March 1999.

   8 - Author's Address

                 Michael Graff
                    Internet Software Consortium
                    950 Charter Street
                    Redwood City, CA 94063
                    +1 650.423.1304
                    <[email-masked]>

   Expires April 2004                                      FORMFEED[Page 5]

---

From: Michael Graff <[email-masked]>
Date: Wed, 29 Oct 2003 17:41:40 +0000

And of course, please s/NXT/NSEC/ -- this was written before the
proposed typecode roll names were set in mud.

--Michael

---

From: Stephen Jacob <[email-masked]>
Date: Wed, 29 Oct 2003 10:17:36 -0800

Hi Michael,

>    is encoded using.  All other bits MUST be set to zero.

Is the text correct or is the diagram correct? I think the diagram
is correct, based on the subsequent text, but the text in the initial
paragraph of 4.1 says, "...the two low-order bits indicate which
format...", but it seems to be suggested elsewhere that this should
be, "...the low-order bit indicates which format...".

Actually, to me "most significant bit" and "least significant bit"
are clearer than "high[est]-order bit" or "low[est]-order bit".

>    specifying a one-byte count, a one-byte prefix, and "count" bytes of

Since the "Data..." are specifically 8-bit quantities, and not
variable bit-length quantities, it might be better to re-do this
figure. Perhaps something like:

          |             DATA              |             DATA              |
          |             DATA              |            ...

Or perhaps better (since showing it as 16 bits wide might suggest
that there had to be an even number of data), something like:

      0   |             COUNT             |   8
          |           HIGH-ORDER          |
          |             DATA              |
          |             DATA              |
          .                               .
          .                               .
          .                               .

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

---

From: Michael Graff <[email-masked]>
Date: Wed, 29 Oct 2003 18:33:37 +0000

> be, "...the low-order bit indicates which format...".

The diagram is correct.  There used to be additional encodings, but
they didn't seem worth it for how complicated they became.

> are clearer than "high[est]-order bit" or "low[est]-order bit".

Noted.

> figure. Perhaps something like:

Thanks much.  I'll see what I can do there.  :)

--Michael

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 29 Oct 2003 20:35:54 +0100

> seems to have been totally ignored by this WG.

The now expired proposed NXT replacement draft at
<http://josefsson.org/draft-ietf-dnsext-not-existing-rr.txt> address
that problem, and a few other problems with NXT that haven't been
addressed (nor firmly acknowledged as problems, for that matter).

Thanks,
Simon

---

From: Daniel Massey <[email-masked]>
Date: Wed, 29 Oct 2003 15:24:41 -0500

>    is encoded using.  All other bits MUST be set to zero.

I think there is a basic problem with having multiple formats.  
Consider the following:

Query:  www.example. A
Response: NO DATA
           www.example. NSEC with zero bit set to 1 (format whatever)
           www.example. SIG(NSEC) by example DNSKEY

The SIG authenticates the NSEC, but the resolver doesn't understand the 
format....   what happens?  Note the resolver is just asking for a 
plain old A record.    The server had to use one of the alternate 
formats since some RR type > 127 is present at www.example and setting 
zero bit = 0 was not an option at the server.    The resolver has no 
way of knowing whether this response proves no A RR exists.   (it could 
be an attacker is sending the NSEC proving the A RR **does** exist, 
knowing the resolver doesn't understand the extended format).

I think what you will find is that in the current term, very few people 
implement the alternate formats for what to do if RR types > 127.   
Fewer still will have really tested these formats so we know they 
work....    As a result when someone adds the first type >127, queries 
for things like A records and DS records can stop working.  If large 
vendor X has failed to implement the >127 type map or discovers it has 
a flaw in this type second (or third or fourth) type map, what do you 
do?   the software won't even be stressed in real conditions until 
years from now...

I have yet another alternate suggestion that handles all type codes, 
but ensures that the process rules for the current types < 127 never 
change:

Type 128 is the FOO record.    The FOO record MUST be present at a name 
if any RR type greater than 128 exists at that name and this record 
lists the types greater than 128 stored at this name.  The FOO record 
MUST NOT be present at a name if no type greater than 128 exists at 
that name. The format of the FOO record is to be defined by a standards 
action if/when the RR type space exceeds 128.

If the query type < 127, do what protocol doc currently says.   If the 
query type > 127 and the answer is no data, do what the protocol do c 
currently says and also the server SHOULD include the FOO RR in the 
response.

If the NSEC zero bit is set in the response, RR types greater than 128 
are present at this name.  If these types are meaningful to the 
resolver, the FOO record indicates which types >127 are present at this 
name.   Queries for types less than 127 are still authenticated 
according the rules above.   If a query that requests types greater 
than 127 and the answer is no data, the FOO record is used to prove the 
requested type does not exist.

For the current doc set, issue done.   Anyone with strong opinions on 
how to encode the type field for types beyond 128, write a FOO record 
draft, but we don't need FOO defined to advance this doc set.   If no 
one writes the FOO record, somewhere down the road the first person to 
define a type greater than 128 is stuck with defining the FOO RR :) 
Note software that has been upgraded to understand the new type > 128 
will need to also be upgraded to understand the new FOO record.   Old 
software (ie today's stuff) will always be able to work fine for all 
types < 128 and will be backwards compatible.

For example, with the FOO RR:

Query:  www.example. A
Response: NO DATA
           www.example. NSEC with zero bit set to 1
           www.example. SIG(NSEC) by example DNSKEY

A resolver looking for the A record can doesn't care the zero bit is 
set to 1.   The current bit map indicates no A record exists.  This 
will always work regardless of what happens due to any increase in the 
type space.

Query: www.example type150
Response:  NO DATA
            www.example. NSEC with zero bit set to 1.
            www.example. SIG(NSEC) by example DNSKEY
            www.example. FOO (indicating what types > 127 exist at 
www.example)
            www.example. SIG(FOO) by example DNSKEY

A resolver looking for the type150 record needs to understand the FOO 
RR.

Dan

---

From: Brian Wellington <[email-masked]>
Date: Wed, 29 Oct 2003 12:28:13 -0800 (PST)

> proposed typecode roll names were set in mud.

Given that the typecodes are being rolled, we might want to consider 
removing the old format completely, and coming up with a new, sane format 
that doesn't have any problem representing all types within the type 
code space.

The compressed format in this document seems like it does that, and it's 
fairly efficient for typical cases.

Do we really need multiple encodings, and backwards compatibility with a
record of a different type?

I propose that we standardize on this (or something better, if anyone has 
a better idea) as the only format and get rid of versioning.

Brian

---

From: Matt Larson <[email-masked]>
Date: Wed, 29 Oct 2003 15:41:01 -0500

On Wed, 29 Oct 2003, Daniel Massey wrote:
> format....   what happens?

I believe this issue will be taken care of by rolling the type codes
and the RFC2535bis documents.  The new documents will specify the new
behavior, which any RFC2535bis-compliant implementation will have to
follow.  We've already sacrificed any backward compatibility and a
fully specified NSEC record that can handle typecodes past 128 is just
another backward incompatibility.

> lists the types greater than 128 stored at this name.

This idea is an ingenious way to cope with the current situation, but
it's a terrible hack.  Let's spend the effort to fix NSEC instead.

Matt

---

From: Daniel Massey <[email-masked]>
Date: Wed, 29 Oct 2003 15:43:32 -0500

Hi,

After some discussions, here is a summary of the various previously 
proposed solutions for large typecodes:

fixed limit options:
a       NSEC only covers up to 127 (by fiat) [0]
b       NSEC expands bit mask to 512/1024 or some other higher number. 
[3]

order list options
c       NSEC covers 1-127 with bit mask and "ordered list" after that. 
[4]
d       NSEC with bit 0 set is turned into "ordered list" [1]
e       NSECbis has "ordered list" and replaces NSEC [2]

other extensions
f       NSEC covers types 1-127 and a FOO extends coverage for 129-n  
[5]

Historical Footnotes:
[0] The bit field was proposed for efficiency reasons.
[1] This is what Andreas proposed in 1997,
[2] This was proposed to Sam when he started the TCR draft.
[3] Original DNSSEC spec had typecode bitmap unrestricted, due to [1] 
and size concerns related to Truncation and OS vendor use of types in 
the 64xxx space, the restriction and bit 0 was put in.
[4] This was also proposed in the 1997 after [3] was put forward.
[5] This is yet another option from the previous message.

To close the records and protocol doc, consensus on one option is 
needed.   From a document editing perspective, quick consensus would be 
very very welcome.  (Note prior to this, last call seemed in sight for 
the records doc)

In my personal view....

One fundamental problem is that if there are multiple type field 
variations, it is possible implementations will not understand them all 
and it is probable that the code path for one of the type fields has a 
bug.  In particular, suppose we allow multiple type fields and someone 
implements only the 127 bit format current in records (or implements 
the other fields incorrectly, but it is not tested since types are < 
127).   Everything works great for now with types < 127, but when the 
first RR type greater than 127 is added, suddenly the altnerate NSEC RR 
formats are needed to correctly process A record queries.  types will 
roll....   My plea is we pick an encoding of the type field such that 
there is one and only one method to authenticate non-existence of the 
good old A record (as well as other current types like DS records).  
this method must work now and still work if the type space exceeds 127.

For the ordered list options, I would also hope that the ordering is 
not overly complex.   The type space may grow, but hopefully the number 
of records types at a given name will not stretch in into the thousands 
or even dozens.    A simple list is more likely be done correctly.

Under these criteria, option c, e and f work.  options a and b postpone 
the problem to when the space type space grows large.  option d creates 
multiple code paths for authenticated denial of existence for the good 
old A record.

Dan

---

From: [email-masked] (Andreas Gustafsson)
Date: Wed, 29 Oct 2003 12:52:37 -0800 (PST)

Brian Wellington writes:
>  [...]

I agree.  Given that the RR type is changing, keeping the old format
is pointless.

There is also the issue that any scheme that allows the server to
freely choose between multiple alternative wire encodings will not
actually work.  This is because DNSSEC signatures are calculated by
hashing the wire-format data, under the assumption that every RR has a
single, unique wire encoding.  If you allow multiple alternative
encodings, you can end up with a situation where the signer calculates
the signatures using one encoding but the name server sends the NSEC
records using a different encoding, and the signatures will fail to
match.
-- 
Andreas Gustafsson, [email-masked]

---

From: Samuel Weiler <[email-masked]>
Date: Wed, 29 Oct 2003 23:33:28 +0100 (CET)

> Type 128 is the FOO record.    The FOO record MUST be present at a name

How do you prove that there should or shouldn't be a FOO?  And the FOO
would have to be added to wildcard proofs, too.  This is too messy.

Let's just change the NSEC format.

-- Sam

---

From: Daniel Massey <[email-masked]>
Date: Wed, 29 Oct 2003 18:22:03 -0500

On Wednesday, October 29, 2003, at 05:33  PM, Samuel Weiler wrote:

> How do you prove that there should or shouldn't be a FOO?

this is bit zero in the NSIG.
bit zero = 1 proves there are types greater than 127 at this name (and 
proves there is a FOO RR that lists these types)
bit zero = 0 proves there are no type greater than 127 at this name 
(and proves there is no FOO RR at the name)

> And the FOO
> would have to be added to wildcard proofs, too.

the wildcard proof still relies on NSEC records.  You use the algorithm 
discussed the current protocol draft to prove whether the name 
exists/whether the wildcard applies.   At the end of the current NSEC 
proof, if the answer you seek is type > 127, you need the FOO RR to 
prove the type does/does not exist.

> This is too messy.
it is unquestionably ugly.   the intent is to make things work in the 
scenario that says:
   use format X if all type codes at this name are less than 127,
   use format Y if some types codes at this name are above 127,
   use format Z the zone is signed on tuesday, your master server has a 
black case, and your favorite type number is 3
this way lies madness and FOO RRs :)   but this is also the current 
approach and the FOO RR is intended only to make that madness work.

the clean fix is to scrap the existing format and define a **single** 
format for the NSEC type field that works for all RR types.

Dan

---

From: Samuel Weiler <[email-masked]>
Date: Wed, 29 Oct 2003 23:44:48 +0100 (CET)

If Andreas is right, and I think he is, then David's strawcritter:

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

may open the door to ambiguity -- can one set N=0 and list codes 3, 5,
and 7 in the 16-bit portion?  Micheal's format 1 may have the same
problem.

Is there anything wrong with the ordered list of 16-bit values
proposed separately by Rob and Micheal (format 0)?  Since the bits for
NSEC and RRSIG then take up space, do we want to make them implicit?
We could turn the silly-state language around and say "if either of
these typecodes is explicitly listed, treat this name as unsecured".

-- Sam

---

From: Rob Austein <[email-masked]>
Date: Wed, 29 Oct 2003 20:19:33 -0500

> records using a different encoding, and the signatures will fail to

You appear to be assuming some form of RDATA transcoding.  We have
that problem for certain well-known types containing DNS names due to
ancient history, but I don't understand why we would allow it here.
So long as the RRset received matches the RRset sent, the signatures
should match.

sig(2) == sig(2).  sig(ii) == sig(ii).  The fact that "2" and "ii" are
different ways of writing the number two shouldn't matter unless
somebody's translating from arabic to roman numbering en route.

At least one of us is confused.

---

From: Brian Wellington <[email-masked]>
Date: Wed, 29 Oct 2003 17:52:45 -0800 (PST)

> and 7 in the 16-bit portion?  Micheal's format 1 may have the same

Both of the formats in Michael's proposal include the phrase 'in 
increasing value.'  This should make the representation unique, as long as 
only one format is chosen.

> these typecodes is explicitly listed, treat this name as unsecured".

Adding special cases for RRSIG and NSEC is confusing.  Using a 16 bit
value is fine also.  The only difference is that the compressed method
allows all combinations of the 64K type codes to be represented without
exceeding the 64K limit for rdata, not that this really matters.

Brian

---

From: Paul Vixie <[email-masked]>
Date: Thu, 30 Oct 2003 01:45:43 +0000

> You appear to be assuming some form of RDATA transcoding.  ...

yes.

> somebody's translating from arabic to roman numbering en route.

a cache who converted an rdata from wire format to host-byte-order and
regenerated the wire format when queried for it could have that property.

---

From: David Blacka <[email-masked]>
Date: Wed, 29 Oct 2003 21:45:23 -0500

> At least one of us is confused.

I think what Andreas is talking about is this:  If there are two 
equally valid wire representations of the same record, there exists a 
possibility for say, the signer to do it one way, and the nameserver to 
encode it another.  Since the textual representation is the same either 
way, there is nothing to prevent this.

However, having multiple NSEC typecode formats is not a problem per se. 
  The issue is that all DNSSEC software must encode a particular NSEC 
record the exact same way.  This could be accomplished by saying 
something like: use format 1 when no typecodes > 127, format 2 
otherwise.

But, that being said, I can see no good reason for having more than one 
format in any case.

I think what we are looking for in a format is:

   * easy to understand.
   * easy to implement.
   * reasonably space efficient for "common" cases.

---

From: [email-masked] (Andreas Gustafsson)
Date: Wed, 29 Oct 2003 18:44:20 -0800 (PST)

> So long as the RRset received matches the RRset sent, the signatures

I'm not sure what you mean by "transcoding".  The RRset received is
identical to the one sent.

The problem is that the sequence of bytes over which the DNSSEC signer
calculates the signature when signing the zone can be different from
the sequence of bytes over which the resolver calculates the signature
when validating a response.

For example, suppose we have a domain name "zz." which is the last
name in the root zone, with only an A record and (after signing) an
NSEC record. Then the DNSSEC signer will insert an NSEC record of the
form

zz. NSEC . A NSEC

Suppose the signer chooses to represent this using the classic RFC2535
bitmap representation.  Then it will internally create an NSEC RDATA
containing the bytes

  00 40 00 00 00 00 00 80

and SIG NSEC record containing the signature of those bytes.
The signer writes the NSEC and SIG NSEC records to a signed master file.

The signed master file is then loaded by a master server.  Suppose the
master server chooses to represent this same NSEC record using Michael
Graff's uncompressed 16-bit wire format.  When queried, it will send
an NSEC RR with an RDATA of

  00 80 00 01 00 30

along with a SIG NSEC record that was calculated by the signer under
the assumption that the RDATA is 00 40 00 00 00 00 00 80.  When the
resolver attempts to validate the response, it calculates a signature
over the bytes 00 80 00 01 00 30.  This signature will then fail to
match the one in the SIG NSEC.

The byte sequences in the example above were constructed by hand in a
hurry and may not have all the right bits set, but that should not
detract from my point, that the signatures calculated by different
parties of the protocol can end up being different.
-- 
Andreas Gustafsson, [email-masked]

---

From: Rob Austein <[email-masked]>
Date: Wed, 29 Oct 2003 23:32:29 -0500

Ok, I was the one who was confused.  Right, if the signer and the name
server use different encodings, it doesn't work.  Thanks.

---

From: Samuel Weiler <[email-masked]>
Date: Thu, 30 Oct 2003 18:11:14 +0100 (CET)

>    * reasonably space efficient for "common" cases.

So I'll ask the following again:

1) Is there anything wrong with the ordered list of 16-bit values
proposed separately by Rob and Micheal (format 0)?

2) Since the bits for NSEC and RRSIG then take up space, do we want to
make them implicit?  (Brian has said "no", I say "yes" -- any others
want to speak up?)

3) If so, do we turn the silly-state language around and say "if
either of these typecodes is explicitly listed, treat this name as
unsecured"?

-- Sam

---

From: David Blacka <[email-masked]>
Date: Thu, 30 Oct 2003 12:29:24 -0500

> and 7 in the 16-bit portion?  Micheal's format 1 may have the same

Hah.  Now that it seems somewhat OK to ditch the bit map, I can improve my 
strawcritter:

  Use the first octet as a count of typecodes < 256, called N.  The next N 
octets are an ascending list of 8-bit integers representing typecodes < 
256.  The remaining RDATA is an ascending list of 16-bit big-endian 
unsigned integers greater than 255 representing typecodes > = 256. 

Actually, this isn't all that different from Michael's "compressed" format, 
except that it doesn't have any flag fields, and it doesn't attempt to 
compress larger typecodes, which would also probably be OK.

---

From: Michael Graff <[email-masked]>
Date: Thu, 30 Oct 2003 19:16:51 +0000

> exceeding the 64K limit for rdata, not that this really matters.

I personally like the idea of being able to represent many types, so
I'd rather see the compressed format move forward and the 16-bit
values method go away.

--Michael

---

From: Paul Vixie <[email-masked]>
Date: Thu, 30 Oct 2003 18:42:11 +0000

> proposed separately by Rob and Micheal (format 0)?

nope.

> make them implicit?  (Brian has said "no", I say "yes" -- any others

implicit is bad.  the space savings is negligible compared to the size of
the signature and key blobs.  explicit is less error prone, or rather, will
lead to earlier signalling of logic/protocol errors, compared to implicit.

> either of these typecodes is explicitly listed, treat this name as

no.

---

From: Samuel Weiler <[email-masked]>
Date: Fri, 31 Oct 2003 17:53:07 +0100 (CET)

> unsigned integers greater than 255 representing typecodes > = 256.

I like this strawcritter.

Are we completely ditching the first octet for format/reserved bits?
If so, we're breaking the "first bit set means alternate format", but
I think that's a safe thing to do, given the type code roll.

If not, we need a rule for what happens when the version is greater
than what the resolver groks.  Adapting the text I sent on Tuesday:
"If you don't have a validated positive answer and the NSEC validates
and you don't understand the NSEC format version, treat the name as
unsecured."

-- Sam

---

From: Paul Vixie <[email-masked]>
Date: Fri, 31 Oct 2003 17:55:37 +0000

> I like this strawcritter.

i don't.  on a strictly puritanical basis, we need a format which can
represent all rrtypes, just in case 65535 of them are ever known to
exist and all 65535 happen to be in use at a name.  the above format
is clean but since both a DNS message and an RDATA are limited to 64K
octets, and an RDATA probably shares its containing DNS message with
some other data an RDATA is probably limited to a size slightly smaller
than 64K octets.  a bit map of 64K bits would fit.  michael's compressed
format would fit, even in the corner case of every-other-typecode in use.
if we can find something clean that is also pure, then so much the better.

yes.

> and you don't understand the NSEC format version, treat the name as

let's avoid optional behaviour and format versioning.