draft-ietf-trans-threat-analysis-12.txt   draft-ietf-trans-threat-analysis-13.txt 
Public Notary Transparency S. Kent Public Notary Transparency S. Kent
Internet-Draft BBN Technologies Internet-Draft Independent
Intended status: Informational October 13, 2017 Intended status: Informational April 12, 2018
Expires: April 13, 2017 Expires: October 14, 2018
Attack and Threat Model for Certificate Transparency Attack and Threat Model for Certificate Transparency
draft-ietf-trans-threat-analysis-12 draft-ietf-trans-threat-analysis-13
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)
system, to establish a context for the model. system, to establish a context for the model.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 https://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 April 13, 2018. This Internet-Draft will expire on October 14, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2018 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 (https://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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
skipping to change at page 2, line 46 skipping to change at page 2, line 46
5.3. CA response to report of a bogus or erroneous certificate 26 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 . . . . . . . . . . 27 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 . . . . . . . . . . . . . . . . . . . . . . . 29 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
9.1. Normative References . . . . . . . . . . . . . . . . . . 29 9.1. Normative References . . . . . . . . . . . . . . . . . . 29
9.2. Informative References . . . . . . . . . . . . . . . . . 29 9.2. Informative References . . . . . . . . . . . . . . . . . 29
9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 30
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
issued to an entity that is authorized to represent the Subject (or issued to an entity that is authorized to represent the Subject (or
skipping to change at page 4, line 12 skipping to change at page 4, line 12
(AIA) extension [RFC5280], it directs a relying party to an OCSP (AIA) extension [RFC5280], it directs a relying party to an OCSP
server to which a request can be directed. This extension also may 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 be used by a browser to request OCSP responses from a TLS server with
which it is communicating [RFC6066][RFC6961]. which it is communicating [RFC6066][RFC6961].
RFC 5280 does not require inclusion of an AIA extension in RFC 5280 does not require inclusion of an AIA extension in
certificates, so a browser cannot assume that this extension will be certificates, so a browser cannot assume that this extension will be
present. The Certification Authority and Browser Forum (CABF) present. The Certification Authority and Browser Forum (CABF)
baseline requirements and extended validation guidelines do mandate baseline requirements and extended validation guidelines do mandate
inclusion of this extension in EE certificates (in conjunction with inclusion of this extension in EE certificates (in conjunction with
their certificate policies). (See https://cabforum.org for the most their certificate policies). (See https://cabforum.org [1] for the
recent versions of these policies.) most recent versions of these policies.)
In addition to the revocation status data dissemination mechanisms In addition to the revocation status data dissemination mechanisms
specified by IETF standards, most browser vendors employ proprietary specified by IETF standards, most browser vendors employ proprietary
means of conveying certificate revocation status information to their means of conveying certificate revocation status information to their
products, e.g., via a blacklist that enumerates revoked certificates products, e.g., via a blacklist that enumerates revoked certificates
(EE or CA). Such capabilities enable a browser vendor to cause (EE or CA). Such capabilities enable a browser vendor to cause
browsers to reject any certificates on the blacklist. This approach browsers to reject any certificates on the blacklist. This approach
also can be employed to remedy mis-issuance. Throughout the also can be employed to remedy mis-issuance. Throughout the
remainder of this document references to certificate revocation as a remainder of this document references to certificate revocation as a
remedy encompass this and analogous forms of browser behavior, if remedy encompass this and analogous forms of browser behavior, if
skipping to change at page 9, line 26 skipping to change at page 9, line 26
3.1. Non-malicious Web PKI CA context 3.1. Non-malicious Web PKI CA context
In this section, we address the case where the CA has no intent to In this section, we address the case where the CA has no intent to
issue a bogus certificate. issue a bogus certificate.
A CA may have mis-issued a certificate as a result of an error or, in A CA may have mis-issued a certificate as a result of an error or, in
the case of a bogus certificate, because it was the victim of a the case of a bogus certificate, because it was the victim of a
social engineering attack or an attack such as the one that affected social engineering attack or an attack such as the one that affected
DigiNotar [https://www.vasco.com/company/about_vasco/press_room/ DigiNotar [https://www.vasco.com/company/about_vasco/press_room/
news_archive/2011/news_diginotar_reports_any security_incident.aspx news_archive/2011/news_diginotar_reports_any security_incident.aspx
]. In the case of an error, the CA should have a record of the [2]]. In the case of an error, the CA should have a record of the
erroneous certificate and be prepared to revoke this certificate once erroneous certificate and be prepared to revoke this certificate once
it has discovered and confirmed the error. In the event of an it has discovered and confirmed the error. In the event of an
attack, a CA may have no record of a bogus certificate. attack, a CA may have no record of a bogus certificate.
3.1.1. Certificate logged 3.1.1. Certificate logged
3.1.1.1. Benign log 3.1.1.1. Benign log
The log (or logs) is benign and thus is presumed to provide The log (or logs) is benign and thus is presumed to provide
consistent, accurate responses to requests from all clients. consistent, accurate responses to requests from all clients.
skipping to change at page 19, line 34 skipping to change at page 19, line 34
In Figure 2, the malicious CA has been issued CA certificates by two In Figure 2, the malicious CA has been issued CA certificates by two
different parent CAs. The parent CAs may be two different trust different parent CAs. The parent CAs may be two different trust
anchors, or one or both of them may be an intermediate CA (i.e., it anchors, or one or both of them may be an intermediate CA (i.e., it
is subordinate to some trust anchor). If both parent CAs are is subordinate to some trust anchor). If both parent CAs are
intermediate CAs, they may be subordinate to the same trust anchor or intermediate CAs, they may be subordinate to the same trust anchor or
to different trust anchors. The malicious CA may have obtained to different trust anchors. The malicious CA may have obtained
certificates from the two parents by applying to them for the certificates from the two parents by applying to them for the
certificates, or by compromising the parent CAs and creating the certificates, or by compromising the parent CAs and creating the
certificates without the knowledge of the CAs. If the malicious CA certificates without the knowledge of the CAs. If the malicious CA
applied for its certificates from these CAs, it may have presented applied for its certificates from these CAs, it may have presented
credentials that cause each parent to believe that the parent is false information as input to the CA's normal issuance procedures,
dealing with a different CA, despite the fact that the CA name and with the result that the CAs do not realize that a certificate with
public key are identical. the same subject name and public key has been issued by another CA.
Because there are two certificate path validation chains, the Because there are two certificate path validation chains, the
malicious CA could provide the chain that includes CA A when malicious CA could provide the chain that includes CA A when
submitting a bogus certificate to one or more logs, but an attacker submitting a bogus certificate to one or more logs, but an attacker
(colluding with the malicious CA) could provide the chain that (colluding with the malicious CA) could provide the chain that
includes CA B to targeted browsers. If the CA's malicious behavior includes CA B to targeted browsers. If the CA's malicious behavior
is detected, then CA A and browser vendors may be alerted (e.g., via is detected, then CA A and browser vendors may be alerted (e.g., via
the CT Monitor function) and revoke/blacklist CA certificate 1. the CT Monitor function) and revoke/blacklist CA certificate 1.
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
skipping to change at page 20, line 10 skipping to change at page 20, line 10
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.
3.5. Attacks Related to Distribution of Revocation Status 3.5. Attacks Related to Distribution of Revocation Status
A bogus certificate that has been revoked may still appear valid to a A bogus certificate that has been revoked may still appear valid to a
browser under certain circumstances. In part this is because browser under certain circumstances. In part this is because the
certificate revocation generally depends on the certificate path revocation information seen by a relying party is partly under the
(chain) used by a relying party when validating a certificate. This control of the CA and/or the certificate subject. As a result,
is true irrespective of whether revocation is effected via use of a different relying parties may be presented with different revocation
CRL or OCSP. Additionally, an attacker can steer a browser to information. This is true irrespective of whether revocation is
specific revocation status data via various means, preventing a effected via use of a CRL or OCSP. Additionally, an attacker can
targeted browser from acquiring accurate revocation status steer a browser to specific revocation status data via various means,
information for a bogus certificate. 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 29, line 11 skipping to change at page 29, line 11
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. Most 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. Thanks also go to Daiming Li
for her editorial assistance.
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-
architecture-04 (work in progress), August 2016. architecture-07 (work in progress), December 2017.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
9.2. Informative References 9.2. Informative References
[I-D.ietf-trans-gossip] [I-D.ietf-trans-gossip]
Nordberg, L., Gillmor, D., and T. Ritter, "Gossiping in Nordberg, L., Gillmor, D., and T. Ritter, "Gossiping in
CT", draft-ietf-trans-gossip-03 (work in progress), July CT", draft-ietf-trans-gossip-05 (work in progress),
2016. January 2018.
[I-D.ietf-trans-rfc6962-bis] [I-D.ietf-trans-rfc6962-bis]
Laurie, B., Langley, A., Kasper, E., Messeri, E., and R. Laurie, B., Langley, A., Kasper, E., Messeri, E., and R.
Stradling, "Certificate Transparency", draft-ietf-trans- Stradling, "Certificate Transparency Version 2.0", draft-
rfc6962-bis-19 (work in progress), August 2016. ietf-trans-rfc6962-bis-28 (work in progress), March 2018.
[I-D.kent-trans-domain-validation-cert-checks] [I-D.kent-trans-domain-validation-cert-checks]
Kent, S. and R. Andrews, "Syntactic and Semantic Checks Kent, S. and R. Andrews, "Syntactic and Semantic Checks
for Domain Validation Certificates", draft-kent-trans- for Domain Validation Certificates", draft-kent-trans-
domain-validation-cert-checks-02 (work in progress), domain-validation-cert-checks-02 (work in progress),
December 2015. December 2015.
[I-D.kent-trans-extended-validation-cert-checks] [I-D.kent-trans-extended-validation-cert-checks]
Kent, S. and R. Andrews, "Syntactic and Semantic Checks Kent, S. and R. Andrews, "Syntactic and Semantic Checks
for Extended Validation Certificates", draft-kent-trans- for Extended Validation Certificates", draft-kent-trans-
extended-validation-cert-checks-02 (work in progress), extended-validation-cert-checks-02 (work in progress),
December 2015. December 2015.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<http://www.rfc-editor.org/info/rfc5280>. <https://www.rfc-editor.org/info/rfc5280>.
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)
Extensions: Extension Definitions", RFC 6066, Extensions: Extension Definitions", RFC 6066,
DOI 10.17487/RFC6066, January 2011, DOI 10.17487/RFC6066, January 2011,
<http://www.rfc-editor.org/info/rfc6066>. <https://www.rfc-editor.org/info/rfc6066>.
[RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A.,
Galperin, S., and C. Adams, "X.509 Internet Public Key Galperin, S., and C. Adams, "X.509 Internet Public Key
Infrastructure Online Certificate Status Protocol - OCSP", Infrastructure Online Certificate Status Protocol - OCSP",
RFC 6960, DOI 10.17487/RFC6960, June 2013, RFC 6960, DOI 10.17487/RFC6960, June 2013,
<http://www.rfc-editor.org/info/rfc6960>. <https://www.rfc-editor.org/info/rfc6960>.
[RFC6961] Pettersen, Y., "The Transport Layer Security (TLS) [RFC6961] Pettersen, Y., "The Transport Layer Security (TLS)
Multiple Certificate Status Request Extension", RFC 6961, Multiple Certificate Status Request Extension", RFC 6961,
DOI 10.17487/RFC6961, June 2013, DOI 10.17487/RFC6961, June 2013,
<http://www.rfc-editor.org/info/rfc6961>. <https://www.rfc-editor.org/info/rfc6961>.
9.3. URIs
[1] https://cabforum.org
[2] https://www.vasco.com/company/about_vasco/press_room/
news_archive/2011/news_diginotar_reports_any
security_incident.aspx
Author's Address Author's Address
Stephen Kent Stephen Kent
Independent Independent
USA
Email: kent@alum.mit.edu Email: kent@alum.mit.edu
 End of changes. 21 change blocks. 
34 lines changed or deleted 44 lines changed or added

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