On 22-Apr-2009, at 14:13, Peter Koch wrote:
this is to initiate a working group last call on
"DNSSEC Trust Anchor Configuration and Maintenance"
draft-ietf-dnsop-dnssec-trust-anchor-03.txt
ending Friday, 2009-05-08, 23:59 UTC. The tools site gives easy
access to
diffs and such under
<http://tools.ietf.org/html/draft-ietf-dnsop-dnssec-trust-anchor-03>.
The document is aimed at a status of "Informational".
Please review the draft and send comments and/or statements of
support or
non-support to the WG mailing list.
There will be a five reviewer threshold.
I have read this document and find it well-written and useful. A few
somewhat minor improvements occurred to me, notes for which can be
found below. I don't think any of them are tremendously substantive,
and I think the document would still be accurate and useful if
published as-is. I apologise for not reading the document and
commenting earlier. I would be happy to suggest text in relation to
any of the points below, if that seems useful.
In the second paragraph of section 1, there is an assertion that root
zone signing is a prerequisite for "widespread public DNSSEC
deployment". The text goes on to discuss islands of security. I am the
last person to suggest that the root should not be signed yesterday,
but I think it's possible for there to be widespread DNSSEC deployment
without a signed root zone -- you just have more islands of security.
I think that paragraph could be tidied up a little to make it clearer
that the content that follows is useful without a signed root zone,
just as it is useful with a signed root zone.
As I read section 2 I found myself expecting to see an example (as
someone else here also mentioned). Perhaps this is because of the
reference to the root hints file in the preceding section; the
analogous advice there gives a presentation format (canonical zone
format) while section 2 does not: it only provides guidance as to the
type of data that should be used. I think the presentation format
should be specified, with an example.
Section 4 does not provide guidance about updating a local trust
anchor repository (e.g. a text file) based on the results of the trust
anchor priming procedure which is described there. This seems like an
important step; otherwise restarting a validator which has a really
old trust anchor stored on disk might suddenly result in a priming
failure, because of a key rollover elsewhere. I think storing updated
trust anchors is implied by the text, but never really called out
explicitly. I think explicit mention of it would be useful.
Given the apparent popularity of the IANA ITAR it might be worth
mentioning it as one of the examples of a trusted update mechanism
that does not use the DNS for trust anchor retrieval.
DLV provides another mechanism for obtaining trust anchors that a
validator could use. It seems plausible that DLV could also be
mentioned as another kind of DNSSEC In-Band Update mechanism, in
addition to 5011.
Joe
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
