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

From: Ólafur Guðmundsson <[email-masked]>
Date: Thu, 13 Feb 2003 12:54:49 -0500

At 12:10 2003-02-13, Hallam-Baker, Phillip wrote:
>There were 27 messages in this thread from 10 distinct individuals.

Thank you for your summary, I'm working on my own, but you are absolutely
correct there was strong showing of support for technical description
of OPT-in.
Expect the follow up WGLC to start this week.

         Olafur

--
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: David Conrad <[email-masked]>
Date: Thu, 13 Feb 2003 10:30:29 -0800

Hi,

On Thursday, February 13, 2003, at 09:10  AM, Hallam-Baker, Phillip 
wrote:
> Q: Is the description in the document of Opt-In complete ?

It would likely be the first RFC in the history of the IETF if it 
were... :-)

> Q: Are there implementations of opt-in and have there been any tests ?
> 	Nordmark - Does this mean that there is a caching resolver
> 		implementation that has been tested?

To be clear:

Nominum has a delegation only opt-in validator implementation in our 
proprietary caching server.  The same person who wrote the opt-in 
validator for our prorietary server (Brian Wellington) also wrote a 
delegation only opt-in validator for BINDv9, but I'm not sure if that 
code has been incorporated into BIND.

Has anyone else written a validator that supports opt-in?

> 	Conrad - To be perfectly honest, I no longer care

Out of context.  I do care that a decision is made, I just no longer 
care what that decision is.

Rgds,
-drc

---

From: David Blacka <[email-masked]>
Date: Thu, 13 Feb 2003 14:27:10 -0500

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    <[email-masked]> 
Sr. Engineer    Verisign Applied Research

---

From: Ólafur Guðmundsson <[email-masked]>
Date: Fri, 14 Feb 2003 12:48:47 -0500

At 12:45 2003-02-13, Ted Hardie wrote:
>At 09:10 AM 2/13/2003 -0800, Hallam-Baker, Phillip wrote:

>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;
>here's the text from the report:
>
>           * specification issues
>          - draft & implementation behavior WRT NXT is different,
>          probably draft needs to change, on inclusion of negative
>          wildcard proof in the answer (draft says MUST NOT, code does
>          it, it's probably harmless, draft should say MAY)

this is a minor change, and wildcards in DNSSEC are a smaller issue
now than 2 months ago see
http://www.ietf.org/internet-drafts/draft-lewis-dns-wildcard-clarify-00.txt

>          - insecure delegation with opt-in NXT is semantically
>          ambiguous, useless, and doesn't work (SERVFAIL)
>          - draft should mention dynamic update behavior. It should
>          caution against dyanmic update with opt-in.

There is (IMHO) no need to outlaw dynamic update in opt-in zone, but
there are some extra rules that are needed as well as update to
RFC2136.
This could be accomplished by a separate document while the
Opt-in document only says dynamic update of opt-in zones is unspecified.

In the following discussion updates to zone APEX are ignored as
they do not change at all.
Nit: Some of the confusion in the document results from inconsistent
terminology. The document seems to use the words "unsigned delegation" and
"unsecure delegation" interchangeably. That is not the case, in my mind
there is a difference between the two.
Unsecure delegation: A delegation without DS record.
Unsigned delegation: A delegation without DS but with a signed NXT.

If the working group concludes that the second is not allowed it does not
change the contents below.
In the text below I will only use the terms [un]signed name.
More terms:
         Local NXT == nxt with the same name as the update
         Previous NXT == NXT at the signed name lexicographically preceding
                         name updated.

For completeness all possible operations are included, in a delegation
only Opt-in case some operations do may change the signed status
as there only one RRset can be unsigned.
At unsigned names deleting the only RRset it is equivalent
of deleting the name.
Only DS RRset can be added to a delegation but that forces signing
of the node.
Note: NO == Does not change the contents of field
       YES == Contents of field changes, requires resigning this record.

                                               NXT  name
                                           local         previous
    case:updating signed name          Bitmap   Name   bitmap  name
         Modifying existing RRset        NO      NO      NO     NO
         Adding a RRset                  YES     NO      NO     no
         Deleting a RRset                YES     No      no     no
         Deleting a name                 NO      NO      no     YES
         Adding a name                   YES     YES     NO     YES

    case: updating unsigned name
         Modifying existing RRset        NO      NO      NO      NO
         Adding a RRset                  YES     YES     NO      YES
         Deleting a name/RRset           NO      NO      NO      NO
         Adding unsigned name            NO      NO      NO      NO

If a delegation can be signed without a DS RRset then the following
apply:
Changing security status of a delegation via Dynamic update
is not obvious and a special rule needs to be made up OR this
is done via server policy somehow.  This adds two cases
to the tables above.
    case: updating signed name
         Changing to unsigned           DELETE            NO      YES

    case: updating unsigned name
         Changing to signed             YES      YES      NO      YES

>didn't say a resolution to this (though I may have missed it in a thread
>permutation).
>

DS + OPT-in is a flag day, and the question is IF/HOW to signal this inside
the protocol, the options are
         do nothing,
         use a new ENDS0 flag to replace DO,
         change type code for NXT
         change type code for NXT SIG and KEY.

The reason against doing nothing is that some implementations really do not
like the NS  + NXT in authority section as specified in DS document.
This is a problem resulting from an under-specialization in RFC2535 as to
when NXT can appear in authority section. The implementation problem is
NXT specific. The advantage changing the NXT type code is then we have a
clean break with 2535 resolvers as they will not understand the new type
and the special processing that Opt-in and DS require.
In my mind there is no need to renumber SIG and KEY.

>                                 regards,

Speaking as a co-chair of DNSEXT:
After reading all the comments received and re-reading the document
it is clear to me the document needs updating before the next
last call can start. I will be working with my co-chair and the authors
on creating a list of changes and clarifications needed.
Thus the last call can not start until sometime next week.
         Olafur

---

From: Brian Wellington <[email-masked]>
Date: Fri, 14 Feb 2003 13:48:21 -0800 (PST)

> There were 27 messages in this thread from 10 distinct individuals.

I can't speak for anyone else, but I have problems with your analysis.
> 
> Q: Does this document satisfy people as being implement able and
> testable
> specification ?
> 
> Answers:
> 	Kosters - Yes  [detailed response]
> 	Loomis - I believe that the specification can be implemented and
> tested.
> 	Wellington - i believe that the current version of the
> specification 
> 		is complete.

I'm pretty sure I never said that.  I have implemented opt-in, but am most 
definitely not sure of its correctness and whether I missed any corner 
cases.

> Answers:
> 	Kosters - Yes [detailed response]
> 	Austein - asked about resolver side implementations
> 	Arends - Yes, Verisignlabs and ISC have auth.server
> implementations, 
> 		ISC has a resolver implementation.
> 	Arends - I don't have material on how thorough the caching
> resolver 
> 		implementation has been tested.
> 	Wellington - yes.

There are two questions here, and 'yes' implies yes to both.  Yes, there 
are implementations.  No, I have never tested them and do not know the 
results of any tests that have been performed.

> In addition there were responses on the question of advancement
> 
> 	Hallam-Baker - It should advance
> 	Vixie - dunno.  but in any case i am strongly in favour of it
> 	Wellington - yes.  (notes to be posted here shortly, so they
> tell me.)

You've got to be kidding me.  I have never supported the advancement of 
opt-in.  I don't know what notes these are, since I haven't publicly said 
anything about opt-in in the last 6 months.

Check your facts before putting words in other people's mouths.

Brian