idnits 2.17.1 draft-ietf-trans-threat-analysis-13.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 5 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 12, 2018) is 2207 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 1392 -- 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 -- Looks like a reference, but probably isn't: '2' on line 1394 == Outdated reference: A later version (-42) exists of draft-ietf-trans-rfc6962-bis-28 -- Obsolete informational reference (is this intentional?): RFC 6961 (Obsoleted by RFC 8446) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Public Notary Transparency S. Kent 3 Internet-Draft Independent 4 Intended status: Informational April 12, 2018 5 Expires: October 14, 2018 7 Attack and Threat Model for Certificate Transparency 8 draft-ietf-trans-threat-analysis-13 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 https://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 October 14, 2018. 38 Copyright Notice 40 Copyright (c) 2018 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 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Conventions used in this document . . . . . . . . . . . . 7 57 2. Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 58 3. Semantic mis-issuance . . . . . . . . . . . . . . . . . . . . 9 59 3.1. Non-malicious Web PKI CA context . . . . . . . . . . . . 9 60 3.1.1. Certificate logged . . . . . . . . . . . . . . . . . 9 61 3.1.2. Certificate not logged . . . . . . . . . . . . . . . 11 62 3.2. Malicious Web PKI CA context . . . . . . . . . . . . . . 12 63 3.2.1. Certificate logged . . . . . . . . . . . . . . . . . 12 64 3.2.2. Certificate not logged . . . . . . . . . . . . . . . 14 65 3.3. Undetected Compromise of CAs or Logs . . . . . . . . . . 15 66 3.3.1. Compromised CA, Benign Log . . . . . . . . . . . . . 15 67 3.3.2. Benign CA, Compromised Log . . . . . . . . . . . . . 17 68 3.3.3. Compromised CA, Compromised Log . . . . . . . . . . . 17 69 3.4. Attacks Based on Exploiting Multiple Certificate Chains . 18 70 3.5. Attacks Related to Distribution of Revocation Status . . 20 71 4. Syntactic mis-issuance . . . . . . . . . . . . . . . . . . . 21 72 4.1. Non-malicious Web PKI CA context . . . . . . . . . . . . 21 73 4.1.1. Certificate logged . . . . . . . . . . . . . . . . . 21 74 4.1.2. Certificate not logged . . . . . . . . . . . . . . . 23 75 4.2. Malicious Web PKI CA context . . . . . . . . . . . . . . 23 76 4.2.1. Certificate logged . . . . . . . . . . . . . . . . . 24 77 4.2.2. Certificate is not logged . . . . . . . . . . . . . . 25 78 5. Issues Applicable to Sections 3 and 4 . . . . . . . . . . . . 25 79 5.1. How does a Subject know which Monitor(s) to use? . . . . 25 80 5.2. How does a Monitor discover new logs? . . . . . . . . . . 25 81 5.3. CA response to report of a bogus or erroneous certificate 26 82 5.4. Browser behavior . . . . . . . . . . . . . . . . . . . . 26 83 5.5. Remediation for a malicious CA . . . . . . . . . . . . . 26 84 5.6. Auditing - detecting misbehaving logs . . . . . . . . . . 27 85 6. Security Considerations . . . . . . . . . . . . . . . . . . . 28 86 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 87 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 88 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 89 9.1. Normative References . . . . . . . . . . . . . . . . . . 29 90 9.2. Informative References . . . . . . . . . . . . . . . . . 29 91 9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 30 92 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 30 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 [1] for the 151 most 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 [2]]. 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. Attacks Based on Exploiting Multiple Certificate Chains 825 Section 3.2 examined attacks in which a malicious CA issued a bogus 826 certificate and either tried to prevent the Subject from detecting 827 the bogus certificate, or reported the bogus certificate as valid, to 828 at least some relying parties, even if the Subject requested 829 revocation. These attacks are limited in that if the bogus 830 certificate is not submitted to a log, then it may not be accepted by 831 CT-aware browsers, and submitting the bogus certificate to a log 832 increases the chances that the CA's malicious behavior will be 833 detected. 835 In general, if a CA is discovered to be acting maliciously, its 836 certificates will no longer be accepted, either because its parent 837 will revoke its CA certificate, its CA certificate will be added to 838 browsers' blacklists, or both. However, a malicious CA may be able 839 to obtain an SCT for each bogus certificate that it issues and 840 continue to have those certificates accepted by relying parties even 841 after its malicious behavior has been detected. It can do this by 842 creating more than one path validation chain for the certificates, as 843 shown in Figure 2. 845 +-----------------+ +-----------------+ 846 | CA A | | CA B | 847 +-----------------+ +-----------------+ 848 \ / 849 \ / 850 CA certificate 1 \ / CA certificate 2 851 \ / 852 +----------------+ 853 | malicious CA | 854 +----------------+ 855 | 856 | bogus EE certificate 857 | 858 +------------------+ 859 | targeted Subject | 860 +------------------+ 862 Figure 2: Multiple Certificate Chains for a Bogus Certificate 864 In Figure 2, the malicious CA has been issued CA certificates by two 865 different parent CAs. The parent CAs may be two different trust 866 anchors, or one or both of them may be an intermediate CA (i.e., it 867 is subordinate to some trust anchor). If both parent CAs are 868 intermediate CAs, they may be subordinate to the same trust anchor or 869 to different trust anchors. The malicious CA may have obtained 870 certificates from the two parents by applying to them for the 871 certificates, or by compromising the parent CAs and creating the 872 certificates without the knowledge of the CAs. If the malicious CA 873 applied for its certificates from these CAs, it may have presented 874 false information as input to the CA's normal issuance procedures, 875 with the result that the CAs do not realize that a certificate with 876 the same subject name and public key has been issued by another CA. 878 Because there are two certificate path validation chains, the 879 malicious CA could provide the chain that includes CA A when 880 submitting a bogus certificate to one or more logs, but an attacker 881 (colluding with the malicious CA) could provide the chain that 882 includes CA B to targeted browsers. If the CA's malicious behavior 883 is detected, then CA A and browser vendors may be alerted (e.g., via 884 the CT Monitor function) and revoke/blacklist CA certificate 1. 885 However, CA certificate 2 does not appear in any logs, and CA A is 886 unaware that CA B has issued a certificate to the malicious CA. Thus 887 those who detected the malicious behavior may not discover the second 888 chain and so may not alert CA B or browser vendors of the need to 889 revoke/blacklist CA certificate 2. In this case, targeted browsers 890 would continue to accept the bogus certificates issued by the 891 malicious CA, since the certificate chain they are provided is valid 892 and because the SCT issued for the bogus certificate it the same 893 irrespective of which certificate chain is presented. 895 3.5. Attacks Related to Distribution of Revocation Status 897 A bogus certificate that has been revoked may still appear valid to a 898 browser under certain circumstances. In part this is because the 899 revocation information seen by a relying party is partly under the 900 control of the CA and/or the certificate subject. As a result, 901 different relying parties may be presented with different revocation 902 information. This is true irrespective of whether revocation is 903 effected via use of a CRL or OCSP. Additionally, an attacker can 904 steer a browser to specific revocation status data via various means, 905 preventing a targeted browser from acquiring accurate revocation 906 status information for a bogus certificate. 908 The bogus certificate might contain an AIA extension pointing to an 909 OCSP server controlled by the malicious CA (or the attacker). As 910 noted in Section 3.2.1.1.1, the malicious CA could send a "good" OCSP 911 response to a targeted browser instance, even if other parties are 912 provided with a "revoked" response. A TLS server can supply an OCSP 913 response to a browser as part of the TLS handshake [RFC6961], if 914 requested by the browser. A TLS server posing as the entity named in 915 the bogus certificate also could acquire a "good" OCSP response from 916 the malicious CA to effect the attack. Only if the browser relies 917 upon a trusted, third-party OCSP responder, one not part of the 918 collusion, would these OCSP-based attacks fail. 920 The bogus certificate could contain a CRL distribution point 921 extension instead of an AIA extension. In that case a site supplying 922 CRLs for the malicious CA could supply different CRLs to different 923 requestors, in an attempt to hide the revocation status of the bogus 924 certificate from targeted browser instances. This is analogous to a 925 split-view attack effected by a CT log. However, as noted in 926 Section 3.2.1.1 and 3.2.1.1.1, no element of CT is responsible for 927 detecting inconsistent reporting of certificate revocation status 928 data. (Monitoring in the CT context tracks log entries made by CAs 929 or Subjects. Auditing is designed to detect misbehavior by logs, not 930 by CAs per se.) 932 The failure of a bogus certificate to be detected as revoked (by a 933 browser) is not the fault of CT. In the class of attacks described 934 above, CT achieves its goal of detecting the bogus certificate when 935 that certificate is logged and a Monitor observes the log entry. 936 Detection is intended to trigger revocation, to effect remediation, 937 the details of which are outside the scope of CT. However the SCT 938 mechanism is intended to assure a relying party that certificate has 939 been logged, is susceptible to being detected as bogus by a Monitor, 940 and presumably will be revoked if detected as such. In the context 941 of these attacks, because of the way revocation may be implemented, 942 the assurance provided by the SCT may not have the anticipated 943 effect. 945 This type of attack might be thwarted in several ways. For example, 946 if all intermediate (i.e., CA) certificates had to be logged, then CA 947 certificate 2 might be rejected by CT-aware browsers. If a malicious 948 CA is discovered, a browser vendor might blacklist it by public key 949 (not by its serial number and the name of the parent CA or by a hash 950 of the certificate). This approach to revocation would cause CA 951 certificate 2 to be rejected as well as CA certificate 1. However 952 none of these mechanisms are part of the CT specification 953 [I-D.ietf-trans-rfc6962-bis] nor general IETF PKI standards (e.g., 954 [RFC5280]). 956 4. Syntactic mis-issuance 958 4.1. Non-malicious Web PKI CA context 960 This section analyzes the scenario in which the CA has no intent to 961 issue a syntactically incorrect certificate. As noted in Section 1, 962 we refer to a syntactically incorrect certificate as erroneous. 964 4.1.1. Certificate logged 966 4.1.1.1. Benign log 968 If a (pre )certificate is submitted to a benign log, syntactic mis- 969 issuance can (optionally) be detected, and noted. This will happen 970 only if the log performs syntactic checks in general, and if the log 971 is capable of performing the checks applicable to the submitted (pre 972 )certificate. (A (pre )certificate SHOULD be logged even if it fails 973 syntactic validation; logging takes precedence over detection of 974 syntactic mis-issuance.) If syntactic validation fails, this can be 975 noted in an SCT extension returned to the submitter. 977 If the (pre )certificate is submitted by the non-malicious issuing 978 CA, then the CA SHOULD remedy the syntactic problem and re-submit the 979 (pre )certificate to a log or logs. If this is a pre-certificate 980 submitted prior to issuance, syntactic checking by a log helps avoid 981 issuance of an erroneous certificate. If the CA does not have a 982 record of the certificate contents, then presumably it was a bogus 983 certificate and the CA SHOULD revoke it. 985 If a certificate is submitted by its Subject, and is deemed 986 erroneous, then the Subject SHOULD contact the issuing CA and request 987 a new certificate. If the Subject is a legitimate subscriber of the 988 CA, then the CA will either have a record of the certificate content 989 or can obtain a copy of the certificate from the Subject. The CA 990 will remedy the syntactic problem and either re-submit a corrected 991 (pre-)certificate to a log and send it to the Subject or the Subject 992 will re-submit it to a log. Here too syntactic checking by a log 993 enables a Subject to be informed that its certificate is erroneous 994 and thus may hasten issuance of a replacement certificate. 996 If a certificate is submitted by a third party, that party might 997 contact the Subject or the issuing CA, but because the party is not 998 the Subject of the certificate it is not clear how the CA will 999 respond. 1001 This analysis suggests that syntactic mis-issuance of a certificate 1002 can be avoided by a CA if it makes use of logs that are capable of 1003 performing these checks for the types of certificates that are 1004 submitted, and if the CA acts on the feedback it receives. If a CA 1005 uses a log that does not perform such checks, or if the CA requests 1006 checking relative to criteria not supported by the log, then 1007 syntactic mis-issuance will not be detected or avoided by this 1008 mechanism. Similarly, syntactic mis-issuance can be remedied if a 1009 Subject submits a certificate to a log that performs syntactic 1010 checks, and if the Subject asks the issuing CA to fix problems 1011 detected by the log. (The issuer is presumed to be willing to re- 1012 issue the certificate, correcting any problems, because the issuing 1013 CA is not malicious.) 1015 4.1.1.2. Misbehaving log or third party Monitor 1017 A log or Monitor that is conspiring with the attacker or is 1018 independently malicious, will either not perform syntactic checks, 1019 even though it claims to do so, or simply not report errors. The log 1020 entry and the SCT for an erroneous certificate will assert that the 1021 certificate syntax was verified. 1023 As with detection of semantic mis-issuance, a distributed Audit 1024 mechanism could, in principle, detect misbehavior by logs or Monitors 1025 with respect to syntactic checking. For example, if for a given 1026 certificate, some logs (or Monitors) are reporting syntactic errors 1027 and some that claim to do syntactic checking, are not reporting these 1028 errors, this is indicative of misbehavior by these logs and/or 1029 Monitors. 1031 Note that a malicious log (or Monitor) could report syntactic errors 1032 for a syntactically valid certificate. This could result in 1033 reporting of non-existent syntactic problems to the issuing CA, which 1034 might cause the CA to do needless investigative work or perhaps 1035 incorrectly revoke and re-issue the Subject's certificate. 1037 4.1.1.3. Self-monitoring Subject and Benign third party Monitor 1039 If a Subject or benign third party Monitor performs syntactic checks, 1040 it will detect the erroneous certificate and the issuing CA will be 1041 notified (by the Subject). If the Subject is a legitimate subscriber 1042 of the CA, then the CA will either have a record of the certificate 1043 content or can obtain a copy of the certificate from the Subject. 1044 The CA SHOULD revoke the erroneous certificate (after investigation) 1045 and remedy the syntactic problem. The CA SHOULD either re-submit the 1046 corrected (pre )certificate to one or more logs and then send the 1047 result to the Subject, or send the corrected certificate to the 1048 Subject, who will re-submit it to one or more logs. 1050 4.1.1.4. CT-enabled browser 1052 If a browser rejects an erroneous certificate and notifies the 1053 Subject and/or the issuing CA, then syntactic mis-issuance will be 1054 detected (see Section 5.) Unfortunately, experience suggests that 1055 many browsers do not perform thorough syntactic checks on 1056 certificates, and so it seems unlikely that browsers will be a 1057 reliable way to detect erroneous certificates. Moreover, a protocol 1058 used by a browser to notify a Subject and/or CA of an erroneous 1059 certificate represents a DoS potential, and thus may not be 1060 appropriate. Additionally, if a browser directly contacts a CA when 1061 an erroneous certificate is detected, this is a potential privacy 1062 violation, i.e., the CA learns that the browser user is visiting the 1063 web site in question. These observations argue for syntactic 1064 checking to be performed by other elements of the CT system, e.g., 1065 logs and/or Monitors. 1067 4.1.2. Certificate not logged 1069 If a CA does not submit a certificate to a log, there can be no 1070 syntactic checking by the log. Detection of syntactic errors will 1071 depend on a Subject performing the requisite checks when it receives 1072 its certificate from a CA. A Monitor that performs syntactic checks 1073 on behalf of a Subject also could detect such problems, but the CT 1074 architecture does not require Monitors to perform such checks. 1076 4.2. Malicious Web PKI CA context 1078 This section analyzes the scenario in which the CA's issuance of a 1079 syntactically incorrect certificate is intentional, not due to error. 1080 The CA is not the victim but the attacker. 1082 4.2.1. Certificate logged 1084 4.2.1.1. Benign log 1086 Because the CA is presumed to be malicious, the CA may cause the log 1087 to not perform checks, in one of several ways. (See 1088 [I-D.kent-trans-domain-validation-cert-checks] and 1089 [I-D.kent-trans-extended-validation-cert-checks] for more details on 1090 validation checks and CCIDs). 1092 1. The CA may assert that the certificate is being issued w/o regard 1093 to any guidelines (the "no guidelines" reserved CCID). 1095 2. The CA may assert a CCID that has not been registered, and thus 1096 no log will be able to perform a check. 1098 3. The CA may check to see which CCIDs a log declares it can check, 1099 and chose a registered CCID that is not checked by the log in 1100 question. 1102 4. The CA may submit a (pre-) certificate to a log that is known to 1103 not perform any syntactic checks, and thus avoid syntactic 1104 checking. 1106 4.2.1.2. Misbehaving log or third party Monitor 1108 A misbehaving log or third party Monitor will either not perform 1109 syntactic checks or not report any problems that it discovers. (See 1110 4.1.1.2 for further problems). Also, as noted above, the CT 1111 architecture includes no explicit provisions for detecting a 1112 misbehaving third-party Monitor. 1114 4.2.1.3. Self-monitoring Subject and Benign third party Monitor 1116 Irrespective of whether syntactic checks are performed by a log, a 1117 malicious CA will acquire an embedded SCT, or post-issuance will 1118 acquire a standalone SCT. If Subjects or Monitors perform syntactic 1119 checks that detect the syntactic mis-issuance and report the problem 1120 to the CA, a malicious CA may do nothing or may delay the action(s) 1121 needed to remedy the problem. 1123 4.2.1.4. CT-enabled browser 1125 As noted above (4.1.1.4), most browsers fail to perform thorough 1126 syntax checks on certificates. Such browsers might benefit from 1127 having syntax checks performed by a log and reported in the SCT, 1128 although the pervasive nature of syntactically-defective certificates 1129 may limit the utility of such checks. (Remember, in this scenario, 1130 the log is benign.) However, if a browser does not discriminate 1131 against certificates that do not contain SCTs (or that are not 1132 accompanied by an SCT in the TLS handshake), only minimal benefits 1133 might accrue to the browser from syntax checks perform by logs or 1134 Monitors. 1136 If a browser accepts certificates that do not appear to have been 1137 syntactically checked by a log (as indicated by the SCT), a malicious 1138 CA need not worry about failing a log-based check. Similarly, if 1139 there is no requirement for a browser to reject a certificate that 1140 was logged by an operator that does not perform syntactic checks, the 1141 fourth attack noted in 4.2.1.1 will succeed as well. If a browser 1142 were configured to know which versions of certificate types are 1143 applicable to its use of a certificate, the second and third attack 1144 strategies noted above could be thwarted. 1146 4.2.2. Certificate is not logged 1148 Since certificates are not logged in this scenario, a Monitor (third- 1149 party or self) cannot detect the issuance of an erroneous 1150 certificate. Thus there is no difference between a benign or a 1151 malicious/conspiring log or a benign or conspiring/malicious Monitor. 1152 (A Subject MAY detect a syntax error by examining the certificate 1153 returned to it by the Issuer.) However, even if errors are detected 1154 and reported to the CA, a malicious/conspiring CA may do nothing to 1155 fix the problem or may delay action. 1157 5. Issues Applicable to Sections 3 and 4 1159 5.1. How does a Subject know which Monitor(s) to use? 1161 If a CA submits a bogus certificate to one or more logs, but these 1162 logs are not tracked by a Monitor that is protecting the targeted 1163 Subject, CT will not remedy this type of mis-issuance attack. If 1164 third-party Monitors advertise which logs they track, Subjects may be 1165 able to use this information to select an appropriate Monitor (or set 1166 thereof). Also, it is not clear whether every third-party Monitor 1167 MUST offer to track every Subject that requests protection. If a 1168 Subject acts as its own Monitor, this problem is solved for that 1169 Subject. 1171 5.2. How does a Monitor discover new logs? 1173 It is not clear how a (self-)Monitor becomes aware of all (relevant) 1174 logs, including newly created logs. The means by which Monitors 1175 become aware of new logs MUST accommodate self-monitoring by a 1176 potentially very large number of web site operators. If there are 1177 many logs, it may not be feasible for a (self-) Monitor to track all 1178 of them, or to determine what set of logs suffice to ensure an 1179 adequate level of coverage. 1181 5.3. CA response to report of a bogus or erroneous certificate 1183 A CA being presented with evidence of a bogus or erroneous 1184 certificate, in the form of a log entry and/or SCT, will need to 1185 examine its records to determine if it has knowledge of the 1186 certificate in question. It also will likely require the targeted 1187 Subject to provide assurances that it is the authorized entity 1188 representing the Subject name (subjectAltname) in question. Thus a 1189 Subject should not expect immediate revocation of a contested 1190 certificate. The time frame in which a CA will respond to a 1191 revocation request usually is described in the CPS for the CA. Other 1192 certificate fields and extensions may be of interest for forensic 1193 purposes, but are not required to effect revocation nor to verify 1194 that the certificate to be revoked is bogus or erroneous, based on 1195 applicable criteria. The SCT and log entry, because each contains a 1196 timestamp from a third party, is probably valuable for forensic 1197 purposes (assuming a non-conspiring log operator). 1199 5.4. Browser behavior 1201 If a browser is to reject a certificate that lacks an embedded SCT, 1202 or is not accompanied by an SCT transported via the TLS handshake, 1203 this behavior needs to be defined in a way that is compatible with 1204 incremental deployment. Issuing a warning to a (human) user is 1205 probably insufficient, based on experience with warnings displayed 1206 for expired certificates, lack of certificate revocation status 1207 information, and similar errors that violate RFC 5280 path validation 1208 rules [RFC5280]. Unless a mechanism is defined that accommodates 1209 incremental deployment of this capability, attackers probably will 1210 avoid submitting bogus certificates to (benign) logs as a means of 1211 evading detection. 1213 5.5. Remediation for a malicious CA 1215 A targeted Subject might ask the parent of a malicious CA to revoke 1216 the certificate of the non-cooperative CA. However, a request of 1217 this sort may be rejected, e.g., because of the potential for 1218 significant collateral damage. A browser might be configured to 1219 reject all certificates issued by the malicious CA, e.g., using a 1220 bad-CA-list distributed by a browser vendor. However, if the 1221 malicious CA has a sufficient number of legitimate clients, treating 1222 all of their certificates as bogus or erroneous still represents 1223 serious collateral damage. If this specification were to require 1224 that a browser can be configured to reject a specific, bogus or 1225 erroneous certificate identified by a Monitor, then the bogus or 1226 erroneous certificate could be rejected in that fashion. This 1227 remediation strategy calls for communication between Monitors and 1228 browsers, or between Monitors and browser vendors. Such 1229 communication has not been specified, i.e., there are no standard 1230 ways to configure a browser to reject individual bogus or erroneous 1231 certificates based on information provided by an external entity such 1232 as a Monitor. Moreover, the same or another malicious CA could issue 1233 new bogus or erroneous certificates for the targeted Subject, which 1234 would have to be detected and rejected in this (as yet unspecified) 1235 fashion. Thus, for now, CT does not seem to provide a way to 1236 facilitate remediation of this form of attack, even though it 1237 provides a basis for detecting such attacks. 1239 5.6. Auditing - detecting misbehaving logs 1241 The combination of a malicious CA and one or more conspiring logs 1242 motivates the definition of an audit function, to detect conspiring 1243 logs. If a Monitor protecting a Subject does not see bogus 1244 certificates, it cannot alert the Subject. If one or more SCTs are 1245 present in a certificate, or passed via the TLS handshake, a browser 1246 has no way to know that the logged certificate is not visible to 1247 Monitors. Only if Monitors and browsers reject certificates that 1248 contain SCTs from conspiring logs (based on information from an 1249 auditor) will CT be able to detect and deter use of such logs. Thus 1250 the means by which a Monitor performing an audit function detects 1251 such logs, and informs browsers must be specified for CT to be 1252 effective in the context of misbehaving logs. 1254 Absent a well-defined mechanism that enables Monitors to verify that 1255 data from logs are reported in a consistent fashion, CT cannot claim 1256 to provide protection against logs that are malicious or may conspire 1257 with, or are victims of, attackers effecting certificate mis- 1258 issuance. The mechanism needs to protect the privacy of users with 1259 respect to which web sites they visit. It needs to scale to 1260 accommodate a potentially large number of self-monitoring Subjects 1261 and a vast number of browsers, if browsers are part of the mechanism. 1262 Even when an Audit mechanism is defined, it will be necessary to 1263 describe how the CT system will deal with a misbehaving or 1264 compromised log. For example, will there be a mechanism to alert all 1265 browsers to reject SCTs issued by such a log? Absent a description 1266 of a remediation strategy to deal with misbehaving or compromised 1267 logs, CT cannot ensure detection of mis-issuance in a wide range of 1268 scenarios. 1270 Monitors play a critical role in detecting semantic certificate mis- 1271 issuance, for Subjects that have requested monitoring of their 1272 certificates. A monitor (including a Subject performing self- 1273 monitoring) examines logs for certificates associated with one or 1274 more Subjects that are being "protected". A third-party Monitor must 1275 obtain a list of valid certificates for the Subject being monitored, 1276 in a secure manner, to use as a reference. It also must be able to 1277 identify and track a potentially large number of logs on behalf of 1278 its Subjects. This may be a daunting task for Subjects that elect to 1279 perform self-monitoring. 1281 Note: A Monitor must not rely on a CA or RA database for its 1282 reference information or use certificate discovery protocols; this 1283 information must be acquired by the Monitor based on reference 1284 certificates provided by a Subject. If a Monitor were to rely on a 1285 CA or RA database (for the CA that issued a targeted certificate), 1286 the Monitor would not detect mis-issuance due to malfeasance on the 1287 part of that CA or the RA, or due to compromise of the CA or the RA. 1288 If a CA or RA database is used, it would support detection of mis- 1289 issuance by an unauthorized CA. A Monitor must not rely on 1290 certificate discovery mechanisms to build the list of valid 1291 certificates since such mechanisms might result in bogus or erroneous 1292 certificates being added to the list. 1294 As noted above, Monitors represent another target for adversaries who 1295 wish to effect certificate mis-issuance. If a Monitor is compromised 1296 by, or conspires with, an attacker, it will fail to alert a Subject 1297 to a bogus or erroneous certificate targeting that Subject, as noted 1298 above. It is suggested that a Subject request certificate monitoring 1299 from multiple sources to guard against such failures. Operation of a 1300 Monitor by a Subject, on its own behalf, avoids dependence on third 1301 party Monitors. However, the burden of Monitor operation may be 1302 viewed as too great for many web sites, and thus this mode of 1303 operation ought not be assumed to be universal when evaluating 1304 protection against Monitor compromise. 1306 6. Security Considerations 1308 An attack and threat model is, by definition, a security-centric 1309 document. Unlike a protocol description, a threat model does not 1310 create security problems nor does it purport to address security 1311 problems. This model postulates a set of threats (i.e., motivated, 1312 capable adversaries) and examines classes of attacks that these 1313 threats are capable of effecting, based on the motivations ascribed 1314 to the threats. It then analyses the ways in which the CT 1315 architecture addresses these attacks. 1317 7. IANA Considerations 1319 None. 1321 8. Acknowledgments 1323 The author would like to thank David Mandelberg and Karen Seo for 1324 their assistance in reviewing and preparing this document, and other 1325 members of the TRANS working group for reviewing it. Most of the 1326 text of Section 3.4 was provided by David Cooper, motivated by 1327 observations from Daniel Kahn Gilmor. Thanks also go to Daiming Li 1328 for her editorial assistance. 1330 9. References 1332 9.1. Normative References 1334 [I-D.kent-trans-architecture] 1335 Kent, S., Mandelberg, D., and K. Seo, "Certificate 1336 Transparency (CT) System Architecture", draft-kent-trans- 1337 architecture-07 (work in progress), December 2017. 1339 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1340 Requirement Levels", BCP 14, RFC 2119, 1341 DOI 10.17487/RFC2119, March 1997, 1342 . 1344 9.2. Informative References 1346 [I-D.ietf-trans-gossip] 1347 Nordberg, L., Gillmor, D., and T. Ritter, "Gossiping in 1348 CT", draft-ietf-trans-gossip-05 (work in progress), 1349 January 2018. 1351 [I-D.ietf-trans-rfc6962-bis] 1352 Laurie, B., Langley, A., Kasper, E., Messeri, E., and R. 1353 Stradling, "Certificate Transparency Version 2.0", draft- 1354 ietf-trans-rfc6962-bis-28 (work in progress), March 2018. 1356 [I-D.kent-trans-domain-validation-cert-checks] 1357 Kent, S. and R. Andrews, "Syntactic and Semantic Checks 1358 for Domain Validation Certificates", draft-kent-trans- 1359 domain-validation-cert-checks-02 (work in progress), 1360 December 2015. 1362 [I-D.kent-trans-extended-validation-cert-checks] 1363 Kent, S. and R. Andrews, "Syntactic and Semantic Checks 1364 for Extended Validation Certificates", draft-kent-trans- 1365 extended-validation-cert-checks-02 (work in progress), 1366 December 2015. 1368 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1369 Housley, R., and W. Polk, "Internet X.509 Public Key 1370 Infrastructure Certificate and Certificate Revocation List 1371 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 1372 . 1374 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 1375 Extensions: Extension Definitions", RFC 6066, 1376 DOI 10.17487/RFC6066, January 2011, 1377 . 1379 [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., 1380 Galperin, S., and C. Adams, "X.509 Internet Public Key 1381 Infrastructure Online Certificate Status Protocol - OCSP", 1382 RFC 6960, DOI 10.17487/RFC6960, June 2013, 1383 . 1385 [RFC6961] Pettersen, Y., "The Transport Layer Security (TLS) 1386 Multiple Certificate Status Request Extension", RFC 6961, 1387 DOI 10.17487/RFC6961, June 2013, 1388 . 1390 9.3. URIs 1392 [1] https://cabforum.org 1394 [2] https://www.vasco.com/company/about_vasco/press_room/ 1395 news_archive/2011/news_diginotar_reports_any 1396 security_incident.aspx 1398 Author's Address 1400 Stephen Kent 1401 Independent 1403 Email: kent@alum.mit.edu