Unfortunately, given the dispersed nature of where you have to put config, I’m not sure there’s an easy delegation model. Even if you go to the effort of adding a host with a redirect, you still need to update the policy id in DNS whenever the policy changes. Similarly, you can’t simply delegate the mta-sts zone as the policy indicator TXT record doesn’t sit in it.
On Mon, 21 Aug 2017 at 20:47, Daniel Margolis <[email protected]> wrote: > 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 protected]> > 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 protected]> >> *To:* [email protected]; Binu Ramakrishnan <[email protected]> >> *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 protected]> >> wrote: >> >> >> > On Aug 20, 2017, at 1:08 PM, Daniel Margolis <[email protected]> >> 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 protected] >> https://www.ietf.org/mailman/ listinfo/uta >> <https://www.ietf.org/mailman/listinfo/uta> >> >> >> >> >> > _______________________________________________ > Uta mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/uta >
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
