Subject: preserving case vs canonicalisation, was RFC4034 6.2 item 3

From: Roy Arends <[email-masked]>
Date: Mon, 12 Mar 2007 13:55:04 +0100

In a perfect world, case is always preserved, though canonicalized for the 
sake of matching, signing and validation. 

Both implementation fail this point.

One implementation, NSD, does not preserve case. i.e. it canonicalizes the 
data in the NSEC RDATA, and subsequently emits the canonicalized data.

Another implementation, the popular one, does not canonicalize the NSEC 
RDATA before signing it.

Removing the requirement in 6.2 point 3 is not an option imho. If we'd 
allow that, example.COM will not match EXAMPLE.com. 

Note that the wireformat of the NSEC rdata refers to canonical order, 
which includes downcasing as well. 

So far my pedantic protocol view.

Changing the specs to bless bugs sets a precedent that we should avoid.

Roy

--
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: Mark Andrews <[email-masked]>
Date: Tue, 13 Mar 2007 08:02:26 +1100

> Another implementation, the popular one, does not canonicalize the NSEC 

	There was no requirement to canonicalize the dname in the
	NSEC record.  The *only* requirement is that the dname in
	the NSEC sorts to after the owner name with the exception
	of the last NSEC record which points to the zone owner.

	ISC's implementation meets this requirement.

	EXAMPLE.COM == eXaMpLe.CoM == example.com

	for the purposes of NSEC.

	Nowhere was it specified that the next domain name field must
	be in canonical *form* only that it must be the next in
	canonical *order*.  Order is not equivalent for form.

	RFC 3845 didn't specify it.  RFC 4034, which replaces RFC 3845,
	didn't specify it.

	RFC 3597 specifically disallows downcasing for canonicalisation.

	RFC 4034 has no words to say that the list overrides the
	list in RFC 3597.

	Downcasing is not reqired for DNSSEC to work.

	Please remember downcasing was introduced to work around
	the cases where domain name compression made it impossible to
	guarantee the case of a domainname.  NXT and SIG both allowed
	compression at some point.  NSEC and RRSIG have never allowed
	compression to be used.  It sets a bad precedent to compress
	NSEC and RRSIG.

	Mark

RFC 3845

2.1.1.  The Next Domain Name Field

   The Next Domain Name field contains the owner name of the next RR in
   the canonical ordering of the zone.  The value of the Next Domain
   Name field in the last NSEC record in the zone is the name of the
   zone apex (the owner name of the zone's SOA RR).

   A sender MUST NOT use DNS name compression on the Next Domain Name
   field when transmitting an NSEC RR.

   Owner names of RRsets that are not authoritative for the given zone
   (such as glue records) MUST NOT be listed in the Next Domain Name
   unless at least one authoritative RRset exists at the same owner
   name.

RFC 4034

4.1.1.  The Next Domain Name Field

   The Next Domain field contains the next owner name (in the canonical
   ordering of the zone) that has authoritative data or contains a
   delegation point NS RRset; see Section 6.1 for an explanation of
   canonical ordering.  The value of the Next Domain Name field in the
   last NSEC record in the zone is the name of the zone apex (the owner
   name of the zone's SOA RR).  This indicates that the owner name of
   the NSEC RR is the last name in the canonical ordering of the zone.

   A sender MUST NOT use DNS name compression on the Next Domain Name
   field when transmitting an NSEC RR.

   Owner names of RRsets for which the given zone is not authoritative
   (such as glue records) MUST NOT be listed in the Next Domain Name
   unless at least one authoritative RRset exists at the same owner
   name.
 
6.2.  Canonical RR Form

   ...

   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;
RFC 3597

   As a courtesy to implementors, it is hereby noted that the complete
   set of such previously published RR types that contain embedded
   domain names, and whose DNSSEC canonical form therefore involves
   downcasing according to the DNS rules for character comparisons,
   consists of the RR types NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR,
   HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX, SRV,
   DNAME, and A6.

   This document specifies that for all other RR types (whether treated
   as unknown types or treated as known types according to an RR type
   definition RFC more recent than RFC 3597), the canonical form is such
   that no downcasing of embedded domain names takes place, and
   otherwise identical to the canonical form specified in [RFC2535]
   section 8.1.

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

---

From: Jelte Jansen <[email-masked]>
Date: Tue, 13 Mar 2007 00:17:32 +0100

> 	canonical *order*.  Order is not equivalent for form.

For the purposes of NSEC, example.com == EXAMPLE.COM

For the purposes of RRSIG however, section 3.1 specifies:

               Any DNS names in the RDATA field of each RR MUST be in
               canonical form; and

               The RRset MUST be sorted in canonical order.

   See Sections 6.2 and 6.3 for details on canonical form and ordering
   of RRsets.

The interoperability problem isn't in the NSECs themselves, it's in
their signatures. The canonicalization problem of the NSEC records just
triggered it.

Now whether or not NSEC belongs in the list in 6.2, at this point we
have at least four implementations that seem to disagree on this point.
Some lowercase prior to signing/verifying, some don't. Some
implementations must be changed, and depending on which, the rfc must be
updated. Either way, this probably warrants some (more) text in the
dnssec bis updates draft.

Jelte

---

From: Mark Andrews <[email-masked]>
Date: Tue, 13 Mar 2007 12:09:13 +1100

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Mark Andrews wrote:

	The canonical form when NSEC was created DID NOT include
	down casing.  We looked at this when NSEC was created and
	there was clear guidance in the existing RFCs (see RFC 3597).
 
> their signatures. The canonicalization problem of the NSEC records just

	I understand that.  We should have never allowed the list of
	RR types which get downcased to be changed.  There was NEVER
	a technical reason to down case NSEC or RRSIG as they NEVER
	were subject to domain name compression.
 
> dnssec bis updates draft.

	RFC 4034 retroactively changed the canonicalisation rules
	for NSEC and RRSIG for not good reason.

	Yes, it will require text.
 
> Jelte
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.3 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iD8DBQFF9d+L4nZCKsdOncURAmU7AJ9BLUy2fxdCpmZleTfYVRtNwNxtCACfbqN3
> 1XcmnHGW/jIEXaMY4tuETAE=
> =Odf5
> -----END PGP SIGNATURE-----
> 
> --

---

From: Peter Koch <[email-masked]>
Date: Tue, 13 Mar 2007 21:05:49 +0100

> Both implementation fail this point.

FWIW, I agree.  Case should have been preserved as per 2.3.3 of RFC 1035
and the NSEC RDATA should have been canonicalized for signing because
of RFC 4034 (and because the signer _can_). A validator agnostic of NSEC
and thus not being able to downcase before validating the NSEC RR's signature
would be in trouble - but it would be in trouble anyway.

I also agree that there was no immediate reason to list NSEC in that list
in RFC 4034.

-Peter (who still wonders whether it would be possible to sneak a
        "wrongly cased" NSEC RR into a validator for a DoS attack)

PS: The list in section 6.2 of RFC 4034 has another (cosmetic) issue:
    RFC 1123 (6.1.3.6) strictly obsoletes the MD and MF RR types, so there's
    no point in giving advice on how to implement or deal with them.