I've tried to explain a number of times that policy in STS is
problematic. This is another attempt. First what I believe
to be the requirements:
1. We need to provide a means for a domain to transition
from having an STS policy to not having an STS policy.
2. The transition process should not look like failure to
obtain the policy, generating warnings in the logs that
don't look different from an active attack.
3. It should be possible to remove policy in a timely manner.
We have two signalling methods understood by STS-capable clients:
A. The DNS TXT record which triggers a policy refresh when
different from the previously observed value.
B. The STS policy obtained via WebPKI-authenticated HTTPS.
Based on the requirements, it should be possible to construct a
combination of the TXT record and STS policy that have the
following semantics:
I. The STS policy causes clients to flush the existing cached
entry, thereby enabling "clean" timely policy removal. Clients
that do policy refresh in the background may still send a few
messages based on previously cached policy, but should have
current policy by the time any deferred messages are retried.
II. The requisite TXT record will cause a refresh of existing
cached policies, but will avoid new policy requests if the
client does not yet have a cached policy for the destination
domain. This avoids a state in which clients constantly look
for a new policy after removing the current policy.
To this end I propose the following design refinement.
a. In the STS policy a value of 0 for max_age signals policy
removal.
b. In the STS DNS TXT record, an empty "id" value implies that no
new policy is expected. Just as with other changes in the id
value an empty id must also trigger refresh of cached policies,
but must not trigger attempts to load new policies.
The process for clean policy removal is then:
i. Publish a new policy with max_age=0, check that all HTTPS
servers have the new policy.
ii. Publish an empty value for the id in the TXT record.
iii. After the expiration of all previous policies (time
of publication + non-zero "max_age"), delete the
empty id TXT record.
The client state is then one of the following:
1. No policy in the cache
When seeing empty id TXT do nothing, just as with NXDOMAIN
or NODATA
2. A policy in the cache with max_age=0 and an expiration
time derived from the DNS TTL of the non-empty id TXT
record that was observed at the time of policy refresh.
Such policies do not enforce TLS or send reports.
When seeing empty id TXT, NXDOMAIN or NODATA, flush such
a cached policy.
If instead (before an empty or non-existent TXT record is
seen) a new policy appears with max_age > 0, cache that.
3. A policy in the cache with max_age > 0 and non-empty TXT id.
Enforce TLS and/or send reports.
If a new policy with max_age=0 is seen along with a non
empty id in the TXT, cache that for the DNS TTL of the TXT
record.
When an empty TXT id is seen fetch the new policy, it will
typically have max_age=0, but otherwise is treated just as
any other policy.
4. A policy in the cache with max_age > 0, and an empty TXT id.
Treat as any other policy until a refresh results in max_age=0.
At that time, if the TXT is empty or missing flush the policy
without further caching.
The basic idea is that an empty TXT tells existing caches to update,
but does not elicit fresh cache entries. While a cache entry with
"max_age=0", waits for the TXT record to become empty or deleted,
so as to avoid policy refresh on every delivery while the TXT id
remains non-empty. The expiration time of the "max_age=0" cache
entry is based on the DNS TTL of the observed non-empty TXT id.
--
Viktor.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
