Some additional modest last call comments on draft-ietf-dane-protocol-19...
terminological issues
---------------------
The "usage" notion has at least five term/phrase variations used in the spec. I
found this quite confusing. Here's the variations I find..
usage = usage type = certificate usage = certificate usage type = TLSA Usages
I suggest settling on one or two phrases for most all occurances. I suggest
using "certificate usage type" in (almost) all cases, and "usage type" perhaps
in cases where the bare term "usage" is presently used. To help out, here's an
updated TLSA RDATA Wire Format diagram..
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Usage Type | Selector | Matching Type | /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ /
/ /
/ Certificate Association Data /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Separately, the term "TLSA certificate association" is used in a few places,
and should probably be "TLS certificate association" for consistency.
I also found the term "TLSA association" used on pages 22 & 23, which ought to
be "TLS certificate association", yes?
Section 8.1 introduces the somewhat ambiguous term "DANE client", which is
contrasted with "common TLS clients" and "current TLS client". Perhaps
"TLSA-aware TLS client" is more appropriate here than "DANE client", especially
if this protocol is referred to as the "TLSA protocol"?
editorial items
---------------
> 1.1. Background of the Problem
[ I'd entitle this section "Background and Motivation" ]
last para:
> DNS-Based Authentication of Named Entities (DANE) offers the option
> to use the DNSSEC infrastructure to store and sign keys and
> certificates that are used by TLS.
If in fact the term "DANE" (and its expansion) names a class of Secure
DNS-based cert/key-to-domain-name associations, and protocols for particular
instances will nominally be assigned their own names, where a case-in-point is
the "TLSA Protocol", then..
s/TLS/security protocols/
..in the above-quoted sentence.
> 1.2 Securing the Association with a Server's Certificate
which association is this section title referring to? (it's ambiguous)
Suggested more precise section title:
"Securing the Association of Domain Name and TLS Server Certificate"
> Currently, the client must extract the domain name from the
> certificate and must successfully validate the certificate, including
> chaining to a trust anchor.
I found the above description unnecessarily imprecise, though recognizing the
desire to provide only a brief overview here. A suggested modest rewrite:
Currently, the client must extract the domain name from the certificate
and validate it [RFC6125], and must also successfully validate the
certificate, including chaining to a CA's trust anchor [RFC5280].
However, as explained above in Section 1.1, essentially any CA may
have issued the certificate for the domain name.
> 2. The TLSA Resource Record
>
> The TLSA DNS resource record (RR) is used to associate a certificate
> with the domain name where the record is found.
suggested clarification..
The TLSA DNS resource record (RR) is used to associate a TLS server
certificate or public key with the domain name where the record is found,
thus forming a "TLS certificate association".
Otherwise, "TLS certificate association" is only tacitly defined.
> 2.1.1. The Certificate Usage Field
>
>
> A one-octet value, called "certificate usage" or just "usage",
> specifies the provided association that will be used to match the
> target certificate from the TLS handshake.
In the above, as well as two more instances in the paragraphs following the
above, I suggest..
s/target certificate/presented certificate/
..to be more consistent with RFC6125.
> 2.1.4. The Certificate Association Data Field
>
>
> The "certificate association data" to be matched. This field
> contains the data to be matched.
The 2nd sentence "This field contains the data to be matched." is redundant.
> 5. TLSA and DANE Use Cases and Requirements
> .
> .
> .
> Combination -- Multiple TLSA records can be published for a given
> host name, thus enabling the client to construct multiple TLSA
> certificate associations that reflect different DANE assertions.
> No support is provided to combine two TLSA certificate
> associations in a single operation.
>
> Roll-over -- TLSA records are processed in the normal manner within
> the scope of DNS protocol, including the TTL expiration of the
> records. This ensures that clients will not latch onto assertions
> made by expired TLSA records, and will be able to transition from
> using one DANE public key or certificate usage type to another.
suggested rewrite eliminating the not-defined-in-RFC6394 terms "DANE assertion"
and "DANE public key"...
Combination -- Multiple TLSA records can be published for a given
host name, thus enabling the client to construct multiple different
TLS certificate associations. No support is provided to combine two
TLS certificate associations in a single operation.
Roll-over -- TLSA records are processed in the normal manner within
the scope of DNS protocol, including the TTL expiration of the
records. This ensures that clients will not latch onto assertions
made by expired TLSA records, and will be able to transition from
using one TLSA-asserted public key or certificate usage type to
another.
> 7.2. TLSA Usages
>
>
> This document creates a new registry, "Certificate Usages for TLSA
> Resource Records".
suggested modest revision for terminological consistency:
7.2. TLSA Certificate Usage Types
This document creates a new registry, "TLSA Resource Record Certificate
Usage Types"
HTH,
=JeffH