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
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to