Subject: [Trans] responses to your threat analysis review comments

From: Stephen Kent <[email-masked]>
Date: Fri, 20 May 2016 14:11:54 -0400

Ben,

Thanks for taking the time to perform a thorough review of this doc.

I have made a number of edits in response to your comments, as described 
below.

Page 3

First para ends with a spurious ")".

*Fixed*

There are two classes of beneficiaries of CT: certificate Subjects

   and relying parties (RPs). In the initial focus context of CT, the
   Web PKI, Subjects are web sites and RPs are browsers employing HTTPS
   to access these web sites.

CAs are also beneficiaries - they get to find out about key loss or 
abuse of their platform, for example.

*Good point. I’ll change the text accordingly.***

it directs a replying party to an OCSP

   server

Should be "relying".

*Fixed*

Page 4

Finally, if an RP were to check logs for
   individual certificates, that would disclose to logs the identity of
   web sites being visited by the RP, a privacy violation. Thus this
   attack model assumes that RPs will not check log entries.

It is not clear that:

a)All RPs care about privacy in this respect,

*True, but it is still appropriate to note that log checking is a 
potential privacy violation for those that do perform checks, as DKG 
noted a while ago.*

b)That checking logs is necessarily privacy violating (for example, 
we've announced an experimental DNS-based protocol for log checking, 
which we are implementing in Chrome),

*The mechanism you describe minimizes the privacy problem, but since it 
is not part of the standard, it is not appropriate to assume it will be 
used by all RPs that confirm to the standard.*

therefore it seems unwarranted to assume that RPs will not check log 
entries.

*I have modified the sentence a bit to address your comments:*

*Thus this attack model does not assume that all RPs will check log 
entries.***

Page 5

There is no
   agreed-upon Audit function design for CT at the time of this
   writing. As a result, the model merely notes where Auditing is
   needed to detect certain classes of attacks.

Section 9.4 of 6962-bis-14 has a comprehensive design for auditing.

*I revised the text to note that the audit functions we enumerated in 
our spec for a CT auditor have now been defined. They don't seem to be 
“comprehensive” i.e., they don’t detect split log views, so the fact 
that there additional work on auditing is ongoing also is noted.*

Page 6

[ 4] SCT (embedded in pre-cert, if applicable)

SCTs are not embedded in pre-certs.

*Fixed the legend to refer to certificates, not pre-certificates.*

Page 8

Spoofing
   enables an adversary to acquire information that a TLS-enabled
   client would not communicate if the client were aware of the
   spoofing.

There are surely many other issues with spoofing - e.g. serving malware.

*Fair point. I have revised the text to note delivery of malware, or 
delivery of misinformation from a website as well.*

An adversary
   may achieve this in various ways, e.g., by causing a user to click
   on a link to the website, or by manipulation of the DNS response
   sent to a TLS client.

If a link alone works, then the site is not spoofed with a mis-issued 
certificate, surely?

*Good point. I removed the reference to clicking on a bogus link.*

Also, MitM is probably the most common attack vector.

*Maybe a user in a public WiFi context is susceptible to this sort of 
attack, but in many contexts a MITM attack is difficult to mount. 
Nonetheless, I will add MITM as an example here.*

The elements of CT may themselves be targets of attacks, as
   described below. A criminal organization might compromise a CA and
   cause it to issue bogus certificates, or it may exert influence over
   a CA (or CA staff) to do so, e.g., through extortion or physical
   threat. (Even though the CA is not intentionally malicious in this
   case, the action is equivalent to a malicious CA, hence the use of
   the term "bogus" here.) A nation state may operate or influence a CA
   that is part of the large set of "root CAs" in browsers. A CA,
   acting in this fashion, is termed a "malicious" CA. A nation state
   also might compromise a CA in another country, to effect issuance of
   bogus certificates. In this case the (non-malicious) CA, upon
   detecting the compromise (perhaps because of CT) is expected to work
   with Subjects to remedy the mis-issuance.

There's also social engineering, which is mentioned elsewhere, but I 
suspect should be here, too.

*I added a mention of social engineering here.*

It seems unlikely that a
   compromised, non-malicious, log would...

This seems odd - a compromised non-malicious log is effectively 
uncompromised, isn't it?

*If the log’s private key has been stolen so that an adversary can use 
the key to generate SCTs, then the log is compromised in that sense, 
even though it is not malicious.*

Page 9.

CT is not designed to
   detect and counter this type of locally-authorized interception.

Actually CT is designed to detect it but it seems likely that browsers 
will explicitly ignore it.

*I added this text in response to a message from Eran, but I have 
revised to text to not mention detection._*

Page 10.

(and elsewhere) is there really any difference between a benign 
third-part monitor and self-monitoring? Couldn't the doc be simplified 
by treating them as the same?

*The taxonomy adopted for this document distinguishes between benign and 
malicious versions of CT system elements. When a Subject monitors its 
own behalf, that distinction does not apply, i.e., a self monitor is 
always viewed as benign. This drives at least part of the distinction 
you note.*

(A misbehaving log also could create and report entries
   for bogus certificates that have not been issued by the indicated CA
   (hereafter called "fake")

This is slightly confusing, as on the face of it, the log could not 
create such a cert, since it doesn't have the CA key. Later wording 
makes it clear that the idea is that the cert would not, in fact, be 
signed by a trusted CA.

*I don't’ see a need to change the text here since, as you note, the 
next sentence explains that a fake entry would not be signed by the 
indicated CA.*

3.1.1.2.1/3.1.1.2.2

Since I think that benign third party and self monitors are essentially 
the same, it is odd that these two sections differ so much.

*They are not the same when the 3^rd party Monitor is malicious, but I 
agree that there is no significant difference when the 3^rd party 
Monitor is benign.I consolidated these two sections.*

Page 11.

Note that independent of any mis-issuance on the part of the CA, a
   misbehaving Monitor could issue false warnings to a Subject that it
   protects. These could cause the Subject to report non-existent
   semantic problems to the issuing CA and cause the CA to do needless
   investigative work or perhaps incorrectly revoke and re-issue the
   Subject's certificate.

This para is general, rather than to do with the section it is in, and 
hence should probably be somewhere else.

*The paragraph describes a type of behavior by a misbehaving 3^rd party 
Monitor, so it belongs in a section that has such a title.*

However, the CT architecture does not describe how
   such behavior by browsers can be deployed incrementally throughout
   the Internet. As a result, this attack model does not assume that
   browsers will reject a certificate that is not accompanied by an
   SCT.

Given that incremental deployment is already under way, this seems 
unnecessarily dogmatic.

*The text says that if a browser rejects a certificate because it lacks 
an SCT, then incremental deployment is problematic. Your assertion that 
CT is being incrementally deployed with respect to browsers is based on 
behavior that does not cause a certificate to be rejected under these 
circumstances.But, to make sure the issue is clear, I have revised the 
text as follows:*

**

*However, **the CT architecture does not describe **how CT can be 
deployed incrementally if browsers reject all certificates not 
accompanied by an SCT. (A browser might “discriminate” againsuch 
certificates, e.g. via warnings or other UI signals. Because a user 
would be free to ignore of override such indications, incremental 
deployment is possible under these assumptions.) As a result, this 
attack model does not assume that browsers will reject a certificate 
that is not accompanied by an SCT.***

Page 13.

For example, the CA could make excuses about inadequate
   proof that the certificate is bogus, or argue that it cannot quickly
   revoke the certificate because of legal concerns, etc. In this case,
   the CT mechanisms will have detected mis-issuance, but the
   information logged by CT does not help remedy the problem. (See
   Sections 4 and 6.)

The logged information clearly _helps_, it just may not be all that is 
needed.

*Fair point. I have modified the text to say “**the information logged 
by CT may not suffice to remedy the problem.”***

Page 14.

3.2.2.1 is essentially the same as 3.1.1.2, just refer to the previous text?

*I could do that, but it’s just one paragraph and I think it’s a bit 
easier for a reader to see the text in context rather than have to flip 
back to the earlier section.*

Page 15.

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.

The attack as described only requires colluding CAs in the case where EE 
certs do not contain links to revocation information.

When EE certs do contain such links, the attack described is simply an 
attack on certificate revocation, regardless of whether one or more CAs 
might have issued the doppelgangers.

In either case, the attack is nothing to do with CT, which does not 
claim to do anything to help with integrity or correctness of revocation 
information.

*The cited sentence notes that the goal of the attack is to cause a 
CT-aware browser to accept a certificate that, by CT goals, it ought 
not. In this sense, the attack is directly relevant to CT. I agree that 
the attack is one that exploits a residual vulnerability in revocation 
in general. However, this section describes the impact of that 
vulnerability in the context of CT, and thus seems relevant to the 
threat analysis.*

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.

All this is independent of the attack and of CT, and applies generally 
to revocation.

*See my rationale above for inclusion of this discussion.*

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

Likewise.

*Ibid.*

Page 20.

This will happen
   only if the log performs syntactic checks in general, and if the log
   is capable of performing the checks applicable to the submitted
   (pre-)certificate.

Anyone can detect syntactic mis-issuance, the log does not need to do it.

*The threat analysis focuses on what the CT system says its elements 
will do, not what some outside entity
not defined by the system might do.*

For example: https://crt.sh/?cablint=1+week 
<https://www.google.com/url?q=https://crt.sh/?cablint%3D1%2Bweek&sa=D&ust=1461067017647000&usg=AFQjCNHX_OatZkczH7TIIEeyYuTshcFzIg>.

Page 21.

If the (pre-)certificate is submitted by the non-malicious issuing
   CA, and if the CA has a record of the certificate content

Clearly there is a record in the log!

*Good point. I’ve revised the text accordingly.*

This analysis suggests that syntactic mis-issuance of a certificate
   can be avoided by a CA if it makes use of logs that are capable of
   performing these checks for the types of certificates that are
   submitted,

The CA can obviously perform these checks itself, logs are not special 
in this regard.

*This discussion is addressing the (not uncommon) situation in which a 
CA fails to perform the appropriate checks.Long ago you noted that this 
is a persistent problem and used that observation to justify the CT log 
language that provides leeway for a log to accept any certificate 
irrespective of whether it meets 5280 or any other certificate syntax 
criteria. So, it seems a bit disingenuous to suggest that a CA would be 
relied upon to perform these checks, in general.*

Throughout this section there is talk about syntactic checking by logs, 
which is not a defined function of logs.

*Syntax checking was proposed as an optional log function that you and 
your co-authors rejected. Thus this text notes that IF a log were to 
perform such checks, certain attacks could be detected on behalf of 
browsers (which also have a terrible track record of enforcing syntactic 
rules).*

Unfortunately, experience suggests that
   many browsers do not perform thorough syntactic checks on
   certificates, and so it seems unlikely that browsers will be a
   reliable way to detect erroneous certificates.

What is unfortunate is that a very large number of extant certs have 
syntax errors and so browsers can't usefully perform checks.

*I see we agree on this aspect of the problem. I am surprised that you 
noted that CAs could be relied upon to perform syntax checking (your 
comment above) given the reality that you cited here!*

Moreover, a protocol
   used by a browser to notify a Subject and/or CA of an erroneous
   certificate represents a DoS potential, and thus may not be
   appropriate.

Subjects are already subject to DoS by virtue of serving web pages. This 
doesn't seem like a valid concern.

*Adding additional DoS opportunities is rarely viewed as a good idea. 
The text says it “may not be appropriate” and I stand by that.*

Such browsers would benefit from
   having such checks performed by a log and reported in the SCT.

Browsers don't need help to perform syntax checks, it just isn't viable 
to do so.

*I have revised the text as follows:*

**

*Such browsers might benefit from having syntax checks performed by a 
log and reported in the SCT, although the pervasive nature of 
syntactically-defective certificates may limit the utility of such 
checks.***

Page 26.

Thus, for now, CT does not seem to provide a
   way to remedy this form of attack, even though it provides a basis
   for detecting such attacks.

CT doesn't claim to provide remedies for attacks, just information that 
reveals them. Once more, you are describing  a flaw with the whole 
system, not a flaw in CT.

*You’re right that CT does not claim to remedy attacks; it claims to 
facilitates remediation. So, I have revised the text as follows:*

**

*Thus, for now, CT does not seem to provide a way to facilitate 
remediation of this form of attack, even though it provides a basis for 
detecting such attacks.***

  Absent a well-defined mechanism that enables Monitors to verify that
   data from logs are reported in a consistent fashion, CT cannot claim
   to provide protection against logs that are malicious or may
   conspire with, or are victims of, attackers effecting certificate
   mis-issuance. The mechanism needs to protect the privacy of users
   with respect to which web sites they visit. It needs to scale to
   accommodate a potentially large number of self-monitoring Subjects
   and a vast number of browsers, if browsers are part of the
   mechanism. Even when an Audit mechanism is defined, it will be
   necessary to describe how the CT system will deal with a misbehaving
   or compromised log. For example, will there be a mechanism to alert
   all browsers to reject SCTs issued by such a log? Absent a
   description of a remediation strategy to deal with misbehaving or
   compromised logs, CT cannot ensure detection of mis-issuance in a
   wide range of scenarios.

The absence of a standard to do a thing does not make the thing 
impossible. In practice, none of this actually seems to be a problem, 
nor in need of standardisation at this time.

*6962-bis is targeted as a standard track document. Thus, when one 
evaluates the CT threat environment we should restrict our attention to 
what is standardized. We can’t speculate on behavior that MIGHT take 
place but is not specified in a standard, and cite that as a mitigating 
factor with respect to an attack or a privacy concern.*