The trouble is that the BRs for those methods are really really vague. I don't know that one can make a stronger case for misissuance versus properly issued in these cases.
I'm certainly no fan of the mechanism in TLS-SNI-01 and regard it deficient in the face of real world deployment circumstances. Clearly Let's Encrypt does too, for why else would they have disabled the mechanism? If we assume a world with more complex infrastructure, the case can be made that they're not attaching to the authorization domain name, because they failed to submit that name via SNI to the endpoint to which they are attached, which may cause the validation to be routed incorrectly within certain more complex hosting architectures. On the other hand, they did access the right IP address via DNS lookup to the correct target authorization domain name, meaning they're talking to the right endpoint at the IP layer. Nothing in the BRs makes clear what would be a correct interpretation. It's hard to imagine that one could not defend that "on the Authorization Domain Name" via TLS over an Authorized Port means no more than at an IP address discovered as an A or AAAA record after having dereferenced the authorization domain name as necessary via typical DNS resolution rules (allowing for CNAME, etc.) on port 443. Nowhere within the BRs is it formally specified that the TLS session over which this validation is taking place need to even implement SNI (an optional feature) much less that there should be regard for the value. Having said all that, and having read the very limited specifications of the 10 blessed methods, I have, as an outsider looking in, arrived at the conclusion that each and every of these methods is ridiculously underspecified. I'm convinced that each of the 10 should be scrutinized thoroughly before being discarded or in the alternative formally specified in egregious detail, such that questions such as this one may not be raised. On Thu, Jan 18, 2018 at 3:46 PM, Doug Beattie via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > The point is, you don’t really connect to the Certificate on the > Authorization Domain Name, you connect to a certificate on the same IP > address as the ADN, but you actually intentionally ask for a different > server name, which has no relationship to the ADN (except they happen to > share the same IP address). It seems like misissuance to me. > > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
