On 10/18/2017 12:39 PM, Viktor Dukhovni wrote: > At present, Postfix always sends SNI when doing DANE and never otherwise. > The STS logic could be the same. Mind you, SNI does introduce a privacy > leak, since SNI is sent in the clear. So one could take the view that > the need for this is slim, and that the motivating use-case is not > compelling. Or one could support virtual-hosted "vanity" aliases for > MX hosts. Given DNS indirection from the domain to the MX hosts, the > case for virtual-hosting with alternate chains is much weaker in SMTP.
The use of SNI does indeed introduce a privacy leak. However, the leak only happens with "multiplexed servers", when a single server waiting for connections at a single IP address can serve multiple "virtual servers". In that case, the multiplexed server uses the SNI to direct the connection to the context of the "virtual server", and then use the appropriate certificate for that server. There is no real SNI leak when the IP address corresponds to a unique server -- the SNI would contain the string otherwise returned by "get host by address" or some equivalent API. But there is leak when the server is multiplexed. Which makes it a hard problem, because the multiplexed server needs to identify the target virtual server, and needs to do that before encryption keys are negotiated by TLS. The clear text SNI is the current solution to the problem. The TLS working group is well aware of this issue, and there is in fact work in progress to address it -- https://datatracker.ietf.org/doc/draft-ietf-tls-sni-encryption/. Since this is a really hard problem, you can expect progress to be slow. As Viktor says, the easy way for STS is to avoid the "multiplexed server" scenario. In fact, that's a pretty natural use of MX records. The MX record for "some-personal-server.com" would point to "mta.example.net", the SNI would be "mta.example.net", and the IP address in the IP header would be that of "mta.example.net". The SNI does not introduce a privacy leak in that scenario. -- Christian Huitema _______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
