On Fri, 12 Apr 2019 16:56:23 +0000 Jeremy Rowley via dev-security-policy <dev-security-policy@lists.mozilla.org> wrote:
> I don't mind filling in details. > > We have a system that permits creation of certificates without a CSR > that works by extracting the key from an existing cert, validating > the domain/org information, and creating a new certificate based on > the contents of the old certificate. The system was supposed to do a > handshake with a server hosting the existing certificate as a form of > checking control over the private key, but that was never > implemented, slated for a phase 2 that never came. We've since > disabled that system, although we didn't file any incident report > (for the reasons discussed so far). Thanks Jeremy I agree that in TLS specifically there's no direct way to leverage these certificates to do anything awful. So for m.d.s.policy's core purpose of caring about Mozilla/ Firefox there's no problem here, and as others have noticed the BRs are silent on this. Though perhaps they should not be. I am not so sure in the general case, it is certainly possible in the very general sense to create scenarios in which something resembling the Confused Deputy problem arises with this sort of certificate, a loose example follows taking inspiration from the work done recently on TLS 1.3 PSK attacks by Drucker and Gueron 1. Trent is a Trusted Third Party, in this case a CA issuing IOT devices certificates tying their identity to a public key. Unfortunately Trent is easily confused as we shall see 2. These IOT devices don't do TLS but have some custom public key protocol using Trent's certificates. One feature in this protcol is the [MUTE] message to tell devices you want nothing further to do with them. 3. Alice, the Archive System, has a cert (Alice,A). Bob, the video surveillance system also has a cert (Bob,B). And finally there's a singing fish toy Carol with a cert (Carol,C) received as a free gift. 4. The makers of Carol trick Trent into issuing (Carol,A) a certificate with Carol's identity but Alice's public key 5. Carol presents Bob with (Carol,A) and annoys Bob with constant nonsense, knowing that in the protocol Bob can reply with a [MUTE] message to make her stop. 6. Bob sends a message to Carol, but using the A public key. Carol can't read this message since she does not know the A private key but she can reasonably guess it's a [MUTE] 7. Carol relays Bob's [MUTE] to Alice. It is encrypted to Alice, and signed by Bob, so Alice will consider this a valid [MUTE] message from Bob. 8. Now the video surveillance footage is not archived, because a toy fish switched it off... it may be very difficult to diagnose that the problem was with Trent, issuing this bogus (Carol,A) cert, as even if suspicion falls on Carol (or Carol's makers) it's far from obvious how they could cause Bob to send Alice a message. The fact that DigiCert's CPS says explicitly that it will check CSRs is a good thing. Not checking them is a bad thing. Is the situation that we need to spell out in the BRs or Mozilla policy every single basically good idea to ensure CAs don't think it's optional and stop doing it? Let's hope not. Nick. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
