Subject: [Trans] updated Section 3.3

From: Stephen Kent <[email-masked]>
Date: Thu, 24 Mar 2016 11:11:23 -0400

3.3 Malicious, Colluding CAs

Section 3.2 examined attacks in which a single CA issued a bogus 
certificate. There is also the potential that two or more CAs might 
collude to issue a bogus certificate in a fashion designed to foil the 
remediation safeguards envisioned by CT.

In general, any two CAs that are not name-constrained and do not share a 
common path to a trust anchor can collude to create a “doppelganger” EE 
certificate that is bogus. The attack need not be initiated by trust 
anchors; any subordinate pair of (not name-constrained) CAs can effect 
this attack without the knowledge of superiors CAs. (RFC 5280 doe not 
preclude the creation of two CAs with the same name, so long as the 
parent CAs are distinct. Requirements for Subject name uniqueness apply 
individually to each CA but not across CA boundaries. There also is no 
requirement for public key uniqueness across all CAs. However, the 
creation of doppelganger EE certificates by these CAs may be a violation 
of RFC 5280 (if one views the CAs that appear on different certification 
paths as one CA).

The attack requires that each of the colluding CAs issues a certificate 
for a targeted Subject (e.g., web site). These two (EE) certificates are 
identical, hence the use of the term “doppelganger”; they contain the 
same name, public key, serial number, etc. Only one of the malicious CAs 
logs the bogus certificate and acquires an SCT for it.

The logged bogus certificate can be detected by a Monitor (third party 
or self), that is observing the log(s) to which the certificate was 
posted. Thus the detection aspect of CT still works with regard to this 
(bogus) certificate. When this certificate is detected, the CA that 
logged the certificate might choose to revoke it, i.e., place it on a 
CRL or create an OCSP response for it. However, a browser checking a CRL 
or OCSP response may not match this revocationstatus data against the 
doppelganger certificate. This is because revocation status checking is 
performed in the context of a certificate path. The doppelganger 
certificates have different certificate paths and thus the revocation 
status data for each might be acquired and stored independently. (RFC 
5280 does not provide implementation guidance for management of 
revocation data.) Revoking a detected, bogus certificatemight be the 
best strategy for the malicious CA that logged the certificate; it makes 
issuance of the bogus certificate appear to be an accident, and thus a 
browser vendor might not feel the need to make an entry on its 
blacklists for the bogus certificate or for the CA that issued it. (If 
the bogus certificate included an AIA extension providing information 
for revocation status checking, revocation by the CA that logged the 
bogus certificate would not be an effective strategy for these colluding 
CAs. However, inclusion of this extension is not mandated by RFC 5280. 
Also the extension is not critical, meaning that relying parties are not 
required to be able to process it.)

If the CA that logged the bogus certificate fails to revoke it, browser 
vendors might blacklist the certificate. However, as noted above, the 
doppelganger, which was not logged, will match the SCT created for the 
logged certificate. If remediation is effected by blacklisting (instead 
of revocation by one of the malicious CAs) then the ability of CT to 
deal with this sort of attack may be diminished. Some forms of 
blacklisting will cause the not-logged bogus certificate to be detected 
and rejected, while others will not, depending on the details of the 
blacklisting mechanism. Mechanisms for blacklisting by browsers are not 
specified in any IETF standards. The mechanisms are browser-specific, 
and the choice of how to blacklist (e.g., the bogus certificate vs. the 
CA that issued it) are the purview of each browser vendor. Thus, 
depending on the details of the blacklist mechanism and the way that a 
browser vendor chooses to manage this list, a doppelganger CA attack 
might or might not pose a problem in terms of successful remediation of 
the attack.

---

From: Paul Wouters <[email-masked]>
Date: Thu, 24 Mar 2016 12:02:25 -0400 (EDT)

On Thu, 24 Mar 2016, Stephen Kent wrote:

> The attack requires that each of the colluding CAs issues a certificate for a targeted Subject (e.g., web site). These two (EE) certificates are
> identical, hence the use of the term “doppelganger”; they contain the same name, public key, serial number, etc. Only one of the malicious CAs logs
> the bogus certificate and acquires an SCT for it.

I don't fully understand your description of the attack.

If the certificates are doppelgangers, wouldn't that mean that they
cannot have AIA's ? Otherwise at least one CA would be using an "unusual"
AIA revocation location that monitors would detect.

> The logged bogus certificate can be detected by a Monitor (third party or self), that is observing the log(s) to which the certificate was posted.
> Thus the detection aspect of CT still works with regard to this (bogus) certificate. When this certificate is detected, the CA that logged the
> certificate might choose to revoke it, i.e., place it on a CRL or create an OCSP response for it. However, a browser checking a CRL or OCSP response
> may not match this revocation status data against the doppelganger certificate.

So either the EE-certificates have different AIA's and are not doppelgangers,
or they would have the same AIA's and a browser would always find the
matching CRL/OCSP responses? Or the EE-certs cannot contain AIA
revocation information (which in itself should be unusual enough for
monitors to pick up)

My understanding is that a lot of code (eg NSS) ignores AIA revocation
information specified on the Root CA's, but do check them on the
intermediate CA's and EE-certs, so I guess the attack can work if the
EE-cert has no AIA but the intermediate CA's do? But I guess it would
also be odd for an intermediate CA with AIA revocation on it, to issue
EE-certifications with no AIA revocation information in it?

Paul

---

From: Stephen Kent <[email-masked]>
Date: Fri, 25 Mar 2016 10:44:50 -0400

Paul,

> ...
The doppelgangers could have AIAs, but they need not, and that is the 
assumption
I adopted here. In general it is in the interest of the CAs to not put 
AIAs in these certs,
if the plan is to revoke one, but not the other.  (Unless the CAs can 
control which
revocation status info is accessible to targeted browser users, in which 
case it doesn't
matter.)
>
>> The logged bogus certificate can be detected by a Monitor (third 
>> party or self), that is observing the log(s) to which the certificate 
>> was posted.
>> Thus the detection aspect of CT still works with regard to this 
>> logged the
>> certificate might choose to revoke it, i.e., place it on a CRL or 
>> create an OCSP response for it. However, a browser checking a CRL or 
>> OCSP response
> matching CRL/OCSP responses? 
There is no requirement that certs contain an AIA extension. It also is 
not mandated by
5280, nor is it required for EE certs that meet the CABF DV or EV profiles.
> Or the EE-certs cannot contain AIA

Because there is no requirement in 5280 (or in DV/EV profiles) that any 
cert to contain an AIA
extension, that is hardly a reason for a Monitor to flag these cert. CA 
certs
MUST contain a CRL DP extension if they conform to the DV or EV 
profiles. But, it appears
that most browsers do not fetch CRLs, so this mandate for DV/EV certs is 
probably moot.
The proposal that I put forth over a year ago would allow a CA to assert 
that it was
issuing a cert that conformed to DV or EV profiles. If that extension to 
the cert submission
data and SCT were adopted, then it would make sense for a Monitor to 
flag a CA cert
that lacked a CRL DP extension, and which claimed to be issued under 
these profiles.
But, that proposal went nowhere, so ...

A Monitor should notify a Subject if the Monitor detects a logged cert 
that does not
have the same public key as a registered by the Subject with the same DN 
or AltName
(as described in draft-kent-trans-monitor-auditor-00.txt, but not 
mentioned in 6962-bis).
> EE-certifications with no AIA revocation information in it?
As I noted above, there is no requirement (in 5280 or in CABF profiles) 
that a cert
contain an AIA extension. Also, the colluding CA certs can contain AIA 
extensions,
but those point to revocation data issued by their parents. If the 
colluding CA certs
contained CRL DP data it could be different for each. Tthere is no 
requirement that those
certs be identical; they need only share the same Subject name for the 
attack to work.
In fact using two different CRLs for these two colluding CAs might even 
help, as it would
naturally direct RPs to different sources for revocation  status info. 
Thus the CA that
revoked the bogus cert would have a different CRL from its partner, and 
an RP would
associate the tow different CRLs with the two CAs (on different paths), 
thus supporting
the attack.

Steve

---

From: Paul Wouters <[email-masked]>
Date: Fri, 25 Mar 2016 10:56:10 -0400 (EDT)

On Fri, 25 Mar 2016, Stephen Kent wrote:

> assumption  I adopted here. In general it is in the interest of the CAs to not put AIAs 
> in these certs,
> if the plan is to revoke one, but not the other.  (Unless the CAs can control 
> which
> revocation status info is accessible to targeted browser users, in which case 
> it doesn't
> matter.)

I would hope that the CT ecosystem would see that if a CA always issues
with AIA in the EE-cert, and then it issues a cert where it does not,
that it would get flagged for a human to look at. Part of CT is keeping
an eye out on the CAs, and this clearly shows some unexpected behaviour
on one or two particular CA's for not including AIA's. It might not be
syntactically bogus, but hopefully something the clients and monitors
would keep an eye out for.

So it seems to me this attack is not very likely to succeed - or at
least would be a short-lived one with a guarantee of being detected.
So it comes with a big enigma problem.

Paul

---

From: Stephen Kent <[email-masked]>
Date: Mon, 28 Mar 2016 10:20:13 -0400

Paul,

>> assumption  I adopted here. In general it is in the interest of the 
>> CAs to not put AIAs in these certs,
>> revocation status info is accessible to targeted browser users, in 
>> which case it doesn't
>> matter.)
>
There is no text in any monitor description that calls for this, so it
may be unduly optimistic to assume such ;-).  Also, if the CAs collude
they would be smart to never include an AIA extension, so as to avoid
drawing attention when an EE cert w/o such an extension is issued.
> So it comes with a big enigma problem.
I can't agree with your conclusion if it's based on the analysis above,
but I also can't predict how long such an attack might go undetected given
the many variables involved.

Steve

---

From: Paul Wouters <[email-masked]>
Date: Mon, 28 Mar 2016 10:35:24 -0400 (EDT)

On Mon, 28 Mar 2016, Stephen Kent wrote:

<chair hat on>

> the many variables involved.

So there seems to be no consensus about the colluding CA's scenario,
and thus no consensus on the text that needs to go into the threat
document. A few people think your text needs changes. It also seems
to be the only issue left for WGLC.

Do you have an idea on how to change the text to accomodate the feedback
received on the list? Should we ask someone else to help you with
this section? Perhaps dkg could help, since he originally came up with
the attack?

We really want to move this document into WGLC, so that the 6962bis
document doesn't have to refer to a draft name, and we are very close
to putting 6962 into WGLC.

Paul

---

From: Ben Laurie <[email-masked]>
Date: Tue, 29 Mar 2016 12:42:41 +0100

On 24 March 2016 at 15:11, Stephen Kent <[email-masked]> wrote:

> certificate. There is also the potential that two or more CAs might collude
> to issue a bogus certificate in a fashion designed to foil the remediation
> safeguards envisioned by CT.
>
>
>
> anchors; any subordinate pair of (not name-constrained) CAs can effect this
> attack without the knowledge of superiors CAs. (RFC 5280 doe not preclude
> the creation of two CAs with the same name, so long as the parent CAs are
> distinct. Requirements for Subject name uniqueness apply individually to
> each CA but not across CA boundaries. There also is no requirement for
> public key uniqueness across all CAs. However, the creation of doppelganger
> EE certificates by these CAs may be a violation of RFC 5280 (if one views
> the CAs that appear on different certification paths as one CA).
>
>
>
> identical, hence the use of the term “doppelganger”; they contain the same
> name, public key, serial number, etc. Only one of the malicious CAs logs
> The logged bogus certificate can be detected by a Monitor (third party or
> self), that is observing the log(s) to which the certificate was posted.
> Thus the detection aspect of CT still works with regard to this (bogus)
> certificate. When this certificate is detected, the CA that logged the
> certificate might choose to revoke it, i.e., place it on a CRL or create an
> OCSP response for it. However, a browser checking a CRL or OCSP response
> may not match this revocation status data against the doppelganger
> certificate. This is because revocation status checking is performed in the
> context of a certificate path. The doppelganger certificates have different
> certificate paths and thus the revocation status data for each might be
> acquired and stored independently. (RFC 5280 does not provide
> implementation guidance for management of revocation data.) Revoking a
> detected, bogus certificate might be the best strategy for the malicious
> CA that logged the certificate; it makes issuance of the bogus certificate
> appear to be an accident, and thus a browser vendor might not feel the need
> to make an entry on its blacklists for the bogus certificate or for the
> CA that issued it. (If the bogus certificate included an AIA extension
> providing information for revocation status checking, revocation by the CA
> that logged the bogus certificate would not be an effective strategy for
> these colluding CAs. However, inclusion of this extension is not mandated
> by RFC 5280. Also the extension is not critical, meaning that relying
> parties are not required to be able to process it.)
>
>
>
> logged certificate. If remediation is effected by blacklisting (instead of
> revocation by one of the malicious CAs) then the ability of CT to deal with
> this sort of attack may be diminished.
>

Once more, this problem is not CT's problem - it is a problem with RFC 5280
et al. That is, the problem exists regardless of the existence or use of CT.

Does this mean 5280 should be updated?

> Some forms of blacklisting will cause the not-logged bogus certificate to
> be detected and rejected, while others will not, depending on the details
> of the blacklisting mechanism. Mechanisms for blacklisting by browsers are
> not specified in any IETF standards. The mechanisms are browser-specific,
> and the choice of how to blacklist (e.g., the bogus certificate vs. the CA
> that issued it) are the purview of each browser vendor. Thus, depending on
> the details of the blacklist mechanism and the way that a browser vendor
> chooses to manage this list, a doppelganger CA attack might or might not
> pose a problem in terms of successful remediation of the attack.
>
> _______________________________________________
> Trans mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trans
>
>

---

From: Ben Laurie <[email-masked]>
Date: Tue, 29 Mar 2016 12:52:41 +0100

On 25 March 2016 at 14:44, Stephen Kent <[email-masked]> wrote:

> contain an AIA extension.
>

This appears to be incorrect. Section 7.1.3.2c of
https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.3.3.pdf says:

"c. authorityInformationAccess

With the exception of stapling, which is noted below, this extension MUST
be present. It MUST NOT be marked critical, and it MUST contain the HTTP
URL of the Issuing CA’s OCSP responder (accessMethod = 1.3.6.1.5.5.7.48.1).
It SHOULD also contain the HTTP URL of the Issuing CA’s certificate
(accessMethod = 1.3.6.1.5.5.7.48.2). . The HTTP URL of the Issuing CA’s
OCSP responder MAY be omitted provided that the Subscriber “staples” OCSP
responses for the Certificate in its TLS handshakes [RFC4366]."

---

From: Stephen Kent <[email-masked]>
Date: Wed, 30 Mar 2016 10:24:42 -0400

Ben,

Whoops, you're right. I missed the reference because I searched for AIA.

So, an EV or DV subscriber cert must contain this extension, although
5280 does not mandate it, and even though no browser is required to be
able to process it (since it's not CRITICAL).

I will revise the text for 3.3 to reflect this.

Steve

>
> On 25 March 2016 at 14:44, Stephen Kent <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     As I noted above, there is no requirement (in 5280 or in CABF
>     profiles) that a cert
> With the exception of stapling, which is noted below, this extension 
> MUST be present. It MUST NOT be marked critical, and it MUST contain 
> the HTTP URL of the Issuing CA’s OCSP responder (accessMethod = 
> 1.3.6.1.5.5.7.48.1). It SHOULD also contain the HTTP URL of the 
> Issuing CA’s certificate (accessMethod = 1.3.6.1.5.5.7.48.2). . The 
> HTTP URL of the Issuing CA’s OCSP responder MAY be omitted provided 
> that the Subscriber “staples” OCSP responses for the Certificate in 
> its TLS handshakes [RFC4366]."
>
>

---

From: Stephen Kent <[email-masked]>
Date: Wed, 30 Mar 2016 10:25:04 -0400

Paul,
> document. 
> A few people think your text needs changes. 
A "few people" also think there need to be changes to 6269-bis :-).
> It also seems
I also posted proposed text (3.4) to address the concerns raised by 
Bryan Ford.
I've received no feedback on that text yet.
> received on the list? 
I will make changes to accommodate feedback that is accurate and rational.
I believe I have been making changes much faster than the authors of 
6269-bis,
over the past 18-24 months.
> Should we ask someone else to help you with
I welcome contributions from DKG.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 30 Mar 2016 10:25:09 -0400

Ben,

> ...
>
>     If the CA that logged the bogus certificate fails to revoke it,
>     browser vendors might blacklist the certificate. However, as noted
>     above, the doppelganger, which was not logged, will match the SCT
>     created for the logged certificate. If remediation is effected by
>     blacklisting (instead of revocation by one of the malicious CAs)
>     then the ability of CT to deal with this sort of attack may be
>     diminished.
>
>
> Once more, this problem is not CT's problem - it is a problem with RFC 
> 5280 et al. That is, the problem exists regardless of the existence or 
> use of CT.
I assume we agree that the issue is not whether inclusion of the AIA 
extension in all EE certs
should be a MUST in 5280, right? Is your point that no standard 
specifies in detail how to manage
revocation status data? If so, then this lack of detail applies not only 
to CRLs and OCSP but
also to browser blacklists, so it's not just a 5280 issue.

In any case, the discussion is an analysis of attacks in the context of 
CT, so to that
extent it is a CT issue.

> Does this mean 5280 should be updated?
I think not. As I noted in prior messages, 5820 is the general PKI spec 
for Internet use of X.509 certs.
There is not always a need to mandate inclusion of AIA, hence it's 
optional. It's appropriate to
profile 5280 for specific application contexts, like the Web PKI. There 
was an IETF WG that was
trying to characterize that context (WPKOPS) but it failed.

Steve

---

From: Ben Laurie <[email-masked]>
Date: Thu, 31 Mar 2016 13:12:22 +0100

On 30 March 2016 at 15:25, Stephen Kent <[email-masked]> wrote:

> 5280 et al. That is, the problem exists regardless of the existence or use
> of CT.
>
> should be a MUST in 5280, right?
>

Right.

> Is your point that no standard specifies in detail how to manage

It seems to me 5280 should at least explain the threat and potential
mitigations (I assume that were you think AIA is not needed has some other
mitigation that should also be documented).