RFC4034 6.2 item 3

["Olaf M. Kolkman" <[e-mail]>]

Dear Colleagues,

We recently discovered an interoperability problem that can be argued  
to be a protocol bug or an editing error.

A popular zone signer and its corresponding validator implementation  
does not lowercase the next domain name in the RDATA, while   
according to RFC4034 section 6.2 item 3 that should be done. The bug  
was discovered when NSD was deployed as a one of the servers in an  
authoritative server cloud. During the zone transfer NSD 'lowercases  
the NSEC RDATA' and starts to hand out different NSEC RDATA then was  
used for input.

One could argue that NSEC is listed in item 3 of section 6.2 in 4034  
in error: The original NSEC specification (RFC3845) does not contain  
rules to make NSEC canonical and therefore the default was to use the  
RFC3597 (Unknown RRs) behavior. RFC3597 does not list.

On the other hand one could argue that when the NSEC is a 'carbon  
copy' of the NXT RR and therefore RFC3597 behavior should have  
applied and not mentioning the requirement to lowercase the dname  
before signature creation in RFC3845 was an error. Besides, the  
RFC35977 case preservation is (most) relevant for implementations of  
DNSSEC validation code but those are also the ones that must have  
detailed knowledge of the NSEC RR so IMHO the deviation of 4034 of  
3597 should in theory not have caused problems.

One of the argument to lower-case the data before signing is that the  
_information_ you want to transport with the NSEC RR is the  
_canonical_ ordering in which casing is irrelevant.

There is one practical example, a bit far fetched, where not  
lowercasing the dname before signing can hurt you:
Assume two sites that AXFR data between them (AXFR does not guarantee  
casing of onwer names to be preserved). Both dynamically generate  
NSECs and sign then dynamically. Now we have the case that for one  
zone the RRSIGs for the NSECs data generated by one server (which is  
exactly the same as for the other, except for the casing) cannot be  
used to validate the NSEC RRset of the other.  A bit construed, but  
still.

I also understand there is an installed-base argument that weighs  
heavily for saying that 4034 is in error:  At this moment there are  
implementations that take a different interpretation. I think it is  
fair to say that the signer and validator with the largest deployment  
base treat the data as case sensitive.

Because of the argument that it is the information in the NSEC that  
matters, the protocol geek in me has a slight preference for the  
interpretation as in 4034, it is cleaner protocol wise. Practically I  
want to have this fixed ASAP and the least disruptive way is to scrap  
NSEC from the above mentioned item 3 in 6.2 of 4034 and to have NLnet  
Labs patch NSD. It is important that the working group chooses a  
position fast.

I leave it to Olafur to judge consensus.

The result should go into draft-ietf-dnsext-dnssec-updates.

--Olaf


-----------------------------------------------------------
Olaf M. Kolkman
NLnet Labs
http://www.nlnetlabs.nl/