On Fri, Oct 13, 2017 at 04:30:01PM +0100, Ivan Ristic wrote:
> Personally, I think SMTP server certificates should match only their own
> names. If virtual SMTP hosting is desired, it can be done either with one
> certificate and multiple hostnames, or via SNI and individual certificates.
Prior to DANE and STS, the *only* way to avoid MiTM attacks on SMTP
via MX lookup forgery was to authenticate the nexthop (typically
recipient) domain, *rather than* the MX hostname. See:
http://www.postfix.org/TLS_README.html#client_tls_limits
http://www.postfix.org/TLS_README.html#client_tls_levels
http://www.postfix.org/TLS_README.html#client_tls_secure
Validating the destination domain has a been a Postfix TLS security
mechanism since ~2006 and subsequently in Microsoft Exchange since
~2007. Thus there are (a minority) of domains whose certificates
are designed to work under that security model.
> People are not just going to enable MTA-STS with their existing
> certificates. They're going to read someone's deployment guide, maybe
> glance at the RFC, go through the motions, check with a testing tool (I
> plan to write one), and deploy.
Perhaps so, and then to support multiple flavours of client auth
they'd need certificates that list both the domain and the MX
hostname as DNS-ID subject altnames.
> The simplest deployment use-case (e.g., one that I expect to be using for
> my business) is that I use MTA-STS to "approve" the use of third-party MX
> servers for my email. The third party only needs to ensure they have valid
> certificates for their own hostnames, nothing else. In this case, virtual
> hosting would be just extreme vanity, because who looks at MX servers'
> names? :)
And indeed the current STS draft in no way precludes that. It does
however, also support domains that list the domain and not the MX
hostname in their certificates.
> I understand that there is a lot of mess out there, but a new RFC is a
> perfect (and practically only) opportunity to improve things, and that's
> what I am arguing for.
I should note that certificates designed to work with pre-DANE/STS
security requirements are not a "mess".
You're arguing to leave those behind, and/or at least always list
the MX hostname. This reversal could be done, at the cost of
placing more strict requirements on the server certificates.
This would require adding language that stresses that all MX
hostnames obtained from DNS (whether they match the STS policy or
not) MUST be taken into account when an MTA performs routing loop
elimination for domains for which its own name (or some implementations
names that resolve to one or more of its own network addresses) is
one of the designated MX hosts.
Any skipping of MX hosts that don't match the STS policy can ONLY
take place after all MX hosts with a preference equal or worse
(larger) than the sending MTAs have been removed from the list.
In other words, STS would filter only connection initiation, not
MX loop elimination.
--
Viktor.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
