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