SMTP Over TLS on Port 26 - Implicit TLS Proposal [Feedback Request]
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.
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.
On 1/11/19 10: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.
What is the IETF draft name? Which IETF mailing list did this discussion happen on? -- Doug Royer - (http://DougRoyer.US http://goo.gl/yrxJTu ) DouglasRoyer@gmail.com 714-989-6135
Hello Doug, it's happening in ietf-smtp. This is my first proposal. So haven't created the I-D yet. I'm not sure how to create one. That's why I published my proposal in the medium. Please see the medium link I posted earlier. Thanks. On Sat, Jan 12, 2019, 6:46 AM Doug Royer <douglasroyer@gmail.com wrote:
On 1/11/19 10: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.
What is the IETF draft name? Which IETF mailing list did this discussion happen on?
--
Doug Royer - (http://DougRoyer.US http://goo.gl/yrxJTu ) DouglasRoyer@gmail.com 714-989-6135
But why do you think creating an out of band verification channel and separate port is going to work for this? There is plenty of local policy available as well to mandate that tls be negotiated with a set of allowed ciphers and prohibit others —srs ________________________________ From: NANOG <nanog-bounces@nanog.org> on behalf of Viruthagiri Thirumavalavan <giri@dombox.org> Sent: Saturday, January 12, 2019 7:43 AM To: Doug Royer Cc: nanog@nanog.org Subject: Re: SMTP Over TLS on Port 26 - Implicit TLS Proposal [Feedback Request] Hello Doug, it's happening in ietf-smtp. This is my first proposal. So haven't created the I-D yet. I'm not sure how to create one. That's why I published my proposal in the medium. Please see the medium link I posted earlier. Thanks. On Sat, Jan 12, 2019, 6:46 AM Doug Royer <douglasroyer@gmail.com<mailto:douglasroyer@gmail.com> wrote: On 1/11/19 10: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.
What is the IETF draft name? Which IETF mailing list did this discussion happen on? -- Doug Royer - (http://DougRoyer.US http://goo.gl/yrxJTu ) DouglasRoyer@gmail.com<mailto:DouglasRoyer@gmail.com> 714-989-6135
On Fri, Jan 11, 2019 at 4:22 PM Viruthagiri Thirumavalavan <giri@dombox.org> wrote:
What IETF Mailing list thinks? - "Implicit TLS doesn't offer any additional security than a downgrade protected STARTTLS. Let's not waste a port."
In addition, it bypasses all the security folks have built around the idea of blocking port 25 traffic from sources which should not be operating as mail servers. Let's not make the network less secure in the name of making it more so.
e.g. mx1.example.com should be prefixed like smtps-mx1.example.com.
I'm not a fan over overloading semantic information in part of a protocol where it doesn't belong, That's dug us in to a lot of deep holes over the years. If you want to do this, seek a new DNS record type or do like everybody else and create a TXT record to inform internet peers of the availability of your new semantics for port 25. Regards, Bill Herrin -- William Herrin ................ herrin@dirtside.com bill@herrin.us Dirtside Systems ......... Web: <http://www.dirtside.com/>
In addition, it bypasses all the security folks have built around the idea of blocking port 25 traffic from sources which should not be operating as mail servers. Let's not make the network less secure in the name of making it more so.
I already addressed this issue in the "security considerations" section. "Port 26 will be a secure alternative for Port 25. So Internet Service Providers are adviced to take precautions to prevent email spam abuse. They are advised to block port 26, if necessary." I'm not a fan over overloading semantic information in part of a
protocol where it doesn't belong, That's dug us in to a lot of deep holes over the years. If you want to do this, seek a new DNS record type or do like everybody else and create a TXT record to inform internet peers of the availability of your new semantics for port 25.
Yes, This suggestion came up on our discussions. On Sat, Jan 12, 2019 at 7:11 AM William Herrin <bill@herrin.us> wrote:
What IETF Mailing list thinks? - "Implicit TLS doesn't offer any additional security than a downgrade protected STARTTLS. Let's not waste a
On Fri, Jan 11, 2019 at 4:22 PM Viruthagiri Thirumavalavan <giri@dombox.org> wrote: port."
In addition, it bypasses all the security folks have built around the idea of blocking port 25 traffic from sources which should not be operating as mail servers. Let's not make the network less secure in the name of making it more so.
e.g. mx1.example.com should be prefixed like smtps-mx1.example.com.
I'm not a fan over overloading semantic information in part of a protocol where it doesn't belong, That's dug us in to a lot of deep holes over the years. If you want to do this, seek a new DNS record type or do like everybody else and create a TXT record to inform internet peers of the availability of your new semantics for port 25.
Regards, Bill Herrin
-- William Herrin ................ herrin@dirtside.com bill@herrin.us Dirtside Systems ......... Web: <http://www.dirtside.com/>
-- Best Regards, Viruthagiri Thirumavalavan Dombox, Inc.
On Fri, Jan 11, 2019 at 5:52 PM Viruthagiri Thirumavalavan <giri@dombox.org> wrote:
In addition, it bypasses all the security folks have built around the idea of blocking port 25 traffic from sources which should not be operating as mail servers. Let's not make the network less secure in the name of making it more so.
I already addressed this issue in the "security considerations" section.
"Port 26 will be a secure alternative for Port 25. So Internet Service Providers are adviced to take precautions to prevent email spam abuse. They are advised to block port 26, if necessary."
While we're at it, let's deprecate IPv4 now that IPv6 is fully deployed. -Bill -- William Herrin ................ herrin@dirtside.com bill@herrin.us Dirtside Systems ......... Web: <http://www.dirtside.com/>
While we're at it, let's deprecate IPv4 now that IPv6 is fully deployed
Come on Mr. Herrin. Blocking a port is much easier than deprecating a heavily used protocol. Google stats show ~75% use IPv4. On Sat, Jan 12, 2019 at 7:30 AM William Herrin <bill@herrin.us> wrote:
On Fri, Jan 11, 2019 at 5:52 PM Viruthagiri Thirumavalavan <giri@dombox.org> wrote:
In addition, it bypasses all the security folks have built around the idea of blocking port 25 traffic from sources which should not be operating as mail servers. Let's not make the network less secure in the name of making it more so.
I already addressed this issue in the "security considerations" section.
"Port 26 will be a secure alternative for Port 25. So Internet Service Providers are adviced to take precautions to prevent email spam abuse. They are advised to block port 26, if necessary."
While we're at it, let's deprecate IPv4 now that IPv6 is fully deployed.
-Bill
-- William Herrin ................ herrin@dirtside.com bill@herrin.us Dirtside Systems ......... Web: <http://www.dirtside.com/>
-- Best Regards, Viruthagiri Thirumavalavan Dombox, Inc.
On Fri, Jan 11, 2019 at 6:14 PM Viruthagiri Thirumavalavan <giri@dombox.org> wrote:
While we're at it, let's deprecate IPv4 now that IPv6 is fully deployed
Come on Mr. Herrin.
Hi Viruthagiri, If you don't want to face the hyperbole then don't stick your head in the sand. Unless you grossly underestimate the cost of operations change, you propose to make the spam problem worse for some nontrivial period of time. In exchange, you offer an explanation for how a new port will succeed where starttls fails that frankly doesn't hold water. Any scenario where starttls is disrupted is at least as vulnerable to a new tcp port being blocked. Your other idea of signaling via DNS that a man in the middle is present if the target SMTP server fails to support encryption could have merit. I think the specific mechanism (overloading the host name) is unwise but I'd be interested to see the concept developed further. Regards, Bill Herrin -- William Herrin ................ herrin@dirtside.com bill@herrin.us Dirtside Systems ......... Web: <http://www.dirtside.com/>
On 1/11/19 9:52 PM, William Herrin wrote:
Your other idea of signaling via DNS that a man in the middle is present if the target SMTP server fails to support encryption could have merit. I think the specific mechanism (overloading the host name) is unwise but I'd be interested to see the concept developed further.
If there's one takeaway I have from this thread to date, it's this. An advisory mechanism in DNS, such as via a TXT record, that says something along the lines of "We always support STARTTLS - if you can't negotiate that, then you are probably experiencing a MITM" could have merit. DANE appears to already offer this (and more), but as has been pointed out, can be complex to deploy. The downside I potentially see to this is that, if someone can MITM DNS (even if not the SMTP TCP session itself) and DNSSEC is not mandatory for this mechanism, that attacker could potentially cause a DoS against anyone they choose who does NOT support STARTTLS by falsely signaling that it is to be expected. I'm not sure how real-world of a threat that is given increasing adoption of STARTTLS, but it's definitely something to consider. -- Brandon Martin
If you all think my prefix proposal have some merits, it still paves the way for future smtps proposals. So I have no issues with killing smtps part of my proposal. As for signalling, I'm not sure whether moving the signalling part to another record type is a good idea. Because my signalling proposal is flawed without DNSSEC as Brandon Martin pointed out. So if we move the signalling part to another record type, then we may have to deal with multiple record set signatures. Also there is one more configuration for the end user. But i'm open for suggestions. To the person who trolled me. I'm here to have some intellectual conversation. So please stop trolling me. You are an engineer. So don't behave like a teen in youtube comments section. I'm proposing these stuffs, so the world can benefit something. By trolling me, you are just killing that. To everyone else, please go easy on me. If I'm little off on something, please forgive my ignorance. The reason I'm here is because you all know these stuffs better than me. I'm here to get some feedback. If you all think opening a new port is waste of time, I'm ok with that. But if you see some benefits on Implicit TLS over Opportunistic TLS, please point that out too. Thank you for your time.
Most new MTA implementations over the past several years default to TLS with strong ciphers. So how much of a problem is low or no TLS right now? How much more of a problem will it be over the next year or two as older hardware is retired and new servers + software deployed, or as is more likely, people move their mail to cloud services that already do support strong ciphers for TLS? How worth solving is rhe problem - what is the return for all this effort? --srs ________________________________ From: NANOG <nanog-bounces+ops.lists=gmail.com@nanog.org> on behalf of Viruthagiri Thirumavalavan <giri@dombox.org> Sent: Saturday, January 12, 2019 9:21 AM To: nanog@nanog.org Subject: Re: SMTP Over TLS on Port 26 - Implicit TLS Proposal [Feedback Request] If you all think my prefix proposal have some merits, it still paves the way for future smtps proposals. So I have no issues with killing smtps part of my proposal. As for signalling, I'm not sure whether moving the signalling part to another record type is a good idea. Because my signalling proposal is flawed without DNSSEC as Brandon Martin pointed out. So if we move the signalling part to another record type, then we may have to deal with multiple record set signatures. Also there is one more configuration for the end user. But i'm open for suggestions. To the person who trolled me. I'm here to have some intellectual conversation. So please stop trolling me. You are an engineer. So don't behave like a teen in youtube comments section. I'm proposing these stuffs, so the world can benefit something. By trolling me, you are just killing that. To everyone else, please go easy on me. If I'm little off on something, please forgive my ignorance. The reason I'm here is because you all know these stuffs better than me. I'm here to get some feedback. If you all think opening a new port is waste of time, I'm ok with that. But if you see some benefits on Implicit TLS over Opportunistic TLS, please point that out too. Thank you for your time.
Hello Mr. Ramasubramanian, When I originally drafted the SMTPS proposal, I thought those plaint text part before the STARTTLS command leaks some sensitive info. e.g. 220 mail.ashleymadison.com AshleyMadison ESMTP Service Ready Those text will always be transferred in plain text. So I thought Implicit TLS would prevent leaking that info. But guys in the IETF mailing list actually showed me a way to get that info. You just get the IP address from 3 way handshake and do reverse lookup / Connect to port 26 to fill the rest of the info. So a new port doesn't offer much security. And I totally I agree with them on that from my understanding of it. But I still want the future of email to adopt Implicit TLS. So someday we can kill Opportunistic TLS. I already lost the case for security. So my smtps part of the proposal not gonna fly. I'm just here to learn whether Implicit TLS can offer anything better than Opportunistic TLS that's worth wasting a port. Thanks On Sat, Jan 12, 2019 at 9:28 AM Suresh Ramasubramanian <ops.lists@gmail.com> wrote:
Most new MTA implementations over the past several years default to TLS with strong ciphers. So how much of a problem is low or no TLS right now?
How much more of a problem will it be over the next year or two as older hardware is retired and new servers + software deployed, or as is more likely, people move their mail to cloud services that already do support strong ciphers for TLS?
How worth solving is rhe problem - what is the return for all this effort?
--srs
------------------------------ *From:* NANOG <nanog-bounces+ops.lists=gmail.com@nanog.org> on behalf of Viruthagiri Thirumavalavan <giri@dombox.org> *Sent:* Saturday, January 12, 2019 9:21 AM *To:* nanog@nanog.org *Subject:* Re: SMTP Over TLS on Port 26 - Implicit TLS Proposal [Feedback Request]
If you all think my prefix proposal have some merits, it still paves the way for future smtps proposals. So I have no issues with killing smtps part of my proposal.
As for signalling, I'm not sure whether moving the signalling part to another record type is a good idea.
Because my signalling proposal is flawed without DNSSEC as Brandon Martin pointed out.
So if we move the signalling part to another record type, then we may have to deal with multiple record set signatures. Also there is one more configuration for the end user. But i'm open for suggestions.
To the person who trolled me. I'm here to have some intellectual conversation. So please stop trolling me. You are an engineer. So don't behave like a teen in youtube comments section. I'm proposing these stuffs, so the world can benefit something. By trolling me, you are just killing that.
To everyone else, please go easy on me. If I'm little off on something, please forgive my ignorance. The reason I'm here is because you all know these stuffs better than me. I'm here to get some feedback.
If you all think opening a new port is waste of time, I'm ok with that. But if you see some benefits on Implicit TLS over Opportunistic TLS, please point that out too.
Thank you for your time.
-- Best Regards, Viruthagiri Thirumavalavan Dombox, Inc.
On Sat, 12 Jan 2019 09:45:12 +0530, Viruthagiri Thirumavalavan said:
When I originally drafted the SMTPS proposal, I thought those plaint text part before the STARTTLS command leaks some sensitive info.
So - given that multiple people have explained to you on the ietf-smtp list that there's no really sensitive info before STARTTLS, what *exactly* does your proposal buy us? What *real* problem is port 26 fixing? And is this something that *you* think is a problem, or that somebody who runs an actual production mail system thinks is a problem?
On Sat, 12 Jan 2019 09:45:12 +0530, Viruthagiri Thirumavalavan said:
But I still want the future of email to adopt Implicit TLS. So someday we can kill Opportunistic TLS. I already lost the case for security. So my smtps part of the proposal not gonna fly. I'm just here to learn whether Implicit TLS can offer anything better than Opportunistic TLS that's worth wasting a port.
Well, the summary on the ietf-smtp list was that the new port doesn't actually buy you anything unless you have DANE, and once you have DANE, the new port doesn't add anything. The conclusion is that we should be deploying DANE more rather than burning a port. Not sure why you expect to hear much differently from NANOG.
To the OP - what's the point of hiding the hostname in the smtp banner? You already know from the dns. Concerned about the MTA version? You can configure postfix to claim it is exchange or avian carrier for that matter
I was concerned about the Brand name right next to the 220 hostname example I posted earlier. I thought it would offer little more privacy. I was wrong. So - given that multiple people have explained to you on the ietf-smtp list
that there's no really sensitive info before STARTTLS, what *exactly* does your proposal buy us? What *real* problem is port 26 fixing? And is this something that *you* think is a problem, or that somebody who runs an actual production mail system thinks is a problem?
Thanks Mr. Kletnieks, Nice to meet you again. [To everyone else - he is one of the nicest person who provided suggestions in ietf-smtp] When I proposed I thought this was an issue. But seem like it's not. What I'm looking for here is will there be any additional pros if we introduce Implicit TLS? Pros of introducing Implicit TLS: + Falls under Best Practices + Sets an early date to deprecate Opportunistic TLS in the future. (e.g. 20 years from now) + Seems like it's what the world wants. Cons of introducing Implicit TLS: - Wastes a port - ISP needs to add little code to block port 26 Well, the summary on the ietf-smtp list was that the new port doesn't
actually buy you anything unless you have DANE, and once you have DANE, the new port doesn't add anything. The conclusion is that we should be deploying DANE more rather than burning a port. Not sure why you expect to hear much differently from NANOG.
I improved my proposal a lot based on feedback I received from people like you. My proposal doesn't rely on DANE. Only DNSSEC. Even for that part, it doesn't mandates that. When example.com mails are third party hosted, example.com needs DNSSEC and third party mail servers (e.g. Google) needs DNSSEC+DANE. But google seem like it's not interested in DNSSEC. Thus Google provides a DANE alternative called MTA-STS. Let's say my domain supports DNSSEC. If my domain mails are hosted in Google, then I have no other way other than going for MTA-STS. MTA-STS needs another https server just for the sake of mail security. My proposal just changes that. Google gonna name their MX servers with starttls- prefix. And now example.com can protect MX record spoofing via DNSSEC. My point is, the signalling mechanism is handed over to third party mail providers like Google in DANE. My solution embeds the signalling mechanism in the hostname. Thus google don't have to evangelise MTA-STS to their millions of customers. Please correct me if I'm wrong with those statements On Sat, Jan 12, 2019 at 10:36 AM <valdis.kletnieks@vt.edu> wrote:
On Sat, 12 Jan 2019 09:45:12 +0530, Viruthagiri Thirumavalavan said:
But I still want the future of email to adopt Implicit TLS. So someday we can kill Opportunistic TLS. I already lost the case for security. So my smtps part of the proposal not gonna fly. I'm just here to learn whether Implicit TLS can offer anything better than Opportunistic TLS that's worth wasting a port.
Well, the summary on the ietf-smtp list was that the new port doesn't actually buy you anything unless you have DANE, and once you have DANE, the new port doesn't add anything.
The conclusion is that we should be deploying DANE more rather than burning a port.
Not sure why you expect to hear much differently from NANOG.
-- Best Regards, Viruthagiri Thirumavalavan Dombox, Inc.
12 Jan. 2019 г., 8:44 Viruthagiri Thirumavalavan <giri@dombox.org>:
Pros of introducing Implicit TLS: + Falls under Best Practices + Seems like it's what the world wants.
None of the above is really a technical argument within standards process. The world wants emojis in domain names, so what?
+ Sets an early date to deprecate Opportunistic TLS in the future.
There's nothing bad in opportunistic TLS per se, and no reason to deprecate it. The real problem is the (absent) downgrade resistance: SMTP in cleartext is historically the default, and there's no tool to reliably advertise to *everyone* on the Internet that your particular SMTP server is not obsolete. Also, TOFU is similarly unreliable for that matter and too opaque for troubleshooting. None of the issues above are solved by adding yet another port to the already overblown e-mail port bundle. In fact, implicit TLS still has some advantages over the explicit version (e.g. 0-RTT) that you've missed, but they are of questionable profit for e-mail. -- Töma
Hi Töma, Those are valid points. Thanks for the input. On Sat, Jan 12, 2019 at 4:02 PM Töma Gavrichenkov <ximaera@gmail.com> wrote:
12 Jan. 2019 г., 8:44 Viruthagiri Thirumavalavan <giri@dombox.org>:
Pros of introducing Implicit TLS: + Falls under Best Practices + Seems like it's what the world wants.
None of the above is really a technical argument within standards process.
The world wants emojis in domain names, so what?
+ Sets an early date to deprecate Opportunistic TLS in the future.
There's nothing bad in opportunistic TLS per se, and no reason to deprecate it. The real problem is the (absent) downgrade resistance: SMTP in cleartext is historically the default, and there's no tool to reliably advertise to *everyone* on the Internet that your particular SMTP server is not obsolete. Also, TOFU is similarly unreliable for that matter and too opaque for troubleshooting.
None of the issues above are solved by adding yet another port to the already overblown e-mail port bundle.
In fact, implicit TLS still has some advantages over the explicit version (e.g. 0-RTT) that you've missed, but they are of questionable profit for e-mail.
-- Töma
-- Best Regards, Viruthagiri Thirumavalavan Dombox, Inc.
On 1/11/19 11:15 PM, Viruthagiri Thirumavalavan wrote:
e.g. 220 mail.ashleymadison.com <http://mail.ashleymadison.com> AshleyMadison ESMTP Service Ready
Those text will always be transferred in plain text. So I thought Implicit TLS would prevent leaking that info.
I'm not really sure how that really matters when anyone on the open internet could connect to that service port and get the information anyway. If I'm in the middle and I really want to know who you're talking to, what prevents me to just connect to that host and get the same information? -- inoc.net!rblayzor XMPP: rblayzor.AT.inoc.net PGP: https://inoc.net/~rblayzor/
Hello Robert, Yes that was pointed out to me in the IETF. That's why I mentioned this part in this thread. "But guys in the IETF mailing list actually showed me a way to get that info. You just get the IP address from 3 way handshake and do reverse lookup / Connect to port 26 to fill the rest of the info. So a new port doesn't offer much security. And I totally I agree with them on that from my understanding of it." On Mon, Jan 14, 2019 at 9:28 PM Robert Blayzor <rblayzor.bulk@inoc.net> wrote:
On 1/11/19 11:15 PM, Viruthagiri Thirumavalavan wrote:
e.g. 220 mail.ashleymadison.com <http://mail.ashleymadison.com> AshleyMadison ESMTP Service Ready
Those text will always be transferred in plain text. So I thought Implicit TLS would prevent leaking that info.
I'm not really sure how that really matters when anyone on the open internet could connect to that service port and get the information anyway.
If I'm in the middle and I really want to know who you're talking to, what prevents me to just connect to that host and get the same information?
-- inoc.net!rblayzor XMPP: rblayzor.AT.inoc.net PGP: https://inoc.net/~rblayzor/
-- Best Regards, Viruthagiri Thirumavalavan Dombox, Inc.
On Fri, 11 Jan 2019 at 22:00, Suresh Ramasubramanian <ops.lists@gmail.com> wrote:
Most new MTA implementations over the past several years default to TLS with strong ciphers. So how much of a problem is low or no TLS right now?
The real problem is that opportunistic StartTLS stops being opportunistic the minute you encounter a `STARTTLS` extension on `EHLO`. At that point and henceforth, TLS is pretty much 100% mandatory. What happens if there are SSL negotiation failures? I'll tell you what happens — the sender will receive a few bounces, X hours and Y days after sending the mail; recipient doesn't receive anything at all. (Unless, of course, one of the administrators would magically decide to change the SSL options in the meantime to be compatible, or to disable the "opportunistic" StartTLS to start with, before the final bounce gets generated by the MTA of the sender.) These problems are real. They're already happening today. StartTLS being "opportunistic" is a pretty big scam. C.
Any place that has a TLS misconfig will pretty much notice it very quickly indeed Opportunistic just means use TLS if it is advertised as available else continue encrypted. Not sure why encountering a starttls negates it. To the OP - what's the point of hiding the hostname in the smtp banner? You already know from the dns. Concerned about the MTA version? You can configure postfix to claim it is exchange or avian carrier for that matter --srs ________________________________ From: Constantine A. Murenin <mureninc@gmail.com> Sent: Saturday, January 12, 2019 10:08 AM To: Suresh Ramasubramanian Cc: nanog@nanog.org Subject: Re: SMTP Over TLS on Port 26 - Implicit TLS Proposal [Feedback Request] On Fri, 11 Jan 2019 at 22:00, Suresh Ramasubramanian <ops.lists@gmail.com> wrote:
Most new MTA implementations over the past several years default to TLS with strong ciphers. So how much of a problem is low or no TLS right now?
The real problem is that opportunistic StartTLS stops being opportunistic the minute you encounter a `STARTTLS` extension on `EHLO`. At that point and henceforth, TLS is pretty much 100% mandatory. What happens if there are SSL negotiation failures? I'll tell you what happens — the sender will receive a few bounces, X hours and Y days after sending the mail; recipient doesn't receive anything at all. (Unless, of course, one of the administrators would magically decide to change the SSL options in the meantime to be compatible, or to disable the "opportunistic" StartTLS to start with, before the final bounce gets generated by the MTA of the sender.) These problems are real. They're already happening today. StartTLS being "opportunistic" is a pretty big scam. C.
On Fri, 11 Jan 2019 at 22:51, Suresh Ramasubramanian <ops.lists@gmail.com> wrote:
Any place that has a TLS misconfig will pretty much notice it very quickly indeed
I disagree. Plenty of evidence that Microsoft/Hotmail doesn't notice / doesn't care. Many people don't notice / don't care about Hotmail, either. Gmail doesn't care either, because it'll be the small parties that'll notice and would probably care.
Opportunistic just means use TLS if it is advertised as available else continue encrypted. Not sure why encountering a starttls negates it.
I'm pretty certain it's only in the TLS world where "opportunistic" means to use it even if it doesn't actually work, just because it's advertised as (potentially) available. C. […]
--srs
________________________________ From: Constantine A. Murenin <mureninc@gmail.com> Sent: Saturday, January 12, 2019 10:08 AM To: Suresh Ramasubramanian Cc: nanog@nanog.org Subject: Re: SMTP Over TLS on Port 26 - Implicit TLS Proposal [Feedback Request]
On Fri, 11 Jan 2019 at 22:00, Suresh Ramasubramanian <ops.lists@gmail.com> wrote:
Most new MTA implementations over the past several years default to TLS with strong ciphers. So how much of a problem is low or no TLS right now?
The real problem is that opportunistic StartTLS stops being opportunistic the minute you encounter a `STARTTLS` extension on `EHLO`.
At that point and henceforth, TLS is pretty much 100% mandatory.
What happens if there are SSL negotiation failures? I'll tell you what happens — the sender will receive a few bounces, X hours and Y days after sending the mail; recipient doesn't receive anything at all. (Unless, of course, one of the administrators would magically decide to change the SSL options in the meantime to be compatible, or to disable the "opportunistic" StartTLS to start with, before the final bounce gets generated by the MTA of the sender.)
These problems are real. They're already happening today. StartTLS being "opportunistic" is a pretty big scam.
C.
Your sarcasm detector might need a bit of a tweak. :) On Fri, Jan 11, 2019 at 9:18 PM Viruthagiri Thirumavalavan <giri@dombox.org> wrote:
While we're at it, let's deprecate IPv4 now that IPv6 is fully deployed
Come on Mr. Herrin.
Blocking a port is much easier than deprecating a heavily used protocol. Google stats show ~75% use IPv4.
On Sat, Jan 12, 2019 at 7:30 AM William Herrin <bill@herrin.us> wrote:
On Fri, Jan 11, 2019 at 5:52 PM Viruthagiri Thirumavalavan <giri@dombox.org> wrote:
In addition, it bypasses all the security folks have built around the idea of blocking port 25 traffic from sources which should not be operating as mail servers. Let's not make the network less secure in the name of making it more so.
I already addressed this issue in the "security considerations" section.
"Port 26 will be a secure alternative for Port 25. So Internet Service Providers are adviced to take precautions to prevent email spam abuse. They are advised to block port 26, if necessary."
While we're at it, let's deprecate IPv4 now that IPv6 is fully deployed.
-Bill
-- William Herrin ................ herrin@dirtside.com bill@herrin.us Dirtside Systems ......... Web: <http://www.dirtside.com/>
-- Best Regards,
Viruthagiri Thirumavalavan Dombox, Inc.
On Fri, 11 Jan 2019 at 20:01, William Herrin <bill@herrin.us> wrote:
On Fri, Jan 11, 2019 at 5:52 PM Viruthagiri Thirumavalavan <giri@dombox.org> wrote:
In addition, it bypasses all the security folks have built around the idea of blocking port 25 traffic from sources which should not be operating as mail servers. Let's not make the network less secure in the name of making it more so.
I already addressed this issue in the "security considerations" section.
"Port 26 will be a secure alternative for Port 25. So Internet Service Providers are adviced to take precautions to prevent email spam abuse. They are advised to block port 26, if necessary."
While we're at it, let's deprecate IPv4 now that IPv6 is fully deployed.
100% agree. If mx1.example.com is prefixed like ip6-smtps-mx1.example.com, then mail should only be deliverable to the domain if all of ports 25, 26 and 27 support TLS with <blink>valid SSL</blink> certificates over <blink><blink><big><big><big>IPv6</big></big></big></blink></blink>. Why? Because I think there's too much confusion between the same ports working on both IPv4 and IPv6, and with Happy-Eyeballs, no certainty which protocol would be used; resulting in downgrade-to-IPv4 attacks in certain situations. For this reason, we should use port 27 in order to guarantee that the connection will happen iff (if-and-only-if) it can be established over IPv6, so that there's no confusion. We can then use port 26 to send out reports of mail being undeliverable over IPv6 with TLS, and port 25 to send out bounces of bounces, which still has to support opportunistic StartTLS, in case we still get TLS errors on port 26 trying to deliver the bounces over IPv4 over TLS. Does this cover every possible scenario, or does anyone think we gotta use a few more ports? Hopefully, this'll teach folks like CogentCo to get their IPv6 peering act together; especially if we get Google with Gmail and G Suite on board, and Cogent will suddenly stop getting their mails from pretty much all of their customers due to all the peering disputes with pretty much the rest of the IPv6 internet. I posted my proposal to the IPv6 zealots Slack channel. I got very good feedback there. Many support my proposal. Some are against it. C.
On 1/11/19 10: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.
Your post to this list was (according to the headers): 11 Jan 2019 23:08:21 +0530 Yet on the IETF-smtp mailing list at: Wed, 9 Jan 2019 12:29:43 +0530 *You* wrote (in part): I'm the guy who proposed SMTP Over TLS on Port 26. Looks like that was dead end. So, now coming with another proposal. Question: Why did you post something on NANOG that you already declared to the IETF yourself as a "dead end" 2 days earlier? I read all of the IETF emails on this idea. They explained why it is currently a no-starter as proposed. -- Doug Royer - (http://DougRoyer.US http://goo.gl/yrxJTu ) DouglasRoyer@gmail.com 714-989-6135
Because I saw support from people like Alessandro Vesely for my proposal. https://mailarchive.ietf.org/arch/msg/ietf-smtp/pSb216OGLuTe31yUzAXtqD2haAo Then it hit me. Maybe more people like him interested in SMTPS too. So I have done some research and posted this comment. https://mailarchive.ietf.org/arch/msg/ietf-smtp/apZ8nBnGpv1aXlFUtbcTjGipA8Q When I open this thread, I just wanted to make sure we are all on the same page. I think I even mentioned what IETF thinks when I created this thread. And asked "I would love to know where you stand on this proposal." So I opened this thread, just to collect some feedback. On Mon, Jan 14, 2019 at 8:45 PM Doug Royer <douglasroyer@gmail.com> wrote:
On 1/11/19 10: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.
Your post to this list was (according to the headers): 11 Jan 2019 23:08:21 +0530
Yet on the IETF-smtp mailing list at: Wed, 9 Jan 2019 12:29:43 +0530
*You* wrote (in part): I'm the guy who proposed SMTP Over TLS on Port 26. Looks like that was dead end. So, now coming with another proposal.
Question: Why did you post something on NANOG that you already declared to the IETF yourself as a "dead end" 2 days earlier? I read all of the IETF emails on this idea. They explained why it is currently a no-starter as proposed.
--
Doug Royer - (http://DougRoyer.US http://goo.gl/yrxJTu ) DouglasRoyer@gmail.com 714-989-6135
-- Best Regards, Viruthagiri Thirumavalavan Dombox, Inc.
For the record, I dropped both proposals. I'm working on my personal projects now. Let's not annoy others by discussing about this anymore. I wanted to bring Implicit TLS to SMTP. So I had a good intention when I opened this thread. But things went little crazy due to my another thread. Many of you gave me your valuable feedback. So I'm convinced now. I really thank you all for the time. Have a nice day.
On Mon, 14 Jan 2019, Viruthagiri Thirumavalavan wrote:
Because I saw support from people like Alessandro Vesely for my proposal.
https://mailarchive.ietf.org/arch/msg/ietf-smtp/pSb216OGLuTe31yUzAXtqD2haAo
Then it hit me. Maybe more people like him interested in SMTPS too. So I have done some research and posted this comment.
https://mailarchive.ietf.org/arch/msg/ietf-smtp/apZ8nBnGpv1aXlFUtbcTjGipA8Q
When I open this thread, I just wanted to make sure we are all on the same page. I think I even mentioned what IETF thinks when I created this thread. And asked "I would love to know where you stand on this proposal."
This is a mailing list for network operations. When SMTP on another alternate port is something we have to configure our routers for (i.e. an ACL update), then it might have some small relevance here. Until then, talk about it is just noise. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
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.
Why would anyone need this when you can just set an option in most (all modern?) SMTP servers to refuse clear connections if you want to force TLS at all times?
Hi Seth, My solution is intended for clients. A client should decide whether to transmit mails in clear text or not. In other words, the server can accept mails in clear text. The prefix informs the client, that the server supports TLS. A client that knows what "starttls-" prefix stands for, would come to know downgrade attacks if the STARTTLS command not found in EHLO response. If I force the server to accept only TLS, then that's not backward compatible. Thanks On Sat, Jan 12, 2019 at 9:24 PM Seth Mattinen <sethm@rollernet.us> wrote:
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.
Why would anyone need this when you can just set an option in most (all modern?) SMTP servers to refuse clear connections if you want to force TLS at all times?
-- Best Regards, Viruthagiri Thirumavalavan Dombox, Inc.
On Jan 12, 2019, at 08:14, Viruthagiri Thirumavalavan <giri@dombox.org> wrote:
My solution is intended for clients. A client should decide whether to transmit mails in clear text or not.
You should spend some time doing research by reading RFCs, and doing a little searching on the internet. Your proposal, would, canonically be called SMTPS. If you put that into a search engine, you'll find not only is it deprecated, but has an assigned port number of 465. https://en.wikipedia.org/wiki/SMTPS
What makes you think I never did any research? https://medium.com/@Viruthagiri/smtp-ports-25-vs-587-vs-465-de1046f57636 On Sat, Jan 12, 2019 at 10:10 PM James Downs <egon@egon.cc> wrote:
On Jan 12, 2019, at 08:14, Viruthagiri Thirumavalavan <giri@dombox.org> wrote:
My solution is intended for clients. A client should decide whether to transmit mails in clear text or not.
You should spend some time doing research by reading RFCs, and doing a little searching on the internet. Your proposal, would, canonically be called SMTPS.
If you put that into a search engine, you'll find not only is it deprecated, but has an assigned port number of 465.
-- Best Regards, Viruthagiri Thirumavalavan Dombox, Inc.
In article <CAOEezJQ0mJYvKW=SdbbE4ZC2Vx6_9FD5Z0SpkF2840r580vZ5w@mail.gmail.com> you write:
What IETF Mailing list thinks? - "Implicit TLS doesn't offer any additional security than a downgrade protected STARTTLS. Let's not waste a port."
He's forum shopping. He's already take this to two IETF lists and we've explained to him why it's not a good idea. If you want to say that all your mail servers use TLS, we already have DANE for people who can deal with DNSSEC and MTA-STS for people who can't (or don't want to for whatever reason.) We do not need yet another hack, particularly one which attempts to reserve string patterns in DNS names. R's, John
Hello Mr. Levine, 5 months back I posted my spam research on DMARC list. You have gone through only 50 words and judged my work. The whole thread gone haywire because of you. I was humiliated there and left. Last week I posted in IETF list. To be very honest, I don't like you. That's because you spent your time only on attacking me on DMARC list. I'm happy to post the private mail screenshots if anyone wants that. Although I don't like you, I still managed to respond politely in IETF lists. Again... In that list the only thing you did was attacking my work. I asked you to provide evidence to support your criticisms, but you never did. You called my work as fantasy, whereas guys in this thread says it has at least some merits. https://mailarchive.ietf.org/arch/msg/uta/CaMj7xkGpkDg6c3qKGlLjksG5do To quote his words Sorry, but this is a fantasy. SMTP routing still falls back to an A
record if there's no MX and the DNS has been around for 30 years. And your assmptions about what is hard and what is easy may be correct for your personal situation, but they are not true in general. Look at it this way -- if you can set up an STS server in less than a decade, you're ahead of the game.
This is what I responded for that. ----- Here is the problem with that part. A records are IE6 equivalent in the SMTP world. These days everyone moved to the MX records. There are rare cases where some mail servers still rely on A records. My solution doesn't deal with A records. It's the clients decision whether to use MX record or A record. Let's just pretend my solution rely on A records, you are criticising my work saying that 0.1% people not gonna upgrade to "MX Records". On the other hand, you think 100% of the internet gonna upgrade to a completely new system STS. Isn't that irony? ----- These are some of his responses to my thread. ------ MTA-STS does a great deal of this. It has a way for a domain to say "all my inbound mail uses TLS" (RFC 8461) and for other systems to report back and say whether they're actually seeing that (RFC 8460.) I don't understand why people are trying to reinvent the wheel when we just defined a fairly round one a few months ago. https://mailarchive.ietf.org/arch/msg/uta/XVHBasNzVBTKbFE2EcLmI9fK324 ----- We went through all of this when we invented MTA-STS. We know that setting up a web server can be non-trivial but for a lot of places, it's far easier than geting DNSSEC to work. I recall a dinner at the Buenos Aires IETF where we were trying to figure out if there were a reasonable way to signal stuff in the DNS. Magic names certainly came up. I think it would be a good idea for anyone interested in this topic to go back through the mailing list discussion and read the drafts and explain what is different now that we didn't know when we defined MTA-STS a few months ago https://mailarchive.ietf.org/arch/msg/uta/nmB53F9Hg9yfPXCXeXv248evYhM ----- John, you should know, I'm doing forum shopping here because of you. I totally understand others tried to help me. But you are not. You created this thread just to attack me. So this is the prime example of you trying to silence my work. Most decent folks never do such thing. To everyone else, my solution is an EASY alternative for both DANE and MTA-STS. John seem like he has vested interest in MTA-STS. Guys, feel free to take a look at our whole conversation in the uta ietf list. And then please tell me this man is not biased at all. I'm happy to terminate my proposal in that case.
From this point forward, all mail containing the phrase "TLS on port 26" in the Subject line will be shunted into my junk mail box, unread, because I do not wish to see any more correspondence on this matter.
'procmail' is my friend. - Brian On Sun, Jan 13, 2019 at 03:20:26AM +0530, Viruthagiri Thirumavalavan wrote:
Hello Mr. Levine, [...]
I'm not sure why are being angry here. For the record, this conversation isn't about TLS on port 26. It's about STARTTLS downgrade protection on port 25. On Sun, Jan 13, 2019 at 3:33 AM Brian Kantor <Brian@ampr.org> wrote:
From this point forward, all mail containing the phrase "TLS on port 26" in the Subject line will be shunted into my junk mail box, unread, because I do not wish to see any more correspondence on this matter.
'procmail' is my friend. - Brian
On Sun, Jan 13, 2019 at 03:20:26AM +0530, Viruthagiri Thirumavalavan wrote:
Hello Mr. Levine, [...]
-- Best Regards, Viruthagiri Thirumavalavan Dombox, Inc.
In my opinion, the problem isn’t that great. As others have stated, you can locally enforce only STARTTLS on the receive connector or send connector locally to ensure that only encrypted transmission occurs. If the MTA doesn’t send/accept STARTTLS send an error message. That the host name is given, doesn’t really matter as most MiTM will still see IP SRC and IP DST so that’s given that transmission occurred. DNSSEC already will ensure the same IP, and RPKI can help on BGP hijacks, given this is still an ongoing process. In my opinion, the major issue is data at rest which would rely on PGP, S/MIME, et al. Another option would be DMTP, like I emailed off list which encrypts even headers. My guess though is that if this gains traction, there will be a corresponding law like CALEA for LEO to intercept. Sincerely, Eric Tykwinski TrueNet, Inc. P: 610-429-8300
On Jan 12, 2019, at 5:09 PM, Viruthagiri Thirumavalavan <giri@dombox.org> wrote:
I'm not sure why are being angry here.
For the record, this conversation isn't about TLS on port 26. It's about STARTTLS downgrade protection on port 25.
On Sun, Jan 13, 2019 at 3:33 AM Brian Kantor <Brian@ampr.org <mailto:Brian@ampr.org>> wrote: From this point forward, all mail containing the phrase "TLS on port 26" in the Subject line will be shunted into my junk mail box, unread, because I do not wish to see any more correspondence on this matter.
'procmail' is my friend. - Brian
On Sun, Jan 13, 2019 at 03:20:26AM +0530, Viruthagiri Thirumavalavan wrote:
Hello Mr. Levine, [...]
-- Best Regards,
Viruthagiri Thirumavalavan Dombox, Inc.
On Sat, 12 Jan 2019 17:37:02 -0500, Eric Tykwinski said:
even headers. My guess though is that if this gains traction, there will be a corresponding law like CALEA for LEO to intercept.
Hopefully *this* time we'll do it in such a way that LEO use will remain higher than bad-guys use. I'm not holding my breath though...
Go and check how many of these match. Then ask yourself why you might be getting a poor reception on lists composed of people who do this stuff for a living.
Hello Mr. Kletnieks, I have no problem when people criticising my work. I even dropped the idea of port 26 because people like you showed me why it's bad. As for port 25 downgrade proposal, I'm happy to walk away if it is really flawed. But I can't walk away when biased people attack me to protect their interests. Remember, I posted in ietf-smtp to put a disclaimer when there is a "conflict of interest" when responding to my messages? I was talking about John and DANE author after seeing their messages in my uta thread. No matter how much time you might have spent, repeating a bad idea over
and over and over again will not turn it into a good idea.
If you are biased, how can I know it's a bad idea. Are you gonna say you are not biased when criticising my work? I just proved you are biased. The people on the IETF lists, particularly Ned Freed, and John Klensin,
know more about mail than anyone in the world. If they don't like your idea, you should pay attention.
I interacted with Mr. Klensin in the ietf-smtp forum. More than knowing things, he seem like a man who respect others work. This is what he said Especially if you are new, please interpret my response (and
those of several others) as "we aren't convinced about your idea" or "we think there are better alternatives", not as "your proposal is bad and will cause problems". I'd like to see a lot more discussion before the latter conclusion is reached although I'd encourage you to read the comments carefully and see if they suggest ways to improve the proposal. I believe that it is very important that new ideas to which long-time participants have initial negative reasons get careful consideration and every reasonable chance to succeed before they are dismissed.
I have improved my solution based on feedback I received. I dropped my port 26 proposal and concentrating only on port 25. How can I get feedback from others, if you are gonna post anti-messages about my work?
On Sun, Jan 13, 2019 at 12:51 AM Viruthagiri Thirumavalavan <giri@dombox.org> wrote:
5 months back I posted my spam research on DMARC list. You have gone through only 50 words and judged my work. The whole thread gone haywire because of you. I was humiliated there and left.
By the way, since that you've left no traces of whatever piece of work you've posted to that list. The website is empty, slides are removed from Speakerdeck, etc. In theory, I can easily recall a few cases in my life when going through just 50 words was quite enough for a judgment.
To be very honest, I don't like you.
Please keep our busy mailing list out of this information, though for me it's a valuable piece of data that someone I don't know personally doesn't like someone else.
Although I don't like you, I still managed to respond politely in IETF lists. Again... In that list the only thing you did was attacking my work.
So, I've read the whole thread, and, as far as I can see, there was nothing coming from John except for a balanced judgement.
And then please tell me this man is not biased at all.
Sorry, he's not. -- Töma
To the IP Other people try to sugar coat what they tell you John has never minced his words in the past two decades that I know him and that's good Yes, 50 words are more than enough to decide a bad idea is bad. You don't have to like that, or like any of us, but facts are facts --srs ________________________________ From: NANOG <nanog-bounces@nanog.org> on behalf of Töma Gavrichenkov <ximaera@gmail.com> Sent: Sunday, January 13, 2019 4:48 AM To: Viruthagiri Thirumavalavan Cc: John Levine; nanog list Subject: Re: yet another round of SMTP Over TLS on Port 26 - Implicit TLS Proposal [Feedback Request] On Sun, Jan 13, 2019 at 12:51 AM Viruthagiri Thirumavalavan <giri@dombox.org> wrote:
5 months back I posted my spam research on DMARC list. You have gone through only 50 words and judged my work. The whole thread gone haywire because of you. I was humiliated there and left.
By the way, since that you've left no traces of whatever piece of work you've posted to that list. The website is empty, slides are removed from Speakerdeck, etc. In theory, I can easily recall a few cases in my life when going through just 50 words was quite enough for a judgment.
To be very honest, I don't like you.
Please keep our busy mailing list out of this information, though for me it's a valuable piece of data that someone I don't know personally doesn't like someone else.
Although I don't like you, I still managed to respond politely in IETF lists. Again... In that list the only thing you did was attacking my work.
So, I've read the whole thread, and, as far as I can see, there was nothing coming from John except for a balanced judgement.
And then please tell me this man is not biased at all.
Sorry, he's not. -- Töma
I don't know why you are all try to defend a man who try to silence my work. Are you saying this thread is necessary? On Sun, Jan 13, 2019 at 4:46 AM Töma Gavrichenkov <ximaera@gmail.com> wrote:
On Sun, Jan 13, 2019 at 12:51 AM Viruthagiri Thirumavalavan <giri@dombox.org> wrote:
5 months back I posted my spam research on DMARC list. You have gone through only 50 words and judged my work. The whole thread gone haywire because of you. I was humiliated there and left.
By the way, since that you've left no traces of whatever piece of work you've posted to that list. The website is empty, slides are removed from Speakerdeck, etc.
In theory, I can easily recall a few cases in my life when going through just 50 words was quite enough for a judgment.
To be very honest, I don't like you.
Please keep our busy mailing list out of this information, though for me it's a valuable piece of data that someone I don't know personally doesn't like someone else.
Although I don't like you, I still managed to respond politely in IETF lists. Again... In that list the only thing you did was attacking my work.
So, I've read the whole thread, and, as far as I can see, there was nothing coming from John except for a balanced judgement.
And then please tell me this man is not biased at all.
Sorry, he's not.
-- Töma
-- Best Regards, Viruthagiri Thirumavalavan Dombox, Inc.
Can we please have a mod step in and shut this thread down? Any conversation of value is long gone. /Chris On Sat, Jan 12, 2019 at 5:25 PM -0600, "Viruthagiri Thirumavalavan" <giri@dombox.org<mailto:giri@dombox.org>> wrote: I don't know why you are all try to defend a man who try to silence my work. Are you saying this thread is necessary? On Sun, Jan 13, 2019 at 4:46 AM Töma Gavrichenkov <ximaera@gmail.com<mailto:ximaera@gmail.com>> wrote: On Sun, Jan 13, 2019 at 12:51 AM Viruthagiri Thirumavalavan <giri@dombox.org<mailto:giri@dombox.org>> wrote:
5 months back I posted my spam research on DMARC list. You have gone through only 50 words and judged my work. The whole thread gone haywire because of you. I was humiliated there and left.
By the way, since that you've left no traces of whatever piece of work you've posted to that list. The website is empty, slides are removed from Speakerdeck, etc. In theory, I can easily recall a few cases in my life when going through just 50 words was quite enough for a judgment.
To be very honest, I don't like you.
Please keep our busy mailing list out of this information, though for me it's a valuable piece of data that someone I don't know personally doesn't like someone else.
Although I don't like you, I still managed to respond politely in IETF lists. Again... In that list the only thing you did was attacking my work.
So, I've read the whole thread, and, as far as I can see, there was nothing coming from John except for a balanced judgement.
And then please tell me this man is not biased at all.
Sorry, he's not. -- Töma -- Best Regards, Viruthagiri Thirumavalavan Dombox, Inc.
Yes please, Thanks Mr. Cummings On Sun, Jan 13, 2019 at 4:56 AM Cummings, Chris <ccummings@coeur.com> wrote:
Can we please have a mod step in and shut this thread down? Any conversation of value is long gone.
/Chris
On Sat, Jan 12, 2019 at 5:25 PM -0600, "Viruthagiri Thirumavalavan" < giri@dombox.org> wrote:
I don't know why you are all try to defend a man who try to silence my
work.
Are you saying this thread is necessary?
On Sun, Jan 13, 2019 at 4:46 AM Töma Gavrichenkov <ximaera@gmail.com> wrote:
On Sun, Jan 13, 2019 at 12:51 AM Viruthagiri Thirumavalavan <giri@dombox.org> wrote:
5 months back I posted my spam research on DMARC list. You have gone through only 50 words and judged my work. The whole thread gone haywire because of you. I was humiliated there and left.
By the way, since that you've left no traces of whatever piece of work you've posted to that list. The website is empty, slides are removed from Speakerdeck, etc.
In theory, I can easily recall a few cases in my life when going through just 50 words was quite enough for a judgment.
To be very honest, I don't like you.
Please keep our busy mailing list out of this information, though for me it's a valuable piece of data that someone I don't know personally doesn't like someone else.
Although I don't like you, I still managed to respond politely in IETF lists. Again... In that list the only thing you did was attacking my work.
So, I've read the whole thread, and, as far as I can see, there was nothing coming from John except for a balanced judgement.
And then please tell me this man is not biased at all.
Sorry, he's not.
-- Töma
-- Best Regards,
Viruthagiri Thirumavalavan Dombox, Inc.
-- Best Regards, Viruthagiri Thirumavalavan Dombox, Inc.
Honestly, you feel very highly of your work in which any of us do in this field but John has a very good point and constructive criticism shroud not be the down fall of anyone. Read it 100 times without taking any thought of your own work and try to see the whole picture. Not agreeing with John or you but it is very straight forward and industry leading. It’s polite. I would feel the proper response from you would be to acknowledge the feedback and ask for some correction and guidance as John has had a lot of involvement here as so many others. He is not saying what you are doing is bad or such but more of guidance in a more proper direction so delusions are not set in the future. The whole picture of any outcome is not only had by just one person trying to make a difference but by the whole for a greater good for which makes sense for the current architectures and policies that are in place. I solute both you and John plus the community at which contribute highly valuable aspects to evolving “our” beat practices and judgements. Whether it’s positive or negative or proof of concept, it is how we get to where we “think” we should be. Criticism is how we get there regardless. Let’s cut out the other non-sense and discontinue this thread and work positively instead of against one-another. -- J. Hellenthal The fact that there's a highway to Hell but only a stairway to Heaven says a lot about anticipated traffic volume.
On Jan 12, 2019, at 17:26, Cummings, Chris <ccummings@coeur.com> wrote:
Can we please have a mod step in and shut this thread down? Any conversation of value is long gone.
/Chris
On Sat, Jan 12, 2019 at 5:25 PM -0600, "Viruthagiri Thirumavalavan" <giri@dombox.org> wrote:
I don't know why you are all try to defend a man who try to silence my work.
Are you saying this thread is necessary?
On Sun, Jan 13, 2019 at 4:46 AM Töma Gavrichenkov <ximaera@gmail.com> wrote: On Sun, Jan 13, 2019 at 12:51 AM Viruthagiri Thirumavalavan <giri@dombox.org> wrote:
5 months back I posted my spam research on DMARC list. You have gone through only 50 words and judged my work. The whole thread gone haywire because of you. I was humiliated there and left.
By the way, since that you've left no traces of whatever piece of work you've posted to that list. The website is empty, slides are removed from Speakerdeck, etc.
In theory, I can easily recall a few cases in my life when going through just 50 words was quite enough for a judgment.
To be very honest, I don't like you.
Please keep our busy mailing list out of this information, though for me it's a valuable piece of data that someone I don't know personally doesn't like someone else.
Although I don't like you, I still managed to respond politely in IETF lists. Again... In that list the only thing you did was attacking my work.
So, I've read the whole thread, and, as far as I can see, there was nothing coming from John except for a balanced judgement.
And then please tell me this man is not biased at all.
Sorry, he's not.
-- Töma
-- Best Regards,
Viruthagiri Thirumavalavan Dombox, Inc.
Jason, Your comment is one of the best I have seen in this thread. Thanks for the input and being neutral.
No problem. We all come across this here and there. We all fail 100 times or more but perception will always be key in how we obtain a final objective that benefits everyone. Thomas Edison failed thousands of times but of all those times his success only came from the knowledge of those so many failures. -- J. Hellenthal The fact that there's a highway to Hell but only a stairway to Heaven says a lot about anticipated traffic volume.
On Jan 12, 2019, at 18:13, Viruthagiri Thirumavalavan <giri@dombox.org> wrote:
Jason, Your comment is one of the best I have seen in this thread.
Thanks for the input and being neutral.
What Jason said in red. On 1/12/19 6:07 PM, Jason Hellenthal via NANOG wrote:
Honestly, you feel very highly of your work in which any of us do in this field but John has a very good point and constructive criticism shroud not be the down fall of anyone. Read it 100 times without taking any thought of your own work and try to see the whole picture.
Not agreeing with John or you but it is very straight forward and industry leading. It’s polite. I would feel the proper response from you would be to acknowledge the feedback and ask for some correction and guidance as John has had a lot of involvement here as so many others.
He is not saying what you are doing is bad or such but more of guidance in a more proper direction so delusions are not set in the future.
The whole picture of any outcome is not only had by just one person trying to make a difference but by the whole for a greater good for which makes sense for the current architectures and policies that are in place.
I solute both you and John plus the community at which contribute highly valuable aspects to evolving “our” beat practices and judgements.
Whether it’s positive or negative or proof of concept, it is how we get to where we “think” we should be.
Criticism is how we get there regardless.
Let’s cut out the other non-sense and discontinue this thread and work positively instead of against one-another.
-- J. Hellenthal
The fact that there's a highway to Hell but only a stairway to Heaven says a lot about anticipated traffic volume.
On Jan 12, 2019, at 17:26, Cummings, Chris <ccummings@coeur.com <mailto:ccummings@coeur.com>> wrote:
Can we please have a mod step in and shut this thread down? Any conversation of value is long gone.
/Chris
On Sat, Jan 12, 2019 at 5:25 PM -0600, "Viruthagiri Thirumavalavan" <giri@dombox.org <mailto:giri@dombox.org>> wrote:
I don't know why you are all try to defend a man who try to silence my work.
Are you saying this thread is necessary?
On Sun, Jan 13, 2019 at 4:46 AM Töma Gavrichenkov <ximaera@gmail.com <mailto:ximaera@gmail.com>> wrote:
On Sun, Jan 13, 2019 at 12:51 AM Viruthagiri Thirumavalavan <giri@dombox.org <mailto:giri@dombox.org>> wrote: > 5 months back I posted my spam research on DMARC list. > You have gone through only 50 words and judged my work. > The whole thread gone haywire because of you. I was > humiliated there and left.
By the way, since that you've left no traces of whatever piece of work you've posted to that list. The website is empty, slides are removed from Speakerdeck, etc.
In theory, I can easily recall a few cases in my life when going through just 50 words was quite enough for a judgment.
> To be very honest, I don't like you.
Please keep our busy mailing list out of this information, though for me it's a valuable piece of data that someone I don't know personally doesn't like someone else.
> Although I don't like you, I still managed to respond politely in > IETF lists. Again... In that list the only thing you did was > attacking my work.
So, I've read the whole thread, and, as far as I can see, there was nothing coming from John except for a balanced judgement.
> And then please tell me this man is not biased at all.
Sorry, he's not.
-- Töma
-- Best Regards,
Viruthagiri Thirumavalavan Dombox, Inc.
Yes. What is all the fuzz about? Email will be as dead as USENET in a couple of years anyway. Welcome to the age of "feeds". You may cry now. Bjørn
In article <871s5gpz1w.fsf@miraculix.mork.no> you write:
Yes. What is all the fuzz about? Email will be as dead as USENET in a couple of years anyway.
Funny, people have been saying that pretty much every year since the 1990s. What's different this time?
By the way, since that you've left no traces of whatever piece of work you've posted to that list. The website is empty, slides are removed from Speakerdeck, etc. In theory, I can easily recall a few cases in my life when going through just 50 words was quite enough for a judgment.
Yes, 50 words are more than enough to decide a bad idea is bad. You don't
have to like that, or like any of us, but facts are facts
Guys, I can't able to disclose my work at this point. But I'm happy to publish my work again next month. In the meantime, I have no issues if you all think my work is bad. But if you all think, my work has some novelty and this man made the wrong choice, be sure to tell that too. On Sun, Jan 13, 2019 at 4:51 AM Viruthagiri Thirumavalavan <giri@dombox.org> wrote:
I don't know why you are all try to defend a man who try to silence my work.
Are you saying this thread is necessary?
On Sun, Jan 13, 2019 at 4:46 AM Töma Gavrichenkov <ximaera@gmail.com> wrote:
On Sun, Jan 13, 2019 at 12:51 AM Viruthagiri Thirumavalavan <giri@dombox.org> wrote:
5 months back I posted my spam research on DMARC list. You have gone through only 50 words and judged my work. The whole thread gone haywire because of you. I was humiliated there and left.
By the way, since that you've left no traces of whatever piece of work you've posted to that list. The website is empty, slides are removed from Speakerdeck, etc.
In theory, I can easily recall a few cases in my life when going through just 50 words was quite enough for a judgment.
To be very honest, I don't like you.
Please keep our busy mailing list out of this information, though for me it's a valuable piece of data that someone I don't know personally doesn't like someone else.
Although I don't like you, I still managed to respond politely in IETF lists. Again... In that list the only thing you did was attacking my work.
So, I've read the whole thread, and, as far as I can see, there was nothing coming from John except for a balanced judgement.
And then please tell me this man is not biased at all.
Sorry, he's not.
-- Töma
-- Best Regards,
Viruthagiri Thirumavalavan Dombox, Inc.
-- Best Regards, Viruthagiri Thirumavalavan Dombox, Inc.
On Sun, 13 Jan 2019 04:57:26 +0530, Viruthagiri Thirumavalavan said:
Guys, I can't able to disclose my work at this point. But I'm happy to publish my work again next month. In the meantime, I have no issues if you all think my work is bad.
You'd probably do the world a favor if you spent that month instead finding mail software that does quoting and attribution correctly. You've made several posts that quoted me, and then quoted others in such a way that it looked like I said it.
But if you all think, my work has some novelty and this man made the wrong choice, be sure to tell that too.
Note that there are far more bad ideas than good ones, and sheer novelty doesn't mean an idea is good.
You'd probably do the world a favor if you spent that month instead finding mail software that does quoting and attribution correctly. You've made several posts that quoted me, and then quoted others in such a way that it looked like I said it.
Oh, I'm sorry about that. I'll pay attention next time. Note that there are far more bad ideas than good ones, and sheer novelty
doesn't mean an idea is good.
Ok
Viruthagiri, You are being too defensive. You've made this discussion about whether or not someone is attacking you, rather than the merit of your idea. It is not about networking or mail anymore. Please end the conversation here. -Ross On Sat, Jan 12, 2019 at 6:26 PM Viruthagiri Thirumavalavan <giri@dombox.org> wrote:
I don't know why you are all try to defend a man who try to silence my work.
Are you saying this thread is necessary?
On Sun, Jan 13, 2019 at 4:46 AM Töma Gavrichenkov <ximaera@gmail.com> wrote:
On Sun, Jan 13, 2019 at 12:51 AM Viruthagiri Thirumavalavan <giri@dombox.org> wrote:
5 months back I posted my spam research on DMARC list. You have gone through only 50 words and judged my work. The whole thread gone haywire because of you. I was humiliated there and left.
By the way, since that you've left no traces of whatever piece of work you've posted to that list. The website is empty, slides are removed from Speakerdeck, etc.
In theory, I can easily recall a few cases in my life when going through just 50 words was quite enough for a judgment.
To be very honest, I don't like you.
Please keep our busy mailing list out of this information, though for me it's a valuable piece of data that someone I don't know personally doesn't like someone else.
Although I don't like you, I still managed to respond politely in IETF lists. Again... In that list the only thing you did was attacking my work.
So, I've read the whole thread, and, as far as I can see, there was nothing coming from John except for a balanced judgement.
And then please tell me this man is not biased at all.
Sorry, he's not.
-- Töma
-- Best Regards,
Viruthagiri Thirumavalavan Dombox, Inc.
Ok guys, let's stop the discussion on this thread. On Sun, Jan 13, 2019 at 5:00 AM Ross Tajvar <ross@tajvar.io> wrote:
Viruthagiri,
You are being too defensive. You've made this discussion about whether or not someone is attacking you, rather than the merit of your idea. It is not about networking or mail anymore. Please end the conversation here.
-Ross
On Sat, Jan 12, 2019 at 6:26 PM Viruthagiri Thirumavalavan < giri@dombox.org> wrote:
I don't know why you are all try to defend a man who try to silence my work.
Are you saying this thread is necessary?
On Sun, Jan 13, 2019 at 4:46 AM Töma Gavrichenkov <ximaera@gmail.com> wrote:
On Sun, Jan 13, 2019 at 12:51 AM Viruthagiri Thirumavalavan <giri@dombox.org> wrote:
5 months back I posted my spam research on DMARC list. You have gone through only 50 words and judged my work. The whole thread gone haywire because of you. I was humiliated there and left.
By the way, since that you've left no traces of whatever piece of work you've posted to that list. The website is empty, slides are removed from Speakerdeck, etc.
In theory, I can easily recall a few cases in my life when going through just 50 words was quite enough for a judgment.
To be very honest, I don't like you.
Please keep our busy mailing list out of this information, though for me it's a valuable piece of data that someone I don't know personally doesn't like someone else.
Although I don't like you, I still managed to respond politely in IETF lists. Again... In that list the only thing you did was attacking my work.
So, I've read the whole thread, and, as far as I can see, there was nothing coming from John except for a balanced judgement.
And then please tell me this man is not biased at all.
Sorry, he's not.
-- Töma
-- Best Regards,
Viruthagiri Thirumavalavan Dombox, Inc.
-- Best Regards, Viruthagiri Thirumavalavan Dombox, Inc.
On Sun, 13 Jan 2019 04:51:40 +0530, Viruthagiri Thirumavalavan said:
I don't know why you are all try to defend a man who try to silence my work.
Rest assured that if he was actually trying to silence your work you wouldn't have been able to post your message to NANOG.
On Jan 11, 2019, at 09:38 , Viruthagiri Thirumavalavan <giri@dombox.org> 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.
How would (2) be different from the previous SMTPS port 465 which was deprecated?
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
https://www.mailgun.com/blog/which-smtp-port-understanding-ports-25-465-587 Seems to agree with my recollection that 465 was never specifically for submission and that it was deprecated shortly after the introduction of STARTTLS.
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.
As a general rule, I think separate ports for TLS-ified versions of existing protocols isn’t the right solution and simply wastes ports. Thinking this through, I don’t think you actually solve the existing problem, either. A client wanting to use your new port 26 would need to fall back to port 25 by default if the MTA at the other end didn’t support port 26. As I see it, there are the following remote MTA possibilities (ignoring submission on 587 and ignoring any possible legacy implementation on 465 for now): 1. Remote MTA supports port 26 and STARTTLS on port 25. 2. Remote MTA supports only port 25 with STARTTLS 3. Remote MTA supports only port 25 in clear text So long as the client will fall back to port 25, you have an identical vulnerability to man in the middle attack in all 3 cases: 1. If port 26 is attempted, Send back a TCP RST or ICMP port unreachable message in response to the connection attempt on port 26. 2. Conventional STARTTLS Downgrade attack. If you have some way to remove the need for fallback to port 25, then you can in all of those instances simply remove the willingness to communicate with an MTA server that does not offer STARTTLS as part of the negotiable option set in response to the EHLO, thus eliminating the acceptance of a downgrade attack.
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.
So the naming convention thing might be usable, but I don’t see any advantage to the explicit TLS port vs. just providing naming-based hints about STARTTLS.
What IETF Mailing list thinks? - "Implicit TLS doesn't offer any additional security than a downgrade protected STARTTLS. Let's not waste a port.”
I’m inclined to agree here… See above.
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.
I don’t think so. First, I think the word you actually want is explicit (specified) vs. implicit (implied). Second, I’m not convinced that it is any more explicit. If you have an immutable out-of-band way of communicating STARTTLS support, then I don’t see port-based explicit as being in any way superior to rule-based explicit use of STARTTLS. So I’m not convinced that chewing up a port just to feel good about explicitness offers any tangible benefit. Third, I think rather than conveying the positive vibe you wish to imply that it would, instead, indicate that the IETF: 1. Can’t make up it’s mind about TLS on SMTP (yes, 465; no, use STARTTLS instead; yes, but this time on port 26) 2. Doesn’t care about wasting well-known port numbers (which are in relatively short supply) I’d consider both of these to be a pretty negative vibe.
What the world thinks? - https://gist.github.com/mistergiri/138fc46ae401b7492662a32409edb07f <https://gist.github.com/mistergiri/138fc46ae401b7492662a32409edb07f> Most of the comments from the world appear not to fully understand the problem and have not thought through the implications I mention above.
If your intent is for all upgraded client sides not to ever try port 25 (thus render them unable to connect to servers that don’t support your port 26 hack), then what do you gain vs. the already present option to tell your software to reject any MTA that doesn’t offer STARTTLS as an option or fails to negotiate TLS when you request it? If that’s an option, just turn that on and you’ve got all the same security this solution would offer without wasting a port. Owen
Hello Owen, Thanks for the input. This thread is not about my SMTPS proposal anymore. I'm already convinced that's not gonna work since I couldn't find any strong advantages over Opportunistic TLS. But I'm still open for suggestions for my "starttls-" prefix proposal. It's just trying to prevent STARTTLS downgrade issues in a very simple way. However people are against that proposal too because of IDN and A record fallback issues. I tested IDN <https://gist.github.com/mistergiri/a4c9a5f1c26fd7003ebc0652af95d314#internationalized-domain-names> and couldn't find any issues. As for A record, If this proposal must support it too for MX fallback mechanism, then I don't think this proposal gonna work. To answer your question How would (2) be different from the previous SMTPS port 465 which was
deprecated?
Port 465 reintroduced in 2018 as submission port in rfc8314. Port 465 never used for relay as far as I know. My SMTPS proposal is all about relay. I have done some research about the ports. If you want, please take look here <https://medium.com/@Viruthagiri/smtp-ports-25-vs-587-vs-465-de1046f57636>. Thanks On Sun, Jan 13, 2019 at 9:45 AM Owen DeLong <owen@delong.com> wrote:
On Jan 11, 2019, at 09:38 , Viruthagiri Thirumavalavan <giri@dombox.org> 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.
How would (2) be different from the previous SMTPS port 465 which was deprecated?
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
https://www.mailgun.com/blog/which-smtp-port-understanding-ports-25-465-587
Seems to agree with my recollection that 465 was never specifically for submission and that it was deprecated shortly after the introduction of STARTTLS.
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.
As a general rule, I think separate ports for TLS-ified versions of existing protocols isn’t the right solution and simply wastes ports.
Thinking this through, I don’t think you actually solve the existing problem, either.
A client wanting to use your new port 26 would need to fall back to port 25 by default if the MTA at the other end didn’t support port 26. As I see it, there are the following remote MTA possibilities (ignoring submission on 587 and ignoring any possible legacy implementation on 465 for now):
1. Remote MTA supports port 26 and STARTTLS on port 25. 2. Remote MTA supports only port 25 with STARTTLS 3. Remote MTA supports only port 25 in clear text
So long as the client will fall back to port 25, you have an identical vulnerability to man in the middle attack in all 3 cases:
1. If port 26 is attempted, Send back a TCP RST or ICMP port unreachable message in response to the connection attempt on port 26. 2. Conventional STARTTLS Downgrade attack.
If you have some way to remove the need for fallback to port 25, then you can in all of those instances simply remove the willingness to communicate with an MTA server that does not offer STARTTLS as part of the negotiable option set in response to the EHLO, thus eliminating the acceptance of a downgrade attack.
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.
So the naming convention thing might be usable, but I don’t see any advantage to the explicit TLS port vs. just providing naming-based hints about STARTTLS.
What IETF Mailing list thinks? - "Implicit TLS doesn't offer any additional security than a downgrade protected STARTTLS. Let's not waste a port.”
I’m inclined to agree here… See above.
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.
I don’t think so. First, I think the word you actually want is explicit (specified) vs. implicit (implied). Second, I’m not convinced that it is any more explicit. If you have an immutable out-of-band way of communicating STARTTLS support, then I don’t see port-based explicit as being in any way superior to rule-based explicit use of STARTTLS. So I’m not convinced that chewing up a port just to feel good about explicitness offers any tangible benefit. Third, I think rather than conveying the positive vibe you wish to imply that it would, instead, indicate that the IETF:
1. Can’t make up it’s mind about TLS on SMTP (yes, 465; no, use STARTTLS instead; yes, but this time on port 26) 2. Doesn’t care about wasting well-known port numbers (which are in relatively short supply)
I’d consider both of these to be a pretty negative vibe.
What the world thinks? - https://gist.github.com/mistergiri/138fc46ae401b7492662a32409edb07f
Most of the comments from the world appear not to fully understand the problem and have not thought through the implications I mention above.
If your intent is for all upgraded client sides not to ever try port 25 (thus render them unable to connect to servers that don’t support your port 26 hack), then what do you gain vs. the already present option to tell your software to reject any MTA that doesn’t offer STARTTLS as an option or fails to negotiate TLS when you request it?
If that’s an option, just turn that on and you’ve got all the same security this solution would offer without wasting a port.
Owen
-- Best Regards, Viruthagiri Thirumavalavan Dombox, Inc.
On Fri, Jan 11, 2019 at 6:23 PM Viruthagiri Thirumavalavan <giri@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
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.
Yes that's what I meant in my proposal too. 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.
Ok. That makes sense. 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.
This proposal just trying to do the job simpler. Let me copy paste some part I posted in ietf-smtp forum. ---- DNSSEC already protects my DNS records from spoofing. So I believe all my DNS records are secure when I enable DNSSEC. My domain is dombox.org and if I have mx records like mx1.dombox.org mx2.dombox.org mx3.dombox.org mx4.dombox.org mx5.dombox.org then those MX records are already protected from forgery since I have now enabled DNSSEC. Now I need to add DANE TLSA record to let the world know that my port 25 supports STARTTLS. So clients can detect downgrade issues. The TLSA records looks like this. 25._tcp.mx1.dombox.org. IN TLSA 3 0 1 ae822a14fd5e56c213eeeb5d6755556980caf4c3f2531c1ec8eca3076f9b7e68 25._tcp.mx2.dombox.org. IN TLSA 3 0 1 ae822a14fd5e56c213eeeb5d6755556980caf4c3f2531c1ec8eca3076f9b7e68 25._tcp.mx3.dombox.org. IN TLSA 3 0 1 ae822a14fd5e56c213eeeb5d6755556980caf4c3f2531c1ec8eca3076f9b7e68 25._tcp.mx4.dombox.org. IN TLSA 3 0 1 ae822a14fd5e56c213eeeb5d6755556980caf4c3f2531c1ec8eca3076f9b7e68 25._tcp.mx5.dombox.org. IN TLSA 3 0 1 ae822a14fd5e56c213eeeb5d6755556980caf4c3f2531c1ec8eca3076f9b7e68 I think we can can simplify that part via CNAME record. But, let's not go there. Now my first question is, does that "fingerprint" adds any security in a "Third party CA" system? Or it's there just to be compatible with the DANE system since DANE is not a mail specific system? My second question, if my MX records are configured to use google MX servers (e.g. aspmx.l.google.com) whose job is to configure those DANE TLSA records? Google or Me? I believe it's not my job. Because there is no easy way I can have Google MX server certificate fingerprint unless google provides it. Even if they provide it, if google change their certificate for security reasons in the future, then that's gonna break millions of domains that depends on Google mail servers. So that would be a poor design. If I'm not wrong Google is against DNSSEC. So there is no way they are gonna configure DANE records like this. 25._tcp.aspmx.l.google.com. IN TLSA 3 0 1 ae822a14fd5e56c213eeeb5d6755556980caf4c3f2531c1ec8eca3076f9b7e68 25._tcp.alt1.aspmx.l.google.com. IN TLSA 3 0 1 ae822a14fd5e56c213eeeb5d6755556980caf4c3f2531c1ec8eca3076f9b7e68 25._tcp.alt2.aspmx.l.google.com. IN TLSA 3 0 1 ae822a14fd5e56c213eeeb5d6755556980caf4c3f2531c1ec8eca3076f9b7e68 25._tcp.alt3.aspmx.l.google.com. IN TLSA 3 0 1 ae822a14fd5e56c213eeeb5d6755556980caf4c3f2531c1ec8eca3076f9b7e68 25._tcp.alt4.aspmx.l.google.com. IN TLSA 3 0 1 ae822a14fd5e56c213eeeb5d6755556980caf4c3f2531c1ec8eca3076f9b7e68 Hopefully, That is one of the reason why MTA-STS got introduced. Even if I love DNSSEC and support it in my domain, Google sets the rules here since I'm relying on their mail hosting. I have no other way, other than supporting MTA-STS since google is against DNSSEC. ------ 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
It's still vulnerable to MiTM attack right? 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.
My solution is vulnerable to MiTM without DNSSEC. I guess I should update my proposal saying DNSSEC mandatory. But if you believe the prefix solution itself flawed, the what's the point. Thanks for the input. Those are all very helpful comments. On Sun, Jan 13, 2019 at 11:36 PM Jimmy Hess <mysidia@gmail.com> wrote:
On Fri, Jan 11, 2019 at 6:23 PM Viruthagiri Thirumavalavan <giri@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
-- Best Regards, Viruthagiri Thirumavalavan Dombox, Inc.
participants (25)
-
Bjørn Mork -
Brandon Martin -
Brian Kantor -
Constantine A. Murenin -
Cummings, Chris -
Doug Royer -
Eric Tykwinski -
James Downs -
Jason Hellenthal -
Jimmy Hess -
John Levine -
Jon Lewis -
Michael Thomas -
Owen DeLong -
Richard -
Robert Blayzor -
Ross Tajvar -
Seth Mattinen -
Suresh Ramasubramanian -
Tom Beecher -
Töma Gavrichenkov -
valdis.kletnieks＠vt.edu -
Viruthagiri Thirumavalavan -
William Anderson -
William Herrin