Subject: [Uta] Rationale for mts-sts.<domain>

From: Ayke van Laethem <[email-masked]>
Date: Fri, 15 Sep 2017 22:02:00 +0200

Hi,

I was wondering what the rationale is for adding the mts-sts prefix to the
domain where the policy file is loaded? E.g. https://mts-sts.example.com/.w
ell-known/mts-sts.txt

As a security feature, an attacker:
- must be able to add a .well-known/mta-sts.txt file in a specific format
(or maybe redirect). Adding a .well-known URL is supposed to be difficult.
- must be able to spoof a special TXT record, either by controlling the
network (MITM without DNSSEC) or controlling the DNS itself (e.g. cache
poisoning)
- must be able to add a subdomain (otherwise the prefix doesn't have a
security advantage) and possibly issue a certificate for it

While there is certainly a security advantage with the third requirement, I
wonder how big it is? Being able to add a .well-known file *and* tampering
with the DNS sound like two very different abilities for an attacker.
A MITM can already easily block the initial DNS request for the TXT record
but once MTA-STS takes effect it can only block policy retrieval, not
change the policy itself (unless it can tamper with the HTTPS request in
which case there is a bigger problem). In fact, blocking policy retrieval
gets *easier* when the domain is prefixed with mta-sts, as it can simply
drop the DNS request itself. It would be a lot harder to block a HTTPS
request on the bare domain without blocking the website itself.
But maybe I've missed something - I'm not a security expert.

I also think it may be easier to set up MTA-STS on a host if the mta-sts
prefix is removed. It drops the requirement for a new subdomain and
certificate. This could help adoption of the standard.

-- Ayke

---

From: Binu Ramakrishnan <[email-masked]>
Date: Fri, 15 Sep 2017 20:14:40 +0000 (UTC)

One advantage of using a sub-domain is the ability to delegate STS policy serving (and mail hosting) to a 3rd party service provider.
Thanks,-binu

      From: Ayke van Laethem <[email-masked]>
 To: [email-masked] 
 Sent: Friday, 15 September 2017 1:02 PM
 Subject: [Uta] Rationale for mts-sts.<domain>
   
Hi,
I was wondering what the rationale is for adding the mts-sts prefix to the domain where the policy file is loaded? E.g. https://mts-sts.example.com/.w ell-known/mts-sts.txt
As a security feature, an attacker:- must be able to add a .well-known/mta-sts.txt file in a specific format (or maybe redirect). Adding a .well-known URL is supposed to be difficult.- must be able to spoof a special TXT record, either by controlling the network (MITM without DNSSEC) or controlling the DNS itself (e.g. cache poisoning)- must be able to add a subdomain (otherwise the prefix doesn't have a security advantage) and possibly issue a certificate for it
While there is certainly a security advantage with the third requirement, I wonder how big it is? Being able to add a .well-known file *and* tampering with the DNS sound like two very different abilities for an attacker.A MITM can already easily block the initial DNS request for the TXT record but once MTA-STS takes effect it can only block policy retrieval, not change the policy itself (unless it can tamper with the HTTPS request in which case there is a bigger problem). In fact, blocking policy retrieval gets *easier* when the domain is prefixed with mta-sts, as it can simply drop the DNS request itself. It would be a lot harder to block a HTTPS request on the bare domain without blocking the website itself.But maybe I've missed something - I'm not a security expert.
I also think it may be easier to set up MTA-STS on a host if the mta-sts prefix is removed. It drops the requirement for a new subdomain and certificate. This could help adoption of the standard.
-- Ayke_______________________________________________
Uta mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/uta

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 15 Sep 2017 20:46:13 +0000

On Fri, Sep 15, 2017 at 08:14:40PM +0000, Binu Ramakrishnan wrote:

> One advantage of using a sub-domain is the ability to delegate STS policy
> serving (and mail hosting) to a 3rd party service provider.

If support for 302 redirects is added, perhaps that case becomes
less compelling?  

Though the redirect to the provider would have to be done by whatever
serves "example.com", rather than "mta-sts.example.com", and it
may in some cases be more difficult to get the redirect to happen
there, so having a subdomain makes it a bit easier to do the job
with a CNAME, if the provider can obtain the requisite certificate.

-- 
	Viktor.

---

From: Jim Fenton <[email-masked]>
Date: Fri, 15 Sep 2017 14:00:38 -0700

> with a CNAME, if the provider can obtain the requisite certificate.
I see the advantage of including mta-sts as being that it doesn't
require access to the domain's main web server. In a large domain, it's
easier for the mail operations folks to operate a different web server,
and mta-sts could always be CNAMEd back to some other server (such as
the main one) if that isn't the case.

But this does make me think: what do other .well-known services do? Do
they run into this problem?

---

From: Ayke van Laethem <[email-masked]>
Date: Fri, 15 Sep 2017 23:45:38 +0200

Those are good points. On large domains it may be more difficult to serve a
policy file on the bare domain. I'm thinking about smaller domains serving
their own policy - but those are possibly less relevant for MTA-STS.

Ayke

On Sep 15, 2017 23:00, "Jim Fenton" <[email-masked]> wrote:

> _______________________________________________
> Uta mailing list
> [email-masked]

---

From: Daniel Margolis <[email-masked]>
Date: Sat, 16 Sep 2017 10:36:40 +0200

Jim and Viktor basically get it right, I think.

I don't believe this has any security value in warding off a DOS; anyone
who can inject a TXT record to a non-implementing domain can also inject
the A or CNAME for mta-sts.example.com.

What this does do which has real security value is allow you to make sure
the org that hosts the policy does not have access to a certificate for the
full domain. If mta-sts.example.com is hosted by (say) the mail team and
not the web team, or by some third party mail provider, you may not want
them to have a cert for .example.com.

(Conversely, however, you are not *required *to obtain a new certificate if
you have a wildcard cert for the full domain. So I don't think this imposes
a lot of difficulty here, and anyway, certificates can be had automagically
from LetsEncrypt or similar.)

Dan

On Fri, Sep 15, 2017 at 11:45 PM, Ayke van Laethem <[email-masked]
> wrote:

> Those are good points. On large domains it may be more difficult to serve
> a policy file on the bare domain. I'm thinking about smaller domains
> serving their own policy - but those are possibly less relevant for MTA-STS.
>
> Ayke
>

---

From: Ayke van Laethem <[email-masked]>
Date: Tue, 19 Sep 2017 20:21:12 +0200

That's are also a good reason to keep them separate, though in the case of
a third party policy provider a redirect could also be good enough.

Thank you all for the answers.

Ayke

On Sep 16, 2017 10:36, "Daniel Margolis" <[email-masked]> wrote:

Dan