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

Sun Jan 13 05:08:46 UTC 2019

Hello Owen,

Thanks for the input.

This thread is not about my SMTPS proposal anymore. I'm already convinced
that's not gonna work since I couldn't find any strong advantages over
Opportunistic TLS.

But I'm still open for suggestions for my "starttls-" prefix proposal. It's
just trying to prevent STARTTLS downgrade issues in a very simple way.

However people are against that proposal too because of IDN and A record
fallback issues. I tested IDN
<https://gist.github.com/mistergiri/a4c9a5f1c26fd7003ebc0652af95d314#internationalized-domain-names>
and couldn't find any issues.

As for A record, If this proposal must support it too for MX fallback
mechanism, then I don't think this proposal gonna work.

To answer your question

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

Port 465 reintroduced in 2018 as submission port in rfc8314. Port 465 never
used for relay as far as I know. My SMTPS proposal is all about relay.  I
have done some research about the ports. If you want, please take look here
<https://medium.com/@Viruthagiri/smtp-ports-25-vs-587-vs-465-de1046f57636>.

Thanks

On Sun, Jan 13, 2019 at 9:45 AM Owen DeLong <owen at delong.com> wrote:

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

-- 
Best Regards,

Viruthagiri Thirumavalavan
Dombox, Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20190113/146d34e0/attachment.html>