Re: [Uta] Comments on draft-ietf-uta-mta-sts-03

[Daniel Margolis <[e-mail]>]

I like your text, Federico:

"If a MTA-STS TXT record is found but no policy can be fetched from the
HTTPS endpoint, and there is no previous cached policy, then senders
MUST assume the recipient domain does not implement MTA-STS."

I will get this into the latest draft. :) (This was previously implied
anyway by the fact that a failure to find a policy means there's no policy,
but it's not so clear as you make it with this edit.)

Regarding the threat of DoS'ing policy lookup until expiration has passed,
as Viktor notes, this is party mitigated by opportunistically fetching new
policies every so often (e.g. when delivering to the domain); Viktor has
previously suggested we call this out more explicitly in the draft (i.e.
that we suggest implementors seek some strategy to keep caches fresh).

In this scenario, I do still feel that there's some gap in a mechanism
(say, via TLSRPT) to allow senders who have non-expired policies from a
recipient domain to tell the recipient domain that they're having trouble
fetching that domain's policy, but the solution is not obvious to me and, I
think, of a lower priority--if you can DoS policy lookup for order of
months, you can potentially foil first discovery, too. And ultimately
long-lived DoSes are the kinds of things to best be discovered through
other transparency and reporting tools--https://gmail.com/postmaster/,
discussions on the IETF list, etc. ;)

Anyway, I'm very open to suggestions on how to make this more transparent
within the scope of TLSRPT, but I don't love the idea of adding policy
complexity by letting recipients specify what to do in this scenario.


On Mon, Mar 27, 2017 at 10:21 AM, Viktor Dukhovni <[e-mail]>
wrote:

>
> > On Mar 27, 2017, at 4:08 AM, Federico Santandrea - Diennea <
> [e-mail]> wrote:
> >
> >
> > Let's suppose the sending MTA finds the MTA-STS TXT record, which states
> > the receiving domain has an MTA-STS policy. The draft says "To discover
> > if a recipient domain implements MTA-STS, a sender need only resolve a
> > single TXT record". But what happens when the sending MTA can't fetch
> > the actual policy via HTTPS?
>
> Keep it simple.  It is just as easy to block access to the TXT record as
> to block access to the HTTPS site.  The TXT record is just an efficiency
> aid, so that MTAs don't have to attempt costly HTTPS connections (that
> typically time out) to domains with no STS records.
>
> Therefore, when the TXT record exists, but STS policy access fails, the
> right action is to assume no policy (regardless of whether this is a
> true first contact, or whether a previously cached policy had expired).
>
> STS is vulnerable to attack when no cached policy exists.  Once the
> cache is primed, email to destinations that receive ongoing traffic
> will continue to have unexpired policy data, because the sender
> should do proactive refresh of the policy before it expires.
>
> For first contact, or domains that don't receive sufficiently regular
> mail, STS is vulnerable to downgrade attacks.
>
> So the right behaviour with TXT records that don't lead to a policy,
> is to continue as though there is no policy.
>
> Indeed with Postfix (if/when STS is implemented) I'm likely to
> always do STS policy lookup in the background, in which case
> the first (more than one if concurrent) message(s) to a domain
> will always go out with opportunistic TLS, and secure delivery
> will only begin once the background policy retrieval succeeds.
>
> Delaying delivery while waiting for remote HTTPS lookups to
> complete is not especially appealing.
>
> --
>         Viktor.
> _______________________________________________
> Uta mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/uta
>