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