On 12. 4. 2012, at 10:26, Dave Cridland wrote: >> 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. > > To expand on this, it's not wholly clear what one might do for SRV (or MX) records in general. It's not clear whether a client needs to access records for every SRV returned. Moreover, protocols such as XMPP do allow a server to use a different certificate depending on the called domain, and existant servers do implement this - this means that acting upon TLSA records found against purely A/AAAA records pointed to in turn by SRV. > > It seems to me that, unfortunately, there is a requirement here to add a further case, by allowing TLSA records against the SRV-style name, such as: > > _xmpp-server._tcp.example.com IN TLSA 1 1 1 DEADBEEFCAFE > > The above comments about SRV are unfortunate, because I'm already concerned with the number of options available. In particular, given the relative ease of certificate/key rollover, I think the SubjectKeyInfo match could be removed. Moreover, I think it absolutely should be for CA certificates - it seems to broaden the attack surface (and moreover, broaden the opportunities for confusion and failure). Please see http://trac.tools.ietf.org/wg/dane/trac/ticket/28 before discussing SRV records further. We have left SRV records on purpose and we expect that this will be solved in separate document (for each affected protocol). > In addition, it's not clear to me that having hashes in lieu of complete data is particularly helpful - I do appreciate that it removes a not inconsiderable number of octets from the wire, but I'd also note that if a full certificate is in DANE, then it's possible for a client to check revocation status without connecting to the service. This seems to me as potentially useful, and I'd note that although the certificates are indeed quite large, they ought to be readily cached as well. The hashes are very useful since any UDP DNS packet not able to fit into MTU will cause truncation and reconnection to DNS server via TCP. So almost any full certificate will cause two serialized connections anyway UDP and TCP. If you connect to the service and to DNS server, you can make those connections in parallel, which considerably speeds up this (because you will need that connection to the service anyway). > Touching on revocation leads on to a further comment - there's only very brief mention of how clients should handle revocation status checks, and it appears to suggest that a "type 2" certificate should not, or even must not, be checked. I'd suggest that at minimum, this ought to be clarified. In particular, the security considerations refer to type 2, but not type 3, certificates. True, I think we need to expand Security Considerations for type 3 as well, since PKIX validation is not performed for Type 3 at all. > Note, incidentally, that §8 refers to "type 2", but §2.1.1 refers to "[Certificate] usage 2" - consistency might be preferable here. Good catch. > As a final comment, I'd presonally like to see some comments about how, and when, extended validation information should be checked and trusted. It seems to me that such information should be ignored when handling type 2 or type 3 certificates; or at best it should be validated independantly using the traditional methods - that is, it should be treated as a type 0 or type 1 certificate for the purposes of extended validation. I think that Extended Validation is out of the scope of this document. And if I am not mistaken the CA which are able to issue EV certificates are hardcoded in the browsers. Thus I think that DANE-aware applications can use standard rules for EV certificates. > Oh, and one more nit, why not. I can't be the only person who notes that the certificate type is a bitfield of "Suppress 5280 validation" and "End Entity Cert" flags. I wonder if this might lead to risk if new cert types were assigned that did not match this? Is it worthwhile making a comment that it's explicitly not a bitfield? I may be being overly paranoid, here. I think you might be overly paranoid :), but on the other hand a simple note would hurt either. I am leaving this up to our editors discretion. 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.sury@xxxxxx http://nic.cz/ tel:+420.222745110 fax:+420.222745112 -------------------------------------------