| RFC 8672 | Pinning with Tickets | October 2019 |
| Sheffer & Migault | Experimental | [Page] |
Misissued public-key certificates can prevent TLS clients from appropriatelyauthenticating the TLS server. Several alternativeshave been proposed to detect this situation and prevent a client from establishinga TLS session with a TLS end point authenticated with an illegitimatepublic-key certificate. These mechanisms are either notwidely deployed or limited to public web browsing.¶
This document proposes experimental extensions to TLS with opaquepinning tickets as a way to pin the server's identity.During an initial TLS session,the server provides an original encrypted pinning ticket.In subsequent TLS session establishment, upon receipt of the pinning ticket,the server proves its ability to decrypt the pinning ticketand thus the ownership of the pinning protection key.The client can now safely conclude that the TLS session is establishedwith the same TLS server as the original TLS session.One of the important properties of this proposal is thatno manual management actions are required.¶
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.¶
This document defines an Experimental Protocol for the Internet community. This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.¶
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained athttps://www.rfc-editor.org/info/rfc8672.¶
Copyright (c) 2019 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 (https://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.¶
Misissued public-key certificates can prevent TLS[RFC8446] clients fromappropriately authenticating the TLS server. This is a significantrisk in the context of the global public key infrastructure (PKI),and similarly for large-scaledeployments of certificates within enterprises.¶
This document proposes experimental extensions to TLS with opaquepinning tickets as a way to pin the server's identity. The approachis intended to be easy to implement and deploy, and reuses some ofthe ideas behind TLS session resumption[RFC5077].¶
Ticket pinning is a second-factor server authentication method and isnot proposed as a substitute for the authentication method provided inthe TLS key exchange. More specifically, the client only uses thepinning identity method after the TLS key exchange is successfullycompleted. In other words, the pinning identity method is onlyperformed over an authenticated TLS session. Note that ticket pinningdoes not pin certificate information and therefore is truly anindependent second-factor authentication.¶
Ticket pinning is a trust-on-first-use (TOFU) mechanism, in that thefirst server authentication is only based on PKI certificate validation,but for any follow-on sessions, the client is further ensuring theserver's identity based on the server's ability to decrypt the ticket,in addition to normal PKI certificate authentication.¶
During initial TLS session establishment, the client requests a pinningticket from the server. Upon receiving the request the server generatesa pinning secret that is expected to be unpredictable for peers otherthan the client or the server. In our case, the pinning secret isgenerated from parameters exchanged during the TLS key exchange, soclient and server can generate it locally and independently. The serverconstructs the pinning ticket with the necessary information to retrievethe pinning secret. The server then encrypts the ticket and returns thepinning ticket to the client with an associated pinning lifetime.¶
The pinning lifetime value indicates for how long the server promises toretain the server-side ticket-encryption key, which allows it tocomplete the protocol exchange correctly and prove its identity. Theserver commitment (and ticket lifetime) is typically on the order ofweeks.¶
Once the key exchange is completed, and the server is deemedauthenticated, the client generates locally the pinning secret andcaches the server's identifiers to index the pinning secret as well asthe pinning ticket and its associated lifetime.¶
When the client reestablishes a new TLS session with the server, itsends the pinning ticket to the server. Upon receiving it, the serverreturns a proof of knowledge of the pinning secret. Once the keyexchange is completed, and the server has been authenticated, the clientchecks the pinning proof returned by the server using the client'sstored pinning secret. If the proof matches, the client can concludethat the server to which it is currently connecting is, in fact, the correctserver.¶
This document only applies to TLS 1.3.We believe that theidea can also be retrofitted into earlier versions of the protocol, butthis would require significant changes.One example is that TLS 1.2[RFC5246] andearlier versions do not provide a generic facility of encryptedhandshake extensions, such as is used here to transport the ticket.¶
The main advantages of this protocol over earlier pinning solutions are the following:¶
A note on terminology: unlike other solutions in this space, we do notdo "certificate pinning" (or "public key pinning"), since the protocolis oblivious to the server's certificate. We prefer the term "serveridentity pinning" for this new solution. In our solution, the serverproves its identity by generating a proof that it can read and decryptan encrypted ticket. As a result, the identity proof relies on proof ofownership of the pinning protection key. However, this key is neverexchanged with the client or known by it, and so cannot itself bepinned.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14[RFC2119][RFC8174] when, and only when, they appear in all capitals, as shown here.¶
This document describes an experimental extension to the TLS protocol.This section defines constraints on this experiment and how it can yield useful information, potentially resulting in a standard.¶
The protocol is designed so that if the server does not support it, the client and server fall back to a normal TLS exchange,with the exception of a single PinningTicket extension being initially sent by the client.In addition, the protocol is designed only to strengthen the validation of the server's identity ("second factor").As a result, implementation or even protocol errors should not result inweakened security compared to the normal TLS exchange.Given these two points, experimentation can be run on the open Internet between consenting client and server implementations.¶
The goal of the experiment is to prove that:¶
Following two years of successful deployment, the authors will publish a document that summarizesthe experiment's findings and will resubmit the protocol forconsideration as a Proposed Standard.¶
The protocol consists of two phases: the first time a particular clientconnects 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 in0-RTT handshakes should be identical.¶
The document presents some similarities with the ticket resumptionmechanism described in[RFC5077]. However the scope of this documentdiffers from session resumption mechanisms implemented with[RFC5077]or with other mechanisms. Specifically, the pinning ticket does notcarry any state associated with a TLS session and thus cannot be usedfor session resumption or client authentication. Instead, thepinning ticket only contains the encrypted pinning secret.The pinning ticket is used by the server to proveits ability to decrypt it, which implies ownership of the pinningprotection key.¶
[RFC5077] has been obsoleted by[RFC8446], and ticket resumption isnow defined bySection 2.2 of [RFC8446]. This document references[RFC5077] as an informational document since it contains a morethorough discussion of stateless ticket resumption, and becauseticket resumption benefitsfrom significant operational experience with TLS 1.2 that is stillwidely deployed at the time of writing. This experience,as well as deployment experience, can easily be re-used for identity pinning.¶
With TLS 1.3, session resumption is based on a Pre-Shared Key (PSK).This is orthogonal to this protocol. With TLS 1.3, a TLS session can beestablished using PKI and a pinning ticket, and later resumed with PSK.¶
However, the protocol described in this document addresses the problemof misissued certificates. Thus, it is not expected to be used outside acertificate-based TLS key exchange, such as in PSK. As a result, PSKhandshakesMUST NOT include the extension defined here.¶
When a client first connects to a server, it requests a pinning ticketby sending an empty PinningTicket extension, and receives it as part ofthe server's first response, in the returned PinningTicket extension.¶
Client Server ClientHello + key_share + signature_algorithms + PinningTicket --------> ServerHello + key_share {EncryptedExtensions + PinningTicket} {CertificateRequest*} {Certificate*} {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.¶If a client supports the PinningTicket extension and does not have anypinning ticket associated with the server, the exchange is considered asan initial connection. Other reasons the client may not have a pinningticket include the client having flushed its pinning ticket store, orthe committed lifetime of the pinning ticket having expired.¶
Upon receipt of the PinningTicket extension, the server computes apinning secret (Section 4.1) and sends the pinning ticket(Section 4.2) encrypted with the pinning protection key(Section 4.3). The pinning ticket is associated with alifetime value by which the server assumes the responsibility ofretaining the pinning protection key and being able to decrypt incomingpinning tickets during the period indicated by the committed lifetime.¶
Once the pinning ticket has been generated, the server returns thepinning ticket and the committed lifetime in a PinningTicket extensionembedded in the EncryptedExtensions message. We note that aPinningTicket extensionMUST NOT be sent as part of a HelloRetryRequest.¶
Upon receiving the pinning ticket, the clientMUST NOT accept it untilthe key exchange is completed and the server authenticated. If the keyexchange is not completed successfully, the clientMUST ignore thereceived pinning ticket. Otherwise, the client computes the pinningsecret andSHOULD cache the pinning secret and the pinning ticket forthe duration indicated by the pinning ticket lifetime. The clientSHOULDclean up the cached values at the end of the indicated lifetime.¶
When the client initiates a connection to a server it has previouslyseen (seeSection 2.3 on identifying servers), itSHOULD send thepinning ticket for that server. The pinning ticket, pinning secret, andpinning ticket lifetime computed during the establishment of theprevious TLS session are designated in this document as the "original"ones, to distinguish them from a new ticket that may be generated duringthe current session.¶
The serverMUST extract the original pinning_secret value from theticket andMUST respond with a PinningTicket extension, which includes:¶
If the server cannot validate the received ticket, that might indicatean earlier MITM attack on this client. The serverMUST then abort theconnection with a handshake_failure alert andSHOULD log this failure.¶
The clientMUST verify the proof, and if it fails to do so, the clientMUST issue ahandshake_failure alert and abort the connection (see alsoSection 6.5). It is important that the client does not attempt to"fall back" by omitting the PinningTicket extension.¶
When the connection is successfully set up, i.e., after the Finishedmessage is verified, the clientSHOULD store the new ticket along withthe corresponding pinning_secret, replacing the original ticket.¶
Although this is an extension, if the client already has a ticket for aserver, the clientMUST interpret a missing PinningTicket extension inthe server's response as an attack, because of the server's priorcommitment to respect the ticket. The clientMUST abort the connectionin this case. See alsoSection 5.5 on ramping down support for thisextension.¶
Each pin is associated with a set of identifiers that include, amongothers, hostname, protocol (TLS or DTLS), and portnumber. In other words, the pin for port TCP/443 may be different fromthat for DTLS, or from the pin for port TCP/8443. These identifiers areexpected to be relevant to characterize the identity of the server aswell as the establishing TLS session. When a hostname is used, itMUST bethe value sent inside the Server Name Indication (SNI) extension. Thisdefinition is similar to the concept of a Web Origin[RFC6454], but does not assumethe existence of a URL.¶
The purpose of ticket pinning is to pin the server identity. As aresult, any information orthogonal to the server's identityMUST NOT beconsidered in indexing. More particularly, IP addresses are ephemeraland forbidden in SNI, and therefore pinsMUST NOT be associated with IPaddresses. Similarly, CA names or public keys associated with serverMUST NOT be used for indexing as they may change over time.¶
This section defines the format of the PinningTicket extension.We follow the message notation of[RFC8446].¶
opaque pinning_ticket<0..2^16-1>; opaque pinning_proof<0..2^8-1>; struct { select (Role) { case client: pinning_ticket ticket<0..2^16-1>; //omitted on 1st connection case server: pinning_proof proof<0..2^8-1>; //no proof on 1st connection pinning_ticket ticket<0..2^16-1>; //omitted on ramp down uint32 lifetime; }} PinningTicketExtension;¶This section provides details on the cryptographic operations performedby the protocol peers.¶
The pinning secret is generated locally by the client and the server,which means they must use the same inputs to generate it. This valuemust be generated before the ServerHello message is sent, as the serverincludes the corresponding pinning ticket in the same flight as theServerHello message. In addition, the pinning secret must beunpredictable to any party other than the client and the server.¶
The pinning secret is derived using the Derive-Secret function providedby TLS 1.3, described inSection 7.1 of [RFC8446].¶
pinning secret = Derive-Secret(Handshake Secret, "pinning secret", ClientHello...ServerHello)¶
The pinning ticket contains the pinning secret. The pinning ticket isprovided by the client to the server, which decrypts it in order toextract the pinning secret and responds with a pinning proof. As aresult, the characteristics of the pinning ticket are:¶
The pinning ticket's format is not specified by this document, buta format similar to the one proposed by[RFC5077]isRECOMMENDED.¶
The pinning protection key is used only by the server and so remainsserver implementation specific.[RFC5077] recommends the use of twokeys, but when using Authenticated Encryption with Associated Data (AEAD) algorithms, only a single key is required.¶
When a single server terminates TLS for multiple virtual servers usingthe SNI mechanism, it is stronglyRECOMMENDED that the server usea separate protection key for each one of them, in order to allowmigrating virtual servers between different servers while keepingpinning active.¶
As noted inSection 5.1, if the server is actually a cluster ofmachines, the protection keyMUST be synchronized between all the nodesthat accept TLS connections to the same server name. When[RFC5077]is deployed, an easy way to do it is to derive the protection key fromthe session-ticket protection key, which is already synchronized. Forexample:¶
pinning_protection_key = HKDF-Expand(resumption_protection_key, "pinning protection", L)¶
Where resumption_protection_key is the ticket protection key defined in[RFC5077]. Both resumption_protection_key and pinning_protection_keyare only used by the server.¶
The above solution attempts to minimize code changes related to management of the resumption_protection_key.The drawback is that this key would be used both to directly encrypt session tickets and to derivethe pinning_protection_key, and such mixed usage of a single key is not in line with cryptographic best practices.Where possible, it isRECOMMENDED that the resumption_protection_key be unrelated to the pinning_protection_key and that they are separately shared among the relevant servers.¶
The pinning proof is sent by the server to demonstrate that it has beenable to decrypt the pinning ticket and to retrieve the pinning secret. Theproof must be unpredictable and must not be replayed. Similarly to thepinning ticket, the pinning proof is sent by the server in theServerHello message. In addition, it must not be possible for a MITMserver with a fake certificate to obtain a pinning proof from theoriginal server.¶
In order to address these requirements, the pinning proof is bound tothe TLS session as well as the public key of the server:¶
pinning_proof_secret=Derive-Secret(Handshake Secret, "pinning proof 1", ClientHello...ServerHello)proof = HMAC(original_pinning_secret, "pinning proof 2" + pinning_proof_secret + Hash(server_public_key))¶
where HMAC[RFC2104] uses the Hash algorithm that was negotiated inthe handshake, and the same hash is also used over the server's publickey. The original_pinning_secret value refers to the secret valueextracted from the ticket sent by the client, to distinguish it from anew pinning secret value that is possibly computed in the currentexchange. The server_public_key value is the DER representation ofthe public key, specifically the SubjectPublicKeyInfo structure as-is.¶
The main motivation behind the current protocol is to enable identitypinning without the need for manual operations. Manual operations aresusceptible to human error, and in the case of public key pinning, caneasily result in "server bricking": the server becoming inaccessible tosome or all of its users. To achieve this goal, operations described inidentity pinning are only performed within the current TLS session, andthere is no dependence on any TLS configuration parameters such as CAidentity or public keys. As a result, configuration changes areunlikely to lead to desynchronized state between the client and theserver.¶
The only operational requirement when deploying this protocol is that, ifthe server is part of a cluster, protection keys (the keys used toencrypt tickets)MUST be synchronized between all cluster members. Theprotocol is designed so that if resumption ticket protection keys[RFC5077] are already synchronized between cluster members, nothingmore 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 oftheir rollover. In such scenarios, each cluster memberMUST be able toaccept tickets protected with a new version of the protection key, evenwhile it is still using an old version to generate keys. This ensuresthat, when a client receives a "new" ticket, it does not next hit a clustermember that still rejects this ticket.¶
Misconfiguration can lead to the server's clock being off by a largeamount of time. Consider a case where a server's clock is misconfigured,for example, to be 1 year inthe future, and the system is allowed to delete expired keys automatically.The server will then delete many outstanding keys because they are nowlong expired and will end up rejecting valid tickets that are storedby clients. Such a scenario could make the serverinaccessible to a large number of clients.¶
The decision to delete a key should at least considerthe largest value of the ticket lifetime as well as the expected timedesynchronization between the servers of the cluster and the timedifference for distributing the new key among the different servers inthe cluster.¶
The lifetime of the ticket is a commitment by the server to retain theticket's corresponding protection key for this duration, so that theserver can prove to the client that it knows the secret embedded in theticket. For production systems, the lifetimeSHOULD be between 7 and 31days.¶
The protocol ensures that the client will continue speaking to thecorrect server even when the server's certificate is renewed. In thissense, pinning is not associated with certificates, which is the reason wedesignate the protocol described in this document as "server identitypinning".¶
Note that this property is not impacted by the use of the server'spublic key in the pinning proof because the scope of the public keyused is only the current TLS session.¶
The protocol is orthogonal to certificate validation in the sense that,if the server's certificate has been revoked or is invalid for someother reason, the clientMUST refuse to connect to it regardless of anyticket-related behavior.¶
A server implementing this protocolMUST have a "ramp down" mode ofoperation where:¶
After a while, no clients will hold valid tickets, and thefeature may be disabled. Note that clients that do not receive a newpinning ticket do not necessarily need to remove the original ticket.Instead, the client may keep using the ticket until its lifetimeexpires. However, as detailed inSection 6.7, re-use of aticket by the client may result in privacy concerns as the ticket valuemay be used to correlate TLS sessions.¶
Issuing a new pinning ticket with a shorter lifetime would only delaythe ramp down process, as the shorter lifetime can only affect clientsthat actually initiated a new connection. Other clients would still seethe original lifetime for their pinning tickets.¶
If a server compromise is detected, the pinning protection keyMUST berotated immediately, but the serverMUST still accept valid tickets thatuse the old, compromised key. Clients that still hold old pinningtickets will remain vulnerable to MITM attacks, but those that connectto the correct server will immediately receive new tickets protectedwith the newly generated pinning protection key.¶
The same procedure applies if the pinning protection key is compromiseddirectly, e.g., if a backup copy is inadvertently made public.¶
All web servers in production need to be backed up, so that they can berecovered if a disaster (including a malicious activity) ever wipes themout. Backup often includes the certificate and its private key, whichmust be backed up securely. The pinning secret, including earlierversions that are still being accepted, must be backed up regularly.However since it is only used as an authentication second factor, itdoes not require the same level of confidentiality as the server'sprivate key.¶
Readers should note that[RFC5077] session resumption keys are moresecurity sensitive and should normally not be backed up, but rathertreated as ephemeral keys. Even when servers derive pinning secrets fromresumption keys (Section 4.1), theyMUST NOT back up resumptionkeys.¶
This section reviews several security aspects related to the proposedextension.¶
This protocol is a trust-on-first-use protocol. If a client initiallyconnects to the "right" server, it will be protected against MITMattackers for the lifetime of each received ticket. If it connectsregularly (depending, of course, on the server-selected lifetime), it willstay constantly protected against fake certificates.¶
However if it initially connects to an attacker, subsequent connectionsto the "right" server will fail. Server operators might want to adviseclients on how to remove corrupted pins, once such large-scale attacksare detected and remediated.¶
The protocol is designed so that it is not vulnerable to an active MITMattacker who has real-time access to the original server. The pinningproof includes a hash of the server's public key to ensure the clientthat the proof was in fact generated by the server with which it isinitiating the connection.¶
Some organizations, and even some countries, perform pervasive monitoringon their constituents[RFC7258]. This often takes the form ofalways-active SSL proxies. Because of the TOFU property, this protocoldoes not provide any security in such cases.¶
Pervasive monitoring may also result in privacy concerns detailed inSection 6.7.¶
Uniquely, this protocol allows the server to detect clients that presentincorrect tickets and therefore can be assumed to be victims of a MITMattack. Server operators can use such cases as indications of ongoingattacks, similarly to fake certificate attacks that took place in a fewcountries in the past.¶
Like it or not, some clients are normally deployed behind an SSL proxy.Similar to[RFC7469], it is acceptable to allow pinning to bedisabled for some hosts according to local policy. For example,a User Agent (UA)MAYdisable pinning for hosts whose validated certificate chain terminatesat a user-defined trust anchor, rather than a trust anchor built intothe UA (or underlying platform). Moreover, a clientMAY accept an emptyPinningTicket extension from such hosts as a valid response.¶
When a client receives a malformed or empty PinningTicket extension froma pinned server, itMUST abort the handshake. If the clientretries the request, itMUST NOT omit thePinningTicket in the retry message. Doing otherwise would expose the client totrivial fallback attacks, similar to those described in[RFC7507].¶
However, this rule can negatively impact clients that move frombehind SSL proxies into the open Internet, and vice versa, if the adviceinSection 6.4 is not followed. Therefore, it isRECOMMENDED thatbrowser and library vendors provide a documented way to remove storedpins.¶
An attacker gains no benefit from stealing pinning tickets, even in conjunction with other pinningparameters such as the associated pinning secret, since pinning tickets are used to secure the clientrather than the server. Similarly, it is useless to forge a ticket fora particular server.¶
This protocol is designed so that an external attacker cannot link different requests to a single client, provided the clientrequests and receives a fresh ticket upon each connection. This may beof concern particularly during ramp down, if the server does not providea new ticket, and the client reuses the same ticket. To reduce or avoid suchprivacy concerns, it isRECOMMENDED for the server to issue a fresh ticket with areduced lifetime. This would at least reduce the time period in whichthe TLS sessions of the client can be linked. The serverMAY alsoissue tickets with a zero-second lifetime until it is confident alltickets are expired.¶
On the other hand, the server to which the client is connecting caneasily track the client. This may be an issue when the client expectsto connect to the server (e.g., a mail server) with multiple identities.ImplementationsSHOULD allow the user to opt out of pinning, either ingeneral or for particular servers.¶
This document does not define the exact content of tickets.Including client-specific information in tickets would raise privacy concernsand isNOT RECOMMENDED.¶
While the ticket format is not mandated by this document, protecting the ticket using authenticated encryption isRECOMMENDED. Some of the algorithmscommonly used for authenticated encryption, e.g., Galois/Counter Mode (GCM), are highlyvulnerable to nonce reuse, and this problem is magnified in a clustersetting. Therefore, implementations that choose AES-GCM or any AEADequivalentMUST adoptone of these three alternatives:¶
The IANA has allocated a TicketPinning extension value in the "TLSExtensionType Values" registry.¶
[RFC8447] defines the procedure, requirements, and the necessaryinformation for the IANA to update the "TLS ExtensionType Values"registry[TLS-EXT]. The registration procedure is "Specification Required"[RFC8126].¶
The TicketPinning extension is registered as follows. (The extension is not limited to Private Use, and as such has its first byte in the range 0-254.)¶
The global PKI system relies on the trust of a CA issuing certificates.As a result, a corrupted trusted CA may issue a certificate for anyorganization 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 theCertificate Transparency (CT) protocol[RFC6962], HTTP Public Key Pinning (HPKP)[RFC7469], and Trust Assertions for Certificate Keys (TACK)[TLS-TACK].¶
CT requirescooperation of a large portion of the hundreds of extant certificateauthorities (CAs) before it can be used "for real", in enforcing mode.It is noted that the relevant industry forum (CA/Browser Forum) isindeed pushing for such extensive adoption. However the public nature of CToften makes it inappropriate for enterprise use because many organizationsare not willing to expose their internal infrastructure publicly.¶
TACK has some similaritiesto the current proposal, but work on it seems to have stalled.Appendix A.2compares our proposal to TACK.¶
HPKP is an IETF standard, but so far has proven hard to deploy. HPKPpins (fixes) a public key, one of the public keys listed in thecertificate chain. As a result, HPKP needs to be coordinated with thecertificate management process. Certificate management impacts HPKP andthus increases the probability of HPKP failures. This risk is made evenhigher given the fact that, even though work has been done in the Automated Certificate Management Environment (ACME)working group to automate certificate management, in many or even most cases,certificates are still managed manually. As a result, HPKP cannot becompletely automated, resulting in error-prone manual configuration. Sucherrors could prevent the web server from being accessed by some clients.In addition, HPKP uses an HTTP header, which makes this solution HTTPSspecific and not generic to TLS. On the other hand, the current documentprovides a solution that is independent of the server's certificatemanagement, and that can be entirely and easily automated.Appendix A.1compares HPKP to the current document in more detail.¶
The ticket pinning proposal augments these mechanisms with a much easierto implement and deploy solution for server identity pinning, by reusingsome of the ideas behind TLS session resumption.¶
This section compares ticket pinning to two earlier proposals, HPKP and TACK.¶
The current IETF standard for pinning the identity of web servers is HPKP[RFC7469].¶
The main differences between HPKP and the current document are thefollowing:¶
On the other hand, HPKP shares the following aspects with identity pinning:¶
Unfortunately HPKP has not seen wide deployment yet. As of March 2016,the number of servers using HPKP was less than 3000[Netcraft]. Thismay simply be due to inertia, but we believe the main reason is theinteractions between HPKP and manual certificate management that isneeded to implement HPKP for enterprise servers. The penalty for makingmistakes (e.g., being too early or too late to deploy new pins) is thatthe server becomes unusable for some of the clients.¶
To demonstrate this point, we present a list of the steps involved indeploying HPKP on a security-sensitive web server.¶
Generate two public/private key pairs on a computer that is not thelive server. The second one is the "backup1" key pair.¶
openssl genrsa -out "example.com.key" 2048;openssl genrsa -out "example.com.backup1.key" 2048;¶
Generate hashes for both of the public keys. These will be used inthe HPKP header:¶
openssl rsa -in "example.com.key" -outform der -pubout | \openssl dgst -sha256 -binary | openssl enc -base64 openssl rsa -in "example.com.backup1.key" -outform der \-pubout | openssl dgst -sha256 -binary | openssl enc -base64¶
Generate a single CSR (Certificate Signing Request) for the firstkey pair, where you include the domain name in the CN (Common Name)field:¶
openssl req -new -subj "/C=GB/ST=Area/L=Town/O=Org/ \CN=example.com" -key "example.com.key" -out "example.com.csr";¶
On the live server, upload and set up the first key pair and itscertificate. At this point, you can add the "Public-Key-Pins" header,using the two hashes you created in step 2.¶
Note that only the first key pair has been uploaded to the server so far.¶
Note that in the above steps, both the certificate issuance as well asthe storage of the backup key pair involve manual steps. Even with anautomated CA that runs the ACME protocol[RFC8555], key backup would be achallenge to automate.¶
Compared with HPKP, TACK[TLS-TACK] is more similarto the current document. It can even be argued that this document is asymmetric-cryptography variant of TACK. That said, there are still afew significant differences:¶
The original idea behind this proposal was published in[Oreo] byMoti Yung, Benny Pinkas, and Omer Berkman. The current protocol isbut a distant relative of the original Oreo protocol, and any errorsare the responsibility of the authors of this document alone.¶
We would like to thank Adrian Farrel, Dave Garrett,Daniel Kahn Gillmor,Alexey Melnikov,Yoav Nir,Eric Rescorla, Benjamin Kaduk, and Rich Salz for their comments on this document.Special thanks to Craig Francis for contributing the HPKP deploymentscript, and to Ralph Holz for several fruitful discussions.¶