<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">If you are using DNS Records to prevent downgrades anyways, then there<br>should be no need nor valid justification for using an extra port number; the<br>client SMTP sender can be required to inspect the DNS Record and find in<br>the record a signal that TLS is mandatory, and the smtp client must not proceed<br>past EHLO other than to STARTTLS immediately.</blockquote><div><br></div><div>Yes that's what I meant in my proposal too. </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">For example, I may very well have a host named<br>"<a href="http://starttls-mx1.example.com/" rel="noreferrer" target="_blank">starttls-mx1.example.com</a>" today,<br>based on current standards which is not used solely for TLS SMTP, Or<br>it might not<br>even support TLS SMTP --- Significance cannot be added to strings in<br>the DNS that<br>did not exist in the original standard, due to potential conflicts<br>with existing implementations.</blockquote><div><br></div><div>Ok. That makes sense.</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">The DANE Facilities and other IETF drafts address this much more adequately.<br>See RFC8461 -- <a href="https://tools.ietf.org/html/rfc8461" rel="noreferrer" target="_blank">https://tools.ietf.org/html/rfc8461<br></a>RFC 8461 seems to solve the same problem and does a better job.</blockquote><div><br></div><div>This proposal just trying to do the job simpler. </div><div><br></div><div>Let me copy paste some part I posted in ietf-smtp forum. </div><div><br></div><div>----</div><div><br></div><div><div>DNSSEC already protects my DNS records from spoofing. So I believe all my DNS records are secure when I enable DNSSEC. </div><div><br></div><div>My domain is <a href="http://dombox.org/" target="_blank">dombox.org</a> and if I have mx records like</div><div><br></div><div><a href="http://mx1.dombox.org/" target="_blank">mx1.dombox.org</a></div><div><a href="http://mx2.dombox.org/" target="_blank">mx2.dombox.org</a></div><div><a href="http://mx3.dombox.org/" target="_blank">mx3.dombox.org</a></div><div><a href="http://mx4.dombox.org/" target="_blank">mx4.dombox.org</a></div><div><a href="http://mx5.dombox.org/" target="_blank">mx5.dombox.org</a> </div><div><br></div><div>then those MX records are already protected from forgery since I have now enabled DNSSEC. </div><div><br></div><div>Now I need to add DANE TLSA record to let the world know that my port 25 supports STARTTLS. So clients can detect downgrade issues.</div><div><br></div><div>The TLSA records looks like this.</div><div><br></div><div>25._<a href="http://tcp.mx1.dombox.org/" target="_blank">tcp.mx1.dombox.org</a>. IN TLSA 3 0 1 ae822a14fd5e56c213eeeb5d6755556980caf4c3f2531c1ec8eca3076f9b7e68<br></div><div>25._<a href="http://tcp.mx2.dombox.org/" target="_blank">tcp.mx2.dombox.org</a>. IN TLSA 3 0 1 ae822a14fd5e56c213eeeb5d6755556980caf4c3f2531c1ec8eca3076f9b7e68<br></div><div>25._<a href="http://tcp.mx3.dombox.org/" target="_blank">tcp.mx3.dombox.org</a>. IN TLSA 3 0 1 ae822a14fd5e56c213eeeb5d6755556980caf4c3f2531c1ec8eca3076f9b7e68<br></div><div>25._<a href="http://tcp.mx4.dombox.org/" target="_blank">tcp.mx4.dombox.org</a>. IN TLSA 3 0 1 ae822a14fd5e56c213eeeb5d6755556980caf4c3f2531c1ec8eca3076f9b7e68<br></div><div>25._<a href="http://tcp.mx5.dombox.org/" target="_blank">tcp.mx5.dombox.org</a>. IN TLSA 3 0 1 ae822a14fd5e56c213eeeb5d6755556980caf4c3f2531c1ec8eca3076f9b7e68<br></div><div><br></div><div>I think we can can simplify that part via CNAME record. But, let's not go there.</div><div><br></div><div>Now my first question is, does that "fingerprint" adds any security in a "Third party CA" system? Or it's there just to be compatible with the DANE system since DANE is not a mail specific system? </div><div><br></div><div>My second question, if my MX records are configured to use google MX servers (e.g. <a href="http://aspmx.l.google.com/" target="_blank">aspmx.l.google.com</a>) whose job is to configure those DANE TLSA records?</div><div><br></div><div>Google or Me?</div><div><br></div><div>I believe it's not my job. Because there is no easy way I can have Google MX server certificate fingerprint unless google provides it. Even if they provide it, if google change their certificate for security reasons in the future, then that's gonna break millions of domains that depends on Google mail servers. So that would be a poor design.</div><div><br></div><div>If I'm not wrong Google is against DNSSEC. So there is no way they are gonna configure DANE records like this.</div><div><br></div><div><div>25._<a href="http://tcp.aspmx.l.google.com/" target="_blank">tcp.aspmx.l.google.com</a>. IN TLSA 3 0 1 ae822a14fd5e56c213eeeb5d6755556980caf4c3f2531c1ec8eca3076f9b7e68<br></div><div>25._<a href="http://tcp.alt1.aspmx.l.google.com/" target="_blank">tcp.alt1.aspmx.l.google.com</a>. IN TLSA 3 0 1 ae822a14fd5e56c213eeeb5d6755556980caf4c3f2531c1ec8eca3076f9b7e68<br></div><div>25._<a href="http://tcp.alt2.aspmx.l.google.com/" target="_blank">tcp.alt2.aspmx.l.google.com</a>. IN TLSA 3 0 1 ae822a14fd5e56c213eeeb5d6755556980caf4c3f2531c1ec8eca3076f9b7e68<br></div><div>25._<a href="http://tcp.alt3.aspmx.l.google.com/" target="_blank">tcp.alt3.aspmx.l.google.com</a>. IN TLSA 3 0 1 ae822a14fd5e56c213eeeb5d6755556980caf4c3f2531c1ec8eca3076f9b7e68<br></div><div>25._<a href="http://tcp.alt4.aspmx.l.google.com/" target="_blank">tcp.alt4.aspmx.l.google.com</a>. IN TLSA 3 0 1 ae822a14fd5e56c213eeeb5d6755556980caf4c3f2531c1ec8eca3076f9b7e68<br></div><div><br></div><div>Hopefully, That is one of the reason why MTA-STS got introduced. </div><div><br></div><div>Even if I love DNSSEC and support it in my domain, Google sets the rules here since I'm relying on their mail hosting. I have no other way, other than supporting MTA-STS since google is against DNSSEC.</div></div></div><div><br></div><div>------</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">You could equally suggest a SMTP Banner Pattern for such a feature;<br>instead of trying to overload<br>the meaning of some DNS label substring.<br>220 <a href="http://smtp.example.com/" rel="noreferrer" target="_blank">smtp.example.com</a> "Welcome to the <a href="http://example.com/" rel="noreferrer" target="_blank">example.com</a> SMTP Server"<br>strict-tls=*.<a href="http://example.com/" rel="noreferrer" target="_blank">example.com</a>; max-age=604800; includeSubDomains</blockquote><div><br></div><div>It's still vulnerable to MiTM attack right? </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">Rewrites the MX response to DNS queries if the record begins with<br>"smtps-XXX" to "<RANDOMUID>-XXX"<br>with the same IP addresses in the additional section and caches the A<br>response for the generated hostnames.</blockquote><div> </div><div>My solution is vulnerable to MiTM without DNSSEC. I guess I should update my proposal saying DNSSEC mandatory. But if you believe the prefix solution itself flawed, the what's the point. </div><div><br></div><div>Thanks for the input. Those are all very helpful comments.</div></div><br><div class="gmail_quote"><div dir="ltr">On Sun, Jan 13, 2019 at 11:36 PM Jimmy Hess <<a href="mailto:mysidia@gmail.com" target="_blank">mysidia@gmail.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">On Fri, Jan 11, 2019 at 6:23 PM Viruthagiri Thirumavalavan<br>
<<a href="mailto:giri@dombox.org" target="_blank">giri@dombox.org</a>> wrote:<br>
<br>
> I'm trying to propose two things to the Internet Standard and it's related to SMTP.<br>
> (1) STARTTLS downgrade protection in a dead simple way<br>
> (2) SMTPS (Implicit TLS) on a new port (26). This is totally optional.<br>
<br>
A new Well-Known Port allocation should come from IANA if required, not<br>
by random cherrypicking; Port 26 has not been assigned for transport, and<br>
might be required for a different application. 465 is already allocated for<br>
SMTP over TLS.<br>
<br>
If you are using DNS Records to prevent downgrades anyways, then there<br>
should be no need nor valid justification for using an extra port number; the<br>
client SMTP sender can be required to inspect the DNS Record and find in<br>
the record a signal that TLS is mandatory, and the smtp client must not proceed<br>
past EHLO other than to STARTTLS immediately.<br>
<br>
> e.g. <a href="http://mx1.example.com" rel="noreferrer" target="_blank">mx1.example.com</a> should be prefixed like <a href="http://starttls-mx1.example.com" rel="noreferrer" target="_blank">starttls-mx1.example.com</a>.<br>
<br>
This is a layering violation/improper way of encoding information in the DNS.<br>
The RFCs that specify the MX RR data have already been written. Special names<br>
in the LABEL portion of a record cannot have special significance for<br>
MX records,<br>
Because it would be backwards-incompatible with current MX records.<br>
<br>
For example, I may very well have a host named<br>
"<a href="http://starttls-mx1.example.com" rel="noreferrer" target="_blank">starttls-mx1.example.com</a>" today,<br>
based on current standards which is not used solely for TLS SMTP, Or<br>
it might not<br>
even support TLS SMTP --- Significance cannot be added to strings in<br>
the DNS that<br>
did not exist in the original standard, due to potential conflicts<br>
with existing implementations.<br>
<br>
If you want a DNS format that behaves differently, then you should<br>
either get a new RR type, or<br>
utilize a TXT record ala DKIM, SPF, DMARC.<br>
<br>
Also, using a DNS Record prefix, TXT, new RR, or whatever still suffers from<br>
the same downgrade attacks you are concerned about (DNS Response<br>
Mangling/Stripping),<br>
unless DNSSEC is a mandatory requirement in order to use the facility.<br>
<br>
The DANE Facilities and other IETF drafts address this much more adequately.<br>
See RFC8461 -- <a href="https://tools.ietf.org/html/rfc8461" rel="noreferrer" target="_blank">https://tools.ietf.org/html/rfc8461</a><br>
RFC 8461 seems to solve the same problem and does a better job.<br>
<br>
> Where "starttls-" says "Our port 25 supports Opportunistic TLS. So if STARTTLS command not found in the EHLO<br>
> response or certificate is invalid, then drop the connection".<br>
<br>
Wait... what you are suggesting is not Opportunistic TLS, but Strict TLS;<br>
or a SMTP equivalent to HTTP's HSTS.<br>
<br>
You could equally suggest a SMTP Banner Pattern for such a feature;<br>
instead of trying to overload<br>
the meaning of some DNS label substring.<br>
<br>
220 <a href="http://smtp.example.com" rel="noreferrer" target="_blank">smtp.example.com</a> "Welcome to the <a href="http://example.com" rel="noreferrer" target="_blank">example.com</a> SMTP Server"<br>
strict-tls=*.<a href="http://example.com" rel="noreferrer" target="_blank">example.com</a>; max-age=604800; includeSubDomains<br>
<br>
> (2) SMTPS Prefix<br>
> Use this prefix if you wanna support Implicit TLS on port 26 and Opportunistic TLS on port 25.<br>
> e.g. <a href="http://mx1.example.com" rel="noreferrer" target="_blank">mx1.example.com</a> should be prefixed like <a href="http://smtps-mx1.example.com" rel="noreferrer" target="_blank">smtps-mx1.example.com</a>.<br>
<br>
Again, this is not useful --- vulnerable to downgrade attacks which<br>
are equivalent to Port 25 SMTP TLS stripping.<br>
The TLS stripper simply intercepts outgoing TCP Port 26 SYN Packets<br>
and responds with TCP RESET.<br>
<br>
Rewrites the MX response to DNS queries if the record begins with<br>
"smtps-XXX" to "<RANDOMUID>-XXX"<br>
with the same IP addresses in the additional section and caches the A<br>
response for the generated hostnames.<br>
<br>
--<br>
-JH<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail-m_-4018628388039873529gmail_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>