Subject: RE: [URGENT] Re: Q: Does advancing DNSSECbis to IESG prevent NSEC-alt in the future?

From: Roy Arends <[email-masked]>
Date: Thu, 17 Jun 2004 15:50:36 +0200 (CEST)

On Thu, 17 Jun 2004, Scott Rose wrote:

> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]]On Behalf Of Edward Lewis
> >
> > I need to re-read -protocol before saying what I was going to say.
> >
> > At 10:12 +0200 6/17/04, Olaf M. Kolkman wrote:
> > >Following are the changes the chairs are aware off and will
> > >be done before documents are forward to IESG:
> > >
> > >  1. Caching issue brought up by David Blacka.
> > >  2. Make it clearer that name space in NSEC records is circular.
> >
> > Is the space circular?  I used to think so, but am less convinced now
> > than a week ago.
> >
>
> So am I.  I don't believe it was intended to be circular as it is written.
> The @ was put simply to mark the end of the namespace covered by the NSEC
> chain.  If the WG desires it to be circular to accomdate something, that is
> a spec change.

It was never ment to make namespace circular, it was ment to deny data
after the last owner-name. This was the only way to signal that.

Roy

--
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 M. Kolkman" <[email-masked]>
Date: Fri, 18 Jun 2004 12:19:29 +0200

> after the last owner-name. This was the only way to signal that.

I observe that you reach this conclusion without any reference to
any of the documents while Ben just quoted two sentences from 4.1.1
that to me provides a description of a circular zone.

I am also inclined to refer back to 2535 5.1 that explicitly states 

   This is handled by treating the name space as circular and putting
   the zone name in the RDATA of the last NXT in a zone.

In order to unambiguously proof the non-existence of names the NSEC
chain was designed the way it was. Creating holes in the NSEC chain
changes the security model and is a change to the initial requirement
for unambiguous denial of existence.

I therefore think that 'circularity' either needs mention (by using
the language from 2535 5.1) or we need the language as is. It is a
purely editorial issue.

Something that occurred to me when reading the thread an that relates
more to Simon's reply...

We have to face that the specs where written without considering that
the zonesigner would provide "lies" about the structure of the
zone. The spec describe the zonesigners behaviors (how the NSEC RR
chain should be constructed) and it is implicitly assumed the
zonesigner can be trusted. 

Changing the implicit assumption that the zonesigner does not lie
about the zone structure is touching on the fundamental design of
DNSSEC, we _will_ open up corner cases. 

Maybe we should make the implicit assumption more explicit.

-- Olaf
   hat in hand.

---------------------------------| Olaf M. Kolkman
---------------------------------| RIPE NCC

---

From: Roy Arends <[email-masked]>
Date: Fri, 18 Jun 2004 12:38:22 +0200 (CEST)

> that to me provides a description of a circular zone.

I never said it wasn't circular...

> chain was designed the way it was.

And this is what rfc 2535 says preceding your quote:

   There is a potential problem with the last NXT in a zone as it wants
   to have an owner name which is the last existing name in canonical
   order, which is easy, but it is not obvious what name to put in its
   RDATA to indicate the entire remainder of the name space.

Hence my conclusion: it was ment to deny data after the last
owner-name. The property of circularity was not the primary design, it was
a solution to an exception.

> Creating holes in the NSEC chain changes the security model and is a
> change to the initial requirement for unambiguous denial of existence.

Absolutely.

> the language from 2535 5.1) or we need the language as is. It is a

Precisely, send text.

Roy

---

From: Ben Laurie <[email-masked]>
Date: Fri, 18 Jun 2004 12:48:47 +0100

> Maybe we should make the implicit assumption more explicit.

You can fix that by making a small change to the first sentence of para 
2 of section 4:

    "Because every authoritative name in a zone must be part of the NSEC
    chain, NSEC RRs must be present for names containing a CNAME RR."

becomes:

    "Because every authoritative name in a zone MUST be part of the NSEC
    chain, NSEC RRs must be present for names containing a CNAME RR."

This makes white lies non-compliant, though I believe that other 
language in the spec ensures that it is a non-compliance that will work 
(modulo resolvers getting clever).

I suspect that in order to be ready for dnssec-ter, Nominet will want to 
use white lies despite their non-compliance, and it would be friendly to 
legitimise this use. Perhaps add this sentence, "However, a zone MAY 
instead include a single NSEC record containing the apex as both owner 
and Next Domain Name in order to work around zone-walking issues with NSEC".

Also, in security considerations, you would then need: "If a zone uses 
the workaround for zone walking detailed in section 4, it is vulnerable 
to replay attacks denying the existence of any name in the zone".

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