Viktor, thanks for the pointer to RFC 7672. Their section 8.1 covers SNI, and I propose to add something similar to MTA-STS.
Requiring SNI support in MTA-STS clients (for both HTTP and SMTP traffic) doesn't force any particular server/certificate deployment model. It just ensures that the target host is included in the TLS handshake via the SNI extension. It's up to the server to decide whether it wants to use that information or ignore it. It's extra information that can be ignored. Better to have it and not use it, then not have it but need to use it. The only intention here is to avoid deployment of MTA-STS without SNI, which would effectively make it impossible to ever use it! It took the HTTPS world a decade to get over that problem, having to wait for Windows XP to die away. Inability to use SNI held back mass-virtual hosting and SaaS service because setting up hosting required networking changes and dedicated IP addresses. It was a huge mess. I'll take a go at the possible wording, drawing from RFC 7672: "To ensure that the server sends the right certificate chain, the SMTP client MUST have support for the TLS SNI extension. When connecting to a HTTP server to retrieve the MTA-STS policy, the SNI extension MUST contain the domain name that hosts the policy. When connecting to an SMTP server, the SNI extension MUST contain the ??? domain name. HTTP servers used to deliver MTA-STS policies MUST have support for the TLS SNI extension and MAY rely on SNI to determine which certificate chain to present to the client. In either case, HTTP servers MUST respond with a certificate chain that matches the policy domain name or abort the TLS handshake if unable to do so. SMTP servers MUST have support for the TLS SNI extension and MAY rely on SNI to determine which certificate chain to present to the client. If the client sends no SNI extension or sends an SNI extension for an unsupported domain, the server MUST simply send some fallback certificate chain of its choice. The reason for not enforcing strict matching of the requested SNI hostname is that MTA-STS TLS clients may be typically willing to accept multiple server names but can only send one name in the SNI extension. The server's fallback certificate may match a different name acceptable to the client, e.g., the original next-hop domain." I made the wording above so that it's compatible with the current MX filtering process. If we do end up changing it, we'll need to update the wording. Also, we need to figure out what hostname will be placed in the SNI extension: the hostname of the MX server itself or the recipient domain name. As it stands, I suppose the latter. On Mon, Oct 16, 2017 at 11:48 PM, Viktor Dukhovni <[email protected]> wrote: > On Mon, Oct 16, 2017 at 11:29:38PM +0200, Daniel Margolis wrote: > > > This is about > > using SNI for hosting the policy (which is already HTTPS). I don't > believe > > SNI brings any value for the MXs themselves (i.e. the SMTP connection). > In > > fact, I can't think of any case where someone would want that. Can you > give > > an example where it would be desirable, or where not supporting SNI would > > force a provider to split traffic? > > RFC7672 (SMTP Opportunistic DANE TLS) specifically requires SNI > for the SMTP STARTTLS handshake. This is because the MX hosts used > by some domains are CNAME aliases (despite requirements to the > contrary) and CNAMEs are broadly supported by MTAs. As a result, > we sometimes find either of: > > example.com. IN MX 0 smtp.example.com. > smtp.example.com. IN CNAME smtp.provider.net. > > example.com. IN MX 0 smtp.example.com. > smtp.example.com. IN A 192.0.2.1 ; Same as... > smtp.provider.net. IN A 192.0.2.1 > > In such cases, the provider may need to be able to present a > certificate for the client's domain. > > Note, I am not saying that it is a good idea to alias provider MX > hosts with vanity names from the client domain, indeed I typically > advise against this, and yet it is done with some frequency. > > So it may be prudent to clarify whether STS is compatible with this > deployment model. Perhaps STS can require that the default (sans > SNI) certificate provided by the MX host match the policy. And > thereby rule out potential SNI-dependence. > > Two examples: > > lesando.network. IN MX 10 mail.lesando.de. > mail.lesando.de. IN CNAME mail.ud13.udmedia.de. > > jachthavenwolderwijd.nl. IN MX 20 mail.wolderwijd.nl. > mail.wolderwijd.nl. IN CNAME mx1.bit.nl. > > -- > Viktor. > > _______________________________________________ > Uta mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/uta > -- Ivan
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
