Subject: Re: [Uta] RFC 8461 on SMTP MTA Strict Transport Security (MTA-STS)

From: Daniel Margolis <[email-masked]>
Date: Mon, 1 Oct 2018 11:22:15 +0200

+1 to everything Hanno says. Yes, you _have_ to do this or else the whole
trust relationship cannot be established. But Let's Encrypt and similar
providers actually make this very easy.

As an example, I wrote the following script for my personal domain:
https://github.com/danmarg/sts-mate.

It does two things:

1. Uses Let's Encrypt to get a cert for the required domain.
2. Optionally, reverse-proxies a policy from a trusted location.

The result of these two functions actually makes it trivial for a hosting
provider to setup new clients:

1. Serve the provider's policy on mta-sts.provider.example.
2. Provide a proxy for customers at mta-sts-proxy.provider.example running
"sts-mate --mirror_sts_from provider.example --my_real_host
mta-sts-proxy.provider.example"
3. Tell customers (or configure their DNS) to create the following two
CNAMEs: _mta-sts.user.example --> _mta-sts.provider.example, and
mta-sts.user.example --> mta-sts-proxy.provider.example

(Note that in step 2, instead of proxying from the policy hosted somewhere
else, one could serve the policy directly from "sts-mate" (or a similar
HTTPS server).)

Importantly, *step 3 is the only thing you have to do for each new customer*.
As a result, setting up a new customer is as easy as setting up two CNAMEs.

As a hopefully obvious aside, this code is totally untested and I make no
assertions about whether this actual implementation is a good one, but
hopefully it provides a handy proof of concept.

Dan

On Sun, Sep 30, 2018 at 8:56 AM Hanno Böck <[email-masked]> wrote:

> On Sat, 29 Sep 2018 20:13:20 +0200
> "A. Schulze" <[email-masked]> wrote:
>
> > I consider implementing MTA-STS on our platform hosting thousand+
> > Domains. Now I just found the following text:
> >
> >    Note that in all such cases, the policy endpoint
> >    ("https://mta-sts.user.example/.well-known/mta-sts.txt" in this
> >    example) must still present a certificate valid for the Policy Host
> >    ("mta-sts.user.example"), and not for that host at the provider's
> >    domain ("mta-sts.provider.example").
> >
> > Does that really mean I have to setup thousand+ virtual hosts
> > https://mta-sts.domain1...1000.example? Or are there other strategies
> > for hosting provider?
>
> This seems to be the one thing that is confusing a lot of people about
> MTA-STS. The answer is yes you have to, no, there are no other
> strategies.
>
> The policy host is the thing that ties your domain name's identity to
> your policy. This makes sure you can only serve a policy for
> user.example if you control and have a certificate for user.example.
> If you could serve a policy for user.example on provider.example you'd
> not have that connection.
>
> There is of course a good solution for this: Automate your virtual host
> and certificate creation.
>
> --
> Hanno Böck
> https://hboeck.de/
>
> mail/jabber: [email-masked]
> GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
>
> _______________________________________________
> Uta mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uta
>

-- 
How's my emailing? http://go/dan-email-slo