On Mon, Oct 23, 2017 at 10:45 PM, Viktor Dukhovni <ietf-d...@dukhovni.org> wrote:
> > > > On Oct 23, 2017, at 4:56 PM, Ivan Ristic <ivan.ris...@gmail.com> 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. Perhaps we don't agree with what's the specific issue at hand. For me, it's the fact that you wish to go against the lessons-learned elsewhere, which came at a very high cost. I made a point how 20 years ago others couldn't perceive the need for SNI in TLS, knowing what they knew then. But you responded to that with hand waving. > 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. In other words, we accept that we don't know everything and design so that our mistakes can be rectified. 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. > 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. Actually, virtually all important HTTP traffic is protected with not only strong encryption, but also with certificate checking, HSTS, and even public key pinning. In the meantime, anyone can downgrade an SMTP connection to plaintext. If SMTP is better at encrypting over HTTP, it's only because email is concentrated in the hands of several big providers. > Setting the bar too high can often > reduce overall security, RFC7435 is pertinent here. > > -- > Viktor. > > _______________________________________________ > 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
