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@ietf.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.s...@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 -------------------------------------------