|
Section 3.4 of draft-ietf-trans-threat-analysis is supposed to
describe the attack presented by DKG in
https://www.ietf.org/mail-archive/web/trans/current/msg01984.html.
However, the text that is currently in the document does not
accurately describe the attack, contains technical errors, and is
difficult to read. So, I have written some text that I propose should replace the text that is currently in Section 3.4 of draft-ietf-trans-threat-analysis. This text would replace all of Sections 3.4, 3.4.1, and 3.4.2. Please review this text and comment if you agree that it better describes the attack in https://www.ietf.org/mail-archive/web/trans/current/msg01984.html than the text that is currently in the document does. Thanks, David 3.4. Multiple Certificate Chains Section 3.2 examined attacks in which a malicious CA issued a bogus certificate and either tried to prevent the Subject from detecting the bogus certificate (Sections 3.2.1.2, 3.2.1.3, and 3.2.2) or continued to present the bogus certificate, to at least some relying parties, as "good" even if the Subject requested revocation (Section 3.2.1.1.1). These attacks are limited in that if the bogus certificate is not submitted to a log, then it may not be accepted by CT-aware browsers, and submitting the bogus certificate to a log increases the chances that the CA's malicious behavior will be detected. In general, if a CA is discovered to be acting maliciously, its certificates will no longer be accepted, either because its parent will revoke its CA certificate, its CA certificate will be added to browsers' blacklists, or both. However, a malicious CA may be able to obtain SCTs for the bogus certificates that it issues and continue to have those certificates accepted by relying parties even after its malicious behavior has been detected by creating more than one chain for the certificates, as shown in Figure 2. +-----------------+ +-----------------+ | CA A | | CA B | +-----------------+ +-----------------+ \ / \ / CA certificate 1 \ / CA certificate 2 \ / +----------------+ | malicious CA | +----------------+ | | bogus EE certificate | +------------------+ | targeted Subject | +------------------+ Figure 2: Multiple Certificate Chains for a Bogus Certificate In Figure 2, the malicious CA has been issued CA certificates by two different parent CAs. The parent CAs may be two different trust anchors, or one or both of them may be an intermediate CA that is subordinate to a trust anchor. If both parent CAs are intermediate CAs, they may be subordinate to the same trust anchor or to different trust anchors. The malicious CA may have obtained certificates from the two parents by applying to them for the certificates, or by compromising the parent CAs and creating the certificates without the CAs' knowledge. By having two chains the malicious CA could provide the chain that includes CA A when submitting certificates to logs, but then provide the chain that includes CA B to targeted browsers. If the CA's malicious behavior is detected, then CA A and browser vendors may be alerted and revoke/blacklist CA certificate 1. However, since CA certificate 2 does not appear in any logs, those who detected the malicious behavior may not discover the second chain and so may not alert CA B or browser vendors of the need to revoke/blacklist CA certificate 2. In this case, targeted browsers would continue to accept the bogus certificates issued by the malicious CA, since the certificate chain they are provided is remains valid. [Editor's note: A number of possible countermeasures have been discussed, but it is not clear whether they should be discussed here or in Section 5. Examples that browsers could implement include: requiring that all intermediate certificates be logged; blacklisting all certificates issued by a malicious CA (not just the CA certificate issued to the malicious CA); and blacklisting the malicious CA's public key rather than just a particular certificate containing that public key. In order for the blacklisting of the EE certificates to help, logs would need to check the status of intermediate certificates in chains submitted to them prior to issuing an SCT.] |
_______________________________________________ Trans mailing list Trans@ietf.org https://www.ietf.org/mailman/listinfo/trans
