idnits 2.17.1 draft-ietf-trans-threat-analysis-02.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 2 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 (July 2015) is 3207 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '10' on line 241 -- Looks like a reference, but probably isn't: '12' on line 243 -- Looks like a reference, but probably isn't: '11' on line 242 == Outdated reference: A later version (-42) exists of draft-ietf-trans-rfc6962-bis-07 == Outdated reference: A later version (-02) exists of draft-kent-trans-domain-validation-cert-checks-01 == Outdated reference: A later version (-02) exists of draft-kent-trans-extended-validation-cert-checks-01 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Public Notary Transparency S. Kent 2 Internet Draft BBN Technologies 3 Expires: January 2016 July 2015 4 Intended Status: Informational 6 Attack Model for Certificate Transparency 7 draft-ietf-trans-threat-analysis-02 9 Abstract 11 This document describes an attack model for the Web PKI context in 12 which security mechanisms to detect mis-issuance of web site 13 certificates will be developed. The model provides an analysis of 14 detection and remediation mechanisms for both syntactic and semantic 15 mis-issuance. The model introduces an outline of attacks to organize 16 the discussion. The model also describes the roles played by the 17 elements of the Certificate Transparency (CT) system, to establish a 18 context for the model. 20 Status of this Memo 22 This Internet-Draft is submitted to IETF in full conformance with 23 the provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that other 27 groups may also distribute working documents as Internet-Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/1id-abstracts.html 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html 40 This Internet-Draft will expire on January 31, 2016. 42 Table of Contents 44 1. Introduction....................................................... 3 45 2. Semantic mis-issuance.............................................. 7 46 2.1. Non-malicious Web PKI CA context ............................... 7 47 2.1.1. Certificate logged ......................................... 8 48 2.1.1.1. Benign log.............................................. 8 49 2.1.1.1.1. Self-monitoring Subject ............................. 8 50 2.1.1.1.2. Benign third party Monitor .......................... 8 51 2.1.1.2. Mis-behaving log........................................ 8 52 2.1.1.2.1. Self-monitoring Subject ............................. 9 53 2.1.1.2.2. Benign third party Monitor .......................... 9 54 2.1.1.3. Mis-behaving third party Monitor....................... 10 55 2.1.2. Certificate not logged .................................... 10 56 2.1.2.1. Self-monitoring Subject................................ 10 57 2.1.2.2. Careful browser........................................ 10 58 2.2. Malicious Web PKI CA context .................................. 11 59 2.2.1. Certificate logged ........................................ 11 60 2.2.1.1. Benign log............................................. 11 61 2.2.1.1.1. Self-monitoring Subject ............................ 11 62 2.2.1.1.2. Benign third party Monitor ......................... 11 63 2.2.1.2. Mis-behaving log....................................... 12 64 2.2.1.2.1. Monitors - third party and self .................... 12 65 2.2.1.3. Mis-behaving third party Monitor....................... 12 66 2.2.2. Certificate not logged .................................... 12 67 2.2.2.1. Careful browser........................................ 13 68 3. Syntactic mis-issuance............................................ 13 69 3.1. Non-malicious Web PKI CA context .............................. 13 70 3.1.1. Certificate logged ........................................ 13 71 3.1.1.1. Benign log............................................. 13 72 3.1.1.2. Mis-behaving log or third party Monitor................ 14 73 3.1.1.3. Self-monitoring Subject and Benign third-party Monitor. 15 74 3.1.1.4. Careful browser........................................ 15 75 3.1.2. Certificate not logged .................................... 15 76 3.2. Malicious Web PKI CA context .................................. 15 77 3.2.1. Certificate logged ........................................ 15 78 3.2.1.1. Benign log............................................. 15 79 3.2.1.2. Mis-behaving log or third party Monitor................ 16 80 3.2.1.3. Self-monitoring Subject and Benign third party Monitor. 16 81 3.2.1.4. Careful browser........................................ 16 82 3.2.2. Certificate is not logged ................................. 17 83 4. Issues Applicable to Sections 2 and 3............................. 17 84 4.1. How does a Subject know which Monitor(s) to use? .............. 17 85 4.2. How does a Monitor discover new logs? ......................... 17 86 4.3. CA response to report of a bogus or erroneous certificate ..... 17 87 4.4. Browser behavior .............................................. 18 88 4.5. Remediation for a malicious CA ................................ 18 89 4.6. Auditing - detecting mis-behaving logs ........................ 19 90 5. Security Considerations........................................... 20 91 6. IANA Considerations............................................... 20 92 7. Acknowledgments................................................... 20 93 8. References........................................................ 21 94 8.1. Normative References .......................................... 21 95 8.2. Informative References ........................................ 21 96 Author's Addresses................................................... 21 97 Copyright Statement.................................................. 21 99 1. Introduction 101 Certificate transparency (CT) is a set of mechanisms designed to 102 detect, deter, and facilitate remediation of certificate mis- 103 issuance. The term certificate mis-issuance is defined here to 104 encompass violations of either semantic or syntactic constraints. 105 The fundamental semantic constraint for a certificate is that it was 106 issued to an entity that is authorized to represent the Subject (or 107 Subject Alternative) named in the certificate. (It is also assumed 108 that the entity requested the certificate from the CA that issued 109 it.) Throughout the remainder of this document we refer to a 110 semantically mis-issued certificate as "bogus.") 111 A certificate is characterized as syntactically mis-issued if it 112 violates syntax constraints associated with the class of certificate 113 that it purports to represent. Syntax constraints for certificates 114 are established by certificate profiles, and typically are 115 application-specific. For example, certificates used in the Web PKI 116 environment might be characterized as domain validation (DV) or 117 extended validation (EV) certificates. Certificates used with 118 applications such as IPsec or S/MIME have different syntactic 119 constraints from those in the Web PKI context. 121 There are two classes of beneficiaries of CT: certificate Subjects 122 and relying parties (RPs). In the initial focus context of CT, the 123 Web PKI, Subjects are web sites and RPs are browsers employing HTTPS 124 to access these web sites. 126 A certificate Subject benefits from CT because CT helps detect 127 certificates that have been mis-issued in the name of that Subject. 128 A Subject learns of a bogus certificate (issued in its name), via 129 the Monitor function of CT. The Monitor function may be provided by 130 the Subject itself, i.e., self-monitoring, or by a third party 131 trusted by the Subject. When a Subject is informed of certificate 132 mis-issuance by a Monitor, the Subject is expected to request/demand 133 revocation of the bogus certificate. Revocation of a bogus 134 certificate is the primary means of remedying mis-issuance. (If a 135 browser vendor distributes a "blacklist" of bogus certificates or 136 CAs that mis-issued certificates and modifies the browser to reject 137 any certificates on the list or for which the issuing CA is on the 138 list, this too remedies mis-issuance. Throughout the remainder of 139 this document references to certificate revocation as a remedy 140 encompass this and analogous forms of browser behavior, if 141 available. Note: there are no IETF standards defining a browser 142 blacklist capability.) 144 Note that a Subject can benefit from the Monitor function of CT even 145 if the Subject's certificate has not been logged. Monitoring of logs 146 for certificates issued in the Subject's name suffices to detect 147 mis-issuance targeting the Subject, if the bogus certificate is 148 logged. 150 A relying party (e.g., browser) benefits from CT if it rejects a 151 bogus certificate, i.e., treats it as invalid. An RP is protected 152 from accepting a bogus certificate if that certificate is revoked, 153 and if the RP checks the revocation status of the certificate. (An 154 RP is also protected if a browser vendor "blacklists" a certificate 155 or a CA as noted above.) An RP also may benefit from CT if the RP 156 validates an SCT associated with a certificate, and rejects the 157 certificate if the SCT is invalid. If an RP verified that a 158 certificate that claims to have been logged has a valid log entry, 159 the RP would have a higher degree of confidence that the certificate 160 is genuine. However, checking logs in this fashion imposes a burden 161 on RPs and on logs. Moreover, the existence of a log entry does not 162 ensure that the certificate is not mis-issued. Unless the 163 certificate Subject is monitoring the log(s) in question, a bogus 164 certificate will not be detected by CT mechanisms. Finally, if an RP 165 were to check logs for individual certificates that would disclose 166 to logs the identity of web sites being visited by the RP, a privacy 167 violation. Thus this attack model assumes that RPs will not check 168 log entries. 170 Note that all RPs may benefit from CT even if they do nothing with 171 SCTs. If Monitors inform Subjects of mis-issuance, and if a CA 172 revokes a certificate in response to a request from the 173 certificate's legitimate Subject, then an RP benefits without having 174 to implement any CT-specific mechanisms. 176 Logging [TRANS] is the central element of CT. Logging enables a 177 Monitor to detect a bogus certificate based on reference information 178 provided by the certificate Subject. Logging of certificates is 179 intended to deter mis-issuance, by creating a publicly-accessible 180 record that associates a CA with any certificates that it mis- 181 issues. Logging does not remedy mis-issuance; but it does facilitate 182 remediation by providing the information needed to enable revocation 183 of bogus certificates in some circumstances. 185 Auditing is a function employed by CT to detect mis-behavior by 186 logs. Auditing is intended to deter mis-issuance that is abetted by 187 misbehaving logs. Auditing detects log mis-behavior by noting 188 inconsistencies between SCTs issued by a log and the log entries 189 published by the log. (A failure to make available log entries in a 190 timely fashion, consistent with the MMD for the log is also a form 191 of misbehavior that can be detected by the Audit function.) Such 192 inconsistencies indicate log misbehavior and suggest that Monitors 193 ought not trust such logs. Thus the Audit function does not detect 194 mis-issuance per se. There is no agreed-upon Audit function design 195 for CT at the time of this writing. As a result, the model merely 196 notes where Auditing is needed to detect certain classes of attacks. 198 Figure 1 (below) illustrates the data exchanges among the major 199 elements of the CT system, based on the log specification [TRANS] 200 and on the assumed behavior of other CT system elements as described 201 above. This Figure does not include the Audit function, because 202 there is not yet agreement on how that function will work in a 203 distributed, privacy-preserving fashion. 205 +----+ +---------+ +---------+ 206 | CA |---[ 1]-->| Log |<---[8]---| Monitor | 207 | | | | | | 208 | |<--[ 2]---| |----[9]-->| | 209 | | | | | | 210 | |---[ 3]-->| |<--[10]---| | 211 | | | | | |--------+ 212 | |<--[ 4]---| |---[11]-->| | | 213 | | | | +---------+ | 214 | | | | | 215 | | | | +---------+ | 216 | | | |<--[8]----| Self- | | 217 | | | | | Monitor | | 218 | | | |---[9]--->|(Subject)| | 219 | | | | | | | 220 | | | |<--[10]---| | [12] 221 | | | | | | | 222 | | | |---[11]-->| | | 223 | | +---------+ +---------+ | 224 | | | 225 | | +---------+ +---------+ | 226 | |---[ 5]-->| Website |---[7]--->| Browser | | 227 | | |(Subject)| +---------+ | 228 | |<--[ 6]-->| |<----------------------------+ 229 +----+ +---------+ 231 [ 1] Retrieve accepted root certs 232 [ 2] accepted root certs 233 [ 3] Add chain to log/add PreCertChain to log 234 [ 4] SCT (embedded in pre-cert, if applicable) 235 [ 5] send cert + SCTs (or cert with embedded SCTs) 236 [ 6] Revocation request/response (in response to detected 237 mis-issuance) 238 [ 7] cert + SCTs (or cert with embedded SCTs) 239 [ 8] Retrieve entries from Log 240 [ 9] returned entries from log 241 [10] Retrieve latest STH 242 [11] returned STH 243 [12] bogus/erroneous cert notification 245 Figure 1. Data Exchanges Between Major Elements of the CT System 246 Certificate mis-issuance may arise in one of several ways. The ways 247 by which CT enables a Subject (or others) to detect and redress mis- 248 issuance depends on the context and the entities involved in the 249 mis-issuance. This attack model applies to use of CT in the Web PKI 250 context. If CT is extended to apply to other contexts, each context 251 will require its own attack model, although most elements of the 252 model described here are likely to be applicable. 254 Because certificates are issued by CAs, the top level 255 differentiation in this analysis is whether the CA that mis-issued a 256 certificate did so maliciously or not. Next, for each scenario, the 257 model considers whether or not the certificate was logged. Scenarios 258 are further differentiated based on whether the logs and monitors 259 are benign or malicious and whether a certificate's Subject is self- 260 monitoring or is using a third party Monitoring service. Finally, 261 the analysis considers whether a browser is performing checking 262 relevant to CT. The scenarios are organized as illustrated by the 263 following outline: 265 Web PKI CA - malicious vs non-malicious 266 Certificate - logged vs not logged 267 Log - benign vs malicious 268 Third party Monitor - benign vs malicious 269 Certificate's Subject - self-monitoring (or not) 270 Browser - careful (or not) 272 The following sections examine each of these cases. As noted above, 273 the focus here is on the Web PKI context, although most of the 274 analysis is applicable to other PKI contexts. 276 Conventions used in this document 278 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 279 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 280 document are to be interpreted as described in [RFC2119]. 282 2. Semantic mis-issuance 284 2.1. Non-malicious Web PKI CA context 286 In this section, we address the case where the CA has no intent to 287 issue a bogus certificate. 289 A CA may have mis-issued a certificate as a result of an error or, in 290 the case of a bogus certificate, because it was the victim of a 291 social engineering attack or an attack such as the one that affected 292 DigiNotar 293 [https://www.vasco.com/company/about_vasco/press_room/news_archive/20 294 11/news_diginotar_reports_security_incident.aspx]. In the case of an 295 error, the CA should have a record of the erroneous certificate and 296 be prepared to revoke this certificate once it has discovered and 297 confirmed the error. In the event of an attack, a CA may have no 298 record of a bogus certificate. 300 2.1.1. Certificate logged 302 2.1.1.1. Benign log 304 The log (or logs) is benign and thus is presumed to provide 305 consistent, accurate responses to requests from all clients. 307 If a bogus (pre-)certificate has been submitted to one or more logs 308 prior to issuance to acquire an embedded SCT, or post-issuance to 309 acquire a standalone SCT, detection of mis-issuance is the 310 responsibility of a Monitor. 312 2.1.1.1.1. Self-monitoring Subject 314 If a Subject is tracking the log(s) to which a certificate was 315 submitted, and is performing self-monitoring, then it will be able to 316 detect a bogus (pre-)certificate and request revocation. In this 317 case, the CA will make use of the log entry (supplied by the Subject) 318 to determine the serial number of the bogus certificate, and 319 investigate/revoke it. (See Sections 4.1, 4.2 and 4.3.) 321 2.1.1.1.2. Benign third party Monitor 323 If a benign third party monitor is checking the logs to which a 324 certificate was submitted and is protecting the targeted Subject, it 325 will detect a bogus certificate and will alert the Subject. The 326 Subject, in turn, will ask the CA to revoke the bogus certificate. In 327 this case, the CA will make use of the log entry (supplied by the 328 Subject) to determine the serial number of the bogus certificate, and 329 revoke it (after investigation). (See Sections 4.1, 4.2 and 4.3.) 331 2.1.1.2. Mis-behaving log 333 In this case, the bogus (pre-)certificate has been submitted to one 334 or more logs, each of which generate an SCT for the submission. In 335 this scenario, a log probably will suppress a bogus certificate log 336 entry, or it may create an entry for the certificate but report it 337 selectively. (A mis-behaving log also could create and report 338 entries for bogus certificates that have not been issued by the 339 indicated CA (hereafter called "fake"). Unless a Monitor validates 340 the associated certificate chains up to roots that it trusts, these 341 fake bogus certificates could cause the Monitors to report non- 342 existent semantic problems to the Subject who would in turn report 343 them to the purported issuing CA. This might cause the CA to do 344 needless investigative work or perhaps incorrectly revoke and re- 345 issue the Subject's real certificate. Note that for every certificate 346 submitted to a log, the log MUST verify a complete certificate chain 347 up to one of the roots it accepts. So creating a log entry for a fake 348 bogus certificate marks the log as mis-behaving.) 350 2.1.1.2.1. Self-monitoring Subject 352 If a mis-behaving log suppresses a bogus certificate log entry, a 353 Subject performing self-monitoring will not detect the bogus 354 certificate. CT relies on an Audit mechanism to detect log 355 misbehavior, as a deterrent. (It is anticipated that logs that are 356 identified as persistently mis-behaving will cease to be trusted by 357 Monitors and by non-malicious CAs.) It is not clear if such a 358 mechanism will be viable if there are a very large number of self- 359 monitoring Subjects. 361 2.1.1.2.2. Benign third party Monitor 363 Because a mis-behaving log will suppress a bogus certificate log 364 entry (or report such entries inconsistently) a benign third party 365 Monitor that is protecting the targeted Subject also will not detect 366 a bogus certificate. In this scenario, CT relies on a distributed 367 Auditing mechanism [gossip] to detect log misbehavior, as a 368 deterrent. (See Section 4.6 below.) However, a Monitor (third-party 369 or self) must participate in the Audit mechanism in order to become 370 aware of log misbehavior. 372 If the mis-behaving log has logged the bogus certificate when it 373 issuing the associated SCT, it will try to hide this from the 374 Subject (if self-monitoring) or from the Monitor protecting the 375 Subject. It does so by presenting them with a view of its log 376 entries and STH that does not contain the bogus certificate. To 377 other entities, the log presents log entries and an STH that include 378 the bogus certificate. This discrepancy can be detected if there is 379 an exchange of information about the log entries and STH between the 380 entities receiving the view that excludes the bogus certificate and 381 entities that receive a view that includes it, i.e., a distributed 382 Audit mechanism. 384 If a malicious log does not create an entry for a bogus certificate 385 (for which an SCT has been issued), then any Monitor/Auditor that 386 sees the bogus certificate will detect this when it checks with the 387 log for log entries and STH (see Section 2.1.2.) 389 2.1.1.3. Mis-behaving third party Monitor 391 A third party Monitor that mis-behaves will not notify the targeted 392 Subject of a bogus certificate. This is true irrespective of whether 393 the Monitor checks the logs or whether the logs are benign or 394 malicious/conspiring. 396 Note that independent of any mis-issuance on the part of the CA, a 397 mis-behaving Monitor could issue false warnings to a Subject that it 398 protects. These could cause the Subject to report non-existent 399 semantic problems to the issuing CA and cause the CA to do needless 400 investigative work or perhaps incorrectly revoke and re-issue the 401 Subject's certificate. 403 2.1.2. Certificate not logged 405 If the CA does not submit a pre-certificate to a log, whether a log 406 is benign or mis-behaving does not matter. The same is true if a 407 Subject is issued a certificate without an SCT and does not log the 408 certificate itself, to acquire an SCT. Also, since there is no log 409 entry in this scenario, there is no difference in outcome between a 410 benign and a mis-behaving third party Monitor. In both cases, no 411 Monitor (self or third-party) will detect a bogus certificate based 412 on Monitor functions and there will be no consequent reporting of the 413 problem to the Subject or by the Subject to the CA based on 414 examination of log entries. 416 2.1.2.1. Self-monitoring Subject 418 A Subject performing self-monitoring will be able to detect the lack 419 of an embedded SCT in the certificate it received from the CA. The 420 Subject SHOULD notify the CA if the Subject believes that its 421 certificate was supposed to be logged. If the certificate was 422 supposed to be logged, but was not, the CA can use the certificate 423 supplied by the Subject to investigate and remedy the problem. In the 424 context of a benign CA, a failure to log the certificate might be the 425 result of an operations error, or evidence of an attack on the CA. 427 2.1.2.2. Careful browser 429 If a browser rejects certificates without SCTs (see Section 4.4.), 430 CAs may be "encouraged" to log the certificates they issue. This, in 431 turn, would make it easier for Monitors to detect bogus 432 certificates. However, it is not clear how such behavior by browsers 433 can be deployed incrementally throughout the Internet. As a result, 434 this model does not assume that browsers will reject a certificate 435 that is not accompanied by an SCT. In the absence of logging, 436 browsers generally do not benefit from CT, since certificates have 437 to be logged to enable detection of mis-issuance by Monitors, and to 438 trigger subsequent revocation. 440 2.2. Malicious Web PKI CA context 442 In this section, we address the scenario in which the mis-issuance 443 is intentional, not due to error. The CA is not the victim but the 444 attacker. 446 2.2.1. Certificate logged 448 2.2.1.1. Benign log 450 A bogus (pre-)certificate may be submitted to one or more benign logs 451 prior to issuance, to acquire an embedded SCT, or post-issuance to 452 acquire a standalone SCT. The log (or logs) replies correctly to 453 requests from clients. 455 2.2.1.1.1. Self-monitoring Subject 457 If a Subject is checking the logs to which a certificate was 458 submitted and is performing self-monitoring, it will be able to 459 detect the bogus certificate and will request revocation. The CA may 460 refuse to revoke, or may substantially delay revoking, the bogus 461 certificate. The CA could make excuses about inadequate proof that 462 the certificate is bogus, or argue that it cannot quickly revoke the 463 certificate because of legal concerns, etc. In this case, the CT 464 mechanisms will have detected mis-issuance, but the information 465 logged by CT does not help remedy the problem. (See Sections 3 and 466 5.) 468 2.2.1.1.2. Benign third party Monitor 470 If a benign third party monitor is checking the logs to which a 471 certificate was submitted and is protecting the targeted Subject, it 472 will detect the bogus certificate and will alert the Subject. The 473 Subject will then ask the CA to revoke the bogus certificate. As in 474 2.2.1.1.1, the CA may or may not revoke the certificate. 476 2.2.1.2. Mis-behaving log 478 A bogus (pre-)certificate may have been submitted to one or more 479 logs that are mis-behaving, e.g., conspiring with an attacker. These 480 logs may or may not issue SCTs, but will hide the log entries from 481 some or all Monitors. 483 2.2.1.2.1. Monitors - third party and self 485 If log entries are hidden from a Monitor (third party or self), the 486 Monitor will not be able to detect issuance of a bogus certificate. 488 The Audit function of CT is intended to detect logs that conspire to 489 delay or suppress log entries (potentially selectively), based on 490 consistency checking of logs. (See 2.1.1.2.2.) If a Monitor learns 491 of misbehaving log operation, it alerts the Subjects that it is 492 protecting, so that they no longer acquire SCTs from that log. The 493 Monitor also avoids relying upon such a log in the future. However, 494 unless a distributed Audit mechanism proves effective in detecting 495 such misbehavior, CT cannot be relied upon to detect this form of 496 mis-issuance. (See Section 4.6 below.) 498 2.2.1.3. Mis-behaving third party Monitor 500 If the third party Monitor that is "protecting" the targeted Subject 501 is mis-behaving, then it will not notify the targeted Subject of any 502 mis-issuance or of any malfeasant log behavior that it detects 503 irrespective of whether the logs it checks are benign or 504 malicious/conspiring. 506 2.2.2. Certificate not logged 508 Because the CA is presumed malicious, it may choose to not submit a 509 (pre-)certificate to a log. This means there is no SCT for the 510 certificate. 512 When a CA does not submit a certificate to a log, whether a log is 513 benign or mis-behaving does not matter. Also, since there is no log 514 entry, there is no difference in behavior between a benign and a mis- 515 behaving third-party Monitor. Neither will report a problem to the 516 Subject. 518 A bogus certificate would not be delivered to the (legitimate) 519 Subject. So the Subject, acting as a self-Monitor, cannot detect the 520 issuance of a bogus certificate in this case. 522 2.2.2.1. Careful browser 524 If careful browsers reject certificates without SCTs, CAs may be 525 "encouraged" to log certificates (see section 4.4.) However, it is 526 not clear how such behavior by browsers can be deployed 527 incrementally throughout the Internet. As a result, this model does 528 not assume that browsers will reject a certificate that is not 529 accompanied by an SCT. In the absence of logging, browsers generally 530 do not benefit from CT, since certificates have to be logged to 531 enable detection of mis-issuance by Monitors, and to trigger 532 subsequent revocation. 534 3. Syntactic mis-issuance 536 3.1. Non-malicious Web PKI CA context 538 This section analyzes the scenario in which the CA has no intent to 539 issue a syntactically incorrect certificate. Throughout the 540 remainder of this document we refer to a syntactically incorrect 541 certificate as "erroneous". 543 3.1.1. Certificate logged 545 3.1.1.1. Benign log 547 If a (pre-)certificate is submitted to a benign log, syntactic mis- 548 issuance can (optionally) be detected, and noted. This will happen 549 only if the log performs syntactic checks in general, and if the log 550 is capable of performing the checks applicable to the submitted 551 (pre-)certificate. (A (pre-)certificate SHOULD be logged even if it 552 fails syntactic validation; logging takes precedence over detection 553 of syntactic mis-issuance.) If syntactic validation fails, this can 554 be noted in an SCT extension returned to the submitter. 556 . If the (pre-)certificate is submitted by the non-malicious issuing 557 CA, and if the CA has a record of the certificate content, then 558 the CA SHOULD remedy the syntactic problem and re-submit the 559 (pre-)certificate to a log or logs. If this is a pre-certificate 560 submitted prior to issuance, syntactic checking by a log helps 561 avoid issuance of an erroneous certificate. If the CA does not 562 have a record of the certificate contents, then presumably it 563 was a bogus certificate and the CA SHOULD revoke it. 565 . If a certificate is submitted by its Subject, and is deemed 566 erroneous, then the Subject SHOULD contact the issuing CA and 567 request a new certificate. If the Subject is a legitimate 568 subscriber of the CA, then the CA will either have a record of 569 the certificate content or can obtain a copy of the certificate 570 from the Subject. The CA will remedy the syntactic problem and 571 either re-submit a corrected (pre-)certificate to a log and send 572 it to the Subject or the Subject will re-submit it to a log. 573 Here too syntactic checking by a log enables a Subject to be 574 informed that its certificate is erroneous and thus may hasten 575 issuance of a replacement certificate. 577 . If a certificate is submitted by a third party, that party might 578 contact the Subject or the issuing CA, but because the party is 579 not the Subject of the certificate it is not clear how the CA 580 will respond. 582 Bottom line: Syntactic mis-issuance of a certificate can be avoided 583 by a CA if it makes use of logs that are capable of performing these 584 checks for the types of certificates that are submitted, and if the 585 CA acts on the feedback it receives. If a CA uses a log that does not 586 perform such checks, or if the CA requests checking relative to 587 criteria not supported by the log, then syntactic mis-issuance will 588 not be detected or avoided by this mechanism. Similarly, syntactic 589 mis-issuance can be remedied if a Subject submits a certificate to a 590 log that performs syntactic checks, and if the Subject asks the 591 issuing CA to fix problems detected by the log. (The issuer is 592 presumed to be willing to re-issue the certificate, correcting any 593 problems, because the issuing CA is not malicious.) 595 3.1.1.2. Mis-behaving log or third party Monitor 597 A log or Monitor that is conspiring with the attacker or is 598 independently malicious, will either not perform syntactic checks, 599 even though it claims to do so, or simply not report errors. The log 600 entry and the SCT for an erroneous certificate will assert that the 601 certificate syntax was verified. 603 As with detection of semantic mis-issuance, a distributed Audit 604 mechanism could, in principle, detect mis-behavior by logs or 605 Monitors with respect to syntactic checking. For example, if for a 606 given certificate, some logs (or Monitors) are reporting syntactic 607 errors and some which claim to do syntactic checking, are not 608 reporting these errors, this is indicative of misbehavior by these 609 logs and/or Monitors. 611 Note that a malicious log (or Monitor) could report syntactic errors 612 for a syntactically valid certificate. This could result in 613 reporting of non-existent syntactic problems to the issuing CA, which 614 might cause the CA to do needless investigative work or perhaps 615 incorrectly revoke and re-issue the Subject's certificate. 617 3.1.1.3. Self-monitoring Subject and Benign third-party Monitor 619 If a Subject or benign Monitor performs syntactic checks, it will 620 detect the erroneous certificate and the issuing CA will be notified 621 (by the Subject). If the Subject is a legitimate subscriber of the 622 CA, then the CA will either have a record of the certificate content 623 or can obtain a copy of the certificate from the Subject. The CA 624 SHOULD revoke the erroneous certificate (after investigation) and 625 remedy the syntactic problem. The CA SHOULD either re-submit the 626 corrected (pre-)certificate to one or more logs and then send the 627 result to the Subject, or send the corrected certificate to the 628 Subject, who will re-submit it to one or more logs. 630 3.1.1.4. Careful browser 632 If a browser rejects an erroneous certificate and notifies the 633 Subject and/or the issuing CA, then syntactic mis-issuance will be 634 detected (see Section 4.) Unfortunately, experience suggests that 635 many browsers do not perform thorough syntactic checks on 636 certificates, and so it seems unlikely that browsers will be a 637 reliable way to detect erroneous certificates. Moreover, a protocol 638 used by a browser to notify a Subject and/or CA of an erroneous 639 certificate represents a DoS potential, and thus may not be 640 appropriate. This argues for syntactic checking to be performed by 641 other elements of the CT system, e.g., logs and/or Monitors. 643 3.1.2. Certificate not logged 645 If a CA does not submit a certificate to a log, there can be no 646 syntactic checking by the log. Detection of syntactic errors will 647 depend on a Subject performing the requisite checks when it receives 648 its certificate from a CA. 650 3.2. Malicious Web PKI CA context 652 This section analyzes the scenario in which the CA's issuance of a 653 syntactically incorrect certificate is intentional, not due to error. 654 The CA is not the victim but the attacker. 656 3.2.1. Certificate logged 658 3.2.1.1. Benign log 660 Because the CA is presumed to be malicious, the CA may cause the log 661 to not perform checks, in one of several ways. (See [DOMVAL] and 662 [EXTVAL] for more details on validation checks and CCIDs). 664 1. The CA may assert that the certificate is being issued w/o 665 regard to any guidelines (the "no guidelines" reserved CCID). 667 2. The CA may assert a CCID that has not been registered, and thus 668 no log will be able to perform a check. 670 3. The CA may check to see which CCIDs a log declares it can 671 check, and chose a registered CCID that is not checked by the log 672 in question. In this fashion the CA can prevent the log from 673 performing checks, and the SCT and log entry will not contain an 674 indication of a failed check. 676 4. The CA may submit a (pre-) certificate to a log that is known 677 to not perform any syntactic checks, and thus avoid syntactic 678 checking. 680 3.2.1.2. Mis-behaving log or third party Monitor 682 A mis-behaving log or third party Monitor will either not perform 683 syntactic checks or not report any problems that it discovers. (See 684 3.1.1.2 for further problems). 686 3.2.1.3. Self-monitoring Subject and Benign third party Monitor 688 Irrespective of whether syntactic checks are performed by a log, a 689 malicious CA will acquire an embedded SCT, or post-issuance will 690 acquire a standalone SCT. If Subjects or Monitors perform syntactic 691 checks that detect the syntactic mis-issuance and report the problem 692 to the CA, a malicious CA may do nothing or may delay action to 693 remedy the problem. 695 3.2.1.4. Careful browser 697 As noted above (3.1.1.4) many browsers fail to perform thorough 698 syntax checks on certificates. Such browsers would benefit from 699 having such checks performed by a log and reported in the SCT. 700 (Remember, in this scenario, the log is benign.) However, if a 701 browser does not discriminate against certificates that do not 702 contain SCTs (or that are not accompanied by an SCT in the TLS 703 handshake), only minimal benefits might accrue to them from syntax 704 checks perform by logs. 706 If a browser accepts certificates that do not appear to have been 707 syntactically checked by a log (as indicated by the SCT), a 708 malicious CA need not worry about failing a log-based check. 709 Similarly, if there is no requirement for a browser to reject a 710 certificate that was logged by an operator that does not perform 711 syntactic checks, the fourth approach noted in 3.2.1.1 will succeed 712 as well. If a browser were configured to know which versions of 713 certificate types are applicable to its use of a certificate, the 714 second and third strategies noted above could be thwarted. 716 3.2.2. Certificate is not logged 718 Since certificates are not logged in this scenario, a Monitor (third- 719 party or self) cannot detect the issuance of an erroneous 720 certificate. Thus there is no difference between a benign or a 721 malicious/conspiring log or a benign or conspiring/malicious Monitor. 722 (A Subject MAY detect a syntax error by examining the certificate 723 returned to it by the Issuer.) However, even if errors are detected 724 and reported to the CA, a malicious/conspiring CA may do nothing to 725 fix the problem or may delay action. 727 4. Issues Applicable to Sections 2 and 3 729 4.1. How does a Subject know which Monitor(s) to use? 731 If a CA submits a bogus certificate to one or more logs, but these 732 logs are not tracked by a Monitor that is protecting the targeted 733 Subject, CT will not remedy this type of mis-issuance attack. It is 734 not clear whether every Monitor MUST offer to track every Subject 735 that requests protection. Absent such a guarantee, how do Subjects 736 know which set of Monitors will provide "sufficient" coverage? If a 737 Subject acts as its own Monitor, this problem is solved for that 738 Subject. 740 4.2. How does a Monitor discover new logs? 742 It is not clear how a (self-)Monitor becomes aware of all (relevant?) 743 logs, including newly created logs. The means by which Monitors 744 become aware of new logs MUST accommodate self-monitoring by a 745 potentially very large number of web site operators. If there are 746 many logs, it may not be feasible for a (self-) Monitor to track all 747 of them. 749 4.3. CA response to report of a bogus or erroneous certificate 751 A CA being presented with evidence of a bogus or erroneous 752 certificate, in the form of a log entry and/or SCT, will need to 753 examine its records to determine if it has knowledge of the 754 certificate in question. It also will likely require the targeted 755 Subject to provide assurances that it is the authorized entity 756 representing the Subject name (subjectAltname) in question. Thus a 757 Subject should not expect immediate revocation of a contested 758 certificate. The time frame in which a CA will respond to a 759 revocation request usually is described in the CPS for the CA. Other 760 certificate fields and extensions may be of interest for forensic 761 purposes, but are not required to effect revocation nor to verify 762 that the certificate to be revoked is bogus or erroneous, based on 763 applicable criteria. The SCT and log entry, because each contains a 764 timestamp from a third party, is probably valuable for forensic 765 purposes (assuming a non-conspiring log operator). 767 4.4. Browser behavior 769 If a browser is to reject a certificate that lacks an embedded SCT, 770 or is not accompanied by an SCT transported via the TLS handshake, 771 this behavior needs to be defined in a way that is compatible with 772 incremental deployment. Issuing a warning to a (human) user is 773 probably insufficient, based on experience with warnings displayed 774 for expired certificates, lack of certificate revocation status 775 information, and similar errors that violate RFC 5280 path validation 776 rules. Unless a mechanism is defined that accommodates incremental 777 deployment of this capability, attackers probably will avoid 778 submitting bogus certificates to (benign) logs as a means of evading 779 detection. 781 4.5. Remediation for a malicious CA 783 A targeted Subject might ask the parent of a malicious CA to revoke 784 the certificate of the non-cooperative CA. However, a request of this 785 sort may be rejected, e.g., because of the potential for significant 786 collateral damage. A browser might be configured to reject all 787 certificates issued by the malicious CA, e.g., using a CA hot list 788 distributed by a browser vendor. However, if the malicious CA has a 789 sufficient number of legitimate clients, treating all of their 790 certificates as bogus or erroneous still represents serious 791 collateral damage. If this specification were to require that a 792 browser can be configured to reject a specific, bogus or erroneous 793 certificate identified by a Monitor, then the bogus or erroneous 794 certificate could be rejected in that fashion. This remediation 795 strategy calls for communication between Monitors and browsers, or 796 between Monitors and browser vendors. Such communication has not been 797 specified, i.e., there are no standard ways to configure a browser to 798 reject individual bogus or erroneous certificates based on 799 information provided by an external entity such as a Monitor. 800 Moreover, the same or another malicious CA could issue new bogus or 801 erroneous certificates for the targeted Subject, which would have to 802 be detected and rejected in this (as yet unspecified) fashion. Thus, 803 for now, CT does not seem to provide a way to remedy this form of 804 attack, even though it provides a basis for detecting such attacks. 806 4.6. Auditing - detecting mis-behaving logs 808 The combination of a malicious CA and one or more conspiring logs 809 motivates the definition of an audit function, to detect conspiring 810 logs. If a Monitor protecting a Subject does not see bogus 811 certificates, it cannot alert the Subject. If one or more SCTs are 812 present in a certificate, or passed via the TLS handshake, a browser 813 has no way to know that the logged certificate is not visible to 814 Monitors. Only if Monitors and browsers reject certificates that 815 contain SCTs from conspiring logs (based on information from an 816 auditor) will CT be able to detect and deter use of such logs. Thus 817 the means by which a Monitor performing an audit function detects 818 such logs, and informs browsers must be specified for CT to be 819 effective in the context of mis-behaving logs. 821 Absent a well-defined mechanism that enables Monitors to verify that 822 data from logs are reported in a consistent fashion, CT cannot claim 823 to provide protection against logs that are malicious or may 824 conspire with, or are victims of, attackers effecting certificate 825 mis-issuance. The mechanism needs to protect the privacy of users 826 with respect to which web sites they visit. It needs to scale to 827 accommodate a potentially large number of self-monitoring Subjects 828 and a vast number of browsers, if browsers are part of the 829 mechanism. Even when an Audit mechanism is defined, it will be 830 necessary to describe how the CT system will deal with a mis- 831 behaving or compromised log. For example, will there be a mechanism 832 to alert all browsers to reject SCTs issued by such a log? Absent a 833 description of a remediation strategy to deal with mis-behaving or 834 compromised logs, CT cannot ensure detection of mis-issuance in a 835 wide range of scenarios. 837 Monitors play a critical role in detecting semantic certificate mis- 838 issuance, for Subjects that have requested monitoring of their 839 certificates. A monitor (including a Subject performing self- 840 monitoring) examines logs for certificates associated with one or 841 more Subjects that are being "protected". A third-party Monitor must 842 obtain a list of valid certificates for the Subject being monitored, 843 in a secure manner, to use as a reference. It also must be able to 844 identify and track a potentially large number of logs on behalf of 845 its Subjects. This may be a daunting task for Subjects that elect to 846 perform self-monitoring. 848 Note: A Monitor must not rely on a CA or RA database for its 849 reference information or use certificate discovery protocols; this 850 information must be acquired by the Monitor based on reference 851 certificates provided by a Subject. If a Monitor were to rely on a 852 CA or RA database (for the CA that issued a targeted certificate), 853 the Monitor would not detect mis-issuance due to malfeasance on the 854 part of that CA or the RA, or due to compromise of the CA or the 855 RA. If a CA or RA database is used, it would support detection of 856 mis-issuance by an unauthorized CA. A Monitor must not rely on 857 certificate discovery mechanisms to build the list of valid 858 certificates since such mechanisms might result in bogus or 859 erroneous certificates being added to the list. 861 As noted above, Monitors represent another target for adversaries 862 who wish to effect certificate mis-issuance. If a Monitor is 863 compromised by, or conspires with, an attacker, it will fail to 864 alert a Subject to a bogus or erroneous certificate targeting that 865 Subject, as noted above. It is suggested that a Subject request 866 certificate monitoring from multiple sources to guard against such 867 failures. Operation of a Monitor by a Subject, on its own behalf, 868 avoids dependence on third party Monitors. However, the burden of 869 Monitor operation may be viewed as too great for many web sites, and 870 thus this mode of operation ought not be assumed to be universal 871 when evaluating protection against Monitor compromise. 873 5. Security Considerations 875 A threat model is, by definition, a security-centric document. Unlike 876 a protocol description, a threat model does not create security 877 problems nor does it purport to address security problems. This model 878 postulates a set of threats (i.e., motivated, capable adversaries) 879 and examines classes of attacks that these threats are capable of 880 effecting, based on the motivations ascribed to the threats. 882 6. IANA Considerations 884 None. 886 7. Acknowledgments 888 The author would like to thank David Mandelberg and Karen Seo for 889 help with the editing and formatting, and other members of the TRANS 890 working group for reviewing this document. 892 8. References 894 8.1. Normative References 896 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 897 Requirement Levels," BCP 14, RFC 2119, March 1997. 899 8.2. Informative References 901 [TRANS] Laurie, B., Langley, A., Kasper, E., Messeri, E., 902 Stradling, R., "Certificate Transparency," draft-ietf- 903 trans-rfc6962-bis-07 (March 9, 2015), work in progress. 905 [DOMVAL] Kent, S., "Syntactic and Semantic Checks for Domain 906 Validation Certificates," draft-kent-trans-domain- 907 validation-cert-checks-01, (December 2014), work in 908 progress. 910 [EXTVAL] Kent, S., "Syntactic and Semantic Checks for Extended 911 Validation Certificates," draft-kent-trans-extended- 912 validation-cert-checks-01 (December 2014), work in 913 progress. 915 [gossip] Nordberg, L, Gillmore, D, "Gossiping in CT," draft-linus- 916 trans-gossip-ct-01, (March 9, 2015), work in progress 918 Author's Addresses 920 Stephen Kent 921 BBN Technologies 922 10 Moulton Street 923 Cambridge MA 02138 924 USA 926 Phone: +1 (617) 873-3988 927 Email: skent@bbn.com 929 Copyright Statement 931 Copyright (c) 2015 IETF Trust and the persons identified as the 932 document authors. All rights reserved. 934 This document is subject to BCP 78 and the IETF Trust's Legal 935 Provisions Relating to IETF Documents 936 (http://trustee.ietf.org/license-info) in effect on the date of 937 publication of this document. Please review these documents 938 carefully, as they describe your rights and restrictions with respect 939 to this document. Code Components extracted from this document must 940 include Simplified BSD License text as described in Section 4.e of 941 the Trust Legal Provisions and are provided without warranty as 942 described in the Simplified BSD License.