SMTP Over TLS on Port 26 - Implicit TLS Proposal [Feedback Request]

Sat Jan 12 00:50:17 UTC 2019

Having been through this many times, I'd say that probably the best way 
to advocate for something is to advocate for what the *problem* is much 
more than what the *solution* is. Invariably, things are more complex 
than we imagine in the solution space and the people who inhabit that 
space are more than happy to inform you of it.

Writing an I-D on what the problem is can be a very useful exercise to 
rally support without putting on a bullseye on your back about a 
solution. I will say that downgrade attacks are taken seriously by the 
security geeks I know. But everything is messy, especially with 
something as ancient as email so listening is a virtue too.

Which isn't so say that running code is bad -- it's one of the best 
things about ietf -- but people have to understand why it's running at 
all :)

Mike, one of the authors of rfc 4871

On 1/11/19 9:38 AM, Viruthagiri Thirumavalavan wrote:
> 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 <http://mx1.example.com> should be prefixed like 
> starttls-mx1.example.com <http://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 <http://mx1.example.com> should be prefixed like 
> smtps-mx1.example.com <http://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
>
> -- 
> Best Regards,
>
> Viruthagiri Thirumavalavan
> Dombox, Inc.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20190111/6ece9075/attachment.html>