[Top] [All Lists]

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

2019-01-10 00:48:16
Hello Viruthagiri,

Concerning DANE I propose you read RFC 6698, RFC 7218, RFC 7671, RFC 7672. The 
latter shall answer your question.

In your particular case, you have to find first a statement from Google, that 
they cannot disable anytime at their
disposal STARTTLS, and before this is done at your place I would not publish 
information that to your domain only
secured connections can be made.  In particular I would not publish MTA-STS 

I have read the DANE RFCs long time ago and I do not remember every detail.  In 
theory you can publish the IP addresses
in charge for your emails under your domain and sign that A(AAA) records.  The 
hash of the used certificates is
published over TLSA.  However certificates are changed from time to time and 
before the change you have to publish in
DNS both the current and the next certificate, as you correctly recognized.  
Then wait until the next certificate is
distributed over DNS and only then switch the STARTTLS certificate.  So you 
need in this scenario also to know when the
certificates will be changed and to know the certificate that is going to be 
applied next.  I do not know whether this
information is published, but there are no compelling reasons not to do so.

If you want to get a feeling how SMTP works in practice I recommend you run 
your own mail server.  If you want to use a
provider, find one that matches your needs.


On Thu, 2019-01-10 at 11:40 +0530, Viruthagiri Thirumavalavan wrote:
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 and if I have mx records like 

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. IN TLSA 3 0 1 
ae822a14fd5e56c213eeeb5d6755556980caf4c3f2531c1ec8eca3076f9b7e68 IN TLSA 3 0 1 
ae822a14fd5e56c213eeeb5d6755556980caf4c3f2531c1ec8eca3076f9b7e68 IN TLSA 3 0 1 
ae822a14fd5e56c213eeeb5d6755556980caf4c3f2531c1ec8eca3076f9b7e68 IN TLSA 3 0 1 
ae822a14fd5e56c213eeeb5d6755556980caf4c3f2531c1ec8eca3076f9b7e68 IN TLSA 3 0 1 

I think we can can simplify that part via CNAME record. But, let's not go 

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. 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. IN TLSA 3 0 1 
ae822a14fd5e56c213eeeb5d6755556980caf4c3f2531c1ec8eca3076f9b7e68 IN TLSA 3 0 1 
ae822a14fd5e56c213eeeb5d6755556980caf4c3f2531c1ec8eca3076f9b7e68 IN TLSA 3 0 1 
ae822a14fd5e56c213eeeb5d6755556980caf4c3f2531c1ec8eca3076f9b7e68 IN TLSA 3 0 1 
ae822a14fd5e56c213eeeb5d6755556980caf4c3f2531c1ec8eca3076f9b7e68 IN TLSA 3 0 1 

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 
"", 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 

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."


"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."


"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 


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


"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 


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


"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.""


"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."


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


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


"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."


"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?"


"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."


"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."


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


"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 


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


"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 


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


"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 


"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."


"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 

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?"


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. 

ietf-smtp mailing list

ietf-smtp mailing list

<Prev in Thread] Current Thread [Next in Thread>