Internet Architecture Board R. Housley Internet-Draft Vigil Security Intended status: Informational K. O'Donoghue Expires: March 26, 2017 Internet Society September 22, 2016 Problems with the Public Key Infrastructure (PKI) for the World Wide Web draft-iab-web-pki-problems-03.txt Abstract The Public Key Infrastructure (PKI) used for the World Wide Web (Web PKI) is a vital component of trust in the Internet. In recent years, there have been a number of improvements made to this infrastructure, including improved certificate status checking, automation, and transparency of governance. However, additional improvements necessary. This document identifies continuing areas of concerns and provides recommendations to the Internet community for additional improvements, moving toward a more robust and secure Web PKI. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on March 26, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect Housley & O'Donoghue Expires March 26, 2017 [Page 1] Internet-Draft Web PKI Problems September 2016 to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Very Brief Description of the Web PKI . . . . . . . . . . . . 2 3. Improvements to the Web PKI . . . . . . . . . . . . . . . . . 3 3.1. Weak Cryptographic Algorithms or Short Public Keys . . . 3 3.2. Support for Enterprise PKIs . . . . . . . . . . . . . . . 4 3.3. Web PKI in the Home . . . . . . . . . . . . . . . . . . . 6 3.4. Browser Error Messages . . . . . . . . . . . . . . . . . 8 3.5. Governance Improvements to the Web PKI . . . . . . . . . 8 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 6.1. Normative References . . . . . . . . . . . . . . . . . . 11 6.2. Informative References . . . . . . . . . . . . . . . . . 11 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 13 Appendix B. IAB Members at the Time of Approval . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 1. Introduction There are many interrelated problems with the current Public Key Infrastructure (PKI) used for the World Wide Web (Web PKI). The Web PKI makes use of certificates as described in RFC 5280 [RFC5280]. These certificates are primarily used with Transport Layer Security (TLS) as described in RFC 5246 [RFC5246]. The economics of the Web PKI value chain are discussed in [VFBH], [AV], and [AVAV]. This document does not discuss the economic issues further, but these economic issues provide motivation for correcting the other problems that are discussed in this document. Over the years, many technical improvements have been made to the Web PKI, but several challenges remain. This document offers a general set of recommendations to the Internet community that might be helpful in addressing these remaining challenges. 2. Very Brief Description of the Web PKI Certificates are specified in RFC 5280 [RFC5280]. Certificates contain, among other things, a subject name, a public key, a limited valid lifetime, and the digital signature of the Certification Authority (CA). Certificate users require confidence that the Housley & O'Donoghue Expires March 26, 2017 [Page 2] Internet-Draft Web PKI Problems September 2016 private key associated with the certified public key is owned by the named subject. The architectural model used in the Web PKI includes: EE: End Entity -- the subject of a certificate -- certificates are issued to end entities including Web servers and clients that need mutual authentication. CA: Certification Authority -- the issuer of a certificate -- issues certificates for end entities including Web servers and clients. RA: Registration Authority -- an optional system to which a CA delegates some management functions such as identity validation or physical credential distribution. A valid certificate may be revoked for any number of reasons. CAs are responsible for indicating the revocation status of the certificates that they issue throughout the lifetime of the certificate. Revocation status information may be provided using the Online Certificate Status Protocol (OCSP) [RFC6960], certificate revocation lists (CRLs) [RFC5280], or some other mechanism. In general, when revocation status information is provided using CRLs, the CA is also the CRL issuer. However, a CA may delegate the responsibility for issuing CRLs to a different entity. The enrollment process used by a CA makes sure that the subject name in the certificate is appropriate and that the subject actually holds the private key. Proof of possession of the private key is often accomplished through a challenge-response protocol. 3. Improvements to the Web PKI Over the years, many technical improvements have been made to the Web PKI. Despite this progress, several challenges remain. This section discusses several unresolved problems, and it suggests general directions for tackling them. 3.1. Weak Cryptographic Algorithms or Short Public Keys Several digital signature algorithms, one-way hash functions, and public key sizes that were once considered strong are no longer considered adequate. This is not a surprise. Cryptographic algorithms age; they become weaker over time. As new cryptanalysis techniques are developed and computing capabilities increase, the amount of time needed to break a particular cryptographic algorithm Housley & O'Donoghue Expires March 26, 2017 [Page 3] Internet-Draft Web PKI Problems September 2016 will decrease. For this reason, the algorithms and key sizes used in the Web PKI need to migrate over time. Browser vendors have been trying to manage algorithm and key size transitions. It is a significant challenge to maintain a very high degree of interoperability across the world wide web while phasing out aged cryptographic algorithm or too small key size. When these appear in a long-lived trust anchor or intermediate CA certificate, refusal to accept them can impact a very large certificate subtree. In addition, if a certificate for a web site with a huge amount of traffic is in that subtree, rejecting that certificate may impact too many users. Despite this situation, the MD5 and SHA-1 one-way hash functions have been almost completely eliminated from the Web PKI, and 1024-bit RSA public keys are essentially gone [MB2015] [MB2016]. It took a very long time to make this happen, and trust anchors and certificates that used these cryptographic algorithms were considered valid long after they were widely known to be too weak. Obviously, additional algorithm transitions will be needed in the future. The algorithms and key sizes that are acceptable today will become weaker with time. [RFC7696] offers some guidelines regarding cryptographic algorithm agility. The Web PKI can prepare for the next transition by: 1. Having experts periodically evaluate the current choices of algorithm and key size. While it is not possible to predict when a new cryptanalysis technique will be discovered, the end of the useful lifetime of most algorithms and key sizes is known many years in advance. 2. Planning for a smooth and orderly transition from a weak algorithm or key size. Experience has shown that many years are needed produce to specifications, develop implementations, and then deploy replacements. 3. Reducing the lifetime of certificates, especially intermediate CA certificates, to create frequent opportunities to change an algorithm or key size. 3.2. Support for Enterprise PKIs Many enterprises operate their own PKI. These enterprises do not want to be part of the traditional Web PKI, but they face many challenges in order to achieve a similar user experience and level of security. Housley & O'Donoghue Expires March 26, 2017 [Page 4] Internet-Draft Web PKI Problems September 2016 Users must install the trust anchor or trust anchors for the enterprise PKI in their browser. There is not a standard way to accomplish trust anchor installation, and users are often faced with scary warnings in the process of the installation. Enterprise PKI users often experience greater latency than tradition Web PKI users. Some browser vendors provide a proprietary revocation checking mechanism that obtains revocation status for the entire Web PKI in a very compact form. This mechanism eliminates latency since no network traffic is generated at the time that a certificate is being validated. However, these mechanisms cover only the trust anchor store for that browser vendor, excluding all enterprise PKIs. In addition, measurements in 2015 [IMC2015] show that these mechanisms do not currently provide adequate coverage of the Web PKI. RFC 6961 [RFC6961] defines the TLS Multiple Certificate Status Request extension, which allows the web server to provide status information about its own certificate and also the status of intermediate certificates in the certification path. By including this extension in the TLS handshake, the browser asks the web server to provide OCSP responses in addition to the server certificate. This approach greatly reduces the latency since the browser does not need to generate any OCSP requests or wait for any OCSP responses. The provision of the time-stamped OCSP response in the TLS handshake is referred to as "stapling" the OCSP response to the TLS handshake. If the browser does not receive a stapled OCSP response, it can contact the OCSP responder directly. In addition, the MUST_STAPLE feature [TLSFEATURE] can be used to insist that OCSP stapling be used. When every browser that connects to a high volume website performs its own OCSP lookup, the OCSP responder must handle a large volume of OCSP requests in real-time. OCSP stapling can avoid enormous volumes of OCSP requests for certificates of popular websites, so stapling can significantly reduce the cost of providing an OCSP service. OCSP stapling can also improve user privacy, since the web server, not the browser, contacts the OCSP responder. In this way, the OCSP responder is not able to determine which browsers are checking the validity of certificate for particular websites. Several enterprises issue certificates to all of their employees, and among other uses, these certificates are used in TLS client authentication. There is not a common way to import the private key and the client certificate into browsers. In fact, the private key can be stored in many different formats depending on the software used to generate the public/private key pair. PKCS#12 [RFC7292] Housley & O'Donoghue Expires March 26, 2017 [Page 5] Internet-Draft Web PKI Problems September 2016 seems to be the most popular format at the moment. A standard way to import the needed keying material and a standard format will make this task much easier, and the World Wide Web might enjoy an increase in mutual authentication. Enterprise PKIs can be better supported if: 1. Each enterprise PKI offers an OCSP Responder, and web sites with certificates from the enterprise PKI make use of OCSP Stapling. 2. Browser vendors support a standard way for the trust anchors for the enterprise PKI to be installed. 3. Browser vendors support a standard way to install private keys and certificates for use in client authentication. 4. In the event that browser vendors continue to offer latency-free proprietary revocation status checking mechanisms, then these mechanisms need to expand the coverage to all of the Web PKI and offer a means to include enterprise PKIs in the coverage. 3.3. Web PKI in the Home More and more, web protocols are being used to manage devices in the home. For example, homeowners can use a web browser to connect to a web site that is embedded in their home router to adjust various settings. The router allows the browser to access web pages to adjust these setting as long as the connection originates from the home network and the proper password is provided. However, there is no way for the browser to authenticate to the embedded web site. Authentication of the web site is normally performed during the TLS handshake, but the Web PKI is not equipped to issue certificates to home routers or the many other home devices that employ embedded web sites for homeowner management. A solution in this environment must not depend on the homeowner to perform duties that are normally associated with a web site administrator. However, some straightforward tasks could be done at the time the device is installed in the home. These task cannot be more complex that the initial setup of a new printer in the home, otherwise they will be skipped or done incorrectly. There are two very different approaches to certificates for home devices that have been discussed over the years. In the first approach, a private key and certificate are installed in the device at the factory. The certificate has an unlimited lifetime. Since it never expires, no homeowner action is needed to renew it. Also, since the certificate never changes, the algorithms are selected by Housley & O'Donoghue Expires March 26, 2017 [Page 6] Internet-Draft Web PKI Problems September 2016 the factory for the lifetime of the device. The subject name in the certificate is quite generic, as it must be comprised of information that is known in the factory. The subject name is often based on some combination of the manufacturer, model, serial number, and MAC address. While these do uniquely identify the device, they have little meaning to the homeowner. In the second approach, like the first one, a private key and a certificate that are installed in the device at the factory, but the homeowner is unaware of them. This factory-installed certificate is used only to authenticate to a CA operated by the manufacturer. At the time the device is installed, the homeowner can provide a portion of the subject name for the device, and the manufacturer CA can issue a certificate that includes a subject name that the homeowner will recognize. The certificate can be renewed without any action by the homeowner at appropriate intervals. Also, following a software update, the algorithms used in the TLS handshake and the certificate can be updated. Section 3.1 of this document calls for the ability to transition from weak cryptographic algorithms over time. For this reason, and the ability to use a subject name that the homeowner will recognize, the second approach is preferred. One potential problem with the second approach is continuity of operations of the manufacturer CA. After the device is deployed, the manufacturer might go out of business, and then come time for renewal of the certificate, there will not be a CA to issue the new certificate. One possible solution might be modeled on the domain name business, where other parties will continue to provide needed services if the original provider goes out of business. The Web PKI can prepare for the vast number of home devices that need certificates by: 1. Building upon the work being done in the IETF ACME Working Group [ACMEWG] to facilitate the automatic renewal of certificates for home devices without any actions by the homeowner beyond the initial device setup. 2. Working with device manufacturers to establish scalable CAs that will continue to issue certificates for the deployed devices even if the manufacture goes out of business. 3. Working with device manufacturers to establish OCSP Responders so that the web sites that are embedded in the devices can provide robust authentication and OCSP stapling in a manner that is compatible with traditional web sites. Housley & O'Donoghue Expires March 26, 2017 [Page 7] Internet-Draft Web PKI Problems September 2016 3.4. Browser Error Messages Many users find browser error messages related to certificates confusing. Good man-machine interfaces are always difficult, but in this situation users are unable to fully understand the risks that they are accepting, and as a result they do not make informed decisions about when to proceed and when to stop. This aspect of browser usability needs to be improved for users to make better security choices. Browser users have been trained to ignore warnings, making them ineffective. Further, solving the error message situation in isolation is probably not possible; instead, it needs to be considered along side the other issues raised in this document. Browser users have been trained to find a way around any error, and very often, the error is the result of web server misconfiguration, and it does not actually present a risk to the browser user. If the risk to the user is high, then the session should be closed with a clear description of the problem that was encountered. Doing so will lead to improved management of the overall Web infrastructure over time, especially as the tools that are being developed for web server administrators are rolled out. In some enterprises, avoiding these errors requires the addition of enterprise-specific trust anchors to the browser. Additional tools are needed to allow administrations to easily add appropriate trust anchors, especially browsers on consumer devices as more and more enterprises are embracing bring-your-own-device policies. The Web PKI can simplify user choice and improve user actions by: 1. Browser vendors providing additional intelligence to eliminate the majority of certificate warnings, only prompting the user when there is likely to be a risk. 2. Browser vendors improving error messages to clearly indicate the risk that the user is accepting if they proceed. 3.5. Governance Improvements to the Web PKI As with many other technologies, Web PKI technical issues are tangled up with policy and process issues. Policy and process issues have evolved over time, sometimes eroding confidence and trust in the Web PKI. Governance structures are needed that increase transparency and trust. Housley & O'Donoghue Expires March 26, 2017 [Page 8] Internet-Draft Web PKI Problems September 2016 Web PKI users are by definition asked to trust CAs. This includes what CAs are trusted to do properly, and what they are trusted not to do. The system for determining which CAs are added to or removed from the trust anchor store in browsers is opaque and confusing to most Web PKI users. The CA/Browser Forum has developed baseline requirements for the management and issuance of certificates [CAB2014] for individual CAs. However, the process by which an individual CA gets added to the trust anchor store by each of the browsers vendors is not straightforward. The individual browser vendors determine what should and should not be trusted by including the CA certificate in their trust anchor store. They do this by leveraging the AICPA/CICA WebTrust Program for Certification Authorities [WEBTRUST]. This program provides auditing requirements and a trust mark for CAs that meet them. Failure to pass an audit can result in the CA being removed from the trust store. Once the browser has shipped, how does a user know which CAs are trusted or what has changed recently? For an informed user, information about which CAs have been added to or deleted from the browser trust anchor store can be found in the browser release notes. Users can also examine the policies of the various CAs that have been developed and posted for the WebTrust Program. However, this is a very high barrier for the average user. There are options to make local modifications by educated users, but there is little understanding about the implications of these choices. How does an individual, organization, or enterprise really determine if a particular CA is trustworthy? Do the default choices inherited from the browser vendors truly represent the organization's trust model? What constitutes sufficiently bad behavior by a CA to cause removal from the trust anchor store? In addition, it can be hazardous for users to remove CAs from the browser trust anchor store. If a user removes a CA from the browser trust anchor store, some web sites may become completely inaccessible or require the user to take explicit action to accept warnings or bypass browser protections related to untrusted certificates. The guidelines provided by the WebTrust program [WEBTRUST] provide a framework for removing a CA from the trust anchor store. There may be a few very large CAs that are critical to significant portions of World Wide Web infrastructure. Removing one of these CAs can have a significant impact on a huge number of websites. As discussed in Section 3.4, users are already struggling to understand the implications of untrusted certificates, so they often ignore warnings presented by the browser. There are a number of organizations that play significant roles in the operation of the Web PKI, including the CA/Browser Forum, the Housley & O'Donoghue Expires March 26, 2017 [Page 9] Internet-Draft Web PKI Problems September 2016 WebTrust Program, and the browser vendors. These organizations act on behalf of the entire Internet community; therefore, transparency in these operations is fundamental to confidence and trust in the Web PKI. Recently the CA/Browser Forum made some changes to their operational procedures to make it easier for people to participate and to improve visibility into their process [CAB1.2]. This is a significant improvement, but these processes need to continue to evolve in an open, inclusive, and transparent manner. Currently, as the name implies, the CA/Browser Forum members primarily represent CAs and browser vendors. It would be better if relying parties also have a voice in this forum. Since the Web PKI is widespread, applications beyond the World Wide Web are making use of the Web PKI. For example, the Web PKI is used to secure connections between SMTP servers. In these environments, the browser-centric capabilities are unavailable. The current governance structure does not provide a way for the relying parties in these applications to participate. The Web PKI governance structures can be made more open and transparent by: 1. Browser vendors providing additional visibility and tools to support the management of the trust anchor store. 2. Governance organizations providing a way for all relying parties, including ones associated with non-browser applications, to participate. 4. Security Considerations This document considers the weaknesses of the current Web PKI system and provides recommendations for improvements. Some of the risks associated with doing nothing or continuing down the current path are articulated. The Web PKI is a vital component of a trusted Internet, and as such needs to be improved to sustain continued growth of the Internet. 5. IANA Considerations None. {{{ RFC Editor: Please remove this section prior to publication. }}} Housley & O'Donoghue Expires March 26, 2017 [Page 10] Internet-Draft Web PKI Problems September 2016 6. References 6.1. Normative References [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, . [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 6960, DOI 10.17487/RFC6960, June 2013, . 6.2. Informative References [ACMEWG] IETF, "Charter for Automated Certificate Management Environment (acme) Working Group", June 2015, . [AV] Arnbak, A. and N. van Eijk, "Certificate Authority Collapse: Regulating Systemic Vulnerabilities in the HTTPS Value Chain", 2012 TRPC , August 2012, . [AVAV] Asghari, H., van Eeten, M., Arnbak, A., and N. van Eijk, "Security Economics in the HTTPS Value Chain", Workshop on Economics of Information Security (WEIS) 2013 , 2013, . [CAB1.2] CA/Browser Forum, "Bylaws of the CA/Browser Forum", October 2014, . [CAB2014] CA/Browser Forum, "CA/Browser Forum Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates, v.1.2.2", October 2014, . [IMC2015] Liu, Y., Tome, W., Zhang, L., Choffnes, D., Levin, D., Maggs, B., Mislove, A., Schulman, A., and C. Wilson, "An End-to-End Measurement of Certificate Revocation in the Web's PKI", October 2015, . Housley & O'Donoghue Expires March 26, 2017 [Page 11] Internet-Draft Web PKI Problems September 2016 [MB2015] Wilson, K., "Phase 2: Phasing out Certificates with 1024-bit RSA Keys", January 2015, . [MB2016] Barnes, R., "Payment Processors Still Using Weak Crypto", February 2016, . [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, . [RFC6961] Pettersen, Y., "The Transport Layer Security (TLS) Multiple Certificate Status Request Extension", RFC 6961, DOI 10.17487/RFC6961, June 2013, . [RFC7292] Moriarty, K., Ed., Nystrom, M., Parkinson, S., Rusch, A., and M. Scott, "PKCS #12: Personal Information Exchange Syntax v1.1", RFC 7292, DOI 10.17487/RFC7292, July 2014, . [RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm Agility and Selecting Mandatory-to-Implement Algorithms", BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015, . [TLSFEATURE] Hallam-Baker, P., "X.509v3 TLS Feature Extension", draft- hallambaker-tlsfeature-10 (work in progress), July 2015. [VFBH] Vratonjic, N., Freudiger, J., Bindschaedler, V., and J. Hubaux, "The Inconvenient Truth About Web Certificates", Workshop on Economics of Information Security (WEIS) 2011 , 2011, . [WEBTRUST] CPA Canada, "WebTrust Program for Certification Authorities", August 2015, . Housley & O'Donoghue Expires March 26, 2017 [Page 12] Internet-Draft Web PKI Problems September 2016 Appendix A. Acknowledgements This document has been developed within the IAB Privacy and Security Program. The authors greatly appreciate the review and suggestions provided by Rick Andrews, Mary Barnes, Richard Barnes, Marc Blanchet, Alissa Cooper, Nick Doty, Stephen Farrell, Joe Hall, Ted Hardie, Ralph Holz, Lee Howard, Christian Huitema, Eliot Lear, Xing Li, Lucy Lynch, Gervase Markham, Andrei Robachevsky, Thomas Roessler, Jeremy Rowley, Christine Runnegar, Jakob Schlyter, Wendy Seltzer, Brian Trammell, and Juan Carlos Zuniga. Appendix B. IAB Members at the Time of Approval {{{ RFC Editor: Please add the names to the IAB members at the time that this document is put into the RFC Editor queue. }}} Authors' Addresses Russ Housley Vigil Security 918 Spring Knoll Drive Herndon, VA 20170 USA Email: housley@vigilsec.com Karen O'Donoghue Internet Society 1775 Wiehle Ave #201 Reston, VA 20190 USA Email: odonoghue@isoc.org Housley & O'Donoghue Expires March 26, 2017 [Page 13]