On 2019-01-31 at 10:10 +0000, Jeremy Harris via Exim-users wrote: > On 31/01/2019 09:47, sqit via Exim-users wrote: > > Forgive me if there has already been a thread on this but I didn't see one. > > Is MTA-STS policy validation being considered for the Exim development > > roadmap? > > Not by me. The requirement to involve an http server puts me off. > > I can't speak for other Exim devs, and contributions are generally > welcome - if they come with testsuite coverage and preferably some > indication of actual use in-the-wild.
I am opposed to MTA-STS as it embodies the security and failures of TLSA usages 0 and 1 (PKIX-TA(0) and PKIX-EE(1)) which are in RFC 7672 section 3.1.3 described as SHOULD NOT for use with SMTP. If entity A publishes policy in DNS for domains {a0, a1, a2, .. aN} then that policy should not have any impact upon the security of connecting to servers for domains {b0, .. bN} run by entity B. Yet the PKIX-TA/EE usages provide just that: DANE-TA says that in addition to meeting the trust anchor requirements for this connection, the client software must also fully trust this certificate authority for all TLS connections not otherwise constrained by DANE. That's not their business and not their authority. Once you have that, in an environment where postmasters get harassed to just make the mail flow, you have a race-to-the-bottom spiral of ever more unreliable CAs having to be trusted, in order to reach some organizations. Instead of the PKIX being "only those you trust" it becomes "you have to trust every disreputable org on the planet". In a federated system of servers, with no end-user to click OK and affect _only their connection_, being able to force third party trust is reprehensible. And yet MTA-STS embodies just this mode, with certain CAs becoming "too big to fail" and whatever the large operators trust being forced on everyone. This is not appropriate for an independent and freely operating Internet of equals. It is overreach. Stick to DANE with TLSA usages DANE-TA/DANE-EE, either of which is suitable for federated trust between servers. If not DANE for whatever reason (some FUD about DNSSEC usually) then if trying to design a replacement then *please* try to understand _why_ the DANE-implementing MTA developer community rejected PKIX-TA/PKIX-EE before going ahead and making their moral equivalent be your sole mode of operation. For exim.org, we _publish_ an MTA-STS policy. Anything which gets stupid senders to latch onto better security is something to be considered. I almost rejected it outright on moral principle, but decided to try it out. It was a close call. If you want certain large senders to reach you and use verified TLS to do so, you can consider publishing such policies. It may result in a small group of senders and their CA policies which constrain your choices, and you should figure out ahead of time when you want to cut and run, if another big sender suddenly says that your chosen CA is not good enough for them. I do not want to see Exim implement client support for MTA-STS as I believe that we would be performing a profound disservice for our users by doing so. What I say is not what goes for Exim, other developers may disagree with my stance. But I will object strongly to attempts to introduce MTA-STS client support. -Phil -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/