Bryan,
Thanks for the thorough review of the sections of the sections of the doc
that I know are of greatest interest to you. I have made a number of edits
to address your comments, as noted below.
Steve
-----
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.)
Just a nitpick: in the parenthetical about “analogous to a log offering
split view", may be worth adding a forward-reference to the text below
(or just the words “described below”) containing the detailed discussion
of that class of attack?
*Fixed.*
3.3 Malicious, Colluding CAs
…
I agree with David Cooper that describing this as “two CAs” is rather
strange given the assumption that they have “the same Subject name and
public key”. I would call that “One Malicious CA with Two Certificate
Chains” or something like that.
*The issue here is whether we define CAs as identical based on their
names and public keys, or based on their location in a PKI, or based on
their physical instantiation, … . In the example I posed, the CAs are
distinct based on two of these three criteria. I’ve edited the text to
add a parenthetical discussion of this issue:*
**
*(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 above next never explicitly describes what the actual relevant
attack is, or why exactly “two trust anchors” make the attack back bad
and can foil the remediation procedures. It almost does, but not quite.
It needs to say something like, “The CA that logged the bogus
certificate may get detected and the certificate revoked via that trust
anchor, but the same certificate remains usable and un-revoked via the
other trust anchor through which the bogus certificate was not logged or
revoked.” Or something like that.
*The text you cited is part of describing the attack context, prior to
describing the attack per se.*
I guess the text in 3.3.1 does get to discussing this “main point", but
only after the reader has waded through the several paragraphs above,
without having (yet) been made aware of the whole reason for existence
of this whole section. It’s probably best to summarize the
attack/implications (and perhaps forward-reference the extended
discussion below) in one quick sentence toward the beginning of 3.3.
*The first paragraph of 3.3 describes the goal of the attack and, at a
top level how it is effected, which I think suffices. It says:*
**
*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.***
**
…
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
certificate cannot 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
It’s probably worth clarifying exactly how this is “apparent” and to
whom. e.g., something like, “also be apparent to anyone who checks the
certificate against the uncompromised log and finds the SCT missing”,
assuming that’s what you had in mind. Inferable, but just best to be
explicit.
*I have revised the paragraph to clarify what I had in mind:*
**
*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 and assuming that the bogus
certificate was not 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. However, the presence of
either of these extensions provides some evidence that an entity other
than the compromised CA issued the certificate in question. (If the
extensions differ from those in other certificates issued by the
compromised CA, that is suspicious.)*
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 revocation poses a problem. This is because
revocation of the bogus
nitpick: extra space between “revocation” and “poses"
*Fixed *
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.
Wait - isn’t the basic assumption of this section that the CA’s private
key has been stolen? And in that case, shouldn’t the CA’s public key
itself be revoked and considered untrustworthy, together with any
certificate the CA has signed in the past (or signs in the future) with
that key? It seems like even if there is a “legitimate certificate”
that was signed by the same key, it should get revoked too! If that’s
not the case, then the “why” needs to be clarified in the above
paragraph, and it needs to be stated in what situations a relying party
may still deem the “legitimate certificate” trustworthy despite being
signed by a compromised CA key.
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.
Although not quite as worrisome as other attacks in practice, there is a
DoS/censorship attack opportunity through equivocation here that might
be worth mentioning. In particular, the compromised log could provide
an SCT for a legitimate cert, and include the cert in a version of the
log it shows most people, but then the compromised log server (or an
evil twin of it) could send targeted relying parties a different log
history that doesn’t include the legitimate cert. As a result, a web
browser run by a targeted user will find the cert missing from the log
and inform the user that the web site may be insecure/compromised, thus
making the user (falsely) think the web site is broken rather than the
log server.
Of course, if the targeted user’s web browser can and does gossip STHs
with benign CT servers, the discrepancy between the log server’s two
histories will be detectable, and it will become known that the log
server is compromised. However, if the user’s web browser is unable to
gossip STHs with benign CT servers (e.g., because the only trusted
auditor(s) are blocked), or if the browser is unwilling to gossip STHs
for privacy reasons, or just doesn’t want the state/storage costs of
tracking and gossiping all log-servers’ STH histories, then the attack
might go undetected and the user might persistently think the web site
itself is compromised or just broken. This might actually be a behavior
desired by the attacker (effectively block the website but make the user
think it’s the website’s fault) in some state-censorship type scenarios.
*I have added the following paragraphs just before 3.4.3, to better
explain the impact of log compromise.*
**
*It is worth noting that if a benign CA was attacked and thus issued one
or more bogus certificates, then a colluding, malicious log might
provide split views of its log to help conceal the bogus certificate
from targeted users. Specifically, the log would show an accurate set of
log entries (and STHs) to most clients, but would maintain a separate
log view for targeted users. This sort of attack motivates the need for
Audit capabilities based on “gossiping” [gossip]. However, even if such
mechanisms are employed, they might be thwarted if a user is unable to
exchange log information with trustworthy partners.*
**
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
I would make it explicit here that the “evil twin CA” and the “evil twin
of a compromised log” are very likely to be one and the same, i.e., just
the attacker himself. Perhaps just “…of a compromised log (which may be
the same attacker)."
*I added a new, 2^nd paragraph to 3.4.3:*
**
*An attacker who compromises a log might act in one of two ways. It
might use the private key of the log only to generate SCTs for a
malicious CA or the evil twin of a compromised CA. If a browser checks
the signature on an SCT but does not contact a log to verify that the
certificate appears in the log, then this is an effective attack
strategy. Alternatively, the attacker might not only generate SCTs, but
also pose as the compromised log, at least with regard to requests from
targeted users. In the latter case, this “evil twin” log could respond
to STH requests from targeted users, making appear that the compromised
log was offering a split view (thus acting as a malicious log). To
detect this attack an Auditor needs to employ a gossip mechanism that is
able to acquire CT data from diverse sources, a feature not yet part of
the base CT system.*
**
*I revised the start of the next paragraph to say:*
*The evil twin CA might submit a bogus certificate to the evil twin of a
compromised log. (The same adversary may be controlling both.)*
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.
"Thorough checking" by whom, against what reference point?
*I revised the text to clarify what I had in mind.*
**
*However, an STH issued by the legitimate log will not correspond to a
tree (maintained by the compromised log) containing these SCTs. Thus
checking the SCTs issued by the evil twin log against STHs from the
compromised log will identify this discrepancy. As noted above, if an
attacker uses the key to generate log entries and respond to log
queries, like an evil twin CA, the effect is analogous to a malicious
log.)***
Here it is important to bring out the question (again) of whether the
relying party or parties targeted with this attack can, or do, gossip
with uncompromised CT entities in order to be able to do that
cross-checking.
*I believe the revised text cited above makes this clearer.*
If the compromised CA and compromised server are giving those bad certs
and bad SCTs to a large body of users, at least some of whom check STH
inclusion proofs and gossip regularly with uncompromised CT log servers,
auditors, or monitors, then they will likely be able to notice the
discrepancy fairly quickly. However, if the evil twin CA+log is
attacking only a few users in a much more targeted fashion, and is in
sufficient control of the target users’ external connectivity to prevent
them from gossiping with legitimate CT parties (or if the attacker
simply happens to know that those users are running software that
disable gossip for privacy reasons), then no one will ever have the
opportunity to notice the discrepancy. I think this really needs to be
made explicit.
An Auditor checking for log consistency might conclude that the
compromised log is acting maliciously, and is presenting a split view to
its clients.
How does this Auditor actually obtain both “views” of the compromised log?
*There are two views only if the attacker uses the purloined key to
generate a parallel log, not just generate SCTs. In this case an Auditor
will see that the bogus SCTs don’t fit into the tree maintained by the
compromised log.It might infer (incorrectly) that the log is malicious,
as the text says. I made a small change to the sentence to clarify this:*
**
*An Auditor checking for log consistency and with access to bogus SCTs,
might conclude that the compromised log is acting maliciously, and is
presenting a split view to its clients.***
If the Auditor is obtaining log records directly from the compromised
log server, then presumably the log server will send it only one of the
two views.
*Yes, if the Auditor has access only to the evil twin log,that’s right.
But, in that case, we’re back to the case of a malicious log.*
(Legitimate Auditors can be deceived through equivocation just as easily
as clients!) This text needs to specify under what conditions the
Auditor can notice the discrepancy: e.g., if it obtains one view from
the log server and learns about a different view via gossip with other
Auditors, Monitors, and/or relying parties that can and choose to gossip
with it.
*I revised the text to make this issue more explicit:*
*An Auditor checking for log consistency (relying on a gossip mechanism
to acquire log views from diverse sources) might conclude that the
compromised log is acting maliciously, and is presenting a split view to
its clients.***
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
