Subject: [dnsext] downcasing of names in IPSECKEY and HIP?

From: Peter van Dijk <[email-masked]>
Date: Thu, 23 Feb 2012 11:39:01 +0100

Dear colleagues,

working from dnssec-bis-updates-16 section 5.1, and 6.2 of 4034, I gather that the rule for downcasing names in RDATA is not simply "downcase everything that is a name", but that the RRtypes listed have been selected for a reason. I am also under the impression that new RRtypes are excluded from the downcasing rules.

Now, types like IPSECKEY and HIP have appeared during , and their RFCs do not explicitly state whether the names appearing in their RDATA should be lowercased in their canonical form for DNSSEC. 

My questions:
- is the exclusion of newer types from these rules intentional? (I could think of a few reasons)
- shouldn't we expect RFCs/drafts for new RRtypes to be explicit about downcasing and perhaps other aspects of canonicalisation?

My apologies if answers to these questions are in the archives; I did a cursory search but did not find anything.

Kind regards,
Peter van Dijk

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

---

From: Mark Andrews <[email-masked]>
Date: Thu, 23 Feb 2012 22:18:47 +1100

In message <[email-masked]>, Peter van Dijk
 writes:
> Dear colleagues,
> 
> working from dnssec-bis-updates-16 section 5.1, and 6.2 of 4034, I gather tha
> t the rule for downcasing names in RDATA is not simply "downcase everything t
> hat is a name", but that the RRtypes listed have been selected for a reason. 

To make those types work as the rdata can be compressed and there is no
requirement for the compression to preserve case.

> I am also under the impression that new RRtypes are excluded from the downcas
> ing rules.
> 
> Now, types like IPSECKEY and HIP have appeared during , and their RFCs do not
> explicitly state whether the names appearing in their RDATA should be lowerc
> ased in their canonical form for DNSSEC. 
> 
> My questions:
> - shouldn't we expect RFCs/drafts for new RRtypes to be explicit about downca
> sing and perhaps other aspects of canonicalisation?

No.  We have rules for how to validate data that you don't know the
internal structure of.  All new RR 's need to be compatible with
those rules.  That is the *entire* system needs to preserve case
of domain names in all new records.  If compression is used it MUST
be done in a case preserving manner.  It would also require signaling
that the client understands the internal structure of the record.
This could be done with EDNS.

> ry search but did not find anything.

The answers are in the RFCs.  http://www.ietf.org/rfc/rfc3597.txt
 
The discussion about downcasing was triggered because the new rules were not
followed and as they were DNSSEC records it wasn't noticed.

-- 
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: Edward Lewis <[email-masked]>
Date: Thu, 23 Feb 2012 08:53:42 -0500

At 22:18 +1100 2/23/12, Mark Andrews wrote:
>  Peter van Dijk writes:
...
>>  My apologies if answers to these questions are in the archives; I 
>>did a curso
>>  ry search but did not find anything.
>

Except that the RFCs aren't clear and contradict themselves.  I'm 
responding because I spent a non-trivial amount of time on this very 
topic sometime last year.

The general rule is supposed to be: if the type is compressible any 
domain name in the RDATA has to be downcased when doing DNSSEC 
operations (signing, validating).  That is because the case of the 
domain name might change due to the order of the response packet and 
the extent to which the sender tries to maintain case.

But, mistakes were made.  Compression was defined early.  A problem 
arose when new types, those in 1183 and later, were defined and 
implementers assumed that these new types should be compressed.  The 
reason they shouldn't was related to backwards compatibility, but 
that wasn't seen as a crucial design goal at the time.  Because some 
implementations of types defined in this "era" compressed the names, 
today we say "be prepared to see these compressed but don't compress 
them anymore."  Hence, down casing is needed.

And then there's the most frustrating case of the RRSIG.  Although it 
was defined after the new enlightenment that new types should not be 
compressed, the leading implementation continued to down case the 
type by mistake.  Kind of illustrating that code beats specification, 
other implementations followed the leading implementation and not the 
specification.  To this day, if you don't down case RRSIG there will 
likely be interoperability problems with your implementation.

 From my spreadsheet, the following type codes are to be down cased for DNSSEC:

2-9,12,14,15,17,18,21,24,26,30,33,35,36,38,39,46.
(Some of those are obsolete.)

The types that are to be compressed on sending and might (will) be on 
receiving:

2-9,12,14,15.

These are in the "well-known" range, those defined in STD 13 documents.

Types not to be compressed when sending but might be on receiving:

17,18,21,24,26,30,33,35.

The other types, 36, 38, 39, 46 are KX, A6, DNAME, and RRSIG.  Except 
for RRSIG, these were simply erroneously defined as needing to be 
down cased from the start.

As far as I can tell...
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

2012...time to reuse those 1984 calendars!
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Mark Andrews <[email-masked]>
Date: Fri, 24 Feb 2012 09:18:16 +1100

> them anymore."  Hence, down casing is needed.

To compress of not is more a matter of signaling understanding of
records internals.  No such signaling has been defined so we don't
compress as we don't now if the receiver can expand the compression.

We could add a EDNS option with a bit map similar to NSEC's bitmap
that signaled understanding of the type's internals. This would
allow us to compress any type identified by the bit map.   We would
still need to do lossless compression rather than the lossy compression
currently used so that DNSSEC signatures do not break.

New AXFR implementations are supposed to use lossless compression,
rather than lossy compression, so that the case of compressed rdata
is preserved.  This is done by using compression pointers that point
to label sequences that have the correct case.

Case preservation was one of the design goals of the DNS, it just
not been well implemented.

RFC 1035, 2.3.3. Character Case

For all parts of the DNS that are part of the official protocol, all
comparisons between character strings (e.g., labels, domain names, etc.)
are done in a case-insensitive manner.  At present, this rule is in
force throughout the domain system without exception.  However, future
additions beyond current usage may need to use the full binary octet
capabilities in names, so attempts to store domain names in 7-bit ASCII
or use of special bytes to terminate labels, etc., should be avoided.