On Thu, Oct 12, 2017 at 12:21 PM, Daniel Margolis <[email protected]> wrote:
> The MX-selection-vs-validation discussion (and change; note that in draft > 03 and prior it worked the way you suggest) was in this thread: > https://www.ietf.org/mail-archive/web/uta/current/msg01914.html. > > I agree that the modifying-MX-selection-loop is mostly a red herring, > since you can do as you suggest and simply choose the host in question as > though you would connect to it and then treat the bad hostname (regardless > of the certificate) as an authentication failure; in effect, you need not > modify MX selection at all. I noted as much here: https://www.ietf.org/ > mail-archive/web/uta/current/msg01950.html. > > I believe Viktor's point (which he repeated here: https://www.ietf.org/ > mail-archive/web/uta/current/msg01921.html) is that it's common practice > to have MX hosts whose certificates do not match the hostname *at all*. > This is the primary argument for having a policy that constraints > certificate identities rather than hostnames. We also discussed the > relative cost of custom matching in that thread. Empirically, per > http://conferences.sigcomm.org/imc/2015/papers/p27.pdf, "However, only > 0.6% of domains present trusted certificates that match their domain name, > while *34.2% present trusted certificates that match their MX server*." > Personally, I think SMTP server certificates should match only their own names. If virtual SMTP hosting is desired, it can be done either with one certificate and multiple hostnames, or via SNI and individual certificates. In practice, probably a combination of both. For example, one certificate could be shared among several hostnames that belong to the same organisation. People are not just going to enable MTA-STS with their existing certificates. They're going to read someone's deployment guide, maybe glance at the RFC, go through the motions, check with a testing tool (I plan to write one), and deploy. The simplest deployment use-case (e.g., one that I expect to be using for my business) is that I use MTA-STS to "approve" the use of third-party MX servers for my email. The third party only needs to ensure they have valid certificates for their own hostnames, nothing else. In this case, virtual hosting would be just extreme vanity, because who looks at MX servers' names? :) I understand that there is a lot of mess out there, but a new RFC is a perfect (and practically only) opportunity to improve things, and that's what I am arguing for. On Thu, Oct 12, 2017 at 10:39 AM, Ivan Ristic <[email protected]> wrote: > >> On Tue, Oct 10, 2017 at 11:42 PM, Viktor Dukhovni <[email protected] >> > wrote: >> >>> ... >>> > - The other thing I found unusual is that (unless I am reading it >>> > incorrectly), certificate validation is done in a kind-of round-about >>> way: >>> > when connecting to an MX server, the certificate is considered valid >>> if it >>> > matches any MX pattern from the policy. This is very unusual and >>> requires a >>> > custom hostname matching algorithm. >>> >>> See the list archives, this is deliberate. The idea is to not >>> override MX selection, and to support sites with UCC certifcates >>> where the identity is the receiving domain name and not the MX >>> host. >>> >> >> Well, you don't have to override the MX selection. Select whichever MX >> you want and then, just prior to connecting to it over TLS, verify that the >> hostname matches one of the patterns provided. Treat it as authentication >> failure if it doesn't. I think this is simpler, faster in case of failure, >> and also allows you to use standard TLS hostname verification. >> >> There's nothing in this approach that would prevent you from using >> UCC/SAN certificates or SNI. >> >> Is there a specific scenario that would work with the current wording and >> not with my more-standard approach? >> >> -- >> Ivan >> >> _______________________________________________ >> Uta mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/uta >> >> > -- Ivan
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
