idnits 2.17.1 draft-tschofenig-iab-webpki-evolution-00.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 (October 21, 2013) is 3840 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == 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 (~~), 2 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: April 24, 2014 October 21, 2013 7 Evolving the Web Public Key Infrastructure 8 draft-tschofenig-iab-webpki-evolution-00.txt 10 Abstract 12 The problems with the WebPKI have received the attention by the 13 Internet security community when DigiNotar, a Dutch certificate 14 authority, had a security breach in 2011 and in the same year a 15 Comodo affiliate was compromised. Both cases lead to fraudulent 16 issue of certificates and raise questions regarding the strength of 17 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 April 24, 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 . . . . . . . . . . . . . . . . . . . . . . 7 71 3.4. Convergence . . . . . . . . . . . . . . . . . . . . . . . 8 72 3.5. Sovereign Keys . . . . . . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 12 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 . . . . . . . . . . . . . . . . . . . . . . . . 15 87 4.10. Limitations . . . . . . . . . . . . . . . . . . . . . . . 15 88 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 89 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 15 90 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 91 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 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 certificate authority, had a security breach [DigiNotar] and 102 in the same year a Comodo affiliate was compromised [Comodo]. Both 103 cases lead to fraudulent issue of certificates. 105 Public Key Infrastructure (PKI) makes use of a trusted third party, 106 the certificate authority (CA), to bind the subject name to a public 107 key. A CA may, however, get compromised despite the best security 108 practices and operational procedures. The main problem, however, is 109 that any CA can issue a certificate for any domain name. One 110 compromised CA is therefore able to impact the security of the entire 111 public key infrastructure. In the case of DigiNotar the attacker was 112 able to issue certificates for Google services even though Google 113 never made use of services from DigiNotar and might not have ever 114 heard of that CA before. 116 Furthermore, over time browsers and applications increased the number 117 of trust anchors that are shipped pre-installed. Depending on 118 software the number of trust anchors may exceed 600, as reported by 119 the Electronic Frontier Foundation (EFF) in their SSL Observatory 120 study [SSL-Observatory]. While the larger number provides choice for 121 relying parties regarding the CA they can select for obtaining a 122 certificate there is also a downside: with today's WebPKI set-up it 123 is sufficient to compromise a single CA to impact the security for 124 all relying parties. Many users and researchers were surprised about 125 the large number of trust anchors installed in normal operating 126 systems and browsers without having an easy way to adjust that list 127 to their preferences. 129 To re-state the problem statement: Every CA can issue certificates 130 for any relying party even though that relying party may have never 131 been in a relationship with the issuing CA. (Note that the trust 132 anchor of that CA needs to be provisioned into the trust anchor 133 store.) 134 These developments have led to a number of protocol design activities 135 for improving the public key infrastructure. In this document we 136 briefly summarize the available technical solutions and include an 137 assessment about who needs to make changes, what type of benefits are 138 provided, and what dependencies exist. The investigated solutions 139 include DANE [RFC6698], Certificate Transparency [RFC6962], Public 140 Key Pinning [I-D.ietf-websec-key-pinning], TACK 141 [I-D.perrin-tls-tack], Perspectives [Perspectives], Sovereign Keys 142 [SovereignKeys], MECAI [MECAI], Convergence [Convergence], and 143 DetecTor [DetecTor]. 145 While there are other challenges with security on the Web, such as 146 user interface problems with certificate warnings, insecure use of 147 cookies, cross-site scripting attacks, injection attacks, etc., this 148 document focuses on improving the public key infrastructure only. It 149 is also worth reminding ourselves that the Web public key 150 infrastructure is not only used for Web applications but also for a 151 range of other applications, including smart phone apps. 152 Furthermore, other public key infrastructures that operate under a 153 different regime with different policies may suffer from similar 154 problems. Consequently, the solution techniques discussed in this 155 document are also useful for these other PKI deployments. 157 The main purpose of this document is to provide an overview of the 158 technical solutions. This description will help us to develop a 159 roadmap for the deployment of the best solutions to improve the 160 overall security of the public key infrastructure. 162 Final note: There are also process solutions, such as stricter audits 163 of CAs with the aim to improve operational practices, and these are 164 not described in this document. These measures will be useful in 165 addition to technical solutions but alone they will, however, not 166 address the underlying problem. 168 2. Terminology 170 This document uses the following terms from from RFC 3280 [RFC3280]: 172 end entity: user of PKI certificates and/or end user system that is 173 the subject of a certificate. 175 CA: certification authority 177 This document also re-uses the term "Leap of faith" from RFC 5386 178 [RFC5386]: 180 "Leap of faith is the term generally used when a user accepts the 181 assertion that a given key identifies a peer on the first 182 communication (despite a lack of strong evidence for that 183 assertion), and then remembers this association for future 184 communications." 186 This security property has become fairly popular with use of 187 Secure Shell [RFC4251], which made use of the leap of faith 188 property. 190 RFC 6973 [RFC6973] provides a definition of the term 'relying party': 192 "The relying party is an entity that relies on assertions of 193 individuals' identities from identity providers in order to 194 provide services to individuals. In effect, the relying party 195 delegates aspects of identity management to the identity 196 provider(s). Such delegation requires protocol exchanges, trust, 197 and a common understanding of semantics of information exchanged 198 between the relying party and the identity provider." 200 In the context of this document the relying party is a TLS server, 201 for example, used to protect the communication of a Web server. 202 Although a lot of focus is on the Web there are other non-HTTP- 203 based services that are included in the definition and may 204 benefits from improvements discussed in this document. 206 The terms 'trust anchor' and 'trust anchor store' are defined in 207 [RFC6024]: 209 "A trust anchor represents an authoritative entity via a public 210 key and associated data. The public key is used to verify digital 211 signatures, and the associated data is used to constrain the types 212 of information for which the trust anchor is authoritative." 214 "A trust anchor store is a set of one or more trust anchors stored 215 in a device. A device may have more than one trust anchor store, 216 each of which may be used by one or more applications." 218 3. Technical Solutions 220 3.1. Public Key Pinning for HTTP 222 [I-D.ietf-websec-key-pinning] describes a solution for instructing 223 user agents (UAs) to remember ("pin") certificates (end entity 224 certificates or CA certs) for a given period of time. During that 225 time, UAs will require that the TLS server presents a certificate 226 chain including at least one Subject Public Key Info structure whose 227 fingerprint matches one of the pinned fingerprints for that host. 229 While the specification provides a number of instructions for the 230 Website operator to indicate towards the UA the basic operation is 231 rather simple and assumes a leap-of-faith policy. To deal with the 232 change of certificates or other failure scenarios the concept of a 233 backup pin is utilized. A Backup Pin is a fingerprint for the public 234 key of a secondary, not-yet-deployed key pair. The operator keeps 235 the backup key pair offline, and sets a pin for it in the Public-Key- 236 Pins header. Then, in case the operator loses control of their 237 primary private key, they can deploy the backup key pair. An 238 interesting feature of the specification is to report pin validation 239 failure. 241 When a pin validation failure occurs the expectation is that the user 242 is notified about the inconsistency (with optionally reporting taking 243 place in the background). 245 This document is the product of the IETF Web Security working group. 247 3.2. Trust Assertions for Certificate Keys (TACK) 249 Similarly to the key pinning solution described in Section 3.1 TACK 250 [I-D.perrin-tls-tack] also aims to enables a TLS server to support 251 "pinning" to a self-chosen signing key. There are, however, a number 252 of substantial differences in the design despite the similarity of 253 the name. 255 TLS server operators create a so-called "TACK signing key" (TSK) and 256 sign their own keys used by TLS servers. A TACK pin then associates 257 a hostname, a TSK, and various parameters (including pin creating 258 time, and lifetime of the pin). A TLS server operator may change a 259 key for a server at any point in time since the TSK will be 260 unchanged. The existing public key infrastructure is replaced by a 261 form of self-signed certificates. Clients store the TACK pins in 262 their pin stores, which they may have obtained from different 263 sources. Although the focus of the specification is to obtain the 264 TACK pins via a TLS extension from the server directly a mechanism to 265 obtain these TACK pins from a third party infrastructure is 266 envisioned, although outside the scope of the specification. When 267 TACK pins are obtained from the TLS server directly they follow a 268 leap-of-faith approach; a third party distribution mechanism may have 269 additional security properties. 271 For incremental deployment the TLS client uses the extension 272 mechanism of TLS to indicate support for the TACK extension by 273 including a new TLS extension type in the ClientHello message. A TLS 274 server that does not support TACK will reply with an ordinary 275 certificate. In case the TLS server supports the extension it 276 replies with the newly defined tack structure, which contains the 277 TACK pin for that server. 279 This specification is an individual submission to the IETF. 281 [Editor's Note: The document claims that the proposal also works with 282 certificates. However, details are missing to describe how the TLS 283 server key is signed with the TSK and then used by a regular TLS 284 library.] 286 3.3. Perspectives 288 Perspectives [Perspectives] aims to utilize notaries (i.e., public 289 servers) that monitor and record the history of public keys used by 290 sites. While the description focuses on the use of raw public keys 291 (in the style of SSH) the same concept also works with certificates. 293 The basic approach is simple: When a TLS client starts to interact 294 with a TLS server it is presented with a key/certificate that it had 295 not seen before. To verify that the key/certificate is the same as 296 observed by other vantage points in the network it contacts one or 297 multiple notary servers. These notary servers provide key/ 298 certificate information they have obtained about the specific website 299 earlier. 301 To improve the leap of faith security by clients the notary services 302 adds security value since they may have obtained the key/certificate 303 from the website in the past already and from a different vantage 304 points in terms of the path used to talk to the server. This helps 305 when attacks are either temporary and or when the man-in-the-middle 306 attacker is located somewhere along the path between the client and 307 the server but closer to the client. The use of multiple notaries 308 also helps to detect malicious notaries. 310 With clients caching information about the keys/certificates of sites 311 visited earlier and the information obtained from notaries there is 312 no additional protocol overhead. In this respect the solution works 313 similar to key pinning. The additional communication overhead for 314 the client only occurs at the time when the client talks to a server 315 for the first time or when the cached information expires. 317 Similar to other notary services there is the question about how they 318 obtain information about the available TLS servers. For popular 319 services obtaining the keys/certificates a list of sites is assumed 320 to pre-configured and queried periodically but for the long tail of 321 small websites the suggested approach query these sites the first 322 time the client wants to connect to them. 324 The proposal is documented in form of an academic research paper, see 325 [Perspectives], but no technical specification is available. 327 3.4. Convergence 329 Convergence [Convergence] is a proposal by Moxie Marlinspike that 330 makes two improvements to Perspectives, namely 332 Reducing Notary Lag: Perspective required TLS clients to interact 333 with notaries to check whether the certificate obtained through 334 TLS matches the information seen by one or many notaries. 335 Notaries then had to initiate an interaction with the TLS servers 336 to obtain information about what certificates they see. 337 Convergence reduces this interaction by utilizing caching of 338 certificates at the notaries. By doing this, however, they also 339 introduce a delay between the time a new certificate is put in 340 operation at a TLS server and when the notaries get to learn about 341 it. 343 Increased Privacy Protection: First, clients cache certificates so 344 that they do not need to contact notaries every time they contact 345 a Web site. Second, clients use a concept called 'notary 346 bouncing' whereby they pick a notary randomly out of their pool of 347 trusted notaries and use it as a proxy to talk to other notaries. 348 Thereby, the notary that receives the query will only see the IP 349 address of another notary who forwarded the query rather than the 350 IP address of the client. 352 The client can decide how many notaries are consulted to obtain 353 certificate from a given TLS servers. As a main advantage the author 354 claims that there is no impact on TLS servers deployments, except in 355 rare situations where multiple certificates are used by a single site 356 in combination with a load balancer. 358 Notaries are designed to be extensible by supporting different 359 mechanisms how they obtain certificates. Currently, Convergence uses 360 the technique proposed by Perspectives to probe a TLS server. 362 The documentation of Convergence only exists in form of a 363 presentation by Moxie Marlinspike given at the BlackHat USA 2011 364 conference [ConvergenceTalk]. 366 3.5. Sovereign Keys 368 Sovereign Keys [SovereignKeys] is a proposal by the Electronic 369 Frontier Foundation (EFF) suggesting to introduce two new concepts to 370 deal with attacks against the public key infrastructure. 372 Sovereign key: Domain owners create a new key pair, the sovereign 373 key, and use it to sign their operational certificates / the 374 public keys. 376 Timeline servers: Append-only timeline servers, as new entities, are 377 introduced that stores mappings between domain names to sovereign 378 keys. To claim a key for a domain name requires evidence of 379 control in the DNS either via a CA-signed certificate or via a key 380 published in the DNS (as provided by DANE). 382 Each timeline server possesses a unique private/public key pair and 383 these keys are assumed to be shipped with client software or TLS 384 libraries to ensure that clients can verify the authenticity of 385 timeline entries. The timeline servers record the history of claims 386 to sovereign keys. 388 TLS clients query timeline servers for entries that belong to a 389 certain domain and verify that the end-entity certificate has been 390 cross-signed by the sovereign key. If the verification fails then 391 the connection attempt is refused. 393 A high-level description can be found at [SovereignKeys] and a more 394 detailed technical specification is available at 395 [SovereignKeys-Spec]. 397 3.6. Mutually Endorsing CA Infrastructure (MECAI) 399 MECAI [MECAI] builds conceptually on top of the Perspective proposal. 400 Perspectives introduces notaries, as new entities in the public key 401 infrastructure, and MECAI takes the position that this function can 402 be taken by existing CAs. With this new role they would turn into 403 Voucher Authorities (VAs), who issue vouchers that confirm what they 404 observe. A voucher is a signature computed over a number of fields 405 including the hash of the server certificate, the certificate chain, 406 the IP address of the server, revocation status information, etc. Of 407 course, a voucher would be created by a CA other than the one that 408 created the original certificate. 410 A client would therefore perform the following steps: it connects to 411 a server via TLS and the server provides the certificate. Then, the 412 client needs to obtain one or multiple vouchers for the server 413 certificate. This can happen either inband within the TLS handshake 414 when talking to the server, similarly to how OCSP stapling works, or 415 via a separate protocol exchange. The former approach is less 416 expensive in terms of communication costs for the client. In any 417 case, a voucher request protocol is needed to let entities (like TLS 418 servers) talk to VAs to obtain a voucher. 420 A client or a server can detect misissuance by matching the 421 information in the vouchers with the certificate. 423 Only a high-level description is available via [MECAI] but no 424 detailed technical specification. 426 3.7. DNS-Based Authentication of Named Entities (DANE) 428 DANE [RFC6698] offers the option to use the DNS infrastructure to 429 store certificates. DANE is envisioned as a preferable basis for 430 binding public keys to DNS names, because the entities that vouch for 431 the binding of public key data to DNS names are the same entities 432 responsible for managing the DNS names in question. 434 Distributing certificates via the DNS does, however, require DNSSEC. 435 With the help of DNSSEC [RFC4033][RFC4034][RFC4035] this offers an 436 opportunity to eliminate off-line processes for validation of the 437 subject name, which today often requires sending a mail to the 438 administrator of that domain. This relationship can be easily 439 demonstrated by having the zone administrator for the subject domain 440 post the public key in the DNS and digitally sign the resulting zone. 442 A high-level description about the different options offered by DANE 443 can be found in [IETF-Journal-DANE] and the authoritative version can 444 be found in RFC 6698 [RFC6698]. 446 3.8. Certificate Transparency 448 RFC 6962 [RFC6962] specifies Certificate Transparency, a protocol for 449 publicly logging the existence of certificates as they are issued or 450 observed, in a manner that allows anyone to audit certificate 451 authority (CA) activity and notice the issuance of suspect 452 certificates as well as to audit the certificate logs themselves. 453 The intent is that eventually clients would refuse to honor 454 certificates that do not appear in a log, effectively forcing CAs to 455 add all issued certificates to the logs. 457 The publicly auditable, append-only logs of all issued certificates 458 does not prevent misissue but allows interested parties to detect 459 misissuance. 461 While various projects, including the EFF with their SSL Observatory 462 [SSL-Observatory] and Crossbear [Crossbear], have scanned the 463 Internet to collect all certificates of publically accessible TLS 464 servers the cooperation from all CAs or from certificate owners is 465 required to make Certificate Transparency proposal successful. The 466 reasons are two-fold: IPv6 makes scanning the address range of the 467 entire Internet much more difficult and the increasing deployment of 468 the TLS Server Name Indication [RFC6066] prevents it from obtaining 469 all available difficult. 471 The expected operation is as follows: CAs or certificate owners 472 contact logs and upload certificates, as they issue them. In 473 response, they receive a Signed Certificate Timestamp (SCT). The SCT 474 is the log's promise to incorporate the certificate in the Merkle 475 Tree, which is the data structure used by the log, within a fixed 476 amount of time. Everyone can check the log for consistency. 477 Particularly website operators will have an interest to regularly 478 check the logs for misissuance of certificates. TLS clients on the 479 other hand are not expected to directly communicate with logs to 480 avoid the communication overhead. Instead, the TLS servers provides 481 the SCT along with the certificate within the TLS handshake. TLS 482 clients reject certificates that do not have a valid SCT for the end 483 entity certificate. Since there is ideally more than one log TLS 484 servers need to provide SCTs from multiple logs to the client. 486 This document has gone through a public review process, and has been 487 approved by the Internet Engineering Steering Group and published an 488 experimental RFC. 490 3.9. DetecTor 492 DetecTor [DetecTor] extends the idea of MECAI and Perspectives by 493 utilizing the Tor onion routing infrastructure [Tor] in order to see 494 connect to sites via different paths through the network. The Tor 495 infrastructure thereby replaces the need to have dedicated notary 496 servers, who connect to sites to obtain certificates from a different 497 vantage point. The server certificate obtained via one or multiple 498 Tor connections is then compared with the certificate that was 499 obtained via the direct TLS connection between the client and the 500 site (i.e., without using Tor). This offers capabilities for the 501 client to detect whether there was an adversary along the path but 502 close to the client. 504 Unlike other proposals, the suggestion is made to provide no 505 information to the user once a failure has been detected. Instead, 506 the connection attempt will be rejected and no recourse is possible. 507 Like other proposals information about the observed certificates may 508 be cached by the client to lower the initial set-up delay. 510 A high-level description can be found at [DetecTor] but no detailed 511 technical specification is available. 513 4. Analysis 515 This version of the document re-uses the analysis criteria proposed 516 by Eric Rescorla [Rescorla]. 518 4.1. Public Key Pinning for HTTP 520 Changes Needed: Browsers, Servers 522 Benefits: Prevention and Detection (when reporting is used) 524 Dependencies: None 526 Incremental Deployment: Newly added server can make use of the 527 technology when browsers have been updated. Works with existing 528 PKI infrastructure. 530 Risks: Provides a leap of faith concept. Self-DoS if pins are 531 configured incorrectly. 533 4.2. Trust Assertions for Certificate Keys (TACK) 535 Changes Needed: Browsers, Servers 537 Benefits: Prevention 539 Dependencies: Requires server operators to create and manage new 540 public / private key pair (TSK) 542 Incremental Deployment: Newly added server can make use of the 543 technology when browsers have been updated. Does not seem to work 544 with existing PKI infrastructure. 546 Risks: Provides a leap of faith concept. 548 4.3. Perspectives 550 Changes Needed: Third party infrastructure (notaries), Clients 552 Benefits: Prevention 554 Dependencies: Requires notaries to be deployed. 556 Incremental Deployment: Once notaries are available and client 557 software the solution works with every server. 559 Risks: Increased communication overhead for contacting notaries and 560 for letting notaries check servers. Potential problems when load 561 balancers are deployed at the server infrastructure. 563 4.4. Convergence 565 Changes Needed: Third party infrastructure (notaries), Clients 567 Benefits: Prevention 569 Dependencies: Requires notaries to be deployed. 571 Incremental Deployment: Once notaries are available and client 572 software the solution works with every server. 574 Risks: Increased communication overhead for contacting notaries and 575 for letting notaries check servers (although more extensive 576 caching is utilized than with Perspectives). The notary bounding 577 concept may introduce additional latency. Potential problems when 578 load balancers are deployed at the server infrastructure. With 579 caching a certain lag may be introduced between the time when a 580 new server certificate is configured and the time when the 581 notaries notice about its existence. 583 4.5. Sovereign Keys 585 Changes Needed: Third party infrastructure (timeline), Clients, 586 Servers 588 Benefits: Prevention 590 Dependencies: Requires server operators to create and manage new 591 public / private key pair (sovereign key). Requires third party 592 infrastructure (timeline servers). 594 Incremental Deployment: New server operators will receive benefits 595 once timeline servers are deployed, and updates to the client 596 software has been made. 598 Risks: Increased communication overhead for contacting timeline 599 servers. 601 4.6. Mutually Endorsing CA Infrastructure (MECAI) 603 Changes Needed: CAs (who operate the Voucher Authorities (VAs)), 604 Servers, Clients 606 Benefits: Prevention 607 Dependencies: Requires CAs to operate VAs 609 Incremental Deployment: Requires at least two CAs to support MECAI 610 before TLS servers can start to offer vouchers in the TLS 611 handshake to clients for verification. 613 Risks: A VA has to obtain a certificate and verify it before it can 614 issue a voucher. A client may request vouchers from a number of 615 VAs to have enough confidence. 617 4.7. DNS-Based Authentication of Named Entities (DANE) 619 Changes Needed: Clients, Server's DNS 621 Benefits: Prevention 623 Dependencies: DNSSEC deployment at clients, and intermediaries. 625 Incremental Deployment: A new server can add support for DANE only 626 it the DNS allows TLSA records to be added and secured via DNSSEC. 627 Then, clients need to have software support in the browsers for 628 verifying the DNSSEC protected TLSA record. 630 Risks: Self-DoS with incorrect TLSA records, false positives with 631 broken intermediaries, lack of DNSSEC deployment or failure with 632 DNSSEC validation. 634 4.8. Certificate Transparency 636 Changes Needed: Third party infrastructure (notaries), CA, Clients, 637 Servers 639 Benefits: Detection 641 Dependencies: Requires notaries and all CAs to participate 643 Incremental Deployment: CAs and servers who want to deploy the 644 infrastructure can start deployment (after notaries have become 645 available). 647 Risks: Non-participating CAs are not monitored and attacks against 648 those cannot be detected. 650 4.9. DetecTor 652 Changes Needed: Clients 654 Benefits: Prevention 656 Dependencies: Depends on Tor infrastructure 658 Incremental Deployment: With client-side only changes all servers 659 can be verified. 661 Risks: Setup delay and sites that utilize load balancers. Relies on 662 leap-of-faith security. Certificate changes on the server-side 663 might cause mismatches with cached information. 665 4.10. Limitations 667 A common problem of all proposals that aim to prevent attacks lies in 668 the user interface design when a failure occurs and end users are 669 informed about the problem. In many cases, the failure may not 670 necessarily be caused by real attacks but rather by the use of 671 captive portals or server-side configuration problems (like warnings 672 caused by expired certificates today). User interface studies, such 673 as [SE09], [SR07], and [BO09], have shown that end users are 674 typically not in the best position to make judgements about these 675 security warning dialogs. Furthermore, proposals that make use of 676 out-of-band communication interactions may face problems with 677 firewalled networks and the additional incurred delay. Claims have 678 been made that this is a problem with the use of OCSP today 679 [OCSP-Performance], which has been the motivation for developing and 680 standardizing OCSP stapling and multiple OCSP stapling. 682 5. Security Considerations 684 This entire document is about security. 686 6. Privacy Considerations 688 The main privacy threat is correlation. Correlation is the 689 combination of various pieces of information related to an individual 690 or that obtain that characteristic when combined. In this specific 691 case there is the risk that newly introduced entities obtain 692 information about the history of service usage. For example, a 693 notary that is contacted each time a user visits a new website can 694 easily be seen as problematic from a privacy point of view. 696 7. IANA Considerations 697 This document does not require actions by IANA. 699 8. Acknowledgements 701 We would like to thank all participants of the NIST workshop on 702 "Improving Trust in the Online Marketplace", April 10-11 2013, for 703 sharing their views with the community. We would also like to thank 704 the authors of various solution proposals for their work. 706 9. References 708 9.1. Normative References 710 [ConvergenceTalk] 711 Marlinspike, M., "BlackHat USA 2011: SSL And The Future Of 712 Authenticity", URL: 713 http://www.youtube.com/watch?v=Z7Wl2FW2TcA, 2013. 715 [Convergence] 716 Marlinspike, M., "Convergence", URL: 717 http://convergence.io, 2013. 719 [DetecTor] 720 Engert, K., "DetecTor", URL: http://detector.io, Sep 2013. 722 [I-D.ietf-websec-key-pinning] 723 Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning 724 Extension for HTTP", draft-ietf-websec-key-pinning-08 725 (work in progress), July 2013. 727 [I-D.perrin-tls-tack] 728 Marlinspike, M., "Trust Assertions for Certificate Keys", 729 draft-perrin-tls-tack-02 (work in progress), January 2013. 731 [MECAI] Engert, K., "MECAI - Mutually Endorsing CA 732 Infrastructure", URL: https://kuix.de/mecai/, Feb 2012. 734 [Perspectives] 735 Wendlandt, D., Andersen, D., and A. Perrig, "Perspectives: 736 Improving SSH-style Host Authentication with Multi-Path 737 Probing", URL: http://www.cs.cmu.edu/~dga/papers/ 738 perspectives-usenix2008/, 2008. 740 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 741 X.509 Public Key Infrastructure Certificate and 742 Certificate Revocation List (CRL) Profile", RFC 3280, 743 April 2002. 745 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 746 Rose, "DNS Security Introduction and Requirements", RFC 747 4033, March 2005. 749 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 750 Rose, "Resource Records for the DNS Security Extensions", 751 RFC 4034, March 2005. 753 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 754 Rose, "Protocol Modifications for the DNS Security 755 Extensions", RFC 4035, March 2005. 757 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 758 Extension Definitions", RFC 6066, January 2011. 760 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 761 of Named Entities (DANE) Transport Layer Security (TLS) 762 Protocol: TLSA", RFC 6698, August 2012. 764 [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate 765 Transparency", RFC 6962, June 2013. 767 [SovereignKeys-Spec] 768 Eckersley, P., "Sovereign Key Cryptography for Internet 769 Domains", URL: https://git.eff.org/?p=sovereign- 770 keys.git;a=blob;f=sovereign-key-design.txt;hb=master, Oct 771 2013. 773 [SovereignKeys] 774 EFF, "The Sovereign Keys Project", URL: https:// 775 www.eff.org/sovereign-keys, Oct 2013. 777 9.2. Informative References 779 [BO09] Biddle, R., van Oorschot, P., Patrick, A., Sobey, J., and 780 T. Whalen, "Browser Interfaces and Extended Validation SSL 781 Certificates: An Empirical Study, Proceedings of the 2009 782 ACM workshop on Cloud computing security", URL: 783 http://www.andrewpatrick.ca/cv/Biddle-CCSW-2009.pdf, 2009. 785 [Comodo] Hallam-Baker, P., "The Recent RA Compromise", URL: http:// 786 blogs.comodo.com/it-security/data-security/the-recent-ra- 787 compromise/, Mar 2011. 789 [Crossbear] 790 Technical University Munich, "Crossbear", URL: https:// 791 pki.net.in.tum.de/, Oct 2013. 793 [DigiNotar] 794 Arthur, C., "DigiNotar SSL certificate hack amounts to 795 cyberwar, says expert", URL: http://www.guardian.co.uk/ 796 technology/2011/sep/05/diginotar-certificate-hack- 797 cyberwar, Sep 2011. 799 [IETF-Journal-DANE] 800 Barnes, R., "DANE: Taking TLS Authentication to the Next 801 Level Using DNSSEC, IETF Journal", URL: http:// 802 www.internetsociety.org/articles/dane-taking-tls- 803 authentication-next-level-using-dnssec, Oct 2011. 805 [OCSP-Performance] 806 Netcraft, "Certificate revocation and the performance of 807 OCSP", URL: http://news.netcraft.com/archives/2013/04/16/ 808 certificate-revocation-and-the-performance-of-ocsp.html, 809 Apr 2013. 811 [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 812 Protocol Architecture", RFC 4251, January 2006. 814 [RFC5386] Williams, N. and M. Richardson, "Better-Than-Nothing 815 Security: An Unauthenticated Mode of IPsec", RFC 5386, 816 November 2008. 818 [RFC6024] Reddy, R. and C. Wallace, "Trust Anchor Management 819 Requirements", RFC 6024, October 2010. 821 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 822 Morris, J., Hansen, M., and R. Smith, "Privacy 823 Considerations for Internet Protocols", RFC 6973, July 824 2013. 826 [Rescorla] 827 Rescorla, E., "Deployment Models for Backup Certificate 828 Systems, NIST Workshop on Improving Trust in the Online 829 Marketplace", URL: http://csrc.nist.gov/groups/ST/ca- 830 workshop-2013/presentations/Rescorla_ca-workshop2013.pdf, 831 Apr 2013. 833 [SE09] Sunshine, J., Egelman, S., Almuhimedi, H., Atri, N., and 834 L. Cranor, "Crying Wolf: An Empirical Study of SSL Warning 835 Effectiveness, 18th USENIX Security Symposium", URL: 836 http://lorrie.cranor.org/pubs/sslwarnings.pdf, Aug 2009. 838 [SR07] Schechter, S., Dhamija, R., Ozment, A., and I. Fischer, 839 "The Emperor's New Security Indicators: An evaluation of 840 website authentication and the effect of role playing on 841 usability studies, The 2007 IEEE Symposium on Security and 842 Privacy", URL: http://www.usablesecurity.org/emperor/, May 843 2007. 845 [SSL-Observatory] 846 EFF, "The EFF SSL Observatory", URL: https://www.eff.org/ 847 observatory, Oct 2013. 849 [Tor] The Tor Project, "Tor - Anonymity Online", URL: https:// 850 www.torproject.org/, Oct 2013. 852 Authors' Addresses 854 Hannes Tschofenig 855 IAB Security Program 857 EMail: Hannes.Tschofenig@gmx.net 859 Eliot Lear 860 IAB Security Program 862 EMail: elear@cisco.com