> On Oct 23, 2017, at 4:56 PM, Ivan Ristic <[email protected]> wrote:
>
> Correct me if I am wrong, but at present no one checks if presented SMTP
> certificates are valid. In fact, a major reason we need MTA-STS is to make a
> clean start. You're not going to get the real-world data you're looking for
> because why would anyone bother when all certificates are being ignored, and
> MTAs downgrade to plaintext anyway.
>
> SNI was not in SSL 3.0 and TLS 1.0 because back then there was no need for
> it. And now, 20+ years, we have this:
>
>
> https://developer.akamai.com/blog/2017/10/20/encrypting-web-need-support-tls-sni-remaining-clients/
>
> The real question is how shall we protect email 20+ years from now. And, if
> SNI is not mandated now, what hoops shall we have to go through to make
> things right :)
>
> Thus, my view is that MTA-STS should be a clean and robust protocol, designed
> learning from mistakes of the past.
These are generalities that ignore the specific issues at hand.
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.
I still see no discussion of the use-cases that do or not motivate
the need for TLS virtual hosting with MTA-to-MTA (port 25) SMTP.
Let's not waste time on vague generalities.
Carping on TLS security in SMTP counter-productive, SMTP encrypts
a larger fraction of its traffic than the web does, precisely
because it is opportunistic. Setting the bar too high can often
reduce overall security, RFC7435 is pertinent here.
--
Viktor.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
