Subject: Re: [Uta] Updated MTA-STS & TLSRPT

From: Binu Ramakrishnan <[email-masked]>
Date: Fri, 29 Sep 2017 20:59:58 +0000 (UTC)

---------- Forwarded message ----------
From: Binu Ramakrishnan <[email-masked]>
Date: Fri, Sep 29, 2017 at 9:52 AM
Subject: Re: [Uta] Updated MTA-STS & TLSRPT
To: Daniel Margolis <[email-masked]>
Cc: Leif Johansson <[email-masked]>, [email-masked], Nicolas Lidzborski␄ <[email-masked]>

IMO, whether to support 30x redirects or just depend on reverse-proxy mechanism is a question of preference. Though both can satisfy policy delegation, I would prefer the later because, as a MTA-STS implementor, I do not need write additional code (and related tests) to support 30x redirects. Like Leif mentioned, all modern general purpose web servers are equally good with both redirects and reverse-proxy.
Thanks,-binu
On Fri, Sep 29, 2017 at 6:20 AM, Daniel Margolis <[email-masked]> wrote:

I actually wrote up a commit with 302 support: https://github.com/mrisher/smtp-sts/commit/c41f24d8500f058073b5b78ac18e177f738146a5. However, I didn't merge it in, since there was no clear consensus on the WG or among the authors.
The argument for 302s is for added flexibility of hosting, of course, especially on delegated policies. An example usage would be to allow people like me, who have a personal domain with just an MX that points to Google, to use a minimal HTTPS host (e.g. from their registrar) to point a 302 for the policy host to Google's policy.
The argument against 302s is merely whether the extra complexity for MTA implementors (to ensure proper validation of identities while traversing redirects, as I wrote* in the commit linked below) is risky or can be gotten wrong, or whether there are additional issues around difficulty figuring out (e.g.) which certificate is not trusted by a sender if there is some policy fetch failure.
I don't think redirects are either critical or fatal, so I would first and foremost like to see the WG reach a consensus (quickly!) on whether to support them or not. 
 Leif, do you think it's reasonable to have a simple up-or-down vote on the 10 draft vs the additional text linked above, with a conclusion by (say) end of next week?
Dan

* "Note that when following an HTTP 30x redirect, the aforementioned certificate authentication MUST nonetheless be applied to the initial HTTPS response that serves the 30x code; subsequent redirect URIs MUST also be HTTPS with a server certificate that is trusted by the sending MTA, non-expired, and valid for the host identity, though this identity may differ from that the initial `mta-sts` host. (Thus, for example, `https://mta-sts.user.com` may redirect requests to `https://mta-sts.provider.com`, but the `provider.com` endpoint must also be authenticated."

On Fri, Sep 29, 2017 at 8:28 AM, Leif Johansson <[email-masked]> wrote:

On 2017-09-28 23:02, Viktor Dukhovni wrote:
>
>> On Sep 28, 2017, at 4:42 PM, Brotman, Alexander <[email-masked]> wrote:
>>
>> Please let us know if you have any comments or questions, and thank you for your time.
>
> I see that 302 HTTP redirects are still not supported, and that policy
> delegation without SNI is via reverse proxying, rather than 302
> redirects.  I may have missed the discussion that arrived at this
> decision.  Is this the "rough consensus" view?
>

May I suggest that if you would like to see redirects supported in
addition to instead of reverse proxy then provide text so we have
something concrete to discuss ?

> I would expected it to be easier to serve 302 redirects than deploy
> a reverse proxy, but perhaps I am mistaken, and HTTPs servers come with
> reverse-proxy support as a common built-in feature?

Speaking as an individual I'd say that modern general purpose webservers
do both equally well and just as easily. There may still be deployment
issues making one or the other preferable in any one situation though...

        Cheers Leif

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

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 29 Sep 2017 21:17:57 +0000

On Fri, Sep 29, 2017 at 08:59:58PM +0000, Binu Ramakrishnan wrote:

> IMO, whether to support 30x redirects or just depend on reverse-proxy
> mechanism is a question of preference. Though both can satisfy policy
> delegation, I would prefer the later because, as a MTA-STS implementor,
> I do not need write additional code (and related tests) to support 30x
> redirects. Like Leif mentioned, all modern general purpose web servers
> are equally good with both redirects and reverse-proxy.

In that case, reverse-proxy it is, but users will likely seek to
configure some sort of caching in the reverse proxy, and the document
should perhaps provide some guidance about that (and of course
stress that the reverse proxy needs to validate the upstream
certificate, if that language is not there already).

-- 
	Viktor.

---

From: Binu Ramakrishnan <[email-masked]>
Date: Sat, 30 Sep 2017 01:39:56 +0000 (UTC)

Hi Victor,
Thank you for the feedback. We will update the document and provide some guidance on reverse-proxy operations.
-binu

      From: Viktor Dukhovni <[email-masked]>
 To: [email-masked] 
 Sent: Friday, 29 September 2017 2:18 PM
 Subject: Re: [Uta] Updated MTA-STS & TLSRPT

-- 
    Viktor.

---

From: Daniel Margolis <[email-masked]>
Date: Sat, 30 Sep 2017 11:15:45 +0200

Sounds fair. Right now there's no specific operational guidance about that,
but I think it makes sense to add to section 6.2. I can easily work
something in there.

Current text:

This can be done either by setting the
> "mta-sts" record to a host or CNAME specified by the hosting
> organization and by giving the hosting organization a TLS certificate
> which is valid for that host, or by setting up a "reverse proxy"
> (also known as a "gateway") server that serves as the Policy Domain's
> policy the policy currently served by the hosting organization.

Regarding authenticating the proxied host, I would just add:

In the case of a reverse proxy configuration, implementors should be
> careful to ensure that the proxy requires a TLS connection to the proxied
> host, and that the host server's identity is authenticated to prevent
> proxying a spoofed policy.

Regarding caching, Viktor, Binu, do you believe this is useful to allow?
While it can be done safely (by simply ensuring the cache-control headers
set by the mta-sts.provider.com host--i.e. the one behind the proxy--are
"correct"), it doesn't strike me as necessary; perhaps it's simpler and
safer to simply recommend against HTTP caching. The expected request rate
is low, and I would assume any provider behind the proxy can handle more
traffic than the proxy itself, so caching isn't quite as compelling, no?