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

[Mark Andrews <[e-mail]>]

In message <a06240800cb6beed8cba6@[10.31.203.212]>, Edward Lewis writes:
> At 22:18 +1100 2/23/12, Mark Andrews wrote:
> >  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 reas
> on.
> ...
> >>  My apologies if answers to these questions are in the archives; I 
> >>did a curso
> >>  ry search but did not find anything.
> >
> >The answers are in the RFCs.  http://www.ietf.org/rfc/rfc3597.txt
> 
> 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.

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.

> 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 DNSSE
> C:
> 
> 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 [phone]
> 
> 2012...time to reuse those 1984 calendars!
> _______________________________________________
> dnsext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsext
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]                 INTERNET: [e-mail]
_______________________________________________
dnsext mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dnsext