Re: RFC4034 6.2 item 3

[Mark Andrews <[e-mail]>]

> 
> This discussion seems to be coming to a conclusion, but to make sure
> everyone is in agreement I want to ask people to answer few simple
> questions about the general case. The IPSECKEY RR is defined in RFC4025
> it is published after RFC3597 which sets the rules for handling of
> future RR's.
> 
> In the answers below say what you think is the Right thing to do not
> what your favorite implementation does.
> 
> 1. The gateway field in IPSECKEY is a domain name
>          1.a: Can it be compressed ?
>          1.b: Can its case be changed as the Record passes through the DNS ?
>          1.c: Should the DNSSEC domain name canonical rules be applied
>               to the name before it is signed/verified ?
>          1.d: Please explain your reasoning

	1.a: No.  (as per RFC 4025 and as per RFC3597)
	1.b: No.  (as pre RFC 1034 Section 3.1. and as per RFC3597 Section 3)
	1.c: Yes. however you asked the wrong question.
	     It you mean should we downcase before signing / verifying then
	     the answer is No.
	
> 2. Explain why different rules should apply to NSEC [RFC3845]
>     and/or NSEC3 [RFC-to-be]?

	They shouldn't.
 
> 3. what RFC's needs to be clarified?

	RFC 4034 to remove NSEC and RRSIG from the list of records
	that need to be downcased to bring it back into line with
	RFC3597.

	Note the -04 draft was in line with RFC3597 and I saw no
	discussion about changing it between the -04 announcement
	and the -05 announcement in namedroppers archives.  I also
	saw no discussion about changing the list in the period
	leading up to -04 announcement.
 
>          Olafur (acting as King Solomon)
> 
> 
> At 05:26 10/03/2007, Olaf M. Kolkman wrote:
> 
> 
> >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
> 
> 
> --
> to unsubscribe send a message to [e-mail] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/namedroppers/>
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]                 INTERNET: [e-mail]

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>