postfix and MTA-STS

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

postfix and MTA-STS

A. Schulze
Hello,

one way to implement MTA-STS in postfix is a server that generate responses
that smtp_tls_policy_maps can consume. I evaluate https://github.com/Snawoot/postfix-mta-sts-resolver...

smtp_tls_policy_maps = socketmap:inet:mta-sts-resolver.example:8461:postfix


this works, but ...
the MTA-STS Policy is also locked up for destinations that may be verified by DANE.

So, where is the problem?

I could setup a MTA without access to the usual CA trust store data - SMTP via TLS is opportunistic.
Also image a destination (mail.de or my domain for example) that could be verified by DANE *and* publish
a MTA-STS policy.

If an MTA connect to such a destination the smtp_tls_policy_maps setup "overwrite" DANE
by returning "secure match=$(MX-List from MTA-STS)"
Now the MTA is required to have access to a CA truststore, otherwise the smtp_tls_policy_map result
let the MTA not deliver the message.

Somehow I feel uncomfortable with such a setup but I've no idea how to avoid that with the current postfix-3.4.5
(beside providing postfix access to a full CA trust store)

Andreas
Reply | Threaded
Open this post in threaded view
|

Re: postfix and MTA-STS

Wietse Venema
Perhaps you could allow the Postfix SMTP client to have access
to the PKI store, and let that SMTP client use DANE certificate
verification for some domains, and PKI for others.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: postfix and MTA-STS

Viktor Dukhovni
In reply to this post by A. Schulze
On Sat, Apr 27, 2019 at 08:09:51PM +0200, A. Schulze wrote:

> one way to implement MTA-STS in postfix is a server that generate responses
> that smtp_tls_policy_maps can consume. I evaluate https://github.com/Snawoot/postfix-mta-sts-resolver...
>
> smtp_tls_policy_maps = socketmap:inet:mta-sts-resolver.example:8461:postfix
>
>
> this works, but ...
> the MTA-STS Policy is also looked up for destinations that may be verified by DANE.
>
> Imagine a destination (mail.de or my domain for example) that could be verified by DANE *and* publish
> a MTA-STS policy.
>
> If an MTA connect to such a destination the smtp_tls_policy_maps setup "overwrite" DANE
> by returning "secure match=$(MX-List from MTA-STS)"

The socketmap service could check for DANE TLSA records first, and
return "dane", it would have to check that the domain is DNSSEC
signed, and then check whether all of (the first 10 by preference
to reduce delay) the MX hosts have TLSA records.

> I could setup a MTA without access to the usual CA trust store data - SMTP
> via TLS is opportunistic.
>
> Now the MTA is required to have access to a CA truststore, otherwise the smtp_tls_policy_map result
> let the MTA not deliver the message.

I don't see how the trust store is relevant here.  For MTA-STS, you need
to trust the full set of CA/B forum CAs.  For DANE the trust store is
ignored.

Adding the full trust store is largely harmless, unless your goal
is to "harden" MTA-STS by trusting only the subset of CAs actually
used in practice by "real" MTA-STS domains.  No idea how you'd
know ahead of time which CAs those should be.

Postfix does not presently support MTA-STS.  My advice would be to
run a cron job daily or weekly, that looks for mta-sts DNS and
policy records for domains to which you've sent email, and once
they have an "enforce" policy, add them to the TLS policy table
if they don't also have DANE.

That is, do MTA-STS out of band.  It is not secure on first
contact, so having the first batch of emails go out with
opportunistic TLS before the cron job sees the traffic is
fine.

You could also use a separate transport for these, in which case
the trusted CAs can be specific to MTA-STS, with fewer CAs trusted
for any domains which you have specifically designated for "secure"
WebPKI delivery.

--
        Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: postfix and MTA-STS

A. Schulze
Hello Viktor,


Am 27.04.19 um 23:26 schrieb Viktor Dukhovni:
> The socketmap service could check for DANE TLSA records first, and> return "dane", it would have to check that the domain is DNSSEC> signed, and then check whether all of (the first 10 by preference> to reduce delay) the MX hosts have TLSA records.
That mean the external application will do the same job as postfix does:
determine DANE TLSA records but not validating them, right?

Isn't implementing the same job in multiple places what Wietse name "waste of ressources"?
:-)

> Adding the full trust store is largely harmless, unless your goal
> is to "harden" MTA-STS by trusting only the subset of CAs actually
> used in practice by "real" MTA-STS domains.

sounds reasonable, will think about that...

Andreas
Reply | Threaded
Open this post in threaded view
|

Re: postfix and MTA-STS

Wietse Venema
Viktor Dukhovni:
> The socketmap service could check for DANE TLSA records first,
> and return "dane", it would have to check that the domain is
> DNSSEC signed, and then check whether all of (the first 10 by
> preference to reduce delay) the MX hosts have TLSA records.

A. Schulze:
> That mean the external application will do the same job as postfix does:
> determine DANE TLSA records but not validating them, right?
>
> Isn't implementing the same job in multiple places what Wietse name "waste of ressources"?

No, it is basic separation of 1) policy selection (by the policy
service) and 2) policy enforcement (by the Postfix SMTP client).

        Wietse