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(_at_)cridland(_dot_)net -
xmpp:dwd(_at_)dave(_dot_)cridland(_dot_)net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade