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(_dot_)sury(_at_)nic(_dot_)cz http://nic.cz/
tel:+420.222745110 fax:+420.222745112
-------------------------------------------