Subject: [dane] checking names in certificates

From: Tony Finch <[email-masked]>
Date: Tue, 14 Aug 2012 12:05:26 +0100

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-masked]>  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.

---

From: Paul Wouters <[email-masked]>
Date: Tue, 14 Aug 2012 11:55:01 -0400 (EDT)

On Tue, 14 Aug 2012, Tony Finch wrote:

> check that the name in the certificate matches the server host name.

Prepare for a lot of non-FQDN CN's such as "Exchange" to cause failures.

I agree that both skipping the name check and using a TLSA type based on
a CA is dangerous and should not be done. (and I also believe you should
only be using some intermediary CA that you control if you put the CA in
a TLSA record. Reducing the strength of your TLSA to the weakest
customer of a certain CA indeed seems dangerous, and we should probably
have talked about that in 6698.

Paul

---

From: Tony Finch <[email-masked]>
Date: Tue, 14 Aug 2012 17:05:55 +0100

> Prepare for a lot of non-FQDN CN's such as "Exchange" to cause failures.

This problem is why the draft uses the existence of TLSA records to signal
that the server is competently configured.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Forties, Cromarty, Forth, Tyne, Dogger: Southeast 4 or 5, occasionally 6
except in Forth and Tyne. Slight or moderate, occasionally rough at first in
Forties. Rain or showers, fog patches. Moderate or good, occasionally very
poor.