Network Working Group Y. Sheffer Internet-Draft Intuit Intended status: Standards Track October 11, 2015 Expires: April 13, 2016 TLS Server Identity Pinning with Tickets draft-sheffer-tls-pinning-ticket-00 Abstract Fake public-key certificates are an ongoing problem for users of TLS. Several solutions have been proposed, but none is currently in wide use. This document proposes to extend TLS with opaque tickets, similar to those being used for TLS session resumption, as a way to pin the server's identity. That is, to ensure the client that it is connecting to the right server even in the presence of corrupt certificate authorities and fake certificates. The main advantage of this solution is that no manual management actions are required. 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 April 13, 2016. Copyright Notice Copyright (c) 2015 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 to this document. Code Components extracted from this document must Sheffer Expires April 13, 2016 [Page 1] Internet-Draft Pinning Tickets October 2015 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 1.1. Conventions used in this document . . . . . . . . . . . . 4 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Initial Connection . . . . . . . . . . . . . . . . . . . 4 2.2. Subsequent Connections . . . . . . . . . . . . . . . . . 5 2.3. Indexing the Pins . . . . . . . . . . . . . . . . . . . . 6 3. Message Definitions . . . . . . . . . . . . . . . . . . . . . 6 4. Cryptographic Operations . . . . . . . . . . . . . . . . . . 7 4.1. Pinning Secret . . . . . . . . . . . . . . . . . . . . . 7 4.2. Pinning Ticket . . . . . . . . . . . . . . . . . . . . . 8 4.3. Pinning Proof . . . . . . . . . . . . . . . . . . . . . . 8 5. Operational Considerations . . . . . . . . . . . . . . . . . 8 5.1. Protection Key Synchronization . . . . . . . . . . . . . 8 5.2. Certificate Renewal . . . . . . . . . . . . . . . . . . . 9 5.3. Certificate Revocation . . . . . . . . . . . . . . . . . 9 5.4. Disabling Pinning . . . . . . . . . . . . . . . . . . . . 9 5.5. Server Compromise . . . . . . . . . . . . . . . . . . . . 9 5.6. Comparison: HPKP Deployment . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6.1. Trust on First Use (TOFU) and MITM Attacks . . . . . . . 11 6.2. Pervasive Monitoring . . . . . . . . . . . . . . . . . . 12 6.3. Server-Side Error Detection . . . . . . . . . . . . . . . 12 6.4. Client Policy . . . . . . . . . . . . . . . . . . . . . . 12 6.5. Client-Side Error Behavior . . . . . . . . . . . . . . . 12 6.6. Client Privacy . . . . . . . . . . . . . . . . . . . . . 12 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 9.2. Informative References . . . . . . . . . . . . . . . . . 13 1. Introduction The weaknesses of the global PKI system are by now widely known. Essentially, any valid CA may issue a certificate for any organization without the organization's approval (a misissued or "fake" certificate), and use the certificate to impersonate the organization. There are many attempts to resolve these weaknesses, including Certificate Transparency (CT) [RFC6962], HTTP Public Key Pinning (HPKP) [RFC7469], and TACK [I-D.perrin-tls-tack]. CT requires cooperation of a large portion of the hundreds of extant certificate authorities (CAs) before it can be used "for real", in Sheffer Expires April 13, 2016 [Page 2] Internet-Draft Pinning Tickets October 2015 enforcing mode. It is noted that the relevant industry forum (CA/ Browser Forum) is indeed pushing for such extensive adoption. TACK has not been standardized. HPKP is a standard, but so far has proven hard to deploy (see Section 5.6). This proposal augments these mechanisms with a much easier to implement and deploy solution for server identity pinning, by reusing some of the mechanisms behind TLS session resumption. When a client first connects to a server, the server responds with a ticket and a committed lifetime. The ticket is modeled on the session resumption ticket, but is distinct from it. Specifically, the ticket acts as a "second factor" for proving the server's identity; the ticket does not authenticate the client. The committed lifetime indicates for how long the server promises to retain the server-side ticket-encryption key, which allows it to complete the protocol exchange correctly and prove its identity. The committed lifetime is typically on the order of weeks or months. We follow the Trust On First Use (TOFU) model, in that the first server authentication is only based on PKI certificate validation, but for any follow-on sessions, the client is further ensuring the server's identity based on the server's ability to decrypt the ticket and complete the handshake correctly. This version of the draft only discusses TLS 1.3. We believe that the idea can also be back-fitted into earlier versions of the protocol. The main advantages of this protocol over earlier pinning solutions are: - The protocol is at the TLS level, and as a result is not restricted to HTTP at the application level. - Once a single parameter is configured (the ticket secret's lifetime), operation is fully automated. The server administrator need not bother with the management of backup certificates or explicit pins. - For server clusters, we reuse the existing [RFC5077] infrastructure where it exists. - Pinning errors, presumably resulting from MITM attacks, can be detected both by the client and the server. This allows for server-side detection of MITM attacks using large-scale analytics. A note on terminology: unlike other solutions in this space, we do not do "certificate pinning", since the protocol is oblivious to the Sheffer Expires April 13, 2016 [Page 3] Internet-Draft Pinning Tickets October 2015 server's certificate. We prefer the term "server identity pinning" for this new solution. 1.1. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Protocol Overview The protocol consists of two phases: the first time a particular client connects to a server, and subsequent connections. This protocol supports full TLS handshakes, as well as 0-RTT handshakes. Below we present it in the context of a full handshake, but behavior in 0-RTT handshakes should be identical. The preshared key (PSK) variant of TLS 1.3 is orthogonal to this protocol. A TLS session can be established using PKI and a pinning ticket, and later resumed with PSK. The PSK handshake MUST NOT include the extension defined here. 2.1. Initial Connection When a client first connects to a server, it requests a pinning ticket by sending an empty PinningTicket extension, and receives it as part of the server's first response, in the returned PinningTicket extension. Sheffer Expires April 13, 2016 [Page 4] Internet-Draft Pinning Tickets October 2015 Client Server ClientHello + ClientKeyShare + PinningTicket --------> ServerHello ServerKeyShare* {EncryptedExtensions + PinningTicket} {ServerConfiguration*} {Certificate*} {CertificateRequest*} {CertificateVerify*} <-------- {Finished} {Certificate*} {CertificateVerify*} {Finished} --------> [Application Data] <-------> [Application Data] * Indicates optional or situation-dependent messages that are not always sent. {} Indicates messages protected using keys derived from the ephemeral secret. [] Indicates messages protected using keys derived from the master secret. The server computes a pinning_secret value (Section 4.1) in order to generate the ticket. When the connection setup is complete, the client computes the same pinning_secret value and saves it locally, together with the received ticket. The client SHOULD cache the ticket and the pinning_secret for the lifetime received from the server. The client MUST forget these values at the end of this duration. The returned ticket is sent as a ServerHello protected extension, and MUST NOT be sent as part of a HelloRetryRequest. 2.2. Subsequent Connections When the client initiates a connection to a server it has previously seen (see Section 2.3 on identifying servers and origins), it SHOULD send the pinning ticket for that server. The server MUST extract the original pinning_secret from the ticket and MUST respond with a PinningTicket extension, which includes: Sheffer Expires April 13, 2016 [Page 5] Internet-Draft Pinning Tickets October 2015 - A proof that the server can understand the ticket that was sent by the client; this proof also binds the pinning ticket to the server's (current) public key. The proof is MANDATORY if a ticket was sent by the client. - A fresh pinning ticket. The main reason for refreshing the ticket on each connection is privacy: to avoid the ticket serving as a fixed client identifier. It is RECOMMENDED to include a fresh ticket with each response. If the server cannot validate the ticket, that might indicate an earlier MITM attack on this client. The server MUST then abort the connection with a handshake_failure alert, and SHOULD log this failure. The client MUST verify the proof, and if it fails to do so, MUST issue a handshake_failure alert and abort the connection (see also Section 6.5). When the connection is successfully set up, the client SHOULD store the new ticket along with the corresponding pinning_secret. Although this is an extension, if the client already has a ticket for a server, the client MUST interpret a missing PinningTicket extension in the server's response as an attack, because of the server's prior commitment to respect the ticket. The client MUST abort the connection in this case. See also Section 5.4 on ramping down support for this extension. 2.3. Indexing the Pins [[TODO. Probably need to index by server name (SNI) and port. And should forbid use with IP addresses, similarly to SNI.]] 3. Message Definitions This section defines the format of the PinningTicket extension. We follow the message notation of [I-D.ietf-tls-tls13]. Sheffer Expires April 13, 2016 [Page 6] Internet-Draft Pinning Tickets October 2015 opaque pinning_ticket<0..2^16-1>; opaque pinning_proof<0..2^8-1>; struct { select (Role) { case client: pinning_ticket ticket<0..1>; // no tickets on 1st connection case server: pinning_proof proof<0..1>; // no proofs on 1st connection pinning_ticket ticket<0..1>; // omitted only on ramp down uint32 lifetime; } } PinningTicketExtension; ticket a pinning ticket sent by the client or returned by the server. The ticket is opaque to the client. proof a demonstration by the server that it understands the ticket and therefore that it is in possession of the secret that was used to generate it originally. The proof is further bound to the server's public key to prevent some MITM attacks. lifetime the duration (in seconds) that the server commits to accept the newly offered ticket in the future. This period MUST be at least one week. 4. Cryptographic Operations This section provides details on the cryptographic operations performed by the protocol peers. 4.1. Pinning Secret On each connection that includes the PinningTicket extension, both peers derive the the value pinning_secret from the shared Diffie Hellman secret. They compute: pinning_secret = HKDF(xSS, xES, "pinning secret", L) using the notation of [I-D.ietf-tls-tls13], sec. Key Schedule. This secret is used by the server to generate the new ticket that it returns to the client. Sheffer Expires April 13, 2016 [Page 7] Internet-Draft Pinning Tickets October 2015 4.2. Pinning Ticket The pinning ticket's format is not specified by this document, but it MUST be encrypted and integrity-protected using a long-term pinning- ticket protection key. The server MUST rotate the protection key periodically, and therefore the ticket MUST contain a protection key ID or serial number. The ticket MUST allow the server to recover the pinning_secret value, and MAY include additional information. As noted in Section 5.1, if the server is actually a cluster of machines, the protection key MUST be synchronized between them. An easy way to do it is to derive it from the session-ticket protection key, which is already synchronized. For example: pinning_protection_key = HKDF(0, resumption_protection_key, "pinning protection", L) 4.3. Pinning Proof The proof sent by the server consists of this value: proof = HMAC(original_pinning_secret, "pinning proof" + '\0' + client.random + server.random + Hash(server_public_key)) where HMAC [RFC2104] uses the Hash algorithm for the handshake, and the same hash is also used over the server's public key. 5. Operational Considerations The main motivation behind the current protocol is to enable identity pinning without the need for manual operations. Manual operations are susceptible to human error and in the case of certificate pinning, can easily result in "server bricking": the server becoming inaccessible to some or all of its users. 5.1. Protection Key Synchronization The only operational requirement when deploying this protocol is that if the server is part of a cluster, protection keys (the keys used to encrypt tickets) MUST be synchronized between all cluster members. The protocol is designed so that if resumption ticket protection keys [RFC5077] are already synchronized between cluster members, nothing more needs to be done. Moreover, synchronization does not need to be instantaneous, e.g. protection keys can be distributed a few minutes or hours in advance of their rollover. Sheffer Expires April 13, 2016 [Page 8] Internet-Draft Pinning Tickets October 2015 5.2. Certificate Renewal The protocol ensures that the client will continue speaking to the correct server even when the server's certificate is renewed. In this sense, we are not "pinning certificates" and the protocol should more precisely be called "server identity pinning". 5.3. Certificate Revocation The protocol is orthogonal to certificate validation, in the sense that, if the server's certificate has been revoked or is invalid for some other reason, the client MUST refuse to connect to it. 5.4. Disabling Pinning A server implementing this protocol MUST have a "ramp down" mode of operation where: - The server continues to accept valid pinning tickets and responds correctly with a proof. - The server does not send back a new pinning ticket. After a while no clients will hold valid tickets any more and the feature may be disabled. 5.5. Server Compromise If a server compromise is detected, the pinning secret MUST be rotated immediately, but the server MUST still accept valid tickets that use the old, compromised key. Clients who still hold old pinning tickets will remain vulnerable to MITM attacks, but those that connect to the correct server will immediately receive new tickets. 5.6. Comparison: HPKP Deployment The current IETF standard for certificate pinning is the Public Key Pinning Extension for HTTP, or HPKP [RFC7469]. Unfortunately HPKP has not seen wide deployment yet. This may simply be due to inertia, but we believe the main reason is the onerous manual certificate management which is needed to implement HPKP for enterprise servers. The penalty for making mistakes (e.g. being too early or too late to deploy new pins) is often bricking the server for some clients. To demonstrate this point, we present an analysis of what it would take to deploy HPKP for a security-sensitive Web server. Sheffer Expires April 13, 2016 [Page 9] Internet-Draft Pinning Tickets October 2015 1. Pin only end-entity certificates. Pinning an intermediate certificate means that the enterprise is at risk if the CA makes sudden operational changes. Pinning the root certificate is useless: it still allows every "brand" (sub-CA) to issue a fake certificate for the servers. 2. Make sure the default reminder period from the certificate management system is long, e.g. 3 months. This is assuming a pin period ("max age") of 1 month. 3. Issue two certificates with the same validity period, the main and a backup one. 4. Once we get the expiration reminder, issue two new certificates and install the new "main" certificate on servers. Change the HPKP header to send the old main certificate as the main pin (actually, what is sent is the certificate's SPKI), the new main certificate as the backup, and the new backup certificate as a secondary backup (in case the new main certificate gets compromised). This transition period must be at least one month, so as not to break clients who still pin to the old main certificate. 5. Shortly before expiration, change the HPKP header again to send the new main certificate's SPKI as the main pin and the new backup certificate as the backup pin. To summarize: Sheffer Expires April 13, 2016 [Page 10] Internet-Draft Pinning Tickets October 2015 +-------------------------+-------------+-------------+-------------+ | Period | Main server | Backup pin | Secondary | | | certificate | | backup pin | +-------------------------+-------------+-------------+-------------+ | Regular operation: | Old main | Old backup | | | before rotation | certificate | certificate | | | | | | | | >1 month before | Old main | New main | New backup | | expiration of old | certificate | certificate | certificate | | certificates | | | | | | | | | | Shortly before | New main | New backup | | | expiration but not | certificate | certificate | | | earlier than the | | | | | previous change + 1 | | | | | month | | | | | | | | | | Regular operation: | New main | New backup | | | after rotation | certificate | certificate | | +-------------------------+-------------+-------------+-------------+ 6. Security Considerations [[Todo: add more threats]] 6.1. Trust on First Use (TOFU) and MITM Attacks This protocol is a "trust on first use" protocol. If a client initially connects to the "right" server, it will be protected against MITM attackers for the lifetime of each received ticket. If it connects regularly (depending of course on the server-selected lifetime), it will stay constantly protected against fake certificates. However if it initially connects to an attacker, subsequent connections to the "right" server will fail. Server operators might want to advise clients on how to remove corrupted pins, once such large scale attacks are detected and remediated. The protocol is designed so that it is not vulnerable to an active MITM attacker who has real-time access to the original server. The pinning proof includes a hash of the server's public key, to ensure the client that the proof was in fact generated by the server with which it is initiating the connection. Sheffer Expires April 13, 2016 [Page 11] Internet-Draft Pinning Tickets October 2015 6.2. Pervasive Monitoring Some organizations, and even some countries perform pervasive monitoring on their constituents [RFC7258]. This often takes the form of SSL proxies. Because of the TOFU property, this protocol does not provide any security in such cases. 6.3. Server-Side Error Detection Uniquely, this protocol allows the server to detect clients that present incorrect tickets and therefore can be assumed to be victims of a MITM attack. Server operators can use such cases as indications of ongoing attacks, similarly to fake certificate attacks that took place in a few countries in the past. 6.4. Client Policy Like it or not, some clients are normally deployed behind an SSL proxy. Similarly to [RFC7469], it is acceptable to allow pinning to be disabled for some hosts according to local policy. For example, a UA MAY disable pinning for hosts whose validated certificate chain terminates at a user-defined trust anchor, rather than a trust anchor built-in to the UA (or underlying platform). Moreover, a client MAY accept an empty PinningTicket extension from such hosts as a valid response. 6.5. Client-Side Error Behavior When a client receives an incorrect or empty PinningTicket from a pinned server, it MUST abort the handshake and MUST NOT retry with no PinningTicket in the request. Doing otherwise would expose the client to trivial fallback attacks, similar to those described in [RFC7507]. This rule can however have negative affects on clients that move from behind SSL proxies into the open Internet. Therefore, browser and library vendors MUST provide a documented way to remove stored pins. 6.6. Client Privacy [[TODO]] 7. IANA Considerations IANA is requested to allocate a TicketPinning extension value in the TLS ExtensionType Registry. No registries are defined by this document. Sheffer Expires April 13, 2016 [Page 12] Internet-Draft Pinning Tickets October 2015 8. Acknowledgements The original idea behind this proposal was published in [Oreo] by Moty Yung, Benny Pinkas and Omer Berkman. The current protocol is but a distant relative of the original Oreo protocol, and any errors are the draft author's alone. I would like to thank Yoav Nir for his comments on this draft. 9. References 9.1. Normative References [I-D.ietf-tls-tls13] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", draft-ietf-tls-tls13-08 (work in progress), August 2015. [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, DOI 10.17487/RFC2104, February 1997, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ RFC2119, March 1997, . [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, "Transport Layer Security (TLS) Session Resumption without Server-Side State", RFC 5077, DOI 10.17487/RFC5077, January 2008, . 9.2. Informative References [I-D.perrin-tls-tack] Marlinspike, M., "Trust Assertions for Certificate Keys", draft-perrin-tls-tack-02 (work in progress), January 2013. [Oreo] Berkman, O., Pinkas, B., and M. Yung, "Firm Grip Handshakes: A Tool for Bidirectional Vouching", Cryptology and Network Security, pp. 142-157 , 2012. [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, . Sheffer Expires April 13, 2016 [Page 13] Internet-Draft Pinning Tickets October 2015 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2014, . [RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April 2015, . [RFC7507] Moeller, B. and A. Langley, "TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks", RFC 7507, DOI 10.17487/RFC7507, April 2015, . Author's Address Yaron Sheffer Intuit EMail: yaronf.ietf@gmail.com Sheffer Expires April 13, 2016 [Page 14]