Hi, Viktor,

Thanks for the thorough writeup. A question about the "requirements" stated:

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.


What do you mean by "remove" and "not having" a policy? What specific
behavior do you want from senders?

E.g. senders will stop

a) performing any kind of certificate validation checks per the policy?
b) making reports based on those checks?
c) any change in delivery behavior based on those checks?
d) maintaining a policy cache entry for the recipient domain?

The reason I ask is that some of these are achievable today, and some of
them are achievable with more minimal modifications than the flow you
describe.

Thanks.

On Mon, Aug 7, 2017 at 5:55 PM, Viktor Dukhovni <ietf-d...@dukhovni.org>
wrote:

> 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
> Uta@ietf.org
> https://www.ietf.org/mailman/listinfo/uta
>

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta

Reply via email to