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.
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
What is the IETF draft name?
Which IETF mailing list did this discussion happen on?
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.
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
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.
While we're at it, let's deprecate IPv4 now that IPv6 is fully deployed.
-Bill
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.
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
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.
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.
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
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.
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
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
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
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.
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?
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.