Subject: Re: comments on nsec3-01

From: [email-masked] (Ted Lindgreen)
Date: Tue, 1 Mar 2005 14:42:25 +0100

[Quoting Roy Arends, on Mar  1, 14:11, in "Re: comments on nsec ..."]

Roy,

I'm not sure I fully understand what you are saying, but I read
from your argumentation:

> Firstly, lets agree that changing the hash-function field value inside the
> NSEC3 requires re-signing the record. If an adversary changes the
> hash-function field value without re-signing, the verification of the
> RR will fail .....

that it leads to:

> Basically, there are three mayor effects:
> 
> 1) negative responses (i.e. no such name, no such type) will deem invalid.
> (for argument sake, this includes responses due to wildcard expansions).
> 
> 2) positive responses can be replaced by any negative response from the
> same zone. Because the hash-function is not known, QNAME can not be
> checked against the interval.
> 
> 3) the status of delegation points is unknown, since the interval of the
> related NSEC3 RR can not be checked, hence, the DS bit status is not
> valid.

which then translates into:

> The most destructive action an adversary can mount at this point is a
> denial of service.

If I understand this correctly, then this expands to:

 We don't really need the authenticated denial of existance machinery
 at all, as the most destructive action is a DOS.

If this were true, then we could do away with NSEC altogether, but
I'm affraid it isn't true as there was (and still is, I think) broad
consensus that authenticated denial of existance is an essential
part of DNSSEC.

Regards,
-- 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: Roy Arends <[email-masked]>
Date: Tue, 1 Mar 2005 15:06:35 +0100 (CET)

> > hash-function field value without re-signing, the verification of the

Nope.

The 'firstly' and 'secondly' I wrote simply makes the resolution fatal. I
explicitly say that.

Then I continue and argue the effect of usage of unknown values for the
hash-function field in the nsec3 RDATA.

> > The most destructive action an adversary can mount at this point is a

'zactly.

>  at all, as the most destructive action is a DOS.

Nope. Not at all. You're jumping to the wrong conclusion.

Let me rephrase that so you might understand what was between the lines:

The most destructive action an adversary can mount at this point is a
denial of service, as opposed to altering a response in such a way that a
resolver now regards data as 'cryptographically not secured'

> If this were true,

Which is not. Please re-read my message.

Roy

---

From: [email-masked] (Ted Lindgreen)
Date: Tue, 1 Mar 2005 15:46:40 +0100

[Quoting Roy Arends, on Mar  1, 15:11, in "Re: comments on nsec ..."]
....
> > > The most destructive action an adversary can mount at this point is a

Ok...
 
> Let me rephrase that so you might understand what was between the lines:

Sorry, I keep having difficulties with reading between your lines...

> Which is not. Please re-read my message.

Does that reviel the unwritten lines in between? I doubt it...

>From what I understand sofar:

- there is a timeframe in which a good and correctly configured
  resolvers can not (are not able to) verify some part of the
  authenticated denial of existance machinery;
- Sam then argues that this would not be an incentive for a
  domainholder to get into this stuff;
- Roy writes that it isn't that bad as it's only a DOS.

What I understand is that, with a good and correctly configured
resolver, the resolver-user may encounter a part of the world where
authenticated denial of existance can not be verified. This gives
two choices:

1. Be strict and accept that this part drops from your world;
2. Be lenient, and accept reduced security.

>From the perspective of a domainholder, I think Sam is right:
if the domain is valuable, the domainholder will be reluctant
to risk that his domain becomes invisible.

However, more important than above details is, IMHO, that NSEC3 is
making DNSSEC so much more complicated that it becomes difficult
for even the people working on DNSSEC to comprehend what exactly
are gaping security holes, or just risks, threats, or only minor
inconveniences.

-- ted

---

From: Roy Arends <[email-masked]>
Date: Tue, 1 Mar 2005 16:29:50 +0100 (CET)

>   domainholder to get into this stuff;

Exactly.

> - Roy writes that it isn't that bad as it's only a DOS.

No. No. No. No. No.

Please quote the part where I say that.

Roy wrote that its a DoS.
Roy did NOT write it isn't that bad.

I agree with Samuel. I noted it is hard to roll the hash-function
field. So did he.

> 1. Be strict and accept that this part drops from your world;

Hence a denial of service.

> 2. Be lenient, and accept reduced security.

You call this lenient ? Lenient to whom ? I call this plain stupid.

> to risk that his domain becomes invisible.

Hmmmm. If the domain is valuable, wouldn't you want resolvers to be
strict ? Enforce the upmost scrutiny ? Therefor use a better hash-function
?

You're confused. You're mixing valuable with visible.

> are gaping security holes, or just risks, threats, or only minor

NSEC3 is complex, just a little more then DNSSEC. Complicated is a
personal view. People who are working on DNSSEC and can't distinguish
between gaping security holes, or just risks, can contact me anytime.

Ted, contact me off-list if you need help with your learning curve.

Roy

---

From: [email-masked] (Ted Lindgreen)
Date: Wed, 2 Mar 2005 19:29:17 +0100

[Quoting Ben Laurie, on Mar  2, 18:25, in "Re: comments on nsec ..."]
> Ted Lindgreen wrote:
> > [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).
> 
> But it isn't bogus, your validator is :-)

No, the protocol (or this particular extention of it) is, I'm affraid.

-- ted

---

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

Paul Vixie wrote:
>>>>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.
>>
>>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.
> 
> 
> 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.

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.

-- 
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: [email-masked] (Ted Lindgreen)
Date: Wed, 2 Mar 2005 16:33:53 +0100

-- ted

---

From: [email-masked] (Ted Lindgreen)
Date: Thu, 3 Mar 2005 12:37:35 +0100

[Quoting Ben Laurie, on Mar  3, 11:37, in "Re: comments on nsec ..."]

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

I'm affraid, I do not agree, and I think most of the protocol
community here feels that NSEC3 does introduce new complications.

What bothers me is that the desire of a few to obscure part of the
data for which DNS is designed to make it available, now seems to
lead to a situation where part (or most?) of the users (all but the
members of the dnssec-of-the-month-club) must settle with either
reduced functionality (SERVFAIL) or reduced security (or be "plain
stupid" to quote Roy).

Regards,
-- ted

---

From: Paul Vixie <[email-masked]>
Date: Thu, 03 Mar 2005 21:17:47 +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?

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]