On Tue, Aug 8, 2017 at 10:20 PM, Viktor Dukhovni <[email protected]> wrote:
> > > On Aug 8, 2017, at 6:24 PM, Daniel Margolis <[email protected]> > wrote: > > > > mode=none still requires period refresh via HTTPS. So it fails the > > requirement to be able to erase all trace of STS. > > > > How do you mean? You have to continue to serve this policy until all > other previously served policies have expired; past that point you can turn > it down at will. > > No. That's the point, you can't generally just turn it out at > will without some care, or else risk creating refresh failures > during a transition period. > Sorry, can you give an example? As I stated before: > (D), I believe, is invariant in all implementations: any hypothetical > "removal" flow *will* involve serving the "removal" signal (whatever it > is--a max_age=0 policy or anything else) until the last point in time the > *old* policy was served + that policy's max_age. So (D) does not > distinguish between different "removal" options. The time period during which a domain who opts out of STS must publish the "opt out" signal--regardless of how it is expressed--is the same in all possible implementations of any opt-out signal. > When a "none" policy is cached, it is still a policy and still > subject to periodic refresh, perhaps you're suggesting to use > "none" as a synonym for "max_age=0" that still leaves us with > a usable cache time, in which case are free to use NODATA/NXDOMAIN > as that TTL is no longer requires. I'm not entirely sure I understand you. To be clear, my point was that "mode=none" can be an indicator of "don't check anything against this policy." The rest--policy caching--still applies as normal. > So the new process would be: > > * Publish a "none" policy with a comparatively short "max_age". > Call the above time "t0". > * Remove the TXT record. > Call this time "t1." Note that this step (removal of the TXT record) can only safely be done once any *previously published* policies are expired. Normally this would require that "t1 > t0 + previous_max_age" (though of course it's possible for *previous-previous policies* to have been published with overlapping max_ages). > * After some time (all previous policies expire) remove the > "none" policy. > This can also happen at "t1", if the above is observed. > Now the clients can: > > * Cache policies with empty id (not otherwise valid) > when TXT lookup returns NXDOMAIN/NODATA. Except > when policy mode is "none" in which case the cache > is immediately flushed, and stays that way unless > the TXT reappears at some point. Refresh per max_age > and proactive update attempt cycle. > * When "none" is seen with a "TXT" id, cache that as > indicated, but if TXT disappears at any time, flush > the policy then. > > This seems to work better than "max_age = 0". However, the > same cannot be said of "report", which has no clean transition > to policy removal, as dropping the TXT record still leads to > policy refresh with no end in sight, while a suddenly missing > policy (404 and the like) is not defined (deliberately IIRC > and likely correctly) to mean policy removal. > I don't understand this statement. If you have a cached policy which has expired and there is no TXT record, why would you be refreshing the policy at all? > > -- > 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
