Subject: [Uta] 302 redirects (was "MTA-STS and HTTP cache control")

From: Daniel Margolis <[email-masked]>
Date: Sun, 20 Aug 2017 19:24:23 +0200

So, the *motivation* for this was simplification: if you allow 302s, you
have to specify a bit more clearly what the behavior is for things like a
302 to a HTTP URI, max redirect depth, etc.

In truth, though, I've never been super happy with the prohibition on 302s,
since it seems to make policy delegation (i.e. "My MX points to Microsoft;
use their policy as well") easier than having your mail provider also host
a policy for you using SNI. I could personally be convinced that we
*should* allow
302s. I seem to recall Binu felt more strongly in the converse, though, so
I will let him chime in and maybe correct me. ;)

On Sun, Aug 20, 2017 at 7:17 PM, Viktor Dukhovni <[email-masked]>
wrote:

>
> > On Aug 20, 2017, at 1:08 PM, Daniel Margolis <[email-masked]>
> wrote:
> >
> > Policies fetched via HTTPS are only valid if the HTTP response code is
> 200 (OK).
> > HTTP 3xx redirects MUST NOT be followed, and HTTP caching (as specified
> in
> > RFC7234) MUST NOT be used.
>
> I forget, is non-support of redirects intended to simplify the policy
> retrieval
> code at the sending MTA , or is it a security concern?  I am all for making
> the service accessible to bare-bones HTTPS implementations, and so am not
> asking
> for redirect support, just wanted to check the motivation...  Perhaps the
> rationale
> should be stated in the draft?
>
> --
>         Viktor.
>
> _______________________________________________
> Uta mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uta
>

---

From: Binu Ramakrishnan <[email-masked]>
Date: Mon, 21 Aug 2017 18:42:16 +0000 (UTC)

My understanding is the primary purpose of a 3xx redirect is policy delegation. For example my MX points to Microsoft, so use their policy. This is certainly useful, however in my opinion it is less compelling use case because of the following observation:

In case of 3rd party provider model, the provider is required to host an HTTPS endpoint for every hosted domain, whether for doing a 3xx redirect or serving a policy. Since we need HTTPS endpoint for every domain, why not serve the policy itself? If the argument is to have one policy file shared by all domains, then as a provider, you may serve a shared file or reverse proxy the policy file from the right server.
>From a security angle, by not supporting 3xx redirect, I think we simplified the policy retrieval and have one less thing to worry about (in spec and implementation).
Thanks,-binu
      From: Daniel Margolis <[email-masked]>
 To: [email-masked]; Binu Ramakrishnan <[email-masked]> 
 Sent: Sunday, 20 August 2017 10:24 AM
 Subject: 302 redirects (was "MTA-STS and HTTP cache control")
   
So, the motivation for this was simplification: if you allow 302s, you have to specify a bit more clearly what the behavior is for things like a 302 to a HTTP URI, max redirect depth, etc. 
In truth, though, I've never been super happy with the prohibition on 302s, since it seems to make policy delegation (i.e. "My MX points to Microsoft; use their policy as well") easier than having your mail provider also host a policy for you using SNI. I could personally be convinced that we should allow 302s. I seem to recall Binu felt more strongly in the converse, though, so I will let him chime in and maybe correct me. ;)
On Sun, Aug 20, 2017 at 7:17 PM, Viktor Dukhovni <[email-masked]> wrote:

> On Aug 20, 2017, at 1:08 PM, Daniel Margolis <[email-masked]> wrote:
>
> Policies fetched via HTTPS are only valid if the HTTP response code is 200 (OK).
> HTTP 3xx redirects MUST NOT be followed, and HTTP caching (as specified in

I forget, is non-support of redirects intended to simplify the policy retrieval
code at the sending MTA , or is it a security concern?  I am all for making
the service accessible to bare-bones HTTPS implementations, and so am not asking
for redirect support, just wanted to check the motivation...  Perhaps the rationale
should be stated in the draft?

--
        Viktor.

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

---

From: Daniel Margolis <[email-masked]>
Date: Mon, 21 Aug 2017 21:47:41 +0200

My point was that if you host on Microsoft, you could have

https://policy.example.com <-- cert for example.com, 302s to
policy.microsoft.com
https://policy.microsoft.com <-- cert for microsoft.com

This way you don't have to give Microsoft your cert and they don't have to
set up SNI--but conversely, you have to set up your own 302 redirector.
Some users may prefer this to SNI, but I don't know if it's worth the
complexity it introduces.

I do agree this brings nice simplicity.

*shrug*

I'm open to feedback on this. I never felt strongly about either direction.

Dan

On Mon, Aug 21, 2017 at 8:42 PM, Binu Ramakrishnan <[email-masked]> wrote:

> My understanding is the primary purpose of a 3xx redirect is policy
> delegation. For example my MX points to Microsoft, so use their policy.
> This is certainly useful, however in my opinion it is less compelling use
> case because of the following observation:
>
> In case of 3rd party provider model, the provider is required to host an
> HTTPS endpoint for every hosted domain, whether for doing a 3xx redirect or
> serving a policy. Since we need HTTPS endpoint for every domain, why not
> serve the policy itself? If the argument is to have one policy file shared
> by all domains, then as a provider, you may serve a shared file or reverse
> proxy the policy file from the right server.
>
> From a security angle, by not supporting 3xx redirect, I think we
> simplified the policy retrieval and have one less thing to worry about (in
> spec and implementation).
>
> Thanks,
> -binu
>
> ------------------------------
> *From:* Daniel Margolis <[email-masked]>
> *To:* [email-masked]; Binu Ramakrishnan <[email-masked]>
> *Sent:* Sunday, 20 August 2017 10:24 AM
> *Subject:* 302 redirects (was "MTA-STS and HTTP cache control")
>
> In truth, though, I've never been super happy with the prohibition on
> 302s, since it seems to make policy delegation (i.e. "My MX points to
> Microsoft; use their policy as well") easier than having your mail provider
> also host a policy for you using SNI. I could personally be convinced that
> we *should* allow 302s. I seem to recall Binu felt more strongly in the
> converse, though, so I will let him chime in and maybe correct me. ;)
>
> <https://www.ietf.org/mailman/listinfo/uta>
>
>
>
>
>