On Tuesday, 18 July 2017 07:45:01 UTC+1, Jakob Bohm wrote: > 1. I believe (though others may know better) that the high general > requirements for the security of CA systems also apply to the > systems performing the validation procedures in question.
Yes, however I don't think Matthew's concern was about systems owned by the CA but rather systems proximate to them in the network. For example if the CA purchases Internet service from a single local Internet Service Provider, the BRs obviously don't require that this ISP have all the security procedures in place of a CA. That ISP would be able to act as a MitM for the entire rest of the Internet, and isn't subject to the BRs so that this might happen at the whim of a 17-year old unpaid intern let loose with the routing tables. > 2. For all DV (Domain Validated) certificate validation methods, it is > basically accepted that if an attacker can hijack access to a domain > for the duration of the validation, then that attacker can fool even > the most secure CA into giving the attacker a DV certificate. > This is because the problem is fundamentally unsolvable. Only some of the 10 Blessed Methods involve the actual network. Domain Authorization Documents would get the job done and needn't travel over the network. If your main threat is from network-based adversaries, such documents are an admirable choice to prevent that. [Aside: Did the CA/B really still not manage to pass a resolution fixing the list of Blessed Methods all these months later? I guess Mozilla's intervention here was more necessary than I'd appreciated] Where a domain has enabled DNSSEC, it is possible for the CA to rely upon DNSSEC to prevent tampering with records for that domain. So that secures DNS-based validations. We can argue about whether the DNSSEC cryptography would withstand attack by a resourceful adversary, but it certainly raises the bar very considerably compared to just fiddling with a routing table. Unlike a typical end user, the CA is certainly in a position to implement DNSSEC validation in its DNS resolver correctly and to reject attempts to validate control which run into problems with DNS server correctness. I know that Let's Encrypt does this, and judging from their user forums a small but noticeable fraction of applicants run into problems because their DNS server is crap and replies SERVFAIL (or times out) for legal DNS queries. There is doubtless a strong temptation for commercial reasons for a CA to ignore such problems and press on with the compromised validation, but the BRs don't require that, and it would not be unreasonable to "level the playing field" by updating them, or Mozilla's programme requirements, to demand the CA reject validation when an applicant's DNS servers won't answer correctly. > 3. The location from which to fetch the confirmation file for HTTP based > validation is generally dictated by the CA, not the applicant. The Blessed Methods specifically call out a sub-path of the IETF's reserved /.well-known/ URLs for this purpose. ACME has its own path, which being IETF-standardized will be suitable as well (the Blessed Methods say you can use a different path if it's on IANA's list and IETF standardization includes adding things to IANA's list as an automatic step), but unless somebody else in the industry has an IETF standards track protocol under the radar those are the only two valid choices under the Blessed Methods. There definitely are lots of non-Blessed Methods approaches deployed when I last looked (and so perhaps still today) which use other paths, but you're correct that they're usually chosen by the CA. This is always going to be more dangerous than letting the IETF control it, so the Blessed Methods are making a good change here. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
