(Eliding Attack 1, since this discussion is about how it’s already been mitigated)
On Fri, Feb 4, 2022 at 6:05 PM Rob Stradling <[email protected]> wrote: > Attack 2 (where the CA treats only the Subscriber's proof-of-possession of > the CSR as equivalent to proof-of-possession of the private key): > Eve correctly guesses that Alice obtained her cert via a particular > certificate reseller. > Eve requests a certificate by providing Alice's CSR to the same > certificate reseller, who forwards it to the CA. > The CA notices that it already has suitable validation records for this > Subscriber (the reseller) that are < 398 days old. > The CA issues the certificate (without requiring the reseller to again > prove control of Alice's domain name). > At this point, do we agree or not that there’s a separate failure? That is, this seems to be exactly the issue with domain reuse, and exactly the lax practices that are concerning, in as much as no diligence of authorization of the request has been done. The fact that a certificate was issued, based on Eve’s request, _and_ that the CA considers the reseller the Subscriber, seems to represent two separate failures. We already went through this with the TLS-01/TLS-ALPN-01 discussion, and there seemed agreement that such a confused deputy system represented a fundamentally unacceptable level of risk, since there, the risk was as well confusion between principals of Alice and Eve. While some providers further allowed Alice a usable certificate, the base level Validation failure was the issue. The CA sends the certificate to the reseller. > The reseller forwards the certificate to Eve. > Eve can't use the certificate, but that was never her intent anyway. > Eve asks the reseller to revoke her cert, selecting Key Compromise as the > reason, and presenting Alice's CSR as "proof". > The reseller forwards this revocation request to the CA. > Here again, we have another failure. To the extent that the reseller is acting as the Subscriber, they have allowed Eve to impersonate Alice, first in the issuance, and then in the revocation. This is a bad reseller. Now, I am with you that it’s likely there are bad resellers in the ecosystem. The extent to which we’ve seen resellers escrow private keys is, no doubt, proof of this. But I’m not sure this is the damning attack, in as much as it relies on the reseller failing. To the CA, only that reseller can make that request. Arguably, nothing we do or say policy wise would change that relationship, since resellers are currently out of scope. It’s easy to show this by looking at resellers who do escrow the key, or resellers which manages a revocation key (on behalf of Alice). If they are able to be directed by Eve to cause the CA to do some action, then this same attack exists for any protocol which requires “active” proof. The fundamental problem with this reseller design is that the reseller is, at best, questionable as the Subscriber. If they truly are authorized by Alice, then so are their failures. Yet if they aren’t, then it’s a failure by the CA to obtain a Subscriber agreement with the correct entity. Have I missed something? The CA accepts this "proof". > The CA revokes Eve's cert. > The CA also revokes Alice's cert, since it has the same key as Eve's cert > and belongs to the same Subscriber (the reseller). > Alice is surprised! > -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAErg%3DHGtK4T0ceimYZqk04NCdoLE8GXvg9S1FXtNKfm%2BYcLNXg%40mail.gmail.com.
