Re: [Uta] MTA-STS-03 review

[Viktor Dukhovni <[e-mail]>]

> On Mar 26, 2017, at 3:56 PM, David Illsley <[e-mail]> wrote:
> 
>>> Here, as discussed on the list, serious consideration should be given
>>> to changing the semantics from validating the MX hostname to specifying
>>> the names allowed in the server's certificate.  This simplifies MX processing
>>> (which remains unmodified) and merely changes the conditions under which an
>>> MX host is considered suitably authenticated per the policy.
>>> 
>>> Which, for example, allows the MX hosts to share a single certificate
>>> with the destination domain (and not the MX hostname) as its DNS SAN.
>>> If the policy lists that (shared) name as what's expected in the certificate,
>>> then authentication succeeds when the MX host's certificate matches one of
>>> the allowed names.
>> 
>> That's interesting. I think it's not actually that big a change--we just get rid of the MX host filtering and instead just apply the logic to validation. 
>> 
>> Downsides:
>> 
>> 1. Misconfigurations _may_ be less obvious without connecting to
>> the SMTP server. That is, today, you can spot some kinds of
>> misconfigurations by merely looking at the DNS (so for example
>> my test tool here http://sts.x.af0.net/ first looks at  DNS, and
>> only then tries SMTP connections).
>> 
>> 2. As you say, it requires some changes to server certificate
>> validation, but not much. 
>> 
>> I don't consider #1 compelling. So this seems fairly reasonable
>> to me, but I will let others chime in.
> 
> FWIW, I'm nervous about the idea of introducing non-standard
> server cert validation. It's not that complex, but certainly
> unexpected to people with experience deploying HTTPS.

Well, TLS for MTA-to-MTA SMTP *is* very different from TLS
for HTTPS.  Reasoning by analogy with HTTPS often leads to
incorrect conclusions.  So, from my perspective, looking more
obviously different from HTTPS is a feature. :-)

> It also looks like some of the rationale is to enable reuse of
> website keys/certs,

No, not *reuse*, rather compatibility with pre-STS practice.
Because MX records are untrusted absent DNSSEC, there is an
existing practice to employ the recipient domain, rather than
the MX hostname, as the DNS name in the certificate.  This
is one with "UCC" certificates.

I'm one of the early instigators of this practice.  I introduced
it with Postfix "secure" TLS policy, and later recommended it to
Microsoft for implementation in Exchange 2007.

   http://www.postfix.org/postconf.5.html#smtp_tls_security_level
   http://www.postfix.org/TLS_README.html#client_tls_limits
   https://technet.microsoft.com/en-us/library/bb266978(v=exchg.80).aspx

So the idea is not "sharing", but compatibility with existing practice,
as some domains may employ both STS and explicit TLS peering with
business partners.  The main motivation for the proposal is to get
out of the way of MX host selection and constrain just certificate
matching.

> which while valid probably isn't desirable because of the risks of
> reusing the same keys for multiple purposes/with multiple software
> configurations (as was demonstrated in the DROWN paper
> https://drownattack.com/

Ironic you mention DROWN:

    DROWN: Breaking TLS using SSLv2

    Nimrod Aviram, Sebastian Schinzel, Juraj Somorovsky,
    Nadia Heninger, Maik Dankel, Jens Steube5, Luke Valenta,
    David Adrian, J. Alex Halderman, Viktor Dukhovni[7],
    Emilia Käsper, Shaanan Cohney, Susanne Engels,
    Christof Paar and Yuval Shavitt

    [7] Two Sigma/OpenSSL

For the record, I do not recommend sharing a single
certificate among multiple MX hosts, or between email
and other services.  In addition to DROWN, (which really
helped drive SSLv2 support out of the ecosystem).

The primary reason to avoid sharing certificates among MX
hosts is to avoid a single point of failure.  Operational
errors in shared certificate/key rotation tend to break
all the MX hosts at once.  The operational issue dwarfs
DROWN in its significance.

-- 
	Viktor.