Re: Last Call: <draft-ietf-dane-protocol-19.txt> (The DNS-Based Authentication of Named Entities (DANE) Protocol for Transport Layer Security (TLS)) to Proposed Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu Apr 12 08:11:43 2012, SM wrote:
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.


No, this seems correct, in as much as multiple TLSA records can be returned. A forward reference to §A.4 would be handy here.
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).
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.
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.
Note, incidentally, that §8 refers to "type 2", but §2.1.1 refers to  
"[Certificate] usage 2" - consistency might be preferable here.
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.
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.
Dave.
--
Dave Cridland - mailto:dave@xxxxxxxxxxxx - xmpp:dwd@xxxxxxxxxxxxxxxxx
 - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
 - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]