I've taken a look at draft-jabley-dnssec-trust-anchor-00
and have a couple of comments -- mostly editorial in nature.
The items below follow a linear walk-through, independent of
any perceived "severity".
(1) Abstract -- nit (punctuation)
For improved readability, I suggest to insert a comma in the second
paragraph of the Abstract:
In order to obtain secure answers from the root zone of the DNS using
| DNSSEC a client must configure a suitable trust anchor. This
document describes how such trust anchors are published.
---
In order to obtain secure answers from the root zone of the DNS using
| DNSSEC, a client must configure a suitable trust anchor. This
^
document describes how such trust anchors are published.
(2) Section 1 (Introduction)
(2a) 1st paragraph -- which specs comprise DNSSEC ?
The Domain Name System (DNS) is described in [RFC1034] and [RFC1035].
| Security extensions to the DNS (DNSSEC) are described in [RFC4033],
| [RFC4034] and [RFC4035].
The DNSEXT WG has defined that the "core DNSSEC document set"
additionally contains RFC 5155 (NSEC3) as well as RFCs 4509 and 5702
(SHA-2 support in DS / DNSKEY and RRSIG records, respectively),
and the DNSSECbis clarifications document under development.
Whereas RFC 5155 arguably is irrelevant for the Root zone,
RFCs 4509 and 5702 are relevant. So I suggest to amend the list
of documents (and references) by at least these two RFCs.
(2b) 3rd paragraph -- misleading text:
| In DNSSEC a secure response to a query is one which is
| cryptographically signed and validated. An individual signature is
validated by following a chain of signatures to a key which is
trusted for some extra-protocol reason.
Hmmm ... doesn't that confuse DNSSEC with DNS transaction security
(TSIG+TKEY / SIG(0)) ?
DNSSEC does not sign responses, it delivers signed RRsets (where the
signature has been provided by the authoritative server for the
respective zone) and key chaining to provide for a chain of trust
along the branches down in the DNS tree.
Strawman replacement for the first sentence:
| In DNSSEC, cryptographically signed RRsets are stored and delivered,
| such that the receiver can verify the integrity and authenticity of
| each RRset.
(2c) 5th (last) paragraph -- amendment / text shuffling from App. E
Appendix E ("to be removed by RFC Editor") contains an (IMHO) important
sentence that should preferably be moved into this paragraph and
adapted properly:
This document describes the distribution of DNSSEC trust anchors.
+ By its publication in the RFC series, it aims at providing a stable
+ reference for DNS implementors and future document authors, and a
+ clear specification that will aid effective and secure dissemination
+ of DNSSEC trust anchors to the operators of DNSSEC validators.
Whilst the data formats and the publication and retrieval methods
described in this document might well be adapted for other uses, this
document's focus is more specific and is concerned only with the
distribution of trust anchors for the root zone.
(3) Section 2
(3a) -- overall presentation of material
This section looks like:
| Trust anchors for the root zone are published in two formats:
| o as the hash [...], as described in Section 2.1, and
^^^^^^^^^^^^^^^^^^^^^^^^^^^
| o as Certificate Signing Requests [...], as described in Section 2.2.
^^^^^^^^^^^^^^^^^^^^^^^^^^^
| Both formats are described in this document.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Given the detail in the bullets, the trailing sentence is redundant
*at this place* and IMO a bit confusing. Maybe It would be better to
amalgamate this sentence with the first paragraph, thus first giving
a coarse sketch and then the details in the bullets:
| Trust anchors for the root zone are published in two formats that
| both are described in this document:
| o as the hash [...], as described in Section 2.1, and
| o as Certificate Signing Requests [...], as described in Section 2.2.
(3b) 1st bullet -- inconsistency in style and grammar
Within the bullets, the first one uses an unpleasant mix of singular
and plural, whereas the second one talks about trusts anchors (plural).
I suggest to modify the first bullet to use the same style:
| o as the hash of the corresponding DNSKEYs consistent with the
defined presentation format of Delegation Signer (DS) resource
records [RFC4034], contained within an XML document, as described
in Section 2.1, and
--- v vv vvvvvvvvv
| o as hashes of the corresponding DNSKEY records, consistent with the
defined presentation format of Delegation Signer (DS) resource
records [RFC4034], contained within an XML document, as described
in Section 2.1, and
(4) Section 2.2 -- clarification needed
The current prose in Appendix C pretends to define a
Certificate Extension, whereas this section talks about an Attribute.
It looks like the latter is actually implemented, although the kind of
CN specified would have been sufficient to identify the Subject, and
thus packing the resourceRecord into a certificate extension (which
would also be signed by the certificate issuer).
[ Note: I don't know how well existing systems deal with unknown
attributes in the Subject name -- the RFC 5280 profile contains a
specific list of attribute types that SHOULD be supported --, but
I would have assumed that a new certificate extension would have
had a better chance of being accepted by CAs. ]
To avoid possible confusion, I propose to clarify both parts of the
document. In Section 2.2, as the ASN.1 type that actually is being
specified and amended is RelativeDistinguishedName in the rdnSequence
CHOICE of the "Subject" Name (cf. RFC 5280, Sect. 4.1.2.4 & 4.1.2.6),
it might be worth changing:
| Each CSR will have a Subject with following attributes:
--- vvvvvvvvvvvvvvvvvvvvvvvvvv
| Each CSR will have a Subject with following RelativeDistinguishedName
attributes:
(5) Section 3 -- additional note
Accidentally, shortly before the submission of the draft (and based
on the predecessor ICANN draft), I have filed an enhancement request
for the IANA web site to make the entire Root zone material (including
the trust anchors) accessible via hyperlinks on common pages where an
average user would perhaps expect to find such pointers.
The RFC Editor traditionally does not like detailed IANA URLs in RFC
text. Therefore, having proper, annotated links down to the various
files on a central page on the IANA site would also help a great deal
in case the RFC Editor refuses to accept the URLs in sect. 3.1/3.2.
(6) Section 4, 1st paragraph -- nit
Near the end of the paragraph: s/which/that/ .
(7) Appendix C
(7a) -- full-fledged ANS-1 module ?
The utility of the information would be improved very much if you could
turn the ASN.1 fragments into a valid ASN.1 module that can be imported
into ASN.1 tools.
(7b) -- misleading headline
As mentioned above, the headline is very confusing; the remainder
of the I-D (including the body of this Appendix) doen't look like
you want to define a "Delegation Signer Extension".
If that's indeed the intent, please change:
|Appendix C. ASN.1 for Delegation Signer Extension
---
|Appendix C. ASN.1 for the resourceRecord Distinguished Name Attribute
or, if you follow (7a), simply:
|Appendix C. ASN.1 Module
(7c) -- normative reference needed
A short sentence should be added -- details depending on the actual
content, wrt (7a) -- that refers to the ASN.1 specification used.
I guess ITU-T X.680 and X.681 will suffice; both should be granted a
Normative Ref.
(8) Appendix E
The text paragraph in Appendix E ...
This document, once published in the RFC series, is intended to
provide a stable reference for DNS implementors and future document
authors, and a clear specification that will aid effective and secure
dissemination of DNSSEC trust anchors to the operators of DNSSEC
validators.
... provides essential information to the reader and should not be
subject to removal by the RFC Editor, but moved into another suitable
part of the draft. If my recommendation in item (2c) above is
followed, this is accomplished and the paragraph here can be dropped.
Kind regards,
Alfred Hönes.
--
+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. |
| Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 |
| D-71254 Ditzingen | E-Mail: a...@tr-sys.de |
+------------------------+--------------------------------------------+
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
