> On May 10, 2018, at 12:16 PM, Daniel Margolis <[email protected]> wrote:
>
> Yes, you're right. I take back my comment, though I'm glad I made it since it
> clarified this whole thing. ;)
>
> I've rewritten this to
>
> 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 example, by
> checking their cached version string against the live policy in a background
> task that runs daily or weekly and updating their cache's "max age"
> accordingly), an attacker would have to foil policy discovery consistent
I don't understand what is meant by "checking their cached version string"
in:
(for example, by checking their cached version string against the
live policy in a background task that runs daily or weekly and
updating their cache's "max age" accordingly)
Can you elaborate. Are you saying that it is enough to check that
the TXT record has not changed to extend the policy max_age? Without
connecting to the HTTPS site?
Does that mean that a site that removes its "mta-sts" HTTPS service
endpoint but keeps a stable TXT record in place will be able to
indefinitely support policies at senders who originally obtained
the policy?
I am ambivalent about this approach. For example, if a site does
the DNS and HTTPS updates out of order, a sender might never learn
the right (most recent) policy...
Or am I misreading the new text?
--
Viktor.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
