Publication request raft-ietf-dnsext-trustupdate-timers-05

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

Title		: Requirements related to DNSSEC Trust Anchor Rollover
Author(s)	: M. StJohns
Filename	: draft-ietf-dnsext-trustupdate-timers-05
Date		: November 29, 2006

Document shepherd: Olaf Kolkman

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 states 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 indicated that he would abtain from providing input on
this draft because he is not satisfied with the requirements
draft. (http://ops.ietf.org/lists/namedroppers/namedroppers.2006/ 
msg01327.html).
He has not threatened with an appeal.



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/