Subject: [Trans] Comments on draft-ietf-trans-threat-analysis-05

From: Ben Laurie <[email-masked]>
Date: Tue, 19 Apr 2016 13:57:11 +0100

(looking at the TXT version)

Page 3

First para ends with a spurious ")".

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.

      it directs a replying party to an OCSP
  server

Should be "relying".

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,

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

therefore it seems unwarranted to assume that RPs will not 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.

Page 6

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

SCTs are not embedded in pre-certs.

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.

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?

Also, MitM is probably the most common attack vector.

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.

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

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

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.

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?

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

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.

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.

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.

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.

Page 14.

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

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.

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.

  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.

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.

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!

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.

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

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.

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.

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.

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.

 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.