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 <o...@delong.com> wrote: > > > On Jan 11, 2019, at 09:38 , Viruthagiri Thirumavalavan <g...@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.
