Subject: Re: zone-covering NSEC ranges -- "which is it?"

From: Edward Lewis <[email-masked]>
Date: Mon, 14 Jun 2004 17:24:01 -0400

I like the second possible answer.  The first answer is "special 
case" and I loathe those.  The second answer is based on a concept in 
use elsewhere (serial number arithmetic, signature lifetimes).

At 21:08 +0000 6/14/04, Paul Vixie wrote:
>i asked this in an earlier message but it was lost in the haze of a larger
>discussion.  here are two NSEC RRs, more or less.
>
>#1:          @ NSEC (SOA NS ...) @
>
>#2:          X NSEC (...) X
>
>there are two visible differences between them: one says there's an SOA and
>NS at the ownername (@), the other does not (X).   and one's owner and target
>names are "@" (the zone apex) and the other's owner and target name is "X"
>(not the zone apex).
>
>those familiar with the specs consider the first one to be a way of expressing
>the nonexistence of any names other than the zone apex.  in other words it
>covers the whole zone, all possible names.
>
>why?  there are two possible answers.  for my own edification i'd like to
>clarify which one applies, and for others' edification i might end up asking
>that the dnssec-bis docset be amended to clarify this point.
>
>the first possible answer to "why does @-NSEC-@ cover all possible names?"
>is that the target name is @, and it's a special case indicating that all
>names from the owner name through the end of the zone are in the range.
>
>the second possible answer to "why does @-NSEC-@ cover all possible names?"
>is that the target name equals the owner name, indicating a null range,
>which in some kind of "serial number arithmetic" kind of way "wraps around."
>
>if we select the first possible answer, then "X-NSEC-X" does not speak for
>all possible names in the same way "@-NSEC-@" does.
>
>if we select the second possible answer, then "X-NSEC-X", for any value of
>X including @ or any other, speaks for all possible names.
>
>which is it?
>
>--
>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/>

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

"I can't go to Miami.  I'm expecting calls from telemarketers." -
Grandpa Simpson.

--
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 Badami <[email-masked]>
Date: Mon, 14 Jun 2004 22:45:20 +0100

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

    Paul> the second possible answer to "why does @-NSEC-@ cover all
    Paul> possible names?"  is that the target name equals the owner
    Paul> name, indicating a null range, which in some kind of "serial
    Paul> number arithmetic" kind of way "wraps around."

I had been assuming the second possible answer, given that RFC2535 said (5.1):

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

However it appears that DNSSECbis makes no similar statement about a
circular name space.

     -roy

---

From: Don Stokes <[email-masked]>
Date: Tue, 15 Jun 2004 11:38:10 +1200

>X including @ or any other, speaks for all possible names.

I rather like the idea that X NSEC X covers all just X and all its
subdomains (with appropriate processing where X is a delegation point).
That generalises nicely to @ NSEC @ as well.

To generalise further, if the Next Domain Name field is less than or
equal to the owner name, then one can assume that the owner name is the
last subdomain of the name specified as the next domain name.

Thus:
	x.y.example.	NSEC y.example. ...

denies z.y.example and z.z.y.example, regardless of whether y.example is
a zone apex or not.

The lovely part of this approach is that you don't actually have to
consider the zone cut when checking if a name is between the owner and
next domain name in an NSEC; the only special case is when the owner
name is a delegation point. 

If you have a "proper" NSEC chain, this happens anyway, it's just that
the wrap happens at the bottom of the zone and wraps to the apex.  But
there's nothing stopping one wrapping tighter than that if appropriate.

The only corner case to consider is where the NSEC points outside the
zone, e.g.

	  x.example.	SOA ...
	y.x.example.	NSEC example. ...

This MUST NOT be treated as a denial for z.example.  This isn't an issue
in the normal case, since you won't be trusting stuff signed from within
x.example when querying z.example, but anything aggressively using NSECs
will need to be aware of that one.

-- don

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Tue, 15 Jun 2004 10:37:04 +0200

On Mon, 14 Jun 2004 21:08:36 +0000

> names are "@" (the zone apex) and the other's owner and target name is "X"

Having read the other mails.

The mention of circularity is unambiguously mentioned in records 4.1.1.

   The value of the Next Domain Name field in the last NSEC record in
   the zone is the name of the zone apex

Per definition the apex alway exists. Now asume that besides the apex
there is only one other record 'X' in the zone, that record X will
always have X NSEC @, independent of the amout of labels in X. 
'@ NSEC @' is just the extreme for X nearing @. It is not a special
protocol case it is the special case of a 1-name-only zone.

This also implies that for all X where X NSEC X, X is the apex of a
zone and white lies will need to be treated as special cases.

special cases->special treatment->new corner cases->more delay.

-- Olaf

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

---

From: Roy Badami <[email-masked]>
Date: Tue, 15 Jun 2004 11:50:32 +0100

>>>>> "Olaf" == Olaf M Kolkman <[email-masked]> writes:

    Olaf> The mention of circularity is unambiguously mentioned in
    Olaf> records 4.1.1.

    Olaf>    The value of the Next Domain Name field in the last NSEC
    Olaf> record in the zone is the name of the zone apex

I disagree that it is unambiguous.  It is perfectly possible to read
the above paragraph as indicating that the last NSEC record in the
zone is a special case.

     -roy

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Tue, 15 Jun 2004 14:07:41 +0200

On Tue, 15 Jun 2004 11:50:32 +0100

> the above paragraph as indicating that the last NSEC record in the

Sorry Roy, I do not see an ambiguity.

The result of reading the text as a 'special case' is that the
name-chain is circular. 

Note also that reading "special case" does not change my argument that
the only name for which X NSEC X can exists is for X==@.

A different way of formulating that argument is that the only name for
which the NSEC RR points to the apex is the last name in the zone (the
special case above). As a concequence if the owner name of the NSEC
that points to the apex is the apex itself there are no other names in
that domain.

-- Olaf

---

From: Roy Badami <[email-masked]>
Date: Tue, 15 Jun 2004 13:33:32 +0100

>>>>> "Olaf" == Olaf M Kolkman <[email-masked]> writes:

    Olaf> Note also that reading "special case" does not change my
    Olaf> argument that the only name for which X NSEC X can exists is
    Olaf> for X==@.

I agree that the question is academic if X NSEC X is only allowed at
the apex.

    -roy

---

From: Edward Lewis <[email-masked]>
Date: Tue, 15 Jun 2004 09:39:50 -0400

I think there are three ways to treat X NSEC X, X != @...

1) It follows the rule for serial arithmetic of names, in line with @ 
NSEC @, and hinted at by the docs.  (*Hinted*)

   -- but then X NSEC X implies @ does not exist, which we know isn't true

2) It is a special case of the NSEC span saying that "I declare nothing about
the rest of the zone."

   -- but this is not congruent with @ NSEC @, and this makes it a special case

3) Disallow it except at the apex

   -- this makes it a special case

(Did I leave anything out?)

It looks like we're caught between a non-sense place and a special 
case (again).

(Why are we trying to solve this again?)

Perhaps, looking at #1, we aren't really dealing with "serial name 
arithmetic" after all.  I had always assumed we were, going back to 
drawings I made in the 90's of the "NXT ring."  If not, then "NSEC @" 
is just a special case of indicating "until the end of the zone."

If "NSEC @" is the special case of "the end", X NSEC X makes no 
(semantic) sense and probably shouldn't be accepted on input (load, 
update) to an authoritative server.

---

From: David Blacka <[email-masked]>
Date: Tue, 15 Jun 2004 09:49:33 -0400

On Tuesday 15 June 2004 4:37 am, Olaf M. Kolkman wrote:
> > i asked this in an earlier message but it was lost in the haze of a
> > larger discussion.  here are two NSEC RRs, more or less.
> >
> > there are two visible differences between them: one says there's an SOA
> > and NS at the ownername (@), the other does not (X).   and one's owner
> > and target names are "@" (the zone apex) and the other's owner and target
> > name is "X" (not the zone apex).
>

> special cases->special treatment->new corner cases->more delay.

I will note that -protocol-06 is missing language for handling this last 
record NSEC case.  From -protocol-06, section 5.4:

   o  If the requested RR name would appear after an authenticated NSEC
      RR's owner name and before the name listed in that NSEC RR's Next
      Domain Name field according to the canonical DNS name order
      defined in [I-D.ietf-dnsext-dnssec-records], then no RRsets with
      the requested name exist in the zone. 

(This is the first sentence of the second bullet in this section.  I couldn't 
find any other more relevant text in the draft).

This may present an Opportunity to define the interpretation of this case of 
NSEC records in a way advantageous to a "white lies" strategy.  Or perhaps 
not.

-- 
David Blacka    <[email-masked]> 
Sr. Engineer    VeriSign Applied Research

---

From: Roy Badami <[email-masked]>
Date: Tue, 15 Jun 2004 16:30:04 +0100

>>  I disagree that it is unambiguous.  It is perfectly possible
    >> to read the above paragraph as indicating that the last NSEC
    >> record in the zone is a special case.

    Olaf> Sorry Roy, I do not see an ambiguity.

Ok, the two interpretations I see are:

1. The Next Domain Name field _normally_ contains the owner name of
   the next RRset in canonical ordering.  But the paragraph you quote
   overrides that, and says that in the case of the last owner name in
   the zone, the Next Domain Name field contains the apex name (by
   implication _instead_ of containing the next owner name).  There is
   hence no implication that the apex actually _is_ the next owner
   name in canonical ordering.

2. The Next Domain Name field _always_ contains the owner name of the
   next RRset in canonical ordering.  Therefore by stating that the
   Next Domain Name field contains the apex name, you implicitly state
   that the apex is the next name in canonical ordering.

As you point out, the distinction is immaterial unless it is deemed
meaningful to have X NSEC X where X =/= @ (or X NSEC Y where Y
precedes X in canonical ordering but Y is not @).

    Jim> In that case, please contribute text that clarifies your
    Jim> perceived ambiguity.

It's not clear that there's a need, or that there is consensus as to
which of the two above interpretations is desired...

      -roy

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Tue, 15 Jun 2004 17:29:47 +0200

On Tue, 15 Jun 2004 09:49:33 -0400
> NSEC records in a way advantageous to a "white lies" strategy.  Or perhaps 

Other angle into the discussion, it is indeed getting a little
academic. Given that you would want to use X NSEC X for 'white
lies'. Do you need changes to DNSSEC-bis?

The question is what to do, following DNSSEC-bis when you receive an X
NSEC X whith a signature that is not generated with a key X DNSKEY but
with a key Y DNSKEY where Y is closer to the root.

Can you verify that record? Sure, if there is no DS (or an NSEC RR
that proves its nonexistence) between Y and X you can use signatures
generated by Y. There is a valid chain of trust. But the record would
also tell me, strictly speaking there are no subdomains below X.

Two things I had to think of.

= Caching of NSECs

Think of the other thread on protocol-06 section 4.5 where we are
trying to be as liberal as we can with respect to reuse of cached NSEC
records. There we say that if you re-use NSEC RRs to proof anything
about other names than for the <QNAME, QCLASS, QTYPE> you orriginally
queried for you are in for problems (it is SHOULD NOT language).

In other words you should not reuse the X NSEC X to proof the
existence of Z in a subdomain of X. The specs are fine.

= Replay attack.

Can an attacker abuse the parental X NSEC X in a replay attack against
a resolver querying for a subzone of X.

( foo.co.uk NSEC foo.co.uk exists in co.uk
 
  www.foo.co.uk exists and is secured. 

   client queries for www.foo.co.uk 

   client receives a spoofed NXDOMAIN 
   with foo.co.uk NSEC foo.co.uk 
                  DNSSIG by co.uk
 )

In theory this spoof would work with DNSSEC-bis. But we have a hook to
deal with it. You can tell from which side of the delegation point the
NSEC RR was received. That is you can make a distinction between white
lies and authoritative non-existence of subdomains by looking at the
SOA bit in the NSEC type bitmap.

So you have to specify the white lie as a special case in order to
prevent a replay attack.

Something like
   Validators receiving "X NSEC X" records MUST only use these records
   for the nonexistence of names below X if the SOA bit of the NSEC RR
   bitmap is set.
will need to go into the specs.

I think this means that 'white lies' cannot be deployed withouth a
change to DNSSEC-bis. Is the change you would need significant enough
in terms of security analysis, code changes, etc to try and _not_
persue it (?).

-- Olaf
   No Hats

---

From: Edward Lewis <[email-masked]>
Date: Tue, 15 Jun 2004 11:56:05 -0400

>    that the apex is the next name in canonical ordering.

I agree with Roy's point here.  As much as I liked the idea of serial 
number arithmetic rules applying, we know there's an exception 
because the apex exists.  Therefore trying to apply serial number 
principles is not correct.

>which of the two above interpretations is desired...

What I like about Roy's presentation is that he stresses "_normally_" 
and "_always_".  The only reason that we are talking about this is a 
proposed contortion of the intent of the record to retro-fit in a new 
requirement.

The ambiguity isn't the problem, it's the contortion that's the issue.

I think the problem isn't the specifications.  The problem is that we 
are trying to "lie" with NSEC's to achieve obfuscation, something the 
NSEC wasn't built to do originally.

Tying threads together, I think it's more promising to define what a 
verifier does to proto != 3 keys and then leave obfuscation (name 
hiding) to something in proto = 4 of DNSSEC that is designed to do 
just that.  I think that's more promising than trying to haggle over 
the meaning of "X NSEC X."

---

From: David Blacka <[email-masked]>
Date: Tue, 15 Jun 2004 12:08:29 -0400

On Tuesday 15 June 2004 11:29 am, Olaf M. Kolkman wrote:
> > (This is the first sentence of the second bullet in this section.  I
> > couldn't find any other more relevant text in the draft).
> >
> > This may present an Opportunity to define the interpretation of this case
> > of NSEC records in a way advantageous to a "white lies" strategy.  Or
> > perhaps not.
>

I personally have no stake in the 'white lies' scheme.  I merely pointed out 
that there might be an opportunity to add some language here that might make 
it easier to do.

To be clear, though, I *do* believe that language needs to be added to
section 5.4 to handle the X-NSEC-@ case.  Whether or not this language
allows for things like X-NSEC-X is up to the WG.  The default should
be in the spirit of 2535, however, like:

  If the requested RR name would appear after an authenticated NSEC
  RR's owner name and before the name listed in that NSEC RR's Next
  Domain Name field according to the canonical DNS name order defined
  in [I-D.ietf-dnsext-dnssec-records], then no RRsets with the
  requested name exist in the zone.  Or, if the Next Domain Name field
  is the zonename (thus indicating that the NSEC's owner name is the
  last name in the zone's canonical ordering), then if the request RR
  name would appear after the NSEC's owner name, no RRsets with the
  requested name exist in the zone.

That might be a bit too clumisly said, however.

---

From: Roy Badami <[email-masked]>
Date: Wed, 16 Jun 2004 02:26:12 +0100

>>>>> "David" == David Blacka <[email-masked]> writes:

    David> To be clear, though, I *do* believe that language needs to
    David> be added to section 5.4 to handle the X-NSEC-@ case.

As someone coming to these documents (relatively) anew, I agree that
from an editorial point of view -protocol should mention this too
(perhaps in 5.4 or probably in 2.3)

The instruction in -protocol 2.3 to refer to -records for a precise
description is not entirely helpful given -records section 4 instucts
the reader to refer to -protocol for a precise description.  I realize
that between the two documents they contain a complete description of
what the NSEC records in a signed zone should contain, but it really
shouldn't be this difficult for the reader...  If it's going to be all
done by cross-references it should at least reference a section rather
than an entire RFC...

If the WG concensus is that the DNSSEC design is based on the idea of
a circular canonical ordering, then I think it would be helpful to
state so in -records section 6, too.

The end-of-zone behaviour is currently hidden away in a seemingly
throwaway remark in -records 4.1.1.  I think this would be confusing
to anyone coming to DNSSECbis who hadn't read RFC2535...

       -roy