Subject: Re: [dnsext] Related to section 5.1 of dnssec-bis-updates (-14)

From: Samuel Weiler <[email-masked]>
Date: Thu, 12 Jan 2012 23:20:14 -0500 (EST)

I don't recall seeing much discussion of the below.  As doc editor, I 
would like to hear an extra voice or three chime in before I fix 
this.

As I understand Ed's message, the (signer) name in an RRSIG does need 
to be downcased.  The next name in a NSEC RR does NOT need to be 
downcased.  Is that right?

On Thu, 13 Oct 2011, Edward Lewis wrote:

> In this section of the still-a-draft update to the DNSSEC definition of RFC 4033-4035 an issue has arisen that needs to be addressed.
> 
> # http://tools.ietf.org/html/draft-ietf-dnsext-dnssec-bis-updates-14
> #
> #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.
> 
> For the purposes of this email a "major implementation" refers to a widely distributed general purpose implementation of DNS.  It's become apparent
> that two major implementations of validators have differed on downcaseing the RRSIG.
> 
> We've been trying to determine why this problem hasn't surfaced in a real-world outage.  It seems that all major implementations of signers down case
> the RRSIG before signing.
> 
> Treat this as a suggestion.  Unexcuse RRSIG from the list of names that avoid downcasing.  (NSEC is not a problem.)  Any thoughts?
> 
> -- 
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Edward Lewis             
> NeuStar                    You can leave a voice message at +1-571-434-5468
> 
> Vote for the word of the day:
> "Papa"razzi - father that constantly takes photos of the baby
> Corpureaucracy - The institution of corporate "red tape"
> 
>

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

---

From: Olafur Gudmundsson <[email-masked]>
Date: Fri, 13 Jan 2012 10:44:46 -0500

WG,

Please help our editor to close this issue by either sending +1 to
the resolution below or explain why not.

Chairs would like to see this issue closed in the next few days.

	Olafur

On 12/01/2012 23:20, Samuel Weiler wrote:
> would like to hear an extra voice or three chime in before I fix this.
>
> As I understand Ed's message, the (signer) name in an RRSIG does need to
> be downcased. The next name in a NSEC RR does NOT need to be downcased.
> Is that right?
>
>> In this section of the still-a-draft update to the DNSSEC definition
>> of RFC 4033-4035 an issue has arisen that needs to be addressed.
>>
>> For the purposes of this email a "major implementation" refers to a
>> widely distributed general purpose implementation of DNS.  It's become
>> apparent
>> We've been trying to determine why this problem hasn't surfaced in a
>> real-world outage.  It seems that all major implementations of signers
>> down case
>> Treat this as a suggestion.  Unexcuse RRSIG from the list of names
>> that avoid downcasing.  (NSEC is not a problem.)  Any thoughts?
>>
>> --

---

From: Mohan Parthasarathy <[email-masked]>
Date: Fri, 13 Jan 2012 10:33:13 -0800

On Thu, Jan 12, 2012 at 8:20 PM, Samuel Weiler <[email-masked]> wrote:
> I don't recall seeing much discussion of the below.  As doc editor, I would
> like to hear an extra voice or three chime in before I fix this.
>
> As I understand Ed's message, the (signer) name in an RRSIG does need to be
> downcased.  The next name in a NSEC RR does NOT need to be downcased.  Is
> that right?
+1. Sometime back there was an email thread (which I can't locate now)
where the signature verification failed if you don't downcase for
something in .US zone.

-mohan

>> In this section of the still-a-draft update to the DNSSEC definition of
>> RFC 4033-4035 an issue has arisen that needs to be addressed.
>>
>> For the purposes of this email a "major implementation" refers to a widely
>> distributed general purpose implementation of DNS.  It's become apparent
>> real-world outage.  It seems that all major implementations of signers down
>> case
>> Treat this as a suggestion.  Unexcuse RRSIG from the list of names that
>> avoid downcasing.  (NSEC is not a problem.)  Any thoughts?
>>
>> --
>>

---

From: Mark Andrews <[email-masked]>
Date: Sat, 14 Jan 2012 09:50:13 +1100

In message <[email-masked]>
, Mohan Parthasarathy writes:
> > I don't recall seeing much discussion of the below. =A0As doc editor, I w=
> ould
> > As I understand Ed's message, the (signer) name in an RRSIG does need to =
> be
> > downcased. =A0The next name in a NSEC RR does NOT need to be downcased. =
> =A0Is
> > that right?

named downcases the RRSIG's Signer's Name
named does not downcase NSEC's Next Domain Name.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Mon, 16 Jan 2012 10:46:48 +0100

Hi Mark,

On 01/13/2012 11:50 PM, Mark Andrews wrote:
>> +1. Sometime back there was an email thread (which I can't locate
>> now) where the signature verification failed if you don't
>> downcase for something in .US zone.
> 
> named downcases the RRSIG's Signer's Name named does not downcase
> NSEC's Next Domain Name.

unbound does not downcase RRSIG signername and does not downcase NSEC
nextdomain name for DNSSEC validation.

ldns rr canonicalisation does not downcase RRSIG signername and NSEC
nextdomain.  So, this is for ldns-signzone and verify.

opendnssec produces lowercase signernames in its RRSIGs, and thus it
does not matter if they are downcased or not (for the RRSIGs produced
by the opendnssec signer).

It started with HINFO, where, today, the rdata is not downcased by
unbound, ldns.

Best regards,
   Wouter

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Mon, 16 Jan 2012 15:35:11 +0100

Hi Sam,

Just to clarify my previous mail: what we implement is RFC3755.  This
states no downcasing in the rdata of NSEC and RRSIG.

To see how we came to this implementation I searched through mail from
2007.  I found that the reason for this is that we first implemented
RFC4034, but that typecodelist in 4034 contained errors (double HINFO,
includes NSEC and RRSIG in a copy-paste-rename-mistake from RFC2535 or
something like that).  This brought to light differences in
implementations from before RFC4034 and after RFC4034.  Because of
this we changed to implement RFC3755 and in dnssec-bis-updates-06 it
is then listed this as something to fix in RFC4034, and it states the
RFC3755 rules.  This is there until -16 (last week) where it changes.

Downcasing is not necessary in NSEC and RRSIG, downcase before
signature verify and create is only needed in case
dname-compression-and-decompression has removed upper-lowercase
differences.  The domain names in the rdata of NSEC and RRSIG are not
compressed, and thus case is preserved.  So, a downcase operation is
not needed (in principle).

So, currently we stay with RFC3755, because we want to implement
standards RFCs, and not drafts if possible.  RFC3755 is obsoleted by
RFC4034, but as already discussed on namedroppers, its typecodelist
was erroneous. And therefore we ignored that list in RFC4034.  Thus
our implementation matches the dnssec-bis-updates draft versions -06
to -15 in this respect.  Regardless of the outcome of this
interoperability problem, we will implement RFCs and thus the RFC that
comes out of dnssec-bis-updates, whether that downcases both(4034),
neither(3755) or something else(draft-16).

Best regards,
   Wouter

On 01/16/2012 10:46 AM, W.C.A. Wijngaards wrote:
>>> +1. Sometime back there was an email thread (which I can't
>>> locate now) where the signature verification failed if you
>>> don't downcase for something in .US zone.
> 
>> named downcases the RRSIG's Signer's Name named does not
>> downcase NSEC's Next Domain Name.
> 
> unbound does not downcase RRSIG signername and does not downcase
> NSEC nextdomain name for DNSSEC validation.
> 
> ldns rr canonicalisation does not downcase RRSIG signername and
> NSEC nextdomain.  So, this is for ldns-signzone and verify.
> 
> opendnssec produces lowercase signernames in its RRSIGs, and thus
> it does not matter if they are downcased or not (for the RRSIGs
> produced by the opendnssec signer).
> 
> Best regards, Wouter 
> _______________________________________________ dnsext mailing
> list [email-masked] https://www.ietf.org/mailman/listinfo/dnsext

---

From: Samuel Weiler <[email-masked]>
Date: Mon, 16 Jan 2012 10:04:51 -0500 (EST)

Thank you for the history.  Going forward, what's the best thing to do 
in the interest of interoperability?

It may be worth asking not only what signers do but also what existing 
validators do.  If we've only seen problems with this in the wild once 
(perhaps?) then there may be an ugly but interoperable answer we can 
document for the future.

-- Sam

On Mon, 16 Jan 2012, W.C.A. Wijngaards wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi Sam,
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iQIcBAEBAgAGBQJPFDWfAAoJEJ9vHC1+BF+NZL4P/Rrs1hl9q02hlU8c83M1BgxT
> v3KPpVQ2369LpY5Vr/0SOUu5W8l8J76pcpkkameKg4PKfW2nzrdUVKD7i/KBmC3h
> 9C9pDzLyamXofG7oxCFAFXOYYJkJ4tXjr31SHfhxsb0YxfvuZE80ZZiOk5+3IhJF
> kWQnUOoIMQMXttCLW6ecHk/i7JhE6gn/7+P8uw3ElunKXqZSleZ42cKIx5WHK+Wg
> 0VNOd3SctuHw41HrtN9O0na7HN/FQr38Gq3tE5+UtFxv1h7hLs+nH2X1Zk2gM9bx
> 5LXpOdMyvuDlHr7jvyPf4v6JSP2XhbRENe3DNonixK41TQ4laDlHbmbWsFQyjZYD
> +CN8vO+w4Mh0TeB6QLEfQAO922l4mR7ts8FwgDYCl0nejoNUU99bb1VVY/6Laa22
> jd8CwcCYqI/pvxcuuTf/kaqOryizyJ5oBFgDSlaKr42AHqmG6vVtXZoamr1Zi248
> UjHDe2bYnY+uf3OpfVvI3Smbs6vFoBY0Xkj4RMAlupPpNvEXeJwtx+k1TQ/E9f7n
> Yh/QMz32Q86TTXR33/9HDIJvF6e7b2WLMGkOUZVTMMzqI3EZiPg2mDbzAhcs1j1G
> tgIweyfpSwYWhykPIIYL0FHCxHsqF2dm59wFn2Bo0B9fdTdoVB0D2iW+9ctnrZbl
> g/mH7UFd4xsNImX2ZNEG
> =n3EK
> -----END PGP SIGNATURE-----

---

From: Mark Andrews <[email-masked]>
Date: Tue, 17 Jan 2012 09:56:48 +1100

In message <[email-masked]>, Samuel Weil
> (perhaps?) then there may be an ugly but interoperable answer we can 

If we emit downcased "Signer Name"s then it does not matter what the
validator does.

To the best of my knowledge no one uses domain name compression on
these names so as long as the signer only uses and emits a downcased
version of the name it will interoperate regardless of what the
validator does.  i.e. Build the RRSIG with a downcased signer name
rather than downcasing signer name when adding it to the digest.

If you are signing with "MiXeD.ExAmPlE" then the signer name in the
RRSIG is "mixed.example".

Unfortunately I missed removing the downcase step for RRSIGs when
I did the type code roll fixes years ago.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 17 Jan 2012 15:06:18 +1100

In message <[email-masked]>, "W.C.A. Wijngaards" writes:
> >>> I don't recall seeing much discussion of the below. =A0As doc
> >>> editor, I would
> >>> As I understand Ed's message, the (signer) name in an RRSIG
> >>> does need to be downcased. 
> >>> The next name in a NSEC RR does NOT need to be downcased. Is
> >>> that right?

Then how does it validate .US, .CO and .BIZ as the signer in the RRSIG
is in upper case?  If I disable down casing I get validation failures.

17-Jan-2012 14:48:21.099 validating @0x101101c00: US DNSKEY: no valid signature found
17-Jan-2012 14:48:22.062 error (insecurity proof failed) resolving 'US/DNSKEY/IN': 156.154.127.70#53
17-Jan-2012 14:48:22.430 validating @0x101101c00: US DNSKEY: no valid signature found
17-Jan-2012 14:48:22.430 error (no valid RRSIG) resolving 'US/DNSKEY/IN': 156.154.126.70#53
17-Jan-2012 14:48:22.735 validating @0x101101c00: US DNSKEY: no valid signature found
17-Jan-2012 14:48:22.735 error (no valid RRSIG) resolving 'US/DNSKEY/IN': 209.173.58.70#53
17-Jan-2012 14:48:23.963 validating @0x101112e00: US DNSKEY: no valid signature found
17-Jan-2012 14:48:23.963 error (no valid RRSIG) resolving 'US/DNSKEY/IN': 156.154.125.70#53
17-Jan-2012 14:48:24.273 validating @0x101112e00: US DNSKEY: no valid signature found
17-Jan-2012 14:48:24.273 error (no valid RRSIG) resolving 'US/DNSKEY/IN': 156.154.124.70#53
17-Jan-2012 14:48:25.502 validating @0x101100c00: US DNSKEY: no valid signature found
17-Jan-2012 14:48:25.502 error (no valid RRSIG) resolving 'US/DNSKEY/IN': 156.154.128.70#53

> It started with HINFO, where, today, the rdata is not downcased by

It would be easy enough to have the validation routines try "as is"
then "lowercase" for backwards compatibility with the expectation
that we can look to removing backwards compatibility hacks Jan 1,
2020.  Similarly we would lowercase the signer when generating the
RRSIG and stop doing that around 2020.  That's 8 years to remove
the old validators.

Mark

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Tue, 17 Jan 2012 10:03:51 +0100

Hi Mark,

On 01/17/2012 05:06 AM, Mark Andrews wrote:
> Then how does it validate .US, .CO and .BIZ as the signer in the
> RRSIG is in upper case?  If I disable down casing I get validation
> failures.

I was wrong!  Looked into the wrong code (there is a (mostly harmless)
bug).  Unbound downcases the RRSIG rdata.  Unbound does not downcase
the NSEC rdata.

So, the deployed Unbound implements -16, and is compatible with BIND.
 Given this is the deployed code, the other arguments are perhaps moot.

Hence that US, CO and BIZ verify.  Thanks for that test.

> It would be easy enough to have the validation routines try "as
> is" then "lowercase" for backwards compatibility with the
> expectation that we can look to removing backwards compatibility
> hacks Jan 1, 2020.

My apologies for wrong information - unbound contains a bug on this
topic - but unbound indeed downcases the RRSIG signer name.  Hence
very strong workarounds are not necessary.

> Similarly we would lowercase the signer when generating the RRSIG
> and stop doing that around 2020.  That's 8 years to remove the old
> validators.

lowercase the signer when generating the RRSIG is a bit on the strict
generation of data perhaps.  Otherwise US. seems to work in practice.

So, in this situation I would recommend keeping -16 as is, and not
changing the situation because of deployed code and signed zones (US,
CO, BIZ).

Best regards,
   Wouter

---

From: Edward Lewis <[email-masked]>
Date: Tue, 17 Jan 2012 10:02:29 -0500

At 10:04 -0500 1/16/12, Samuel Weiler wrote:
>Thank you for the history.  Going forward, what's the best thing to 
>do in the interest of interoperability?
>
>It may be worth asking not only what signers do but also what 
>existing validators do.  If we've only seen problems with this in 
>the wild once (perhaps?) then there may be an ugly but interoperable 
>answer we can document for the future.
>

(Adding to some off-list messages, a shortened version of what I've written:)

Downcase RRSIG, not NSEC.  That includes publishing the RRSIG with 
the downcased name in the RDATA.

 From what I've seen, all known signers do that, regardless of what 
any spec says, hence no validators are tripped up by it.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 18 Jan 2012 10:06:22 +1100

> any spec says, hence no validators are tripped up by it.

Named preserves the signer's case when publishing.  US, CO and BIZ publish
RRSIGs with the signer field in upper case.

Mark

% dnssec-keygen EX
Generating key pair...++++++ .............................++++++ 
Kex.+005+57567
% dnssec-keygen -f KSK EX
Generating key pair...........+++ .....................................................................................+++ 
Kex.+005+38353
% dnssec-signzone -S -o EX ex
Fetching KSK 38353/RSASHA1 from key repository.
Fetching ZSK 57567/RSASHA1 from key repository.
Verifying the zone using the following algorithms: RSASHA1.
Zone signing complete:
Algorithm: RSASHA1: KSKs: 1 active, 0 stand-by, 0 revoked
                    ZSKs: 1 active, 0 stand-by, 0 revoked
ex.signed
% grep 2012 ex.signed 
; File written on Wed Jan 18 09:59:29 2012
			0	RRSIG	SOA 5 1 0 20120216215928 (
					20120117215928 57567 EX.
			0	RRSIG	NS 5 1 0 20120216215928 (
					20120117215928 57567 EX.
			0	RRSIG	NSEC 5 1 0 20120216215928 (
					20120117215928 57567 EX.
			0	RRSIG	DNSKEY 5 1 0 20120216215928 (
					20120117215928 38353 EX.
			0	RRSIG	DNSKEY 5 1 0 20120216215928 (
					20120117215928 57567 EX.
%