Subject: RE: NSEC version field (Re: NSEC2- and an Authenticated Denial M echanism Flag)

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 28 May 2004 12:41:11 -0700

> If this method is being used, then, v2 using zones will 
> appear to be unsigned 
> to v2 unaware resolvers.  There would be no way for a "V1 
> resolver" to check 
> a "V2 zone".  Signing with both known and "unknown" 
> algorithms would cause 
> the zone to just be broken.

Could we maybe as a compromise agree now that the only difference
between v1 and v2 will be that in v2 a new versioned NSEC 
record would be used?

We do not make any changes to the DNSSECbis document set at all.

We write a new short note that says that the V2 identifier is
reserved for servers that support NSEC-V, the versioned variant
of NSEC.

At that point it is possible to start deployment of DNSSEC
aware 'stuff' even though we do not have the new NSEC record
defined. That 'stuff' can also make partial use of information
from a V2 zone, even though there will be certain attacks that
are still possible.

This compromise would mean that we can go ahead and start 
deployment on the original schedule. The only difference 
would be that .uk and .de would start deployment using the 
V2 identifier and they would have to wait until we define
NSECV before they can publish any form of NXT.

Worst case this would mean that we burn a version identifier.
I think we can live with that.

We also get early experience of transitioning the system
and code has to be written with this in mind. So far I have
avoided comment on the NSEC2 proposal itself. I cannot believe 
that is going to be the final answer either.

		Phill

--
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: Edward Lewis <[email-masked]>
Date: Fri, 28 May 2004 18:06:34 -0400

>between v1 and v2 will be that in v2 a new versioned NSEC

I don't think there's been an agreement that there ought to be an 
answer to zone enumeration.  I've been analyzing the possibility of 
1) allowing there to be a way forward and 2) adoption of the NSEC2 
proposal in case we decided this is to be pursued.

I'm not convinced that we need to defend against zone enumeration. 
I'm all for providing this if it were easy to accomplish.

I have yet to see a way to provide a seamless way to convert from 
NSEC to another approach to authenticated denial (for any purpose). 
(Hmmm, perhaps detailing what happens if the NSEC claims that it 
itself doesn't exist - but that's been tried before and failed.)

I think that the NSEC2 is capable of obfuscating the zone's contents, 
but can do so only at a greater cost.  This cost can be gamed by the 
client and has the potential to be rather high.

I'd put my opinions this way - if providing a way forward were easy 
and/or if providing obfuscation was cheap to do, I'd be for it.  But 
from the work I've done, the costs to do either seem to be rather 
high, meaning that there has to be a lot of need to provide them.

>reserved for servers that support NSEC-V, the versioned variant

What is the V2 identifier?

>Worst case this would mean that we burn a version identifier.

There's no version identifier in the current definition of DNSSECbis, 
one of the  premises was to this proposal was that there would be no 
need to change the documents.

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

Even the voices inside my head are refusing to talk to me anymore.

---

From: Paul Vixie <[email-masked]>
Date: Sat, 29 May 2004 06:10:33 +0000

> ...

i have a similar conclusion, which is that if we want NSEC to be
upgradeable then it's going to take (at least) some period of time to
find out whether it already is, which will take some modelling.  if it's
not already upgradeable, then it'll take some additional period to
decide how to make it so, which should include competing alternatives,
independent modelling/analysis/review, prototyping, and testing.

i'm calling the first period six weeks, since i know how namedroppers
works.  it could be longer, since it's coming up on summer in a lot of
places, and a lot of namedroppers children will be out of school, and
there will be some vacations.

if there is a second period (see above) then NSD 2.0 will become
out-of-date, and BIND 9.3.0 (now in beta testing but maybe in release
candidacy or actual release by that time) will become out-of-date, and
then the second period is probably around four months, maybe longer
since it will overlap with end-of-year holidays.

since we know that we can push out replacement dnssec technology by
using different type codes for it and changing the time scale from
months to years, it is my hope that on june 1 when WGLC ends, the
chairs will recognize that the dnssec-bis docset appears to meet its
design goals and appears to have adequate document quality and adequate
protocol quality, and forward the documents to IESG for publication.

and then, depending on funding and other resources, this WG can start
work on a DNSSECv2 that uses different type codes to operate "like ships
in the night" with DNSSECv1 and can take a year or even longer to ensure
that its design matches the community's then-current requirements and
that it is implemented straightforwardly and that deployment considerations
are known and handled from day 1.  it can even share/reuse keys, and could
have a gateway back to DNSSECv1.  but it would not be "DNSSECv1 with
versions", since the time between now and when we'll know whether that's
possible is longer than many of us want to wait.  and because DNSSECv1
appears to have achieved its design goals, which did not include 
confidentiality.

---

From: Paul Vixie <[email-masked]>
Date: Sat, 29 May 2004 06:10:33 +0000

---

From: Greg Hudson <[email-masked]>
Date: Sat, 29 May 2004 20:50:15 -0400

On Sat, 2004-05-29 at 02:10, Paul Vixie wrote:
> find out whether it already is, which will take some modelling.

It seems like, at the very least, it should be possible to rev all the
DNSSEC record types, such that zones signed with DNSSECtre (which
somehow magically solves the enumeration "problem" with compromising
something equally important) appear unsigned to DNSSECbis-only
resolvers.

This plan might present an upgrade impediment to zones signed with
DNSSECbis; they might have to choose between providing twice as much
data or appearing unsigned to DNSSECbis-only resolvers.  But if the only
reason to upgrade to DNSSECtre is enumeration, then that choice has to
be made anyway (either you didn't deploy DNSSECbis, or you did deploy it
in spite of the enumeration concern, and you won't solve the enumeration
concern without leaving behind DNSSECbis-only resolvers).

---

From: Paul Vixie <[email-masked]>
Date: Sun, 30 May 2004 02:10:41 +0000

> something equally important) appear unsigned to DNSSECbis-only

yes.  this is what we did in TCR to invalidate the universe of RFC2535.

> data or appearing unsigned to DNSSECbis-only resolvers.

it won't be twice as much data.  another EDNS0 option bit will have to
be allocated to say "when i set the i-want-dnssec option, i really mean
dnssec-ter".  middleboxes who havn't cached an answer that was fetched
using this option will go upstream (forward, using this option) and only
data that was fetched using this option will be returned from a middlebox
who is queried using this option.  (that's what RRD and QDCOUNT>0 did in
the original EDNS specification, it was a way of upgrading a hop-by-hop
signalling method to end-to-end, and it would have worked, but we were a
weary and wary group of folks by that point in the EDNS adventure...)

> But if the only reason to upgrade to DNSSECtre is enumeration, then
> that choice has to be made anyway (either you didn't deploy DNSSECbis,
> or you did deploy it in spite of the enumeration concern, and you
> won't solve the enumeration concern without leaving behind
> DNSSECbis-only resolvers).

speaking for bind, i think it would be necessary to support both -bis and
-ter when signing (if that's what the zone operator asks for) and serving.
DNSKEY wouldn't have to rev this time, only RRSIG and/or NSEC.

it's even dimly possible that NSEC2 or RRSIG2 could be generated from NSEC
or RRSIG, assuming that the new ones are subsets of the old, so that a -ter
middlebox could synthesize -ter style responses if it had cached something
from a -bis style response.

the sky's the limit.  as long as, that is, we don't try to do it before -bis.
if we try to do it before -bis, then either -bis is late, or we have some
unfortunate compromises whose sideeffects take a long time to become known,
or more likely, both.  -bis must go as is.  TCR++ is the way to -ter.

---

From: Paul Vixie <[email-masked]>
Date: Sun, 30 May 2004 02:10:41 +0000

---

From: [email-masked]
Date: Mon, 31 May 2004 12:38:46 +0200 (CEST)

> independent modelling/analysis/review, prototyping, and testing.

There are many possibilities to start an upgrade path, versioning and
such. The REAL problem is specifying resolver behaviour when it encounters
an unknown vesion of NSEC. It will introduce numerous cornercases since
NSEC is used in both negative and positive proofs (this is not FUD, there
were some cornercases in the past when we're trying to model opt-in). It
also needs to be tested very well. CAIDA has recently done some modelling
http://www.caida.org/outreach/papers/2004/dnspam/ and one of the
conclusions is that resolvers tend to become aggressive when denied
certain data. Ignoring incompatible NSEC versions is exactly what that is.

Being one of the authors of the docset and knowing how much effort it took
to get here from where we were 4 to 5 years ago, it will be another year
_atleast_ before something as little as an MBZ will make it through. Going
over the docset again, there are many hooks that needs eyes and text in
case the wg decides on versioning. I'm not saying we shouldn't, but before
we get to where we are now with rough consensus and running code,it will
be another two years.

To my frustration, I think we've REALLY missed the bus on NSEC, since
everything from label types to packetsize, from header bits to transaction
signatures _is_ extendable, while a few of the big namedroppers mud-fights
were due to lack of NSEC versioning.

Having said that, my conclusion is to ship the docset now and get some
real experience in userland. A TCR++ degauss of DNSKEY/NSEC in the near
future can introduce a version scheme for NSEC. That would probably also
take some time, and is bw compatible with DNSSECbis, but at least we can
move forward now.

Roy

---

From: Roy Badami <[email-masked]>
Date: Mon, 31 May 2004 13:02:36 +0100

>>>>> "Edward" == Edward Lewis <[email-masked]> writes:

    Edward> (Hmmm, perhaps detailing what happens if the NSEC claims
    Edward> that it itself doesn't exist - but that's been tried
    Edward> before and failed.)

As far as I can see the current document set _does_ detail what
happens in this case.

-protocol 5.4:

   Since a validated NSEC RR proves the existence of both itself and
   its corresponding RRSIG RR, a validator MUST ignore the settings of
   the NSEC and RRSIG bits in an NSEC RR.

   -roy