Subject: [Trans] slight timing whoops

From: Stephen Kent <[email-masked]>
Date: Thu, 14 Apr 2016 09:55:26 -0400

We've been having trouble getting the -05 version of the threat analysis 
posted, so
my message about the changes that have been incorporated is a bit premature.

Here is the modified text:

*Introduction, page 4:*

Certificate Revocations Lists (CRLs) [RFC5280] are the primary meansof
    certificate revocation established by IETF standards.Unfortunately, 
most
    browsers do not make use of CRLs to check therevocation status of 
certificates
    presented by a TLS Server(Subject). Some browsers make use of Online
    Certificate  StatusProtocol (OCSP) data [RFC6960] as a 
standards-based alternative
    toCRLs. If a certificate contains an Authority Information Access 
(AIA )
    extension [RFC5280], it directs a replying party to an OCSP server to
    which a request can be directed. This extension also may be used by a
    browser to request OCSP responses from a TLS server with which it is
    communicating [RFC6066, RFC6961].

    RFC 5280 does not require inclusion of an AIA extension in 
certificates,
    so a browser cannot assume that this extension will be present. The
    Certification Authority and Browser Forum (CABF) baseline 
requirements and
    extended validation guidelines do mandate inclusion of this 
extension in EE
    certificates (in conjunction with their certificate policies). (See
https://cabforum.org for the most recent versions of these policies.)

    In addition to the revocation status data dissemination mechanisms 
specified
    by IETF standards, most browser vendors employ proprietary means of

conveying certificate revocation status information to their products, 
e.g.,
    via a blacklist that enumerates revoked certificates (EE or CA).Such
    capabilities enable a browser vendor to cause browsers toreject any
    certificates on the blacklist. This approach also can be employed to
    remedy mis-issuance.Throughout the remainder of this document 
references to
    certificaterevocation as a remedy encompass this and analogous forms of
    browser behavior, if available. Note: there are no IETF standards 
that define
    browser blacklist mechanisms.

3.2.1.1.1. Self-monitoring Subject

< add a second paragraph>

    A malicious CA might revoke a bogus certificate to avoid having browser
    vendors take punitive action against the CA and/or to persuade them 
to not
    enter the bogus certificate on a vendor-maintained blacklist. 
However, the CA
    might provide a “good” OCSP response (from a server it operates) to 
a targeted
    user (browser instance) as a way to circumvent the remediation 
nominally offered
    by revocation. No component of CT is tasked with detecting this sort 
of misbehavior
    by a CA. (The misbehavior is analogous to a log offering split views 
to different
    clients. The Audit element of CT is tasked with detecting this sort 
of attack.)

3.2.1.1.2. Benign third party Monitor

If a benign third party monitor is checking the logs to which 
acertificate was
    submitted and is protecting the targeted Subject, itwill detect the 
bogus certificate
    and will alert the Subject. TheSubject will then ask the CA to 
revoke the bogus
    certificate. As in3.2.1.1.1, the CA may or may not revoke the 
certificate and it
    might revoke the  certificate but provide “good” OCSP responses to a 
targeted user
    (browser instance).

--------

3.3 Malicious, Colluding CAs

Section 3.2 examined attacks in which a single CA might issue 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 (but not detection) safeguards envisioned by CT. Their goal 
would be trick a CT-aware browser into accepting a bogus certificate 
because it was accompanied by a valid SCT, while evading certificate 
revocation status indications. This section explores such scenarios.

In this attack two CAs that do not share a common path to a trust 
anchor, collude to create a “doppelganger” (bogus) EE certificate. 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 (which are presumed to be benign). The two CAs must 
have the same Subject name and the same public key for the attack. (RFC 
5280 doe not explicitly 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, as per Section 4.2.1.6. However, the Security Considerations 
section of RFC 5280 warns that name collisions could cause security 
problems.)

Because the two CAs have the same name and make use of the same key, 
each can issue the (bogus) doppelganger certificates. One of the CAs 
would log the certificate and acquire an SCT for it, while the other 
would not.

Because the bogus certificate is logged, it is subject to detection as 
such by a Monitor. Once the bogus certificate is detected it is 
anticipated that action will be taken to render it invalid. The bogus 
certificate itself might be revoked by the CA that issued and logged it, 
an action that masks the malicious intent of that CA. A browser vendor 
might add the bogus certificate to a blacklist maintained by the vendor, 
e.g., because the CA failed to revoke the bogus certificate.

If the CA that logged the bogus certificate is suspected of being 
malicious, e.g., because it has a history of using bogus certificates, 
the certificate of that CA might itself be revoked. This revocation 
might be effected by the parent of that CA (which is not complicit), or 
by a browser vendor using a blacklist. Whether the proposed attack can 
achieve its goal depends on which revocation mechanism is employed, and 
which certificate or certificates are revoked.

3.3.1 Revocation of the Bogus Certificate

If the bogus (EE) certificate is revoked by the CA that issued and 
logged it, browsers should treat that certificate as invalid. However, a 
browser checking a CRL or OCSP response might not match this revocation 
status data against the doppelganger issued by the second CA. This is 
because revocation status checking is performed in the context of a 
certification path (during path validation). The doppelgangers have 
different certification paths and thus the revocation status data for 
each might be acquired and managed independently. (RFC 5280 does not 
provide implementation guidance for management of revocation data. It is 
known that some relying party implementations maintain such information 
on a per-certificate path basis, but others might not.)

Even if the bogus certificates contain an AIA extension pointing to an 
OCSP server the attack might still succeed. (As noted in the Section 1, 
RFC 5280 does not mandate inclusion this extension, but its presence is 
required by CABF requirements.) As noted in Section 3.2.1.1.1, a 
malicious CA could send a “good” OCSP response to a targeted browser 
instance, even if other parties are provided with a “revoked” response. 
Also note that a TLS server can supply an OCSP response to a browser as 
part of the TLS handshake [RFC6961], if requested by the browser. A TLS 
server posing as the entity named in the bogus certificate could acquire 
a “good” OCSP response from the colluding CAs to effect the attack. Only 
if the browser relies upon a trusted, third-party OCSP responder, one 
not part of the collusion, would the attack fail.

The analysis above also applies to the use of CRLs to disseminate 
certificate revocation status data. The doppelganger certificate could 
contain a CRL distribution point extension instead of an AIA extension. 
In that case a site supplying CRLs for the colluding CAs could supply 
different CRLs to different requestors, in an attempt to hide the 
revocation status of the doppelganger from targeted browsers instances. 
This is analogous to a split-view attack effected by a CT log. However, 
as noted in Section 3.2.1.1 and 3.2.1.1.1, no element of CT is 
responsible for detecting inconsistent reporting of certificate 
revocation status data. (Monitoring in the CT context tracks log entries 
made by CAs or Subjects. Auditing is designed to detect misbehavior by 
logs, not by CAs per se.)

If the CA that logged the certificate does not revoke it, a browser 
vendor might enter the bogus certificate into a “blacklist”. 
Unfortunately, there are no IETF standards for such blacklists. Thus it 
is conceivable that the revocation status data also might be managed in 
a path-specific fashion. If that were true, then the attack could 
succeed. However, if a vendor maintains revocation status data in a 
path-independent fashion, then the attack will fail. For example, if 
revoked certificates are identified by CA name and serial number, or a 
hash of the certificate, this attack would fail.

3.2.2 Revocation of the Colluding CA Certificate

If the CA that logged the bogus certificate is viewed as acting 
maliciously, its parent might revoke that CA’s certificate. Even though 
the two colluding CAs have the same name and use the same public key, 
their certificates are distinct, e.g., they were issued by different 
parents and almost certainly have different certificate serial numbers. 
Thus revocation of the certificate of the CA that logged the bogus 
certificate does not affect the certificate of its colluding partner. In 
this case, the bogus EE certificate would be treated as valid when it 
appears in a certification path involving the second colluding CA. Thus 
revocation the certificate for the CA that was detected as malicious 
does not prevent this attack from succeeding.

A vendor also might choose to add the certificate of the CA that issued 
the bogus certificate to its blacklist, e.g., if that CA refuses to 
revoke the bogus certificate. This also may not prevent the bogus 
certificate from being accepted by a browser. For example, if the CA 
certificate blacklist entry is analogous to a CRL entry (Subject name of 
the parent of the malicious CA and the serial number of the malicious 
CA’s certificate), the colluding CA’s certificate would still be valid 
in this case.

-------

3.4 Undetected Compromise of CAs or Logs

Sections 3.1 and 3.2 examined attacks in the context of non-malicious 
and malicious CAs, and benign and misbehaving logs. Another class of 
attacks might occur in the context of a non-malicious CA and/or a benign 
log. Specifically these CT elements might be compromised and the 
compromise might go undetected. Compromise of CAs and logs was noted in 
Section 2, as was coercion of a CA. As noted there, a compromised CA is 
essentially a malicious CA, and thus the discussions in Section 3.2 are 
applicable. The case of an undetected compromise warrants some 
additional discussion, since some relying parties may see signed objects 
issued by the legitimate (non-malicious) CA, others may see signed 
objects from its compromised counterpart, and some may see objects from 
both. In the case of a compromised CA or log the adversary is presumed 
to have access to the private key used by a CA to sign certificates, or 
used by a log to sign SCTs and STHs. Because the compromise is 
undetected, there will be no effort by a CA to have its certificate 
revoked or by a log to shut down the log.

3.4.1 Compromised CA, Benign Log

In the case of a compromised (non-malicious) CA, an attacker uses the 
purloined private key to generate a bogus certificate (that the 
compromised CA would not issue). If this certificate is submitted to a 
(benign) log, then it subject to detection by a Monitor, as discussed in 
3.1.1.1. If the bogus certificate is submitted to a misbehaving log, 
then an SCT can be generated, but there will be no entry for it, as 
discussed in 3.1.1.2. If the bogus certificate is not logged, then there 
will be no SCT, and the implications are as described in 3.1.2.

This sort of attack may be most effective if the CA that is the victim 
of the attack has issueda certificate for the targeted Subject. In this 
case the bogus certificate will then have the same certification path as 
the legitimate certificate, which may help hide the bogus certificate. 
However, means of remedying the attack are independent of this aspect, 
i.e., revocation canbe effected irrespective of whether the targeted 
Subject received its certificate from the compromised CA.

A compromised (non-malicious) CA may be able to revoke the bogus 
certificate if it is detected by a Monitor, and the targeted Subject has 
been notified. It can do so only when the serial number of the bogus 
certificate is made known to this CA. Also, the bogus certificatecannot 
have been issued with an Authority Information Access (AIA) or CRL 
Distribution Point (CRL DP) extension that enables only the malicious 
twin to revoke the certificate. (The AIA extension in the bogus 
certificate could be used to direct relying parties to an OCSP server 
controlled by the malicious twin. The CRL DP extension could be used to 
direct relying parties to a CRL controlled by the malicious twin.) If 
the bogus certificate contains either extension, the compromised CA 
cannot effectively revoke it, but it will also be apparent that the 
bogus certificate was issued by the malicious twin. (The AIA or CRL DP 
extension would provide a strong indication that the bogus certificate 
was not generated by the compromised CA itself.)

If the serial number of the bogus certificate is the same as for a 
valid, not-expired certificate issued by the CA (to the target or to 
another Subject), then revocationposes a problem. This is because 
revocation of the bogus certificate will also invalidate a legitimate 
certificate. This problem may cause the compromised CA to delay 
revocation, thus allowing the bogus certificate to remain a danger for a 
longer time.

The compromised CA may not realize that the bogus certificate was issued 
by a malicious twin; one occurrence of this sort might be regarded as an 
error, and not cause the CA to transition to a new key pair. (This 
assumes that the bogus certificate does not contain an AIA or CRL DP 
extension that wrests control of revocation from the compromised CA.) If 
the compromised CA does determine that its private key has been stolen, 
it may take some time to transition to a new key pair, and reissue 
certificates to all of its legitimate Subjects. Thus an attack of this 
sort may take a while to be remedied.

Also note that the malicious twin of the compromised CA may be capable 
of issuing its own CRL or OCSP responses, without changing any AIA/CRL 
DP data present in the targeted certificate. The revocation status data 
from the evil twin will appear as valid as those of the compromised CA. 
If the attacker has the ability to control the sources of revocation 
status data available to a targeted user (browser instance), then the 
user may not become aware of the attack.

A bogus certificate issued by the malicious CA will not match the SCT 
for the legitimate certificate, since they are not identical, e.g., at a 
minimum the private keys do not match. Thus a CT-aware browser that 
rejects certificates without SCTs (see 3.1.2.2) will reject a bogus 
certificate created under these circumstances if it is not logged. If 
the bogus certificate is detected and logged, browsers that require an 
SCT will reject the bogus certificate.

3.4.2 Benign CA, Compromised Log

A benign CA does not issue bogus certificates, except as a result of an 
accident or attack. So, in normal operation, it is not clear what 
behavior by a compromised log would yield an attack. If a bogus 
certificate is issued by a benign CA (under these circumstances) is 
submitted to a compromised (non-malicious) log, then both an SCT and a 
log entry will be created. Again, it is not clear what additional 
adverse actions the compromised log would perform to further an attack 
on CT.

3.4.3 Compromised CA, Compromised Log

As noted in 3.4.1, an evil twin CA may issue a bogus certificate that 
contains the same Subject name as a legitimate certificate issued by the 
compromised CA. Alternatively, the bogus certificate may contain a 
different name but reuse a serial number from a valid, not revoked 
certificate issued by that CA.

The evil twin CA might submit a bogus certificate to the evil twin of a 
compromised log. The operator of the evil twin log can use the purloined 
private key to generate SCTs for certificates that have not been logged 
by its legitimate counterpart. These SCTs will appear valid relative to 
the public key associated with the legitimate log. However, an STH 
issued by the legitimate log will not correspond to a tree containing 
these SCTs. Thus thorough checking of the SCTs issued by the evil twin 
log will identify this discrepancy.

An Auditor checking for log consistency might conclude that the 
compromised log is acting maliciously, and is presenting a split view to 
its clients. In this fashion the compromised log may be shunned and 
forced to shut down. However, if an attacker targets a set of TLS 
clients that do not have access to the legitimate log, they may not be 
able to detect this inconsistency. In this case CT would need to rely on 
a distributed gossiping audit mechanism to detect the compromise (see 
Section 5.6).

In general, this sort of attack is analogous to a malicious CA creating 
a bogus certificate and receiving an SCT (with no log entry) from a 
misbehaving log (Section 4.2.1.2). The lack of a log entry prevents 
detection of the bogus certificate by Monitors, and the presence of the 
SCT prevents rejection by a CT-aware browser that accepts SCTs from the 
compromised log.

---

From: "David A. Cooper" <[email-masked]>
Date: Tue, 26 Apr 2016 16:05:03 -0400

Is it necessary for me to point out
that this draft has not fixed the problems from the previous
drafts? Isn't this supposed to be a working
group document? Why does the document still talk about two
different CAs that have the same name and same key, and that are
"both" controlled by the same entity (the attacker)?

This insistence on referring to this CA as "two CAs" is not only
factually wrong (as are the statements about RFC 5280), they lead
to confusion. The text suggests that the two or more CAs that
might collude to issue a bogus certificate are the "two CAs" that
"have the same Subject name and the same public key," but it is
not. The two colluding CAs are the two CAs that each issue a
cross-certificate to the one (bogus) CA that issues the
(bogus) EE certificate.

Granted, "colluding" may not be the appropriate term. They may be
two CAs that have been unknowingly compromised by the attacker
into issuing the cross-certificates to the (bogus) CA controlled
by the attacker. But what makes this attack different is the two
cross-certificates; so if there is any collusion, it is between
the issuers of the cross-certificates.

On 04/14/2016 09:55 AM, Stephen Kent wrote:

We've been having trouble getting the -05 version of the threat
analysis posted, so

my message about the changes that have been incorporated is a bit
premature.

3.3 Malicious,
Colluding CAs

Section 3.2
examined attacks in which a single CA might issue 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 (but not detection)
safeguards envisioned by CT. Their goal would be trick a
CT-aware browser into accepting a bogus certificate because it
was accompanied by a valid SCT, while evading certificate
revocation status indications. This section explores such
scenarios.

In this attack
two CAs that do not share a common path to a trust anchor,
collude to create a “doppelganger” (bogus) EE certificate. 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 (which are presumed to
be benign). The two CAs must have the same Subject name and
the same public key for the attack. (RFC 5280 doe not
explicitly 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, as per Section 4.2.1.6. However, the
Security Considerations section of RFC 5280 warns that name
collisions could cause security problems.)

Because the two
CAs have the same name and make use of the same key, each can
issue the (bogus) doppelganger certificates. One of the CAs
would log the certificate and acquire an SCT for it, while the
other would not.

Because the bogus
certificate is logged, it is subject to detection as such by a
Monitor. Once the bogus certificate is detected it is
anticipated that action will be taken to render it invalid.
The bogus certificate itself might be revoked by the CA that
issued and logged it, an action that masks the malicious
intent of that CA. A browser vendor might add the bogus
certificate to a blacklist maintained by the vendor, e.g.,
because the CA failed to revoke the bogus certificate.

If the CA that
logged the bogus certificate is suspected of being malicious,
e.g., because it has a history of using bogus certificates,
the certificate of that CA might itself be revoked. This
revocation might be effected by the parent of that CA (which
is not complicit), or by a browser vendor using a blacklist.
Whether the proposed attack can achieve its goal depends on
which revocation mechanism is employed, and which certificate
or certificates are revoked.

3.3.1 Revocation
of the Bogus Certificate

If the bogus (EE)
certificate is revoked by the CA that issued and logged it,
browsers should treat that certificate as invalid. However, a
browser checking a CRL or OCSP response might not match this
revocation status data against the doppelganger issued by the
second CA. This is because revocation status checking is
performed in the context of a certification path (during path
validation). The doppelgangers have different certification
paths and thus the revocation status data for each might be
acquired and managed independently. (RFC 5280 does not provide
implementation guidance for management of revocation data. It
is known that some relying party implementations maintain such
information on a per-certificate path basis, but others might
not.)

Even if the bogus
certificates contain an AIA extension pointing to an OCSP
server the attack might still succeed. (As noted in the
Section 1, RFC 5280 does not mandate inclusion this extension,
but its presence is required by CABF requirements.)  As noted in Section
3.2.1.1.1, a malicious CA could send a “good” OCSP response to
a targeted browser instance, even if other parties are
provided with a “revoked” response. Also note that a TLS
server can supply an OCSP response to a browser as part of the
TLS handshake [RFC6961], if requested by the browser. A TLS
server posing as the entity named in the bogus certificate
could acquire a “good” OCSP response from the colluding CAs to
effect the attack. Only if the browser relies upon a trusted,
third-party OCSP responder, one not part of the collusion,
would the attack fail.

The analysis
above also applies to the use of CRLs to disseminate
certificate revocation status data. The doppelganger
certificate could contain a CRL distribution point extension
instead of an AIA extension. In that case a site supplying
CRLs for the colluding CAs could supply different CRLs to
different requestors, in an attempt to hide the revocation
status of the doppelganger from targeted browsers instances.
This is analogous to a split-view attack effected by a CT log.
However, as noted in Section 3.2.1.1 and 3.2.1.1.1, no element
of CT is responsible for detecting inconsistent reporting of
certificate revocation status data. (Monitoring in the CT
context tracks log entries made by CAs or Subjects. Auditing
is designed to detect misbehavior by logs, not by CAs per se.)

If the CA that
logged the certificate does not revoke it, a browser vendor
might enter the bogus certificate into a “blacklist”.
Unfortunately, there are no IETF standards for such
blacklists. Thus it is conceivable that the revocation status
data also might be managed in a path-specific fashion. If that
were true, then the attack could succeed. However, if a vendor
maintains revocation status data in a path-independent
fashion, then the attack will fail. For example, if revoked
certificates are identified by CA name and serial number, or a
hash of the certificate, this attack would fail.

3.2.2 Revocation
of the Colluding CA Certificate

If the CA that
logged the bogus certificate is viewed as acting maliciously,
its parent might revoke that CA’s certificate. Even though the
two colluding CAs have the same name and use the same public
key, their certificates are distinct, e.g., they were issued
by different parents and almost certainly have different
certificate serial numbers. Thus revocation of the certificate
of the CA that logged the bogus certificate does not affect
the certificate of its colluding partner. In this case, the
bogus EE certificate would be treated as valid when it appears
in a certification path involving the second colluding CA.
Thus revocation the certificate for the CA that was detected
as malicious does not prevent this attack from succeeding.

A vendor also
might choose to add the certificate of the CA that issued the
bogus certificate to its blacklist, e.g., if that CA refuses
to revoke the bogus certificate. This also may not prevent the
bogus certificate from being accepted by a browser. For
example, if the CA certificate blacklist entry is analogous to
a CRL entry (Subject name of the parent of the malicious CA
and the serial number of the malicious CA’s certificate), the
colluding CA’s certificate would still be valid in this case.