Subject: [dnsext] RRSIG signer name down-casing

From: "George Barwood" <[email-masked]>
Date: Tue, 21 Jun 2011 08:57:29 +0100

The DNSKEY RRset for the .us. TLD currently has an upper-case signer name for one of the signatures.

dig dnskey us @a.cctld.us +dnssec

..

us.  518400  IN      RRSIG   DNSKEY 5 1 518400 20110710100000
 20110610090000 2058 US. Zr6NjHuwkNyFIDgixFmpLjEtDrbPSci0YLuRqMglU9ExpuHu42B7c/5
f h7eEe909Cm9kJblmCN3GVlF3AeNpWLd1320oukfJkLw8Zi+sh63TN47v uHBZyjvHf5KyAguvL/W7+
qoQIEcfVUzhAHh4yJPmyjgmaf1yfP+fKYTx 8PDzGWrubjkIItsBVJBvX0ul2Sgd+7nFwM/o5YWf089R
Thc+eU9Deo/Z 7WmYgN7UW6dTPzz+Li/bsljSkCQk6JZAkkBlMQljtvvLfqDQv37xNulS hBglDeUiat
Klp9mq1hsxNCvlOcAg8E6WRrySnTSfAWzdzk9o43unjHf4 sFotGg==

It seems that the signer name has to be down-cased for this signature to verify.

However this is contrary to http://tools.ietf.org/html/draft-ietf-dnsext-dnssec-bis-updates-12#section-5.1

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

But existing validators don't fail, so it seems they do down-case.

Hence I'm confused. Is dnssec-bis-updates "wrong"? 

George

---

From: Edward Lewis <[email-masked]>
Date: Tue, 21 Jun 2011 09:38:10 -0400

At 8:57 +0100 6/21/11, George Barwood wrote:

>However this is contrary to 
>http://tools.ietf.org/html/draft-ietf-dnsext-dnssec-bis-updates-12#section-5.1
>

This discussion came up recently on some list.  The answer is that 
the case doesn't matter, uh, in this case.  The only time a domain 
name in the RDATA has to be down cased is when it can be compressed.

The reason is - without compression, the RR will appear in a response 
the same as it was generated (outside of forgeries, which is what 
DNSSEC is about).  With compression, the case used for the domain 
name in the RDATA depends on what comes first in the response.

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

I'm overly entertained.

---

From: Sean Wells <[email-masked]>
Date: Tue, 28 Jun 2011 12:23:15 -0700

On Tue, Jun 21, 2011 at 6:38 AM, Edward Lewis <[email-masked]> wrote:

>> However this is contrary to http://tools.ietf.org/html/**
>> draft-ietf-dnsext-dnssec-bis-**updates-12#section-5.1<http://tools.ietf.org/html/draft-ietf-dnsext-dnssec-bis-updates-12#section-5.1>
>>
> This discussion came up recently on some list.  The answer is that the case
> doesn't matter, uh, in this case.  The only time a domain name in the RDATA
> has to be down cased is when it can be compressed.
>
> The reason is - without compression, the RR will appear in a response the
> same as it was generated (outside of forgeries, which is what DNSSEC is
> about).  With compression, the case used for the domain name in the RDATA
> depends on what comes first in the response.
>
> I am a little confused about this. As per RFC 4034, the signer name cannot
be compressed and for signature calculation it should be lower case. So, it
is possible that the received RRSIG has "ORG" in the signer name whereas the
signature was computed with "org" ?

> --
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=**-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=**
> -=-=-=-=-=-=-=-
> Edward Lewis
> ______________________________**_________________
> dnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/dnsext<https://www.ietf.org/mailman/listinfo/dnsext>
>

-- 
Sean

---

From: Edward Lewis <[email-masked]>
Date: Tue, 28 Jun 2011 16:18:12 -0400

At 12:23 -0700 6/28/11, Sean Wells wrote:

>be compressed and for signature calculation it should be lower case. So,
>it is possible that the received RRSIG has "ORG" in the signer name whereas
>the signature was computed with "org" ?

Where in RFC 4034 does it say "it should be in lower case."?

Sect 6.2, item 3 does not include RRSIG, item 2 applies to the owner 
field only.
Sect 3.1.7 does not mention a lower case requirement.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

I'm overly entertained.

---

From: Brian Dickson <[email-masked]>
Date: Tue, 28 Jun 2011 16:47:50 -0400

> Where in RFC 4034 does it say "it should be in lower case."?

3.1.8.1 says "RRSIG_RDATA is the wire format of the RRSIG RDATA fields
               with the Signer's Name field in canonical form"...

That, combined with 6.2 subitem 2, gives the requirement for lowercase.

> Sect 6.2, item 3 does not include RRSIG, item 2 applies to the owner field
> only.

I agree that it should have been explicitly put into 3.1.7, to be more clear.

Brian

---

From: Sean Wells <[email-masked]>
Date: Tue, 28 Jun 2011 13:54:51 -0700

On Tue, Jun 28, 2011 at 1:18 PM, Edward Lewis <[email-masked]> wrote:

> Section 6.2 item 3:

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;

Any implementation based on this would have replaced the signer name
with lower case. With the example George gave, it does not validate
without replacing "US" with "us" when calculating the signature.

-- 
Sean

---

From: Jaap Akkerhuis <[email-masked]>
Date: Tue, 28 Jun 2011 23:32:28 +0200

It doesn't say you have to do this replacement but qor order the
RR's as if this replacement took place.

	jaap

---

From: Edward Lewis <[email-masked]>
Date: Tue, 28 Jun 2011 18:29:31 -0400

>        corresponding lowercase US-ASCII letters;

OK - I missed the RRSIG in the middle of that.  (I keep getting 
confused between DNSKEY and RRSIG in this thread.)

US has been signed this way since 2009.  Haven't heard a validation 
problem related to it.  There are a few factors here.

1 - (Protocol designer speaking) It really doesn't matter what the 
case is because there's no compression, i.e., the requirement is 
wrong.  However it is a requirement, I'll grant that.  But there's 
some history, that list has been problematic as well as a 
misunderstanding of the list of compressible RR types over time. 
There happens to be an errata lodged against that very list.

2 - (Hack implementer/operator speaking) It's not apparent to me that 
validators aren't replacing the domain name with the down cased 
version.  What you are seeing is the presentation/print format which 
is trying to preserve case.  I haven't read the unbound and named 
code to see what they do.

I know that it is a performance killer to copy data.  But validators 
pretty much have to - to undo compression, to sort into canonical 
order and to assemble the plaintext buffer.  One implementation 
technique is to preserve the original format, create a workspace, 
make it canonical, evaluate, and delete once the validation process 
finishes.  The end user may never see the canonical form.

If there were a bug here, I know we'd have seen it already...
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis             
NeuStar                    You can leave a voice message at +1-571-434-5468

I'm overly entertained.

---

From: Sean Wells <[email-masked]>
Date: Tue, 28 Jun 2011 16:06:09 -0700

On Tue, Jun 28, 2011 at 3:29 PM, Edward Lewis <[email-masked]> wrote:

> **
> OK - I missed the RRSIG in the middle of that.  (I keep getting confused
> between DNSKEY and RRSIG in this thread.)
>
> US has been signed this way since 2009.  Haven't heard a validation problem
> related to it.  There are a few factors here.
>
> Because the implementation is converting to lower case. I tried this in a
validator by not converting to lower case and it fails.

> 1 - (Protocol designer speaking) It really doesn't matter what the case is
> because there's no compression, i.e., the requirement is wrong.  However it
> is a requirement, I'll grant that.  But there's some history, that list has
> been problematic as well as a misunderstanding of the list of compressible
> RR types over time.  There happens to be an errata lodged against that very
> list.
>

Ok, I see your point now.

> validators aren't replacing the domain name with the down cased version.
> What you are seeing is the presentation/print format which is trying to
> preserve case.  I haven't read the unbound and named code to see what they
> do.
>
See above.

>
> I know that it is a performance killer to copy data.  But validators pretty
> much have to - to undo compression, to sort into canonical order and to
> assemble the plaintext buffer.  One implementation technique is to preserve
> the original format, create a workspace, make it canonical, evaluate, and
> delete once the validation process finishes.  The end user may never see the
> canonical form.
>

There is no bug. Implementations must be converting to lower case. It is the
dnssec-bis-updates that is incorrect.

> **
> **
> _______________________________________________
> dnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsext
>
>

-- 
Sean

---

From: Mark Andrews <[email-masked]>
Date: Wed, 29 Jun 2011 13:31:15 +1000

In message <[email-masked]>, Jaap Akkerhuis wr
> RR's as if this replacement took place.

When we implemented NSEC (RFC 3845) in named, well before RFC 4034
was written, we digested it as per RFC 2535/RFC 3597 (no downcasing).
NSEC was *not* a type code roll of NXT.  It was a new record that
supports the listing of all possible types.

RRSIG however was a type code roll of SIG (RFC 3755) and I missed
making its signature generation compliant with RFC 3755 by not
removing the downcasing of the signer's name.  Others also missed
doing this.  The digest was built on the fly rather that by taking
a complete RR and digesting that.

RFC 3755

   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.

RFC 4034 then took the list from RFC 3597, including errors, and
extended it to add RRSIG and NSEC.  This was not noticed until there
was a post RFC 4034 implementation of DNSSECbis which immediately
brought to light the issue with NSEC.

It was then decided to correct RFC 4034 to bring it into line with
RFC 3597 and correct the other defects in the list.  No one however
noticed that everyone had actually digested RRSIG's as described
in RFC 4034 rather than RFC 3755.  RFC 4034 was supposed to capture
RFC 3755, not change it.

The simplest way forward is to stay just downcase the signer when
computing the digest of RRSIG.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]