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.*
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
