Subject: Wrap-up trustupdate timers

From: "Olaf M. Kolkman" <[email-masked]>
Date: Tue, 21 Nov 2006 20:33:11 +0100

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/

---

From: Mike StJohns <[email-masked]>
Date: Tue, 21 Nov 2006 15:40:35 -0500

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:

>   That is an indication that that section is not quite self- documenting.
>

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.

>(pending an additional review by the chairs).

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

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

--
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: "Olaf M. Kolkman" <[email-masked]>
Date: Wed, 22 Nov 2006 21:06:22 +0100

On 21Nov 2006, at 9:40 PM, Mike StJohns wrote:

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

Eh... well Mike, I noted that there was confusion over 2.3 and  
provided a strawman to mitigate that confusion. Now we (as a working  
group) can accept that you (the editor) are not going to do anything  
with this text and wait for the IESG to get confused or we can solve  
things now.

Obviously, we do not want a long debate and we need to get closure on  
this so I (as chair) propose lets follow your suggestion: lower case  
the 2119 keywords in section 5 and 6 and leave the text as is unless  
the wg indicates that my (as an individual contributer) strawman or a  
proper English variation thereof is clearer.

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

Shall we allow Monday noon CET to allow the WG to respond to this  
issue. Silence on the matter indicates agreement to leave the text  
and lower-case.

Rest assured that I want to deliver this document to the IESG ASAP.  
An my apologies for not posting my wrap up earlier.

--Olaf