Re: Summary RE: DNSEXT WGLC: DNSSEC Opt-in

[David Blacka <davidb@verisignlabs.com>]

On Thursday 13 February 2003 12:45 pm, Ted Hardie wrote:

> Note that David and Rob's reply dealt with the issues around section
> 3.1.1.  I have seen no replies about the concern raised about
> section 7 (more explicit text on the interaction of opt-in and
> NXDOMAIN).  I know Roy has done some pretty extensive thinking on
> it, but that is not yet in the draft.  Others may disagree that it
> is needed, but no one said so explicitly.

I haven't forgotten your concern, Ted.  I haven't commented on it yet
because I haven't thought about it enough.

> The workshop reports also indicated that the document didn't agree
> with implemented behavior in regards to NXT and needed to recommend
> against dynamic update;

Yes, I am aware of these issues as well.  I apologize for not having
posted an open issues list to namedroppers by now (see the end of this
message, however, for one).

At this point, however, I do not believe recommending against dynamic
update with Opt-In is correct.  I don't think there is a real conflict
between them.  But dynamic update should be mentioned in the draft.

> There was also the discussion among Rob, Johann, and Michael about
> the need to rev NXT (and possibly SIG and KEY) to make the current
> infrastructure distinguishable from the previous infrastructure.  I
> didn't say a resolution to this (though I may have missed it in a
> thread permutation).

This issue is totally orthogonal to Opt-In.  I think you haven't seen
a resolution to this issue because there hasn't been one.

> There are two possible outstanding editorial issues concerning
> section 7 >and section 3.1.1 but these are not rated as being
> significant enough to >prevent progress of the document.  Please add
> the dynamic update and NXT issues to this list.  I'm most concerned,
> obviously, about the mismatch between tested implementations and the
> spec on the NXT issue.

The workshop summary was somewhat unclear on the NXT issue.  It is far
from a major one.  Essentially the draft forbids sending the negative
wildcard proof NXT when sending an NXDOMAIN response.  We had two
server implementations for opt-in: one which sent the negative
wildcard proof and one that didn't.  Both worked.  So the draft is
using a MUST when it should be using either SHOULD or MAY.  This was
actually suggested by Ed Lewis before the publication of the -04
version but got missed somehow.

> >So the question for the chairs is what do we do next?
> 
> Speaking personally, I think the authors should rev the docs to fix these
> spec bugs.

I, as one of the authors, agree.  I believe that the other authors
(Mark and Roy) also agree.

To summarize the "spec bug" issues list that I am aware of:

  * change the MUST NOT send negative wildcard proof to a SHOULD NOT
    or MAY NOT (or some other language that means the same thing).

  * Clarify opt-in behavior wrt dynamic update.  (although I'm not
    sure what the clarification should say).

  * In section 3.1.1, make it clear that a violation results in a
    validation error.

  * Various additional warnings and comments to be placed in the
    Security Considerations section.  This includes:

    o something about NXDOMAIN (although I'm not sure what needs to be
      said about this).

    o some additional description of domain hijacking possibilities
      (asked by Paul Vixie during the Atlanta dnsext meeting).  From
      the minutes:
    
      There was a comment that security section needs stronger
      language, Clearly list the need for zone transfer protection and
      risk from zone hijacking of opt-outed delegations.  Authors
      agreed examine if the current text is insufficient .

Anything else?

I'd like to point out that none of these proposed changes should
affect existing implementations in any way.
-- 
David Blacka    <davidb@verisignlabs.com> 
Sr. Engineer    Verisign Applied Research


--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>