On Tue, Aug 8, 2017 at 10:20 PM, Viktor Dukhovni <ietf-d...@dukhovni.org>

> > 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.

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

> * 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
> Uta@ietf.org
> https://www.ietf.org/mailman/listinfo/uta

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Uta mailing list

Reply via email to