Subject: Re: comments on nsec3-01

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

--
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: Paul Vixie <[email-masked]>
Date: Wed, 02 Mar 2005 19:15:45 +0000

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

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

---

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: Paul Vixie <[email-masked]>
Date: Thu, 10 Mar 2005 17:12:29 +0000

> > So an NSEC3 nameserver will have to explicitly prove the non-existence
> > of an NS record at each label up to the closest non-empty encloser by
> > returning the appropriate NSEC3 record of each parent label.
> 
> No, because there should be no records below the NS record in the parent
> zone, so if there is an NS, it will be at the closest encloser. The same
> argument applies to NSEC, as far as I can see.

i don't think this holds.  the parent can contain in-child glue, which
will never appear in answer sections.  this is how zones are "reachable"
even if all nameservers are in-zone or below-zone.  that means

$ORIGIN .
net NS a.gtld-servers.net.
a.gtld-servers.net. A i.p.v.4

---

From: Jim Reid <[email-masked]>
Date: Thu, 17 Mar 2005 12:23:03 +0000

>>>>> "Ben" == Ben Laurie <[email-masked]> writes:

    >> Even with 5 years of security expertise as input RFC 2065 was
    >> so operations unfriendly that it took years to fix the problem
    >> and years more to generate a new definition.  I don't want to
    >> repeat that experience.

    Ben> Don't worry, we are committed to producing the tools required
    Ben> to test NSEC3.

Who's "we"? Producing tools and what have you to test NSEC3 is all
very well. But if they're coming from the people who write the NSEC3
draft, that test suite could be unsatisfactory. Please note I'm not
questioning the integrity of those writing the NSEC3 drafts. I am
saying that if the test suite comes from the same source as NSEC3, the
tests could be relying on knowledge that's in the heads of the authors
but not written in the spec; or the tests have too narrow a focus;
etc, etc.

That said, Ed's point is well-made. Once the NSEC3 draft is done,
there should be a period of experimental deployment with workshops and
interoperability events so that the draft can be tweaked if
operational experience suggests that's needed.