On Mon, Oct 23, 2017 at 7:37 PM, Viktor Dukhovni <ietf-d...@dukhovni.org> wrote:
> > In other words, where's the data that makes it possible to > understand whether SNI is actually useful, or mostly just > an auto-pilot design to look like virtual-hosting with HTTPS > where the requirements are very different. > 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. -- > Viktor. > > P.S. > > Some may notice that I failed to do the necessary research > on this for RFC7672, and just assumed that SNI might be > needed and chose to require it, just in case. Sorry about > that... At the time I wanted above all else to maximize > the chance that an advertised TLSA record would match, > and SNI could hypothetically be needed. I did not consider > proscribing such a dependency. The same questions should > have applied. > > _______________________________________________ > Uta mailing list > Uta@ietf.org > https://www.ietf.org/mailman/listinfo/uta > -- Ivan
_______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
