Subject: Re: some issues with NSEC3, based on the workshop last week

From: David Blacka <[email-masked]>
Date: Wed, 17 May 2006 21:04:20 -0400

I'm gonna try and answer the ones that I know the answer to, and ask  
questions about the issues that you are presenting that I don't  
understand.

On May 17, 2006, at 6:00 PM, Edward Lewis wrote:

> On a conference call I listed a few concerns I had with NSEC3 based  
> on the workshop held last week.  The list here isn't in response to  
> any document, nor is it necessarily complete nor well-supported.   
> For the sake of "entering it into the record" here are things that  
> I still see open ended with regards to NSEC3.  (Some of these were  
> in the jabber log, some have been added with a few more minutes of  
> contemplation.)
>
> 1) No transition plan yet. (An earlier email went out on this).
>
> 2) No coexistence plan (I haven't see anyone test NSEC and NSEC3 in  
> the same tree) or testing.  Can NSEC and NSEC3 coexist in the  
> field, or will there be pressure to choose one?  Registry operators  
> cannot be easily divided into gTLDs, ccTLD, ENUM registries  
> anymore, usually the same functions will be under the same roof.   
> Ergo, I don't think it's safe to write off NSEC3 as not appropriate  
> for, say, what's in .arpa.

I don't understand what the difference is between "transition" and  
"coexistence" here.  This is probably just a terminology issue.  Are  
you actually worried that an NSEC3-aware validating resolver wouldn't  
be able to handle a delegation path with both NSEC and NSEC3?

> 3) The need for debugging tools and hooks.  (Tool development is  
> not the IETF's baliwick, but it is a concern to operations.)

Since I'm pretty convinced that RFC 4035 DNSSEC doesn't have  
particularly great debugging tools, I'm not sure what your point is.   
I don't know what you mean by "hooks".

> 4) Why is the number of iterations a parameter?  Why can't we just  
> use one number and reply on the degree of freedom provided by the  
> salt.  Can there be a limit to the length of the salt to prevent  
> abuse?

Salt and iterations solve different problems.  Salt is about  
preventing the use of a pre-computed dictionary.  Iterations is about  
raising the cost of computing that dictionary.  Increasing the length  
of the salt doesn't substantially increase the cost of computing a  
dictionary (well, unless you make the salt really really really long).

There is a limit to the length of the salt: it can be at most 255  
octets.

> 5) Is there an opportunity for a malevolent configuration to turn  
> NSEC3 into an attack vector on resolvers, is there a way to make it  
> an amplifier of activity?

The only vector for this that I see is the iterations parameter, and  
that issue has been addressed in the document.

> 6) Is opt-in necessary for NSEC3 or are they different issues?   
> Could NSEC3 be defined without having the complexity of analyzing  
> opt-in for the first go-round?

They are different issues conceptually, but related  
implementationally.  And as Olaf said (I think), opt-in is the least  
complicated thing about NSEC3.

> 7) What is the toll on verifiers when the salt (and iterations) are  
> not uniform in the NSEC3 records presented?  Is there someway to  
> hide the latency of calculating the hashes needed to start  
> validating of negative answers in the resolver?

Non-uniform NSEC3 sets in a response is more irritating to code than  
inefficient to validate.  Since I cannot think of a legitimate reason  
for anything to produce a response with that property, I would  
suggest that we define such responses as bogus, regardless.

Generating a SHA1 hash over a domainname is so much faster than  
actually verifying a signature, I'm not entirely certain where the  
latency concern comes from.

> 8) What will this look like to recursive servers, caching, and  
> negative caching? This is an open issue as we didn't test this in  
> the workshop.  WHat does it look like if a zone has just turned on  
> NSEC3, turned it off?  See #1.

What does it look like if a zone has just turned on DNSSEC, turned it  
off?  I'm not sure how this is any different.

I would guess that we *did* actually test caching in the workshop,  
even if it was unintentional.  We absolutely did test a recursive  
server in the workshop.

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

--
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: Edward Lewis <[email-masked]>
Date: Thu, 18 May 2006 08:40:34 -0400

At 21:04 -0400 5/17/06, David Blacka wrote:

>"coexistence" here.  This is probably just a terminology issue.  Are you
>actually worried that an NSEC3-aware validating resolver wouldn't be able to
>handle a delegation path with both NSEC and NSEC3?

Yes.  I have never seen it work.  Therefore, I worry.

I am also concerned about how an NSEC-era validator will react to a 
NSEC root, NSEC3 tld, NSEC second-level, a non-signed second-level, 
etc.  Coexistence doesn't just mean "can the new code deal with the 
old world." Coexistence also covers "can the old code deal with the 
new world?"

>Since I'm pretty convinced that RFC 4035 DNSSEC doesn't have particularly
>great debugging tools, I'm not sure what your point is.

This is part of "why aren't operators at the IETF."  We want tools, 
which matter more than specs in operations, and the IETF says it 
doesn't do that.

Hooks - protocol features that are present which make maintenance of 
protocol operations easier.

>Salt and iterations solve different problems.  Salt is about preventing the
>use of a pre-computed dictionary.  Iterations is about raising the cost of
>computing that dictionary.  Increasing the length of the salt doesn't
>substantially increase the cost of computing a dictionary (well, unless you
>make the salt really really really long).
>
>There is a limit to the length of the salt: it can be at most 255 octets.

Okay, this explains the difference between salt and iterations.  No 
one at the workshop gave that reasoning.

That leads me to ask, are iterations an intentional protocol knob 
that enhances DNS's amplification feature?  Are we then trading zone 
exposure for amplification (and maybe other unknowns)?

>The only vector for this that I see is the iterations parameter, and that
>issue has been addressed in the document.

One of my concerns is a zone that has NSEC3 records with different 
parameters, forcing a resolver to compute a lot of hashed before 
finding the needed ones.

>They are different issues conceptually, but related implementationally.  And
>as Olaf said (I think), opt-in is the least complicated thing about NSEC3.

Looking at Ben's last message about dynamic update, it seemed that 
opt-in doubled the cases.

Has there been a resolution to the (old?) conflict of wild cards and opt-in?

>inefficient to validate.  Since I cannot think of a legitimate reason for
>anything to produce a response with that property, I would suggest that we
>define such responses as bogus, regardless.

When something is irritating, then only the malevolent will use it. 
(An attempted twist on a US pro-handgun lobby's slogan: when you 
outlaw guns, only outlaws will have guns.)

What does it mean to label a response as bogus?

What about during transitions of NSEC3 parameters?  Does this mean we 
have to count on flash cutovers?

>Generating a SHA1 hash over a domainname is so much faster than actually
>verifying a signature, I'm not entirely certain where the latency concern
>comes from.

It takes finite time to calculate a hash.  That's latency.

"Hiding latency" is something I picked up working in spacecraft 
ground systems and is something that is a concern in any application 
where there is a forced wait, like during the lookups in DNS.  My 
question comes from hearing of applications that will issue a scatter 
shot lookup.  Like, if a user types in "tires" to their browser, the 
browser will as for tires/IN/A, tires/IN/AAAA, tires.tld/IN/A, 
tires.tld/IN/AAAA, www.tires.tld/IN/A, www.tires.tld/IN/AAAA, with 
the usual variations on "tld".

>What does it look like if a zone has just turned on DNSSEC, turned it off?
>I'm not sure how this is any different.

To someone that has paid for DNSSEC registration, it looks like they 
are getting ripped off.

>I would guess that we *did* actually test caching in the workshop, even if it
>was unintentional.  We absolutely did test a recursive server in the workshop.

We had the unbound code, which did caching.  No other implementation 
is available.

For years we have known that the authority servers are far simpler 
than the recursive servers, yet we repeatedly go to workshops 
thinking that code diversity in authority servers is sufficient. 
This was not new at this workshop, it's been that way for some time. 
We should learn not rest on such laurels.

We also know that issues in recursion sometimes take quite a while to 
appear.  Race conditions as TTLs expire take time to appear.  I have 
never seen a key roll scenarion work completely without an outage. 
Usually this problem creeps up at the end of a multi-day 
workshop/tutorial and we've run out of gas for the debugging.

The point is that we did have recursive code running.  But it was far 
from tested to satisfaction.  And not to lay the blame on the code, 
there were bugs (fixed) in the authority servers (how many NSD's and 
BIND's code cuts were redist'd in the first two days) and there were 
configurations bugs (like forgetting to reset NSD's runtime 
parameters on a restart.)

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Nothin' more exciting than going to the printer to watch the toner drain...

---

From: David Blacka <[email-masked]>
Date: Thu, 18 May 2006 14:23:02 -0400

> Yes.  I have never seen it work.  Therefore, I worry.

Well, I feel certain that it will be tested.  However, if *you* need  
to see it work, then I would suggest that the best way to see it is  
to test it yourself.

I will state that this case does not worry me, personally.  Keep in  
mind that if the resolver is following a secure delegation path, then  
the returned referrals look the same between NSEC3 and NSEC signed  
zones.  If the path is insecure, then it is sufficient to know that  
the validator will correctly determine it in both the NSEC and NSEC3  
cases.

> old world." Coexistence also covers "can the old code deal with the  

Protocol-wise, I see this as an orthogonal issue.  The  
"transition" (or coexistence) technique is just as likely to work for  
NSEC8 as NSEC3.  We will get to testing this as well.

>> particularly

I still don't get the point.  Are you just whining, or is there  
something you want the working group to do?

> Hooks - protocol features that are present which make maintenance  
> of protocol operations easier.

I still don't know what you are talking about.

>> preventing the
> that enhances DNS's amplification feature?  Are we then trading  
> zone exposure for amplification (and maybe other unknowns)?

Ed, this whole issue was discussed at length on namedroppers.  It  
resulted in section 8.1 of the current nsec3 document.

>> implementationally.  And

True, but it all so straightforward.

> Has there been a resolution to the (old?) conflict of wild cards  

What conflict?

> What does it mean to label a response as bogus?

Define as bogus.  Treat as bogus.  Not support.  Fail validation when  
seeing such a response.  Make illegal.  You tell me what phrase works  
for you.

> What about during transitions of NSEC3 parameters?  Does this mean  
> we have to count on flash cutovers?

You mean, does an authoritative server have to answer responses using  
one set of NSEC3 parameters one moment, then answer using a different  
set the next?  Yes.  Does it have to suddenly replace all NSEC3  
records with a different set of NSEC3 records?  No.

>> actually

I wasn't denying the existence of latency, I was questioning the  
concern.  Is there a way to hide the latency caused by verifying a  
signature?

There is more work for the validator to do when validating a negative  
response with NSEC3 records, but the increased amount of work is less  
than the time it would take to verify an additional signature.  So I  
have a very hard time getting excited about it.

> To someone that has paid for DNSSEC registration, it looks like  
> they are getting ripped off.

I think the point of your original question has gotten lost.  I was  
trying to ask another question in the hope of focusing your problem  
statement, but I totally failed.

Your original concern was a fairly vague worry that something might  
go wrong when a zone turns on NSEC3 and then turns it off.  My  
problem with responding to your vague worry is that it is too  
unspecific for me to get a handle on it.  But in general, I'm having  
a hard time seeing how switching NSEC3 on and off is substantially  
different than any other zone change.  Resolvers work with each  
response individually.