On Wed, Aug 09, 2017 at 08:52:48AM -0700, Daniel Margolis wrote:

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

Yes, but "report" is NOT an opt-out signal.  It is a policy that
is subject to further cache refresh.  Please describe how you
think one correctly phases out a "report" policy without causing
apparent policy refresh failures at a sending domain?

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

No, with "none" the policy refresh can stop (and cache flushed) as
soon as NXDOMAIN/NODATA is seen for the TXT lookup.  The same is
not true for "report", to avoid downgrade attacks.

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

Because the TXT record presence/absense is *insecure* (no DNSSEC
or else we'd be doing DANE!).  Therefore the TXT record must ONLY
be used:

    1.  To signal initial policy presence when none is cached.
    2.  To signal expedited policy refresh when the id changes.
    3.  [New] To signal policy removal when the policy is "none"
        and the TXT record "disappears".
    4.  [New] Conversely to signal policy removal when the policy
        transitions to "none" and was cached in the absence of a
        TXT record (still absent).

It seems that safe policy removal and cache refresh downgrade
resistance needs more discussion to avoid implementation errors.

Mere removal of the TXT record is *not* sufficient to stop policy
refresh.  Recall that policy refresh will typically happen 
before the policy is expired (more robust continuity) and must
not at that time be subject to DNS downgrade.  When a policy
is refreshed.  It will be stored for the advertised max_age
even if the TXT record is missing.

If a policy just vanishes without a secure signal that it is
being removed, that looks like an attack, unless you want to
use 404 as a secure policy removal signal (last I asked that
was not the case).


Uta mailing list

Reply via email to