Subject: Section 4 of dnssec-protocol-03

From: Mike StJohns <[email-masked]>
Date: Thu, 30 Oct 2003 12:36:28 -0500

Comments:

Section 4, page 20.  "Trusted starting point".  A more precise term might 
be "trust anchor".

Page 20, para beginning "A security-aware resolver..." delete  "MUST be 
capable....key, and" - the latter clause includes the meaning of the 
indicated clause.   Add at end of para "However, such mechanisms are out of 
scope for this document."

And the meat of the matter:  Would it make sense to add a second bit 
mirroring the DO bit to indicate a new DNSSEC query rather than an old 
DNSSEC query?   DO would indicate an old DNSSEC query, DX would indicate a 
new query.  E.g. how do we handle the legacy case?  *sigh*

Mike

--
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: "Scott Rose" <[email-masked]>
Date: Thu, 30 Oct 2003 13:27:26 -0500

----- Original Message ----- 
From: "Mike StJohns" <[email-masked]>
> new query.  E.g. how do we handle the legacy case?  *sigh*

The typecode draft/RFC (hopefully soon) discussed that idea.  Servers and
resolvers are supposed to ignore pre-DS DNSSEC RRs and not use them.

It would also be good not to condone a "dual world" DNSSEC.  One with
KEY/SIG/NXT and one with the new typecodes.  Right now, RFC2535 security
aware resolver wouldn't be able to verify the RRSIGs, but would not be able
to follow secure delegations anyway (DS RR).  Having the option of allowing
"2535" DNSSEC means there would have to be the same 2535-DNSSEC security
chain with parent SIGs in the child zone.

Basically, there is not a lot of danger in just ignoring the legacy case.
DNSSEC is not widely deployed to warrent a lot of backwards compatibility.
Scott

---

From: Mike StJohns <[email-masked]>
Date: Thu, 30 Oct 2003 16:03:25 -0500

>resolvers are supposed to ignore pre-DS DNSSEC RRs and not use them.

Actually, I think the issue is pre-DS security aware stub resolvers talking 
to post-DS resolvers or vice versa.  As it stands, a pre-DS aware resolver 
setting the DO bit can get post-DS answers that it doesn't have a clue of 
how to use.

>DNSSEC is not widely deployed to warrent a lot of backwards compatibility.

I think I mostly agree with this.  On the other hand, we changed all the 
type codes to prevent problems with legacy systems - might it not make 
sense to make the hard separation include stub to recursive resolver 
signalling?  Its one bit in the EDNS0 header.

---

From: Rob Austein <[email-masked]>
Date: Thu, 30 Oct 2003 16:31:20 -0500

At Thu, 30 Oct 2003 16:03:25 -0500, Michael StJohns wrote:
> ...

I don't feel strongly about this, but here's my take, for what it's
worth.

The primary purpose of the DO bit is to keep old buggy code from
dumping core upon seeing DNSSEC records (by keeping said buggy code
from ever seeing DNSSEC).  I have not seen this happen myself, but
I've been assured that this was a real problem for some old buggy
implementations.  Nobody ever claimed that this was anything but
broken behavior on the part of the old code, but it was a real
operational problem that stood in the way of deployment, and this
seemed the least bad answer to it.

The situation with pre-DS and post-DS DNSSEC is not analagous, unless
somebody steps forward to claim that there's code deployed now that
will is ok with pre-DS DNSSEC but dumps core upon seeing post-DS
DNSSEC.  While I suppose that's possible, it seems less likely, and I
haven't heard anybody make such a claim.

So I conclude that we probably don't need another bit.

---

From: Paul Vixie <[email-masked]>
Date: Thu, 30 Oct 2003 22:55:42 +0000

> So I conclude that we probably don't need another bit.

<AOL>
Me, too!
</AOL>

---

From: Samuel Weiler <[email-masked]>
Date: Fri, 31 Oct 2003 16:28:44 +0100 (CET)

On Thu, 30 Oct 2003, Mike StJohns wrote:

> ... we changed all the type codes to prevent problems with legacy
> systems - might it not make sense to make the hard separation
> include stub to recursive resolver signalling?  Its one bit in the
> EDNS0 header.

I find it interesting how questions that have been discussed at
length, including in last-called and IESG-approved documents (albeit
ones not yet out of the RFC editor's queue), keep getting raised.

See section 2.3 of the TCR draft, which went to IETF last call on July
16th and was approved for publication on 21 August.  If the standards
process is letting documents through with too little review, then we
have bigger problems than a header bit will fix.

-- Sam