Good point. So, the TXT record could be moved to support this case, but I'm not sure any of this is worth it. To recap, you have a few delegation models:
1. HTTPS: Currently only by giving a cert to your provider and having them use SNI; hypothetically possible by 302s. 2. TXT: Currently not possible; hypothetically possible by zone delegation. On the other hand, I don't expect policies to change any more frequently than MX records themselves, which is why it never seemed critical to me to support delegation. Thoughts? On Sun, Sep 3, 2017 at 3:21 PM, David Illsley <[email protected]> wrote: > 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 >> >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
