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*." 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 > >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
