On Tue, Oct 31, 2017, at 06:29 PM, Chris Newman wrote: > On 30 Oct 2017, at 19:30, Keith Moore wrote: > > After a bit more thought on this, I've concluded that using the mail > > server's server certificates to verify authenticity of SRV records > > probably isn't a good idea - or at least there are more considerations > > and pitfalls than can reasonably be thought through in the context of > > this document. > > I think what RFC 7817 says about certificate validation is fine, so I > don't want to repeat or contradict what it says. > > > One consideration is that TLS "reverse proxies" can (and likely > > do/will) use SNI to dispatch to different hosts on the back end, as > > one way to implement "virtual hosting" of mail services. > > I don't know if this is done for mail, but SNI routing appears to be in > use: > http://proxy.dockerflow.com/sni-routing/ > > Luckily domain names are cheap, so example.com SRV can point to an > example.com.mailhosting.example.net domain name or something like that > so there's no ambiguity and RFC 7817 cert validation will work fine on > that domain name. > > > Also, of course, being able to authenticate to two different servers > > (even if both present valid certificates for their respective domain > > names) is not the same thing as those two servers being the same. > > It's becoming less likely over time that two connections to a particular > domain name will be handled by the same physical hardware. Luckily > certificates don't restrict this. > > > So now I'm inclined to add a simple sentence or two along the lines of > > Chris's suggestion. I think that's the best we can do in a short > > time without additional review cycles. > > Agreed.
I agree as well. _______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
