> On Mar 26, 2017, at 3:56 PM, David Illsley <[email protected]> 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. _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
