Wrap-up trustupdate timers

["Olaf M. Kolkman" <[e-mail]>]

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:

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

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