[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

At 12:45 2003-02-13, Ted Hardie wrote:

At 09:10 AM 2/13/2003 -0800, Hallam-Baker, Phillip wrote:

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



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







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




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.





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



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