Yeah, I think it can go either way. But this is a suggestion we make on implementations, so I wouldn't worry *too much*; the door is open for implementors to vary approaches, and either approach (TXT optimization or not) is still compliant. I have changed the text to this:
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 fetching currently live policy in a background task that runs daily or weekly, regardless of the state of the `_mta_sts` TXT record, and updating their cache's "max age" accordingly), an attacker would have to foil policy discovery consistently over the lifetime of a cached policy to prevent a successful refresh. On Thu, May 10, 2018 at 8:56 PM Viktor Dukhovni <[email protected]> wrote: > > > > On May 10, 2018, at 2:13 PM, Daniel Margolis <[email protected]> > wrote: > > > > No, it's just a rushed edit on my part. My intent was t say that you > should check the cached version against the version in HTTPS. > > > > One could argue (as you speculated) that as long as the TXT is there, > one can bump the max-age parameter in the cache and not bother to do the > HTTPS fetch (since it should be a foregone conclusion). I don't see a > problem with that, really. > > > > (In the problematic example you give, a sender can still only cache the > old version for as long as the TXT is unchanged, which is allowed in the > specification!) > > > > In short, I think your interpretation (which was not my intent) works > perfectly fine, though I don't know that we would desire people do that. We > may want to simply not specify this--what we do want is for senders to > periodically and in advance of expiration refresh their cached policies; > technically this does not really require HTTPS I don't think, but it > doesn't hurt to do the fetch. > > > > WDYT? > > I think that extending the max_age based on just seeing the same TXT id, > while quite tempting from a performance perspective, is potentially risky. > > I'm inclined to be more conservative and require at least one actual > HTTPS policy lookup per max_age interval. This would mean that a policy > expiration would never be extended without an HTTPS confirmation. The > TXT record is then at most a policy "staleness" signal (including having > a "stale" no-policy). > > Hybrid approaches are possible, but I don't think they are warranted. > Perhaps some others should chime in as well... > > -- > Viktor. > _______________________________________________ > Uta mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/uta >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
