Subject: Re: comments on nsec3-01

From: Ben Laurie <[email-masked]>
Date: Thu, 03 Mar 2005 09:03:01 +0000

Paul Vixie wrote:
>>>if NSEC3 alters this then i'm concerned and would like to hear more.
>>
>>I do not believe NSEC3 alters it, that was my point. If the validator
>>treats hashes it can't handle in the same way as unsigned data or data
>>signed with the wrong key, etc, then, it seems to me, you are in the
>>"provably not secure" space.
> 
> 
> ok, so what if someone signs a zone with NSEC3 but not NSEC?  that'll
> mean old validators can prove existence but not nonexistence.  how would
> a validator signal nonexistence to its application?  it would have to
> signal SERVFAIL rather than NXDOMAIN.  is that ok?  (it's important to
> know this, because the same thing happens if we change the NSEC3 hash
> later on, so it's not a once-only transition cost.)

It sounds OK to me, though I can see why one might want a slightly 
richer user experience, if only so the user has a better idea what they 
might do about the failure (signature mismatch might be caused by 
out-of-date keys, for example).

>>Note that if the validator is up-to-date, then this is not an issue
>>anyway, so people who _really_ care about security should never be
>>exposed to this problem.
> 
> 
> agreed, but what i'm trying to understand is whether we're reducing the
> security for the part of the community who doesn't subscribe to the
> dnssec-of-the-month club.  if so, and if it's inevitable that we do this
> and not merely a failing in the current draft, then we have to disclose
> it to the communities who might fund the work or use it when complete.

Given that the alternative (in the case of NSEC3) is no security at all, 
I can't see how we can be reducing security by deploying it.

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

--
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: Jaap Akkerhuis <[email-masked]>
Date: Thu, 03 Mar 2005 10:38:41 +0100

It sounds OK to me, though I can see why one might want a slightly 
    richer user experience, if only so the user has a better idea what they 
    might do about the failure ...

So pushing even more complications towards the resolver.

I'm loosing track of all the corner cases which will be introduced
by NSEC2, NSEC3 and friends, although I see one common theme in
these solutions: methods to guard the server or the information it
produces, seem to put all of the burden towards the resolver. Proper
resolving for dnssec-bis is already difficult enough.
    
	jaap

---

From: Alex Bligh <[email-masked]>
Date: Thu, 03 Mar 2005 10:07:34 +0000

> resolving for dnssec-bis is already difficult enough.

I don't think this is fair criticism.

Part of the issue here is that it seems to me DNSSEC has at least in
part been driven by the protocol community, not the application community.

So naturally we have a little bit of a vacuum when the question "how
do you want the results presented" is asked anyway. Put NSEC3 aside
for a minute. Can you give me a consistent answer to how an application
that wants to resolve (say) www.microsoft.com to retrieve a web page
should treat:
a) Unsecurely denied existence (i.e. NXDOMAIN in vanilla DNS)
b) Securely denied existence (i.e. normal NSEC)
c) An attempt at secure denial of existence but where the proof fails due
   to
   i)   expired keys
   ii)  failed signature
   iii) unsupported signature algorithm
d) Unsecure reported existence (i.e. an A record in vanilla DNS)
e) Secure reported existence
f) An attempt at a secure reported existence (i.e. signed RR) but the proof
   fails due to
   i)   expired keys
   ii)  failed signature
   iii) unsupported signature algorithm

Now, that isn't an easy question to answer. As I argued previously, much
depends on application behaviour (for instance whether it wants to treat
(c)/(f) like (a)/(d) or as SERVFAIL, or some subcases of (c)/(f)
differently, or report them to the user, or what), and we don't actually
know what applications want to do.

Now granted NSEC3 carries one more algorithm that might not be understood,
and carries (with opt-in) one more possibility of generating case (a).
However, it doesn't (it seems to me) change the number of end-cases (i.e.
there is no '(g)' to add to the list above).

Your criticism is valid in so much as DNSSEC-bis does not (currently)
definitively determine what action an application should take (and perhaps
this is right) so a resolver writer is going to be left passing quite a
rich data set to the app "just in case" it wants to know; I agree
incidentally that this isn't necessarily a recipe for ensuring application
writers with little knowledge of DNSSEC end up writing secure apps.
However, this is a criticism of DNSSEC (and the need to maintain backward
compatibility) as a whole. NSEC3 should add no further states which the
application writer needs to guard against.

Clearly, NSEC3 is going to add some *internal* complexity to the resolver.
But it should be just that: internal. And internal complexity is necessary
(as far as I can see) to achieve the design objectives. I should point
out that the server-side proposals for solutions were substantially more
ugly in design terms (see epsilon draft - no criticism of the authors
intended).

Alex

---

From: Ben Laurie <[email-masked]>
Date: Thu, 03 Mar 2005 10:36:23 +0000

> So pushing even more complications towards the resolver.

As Alex has pointed out, no new complications. This issue is there 
throughout DNSSEC.

---

From: Miek Gieben <[email-masked]>
Date: Thu, 3 Mar 2005 11:36:30 +0100

[On 03 Mar, @ 10:38, Jaap wrote in "Re: comments on nsec3-01 ..."]
> So pushing even more complications towards the resolver.

I think this is a fair observation. I also feel that can all agree that 
 o a DNSSEC aware resolver is a complicated beast
 o NSECx isn't going to make it any less complicated

--
grtz,
  - Miek

http://www.miek.nl                   http://www.nlnetlabs.nl

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Thu, 03 Mar 2005 10:28:48 +0100

[ Moderators note: Post was moderated, either because it was posted by 
   a non-subscriber, or because it was over 20K.  
   With the massive amount of spam, it is easy to miss and therefore 
   delete relevant posts by non-subscribers. Please fix your 
   subscription addresses. ]

> Given that the alternative (in the case of NSEC3) is no security at 
> all, I can't see how we can be reducing security by deploying it.
>

I interpret what Paul sais as:

  If you deploy today, the introduction of new features should not make 
you vulnarable if you choose not  to upgrade and use the new feature.

I interpet what Ben sais as:

  If you cannot deal with the new features then you should treat the 
data as if the features would not be there at all; treat the data as 
"classic DNS".

Those are two different requirements.

I think we all agree that iff a new feature is introduces (e.g. NSEC3) 
it should be introduced in such a way that it is "neutral" for the usere 
of DNSSECbis. That means you have to signal the use of NSEC3 by a zone. 
There are multiple transition mechanisms that could be used such as 
algorithm roll.

What we are trying to assess now is what to do if we have a base of 
deployed NSEC3 and we need to roll the hash algorithm.

--Olaf

---

From: Ben Laurie <[email-masked]>
Date: Thu, 03 Mar 2005 10:39:24 +0000

Olaf M. Kolkman wrote:
>  If you cannot deal with the new features then you should treat the data 
> as if the features would not be there at all; treat the data as "classic 
> DNS".

No, that's not what I'm saying. I'm saying that those who want NSEC3 
_will not deploy_ with NSEC, so what you get _is_ classis DNS unless you 
deploy NSEC3.

> There are multiple transition mechanisms that could be used such as 

Why doesn't it suffice to simply return NSEC3 records? Why do you need 
to know before you see an NSEC3 that the zone uses NSEC3?

> deployed NSEC3 and we need to roll the hash algorithm.

I suspect that if we have any sense, we'd use the same algorithm for 
NSEC3 as we do for signing, so we'd only have to roll it if we had to 
roll the signing algorithm.

Cheers,

Ben.

---

From: Alex Bligh <[email-masked]>
Date: Thu, 03 Mar 2005 15:22:34 +0000

> _will not deploy_ with NSEC, so what you get _is_ classis DNS unless you

Whilst I agree with your argument in general, the foregoing is actually an
exaggeration. Yes, a large constituency of those who want NSEC3 will not
deploy with NSEC. However, there are others for whom NSEC3 is desirable
(perhaps because it gives opt-in, perhaps because they don't like
enumeration but are less fussed about it than others, perhaps because they
like to be using 'the latest code' for whatever reason) who will deploy
NSEC then NSEC3.

For these people, it is (as Olaf states) a reasonable requirement that
there is no degradation of functionality UNLESS it is intended by the
user; by which I mean the user switching from NSEC to NSEC3 to exploit
opt-in to reduce the size of a zonefile with only sparse secure delegations
knows has the option to use opt-in or not, and any consequent perceived
reduction in security from lack of authenticated denial is his own choice -
he could have used NSEC3 without opt-in.

So while Olaf has Paul saying:
> If you deploy today, the introduction of new features should not make you
> vulnarable if you choose not  to upgrade and use the new feature.

that's a reasonable requirement if by "use the new feature" you mean
"use NSEC3 not NSEC" provided you also add "and do not deliberately
use options that arguably make you more vulnerable" (e.g. opt-in).

Alex