Mailing List Archive

MTA-STS support?
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?

Thanks for your help!

--
## 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/
Re: MTA-STS support? [ In reply to ]
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.
--
Cheers,
Jeremy



--
## 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/
Re: MTA-STS support? [ In reply to ]
On 1/31/19 2:10 AM, 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.
>

One thing I am hoping is that an update to the standard will be
published that allows the mode (enforce or testing or none) to be
published in the DNS record for MTA-STS.

When the zone is DNSSEC signed, the MX record could then be trusted and
there would be no need to query the https server.

Querying the https server would still be needed to secure the MX hosts
for zones that are not signed.

--
## 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/
Re: MTA-STS support? [ In reply to ]
On Thu, Jan 31, 2019 at 08:58:04PM -0800, Alice Wonder via Exim-users wrote:

> One thing I am hoping is that an update to the standard will be
> published that allows the mode (enforce or testing or none) to be
> published in the DNS record for MTA-STS.
>
> When the zone is DNSSEC signed, the MX record could then be trusted and
> there would be no need to query the https server.

When the zone is DNSSEC-signed it can use DANE if its MX hosts are
also in signed zones and have TLSA records. Even Google now has a
few signed MX hosts in the form of mx[1234].smtp.goog . These are
actually alternative names for the same underlying bunch of nodes
as the unsigned names you're used to. Once they add TLSA records,
they'll have support for inbound DANE.

So I don't see a compelling case for signed domains to go with
MTA-STS.

--
Viktor.

--
## 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/
Re: MTA-STS support? [ In reply to ]
On 2/3/19 1:36 PM, Viktor Dukhovni via Exim-users wrote:
> On Thu, Jan 31, 2019 at 08:58:04PM -0800, Alice Wonder via Exim-users wrote:
>
>> One thing I am hoping is that an update to the standard will be
>> published that allows the mode (enforce or testing or none) to be
>> published in the DNS record for MTA-STS.
>>
>> When the zone is DNSSEC signed, the MX record could then be trusted and
>> there would be no need to query the https server.
>
> When the zone is DNSSEC-signed it can use DANE if its MX hosts are
> also in signed zones and have TLSA records. Even Google now has a
> few signed MX hosts in the form of mx[1234].smtp.goog . These are
> actually alternative names for the same underlying bunch of nodes
> as the unsigned names you're used to. Once they add TLSA records,
> they'll have support for inbound DANE.
>
> So I don't see a compelling case for signed domains to go with
> MTA-STS.
>

Some don't want to have coordinate certificates with fingerprints in
TLSA records, as more hosting providers provide DNSSEC just by default
when you use their DNS as well, MTA-STS may be easier than new
fingerprint from keypair every time generating new key.

And some distribution of Exim ship without DANE enabled at build-time.
Fedora, for example. Not sure why.

But I agree DANE for SMTP is better.

--
## 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/
Re: MTA-STS support? [ In reply to ]
> On Feb 3, 2019, at 11:28 PM, Alice Wonder via Exim-users <exim-users@exim.org> wrote:
>
> Some don't want to have coordinate certificates with fingerprints in TLSA records,
> as more hosting providers provide DNSSEC just by default when you use their DNS as
> well, MTA-STS may be easier than new fingerprint from keypair every time generating
> new key.

The same providers that have DNSSEC on by default often also have DANE-enabled MX
hosts, e.g. most notably one.com, but also transip.nl, domeneshop.no, ...

The job of keeping TLSA records up to date falls on the MX host operator, not
on the domain operator, so for example, one.com has to manage only a couple of
dozen TLSA RRs (to cover their various MX clusters) and thereby enable DANE for
presently ~674k domains.

> And some distribution of Exim ship without DANE enabled at build-time. Fedora, for example. Not sure why.
>
> But I agree DANE for SMTP is better.

Well, we architect for a horizon somewhat beyond the present moment, so we
can wait a bit and see how this plays out.

--
Viktor.


--
## 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/
Re: MTA-STS support? [ In reply to ]
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/