internet-drafts | 27 May 14:40 2016
Picon

[Trans] I-D Action: draft-ietf-trans-rfc6962-bis-16.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public Notary Transparency  of the IETF.

        Title           : Certificate Transparency
        Authors         : Ben Laurie
                          Adam Langley
                          Emilia Kasper
                          Eran Messeri
                          Rob Stradling
	Filename        : draft-ietf-trans-rfc6962-bis-16.txt
	Pages           : 52
	Date            : 2016-05-27

Abstract:
   This document describes a protocol for publicly logging the existence
   of Transport Layer Security (TLS) certificates as they are issued or
   observed, in a manner that allows anyone to audit certification
   authority (CA) activity and notice the issuance of suspect
   certificates as well as to audit the certificate logs themselves.
   The intent is that eventually clients would refuse to honor
   certificates that do not appear in a log, effectively forcing CAs to
   add all issued certificates to the logs.

   Logs are network services that implement the protocol operations for
   submissions and queries that are defined in this document.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-trans-rfc6962-bis/

(Continue reading)

Melinda Shore | 26 May 23:15 2016
Picon

[Trans] Starting working group last call, draft-ietf-trans-rfc6962-bis

This is to announce the beginning of working group last call
for draft-ietf-trans-rfc6962-bis.  The purpose of working group
last call is to establish working group consensus that the
document is ready for publication.

Please give the draft a thorough review and post comments to
this mailing list.  Document review is one of the most significant
contributions you can make to the work of the IETF, and we
encourage newer participants who've never done a document review
before to join in (if you've got questions about how to review
a document, please contact Paul or me directly).

The URL for the draft is:
https://datatracker.ietf.org/doc/draft-ietf-trans-rfc6962-bis/

Last call closes in three weeks, on June 16, at 23:59 GMT.

Many thanks for all the work done so far, and for the reviews
yet to come.

Melinda & Paul
internet-drafts | 26 May 17:24 2016
Picon

[Trans] I-D Action: draft-ietf-trans-rfc6962-bis-15.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public Notary Transparency  of the IETF.

        Title           : Certificate Transparency
        Authors         : Ben Laurie
                          Adam Langley
                          Emilia Kasper
                          Eran Messeri
                          Rob Stradling
	Filename        : draft-ietf-trans-rfc6962-bis-15.txt
	Pages           : 54
	Date            : 2016-05-26

Abstract:
   This document describes a protocol for publicly logging the existence
   of Transport Layer Security (TLS) certificates as they are issued or
   observed, in a manner that allows anyone to audit certification
   authority (CA) activity and notice the issuance of suspect
   certificates as well as to audit the certificate logs themselves.
   The intent is that eventually clients would refuse to honor
   certificates that do not appear in a log, effectively forcing CAs to
   add all issued certificates to the logs.

   Logs are network services that implement the protocol operations for
   submissions and queries that are defined in this document.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-trans-rfc6962-bis/

(Continue reading)

Stephen Kent | 20 May 20:11 2016
Picon

[Trans] responses to your threat analysis review comments

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 3rd party Monitor is malicious, but I agree that there is no significant difference when the 3rd 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 3rd 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” again  such 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.

 

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.

 

<!-- /* Font Definitions */ <at> font-face {font-family:Arial; panose-1:2 11 6 4 2 2 2 2 2 4; mso-font-charset:0; mso-generic-font-family:auto; mso-font-pitch:variable; mso-font-signature:3 0 0 0 1 0;} <at> font-face {font-family:"Courier New"; panose-1:2 7 3 9 2 2 5 2 4 4; mso-font-charset:0; mso-generic-font-family:auto; mso-font-pitch:variable; mso-font-signature:3 0 0 0 1 0;} <at> font-face {font-family:Times; panose-1:2 0 5 0 0 0 0 0 0 0; mso-font-charset:0; mso-generic-font-family:auto; mso-font-pitch:variable; mso-font-signature:3 0 0 0 1 0;} <at> font-face {font-family:"MS 明朝"; panose-1:0 0 0 0 0 0 0 0 0 0; mso-font-charset:128; mso-generic-font-family:roman; mso-font-format:other; mso-font-pitch:fixed; mso-font-signature:1 134676480 16 0 131072 0;} <at> font-face {font-family:"MS 明朝"; panose-1:0 0 0 0 0 0 0 0 0 0; mso-font-charset:128; mso-generic-font-family:roman; mso-font-format:other; mso-font-pitch:fixed; mso-font-signature:1 134676480 16 0 131072 0;} <at> font-face {font-family:Cambria; panose-1:2 4 5 3 5 4 6 3 2 4; mso-font-charset:0; mso-generic-font-family:auto; mso-font-pitch:variable; mso-font-signature:3 0 0 0 1 0;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {mso-style-unhide:no; mso-style-qformat:yes; mso-style-parent:""; margin:0in; margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:12.0pt; mso-bidi-font-size:10.0pt; font-family:Cambria; mso-ascii-font-family:Cambria; mso-ascii-theme-font:minor-latin; mso-fareast-font-family:"MS 明朝"; mso-fareast-theme-font:minor-fareast; mso-hansi-font-family:Cambria; mso-hansi-theme-font:minor-latin; mso-bidi-font-family:"Times New Roman"; mso-bidi-theme-font:minor-bidi; mso-fareast-language:JA;} p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph {mso-style-priority:34; mso-style-unhide:no; mso-style-qformat:yes; margin-top:0in; margin-right:0in; margin-bottom:0in; margin-left:.5in; margin-bottom:.0001pt; mso-add-space:auto; mso-pagination:widow-orphan; font-size:12.0pt; mso-bidi-font-size:10.0pt; font-family:Cambria; mso-ascii-font-family:Cambria; mso-ascii-theme-font:minor-latin; mso-fareast-font-family:"MS 明朝"; mso-fareast-theme-font:minor-fareast; mso-hansi-font-family:Cambria; mso-hansi-theme-font:minor-latin; mso-bidi-font-family:"Times New Roman"; mso-bidi-theme-font:minor-bidi; mso-fareast-language:JA;} p.MsoListParagraphCxSpFirst, li.MsoListParagraphCxSpFirst, div.MsoListParagraphCxSpFirst {mso-style-priority:34; mso-style-unhide:no; mso-style-qformat:yes; mso-style-type:export-only; margin-top:0in; margin-right:0in; margin-bottom:0in; margin-left:.5in; margin-bottom:.0001pt; mso-add-space:auto; mso-pagination:widow-orphan; font-size:12.0pt; mso-bidi-font-size:10.0pt; font-family:Cambria; mso-ascii-font-family:Cambria; mso-ascii-theme-font:minor-latin; mso-fareast-font-family:"MS 明朝"; mso-fareast-theme-font:minor-fareast; mso-hansi-font-family:Cambria; mso-hansi-theme-font:minor-latin; mso-bidi-font-family:"Times New Roman"; mso-bidi-theme-font:minor-bidi; mso-fareast-language:JA;} p.MsoListParagraphCxSpMiddle, li.MsoListParagraphCxSpMiddle, div.MsoListParagraphCxSpMiddle {mso-style-priority:34; mso-style-unhide:no; mso-style-qformat:yes; mso-style-type:export-only; margin-top:0in; margin-right:0in; margin-bottom:0in; margin-left:.5in; margin-bottom:.0001pt; mso-add-space:auto; mso-pagination:widow-orphan; font-size:12.0pt; mso-bidi-font-size:10.0pt; font-family:Cambria; mso-ascii-font-family:Cambria; mso-ascii-theme-font:minor-latin; mso-fareast-font-family:"MS 明朝"; mso-fareast-theme-font:minor-fareast; mso-hansi-font-family:Cambria; mso-hansi-theme-font:minor-latin; mso-bidi-font-family:"Times New Roman"; mso-bidi-theme-font:minor-bidi; mso-fareast-language:JA;} p.MsoListParagraphCxSpLast, li.MsoListParagraphCxSpLast, div.MsoListParagraphCxSpLast {mso-style-priority:34; mso-style-unhide:no; mso-style-qformat:yes; mso-style-type:export-only; margin-top:0in; margin-right:0in; margin-bottom:0in; margin-left:.5in; margin-bottom:.0001pt; mso-add-space:auto; mso-pagination:widow-orphan; font-size:12.0pt; mso-bidi-font-size:10.0pt; font-family:Cambria; mso-ascii-font-family:Cambria; mso-ascii-theme-font:minor-latin; mso-fareast-font-family:"MS 明朝"; mso-fareast-theme-font:minor-fareast; mso-hansi-font-family:Cambria; mso-hansi-theme-font:minor-latin; mso-bidi-font-family:"Times New Roman"; mso-bidi-theme-font:minor-bidi; mso-fareast-language:JA;} .MsoChpDefault {mso-style-type:export-only; mso-default-props:yes; font-size:10.0pt; mso-ansi-font-size:10.0pt; mso-bidi-font-size:10.0pt; font-family:Cambria; mso-ascii-font-family:Cambria; mso-ascii-theme-font:minor-latin; mso-fareast-font-family:"MS 明朝"; mso-fareast-theme-font:minor-fareast; mso-hansi-font-family:Cambria; mso-hansi-theme-font:minor-latin; mso-bidi-font-family:"Times New Roman"; mso-bidi-theme-font:minor-bidi; mso-fareast-language:JA;} <at> page WordSection1 {size:8.5in 792.7pt; margin:1.0in 1.0in 1.0in 1.0in; mso-header-margin:.5in; mso-footer-margin:.5in; mso-paper-source:0;} div.WordSection1 {page:WordSection1;} /* List Definitions */ <at> list l0 {mso-list-id:313722978; mso-list-type:hybrid; mso-list-template-ids:-1164143446 67698711 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;} <at> list l0:level1 {mso-level-number-format:alpha-lower; mso-level-text:"%1\)"; mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in;} <at> list l0:level2 {mso-level-number-format:alpha-lower; mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in;} <at> list l0:level3 {mso-level-number-format:roman-lower; mso-level-tab-stop:none; mso-level-number-position:right; text-indent:-9.0pt;} <at> list l0:level4 {mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in;} <at> list l0:level5 {mso-level-number-format:alpha-lower; mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in;} <at> list l0:level6 {mso-level-number-format:roman-lower; mso-level-tab-stop:none; mso-level-number-position:right; text-indent:-9.0pt;} <at> list l0:level7 {mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in;} <at> list l0:level8 {mso-level-number-format:alpha-lower; mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in;} <at> list l0:level9 {mso-level-number-format:roman-lower; mso-level-tab-stop:none; mso-level-number-position:right; text-indent:-9.0pt;} ol {margin-bottom:0in;} ul {margin-bottom:0in;} -->
_______________________________________________
Trans mailing list
Trans <at> ietf.org
https://www.ietf.org/mailman/listinfo/trans
Stephen Kent | 16 May 21:54 2016
Picon

[Trans] I'm baaaaack

I've just returned from a month-long vacation and working my way through 
about 3K messages.

I see that Ben has provided comments on the latest version of the threat 
analysis. I
plan to read his comments and respond later this week.

Steve
Daniel Kahn Gillmor | 5 May 00:12 2016
Picon

[Trans] evaluating an SCT in the absence of the cert's issuer key

hey folks--

Why aren't we explicitly including the issuer_hash in the
SignedCertificateTimestampDataV2 object?

i notice that someone who has only:

 a) an X.509 end-entity certificate and
 b) what appears to be a corresponding SCT

Can't actually evaluate the validity of the log signature on the SCT
over the certificate.  This missing data is the hash of the issuer's
public key, which is included in the signed material but isn't otherwise
available from either (a) or (b).

(i'm assuming here that (b) is a TransItem with versioned_type set to
either x509_sct_v2(3) or precert_sct_v2(4), with data set to a
SignedCertificateTimestampDataV2)

I understand that adding the issuer_hash will increase the size of the
SCT by 32 octets, but without that information, someone evaluating the
SCT has no way of knowing whether it is legitimate.

In the TLS handshake case, it's likely that the TLS client can compute
the issuer_hash by extracting the SPKI from the next cert in the offered
x.509 chain.  But in other cases (e.g. auditing, gossiping), there's no
guarantee that the issuer cert (or issuer public key) is going to be
passed alongside the SCT.

Do we want to require people to pass the issuer cert (or issuer public
key?) alongside the cert in order to be able to verify the signature on
an SCT?  If so, where is the best place to document that concern?

Or have i misunderstood the data structures?  I'm working from
https://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis-14

the issuer key hash was re-introduced here, i think:

 https://trac.tools.ietf.org/wg/trans/trac/ticket/80

but there's no consideration there for how validators are expected to
function in the absence of the full chain.

Any thoughts?

   --dkg
_______________________________________________
Trans mailing list
Trans <at> ietf.org
https://www.ietf.org/mailman/listinfo/trans
Daniel Kahn Gillmor | 26 Apr 21:13 2016
Picon

[Trans] STHExtension expression

in rfc6962-bis-14, both the TreeHeadDataV2 (section 5.7) and
SignedTreeHeadDataV2 (section 5.8) structures have an SthExtensions
member.  The SignedTreeHeadDataV2 structure itself contains a
digitally-signed struct "signature" that contains a TransItem
merkle_tree_head which is constrained to be a TreeHeadDataV2.

  https://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis-14

I'm assuming that the the implication here is that
SignedTreeHeadDataV2.signature.merkel_tree_head is not expected to be
literally included in the bytestream, or else we'd have two copies of
the sth_extensions field in the SignedTreeHeadDataV2, which i don't
think we want.

But the specification of whether SthExtensions are present is unclear.
in the STHv2 description, it says:

       enum {
           reserved(65535)
       } SthExtensionType;

       struct {
           SthExtensionType sth_extension_type;
           opaque sth_extension_data<0..2^16-1>;
       } SthExtension;

       struct {
           LogID log_id;
           uint64 timestamp;
           uint64 tree_size;
           NodeHash root_hash;
           SthExtension sth_extensions<0..2^16-1>;
           digitally-signed struct {
               TransItem merkle_tree_head;
           } signature;
       } SignedTreeHeadDataV2;

 [...]

   "sth_extensions" is a vector of 0 or more STH extensions.  This
   vector MUST NOT include more than one extension with the same
   "sth_extension_type".  The extensions in the vector MUST be ordered
   by the value of the "sth_extension_type" field, smallest value first.
   If an implementation sees an extension that it does not understand,
   it SHOULD ignore that extension.  Furthermore, an implementation MAY
   choose to ignore any extension(s) that it does understand.

This is not an "opaque" data type, so there is no indicator of the
number of extensions available in the bytestream.

Consider the case of zero extensions:

 log_id
 timestamp
 tree_size
 root_hash
 signature

and the case of one extension:

 log_id
 timestamp
 tree_size
 root_hash
 extension_0
 signature

if the start of the signature was mistakable for the start of an
SthExtension, then there is a potential for ambiguity.

This concatenated array representation is used in TreeHeadDataV2, as
well as in TLS 1.2 for client and server Extensions (a list of TLV
extensions at the tail of the Hello handshake message), and for
Certificate messages (a distinct and independent Certificate handshake
message).  But those uses have the advantage of an external frame
indicating the overall length of the repeated datatype.

I see four possible resolutions, none of which are that great; i'd be
happy with a better proposal:

(a) explicitly indicate the number of extensions to expect:

index ef69039..0b09171 100644
--- a/rfc6962-bis.xml
+++ b/rfc6962-bis.xml
 <at>  <at>  -654,6 +654,7  <at>  <at>  d0 d1   d2 d3           d0 d1   d2 d3  d4 d5</artwork>
         uint64 timestamp;
         uint64 tree_size;
         NodeHash root_hash;
+        uint8 extension_count;
         SthExtension sth_extensions&lt;0..2^16-1&gt;;
         digitally-signed struct {
             TransItem merkle_tree_head;

(b) If the size of the signature is guaranteed to be known or computable
    in advance, move the extensions to follow the signature, so that
    they're delimited by the size and framing of the STHv2 itself:

--- a/rfc6962-bis.xml
+++ b/rfc6962-bis.xml
 <at>  <at>  -654,10 +654,10  <at>  <at>  d0 d1   d2 d3           d0 d1   d2 d3  d4 d5</artwork>
         uint64 timestamp;
         uint64 tree_size;
         NodeHash root_hash;
-        SthExtension sth_extensions&lt;0..2^16-1&gt;;
         digitally-signed struct {
             TransItem merkle_tree_head;
         } signature;
+        SthExtension sth_extensions&lt;0..2^16-1&gt;;
     } SignedTreeHeadDataV2;</artwork>
         </figure>
         <t>

(c) If the size of the signature is guaranteed to be known or computable
    in advance, provide guidance on determining the signatures in a
    reverse scan:

--- a/rfc6962-bis.xml
+++ b/rfc6962-bis.xml
 <at>  <at>  -682,6 +682,12  <at>  <at>  d0 d1   d2 d3           d0 d1   d2 d3  d4 d5</artwork>
           <spanx style="verb">sth_extensions</spanx> is a vector of 0 or more STH extensions. This vector MUST NOT
include more than one extension with the same <spanx style="verb">sth_extension_type</spanx>. The
extensions in the vector MUST be ordered by the value of the <spanx
style="verb">sth_extension_type</spanx> field, smallest value first. If an implementation sees an
extension that it does not understand, it SHOULD ignore that extension. Furthermore, an implementation
MAY choose to ignore any extension(s) that it does understand.
         </t>
         <t>
+          To determine the size of the <spanx
+          style="verb">sth_extensions</spanx> field, subtract the
+          expected size of the <spanx style="verb">signature</spanx>
+          field from the size of the SignedTreeHeadDataV2 object.
+        </t>
+        <t>
           <spanx style="verb">merkle_tree_head</spanx> is a <spanx style="verb">TransItem</spanx>
structure that MUST be of type <spanx style="verb">tree_head_v2</spanx> (see <xref target="tree_head"/>).
         </t>
       </section>

(d) treat the signature as a very special-cased extension:

--- a/rfc6962-bis.xml
+++ b/rfc6962-bis.xml
 <at>  <at>  -628,7 +628,7  <at>  <at>  d0 d1   d2 d3           d0 d1   d2 d3  d4 d5</artwork>
           <spanx style="verb">root_hash</spanx> is the root of the Merkle Hash Tree.
         </t>
         <t>
-          <spanx style="verb">sth_extensions</spanx> matches the STH extensions of the corresponding STH.
+          <spanx style="verb">sth_extensions</spanx> matches the STH extensions of the corresponding STH,
with the "signature" extension removed.
         </t>
       </section>
       <section title="Signed Tree Head (STH)" anchor="STH">
 <at>  <at>  -641,7 +641,7  <at>  <at>  d0 d1   d2 d3           d0 d1   d2 d3  d4 d5</artwork>
           </preamble>
           <artwork>
     enum {
-        reserved(65535)
+        signature(65535)
     } SthExtensionType;

     struct {
 <at>  <at>  -655,9 +655,6  <at>  <at>  d0 d1   d2 d3           d0 d1   d2 d3  d4 d5</artwork>
         uint64 tree_size;
         NodeHash root_hash;
         SthExtension sth_extensions&lt;0..2^16-1&gt;;
-        digitally-signed struct {
-            TransItem merkle_tree_head;
-        } signature;
     } SignedTreeHeadDataV2;</artwork>
         </figure>
         <t>
 <at>  <at>  -682,6 +679,15  <at>  <at>  d0 d1   d2 d3           d0 d1   d2 d3  d4 d5</artwork>
           <spanx style="verb">sth_extensions</spanx> is a vector of 0 or more STH extensions. This vector MUST NOT
include more than one extension with the same <spanx style="verb">sth_extension_type</spanx>. The
extensions in the vector MUST be ordered by the value of the <spanx
style="verb">sth_extension_type</spanx> field, smallest value first. If an implementation sees an
extension that it does not understand, it SHOULD ignore that extension. Furthermore, an implementation
MAY choose to ignore any extension(s) that it does understand.
         </t>
         <t>
+          The extension of type "signature" is special, in that it
+          contains a signature made by the log as defined in <xref
+          target="signature_algorithms"/>, and it is omitted from the
+          data being signed.  The <spanx
+          style=verb">sth_extensions</spanx> field of a
+          SignedTreeHeadDataV2 MUST contain a "signature" extension as
+          the last extension.
+        </t>
+        <t>
           <spanx style="verb">merkle_tree_head</spanx> is a <spanx style="verb">TransItem</spanx>
structure that MUST be of type <spanx style="verb">tree_head_v2</spanx> (see <xref target="tree_head"/>).
         </t>
       </section>

Any suggestions on how to resolve this?

    --dkg
Melinda Shore | 26 Apr 21:08 2016
Picon

[Trans] IETF 96 planning

Hi, all:

At the moment it doesn't look like there's much on the
table[*], although we've got some pending work on gossip and
on logging other types of data (DNSSEC, blobs).  I'm
hopeful that we'll be making progress on both types of
documents and it's possible there will be issues that will
benefit from face-to-face discussion, so I'd like to go
ahead and request a 1-hour session, with the possibility
of cancelling it if we don't need it.  If you are planning
on asking for time on the agenda, please make sure that
there's been enough mailing list discussion of your draft
to identify what issues would benefit from in-person
conversation.

Melinda

[* the -bis document will be starting working group last call
shortly, and the threat document will restart working group
last call once Steve addresses Ben's comments.]
Ben Laurie | 19 Apr 14:57 2016
Picon

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

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


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.

_______________________________________________
Trans mailing list
Trans <at> ietf.org
https://www.ietf.org/mailman/listinfo/trans
internet-drafts | 14 Apr 19:35 2016
Picon

[Trans] I-D Action: draft-ietf-trans-threat-analysis-05.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public Notary Transparency  of the IETF.

        Title           : Attack Model and Threat for Certificate Transparency
        Author          : Stephen Kent
	Filename        : draft-ietf-trans-threat-analysis-05.txt
	Pages           : 31
	Date            : 2016-04-07

Abstract:
   This document describes an attack model and discusses threats for
   the Web PKI context in which security mechanisms to detect mis-
   issuance of web site certificates are being developed. The model
   provides an analysis of detection and remediation mechanisms for
   both syntactic and semantic mis-issuance. The model introduces an
   outline of attacks to organize the discussion. The model also
   describes the roles played by the elements of the Certificate
   Transparency (CT) system, to establish a context for the model.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-trans-threat-analysis/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-trans-threat-analysis-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-trans-threat-analysis-05

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
Stephen Kent | 14 Apr 15:55 2016
Picon

[Trans] slight timing whoops

We've been having trouble getting the -05 version of the threat analysis posted, so
my message about the changes that have been incorporated is a bit premature.

Here is the modified text:

Introduction, page 4:

 

   Certificate Revocations Lists (CRLs) [RFC5280] are the primary means

of
   certificate revocation established by IETF standards.

Unfortunately, most
   browsers do not make use of CRLs to check the

revocation status of certificates
   presented by a TLS Server

(Subject). Some browsers make use of Online
   Certificate  Status

Protocol (OCSP) data [RFC6960] as a standards-based alternative
   to

CRLs. If a certificate contains an Authority Information Access (AIA )
   extension [RFC5280], it directs a replying party to an OCSP server to
   which a request can be directed. This extension also may be used by a
   browser to request OCSP responses from a TLS server with which it is
   communicating [RFC6066, RFC6961].

   RFC 5280 does not require inclusion of an AIA extension in certificates,
   so a browser cannot assume that this extension will be present. The
   Certification Authority and Browser Forum (CABF) baseline requirements and
   extended validation guidelines do mandate inclusion of this extension in EE
   certificates (in conjunction with their certificate policies). (See
   https://cabforum.org for the most recent versions of these policies.)

   In addition to the revocation status data dissemination mechanisms specified
   by IETF standards, most browser vendors employ proprietary means of

   conveying certificate revocation status information to their products, e.g.,
   via a blacklist that enumerates revoked certificates (EE or CA).

  Such
   capabilities enable a browser vendor to cause browsers to

reject any
   certificates on the blacklist. This approach also can be employed to
   remedy mis-issuance.

  Throughout the remainder of this document references to
   certificate

revocation as a remedy encompass this and analogous forms of
   browser

behavior, if available. Note: there are no IETF standards that define
   browser blacklist mechanisms.

 

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

 

3.2.1.1.2. Benign third party Monitor

 

   If a benign third party monitor is checking the logs to which a

certificate was
   submitted and is protecting the targeted Subject, it

will detect the bogus certificate
   and will alert the Subject. The

Subject will then ask the CA to revoke the bogus
   certificate. As in

3.2.1.1.1, the CA may or may not revoke the certificate and it
   might revoke the  certificate but provide “good” OCSP responses to a targeted user
   (browser instance).


--------

<!-- /* Font Definitions */ <at> font-face {font-family:"MS 明朝"; panose-1:0 0 0 0 0 0 0 0 0 0; mso-font-alt:"Optima ExtraBlack"; mso-font-charset:128; mso-generic-font-family:roman; mso-font-format:other; mso-font-pitch:fixed; mso-font-signature:1 134676480 16 0 131072 0;} <at> font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4; mso-font-charset:0; mso-generic-font-family:auto; mso-font-pitch:variable; mso-font-signature:-536870145 1107305727 0 0 415 0;} <at> font-face {font-family:Cambria; panose-1:2 4 5 3 5 4 6 3 2 4; mso-font-charset:0; mso-generic-font-family:auto; mso-font-pitch:variable; mso-font-signature:-536870145 1073743103 0 0 415 0;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {mso-style-unhide:no; mso-style-qformat:yes; mso-style-parent:""; margin:0in; margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:12.0pt; mso-bidi-font-size:10.0pt; font-family:Cambria; mso-ascii-font-family:Cambria; mso-ascii-theme-font:minor-latin; mso-fareast-font-family:"MS 明朝"; mso-fareast-theme-font:minor-fareast; mso-hansi-font-family:Cambria; mso-hansi-theme-font:minor-latin; mso-bidi-font-family:"Times New Roman"; mso-bidi-theme-font:minor-bidi; mso-fareast-language:JA;} .MsoChpDefault {mso-style-type:export-only; mso-default-props:yes; font-size:10.0pt; mso-ansi-font-size:10.0pt; mso-bidi-font-size:10.0pt; font-family:Cambria; mso-ascii-font-family:Cambria; mso-ascii-theme-font:minor-latin; mso-fareast-font-family:"MS 明朝"; mso-fareast-theme-font:minor-fareast; mso-hansi-font-family:Cambria; mso-hansi-theme-font:minor-latin; mso-bidi-font-family:"Times New Roman"; mso-bidi-theme-font:minor-bidi; mso-fareast-language:JA;} <at> page WordSection1 {size:8.5in 792.7pt; margin:.75in .75in .75in .75in; mso-header-margin:0in; mso-footer-margin:.65in; mso-paper-source:0;} div.WordSection1 {page:WordSection1;} -->

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


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


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.


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

If the CA that logged the certificate does not revoke it, a browser vendor might enter the bogus certificate into a “blacklist”. Unfortunately, there are no IETF standards for such blacklists. Thus it is conceivable that the revocation status data also might be managed in a path-specific fashion. If that were true, then the attack could succeed. However, if a vendor maintains revocation status data in a path-independent fashion, then the attack will fail. For example, if revoked certificates are identified by CA name and serial number, or a hash of the certificate, this attack would fail.


3.2.2 Revocation of the Colluding CA Certificate


If the CA that logged the bogus certificate is viewed as acting maliciously, its parent might revoke that CA’s certificate. Even though the two colluding CAs have the same name and use the same public key, their certificates are distinct, e.g., they were issued by different parents and almost certainly have different certificate serial numbers. Thus revocation of the certificate of the CA that logged the bogus certificate does not affect the certificate of its colluding partner. In this case, the bogus EE certificate would be treated as valid when it appears in a certification path involving the second colluding CA. Thus revocation the certificate for the CA that was detected as malicious does not prevent this attack from succeeding.


A vendor also might choose to add the certificate of the CA that issued the bogus certificate to its blacklist, e.g., if that CA refuses to revoke the bogus certificate. This also may not prevent the bogus certificate from being accepted by a browser. For example, if the CA certificate blacklist entry is analogous to a CRL entry (Subject name of the parent of the malicious CA and the serial number of the malicious CA’s certificate), the colluding CA’s certificate would still be valid in this case.


<!-- /* Font Definitions */ <at> font-face {font-family:"MS 明朝"; panose-1:0 0 0 0 0 0 0 0 0 0; mso-font-alt:"Optima ExtraBlack"; mso-font-charset:128; mso-generic-font-family:roman; mso-font-format:other; mso-font-pitch:fixed; mso-font-signature:1 134676480 16 0 131072 0;} <at> font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4; mso-font-charset:0; mso-generic-font-family:auto; mso-font-pitch:variable; mso-font-signature:-536870145 1107305727 0 0 415 0;} <at> font-face {font-family:Cambria; panose-1:2 4 5 3 5 4 6 3 2 4; mso-font-charset:0; mso-generic-font-family:auto; mso-font-pitch:variable; mso-font-signature:-536870145 1073743103 0 0 415 0;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {mso-style-unhide:no; mso-style-qformat:yes; mso-style-parent:""; margin:0in; margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:12.0pt; mso-bidi-font-size:10.0pt; font-family:Cambria; mso-ascii-font-family:Cambria; mso-ascii-theme-font:minor-latin; mso-fareast-font-family:"MS 明朝"; mso-fareast-theme-font:minor-fareast; mso-hansi-font-family:Cambria; mso-hansi-theme-font:minor-latin; mso-bidi-font-family:"Times New Roman"; mso-bidi-theme-font:minor-bidi; mso-fareast-language:JA;} .MsoChpDefault {mso-style-type:export-only; mso-default-props:yes; font-size:10.0pt; mso-ansi-font-size:10.0pt; mso-bidi-font-size:10.0pt; font-family:Cambria; mso-ascii-font-family:Cambria; mso-ascii-theme-font:minor-latin; mso-fareast-font-family:"MS 明朝"; mso-fareast-theme-font:minor-fareast; mso-hansi-font-family:Cambria; mso-hansi-theme-font:minor-latin; mso-bidi-font-family:"Times New Roman"; mso-bidi-theme-font:minor-bidi; mso-fareast-language:JA;} <at> page WordSection1 {size:8.5in 792.7pt; margin:.75in .75in .75in .75in; mso-header-margin:0in; mso-footer-margin:.65in; mso-paper-source:0;} div.WordSection1 {page:WordSection1;} -->

-------

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

 

The compromised CA may not realize that the bogus certificate was issued by a malicious twin; one occurrence of this sort might be regarded as an error, and not cause the CA to transition to a new key pair. (This assumes that the bogus certificate does not contain an AIA or CRL DP extension that wrests control of revocation from the compromised CA.)  If the compromised CA does determine that its private key has been stolen, it may take some time to transition to a new key pair, and reissue certificates to all of its legitimate Subjects. Thus an attack of this sort may take a while to be remedied.

 

Also note that the malicious twin of the compromised CA may be capable of issuing its own CRL or OCSP responses, without changing any AIA/CRL DP data present in the targeted certificate. The revocation status data from the evil twin will appear as valid as those of the compromised CA. If the attacker has the ability to control the sources of revocation status data available to a targeted user (browser instance), then the user may not become aware of the attack.

 

A bogus certificate issued by the malicious CA will not match the SCT for the legitimate certificate, since they are not identical, e.g., at a minimum the private keys do not match.  Thus a CT-aware browser that rejects certificates without SCTs (see 3.1.2.2) will reject a bogus certificate created under these circumstances if it is not logged. If the bogus certificate is detected and logged, browsers that require an SCT will reject the bogus certificate.

 

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.

 

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

 

An Auditor checking for log consistency might conclude that the compromised log is acting maliciously, and is presenting a split view to its clients. 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.

 

 

 

 

 

 

 



<!-- /* Font Definitions */ <at> font-face {font-family:"MS 明朝"; panose-1:0 0 0 0 0 0 0 0 0 0; mso-font-alt:"Optima ExtraBlack"; mso-font-charset:128; mso-generic-font-family:roman; mso-font-format:other; mso-font-pitch:fixed; mso-font-signature:1 134676480 16 0 131072 0;} <at> font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4; mso-font-charset:0; mso-generic-font-family:auto; mso-font-pitch:variable; mso-font-signature:-536870145 1107305727 0 0 415 0;} <at> font-face {font-family:Cambria; panose-1:2 4 5 3 5 4 6 3 2 4; mso-font-charset:0; mso-generic-font-family:auto; mso-font-pitch:variable; mso-font-signature:-536870145 1073743103 0 0 415 0;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {mso-style-unhide:no; mso-style-qformat:yes; mso-style-parent:""; margin:0in; margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:12.0pt; mso-bidi-font-size:10.0pt; font-family:Cambria; mso-ascii-font-family:Cambria; mso-ascii-theme-font:minor-latin; mso-fareast-font-family:"MS 明朝"; mso-fareast-theme-font:minor-fareast; mso-hansi-font-family:Cambria; mso-hansi-theme-font:minor-latin; mso-bidi-font-family:"Times New Roman"; mso-bidi-theme-font:minor-bidi; mso-fareast-language:JA;} .MsoChpDefault {mso-style-type:export-only; mso-default-props:yes; font-size:10.0pt; mso-ansi-font-size:10.0pt; mso-bidi-font-size:10.0pt; font-family:Cambria; mso-ascii-font-family:Cambria; mso-ascii-theme-font:minor-latin; mso-fareast-font-family:"MS 明朝"; mso-fareast-theme-font:minor-fareast; mso-hansi-font-family:Cambria; mso-hansi-theme-font:minor-latin; mso-bidi-font-family:"Times New Roman"; mso-bidi-theme-font:minor-bidi; mso-fareast-language:JA;} <at> page WordSection1 {size:8.5in 792.7pt; margin:.75in .75in .75in .75in; mso-header-margin:0in; mso-footer-margin:.65in; mso-paper-source:0;} div.WordSection1 {page:WordSection1;} -->

_______________________________________________
Trans mailing list
Trans <at> ietf.org
https://www.ietf.org/mailman/listinfo/trans

Gmane