Re: SMTP/TLS (RFC 2487) server authentication question

["RL 'Bob' Morgan" <rlmorgan@xxxxxxxxxxxxxxxxxx>]

> While working on a RFC2487 extension to the Postfix MTA I stumbled over
> the following question:
> How should the client verify the servers identity?
> Unlike other protocols (e.g. RFC2595), where an explicit statement is made
> (Section 2.4. Server Identity Check) that the name presented in the certifiate
> MUST be checked against the hostname the client used to connect, there is
> no information in RFC2487. (I also checked the ietf-apps-tls archive and
> found no discussion about it.)

In section 5.1 of RFC 2487 there is:

   The decision of whether or not to believe the authenticity of the
   other party in a TLS negotiation is a local matter. However, some
   general rules for the decisions are:

    - A SMTP client would probably only want to authenticate an SMTP
      server whose server certificate has a domain name that is the
      domain name that the client thought it was connecting to.
 
> The problem arises since the mail client software must look up the MX
> record using DNS. As of now, I use the name returned from the MX lookup
> to check.
> 
> 1. Is there some SHOULD or MAY policy I just missed?
> 2. Is this left out because the data returned from DNS lookups is considered
>    "unreliable" as of today?

An excellent question.  I don't know the details of how the SMTP spec came
to be the way it is regarding this issue, but it is certainly a tricky
one.  It is unfortunate that the various appfoo-over-TLS specs are all
slightly different in their statements about this.  The problem gets to
the heart of the security guarantees that TLS (or any security scheme,
really) is offering to client apps that use it.

When a client gets a cert from a server via TLS, server authentication is
accomplished by the client (and user) verifying the contents of the cert
and determining that the information in the cert actually applies to the
service entity that the user directed the client to contact.  
Unfortunately "service entity" is not a well-standardized concept, even
within particular application protocols.  To the user the service they're
attempting to contact is probably "the online banking function of BigBank
Inc", or "my MailZombies mailbox", or "the SMTP router for MegaSoftCo".  
The fact that the server machines are called bnksrv1.bigbank.com and
mail23.mailzombies.com and smtp.megasoftco.com is a mystery to the average
person.  So if the attacker can trick the client into asking for
bnksrv1.badguy.com when it thinks it's going to BigBank Inc, and get a
cert (from a trusted CA) for that server (which may not be easy, of
course) then the game has been lost.  This is the gist of some recent
highly-publicized "SSL isn't secure" rants.

So, all the client can really do without a fruitless appeal to the user is
check that the hostname it is asked to contact is in the cert.  As you
note, this hostname may be resolved via DNS into another hostname before
turning into an IP address, and in the SMTP case this is very common,
obviously.  A MX resolution step is just like the high-level-name to
DNS-name step I describe above:  a chance for the attacker to insert bad
info and foil the process.  If your client, as you state, only checks for
the name after the MX lookup rather than the name it started with, then it
allows the attacker to do this undetected, and hence provides less
protection than the client that checks for the initial name.  Whether this
is a terrible lapse in security or a practical compromise is in the eye of
the beholder, I think.  (Note that Kerberos, in which clients do CNAME
resolution if necessary before asking for a service ticket, suffers from
this same problem.)

But I'm sure it's clear that if all clients check for the initial name,
this will change what service deployers have to do drastically:  any time
they add a new MX record for a host SMTP service, they'll need to modify
the server cert for that service to add the new MX-able name.  If the
server has 50 MXes, each one will have to appear in the cert.  This makes
sense from a security point of view but would certainly trip up the
typical admin, seems to me.

As a further complication, note that the PKIX cert RFC (RFC 2459) suggests
(in section 4.2.1.7) putting a DNS-named subject into the subjectAltName
extension of the cert, tagged as a dNSName type; though unlike
email-address-named subjects the spec doesn't specifically discourage
using the subject field for this kind of name.  But a robust client should
be prepared to look in both places for the server's DNS name.

Perhaps the right thing for an SMTP-TLS client is to have optional levels
of strictness in its checking, defaulting to insisting on the
pre-MX-lookup name being in the cert, but having an optional setting that
would only ask for the post-MX-lookup name.  Probably there would be other
useful knobs as well, regarding following of CA chains, etc.

 - RL "Bob"