Subject: [Trans] draft-ietf-trans-threat-analysis and DKG's conspiring CAs attack

From: "David A. Cooper" <[email-masked]>
Date: Thu, 18 Aug 2016 15:24:01 -0400

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.]

---

From: Melinda Shore <[email-masked]>
Date: Thu, 18 Aug 2016 11:52:01 -0800

Please give this a serious, thoughtful review.  We'd like to
get this document wrapped up and cannot do that until we've
got general agreement on the attack description.

Melinda

On 8/18/16 11:24 AM, David A. Cooper wrote:
> Section 3.4 of draft-ietf-trans-threat-analysis is supposed to describe
> the attack presented by DKG in
> 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.
> 
> https://www.ietf.org/mail-archive/web/trans/current/msg01984.html than
> the text that is currently in the document does.
> 
> Thanks,
> 
> David
> 
> ------------------------------------------------------------------------
> 
> 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.
> 
> 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.
> 
>    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.
> 
> 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.
> 
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trans
>

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 23 Aug 2016 15:41:20 +0000

I read the text in the mail message.  I find it clear and understandable. 

I don't find the existing text as clear.  I am not sure that they are talking about the same thing.  If I had more cycles available, I could convince myself that they are.

But open reading the mail text, my response is "yup, it can't, and that's okay ."  Which leads me to a propose simpler text.

"CT cannot protect against multiple CA's signing the same TBSCertificate[keypair, if you prefer] unless both CA's are logging what they sign."