Subject: Re: comments on nsec3-01

From: [email-masked] (Ted Lindgreen)
Date: Wed, 2 Mar 2005 16:33:53 +0100

[Quoting Ben Laurie, on Mar  2, 16:18, in "Re: comments on nsec ..."]

> > One of the many questions I have is what should be the default
> > behavior in case you do not understand the new hash algorithm. Should
> > you treat the answer as non secure?
> 
> The answer is non secure, so it would be slightly insane to treat it any 
> other way.

Shouldn't you be treating it as bogus? (Because it was meant to
be secured, but you can't verify it).

-- ted

--
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: Alex Bligh <[email-masked]>
Date: Wed, 02 Mar 2005 16:21:07 +0000

> be secured, but you can't verify it).

It's no more bogus than an unsigned reply. It might be bogus, or it
might be a hash function you don't implement and be perfectly OK.

Alex

---

From: Roy Arends <[email-masked]>
Date: Wed, 2 Mar 2005 17:50:47 +0100 (CET)

> be secured, but you can't verify it).

I'm with Ted on this one. This is a degradation attack.

If the stripping of an NSEC3 record from the response can go undetected,
and meanwhile treating the other NSEC3 (with unknown hash) response as
unsigned, an attacker can degrade security.

Roy

---

From: Ben Laurie <[email-masked]>
Date: Wed, 02 Mar 2005 17:25:36 +0000

> be secured, but you can't verify it).

But it isn't bogus, your validator is :-)

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

---

From: Ben Laurie <[email-masked]>
Date: Wed, 02 Mar 2005 17:27:16 +0000

> unsigned, an attacker can degrade security.

An attacker can "degrade security" in the same way by blocking the 
(understood) NSEC3 response and providing an unsigned response. This 
does not seem to me to be either interesting or preventable.

Cheers,

Ben.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 02 Mar 2005 18:26:38 +0000

> > > Shouldn't you be treating it as bogus? (Because it was meant to be
> > > secured, but you can't verify it).
> 
> > I'm with Ted on this one. This is a degradation attack.  If the
> > stripping of an NSEC3 record from the response can go undetected,
> > and meanwhile treating the other NSEC3 (with unknown hash) response
> > as unsigned, an attacker can degrade security.
> 

this goes to expectation.  in dnssec-bis, if you learned a DS RR from
the parent or if your validator's SEP indicates "must be secure" for
some domain, then if you don't get security metadata from the subzone,
you have to assume that you're being MIM'd.  in this case you'll drop
the data and the application on the other side of your API will never
see it.  it'll be the same, from the application's point of view, as
SERVFAIL.  same thing happens if the data is signed with the wrong key
or if the signature doesn't match.  this is the "provably not secure"
member of the trivalued validator result space.

if NSEC3 alters this then i'm concerned and would like to hear more.

---

From: Ben Laurie <[email-masked]>
Date: Wed, 02 Mar 2005 19:07:19 +0000

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

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.

Cheers,

Ben.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 02 Mar 2005 19:15:45 +0000

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

> anyway, so people who _really_ care about security should never be

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.

---

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

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

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

---

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: Ben Laurie <[email-masked]>
Date: Thu, 03 Mar 2005 10:39:24 +0000

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

Olaf M. Kolkman wrote:
>> 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".

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.

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

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?

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

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

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

--Olaf

---

From: Jim Reid <[email-masked]>
Date: Thu, 03 Mar 2005 14:55:58 +0000

Just curious. If/when DNSSEC-ter gets through IETF, what's going to be
done about RFC3225? Are more EDNS header bits going to be used to
signal that a resolver groks NSEC[23] (or whatever) RRs but not NSECs?
And vice versa?

---

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

---

From: Paul Vixie <[email-masked]>
Date: Thu, 03 Mar 2005 21:17:47 +0000

> signal that a resolver groks NSEC[23] (or whatever) RRs but not NSECs?

previously i'd suggested the following:

   DNSEXT Working Group                                         Paul Vixie
   INTERNET-DRAFT                                                      ISC
   <draft-vixie-dnssec-ter-01.txt>                               June 2004

                      Extending DNSSEC-BIS (DNSSEC-TER)

   Status of this Memo

      This document is an Internet-Draft and is in full conformance with
      all provisions of Section 10 of RFC2026.

      Internet-Drafts are working documents of the Internet Engineering
      Task Force (IETF), its areas, and its working groups.  Note that
      other groups may also distribute working documents as Internet-
      Drafts.

      Internet-Drafts are draft documents valid for a maximum of six months
      and may be updated, replaced, or obsoleted by other documents at any
      time.  It is inappropriate to use Internet-Drafts as reference
      material or to cite them other than as "work in progress."

      The list of current Internet-Drafts can be accessed at
      http://www.ietf.org/ietf/1id-abstracts.txt

      The list of Internet-Draft Shadow Directories can be accessed at
      http://www.ietf.org/shadow.html.

   Abstract

      As the DNSSEC-BIS document set goes to press, we find that the design
      goals for DNSSEC have shifted somewhat in the ten years of its
      preproduction.  This memo lists some possible new directions for
      DNSSEC-TER, and also, some methods by which DNSSEC-TER could first
      coexist with, and possibly replace, DNSSEC-BIS.

   1 - Rationale and Scope

   1.1. DNSSEC-BIS, which took ten years to evolve, is widely considered to
   be a working solution for end to end DNS data authenticity.  However,
   the threat model which drove the design of DNSSEC and DNSSEC-BIS fails
   to address issues of great interest to some members of the community,
   for example, domain name confidentiality.

   Expires December 2004                                           [Page 1]

   INTERNET-DRAFT                 DNSSEC-TER                      June 2004

   1.2. Without proposing any specific new features, this memo will lay out
   an upgrade path whereby DNSSEC-TER could first coexist with, and then
   possibly replace DNSSEC-BIS, with no loss of functionality for DNSSEC-
   BIS adopters.  The method used has been called a "type code roll" or
   TCR.

   1.3. The goal of this memo is not to specify DNSSEC-TER itself, but
   rather, to describe the method by which it can be developed and
   deployed, compatibly with an existing DNSSEC-BIS installed base.

   2 - New Signalling, New Metadata

   2.1. Since DNSSEC-BIS already depends on EDNS due to message size
   increases, it is safe to depend on EDNS to carry a new DNSSEC-TER flag.
   The meaning of this flag would be, generally, "when I say I want DNSSEC
   metadata in the response to this query, I can handle, and prefer,
   DNSSEC-TER metadata."

   2.2. DNSSEC-TER might define new metadata records (for example, DS2,
   NSEC2, RRSIG2, and/or DNSKEY2), but will not redefine the meaning or
   format of existing DNSSEC-BIS metadata records due to the risk of these
   records becoming separated from the DNSSEC-TER tag that tells how to
   interpret them.

   2.3. EDNS is a hop by hop protocol, carrying meaning only between an
   initiator and a responder.  A caching forwarder who can process both
   DNSSEC-TER and DNSSEC-BIS will "tag" its security metadata using the
   "DNSSEC-TER data is wanted" status of the query which causes that
   metadata to enter the cache.  If cached data exists but was fetched
   without (or with) this tag, and a query arrives with (or without) the
   "DNSSEC-TER wanted" flag, then the new query will have to be forwarded
   upstream toward the authority servers, and the result (even if negative)
   will be cached and used separately.  This behaviour has the effect of
   promoting the "DNSSEC-TER" wanted flag from hop-by-hop to end-to-end.

   2.4. If an authority server or caching recursive server is asked for
   DNSSEC-TER metadata but only has DNSSEC-BIS metadata available, then
   DNSSEC-BIS data will be sent.  Thus, a requestor who is capable of
   handling DNSSEC-TER metadata records should ask for DNSSEC-TER first,
   and then fall back to DNSSEC-BIS if necessary.  This optimizes for the
   eventual case when the installed base of DNSSEC-BIS has completely
   upgraded to DNSSEC-TER.  An initiator is not permitted to assume, from
   the lack of a DNSSEC-TER response, that either that server or that zone
   does not in general support DNSSEC-TER.

   Expires December 2004                                           [Page 2]

   INTERNET-DRAFT                 DNSSEC-TER                      June 2004

   2.5. A zone signer and/or authority server might choose to support both
   DNSSEC-BIS and DNSSEC-TER, or only DNSSEC-BIS, or only DNSSEC-TER.  It
   is expected that a validating recursive server, or a caching recursive
   server, will support either DNSSEC-BIS alone (as is the case today), or
   both DNSSEC-BIS and DNSSEC-TER, but never DNSSEC-TER alone.

   3 - References

   [RFC1035]  P. Mockapetris, ``Domain Names - Implementation and
              Specification,'' RFC 1035, USC/Information Sciences
              Institute, November 1987.

   [RFC2671]  P. Vixie, ``Extension mechanisms for DNS (EDNS0),'' RFC 2671,
              IETF DNSIND, September 1998

   4 - Author's Address

                 Paul Vixie
                    Internet Systems Consortium, Inc.
                    950 Charter Street
                    Redwood City, CA 94063
                    +1.650.423.1301
                    <[email-masked]>
                    3557*VIX

   Expires December 2004                                           [Page 3]

---

From: Paul Vixie <[email-masked]>
Date: Thu, 03 Mar 2005 21:27:06 +0000

> deploy with NSEC. However, there are others for whom NSEC3 is desirable ...
> 
> > 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.
> 

and yet, none of these takes account of what i meant by dnssec-of-the-month.

every time we roll the hash algo for NSEC3, the problem recurs.

if it was just that adding NSEC3 made zones less secure while validators
were yet to upgrade, then there'd be a flag day.

we're talking about a flag-tuesday.  every tuesday from now on.  is that ok?

---

From: Alex Bligh <[email-masked]>
Date: Fri, 04 Mar 2005 10:29:30 +0000

Paul,

> we're talking about a flag-tuesday.  every tuesday from now on.  is that

I'm must be missing the point of what you saying, and/or there's
more agreement here than people realize.

I am saying that the introduction of new features in NSEC3 (which at
least by specification gives non-enumerability and opt-in) should not
weaken security for those who migrate from NSEC to NSEC3, but opt not
want to use features the very purpose of which is to reduce security
(e.g. opt-in) - i.e. if you migrate, you should have the option of being
unaffected. [*]

Now that INCLUDES any hash-roll algorithm that is in place within NSEC3.
So, taking the hypothetical case, IF NSEC3 introduced a hash-roll
algorithm that reduced security during a hash-roll, and (taking a
hypothetical case which I believe to be counterfactual, but...)
hash-roll is actually useful and likely to be used in more than a
test environment, THEN the NSEC3 does *not* meet criteria '*' above.
I think this is what you are asking by "is this OK" and, with the
previous assumptions the answer is "no".

This implies (in my book) we either have to
a) find a non-security-weakening form of hash-roll (which Ben seems to
   think he has already) OR
b) abandon hash-roll

For reasons I've set out elsewhere, whilst (a) sounds like a fun
engineering task (perhaps one already completed, perhaps not), I actually
don't see the point of hash-roll at all, in which case (b) is fine.

In the specific context of your question, I don't think hash roll (and I'm
talking about here not 'changing the hash algorithm to one the resolver
MUST support' or 'changing the salt' [**], but 'changing the algorithm to
one which which the resolver MAY not support') is going to be common at all
- why should it be every Tuesday? Are we not happy with "if all mandatory
hash algorithms are broken, we give up and have a flag day then". I think
that buys us a good 20 years rather than 7 days.

[**]=for these types of roll, surely there is no issue?

Alex

---

From: Ben Laurie <[email-masked]>
Date: Fri, 04 Mar 2005 10:43:48 +0000

> don't see the point of hash-roll at all, in which case (b) is fine.

I agree. Just because NSEC3 has a field to specify the hash algorithm, 
it doesn't mean we have to be ready to update its meaning on-the-fly.

Cheers,

Ben.

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Fri, 04 Mar 2005 11:53:44 +0100

> it doesn't mean we have to be ready to update its meaning on-the-fly.

But we do have to specify what applications do if they see that field 
having a value that they do not understand and we have to understand 
what happens if the applications receive such packets.

The problem in this case is that if the vallue of the hash field is 
critical in the verification of the answer. And if the field  is unknown 
the NSEC3 cannot be reliably coupled to the original QNAME.

--Olaf

---

From: Ben Laurie <[email-masked]>
Date: Fri, 04 Mar 2005 10:58:23 +0000

> the NSEC3 cannot be reliably coupled to the original QNAME.

Correct.

Cheers,

Ben.

---

From: Alex Bligh <[email-masked]>
Date: Fri, 04 Mar 2005 11:12:50 +0000

>> the NSEC3 cannot be reliably coupled to the original QNAME.

& so the answer (where there is no hash roll to non-mandatory algorithms)
is that the server MUST NOT put a value in the hash algorithm field which
is not that of a specified mandatory algorithm in the NSEC3 docs (as
released), that the resolver MUST implement all such mandatory algorithms
(if that isn't tautology), and hence that if the resolver finds a value in
the algorithm field which does not map to such a mandatory algorithm, it
knows the server is behaving out of protocol.

According to Sam's exposition, the data is not insecure due to "some fault
in the validator", it is because the server is out of protocol. So the
correct interpretation here is state #3 (Bogus). That seems correct to me
(given that we are not trying to support roll).

Alex

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Fri, 04 Mar 2005 13:16:43 +0100

> (given that we are not trying to support roll).

I agree.

--Olaf
   (namedropper)