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

From: "Olaf M. Kolkman" <[email-masked]>
Date: Thu, 17 Jun 2004 10:12:22 +0200

In  http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg01033.html
Ólafur Gudmundsson wrote:

 >After reading Paul's Vixie -ter proposal
 >http://psg.com/lists/namedroppers/namedroppers.2004/msg00967.html
 >and  Jakob, Peter and Roy's -trans list of approaches
 >http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-trans-00.txt
 >
 >Please speak up on this question to help chairs gauge consensus.

The question being:
Q: Does advancing DNSSECbis to IESG prevent NSEC-alt in the future?

There has not been enough clear statements, we are looking for
support, please help us out.

We need to be able document that there is consensus that forwarding
DNSSEC-bis does not close the door on NSEC2, NSEC-alt or other methods
denial of existence that prevent zone enumeration.

Please respond either on the mailing list or in a e-mail to both
chairs.

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.
 3. Minor text clarifications brought up.

Issues that are not resolved yet:
 1. Division of flag bits, as proposed by Simon Josefsson
 2. Need for special cases in NSEC records processing for
    white lies/on-line signing.

Speak out if you think these items need or need not be resolved. If
you think these items need to be resolved than contribute with text
that can go into the document. If there is no obvious consensus on
support for these proposals, they will not be taken into account.

We need to move forward. If not, we will not make the cut-off date,
run into the holiday season and it will be mid September before we
have had any progress.

 Ólafur and Olaf 
 DNSEXT Co-Chairs

--
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 Arends <[email-masked]>
Date: Thu, 17 Jun 2004 10:35:58 +0200 (CEST)

>     white lies/on-line signing.

I've just send an alternative for on-line signing that obsoletes the need
for NSEC or similar records. (see mail with rrsig(qname)).

I'd like to keep current NSEC 'clean' of hacks.

Roy

---

From: Roy Arends <[email-masked]>
Date: Thu, 17 Jun 2004 10:37:13 +0200 (CEST)

> Q: Does advancing DNSSECbis to IESG prevent NSEC-alt in the future?

No. It does not preven NSEC-alt in the future.

Roy

---

From: Ben Laurie <[email-masked]>
Date: Thu, 17 Jun 2004 12:54:23 +0100

>     white lies/on-line signing.

It may be worth clarifying in the text, but it isn't clear to me that 
anything special is needed for the @ NSEC @ white lie. My reasoning is this:

a) 4.1.1 states: "The Next Domain Name field contains the owner name of 
the next authoritative owner name in the canonical ordering of the zone"

b) 4.1.1 also states: "The value of the Next Domain Name field in the 
last NSEC record in the zone is the name of the zone apex"

Therefore @ NSEC @ quite clearly means that there are no authoritative 
owner names other than @ in the zone.

X NSEC X where X is not @ is also clearly illegal: X cannot be the next 
authoritative owner name - either there is another name, Y, which comes 
after X, in which case X NSEC Y would be correct, or X is the last name 
in the zone, in which case the record should be X NSEC @.

It also seems to me, unless I'm missing something, that @ NSEC @ will 
come up in circumstances where it is not a lie, for example in zones 
where there is nothing but glue, and all subdomains are not secure. So, 
resolvers had better handle this case without exploding, or there's a 
problem. Again, this might be worth clarifying in the text. We could add 
to 4.1.1:

"Note that a consequence of these rules is that an NSEC record owned by 
the apex of the zone and containing the apex as the Next Domain Name 
indicates that the zone contains no authoritative names other than the 
apex."

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: Edward Lewis <[email-masked]>
Date: Thu, 17 Jun 2004 09:11:43 -0400

I need to re-read -protocol before saying what I was going to say.

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

>  1. Division of flag bits, as proposed by Simon Josefsson

Or the role of the protocol field.  I think Simon's onto something, 
but I think that using the flag bits is too complicated and there's 
that lovely protocol field begging to be used.

>     white lies/on-line signing.

I think the "white lies" thing is an aberration of the protocol.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

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

---

From: "Scott Rose" <[email-masked]>
Date: Thu, 17 Jun 2004 09:40:55 -0400

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Edward Lewis
>

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.

> I think the "white lies" thing is an aberration of the protocol.

I think so too, but having X nsec @ would be perferable, especially since
the spec also forbids cachings from using NSECs to formulate new
non-existence response.

Scott

---

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

> chain.  If the WG desires it to be circular to accomdate something, that is

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

---

From: [email-masked]
Date: Thu, 17 Jun 2004 15:04:18 +0000

> Is the space circular?  I used to think so, but am less convinced now 

	why am i thinking of 802.5 here?

	in general, I beleive that the -bis docset should be
	released. nothing prevents future change from occuring.

--bill

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 17 Jun 2004 17:15:35 +0200

> Q: Does advancing DNSSECbis to IESG prevent NSEC-alt in the future?

I already answered, but as "yes" or "no" sounds more like opinions
than technically motivated answers, here is something I believe would
complicate NSEC-alt in the future if DNSSECbis is advanced.  Section
2.3:

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

The behaviour for when the MUST is not followed, such as if lying NSEC
is used, are not described.  It is conceivable that a validating
resolver treat missing NSEC's for authoritative data in a zone as a
protocol error, and label the zone as bogus, and return SERVFAIL to a
CD=0 client.

Depending on how resolvers implement the above requirement, this might
prevent lying NSEC.

It might simplify migration if the presence of NSEC RR was not a
protocol requirements, but instead the validation logic simply
returned "insecure" (for questions with positive answers) or "bogus"
(for questions with negative answers) when a NSEC is missing.  This
would be a larger change, so I'm not proposing to do this, just that
it can be considered.

Thanks,
Simon

---

From: Rob Austein <[email-masked]>
Date: Thu, 17 Jun 2004 11:25:42 -0400

> Q: Does advancing DNSSECbis to IESG prevent NSEC-alt in the future?

Advancing DNSSECbis does not prevent NSEC-alt in the future.

Plenty of type codes left in the registry.

---

From: Edward Lewis <[email-masked]>
Date: Thu, 17 Jun 2004 11:33:56 -0400

>Plenty of type codes left in the registry.

My concern is "how burned" will DNSSECbis installations be when 
DNSSECbis++ comes out.  (That's why I need to reread -protocol.)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

---

From: Rob Austein <[email-masked]>
Date: Thu, 17 Jun 2004 12:13:33 -0400

[Subject changed to avoid cluttering chairs' query thread]

> DNSSECbis++ comes out.  (That's why I need to reread -protocol.)

They wouldn't be burned at all by a full TCR.  They wouldn't be part
of the DNSSECter universe until they upgrade to software that
understands DNSSECter, but that's the way the bagel bends.  See the
definition of "Proposed Standard".

When considering the arguments for and against full TCR, note that, in
principle, it is not strictly necessary to have multiple keys for each
trust anchor simply because one has multiple KEY-like RR types.  That
is, one might choose to present the same keying material in more than
one KEY-like RR type, so long as the only significant difference
between the RR types were the RR type code itself.  Whether this
approach would allow us to simplify the trust anchor problem during a
hypothetical migration from DNSSECbis to DNSSECter remains to be seen,
but I suspect that it would at least be worth investigating.

---

From: David Blacka <[email-masked]>
Date: Thu, 17 Jun 2004 12:26:02 -0400

> Q: Does advancing DNSSECbis to IESG prevent NSEC-alt in the future?

Well, we certainly know *a* way to implement NSEC-alt in the future.  What I 
am concerned about is that we don't know if that way is the "best" way.

I think we would be doing ourselves a disservice if we do not try to 
understand the pros and cons of a number of different transition strategies 
before submitting the DNSSEC-bis documents to the IESG.

In my mind, the central property of a transition mechanism is that it is able 
to protect "legacy" validators from non-backwards-compatible changes to 
DNSSEC.  I believe that a full typecode rollover would fulfill this 
requirement, but so would other, possibly less onerous mechanisms.  And these 
other mechanisms might require some minor language changes.

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

---

From: Edward Lewis <[email-masked]>
Date: Thu, 17 Jun 2004 14:11:37 -0400

>but I suspect that it would at least be worth investigating.

I'd like to agree, but I have a nagging suspicion.

On the one hand there is the point about what Proposed Standard 
means.  In that case, rolling to new versions is a non-issue.

Trusted keys for islands "deep" in the zone I suspect are easily handled too.

It's "what if there's a DNSSECbis key for the root" or some other top zone?

Maybe - what if we discourage a key from being distributed 
(operationally) for the root until we get to Draft Standard?
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

---

From: Paul Vixie <[email-masked]>
Date: Thu, 17 Jun 2004 19:18:52 +0000

> Maybe - what if we discourage a key from being distributed (operationally)
> for the root until we get to Draft Standard?

semantically, that boils down to "dnssec-bis is not dnssec, use it for
small experiments only, we'll have -ter for you in a year or two."

let's be very careful about actually making statements equivalent to that.
(the above is only a proposal, not a statement, so we're ok so far... but
the day is young.)

((herding cats would be easier.  this is like trying to get a bunch of
puppies into a bag, without a twist-tie and without rocks.))

---

From: Russ Mundy <[email-masked]>
Date: Thu, 17 Jun 2004 18:55:41 -0400

At 10:12 AM +0200 6/17/04, Olaf M. Kolkman wrote:
---------------------------------- snip ---------------------------------
>Q: Does advancing DNSSECbis to IESG prevent NSEC-alt in the future?

No, advancing these now does NOT prevent NSEC-alt (or other changes) in the
future.

Folks that use implementations of RFC's that are Proposed Standards should
expect to have the specs change.  I now have one signed zone operating with
a currently available implementation and would like to field additional
signed zones to have more operational experience.  I also have some good
sized customers that have a signed zone experiment underway and these users
would very much like to see DNSSECbis get published as RFCs.

>support, please help us out.

Certainly will.

I would very much like to see the DNSSECbis go forward now (sooner as
opposed to later).  Folks that I know who want to use this now want to do
so even if they need to make some changes later.  It's not easy to make
some changes but others come more or less for 'free' with the normal
upgrade of new software so even though some future changes may be needed,
they would much rather have DNSSECbis go to RFCs sooner rather than later
(even if change is needed later).

>denial of existence that prevent zone enumeration.

I don't know of any reason why publishing DNSSECbis would close that door
nor have I seen any convincing description of one on the list.

Additionally, changes to specs at the Proposed Standard level should be
consider 'normal' per the established IETF standards process (per para
4.1.1, BCP-9/RFC-2026).  Although the focus of much of the WG discussion
lately has been on possible changes to NSEC, operational use of
implementations of the current specs may well identify other changes that
will need to be incorporated.  This should be viewed as normal and a
feature of the IETF process (BCP-9/RFC-2026) - we should use the 'feature'
not fight it.  We (the working group) should make well engineered,
intelligent choices for the current specifications to allow for future
change but potential requirement(s) for future change should _not_ keep the
current specifications from moving forward.

> 3. Minor text clarifications brought up.

This is a Good Thing.

>    white lies/on-line signing.

Publish what's ready now, work these requirement/issues in the WG and
publish RFCs as needed to update (change) in the future what needs to be
published now.  After all, the specs are at the Proposed level where
(according to BCP-9) change should be expected.  If it turns out that
changes are not needed, then we're that much closer to being able to
advance things to the Draft level.

>support for these proposals, they will not be taken into account.

I certainly agree that there is not a consensus on how to resolve the two
issues identified above but I also think that we should forward the
documents to the IESG as soon as the listed clarifications are completed.
As long as we are committed to address these issues (and others that might
arise) in a reasonable time-frame, individuals with concerns about
identified issues should be able to expect the WG to address them and
develop changes that might be required in some reasonable time period - the
real key being 'reasonable time period'.

>run into the holiday season and it will be mid September before we

Russ

---

From: [email-masked] (Geoffrey Sisson)
Date: Fri, 18 Jun 2004 02:19:02 +0100 (BST)

> Q: Does advancing DNSSECbis to IESG prevent NSEC-alt in the future?

A:

I'm persuaded that -ter represents a viable roadmap to NSEC-alt, so I
now think the DNSSECbis docset can go to the IESG without the
introduction of any version/MBZ fields.

Roy's rrsig(qtype) proposal looks promising and, unless any killer
corner cases are found, I would favour changes to the DNSSECbis docset
which would make this option available to anyone who might want/have to
do on-the-fly signing.  This should not be interpreted to mean that
Nominet might not still use NSEC white lies.

Regards

Geoff

---

From: Edward Lewis <[email-masked]>
Date: Thu, 17 Jun 2004 22:33:32 -0400

>small experiments only, we'll have -ter for you in a year or two."

That struck me too as I sent it.

>(the above is only a proposal, not a statement, so we're ok so far... but

'Zactly.

Given experience, it's probably wise to just say "here is the spec" 
and let the community figure out what to do (or not) with it.

Right now I kind of like using the proto field of the DNSKEY to 
"signal" a new method, recognizing there are other approaches out 
there.  Given the tenor that this is just a Proposed Standard and all 
that it entails, I think we might as well push the docs as they are.

---

From: Russ Mundy <[email-masked]>
Date: Thu, 17 Jun 2004 18:55:41 -0400

---------------------------------- snip ---------------------------------

Certainly will.

This is a Good Thing.

Russ

---

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.