> On May 10, 2018, at 10:55 AM, Daniel Margolis <[email protected]> wrote:
>
> I slightly disagree with your reasoning, though I agree with the conclusion.
>
> Sender should, as we have talked about in the past, feel free to proactively
> check for new policies, but there's no real reason for them to check via
> HTTPS. If they check the TXT record and the ID has not changed, they
> shouldn't feel any need to go to HTTPS anyway--the only reason to do this is
> if the recipient has screwed up their DNS, and we should not necessarily want
> to encourage that by allowing the system to be robust to such errors, right?
Actually, not right.
1. The TXT record should be checked on every connection, and trigger an
ASAP policy update if changed.
2. The purpose of proactive refresh that is NOT based on a changing TXT
record is to update the *policy expiration time*, moving further into
the future, thus avoiding a cold start on policy expiration.
Indeed there is a problem I've failed to notice in Section 10.2:
Because this attack is also possible upon refresh of a cached policy,
we suggest implementers do not wait until a cached policy has expired
before checking for an update; if senders attempt to refresh the
cache regularly (for instance, by checking their cached version
string against the TXT record on each successful send, or in a
background task that runs daily or weekly), an attacker would have to
foil policy discovery consistently over the lifetime of a cached
policy to prevent a successful refresh.
It seems to suggest that just periodic checks of the TXT records are
enough, but they're not. Many sites will have a fixed unchanging policy
for a long time, and therefore a fixed non-changing TXT record id. So,
absent a proactive periodic HTTPS poll, the policy will expire and the
cold start attack will come into play.
A correct MTA-STS implementation should check the TXT record on every
connection (DNS lookups are cheap, locally cached, MTAs don't mind the
small latency blip, ...). A robust MTA-STS implementation that avoids
downgrade to cold-start SHOULD also proactively refresh the policy via
HTTPS. If/when this is done in Postfix, it will likely be after half
remaining expiration time since last fetch attempt (shortly after the
first delivery to the destination after such a time).
--
Viktor.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
