Subject: RFC4034 6.2 item 3

From: "Olaf M. Kolkman" <[email-masked]>
Date: Sat, 10 Mar 2007 10:26:48 +0100

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/

---

From: Paul Vixie <[email-masked]>
Date: Sat, 10 Mar 2007 14:54:17 +0000

> ...
> There is one practical example, a bit far fetched, where not  lowercasing
> the dname before signing can hurt you:
> casing of onwer names to be preserved).

i was going to argue this point, because case is supposed to be preserved on
the wire.  however, if you received the NS-EXT.VIX.COM name as glue from a
server who sends it in "UPPER CASE", and you then later become a secondary for
EXAMPLE.COM which keeps all of its names in "lower case", you will end up with
a copy of the zone that has names in it like "www.example.COM" even though
they weren't transferred to you that way.  what an unhappy mess case-folding
continues to be.  and if i recall correctly, idn nameprep doesn't have any
aliasing or antialiasing of same-meaning or same-appearance glyphs, so in 
addition to being evil in its own right, case folding will also be seen as
"missing" from the point of view of non-US-ASCII users.

as for the topic at hand:

> 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 may be seen as having a bias toward the preponderant implementation in the
field.  i think none of this matters.  NSEC3 will be an implicit "flag day" in
that COM won't be signed with NSEC and so virtually all validators will 
support NSEC3 in order to validate the domains that are most widely used in
e-commerce.  so the true 800-pound gorilla in the DNS Security market isn't
online yet, and will bring its own installed base, and NSEC is a toy that'll
be swept away into the dustbin of RFCs nobody implements any more.  so the
right thing to do is patch NSD so that we can keep the insignificant current
installed base happy and avoid unnecessary flag days while we wait for the
real flag day to come later with NSEC3.  (NSEC3 would be better than NSEC for
no other reason than that its design precludes any notice of case folding.)

--
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: Sam Weiler <[email-masked]>
Date: Sat, 10 Mar 2007 09:59:07 -0500 (EST)

On Sat, 10 Mar 2007, Olaf M. Kolkman wrote:

> rules to make NSEC canonical and therefore the default was to use 
> the RFC3597 (Unknown RRs) behavior. RFC3597 does not list.

There's even more history to consider:

RFC3755, Section 3:

    2) Embedded domain names in RRSIG and NSEC RRs are not downcased for
       purposes of DNSSEC canonical form and ordering nor for equality
       comparison,...

Which raises the question of whether NSD has exactly the same problem 
with RRSIG RR's, too.  (The list in 4034 includes both RRSIG and 
NSEC.)

> 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.

While 4034's interpretation is obviously cleaner, and it could be 
argued that we didn't NEED to specify 3597 handling for NSEC and 
RRSIG, the historical record satisfies the protocol geek in me, and I 
find the installed base argument pretty compelling.  An argument of 
"it really, really works better to do case-folding" could sway me, 
but, for the moment, ...

I think we should treat this as an editting error in 4034.

-- Sam

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Sat, 10 Mar 2007 16:52:42 +0100

On 10Mar 2007, at 3:59 PM, Sam Weiler wrote:

> Which raises the question of whether NSD has exactly the same  
> problem with RRSIG RR's, too.  (The list in 4034 includes both  
> RRSIG and NSEC.)

Yes, but, I cannot think of any interop problem that that may cause.  
RRSIGs are not signed themselves. Maybe I am missing something.

--Olaf

---

From: David Blacka <[email-masked]>
Date: Sat, 10 Mar 2007 11:23:15 -0500

On Mar 10, 2007, at 10:52 AM, Olaf M. Kolkman wrote:

> Yes, but, I cannot think of any interop problem that that may  
> cause. RRSIGs are not signed themselves. Maybe I am missing something.

The RRSIG RDATA is included in the signature.  However, the behavior  
here is clear:

          signature = sign(RRSIG_RDATA | RR(1) | RR(2)... ) where

             "|" denotes concatenation;

             RRSIG_RDATA is the wire format of the RRSIG RDATA fields
                with the Signer's Name field in canonical form and
                the Signature field excluded;

(From RFC 4034 3.1.8.1)

--
David Blacka    <[email-masked]>
Sr. Engineer    VeriSign Applied Research

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Sat, 10 Mar 2007 17:43:52 +0100

I wrote:

>>  Maybe I am missing something.
>
>
>             "|" denotes concatenation;

doohhh..

Since NSD will lowercase dnames in RRSIGs too there will be an  
interop problem when we stick to 4034.

--Olaf

---

From: David Blacka <[email-masked]>
Date: Sat, 10 Mar 2007 12:28:47 -0500

> interop problem when we stick to 4034.

Now I must be missing something.  Lowercasing dnames (I assume you  
mean the SignerName here) in RRSIGs should not be a problem. The  
signer and validator must lowercase it prior to generating or  
verifying the signature anyway.  The canonical form is stated  
multiple times in the RFCs (4034 3.1.8.1, the aforementioned section  
6.2, and repeated again in 4035 5.3.2).

---

From: Edward Lewis <[email-masked]>
Date: Sun, 11 Mar 2007 09:45:52 -0400

>be swept away into the dustbin of RFCs nobody implements any more.  so the

10 months ago -

At 9:07 -0700 5/18/06, some one antagonistically wrote to namedroppers:

>I suggest that unless Ed plans to actually deploy NSEC3 he should not be
>permitted to attach new requirements for advancement at this late stage in
>the process.

Now...as Paul said...that is why I stuck my nose into NSEC3 a year ago.

I don't mean to dredge up the animosity that led to the second 
comment, I show it as a point of data.  That wasn't the only barbed 
commend I received, just the most public and archived one.

Sometimes what might seem like a motivated attempt to stall a 
proposal might actually be rooted in a real concern for seeing 
something properly advance.  Although I had no outward motive to care 
about NSEC3 as none of the registries I have ever been a part of 
would care about zone enumeration, I saw then what Paul is commenting 
now, that NSEC3 might completely replace NSEC whether or not zone 
enumeration is the issue.

P.S. I am not insinuating that Paul is just now "seeing the light" 
nor made any barbed comment.  It's just that his comment comes now.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Sarcasm doesn't scale.

---

From: Paul Vixie <[email-masked]>
Date: Sun, 11 Mar 2007 22:39:29 +0000

> From: Edward Lewis <[email-masked]>
> ...

on <Mon, 22 Aug 2005 15:33:08 +0000> in e-mail to the following folks:

	To: John Curran <[email-masked]>
	cc: Randy Bush <[email-masked]>, Bill Woodcock <[email-masked]>,
	    David Conrad <[email-masked]>,
	    Rodney Joffe <[email-masked]>,
	    Mark Kosters <[email-masked]>

i spake thusly:

	then there's NSEC3, which will not actually have to co-exist with NSEC
	since (a) ..., and (b) .COM will never implement NSEC, so all useful
	validators in the world will support NSEC3 from "day 1".

i was referring both to my general comments on the original opt-in debacle
wherein verisign's perfectly reasonable request for opt-in was denied by the
bloodthirsty torchbearing mob, and to my specific comments as made in
message-id <[email-masked]>.  so while i can believe
that my comment which came now gave ed reason to remember what's gone on in
this thread, it's not just now that my comment actually came.

---

From: Mark Andrews <[email-masked]>
Date: Mon, 12 Mar 2007 11:32:46 +1100

For the record, I think RFC 4034 is in error here.

> before signature creation in RFC3845 was an error.

	This is factually incorrect. NSEC and NXT have different wire
	formats.  The presentation formats are the same sans typecode.
	It was this difference that prompted the type code roll.

> Besides, the  

	Then that is up to the implemantions to sort out.  The model
	for DNSSEC is a *single* master with transfer of the zone
	to the other authoritative nodes.  Epsilon implementations
	may wish to note this.
 
> base treat the data as case sensitive.

	Treats the record as opaque.  The same is it treats every
	other record not mentioned as being special.  RFC 4034 for
	NSEC was a rollup of existing RFC.
 
> The result should go into draft-ietf-dnsext-dnssec-updates.

	If it is decided to make NSEC a special case then text needs to
	be added to say that the list of records with special processing
	has been extended.
 
	Mark

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

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 12 Mar 2007 08:12:34 -0400

> Labs patch NSD. It is important that the working group chooses a  

I think the running code wins, even if people think (and I don't know
they do) that the RFC is correct.  

A

-- 
----
Andrew Sullivan                         204-4141 Yonge Street
Afilias Canada                        Toronto, Ontario Canada
<[email-masked]>                              M2P 2A8
                                        +1 416 646 3304 x4110

---

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

> they do) that the RFC is correct. 

Which running code wins ? The one that conforms to the RFC, or the one 
that does not ?

;)

Roy

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Mon, 12 Mar 2007 13:55:55 +0100

> Which running code wins ? The one that conforms to the RFC, or the one

As it turns out, from off-band discussion, NSD will need treat the  
RDATA as an opaque blob for XFR purposes anyway. So a fix is on its  
way. As a practical side effect of that fix the likelihood of being  
'hit' by the problem would decrease for people that validate using  
BIND or Net::DNS::SEC based code. The interoperability issue would  
still exist.

Regardless if we strike NSEC from the list in  item 3 in 6.2 of 4034  
we would need to make the warning on the package pretty big and we  
would need to publish this relatively fast.

--Olaf

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 12 Mar 2007 09:11:42 -0400

> Which running code wins ? The one that conforms to the RFC, or the one 

I should have coffee before writing email.  What I meant, really, was
the large installed base wins.  (I don't think this is a universal
principle, mind: an obviously wrong implementation that is everywhere
wouldn't override the RFC.  But where there is apparent disagreement
over intent in the RFC, I think it's the right approach.)

Sorry for the noise.

A

---

From: "Geoffrey Sisson" <[email-masked]>
Date: Mon, 12 Mar 2007 13:42:20 +0000

> Labs patch NSD. It is important that the working group chooses a 

From a risk assessment point-of-view, I think the damage caused by
trying to change to protocol will be worse than the damage caused
by the few corner cases that may be encountered in the interim
until NSEC3 is published and deployed.  NSEC3 deployment will probably
cause most installations that use DNSSEC in anger (either publishing
or validating) to upgrade.

Geoff

---

From: Edward Lewis <[email-masked]>
Date: Mon, 12 Mar 2007 10:15:08 -0400

>this thread, it's not just now that my comment actually came.

Oh, I'm sure the notion is not new, I doubt that I am the only or 
first to see the evolution of this.  The "just now" referred to the 
to (instance of) the comment I was reacting to.

;)

Sarcasm doesn't scale.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 13 Mar 2007 08:19:28 +1100

> > Which running code wins ? The one that conforms to the RFC, or the one 

	It's actually dualing RFC's.  The rollup into RFC 4034
	changed how NSECs were handled and no one noticed because
	it was a unnecessary change.

	It's only coming up now as we have a implementation that is
	basically written after RFC 4034.

---

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 13 Mar 2007 15:35:12 -0400

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

2. Explain why different rules should apply to NSEC [RFC3845]
    and/or NSEC3 [RFC-to-be]?

3. what RFC's needs to be clarified?

         Olafur (acting as King Solomon)

---

From: Roy Arends <[email-masked]>
Date: Tue, 13 Mar 2007 23:51:21 +0100

>          1.a: Can it be compressed ?

No. Compression would cause resolvers agnostic of IPSECKEY to fail to 
decompress it before shipping it to the client.

>          1.b: Can its case be changed as the Record passes through the 
DNS ?

No. IPSECKEY agnostic resolvers/validators treat this as an unknown blob. 
If anything up the wire changed anything in the rdata, validators will 
fail to validate the unknown blob.

>               to the name before it is signed/verified ?

No. The canonical rules should just be applied to the ownername at nsec 
generation time (for the purpose of canonical sorting) and at rrsig 
generation time. not to anything in rdata.

>          1.d: Please explain your reasoning

         Thou Shall Not Fondle With Rdata.

> 2. Explain why different rules should apply to NSEC [RFC3845]

These should not been different for NSEC. I know they are. But they should 
not. 

>     and/or NSEC3 [RFC-to-be]?

There is no domain name in NSEC3 rdata. If you're referring to the next 
hash domain name, it is a binary blob, a hash. 

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

Nothing really. If one would follow RFC 4034 to the letter, we're all 
fine. 

Roy

---

From: Mark Andrews <[email-masked]>
Date: Wed, 14 Mar 2007 10:28:23 +1100

>          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.
	
>     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.

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Wed, 14 Mar 2007 10:11:21 +0100

Olafur Oh Thou Mighty King ;-)

> 	     It you mean should we downcase before signing / verifying then
I agree with Mark here, item 3 of  6.3 of RFC4032 is clear. IPSECKEY  
is not one of the RRtypes enumerated there:

    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;

>>     and/or NSEC3 [RFC-to-be]?

One could also argue that the NSEC draft dropped the ball and should  
be clarified. The argument would be that the downcasing provides more  
robustness against implementations that do mingle with the RDATA and  
that a DNSSEC-bis aware validator/signer will not treat NSEC as an  
opaque blob anyway. I will not pursue that argument but I am  
mentioning the line of thought because I think that if we had  
discussed this issue when there would have been no fielded  
implementations the outcome may well have been the current text.

I can consent with NSEC being removed from the enumeration in item 3.

--Olaf

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 14 Mar 2007 16:53:54 -0400

>         1.a: Can it be compressed ?

No.

>         1.b: Can its case be changed as the Record passes through the DNS ?

No.

>              to the name before it is signed/verified ?

I don't think so.

>         1.d: Please explain your reasoning

RFC 3597 does not list IPSECKEY in Section 7.  Therefore, any
fiddling with the RDATA is not allowed.
 
>    and/or NSEC3 [RFC-to-be]?

One might argue that the value to DNSSEC of catching such cases is
great enough that the rules in RFC 3597 can be violated.  That seems
like a pretty high bar to jump, though, and would require fairly
extensive discussion by the working group, I think.  I don't see such
discussion in the archive, and in its absence, I can't think of a
reason to apply different rules.
 
> 3. what RFC's needs to be clarified?

It appears that RFC 4034 includes the same list if RRs as RFC 3597
(right down to listing HINFO twice), except that adds RRSIG and NSEC.
That appears to violate the rules in RFC 3597.  So it likely needs
fixing.

A

-- 
Andrew Sullivan                         204-4141 Yonge Street
Afilias Canada                        Toronto, Ontario Canada
<[email-masked]>                              M2P 2A8
jabber: [email-masked]                 +1 416 646 3304 x4110

---

From: Ólafur Guðmundsson /DNSEXT co-chair <[email-masked]>
Date: Thu, 15 Mar 2007 11:29:26 -0400

After reading the thread on this issue and researching the history
the paragraph in question, I'm ready to make a recommendation
on how to proceed.
Below is short history and my recommendation of what to do.

>         leading up to -04 announcement.

I did take a look at the archives of dnssec-editors mailing list
and the CVS archive of the documents to figure out what happened here.
I did not look inside the Ticket system archive as there is no mention
of a ticket being created around this item.

During a real intense editing session around Sept 25'th 2003
following email exchange proceeded the change in the document.

names of editors involved are not important:

Ed1: asks in email:
>Should we add NSEC RRSIG to this list (to be complete) or leave this to
>previous sections (as is now).

Ed2: replies few minutes later:
>We probably better add it, if only for completeness.  Can't hurt.

Ed1: few minutes later:
>added, committed.

This was the end of the discussion.

There was a conference call by the editors and chairs the
day after but as far as I can tell and recollect this issue
was not discussed, most of the time was used to discuss the
NSEC and wild card interaction.

So in my opinion the chairs let the working group down by
not saying stop what are the implications of this change.
The other editors did not say anything, the ED2 above
made a quick judgement call without thinking the issue
through.
It is hard to determine how hard ED1 thought about
the issue but his email does not list issues.
The working group members also share some blame for not questioning 
this change. (Of course if tools.ietf.org wdiff tool
had been available at the time this would have been easier).

To be fair to the people involved, there where number of other
issues handled the same way and this mostly worked well.
Secondly none of us could at the time, imagine an implementation
that blindly down cases <DNAME> inside RDATA based on this list.

Proposed change:
RFC3597 trumps RFC403x

NSEC and RRSIG should be removed from the list of types
to apply DNSSEC canonical down casing name rules to domain
names in RDATA.

Justification:
Only domain names that are candidates for domain compression need
the protection of the canonical name representation, all other
domain names SHOULD/MUST have the expectation to not change during
transition through the DNS system.

As RFC304x are inconsistent by not allowing domain name compression
in the types defined after RFC3597, then listing them is needing
the protection applied to compressible names. It is safe to make this
change.

WG Actions:
DNSSEC-bis-updates will reflect this change as soon a possible
i.e. after chair confirms this proposed change on the mailing
list. The working group will have at least one week to discuss
this issue on the mailing list and at the DNSEXT meeting next week.

Affected implementations:
It looks like the new kids on the block need to change their
behavior.  Lets thank them for identifying the issue.

         Olafur

---

From: Sam Weiler <[email-masked]>
Date: Thu, 15 Mar 2007 14:42:49 -0400 (EDT)

On Mon, 12 Mar 2007, Mark Andrews wrote:

> 	... NSEC and NXT have different wire

Perhaps we recall the history differently.  RFC3755 justifies the type 
code roll for another reason (having to do with an underspecification 
in RFC2535, or, for the more cynical, the severe brokenness of a 
widely deployed resolver).  We changed the wire format at the same 
time (with RFC3845) for different reasons.

-- Sam

---

From: Sam Weiler <[email-masked]>
Date: Thu, 15 Mar 2007 15:11:35 -0400 (EDT)

I like Roy's answers to these questions.

>        1.a: Can it be compressed ?

No, for the reasons specified by Roy and because 4025 says so in
section 2.3.

>        1.b: Can its case be changed as the Record passes through the

No.  RFC3597.

>             to the name before it is signed/verified ?

As Mark said, wrong question.  Don't mess with the RDATA in any way.

>   and/or NSEC3 [RFC-to-be]?

For NSEC, they shouldn't, per 3755 Section 3, which is incredibly 
clear on the subject.

In the case of compression for NSEC or NSEC3, the same logic applies 
as in 1.a, above.

We COULD mess with the case (since the failure mode is all about 
DNSSEC validation, and we have control over that), but I haven't heard 
any compelling reason to.  Given the history and installed base, it's 
a bad idea to change the NSEC behavior, though we could consider it 
for NSEC3.

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

4034 (only), by reference to 3755 Section 3.

-- Sam

---

From: Paul Vixie <[email-masked]>
Date: Thu, 15 Mar 2007 19:04:55 +0000

> Perhaps we recall the history differently.  RFC3755 justifies the type code
> roll for another reason (having to do with an underspecification in RFC2535,
> or, for the more cynical, the severe brokenness of a widely deployed
> resolver).  We changed the wire format at the same time (with RFC3845) for
> different reasons.

sam's right.  the genesis of TCR was the following thread here in Nov'02:

Subject: type codes (Re: wildcard optimization and b/w incompatibility )
From: Paul Vixie <[email-masked]>
To: [email-masked]
Date: Thu, 21 Nov 2002 20:51:19 +0000

regarding backward compatibility, let's talk about RR type codes for
SIG, NXT, KEY, etc

the deployed base of 2535 is insignificant, and no effort has been made
to try to "remain true" to the protocol as described in any earlier dnssec
specification.  therefore in each incompatible revision of dnssec, we ought
to deprecate the old type codes for dnssec-specific RRs.  this will cause
"interrim" implementations to believe that "there is no security data" and
fall back to normal, pre-dnssec operation.

naturally this also presents an unfortunate opportunity to change the rdata
format with each revision, but i hope that we can manage not to take it.

it also means that the mneumonics will change with each revision, so we may
end up with things like SIG2/KEY2/DS2 or even SIG3950/NXT3950/DS3950 if there
were a dnssec revision defined in RFC3950.

however, this is the only way to be sure of "b/w compatibility" with interrim
dnssec implementations -- and that is, to invalidate them entirely and force
them into their pre-dnssec mode.

Subject: Re: type codes (Re: wildcard optimization and b/w incompatibility )
From: Paul Vixie <[email-masked]>
To: [email-masked]
Date: Fri, 22 Nov 2002 04:12:41 +0000

> To quote the "A-Team":  That's so crazy it just might work!

i apologize for keeping the thought to myself for the last year, then.
(i keep wanting to stay out of dnssec's innards because security hurts
me to think about, but then dnssec keeps running aground on issues more
related to dns than security... i promise to speak up sooner next time.)

> But I still have some doubts.  That will help identify the "true" security
> aware servers/resolvers, but will it help the problem of a non-DS aware
> cache between the resolver and authoritative server?

no, and it isn't expected to.  what we want to do is limit the cases to
"pre-dnssec" and "current-dnssec" and not "interim-dnssec-N" or even
"interim-dnssec-N+1".

> If a recursive forwarder doesn't know where to ask for the DS record,
> it doesn't matter what the type code is.

right.  but that problem is separately tractible.  later tonight i will write
in with "ENS", which while uglier than sin, may yet be prettier than namehack.

Subject: Re: type codes (Re: wildcard optimization and b/w incompatibility )
From: Paul Vixie <[email-masked]>
To: [email-masked]
Date: Fri, 22 Nov 2002 04:50:47 +0000

>   However, I think that DS is probably a good seperation for zone cuts.
> If we can simply make the child pull records from the parent again, then we
> might find a resolution to this problem. The stub zone stuff that bind has
> might be a good model - pull it down when you can and save it. 

it's not reasonable to ask an authoritative server to have to fetch anything
from anybody.  it should not need a root.cache file, it should never have to
ask a udp/53 question other than, perhaps, when a slave server asks a master
for its SOA to find out if "now" is a good time for an AXFR.

>   If you are offline and can not speak to the zone's parent during a key
> rollover is a clear problem here.
> 
>   So, we either find a way to put the DS record CLEARLY in the parent, or
> a way for the CHILD to get a copy of it.

watch for the "ENS RR", coming soon to a namedroppers list near you.

>   BTW: NS also lives in both places, BUT, we don't have failures if the
> child and parent disagree. In fact, this is often a feature for some.

putting crap at the delegation point is hairy business.

Subject: Re: type codes (Re: wildcard optimization and b/w incompatibility )
From: Paul Vixie <[email-masked]>
To: Olafur Gudmundsson <[email-masked]>
Cc: Ed Lewis <[email-masked]>
Date: Fri, 22 Nov 2002 04:54:54 +0000

> Well there is no need to rename DS it is not in use in released code.

fine.

> If we are going down this path DO we want to fix the other two problems
> with DNSSEC types ?
> 	the inability to ask for SIG(foo)
> 	the two NXT's at delegations

yes.

> The first one we fix by numbering SIG's with a high bit truned on in
> the type flags (say bit 15) (same way as Bind9 stores them).

except that we should reserve four bits (leaving 4096 RRtypes), yes.

> Fixing the NXT problem we need the authenticated denial type to
> be replaced by two types either something like this
> 	NXT ---> DXT   ----> NXT  (where DXT is a delegation NXT that is
> 		in child zone)
> or	SXT ---> NXT ... NXT ---> SXT  (Start of NXT)
> 
> as you see I do not want to mention this in public as this will
> cause uproar, but if your proposal gets traction then we may want
> to think about this.

either of those would be fine.

> DXT has the same semantics as DS so it is possible just use the DS
> as authenticated denial by using a value inside the records and having
> the next name in the record. In this case the DS record looks like this:
> 	DS <name> <digest> <hash>
> digest ==0 not secure and empty hash
> digest > 0 secure and hash in there
> 
> The attraction of this are
> 	1. Parent expicitly states the security status
> 	2. Only one signature at all delegation (MarkK will like this)

what i want to see is an ENS RR which is NS+DS.  when an EDNS-speaker
signals its interest in things DNSSEC-y, they get ENS RR's (if there are
any).  otherwise, NS RR's are synthesized.  presto, bingo, the zone key
has a place to live and the rules about who owns it (the child, always,
and the parent's copy is nonauthoritative delegation glue) are clear.

oh yes, and delegation NS RR's (or ENS RR's) need to be signed using the
parent's ZSK, even though they are not officially an authoritative part
of the parent zone.

---

From: Roy Arends <[email-masked]>
Date: Fri, 16 Mar 2007 00:00:24 +0100

> a bad idea to change the NSEC behavior, though we could consider it 

NSEC3 has no domain name in its rdata section. The wire format of the next 
hashed domain name is binary. No case issues. No compression. There is 
nothing to consider for NSEC3.

Roy