At 18:41 11-04-2012, The IESG wrote:
The IESG has received a request from the DNS-based Authentication of
Named Entities WG (dane) to consider the following document:
- 'The DNS-Based Authentication of Named Entities (DANE) Protocol for
Transport Layer Security (TLS)'
<draft-ietf-dane-protocol-19.txt> as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf(_at_)ietf(_dot_)org mailing lists by 2012-04-25. Exceptionally, comments
may be
In Section 1.2:
"This document applies to both TLS [RFC5246]"
Does this mean that DANE is not applicable for TLS 1.1?
In Section 1.3:
"A DNS query can return multiple certificate associations, such as in
the case of a server is changing from one certificate to another."
The sentence seems incorrect.
In Section 2.1.1:
"The certificate usages defined in this document explicitly only apply
to PKIX-formatted certificates in DER encoding."
I suggest adding a reference to X.690.
In Section 2.1.3:
"If the TLSA record's matching type is a hash, having the record use
the same hash algorithm that was used in the signature in the
certificate (if possible) will assist clients that support a small
number of hash algorithms."
As a comment that does not argue for any change, having SHA-256 hash
as the "lowest" hash excludes SHA-1, a widely deployed hash
algorithm. I gather that the WG has made a tradeoff between
perceived security and ease of deployment.
In Section 3:
'For example, to request a TLSA resource record for an HTTP server
running TLS on port 443 at "www.example.com",
"_443._tcp.www.example.com" is used in the request. To request a
TLSA resource record for an SMTP server running the STARTTLS protocol
on port 25 at "mail.example.com", "_25._tcp.mail.example.com" is
used.'
HTTPS for www.example.com is a straight-forward example. In the case
of a SMTP server, it is not as easy. Once the target host is
located, mail.example.com in this case, one might assume that the
server would advertise that hostname or the domain name used to
locate the target host as an identity. That's rarely the case due to
issues outside the scope of DANE. It's easier not to use the
STARTTLS protocol as an example.
In Section 7.2, 7.3 and 7.4:
"Applications to the registry can request specific values that have
yet to be assigned."
What is the meaning of "can request specific values" in that sentence?
In Section 8.1:
"If it is less likely that a user will hear about its trusted DNSSEC
validators being hacked that it is of a public CA being compromised"
I suggest using "compromised" instead of "hacked".
Regards,
-sm