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.


Uta mailing list

Reply via email to