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
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
