Re: [Uta] draft-ietf-uta-mta-sts-07 STS policy removal.

[Ilari Liusvaara <[e-mail]>]

On Tue, Aug 08, 2017 at 08:58:03AM -0400, Daniel Margolis wrote:
> 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 way I understand the request, it is full clear of policy, that is:

- The existing policy is (immediately) invalidated.
- The policy cache entry for the recipient is deleted.

And since there is no policy anymore:

- All certificate validation per the policy ceases.
- All reporting per the policy ceases.
- There is no difference in delivery behavior (for future deliveries)
  from STS policy having never existed.


This is similar behavior with what happens with HSTS if valid HSTS
header with max-age=0 is ever received: The HSTS policy is instantly
deleted and the name reverts to non-HSTS operation (http:// connections
work and certificate errors can be clicked through).


-Ilari