> 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
