Subject: [dnsext] Section 5.1 of draft-dnssec-bis

From: Edward Lewis <[email-masked]>
Date: Tue, 8 Jun 2010 07:48:57 -0400

Why does section 5.1 exist?  It's going to create problems once 
resolvers start validating responses.

Section 5.1 says:

5.  Interoperability Concerns

5.1.  Errors in Canonical Form Type Code List

    When canonicalizing DNS names, DNS names in the RDATA section of NSEC
    and RRSIG resource records are not downcased.

    [RFC4034] Section 6.2 item 3 has a list of resource record types for
    which DNS names in the RDATA are downcased for purposes of DNSSEC
    canonical form (for both ordering and signing).  That list
    erroneously contains NSEC and RRSIG.  According to [RFC3755], DNS
    names in the RDATA of NSEC and RRSIG should not be downcased.

    The same section also erroneously lists HINFO, and twice at that.
    Since HINFO records contain no domain names, they are not subject to
    downcasing.

The document-trouble here is that RFC 4034 (et.al.) obsoletes RFC 
3755.  This draft now says that the obsoleting document (4034) is to 
be updated by the obsoleted document (3755).

The reality-problem here is that RFC 4034's section 6.2 makes sense. 
RFC 3755 did not on this matter.  When it comes to the DNSSEC types, 
DNSSEC can make type-specific rules about the RDATA.

The operations&tools-problem here is that there are tools being 
produced that automatically manage the NSEC (and NSEC3) chains.  Some 
tools are exhibiting unexpected behavior in operations because they 
follow the un-vetted draft and not the existing proposed standard.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis             
NeuStar                    You can leave a voice message at +1-571-434-5468

Discussing IPv4 address policy is like deciding what to eat on the Titanic.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 09 Jun 2010 00:32:28 +1000

> resolvers start validating responses.

Because RFC 4034 go the list wrong.  RFC 3755, which introduced NSEC
had it right.  RFC 4034 broke compatibility.  Section 5.1 restores
compatibility.

RFC 3755

   The new types will have exactly the same syntax and semantics as
   specified for SIG, KEY, and NXT in RFC 2535 and RFC 3658 except for
   the following:

   1) Consistent with [RFC3597], domain names embedded in RRSIG and NSEC
      RRs MUST NOT be compressed,

   2) Embedded domain names in RRSIG and NSEC RRs are not downcased for
      purposes of DNSSEC canonical form and ordering nor for equality
      comparison, and

   3) An RRSIG with a type-covered field of zero has undefined
      semantics.  The meaning of such a resource record may only be
      defined by IETF Standards Action.

> be updated by the obsoleted document (3755).

No.  It says that RFC 4034 has a error in it.  That the earlier list
was correct and that this document is correcting the list to match
that in RFC 3755.

> DNSSEC can make type-specific rules about the RDATA.

Not in the context of why one canonicalize domain names.  The only
reason to do this is because the name could be compressed.  NSEC
and RRSIG records have never been allowed to be compressed.
 
> follow the un-vetted draft and not the existing proposed standard.

No.  There is a problem because we missed the fact that the list
was wrong and in the process broke compatibility with existing code
for no good reason.

The draft is there to catch the errata in the DNSSEC documents and
that includes RFC 4034.  Perhaps it is time to publish the draft.

Mark

> --============_-936124530==_ma============
> Content-Type: text/html; charset="us-ascii"
> 
> <!doctype html public "-//W3C//DTD W3 HTML//EN">
> <html><head><style type="text/css"><!--
> blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
>  --></style><title>Section 5.1 of
> draft-dnssec-bis</title></head><body>
> <div>Why does section 5.1 exist?&nbsp; It's going to create problems
> once resolvers start validating responses.</div>
> <div><br></div>
> <div>Section 5.1 says:</div>
> <div><br></div>
> <div>5.&nbsp; Interoperability Concerns<br>
> <br>
> 5.1.&nbsp; Errors in Canonical Form Type Code List<br>
> <br>
> &nbsp;&nbsp; When canonicalizing DNS names, DNS names in the RDATA
> section of NSEC<br>
> &nbsp;&nbsp; and RRSIG resource records are not downcased.<br>
> <br>
> &nbsp;&nbsp; [RFC4034] Section 6.2 item 3 has a list of resource
> record types for<br>
> &nbsp;&nbsp; which DNS names in the RDATA are downcased for purposes
> of DNSSEC<br>
> &nbsp;&nbsp; canonical form (for both ordering and signing).&nbsp;
> That list<br>
> &nbsp;&nbsp; erroneously contains NSEC and RRSIG.&nbsp; According to
> [RFC3755], DNS<br>
> &nbsp;&nbsp; names in the RDATA of NSEC and RRSIG should not be
> downcased.<br>
> <br>
> &nbsp;&nbsp; The same section also erroneously lists HINFO, and twice
> at that.<br>
> &nbsp;&nbsp; Since HINFO records contain no domain names, they are not
> subject to</div>
> <div>&nbsp;&nbsp; downcasing.</div>
> <div><br></div>
> <div>The document-trouble here is that RFC 4034 (et.al.) obsoletes RFC
> 3755.&nbsp; This draft now says that the obsoleting document (4034) is
> to be updated by the obsoleted document (3755).</div>
> <div><br></div>
> <div>The reality-problem here is that RFC 4034's section 6.2 makes
> sense.&nbsp; RFC 3755 did not on this matter.&nbsp; When it comes to
> the DNSSEC types, DNSSEC can make type-specific rules about the
> RDATA.</div>
> <div><br></div>
> <div>The operations&amp;tools-problem here is that there are tools
> being produced that automatically manage the NSEC (and NSEC3) chains.&nbsp;
> Some tools are exhibiting unexpected behavior in operations because
> they follow the un-vetted draft and not the existing proposed
> standard.</div>
> <div><br></div>
> <x-sigsep><pre>-- 
> </pre></x-sigsep>
> <div
> >-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=<span
> ></span>-=-=-=-</div>
> <div>Edward
> Lewis&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
> ></span>&nbsp;&nbsp;&nbsp;<br>
> NeuStar&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
> ></span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; You can
> leave a voice message at +1-571-434-5468</div>
> <div><br></div>
> <div>Discussing IPv4 address policy is like deciding what to eat on
> the Titanic.</div>
> </body>
> </html>
> --============_-936124530==_ma============--
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Edward Lewis <[email-masked]>
Date: Tue, 8 Jun 2010 10:59:49 -0400

>had it right.  RFC 4034 broke compatibility.  Section 5.1 restores

Compatibility with what?

>and RRSIG records have never been allowed to be compressed.

My concern isn't about compression.  It's about the handling of the 
cases (as in upper/lower case).

I know that there's a complication in putting domain names in the 
RDATA and expecting them to be treated specially because the location 
of the domain name within the RDATA has to be found.  This is why 
compression was "stopped" for all new record types.

But what we are seeing in operations is ambiguity when it comes to 
the case of the domain names in the NSEC and RRSIG records - and 
possibly NSEC3 (but I am not looking at them).

How will validation work if the domain names in NSEC and RRSIG are 
not down cased first?  Will the validator have to try all 
permutations of the name until there's a match?

TLD. = TLd. = Tld. = tld. = tLD. = tLd. = TlD. = tlD. ?

>was wrong and in the process broke compatibility with existing code

There's a problem in operations.  Tools that are not compliant with 
the RFC are causing problems.

>that includes RFC 4034.  Perhaps it is time to publish the draft.

With the discussion of the CD bit still going on, and the fact that 
DNSSEC is only now getting to the point where we can identify the 
"bugs" I hardly think that an update document is near completion.

I want to close with this question - why not require DNSSEC signers 
to down case the domain names in NSEC and RRSIG?

---

From: Edward Lewis <[email-masked]>
Date: Tue, 8 Jun 2010 14:20:04 -0400

At 10:59 -0400 6/8/10, Edward Lewis wrote:

>How will validation work if the domain names in NSEC and RRSIG are not down
>cased first?  Will the validator have to try all permutations of the name
>until there's a match?

I had a conversation with David Blacka and it turns out that there's 
no reason to do the down casing.

The "deal" is that the domain names in NSEC and RRSIG (David reminded 
me that there are no domain names in NSEC3, d'oh) are going to travel 
unmolested (that is not compressed) in plain text through the system. 
If the case is dittled with, then it's not the original record, so 
DNSSEC should fail (even if that seems over the top.)

I would like to suggest the following for 5.1.  Quibbles over word 
choice are accepted, the goal is to establish that the DNS names in 
question aren't
subject to legitimate changes (or allowed to be changed), not even 
via compression.

    Contray to the specification in [RFC4034] ehen canonicalizing DNS names,
    DNS names in the RDATA section of NSEC and RRSIG resource records are not
    to be downcased.  The rational is that the DNS names in those two records
    are not subject to legitimate changes, such as what compression pointers
    might cause, therefore what the validator receives can be expected to be
    what the signer signed.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 09 Jun 2010 08:26:33 +1000

> >had it right.  RFC 4034 broke compatibility.  Section 5.1 restores

Deployed code.  RFC 4034 were rollups of lots of other RFC's.  We stuffed
the rollup.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 09 Jun 2010 08:57:46 +1000

> TLD. = TLd. = Tld. = tld. = tLD. = tLd. = TlD. = tlD. ?

Firstly.  Case is supposed to be preserved in records.  This is a
requirement from RFC 1034.  It's also a requirement from RFC 2535
on all new records types.  If you don't go and change the case, by
doing unnecessary cannonicalization, the records validate.

The reason we downcase NS rdata is that when the record is transmitted
and it happens to use a compression pointer, there in no guarantee
that the domain pointed to has the same case as the original record
had.

Compression pointer are why we cannonicalize owner names.

At some point in the future we may want to use compression pointers
for some of the newer records.  We can still do that but there will
be a additional requirement that case be preserved and it will also
require hop-by-hop option indicating that the client knows how to
decompress the records.

> to down case the domain names in NSEC and RRSIG?

Because it will break the deployed code and it is not needed to be done.

---

From: Edward Lewis <[email-masked]>
Date: Wed, 9 Jun 2010 07:37:42 -0400

>Deployed code.  RFC 4034 were rollups of lots of other RFC's.  We stuffed

The reason I'm not letting this go like a sane person would is that 
it's not simply that we "stuffed the rollup."  And that's why I 
supplied text in a previous message.

In RFC 2065 (the first stab at DNSSEC) is says this towards the end of 4.1:

    The "signer's name" field is the domain name of the signer generating
    the SIG RR.  This is the owner of the public KEY RR that can be used
    to verify the signature.  It is frequently the zone which contained
    the RR(s) being authenticated.  The signer's name may be compressed
    with standard DNS name compression when being transmitted over the
    network.

In RFC 2535 carries this forward:

4.1.7 Signer's Name Field

    ....................... The signer's name may be compressed with
    standard DNS name compression when being transmitted over the
    network.

Because both were specified to be compressible they needed to be down 
cased.  So to undo this mistaken assumption we should document the 
reason for the change explicitly.  (The reason I was so convinced we 
needed to down case was because when I wrote code on this I had to 
down case given the assumptions of the time.  No truth to the rumor 
that my code is so old it is in Fortran IV.)

If a signer down cased as part of writing the entire zone, meaning it 
also down cases the RDATA, this all worked.  When the signer didn't 
down case the RDATA this caused problems.  I got that from David.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis             
NeuStar                    You can leave a voice message at +1-571-434-5468

---

From: Mark Andrews <[email-masked]>
Date: Thu, 24 Jun 2010 10:30:23 +1000

> down case the RDATA this caused problems.  I got that from David.

This comment got me looking in the code and named does downcase the
signer's name when generating the rrsig.  This was a hold over from
how it generates sig records which do need to be downcased (the
same code does both sig and rrsig generation).  rrsig records don't
provided the casing is preserved everywhere.  mea culpa as I failed
to change that part in doing the type code roll in named.

The question is where do we go from here?
* We can cause breakage and make everything consistent with RFC 3755
  or RFC 4034.  Doing either will cause validation failures.
* We can document the current code base.

Mark

---

From: Edward Lewis <[email-masked]>
Date: Thu, 24 Jun 2010 08:14:01 -0400

>* We can document the current code base.

I prefer the latter - from the age-old IETF mantra, restated for 
today's generation "code rulz!"  Avoiding another requirement to have 
everyone validating DNSSEC update their code would be good thing too.

But we do need clean specs so code bases all are on the same page.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

The World Cup would be more fun if they didn't interrupt it with soccer games.

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 24 Jun 2010 10:24:42 -0400

See below..

On Thu, Jun 24, 2010 at 2:56 AM, George Barwood
<[email-masked]> wrote:
>
> ----- Original Message -----
> From: "Mark Andrews" <[email-masked]>
>
> http://tools.ietf.org/html/rfc4034#section-3.1.8
>
> says
>
> <<
> RRSIG_RDATA is the wire format of the RRSIG RDATA fields
> with the Signer's Name field in canonical form and the Signature field excluded;
>>>
>
> Unfortunately, AFAICS, no definition is given for the canonical form of a domain name.

See Section 6.2:

6.2.  Canonical RR Form

   For the purposes of DNS security, the canonical form of an RR is the
   wire format of the RR where:

   1.  every domain name in the RR is fully expanded (no DNS name
       compression) and fully qualified;

   2.  all uppercase US-ASCII letters in the owner name of the RR are
       replaced by the corresponding lowercase US-ASCII letters;

   3.  if the type of the RR is NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR,
       HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX,
       SRV, DNAME, A6, RRSIG, or NSEC, all uppercase US-ASCII letters in
       the DNS names contained within the RDATA are replaced by the
       corresponding lowercase US-ASCII letters;

   4.  if the owner name of the RR is a wildcard name, the owner name is
       in its original unexpanded form, including the "*" label (no
       wildcard substitution); and

   5.  the RR's TTL is set to its original value as it appears in the
       originating authoritative zone or the Original TTL field of the
       covering RRSIG RR.

Thanks,
Donald

> Regardless, when generating authoritative RRSIG/NSEC records (signing), an implementation is free to downcase names without causing validation problems ( a validating resolver cannot go wrong once this is done), and given the conflicting RFCs, I think this is highly advisable.
>
> I suggest documenting that signers MUST downcase the NSEC NextName field
> and the RRSIG Signer's Name field.
>
> George
>

---

From: Edward Lewis <[email-masked]>
Date: Thu, 24 Jun 2010 13:05:32 -0400

At 15:41 +0100 6/24/10, George Barwood wrote:

>Nowhere does it define the canonical form of a domain name,
>so we are apparently left to guess what this might be.

I disagree - it is pretty clear if you read the RFC for what an RFC 
is.  True that there's no mention of "canonical form of a domain 
name" in the section, but it is clear that the intent is to down 
case.  (I'm reflecting what the text says, not trying to re-ignite 
the debate over whether the down casing is correct.)

If one wants to pick nits on the fact that in one place it says 
"canonical domain name" in one location and then "canonical RR" in 
another place, you might as well start at the beginning and nit pick 
all of the documents.  The RFCs have to be read with an understanding 
that they are describing the engineering intent and not the precise 
verbiage of a proscriptive specification.  Even if we try to write 
them as specifications.

For example, I often lean on RFC 1034's section 4.3.2.  In a comment 
early in the wild card "clarify" document discussion, Rob Austein 
made it clear that that section was about intent, not about code and 
not even pseudo-code.  The algorithm described the intended result of 
the search, not how you would code it up.

The specs do say "down case" the name.  But the rationale was in 
error.  The question is how to fix this, as Mark has already asked.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 24 Jun 2010 13:21:48 -0400

+1
Donald

On Thu, Jun 24, 2010 at 1:05 PM, Edward Lewis <[email-masked]> wrote:
> I disagree - it is pretty clear if you read the RFC for what an RFC is.
>  True that there's no mention of "canonical form of a domain name" in the
> section, but it is clear that the intent is to down case.  (I'm reflecting
> what the text says, not trying to re-ignite the debate over whether the down
> casing is correct.)
>
> If one wants to pick nits on the fact that in one place it says "canonical
> domain name" in one location and then "canonical RR" in another place, you
> might as well start at the beginning and nit pick all of the documents.  The
> RFCs have to be read with an understanding that they are describing the
> engineering intent and not the precise verbiage of a proscriptive
> specification.  Even if we try to write them as specifications.
>
> For example, I often lean on RFC 1034's section 4.3.2.  In a comment early
> in the wild card "clarify" document discussion, Rob Austein made it clear
> that that section was about intent, not about code and not even pseudo-code.
>  The algorithm described the intended result of the search, not how you
> would code it up.
>
> The specs do say "down case" the name.  But the rationale was in error.  The
> question is how to fix this, as Mark has already asked.
> --