Re: Wrap-up trustupdate timers

[Mike StJohns <[e-mail]>]

I'm working on the editorial changes I agreed to in previous 
messages, but... see below.



At 02:33 PM 11/21/2006, Olaf M. Kolkman wrote:



>Dear colleagues,
>
>We have reviewed the comments received during the last call for
>draft-ietf-dnsext-trustupdate-timers-04
>
>
>
>Summary:
>
>There is a rough consensus for forwarding the rollover requirements
>document although there are some minor editorial changes that need to
>be addressed in a new rev.
>
>
>During the WGLC the editor has stated a number of times that he was of
>the opinion that issues where closed and discarded those. Most notably
>
>
>- There has been quite some discussion on section 2.3.
>   That is an indication that that section is not quite self- documenting.
>
>   A strawman proposal is to reorder/rewrite the text so that it is
>   clear that the zone-owner can take action within a certain time after
>   publishing a new key in a keyset and what the response of the
>resolver
>   of that action is. How about:

As I said previously, if I'm going to do anything with this text, its 
that I'm going to remove it.  The first sentence covers what the zone 
owner can do with the contents of the zone.  Obviously, the zone 
owner can put into the zone whatever he or she wants and is not 
subject to MUST/MAY/SHOULD...  the lower case may be appropriate, but 
only as administrative guidance.   The second sentence covers what 
the resolver does when it sees strange information from the 
zone.  What the readers seem to be unable to grasp is that what the 
zone owner does is not controlling on what the resolver does except 
as to how the resolver reacts to the records retrieved from the zone.

So I'll remove this section rather than go through this discussion once again.

I'm actually going through and lower casing most of the SHOULDs in 
section 6 as well.


>     2.3 Remove Hold-down
>
>     Zone owners MAY remove a new key from the DNSKEY RRset if the add
>     hold-down timer has not been reached after first publication of
>     the RRset in the DNS i.e. when the DNSKEY RR set first seen by
>     resolvers.
>
>     If resolvers notice the removal of a previously added new key from
>     a DNSKEY RRset, it waits for the remove hold-down time and then,
>     if the key hasn't reappeared, SHOULD discard any information about
>     the key.
>
>   Obviously the editor, who is a native speaker, will find ways to
>   improve on this.
>
>- Clarification of the calculation of the minimum transmit time.
>
>- The editor has responded to most comments made and promised a
>   number of minor edits. He did, at a number of times, push back
>   suggestions made by working group members. Since there was no
>   further dispute the chairs assume consent with the editors position
>   and close these issues.
>
>Our proposal is to wait for rev 5 of the document allow for 1 week of
>review and then advance the document to the IESG with the note below
>(pending an additional review by the chairs).

Yup.  Figure sometime next week if not earlier for the -05 rev.


>-- Olaf and Olafur
>    DNSEXT chairs
>
>
>
>Title           : Requirements related to DNSSEC Trust Anchor Rollover
>Author(s)       : M. StJohns
>Filename        : draft-ietf-dnsext-trustupdate-timers-05
>Pages           :
>Date            : September 2006
>
>This is a request to publish the document on the standards track
>
>This draft relates to draft-ietf-dnsext-rollover-requirements and we
>think these two documents should be treated together.
>
>
>1) Have the chairs personally reviewed this version of the ID and do
>     they believe this ID is sufficiently baked to forward to the IESG
>     for publication?
>
>There are no nits according to idnits 1.108 (via tools.ietf.org). One
>could argue that DNSSEC terminology should have been expanded at first
>use, the chairs thinks this is not needed.
>
>
>2) Has the document had adequate review from both key WG members and
>     key non-WG members? Do you have any concerns about the depth or
>     breadth of the reviews that have been performed?
>
>
>Yes during last-call this document has been reviewed in depth by (at
>least) the following people.
>
>     - Wouter Wijngaards
>     http://ops.ietf.org/lists/namedroppers/namedroppers.2006/ msg01270.html
>
>     - Sam Weiler
>     http://ops.ietf.org/lists/namedroppers/namedroppers.2006/ msg01357.html
>
>     - Scott Rose
>     http://ops.ietf.org/lists/namedroppers/namedroppers.2006/ msg01280.html
>
>     - Andrew Sullivan
>     http://ops.ietf.org/lists/namedroppers/namedroppers.2006/ msg01306.html
>
>     - Wesley Griffin
>     http://ops.ietf.org/lists/namedroppers/namedroppers.2006/ msg01372.html
>
>     - Robert Story
>     http://ops.ietf.org/lists/namedroppers/namedroppers.2006/ msg01373.html
>
>     - Suresh Krishnaswamy
>     http://ops.ietf.org/lists/namedroppers/namedroppers.2006/ msg01311.html
>
>At an earlier phase the document has been reviewed by Eric Rescorla.
>http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg01026.html
>
>(Eric brought up a number of issues which were argued to be
>operational issues concerning key handling and not relevant to the
>protocol described in the draft)
>
>Reviewers have compared the properties of this rollover mechanism
>with the goals as set in the rollover-requirements draft.
>
>The reviewers are satisfied that the threshold-timers document
>satisfies (see
>section 5 of draft-ietf-dnsext-rollover-requirements)
>
>      1.  Scalability
>      3.  General Applicability
>      4.  Support Private Networks
>      7.  Planned and Unplanned Rollovers
>      8.  Timeliness
>      10. New RR Types (unclear requirement, but no new RR type needed)
>      11. Support for Trust Anchor Maintenance Operations
>            (accomplishes replace w/ separate add/delete)
>      12. Recovery From Compromise
>      13. Non-degrading Trust
>
>There have been ('non-blocking') comments about:
>
>      5.  Stale Trust Anchor Detection
>         Depending on how many revoked DNSKEYs are in the RRset
>
>      6.  Manual Operations
>         From the resolver point of view the operations may be difficult
>         to perform manually, on the zone-owner side manual operations is
>         not a problem.
>
>      9.  High Availability
>
>         In particular the amount of revoked DNSKEYs could increase
>          the size of the DNSKEY RRset to
>
>
>      2.  No Intellectual Property Encumbrance
>
>      Folk have been reluctant to comment on the status of the IPR
>      claims more about this at 4) below.
>
>
>3) Do you have concerns that the document needs more review from a
>     particular (broader) perspective (e.g., security, operational
>     complexity, someone familiar with AAA, etc.)?
>
>
>We think this document has had sufficient review, also from security
>savvy reviewers, on the other hand a final review will never hurt.
>
>
>4) Do you have any specific concerns/issues with this document that
>     you believe the ADs and/or IESG should be aware of? For example,
>     perhaps you are uncomfortable with certain parts of the document,
>     or whether there really is a need for it, etc., but at the same
>     time these issues have been discussed in the WG and the WG has
>     indicated it wishes to advance the document anyway.
>
>
>The rollover-requirements draft state that the preferred solution
>should not be IPR encumbered. Mr. Moreau claims that a patent applies
>(see
>http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg01283.html)
>The editor does not agree with this statement.
>
>We do not know if Mr. Moreau followed the instructions in 6.1.3 of
>BCP79.
>
>Besides, Diversinet claimed IPR
>(see https://datatracker.ietf.org/public/ipr_search.cgi? 
>option=document_search&document_search=ietf-dnsext-trustupdate-timers)
>
>It should also be noted that there were a number of proposals from
>which this particular draft was selected. This included
>draft-ietf-dnsext-trustupdate-threshold (covered by the same
>Diversinet IPR claim) and draft-moreau-dnsext-takrem-dns-02.txt (see
>https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=639). The
>draft-moreau-dnsext-takrem-dns-02 draft was published with a
>non-derivative clause.
>
>The working group has been made aware of the IPR claims and they were
>not subject to further discussion about applicability.
>
>
>
>
>5) How solid is the WG consensus behind this document?  Does it
>     represent the strong concurrence of a few individuals, with others
>     being silent, or does the WG as a whole understand and agree with
>     it?
>
>
>The selection for this particular proposal was done during the
>face-2-face meeting in Montreal and met wide consensus. This consensus
>was confirmed on-list. Also during the last call there were several
>folk that supported this document explicitly.
>
>
>6) Has anyone threatened an appeal or otherwise indicated extreme
>     discontent?  If so, please summarize what are they upset about.
>
>Mr. Moreau has stated discontent with the process. See
>https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=639
>and references therein.
>
>
>
>7) Have the chairs verified that the document adheres to _all_ of the
>     ID nits?  (see http://www.ietf.org/ID-nits.html).
>
>
>Yes.
>
>
>8) For Standards Track and BCP documents, the IESG approval
>     announcement includes a writeup section with the following
>     sections:
>
>     - Technical Summary
>
>     The document describes a means for automatically updating public
>     keys that are configured in DNSSEC aware resolvers. New
>     trust-anchors are configured when signatures over them can be
>     validated using the previous trust-anchors. By introducing explicit
>     revocation and a delay mechanism the chances of an attacker
>     introducing a mala fide trust-anchor after a key compromise are
>     mitigated, albeit not solved.
>
>
>     - Working Group Summary
>
>     There is a broad consensus that this solution provides a workable
>     key-rollover. The working group is aware IPR issues.
>
>     - Protocol Quality
>
>     There are no implementations yet. The chairs are aware of at least
>     1 and maybe 2 independent organizations that plan on
>     implementing. At least one implementer has done in-depth review
>     during last call.
>
>     The chairs are of the opinion that after implementations are
>     written there is probably millage in documenting operational
>     experiences.
>
>
>
>-----------------------------------------------------------
>Olaf M. Kolkman
>NLnet Labs
>http://www.nlnetlabs.nl/
>
>
>
>
>


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