On Thursday, July 20, 2017 at 9:39:40 AM UTC-5, Gervase Markham wrote: > Your point, in the abstract, is a reasonable one, but so is your further > point about trade-offs. The only way we can really make progress is for > you to propose specific changes to the language, and we can then discuss > the trade-offs of each.
I would be willing to take a stab at this if the subject matter is of interest and would be willing to commit some time to work on it providing that it would appear a convenient time to discuss and contemplate the matter. Can anyone give me a sense of whether the matter of the potential vulnerabilities that I see here -- and of the potential mitigations I might suggest -- are of interest to the community? > Certainly for CAA, we don't allow broken DNSSEC to fail open. I hope > that will be true of DNS-based validation methods - either after 190 > passes, or soon after that. A requirement that if the zone is configured for DNSSEC that any domain validation technology that relies in any part upon DNS lookups (i.e. direct DNS validations as well as HTTP validations) must succeed only if DNSSEC validation of the lookups succeeds would strengthen the requirements with very little cost or negative consequence. This would, of course, only improve the security posture of domain validations for those domains configured for DNSSEC, but that is still a significant benefit. Much like CAA, it gives those holding and/or managing high value domains significant power to restrict domain hijacking for purposes of acquiring certificates. Quite separately, it appears that 3.2.2.8's "As part of the issuance process..." text would strongly suggest that CAA record checking be performed upon each instance of certificate issuance. I presume that applies even in the face of a CA which might be relying upon previous DNS / HTTP domain validation. I grant that the text goes on to say that issuance must occur within the greater of 8 hours or the CAA TTL, but it does appear that the intent is that CAA records be queried for each instance of issuance and for each SAN dnsName. If this is the intent and ultimately the practice and we are already requiring blocking reliance on DNS query within the process of certificate issuance, should the validity of domain validation itself be similarly curtailed? My argument is that if we are placing a blocking reliance upon both the CA's DNS validation infrastructure AS WELL AS the target domain's authoritative DNS infrastructure during the course of the certificate issuance process , then there is precious little extra point of failure in just requiring that domain validation occur with similarly reduced validity period. > > I believe there would be a massive improvement in the security of DNS query > > and HTTP client fetch type validations if the CA were required to execute > > multiple queries (ideally at least 3 or 4), sourced from different physical > > locations (said locations having substantial network and geographic > > distance between them) and each location utilizing significantly different > > internet interconnection providers. > > How could such a requirement be concretely specced in an auditable way? I can certainly propose a series of concrete specifications / requirements as to a more resilient validation infrastructure. I can further propose a list of procedures for validating point-in-time compliance of each of the requirements in the aforementioned list. Further, I can propose a list of data points / measurements / audit data that might be recorded as part of the validation record data set by the CA at the time of validation which could be used to provide strong support that the specifications / requirements are being followed through the course of operations. If those were written up and presented does that begin to address your question? Thanks, Matt Hardeman _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
