On Thu, Jul 20, 2017 at 8:13 PM, Matthew Hardeman via dev-security-policy < [email protected]> wrote: > > My purpose in writing this was to illustrate just how easily someone with > quite modest resources and the right skill set can presently overcome the > technical checks of DNS based domain validation (which includes things such > as HTTP validation). >
Sure, and this was an excellent post for that. But I note that you discounted, for example, registry attacks (which are, sadly, all too common). And I think that's an important thing to consider. The use of BGP attacks against certificate issuance are well-known and long-documented, and I also agree that it's not something we've mitigated by policy. I also appreciate the desire to improve issuance practices - after all, it's telling that it's only 2017 before we're likely to finally do away with "CA invents whatever method to validate it wants" - but I think we should also look holistically at the threat scenario. I mention these not because I wouldn't want to see mitigations for these, but to make sure that the mitigations proposed are both practical and realistic, and that they look holistically at the threat model. In a holistic look, one which accepts that the registry can easily be compromised (and/or other forms of DNSSEC shenanigans), it may be that the solution is better invested on detection than prevention. I'll write separately in a less sensationalized post to describe each risk > factor and appropriate mitigations. > > In closing I wish to emphasize that Let's Encrypt was only chosen for this > example because it was convenient as I already had a client installed and > also literally free for me to perform multiple validations and certificate > issuances. (Though I could do that with Comodo's domain validation 3 month > trial product too, couldn't I?) A couple of extra checks strongly suggest > that quite several other CAs which issue domain validation products could > be just as easily subverted. As yet, I have not identified a CA which I > believe is well prepared for this level of network manipulation. To their > credit, it is clear to me that the people behind Let's Encrypt actual > recognize this risk (on the basis of comments I've seen in their discussion > forums as well as commentary in some of their recent GitHub commits.) > Furthermore, there is evidence that they are working toward a plan which > would help mitigate the risks of this kind of attack. I reiterate again > that nothing in this article highlights a risk surfaced by Let's Encrypt > that isn't also exposed by every other DV issuing CA I've scrutinized. Agreed. However, we're still figuring out with CAs how not to follow redirects when validating requests, so we've got some very, very low-hanging fruit in the security space to improve on. And this improvement is, to some extent, a limited budget, so we want to go for the big returns. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
