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

Sun Jan 13 18:06:20 UTC 2019

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