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/
Attachment:
PGP.sig
Description: This is a digitally signed message part