draft-ietf-trans-threat-analysis-09.txt   draft-ietf-trans-threat-analysis-10.txt 
Public Notary Transparency S. Kent Public Notary Transparency S. Kent
Internet-Draft BBN Technologies Internet-Draft BBN Technologies
Intended status: Informational September 18, 2016 Intended status: Informational October 18, 2016
Expires: March 22, 2017 Expires: April 21, 2017
Attack and Threat Model for Certificate Transparency Attack and Threat Model for Certificate Transparency
draft-ietf-trans-threat-analysis-09 draft-ietf-trans-threat-analysis-10
Abstract Abstract
This document describes an attack model and discusses threats for the This document describes an attack model and discusses threats for the
Web PKI context in which security mechanisms to detect mis-issuance Web PKI context in which security mechanisms to detect mis-issuance
of web site certificates are being developed. The model provides an of web site certificates are being developed. The model provides an
analysis of detection and remediation mechanisms for both syntactic analysis of detection and remediation mechanisms for both syntactic
and semantic mis-issuance. The model introduces an outline of and semantic mis-issuance. The model introduces an outline of
attacks to organize the discussion. The model also describes the attacks to organize the discussion. The model also describes the
roles played by the elements of the Certificate Transparency (CT) roles played by the elements of the Certificate Transparency (CT)
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 22, 2017. This Internet-Draft will expire on April 21, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions used in this document . . . . . . . . . . . . 7 1.1. Conventions used in this document . . . . . . . . . . . . 7
2. Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Semantic mis-issuance . . . . . . . . . . . . . . . . . . . . 9 3. Semantic mis-issuance . . . . . . . . . . . . . . . . . . . . 9
3.1. Non-malicious Web PKI CA context . . . . . . . . . . . . 9 3.1. Non-malicious Web PKI CA context . . . . . . . . . . . . 9
3.1.1. Certificate logged . . . . . . . . . . . . . . . . . 9 3.1.1. Certificate logged . . . . . . . . . . . . . . . . . 9
3.1.2. Certificate not logged . . . . . . . . . . . . . . . 11 3.1.2. Certificate not logged . . . . . . . . . . . . . . . 11
3.2. Malicious Web PKI CA context . . . . . . . . . . . . . . 12 3.2. Malicious Web PKI CA context . . . . . . . . . . . . . . 12
3.2.1. Certificate logged . . . . . . . . . . . . . . . . . 12 3.2.1. Certificate logged . . . . . . . . . . . . . . . . . 12
3.2.2. Certificate not logged . . . . . . . . . . . . . . . 14 3.2.2. Certificate not logged . . . . . . . . . . . . . . . 14
3.3. Undetected Compromise of CAs or Logs . . . . . . . . . . 14 3.3. Undetected Compromise of CAs or Logs . . . . . . . . . . 15
3.3.1. Compromised CA, Benign Log . . . . . . . . . . . . . 15 3.3.1. Compromised CA, Benign Log . . . . . . . . . . . . . 15
3.3.2. Benign CA, Compromised Log . . . . . . . . . . . . . 16 3.3.2. Benign CA, Compromised Log . . . . . . . . . . . . . 17
3.3.3. Compromised CA, Compromised Log . . . . . . . . . . . 17 3.3.3. Compromised CA, Compromised Log . . . . . . . . . . . 17
3.4. Attacks Based on Exploiting Multiple Certificate Chains . 18 3.4. Attacks Based on Exploiting Multiple Certificate Chains . 18
4. Syntactic mis-issuance . . . . . . . . . . . . . . . . . . . 20 3.5. Attacks Related to Distribution of Revocation Status . . 20
4.1. Non-malicious Web PKI CA context . . . . . . . . . . . . 20 4. Syntactic mis-issuance . . . . . . . . . . . . . . . . . . . 21
4.1. Non-malicious Web PKI CA context . . . . . . . . . . . . 21
4.1.1. Certificate logged . . . . . . . . . . . . . . . . . 21 4.1.1. Certificate logged . . . . . . . . . . . . . . . . . 21
4.1.2. Certificate not logged . . . . . . . . . . . . . . . 23 4.1.2. Certificate not logged . . . . . . . . . . . . . . . 23
4.2. Malicious Web PKI CA context . . . . . . . . . . . . . . 23 4.2. Malicious Web PKI CA context . . . . . . . . . . . . . . 23
4.2.1. Certificate logged . . . . . . . . . . . . . . . . . 23 4.2.1. Certificate logged . . . . . . . . . . . . . . . . . 24
4.2.2. Certificate is not logged . . . . . . . . . . . . . . 24 4.2.2. Certificate is not logged . . . . . . . . . . . . . . 25
5. Issues Applicable to Sections 3 and 4 . . . . . . . . . . . . 25 5. Issues Applicable to Sections 3 and 4 . . . . . . . . . . . . 25
5.1. How does a Subject know which Monitor(s) to use? . . . . 25 5.1. How does a Subject know which Monitor(s) to use? . . . . 25
5.2. How does a Monitor discover new logs? . . . . . . . . . . 25 5.2. How does a Monitor discover new logs? . . . . . . . . . . 25
5.3. CA response to report of a bogus or erroneous certificate 25 5.3. CA response to report of a bogus or erroneous certificate 26
5.4. Browser behavior . . . . . . . . . . . . . . . . . . . . 26 5.4. Browser behavior . . . . . . . . . . . . . . . . . . . . 26
5.5. Remediation for a malicious CA . . . . . . . . . . . . . 26 5.5. Remediation for a malicious CA . . . . . . . . . . . . . 26
5.6. Auditing - detecting misbehaving logs . . . . . . . . . . 26 5.6. Auditing - detecting misbehaving logs . . . . . . . . . . 27
6. Security Considerations . . . . . . . . . . . . . . . . . . . 28 6. Security Considerations . . . . . . . . . . . . . . . . . . . 28
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
9.1. Normative References . . . . . . . . . . . . . . . . . . 28 9.1. Normative References . . . . . . . . . . . . . . . . . . 29
9.2. Informative References . . . . . . . . . . . . . . . . . 29 9.2. Informative References . . . . . . . . . . . . . . . . . 29
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 30 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 30
1. Introduction 1. Introduction
Certificate transparency (CT) is a set of mechanisms designed to Certificate transparency (CT) is a set of mechanisms designed to
detect, deter, and facilitate remediation of certificate mis- detect, deter, and facilitate remediation of certificate mis-
issuance. The term certificate mis-issuance is defined here to issuance. The term certificate mis-issuance is defined here to
encompass violations of either semantic or syntactic constraints. encompass violations of either semantic or syntactic constraints.
The fundamental semantic constraint for a certificate is that it was The fundamental semantic constraint for a certificate is that it was
skipping to change at page 19, line 36 skipping to change at page 20, line 7
However, CA certificate 2 does not appear in any logs, and CA A is However, CA certificate 2 does not appear in any logs, and CA A is
unaware that CA B has issued a certificate to the malicious CA. Thus unaware that CA B has issued a certificate to the malicious CA. Thus
those who detected the malicious behavior may not discover the second those who detected the malicious behavior may not discover the second
chain and so may not alert CA B or browser vendors of the need to chain and so may not alert CA B or browser vendors of the need to
revoke/blacklist CA certificate 2. In this case, targeted browsers revoke/blacklist CA certificate 2. In this case, targeted browsers
would continue to accept the bogus certificates issued by the would continue to accept the bogus certificates issued by the
malicious CA, since the certificate chain they are provided is valid malicious CA, since the certificate chain they are provided is valid
and because the SCT issued for the bogus certificate it the same and because the SCT issued for the bogus certificate it the same
irrespective of which certificate chain is presented. irrespective of which certificate chain is presented.
The bogus certificate will appear valid to a browser because 3.5. Attacks Related to Distribution of Revocation Status
A bogus certificate that has been revoked may still appear valid to a
browser under certain circumstances. In part this is because
certificate revocation generally depends on the certificate path certificate revocation generally depends on the certificate path
(chain) used by a relying party when validating a certificate. This (chain) used by a relying party when validating a certificate. This
is true irrespective of whether revocation is effected via use of a is true irrespective of whether revocation is effected via use of a
CRL or OCSP. Moreover, an attacker can steer a browser to specific CRL or OCSP. Additionally, an attacker can steer a browser to
revocation status data via various means. specific revocation status data via various means, preventing a
targeted browser from acquiring accurate revocation status
information for a bogus certificate.
The bogus certificate might contain an AIA extension pointing to an The bogus certificate might contain an AIA extension pointing to an
OCSP server controlled by the malicious CA (or the attacker). As OCSP server controlled by the malicious CA (or the attacker). As
noted in Section 3.2.1.1.1, the malicious CA could send a "good" OCSP noted in Section 3.2.1.1.1, the malicious CA could send a "good" OCSP
response to a targeted browser instance, even if other parties are response to a targeted browser instance, even if other parties are
provided with a "revoked" response. A TLS server can supply an OCSP provided with a "revoked" response. A TLS server can supply an OCSP
response to a browser as part of the TLS handshake [RFC6961], if 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 requested by the browser. A TLS server posing as the entity named in
the bogus certificate also could acquire a "good" OCSP response from the bogus certificate also could acquire a "good" OCSP response from
the malicious CA to effect the attack. Only if the browser relies the malicious CA to effect the attack. Only if the browser relies
skipping to change at page 20, line 21 skipping to change at page 20, line 45
certificate from targeted browser instances. This is analogous to a certificate from targeted browser instances. This is analogous to a
split-view attack effected by a CT log. However, as noted in 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 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 detecting inconsistent reporting of certificate revocation status
data. (Monitoring in the CT context tracks log entries made by CAs data. (Monitoring in the CT context tracks log entries made by CAs
or Subjects. Auditing is designed to detect misbehavior by logs, not or Subjects. Auditing is designed to detect misbehavior by logs, not
by CAs per se.) by CAs per se.)
The failure of a bogus certificate to be detected as revoked (by a The failure of a bogus certificate to be detected as revoked (by a
browser) is not the fault of CT. In the class of attacks described browser) is not the fault of CT. In the class of attacks described
here, CT achieves its goal of detecting the bogus certificate when above, CT achieves its goal of detecting the bogus certificate when
that certificate is logged and a Monitor observes the log entry. that certificate is logged and a Monitor observes the log entry.
Detection is intended to trigger revocation, to effect remediation, Detection is intended to trigger revocation, to effect remediation,
the details of which are outside the scope of CT. However the SCT the details of which are outside the scope of CT. However the SCT
mechanism is intended to assure a relying party that certificate has mechanism is intended to assure a relying party that certificate has
been logged, is susceptible to being detected as bogus by a Monitor, been logged, is susceptible to being detected as bogus by a Monitor,
and presumably will be revoked if detected as such. In the context and presumably will be revoked if detected as such. In the context
of these attacks, because of the way revocation may be implemented, of these attacks, because of the way revocation may be implemented,
the assurance provided by the SCT may not have the anticipated the assurance provided by the SCT may not have the anticipated
effect. effect.
skipping to change at page 28, line 36 skipping to change at page 29, line 9
architecture addresses these attacks. architecture addresses these attacks.
7. IANA Considerations 7. IANA Considerations
None. None.
8. Acknowledgments 8. Acknowledgments
The author would like to thank David Mandelberg and Karen Seo for The author would like to thank David Mandelberg and Karen Seo for
their assistance in reviewing and preparing this document, and other their assistance in reviewing and preparing this document, and other
members of the TRANS working group for reviewing it. Much of the members of the TRANS working group for reviewing it. Most of the
text of Section 3.4 was provided by David Cooper, motivated by text of Section 3.4 was provided by David Cooper, motivated by
observations from Daniel Kahn Gilmor. observations from Daniel Kahn Gilmor.
9. References 9. References
9.1. Normative References 9.1. Normative References
[I-D.kent-trans-architecture] [I-D.kent-trans-architecture]
Kent, S., Mandelberg, D., and K. Seo, "Certificate Kent, S., Mandelberg, D., and K. Seo, "Certificate
Transparency (CT) System Architecture", draft-kent-trans- Transparency (CT) System Architecture", draft-kent-trans-
skipping to change at page 30, line 14 skipping to change at page 30, line 36
Author's Address Author's Address
Stephen Kent Stephen Kent
BBN Technologies BBN Technologies
10 Moulton Street 10 Moulton Street
Cambridge, MA 02138 Cambridge, MA 02138
USA USA
Phone: +1 (617) 873-3988 Phone: +1 (617) 873-3988
Email: skent@bbn.com Email: kent@alum.mit.edu
 End of changes. 16 change blocks. 
21 lines changed or deleted 27 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/