> On Aug 11, 2016, at 8:54 PM, Mark Risher <[email protected]> wrote:
>
> This sounds interesting. So in this model, would we eschew the "max-age" in
> the policy itself and rely solely on updates to the DNS? This seems like the
> best leverage of the existing DNS caching capabilities, the lightest impact
> on the HTTPS end, and a simplification around synchronizing policy+DNS
> changes.
That's a possibility. The expiration of data from the cache might
then become local policy for flushing stale cache entires that have
not seen repeat access for a sufficiently long time. For domains with
steady traffic, the cached entry might indeed be retained indefinitely,
if the DNS signal does not change.
If the DNS entry is deleted, the cache could be refreshed, and if
HTTPS still returns anything other than a 404, the cached <id>
would become "unset", and the policy would finally be subject
to expiration.
So one still retain max-age, but it would be measured not from
the time the policy was last cached, but rather from the oldest
of:
* The last time a message was sent via that cached policy.
* The last time a DNS TXT record was seen for the domain.
This would ensure that deletion of the DNS record does not cause
constant refreshes, but rather a single refresh that unsets the
<id> (except that an authenticated 404 does clear the cached policy).
And deletion of the DNS record does eventually cause the policy to
be refreshed if the record is not seen in the DNS for an interval
of at least max-age.
--
Viktor.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta