Re: [ietf-smtp] SMTP Over TLS on Port 26 - Implicit TLS Proposal

[Viruthagiri Thirumavalavan <[e-mail]>]

Hey all, I have some questions about DANE and I have some case to make
regarding my SMTPS proposal.

I still can't wrap my head around DANE.  I understand DANE is trying to be
"your own CA".

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.

Please correct me if I'm wrong with those statements.

-------

My above statements might be wrong. But if there is a slightest chance
those are true, isn't my design offers simpler version of the story?

Step 1: If you wanna support port 26, make sure port 25 is secure too. Then
name your records with prefix "smtps-".  If you don't wanna support port
26, but wanna secure only port 25, then name your records with prefix
"starttls-"

Step 2: Enable DNSSEC. If you can't do that, just serve a txt file in a
https server (STS).

First step should be treated as "Basic Security". And second step should be
treated as "Ultimate Security".

Isn't that simple there?

1) No need to rely on DANE here. Just DNSSEC is enough.
2) Google don't have to interfere with your decision here. You can go for
either DNSSEC or STS for authentication since Google's MX records gonna
start with "smtps-" prefix. If you don't go for DNSSEC or STS, it still
fall under "Basic Security"
3) TLSA, CNAME, SRV records very new to the people who used only MX records
before. They don't have to be forced to learn those new records since the
signalling is embedded in the MX records.

MTA-STS needs a HTTPS server.  So you need a hosting and ssl certificates.
You can get both for free these days. For example my website is hosted in
Github. Github offers free hosting for simple html pages. And you can get
SSL certificates for free via LetsEncrypt.

But it's not about tech-savvy folks who knows things. It's about non-tech
savvy folks who just get started via services like GoDaddy. GoDaddy gonna
cross-sell hosting and ssl certificates for this reason rather than guiding
them to get hosting and ssl certificates for free. Why should they?. They
are a For-Profit company. If they start to recommend free alternatives then
their business gonna lose money. So the domain owners are forced to spend
money here.  MTA-STS should be a backup plan who are paranoid about DNSSEC.
But It shouldn't be the main plan.

As for DANE. If a MX record that's protected by DNSSEC says "
aspmx.l.google.com <http://tcp.aspmx.l.google.com/>", then i'm gonna
validate the SSL certificate and make sure the domain matches. Why do we
need DANE for that? If the fingerprint doesn't add any security value and
used only for "we support STARTTLS" signalling and designed that way only
to be compatible with the DANE system, then I think we are complicating
things there.

As for introducing SMTPS on port 26, I already lost the "security"
argument. I cannot go down that road again.

But we can't just ignore Implicit TLS just because it's gonna waste a port.
My proposal at least sends out the positive vibe that the IETF still cares
about email security. Right now by keep patching STARTTLS, we are only
doing "plastic surgery" to the SMTP security.

I'm not sure why people here not backing me up with my SMTPS proposal. The
only person that supports my cause here is Alessandro Vesely.  There are
plenty of people like him out there. They are just not here.

Since no one here to back me up other than Alessandro Vesely, I have to do
some research and bring some comments from the Internet. I'm gonna leave
those comments here, just to bring some thoughts on this.

Just to be clear, I'm not in anyway saying they are all right and you are
all wrong. I'm just trying to present my case here.

And one more thing, I'm new to the IETF. If you are against my proposal and
you are one of the people behind MTA-STS and MTA-DANE related works, please
put that in the disclaimer while objecting my proposal. My proposal tries
to make the job easier for end user and trying to bring something new to
the SMTP world. I just don't want IETF to kill my proposal if people are
all biased.

Here are the comments I sourced from Hacker news.

-------

"The only (weak) argument I can find is that since servers that had a port
465 open also had to keep a port 25 open for compatibility, you could
perform the same downgrade attack by blocking connections to port 465,
which would result in a submission to the port 25. But that's a "if it's
broken let's make sure it remains broken" kind of argument."

https://news.ycombinator.com/item?id=17399079

-------

"How did these committees think that optional, downgradable encryption was
preferable to a standalone, encrypted only port (465)? Were they trying to
save server ports, like if it was a precious resource? Any design decision
I have seen regarding email since 2000 defies common sense. Like I heard
most SMTP implementations do not validate certificates. What good is an
unvalidated certificate? SPF is treated as indicative only or ignored."

https://news.ycombinator.com/item?id=17398280

-------

"True, but the underlying question is still interesting: why isn't there a
similar TLS-only port for MTA-MTA and we all agree to try to connect there
first"

https://news.ycombinator.com/item?id=17400554

-------

"I'm not a big fan of STARTTLS, I'd rather just have implicit TLS (All or
nothing) from the get go."

https://news.ycombinator.com/item?id=17401895

-------

"I appreciate what they're trying to do, and it may improve the status quo,
but we've learned that the push away from implicit SSL/TLS and towards
STARTTLS was wrong. Using one insecure aspect (DNS) to note that you SHOULD
be able to do TLS with my mail server isn't a great solution.
We need to revisit the STARTTLS vs implicit TLS debate in light of the
obvious vulnerability and overhead of starting with plain TCP connections
and then hopefully signalling towards security. HTTPS is obviously implicit
TLS and it works great. We know STARTTLS has issues. Can we not keep going
down the STARTTLS road for email, while going down the implicit TLS road
for other things?"

https://news.ycombinator.com/item?id=17402701

-------

"The problem is partly because we don't have an assigned port for MTA2MTA
implicit TLS."

https://news.ycombinator.com/item?id=17403441

-------

"The main problem with this is that STARTTLS is not anywhere near good
enough, but if it sees high adoption, nobody may bother with something
better in the future because they'll all think "Mission Accomplished.""

https://news.ycombinator.com/item?id=17398335

-------

"I fully agree. It will not achieve anything. FYI, "SMTP Require TLS" was
running on port 465 many years ago.
With many ISPs (and even some VPS) now blocking port 25, it could have been
an opportunity to migrate naturally towards the "new" unencumbered port."

https://news.ycombinator.com/item?id=17397838

-------

"Perhaps fixing STARTTLS is one of those problems where the solution adds
even more problems (and moving parts)."

https://news.ycombinator.com/item?id=17398783

-------

"So there was never really a dedicated TLS port for MTA to begin with?"

https://news.ycombinator.com/item?id=17400128

-------

"Yes - it's a weak argument, and one that's probably been debunked by
looking the way https lifted off recently. My view is if port 465 was still
around today, it would probably get the same level of attention as port 443
has. We could have been at a stage where port 25 could be made
intentionally unavailable (same way we move browsers from http to https)
and everything forced to 465. Email agent developers would be forced to
update their practices as well, no email should be sent over plaintext. At
present, there is no good way to tell your clients you're not accepting
plaintext. STARTTS is from a world where 99% of emails were plaintext."

https://news.ycombinator.com/item?id=17399344

-------

"Apparently 465 is only for mail submission, not MTA-MTA -- but of course
that still leaves the obvious questions of a) why? b) if it must be a
different port, why not make that TLS-only?"

https://news.ycombinator.com/item?id=17400568

-------

"See, at surface value I agree. But at a deeper level I don't. The problem
is too many broken protocols exist via RFC only (dns, smtp, etc). Rather
than violate that, or force it into something it's not, we should be
writing newer, better protocols. The friction against this is huge, mainly
by those who capped out at the previous RFCs, though. Email(well, smtp)
itself is so outdated and broken, I can't believe it's still so widely
used."

https://news.ycombinator.com/item?id=17398011

-------

"I'm sorry, but the problem is more complicated than that.
SSL is not mandatory on either port 25 or 587, and SSL can not be made
mandatory if you follow the RFCs (it can be made mandatory if you tweak
your MTA, but you may lose some mail). Advertising for SSL over DNS means
you trust the DNS records - which you shouldn't without DNSSEC. Even with
it, there can be workarounds that in practice will allow MITMs.

The only real solution is making SSL mandatory, and doing SMTP over SSL as
in the good old days of using stunnel on port 465 to decrypt, then netcat
to forward the output to the MTA running on localhost:25

But that is not standard. Maybe the efforts would be better invested by
changing the standards to have a port where SMTP can not happen at all
without SSL - just like port 465 was, over 10 years ago."

https://news.ycombinator.com/item?id=17397803

-------

"I agree with you, STARTTLS Everywhere is not "a problem". It is not a
solution either - at best a minor improvement."

https://news.ycombinator.com/item?id=17397850

-------

"I consider myself very technical, and know my way around Windows and Linux
pretty well (I've used both for many years), but setting up a mail server
is something I do very infrequently and find complicated to get right when
I do so, especially when getting it working with TLS, DKIM, SPF and spam
filtering."

https://news.ycombinator.com/item?id=17632545

-------

"It would be better to have a TLS connection right at the start. STARTTLS
is less secure. Why hasn't this happened for SMTP?"

https://news.ycombinator.com/item?id=17631820

-------

"Because it's not backwards compatible, and would prevent delivery of a
large amount of email.
We just need a way for domain owners to signal that their domains
definitely accept email over STARTTLS. At that point, senders which
recognise those signals can start to enforce that mail which they send to
those domains MUST use STARTTLS. Fortunately, those signalling methods are
beginning to rise to the surface. We have MTA-STS, and now also a preload
list thanks to StartTLS Everywhere."

https://news.ycombinator.com/item?id=17632756

-------

"All you need is another port in addition to the regular SMTP port. They
are not mutually exclusive."

https://news.ycombinator.com/item?id=17634344

-------

"That is completely insecure. A MITM would just block access to the
tls-on-connect port, forcing the sending host to retry on port 25, where
they would strip the STARTTLS advertisement.
Unless you're recommending to not fall back to port 25 after a failed
connection to the tls-on-connect port. In which case, see the comment you
were replying to where I said it would be backwards incompatible.

Both of the solutions I mentioned are backwards compatible, and protected
from a similar downgrade situation." (Refering to MTA-STS and StartTLS
Everywhere)

https://news.ycombinator.com/item?id=17648703

-------

"Right, I should have said that I was recommending not ever sending on 25.
The STARTTLS mitm is just too easy for large attackers.
IMHO, being backwards compatible is necessary for a transition period. The
messaging to SMTP operators should be... get on board, or you are going to
start losing mail in 1 year.

Even Chrome is going to show all http as insecure in the very near future.
Which reminds me... I need to get all my sites upgraded."

https://news.ycombinator.com/item?id=17655371

-------

"MTA-STS is pretty ill-conceived. In essence it mandates that compliant
MTAs also run a concurrent web service. The authors do not explain why this
is useful instead of the simpler approach -- enhance SMTP to reject mail on
port 25 with a NEEDS-TLS error, then fall back to implicit TLS (what port
465 was originally for)."

"The system needs to be able to authenticate a DNS-resolved endpoint. HTTPS
provides this.
Of course, they could have gone with DNSSEC, but HTTPS has the virtue of
solving the same problem (modulo proper configuration), while also being
more widely deployed and better understood."

"HTTPS does not provide authentication sufficiently well to put every egg
in its basket.
As for "better understood," the authors of this standard work for Google,
Verizon, Microsoft, and Comcast. Combined they probably serve most of the
email in the western hemisphere.

There is no excuse for overcomplicating a proposed standard -- and "we have
this stuff lying around" is no exception. This plan has the effect of
causing a networking protocol to depend on an entire series of unrelated
networking protocols.

It does not bode well for the future of independent email operators and it
provides no path forward for integrating existing devices. It pushes many,
many extra steps onto client devices, necessitating entire additional
libraries of software to deal with them. That's not a problem for companies
with tens of thousands of developers at their beck and call -- but it is
only going to raise the barrier-to-entry of operating an independent
service."

"Those sound like reasonable objections. Are you posting them to the
discussions involved in shaping and ratifying the proposed standard?"

https://news.ycombinator.com/item?id=16279241

------

Back to the original discussion, I totally agree with Mark Andrews, Valdis
Kletnieks and others that Implicit TLS doesn't offer any additional
security than a downgrade protected STARTTLS.

But, you guys are like movie critics. You go to watch movies just to find
flaws. But an average movie goers go for entertainment.  For 20 years, we
already established with the fact STARTTLS is not secure. If you wanna sell
the same thing again by saying it's secure, then you have to go into detail
and explaining why it's secure. So I believe it's much easier to SELL
"Implicit TLS" is secure than STARTTLS is secure.

My SMTPS proposal is an optional proposal. Nobody is forced to setup SMTPS.
People like me, Alessandro Vesely and many other hacker news users would
love to support Implicit TLS in SMTP even though the same level security
can be achieved via STATTLS. If something is better (at least in perceiving
this), why against it? Also note companies like google still do offer both
Implicit TLS and Opportunistic TLS for submission. So it can't hurt to have
Implicit TLS in SMTP too.

My apologies for starting the discussion again.

Thanks