draft-ietf-trans-threat-analysis-14.txt   draft-ietf-trans-threat-analysis-15.txt 
Public Notary Transparency S. Kent Public Notary Transparency S. Kent
Internet-Draft Independent Internet-Draft Independent
Intended status: Informational May 29, 2018 Intended status: Informational August 30, 2018
Expires: November 30, 2018 Expires: March 3, 2019
Attack and Threat Model for Certificate Transparency Attack and Threat Model for Certificate Transparency
draft-ietf-trans-threat-analysis-14 draft-ietf-trans-threat-analysis-15
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 for which security mechanisms to detect mis-issuance Web PKI context for 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 https://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 November 30, 2018. This Internet-Draft will expire on March 3, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 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
(https://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
skipping to change at page 2, line 20 skipping to change at page 2, line 20
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions used in this document . . . . . . . . . . . . 8 1.1. Conventions used in this document . . . . . . . . . . . . 8
2. Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2. Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3. Semantic mis-issuance . . . . . . . . . . . . . . . . . . . . 10 3. Semantic mis-issuance . . . . . . . . . . . . . . . . . . . . 10
3.1. Non-malicious Web PKI CA context . . . . . . . . . . . . 10 3.1. Non-malicious Web PKI CA context . . . . . . . . . . . . 10
3.1.1. Certificate logged . . . . . . . . . . . . . . . . . 10 3.1.1. Certificate logged . . . . . . . . . . . . . . . . . 10
3.1.1.1. Benign log . . . . . . . . . . . . . . . . . . . 10 3.1.1.1. Benign log . . . . . . . . . . . . . . . . . . . 10
3.1.1.2. Misbehaving log . . . . . . . . . . . . . . . . . 11 3.1.1.2. Misbehaving log . . . . . . . . . . . . . . . . . 11
3.1.1.3. Misbehaving third party Monitor . . . . . . . . . 12 3.1.1.3. Misbehaving third party Monitor . . . . . . . . . 12
3.1.2. Certificate not logged . . . . . . . . . . . . . . . 12 3.1.2. Certificate not logged . . . . . . . . . . . . . . . 12
3.1.2.1. CT-enabled browser . . . . . . . . . . . . . . . 12 3.2. Malicious Web PKI CA context . . . . . . . . . . . . . . 12
3.2. Malicious Web PKI CA context . . . . . . . . . . . . . . 13
3.2.1. Certificate logged . . . . . . . . . . . . . . . . . 13 3.2.1. Certificate logged . . . . . . . . . . . . . . . . . 13
3.2.1.1. Benign log . . . . . . . . . . . . . . . . . . . 13 3.2.1.1. Benign log . . . . . . . . . . . . . . . . . . . 13
3.2.1.2. Misbehaving log . . . . . . . . . . . . . . . . . 14 3.2.1.2. Misbehaving log . . . . . . . . . . . . . . . . . 13
3.2.1.3. Misbehaving third party Monitor . . . . . . . . . 14 3.2.1.3. Misbehaving third party Monitor . . . . . . . . . 14
3.2.2. Certificate not logged . . . . . . . . . . . . . . . 14 3.2.2. Certificate not logged . . . . . . . . . . . . . . . 14
3.2.2.1. CT-aware browser . . . . . . . . . . . . . . . . 15 3.2.2.1. CT-aware browser . . . . . . . . . . . . . . . . 14
3.3. Undetected Compromise of CAs or Logs . . . . . . . . . . 15 3.3. Undetected Compromise of CAs or Logs . . . . . . . . . . 15
3.3.1. Compromised CA, Benign Log . . . . . . . . . . . . . 16 3.3.1. Compromised CA, Benign Log . . . . . . . . . . . . . 15
3.3.2. Benign CA, Compromised Log . . . . . . . . . . . . . 17 3.3.2. Benign CA, Compromised Log . . . . . . . . . . . . . 17
3.3.3. Compromised CA, Compromised Log . . . . . . . . . . . 18 3.3.3. Compromised CA, Compromised Log . . . . . . . . . . . 18
3.4. Attacks Based on Exploiting Multiple Certificate Chains . 19 3.4. Attacks Based on Exploiting Multiple Certificate Chains . 19
3.5. Attacks Related to Distribution of Revocation Status . . 20 3.5. Attacks Related to Distribution of Revocation Status . . 20
4. Syntactic mis-issuance . . . . . . . . . . . . . . . . . . . 21 4. Syntactic mis-issuance . . . . . . . . . . . . . . . . . . . 21
4.1. Non-malicious Web PKI CA context . . . . . . . . . . . . 22 4.1. Non-malicious Web PKI CA context . . . . . . . . . . . . 21
4.1.1. Certificate logged . . . . . . . . . . . . . . . . . 22 4.1.1. Certificate logged . . . . . . . . . . . . . . . . . 22
4.1.1.1. Benign log . . . . . . . . . . . . . . . . . . . 22 4.1.1.1. Benign log . . . . . . . . . . . . . . . . . . . 22
4.1.1.2. Misbehaving log or third party Monitor . . . . . 23 4.1.1.2. Misbehaving log or third party Monitor . . . . . 23
4.1.2. Certificate not logged . . . . . . . . . . . . . . . 23 4.1.2. Certificate not logged . . . . . . . . . . . . . . . 23
4.1.2.1. Self-monitoring Subject . . . . . . . . . . . . . 23 4.1.2.1. Self-monitoring Subject . . . . . . . . . . . . . 24
4.1.3. Situations Independent of Certificate Logging . . . . 24 4.1.3. Situations Independent of Certificate Logging . . . . 24
4.1.3.1. Self-monitoring Subject and Benign third party 4.1.3.1. Self-monitoring Subject and Benign third party
Monitor . . . . . . . . . . . . . . . . . . . . . 24 Monitor . . . . . . . . . . . . . . . . . . . . . 24
4.1.3.2. CT-enabled browser . . . . . . . . . . . . . . . 24 4.1.3.2. CT-enabled browser . . . . . . . . . . . . . . . 24
4.2. Malicious Web PKI CA context . . . . . . . . . . . . . . 24 4.2. Malicious Web PKI CA context . . . . . . . . . . . . . . 25
4.2.1. Certificate logged . . . . . . . . . . . . . . . . . 25 4.2.1. Certificate logged . . . . . . . . . . . . . . . . . 25
4.2.1.1. Benign log . . . . . . . . . . . . . . . . . . . 25 4.2.1.1. Benign log . . . . . . . . . . . . . . . . . . . 25
4.2.1.2. Misbehaving log or third party Monitor . . . . . 25 4.2.1.2. Misbehaving log or third party Monitor . . . . . 25
4.2.1.3. CT-enabled browser . . . . . . . . . . . . . . . 25 4.2.1.3. CT-enabled browser . . . . . . . . . . . . . . . 26
4.2.2. Certificate is not logged . . . . . . . . . . . . . . 26 4.2.2. Certificate is not logged . . . . . . . . . . . . . . 26
5. Issues Applicable to Sections 3 and 4 . . . . . . . . . . . . 26 5. Issues Applicable to Sections 3 and 4 . . . . . . . . . . . . 26
5.1. How does a Subject know which Monitor(s) to use? . . . . 26 5.1. How does a Subject know which Monitor(s) to use? . . . . 26
5.2. How does a Monitor discover new logs? . . . . . . . . . . 26 5.2. How does a Monitor discover new logs? . . . . . . . . . . 27
5.3. CA response to report of a bogus or erroneous certificate 27 5.3. CA response to report of a bogus or erroneous certificate 27
5.4. Browser behavior . . . . . . . . . . . . . . . . . . . . 27 5.4. Browser behavior . . . . . . . . . . . . . . . . . . . . 27
5.5. Remediation for a malicious CA . . . . . . . . . . . . . 27 5.5. Remediation for a malicious CA . . . . . . . . . . . . . 28
5.6. Auditing - detecting misbehaving logs . . . . . . . . . . 28 5.6. Auditing - detecting misbehaving logs . . . . . . . . . . 28
6. Security Considerations . . . . . . . . . . . . . . . . . . . 29 6. Security Considerations . . . . . . . . . . . . . . . . . . . 30
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
9.1. Normative References . . . . . . . . . . . . . . . . . . 30 9.1. Normative References . . . . . . . . . . . . . . . . . . 30
9.2. Informative References . . . . . . . . . . . . . . . . . 30 9.2. Informative References . . . . . . . . . . . . . . . . . 30
9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 31 9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 31 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 31
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-
skipping to change at page 4, line 18 skipping to change at page 4, line 17
primary means of remedying mis-issuance. primary means of remedying mis-issuance.
Certificate Revocations Lists (CRLs) [RFC5280] are the primary means Certificate Revocations Lists (CRLs) [RFC5280] are the primary means
of certificate revocation established by IETF standards. of certificate revocation established by IETF standards.
Unfortunately, most browsers do not make use of CRLs to check the Unfortunately, most browsers do not make use of CRLs to check the
revocation status of certificates presented by a TLS Server revocation status of certificates presented by a TLS Server
(Subject). Some browsers make use of Online Certificate Status (Subject). Some browsers make use of Online Certificate Status
Protocol (OCSP) data [RFC6960] as a standards-based alternative to Protocol (OCSP) data [RFC6960] as a standards-based alternative to
CRLs. If a certificate contains an Authority Information Access CRLs. If a certificate contains an Authority Information Access
(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. The data from this server to which a request can be directed. A browser may also
extension also may be used by a browser to request OCSP responses request OCSP responses from a TLS server with which it is
from a TLS server with which it is communicating [RFC6066][RFC6961]. 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 cabforum.org [1] for the most their certificate policies). (See cabforum.org [1] for the most
recent versions of these policies.) recent versions of these policies.)
In addition to the revocation status data dissemination mechanisms In addition to the revocation status data dissemination mechanisms
skipping to change at page 7, line 6 skipping to change at page 7, line 6
misbehavior are not yet standardized. misbehavior are not yet standardized.
Figure 1 (below) illustrates the data exchanges among the major Figure 1 (below) illustrates the data exchanges among the major
elements of the CT system, based on the log specification elements of the CT system, based on the log specification
[I-D.ietf-trans-rfc6962-bis] and on the assumed behavior of other CT [I-D.ietf-trans-rfc6962-bis] and on the assumed behavior of other CT
system elements as described above. This Figure does not include the system elements as described above. This Figure does not include the
Audit function, because there is not yet agreement on how that Audit function, because there is not yet agreement on how that
function will work in a distributed, privacy-preserving fashion. function will work in a distributed, privacy-preserving fashion.
+----+ +---------+ +---------+ +----+ +---------+ +---------+
| CA |---[1-]-->| Log |<---[8]---| Monitor | | CA |---[1]--->| Log |<---[8]---| Monitor |
| | | | | | | | | | | |
| |<--[2]----| |----[9]-->| | | |<--[2]----| |----[9]-->| |
| | | | | | | | | | | |
| |---[3]--->| |<--[10]---| | | |---[3]--->| |<--[10]---| |
| | | | | |--------+ | | | | | |--------+
| |<--[4]----| |---[11]-->| | | | |<--[4]----| |---[11]-->| | |
| | | | +---------+ | | | | | +---------+ |
| | | | | | | | | |
| | | | +---------+ | | | | | +---------+ |
| | | |<--[8]----| Self- | | | | | |<--[8]----| Self- | |
| | | | | Monitor | | | | | | | Monitor | |
| | | |---[9]--->|(Subject)| | | | | |---[9]--->|(Subject)| |
| | | | | | | | | | | | | |
| | | |<--[10]---| | [12] | | | |<--[10]---| | [12]
| | | | | | | | | | | | | |
| | | |---[11]-->| | | | | | |---[11]-->| | |
| | +---------+ +---------+ | | | +---------+ +---------+ |
| | | | | |
| | +---------+ +---------+ | | | +---------+ +---------+ |
| |----[5]-->| Website |---[7]--->| Browser | | | |---[5]--->| Website |---[7]--->| Browser | |
| | |(Subject)| +---------+ | | | |(Subject)| +---------+ |
| |<---[6]-->| |<----------------------------+ | |<--[6]--->| |<----------------------------+
+----+ +---------+ +----+ +---------+
[ 1] Retrieve accepted root certs [ 1] Retrieve accepted root certs
[ 2] accepted root certs [ 2] accepted root certs
[ 3] Add chain to log/add PreCertChain to log [ 3] Add chain to log/add PreCertChain to log
[ 4] SCT [ 4] SCT
[ 5] send cert + SCTs (or cert with embedded SCTs) [ 5] send cert + SCTs (or cert with embedded SCTs)
[ 6] Revocation request/response (in response to detected [ 6] Revocation request/response (in response to detected
mis-issuance) mis-issuance)
[ 7] cert + SCTs (or cert with embedded SCTs) [ 7] cert + SCTs (or cert with embedded SCTs)
skipping to change at page 8, line 37 skipping to change at page 8, line 37
most of the analysis is applicable to other PKI contexts. most of the analysis is applicable to other PKI contexts.
1.1. Conventions used in this document 1.1. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Threats 2. Threats
A threat is defined, traditionally, as a motivated, capable In the context of this document, a threat is defined, traditionally,
adversary. An adversary who is not motivated to attack a system is as a motivated, capable adversary. An adversary who is not motivated
not a threat. An adversary who is motivated but not "capable" also to attack a system is not a threat. An adversary who is motivated
is not a threat. Threats change over time; new classes of but not "capable" also is not a threat. Threats change over time;
adversaries may arise, new motivations may come into play, and the new classes of adversaries may arise, new motivations may come into
capabilities of adversaries may change. Nonetheless, it is useful to play, and the capabilities of adversaries may change. Nonetheless,
document perceived threats against a system to provide a context for it is useful to document perceived threats against a system to
understanding attacks (even though some attacks may be the result of provide a context for understanding attacks (even though some attacks
errors, not threats). Even if the assumptions about adversaries may be the result of errors, not threats). Even if the assumptions
prove to be incorrect, documenting the assumptions is valuable. about adversaries prove to be incorrect, documenting the assumptions
is valuable.
As noted above, the goals of CT are to deter, detect, and facilitate As noted above, the goals of CT are to deter, detect, and facilitate
remediation of attacks that result in certificate mis-issuance in the remediation of attacks that result in certificate mis-issuance in the
Web PKI. (CT also may facilitate detection and remediation of errors Web PKI. (Note that errors by a CA are viewed as attacks, in the
that result in certificate mis-issuance.) Such attacks can enable an context of this document.) Such attacks can enable an attacker to
attacker to spoof the identity of TLS-enabled web sites. Spoofing spoof the identity of TLS-enabled web sites. Spoofing enables an
enables an adversary to perform many types of attacks, e.g., delivery adversary to perform many types of attacks, e.g., delivery of malware
of malware to a client, reporting bogus information, or acquiring to a client, reporting bogus information, or acquiring information
information that a client would not communicate if the client were that a client would not communicate if the client were aware of the
aware of the spoofing. Such information may include personal spoofing. Such information may include personal identification and
identification and authentication information and electronic payment authentication information and electronic payment authorization
authorization information. Because of the nature of the information information. Because of the nature of the information that may be
that may be divulged (or misinformation or malware that may be divulged (or misinformation or malware that may be delivered), the
delivered), the principal adversaries in the CT context are perceived principal adversaries in the CT context are perceived to be (cyber)
to be (cyber) criminals and nation states. Both adversaries are criminals and nation states. Both adversaries are motivated to
motivated to acquire personal identification and authentication acquire personal identification and authentication information.
information. Criminals are also motivated to acquire electronic Criminals are also motivated to acquire electronic payment
payment authorization information. authorization information.
To make use of bogus web site certificates, an adversary must be able To make use of bogus web site certificates, an adversary must be able
to direct a TLS client to a spoofed web site, so that it can present to direct a TLS client to a spoofed web site, so that it can present
the bogus certificate during a TLS handshake. An adversary may the bogus certificate during a TLS handshake. An adversary may
achieve this in various ways, e.g., by manipulation of the DNS achieve this in various ways, e.g., by manipulation of the DNS
response sent to a TLS client or via a man-in-the-middle attack. The response sent to a TLS client or via a man-in-the-middle attack. The
former type of attack is well within the perceived capabilities of former type of attack is well within the perceived capabilities of
both classes of adversary. The latter attack may be possible for both classes of adversary. The latter attack may be possible for
criminals and is certainly a capability available to a nation state criminals and is certainly a capability available to a nation state
within its borders. Nation states also may be able to compromise DNS within its borders. Nation states also may be able to compromise DNS
skipping to change at page 12, line 44 skipping to change at page 12, line 44
is benign or misbehaving does not matter. The same is true if a is benign or misbehaving does not matter. The same is true if a
Subject is issued a certificate without an SCT and does not log the Subject is issued a certificate without an SCT and does not log the
certificate itself, to acquire an SCT. Also, since there is no log certificate itself, to acquire an SCT. Also, since there is no log
entry in this scenario, there is no difference in outcome between a entry in this scenario, there is no difference in outcome between a
benign and a misbehaving third party Monitor. In both cases, no benign and a misbehaving third party Monitor. In both cases, no
Monitor (self or third-party) will detect a bogus certificate based Monitor (self or third-party) will detect a bogus certificate based
on Monitor functions and there will be no consequent reporting of the on Monitor functions and there will be no consequent reporting of the
problem to the Subject or by the Subject to the CA based on problem to the Subject or by the Subject to the CA based on
examination of log entries. examination of log entries.
3.1.2.1. CT-enabled browser
If a browser rejects certificates without SCTs (see Section 5.4), CAs
may be "encouraged" to log the certificates they issue. This, in
turn, would make it easier for Monitors to detect bogus certificates.
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. In the CT
architecture certificates have to be logged to enable Monitors to
detect mis-issuance, and to trigger subsequent revocation. Thus the
effectiveness of CT is diminished in this context.
3.2. Malicious Web PKI CA context 3.2. Malicious Web PKI CA context
In this section, we address the scenario in which the mis-issuance is In this section, we address the scenario in which the mis-issuance is
intentional, not due to error. The CA is not the victim but the intentional, not due to error. The CA is not the victim but the
attacker. attacker.
3.2.1. Certificate logged 3.2.1. Certificate logged
3.2.1.1. Benign log 3.2.1.1. Benign log
skipping to change at page 15, line 18 skipping to change at page 14, line 50
misbehaving third-party Monitor. Neither will report a problem to misbehaving third-party Monitor. Neither will report a problem to
the Subject. the Subject.
A bogus certificate would not be delivered to the legitimate Subject. A bogus certificate would not be delivered to the legitimate Subject.
So the Subject, acting as a self-Monitor, cannot detect the issuance So the Subject, acting as a self-Monitor, cannot detect the issuance
of a bogus certificate in this case. of a bogus certificate in this case.
3.2.2.1. CT-aware browser 3.2.2.1. CT-aware browser
If careful browsers reject certificates without SCTs, CAs may be If careful browsers reject certificates without SCTs, CAs may be
"encouraged" to log certificates (see section 5.4.) However, the CT "encouraged" to log certificates (see section 5.4). However, the CT
architecture does not describe how such behavior by browsers can be architecture does not require a browser to reject a certificate
deployed incrementally throughout the Internet. As a result, this lacking a matching SCT (or equivalent evidence of logging) in all
attack model does not assume that browsers will reject a certificate cases. This is a matter of local policy. Section 8.1.6 of
that is not accompanied by an SCT. Since certificates have to be [I-D.ietf-trans-rfc6962-bis] says: "It is up to a client's local
logged to enable detection of mis-issuance by Monitors, and to policy to specify the quantity and form of evidence (SCTs, inclusion
proofs or a combination) needed to achieve compliance and how to
handle non-compliance." As a result, this attack model does not
assume that browsers will reject a certificate that is not
accompanied by an SCT in all circumstances. Since certificates have
to be logged to enable detection of mis-issuance by Monitors, and to
trigger subsequent revocation, the effectiveness of CT is diminished trigger subsequent revocation, the effectiveness of CT is diminished
in this context. in circumstances where local policy does not mandate SCT or inclusion
proof checking.
3.3. Undetected Compromise of CAs or Logs 3.3. Undetected Compromise of CAs or Logs
Sections 3.1 and 3.2 examined attacks in the context of non-malicious 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 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 attacks might occur in the context of a non-malicious CA and/or a
benign log. Specifically these CT elements might be compromised and benign log. Specifically these CT elements might be compromised and
the compromise might go undetected. Compromise of CAs and logs was 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 noted in Section 2, as was coercion of a CA. As noted there, a
compromised CA is almost equivalent to a malicious CA, and thus the compromised CA is almost equivalent to a malicious CA, and thus the
skipping to change at page 16, line 9 skipping to change at page 15, line 48
and STHs. (An attacker might not have access to a CA or log private and STHs. (An attacker might not have access to a CA or log private
key per se. The attacker may be able to cause a CA to issue bogus key per se. The attacker may be able to cause a CA to issue bogus
certificates, or a log to generate bogus objects, and not have a certificates, or a log to generate bogus objects, and not have a
record of them. The DigiNotar [2] case is an example of this sort of record of them. The DigiNotar [2] case is an example of this sort of
attack on a CA.) Because the compromise is undetected, there will be attack on a CA.) Because the compromise is undetected, there will be
no effort by a CA to have its certificate revoked or by a log to shut no effort by a CA to have its certificate revoked or by a log to shut
down the log. down the log.
3.3.1. Compromised CA, Benign Log 3.3.1. Compromised CA, Benign Log
In the case of a compromised (non-malicious) CA, an attacker uses the In the case of a compromised (non-malicious) CA, an attacker may have
purloined private key to generate a bogus certificate (that the CA acquired the CA's private key, or it may be able to cause the CA to
would not knowingly issue). If this certificate is submitted to a sign certificates using that key, even though the attacker does not
(benign) log, then it subject to detection by a Monitor, as discussed know the key per se. In other case the goal is to cause the CA to
in 3.1.1.1. If the bogus certificate is submitted to a misbehaving issues a bogus certificate (that the CA would not knowingly issue).
log, then an SCT can be generated, but there will be no entry for it, If this certificate is submitted to a (benign) log, then it subject
as discussed in 3.1.1.2. If the bogus certificate is not logged, to detection by a Monitor, as discussed in 3.1.1.1. If the bogus
then there will be no SCT, and the implications are as described in certificate is submitted to a misbehaving log, then an SCT can be
3.1.2. 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 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 victim of the attack has issued a certificate for the targeted
Subject. In this case the bogus certificate will then have the same Subject. In this case the bogus certificate will then have the same
certification path as the legitimate certificate, which may help hide certification path as the legitimate certificate, which may help hide
the bogus certificate. However, means of remedying the attack are the bogus certificate. However, means of remedying the attack are
independent of this aspect, i.e., revocation can be effected independent of this aspect, i.e., revocation can be effected
irrespective of whether the targeted Subject received its certificate irrespective of whether the targeted Subject received its certificate
from the compromised CA. from the compromised CA.
skipping to change at page 17, line 28 skipping to change at page 17, line 21
any AIA/CRL DP data present in the targeted certificate. The any AIA/CRL DP data present in the targeted certificate. The
revocation status data from the evil twin will appear as valid as revocation status data from the evil twin will appear as valid as
those of the compromised CA. If the attacker has the ability to those of the compromised CA. If the attacker has the ability to
control the sources of revocation status data available to a targeted control the sources of revocation status data available to a targeted
user (browser instance), then the user may not become aware of the user (browser instance), then the user may not become aware of the
attack. attack.
A bogus certificate issued by the malicious CA will not match the SCT A bogus certificate issued by the malicious CA will not match the SCT
for the legitimate certificate, since they are not identical, e.g., 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 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 that rejects certificates without SCTs (see 3.2.2.1) will reject a
bogus certificate created under these circumstances if it is not bogus certificate created under these circumstances if it is not
logged. If the bogus certificate is logged it is subject to logged. If the bogus certificate is logged it is subject to
detection by Monitors. Because the CA is presumed to be malicious detection by Monitors. Because the CA is presumed to be malicious
the CA may delay revocation or try to suppress revocation status (see the CA may delay revocation or try to suppress revocation status (see
Section 3.5) even when confronted with evidence of issuance of the Section 3.5) even when confronted with evidence of issuance of the
bogus certificate. In this case, even browsers that require an SCT bogus certificate. In this case, even browsers that require an SCT
will still accept the bogus certificate until they become aware of will still accept the bogus certificate until they become aware of
its revocation status. its revocation status.
3.3.2. Benign CA, Compromised Log 3.3.2. Benign CA, Compromised Log
skipping to change at page 20, line 35 skipping to change at page 20, line 32
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.
This sort of attack might be thwarted if all intermediate (i.e., CA) This sort of attack might be thwarted if all intermediate (i.e., CA)
certificates had to be logged. In that case CA certificate 2 might certificates had to be logged. In that case CA certificate 2 might
be rejected by CT-aware browsers. be rejected by CT-aware browsers.
This type of attack also might be thwarted if a browser vendor
blacklists a malicious CA using the CA's public key (not by its
serial number and the name of the parent CA or by a hash of the
certificate). This approach to revocation would cause CA certificate
2 to be rejected as well as CA certificate 1. However none of these
mechanisms are part of the CT specification
[I-D.ietf-trans-rfc6962-bis] nor general IETF PKI standards (e.g.,
[RFC5280]).
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 the browser under certain circumstances. In part this is because the
revocation information seen by a relying party is partly under the revocation information seen by a relying party is partly under the
control of the CA and/or the certificate subject. As a result, control of the CA and/or the certificate subject. As a result,
different relying parties may be presented with different revocation different relying parties may be presented with different revocation
information. This is true irrespective of whether revocation is information. This is true irrespective of whether revocation is
effected via use of a CRL or OCSP. Additionally, an attacker can effected via use of a CRL or OCSP. Additionally, an attacker can
steer a browser to specific revocation status data via various means, steer a browser to specific revocation status data via various means,
skipping to change at page 21, line 37 skipping to change at page 21, line 44
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.
This type of attack might be thwarted in several ways. If a
malicious CA is discovered, a browser vendor might blacklist it by
public key (not by its serial number and the name of the parent CA or
by a hash of the certificate). This approach to revocation would
cause CA certificate 2 to be rejected as well as CA certificate 1.
However none of these mechanisms are part of the CT specification
[I-D.ietf-trans-rfc6962-bis] nor general IETF PKI standards (e.g.,
[RFC5280]).
4. Syntactic mis-issuance 4. Syntactic mis-issuance
4.1. Non-malicious Web PKI CA context 4.1. Non-malicious Web PKI CA context
This section analyzes the scenario in which the CA has no intent to This section analyzes the scenario in which the CA has no intent to
issue a syntactically incorrect certificate. As noted in Section 1, issue a syntactically incorrect certificate, but it may do so in
we refer to a syntactically incorrect certificate as erroneous. error. (Remember that errors are considered form of attack in this
document, see Section 2). As noted in Section 1, we refer to a
syntactically incorrect certificate as erroneous. A certificate is
erroneous if it violates a criteria to which the issuing CA claims to
adhere. This might be a general profile such as [RFC5280], or a
narrower profile such as those established by the CABF [1] for domain
validated (DV) or extended validation (EV) certificates. If the
Subject is a web site that expected to receive an EV certificate, but
the certificate issued to it carries the DV policy OID, or no policy
OID, relying parties may reject the certificate, causing harm to the
business of the Subject. Conversely, if a CA issues a certificate to
a web site and erroneously includes the EV policy OID, relying
parties may place more trust in the certificate than is warranted.
4.1.1. Certificate logged 4.1.1. Certificate logged
4.1.1.1. Benign log 4.1.1.1. Benign log
If a (pre )certificate is submitted to a benign log, syntactic mis- If a (pre )certificate is submitted to a benign log, syntactic mis-
issuance can (optionally) be detected, and noted. This will happen issuance can (optionally) be detected, and noted. This will happen
only if the log performs syntactic checks in general, and if the log only if the log performs syntactic checks in general, and if the log
is capable of performing the checks applicable to the submitted (pre is capable of performing the checks applicable to the submitted (pre
)certificate. (A (pre )certificate should be logged even if it fails )certificate. (A (pre )certificate should be logged even if it fails
skipping to change at page 24, line 31 skipping to change at page 24, line 40
and remedy the syntactic problem. The CA SHOULD either re-submit the and remedy the syntactic problem. The CA SHOULD either re-submit the
corrected (pre )certificate to one or more logs and then send the corrected (pre )certificate to one or more logs and then send the
result to the Subject, or send the corrected certificate to the result to the Subject, or send the corrected certificate to the
Subject, who will re-submit it to one or more logs. Subject, who will re-submit it to one or more logs.
4.1.3.2. CT-enabled browser 4.1.3.2. CT-enabled browser
If a browser rejects an erroneous certificate and notifies the If a browser rejects an erroneous certificate and notifies the
Subject and/or the issuing CA, then syntactic mis-issuance will be Subject and/or the issuing CA, then syntactic mis-issuance will be
detected (see Section 5.) Unfortunately, experience suggests that detected (see Section 5.) Unfortunately, experience suggests that
many browsers do not perform thorough syntactic checks on many browsers do not always perform very good syntactic checks on
certificates, and so it seems unlikely that browsers will be a certificates. For example, a browser may fail to verify that a
reliable way to detect erroneous certificates. Moreover, a protocol certificate used in a certificate path is properly marked as a CA
used by a browser to notify a Subject and/or CA of an erroneous certificate. Also, it would be problematic for a browser to check a
certificate represents a DoS potential, and thus may not be certificate against a specific version of a profile if the profile
appropriate. Additionally, if a browser directly contacts a CA when changes and the policy OID remains constant. Thus it seems unlikely
an erroneous certificate is detected, this is a potential privacy that browsers will be a reliable way to detect erroneous certificates
violation, i.e., the CA learns that the browser user is visiting the in all circumstances. Moreover, a protocol used by a browser to
web site in question. These observations argue for syntactic notify a Subject and/or CA of an erroneous certificate represents a
checking to be performed by other elements of the CT system, e.g., DoS potential, and thus may not be appropriate. Additionally, if a
logs and/or Monitors. browser directly contacts a CA when an erroneous certificate is
detected, this is a potential privacy violation, i.e., the CA learns
that the browser user is visiting the web site in question. These
observations argue for syntactic checking to be performed by other
elements of the CT system, e.g., logs and/or Monitors.
4.2. Malicious Web PKI CA context 4.2. Malicious Web PKI CA context
This section analyzes the scenario in which the CA's issuance of a This section analyzes the scenario in which the CA's issuance of a
syntactically incorrect certificate is intentional, not due to error. syntactically incorrect certificate is intentional, not due to error.
The CA is not the victim but the attacker. The CA is not the victim but the attacker.
Note that irrespective of whether syntactic checks are performed by a Note that irrespective of whether syntactic checks are performed by a
log, a malicious CA can acquire an embedded SCT, or post-issuance log, a malicious CA can acquire an embedded SCT, or post-issuance
will acquire a standalone SCT for an erroneous certificate. If will acquire a standalone SCT for an erroneous certificate. If
skipping to change at page 25, line 41 skipping to change at page 26, line 7
4.2.1.2. Misbehaving log or third party Monitor 4.2.1.2. Misbehaving log or third party Monitor
A misbehaving log or third party Monitor will either not perform A misbehaving log or third party Monitor will either not perform
syntactic checks or not report any problems that it discovers. (See syntactic checks or not report any problems that it discovers. (See
4.1.1.2 for further problems). Also, as noted above, the CT 4.1.1.2 for further problems). Also, as noted above, the CT
architecture includes no explicit provisions for detecting a architecture includes no explicit provisions for detecting a
misbehaving third-party Monitor. misbehaving third-party Monitor.
4.2.1.3. CT-enabled browser 4.2.1.3. CT-enabled browser
As noted above (4.1.1.4), most browsers fail to perform thorough As noted above (4.1.3.2), most browsers fail to perform thorough
syntax checks on certificates. Such browsers might benefit from syntax checks on certificates. Such browsers might benefit from
having syntax checks performed by a log and reported in the SCT, having syntax checks performed by a log and reported in the SCT,
although the pervasive nature of syntactically-defective certificates although the pervasive nature of syntactically-defective certificates
may limit the utility of such checks. (Remember, in this scenario, may limit the utility of such checks. (Remember, in this scenario,
the log is benign.) However, if a browser does not discriminate the log is benign.) However, if a browser does not discriminate
against certificates that do not contain SCTs (or that are not against certificates that do not contain SCTs (or that are not
accompanied by an SCT in the TLS handshake), only minimal benefits accompanied by an SCT in the TLS handshake), only minimal benefits
might accrue to the browser from syntax checks perform by logs or might accrue to the browser from syntax checks perform by logs or
Monitors. Monitors.
skipping to change at page 27, line 27 skipping to change at page 27, line 39
purposes, but are not required to effect. The SCT and log entry, purposes, but are not required to effect. The SCT and log entry,
because each contains a timestamp from a third party, is probably because each contains a timestamp from a third party, is probably
valuable for forensic purposes (assuming a non-conspiring log valuable for forensic purposes (assuming a non-conspiring log
operator). operator).
5.4. Browser behavior 5.4. Browser behavior
If a browser is to reject a certificate that lacks an embedded SCT, If a browser is to reject a certificate that lacks an embedded SCT,
or is not accompanied by an SCT transported via the TLS handshake, or is not accompanied by an SCT transported via the TLS handshake,
this behavior needs to be defined in a way that is compatible with this behavior needs to be defined in a way that is compatible with
incremental deployment. Issuing a warning to a (human) user is incremental deployment. [I-D.ietf-trans-rfc6962-bis] does not
describe a strategy for incremental deployment, however it calls for
local policy controls that might be used to facilitate incremental
deployment (see 3.2.2.1 earlier). For example a browser might
establish a date after which all certificates issued MUST contain an
SCT or be accompanied by an SCT during TLS session establishment. A
strategy like this would allow certificates issued before that date
to be "grandfathered". This approach would allow a malicious CA to
backdate a certificate to avoid logging it, exploiting a window of
vulnerability. Note that issuing a warning to a (human) user is
probably insufficient, based on experience with warnings displayed probably insufficient, based on experience with warnings displayed
for expired certificates, lack of certificate revocation status for expired certificates, lack of certificate revocation status
information, and similar errors that violate RFC 5280 path validation information, and similar errors that violate RFC 5280 path validation
rules [RFC5280]. Unless a mechanism is defined that accommodates rules [RFC5280].
incremental deployment of this capability, attackers probably will
avoid submitting bogus certificates to (benign) logs as a means of
evading detection.
5.5. Remediation for a malicious CA 5.5. Remediation for a malicious CA
A targeted Subject might ask the parent of a malicious CA to revoke A targeted Subject might ask the parent of a malicious CA to revoke
the certificate of the non-cooperative CA. However, a request of the certificate of the non-cooperative CA. However, a request of
this sort may be rejected, e.g., because of the potential for this sort may be rejected, e.g., because of the potential for
significant collateral damage. A browser might be configured to significant collateral damage. A browser might be configured to
reject all certificates issued by the malicious CA, e.g., using a reject all certificates issued by the malicious CA, e.g., using a
bad-CA-list distributed by a browser vendor. However, if the bad-CA-list distributed by a browser vendor. However, if the
malicious CA has a sufficient number of legitimate clients, treating malicious CA has a sufficient number of legitimate clients, treating
skipping to change at page 30, line 21 skipping to change at page 30, line 45
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://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-05 (work in progress), CT", draft-ietf-trans-gossip-05 (work in progress),
January 2018. January 2018.
[I-D.kent-trans-extended-validation-cert-checks] [I-D.ietf-trans-rfc6962-bis]
Kent, S. and R. Andrews, "Syntactic and Semantic Checks Laurie, B., Langley, A., Kasper, E., Messeri, E., and R.
for Extended Validation Certificates", draft-kent-trans- Stradling, "Certificate Transparency Version 2.0", draft-
extended-validation-cert-checks-02 (work in progress), ietf-trans-rfc6962-bis-28 (work in progress), March 2018.
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,
<https://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,
 End of changes. 34 change blocks. 
112 lines changed or deleted 129 lines changed or added

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