Hello NANOG, Belated new year wishes.

I would like to gather some feedback from you all.

I'm trying to propose two things to the Internet Standard and it's related to SMTP. 

(1) STARTTLS downgrade protection in a dead simple way

(2) SMTPS (Implicit TLS) on a new port (26). This is totally optional. 

I posted my proposal in IETF mailing list. I got very good feedback there. Some support my proposal. Many are against it.

I would love to know where you stand on this proposal. Let me give you the abstract first.

-----

SMTP is still suffering from downgrade attacks like STRIPTLS. While we have "Opportunistic TLS", we still don't have "Implicit TLS" in the SMTP.

Don't take this in the wrong way. We do have "Implicit TLS" for "SMTP Submission" on port 465. But we don't have a secure port 25 alternative. i.e. The real SMTPS

Both MTA-STS and MTA-DANE tries to fix the STARTTLS downgrade issue. However the implementation is not simple. The former requires a HTTPS server and the latter requires DNSSEC to even get started.

This proposal fixes STARTTLS downgrade issue and propose a new port 26, an "Implicit TLS" alternative for port 25 and recommends the MX server to signal the port via a prefix.

This proposal offers two ways.

(1) STARTTLS Prefix

Use this prefix only to deal with STARTTLS downgrade issue.

e.g. mx1.example.com should be prefixed like starttls-mx1.example.com.

Where "starttls-" says "Our port 25 supports Opportunistic TLS. So if STARTTLS command not found in the EHLO response or certificate is invalid, then drop the connection".

(2) SMTPS Prefix

Use this prefix if you wanna support Implicit TLS on port 26 and Opportunistic TLS on port 25.

e.g. mx1.example.com should be prefixed like smtps-mx1.example.com.

Where "smtps-" 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".

In "starttls-" prefix port 25 MUST support encryption with valid SSL certificates.

In "smtps-" prefix, BOTH port 26 and port 25 MUST support encryption with valid SSL certificates.

Note: You need to enable DNSSEC to prevent MX record spoofing. My proposal highly recommends DNSSEC. Not mandates that. 

-------

What IETF Mailing list thinks? - "Implicit TLS doesn't offer any additional security than a downgrade protected STARTTLS. Let's not waste a port."

What I think? - Implicit TLS still fall under the "best practices". So it will send out the positive vibe that IETF still cares about email security. 

What the world thinks? - https://gist.github.com/mistergiri/138fc46ae401b7492662a32409edb07f

What do you all think? - https://medium.com/@dombox/smtp-over-tls-on-port-26-efc67e8a99ce