On Jan 11, 2019, at 09:38 , Viruthagiri Thirumavalavan <giri@dombox.org> 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. 

How would (2) be different from the previous SMTPS port 465 which was deprecated?

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

https://www.mailgun.com/blog/which-smtp-port-understanding-ports-25-465-587

Seems to agree with my recollection that 465 was never specifically for submission and that it was deprecated shortly after the introduction of STARTTLS.

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.

As a general rule, I think separate ports for TLS-ified versions of existing protocols isn’t the right solution and simply wastes ports.

Thinking this through, I don’t think you actually solve the existing problem, either.

A client wanting to use your new port 26 would need to fall back to port 25 by default if the MTA at the other end didn’t support port 26. As I see it, there are the following remote MTA possibilities (ignoring submission on 587 and ignoring any possible legacy implementation on 465 for now):

1. Remote MTA supports port 26 and STARTTLS on port 25.

2. Remote MTA supports only port 25 with STARTTLS

3. Remote MTA supports only port 25 in clear text

So long as the client will fall back to port 25, you have an identical vulnerability to man in the middle attack in all 3 cases:

1. If port 26 is attempted, Send back a TCP RST or ICMP port unreachable message in response to the connection attempt on port 26.

2. Conventional STARTTLS Downgrade attack.

If you have some way to remove the need for fallback to port 25, then you can in all of those instances simply remove the willingness to communicate with an MTA server that does not offer STARTTLS as part of the negotiable option set in response to the EHLO, thus eliminating the acceptance of a downgrade attack.

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. 

So the naming convention thing might be usable, but I don’t see any advantage to the explicit TLS port vs. just providing naming-based hints about STARTTLS.

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

I’m inclined to agree here… See above.

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. 

I don’t think so. First, I think the word you actually want is explicit (specified) vs. implicit (implied). Second, I’m not convinced that it is any more explicit. If you have an immutable out-of-band way of communicating STARTTLS support, then I don’t see port-based explicit as being in any way superior to rule-based explicit use of STARTTLS. So I’m not convinced that chewing up a port just to feel good about explicitness offers any tangible benefit. Third, I think rather than conveying the positive vibe you wish to imply that it would, instead, indicate that the IETF:

1. Can’t make up it’s mind about TLS on SMTP (yes, 465; no, use STARTTLS instead; yes, but this time on port 26)

2. Doesn’t care about wasting well-known port numbers (which are in relatively short supply)

I’d consider both of these to be a pretty negative vibe.

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

Most of the comments from the world appear not to fully understand the problem and have not thought through the implications I mention above.

If your intent is for all upgraded client sides not to ever try port 25 (thus render them unable to connect to servers that don’t support your port 26 hack), then what do you gain vs. the already present option to tell your software to reject any MTA that doesn’t offer STARTTLS as an option or fails to negotiate TLS when you request it?

If that’s an option, just turn that on and you’ve got all the same security this solution would offer without wasting a port.

Owen