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.
