Let's Encrypt for SMTP


#1

Hello, saw a tweet about Let’s Encrypt for SMTP. There are some points I believe need to be known.

First of all, SMTP was designed without any hop to hop encryption. Unfortunately it is not like HTTP where it is easy to just use a different port to require encryption, SMTP goes through Port 25 whether it is encrypted or not.

Secondly, certificate authorities are useless for SMTP. Servers do not validate the certificate. They can’t. There is no standardized set of trusted certificate authorities and there is no human involved to evaluate what to do when there is a problem with a certificate, so certificate authorities are just ignored.

I do believe there is value in Let’s Encrypt developers being involved in helping secure SMTP but that value is not related to certificate authorities.

Look at certificates out there used by major companies. Many are expired, many don’t match the hostname, many are self-signed. This is because SMTP does not care about the validity of the certificate. It simply doesn’t. The alternative the RFC requires is plain text, so using the public key from a problematic certificate is actually more secure than using plain text because there was a problem with the certificate.

The only way to secure SMTP to SMTP is to use DANE for SMTP.

What this does, when the receiving SMTP server uses DNSSEC and has a fingerprint of their certificate in a TLSA record for TCP port 25, then the sending SMTP refuses to connect if the receiving server either does not support a cipher in common that can be used or does not have a public key that matches the fingerprint in the TLSA record.

Those are the only things that matter with DANE for SMTP -
A) Use of DNSSEC
B) TLSA record for TCP Port 25
C) Public key fingerprint matches

Whether the certificate is signed by a certificate authority or not simply does not matter, it does not add any security at all, other SMTP servers are not going to care.

What Let’s Encrypt should be working on SMTP is detecting whether or not the zone uses DNSSEC and helping the admin get that set up (which can’t be automated), creating a self-signed cert with a three year life, and generating the appropriating TLSA record for the admin to add to the zone file.

That’s what secures SMTP between hops. Signed certificates do not.


#2

A false sense of security is dangerous. Implying that a Let’s Encrypt certificate makes SMTP safer is the wrong thing to do.

Helping users set up DANE for SMTP is the right thing to do.


#3

…and who is doing that?


#4

Note: I’m just a regular here, not affiliated with Let’s Encrypt in any way…

While I support your idea for secure e-mailing, I’m not really sure how this is something Let’s Encrypt should be working on?

Let’s Encrypt is a free Certificate Authority. You just said in your argument there’s no role for Certificate Authorities (and thus Let’s Encrypt) in securing SMTP.

I’m guessing you could argue the Internet Security Research Group (ISRG) should also have a project, like Let’s Encrypt, to help people with DANE. But I’m not sure how it is Let’s Encrypts responsibility.

Also, it is very much possible to demand a valid certificate with MTA SMTP clients


#5

The EFF tweet that brought me here gave that impression, indicating that it wanted LE to bring startTLS everywhere.

starttls though only ads passive security when at attacker doesn’t want to look anyway, without DANE it is useless as it is easily stripped or MITMed


#6

MTA clients are different issue, but they should not be using port 25 - they should probably be using the submission port 587.

I’m referring to the EFF tweet that referenced Let’s Encrypt securing hop to hop SMTP - which is where certificate authorities are useless as the validity of the certificate is never checked.


#7

I’m skimming the “STARTTLS Everywhere” site, but I don’t see a reference to LE yet, perhaps you can point me to the reference directly?

Also, the “STARTTLS Everywhere” project is a project which should mitigate all the problems you’re having with secure SMTP. It also mentions DANE

So the whole argument you’re posting here “against” Let’s Encrypt, pointed here through a tweet about an EFF project to do exactly what you actually want… I’m not really seeing what you’re trying to accomplish here…?

Yes, DANE is an option to secure e-mail. But the FAQ clearly also points out some other options, like MTA-STS or their proposed “STARTTLS Policy List”.


#8

Just to clarify the issue here is SMTP hop to hop.

Certificate Authorities are of value to the MTA (endpoints) where there are humans to decided what to do if the certificate is either expired, invalid, or signed by an authority the client doesn’t trust.

It’s the hop to hop where humans are not involved the specification is to downgrade to plain text if a secure connection can’t be established.

Those connection do not care about the certificate, it’s just a container for the public key - and the public key is not validated because plain text is the fallback anyway.

DANE changes that, DANE says fail to send the mail to me if TLS can’t be used or the public key doesn’t match this fingerprint.

DANE is the only way to secure hop to hop SMTP.


#9

But… DANE is only securing hops if they participate in DANE, right?

If server A sends an email to server B in an unsecure way after which server B and server C agree to use TLS b/c server C has a TLSA record set up, how makes this the whole end-to-end connection secure? It doesn’t.

If server A doesn’t respect DANE, the whole path is unsecure.

Of course, you could say: “EVERYBODY SHOULD DO DANE!!!11111111111oneoneone”, but that’s the same as saying “Every SMTP server should do TLS in a normal matter, just like HTTPS”.

Also, the whole MitM and downgrade attacks are an issue with HTTPS too. If Alice and Bob want to communicate securely and Bobs server has a redirect to HTTPS on his HTTP webserver, Eve could easily rewrite the whole HTTP redirect and intercept the connection. That’s why HSTS was born. That’s why things like MTA-STS could also help SMTP without DANE.


#10

Hi everybody,

STARTTLS Everywhere is a specific project that addresses the link encryption issue by providing one path by which MTAs can validate certificates on SMTP hops, when the receiving server has opted in to this validation. This will deliberately change the default MTA behavior called for by the STARTTLS RFC; it’s specifically one way out of this bootstrapping conundrum.

I believe learning more details will help people to understand where this may be useful.


I tried to address some of the same issues above at

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

If you have more questions or concerns after reviewing these resources, maybe @sydneyli or @pde can help clarify them.


#11

MTAs should have signed certificates, the tweet though mentioned hop to hop with is SMTP to SMTP and not MTA to SMTP or POP3/IMAP.

Just so everyone in this thread knows, signed certificates for MTAs is a good thing (at least until MTAs start being DANE aware, and AFAIK none are)


#12

By MTA I mean what the MUA connects with - the user agents are not DANE aware.

It’s SMTP to SMTP where DANE is the only way to secure.

I send to mail.example.org over Port 587 with my login credentials - there a TLS cert should be signed.

mail.example.org sees the e-mail is destined for user@gmail.com and looks up the gmail.com SMTP host where it sends it to Port 25 - that’s the hop to hop where signed certificates are pointless.


#13

Did you take a look at the resources that I linked above about our plans for STARTTLS Everywhere?


#14

What you are trying to do though is what DANE for SMTP already does.

When the receiving SMTP has a TLSA record for Port 25 then the sending SMTP can be configured to refuse to send if the fingerprint does not match, and many SMTP servers already set up this way.

Requiring a signed certificate simply can not work because there is not official list of trusted certificate authorities, so validating a certificate against a certificate authority is pointless because some mail servers will be signed by authorities other mail servers do not trust.

That’s why DANE is the only solution that works for automated trust w/o user interaction.

There are thousands of certificate authorities globally, are there not? Blindly trusting them all so the e-mail works is kind of dangerous.


#15

Also - I run deviant.email and I initially set it up against the RFC to reject incoming mail that did not use encryption and I had to turn that off because websites all over the world often use the SMTP on the web host and do not even try TLS.

I did not have a problem sending e-mail, it seems almost every SMTP server that delivers to a mailbox does accept starttls but especially wordpress hosts, they frequently still use qmail and simply don’t send with encrypted. So users could not get notifications from those websites.

Setting it up to enforce DANE when the receiving SMTP uses a TLSA record worked beautifully, and hopefully more SMTP servers go that route, but SMTP servers have to continue to receive plain text or their users simply will not get a lot of mail.


#16

It really doesn’t look like you’ve read the resources that I linked to.


#17

``In order to detect downgrade attacks, we’re hosting a policy list of mailservers that we know support STARTTLS.’’

That’s centralization, which has a host of issues. How do you know the centralized list is accurate?

Chrome started putting TLS only host list into Chrome, and then FireFox and IE copied them. And it created problems. Why?

Because now if you want to do testing on a sub-domain, the testing has to be done with a signed certificate - self signed isn’t allowed by the browser even for testing. And getting removed from the centralized list is a pain in the arse.

DNSSEC / DANE provides a distributed list of domain names with their fingerprints that the authoritative DNS server has control over, not a centralized list.

You know way way back, the hosts list was a centralized list that was distributed and they switched to DNS because it was better than the centralized list model, easier to modify when needed.

Centralized lists aren’t the solution. DANE is, and that really is what should be promoted.


#18

Huh? All of these domains were opted-in, in an authenticated way, by their administrators. If you opt-in to HSTS (preload or long duration) and then regret it, that’s not a problem with HSTS.

DANE’s great, but relies strongly on DNSSEC, which is an even bigger challenge to roll out widely, since not even all public suffixes support it. The majority of large sites and email providers are unsigned. According to the .com registrar, less than a million/0.6% .com domains are signed. That’s an absurdly low adoption rate for a prerequisite technology.


#19

If one of the MTA’s in the chain doesn’t use DANE, then in essence, DANE is useless for that chain of SMTP hosts.


#20

If it doesn’t use DANE then you can not validate the cert fingerprint is genuine and you have a potential for MITM.