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

Sun Jan 13 21:12:04 UTC 2019

>
> If you are using DNS Records to prevent downgrades anyways,  then there
> should be no need nor valid justification for using an extra port number;
> the
> client SMTP sender can be required to inspect the DNS Record and find in
> the record a signal that TLS is mandatory,  and the smtp client must not
> proceed
> past EHLO  other than to STARTTLS immediately.

Yes that's what I meant in my proposal too.

For example,  I may very well have a host named
> "starttls-mx1.example.com"  today,
> based on current standards which is not used solely for TLS SMTP,   Or
> it might not
> even support TLS SMTP ---  Significance cannot be added to strings in
> the DNS that
> did not exist in the original standard,  due to potential conflicts
> with existing implementations.

Ok. That makes sense.

The DANE Facilities and other IETF drafts address this much more adequately.
> See RFC8461 -- https://tools.ietf.org/html/rfc8461
> RFC 8461 seems to solve the same problem and does a better job.

This proposal just trying to do the job simpler.

Let me copy paste some part I posted in ietf-smtp forum.

----

DNSSEC already protects my DNS records from spoofing. So I believe all my
DNS records are secure when I enable DNSSEC.

My domain is dombox.org and if I have mx records like

mx1.dombox.org
mx2.dombox.org
mx3.dombox.org
mx4.dombox.org
mx5.dombox.org

then those MX records are already protected from forgery since I have now
enabled DNSSEC.

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.

The TLSA records looks like this.

25._tcp.mx1.dombox.org. IN TLSA 3 0 1
ae822a14fd5e56c213eeeb5d6755556980caf4c3f2531c1ec8eca3076f9b7e68
25._tcp.mx2.dombox.org. IN TLSA 3 0 1
ae822a14fd5e56c213eeeb5d6755556980caf4c3f2531c1ec8eca3076f9b7e68
25._tcp.mx3.dombox.org. IN TLSA 3 0 1
ae822a14fd5e56c213eeeb5d6755556980caf4c3f2531c1ec8eca3076f9b7e68
25._tcp.mx4.dombox.org. IN TLSA 3 0 1
ae822a14fd5e56c213eeeb5d6755556980caf4c3f2531c1ec8eca3076f9b7e68
25._tcp.mx5.dombox.org. IN TLSA 3 0 1
ae822a14fd5e56c213eeeb5d6755556980caf4c3f2531c1ec8eca3076f9b7e68

I think we can can simplify that part via CNAME record. But, let's not go
there.

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?

My second question, if my MX records are configured to use google MX
servers (e.g. aspmx.l.google.com) whose job is to configure those DANE TLSA
records?

Google or Me?

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.

If I'm not wrong Google is against DNSSEC. So there is no way they are
gonna configure DANE records like this.

25._tcp.aspmx.l.google.com. IN TLSA 3 0 1
ae822a14fd5e56c213eeeb5d6755556980caf4c3f2531c1ec8eca3076f9b7e68
25._tcp.alt1.aspmx.l.google.com. IN TLSA 3 0 1
ae822a14fd5e56c213eeeb5d6755556980caf4c3f2531c1ec8eca3076f9b7e68
25._tcp.alt2.aspmx.l.google.com. IN TLSA 3 0 1
ae822a14fd5e56c213eeeb5d6755556980caf4c3f2531c1ec8eca3076f9b7e68
25._tcp.alt3.aspmx.l.google.com. IN TLSA 3 0 1
ae822a14fd5e56c213eeeb5d6755556980caf4c3f2531c1ec8eca3076f9b7e68
25._tcp.alt4.aspmx.l.google.com. IN TLSA 3 0 1
ae822a14fd5e56c213eeeb5d6755556980caf4c3f2531c1ec8eca3076f9b7e68

Hopefully, That is one of the reason why MTA-STS got introduced.

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.

------

You could equally suggest a  SMTP  Banner Pattern for such a feature;
> instead of trying to overload
> the meaning of some DNS label substring.
> 220   smtp.example.com "Welcome to the example.com SMTP Server"
> strict-tls=*.example.com;  max-age=604800; includeSubDomains

It's still vulnerable to MiTM attack right?

Rewrites the MX response to DNS queries   if the record begins with
> "smtps-XXX"  to   "<RANDOMUID>-XXX"
> with the same IP addresses in the additional section  and caches the A
> response  for the  generated hostnames.

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.

Thanks for the input. Those are all very helpful comments.

On Sun, Jan 13, 2019 at 11:36 PM Jimmy Hess <mysidia at gmail.com> wrote:

> On Fri, Jan 11, 2019 at 6:23 PM Viruthagiri Thirumavalavan
> <giri at dombox.org> wrote:
>
> > 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.
>
> A new Well-Known Port allocation should come from IANA if required, not
> by random cherrypicking;   Port 26 has not been assigned for transport,
> and
> might be required for a different application. 465 is already allocated for
> SMTP over TLS.
>
> If you are using DNS Records to prevent downgrades anyways,  then there
> should be no need nor valid justification for using an extra port number;
> the
> client SMTP sender can be required to inspect the DNS Record and find in
> the record a signal that TLS is mandatory,  and the smtp client must not
> proceed
> past EHLO  other than to STARTTLS immediately.
>
> > e.g. mx1.example.com should be prefixed like starttls-mx1.example.com.
>
> This is a layering violation/improper way of encoding information in the
> DNS.
> The RFCs that specify the MX RR data have already been written. Special
> names
> in the LABEL portion of a record cannot have special significance for
> MX records,
> Because it would be  backwards-incompatible with current MX records.
>
> For example,  I may very well have a host named
> "starttls-mx1.example.com"  today,
> based on current standards which is not used solely for TLS SMTP,   Or
> it might not
> even support TLS SMTP ---  Significance cannot be added to strings in
> the DNS that
> did not exist in the original standard,  due to potential conflicts
> with existing implementations.
>
> If you want a DNS format that behaves differently, then you should
> either get a new RR type, or
> utilize a TXT record  ala  DKIM, SPF, DMARC.
>
> Also,  using a DNS Record prefix, TXT,  new RR,  or whatever still suffers
> from
> the same downgrade attacks you are concerned about  (DNS Response
> Mangling/Stripping),
> unless DNSSEC is a mandatory  requirement  in order to use the facility.
>
> The DANE Facilities and other IETF drafts address this much more
> adequately.
> See RFC8461 -- https://tools.ietf.org/html/rfc8461
> RFC 8461 seems to solve the same problem and does a better job.
>
> > 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".
>
> Wait... what you are suggesting is not Opportunistic TLS, but  Strict TLS;
> or a SMTP equivalent to  HTTP's  HSTS.
>
> You could equally suggest a  SMTP  Banner Pattern for such a feature;
> instead of trying to overload
> the meaning of some DNS label substring.
>
> 220   smtp.example.com "Welcome to the example.com SMTP Server"
> strict-tls=*.example.com;  max-age=604800; includeSubDomains
>
> > (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.
>
> Again, this is not useful ---  vulnerable to downgrade attacks which
> are equivalent to Port 25 SMTP TLS stripping.
> The TLS stripper  simply  intercepts  outgoing TCP Port 26 SYN Packets
> and responds with TCP RESET.
>
> Rewrites the MX response to DNS queries   if the record begins with
> "smtps-XXX"  to   "<RANDOMUID>-XXX"
> with the same IP addresses in the additional section  and caches the A
> response  for the  generated hostnames.
>
> --
> -JH
>

-- 
Best Regards,

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