I believe Google's MTAs are sending SNI. But the only time this would matter would be for cases like https://support.google.com/a/answer/2520500?hl=en, since ordinarily nobody is validating identities on server-to-server SMTP.
Regarding arguments in favor of supporting SNI, Jim made the best attempt
in this thread to come up with a motivating use case, and I don't find it
very compelling. In his example (where two hosting providers merge
infrastructure), a) STS does not require that the hostnames actually match
the certificate presented (but only that the certificate match the
policy!), and b) even if the provider wants the hostname to match the
certificate, they can just use a single cert with multiple SANs to achieve
this.
To expand on this slightly, I believe the vanity hostname discussion was
(and my apologies for this) misleading. Even given Viktor's example
example.com. IN MX 0 smtp.example.com.
smtp.example.com. IN CNAME smtp.provider.net.
there's no need for SNI *or* a certificate that has multiple SANs (for
example.com and provider.net); the STS policy in all cases matches "
provider.net." The only reason to desire the certificate hostname to be "
example.com" is if example.com wants to have two different MX records
pointing at (say) provider1.net and provider2.com, and wants both to share
the "example.com" certificate--and even this is nonsensical, since they can
just have a policy that lists multiple acceptable "mx" patterns ("mx:
provider1.net, mx:provider2.com, mx: example.com", with the third thrown in
for safety!).
Ivan, you're definitely right that we may not be able to foresee all the
uses here, but I do think there are clear *differences* between HTTP and
SMTP that make the analogy imperfect. In HTTP, there are two specific
constraints not applicable to our use case which motivate SNI: first, the
hostname is a UI component in the browser, so when you have two different
organizations sharing a HTTP endpoint, they don't want to share a hostname;
second, the hostname is required to match the certificate. The first is not
true for SMTP (the MX hostname doesn't really matter in the UX) and the
second is not true for STS (the "mx" pattern constrains the certificate and
not the DNS record).
Regarding arguments against SNI, I don't think the privacy risk is
significant, or really a reason not to require SNI. The only case I see
where SNI introduces an actual privacy leak that wasn't present before is
the case of multi-tenant shared-IP hosting where instead you would use a
shared cert with multiple SANs. Otherwise, if (instead of SNI) you use
dedicated IPs, you of course have same privacy leak.
In short, I see neither strong arguments against SNI nor any particular
reason to support it. I agree with Viktor that we can just require it (with
Ivan's language) so as to move the spec forward and be future proof. That
sounds less than satisfying to me, but it's not something I'd lose sleep
over.
I'll try to ask around off-list about SNI usage. But a better motivating
example from the group here would probably also help the discussion.
Dan
On Tue, Oct 24, 2017 at 1:27 AM, Viktor Dukhovni <ietf-d...@dukhovni.org>
wrote:
>
>
> > On Oct 23, 2017, at 6:39 PM, Ivan Ristic <ivan.ris...@gmail.com> wrote:
> >
> >> If we conclude that there's no need for virtual-hosting of TLS
> >> (multiple chains at the same transport endpoint) with MTA-to-MTA
> >> SMTP, then there's demonstrably no need for SNI, no matter how
> >> much goodness it brings to the Web.
> >
> > We can conclude that, and it may be true today, but it would still
> > be prudent to mandate SNI just so that it could be used at some point
> > in the future, should the need arise.
>
> Well, we are designing a standard for the foreseeable future, and some
> crystal ball gazing is appropriate. We should make a best-effort to
> determine what might be reasonably useful, and produce a standard
> that meets reasonable requirements, that is not bloated with
> features that are unlikely to be useful or perform reliably.
>
> Your past experience with the Web is a good reason to not dismiss
> flexibility to lightly, so the issue is worth discussing, but it
> does not justify SNI on merely a "we might need it some day" basis.
> There really does need to be a reasonable use-case.
>
> > In other words, we accept that we don't know everything and design so
> > that our mistakes can be rectified.
>
> Sometimes too many features are also a mistake that is hard to rectify.
>
> > If the group strongly believes there is a privacy issue with SNI that
> > makes it not acceptable, so be it. But I haven't seen other compelling
> > arguments against.
>
> All I'm saying is: Let's discuss whether there's a plausible use-case
> for SNI in MTA-to-MTA SMTP. Not whether SNI proved to be needed for
> HTTP. HTTP lacks an equivalent of MX indirection, so the requirements
> are different.
>
> Who needs SNI for port 25 SMTP, are they a small minority and can they
> make do without. Is there significant customer demand, ...
>
> This may be too tiresome, and perhaps the easy way out it to throw in
> the kitchen sink so that the obstacle to progressing the draft goes
> away, but that sadly leaves the questions unaddressed and the spec
> potentially bloated with a pointless privacy leak.
>
> I think that if Google, et. al. read the tea leaves, chatted with
> some more email service operators (rather than TLS geeks like us)
> there'd probably be a sensible answer to this question, and I for
> one would go with whatever best matches expected needs.
>
> --
> Viktor.
>
> _______________________________________________
> Uta mailing list
> Uta@ietf.org
> https://www.ietf.org/mailman/listinfo/uta
>
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
