On Tuesday, September 19, 2017 at 8:02:36 AM UTC-5, Gervase Markham wrote: > I'd be interested in your engagement on my brief threat modelling; it > seems to me that DNSSEC only adds value in the scenario where an > attacker has some control of CA Foo's issuance process, but not enough > to override the CAA check internally, but it also has enough control of > the network (either at the target, or at the CA) to spoof DNS responses > to defeat CAA. That seems on the surface like a rare scenario.
The situation involves somewhat more / different risks than you've described. A (properly positioned -- as further described below) prospective attacker need only be aware of any particular CA which might issue a domain validation certificate upon his/her request, said CA having been chosen because of support of an automated domain validation mechanism which relies exclusively upon DNS queries and which fails to enforce the full integrity of DNSSEC validation despite the target FQDN having been configured for DNSSEC. In fairness, the risk that I outline below is principally a risk that has not been previously mitigated in the general issuance of DV certificates historically. As such, the risk illuminated here might best be described as a "reduction in functional security value and/or reduction in potential functional security value derived from CAA checking". What I mean to illustrate is that for the first time, CAA checking in combination with strict enforcement of DNSSEC validation -- including strict enforcement of securely discovering whether or not a particular zone should be DNSSEC signed -- offers the opportunity to introduce a strong cryptographic assurance that a Domain Validated certificate issued for a properly DNSSEC signed and CAA implementing domain was, in fact, validated without data tampering from the proper name servers regardless of any IP address hijack or well positioned man-in-the-middle between the CA's validation infrastructure and the certificate requestor. Some significant academic work has recently been performed in the area of the danger of specific BGP hijacks of IP space for purposes of improperly acquiring DV certificates for chosen target domains. See, for example: https://www.princeton.edu/~pmittal/publications/bgp-tls-hotpets17 Additionally, on the basis of this and other work, significant advancement toward certain field mitigations of these threats is beginning to advance. See: https://community.letsencrypt.org/t/validating-challenges-from-multiple-network-vantage-points/40955 These field mitigations, such as redundant checks of the domain validation from multiple geo-distinct network vantage points certainly reduce the risk, particularly they reduce the risk of super-quiet narrowly scoped, geographically specific network space hijacks which might go largely unnoticed. Those techniques will be significantly more limited and thus significantly less effective as pertains quite brief (seconds to minutes) but global, far less subtle IP space hijacks. Risk illustration by positing a hypothetical scenario in which: My evil reverse twin (see various strange ramblings of Chuck Tingle for reference) seeks to improperly acquire a certificate for ipifony.net and/or subdomains thereof. Said evil party is aware that ipifony.net is DNSSEC signed but knows of a CA that: doesn't DNSSEC validate and that connects to the broader internet via one or more upstreams that he can influence to believe that his systems are the paths to the IP space of the zone's authoritative DNS servers, even if only briefly. In less than a minute total, the certificate can be had. A party well positioned and skilled in the art (the well positioned part, at least, is probably far less expensive than many would suspect) advertises the two /24s which contain the ipifony.net authoritative DNS servers. Just needs to be an entity well peered at one of the nation's several significant IXP hosting carrier hotels. Again, costs less than one would imagine. Request for automated fulfillment of DV cert is submitted. CA performs DNS queries, speaking with fake / substitute DNS servers. Confirms lack of CAA and proper TXT or CNAM records to authenticate DV issuance. CA issues certificate. Hijack advertisement withdrawn. Alternatively, if issuance could happen only after CAA checking with DNSSEC validation enforced, this IP space hijack will have been thwarted (assuming I have managed my domain configuration at the registrar securely and that I have maintained proper custody and control over my DNSSEC signing keys). With DNSSEC validation on, there is no way to successfully persuade the CA that the CAA record does not exist by way of a fraudulent authoritative DNS server. More significantly, ongoing enhancement of work in the CAA sphere will allow for CAs to get even more selective about issuance rules specified in CAA records. Let's Encrypt, for example, is currently contemplating a pull request for an enhancement to their handling of CAA records to allow the CAA records to further specify which of Let's Encrypt's challenge methods are acceptable for the domain holder, pursuant to the CAA records. (In other words, I can use CAA to indicate that only Let's Encrypt may issue AND FURTHERMORE that only the DNS-01 challenge is acceptable.) See: https://github.com/letsencrypt/boulder/pull/3003 The actual risk, then, is that the implementation of CAA checking WITHOUT DNSSEC validation enforcement for those sites for which DNSSEC has been enabled (and the right way to check is to get secure proof that the zone does not implement DNSSEC before deciding DNSSEC is not needed for a given FQDN) yield a much diminished value of the CAA mechanism, as it misses the opportunity for a cryptographically secure mechanism by which a domain holder can prevent issuance even in the face of a BGP IP space hijack of the authoritative DNS servers. While I will concede that BGP hijacks of IP space for the purpose of fraudulent acquisition of DV certificates has to be a pretty rare case today, I assert that it is far easier to achieve than one might believe. Unfortunately, demonstrating how easily not just one who is well positioned to achieve this today can do so, but rather setting forth a template whereby one with modest means (corporately speaking) and starting from 0 technologically could do so is unfortunately too dangerous to ethically recommend. Nevertheless, it is the case that such a scenario could be undertaken pretty easily. I encourage those who doubt the same to reach out to a network engineer with significant IXP peering experience from among their own trusted professional associates for further discussion on the feasibility of these kinds of attacks. In summary, my brief threat model in response is: DNSSEC validation adds value in such scenarios as involve the existence of any publicly trusted CA known by said attacker to conduct a mechanism of automated domain validation via DNS queries AND such CA chosen as it executes these validation queries from a point of origin whose upstream routing may be manipulated via the attacker so as to intercept DNS query traffic intended to leave the CA destined for the authoritative DNS servers for the FDQN being attacked. In the absence of ubiquitious DNSSEC validation, even a properly DNSSEC signed zone is unlikely to evade an attack of this nature. In an environment where CAA checking is universally paired with proper DNSSEC validation of the CAA check queries, a properly DNSSEC signed zone will definitely shut down these attacks. Thanks, Matt Hardeman _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
