> > I stand by the "has no merit" assessment. Nobody is going to turn > off port 25 support overnight.
I presume you didn't read my document. It's all about turn off port 25 ten years from the standard publication date. Not overnight. This proposal would need to be able > to coëxist with the traditional port 25 SMTP service, but then it is > trivially vulnerable to the same downgrade attacks that it ostensibly > tries to avoid by using "implicit TLS" instead of "STARTTLS". Sure it can co-exist. I had this part. *The "26pref" says "We prefer if you connect to our SMTPS in port 26. But we also accept mails in port 25".* So let me amend that part *The "26pref" says "We prefer if you connect to our SMTPS in port 26. But we also accept mails in port 25. And our port 25 supports Opportunistic TLS. So if STARTTLS command not found in the EHLO response or certificate is invalid, then drop the connection".* Basically that means, who ever opt for "Implicit TLS" must also make sure that they have "Opportunistic TLS" with valid SSL certificate on port 25. Thus the client can decide either speak securely or don't speak at all. On Sun, Jan 6, 2019 at 8:43 AM Viktor Dukhovni <[email protected]> wrote: > On Sun, Jan 06, 2019 at 05:48:46AM +0530, Viruthagiri Thirumavalavan wrote: > > > > This adds complexity, without solving any problems. I'm afraid > > > this proposal has no merit. > > > * The attacker can just as easily block connections to port 26, > > > as filter out STARTTLS. > > > * This in no way addresses the authentication issues. > > > > I already addressed both issues in the document. Refer "Deprecation" and > > "Security Considerations" section. My proposal is all about deprecating > > "Plain Text" in port 25. > > I stand by the "has no merit" assessment. Nobody is going to turn > off port 25 support overnight. This proposal would need to be able > to coëxist with the traditional port 25 SMTP service, but then it is > trivially vulnerable to the same downgrade attacks that it ostensibly > tries to avoid by using "implicit TLS" instead of "STARTTLS". > > Indeed STARTTLS gives MTAs the opportunity to decline service prior > to completing the TLS handshake, which can be useful when the client > is e.g. listed on an RBL, or is performing TLS handshakes at an > excessive rate. > > Secure MTA-to-MTA SMTP does not require abandoning STARTTLS. Rather, > MTA-to-MTA SMTP security requires a downgrade-resistant signal of > when TLS is mandatory, and a robust means to authenticate the peer. > Neither of these is facilitated by this proposal. > > -- > Viktor. > > P.S. Everyone is of course free to post to the list some plausibly > (or even vaguely) on-topic content, and all posts made in good faith > are welcome. That said, I will not make any further comments in > this thread, as it rather looks like a dead-end. > > _______________________________________________ > Uta mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/uta > -- Best Regards, Viruthagiri Thirumavalavan Dombox, Inc.
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
