Requirements Related to DNS Security (DNSSEC) Trust Anchor Rollover
draft-ietf-dnsext-rollover-requirements-04

[Ballot comment]
Section 2, paragraph 3:

  Remove the text about what dnsext did and didn't do - not typically
  published in RFCs. ("Several mechanisms...set of requirements.")

[Ballot comment]
Based on Gen-ART Review by Spencer Dawkins:

  In section 3, the following paragraph took me several reads to parse.
  I think it's saying: "It should be noted that only the DNSKEY RRs and
  DS RRs that are known to be Trust Anchors are the DNSKEY RRs for the
  root zone, so responsibility lies with the operators of security-aware
  resolvers, and not signed zone operators", but if I got this right,
  putting this thought at the beginning of the paragraph would help a lot.
  >
  > It should be noted that DNSKEY RRs and DS RRs are not Trust Anchors
  > when they are created by the signed zone operation nor are they Trust
  > Anchors because the records are published in the signed zone.  A
  > DNSKEY RR or DS RR becomes a Trust Anchor when an operator of a
  > security-aware resolver determines that the public key or hash will
  > be used as a Trust Anchor.  Thus the signed zone operator that
  > created and/or published these RRs may not know if any of the DNSKEY
  > RRs or DS RRs associated with their zone are being used as Trust
  > Anchors by security aware resolvers.  The obvious exceptions are the
  > DNSKEY RR(s) for the root zone that will be used by many security-
  > aware resolvers.  For various reasons, DNSKEY RRs or DS RRs from
  > zones other than root can be used by operators of security-aware
  > resolvers as Trust Anchors.  It follows that responsibility lies with
  > the operator of the security-aware resolver to ensure that the DNSKEY
  > and/or DS RRs they have chosen to use as Trust Anchors are valid at
  > the time they are used by the security-aware resolver as the starting
  > point for building the authentication chain to validate a signed DNS
  > response.

  Also in Section 3:
  >
  > When operators of security-aware resolvers choose one or more Trust
  > Anchors, they must also determine the method(s) they will use to
  > ensure that they are using valid RRs and that they are able to
  > determine when RRs being used as Trust Anchors should be replaced or
  > removed.  Early adopters of DNS signed zones have published
  > information about the processes and methods they will use when their
  > DNSKEY and/or DS RRs change so that operators of security-aware ...
  >
  Is the point "this manual approach will not scale"?  If so,
  inserting the word "manual" would help me understand...

  In section 5.1:
  >
  > The automated Trust Anchor Rollover solution MUST be capable of
  > scaling to Internet-wide useage.  The probable largest number of
  > instances of security-aware resolvers needing to rollover a Trust
  > Anchor will be for the root zone.  This number could be extremely
  > large (possibly many millions) if a number of applications have ...
  >
  I'm not sure where the "possibly many millions" is coming from.  If
  this is the number of security-aware resolvers that we expect to be
  connected to the Internet, wouldn't this be potentially a larger
  number than this?

  The title of Section 5.2 is "No Intellectual Property Encumbrance."
  Sadly, the title should probably be "No Known Intellectual Property
  Encumbrance". That's all we can say in the IETF...

  Also in Section 5.2:
  >
  > For this purpose, "royalty-free" is defined as follows: world wide,
  > irrevocable, perpetual right to use, without fee, in commerce or
  > otherwise, where "use" includes descriptions of algorithms,
  > distribution and/or use of hardware implementations, distribution
  > and/or use of software systems in source and/or binary form, in all
  > DNS or DNSSEC applications including registry, registrar, domain name
  > service including authority, recursion, caching, forwarding, stub
  > resolver, or similar.
  >
  Please note that IANAL, but I've been seeing pushback from the open
  source community about additional conditions on "royalty-free" licenses.
  Do you need to say anything about this?  Would royalty-free with
  reciprocity be acceptable?

  In Section 5.8:
  >
  > Resource Records used as Trust Anchors SHOULD be able to be
  > distributed to security-aware resolvers in a timely manner.
  >
  > Security-aware resolvers need to acquire new and remove revoked
  > DNSKEY and/or DS RRs that are being used as Trust Anchors for a zone
  > such that no old RR is used as a Trust Anchor for long after the zone
  > issues new or revokes existing RRs.
  >
  I don't actually know what "for long" means, in this paragraph.
  Could you bound it in units? "for more than a few
  minutes/hours/days/weeks/..."?

[Ballot comment]
Minor things I noticed reading this draft:

- I have no clue what "specification-based" is supposed to mean as a qualifier.  As a reader, the doc would mean the same thing to me if that phrase was simply elided.  Yet it seemed emphasized, so I worry that I'm missing something important.

- section 5.6: "must allow the implementation to support both automated and manual rollover".  I think this means that even when a trust anchor was obtained automatically, it must be possible for the operator to remove it manually without this change being overwritten by the next RRSet received with that key.  Also, is there a requirement for manual revocation (which is like rollover but without replacement) or manual adding of keys? 

thx,
Lisa

Security Model issues

While acknowleding that he wasn't sure how much this mattered for a requirements document, Stefan Santesson sent an email to the secdir containing:

- Lack of security tradeoff vision

This document sets out to specify requirements for a security service which must face security tradeoffs. Root keys are by definition distributed out-of-band, simply because if they are root keys, they are not signed by any higher authority. A protocol for automatic distribution and updating root keys therefore by definition face certain security tradeoffs or needs to be validated through some other root key not distributed through this solution. A traditional tradeoff is to have very stabile and long lived top level root keys, often pre-installed with each module  to reduce the pain of manual installation and validation. I lack a vision or direction in this requirement specification what the tradeoffs for this solution should optimize on (security vs. functionality)

Thierry Moreau also stated to the IETF list:

(C) In the later phase of DNSEXT wg activities in this area, an IESG member expressed concerns about the absence of a security model in the protocol document (see comment by Eric Rescorla  at http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg01027.html and replies by Mike St-Johns at http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg01036.html and myself at http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg01038.html). Does the IESG perspective call for a greater attention to a formal security foundation in the requirements specifications phase as well?

-------- Original Message --------
Subject: Last Call: draft-ietf-dnsext-rollover-requirements -- Comment submission
Date: Fri, 19 Jan 2007 07:48:21 -0500
From: Thierry Moreau
To: ietf@ietf.org


Dear IESG participants:

Now that the draft-ietf-dnsext-rollover-requirements comes to the IESG,
I suspect the document should be reviewed with a broader perspective
than the interoperability focus of the DNSEXT wg.

This draft is a requirements document that supports a protocol document,
i.e. draft-ietf-dnsext-trustupdate-timers. In the DNSEXT wg, I objected
to the requirements document, but acknowledged that the protocol
document seems coherent with the requirements as documented.

In this context, I bring to the IESG three questions about the
draft-ietf-dnsext-rollover-requirements:

(A) Is the redefinition of IPR procedures in a working group
requirements document an acceptable precedent in IETF governance? See
the text of document section 5.2 which was instrumental in the adoption
of the protocol document by the DNSEXT wg.

(B) ICANN (with the assistance of its IANA operating entity and DNS root
operators) is the foremost operator for the protocol to be adopted by
the IETF for automated DNSSEC trust anchor key rollover. Was the ICANN
perspective taken into account in the document development process to
the satisfaction fo the IESG?

(C) In the later phase of DNSEXT wg activities in this area, an IESG
member expressed concerns about the absence of a security model in the
protocol document (see comment by Eric Rescorla  at
http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg01027.html
and replies by Mike St-Johns at
http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg01036.html
and myself at
http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg01038.html).
Does the IESG perspective call for a greater attention to a formal
security foundation in the requirements specifications phase as well?

Despite my personal reservations about the DNSEXT wg process that
brought the two drafts to their current state, e.g. question (A) above,
I do not challenge the fact that rough consensus was reached at the wg
level. Thus, the above three questions would be relevant to the extent
that the IESG perspective may be more encompassing  than the wg one.

Thanks for your attention to the DNSSEC protocol extension project; in
any event, it remains a fascinating application scheme for public key
digital signatures.

Best regards,

--

- Thierry Moreau

CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, Qc
Canada  H2M 2A1

Tel.: (514)385-5691
Fax:  (514)385-5900

web site: http://www.connotech.com
e-mail: thierry.moreau@connotech.com


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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?

The shepherding chair (Olaf) has reviewed the document. And believes the
document is ready for IESG submission.


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?


There has been an active core of WG members involved in creating this
document. The document has been reviewed and explicitly supported by:

- Scott Rose
http://ops.ietf.org/lists/namedroppers/namedroppers.2006/
msg01280.html

- Wouter Wijngaards
http://ops.ietf.org/lists/namedroppers/namedroppers.2006/
msg01294.html

- Char Sample
http://ops.ietf.org/lists/namedroppers/namedroppers.2006/
msg01307.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

- Lindy Foster
http://ops.ietf.org/lists/namedroppers/namedroppers.2006/
msg01309.html

Two people have raised their concerns:
- Bill Manning

http://ops.ietf.org/lists/namedroppers/namedroppers.2006/
msg01315.html
Who argues that the document does not meet his perception of
key-roll but does not provide technical arguments even when asked
for.


- Thierry Moreau

His arguments are summarized in
http://ops.ietf.org/lists/namedroppers/namedroppers.2006/
msg01327.html
and references therein. The issues raised by Mr Moreau
* Lack of a security model for automated trust anchor rollover
* And WG process of intellectual property issue
* Work is beyond the charter of the group

The chairs are of the opinion that these arguments are mostly of
procedural nature.



Note has been taken that 3 folk from the above list are from Sparta
and two of those are not regular contributers to DNSEXT. In addition
there have been responses in the same thread (applying the
requirements to draft-ietf-dnsext-trustupdate-timers) which indicate
that people who have not explicitly supported the draft have read it.

We have confidence that support is the consensus position.


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 a review by security folk would not hurt, but see below



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.

See question 2).


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?


See question 2)



6) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize what are they upset about.


Mr Moreau has shown discontent, also see question 2). A relevant
data point may be that Mr. Moreau was not satisfied with the agenda of
the Montreal meeting where these items were discussed.


7) Have the chairs verified that the document adheres to _all_ of the
ID nits? (see http://www.ietf.org/ID-nits.html).






8) For Standards Track and BCP documents, the IESG approval
announcement includes a writeup section with the following
sections:

- Technical Summary
- Working Group Summary
- Protocol Quality




Summary.

This document provides a number or "requirements" for key-rollover in a
DNSSEC operational environment.

DNSSEC has been designed in such a way that zone operators can roll
their key-signin key, when those key-signing keys are configured as
trust anchors in remote resolvers those resolvers should automatically
adapt to these changes. This document sets out the requirements that
must be met by a DNS trust-anchor rollover solution for DNSSEC aware
resolvers.

As described in section 1 and 2, this document is intended to capture
the various requirements and use those in making a trade-off between
the various proposals that were available to the group. These
requirements acted as "goals". With the selection of
draft-ietf-dnsext-trustupdate-timers this document has no further
relevance. It is requested to be published as informational.