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