Quick conversation with some DNS folks, and they say that we can publish a TXT record at the apex of a delegated sub-domain. CNAMEs would not be allowed, but A/TXT should be okay.
-- Alex Brotman Sr. Engineer, Anti-Abuse Comcast From: Uta [mailto:[email protected]] On Behalf Of Daniel Margolis Sent: Tuesday, September 05, 2017 9:28 AM To: David Illsley <[email protected]> Cc: [email protected]; Binu Ramakrishnan <[email protected]> Subject: Re: [Uta] 302 redirects (was "MTA-STS and HTTP cache control") 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]<mailto:[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]<mailto:[email protected]>> wrote: My point was that if you host on Microsoft, you could have https://policy.example.com <-- cert for example.com<http://example.com>, 302s to policy.microsoft.com<http://policy.microsoft.com> https://policy.microsoft.com <-- cert for microsoft.com<http://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]<mailto:[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]<mailto:[email protected]>> To: [email protected]<mailto:[email protected]>; Binu Ramakrishnan <[email protected]<mailto:[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]<mailto:[email protected]>> wrote: > On Aug 20, 2017, at 1:08 PM, Daniel Margolis > <[email protected]<mailto:[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]<mailto:[email protected]> https://www.ietf.org/mailman/ listinfo/uta<https://www.ietf.org/mailman/listinfo/uta> _______________________________________________ Uta mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/uta
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
