Re: [Uta] STS policy removal

[Daniel Margolis <[e-mail]>]

>
>
> That's not the problem.  The problem is that even after that time expires
> the
> current specification does not appear to provide a means to *ever* stop
> publishing
> a policy.  A "report" policy will get cached and then be subject to
> another timer,
> lather/rinse/repeat.  How does the "report" policy ever transition out of
> existence,
> without looking like a downgrade attack?
>
> Are you suggesting to rely just on eventual flushing of expired cache
> entries that
> fail to refresh?


Yes. A "report-only" policy with a short max_age (like 1 day) means a
client will continue to refresh the policy once/day and, once the time
period we have already discussed has passed, will forget it in a day.

In terms of optimizing this period of time, there are no options that I
see: as I previously noted (though this is trimmed in your reply; just for
casual readers I am referring to
https://www.ietf.org/mail-archive/web/uta/current/msg01983.html), absent
(complex) changes to the TXT records, senders will have to cache some
policy existence data anyway, for some period of time, so they will have to
cache *something* for *some period*, essentially equivalent to "some period
after the expiration time we have discussed", e.g. 1 day. :)


> And in the mean-time clients may burn some cycles keeping reporting
> data that is unwanted, and may never be sent.
>

Yes, indeed. So my point was that you could solve this by having a "none"
mode (i.e. neither enforce nor report), but the only part of this issue we
can optimize is the one you note here (keeping reporting data); *not* (at
least without reworking the DNS advertising model, which I think is
needless complexity) the caching time.


> There ought to be a way to cleanly stop the process without failing
> retries at the
> end of the cycle.  A "max_age = 0" should suffice (published for the
> previous
> max_age + DNS TTL).
>

It's still not clear to me whether you are trying to save sender cache
entries, sender reporting cycles, or both. I think it would be more clear
to split the discussion on those two things.

As I noted, you could certainly set "report=false" and "enforce=false"
(effectively) by adding some mode switch for this, but the only thing it
would optimize is the "keeping stats for reporting is expensive" concern.
(I am not really convinced this is that expensive, but it's a fair point.)

*Separately*, I do not believe "max_age=0" makes cache expiration easier.
As I have already noted, senders who purge a cache entry upon seeing
"max_age=0" will then...see the _mta_sts TXT record for this domain next
time they check and fetch the policy! So they have to cache the policy to
avoid hitting the HTTPS endpoint all the time.

How do you propose this should work? It may help me to better understand
your suggestion if you flesh it out a little bit more. For example, would
senders cache the presence of a "max_age=0" policy for a hardcoded amount
of time?


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