> 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
