---------- Forwarded message ---------- From: Binu Ramakrishnan <[email protected]> Date: Fri, Sep 29, 2017 at 9:52 AM Subject: Re: [Uta] Updated MTA-STS & TLSRPT To: Daniel Margolis <[email protected]> Cc: Leif Johansson <[email protected]>, [email protected], Nicolas Lidzborski␄ <[email protected]>
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 protected]> 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 protected]> wrote: On 2017-09-28 23:02, Viktor Dukhovni wrote: > >> On Sep 28, 2017, at 4:42 PM, Brotman, Alexander >> <[email protected]> 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 protected] https://www.ietf.org/mailman/listinfo/uta
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
