idnits 2.17.1 draft-sheffer-tls-pinning-ticket-03.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 == Line 405 has weird spacing: '... ticket a pin...' == Line 409 has weird spacing: '... proof a dem...' == Line 414 has weird spacing: '...ifetime the d...' -- The document date (October 04, 2016) is 2760 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-28) exists of draft-ietf-tls-tls13-14 ** Downref: Normative reference to an Informational RFC: RFC 2104 ** Obsolete normative reference: RFC 5077 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 6962 (Obsoleted by RFC 9162) -- Obsolete informational reference (is this intentional?): RFC 7507 (Obsoleted by RFC 8996) Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Y. Sheffer 3 Internet-Draft Intuit 4 Intended status: Standards Track D. Migault 5 Expires: April 7, 2017 Ericsson 6 October 04, 2016 8 TLS Server Identity Pinning with Tickets 9 draft-sheffer-tls-pinning-ticket-03 11 Abstract 13 Misissued public-key certificates can prevent TLS clients from 14 appropriately authenticating the TLS server. Several alternatives 15 have been proposed to detect this situation and prevent a client from 16 establishing a TLS session with a TLS end point authenticated with an 17 illegitimate public-key certificate, but none is currently in wide 18 use. 20 This document proposes to extend TLS with opaque pinning tickets as a 21 way to pin the server's identity. During an initial TLS session, the 22 server provides an original encrypted pinning ticket. In subsequent 23 TLS session establishment, upon receipt of the pinning ticket, the 24 server proves its ability to decrypt the pinning ticket and thus the 25 ownership if the pinning protection key. The client can now safely 26 conclude that the TLS session is established with the same TLS server 27 as the original TLS session. One of the important properties of this 28 proposal is that no manual management actions are required. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on April 7, 2017. 47 Copyright Notice 49 Copyright (c) 2016 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.1. Conventions used in this document . . . . . . . . . . . . 5 66 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5 67 2.1. Initial Connection . . . . . . . . . . . . . . . . . . . 6 68 2.2. Subsequent Connections . . . . . . . . . . . . . . . . . 8 69 2.3. Indexing the Pins . . . . . . . . . . . . . . . . . . . . 9 70 3. Message Definitions . . . . . . . . . . . . . . . . . . . . . 9 71 4. Cryptographic Operations . . . . . . . . . . . . . . . . . . 10 72 4.1. Pinning Secret . . . . . . . . . . . . . . . . . . . . . 10 73 4.2. Pinning Ticket . . . . . . . . . . . . . . . . . . . . . 10 74 4.3. Pinning Protection Key . . . . . . . . . . . . . . . . . 11 75 4.4. Pinning Proof . . . . . . . . . . . . . . . . . . . . . . 11 76 5. Operational Considerations . . . . . . . . . . . . . . . . . 12 77 5.1. Protection Key Synchronization . . . . . . . . . . . . . 12 78 5.2. Ticket Lifetime . . . . . . . . . . . . . . . . . . . . . 12 79 5.3. Certificate Renewal . . . . . . . . . . . . . . . . . . . 12 80 5.4. Certificate Revocation . . . . . . . . . . . . . . . . . 13 81 5.5. Disabling Pinning . . . . . . . . . . . . . . . . . . . . 13 82 5.6. Server Compromise . . . . . . . . . . . . . . . . . . . . 13 83 5.7. Disaster Recovery . . . . . . . . . . . . . . . . . . . . 13 84 6. Previous Work . . . . . . . . . . . . . . . . . . . . . . . . 14 85 6.1. Comparison: HPKP Deployment . . . . . . . . . . . . . . . 14 86 6.2. Comparison: TACK . . . . . . . . . . . . . . . . . . . . 15 87 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 16 88 7.1. Mint Fork . . . . . . . . . . . . . . . . . . . . . . . . 17 89 7.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . 17 90 7.1.2. Description . . . . . . . . . . . . . . . . . . . . . 17 91 7.1.3. Level of Maturity . . . . . . . . . . . . . . . . . . 17 92 7.1.4. Coverage . . . . . . . . . . . . . . . . . . . . . . 17 93 7.1.5. Version Compatibility . . . . . . . . . . . . . . . . 17 94 7.1.6. Licensing . . . . . . . . . . . . . . . . . . . . . . 17 95 7.1.7. Contact Information . . . . . . . . . . . . . . . . . 17 96 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 97 8.1. Trust on First Use (TOFU) and MITM Attacks . . . . . . . 17 98 8.2. Pervasive Monitoring . . . . . . . . . . . . . . . . . . 18 99 8.3. Server-Side Error Detection . . . . . . . . . . . . . . . 18 100 8.4. Client Policy and SSL Proxies . . . . . . . . . . . . . . 18 101 8.5. Client-Side Error Behavior . . . . . . . . . . . . . . . 18 102 8.6. Stolen and Forged Tickets . . . . . . . . . . . . . . . . 19 103 8.7. Client Privacy . . . . . . . . . . . . . . . . . . . . . 19 104 8.8. Ticket Protection Key Management . . . . . . . . . . . . 19 105 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 106 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 107 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 108 11.1. Normative References . . . . . . . . . . . . . . . . . . 20 109 11.2. Informative References . . . . . . . . . . . . . . . . . 20 110 Appendix A. Document History . . . . . . . . . . . . . . . . . . 22 111 A.1. draft-sheffer-tls-pinning-ticket-03 . . . . . . . . . . . 22 112 A.2. draft-sheffer-tls-pinning-ticket-02 . . . . . . . . . . . 22 113 A.3. draft-sheffer-tls-pinning-ticket-01 . . . . . . . . . . . 22 114 A.4. draft-sheffer-tls-pinning-ticket-00 . . . . . . . . . . . 22 115 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 117 1. Introduction 119 The weaknesses of the global PKI system are by now widely known. 120 Essentially, any valid CA may issue a certificate for any 121 organization without the organization's approval (a misissued or 122 "fake" certificate), and use the certificate to impersonate the 123 organization. There are many attempts to resolve these weaknesses, 124 including Certificate Transparency (CT) [RFC6962], HTTP Public Key 125 Pinning (HPKP) [RFC7469], and TACK [I-D.perrin-tls-tack]. CT 126 requires cooperation of a large portion of the hundreds of extant 127 certificate authorities (CAs) before it can be used "for real", in 128 enforcing mode. It is noted that the relevant industry forum (CA/ 129 Browser Forum) is indeed pushing for such extensive adoption. TACK 130 has some similarities to the current proposal, but work on it seems 131 to have stalled. Section 6.2 compares our proposal to TACK. 133 HPKP is an IETF standard, but so far has proven hard to deploy. HPKP 134 cannot be completely automated resulting in error-prone manual 135 configuration. Such errors could prevent the web server from being 136 accessed by some clients. In addition, HPKP uses a HTTP header which 137 makes this solution HTTPS specific and not generic to TLS. On the 138 other hand, the current document provides a solution that can be 139 entirely automated. Section 6.1 compares HPKP to the current draft 140 in more detail. 142 The ticket pinning proposal augments these mechanisms with a much 143 easier to implement and deploy solution for server identity pinning, 144 by reusing some of the ideas behind TLS session resumption. 146 Ticket pinning is a second factor server authentication method and is 147 not proposed as a substitute of the authentication method provided in 148 the TLS key exchange. More specifically, the client only uses the 149 pinning identity method after the TLS key exchange is successfully 150 completed. In other words, the pinning identity method is only 151 performed over an authenticated TLS session. 153 Ticket pinning is a Trust On First Use (TOFU) mechanism, in that the 154 first server authentication is only based on PKI certificate 155 validation, but for any follow-on sessions, the client is further 156 ensuring the server's identity based on the server's ability to 157 decrypt the ticket, in addition to normal PKI certificate 158 authentication. 160 During initial TLS session establishment, the client requests a 161 pinning ticket from the server. Upon receiving the request the 162 server generates a pinning secret which is expected to be 163 unpredictable for peers other than the client or the server. In our 164 case, the pinning secret is generated from parameters exchanged 165 during the TLS key exchange, so client and server can generate it 166 locally and independently. The server constructs the pinning ticket 167 with the necessary information to retrieve the pinning secret. The 168 server then encrypts the ticket and returns the pinning ticket to the 169 client with an associated pinning lifetime. 171 The pinning lifetime value indicates for how long the server promises 172 to retain the server-side ticket-encryption key, which allows it to 173 complete the protocol exchange correctly and prove its identity. The 174 committed lifetime is typically on the order of weeks or months. 176 Once the key exchange is completed and the server is deemed 177 authenticated, the client generates locally the pinning secret and 178 caches the server's identifiers to index the pinning secret as well 179 as the pinning ticket and its associated lifetime. 181 When the client re-establishes a new TLS session with the server, it 182 sends the pinning ticket to the server. Upon receiving it, the 183 server returns a proof of knowledge of the pinning secret. Once the 184 key exchange is completed and the server has been authenticated, the 185 client checks the pinning proof returned by the server with its 186 pinning secret. It a match occurs, the client concludes that the 187 server it is currently connected to and the server it was previously 188 connected to both own the same pinning protection key and thus are 189 the same server. 191 This version of the draft only applies to TLS 1.3. We believe that 192 the idea can also be back-fitted into earlier versions of the 193 protocol. 195 The main advantages of this protocol over earlier pinning solutions 196 are: 198 - The protocol is at the TLS level, and as a result is not 199 restricted to HTTP at the application level. 201 - The protocol is robust to server IP, CA, and public key changes. 202 The server is characterized by the ownership of the pinning 203 protection key, which is never provided to the client. Server 204 configuration parameters such as the CA and the public key may 205 change without affecting the pinning ticket protocol. 207 - Once a single parameter is configured (the ticket's lifetime), 208 operation is fully automated. The server administrator need not 209 bother with the management of backup certificates or explicit 210 pins. 212 - For server clusters, we reuse the existing [RFC5077] 213 infrastructure where it exists. 215 - Pinning errors, presumably resulting from MITM attacks, can be 216 detected both by the client and the server. This allows for 217 server-side detection of MITM attacks using large-scale analytics. 219 A note on terminology: unlike other solutions in this space, we do 220 not do "certificate pinning" (or "public key pinning"), since the 221 protocol is oblivious to the server's certificate. We prefer the 222 term "server identity pinning" for this new solution. 224 1.1. Conventions used in this document 226 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 227 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 228 document are to be interpreted as described in [RFC2119]. 230 2. Protocol Overview 232 The protocol consists of two phases: the first time a particular 233 client connects to a server, and subsequent connections. 235 This protocol supports full TLS handshakes, as well as 0-RTT 236 handshakes. Below we present it in the context of a full handshake, 237 but behavior in 0-RTT handshakes should be identical. 239 The document presents some similarities with the ticket resumption 240 mechanism described in [RFC5077]. However the scope of this document 241 differs from session resumption mechanisms implemented with [RFC5077] 242 or with other mechanisms. Specifically, the pinning ticket does not 243 carry any state associated with a TLS session and thus cannot be used 244 for session resumption, or to authenticate the client. 246 With TLS 1.3, session resumption is based on a preshared key (PSK). 247 This is orthogonal to this protocol. With TLS 1.3, a TLS session can 248 be established using PKI and a pinning ticket, and later resumed with 249 PSK. 251 However, the protocol described in this document addresses the 252 problem of misissued certificates. Thus, it is not expected to be 253 used outside a certificate-based TLS key exchange, such as in PSK. 254 As a result, PSK handshakes MUST NOT include the extension defined 255 here. 257 2.1. Initial Connection 259 When a client first connects to a server, it requests a pinning 260 ticket by sending an empty PinningTicket extension, and receives it 261 as part of the server's first response, in the returned PinningTicket 262 extension. 264 Client Server 266 ClientHello 267 + key_share 268 + PinningTicket --------> 269 ServerHello 270 + key_share 271 {EncryptedExtensions 272 + PinningTicket} 273 {ServerConfiguration*} 274 {Certificate*} 275 {CertificateRequest*} 276 {CertificateVerify*} 277 <-------- {Finished} 278 {Certificate*} 279 {CertificateVerify*} 280 {Finished} --------> 281 [Application Data] <-------> [Application Data] 283 * Indicates optional or situation-dependent 284 messages that are not always sent. 286 {} Indicates messages protected using keys 287 derived from the ephemeral secret. 289 [] Indicates messages protected using keys 290 derived from the master secret. 292 If a client supports the pinning ticket extension and does not have 293 any pinning ticket associated with the server, the exchange is 294 considered as an initial connection. Other reasons the client may 295 not have a pinning ticket include the client having flushed its 296 pinning ticket store, or the committed lifetime of the pinning ticket 297 having expired. 299 Upon receipt of the PinningTicket extension, the server computes a 300 pinning secret (Section 4.1), and sends the pinning ticket 301 (Section 4.2) encrypted with the pinning protection key 302 (Section 4.3). The pinning ticket is associated with a lifetime 303 value by which the server assumes the responsibility of retaining the 304 pinning protection key and being able to decrypt incoming pinning 305 tickets during the period indicated by the committed lifetime. 307 Once the pinning ticket has been generated, the server returns the 308 pinning ticket and the committed lifetime in a PinningTicket 309 extension embedded in the EncryptedExtensions message. We note that 310 a PinningTicket extension MUST NOT be sent as part of a 311 HelloRetryRequest. 313 Upon receiving the pinning ticket, the client MUST NOT accept it 314 until the key exchange is completed and the server authenticated. If 315 the key exchange is not completed successfully, the client MUST 316 ignore the received pinning ticket. Otherwise, the client computes 317 the pinning secret and SHOULD cache the pinning secret and the 318 pinning ticket for the duration indicated by the pinning ticket 319 lifetime. The client SHOULD clean up the cached values at the end of 320 the indicated lifetime. 322 2.2. Subsequent Connections 324 When the client initiates a connection to a server it has previously 325 seen (see Section 2.3 on identifying servers), it SHOULD send the 326 pinning ticket for that server. The pinning ticket, pinning secret 327 and pinning ticket lifetime computed during the establishment of the 328 previous TLS session are designated in this document as the 329 "original" ones, to distinguish them from a new ticket that may be 330 generated during the current session. 332 The server MUST extract the original pinning_secret value from the 333 ticket and MUST respond with a PinningTicket extension, which 334 includes: 336 - A proof that the server can understand the ticket that was sent by 337 the client; this proof also binds the pinning ticket to the 338 server's (current) public key. The proof is MANDATORY if a 339 pinning ticket was sent by the client. 341 - A fresh pinning ticket. The main reason for refreshing the ticket 342 on each connection is privacy: to avoid the ticket serving as a 343 fixed client identifier. It is RECOMMENDED to include a fresh 344 ticket with each response. 346 If the server cannot validate the received ticket, that might 347 indicate an earlier MITM attack on this client. The server MUST then 348 abort the connection with a handshake_failure alert, and SHOULD log 349 this failure. 351 The client MUST verify the proof, and if it fails to do so, MUST 352 issue a handshake_failure alert and abort the connection (see also 353 Section 8.5). It is important that the client does not attempt to 354 "fall back" by omitting the PinningTicket extension. 356 When the connection is successfully set up, i.e. after the Finished 357 message is verified, the client SHOULD store the new ticket along 358 with the corresponding pinning_secret, replacing the original ticket. 360 Although this is an extension, if the client already has a ticket for 361 a server, the client MUST interpret a missing PinningTicket extension 362 in the server's response as an attack, because of the server's prior 363 commitment to respect the ticket. The client MUST abort the 364 connection in this case. See also Section 5.5 on ramping down 365 support for this extension. 367 2.3. Indexing the Pins 369 Each pin is associated with a host name, protocol (TLS or DTLS) and 370 port number. In other words, the pin for port TCP/443 may be 371 different from that for DTLS or from the pin for port TCP/8443. The 372 host name MUST be the value sent inside the Server Name Indication 373 (SNI) extension. This definition is similar to a Web Origin 374 [RFC6454], but does not assume the existence of a URL. 376 The purpose of ticket pinning is to pin the server identity. As a 377 result, any information orthogonal to the server's identity MUST NOT 378 be considered in indexing. More particularly, IP addresses are 379 ephemeral and forbidden in SNI and therefore pins MUST NOT be 380 associated with IP addresses. Similarly, CA names or public keys 381 associated with server MUST NOT be used for indexing as they may 382 change over time. 384 3. Message Definitions 386 This section defines the format of the PinningTicket extension. We 387 follow the message notation of [I-D.ietf-tls-tls13]. 389 opaque pinning_ticket<0..2^16-1>; 391 opaque pinning_proof<0..2^8-1>; 393 struct { 394 select (Role) { 395 case client: 396 pinning_ticket ticket<0..2^16-1>; //omitted on 1st connection 398 case server: 399 pinning_proof proof<0..2^8-1>; //no proof on 1st connection 400 pinning_ticket ticket<0..2^16-1>; //omitted on ramp down 401 uint32 lifetime; 402 } 403 } PinningTicketExtension; 405 ticket a pinning ticket sent by the client or returned by the 406 server. The ticket is opaque to the client. The extension MUST 407 contain exactly 0 or 1 tickets. 409 proof a demonstration by the server that it understands the received 410 ticket and therefore that it is in possession of the secret that 411 was used to generate it originally. The extension MUST contain 412 exactly 0 or 1 proofs. 414 lifetime the duration (in seconds) that the server commits to accept 415 offered tickets in the future. 417 4. Cryptographic Operations 419 This section provides details on the cryptographic operations 420 performed by the protocol peers. 422 4.1. Pinning Secret 424 The pinning secret is generated locally by the client and the server 425 which means they must use the same inputs to generate it. This value 426 must be generated before the ServerHello message is sent, and must be 427 unpredictable to any party other than the client and the server. 429 The pinning secret is derived using the Derive-Secret function 430 provided by TLS 1.3, described in Section "Key Schedule" of 431 [I-D.ietf-tls-tls13]. 433 pinning secret = Derive-Secret(Handshake Secret, "pinning secret", 434 ClientHello...ServerHello) 436 4.2. Pinning Ticket 438 The pinning ticket contains the pinning secret. The pinning ticket 439 is provided by the client to the server which decrypts it in order to 440 extract the pinning secret and responds with a pinning proof. As a 441 result, the characteristics of the pinning ticket are: 443 - Pinning tickets MUST be encrypted and integrity-protected using 444 strong cryptographic algorithms. 446 - Pinning tickets MUST be protected with a long-term pinning 447 protection key. 449 - Pinning tickets MUST include a pinning protection key ID or serial 450 number as to enable the pinning protection key to be refreshed. 452 - The pinning ticket MAY include other information, in addition to 453 the pinning secret. 455 The pinning ticket's format is not specified by this document, but we 456 RECOMMEND a format similar to the one proposed by [RFC5077]. 458 4.3. Pinning Protection Key 460 The pinning protection key is only used by the server and so remains 461 server implementation specific. [RFC5077] recommends the use of two 462 keys, but when using AEAD algorithms only a single key is required. 464 When a single server terminates TLS for multiple virtual servers 465 using the Server Name Indication (SNI) mechanism, we strongly 466 RECOMMEND to use a separate protection key for each one of them, in 467 order to allow migrating virtual servers between different servers 468 while keeping pinning active. 470 As noted in Section 5.1, if the server is actually a cluster of 471 machines, the protection key MUST be synchronized between them. When 472 [RFC5077] is deployed, an easy way to do it is to derive the 473 protection key from the session-ticket protection key, which is 474 already synchronized. For example: 476 pinning_protection_key = HKDF-Expand(resumption_protection_key, 477 "pinning protection", L) 479 4.4. Pinning Proof 481 The pinning proof is sent by the server to demonstrate that it has 482 been able to decrypt the pinning ticket and retrieve the pinning 483 secret. The proof must be unpredictable and must not be replayed. 484 Similarly to the pinning secret, the pinning proof is sent by the 485 server in the ServerHello message. In addition, it must not be 486 possible for a MITM server with a fake certificate to obtain a 487 pinning proof from the original server. 489 In order to address these requirements, the pinning proof is bound to 490 the TLS session as well as the public key of the server: 492 proof = HMAC(original_pinning_secret, "pinning proof" + 493 Handshake-Secret + Hash(server_public_key)) 495 where HMAC [RFC2104] uses the Hash algorithm that was negotiated in 496 the handshake, and the same hash is also used over the server's 497 public key. The original_pinning_secret value refers to the secret 498 value extracted from the ticket sent by the client, to distinguish it 499 from a new pinning secret value that is possibly computed in the 500 current exchange. The server_public_key value is the DER 501 representation of the public key, specifically the 502 SubjectPublicKeyInfo structure as-is. 504 5. Operational Considerations 506 The main motivation behind the current protocol is to enable identity 507 pinning without the need for manual operations. To achieve this goal 508 operations described in identity pinning are only performed within 509 the current TLS session, and there is no dependence on any TLS 510 configuration parameters such as CA identity or public keys. As a 511 result, configuration changes are unlikely to lead to desynchronized 512 state between the client and the server. Manual operations are 513 susceptible to human error and in the case of public key pinning, can 514 easily result in "server bricking": the server becoming inaccessible 515 to some or all of its users. 517 5.1. Protection Key Synchronization 519 The only operational requirement when deploying this protocol is that 520 if the server is part of a cluster, protection keys (the keys used to 521 encrypt tickets) MUST be synchronized between all cluster members. 522 The protocol is designed so that if resumption ticket protection keys 523 [RFC5077] are already synchronized between cluster members, nothing 524 more needs to be done. 526 Moreover, synchronization does not need to be instantaneous, e.g. 527 protection keys can be distributed a few minutes or hours in advance 528 of their rollover. 530 Misconfiguration can lead to the server's clock being off by a large 531 amount of time. Therefore we RECOMMEND never to automatically delete 532 protection keys, even when they are long expired. 534 5.2. Ticket Lifetime 536 The lifetime of the ticket is a commitment by the server to retain 537 the ticket's corresponding protection key for this duration, so that 538 the server can prove to the client that it knows the secret embedded 539 in the ticket. For production systems, the lifetime SHOULD be 540 between 7 and 30 days. 542 5.3. Certificate Renewal 544 The protocol ensures that the client will continue speaking to the 545 correct server even when the server's certificate is renewed. In 546 this sense, we are not "pinning certificates" and the protocol should 547 more precisely be called "server identity pinning". 549 Note that this property is not impacted by the use of the server's 550 public key in the pinning proof, because the scope of the public key 551 used is only the current TLS session. 553 5.4. Certificate Revocation 555 The protocol is orthogonal to certificate validation in the sense 556 that, if the server's certificate has been revoked or is invalid for 557 some other reason, the client MUST refuse to connect to it regardless 558 of any ticket-related behavior. 560 5.5. Disabling Pinning 562 A server implementing this protocol MUST have a "ramp down" mode of 563 operation where: 565 - The server continues to accept valid pinning tickets and responds 566 correctly with a proof. 568 - The server does not send back a new pinning ticket. 570 After a while no clients will hold valid tickets any more and the 571 feature may be disabled. 573 5.6. Server Compromise 575 If a server compromise is detected, the pinning protection key MUST 576 be rotated immediately, but the server MUST still accept valid 577 tickets that use the old, compromised key. Clients that still hold 578 old pinning tickets will remain vulnerable to MITM attacks, but those 579 that connect to the correct server will immediately receive new 580 tickets protected with the newly generated pinning protection key. 582 5.7. Disaster Recovery 584 All web servers in production need to be backed up, so that they can 585 be recovered if a disaster (including a malicious activity) ever 586 wipes them out. Backup typically includes the certificate and its 587 private key, which must be backed up securely. The pinning secret, 588 including earlier versions that are still being accepted, must be 589 backed up regularly. However since it is only used as an 590 authentication second factor, it does not require the same level of 591 confidentiality as the server's private key. 593 Readers should note that [RFC5077] session resumption keys are more 594 security sensitive, and should normally not be backed up but rather 595 treated as ephemeral keys. Even when servers derive pinning secrets 596 from resumption keys (Section 4.1), they MUST NOT back up resumption 597 keys. 599 6. Previous Work 601 This section compares ticket pinning to two earlier proposals, HPKP 602 and TACK. 604 6.1. Comparison: HPKP Deployment 606 The current IETF standard for pinning the identity of web servers is 607 the Public Key Pinning Extension for HTTP, or HPKP [RFC7469]. 608 Unfortunately HPKP has not seen wide deployment yet. As of March 609 2016, the number of servers using HPKP was less than 3000 [Netcraft]. 610 This may simply be due to inertia, but we believe the main reason is 611 the onerous manual certificate management which is needed to 612 implement HPKP for enterprise servers. The penalty for making 613 mistakes (e.g. being too early or too late to deploy new pins) is 614 having the server become unusable for some of the clients. 616 To demonstrate this point, we present a list of the steps involved in 617 deploying HPKP on a security-sensitive Web server. 619 1. Generate two public/private key-pairs on a computer that is not 620 the Live server. The second one is the "backup1" key-pair. 622 "openssl genrsa -out "example.com.key" 2048;" 624 "openssl genrsa -out "example.com.backup1.key" 2048;" 626 2. Generate hashes for both of the public keys. These will be used 627 in the HPKP header: 629 "openssl rsa -in "example.com.key" -outform der -pubout | 630 openssl dgst -sha256 -binary | openssl enc -base64" 632 "openssl rsa -in "example.com.backup1.key" -outform der 633 -pubout | openssl dgst -sha256 -binary | openssl enc -base64" 635 3. Generate a single CSR (Certificate Signing Request) for the 636 first key-pair, where you include the domain name in the CN 637 (Common Name) field: 639 "openssl req -new -subj "/C=GB/ST=Area/L=Town/O=Company/ 640 CN=example.com" -key "example.com.key" -out "example.com.csr";" 642 4. Send this CSR to the CA (Certificate Authority), and go though 643 the dance to prove you own the domain. The CA will give you 644 back a single certificate that will typically expire within a 645 year or two. 647 5. On the Live server, upload and setup the first key-pair (and its 648 certificate). At this point you can add the "Public-Key-Pins" 649 header, using the two hashes you created in step 2. 651 Note that only the first key-pair has been uploaded to the 652 server so far. 654 6. Store the second (backup1) key-pair somewhere safe, probably 655 somewhere encrypted like a password manager. It won't expire, 656 as it's just a key-pair, it just needs to be ready for when you 657 need to get your next certificate. 659 7. Time passes... probably just under a year (if waiting for a 660 certificate to expire), or maybe sooner if you find that your 661 server has been compromised and you need to replace the key-pair 662 and certificate. 664 8. Create a new CSR (Certificate Signing Request) using the 665 "backup1" key-pair, and get a new certificate from your CA. 667 9. Generate a new backup key-pair (backup2), get its hash, and 668 store it in a safe place (again, not on the Live server). 670 10. Replace your old certificate and old key-pair, and update the 671 "Public-Key-Pins" header to remove the old hash, and add the new 672 "backup2" key-pair. 674 Note that in the above steps, both the certificate issuance as well 675 as the storage of the backup key pair involve manual steps. Even 676 with an automated CA that runs the ACME protocol, key backup would be 677 a challenge to automate. 679 6.2. Comparison: TACK 681 Compared with HPKP, TACK [I-D.perrin-tls-tack] is a lot more similar 682 to the current draft. It can even be argued that this document is a 683 symmetric-cryptography variant of TACK. That said, there are still a 684 few significant differences: 686 - Probably the most important difference is that with TACK, 687 validation of the server certificate is no longer required, and in 688 fact TACK specifies it as a "MAY" requirement (Sec. 5.3). With 689 ticket pinning, certificate validation by the client remains a 690 MUST requirement, and the ticket acts only as a second factor. If 691 the pinning secret is compromised, the server's security is not 692 immediately at risk. 694 - Both TACK and the current draft are mostly orthogonal to the 695 server certificate as far as their life cycle, and so both can be 696 deployed with no manual steps. 698 - TACK uses ECDSA to sign the server's public key. This allows 699 cooperating clients to share server assertions between themselves. 700 This is an optional TACK feature, and one that cannot be done with 701 pinning tickets. 703 - TACK allows multiple servers to share its public keys. Such 704 sharing is disallowed by the current document. 706 - TACK does not allow the server to track a particular client, and 707 so has better privacy properties than the current draft. 709 - TACK has an interesting way to determine the pin's lifetime, 710 setting it to the time period since the pin was first observed, 711 with a hard upper bound of 30 days. The current draft makes the 712 lifetime explicit, which may be more flexible to deploy. For 713 example, Web sites which are only visited rarely by users may opt 714 for a longer period than other sites that expect users to visit on 715 a daily basis. 717 7. Implementation Status 719 Note to RFC Editor: please remove this section before publication, 720 including the reference to [RFC7942]. 722 This section records the status of known implementations of the 723 protocol defined by this specification at the time of posting of this 724 Internet-Draft, and is based on a proposal described in [RFC7942]. 725 The description of implementations in this section is intended to 726 assist the IETF in its decision processes in progressing drafts to 727 RFCs. Please note that the listing of any individual implementation 728 here does not imply endorsement by the IETF. Furthermore, no effort 729 has been spent to verify the information presented here that was 730 supplied by IETF contributors. This is not intended as, and must not 731 be construed to be, a catalog of available implementations or their 732 features. Readers are advised to note that other implementations may 733 exist. 735 According to RFC 7942, "this will allow reviewers and working groups 736 to assign due consideration to documents that have the benefit of 737 running code, which may serve as evidence of valuable experimentation 738 and feedback that have made the implemented protocols more mature. 739 It is up to the individual working groups to use this information as 740 they see fit". 742 7.1. Mint Fork 744 7.1.1. Overview 746 A fork of the Mint TLS 1.3 implementation, developed by Yaron Sheffer 747 and available at https://github.com/yaronf/mint. 749 7.1.2. Description 751 This is a fork of the TLS 1.3 implementation, and includes client and 752 server code. In addition to the actual protocol, several utilities 753 are provided allowing to manage pinning protection keys on the server 754 side, and pinning tickets on the client side. 756 7.1.3. Level of Maturity 758 This is a prototype. 760 7.1.4. Coverage 762 The entire protocol is implemented. 764 7.1.5. Version Compatibility 766 The implementation is compatible with draft-sheffer-tls-pinning- 767 ticket-02. 769 7.1.6. Licensing 771 Mint itself and this fork are available under an MIT license. 773 7.1.7. Contact Information 775 See author details below. 777 8. Security Considerations 779 This section reviews several security aspects related to the proposed 780 extension. 782 8.1. Trust on First Use (TOFU) and MITM Attacks 784 This protocol is a "trust on first use" protocol. If a client 785 initially connects to the "right" server, it will be protected 786 against MITM attackers for the lifetime of each received ticket. If 787 it connects regularly (depending of course on the server-selected 788 lifetime), it will stay constantly protected against fake 789 certificates. 791 However if it initially connects to an attacker, subsequent 792 connections to the "right" server will fail. Server operators might 793 want to advise clients on how to remove corrupted pins, once such 794 large scale attacks are detected and remediated. 796 The protocol is designed so that it is not vulnerable to an active 797 MITM attacker who has real-time access to the original server. The 798 pinning proof includes a hash of the server's public key, to ensure 799 the client that the proof was in fact generated by the server with 800 which it is initiating the connection. 802 8.2. Pervasive Monitoring 804 Some organizations, and even some countries perform pervasive 805 monitoring on their constituents [RFC7258]. This often takes the 806 form of always-active SSL proxies. Because of the TOFU property, 807 this protocol does not provide any security in such cases. 809 8.3. Server-Side Error Detection 811 Uniquely, this protocol allows the server to detect clients that 812 present incorrect tickets and therefore can be assumed to be victims 813 of a MITM attack. Server operators can use such cases as indications 814 of ongoing attacks, similarly to fake certificate attacks that took 815 place in a few countries in the past. 817 8.4. Client Policy and SSL Proxies 819 Like it or not, some clients are normally deployed behind an SSL 820 proxy. Similarly to [RFC7469], it is acceptable to allow pinning to 821 be disabled for some hosts according to local policy. For example, a 822 UA MAY disable pinning for hosts whose validated certificate chain 823 terminates at a user-defined trust anchor, rather than a trust anchor 824 built-in to the UA (or underlying platform). Moreover, a client MAY 825 accept an empty PinningTicket extension from such hosts as a valid 826 response. 828 8.5. Client-Side Error Behavior 830 When a client receives a malformed or empty PinningTicket extension 831 from a pinned server, it MUST abort the handshake and MUST NOT retry 832 with no PinningTicket in the request. Doing otherwise would expose 833 the client to trivial fallback attacks, similar to those described in 834 [RFC7507]. 836 This rule can however have negative affects on clients that move from 837 behind SSL proxies into the open Internet and vice versa, if the 838 advice in Section 8.4 is not followed. Therefore, we RECOMMEND that 839 browser and library vendors provide a documented way to remove stored 840 pins. 842 8.6. Stolen and Forged Tickets 844 Stealing pinning tickets even in conjunction with other pinning 845 parameters, such as the associated pinning secret, provides no 846 benefit to the attacker since pinning tickets are used to secure the 847 client rather than the server. Similarly, it is useless to forge a 848 ticket for a particular sever. 850 8.7. Client Privacy 852 This protocol is designed so that an external attacker cannot 853 correlate between different requests of a single client, provided the 854 client requests and receives a fresh ticket upon each connection. 856 On the other hand, the server to which the client is connecting can 857 easily track the client. This may be an issue when the client 858 expects to connect to the server (e.g., a mail server) with multiple 859 identities. Implementations SHOULD allow the user to opt out of 860 pinning, either in general or for particular servers. 862 8.8. Ticket Protection Key Management 864 While the ticket format is not mandated by this document, we 865 RECOMMEND using authenticated encryption to protect it. Some of the 866 algorithms commonly used for authenticated encryption, e.g. GCM, are 867 highly vulnerable to nonce reuse, and this problem is magnified in a 868 cluster setting. Therefore implementations that choose AES-128-GCM 869 MUST adopt one of these two alternatives: 871 - Partition the nonce namespace between cluster members and use 872 monotonic counters on each member, e.g. by setting the nonce to 873 the concatenation of the cluster member ID and an incremental 874 counter. 876 - Generate random nonces but avoid the so-called birthday bound, 877 i.e. never generate more than 2**64 encrypted tickets for the same 878 ticket pinning protection Key. 880 9. IANA Considerations 882 IANA is requested to allocate a TicketPinning extension value in the 883 TLS ExtensionType Registry. 885 No registries are defined by this document. 887 10. Acknowledgements 889 The original idea behind this proposal was published in [Oreo] by 890 Moty Yung, Benny Pinkas and Omer Berkman. The current protocol is 891 but a distant relative of the original Oreo protocol, and any errors 892 are the draft authors' alone. 894 We would like to thank Dave Garrett, Daniel Kahn Gillmor and Yoav Nir 895 for their comments on this draft. Special thanks to Craig Francis 896 for contributing the HPKP deployment script, and to Ralph Holz for 897 several fruitful discussions. 899 11. References 901 11.1. Normative References 903 [I-D.ietf-tls-tls13] 904 Rescorla, E., "The Transport Layer Security (TLS) Protocol 905 Version 1.3", draft-ietf-tls-tls13-14 (work in progress), 906 July 2016. 908 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 909 Hashing for Message Authentication", RFC 2104, 910 DOI 10.17487/RFC2104, February 1997, 911 . 913 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 914 Requirement Levels", BCP 14, RFC 2119, 915 DOI 10.17487/RFC2119, March 1997, 916 . 918 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 919 "Transport Layer Security (TLS) Session Resumption without 920 Server-Side State", RFC 5077, DOI 10.17487/RFC5077, 921 January 2008, . 923 11.2. Informative References 925 [I-D.perrin-tls-tack] 926 Marlinspike, M., "Trust Assertions for Certificate Keys", 927 draft-perrin-tls-tack-02 (work in progress), January 2013. 929 [Netcraft] 930 Mutton, P., "HTTP Public Key Pinning: You're doing it 931 wrong!", March 2016, 932 . 935 [Oreo] Berkman, O., Pinkas, B., and M. Yung, "Firm Grip 936 Handshakes: A Tool for Bidirectional Vouching", Cryptology 937 and Network Security, pp. 142-157 , 2012. 939 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, 940 DOI 10.17487/RFC6454, December 2011, 941 . 943 [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate 944 Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, 945 . 947 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 948 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 949 2014, . 951 [RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning 952 Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April 953 2015, . 955 [RFC7507] Moeller, B. and A. Langley, "TLS Fallback Signaling Cipher 956 Suite Value (SCSV) for Preventing Protocol Downgrade 957 Attacks", RFC 7507, DOI 10.17487/RFC7507, April 2015, 958 . 960 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 961 Code: The Implementation Status Section", BCP 205, 962 RFC 7942, DOI 10.17487/RFC7942, July 2016, 963 . 965 Appendix A. Document History 967 A.1. draft-sheffer-tls-pinning-ticket-03 969 - Deleted redundant length fields in the extension's formal 970 definition. 972 - Modified cryptographic operations to align with the current state 973 of TLS 1.3. 975 - Numerous textual improvements. 977 A.2. draft-sheffer-tls-pinning-ticket-02 979 - Added an Implementation Status section. 981 - Added lengths into the extension structure. 983 - Changed the computation of the pinning proof to be more robust. 985 - Clarified requirements on the length of the pinning_secret. 987 - Revamped the HPKP section to be more in line with current 988 practices, and added recent statistics on HPKP deployment. 990 A.3. draft-sheffer-tls-pinning-ticket-01 992 - Corrected the notation for variable-sized vectors. 994 - Added a section on disaster recovery and backup. 996 - Added a section on privacy. 998 - Clarified the assumptions behind the HPKP procedure in the 999 comparison section. 1001 - Added a definition of pin indexing (origin). 1003 - Adjusted to the latest TLS 1.3 notation. 1005 A.4. draft-sheffer-tls-pinning-ticket-00 1007 Initial version. 1009 Authors' Addresses 1011 Yaron Sheffer 1012 Intuit 1014 EMail: yaronf.ietf@gmail.com 1016 Daniel Migault 1017 Ericsson 1019 EMail: daniel.migault@ericsson.com