[Gen-art] Gen-ART LC review of draft-ietf-dnsext-rollover-requirements-04.txt

[Spencer Dawkins <[e-mail]>]

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-dnsext-rollover-requirements-04
Reviewer: Spencer Dawkins
Review Date:  2007-01-23
IETF LC End Date: 2007-01-29
IESG Telechat date: (

Summary: This document is almost ready for publication as an Informational 
RFC. I have some questions and suggestions, but no objections.

Comments:

3  Background

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

   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

Spencer: is the point "this manual approach will not scale"? If so, 
inserting the word "manual" would help me understand...

   resolvers can change the Trust Anchors at the appropriate time.  This
   approach will not scale and, therefore, drives the need for an
   automated specification-based approach for rollover of Trust Anchors
   for security-aware resolvers.

5.1  Scalability

   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

Spencer: 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?

   embedded security-aware resolvers.

5.2  No Intellectual Property Encumbrance

Spencer: Sadly, the title should probably be "No Known Intellectual Property 
Encumbrance". That's all we can say in the IETF...

   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.

Spencer: 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 
OK?

5.8  Timeliness

   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.

Spencer: 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/..."?














_______________________________________________
Gen-art mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/gen-art