idnits 2.17.1 draft-ietf-trans-threat-analysis-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 5 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 17, 2017) is 2537 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '10' on line 278 -- Looks like a reference, but probably isn't: '12' on line 280 -- Looks like a reference, but probably isn't: '11' on line 279 == Outdated reference: A later version (-07) exists of draft-kent-trans-architecture-04 == Outdated reference: A later version (-05) exists of draft-ietf-trans-gossip-03 == Outdated reference: A later version (-42) exists of draft-ietf-trans-rfc6962-bis-19 -- Obsolete informational reference (is this intentional?): RFC 6961 (Obsoleted by RFC 8446) Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Public Notary Transparency S. Kent 3 Internet-Draft BBN Technologies 4 Intended status: Informational April 17, 2017 5 Expires: October 17, 2017 7 Attack and Threat Model for Certificate Transparency 8 draft-ietf-trans-threat-analysis-11 10 Abstract 12 This document describes an attack model and discusses threats for the 13 Web PKI context in which security mechanisms to detect mis-issuance 14 of web site certificates are being developed. The model provides an 15 analysis of detection and remediation mechanisms for both syntactic 16 and semantic mis-issuance. The model introduces an outline of 17 attacks to organize the discussion. The model also describes the 18 roles played by the elements of the Certificate Transparency (CT) 19 system, to establish a context for the model. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on April 21, 2017. 38 Copyright Notice 40 Copyright (c) 2016 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Conventions used in this document . . . . . . . . . . . . 7 57 2. Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 58 3. Semantic mis-issuance . . . . . . . . . . . . . . . . . . . . 9 59 3.1. Non-malicious Web PKI CA context . . . . . . . . . . . . 9 60 3.1.1. Certificate logged . . . . . . . . . . . . . . . . . 9 61 3.1.2. Certificate not logged . . . . . . . . . . . . . . . 11 62 3.2. Malicious Web PKI CA context . . . . . . . . . . . . . . 12 63 3.2.1. Certificate logged . . . . . . . . . . . . . . . . . 12 64 3.2.2. Certificate not logged . . . . . . . . . . . . . . . 14 65 3.3. Undetected Compromise of CAs or Logs . . . . . . . . . . 15 66 3.3.1. Compromised CA, Benign Log . . . . . . . . . . . . . 15 67 3.3.2. Benign CA, Compromised Log . . . . . . . . . . . . . 17 68 3.3.3. Compromised CA, Compromised Log . . . . . . . . . . . 17 69 3.4. Attacks Based on Exploiting Multiple Certificate Chains . 18 70 3.5. Attacks Related to Distribution of Revocation Status . . 20 71 4. Syntactic mis-issuance . . . . . . . . . . . . . . . . . . . 21 72 4.1. Non-malicious Web PKI CA context . . . . . . . . . . . . 21 73 4.1.1. Certificate logged . . . . . . . . . . . . . . . . . 21 74 4.1.2. Certificate not logged . . . . . . . . . . . . . . . 23 75 4.2. Malicious Web PKI CA context . . . . . . . . . . . . . . 23 76 4.2.1. Certificate logged . . . . . . . . . . . . . . . . . 24 77 4.2.2. Certificate is not logged . . . . . . . . . . . . . . 25 78 5. Issues Applicable to Sections 3 and 4 . . . . . . . . . . . . 25 79 5.1. How does a Subject know which Monitor(s) to use? . . . . 25 80 5.2. How does a Monitor discover new logs? . . . . . . . . . . 25 81 5.3. CA response to report of a bogus or erroneous certificate 26 82 5.4. Browser behavior . . . . . . . . . . . . . . . . . . . . 26 83 5.5. Remediation for a malicious CA . . . . . . . . . . . . . 26 84 5.6. Auditing - detecting misbehaving logs . . . . . . . . . . 27 85 6. Security Considerations . . . . . . . . . . . . . . . . . . . 28 86 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 87 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 88 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 89 9.1. Normative References . . . . . . . . . . . . . . . . . . 29 90 9.2. Informative References . . . . . . . . . . . . . . . . . 29 91 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 30 93 1. Introduction 95 Certificate transparency (CT) is a set of mechanisms designed to 96 detect, deter, and facilitate remediation of certificate mis- 97 issuance. The term certificate mis-issuance is defined here to 98 encompass violations of either semantic or syntactic constraints. 99 The fundamental semantic constraint for a certificate is that it was 100 issued to an entity that is authorized to represent the Subject (or 101 Subject Alternative) named in the certificate. (It is also assumed 102 that the entity requested the certificate from the CA that issued 103 it.) Throughout the remainder of this document we refer to a 104 semantically mis-issued certificate as "bogus." 106 A certificate is characterized as syntactically mis-issued (aka 107 erroneous) if it violates syntax constraints associated with the 108 class of certificate that it purports to represent. Syntax 109 constraints for certificates are established by certificate profiles, 110 and typically are application-specific. For example, certificates 111 used in the Web PKI environment might be characterized as domain 112 validation (DV) or extended validation (EV) certificates. 113 Certificates used with applications such as IPsec or S/MIME have 114 different syntactic constraints from those in the Web PKI context. 116 There are three classes of beneficiaries of CT: certificate Subjects, 117 CAs, and relying parties (RPs). In the initial focus context of CT, 118 the Web PKI, Subjects are web sites and RPs are browsers employing 119 HTTPS to access these web sites. Thee CAs that benefit are issuers 120 of certificates used to authenticate web sites. 122 A certificate Subject benefits from CT because CT helps detect 123 certificates that have been mis-issued in the name of that Subject. 124 A Subject learns of a bogus certificate (issued in its name), via the 125 Monitor function of CT. The Monitor function may be provided by the 126 Subject itself, i.e., self-monitoring, or by a third party trusted by 127 the Subject. When a Subject is informed of certificate mis-issuance 128 by a Monitor, the Subject is expected to request/demand revocation of 129 the bogus certificate. Revocation of a bogus certificate is the 130 primary means of remedying mis-issuance. 132 Certificate Revocations Lists (CRLs) [RFC5280] are the primary means 133 of certificate revocation established by IETF standards. 134 Unfortunately, most browsers do not make use of CRLs to check the 135 revocation status of certificates presented by a TLS Server 136 (Subject). Some browsers make use of Online Certificate Status 137 Protocol (OCSP) data [RFC6960] as a standards-based alternative to 138 CRLs. If a certificate contains an Authority Information Access 139 (AIA) extension [RFC5280], it directs a relying party to an OCSP 140 server to which a request can be directed. This extension also may 141 be used by a browser to request OCSP responses from a TLS server with 142 which it is communicating [RFC6066][RFC6961]. 144 RFC 5280 does not require inclusion of an AIA extension in 145 certificates, so a browser cannot assume that this extension will be 146 present. The Certification Authority and Browser Forum (CABF) 147 baseline requirements and extended validation guidelines do mandate 148 inclusion of this extension in EE certificates (in conjunction with 149 their certificate policies). (See https://cabforum.org for the most 150 recent versions of these policies.) 152 In addition to the revocation status data dissemination mechanisms 153 specified by IETF standards, most browser vendors employ proprietary 154 means of conveying certificate revocation status information to their 155 products, e.g., via a blacklist that enumerates revoked certificates 156 (EE or CA). Such capabilities enable a browser vendor to cause 157 browsers to reject any certificates on the blacklist. This approach 158 also can be employed to remedy mis-issuance. Throughout the 159 remainder of this document references to certificate revocation as a 160 remedy encompass this and analogous forms of browser behavior, if 161 available. Note: there are no IETF standards defining a browser 162 blacklist capability. 164 Note that a Subject can benefit from the Monitor function of CT even 165 if the Subject's certificate has not been logged. Monitoring of logs 166 for certificates issued in the Subject's name suffices to detect mis- 167 issuance targeting the Subject, if the bogus/erroneous certificate is 168 logged. 170 A relying party (e.g., browser) benefits from CT if it rejects a 171 bogus certificate, i.e., treats it as invalid. An RP is protected 172 from accepting a bogus certificate if that certificate is revoked, 173 and if the RP checks the revocation status of the certificate. (An 174 RP is also protected if a browser vendor "blacklists" a certificate 175 or "bad-CA-lists" a CA as noted above.) An RP also may benefit from 176 CT if the RP validates an SCT associated with a certificate, and 177 rejects the certificate if the Signed certificate Timestamp (SCT) 178 [I-D.ietf-trans-rfc6962-bis] is invalid. If an RP verified that a 179 certificate that claims to have been logged has a valid log entry, 180 the RP would have a higher degree of confidence that the certificate 181 is genuine. However, checking logs in this fashion imposes a burden 182 on RPs and on logs. Moreover, the existence of a log entry does not 183 ensure that the certificate is not mis-issued. Unless the 184 certificate Subject is monitoring the log(s) in question, a bogus 185 certificate will not be detected by CT mechanisms. Finally, if an RP 186 were to check logs for individual certificates, that would disclose 187 to logs the identity of web sites being visited by the RP, a privacy 188 violation. Thus this attack model does not assume that all RPs will 189 check log entries. 191 A CA benefits from CT when it detects a (mis-issued) certificate that 192 represents the same Subject name as a legitimate certificate issued 193 by the CA. 195 Note that all RPs may benefit from CT even if they do nothing with 196 SCTs. If Monitors inform Subjects of mis-issuance, and if a CA 197 revokes a certificate in response to a request from the certificate's 198 legitimate Subject, then an RP benefits without having to implement 199 any CT-specific mechanisms. 201 Also note that one proposal [I-D.ietf-trans-gossip] for distributing 202 Audit information (to detect misbehaving logs) calls for a browser to 203 send SCTs it receives to the corresponding website when visited by 204 the browser. If a website acquires an inclusion proof from a log for 205 each (unique) SCT it receives in this fashion, this would cause a 206 bogus SCT to be discovered, and, presumably, trigger a revocation 207 request. 209 Logging [I-D.ietf-trans-rfc6962-bis] is the central element of CT. 210 Logging enables a Monitor to detect a bogus certificate based on 211 reference information provided by the certificate Subject. Logging 212 of certificates is intended to deter mis-issuance, by creating a 213 publicly-accessible record that associates a CA with any certificates 214 that it mis-issues. Logging does not remedy mis-issuance; but it 215 does facilitate remediation by providing the information needed to 216 enable detection and consequently revocation of bogus certificates in 217 some circumstances. 219 Auditing is a function employed by CT to detect misbehavior by logs 220 and to deter mis-issuance that is abetted by misbehaving logs. 221 Auditing detects several types of log misbehavior, including failures 222 to adhere to the advertised Maximum Merge Delay (MMD) and Signed Tree 223 Head (STH) frequency count [I-D.ietf-trans-rfc6962-bis] violating the 224 append-only property, and providing inconsistent views of the log to 225 different log clients. The first three of these are relatively easy 226 for an individual auditor to detect, but the last form of misbehavior 227 requires communication among multiple log clients. Monitors ought 228 not trust logs that are detected misbehaving. Thus the Audit 229 function does not detect mis-issuance per se. The CT design 230 identifies audit functions designed to detect several types of 231 misbehavior. However, mechanisms to detect some forms of log 232 misbehavior are not yet standardized. 234 Figure 1 (below) illustrates the data exchanges among the major 235 elements of the CT system, based on the log specification 237 [I-D.ietf-trans-rfc6962-bis] and on the assumed behavior of other CT 238 system elements as described above. This Figure does not include the 239 Audit function, because there is not yet agreement on how that 240 function will work in a distributed, privacy-preserving fashion. 242 +----+ +---------+ +---------+ 243 | CA |---[ 1]-->| Log | ---[8]---| Monitor | 244 | | | | | | 245 | | --[ 2]---| |----[9]-->| | 246 | | | | | | 247 | |---[ 3]-->| | --[10]---| | 248 | | | | | |--------+ 249 | | --[ 4]---| |---[11]-->| | | 250 | | | | +---------+ | 251 | | | | | 252 | | | | +---------+ | 253 | | | | --[8]----| Self- | | 254 | | | | | Monitor | | 255 | | | |---[9]--->|(Subject)| | 256 | | | | | | | 257 | | | | --[10]---| | [12] 258 | | | | | | | 259 | | | |---[11]-->| | | 260 | | +---------+ +---------+ | 261 | | | 262 | | +---------+ +---------+ | 263 | |---[ 5]-->| Website |---[7]--->| Browser | | 264 | | |(Subject)| +---------+ | 265 | | --[ 6]-->| | ----------------------------+ 266 +----+ +---------+ 268 [ 1] Retrieve accepted root certs 269 [ 2] accepted root certs 270 [ 3] Add chain to log/add PreCertChain to log 271 [ 4] SCT 272 [ 5] send cert + SCTs (or cert with embedded SCTs) 273 [ 6] Revocation request/response (in response to detected 274 mis-issuance) 275 [ 7] cert + SCTs (or cert with embedded SCTs) 276 [ 8] Retrieve entries from Log 277 [ 9] returned entries from log 278 [10] Retrieve latest STH 279 [11] returned STH 280 [12] bogus/erroneous cert notification 282 Figure 1: Data Exchanges Between Major Elements of the CT System 284 Certificate mis-issuance may arise in one of several ways. The ways 285 by which CT enables a Subject (or others) to detect and redress mis- 286 issuance depends on the context and the entities involved in the mis- 287 issuance. This attack model applies to use of CT in the Web PKI 288 context. If CT is extended to apply to other contexts, each context 289 will require its own attack model, although most elements of the 290 model described here are likely to be applicable. 292 Because certificates are issued by CAs, the top level differentiation 293 in this analysis is whether the CA that mis-issued a certificate did 294 so maliciously or not. Next, for each scenario, the model considers 295 whether or not the certificate was logged. Scenarios are further 296 differentiated based on whether the logs and monitors are benign or 297 malicious and whether a certificate's Subject is self-monitoring or 298 is using a third party Monitoring service. Finally, the analysis 299 considers whether a browser is performing checking relevant to CT. 300 The scenarios are organized as illustrated by the following outline: 302 Web PKI CA - malicious vs non-malicious 303 Certificate - logged vs not logged 304 Log - benign vs malicious 305 Third party Monitor - benign vs malicious 306 Certificate's Subject - self-monitoring (or not) 307 Browser - CT-supporting (or not) 309 The next section of the document briefly discusses threats. 310 Subsequent sections examine each of the cases described above. As 311 noted earlier, the focus here is on the Web PKI context, although 312 most of the analysis is applicable to other PKI contexts. 314 1.1. Conventions used in this document 316 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 317 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 318 document are to be interpreted as described in [RFC2119]. 320 2. Threats 322 A threat is defined, traditionally, as a motivated, capable 323 adversary. An adversary who is not motivated to attack a system is 324 not a threat. An adversary who is motivated but not "capable" also 325 is not a threat. Threats change over time; new classes of 326 adversaries may arise, new motivations may come into play, and the 327 capabilities of adversaries may change. Nonetheless, it is useful to 328 document perceived threats against a system to provide a context for 329 understanding attacks. Even if the assumptions about adversaries 330 prove to be incorrect, documenting the assumptions is valuable. 332 As noted above, the goals of CT are to deter, detect, and facilitate 333 remediation of attacks on the web PKI. Such attacks can enable an 334 attacker to spoof the identity of TLS-enabled web sites. Spoofing 335 enables an adversary to perform many types of attacks, e.g., delivery 336 of malware to a client, reporting bogus information, or acquiring 337 information that a client would not communicate if the client were 338 aware of the spoofing. Such information may include personal 339 identification and authentication information and electronic payment 340 authorization information. Because of the nature of the information 341 that may be divulged (or misinformation or malware that may be 342 delivered), the principal adversaries in the CT context are perceived 343 to be (cyber) criminals and nation states. Both adversaries are 344 motivated to acquire personal identification and authentication 345 information. Criminals are also motivated to acquire electronic 346 payment authorization information. 348 To make use of forged web site certificates, an adversary must be 349 able to direct a TLS client to a spoofed web site, so that it can 350 present the forged certificate during a TLS handshake. An adversary 351 may achieve this in various ways, e.g., by manipulation of the DNS 352 response sent to a TLS client or via a man-in-the-middle attack. The 353 former type of attack is well within the perceived capabilities of 354 both classes of adversary. The latter attack may be possible for 355 criminals and is certainly a capability available to a nation state 356 within its borders. Nation states also may be able to compromise DNS 357 servers outside their own jurisdiction. 359 The elements of CT may themselves be targets of attacks, as described 360 below. A criminal organization might compromise a CA and cause it to 361 issue bogus certificates, or it may exert influence over a CA (or CA 362 staff) to do so, e.g., through extortion or physical threat. A CA 363 may be the victim of social engineering, causing it to issue a 364 certificate to an inappropriate Subject. (Even though the CA is not 365 intentionally malicious in this case, the action is equivalent to a 366 malicious CA, hence the use of the term "bogus" here.) A nation 367 state may operate or influence a CA that is part of the large set of 368 "root CAs" in browsers. A CA, acting in this fashion, is termed a 369 "malicious" CA. A nation state also might compromise a CA in another 370 country, to effect issuance of bogus certificates. In this case the 371 (non-malicious) CA, upon detecting the compromise (perhaps because of 372 CT) is expected to work with Subjects to remedy the mis-issuance. 374 A log also might be compromised by a suitably sophisticated criminal 375 organization or by a nation state. Compromising a log would enable a 376 compromised or rogue CA to acquire SCTs, but log entries would be 377 suppressed, either for all log clients or for targeted clients (e.g., 378 to selected Monitors or Auditors). It seems unlikely that a 379 compromised, non-malicious, log would persist in presenting multiple 380 views of its data, but a malicious log would. 382 Finally, note that a browser trust store may include a CA that is 383 intended to issue certificates to enable monitoring of encrypted 384 browser sessions. The inclusion of a trust anchor for such a CA is 385 intended to facilitate monitoring encrypted content, via an 386 authorized man-in-the-middle (MITM) attack. CT is not designed to 387 counter this type of locally-authorized interception. 389 3. Semantic mis-issuance 391 3.1. Non-malicious Web PKI CA context 393 In this section, we address the case where the CA has no intent to 394 issue a bogus certificate. 396 A CA may have mis-issued a certificate as a result of an error or, in 397 the case of a bogus certificate, because it was the victim of a 398 social engineering attack or an attack such as the one that affected 399 DigiNotar [https://www.vasco.com/company/about_vasco/press_room/ 400 news_archive/2011/news_diginotar_reports_any security_incident.aspx 401 ]. In the case of an error, the CA should have a record of the 402 erroneous certificate and be prepared to revoke this certificate once 403 it has discovered and confirmed the error. In the event of an 404 attack, a CA may have no record of a bogus certificate. 406 3.1.1. Certificate logged 408 3.1.1.1. Benign log 410 The log (or logs) is benign and thus is presumed to provide 411 consistent, accurate responses to requests from all clients. 413 If a bogus (pre-)certificate has been submitted to one or more logs 414 prior to issuance to acquire an embedded SCT, or post-issuance to 415 acquire a standalone SCT, detection of this mis-issuance is the 416 responsibility of a Monitor. 418 3.1.1.1.1. Self-monitoring Subject 420 If a Subject is tracking the log(s) to which a certificate was 421 submitted, and is performing self-monitoring, then it will be able to 422 detect a bogus (pre-)certificate and request revocation. In this 423 case, the CA will make use of the log entry (supplied by the Subject) 424 to determine the serial number of the bogus certificate, and 425 investigate/revoke it. (See Sections 5.1, 5.2 and 5.3.) 427 3.1.1.1.2. Benign third party Monitor 429 If a benign third party monitor is checking the logs to which a 430 certificate was submitted and is protecting the targeted Subject, it 431 will detect a bogus certificate and will alert the Subject. The 432 Subject, in turn, will ask the CA to revoke the bogus certificate. 433 In this case, the CA will make use of the log entry (supplied by the 434 Subject) to determine the serial number of the bogus certificate, and 435 revoke it (after investigation). (See Sections 5.1, 5.2 and 5.3.) 437 3.1.1.2. Misbehaving log 439 In this case, the bogus (pre-)certificate has been submitted to one 440 or more logs, each of which generate an SCT for the submission. A 441 misbehaving log probably will suppress a bogus certificate log entry, 442 or it may create an entry for the certificate but report it 443 selectively. (A misbehaving log also could create and report entries 444 for bogus certificates that have not been issued by the indicated CA 445 (hereafter called "fake"). Unless a Monitor validates the associated 446 certificate chains up to roots that it trusts, these fake bogus 447 certificates could cause the Monitors to report non-existent semantic 448 problems to the Subject who would in turn report them to the 449 purported issuing CA. This might cause the CA to do needless 450 investigative work or perhaps incorrectly revoke and re-issue the 451 Subject's real certificate. Note that for every certificate 452 submitted to a log, the log MUST verify a complete certificate chain 453 up to one of the roots it accepts. So creating a log entry for a 454 fake bogus certificate marks the log as misbehaving. 456 3.1.1.2.1. Self-monitoring Subject & Benign third party Monitor 458 If a misbehaving log suppresses a bogus certificate log entry, a 459 Subject performing self-monitoring will not detect the bogus 460 certificate. CT relies on an Audit mechanism to detect log 461 misbehavior, as a deterrent. It is anticipated that logs that are 462 identified as persistently misbehaving will cease to be trusted by 463 Monitors, non-malicious CAs, and by browser vendors. This assumption 464 forms the basis for the perceived deterrent. It is not clear if 465 mechanisms to detect this sort of log misbehavior will be viable. 467 Similarly, when a misbehaving log suppresses a bogus certificate log 468 entry (or report such entries inconsistently) a benign third party 469 Monitor that is protecting the targeted Subject also will not detect 470 a bogus certificate. In this scenario, CT relies on a distributed 471 Auditing mechanism [I-D.ietf-trans-gossip] to detect log misbehavior, 472 as a deterrent. (See Section 5.6 below.) However, a Monitor (third- 473 party or self) must participate in the Audit mechanism in order to 474 become aware of log misbehavior. 476 If the misbehaving log has logged the bogus certificate when issuing 477 the associated SCT, it will try to hide this from the Subject (if 478 self-monitoring) or from the Monitor protecting the Subject. It does 479 so by presenting them with a view of its log entries and STH that 480 does not contain the bogus certificate. To other entities, the log 481 presents log entries and an STH that include the bogus certificate. 482 This discrepancy can be detected if there is an exchange of 483 information about the log entries and STH between the entities 484 receiving the view that excludes the bogus certificate and entities 485 that receive a view that includes it, i.e., a distributed Audit 486 mechanism. 488 If a malicious log does not create an entry for a bogus certificate 489 (for which an SCT has been issued), then any Monitor/Auditor that 490 sees the bogus certificate will detect this when it checks with the 491 log for log entries and STH (see Section 3.1.2.) 493 3.1.1.3. Misbehaving third party Monitor 495 A third party Monitor that misbehaves will not notify the targeted 496 Subject of a bogus certificate. This is true irrespective of whether 497 the Monitor checks the logs or whether the logs are benign or 498 malicious/conspiring. 500 Note that independent of any mis-issuance on the part of the CA, a 501 misbehaving Monitor could issue false warnings to a Subject that it 502 protects. These could cause the Subject to report non-existent 503 semantic problems to the issuing CA and cause the CA to do needless 504 investigative work or perhaps incorrectly revoke and re-issue the 505 Subject's certificate. 507 3.1.2. Certificate not logged 509 If the CA does not submit a pre-certificate to a log, whether a log 510 is benign or misbehaving does not matter. The same is true if a 511 Subject is issued a certificate without an SCT and does not log the 512 certificate itself, to acquire an SCT. Also, since there is no log 513 entry in this scenario, there is no difference in outcome between a 514 benign and a misbehaving third party Monitor. In both cases, no 515 Monitor (self or third-party) will detect a bogus certificate based 516 on Monitor functions and there will be no consequent reporting of the 517 problem to the Subject or by the Subject to the CA based on 518 examination of log entries. 520 3.1.2.1. Self-monitoring Subject 522 A Subject performing self-monitoring will be able to detect the lack 523 of an embedded SCT in the certificate it received from the CA, or the 524 lack of an SCT supplied to the Subject via an out-of-band channel. A 525 Subject ought to notify the CA if the Subject expected that its 526 certificate was to be logged. (A Subject would expect its 527 certificate to be logged if there is an agreement between the Subject 528 and the CA to do so, or because the CA advertises that it logs all of 529 the certificates that it issues.) If the certificate was supposed to 530 be logged, but was not, the CA can use the certificate supplied by 531 the Subject to investigate and remedy the problem. In the context of 532 a benign CA, a failure to log the certificate might be the result of 533 an operations error, or evidence of an attack on the CA. 535 3.1.2.2. CT-enabled browser 537 If a browser rejects certificates without SCTs (see Section 5.4), CAs 538 may be "encouraged" to log the certificates they issue. This, in 539 turn, would make it easier for Monitors to detect bogus certificates. 540 However, the CT architecture does not describe how such behavior by 541 browsers can be deployed incrementally throughout the Internet. As a 542 result, this attack model does not assume that browsers will reject a 543 certificate that is not accompanied by an SCT. In the CT 544 architecture certificates have to be logged to enable Monitors to 545 detect mis-issuance, and to trigger subsequent revocation 546 [I-D.kent-trans-architecture]. Thus the effectiveness of CT is 547 diminished in this context. 549 3.2. Malicious Web PKI CA context 551 In this section, we address the scenario in which the mis-issuance is 552 intentional, not due to error. The CA is not the victim but the 553 attacker. 555 3.2.1. Certificate logged 557 3.2.1.1. Benign log 559 A bogus (pre-)certificate may be submitted to one or more benign logs 560 prior to issuance, to acquire an embedded SCT, or post-issuance to 561 acquire a standalone SCT. The log (or logs) replies correctly to 562 requests from clients. 564 3.2.1.1.1. Self-monitoring Subject 566 If a Subject is checking the logs to which a certificate was 567 submitted and is performing self-monitoring, it will be able to 568 detect the bogus certificate and will request revocation. The CA may 569 refuse to revoke, or may substantially delay revoking, the bogus 570 certificate. For example, the CA could make excuses about inadequate 571 proof that the certificate is bogus, or argue that it cannot quickly 572 revoke the certificate because of legal concerns, etc. In this case, 573 the CT mechanisms will have detected mis-issuance, but the 574 information logged by CT may not suffice to remedy the problem. (See 575 Sections 4 and 6.) 577 A malicious CA might revoke a bogus certificate to avoid having 578 browser vendors take punitive action against the CA and/or to 579 persuade them to not enter the bogus certificate on a vendor- 580 maintained blacklist. However, the CA might provide a "good" OCSP 581 response (from a server it operates) to a targeted browser instance 582 as a way to circumvent the remediation nominally offered by 583 revocation. No component of CT is tasked with detecting this sort of 584 misbehavior by a CA. (The misbehavior is analogous to a log offering 585 split views to different clients, as discussed later. The Audit 586 element of CT is tasked with detecting this sort of attack.) 588 3.2.1.1.2. Benign third party Monitor 590 If a benign third party monitor is checking the logs to which a 591 certificate was submitted and is protecting the targeted Subject, it 592 will detect the bogus certificate and will alert the Subject. The 593 Subject will then ask the CA to revoke the bogus certificate. As in 594 3.2.1.1.1, the CA may or may not revoke the certificate and it might 595 revoke the certificate but provide "good" OCSP responses to a 596 targeted browser instance. 598 3.2.1.2. Misbehaving log 600 A bogus (pre-)certificate may have been submitted to one or more logs 601 that are misbehaving, e.g., conspiring with an attacker. These logs 602 may or may not issue SCTs, but will hide the log entries from some or 603 all Monitors. 605 3.2.1.2.1. Monitors - third party and self 607 If log entries are hidden from a Monitor (third party or self), the 608 Monitor will not be able to detect issuance of a bogus certificate. 610 The Audit function of CT is intended to detect logs that conspire to 611 delay or suppress log entries (potentially selectively), based on 612 consistency checking of logs. (See 3.1.1.2.2.) If a Monitor learns 613 of misbehaving log operation, it alerts the Subjects that it is 614 protecting, so that they no longer acquire SCTs from that log. The 615 Monitor also avoids relying upon such a log in the future. However, 616 unless a distributed Audit mechanism proves effective in detecting 617 such misbehavior, CT cannot be relied upon to detect this form of 618 mis-issuance. (See Section 5.6 below.) 620 3.2.1.3. Misbehaving third party Monitor 622 If the third party Monitor that is "protecting" the targeted Subject 623 is misbehaving, then it will not notify the targeted Subject of any 624 mis-issuance or of any malfeasant log behavior that it detects 625 irrespective of whether the logs it checks are benign or malicious/ 626 conspiring. The CT architecture does not include any measures to 627 detect misbehavior by third-party monitors. 629 3.2.2. Certificate not logged 631 Because the CA is presumed malicious, it may choose to not submit a 632 (pre-)certificate to a log. This means there is no SCT for the 633 certificate. 635 When a CA does not submit a certificate to a log, whether a log is 636 benign or misbehaving does not matter. Also, since there is no log 637 entry, there is no difference in behavior between a benign and a 638 misbehaving third-party Monitor. Neither will report a problem to 639 the Subject. 641 A bogus certificate would not be delivered to the legitimate Subject. 642 So the Subject, acting as a self-Monitor, cannot detect the issuance 643 of a bogus certificate in this case. 645 3.2.2.1. CT-aware browser 647 If careful browsers reject certificates without SCTs, CAs may be 648 "encouraged" to log certificates (see section 5.4.) However, the CT 649 architecture does not describe how such behavior by browsers can be 650 deployed incrementally throughout the Internet. As a result, this 651 attack model does not assume that browsers will reject a certificate 652 that is not accompanied by an SCT. Since certificates have to be 653 logged to enable detection of mis-issuance by Monitors, and to 654 trigger subsequent revocation, the effectiveness of CT is diminished 655 in this context. 657 3.3. Undetected Compromise of CAs or Logs 659 Sections 3.1 and 3.2 examined attacks in the context of non-malicious 660 and malicious CAs, and benign and misbehaving logs. Another class of 661 attacks might occur in the context of a non-malicious CA and/or a 662 benign log. Specifically these CT elements might be compromised and 663 the compromise might go undetected. Compromise of CAs and logs was 664 noted in Section 2, as was coercion of a CA. As noted there, a 665 compromised CA is essentially a malicious CA, and thus the 666 discussions in Section 3.2 are applicable. Section 3.3 explored the 667 undetected compromise of a CA in the context of attacks designed to 668 issue a bogus certificate that might avoid revocation (because the 669 certificate would appear on distinct certificate paths). 671 The section focuses on undetected compromise of CAs. Such 672 compromises warrant some additional discussion, since some relying 673 parties may see signed objects issued by the legitimate (non- 674 malicious) CA, others may see signed objects from its compromised 675 counterpart, and some may see objects from both. In the case of a 676 compromised CA or log the adversary is presumed to have access to the 677 private key used by a CA to sign certificates, or used by a log to 678 sign SCTs and STHs. Because the compromise is undetected, there will 679 be no effort by a CA to have its certificate revoked or by a log to 680 shut down the log. 682 3.3.1. Compromised CA, Benign Log 684 In the case of a compromised (non-malicious) CA, an attacker uses the 685 purloined private key to generate a bogus certificate (that the 686 compromised CA would not issue). If this certificate is submitted to 687 a (benign) log, then it subject to detection by a Monitor, as 688 discussed in 3.1.1.1. If the bogus certificate is submitted to a 689 misbehaving log, then an SCT can be generated, but there will be no 690 entry for it, as discussed in 3.1.1.2. If the bogus certificate is 691 not logged, then there will be no SCT, and the implications are as 692 described in 3.1.2. 694 This sort of attack may be most effective if the CA that is the 695 victim of the attack has issued a certificate for the targeted 696 Subject. In this case the bogus certificate will then have the same 697 certification path as the legitimate certificate, which may help hide 698 the bogus certificate. However, means of remedying the attack are 699 independent of this aspect, i.e., revocation can be effected 700 irrespective of whether the targeted Subject received its certificate 701 from the compromised CA. 703 A compromised (non-malicious) CA may be able to revoke the bogus 704 certificate if it is detected by a Monitor, and the targeted Subject 705 has been notified. It can do so only when the serial number of the 706 bogus certificate is made known to this CA and assuming that the 707 bogus certificate was not issued with an Authority Information Access 708 (AIA) or CRL Distribution Point (CRL DP) extension that enables only 709 the malicious twin to revoke the certificate. (The AIA extension in 710 the bogus certificate could be used to direct relying parties to an 711 OCSP server controlled by the malicious twin. The CRL DP extension 712 could be used to direct relying parties to a CRL controlled by the 713 malicious twin.) If the bogus certificate contains either extension, 714 the compromised CA cannot effectively revoke it. However, the 715 presence of either of these extensions provides some evidence that an 716 entity other than the compromised CA issued the certificate in 717 question. (If the extensions differ from those in other certificates 718 issued by the compromised CA, that is suspicious.) 720 If the serial number of the bogus certificate is the same as for a 721 valid, not-expired certificate issued by the CA (to the target or to 722 another Subject), then revocation poses a problem. This is because 723 revocation of the bogus certificate will also invalidate a legitimate 724 certificate. This problem may cause the compromised CA to delay 725 revocation, thus allowing the bogus certificate to remain a danger 726 for a longer time. 728 The compromised CA may not realize that the bogus certificate was 729 issued by a malicious twin; one occurrence of this sort might be 730 regarded as an error, and not cause the CA to transition to a new key 731 pair. (This assumes that the bogus certificate does not contain an 732 AIA or CRL DP extension that wrests control of revocation from the 733 compromised CA.) If the compromised CA does determine that its 734 private key has been stolen, it probably will take some time to 735 transition to a new key pair, and reissue certificates to all of its 736 legitimate Subjects. Thus an attack of this sort probably will take 737 a while to be remedied. 739 Also note that the malicious twin of the compromised CA may be 740 capable of issuing its own CRL or OCSP responses, without changing 741 any AIA/CRL DP data present in the targeted certificate. The 742 revocation status data from the evil twin will appear as valid as 743 those of the compromised CA. If the attacker has the ability to 744 control the sources of revocation status data available to a targeted 745 user (browser instance), then the user may not become aware of the 746 attack. 748 A bogus certificate issued by the malicious CA will not match the SCT 749 for the legitimate certificate, since they are not identical, e.g., 750 at a minimum the private keys do not match. Thus a CT-aware browser 751 that rejects certificates without SCTs (see 3.1.2.2) will reject a 752 bogus certificate created under these circumstances if it is not 753 logged. If the bogus certificate is detected and logged, browsers 754 that require an SCT will reject the bogus certificate. 756 3.3.2. Benign CA, Compromised Log 758 A benign CA does not issue bogus certificates, except as a result of 759 an accident or attack. So, in normal operation, it is not clear what 760 behavior by a compromised log would yield an attack. If a bogus 761 certificate is issued by a benign CA (under these circumstances) is 762 submitted to a compromised (non-malicious) log, then both an SCT and 763 a log entry will be created. Again, it is not clear what additional 764 adverse actions the compromised log would perform to further an 765 attack on CT. 767 It is worth noting that if a benign CA was attacked and thus issued 768 one or more bogus certificates, then a malicious log might provide 769 split views of its log to help conceal the bogus certificate from 770 targeted users. Specifically, the log would show an accurate set of 771 log entries (and STHs) to most clients, but would maintain a separate 772 log view for targeted users. This sort of attack motivates the need 773 for Audit capabilities based on "gossiping" [I-D.ietf-trans-gossip]. 774 However, even if such mechanisms are employed, they might be thwarted 775 if a user is unable to exchange log information with trustworthy 776 partners. 778 3.3.3. Compromised CA, Compromised Log 780 As noted in 3.4.1, an evil twin CA may issue a bogus certificate that 781 contains the same Subject name as a legitimate certificate issued by 782 the compromised CA. Alternatively, the bogus certificate may contain 783 a different name but reuse a serial number from a valid, not revoked 784 certificate issued by that CA. 786 An attacker who compromises a log might act in one of two ways. It 787 might use the private key of the log only to generate SCTs for a 788 malicious CA or the evil twin of a compromised CA. If a browser 789 checks the signature on an SCT but does not contact a log to verify 790 that the certificate appears in the log, then this is an effective 791 attack strategy. Alternatively, the attacker might not only generate 792 SCTs, but also pose as the compromised log, at least with regard to 793 requests from targeted users. In the latter case, this "evil twin" 794 log could respond to STH requests from targeted users, making appear 795 that the compromised log was offering a split view (thus acting as a 796 malicious log). To detect this attack an Auditor needs to employ a 797 gossip mechanism that is able to acquire CT data from diverse 798 sources, a feature not yet part of the base CT system. 800 An evil twin CA might submit a bogus certificate to the evil twin of 801 a compromised log. (The same adversary may be controlling both.) 802 The operator of the evil twin log can use the purloined private key 803 to generate SCTs for certificates that have not been logged by its 804 legitimate counterpart. These SCTs will appear valid relative to the 805 public key associated with the legitimate log. However, an STH 806 issued by the legitimate log will not correspond to a tree 807 (maintained by the compromised log) containing these SCTs. Thus 808 checking the SCTs issued by the evil twin log against STHs from the 809 compromised log will identify this discrepancy. As noted above, if 810 an attacker uses the key to generate log entries and respond to log 811 queries, the effect is analogous to a malicious log.) 813 An Auditor checking for log consistency and with access to bogus 814 SCTs, might conclude that the compromised log is acting maliciously, 815 and is presenting a split view to its clients. In this fashion the 816 compromised log may be shunned and forced to shut down. However, if 817 an attacker targets a set of TLS clients that do not have access to 818 the legitimate log, they may not be able to detect this 819 inconsistency. In this case CT would need to rely on a distributed 820 gossiping audit mechanism to detect the compromise (see Section 5.6). 822 3.4. Attacks Based on Exploiting Multiple Certificate Chains 824 Section 3.2 examined attacks in which a malicious CA issued a bogus 825 certificate and either tried to prevent the Subject from detecting 826 the bogus certificate, or reported the bogus certificate as valid, to 827 at least some relying parties, even if the Subject requested 828 revocation. These attacks are limited in that if the bogus 829 certificate is not submitted to a log, then it may not be accepted by 830 CT-aware browsers, and submitting the bogus certificate to a log 831 increases the chances that the CA's malicious behavior will be 832 detected. 834 In general, if a CA is discovered to be acting maliciously, its 835 certificates will no longer be accepted, either because its parent 836 will revoke its CA certificate, its CA certificate will be added to 837 browsers' blacklists, or both. However, a malicious CA may be able 838 to obtain an SCT for each bogus certificate that it issues and 839 continue to have those certificates accepted by relying parties even 840 after its malicious behavior has been detected. It can do this by 841 creating more than one path validation chain for the certificates, as 842 shown in Figure 2. 844 +-----------------+ +-----------------+ 845 | CA A | | CA B | 846 +-----------------+ +-----------------+ 847 \ / 848 \ / 849 CA certificate 1 \ / CA certificate 2 850 \ / 851 +----------------+ 852 | malicious CA | 853 +----------------+ 854 | 855 | bogus EE certificate 856 | 857 +------------------+ 858 | targeted Subject | 859 +------------------+ 861 Figure 2: Multiple Certificate Chains for a Bogus Certificate 863 In Figure 2, the malicious CA has been issued CA certificates by two 864 different parent CAs. The parent CAs may be two different trust 865 anchors, or one or both of them may be an intermediate CA (i.e., it 866 is subordinate to some trust anchor). If both parent CAs are 867 intermediate CAs, they may be subordinate to the same trust anchor or 868 to different trust anchors. The malicious CA may have obtained 869 certificates from the two parents by applying to them for the 870 certificates, or by compromising the parent CAs and creating the 871 certificates without the knowledge of the CAs. If the malicious CA 872 applied for its certificates from these CAs, it may have presented 873 credentials that cause each parent to believe that the parent is 874 dealing with a different CA, despite the fact that the CA name and 875 public key are identical. 877 Because there are two certificate path validation chains, the 878 malicious CA could provide the chain that includes CA A when 879 submitting a bogus certificate to one or more logs, but an attacker 880 (colluding with the malicious CA) could provide the chain that 881 includes CA B to targeted browsers. If the CA's malicious behavior 882 is detected, then CA A and browser vendors may be alerted (e.g., via 883 the CT Monitor function) and revoke/blacklist CA certificate 1. 884 However, CA certificate 2 does not appear in any logs, and CA A is 885 unaware that CA B has issued a certificate to the malicious CA. Thus 886 those who detected the malicious behavior may not discover the second 887 chain and so may not alert CA B or browser vendors of the need to 888 revoke/blacklist CA certificate 2. In this case, targeted browsers 889 would continue to accept the bogus certificates issued by the 890 malicious CA, since the certificate chain they are provided is valid 891 and because the SCT issued for the bogus certificate it the same 892 irrespective of which certificate chain is presented. 894 3.5. Attacks Related to Distribution of Revocation Status 896 A bogus certificate that has been revoked may still appear valid to a 897 browser under certain circumstances. In part this is because 898 certificate revocation generally depends on the certificate path 899 (chain) used by a relying party when validating a certificate. This 900 is true irrespective of whether revocation is effected via use of a 901 CRL or OCSP. Additionally, an attacker can steer a browser to 902 specific revocation status data via various means, preventing a 903 targeted browser from acquiring accurate revocation status 904 information for a bogus certificate. 906 The bogus certificate might contain an AIA extension pointing to an 907 OCSP server controlled by the malicious CA (or the attacker). As 908 noted in Section 3.2.1.1.1, the malicious CA could send a "good" OCSP 909 response to a targeted browser instance, even if other parties are 910 provided with a "revoked" response. A TLS server can supply an OCSP 911 response to a browser as part of the TLS handshake [RFC6961], if 912 requested by the browser. A TLS server posing as the entity named in 913 the bogus certificate also could acquire a "good" OCSP response from 914 the malicious CA to effect the attack. Only if the browser relies 915 upon a trusted, third-party OCSP responder, one not part of the 916 collusion, would these OCSP-based attacks fail. 918 The bogus certificate could contain a CRL distribution point 919 extension instead of an AIA extension. In that case a site supplying 920 CRLs for the malicious CA could supply different CRLs to different 921 requestors, in an attempt to hide the revocation status of the bogus 922 certificate from targeted browser instances. This is analogous to a 923 split-view attack effected by a CT log. However, as noted in 924 Section 3.2.1.1 and 3.2.1.1.1, no element of CT is responsible for 925 detecting inconsistent reporting of certificate revocation status 926 data. (Monitoring in the CT context tracks log entries made by CAs 927 or Subjects. Auditing is designed to detect misbehavior by logs, not 928 by CAs per se.) 930 The failure of a bogus certificate to be detected as revoked (by a 931 browser) is not the fault of CT. In the class of attacks described 932 above, CT achieves its goal of detecting the bogus certificate when 933 that certificate is logged and a Monitor observes the log entry. 934 Detection is intended to trigger revocation, to effect remediation, 935 the details of which are outside the scope of CT. However the SCT 936 mechanism is intended to assure a relying party that certificate has 937 been logged, is susceptible to being detected as bogus by a Monitor, 938 and presumably will be revoked if detected as such. In the context 939 of these attacks, because of the way revocation may be implemented, 940 the assurance provided by the SCT may not have the anticipated 941 effect. 943 This type of attack might be thwarted in several ways. For example, 944 if all intermediate (i.e., CA) certificates had to be logged, then CA 945 certificate 2 might be rejected by CT-aware browsers. If a malicious 946 CA is discovered, a browser vendor might blacklist it by public key 947 (not by its serial number and the name of the parent CA or by a hash 948 of the certificate). This approach to revocation would cause CA 949 certificate 2 to be rejected as well as CA certificate 1. However 950 none of these mechanisms are part of the CT specification 951 [I-D.ietf-trans-rfc6962-bis] nor general IETF PKI standards (e.g., 952 [RFC5280]). 954 4. Syntactic mis-issuance 956 4.1. Non-malicious Web PKI CA context 958 This section analyzes the scenario in which the CA has no intent to 959 issue a syntactically incorrect certificate. As noted in Section 1, 960 we refer to a syntactically incorrect certificate as erroneous. 962 4.1.1. Certificate logged 964 4.1.1.1. Benign log 966 If a (pre )certificate is submitted to a benign log, syntactic mis- 967 issuance can (optionally) be detected, and noted. This will happen 968 only if the log performs syntactic checks in general, and if the log 969 is capable of performing the checks applicable to the submitted (pre 970 )certificate. (A (pre )certificate SHOULD be logged even if it fails 971 syntactic validation; logging takes precedence over detection of 972 syntactic mis-issuance.) If syntactic validation fails, this can be 973 noted in an SCT extension returned to the submitter. 975 If the (pre )certificate is submitted by the non-malicious issuing 976 CA, then the CA SHOULD remedy the syntactic problem and re-submit the 977 (pre )certificate to a log or logs. If this is a pre-certificate 978 submitted prior to issuance, syntactic checking by a log helps avoid 979 issuance of an erroneous certificate. If the CA does not have a 980 record of the certificate contents, then presumably it was a bogus 981 certificate and the CA SHOULD revoke it. 983 If a certificate is submitted by its Subject, and is deemed 984 erroneous, then the Subject SHOULD contact the issuing CA and request 985 a new certificate. If the Subject is a legitimate subscriber of the 986 CA, then the CA will either have a record of the certificate content 987 or can obtain a copy of the certificate from the Subject. The CA 988 will remedy the syntactic problem and either re-submit a corrected 989 (pre-)certificate to a log and send it to the Subject or the Subject 990 will re-submit it to a log. Here too syntactic checking by a log 991 enables a Subject to be informed that its certificate is erroneous 992 and thus may hasten issuance of a replacement certificate. 994 If a certificate is submitted by a third party, that party might 995 contact the Subject or the issuing CA, but because the party is not 996 the Subject of the certificate it is not clear how the CA will 997 respond. 999 This analysis suggests that syntactic mis-issuance of a certificate 1000 can be avoided by a CA if it makes use of logs that are capable of 1001 performing these checks for the types of certificates that are 1002 submitted, and if the CA acts on the feedback it receives. If a CA 1003 uses a log that does not perform such checks, or if the CA requests 1004 checking relative to criteria not supported by the log, then 1005 syntactic mis-issuance will not be detected or avoided by this 1006 mechanism. Similarly, syntactic mis-issuance can be remedied if a 1007 Subject submits a certificate to a log that performs syntactic 1008 checks, and if the Subject asks the issuing CA to fix problems 1009 detected by the log. (The issuer is presumed to be willing to re- 1010 issue the certificate, correcting any problems, because the issuing 1011 CA is not malicious.) 1013 4.1.1.2. Misbehaving log or third party Monitor 1015 A log or Monitor that is conspiring with the attacker or is 1016 independently malicious, will either not perform syntactic checks, 1017 even though it claims to do so, or simply not report errors. The log 1018 entry and the SCT for an erroneous certificate will assert that the 1019 certificate syntax was verified. 1021 As with detection of semantic mis-issuance, a distributed Audit 1022 mechanism could, in principle, detect misbehavior by logs or Monitors 1023 with respect to syntactic checking. For example, if for a given 1024 certificate, some logs (or Monitors) are reporting syntactic errors 1025 and some that claim to do syntactic checking, are not reporting these 1026 errors, this is indicative of misbehavior by these logs and/or 1027 Monitors. 1029 Note that a malicious log (or Monitor) could report syntactic errors 1030 for a syntactically valid certificate. This could result in 1031 reporting of non-existent syntactic problems to the issuing CA, which 1032 might cause the CA to do needless investigative work or perhaps 1033 incorrectly revoke and re-issue the Subject's certificate. 1035 4.1.1.3. Self-monitoring Subject and Benign third party Monitor 1037 If a Subject or benign third party Monitor performs syntactic checks, 1038 it will detect the erroneous certificate and the issuing CA will be 1039 notified (by the Subject). If the Subject is a legitimate subscriber 1040 of the CA, then the CA will either have a record of the certificate 1041 content or can obtain a copy of the certificate from the Subject. 1042 The CA SHOULD revoke the erroneous certificate (after investigation) 1043 and remedy the syntactic problem. The CA SHOULD either re-submit the 1044 corrected (pre )certificate to one or more logs and then send the 1045 result to the Subject, or send the corrected certificate to the 1046 Subject, who will re-submit it to one or more logs. 1048 4.1.1.4. CT-enabled browser 1050 If a browser rejects an erroneous certificate and notifies the 1051 Subject and/or the issuing CA, then syntactic mis-issuance will be 1052 detected (see Section 5.) Unfortunately, experience suggests that 1053 many browsers do not perform thorough syntactic checks on 1054 certificates, and so it seems unlikely that browsers will be a 1055 reliable way to detect erroneous certificates. Moreover, a protocol 1056 used by a browser to notify a Subject and/or CA of an erroneous 1057 certificate represents a DoS potential, and thus may not be 1058 appropriate. Additionally, if a browser directly contacts a CA when 1059 an erroneous certificate is detected, this is a potential privacy 1060 violation, i.e., the CA learns that the browser user is visiting the 1061 web site in question. These observations argue for syntactic 1062 checking to be performed by other elements of the CT system, e.g., 1063 logs and/or Monitors. 1065 4.1.2. Certificate not logged 1067 If a CA does not submit a certificate to a log, there can be no 1068 syntactic checking by the log. Detection of syntactic errors will 1069 depend on a Subject performing the requisite checks when it receives 1070 its certificate from a CA. A Monitor that performs syntactic checks 1071 on behalf of a Subject also could detect such problems, but the CT 1072 architecture does not require Monitors to perform such checks. 1074 4.2. Malicious Web PKI CA context 1076 This section analyzes the scenario in which the CA's issuance of a 1077 syntactically incorrect certificate is intentional, not due to error. 1078 The CA is not the victim but the attacker. 1080 4.2.1. Certificate logged 1082 4.2.1.1. Benign log 1084 Because the CA is presumed to be malicious, the CA may cause the log 1085 to not perform checks, in one of several ways. (See 1086 [I-D.kent-trans-domain-validation-cert-checks] and 1087 [I-D.kent-trans-extended-validation-cert-checks] for more details on 1088 validation checks and CCIDs). 1090 1. The CA may assert that the certificate is being issued w/o regard 1091 to any guidelines (the "no guidelines" reserved CCID). 1093 2. The CA may assert a CCID that has not been registered, and thus 1094 no log will be able to perform a check. 1096 3. The CA may check to see which CCIDs a log declares it can check, 1097 and chose a registered CCID that is not checked by the log in 1098 question. 1100 4. The CA may submit a (pre-) certificate to a log that is known to 1101 not perform any syntactic checks, and thus avoid syntactic 1102 checking. 1104 4.2.1.2. Misbehaving log or third party Monitor 1106 A misbehaving log or third party Monitor will either not perform 1107 syntactic checks or not report any problems that it discovers. (See 1108 4.1.1.2 for further problems). Also, as noted above, the CT 1109 architecture includes no explicit provisions for detecting a 1110 misbehaving third-party Monitor. 1112 4.2.1.3. Self-monitoring Subject and Benign third party Monitor 1114 Irrespective of whether syntactic checks are performed by a log, a 1115 malicious CA will acquire an embedded SCT, or post-issuance will 1116 acquire a standalone SCT. If Subjects or Monitors perform syntactic 1117 checks that detect the syntactic mis-issuance and report the problem 1118 to the CA, a malicious CA may do nothing or may delay the action(s) 1119 needed to remedy the problem. 1121 4.2.1.4. CT-enabled browser 1123 As noted above (4.1.1.4), most browsers fail to perform thorough 1124 syntax checks on certificates. Such browsers might benefit from 1125 having syntax checks performed by a log and reported in the SCT, 1126 although the pervasive nature of syntactically-defective certificates 1127 may limit the utility of such checks. (Remember, in this scenario, 1128 the log is benign.) However, if a browser does not discriminate 1129 against certificates that do not contain SCTs (or that are not 1130 accompanied by an SCT in the TLS handshake), only minimal benefits 1131 might accrue to the browser from syntax checks perform by logs or 1132 Monitors. 1134 If a browser accepts certificates that do not appear to have been 1135 syntactically checked by a log (as indicated by the SCT), a malicious 1136 CA need not worry about failing a log-based check. Similarly, if 1137 there is no requirement for a browser to reject a certificate that 1138 was logged by an operator that does not perform syntactic checks, the 1139 fourth attack noted in 4.2.1.1 will succeed as well. If a browser 1140 were configured to know which versions of certificate types are 1141 applicable to its use of a certificate, the second and third attack 1142 strategies noted above could be thwarted. 1144 4.2.2. Certificate is not logged 1146 Since certificates are not logged in this scenario, a Monitor (third- 1147 party or self) cannot detect the issuance of an erroneous 1148 certificate. Thus there is no difference between a benign or a 1149 malicious/conspiring log or a benign or conspiring/malicious Monitor. 1150 (A Subject MAY detect a syntax error by examining the certificate 1151 returned to it by the Issuer.) However, even if errors are detected 1152 and reported to the CA, a malicious/conspiring CA may do nothing to 1153 fix the problem or may delay action. 1155 5. Issues Applicable to Sections 3 and 4 1157 5.1. How does a Subject know which Monitor(s) to use? 1159 If a CA submits a bogus certificate to one or more logs, but these 1160 logs are not tracked by a Monitor that is protecting the targeted 1161 Subject, CT will not remedy this type of mis-issuance attack. If 1162 third-party Monitors advertise which logs they track, Subjects may be 1163 able to use this information to select an appropriate Monitor (or set 1164 thereof). Also, it is not clear whether every third-party Monitor 1165 MUST offer to track every Subject that requests protection. If a 1166 Subject acts as its own Monitor, this problem is solved for that 1167 Subject. 1169 5.2. How does a Monitor discover new logs? 1171 It is not clear how a (self-)Monitor becomes aware of all (relevant) 1172 logs, including newly created logs. The means by which Monitors 1173 become aware of new logs MUST accommodate self-monitoring by a 1174 potentially very large number of web site operators. If there are 1175 many logs, it may not be feasible for a (self-) Monitor to track all 1176 of them, or to determine what set of logs suffice to ensure an 1177 adequate level of coverage. 1179 5.3. CA response to report of a bogus or erroneous certificate 1181 A CA being presented with evidence of a bogus or erroneous 1182 certificate, in the form of a log entry and/or SCT, will need to 1183 examine its records to determine if it has knowledge of the 1184 certificate in question. It also will likely require the targeted 1185 Subject to provide assurances that it is the authorized entity 1186 representing the Subject name (subjectAltname) in question. Thus a 1187 Subject should not expect immediate revocation of a contested 1188 certificate. The time frame in which a CA will respond to a 1189 revocation request usually is described in the CPS for the CA. Other 1190 certificate fields and extensions may be of interest for forensic 1191 purposes, but are not required to effect revocation nor to verify 1192 that the certificate to be revoked is bogus or erroneous, based on 1193 applicable criteria. The SCT and log entry, because each contains a 1194 timestamp from a third party, is probably valuable for forensic 1195 purposes (assuming a non-conspiring log operator). 1197 5.4. Browser behavior 1199 If a browser is to reject a certificate that lacks an embedded SCT, 1200 or is not accompanied by an SCT transported via the TLS handshake, 1201 this behavior needs to be defined in a way that is compatible with 1202 incremental deployment. Issuing a warning to a (human) user is 1203 probably insufficient, based on experience with warnings displayed 1204 for expired certificates, lack of certificate revocation status 1205 information, and similar errors that violate RFC 5280 path validation 1206 rules [RFC5280]. Unless a mechanism is defined that accommodates 1207 incremental deployment of this capability, attackers probably will 1208 avoid submitting bogus certificates to (benign) logs as a means of 1209 evading detection. 1211 5.5. Remediation for a malicious CA 1213 A targeted Subject might ask the parent of a malicious CA to revoke 1214 the certificate of the non-cooperative CA. However, a request of 1215 this sort may be rejected, e.g., because of the potential for 1216 significant collateral damage. A browser might be configured to 1217 reject all certificates issued by the malicious CA, e.g., using a 1218 bad-CA-list distributed by a browser vendor. However, if the 1219 malicious CA has a sufficient number of legitimate clients, treating 1220 all of their certificates as bogus or erroneous still represents 1221 serious collateral damage. If this specification were to require 1222 that a browser can be configured to reject a specific, bogus or 1223 erroneous certificate identified by a Monitor, then the bogus or 1224 erroneous certificate could be rejected in that fashion. This 1225 remediation strategy calls for communication between Monitors and 1226 browsers, or between Monitors and browser vendors. Such 1227 communication has not been specified, i.e., there are no standard 1228 ways to configure a browser to reject individual bogus or erroneous 1229 certificates based on information provided by an external entity such 1230 as a Monitor. Moreover, the same or another malicious CA could issue 1231 new bogus or erroneous certificates for the targeted Subject, which 1232 would have to be detected and rejected in this (as yet unspecified) 1233 fashion. Thus, for now, CT does not seem to provide a way to 1234 facilitate remediation of this form of attack, even though it 1235 provides a basis for detecting such attacks. 1237 5.6. Auditing - detecting misbehaving logs 1239 The combination of a malicious CA and one or more conspiring logs 1240 motivates the definition of an audit function, to detect conspiring 1241 logs. If a Monitor protecting a Subject does not see bogus 1242 certificates, it cannot alert the Subject. If one or more SCTs are 1243 present in a certificate, or passed via the TLS handshake, a browser 1244 has no way to know that the logged certificate is not visible to 1245 Monitors. Only if Monitors and browsers reject certificates that 1246 contain SCTs from conspiring logs (based on information from an 1247 auditor) will CT be able to detect and deter use of such logs. Thus 1248 the means by which a Monitor performing an audit function detects 1249 such logs, and informs browsers must be specified for CT to be 1250 effective in the context of misbehaving logs. 1252 Absent a well-defined mechanism that enables Monitors to verify that 1253 data from logs are reported in a consistent fashion, CT cannot claim 1254 to provide protection against logs that are malicious or may conspire 1255 with, or are victims of, attackers effecting certificate mis- 1256 issuance. The mechanism needs to protect the privacy of users with 1257 respect to which web sites they visit. It needs to scale to 1258 accommodate a potentially large number of self-monitoring Subjects 1259 and a vast number of browsers, if browsers are part of the mechanism. 1260 Even when an Audit mechanism is defined, it will be necessary to 1261 describe how the CT system will deal with a misbehaving or 1262 compromised log. For example, will there be a mechanism to alert all 1263 browsers to reject SCTs issued by such a log? Absent a description 1264 of a remediation strategy to deal with misbehaving or compromised 1265 logs, CT cannot ensure detection of mis-issuance in a wide range of 1266 scenarios. 1268 Monitors play a critical role in detecting semantic certificate mis- 1269 issuance, for Subjects that have requested monitoring of their 1270 certificates. A monitor (including a Subject performing self- 1271 monitoring) examines logs for certificates associated with one or 1272 more Subjects that are being "protected". A third-party Monitor must 1273 obtain a list of valid certificates for the Subject being monitored, 1274 in a secure manner, to use as a reference. It also must be able to 1275 identify and track a potentially large number of logs on behalf of 1276 its Subjects. This may be a daunting task for Subjects that elect to 1277 perform self-monitoring. 1279 Note: A Monitor must not rely on a CA or RA database for its 1280 reference information or use certificate discovery protocols; this 1281 information must be acquired by the Monitor based on reference 1282 certificates provided by a Subject. If a Monitor were to rely on a 1283 CA or RA database (for the CA that issued a targeted certificate), 1284 the Monitor would not detect mis-issuance due to malfeasance on the 1285 part of that CA or the RA, or due to compromise of the CA or the RA. 1286 If a CA or RA database is used, it would support detection of mis- 1287 issuance by an unauthorized CA. A Monitor must not rely on 1288 certificate discovery mechanisms to build the list of valid 1289 certificates since such mechanisms might result in bogus or erroneous 1290 certificates being added to the list. 1292 As noted above, Monitors represent another target for adversaries who 1293 wish to effect certificate mis-issuance. If a Monitor is compromised 1294 by, or conspires with, an attacker, it will fail to alert a Subject 1295 to a bogus or erroneous certificate targeting that Subject, as noted 1296 above. It is suggested that a Subject request certificate monitoring 1297 from multiple sources to guard against such failures. Operation of a 1298 Monitor by a Subject, on its own behalf, avoids dependence on third 1299 party Monitors. However, the burden of Monitor operation may be 1300 viewed as too great for many web sites, and thus this mode of 1301 operation ought not be assumed to be universal when evaluating 1302 protection against Monitor compromise. 1304 6. Security Considerations 1306 An attack and threat model is, by definition, a security-centric 1307 document. Unlike a protocol description, a threat model does not 1308 create security problems nor does it purport to address security 1309 problems. This model postulates a set of threats (i.e., motivated, 1310 capable adversaries) and examines classes of attacks that these 1311 threats are capable of effecting, based on the motivations ascribed 1312 to the threats. It then analyses the ways in which the CT 1313 architecture addresses these attacks. 1315 7. IANA Considerations 1317 None. 1319 8. Acknowledgments 1321 The author would like to thank David Mandelberg and Karen Seo for 1322 their assistance in reviewing and preparing this document, and other 1323 members of the TRANS working group for reviewing it. Most of the 1324 text of Section 3.4 was provided by David Cooper, motivated by 1325 observations from Daniel Kahn Gilmor. 1327 9. References 1329 9.1. Normative References 1331 [I-D.kent-trans-architecture] 1332 Kent, S., Mandelberg, D., and K. Seo, "Certificate 1333 Transparency (CT) System Architecture", draft-kent-trans- 1334 architecture-04 (work in progress), August 2016. 1336 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1337 Requirement Levels", BCP 14, RFC 2119, 1338 DOI 10.17487/RFC2119, March 1997, 1339 . 1341 9.2. Informative References 1343 [I-D.ietf-trans-gossip] 1344 Nordberg, L., Gillmor, D., and T. Ritter, "Gossiping in 1345 CT", draft-ietf-trans-gossip-03 (work in progress), July 1346 2016. 1348 [I-D.ietf-trans-rfc6962-bis] 1349 Laurie, B., Langley, A., Kasper, E., Messeri, E., and R. 1350 Stradling, "Certificate Transparency", draft-ietf-trans- 1351 rfc6962-bis-19 (work in progress), August 2016. 1353 [I-D.kent-trans-domain-validation-cert-checks] 1354 Kent, S. and R. Andrews, "Syntactic and Semantic Checks 1355 for Domain Validation Certificates", draft-kent-trans- 1356 domain-validation-cert-checks-02 (work in progress), 1357 December 2015. 1359 [I-D.kent-trans-extended-validation-cert-checks] 1360 Kent, S. and R. Andrews, "Syntactic and Semantic Checks 1361 for Extended Validation Certificates", draft-kent-trans- 1362 extended-validation-cert-checks-02 (work in progress), 1363 December 2015. 1365 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1366 Housley, R., and W. Polk, "Internet X.509 Public Key 1367 Infrastructure Certificate and Certificate Revocation List 1368 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 1369 . 1371 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 1372 Extensions: Extension Definitions", RFC 6066, 1373 DOI 10.17487/RFC6066, January 2011, 1374 . 1376 [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., 1377 Galperin, S., and C. Adams, "X.509 Internet Public Key 1378 Infrastructure Online Certificate Status Protocol - OCSP", 1379 RFC 6960, DOI 10.17487/RFC6960, June 2013, 1380 . 1382 [RFC6961] Pettersen, Y., "The Transport Layer Security (TLS) 1383 Multiple Certificate Status Request Extension", RFC 6961, 1384 DOI 10.17487/RFC6961, June 2013, 1385 . 1387 Author's Address 1389 Stephen Kent 1390 BBN Technologies 1391 10 Moulton Street 1392 Cambridge, MA 02138 1393 USA 1395 Phone: +1 (617) 873-3988 1396 Email: kent@alum.mit.edu