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

[Viktor Dukhovni <[e-mail]>]

> 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.