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 should be prefixed like 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 should be prefixed like 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.
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 should be prefixed like 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 should be prefixed like 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.
