I have some feedback and questions about MTA-STS revision 10. - The specification introduces its own hostname matching algorithm that allows common names. CNs are deprecated by Baseline Requirements; browsers ignore them in presence of the SAN extension. However, the MTA-STS seems to allow a match in CN _or_ SAN. This is inconsistent with how PKI is used elsewhere; is there are good reason for it?
Also do note that RFC 6125, referenced by MTA-STS, states that CNs must be ignored when a SAN is present. I think dropping CNs altogether would bring this RFC in line with how PKI is used elsewhere and reduce complexities and opportunities for security issues without losing any functionality. - 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. Is there are reason not to implement the more straightforward approach: 1. Attempt delivery only to MX servers listed in the policy (here you can use some pattern matching that's necessary to support wildcards). 2. When actually connecting to an MX server, validate the certificate as any other TLS client would (i.e., that it matches the hostname to which you're connecting). The advantage of this approach is that this is what TLS client libraries already implement. I am afraid that this custom approach is dangerous and might contain hidden problems, but also that increases the amount of potentially tricky code that needs to be written. - As a final small point, in at least one place the spec gives a very vague explanation of how certificates are verified: "The certificate presented by the receiving MX MUST chain to a root CA that is trusted by the sending MTA and be non-expired." I am afraid that this incomplete guidance might give some people idea that it's not necessary to perform any other checks (such as KU/EKU, pathlen, name constraints, check that the signature algorithms are acceptable, and so on). I suppose all my three comments can be rolled up into one: implement certificate checking in MTA-STS as it's practiced elsewhere. It would make the spec simpler, easier to understand, and more robust. -- Ivan
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
