[schoen]

I think the title of the submission is mis-editorialized. The comparison that my colleagues working on this project make is that it's like HTTPS Everywhere, or even more like the HSTS preload list, rather than like Let's Encrypt. I don't think you'll find the comparison to Let's Encrypt on the site itself.

(Edit: in addition to the site tester that you noticed, there is also a public policy list and some forthcoming tools to enforce STARTTLS on the client MTA side when delivering e-mail, preventing downgrade and MITM attacks.)

However, you can also use Let's Encrypt to make this more useful by getting a publicly-trusted certificate for the TLS service on your mail server, and then listing your mail server with this list!

The introductions my colleagues posted about this today are at

https://www.eff.org/deeplinks/2018/06/announcing-starttls-ev...

https://www.eff.org/deeplinks/2018/06/technical-deep-dive-st...

which will hopefully give a clearer explanation of what the service is meant for.

[devereaux]

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.

[schoen]

> SSL is not mandatory on either port 25 or 587, and can not be made mandatory if you follow the RFCs.

I'm well-aware of the RFC difficulty, but I don't think that the current approach of STARTTLS Everywhere is really a problem because it's effectively opt-in on both ends. The enforcement is requested by the receiving side and then implemented by the sending side.

* The receiving MTA has to proactively choose to be listed.

* The sending MTA has to proactively choose to make use of the list.

So, with the current version of STARTTLS Everywhere, only sites that deliberately choose to enforce STARTTLS will do so, and they will only do it when communicating with sites that have specifically asked them to enforce it! This would only be an RFC violation if we thought that the RFC meant to categorically forbid sites from separately agreeing to a stricter security policy.

This approach might have its scalability limitations, but I won't try to speak for my colleagues about any future steps.

[devereaux]

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

The problem is not the MTA who will chose to be listed, but those who won't be listed - the immense majority. "Scalability limitation" is certainly a more polite way to say that.

I'm sorry if my message was too blunt, but I am not sure it was worth downvoting my technical explanation just for this.

[pde3]

We think we can make a huge difference even by listing a few dozen or a few hundred of the highest-traffic email domains.

[schoen]

I didn't downvote you; I'm sorry someone else did.

The HSTS preload list also has a huge scalability problem, but it's also improved the situation about HTTPS downgrades a lot!

[dang]

Ok, we've changed the title above to the hopefully least controversial part of the article's original title. (Submitted title was "STARTTLS Everywhere: HTTPS Everywhere, but for SMTP".)

[schoen]

Oh, the submitter had already changed it. The original submitted title was "STARTTLS Everywhere: Let's Encrypt, but for SMTP").