Subject: dnssec-records ISSUE: don't make NSEC a protocol requirement

From: Simon Josefsson <[email-masked]>
Date: Tue, 22 Jun 2004 10:56:09 +0200

(I'm trying to get some issues entered into the issue tracker, since
they might be lost in the flood of messages on the list otherwise..)

Transition to DNSSEC-ter difficulty caused by DNSSEC-bis requirement for NSEC.

name: Simon Josefsson
email: [email-masked]
Date: June 22
Reference: http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg01161.html
Type: T
Priority: W

Document: draft-ietf-dnsext-dnssec-records-08
Section: 2.3

Rationale/Explanation of issue:

Recent posts make it clear that people believe DNSSEC-ter and
DNSSEC-bis is intended to co-exist.  If DNSSEC-ter is supposed to
solve the zone walking issue, I don't think this will be possible
given current text in DNSSEC-bis.  It says:

   Each owner name in the zone which has authoritative data or a
   delegation point NS RRset MUST have an NSEC resource record. The
   process for constructing the NSEC RR for a given name is described in
   [I-D.ietf-dnsext-dnssec-records].

So any zone not including NSEC's for all owner names violate the
protocol, and a DNSSEC-bis resolver somehow detecting this situation
is allowed to regard the zone as bogus.

Requested change:

The simple part is to change MUST into SHOULD above, and add the
following security consideration:

  When NSEC's are not provided for all owner names in a zone, perhaps
  to prevent zone walking, resolvers will not be able to verify
  negative proofs.  Further, if a all-inclusive NSEC is added, it may
  be used in a replay attack to prove non-existence of existing names.

The document must also require behaviour on resolvers that encounter
absent NSEC's, and this is where it get complicated.  I proposed
something like:

   If a resolver do not receive expected NSEC's to a query, it MUST
   NOT assume the zone is bogus, but instead assume negative proofs
   are absent.

But there may be other changes needed as well.

--
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: Olaf Kolkman <[email-masked]>
Date: Tue, 22 Jun 2004 11:28:53 +0200

Issue is created in the issue tracker. As issue 5
  see https://roundup.machshav.com/dnsext/

Please reply in thread.

--Olaf

---

From: Olaf Kolkman <[email-masked]>
Date: Tue, 22 Jun 2004 11:57:21 +0200

>    NOT assume the zone is bogus, but instead assume negative proofs

With reference to 
http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg01188.html

The specifications are written in such a way that signer and server 
behavior lead to an unambiguous state when verifying. One of the 
implicit assumptions in the specs is that the signer will not lie about 
the zone content. This proposal tries to allow for the signer to lie.

You must be able to unambiguously determine the security state even 
when RRsets are stripped from your packets. The language you are 
proposing does not, IMHO, allow for that.

Since this proposal fundamentally alters the security model I am 
opposed to this change.

However,  'bogus' comes in many shapes and forms, you may be in 'bogus' 
state because the crypto failed, because your signature expired, 
because you did not get expected data. Intro section 5 contains 
language that
allows to 'deal' with the many states of 'bogus' later (!).

--Olaf
   No Hats

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 22 Jun 2004 12:16:11 +0200

Olaf Kolkman <[email-masked]> writes:

> implicit assumptions in the specs is that the signer will not lie
> about the zone content. This proposal tries to allow for the signer to
> lie.
>

How can DNSSEC-ter coexist or be backwards compatible with DNSSEC-bis,
if DNSSEC-bis require NSEC's to exist for all names?  Should the
conclusion be that DNSSEC-ter, if it is supposed to solve the zone
walking issue, cannot coexist with DNSSEC-bis?

I agree the text you quoted would be insufficient, but it was a
starting point for more thorough proposals.

Thanks,
Simon

---

From: Olaf Kolkman <[email-masked]>
Date: Tue, 22 Jun 2004 13:18:44 +0200

Hi Simon,

> walking issue, cannot coexist with DNSSEC-bis?

It can, but only if you indicate in some secure way that the verifier 
should not expect NSECs, and that is the whole point of the transition 
mechanism. How to securely signal that NSECs are not to be expected but 
that they are either not present or that their semantics have changed.

IMHO this can be done with an algorithm roll and with TCR, maybe by 
other ways. Both do not need textual changes.

> starting point for more thorough proposals.

I highly appreciate the effort, but I think that this particular 
proposal touches upon the core design and are therefore not small 
modifications but a big design change. Can we not just agree not to go 
down this particular road?

--Olaf

---

From: Paul Vixie <[email-masked]>
Date: Wed, 23 Jun 2004 00:31:49 +0000

> Since this proposal fundamentally alters the security model I am

i agree.  anyone who publishes a static NSEC that covers names which
do in fact actually exist, is not following the -bis protocol.  to the
extent that they do this and find that it works out well for them, then
we can call it a "successful loophole".  but it's not reasonable to
change the spec to allow this, without a lot more analysis and testing
than this working group has time (or motivation) to perform right now.

it's possible that we can widen this loophole a bit without changing
the security model, by strengthening the "you should not use the NSEC
for synthetic negative caching" text which is already present in the
specs.

what would be best, though, is if implementors either followed the -bis
specs completely (avoiding loopholes), or waited for -ter.  since it's
possible to synthesize NSEC with a target range that only covers the
qname, and it's possible to deploy hardware devices to speed up the
crypto in this case, and it's possible to rate-limit negative responses
in a way that hurts noone but the zone owner and the subdomain holders,
i consider -bis deployable even by folks who are allergic to zonewalking.

---

From: Roy Badami <[email-masked]>
Date: Wed, 23 Jun 2004 02:54:43 +0100

>>>>> "Paul" == Paul Vixie <[email-masked]> writes:

    Paul> what would be best, though, is if implementors either
    Paul> followed the -bis specs completely (avoiding loopholes), or
    Paul> waited for -ter.  since it's possible to synthesize NSEC
    Paul> with a target range that only covers the qname [...]

Not without violating -bis, given the current intent of -bis is
clearly to prohibit having NSEC records for owner names that wouldn't
otherwise have any RRs (-protocol 2.3)

So I think such an approach falls into the same loophole category...

If we want to legitimise such an approach we'd have to replace both
MUST NOTs in -protocol 2.3 para 3 with SHOULD NOTs.

   -roy

---

From: Rob Austein <[email-masked]>
Date: Wed, 23 Jun 2004 02:36:20 -0400

<hat editor=off just-another-bozo=on>

  I do not support this proposal, because it looks like a nontrivial
  change to the DNSSECbis security model.

</hat>

---

From: Ben Laurie <[email-masked]>
Date: Wed, 23 Jun 2004 10:38:36 +0100

Paul Vixie wrote:
> qname,

This is also in violation of the protocol, surely, since both the owner 
and next domain fields would not exist.

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: Paul Vixie <[email-masked]>
Date: Wed, 23 Jun 2004 14:14:43 +0000

> > specs completely (avoiding loopholes), or waited for -ter.

this is still my position.

> > since it's possible to synthesize NSEC with a target range that only
> > covers the qname,
> 
> This is also in violation of the protocol, surely, since both the owner and
> next domain fields would not exist.

yes, sorry.  i forgot where we'd gotten to last time we explored this.