Hi all-- This is a review of https://tools.ietf.org/html/draft-ietf-trans-threat-analysis-06, with a specific focus on the colluding CAs section, which has been a subject of some contention, and which i think was intended to capture the attack which i described on-list a few months ago.
Many thanks to Steve for his work on this draft.
One brief comment on the Introduction:
-----
In the Introduction:
> Also note that one proposal for distributing Audit information (to
> detect misbehaving logs) calls for a browser to send SCTs [...]
This should probably link directly to the gossip draft.
------
> 3.3. Malicious, Colluding CAs
The text in this section does not clearly describe the attack i had
outlined, although it comes close. I think that some ascii-art diagrams
might be useful, and there is some terminology that can be cleaned up.
I'll try to intersperse some comments below for improved clarity.
One initial overall observation is that the "collusion" need not be
contemporaneous.
Consider CA A, whose intermediate CA with cert A_N (using key N) is
compromised and used to issue a bogus EE cert X:
A → A_N → X
This compromise is identified, and X is revoked (by whatever means:
OCSP, CRLs, CRLsets, etc). A considers the failure severe enough to
conclude that N was compromised, and revokes A_N.
However, the attacker has already used N to issue another bogus EE cert
Y, which is not yet deployed in any scenario, so it is unknown:
A → A_N → Y
Some time later, the attacker gains control of CA B.
They use this control to issue intermediate CA cert B_N whose public key
is also N. This means there are two possible chains for Y:
0) A + A_N → Y
1) B → B_N → Y
The attacker logs chain 0, and receives SCT SCT_Y. The log operators
can't block this inclusion in their logs without themselves becoming
meta-CA. If the log decides to try to do this, i believe that other
attacks on the ecosystem appear (based on non-synchronization between
the intermediate CAs blocked by the log and those blocked by the relying
parties).
Though it was logged with chain 0, the cert is deployed with chain 1,
and still shipped with SCT_Y.
Anyone just looking at chain 1 and SCT_Y can tell that it the cert chain
is correct, and that the EE cert has been logged. However, none of the
certificates in its chain have been revoked, and so no alarm bells will
be raised.
Anyone monitoring the logs on behalf of the service identified in Y will
note that a cert was issued to it, but under a bogus, revoked,
known-compromised intermediate cert. None of the existing revocation
mechanisms are likely to revoke Y, since the chain is already thoroughly
debunked.
If the attacker is afraid of a risk of all their certs being revoked,
they can simply issue hundreds or thousands of certs while they have
access to A_N, which encourages narrow-bandwidth blocklisting mechanisms
like CRLsets to just revoke the intermediate CA, and not the EEs,
permitting the alternate chain to be used without detection.
Note that the attacker doesn't even need to maintain access to N if they
are thoughtful about their plans during the period in which N is
compromised.
OK, on to specific comments:
> 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.
Aside from the implication of contemporaneousness, i think this is a
fair characterisation.
> In this attack two CAs that do not share a common path to a trust
> anchor,
I don't think that "do not share a common path to a trust anchor" is
relevant. in a complex issuance hierarchy like this (where the "trust
anchor" is A, and all named nodes are intermediate CAs):
A
/ \
B C
/| |\
D E F G
a compromise of any two nodes would suffice, despite the fact that they
all share a trust anchor.
> collude to create a "doppelganger" (bogus) EE certificate.
I'm not sure that "doppelganger" is a useful turn of phrase here. The
closest thing we have to a "doppelganger" in the particular attack i
described above is B_N, which technically *isn't* any more bogus than
A_N. these intermediate CA certs are "doppelgangers" because they share
SPKI and Subject. But the EE cert in this attack scenario is singular,
not doubled.
> 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 superior CAs (which are presumed to be benign).
This isn't precisely true, because of path length (not name)
constraints. In the attack i've outlined, at least one of the
compromised CAs must either have pathLenConstraint absent, or greater
than zero. If the public certs for all of the compromised CAs have
pathLenConstraint == 0, the attack is not possible.
> (The following text refers to these as two CAs, because they might
> be represented by entities that are organizationally distinct,
> perhaps realized by different physical presences. However, because
> they share the same name and key pair, one also might view them as
> the same CA that appears in two cert paths terminating at different
> TAs.) The two CAs must have the same Subject name and the same
> public key for the attack. (RFC 5280 does 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.)
This paragraph seems wrong to me. The compromised CAs in question are
*not* the same CA, though they do need to create at least one "doubled"
intermediate CA that shares at least the same key (and likely, the same
Subject).
Perhaps it would be better to think about "compromised CA keys" instead
of "compromised CAs", and leave the mechanism of compromise out of the
technical discussion?
> Because the two CAs have the same name and make use of the same key,
> each can issue the (bogus) doppelganger certificates.
This should say "either can issue the bogus end-entity certificate".
(s/each/either/ and dropping doppelganger)
> 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.
>
>
> Kent Expires November 31, 2016 [Page 17]
>
>
> Internet-Draft Attack Model for Certificate Mis-issuance May 2016
>
>
> 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.
It also depends on what bogus EE certificates are issued, and (arguably)
whether or not any of the logs reject certificate chains with
known-revoked CAs in them. Of course, if the logs start doing that kind
of rejection, then log operators become required to act as meta-CAs,
which i believe is a rather radical departure from the story we've told
about logs in the past.
> 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.
Again, the EE cert is actually the same cert; the "second CA" is the
doppelganger.
> 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.
This would be better as:
Even if the bogus EE certificate contains 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.)
Does this mean that monitors should raise flags for EE certs missing AIA
extensions which identify an OCSP server? If so, is anyone doing this
check? What action should be taken if this is found missing?
> 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.
This represents a separate and distinct CA key compromise from the
original described attack, since the OSCP responder is often a separate
key. I think this muddies the waters when trying to describe the
"dual-CA compromise".
More broadly, this seems like a discussion about failings in the
revocation infrastructure, which might itself be out-of-scope for CT. A
separate document that collates all the failings of revocation would be
interesting and useful, but shoehorning it into this section might be a
mistake.
> 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.
Again, i don't think "doppelganger" should be used here. I think this
refers to the "bogus EE certificate", so please use that term.
> 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.
Again, this is a separate compromise, and i think it muddies the waters.
> (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.)
I think this is correct, but i'm not sure it belongs in this section.
> 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.
I think this is the most-relevant bit of this section. Some revocation
mechanisms depend on the *path*, not just on the EE cert and signing
subkey.
Perhaps it would make more sense to enumerate those revocation
mechanisms that are path-reliant (and therefore vulnerable to this
colluding-CA hiding attack):
a) any blocklist mechanism (like CRLsets) that sometimes blocks
intermediate CA certificates without also including a full explicit
blocklist of all known child certs of the blocked intermediate CA.
b) relying parties which depend on identifying OCSP or CRL or other
revocation mechanisms in the issuing certificate, rather than in the
end-entity certificate.
> 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.
The attack that fails for path-independent revocation mechanisms is use
the bogus, known-revoked EE certificates.
But the other attack (the hidden, secondary CA compromise) is still not
discovered by CT in this case.
> 3.3.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.
This last sentence is missing an "of".
> 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.
Should we instead recommend "relying parties capable of blocking
known-malicious intermediate CAs should enumerate these entities by
public key" ? This doesn't entirely solve the problem (two conspiring
CAs can create an unlimited number of doppelganger CA pairs), but it's
certainly better than blocking intermediate CAs by full certificate or
by issuer+serialnumber.
Sorry that describing this attack has proved so complex. I think the
complexity is due to the complexity of the overall ecosystem (including
PKIX, X.509, CAs, logs, browsers, revocation mechanisms, etc). the
simpler we can make things the better.
Regards,
--dkg
signature.asc
Description: PGP signature
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
