idnits 2.17.1 draft-tschofenig-iab-webpki-evolution-01.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 19, 2013) is 3782 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3280' is defined on line 744, but no explicit reference was found in the text == Outdated reference: A later version (-21) exists of draft-ietf-websec-key-pinning-08 ** Obsolete normative reference: RFC 3280 (Obsoleted by RFC 5280) ** Obsolete normative reference: RFC 6962 (Obsoleted by RFC 9162) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Tschofenig 3 Internet-Draft E. Lear 4 Intended status: Informational IAB Security Program 5 Expires: May 23, 2014 November 19, 2013 7 Evolving the Web Public Key Infrastructure 8 draft-tschofenig-iab-webpki-evolution-01.txt 10 Abstract 12 The problems with the WebPKI have received the attention by the 13 Internet security community when DigiNotar, a Dutch certification 14 authority, had a security breach in 2011 and in the same year a 15 Comodo affiliate was compromised. Both cases led to fraudulent 16 issuance of certificates and raise questions regarding the strength 17 of the WebPKI used by so many applications. 19 Almost 2 years have passed since these incidents and various 20 standardization activities have happened in the meanwhile offering 21 new technical solutions to make the public key infrastructure more 22 resilient. 24 The important question, however, is which of the technical solutions 25 will get widespread deployment? In this document we compare the 26 different technical solutions in an attempt to engage the impacted 27 stakeholders to trigger deployment actions to improve the status quo. 28 This document does not include any recommendations what techniques to 29 use. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on May 23, 2014. 48 Copyright Notice 50 Copyright (c) 2013 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 3. Technical Solutions . . . . . . . . . . . . . . . . . . . . . 5 68 3.1. Public Key Pinning for HTTP . . . . . . . . . . . . . . . 5 69 3.2. Trust Assertions for Certificate Keys (TACK) . . . . . . 6 70 3.3. Perspectives . . . . . . . . . . . . . . . . . . . . . . 6 71 3.4. Convergence . . . . . . . . . . . . . . . . . . . . . . . 8 72 3.5. Sovereign Keys . . . . . . . . . . . . . . . . . . . . . 8 73 3.6. Mutually Endorsing CA Infrastructure (MECAI) . . . . . . 9 74 3.7. DNS-Based Authentication of Named Entities (DANE) . . . . 10 75 3.8. Certificate Transparency . . . . . . . . . . . . . . . . 10 76 3.9. DetecTor . . . . . . . . . . . . . . . . . . . . . . . . 11 77 4. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . 11 78 4.1. Public Key Pinning for HTTP . . . . . . . . . . . . . . . 12 79 4.2. Trust Assertions for Certificate Keys (TACK) . . . . . . 12 80 4.3. Perspectives . . . . . . . . . . . . . . . . . . . . . . 12 81 4.4. Convergence . . . . . . . . . . . . . . . . . . . . . . . 13 82 4.5. Sovereign Keys . . . . . . . . . . . . . . . . . . . . . 13 83 4.6. Mutually Endorsing CA Infrastructure (MECAI) . . . . . . 13 84 4.7. DNS-Based Authentication of Named Entities (DANE) . . . . 14 85 4.8. Certificate Transparency . . . . . . . . . . . . . . . . 14 86 4.9. DetecTor . . . . . . . . . . . . . . . . . . . . . . . . 14 87 4.10. Limitations . . . . . . . . . . . . . . . . . . . . . . . 15 88 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 89 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 15 90 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 91 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 92 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 93 9.1. Normative References . . . . . . . . . . . . . . . . . . 16 94 9.2. Informative References . . . . . . . . . . . . . . . . . 17 96 1. Introduction 98 High-profile data breaches and security incidents on the Web are 99 gaining increasing attention from the public, the press, and 100 governments. A few examples may illustrate the problems: DigiNotar, 101 a Dutch certification authority, had a security breach [DigiNotar] 102 and in the same year a Comodo affiliate was compromised [Comodo]. 103 Both cases led to fraudulent issuance of certificates. 105 The Web Public Key Infrastructure (WebPKI) makes use of trusted third 106 parties, the certification authority (CAs), to bind a subject name to 107 a public key. A CA may, however, be compromised despite the best 108 security practices and operational procedures. The main problem, 109 however, is that any CA can issue a certificate for any domain name. 110 One compromised CA is therefore able to impact the security of the 111 entire public key infrastructure. In the case of DigiNotar the 112 attacker was able to issue certificates for Google services even 113 though Google never made use of services from DigiNotar. 115 Furthermore, over time browser vendors and operating systems 116 increased the number of trust anchors (TAs) that are pre-installed. 117 Depending on software the number of trust anchors may exceed 600, as 118 reported by the Electronic Frontier Foundation (EFF) in their SSL 119 Observatory study [SSL-Observatory]. While the larger number 120 provides choice for subjects regarding the CA they can select for 121 obtaining a certificate there is also a downside: with today's WebPKI 122 set-up it is sufficient to compromise a single CA to impact the 123 security for all relying parties. Many users were surprised about 124 the large number of trust anchors installed in normal operating 125 systems and browsers without having an easy way to adjust that list 126 to their preferences. Worse, most end users would not know what 127 criteria to use to manage the trust anchor stores, even with better 128 interfaces. 130 To re-state the problem statement: Every CA can issue certificates 131 for any relying party even though that relying party may have never 132 been in a relationship with the issuing CA. (Note that the trust 133 anchor of that CA needs to be provisioned into the trust anchor 134 store.) 135 These developments have led to a number of protocol design activities 136 for improving the WebPKI. In this document we briefly summarize the 137 available technical solutions and include an assessment about who 138 needs to make changes, what type of benefits are provided, and what 139 dependencies exist. The investigated solutions include DANE 140 [RFC6698], Certificate Transparency [RFC6962], Public Key Pinning 141 [I-D.ietf-websec-key-pinning], TACK [I-D.perrin-tls-tack], 142 Perspectives [Perspectives], Sovereign Keys [SovereignKeys], MECAI 143 [MECAI], Convergence [Convergence], and DetecTor [DetecTor]. 145 There are many challenges with security on the Web, including user 146 interface problems with certificate warnings, insecure use of 147 cookies, cross-site scripting attacks, and injection attacks. This 148 document focuses only on improving the WebPKI. It is also worth 149 reminding ourselves that the WebPKI is not only used for Web 150 applications but also for a range of other applications, including 151 smart phone apps. 153 The main purpose of this document is to provide an overview of some 154 technical solutions. This description will help us to develop a 155 roadmap for the deployment of the best solutions to improve the 156 overall security of the public key infrastructure. 158 Final note: There are also process solutions, such as stricter audits 159 of CAs with the aim to improve operational practices, and these are 160 not described in this document. These measures will be useful in 161 addition to technical solutions but alone they will, however, not 162 address the underlying problem. 164 2. Terminology 166 This document uses the following terms from from RFC 5280 [RFC5280]: 168 end entity: user of PKI certificates and/or end user system that is 169 the subject of a certificate. 171 CA: certification authority 173 This document also re-uses the term "Leap of faith" from RFC 5386 174 [RFC5386]: 176 "Leap of faith is the term generally used when a user accepts the 177 assertion that a given key identifies a peer on the first 178 communication (despite a lack of strong evidence for that 179 assertion), and then remembers this association for future 180 communications." 181 This security property has become fairly popular with use of 182 Secure Shell [RFC4251], which made use of the leap of faith 183 property. 185 RFC 6973 [RFC6973] provides a definition of the term 'relying party': 187 "The relying party is an entity that relies on assertions of 188 individuals' identities from identity providers in order to 189 provide services to individuals. In effect, the relying party 190 delegates aspects of identity management to the identity 191 provider(s). Such delegation requires protocol exchanges, trust, 192 and a common understanding of semantics of information exchanged 193 between the relying party and the identity provider." 195 In the context of this document the relying party is a TLS client, 196 for example, used to protect the communication from a Web server. 197 Although a lot of focus is on the Web there are other non-HTTP- 198 based services that are included in the definition and may 199 benefits from improvements discussed in this document. 201 The terms 'trust anchor' and 'trust anchor store' are defined in 202 [RFC6024]: 204 "A trust anchor represents an authoritative entity via a public 205 key and associated data. The public key is used to verify digital 206 signatures, and the associated data is used to constrain the types 207 of information for which the trust anchor is authoritative." 209 "A trust anchor store is a set of one or more trust anchors stored 210 in a device. A device may have more than one trust anchor store, 211 each of which may be used by one or more applications." 213 3. Technical Solutions 215 3.1. Public Key Pinning for HTTP 217 [I-D.ietf-websec-key-pinning] describes a solution for instructing 218 user agents (UAs) to remember ("pin") certificates (end entity 219 certificates or CA certs) for a given period of time. This pin is 220 provided to the client with the initial interaction with a Web server 221 using a newly defined HTTP headers. During that time, UAs will 222 require that the TLS server presents a certificate chain including at 223 least one Subject Public Key Info structure the fingerprint of which 224 matches one of the pinned fingerprints for that server. 226 While the specification provides a number of instructions for the 227 Website operator the basic operation is rather simple and assumes a 228 leap-of-faith policy. To deal with the change of certificates or 229 other failure scenarios, the concept of a backup pin is utilized. A 230 Backup Pin is a fingerprint for the public key of a secondary, not- 231 yet-deployed key pair. The operator keeps the backup key pair 232 offline, and sets a pin for it in the Public-Key-Pins header. If an 233 operator loses control of his/her primary private key, he/she can 234 deploy the backup key pair. An interesting feature of the 235 specification is to report pin validation failure to a URI using an 236 HTTP POST. 238 When a pin validation failure occurs the expectation is that the user 239 is notified about the inconsistency (with optionally reporting taking 240 place in the background). 242 This document is the product of the IETF Web Security working group. 244 3.2. Trust Assertions for Certificate Keys (TACK) 246 Similarly to the key pinning solution described in Section 3.1 TACK 247 [I-D.perrin-tls-tack], also aims to enables a TLS server to support 248 "pinning" to a self-chosen signing key. 250 A TLS server operator creates a so-called "TACK signing key" (TSK) 251 and signs its own keys using this TSK. A TACK pin then associates a 252 hostname, a TSK, and various parameters (including pin creation time, 253 and lifetime of the pin). A TLS server operator may change a key for 254 a server at any point in time since the TSK will be unchanged. Each 255 server thereby acts as its own CA and issues end entity certificates 256 to itself. Clients store the TACK pins in their pin stores, which 257 they obtain via a TLS extension from the server directly. When TACK 258 pins are obtained from the TLS server directly, they follow a leap- 259 of-faith approach. 261 To enable incremental deployment, a TLS client uses the extension 262 mechanism of TLS to indicate support for the TACK extension by 263 including a new TLS extension type in the ClientHello message. A TLS 264 server that does not support TACK will reply with an ordinary 265 certificate. In case the TLS server supports the extension it 266 replies with the newly defined tack structure, which contains the 267 TACK pin for that server. 269 This specification is an individual submission to the IETF. 271 3.3. Perspectives 273 Perspectives [Perspectives] aims to utilize notaries (i.e., public 274 servers) that monitor and record the history of public keys used by 275 services. A notary cryptographically signs statements saying that at 276 time t it observed service S using public key K. While the 277 description focuses on the use of raw public keys (in the style of 278 SSH) the same concept also works with certificates. 280 The basic approach is simple: When a TLS client starts to interact 281 with a TLS server it is presented with a key/certificate that it had 282 not seen before. To verify that the key/certificate is the same as 283 observed by other vantage points in the network it contacts notary 284 servers. These notaries provide key/certificate information they 285 have obtained about the specific website earlier. Subsequently, 286 clients cache the information returned by notaries for future use. 288 Since the security and availability of the proposed system depends on 289 the location, the independence, and the number of notaries the 290 following approach is suggested. Notaries are organized in groups, 291 each group having a notary authority. The notary authority publishes 292 lists of the notaries it offers. These lists contain entries with IP 293 address information and their public keys, one for each notary. This 294 list is then digitally signed with the private key of the notary 295 authority. Clients are expected to download these lists and verify 296 them with the public key of the respective notary authority. The 297 public keys of the notary authorities are obtained out-of-band. 299 To improve the leap of faith security by clients, the notary services 300 adds security value since they may have obtained the key/certificate 301 from the website in the past already and from different vantage 302 points (in terms of the path used to talk to the server). This helps 303 when attacks are either temporary and or when a man-in-the-middle 304 attacker is located somewhere along the path between the client and 305 the server but closer to the client. The use of multiple notaries 306 also helps to detect malicious notaries. 308 Similar to other notary services there is the question about how they 309 obtain the keys/certificates of TLS servers (and other services). 310 For popular services the keys/certificates are assumed to pre- 311 configured at the notaries and queried periodically. For the long 312 tail of small websites the suggested approach is to query these sites 313 the first time a client wants to connect to them since this is the 314 time when the notary learns about their existence. 316 With clients caching information about the keys/certificates of sites 317 visited earlier, and the information obtained from notaries, there is 318 no additional protocol overhead. In this respect the solution works 319 similar to key pinning. The additional communication overhead for 320 the client only occurs at the time when the client talks to a server 321 for the first time or when the cached information expires. 323 The proposal is documented in form of an academic research paper, see 324 [Perspectives], but no technical specification is available. 326 3.4. Convergence 328 Convergence [Convergence] is a proposal by Moxie Marlinspike that 329 makes two improvements to Perspectives, namely 331 Reducing Notary Lag: The Perspectives solution required TLS clients 332 to interact with notaries to check whether a certificate obtained 333 via TLS matches the information seen notaries. Notaries then had 334 to initiate an interaction with the TLS servers to obtain 335 information about what certificates they see. Convergence reduces 336 this interaction by utilizing caching of certificates at the 337 notaries. By doing this, however, they also introduce a delay 338 between the time a new certificate is put in operation at a TLS 339 server and when the notaries get to learn about it. 341 Increased Privacy Protection: First, clients cache certificates so 342 that they do not need to contact notaries every time they contact 343 a Web site. Second, clients use a concept called 'notary 344 bouncing' whereby they pick a notary randomly out of their pool of 345 trusted notaries and use it as a proxy to talk to other notaries. 346 Thereby, the notary that receives the query will only see the IP 347 address of another notary who forwarded the query rather than the 348 IP address of the client. 350 As a main advantage, according to the author and similar to 351 Perspectives, there is no impact on TLS server deployment, except in 352 rare situations where multiple certificates are used by a single site 353 in combination with a load balancer. Load balancers often terminate 354 TLS connections and if those load balancers use independent 355 certificates then different notaries requesting certificates from the 356 Web site will receive different certificates. 358 Notaries are designed to be extensible by supporting different 359 mechanisms with respect to how they obtain certificates. Currently, 360 Convergence uses the technique proposed by Perspectives to probe a 361 TLS server. 363 The documentation of Convergence only exists in form of a 364 presentation by Moxie Marlinspike given at the BlackHat USA 2011 365 conference [ConvergenceTalk]. 367 3.5. Sovereign Keys 369 Sovereign Keys [SovereignKeys] is a proposal by the Electronic 370 Frontier Foundation (EFF). It introduces two new concepts to deal 371 with attacks against the WebPKI. 373 Sovereign key: Each domain owner creates a new key pair, the 374 sovereign keys, and use the private key to sign its operational 375 (EE) certificates or public keys. 377 Timeline servers: Append-only timeline servers, as new entities, are 378 introduced. They stores mappings between domain names and 379 sovereign keys. To claim a key for a domain name requires 380 evidence of control in the DNS either via a CA-signed certificate 381 or via a key published in the DNS (as provided by DANE). 383 Each timeline server possesses a unique private/public key pair and 384 these keys are assumed to be shipped with client software or TLS 385 libraries to ensure that clients can verify the authenticity of 386 timeline entries. The timeline servers record the history of claims 387 to sovereign keys. 389 TLS clients query timeline servers for entries that belong to a 390 certain domain and verify that the end-entity certificate has been 391 issued under the sovereign key. If the verification fails then the 392 connection attempt is refused. 394 A high-level description can be found at [SovereignKeys] and a more 395 detailed technical specification is available at 396 [SovereignKeys-Spec]. 398 3.6. Mutually Endorsing CA Infrastructure (MECAI) 400 MECAI [MECAI] builds conceptually on top of the Perspective proposal. 401 Perspectives introduces notaries, as new entities in the WebPKI, and 402 MECAI takes the position that this function can be taken by existing 403 CAs. With this new role they would turn into Voucher Authorities 404 (VAs), who issue vouchers that confirm what they observe. A voucher 405 is a signature computed over a number of fields including the hash of 406 a server certificate, a certificate chain, the IP address of the 407 server, revocation status information, etc. Of course, a voucher 408 would be created by a CA other than the one that created the original 409 certificate. 411 A client would therefore perform the following steps: it connects to 412 a server via TLS and the server provides the certificate. Then, the 413 client needs to obtain one or multiple vouchers for the server 414 certificate. This can happen either inband within the TLS handshake 415 when talking to the server, similarly to how OCSP stapling works, or 416 via a separate protocol exchange. The former approach is less 417 expensive in terms of communication costs for the client. In any 418 case, a voucher request protocol is needed to let entities (like TLS 419 servers) talk to VAs to obtain a voucher. 421 A client or a server can detect misissuance by matching the 422 information in the vouchers with the certificate. 424 Only a high-level description is available via [MECAI] but no 425 detailed technical specification. 427 3.7. DNS-Based Authentication of Named Entities (DANE) 429 DANE [RFC6698] offers the option to use the DNS infrastructure to 430 store certificates. DANE is envisioned as a preferable basis for 431 binding public keys to DNS names, because the entities that vouch for 432 the binding of public key data to DNS names are the same entities 433 responsible for managing the DNS names in question. 435 Distributing certificates via the DNS does, however, require DNSSEC. 436 With the help of DNSSEC [RFC4033][RFC4034][RFC4035] this offers an 437 opportunity to eliminate off-line processes for validation of the 438 subject name, which today often requires sending a mail to the 439 administrator of that domain. This relationship can be easily 440 demonstrated by having the zone administrator for the subject domain 441 post the public key in the DNS and digitally sign the resulting zone. 443 A high-level description about the different options offered by DANE 444 can be found in [IETF-Journal-DANE] and the authoritative version can 445 be found in RFC 6698 [RFC6698]. 447 3.8. Certificate Transparency 449 RFC 6962 [RFC6962] specifies Certificate Transparency, a protocol for 450 publicly logging the existence of certificates as they are issued or 451 observed. This allows anyone to audit certification authority (CA) 452 activity and detect the issuance of suspect certificates, as well as 453 to audit the certificate logs themselves. The intent is that 454 eventually clients would refuse to honor certificates that do not 455 appear in a log, effectively forcing CAs to add all issued 456 certificates to the logs. 458 The publicly auditable, append-only logs of all issued certificates 459 does not prevent misissue but allows interested parties to detect 460 misissuance. 462 While various projects, including the EFF with their SSL Observatory 463 [SSL-Observatory] and Crossbear [Crossbear], have scanned the 464 Internet to collect all certificates of publically accessible TLS 465 servers, the cooperation from all TAs (and subordinate CAs) is 466 required to make Certificate Transparency proposal successful. The 467 reasons are two-fold: IPv6 makes scanning the address range of the 468 entire Internet much more difficult and the increasing deployment of 469 the TLS Server Name Indication [RFC6066] prevents it from obtaining 470 all certificates. 472 The expected operation is as follows: TA and subordinate CAs contact 473 log servers and upload certificates, as they are issued. In 474 response, they receive a Signed Certificate Timestamp (SCT). The SCT 475 is the log's promise to incorporate the certificate in a Merkle Tree, 476 which is the data structure used by the log, within a fixed amount of 477 time. Everyone can check the log for consistency. Website operators 478 will have an incentive to regularly check the logs for misissuance of 479 certificates issued to DNS names associated with their sites. TLS 480 clients on the other hand are not expected to directly communicate 481 with logs to avoid the communication overhead. Instead, the TLS 482 servers provides the SCT along with the certificate within the TLS 483 handshake. TLS clients reject certificates that do not have a valid 484 SCT for the end entity certificate. Since there is ideally more than 485 one log TLS servers need to provide SCTs from multiple logs to the 486 client. 488 This document has gone through a public review process, and has been 489 approved by the Internet Engineering Steering Group and published an 490 experimental RFC. 492 3.9. DetecTor 494 DetecTor [DetecTor] extends the idea of MECAI and Perspectives by 495 utilizing the Tor onion routing infrastructure [Tor] in order to 496 connect to sites via different paths through the network. The Tor 497 infrastructure thereby replaces the need to have dedicated notary 498 servers, who connect to sites to obtain certificates from a different 499 vantage point. The server certificate obtained via one or multiple 500 Tor connections is then compared with the certificate that was 501 obtained via the direct TLS connection between the client and the 502 site (i.e., without using Tor). This offers capabilities for the 503 client to detect whether there was an adversary along the path but 504 close to the client. 506 Unlike other proposals, the suggestion is made to provide no 507 information to the user once a failure has been detected. Instead, 508 the connection attempt will be rejected and no recourse is possible. 509 Like other proposals information about the observed certificates may 510 be cached by the client to lower the initial set-up delay. 512 A high-level description can be found at [DetecTor] but no detailed 513 technical specification is available. 515 4. Analysis 516 This version of the document re-uses the analysis criteria proposed 517 by Eric Rescorla [Rescorla]. 519 4.1. Public Key Pinning for HTTP 521 Changes Needed: Browsers, Servers 523 Benefits: Prevention and Detection (when reporting is used) 525 Dependencies: None 527 Incremental Deployment: Newly added server can make use of the 528 technology when browsers have been updated. Works with existing 529 WebPKI infrastructure. 531 Risks: Employs a leap of faith concept. Self-DoS if pins are 532 configured incorrectly. 534 4.2. Trust Assertions for Certificate Keys (TACK) 536 Changes Needed: Browsers, Servers 538 Benefits: Prevention 540 Dependencies: Requires server operators to create and manage new 541 public / private key pair (TSK) 543 Incremental Deployment: A newly deployed server can make use of the 544 technology when browsers have been updated. Does not seem to work 545 with existing WebPKI. 547 Risks: Employs a leap of faith concept. 549 4.3. Perspectives 551 Changes Needed: Third party infrastructure (notaries), Clients 553 Benefits: Prevention 555 Dependencies: Requires notaries to be deployed. 557 Incremental Deployment: Once notaries are available and client 558 software is updated, the solution works for every server. 560 Risks: Increased communication overhead for contacting notaries and 561 waiting notaries to check servers. Potential problems when load 562 balancers are deployed at the server infrastructure. 564 4.4. Convergence 566 Changes Needed: Third party infrastructure (notaries), Clients 568 Benefits: Prevention 570 Dependencies: Requires notaries to be deployed. 572 Incremental Deployment: Once notaries are available and client 573 software is updated, the solution works for every server. 575 Risks: Increased communication overhead for contacting notaries and 576 for letting notaries check servers (although more extensive 577 caching is utilized than with Perspectives). The notary bounding 578 concept may introduce additional latency. Potential problems when 579 load balancers are deployed at the server infrastructure. With 580 caching, a delay may be introduced between the time when a new 581 server certificate is configured and the time when the notaries 582 notice about its existence, resulting in false alarms. 584 4.5. Sovereign Keys 586 Changes Needed: Third party infrastructure (timeline), Clients, 587 Servers 589 Benefits: Prevention 591 Dependencies: Requires server operators to create and manage a new 592 public / private key pair (sovereign key). Requires third party 593 infrastructure (timeline servers). 595 Incremental Deployment: Server operators will receive benefits once 596 timeline servers are deployed, and updates to the client software 597 have been made. 599 Risks: Increased communication overhead for contacting timeline 600 servers. 602 4.6. Mutually Endorsing CA Infrastructure (MECAI) 604 Changes Needed: CAs (who operate as Voucher Authorities (VAs)), 605 Servers, Clients 607 Benefits: Prevention 609 Dependencies: Requires CAs to operate VAs 610 Incremental Deployment: Requires at least two CAs to support MECAI 611 before TLS servers can start to offer vouchers in the TLS 612 handshake to clients for verification. 614 Risks: A VA has to obtain a certificate and verify it before it can 615 issue a voucher. A client may request vouchers from a number of 616 VAs, via an extension within the TLS handshake, to have increased 617 confidence. 619 4.7. DNS-Based Authentication of Named Entities (DANE) 621 Changes Needed: Clients, Server's DNS 623 Benefits: Prevention 625 Dependencies: DNSSEC deployment at clients, and intermediaries. 627 Incremental Deployment: A new server can add support for DANE only 628 if its DNS server operator allows TLSA records to be added and 629 secured via DNSSEC. Clients require software support in the 630 browsers for verifying the DNSSEC protected TLSA record. 632 Risks: Self-DoS with incorrect TLSA records, false positives with 633 broken intermediaries, lack of DNSSEC deployment or failure of 634 DNSSEC validation. 636 4.8. Certificate Transparency 638 Changes Needed: Third party infrastructure (notaries), CA, Clients, 639 Servers 641 Benefits: Detection 643 Dependencies: Requires notaries and all CAs to participate 645 Incremental Deployment: CAs and servers who want to deploy the 646 infrastructure can start deployment (after notaries have become 647 available). 649 Risks: Non-participating CAs are not monitored and attacks against 650 those cannot be detected. 652 4.9. DetecTor 654 Changes Needed: Clients 656 Benefits: Prevention 657 Dependencies: Depends on Tor infrastructure 659 Incremental Deployment: With client-side only changes all servers 660 can be verified. 662 Risks: Setup delay and sites that utilize load balancers. Relies on 663 leap-of-faith security. Server certificate changes might cause 664 mismatches with cached information. 666 4.10. Limitations 668 A common problem of all proposals that aim to prevent attacks lies in 669 the user interface design when a failure occurs and end users are 670 informed about the problem. In many cases, the failure may not 671 necessarily be caused by real attacks but rather by the use of 672 captive portals or server-side configuration problems (like warnings 673 caused by expired certificates today). User interface studies, such 674 as [SE09], [SR07], and [BO09], have shown that end users are 675 typically not in the best position to make judgments about these 676 security warning dialogs. Furthermore, proposals that make use of 677 out-of-band communication interactions may face problems with 678 firewalled networks and the additional delay incurred. Claims have 679 been made that this is a problem with the use of OCSP today 680 [OCSP-Performance], which has been the motivation for developing and 681 standardizing OCSP stapling and multiple OCSP stapling. 683 5. Security Considerations 685 This entire document is about security. 687 6. Privacy Considerations 689 The main privacy threat is correlation. Correlation is the 690 combination of various pieces of information related to an individual 691 or that obtain that characteristic when combined. In this specific 692 case there is the risk that newly introduced entities obtain 693 information about the history of service usage by users. For 694 example, a notary that is contacted each time a user visits a new 695 website can easily be seen as problematic from a privacy point of 696 view. 698 7. IANA Considerations 700 This document does not require actions by IANA. 702 8. Acknowledgements 703 We would like to thank all participants of the NIST workshop on 704 "Improving Trust in the Online Marketplace", April 10-11 2013, for 705 sharing their views with the community. We would also like to thank 706 the authors of various solution proposals for their work. 708 Big thanks to Steven Kent for his detailed review. 710 9. References 712 9.1. Normative References 714 [ConvergenceTalk] 715 Marlinspike, M., "BlackHat USA 2011: SSL And The Future Of 716 Authenticity", URL: 717 http://www.youtube.com/watch?v=Z7Wl2FW2TcA, 2013. 719 [Convergence] 720 Marlinspike, M., "Convergence", URL: 721 http://convergence.io, 2013. 723 [DetecTor] 724 Engert, K., "DetecTor", URL: http://detector.io, Sep 2013. 726 [I-D.ietf-websec-key-pinning] 727 Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning 728 Extension for HTTP", draft-ietf-websec-key-pinning-08 729 (work in progress), July 2013. 731 [I-D.perrin-tls-tack] 732 Marlinspike, M., "Trust Assertions for Certificate Keys", 733 draft-perrin-tls-tack-02 (work in progress), January 2013. 735 [MECAI] Engert, K., "MECAI - Mutually Endorsing CA 736 Infrastructure", URL: https://kuix.de/mecai/, Feb 2012. 738 [Perspectives] 739 Wendlandt, D., Andersen, D., and A. Perrig, "Perspectives: 740 Improving SSH-style Host Authentication with Multi-Path 741 Probing", URL: http://www.cs.cmu.edu/~dga/papers/ 742 perspectives-usenix2008/, 2008. 744 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 745 X.509 Public Key Infrastructure Certificate and 746 Certificate Revocation List (CRL) Profile", RFC 3280, 747 April 2002. 749 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 750 Rose, "DNS Security Introduction and Requirements", RFC 751 4033, March 2005. 753 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 754 Rose, "Resource Records for the DNS Security Extensions", 755 RFC 4034, March 2005. 757 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 758 Rose, "Protocol Modifications for the DNS Security 759 Extensions", RFC 4035, March 2005. 761 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 762 Housley, R., and W. Polk, "Internet X.509 Public Key 763 Infrastructure Certificate and Certificate Revocation List 764 (CRL) Profile", RFC 5280, May 2008. 766 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 767 Extension Definitions", RFC 6066, January 2011. 769 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 770 of Named Entities (DANE) Transport Layer Security (TLS) 771 Protocol: TLSA", RFC 6698, August 2012. 773 [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate 774 Transparency", RFC 6962, June 2013. 776 [SovereignKeys-Spec] 777 Eckersley, P., "Sovereign Key Cryptography for Internet 778 Domains", URL: https://git.eff.org/?p=sovereign- 779 keys.git;a=blob;f=sovereign-key-design.txt;hb=master, Oct 780 2013. 782 [SovereignKeys] 783 EFF, "The Sovereign Keys Project", URL: https:// 784 www.eff.org/sovereign-keys, Oct 2013. 786 9.2. Informative References 788 [BO09] Biddle, R., van Oorschot, P., Patrick, A., Sobey, J., and 789 T. Whalen, "Browser Interfaces and Extended Validation SSL 790 Certificates: An Empirical Study, Proceedings of the 2009 791 ACM workshop on Cloud computing security", URL: 792 http://www.andrewpatrick.ca/cv/Biddle-CCSW-2009.pdf, 2009. 794 [Comodo] Hallam-Baker, P., "The Recent RA Compromise", URL: http:// 795 blogs.comodo.com/it-security/data-security/the-recent-ra- 796 compromise/, Mar 2011. 798 [Crossbear] 799 Technical University Munich, "Crossbear", URL: https:// 800 pki.net.in.tum.de/, Oct 2013. 802 [DigiNotar] 803 Arthur, C., "DigiNotar SSL certificate hack amounts to 804 cyberwar, says expert", URL: http://www.guardian.co.uk/ 805 technology/2011/sep/05/diginotar-certificate-hack- 806 cyberwar, Sep 2011. 808 [IETF-Journal-DANE] 809 Barnes, R., "DANE: Taking TLS Authentication to the Next 810 Level Using DNSSEC, IETF Journal", URL: http:// 811 www.internetsociety.org/articles/dane-taking-tls- 812 authentication-next-level-using-dnssec, Oct 2011. 814 [OCSP-Performance] 815 Netcraft, "Certificate revocation and the performance of 816 OCSP", URL: http://news.netcraft.com/archives/2013/04/16/ 817 certificate-revocation-and-the-performance-of-ocsp.html, 818 Apr 2013. 820 [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 821 Protocol Architecture", RFC 4251, January 2006. 823 [RFC5386] Williams, N. and M. Richardson, "Better-Than-Nothing 824 Security: An Unauthenticated Mode of IPsec", RFC 5386, 825 November 2008. 827 [RFC6024] Reddy, R. and C. Wallace, "Trust Anchor Management 828 Requirements", RFC 6024, October 2010. 830 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 831 Morris, J., Hansen, M., and R. Smith, "Privacy 832 Considerations for Internet Protocols", RFC 6973, July 833 2013. 835 [Rescorla] 836 Rescorla, E., "Deployment Models for Backup Certificate 837 Systems, NIST Workshop on Improving Trust in the Online 838 Marketplace", URL: http://csrc.nist.gov/groups/ST/ca- 839 workshop-2013/presentations/Rescorla_ca-workshop2013.pdf, 840 Apr 2013. 842 [SE09] Sunshine, J., Egelman, S., Almuhimedi, H., Atri, N., and 843 L. Cranor, "Crying Wolf: An Empirical Study of SSL Warning 844 Effectiveness, 18th USENIX Security Symposium", URL: 845 http://lorrie.cranor.org/pubs/sslwarnings.pdf, Aug 2009. 847 [SR07] Schechter, S., Dhamija, R., Ozment, A., and I. Fischer, 848 "The Emperor's New Security Indicators: An evaluation of 849 website authentication and the effect of role playing on 850 usability studies, The 2007 IEEE Symposium on Security and 851 Privacy", URL: http://www.usablesecurity.org/emperor/, May 852 2007. 854 [SSL-Observatory] 855 EFF, "The EFF SSL Observatory", URL: https://www.eff.org/ 856 observatory, Oct 2013. 858 [Tor] The Tor Project, "Tor - Anonymity Online", URL: https:// 859 www.torproject.org/, Oct 2013. 861 Authors' Addresses 863 Hannes Tschofenig 864 IAB Security Program 866 EMail: Hannes.Tschofenig@gmx.net 868 Eliot Lear 869 IAB Security Program 871 EMail: elear@cisco.com