Subject: Re: [Trans] slight timing whoops

From: Bryan Ford <[email-masked]>
Date: Thu, 19 May 2016 16:43:58 +0200

Hi Stephen,

Finally catching up on the latest version of your new threat analysis text...

On Apr 14, 2016, at 3:55 PM, Stephen Kent <[email-masked]> wrote:
> 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.)
> 
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?

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

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.

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

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.

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.

> 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.)
> 
> […]
> 
> -------
> 
> 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 issued  a 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 can  be 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 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.

> 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 revocation  poses a problem. This is because revocation of the bogus

nitpick: extra space between “revocation” and “poses"

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

> 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)."

> 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?  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.  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?  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.  (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.

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

Cheers
Bryan
> 
> _______________________________________________
> Trans mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/trans <https://www.ietf.org/mailman/listinfo/trans>

---

From: Stephen Kent <[email-masked]>
Date: Tue, 24 May 2016 11:15:35 -0400

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

…

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

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

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

**

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