search

EFForg / starttls-everywhere

A system for ensuring & authenticating STARTTLS encryption between mail servers
Other
371 stars 43 forks source link

Please clarify relation of starttls-everywhere and MTA-STS #88

Closed hannob closed 5 years ago

hannob commented 6 years ago

I hope this is the right place to raise this discussion. I'm confused about what the intention of STARTTLS Everywhere is in relation to MTA-STS.

In a blogpost in June here https://www.eff.org/deeplinks/2018/06/technical-deep-dive-starttls-everywhere EFF writes: "In order to detect downgrade attacks, we’re hosting a policy list of mailservers that we know support STARTTLS. This list acts essentially as a preload list of MTA-STS security policies."

That sounds good. Yet from all I can tell this is not what's happening right now. The current STARTTLS Everywhere web page doesn't even mention MTA-STS. When I try to submit a domain to the list I am asked to provide my MX hostnames. It provides no option to say "get the MX records from my MTA-STS policy file", which would be what an MTA-STS preload list would do.

I believe this way of operating the list is actively dangerous. Some people may start using the list without regularly updating it. So if you add your MX records you may end up in a situation where you can't change your MX records any more without breaking stuff.

jgillula commented 6 years ago

You're absolutely right! The reason for the current configuration is that this project was conceived before MTA-STS was even proposed, so for a long time the sole purpose of the STARTTLS Everywhere project was to serve as a "expect STARTTLS" preload list of sorts. By the time we launched in June and posted that blog post, there was still a lot of inertia behind that idea, and MTA-STS hadn't been officially approved yet (though it was close).

With all that said, the right way forward is indeed to eventually make the STARTTLS Everywhere policy list literally just a MTA-STS preload list. To accomplish that, our plan moving forward in the next couple of months is to (in roughly chronological order):

  1. Update the STARTTLS-Everywhere website to give users the option to instead get the MX records for inclusion in the STARTTLS Everywhere Policy list from their MTA-STS policy file.

  2. Start doing regular scanning to see what percentage of mailservers have MTA-STS policies posted.

  3. Update the STARTTLS-Everywhere website with an MTA-STS config generator: a simple tool that a mailserver admin can use to generate a MTA-STS policy file and the DNS records they should create.

Further out, the next steps are:

  1. Work on building a solution that will quickly and easily bring sender-side MTA-STS support to as many MTAs as we can. (We don't know what that solution will look like yet, but we'd love to hear your thoughts!)

  2. Add TLSRPT functionality to that solution.

  3. Start transitioning the STARTTLS-Everywhere list to an actual MTA-STS preload list, where being on the list is an indicator that the domain supports MTA-STS, and your MTA should check the domain's MTA-STS policy for details.

The primary reason we don't want to jump straight to (6) is that right now, no MTA has outgoing MTA-STS support. As a result, making the list a purely MTA-STS preload list right now wouldn't have any immediate security benefits.

With that said, I definitely recognize your concerns. At the moment we still consider the list experimental, which is why all the entries on the list are still set to "testing" instead of "enforce."

And with all that said, I'd love more feedback on our plan and if you have thoughts on how we can more quickly get to (6) while still maintaining some security benefits along the way.