> On Apr 23, 2017, at 8:42 AM, Daniel Margolis <[email protected]> wrote:
>
>>>> How does a domain get rid of its STS policy? I thought we had discussed
>>>> using "max_age = 0" for this, which after being in place long enough to
>>>> assure that all previously cached policies have expired can be removed.
>>>> Or might just "404" suffice
>>>
>>> Yes, I remember discussing this. But I am not sure such a mechanism is
>>> needed.
>>
>> I rather think it is needed. When a domain changes hands, or no longer
>> wishes
>> to deal with the hassles of certificate expiration, it must be possible to
>> revoke the policy.
>>
>>> 1. Domains can publish a "report" policy (with or without a TLSRPT record!)
>>> with a low expiration
>>
>> What happens when that expires? It is again found and refreshed unless
>> there's
>> a way to ultimate say "no policy".
>
> Sure, but as I explained, given any hypothetical "opt-out" mechanism, it is
> theoretically not possible to design one which you do not have to keep
> publishing
> until $time_you_last_had_a_different_policy + $that_policy's_max_age has
> passed.
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? And in the mean-time clients may burn some cycles keeping
reporting
data that is unwanted, and may never be sent.
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).
--
Viktor.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
