<div dir="ltr"><div dir="ltr">Hello Owen, <div><br></div><div>Thanks for the input.<br><div><br></div><div>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.</div></div><div><br></div><div>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. </div><div><br></div><div>However people are against that proposal too because of IDN and A record fallback issues. I <a href="https://gist.github.com/mistergiri/a4c9a5f1c26fd7003ebc0652af95d314#internationalized-domain-names">tested IDN</a> and couldn't find any issues. </div><div><br></div><div>As for A record, If this proposal must support it too for MX fallback mechanism, then I don't think this proposal gonna work.    </div><div><br></div><div>To answer your question</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">How would (2) be different from the previous SMTPS port 465 which was deprecated?</blockquote><div><br></div><div>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 <a href="https://medium.com/@Viruthagiri/smtp-ports-25-vs-587-vs-465-de1046f57636">look here</a>.</div><div><br></div><div>Thanks</div></div></div><br><div class="gmail_quote"><div dir="ltr">On Sun, Jan 13, 2019 at 9:45 AM Owen DeLong <<a href="mailto:owen@delong.com">owen@delong.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><br><div><br><blockquote type="cite"><div>On Jan 11, 2019, at 09:38 , Viruthagiri Thirumavalavan <<a href="mailto:giri@dombox.org" target="_blank">giri@dombox.org</a>> wrote:</div><br class="gmail-m_3539702937218411640Apple-interchange-newline"><div><div dir="ltr"><div dir="ltr"><div>Hello NANOG, Belated new year wishes.</div><div><br></div><div>I would like to gather some feedback from you all.</div><div><br></div><div>I'm trying to propose two things to the Internet Standard and it's related to SMTP. </div><div><br></div><div>(1) STARTTLS downgrade protection in a dead simple way</div><div><br></div><div>(2) SMTPS (Implicit TLS) on a new port (26). This is totally optional. </div></div></div></div></blockquote><div><br></div>How would (2) be different from the previous SMTPS port 465 which was deprecated?</div><div><br><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div>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</div></div></div></blockquote><div><br></div><a href="https://www.mailgun.com/blog/which-smtp-port-understanding-ports-25-465-587" target="_blank">https://www.mailgun.com/blog/which-smtp-port-understanding-ports-25-465-587</a></div><div><br></div><div>Seems to agree with my recollection that 465 was never specifically for submission and that it was deprecated shortly after the introduction of STARTTLS.</div><div><br></div><div><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div>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.</div><div><br></div><div>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.</div></div></div></blockquote><div><br></div>As a general rule, I think separate ports for TLS-ified versions of existing protocols isn’t the right solution and simply wastes ports.</div><div><br></div><div>Thinking this through, I don’t think you actually solve the existing problem, either.</div><div><br></div><div>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):</div><div><br></div><div><span class="gmail-m_3539702937218411640Apple-tab-span" style="white-space:pre-wrap">   </span>1.<span class="gmail-m_3539702937218411640Apple-tab-span" style="white-space:pre-wrap">  </span>Remote MTA supports port 26 and STARTTLS on port 25.</div><div><span class="gmail-m_3539702937218411640Apple-tab-span" style="white-space:pre-wrap"> </span>2.<span class="gmail-m_3539702937218411640Apple-tab-span" style="white-space:pre-wrap">  </span>Remote MTA supports only port 25 with STARTTLS</div><div><span class="gmail-m_3539702937218411640Apple-tab-span" style="white-space:pre-wrap">       </span>3.<span class="gmail-m_3539702937218411640Apple-tab-span" style="white-space:pre-wrap">  </span>Remote MTA supports only port 25 in clear text</div><div><br></div><div>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:</div><div><br></div><div><span class="gmail-m_3539702937218411640Apple-tab-span" style="white-space:pre-wrap">      </span>1.<span class="gmail-m_3539702937218411640Apple-tab-span" style="white-space:pre-wrap">  </span>If port 26 is attempted, Send back a TCP RST or ICMP port unreachable message in response to the connection attempt on port 26.</div><div><span class="gmail-m_3539702937218411640Apple-tab-span" style="white-space:pre-wrap">     </span>2.<span class="gmail-m_3539702937218411640Apple-tab-span" style="white-space:pre-wrap">  </span>Conventional STARTTLS Downgrade attack.</div><div><br></div><div>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.</div><div><br></div><div><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div><br></div><div>This proposal offers two ways.</div><div><br></div><div>(1) STARTTLS Prefix</div><div><br></div><div>Use this prefix only to deal with STARTTLS downgrade issue.</div><div><br></div><div>e.g. <a href="http://mx1.example.com/" target="_blank">mx1.example.com</a> should be prefixed like <a href="http://starttls-mx1.example.com/" target="_blank">starttls-mx1.example.com</a>.</div><div><br></div><div>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”.</div></div></div></blockquote><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div><br></div><div>(2) SMTPS Prefix</div><div><br></div><div>Use this prefix if you wanna support Implicit TLS on port 26 and Opportunistic TLS on port 25.</div><div><br></div><div>e.g. <a href="http://mx1.example.com/" target="_blank">mx1.example.com</a> should be prefixed like <a href="http://smtps-mx1.example.com/" target="_blank">smtps-mx1.example.com</a>.</div><div><br></div><div>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".</div><div><br></div><div>In "starttls-" prefix port 25 <b>MUST</b> support encryption with <b>valid SSL</b> certificates.</div><div><br></div><div>In "smtps-" prefix, <b>BOTH</b> port 26 and port 25 <b>MUST</b> support encryption with <b>valid SSL</b> certificates.</div><div><br></div><div>Note: You need to enable DNSSEC to prevent MX record spoofing. My proposal highly recommends DNSSEC. Not mandates that. </div></div></div></blockquote><div><br></div>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.</div><div><br></div><div><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div>What IETF Mailing list thinks? - "Implicit TLS doesn't offer any additional security than a downgrade protected STARTTLS. Let's not waste a port.”</div></div></div></blockquote><div><br></div>I’m inclined to agree here… See above.</div><div><br><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div>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. </div></div></div></blockquote><div><br></div>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:</div><div><br></div><div><span class="gmail-m_3539702937218411640Apple-tab-span" style="white-space:pre-wrap">        </span>1.<span class="gmail-m_3539702937218411640Apple-tab-span" style="white-space:pre-wrap">  </span>Can’t make up it’s mind about TLS on SMTP (yes, 465; no, use STARTTLS instead; yes, but this time on port 26)</div><div><span class="gmail-m_3539702937218411640Apple-tab-span" style="white-space:pre-wrap">    </span>2.<span class="gmail-m_3539702937218411640Apple-tab-span" style="white-space:pre-wrap">  </span>Doesn’t care about wasting well-known port numbers (which are in relatively short supply)</div><div><br></div><div>I’d consider both of these to be a pretty negative vibe.</div><div><br></div><div><br><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div>What the world thinks? - <a href="https://gist.github.com/mistergiri/138fc46ae401b7492662a32409edb07f" target="_blank">https://gist.github.com/mistergiri/138fc46ae401b7492662a32409edb07f</a></div></div></div></blockquote><div><br></div>Most of the comments from the world appear not to fully understand the problem and have not thought through the implications I mention above.</div><div><br></div><div>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?</div><div><br></div><div>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.</div><div><br></div><div>Owen</div><div><br></div></div></blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr">Best Regards,<div><br><div>Viruthagiri Thirumavalavan</div><div><span style="font-size:12.8px">Dombox, Inc.</span><br></div></div></div></div></div></div></div>