> On Aug 8, 2017, at 6:24 PM, Daniel Margolis <dmargo...@google.com> 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.
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.
So the new process would be:
* Publish a "none" policy with a comparatively short "max_age".
* Remove the TXT record.
* After some time (all previous policies expire) remove the
"none" policy.
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.
--
Viktor.
_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
