Re: [Uta] draft-ietf-uta-mta-sts-07 STS policy removal.

[Daniel Margolis <[e-mail]>]

On Wed, Aug 9, 2017 at 10:48 AM, Viktor Dukhovni <[e-mail]>
wrote:

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

"Report" is not an opt-out signal, but not for the reason you say: a
"report" policy still generates TLSRPT reports on failure, and thus is not
a true opt-out.

It does not, however, result in any change to refresh behavior. Whether a
sender has a cached policy has no impact on their behavior with respect to
refreshes, does it?


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

That's not true; once a policy expires, it can be flushed from the cache
(as it can no longer safely be used).


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

Can you point to what language in the current draft suggests that the
behavior with respect to policy refreshing differs if you have a cached
policy versus if you do not? I am still not understanding what difference
you see here.

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.


I believe this is your mistake. While I agree that one should try to
refresh a policy prior to expiration, "refresh a policy" means checking the
TXT record.

Your first sentence ("mere removal of the TXT record...") does not follow
from your second sentence.

There's zero security advantage in ignoring the TXT record and going
straight to HTTPS, since HTTPS also relies upon the (insecure) DNS
resolution. As a result, it makes no real sense to refresh the policy if
the TXT does not say to do it. A sender who implements this will appear to
be compliant with the draft--there's no real harm from doing this, aside
from maybe excessive HTTPS requests--but there's no great reason to do this
unless you think attackers can only attack the TXT record and not the
CNAME/A for the policy host.


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



> --
>         Viktor.
>
> _______________________________________________
> Uta mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/uta
>