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