Automated Updates of DNS Security (DNSSEC) Trust Anchors
draft-ietf-dnsext-trustupdate-timers-06

[Ballot comment]
In his SecDir Review, Stefan Santesson said:
  >
  > This document introduce a rule set for revocation of a DNS key
  > where revocation of that key requires use of the corresponding
  > private key.  This raises a question how you revoke a key that
  > may be compromised but where the private key has been lost. Is
  > there a non-recoverable security risk involved if a vital key
  > can't be revoked due to such situation?
  >
  The security considerations ought to discuss this point.  It already
  says that a non-compromised key is needed to recover.  However it
  does not say anything about the situation where a hardware module
  fails that contains the private key.  It is not compromised, but
  no one can make use of it.  (I'm ignoring backup of keys for
  simplicity.  I think the author will still understand the point.)

[Ballot discuss]
The key roll-over process described in section 6.3 results in a trust point with a single active
key  ('B') and no stand-by key until the hold-down expires for the new key ('C').  Wouldn't it
be more prudent to revoke the old key ('A') after the add hold-down expires for the new key?

To meet the requirement for "Non-degrading trust" (as defined in Section 5.13 of
dnsext-rollover-requirements), new stand-by keys should be at least as strong as as the
current active keys.  This should be noted briefly in the security considerations section.

[Ballot discuss]
The key roll-over process described in section 6.3 results in a trust point with a single active
key  ('B') and no stand-by key until the hold-down expires for the new key ('C').  Wouldn't it
be more prudent to revoke the old key ('A') after the add hold-down expires for the new key?

[Ballot comment]
Should we include an RFC Editor Note to update section 3 based on the assignment of a bit in
the DNSKEY flags field?  The current text of section 3 begins "Bit n of the DNSKEY Flags field",
and there is no inline note to the RFC editor to update the text...

In section 2.3, I don't think you need "MAX" in the definition of queryInterval. Similarly, I believe
there are issues with the definition of retryTime in the following paragraph.  I think both should
specify a range, but MAX gives us a scalar right?

[Ballot comment]
Should we include an RFC Editor Note to update section 3 based on the assignment of a bit in the
DNSKEY flags field?  The current text of section 3 begins "Bit n of the DNSKEY Flags field", and there is no inline note to the RFC editor to update the text...

In section 2.3, I don't think you need "MAX" in the definition of queryInterval. Similarly, I believe there are issues with the definition of retryTime in the following paragraph.  I think both should specify a range, but MAX gives us a scalar right?

[Ballot discuss]
The key roll-over process described in section 6.3 results in a trust point with a single active key  ('B') and no stand-by key until the hold-down expires for the new key ('C').  Wouldn't it be more prudent to revoke the old key ('A') after the add hold-down expires for the new key?

[Ballot comment]
Should we include an RFC Editor Note to update section 3 based on the assignment of a bit in the
DNSKEY flags field?  The current text of section 3 begins "Bit n of the DNSKEY Flags field", and there is no inline note to the RFC editor to update the text...

IANA Last call Comment:

IANA understands that, upon approval of this document,
there is a single IANA Action that needs to be completed.

In the DNSKEY FLAGS registry located at:

http://www.iana.org/assignments/dnskey-flags

a single value would be added:

Number Description
------ ------------------------------
TBD REVOKE

IANA understands that this is the only action required
upon approval of this document.

PROTO Write-up

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.