SMTP Over TLS on Port 26 - Implicit TLS Proposal [Feedback Request]
Jimmy Hess
mysidia at gmail.com
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
More information about the NANOG
mailing list