Having been through this many times, I'd say that probably the best way
to advocate for something is to advocate for what the *problem* is much
more than what the *solution* is. Invariably, things are more complex
than we imagine in the solution space and the people who inhabit that
space are more than happy to inform you of it.
Writing an I-D on what the problem is can be a very useful exercise to
rally support without putting on a bullseye on your back about a
solution. I will say that downgrade attacks are taken seriously by the
security geeks I know. But everything is messy, especially with
something as ancient as email so listening is a virtue too.
Which isn't so say that running code is bad -- it's one of the best
things about ietf -- but people have to understand why it's running at
all :)
Mike, one of the authors of rfc 4871
On 1/11/19 9:38 AM, Viruthagiri Thirumavalavan wrote:
Hello NANOG, Belated new year wishes.
I would like to gather some feedback from you all.
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.
I posted my proposal in IETF mailing list. I got very good feedback
there. Some support my proposal. Many are against it.
I would love to know where you stand on this proposal. Let me give you
the abstract first.
-----
SMTP is still suffering from downgrade attacks like STRIPTLS. While we
have "Opportunistic TLS", we still don't have "Implicit TLS" in the SMTP.
Don't take this in the wrong way. We do have "Implicit TLS" for "SMTP
Submission" on port 465. But we don't have a secure port 25
alternative. i.e. The real SMTPS
Both MTA-STS and MTA-DANE tries to fix the STARTTLS downgrade issue.
However the implementation is not simple. The former requires a HTTPS
server and the latter requires DNSSEC to even get started.
This proposal fixes STARTTLS downgrade issue and propose a new port
26, an "Implicit TLS" alternative for port 25 and recommends the MX
server to signal the port via a prefix.
This proposal offers two ways.
(1) STARTTLS Prefix
Use this prefix only to deal with STARTTLS downgrade issue.
e.g. mx1.example.com <http://mx1.example.com> should be prefixed like
starttls-mx1.example.com <http://starttls-mx1.example.com>.
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".
(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 <http://mx1.example.com> should be prefixed like
smtps-mx1.example.com <http://smtps-mx1.example.com>.
Where "smtps-" says "We prefer if you connect to our SMTPS in port 26.
But we also accept mails in port 25. And our port 25 supports
Opportunistic TLS. So if STARTTLS command not found in the EHLO
response or certificate is invalid, then drop the connection".
In "starttls-" prefix port 25 *MUST* support encryption with *valid
SSL* certificates.
In "smtps-" prefix, *BOTH* port 26 and port 25 *MUST* support
encryption with *valid SSL* certificates.
Note: You need to enable DNSSEC to prevent MX record spoofing. My
proposal highly recommends DNSSEC. Not mandates that.
-------
What IETF Mailing list thinks? - "Implicit TLS doesn't offer any
additional security than a downgrade protected STARTTLS. Let's not
waste a port."
What I think? - Implicit TLS still fall under the "best practices". So
it will send out the positive vibe that IETF still cares about email
security.
What the world thinks? -
https://gist.github.com/mistergiri/138fc46ae401b7492662a32409edb07f
What do you all think? -
https://medium.com/@dombox/smtp-over-tls-on-port-26-efc67e8a99ce
--
Best Regards,
Viruthagiri Thirumavalavan
Dombox, Inc.
