On 12. 4. 2012, at 9:11, SM wrote:
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?
RFC4346 (TLS 1.1) has been obsoleted by RFC5246. We cannot make references
to obsoleted documents. As a side note, we don't say "to both TLS 1.2", but
just TLS.
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.
Dave already commented on this. I also don't see anything wrong with the
sentence.
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.
Seems reasonable.
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.
SHA-2 was first published 11 years ago and I don't really think that
applications which will decide to implement DANE will not have support
for SHA-2 family.
The quoted sentence just says: Use closest available algorithm to help
clients (e.g. please don't use SHA-3 if the certificate signature is SHA-256).
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.
Here the rules from RFC3207 can be applied:
The decision of whether or not to believe the authenticity of the
other party in a TLS negotiation is a local matter. However, some
general rules for the decisions are:
- A SMTP client would probably only want to authenticate an SMTP
server whose server certificate has a domain name that is the
domain name that the client thought it was connecting to.
Similar logic applies to DANE, but it's not the DANE which decides the
name, but TLS capable client, which already know which name to expect.
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?
It's just a note, that we expect that future standards would be able
to assign new values (f.e. new hash algorithms when SHA-3 is out).
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".
lgtm
O.
--
Ondřej Surý
vedoucí výzkumu/Head of R&D department
-------------------------------------------
CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC
Americka 23, 120 00 Praha 2, Czech Republic
mailto:ondrej(_dot_)sury(_at_)nic(_dot_)cz http://nic.cz/
tel:+420.222745110 fax:+420.222745112
-------------------------------------------