On Wed, Oct 18, 2017 at 9:39 AM, Ivan Ristic <ivan.ris...@gmail.com> wrote:
> Viktor, thanks for the pointer to RFC 7672. Their section 8.1 covers SNI, > and I propose to add something similar to MTA-STS. > ... > 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. > Apologies for replying to myself, but the latter makes no sense. When connecting to an SMTP server, the SNI extension should contain the hostname of the intended MX server. If someone wants a vanity MX server they can use a CNAME to ensure that the correct hostname is sent via TLS. On Mon, Oct 16, 2017 at 11:48 PM, Viktor Dukhovni <ietf-d...@dukhovni.org> > 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 >> Uta@ietf.org >> https://www.ietf.org/mailman/listinfo/uta >> > > > > -- > Ivan > -- Ivan
_______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
