RFC 6698 sextion 4 says: Some specifications for applications that run over TLS, such as [RFC2818] for HTTP, require that the server's certificate have a domain name that matches the host name expected by the client. Some specifications, such as [RFC6125], detail how to match the identity given in a PKIX certificate with those expected by the user.
In draft-fanf-dane-smtp and draft-fanf-dane-mua I said that clients must check that the name in the certificate matches the server host name. This was based on the fairly vague reasoning that this is the normal thing to do in current code and that it would be simpler to keep this logic in all cases. However there is a stronger reason. I'm adding this to my security considerations section: Section 4 of the TLSA specification [RFC6698] leaves the details of checking names in certificates to higher level application protocols, though it suggests the use of [RFC6125]. Name checking might appear to be unnecessary, since DNSSEC provides a secure binding between the server name and the TLSA record, which in turn authenticates the certificate. However this latter step can be indirect, via a chain of certificates. A usage=0 TLSA record only authenticates the CA that issued the certificate, and third parties can obtain certificates from the same CA. So this specification says that SMTP clients check that the server's certificate matches the server host name, to ensure that the certificate was issued by the CA to the server that the client is connecting to. The client always performs this check regardless of the TLSA usage, because the implementation is simpler and so that this specification is less likely to need updating when new TLSA usages are added. Tony. -- f.anthony.n.finch <[email protected]> http://dotat.at/ Rockall, Malin, Hebrides, Bailey: Southeast 4 or 5, occasionally 6 at first, decreasing 3 for a time later. Slight or moderate, occasionally rough at first. Thundery showers. Good, occasionally poor. _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
