On Fri, Jan 11, 2019 at 6:23 PM Viruthagiri Thirumavalavan <g...@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