Re: Man In The Middle Attacks and STARTTLS

On Thu, Apr 15, 1999 at 02:33:26PM -0700, Paul Hoffman / IMC wrote:
> At 02:01 PM 4/15/99 -0700, Dan Wing wrote:

>> To protect against the MITM attack you describe below, the client needs to
>> treat "454 TLS not available due to temporary reason"  exactly the same as
>> a missing "250 STARTTLS" from the EHLO response.

> That's my conclusion. It also means that watching for the lack of "250 
> STARTTLS" doesn't buy you anything.

Sure.  There's one difference between the two cases, though: If a
sending MTA caches the names of servers that are known to handle TLS
and this MTA tries to send mail to a previously unknown server that
announces STARTTLS, then it should add this name to its list even if
STARTTLS gets a 454 reply, and should probably try again later.  Since
the server announces STARTTLS, we can expect it to handle the command
at some time -- maybe after the operator entered the password to
decrypt the server key, which may have become unavailable because of a
server reboot.  If a missing STARTTLS and the 454 error were treated
equally, we'd unnecessarily become vulnerable even to passive
eavesdroppers.

The discussion of authentication in RFC 2487 is rather vague, anyway.
The RFC defines a protocol mechanism, but does not thoroughly discuss
the goals that may be the reason to use this mechanism.  Depending on
what one is trying to achieve, things can look quite different.

E.g.: TLS can be used for client authentication to decide whether
relaying should be allowed (paying customers are authorized, others
are not), or whether the client may send a message to a certain
mailing list and things like that; there may be no need for secrecy.
In this case, the client does not worry at all whether TLS is used or
not -- it's just interested in sending its message.  So if STARTTLS is
announced, it will give it a try, and if this fails, it'll just send the
message in clear, which may or may not work (e.g., relaying may be
allowed for anyone who either is in the ISP's dial-up network or
has a valid TLS certificate issued by the ISP).

Now when secrecy is the point, then we probably want to define a list
of hosts for which encryption (and authentication, namely a server
certificate from a specific CA) is required in any case.  For example,
the mail host at someplace.example.com may insist on TLS for all
messages to somewhereelse.example.com because these messages likely
are company-internal e-mail between different locations.

The hints in RFC 2487 are rather fuzzy, e.g.:

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

When taken literally, this way of authenticating the server is all but
useless because the name of the server to connect to will typically be
obtained by a DNS query that does not use strong authentication -- and
the domain name of the MX need not have anything to do with the domain
name in the recipient's e-mail address.  Only if the client knows from
the start where to send the mail, authenticating the server makes
sense.

https:// URLs can be regarded as implying that authentication of the
server is requested (although the granularity of this is very low --
it's just a binary flag, there's no way to express that only
certificates from certain CAs should be accepted).  We don't have
something like that for e-mail, unfortunately.  A similar problem is
also introduced by draft-ietf-tls-http-upgrade-00.txt for TLS-secured
HTTP: When I have a bookmark for an HTTPS URL, then usually I don't
want to reveal the path to anyone but the specified host.
With the scheme from draft-ietf-tls-http-upgrade-00.txt, my bookmark
wouldn't any longer contain that "server authentication required"
flag.

To summarize, it appears to me that one important question is usually
neglected: What problem is it that we trying to solve by using TLS?
Several different answers are possible, and these must be considered
when specifying TLS applications.  Without thoroughly understanding
the problem, we cannot really hope for a good solution (and HTTPS,
with the https:// URL scheme and its implementation in current
browsers, is far from perfect: How do I specify that HTTPS server
www.mycompany.com should be considered authentic only if it can
present a certificate from my company's own CA?  I can't -- neither in
hyperlinks nor in my personal WWW bookmarks).