On Tue, Aug 08, 2017 at 12:08:05PM -0700, Daniel Margolis wrote:
> So forgive me for fleshing out slightly more, but I believe "removal" is
> comprised of roughly the following behaviors:
>
> A. MX/certificate changes don't affect mail delivery
> B. MX/certificate changes don't affect TLSRPT reporting (since a domain may
> wish to continue to use TLSRPT but stop using MTA-STS)
> C. Any resource impact on *senders to this domain* from doing MTA-STS
> validation is eliminated
> D. It is safe to remove the policy and TXT record
>
> (D), I believe, is invariant in all implementations: any hypothetical
> "removal" flow *will* involve serving the "removal" signal (whatever it
> is--a max_age=0 policy or anything else) until the last point in time the
> *old* policy was served + that policy's max_age. So (D) does not
> distinguish between different "removal" options.
It must be possible to phase out the STS policy and decommission
the associated HTTPS service.
So, it I think that it is D that I'm trying describe, and specifically
looking for D to happen "cleanly", that is, removal happens without
policy refresh failures that look like an active attack.
> *Currently: *By setting "mode=report", you can achieve (A), but not (B).
Not the subject of this thread.
> *Under the "max_age=0" proposal: *You can achieve (A), (B), and (C).
The *combination* of max_age=0 *and* empty TXT id, makes it possible
to cleanly transition from STS to no STS with no DNS TXT record
and no HTTPS policy object.
> *Alternatively: *If we had a "mode=none", you would achieve (A) and (B) but
> *not* (C), since senders would cache the "mode=none" policy until max_age
> has passed).
mode=none still requires period refresh via HTTPS. So it fails the
requirement to be able to erase all trace of STS.
> I also believe property (C) is unimportant, since senders who implement
> MTA-STS must be resilient (in the resource usage sense) to recipients who
> have live policies; they can't in any way depend on the recipient revoking
> a policy to keep the cost of policy validation or caching down.
Once again the goal is to give the domain that publishes the policy a
clean way out.
> *Questions:*
>
> Is the "mode=none" proposal simpler or more complex than "max_age=0"?
It fails to address how to actually *remove* all STS policy.
The domain owner should be able to discontinue the underlying
HTTPS service, and periodic policy updates from senders.
--
Viktor.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
