Subject: [Uta] Expired/sold domains with a long max_age policy

From: Ayke van Laethem <[email-masked]>
Date: Wed, 16 Aug 2017 02:39:43 +0200

I see a potential issue with very long max_age rules. Consider that
the domain name example.org is sold to someone else, but the previous
max_age in the policy was set at 10 years and various hosts (e.g.
gmail.com) have sent email to example.org and thus have a cached
policy.
So if the new owner of example.org decides to add email, they *have
to* also implement STARTTLS with the given MX hosts in the previous
policy (which will often be impossible due to moving to a different
email provider), or publish a new MTA-STS policy. If they don't know
MTA-STS was used before, sending email will not work from some
domains, without a clear signal as to why this is the case.

Note that setting up MTA-STS requires some effort above simply setting
up email itself (setting up STARTTLS, setting up a new mta-sts domain,
obtaining a certificate, serving a new policy file). It is also not
like HSTS: with HSTS the only requirement is enabling HTTPS, but with
MTA-STS many more things need to be configured to override or adhere
to a cached policy.

My suggestion would be to add to the description of max_age that long
durations may not always be desirable.
Another option is to limit max_age to one year, similar to how HTTP
used to limit caching to one year [1][2]. Also see [3]. This is not a
perfect solution, but it will reduce the size of the problem.

[1]: https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.3
[2]: https://tools.ietf.org/html/rfc7234#section-5.3
[3]: https://github.com/mrisher/smtp-sts/blob/master/mta-sts.md#denial-of-service

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 16 Aug 2017 06:06:48 +0000

On Wed, Aug 16, 2017 at 02:39:43AM +0200, Ayke van Laethem wrote:

> email provider), or publish a new MTA-STS policy.

If they take over the domain, they presumably also take over DNS.
If they don't intent to implement STS, they will not publish the
TXT record, which is a change in the TXT record, and thus any cached
policy should trigger a refresh attempt.  

For that refresh attempt to cause the policy to be flushed there
would actually need to be an HTTPS server serving a "none" policy.

> If they don't know

Yes, the new domain owner would have to know that the domain had
STS< or just publish a "none" policy in case there was a previous
policy in place.  The difficulty is of course how long such a "none"
policy should be in place.  For this to be a manageable duration,
there should be a maximum "max_age" that sending systems accept,
with any higher values truncated to that maximum.

> perfect solution, but it will reduce the size of the problem.

Yes, with the limit imposed by each sender and a "SHOULD NOT" on publishing
max_age beyond that limit for receiving domains.

-- 
	Viktor.

---

From: Daniel Margolis <[email-masked]>
Date: Wed, 16 Aug 2017 10:07:28 +0200

I'm OK with a one-year SHOULD NOT. Realistically, though, that year could
still be painful; as Viktor said, there's always the opt-out option (but,
yes, you have to get a certificate, set up DNS, etc).

I would liken this more to HPKP than HSTS; HPKP, unlike STS, has (as far as
I can tell) no workable opt-out mechanism; if someone pins a leaf
certificate that the new domain owner doesn't have, the new domain owner is
screwed until/unless the policy expires. I'm not saying that's in any way a
mitigation of STS having some similar issues, though I'm also not
personally aware of HPKP being abused like so in the wild. (Then again,
HPKP adoption appears to be fairly minimal, so this has less chance of
happening by accident.)

On Wed, Aug 16, 2017 at 8:06 AM, Viktor Dukhovni <[email-masked]>
wrote:

> _______________________________________________
> Uta mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uta
>