idnits 2.17.1 draft-sheffer-tls-pinning-ticket-08.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 432 has weird spacing: '... ticket a pin...' == Line 436 has weird spacing: '... proof a dem...' == Line 441 has weird spacing: '...ifetime the d...' -- The document date (January 17, 2019) is 1925 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** 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: 1 error (**), 0 flaws (~~), 4 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: Experimental D. Migault 5 Expires: July 21, 2019 Ericsson 6 January 17, 2019 8 TLS Server Identity Pinning with Tickets 9 draft-sheffer-tls-pinning-ticket-08 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 of 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 https://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 July 21, 2019. 47 Copyright Notice 49 Copyright (c) 2019 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 (https://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 . . . . . . . . . . . . 6 66 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 67 2.1. Initial Connection . . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . . . . . . 11 74 4.3. Pinning Protection Key . . . . . . . . . . . . . . . . . 11 75 4.4. Pinning Proof . . . . . . . . . . . . . . . . . . . . . . 12 76 5. Operational Considerations . . . . . . . . . . . . . . . . . 12 77 5.1. Protection Key Synchronization . . . . . . . . . . . . . 12 78 5.2. Ticket Lifetime . . . . . . . . . . . . . . . . . . . . . 13 79 5.3. Certificate Renewal . . . . . . . . . . . . . . . . . . . 13 80 5.4. Certificate Revocation . . . . . . . . . . . . . . . . . 13 81 5.5. Disabling Pinning . . . . . . . . . . . . . . . . . . . . 13 82 5.6. Server Compromise . . . . . . . . . . . . . . . . . . . . 14 83 5.7. Disaster Recovery . . . . . . . . . . . . . . . . . . . . 14 84 6. Previous Work . . . . . . . . . . . . . . . . . . . . . . . . 15 85 6.1. Comparison: HPKP . . . . . . . . . . . . . . . . . . . . 15 86 6.2. Comparison: TACK . . . . . . . . . . . . . . . . . . . . 17 87 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 18 88 7.1. Mint Fork . . . . . . . . . . . . . . . . . . . . . . . . 19 89 7.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . 19 90 7.1.2. Description . . . . . . . . . . . . . . . . . . . . . 19 91 7.1.3. Level of Maturity . . . . . . . . . . . . . . . . . . 19 92 7.1.4. Coverage . . . . . . . . . . . . . . . . . . . . . . 19 93 7.1.5. Version Compatibility . . . . . . . . . . . . . . . . 19 94 7.1.6. Licensing . . . . . . . . . . . . . . . . . . . . . . 19 95 7.1.7. Contact Information . . . . . . . . . . . . . . . . . 19 96 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 97 8.1. Trust on First Use (TOFU) and MITM Attacks . . . . . . . 19 98 8.2. Pervasive Monitoring . . . . . . . . . . . . . . . . . . 20 99 8.3. Server-Side Error Detection . . . . . . . . . . . . . . . 20 100 8.4. Client Policy and SSL Proxies . . . . . . . . . . . . . . 20 101 8.5. Client-Side Error Behavior . . . . . . . . . . . . . . . 20 102 8.6. Stolen and Forged Tickets . . . . . . . . . . . . . . . . 21 103 8.7. Client Privacy . . . . . . . . . . . . . . . . . . . . . 21 104 8.8. Ticket Protection Key Management . . . . . . . . . . . . 21 105 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 106 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 107 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 108 11.1. Normative References . . . . . . . . . . . . . . . . . . 22 109 11.2. Informative References . . . . . . . . . . . . . . . . . 23 110 Appendix A. Document History . . . . . . . . . . . . . . . . . . 25 111 A.1. draft-sheffer-tls-pinning-ticket-08 . . . . . . . . . . . 25 112 A.2. draft-sheffer-tls-pinning-ticket-07 . . . . . . . . . . . 25 113 A.3. draft-sheffer-tls-pinning-ticket-06 . . . . . . . . . . . 25 114 A.4. draft-sheffer-tls-pinning-ticket-05 . . . . . . . . . . . 25 115 A.5. draft-sheffer-tls-pinning-ticket-04 . . . . . . . . . . . 25 116 A.6. draft-sheffer-tls-pinning-ticket-03 . . . . . . . . . . . 25 117 A.7. draft-sheffer-tls-pinning-ticket-02 . . . . . . . . . . . 25 118 A.8. draft-sheffer-tls-pinning-ticket-01 . . . . . . . . . . . 26 119 A.9. draft-sheffer-tls-pinning-ticket-00 . . . . . . . . . . . 26 120 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 122 1. Introduction 124 The global PKI system relies on the trust of a CA issuing 125 certificates. As a result, a corrupted trusted CA may issue a 126 certificate for any organization without the organization's approval 127 (a misissued or "fake" certificate), and use the certificate to 128 impersonate the organization. There are many attempts to resolve 129 these weaknesses, including Certificate Transparency (CT) [RFC6962], 130 HTTP Public Key Pinning (HPKP) [RFC7469], and TACK 131 [I-D.perrin-tls-tack]. CT requires cooperation of a large portion of 132 the hundreds of extant certificate authorities (CAs) before it can be 133 used "for real", in enforcing mode. It is noted that the relevant 134 industry forum (CA/Browser Forum) is indeed pushing for such 135 extensive adoption. TACK has some similarities to the current 136 proposal, but work on it seems to have stalled. Section 6.2 compares 137 our proposal to TACK. 139 HPKP is an IETF standard, but so far has proven hard to deploy. HPKP 140 pins (fixes) a public key, one of the public keys listed in the 141 certificate chain. As a result, HPKP needs to be coordinated with 142 the certificate management process. Certificate management impacts 143 HPKP and thus increases the probability of HPKP failures. This risk 144 is made even higher given the fact that, even though work has been 145 done at the ACME WG to automate certificate management, in many or 146 even most cases, certificates are still managed manually. As a 147 result, HPKP cannot be completely automated resulting in error-prone 148 manual configuration. Such errors could prevent the web server from 149 being accessed by some clients. In addition, HPKP uses a HTTP header 150 which makes this solution HTTPS specific and not generic to TLS. On 151 the other hand, the current document provides a solution that is 152 independent of the server's certificate management and that can be 153 entirely and easily automated. Section 6.1 compares HPKP to the 154 current draft in more detail. 156 The ticket pinning proposal augments these mechanisms with a much 157 easier to implement and deploy solution for server identity pinning, 158 by reusing some of the ideas behind TLS session resumption. 160 Ticket pinning is a second factor server authentication method and is 161 not proposed as a substitute of the authentication method provided in 162 the TLS key exchange. More specifically, the client only uses the 163 pinning identity method after the TLS key exchange is successfully 164 completed. In other words, the pinning identity method is only 165 performed over an authenticated TLS session. Note that Ticket 166 Pinning does not pin certificate information and as such should be 167 considered a "real" independent second factor authentication. 169 Ticket pinning is a Trust On First Use (TOFU) mechanism, in that the 170 first server authentication is only based on PKI certificate 171 validation, but for any follow-on sessions, the client is further 172 ensuring the server's identity based on the server's ability to 173 decrypt the ticket, in addition to normal PKI certificate 174 authentication. 176 During initial TLS session establishment, the client requests a 177 pinning ticket from the server. Upon receiving the request the 178 server generates a pinning secret which is expected to be 179 unpredictable for peers other than the client or the server. In our 180 case, the pinning secret is generated from parameters exchanged 181 during the TLS key exchange, so client and server can generate it 182 locally and independently. The server constructs the pinning ticket 183 with the necessary information to retrieve the pinning secret. The 184 server then encrypts the ticket and returns the pinning ticket to the 185 client with an associated pinning lifetime. 187 The pinning lifetime value indicates for how long the server promises 188 to retain the server-side ticket-encryption key, which allows it to 189 complete the protocol exchange correctly and prove its identity. The 190 committed lifetime is typically on the order of weeks. 192 Once the key exchange is completed and the server is deemed 193 authenticated, the client generates locally the pinning secret and 194 caches the server's identifiers to index the pinning secret as well 195 as the pinning ticket and its associated lifetime. 197 When the client re-establishes a new TLS session with the server, it 198 sends the pinning ticket to the server. Upon receiving it, the 199 server returns a proof of knowledge of the pinning secret. Once the 200 key exchange is completed and the server has been authenticated, the 201 client checks the pinning proof returned by the server using the 202 client's stored pinning secret. If the proof matches, the client can 203 conclude that the server it is currently connecting to is in fact the 204 correct server. 206 This version of the draft only applies to TLS 1.3. We believe that 207 the idea can also be back-fitted into earlier versions of the 208 protocol, but this would require significant changes. One example is 209 that TLS 1.2 and earlier versions do not provide a generic facility 210 of encrypted handshake extensions, such as is used here to transport 211 the ticket. 213 The main advantages of this protocol over earlier pinning solutions 214 are: 216 - The protocol is at the TLS level, and as a result is not 217 restricted to HTTP at the application level. 219 - The protocol is robust to server IP, CA, and public key changes. 220 The server is characterized by the ownership of the pinning 221 protection key, which is never provided to the client. Server 222 configuration parameters such as the CA and the public key may 223 change without affecting the pinning ticket protocol. 225 - Once a single parameter is configured (the ticket's lifetime), 226 operation is fully automated. The server administrator need not 227 bother with the management of backup certificates or explicit 228 pins. 230 - For server clusters, we reuse the existing [RFC5077] 231 infrastructure where it exists. 233 - Pinning errors, presumably resulting from MITM attacks, can be 234 detected both by the client and the server. This allows for 235 server-side detection of MITM attacks using large-scale analytics, 236 and with no need to rely on clients to explicitly report the 237 error. 239 A note on terminology: unlike other solutions in this space, we do 240 not do "certificate pinning" (or "public key pinning"), since the 241 protocol is oblivious to the server's certificate. We prefer the 242 term "server identity pinning" for this new solution. In our 243 solution, the server proves its identity by generating a proof that 244 it can read and decrypt an encrypted ticket. As a result, the 245 identity proof relies on proof of ownership of the pinning protection 246 key. However, this key is never exchanged with the client or known 247 by it, and so cannot itself be pinned. 249 1.1. Conventions used in this document 251 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 252 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 253 document are to be interpreted as described in [RFC2119]. 255 2. Protocol Overview 257 The protocol consists of two phases: the first time a particular 258 client connects to a server, and subsequent connections. 260 This protocol supports full TLS handshakes, as well as 0-RTT 261 handshakes. Below we present it in the context of a full handshake, 262 but behavior in 0-RTT handshakes should be identical. 264 The document presents some similarities with the ticket resumption 265 mechanism described in [RFC5077]. However the scope of this document 266 differs from session resumption mechanisms implemented with [RFC5077] 267 or with other mechanisms. Specifically, the pinning ticket does not 268 carry any state associated with a TLS session and thus cannot be used 269 for session resumption, or to authenticate the client. Instead, the 270 pinning ticket only contains the Pinning Secret used to generate the 271 proof. 273 With TLS 1.3, session resumption is based on a preshared key (PSK). 274 This is orthogonal to this protocol. With TLS 1.3, a TLS session can 275 be established using PKI and a pinning ticket, and later resumed with 276 PSK. 278 However, the protocol described in this document addresses the 279 problem of misissued certificates. Thus, it is not expected to be 280 used outside a certificate-based TLS key exchange, such as in PSK. 281 As a result, PSK handshakes MUST NOT include the extension defined 282 here. 284 2.1. Initial Connection 286 When a client first connects to a server, it requests a pinning 287 ticket by sending an empty PinningTicket extension, and receives it 288 as part of the server's first response, in the returned PinningTicket 289 extension. 291 Client Server 293 ClientHello 294 + key_share 295 + signature_algorithms* 296 + PinningTicket --------> 297 ServerHello 298 + key_share 299 {EncryptedExtensions 300 + PinningTicket} 301 {CertificateRequest*} 302 {Certificate*} 303 {CertificateVerify*} 304 <-------- {Finished} 305 {Certificate*} 306 {CertificateVerify*} 307 {Finished} --------> 308 [Application Data] <-------> [Application Data] 310 * Indicates optional or situation-dependent 311 messages that are not always sent. 313 {} Indicates messages protected using keys 314 derived from the ephemeral secret. 316 [] Indicates messages protected using keys 317 derived from the master secret. 319 If a client supports the pinning ticket extension and does not have 320 any pinning ticket associated with the server, the exchange is 321 considered as an initial connection. Other reasons the client may 322 not have a pinning ticket include the client having flushed its 323 pinning ticket store, or the committed lifetime of the pinning ticket 324 having expired. 326 Upon receipt of the PinningTicket extension, the server computes a 327 pinning secret (Section 4.1), and sends the pinning ticket 328 (Section 4.2) encrypted with the pinning protection key 329 (Section 4.3). The pinning ticket is associated with a lifetime 330 value by which the server assumes the responsibility of retaining the 331 pinning protection key and being able to decrypt incoming pinning 332 tickets during the period indicated by the committed lifetime. 334 Once the pinning ticket has been generated, the server returns the 335 pinning ticket and the committed lifetime in a PinningTicket 336 extension embedded in the EncryptedExtensions message. We note that 337 a PinningTicket extension MUST NOT be sent as part of a 338 HelloRetryRequest. 340 Upon receiving the pinning ticket, the client MUST NOT accept it 341 until the key exchange is completed and the server authenticated. If 342 the key exchange is not completed successfully, the client MUST 343 ignore the received pinning ticket. Otherwise, the client computes 344 the pinning secret and SHOULD cache the pinning secret and the 345 pinning ticket for the duration indicated by the pinning ticket 346 lifetime. The client SHOULD clean up the cached values at the end of 347 the indicated lifetime. 349 2.2. Subsequent Connections 351 When the client initiates a connection to a server it has previously 352 seen (see Section 2.3 on identifying servers), it SHOULD send the 353 pinning ticket for that server. The pinning ticket, pinning secret 354 and pinning ticket lifetime computed during the establishment of the 355 previous TLS session are designated in this document as the 356 "original" ones, to distinguish them from a new ticket that may be 357 generated during the current session. 359 The server MUST extract the original pinning_secret value from the 360 ticket and MUST respond with a PinningTicket extension, which 361 includes: 363 - A proof that the server can understand the ticket that was sent by 364 the client; this proof also binds the pinning ticket to the 365 server's (current) public key, as well as the ongoing TLS session. 366 The proof is MANDATORY if a pinning ticket was sent by the client. 368 - A fresh pinning ticket. The main reason for refreshing the ticket 369 on each connection is privacy: to avoid the ticket serving as a 370 fixed client identifier. It is RECOMMENDED to include a fresh 371 ticket with each response. 373 If the server cannot validate the received ticket, that might 374 indicate an earlier MITM attack on this client. The server MUST then 375 abort the connection with a handshake_failure alert, and SHOULD log 376 this failure. 378 The client MUST verify the proof, and if it fails to do so, MUST 379 issue a handshake_failure alert and abort the connection (see also 380 Section 8.5). It is important that the client does not attempt to 381 "fall back" by omitting the PinningTicket extension. 383 When the connection is successfully set up, i.e. after the Finished 384 message is verified, the client SHOULD store the new ticket along 385 with the corresponding pinning_secret, replacing the original ticket. 387 Although this is an extension, if the client already has a ticket for 388 a server, the client MUST interpret a missing PinningTicket extension 389 in the server's response as an attack, because of the server's prior 390 commitment to respect the ticket. The client MUST abort the 391 connection in this case. See also Section 5.5 on ramping down 392 support for this extension. 394 2.3. Indexing the Pins 396 Each pin is associated with a host name, protocol (TLS or DTLS) and 397 port number. In other words, the pin for port TCP/443 may be 398 different from that for DTLS or from the pin for port TCP/8443. The 399 host name MUST be the value sent inside the Server Name Indication 400 (SNI) extension. This definition is similar to a Web Origin 401 [RFC6454], but does not assume the existence of a URL. 403 The purpose of ticket pinning is to pin the server identity. As a 404 result, any information orthogonal to the server's identity MUST NOT 405 be considered in indexing. More particularly, IP addresses are 406 ephemeral and forbidden in SNI and therefore pins MUST NOT be 407 associated with IP addresses. Similarly, CA names or public keys 408 associated with server MUST NOT be used for indexing as they may 409 change over time. 411 3. Message Definitions 413 This section defines the format of the PinningTicket extension. We 414 follow the message notation of [RFC8446]. 416 opaque pinning_ticket<0..2^16-1>; 418 opaque pinning_proof<0..2^8-1>; 420 struct { 421 select (Role) { 422 case client: 423 pinning_ticket ticket<0..2^16-1>; //omitted on 1st connection 425 case server: 426 pinning_proof proof<0..2^8-1>; //no proof on 1st connection 427 pinning_ticket ticket<0..2^16-1>; //omitted on ramp down 428 uint32 lifetime; 429 } 430 } PinningTicketExtension; 432 ticket a pinning ticket sent by the client or returned by the 433 server. The ticket is opaque to the client. The extension MUST 434 contain exactly 0 or 1 tickets. 436 proof a demonstration by the server that it understands the received 437 ticket and therefore that it is in possession of the secret that 438 was used to generate it originally. The extension MUST contain 439 exactly 0 or 1 proofs. 441 lifetime the duration (in seconds) that the server commits to accept 442 offered tickets in the future. 444 4. Cryptographic Operations 446 This section provides details on the cryptographic operations 447 performed by the protocol peers. 449 4.1. Pinning Secret 451 The pinning secret is generated locally by the client and the server 452 which means they must use the same inputs to generate it. This value 453 must be generated before the ServerHello message is sent, as the 454 server includes the corresponding pinning ticket in the ServerHello 455 message. In addition, the pinning secret must be unpredictable to 456 any party other than the client and the server. 458 The pinning secret is derived using the Derive-Secret function 459 provided by TLS 1.3, described in Section "Key Schedule" of 460 [RFC8446]. 462 pinning secret = Derive-Secret(Handshake Secret, "pinning secret", 463 ClientHello...ServerHello) 465 4.2. Pinning Ticket 467 The pinning ticket contains the pinning secret. The pinning ticket 468 is provided by the client to the server which decrypts it in order to 469 extract the pinning secret and responds with a pinning proof. As a 470 result, the characteristics of the pinning ticket are: 472 - Pinning tickets MUST be encrypted and integrity-protected using 473 strong cryptographic algorithms. 475 - Pinning tickets MUST be protected with a long-term pinning 476 protection key. 478 - Pinning tickets MUST include a pinning protection key ID or serial 479 number as to enable the pinning protection key to be refreshed. 481 - The pinning ticket MAY include other information, in addition to 482 the pinning secret. 484 The pinning ticket's format is not specified by this document, but we 485 RECOMMEND a format similar to the one proposed by [RFC5077]. 487 4.3. Pinning Protection Key 489 The pinning protection key is only used by the server and so remains 490 server implementation specific. [RFC5077] recommends the use of two 491 keys, but when using AEAD algorithms only a single key is required. 493 When a single server terminates TLS for multiple virtual servers 494 using the Server Name Indication (SNI) mechanism, we strongly 495 RECOMMEND to use a separate protection key for each one of them, in 496 order to allow migrating virtual servers between different servers 497 while keeping pinning active. 499 As noted in Section 5.1, if the server is actually a cluster of 500 machines, the protection key MUST be synchronized between all the 501 nodes that accept TLS connections to the same server name. When 502 [RFC5077] is deployed, an easy way to do it is to derive the 503 protection key from the session-ticket protection key, which is 504 already synchronized. For example: 506 pinning_protection_key = HKDF-Expand(resumption_protection_key, 507 "pinning protection", L) 509 4.4. Pinning Proof 511 The pinning proof is sent by the server to demonstrate that it has 512 been able to decrypt the pinning ticket and retrieve the pinning 513 secret. The proof must be unpredictable and must not be replayed. 514 Similarly to the pinning secret, the pinning proof is sent by the 515 server in the ServerHello message. In addition, it must not be 516 possible for a MITM server with a fake certificate to obtain a 517 pinning proof from the original server. 519 In order to address these requirements, the pinning proof is bound to 520 the TLS session as well as the public key of the server: 522 proof = HMAC(original_pinning_secret, "pinning proof" + 523 Handshake-Secret + Hash(server_public_key)) 525 where HMAC [RFC2104] uses the Hash algorithm that was negotiated in 526 the handshake, and the same hash is also used over the server's 527 public key. The original_pinning_secret value refers to the secret 528 value extracted from the ticket sent by the client, to distinguish it 529 from a new pinning secret value that is possibly computed in the 530 current exchange. The server_public_key value is the DER 531 representation of the public key, specifically the 532 SubjectPublicKeyInfo structure as-is. 534 5. Operational Considerations 536 The main motivation behind the current protocol is to enable identity 537 pinning without the need for manual operations. Manual operations 538 are susceptible to human error and in the case of public key pinning, 539 can easily result in "server bricking": the server becoming 540 inaccessible to some or all of its users. To achieve this goal 541 operations described in identity pinning are only performed within 542 the current TLS session, and there is no dependence on any TLS 543 configuration parameters such as CA identity or public keys. As a 544 result, configuration changes are unlikely to lead to desynchronized 545 state between the client and the server. 547 5.1. Protection Key Synchronization 549 The only operational requirement when deploying this protocol is that 550 if the server is part of a cluster, protection keys (the keys used to 551 encrypt tickets) MUST be synchronized between all cluster members. 552 The protocol is designed so that if resumption ticket protection keys 553 [RFC5077] are already synchronized between cluster members, nothing 554 more needs to be done. 556 Moreover, synchronization does not need to be instantaneous, e.g. 557 protection keys can be distributed a few minutes or hours in advance 558 of their rollover. In such scenarios, each cluster member MUST be 559 able to accept tickets protected with a new version of the protection 560 key, even while it is still using an old version to generate keys. 561 This ensures that a client that receives a "new" ticket does not next 562 hit a cluster member that still rejects this ticket. 564 Misconfiguration can lead to the server's clock being off by a large 565 amount of time. Therefore we RECOMMEND never to automatically delete 566 protection keys, even when they are long expired. The decision to 567 delete a key should at least consider the largest value of the ticket 568 lifetime as well as the expected time desynchronisation between the 569 servers of the cluster and the time difference for distributing the 570 new key among the different servers in the cluster. 572 5.2. Ticket Lifetime 574 The lifetime of the ticket is a commitment by the server to retain 575 the ticket's corresponding protection key for this duration, so that 576 the server can prove to the client that it knows the secret embedded 577 in the ticket. For production systems, the lifetime SHOULD be 578 between 7 and 31 days. 580 5.3. Certificate Renewal 582 The protocol ensures that the client will continue speaking to the 583 correct server even when the server's certificate is renewed. In 584 this sense, we are not "pinning certificates" and the protocol should 585 more precisely be called "server identity pinning". 587 Note that this property is not impacted by the use of the server's 588 public key in the pinning proof, because the scope of the public key 589 used is only the current TLS session. 591 5.4. Certificate Revocation 593 The protocol is orthogonal to certificate validation in the sense 594 that, if the server's certificate has been revoked or is invalid for 595 some other reason, the client MUST refuse to connect to it regardless 596 of any ticket-related behavior. 598 5.5. Disabling Pinning 600 A server implementing this protocol MUST have a "ramp down" mode of 601 operation where: 603 - The server continues to accept valid pinning tickets and responds 604 correctly with a proof. 606 - The server does not send back a new pinning ticket. 608 After a while no clients will hold valid tickets any more and the 609 feature may be disabled. Note that clients that do not receive a new 610 pinning ticket do not remove the original ticket. Instead, the 611 client keeps on using the ticket until its lifetime expires. 613 Issuing a new pinning ticket with a shorter lifetime would only delay 614 the ramp down process, as the shorter lifetime can only affect 615 clients that actually initiated a new connection. Other clients 616 would still see the original lifetime for their pinning tickets. 618 5.6. Server Compromise 620 If a server compromise is detected, the pinning protection key MUST 621 be rotated immediately, but the server MUST still accept valid 622 tickets that use the old, compromised key. Clients that still hold 623 old pinning tickets will remain vulnerable to MITM attacks, but those 624 that connect to the correct server will immediately receive new 625 tickets protected with the newly generated pinning protection key. 627 The same procedure applies if the pinning protection key is 628 compromised directly, e.g. if a backup copy is inadvertently made 629 public. 631 5.7. Disaster Recovery 633 All web servers in production need to be backed up, so that they can 634 be recovered if a disaster (including a malicious activity) ever 635 wipes them out. Backup often includes the certificate and its 636 private key, which must be backed up securely. The pinning secret, 637 including earlier versions that are still being accepted, must be 638 backed up regularly. However since it is only used as an 639 authentication second factor, it does not require the same level of 640 confidentiality as the server's private key. 642 Readers should note that [RFC5077] session resumption keys are more 643 security sensitive, and should normally not be backed up but rather 644 treated as ephemeral keys. Even when servers derive pinning secrets 645 from resumption keys (Section 4.1), they MUST NOT back up resumption 646 keys. 648 6. Previous Work 650 This section compares ticket pinning to two earlier proposals, HPKP 651 and TACK. 653 6.1. Comparison: HPKP 655 The current IETF standard for pinning the identity of web servers is 656 the Public Key Pinning Extension for HTTP, or HPKP [RFC7469]. 658 The main differences between HPKP and the current document are the 659 following: 661 - HPKP limits its scope to HTTPS, while the current document 662 considers all application above TLS. 664 - HPKP pins the public key of the server (or another public key 665 along the certificate chain) and as such is highly dependent on 666 the management of certificates. Such dependency increases the 667 potential error surface, especially as certificate management is 668 not yet largely automated. The current proposal, on the other 669 hand is independent of certificate management. 671 - HPKP pins public keys which are public and used for the standard 672 TLS authentication. Identity pinning relies on the ownership of 673 the pinning key which is not disclosed to the public and not 674 involved in the standard TLS authentication. As a result, 675 identity pinning is a completely independent second factor 676 authentication mechanism. 678 - HPKP relies on a backup key to recover the mis-issuance of a key. 679 We believe such backup mechanisms add excessive complexity and 680 cost. Reliability of the current mechanism is primarily based on 681 its being highly automated. 683 - HPKP relies on the client to report errors to the report-uri. The 684 current document not need any out-of band mechanism, and the 685 server is informed automatically. This provides an easier and 686 more reliable health monitoring. 688 On the other hand, HPKP shares the following aspects with identity 689 pinning: 691 - Both mechanisms provide hard failure. With HPKP only the client 692 is aware of the failure, while with the current proposal both 693 client and server are informed of the failure. This provides room 694 for further mechanisms to automatically recover such failures. 696 - Both mechanisms are subject to a server compromise in which users 697 are provided with an invalid ticket (e.g. a random one) or HTTP 698 Header, with a very long lifetime. For identity pinning, this 699 lifetime SHOULD NOT be longer than 31 days. In both cases, 700 clients will not be able to reconnect the server during this 701 lifetime. With the current proposal, an attacker needs to 702 compromise the TLS layer, while with HPKP, the attacker needs to 703 compromise the HTTP server. Arguably, the TLS-level compromise is 704 typically more difficult for the attacker. 706 Unfortunately HPKP has not seen wide deployment yet. As of March 707 2016, the number of servers using HPKP was less than 3000 [Netcraft]. 708 This may simply be due to inertia, but we believe the main reason is 709 the interactions between HPKP and manual certificate management which 710 is needed to implement HPKP for enterprise servers. The penalty for 711 making mistakes (e.g. being too early or too late to deploy new pins) 712 is having the server become unusable for some of the clients. 714 To demonstrate this point, we present a list of the steps involved in 715 deploying HPKP on a security-sensitive Web server. 717 1. Generate two public/private key-pairs on a computer that is not 718 the Live server. The second one is the "backup1" key-pair. 720 "openssl genrsa -out "example.com.key" 2048;" 722 "openssl genrsa -out "example.com.backup1.key" 2048;" 724 2. Generate hashes for both of the public keys. These will be used 725 in the HPKP header: 727 "openssl rsa -in "example.com.key" -outform der -pubout | 728 openssl dgst -sha256 -binary | openssl enc -base64" 730 "openssl rsa -in "example.com.backup1.key" -outform der 731 -pubout | openssl dgst -sha256 -binary | openssl enc -base64" 733 3. Generate a single CSR (Certificate Signing Request) for the 734 first key-pair, where you include the domain name in the CN 735 (Common Name) field: 737 "openssl req -new -subj "/C=GB/ST=Area/L=Town/O=Company/ 738 CN=example.com" -key "example.com.key" -out "example.com.csr";" 740 4. Send this CSR to the CA (Certificate Authority), and go though 741 the dance to prove you own the domain. The CA will give you 742 back a single certificate that will typically expire within a 743 year or two. 745 5. On the Live server, upload and setup the first key-pair (and its 746 certificate). At this point you can add the "Public-Key-Pins" 747 header, using the two hashes you created in step 2. 749 Note that only the first key-pair has been uploaded to the 750 server so far. 752 6. Store the second (backup1) key-pair somewhere safe, probably 753 somewhere encrypted like a password manager. It won't expire, 754 as it's just a key-pair, it just needs to be ready for when you 755 need to get your next certificate. 757 7. Time passes... probably just under a year (if waiting for a 758 certificate to expire), or maybe sooner if you find that your 759 server has been compromised and you need to replace the key-pair 760 and certificate. 762 8. Create a new CSR (Certificate Signing Request) using the 763 "backup1" key-pair, and get a new certificate from your CA. 765 9. Generate a new backup key-pair (backup2), get its hash, and 766 store it in a safe place (again, not on the Live server). 768 10. Replace your old certificate and old key-pair, and update the 769 "Public-Key-Pins" header to remove the old hash, and add the new 770 "backup2" key-pair. 772 Note that in the above steps, both the certificate issuance as well 773 as the storage of the backup key pair involve manual steps. Even 774 with an automated CA that runs the ACME protocol, key backup would be 775 a challenge to automate. 777 6.2. Comparison: TACK 779 Compared with HPKP, TACK [I-D.perrin-tls-tack] is a lot more similar 780 to the current draft. It can even be argued that this document is a 781 symmetric-cryptography variant of TACK. That said, there are still a 782 few significant differences: 784 - Probably the most important difference is that with TACK, 785 validation of the server certificate is no longer required, and in 786 fact TACK specifies it as a "MAY" requirement (Sec. 5.3). With 787 ticket pinning, certificate validation by the client remains a 788 MUST requirement, and the ticket acts only as a second factor. If 789 the pinning secret is compromised, the server's security is not 790 immediately at risk. 792 - Both TACK and the current draft are mostly orthogonal to the 793 server certificate as far as their life cycle, and so both can be 794 deployed with no manual steps. 796 - TACK uses ECDSA to sign the server's public key. This allows 797 cooperating clients to share server assertions between themselves. 798 This is an optional TACK feature, and one that cannot be done with 799 pinning tickets. 801 - TACK allows multiple servers to share its public keys. Such 802 sharing is disallowed by the current document. 804 - TACK does not allow the server to track a particular client, and 805 so has better privacy properties than the current draft. 807 - TACK has an interesting way to determine the pin's lifetime, 808 setting it to the time period since the pin was first observed, 809 with a hard upper bound of 30 days. The current draft makes the 810 lifetime explicit, which may be more flexible to deploy. For 811 example, Web sites which are only visited rarely by users may opt 812 for a longer period than other sites that expect users to visit on 813 a daily basis. 815 7. Implementation Status 817 Note to RFC Editor: please remove this section before publication, 818 including the reference to [RFC7942]. 820 This section records the status of known implementations of the 821 protocol defined by this specification at the time of posting of this 822 Internet-Draft, and is based on a proposal described in [RFC7942]. 823 The description of implementations in this section is intended to 824 assist the IETF in its decision processes in progressing drafts to 825 RFCs. Please note that the listing of any individual implementation 826 here does not imply endorsement by the IETF. Furthermore, no effort 827 has been spent to verify the information presented here that was 828 supplied by IETF contributors. This is not intended as, and must not 829 be construed to be, a catalog of available implementations or their 830 features. Readers are advised to note that other implementations may 831 exist. 833 According to RFC 7942, "this will allow reviewers and working groups 834 to assign due consideration to documents that have the benefit of 835 running code, which may serve as evidence of valuable experimentation 836 and feedback that have made the implemented protocols more mature. 837 It is up to the individual working groups to use this information as 838 they see fit". 840 7.1. Mint Fork 842 7.1.1. Overview 844 A fork of the Mint TLS 1.3 implementation, developed by Yaron Sheffer 845 and available at https://github.com/yaronf/mint. 847 7.1.2. Description 849 This is a fork of the TLS 1.3 implementation, and includes client and 850 server code. In addition to the actual protocol, several utilities 851 are provided allowing to manage pinning protection keys on the server 852 side, and pinning tickets on the client side. 854 7.1.3. Level of Maturity 856 This is a prototype. 858 7.1.4. Coverage 860 The entire protocol is implemented. 862 7.1.5. Version Compatibility 864 The implementation is compatible with draft-sheffer-tls-pinning- 865 ticket-02. 867 7.1.6. Licensing 869 Mint itself and this fork are available under an MIT license. 871 7.1.7. Contact Information 873 See author details below. 875 8. Security Considerations 877 This section reviews several security aspects related to the proposed 878 extension. 880 8.1. Trust on First Use (TOFU) and MITM Attacks 882 This protocol is a "trust on first use" protocol. If a client 883 initially connects to the "right" server, it will be protected 884 against MITM attackers for the lifetime of each received ticket. If 885 it connects regularly (depending of course on the server-selected 886 lifetime), it will stay constantly protected against fake 887 certificates. 889 However if it initially connects to an attacker, subsequent 890 connections to the "right" server will fail. Server operators might 891 want to advise clients on how to remove corrupted pins, once such 892 large scale attacks are detected and remediated. 894 The protocol is designed so that it is not vulnerable to an active 895 MITM attacker who has real-time access to the original server. The 896 pinning proof includes a hash of the server's public key, to ensure 897 the client that the proof was in fact generated by the server with 898 which it is initiating the connection. 900 8.2. Pervasive Monitoring 902 Some organizations, and even some countries perform pervasive 903 monitoring on their constituents [RFC7258]. This often takes the 904 form of always-active SSL proxies. Because of the TOFU property, 905 this protocol does not provide any security in such cases. 907 8.3. Server-Side Error Detection 909 Uniquely, this protocol allows the server to detect clients that 910 present incorrect tickets and therefore can be assumed to be victims 911 of a MITM attack. Server operators can use such cases as indications 912 of ongoing attacks, similarly to fake certificate attacks that took 913 place in a few countries in the past. 915 8.4. Client Policy and SSL Proxies 917 Like it or not, some clients are normally deployed behind an SSL 918 proxy. Similarly to [RFC7469], it is acceptable to allow pinning to 919 be disabled for some hosts according to local policy. For example, a 920 UA MAY disable pinning for hosts whose validated certificate chain 921 terminates at a user-defined trust anchor, rather than a trust anchor 922 built-in to the UA (or underlying platform). Moreover, a client MAY 923 accept an empty PinningTicket extension from such hosts as a valid 924 response. 926 8.5. Client-Side Error Behavior 928 When a client receives a malformed or empty PinningTicket extension 929 from a pinned server, it MUST abort the handshake and MUST NOT retry 930 with no PinningTicket in the request. Doing otherwise would expose 931 the client to trivial fallback attacks, similar to those described in 932 [RFC7507]. 934 This rule can however have negative affects on clients that move from 935 behind SSL proxies into the open Internet and vice versa, if the 936 advice in Section 8.4 is not followed. Therefore, we RECOMMEND that 937 browser and library vendors provide a documented way to remove stored 938 pins. 940 8.6. Stolen and Forged Tickets 942 Stealing pinning tickets even in conjunction with other pinning 943 parameters, such as the associated pinning secret, provides no 944 benefit to the attacker since pinning tickets are used to secure the 945 client rather than the server. Similarly, it is useless to forge a 946 ticket for a particular sever. 948 8.7. Client Privacy 950 This protocol is designed so that an external attacker cannot 951 correlate between different requests of a single client, provided the 952 client requests and receives a fresh ticket upon each connection. 954 On the other hand, the server to which the client is connecting can 955 easily track the client. This may be an issue when the client 956 expects to connect to the server (e.g., a mail server) with multiple 957 identities. Implementations SHOULD allow the user to opt out of 958 pinning, either in general or for particular servers. 960 8.8. Ticket Protection Key Management 962 While the ticket format is not mandated by this document, we 963 RECOMMEND using authenticated encryption to protect it. Some of the 964 algorithms commonly used for authenticated encryption, e.g. GCM, are 965 highly vulnerable to nonce reuse, and this problem is magnified in a 966 cluster setting. Therefore implementations that choose AES-128-GCM 967 MUST adopt one of these three alternatives: 969 - Partition the nonce namespace between cluster members and use 970 monotonic counters on each member, e.g. by setting the nonce to 971 the concatenation of the cluster member ID and an incremental 972 counter. 974 - Generate random nonces but avoid the so-called birthday bound, 975 i.e. never generate more than 2**64 encrypted tickets for the 976 same ticket pinning protection Key. 978 - An alternative design which has been attributed to Karthik 979 Bhargavan is as follows. Start with a 128-bit master key 980 "K_master" and then for each encryption, generate a 256-bit random 981 nonce and compute: K = HKDF(K_master, Nonce || "key"), then N = 982 HKDF(K_master, Nonce || "nonce"). Use these values to encrypt the 983 ticket, AES-GCM(K, N, data). This nonce should then be stored and 984 transmitted with the ticket. 986 9. IANA Considerations 988 IANA is requested to allocate a TicketPinning extension value in the 989 TLS ExtensionType Registry. 991 [RFC8447] defines the procedure and requirements and the necessary 992 information for the IANA to update the "TLS ExtensionType Values" 993 registry [TLS-EXT]. 995 According to [RFC8447] the update of the "TLS ExtensionType Values" 996 registry is "Specification Required" [RFC8126] which is fulfilled by 997 the current document, when it is published as an RFC. 999 The TicketPinning Extension is not limited to Private use and as such 1000 the TicketPinning Extension Value is expected to have its first byte 1001 in the range 0-254. A value of 26 would address this requirement. 1003 The TicketPinning Extension Name is expected to be ticket_pinning. 1005 The TicketPinning Extension Recommended value should be set to "No" 1006 with the publication of the current document as "Experimental". 1008 The TicketPinning Extension TLS.13 column should be set to CH, SH to 1009 indicate that the TicketPinning Extension is present in ClientHello 1010 and ServerHello messages. 1012 10. Acknowledgements 1014 The original idea behind this proposal was published in [Oreo] by 1015 Moti Yung, Benny Pinkas and Omer Berkman. The current protocol is 1016 but a distant relative of the original Oreo protocol, and any errors 1017 are the draft authors' alone. 1019 We would like to thank Dave Garrett, Daniel Kahn Gillmor, Yoav Nir, 1020 Eric Rescorla and Rich Salz for their comments on this draft. 1021 Special thanks to Craig Francis for contributing the HPKP deployment 1022 script, and to Ralph Holz for several fruitful discussions. 1024 11. References 1026 11.1. Normative References 1028 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1029 Requirement Levels", BCP 14, RFC 2119, 1030 DOI 10.17487/RFC2119, March 1997, 1031 . 1033 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 1034 "Transport Layer Security (TLS) Session Resumption without 1035 Server-Side State", RFC 5077, DOI 10.17487/RFC5077, 1036 January 2008, . 1038 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1039 Writing an IANA Considerations Section in RFCs", BCP 26, 1040 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1041 . 1043 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1044 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1045 . 1047 [RFC8447] Salowey, J. and S. Turner, "IANA Registry Updates for TLS 1048 and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018, 1049 . 1051 11.2. Informative References 1053 [I-D.perrin-tls-tack] 1054 Marlinspike, M., "Trust Assertions for Certificate Keys", 1055 draft-perrin-tls-tack-02 (work in progress), January 2013. 1057 [Netcraft] 1058 Mutton, P., "HTTP Public Key Pinning: You're doing it 1059 wrong!", March 2016, 1060 . 1063 [Oreo] Berkman, O., Pinkas, B., and M. Yung, "Firm Grip 1064 Handshakes: A Tool for Bidirectional Vouching", Cryptology 1065 and Network Security, pp. 142-157 , 2012. 1067 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1068 Hashing for Message Authentication", RFC 2104, 1069 DOI 10.17487/RFC2104, February 1997, 1070 . 1072 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, 1073 DOI 10.17487/RFC6454, December 2011, 1074 . 1076 [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate 1077 Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, 1078 . 1080 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 1081 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 1082 2014, . 1084 [RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning 1085 Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April 1086 2015, . 1088 [RFC7507] Moeller, B. and A. Langley, "TLS Fallback Signaling Cipher 1089 Suite Value (SCSV) for Preventing Protocol Downgrade 1090 Attacks", RFC 7507, DOI 10.17487/RFC7507, April 2015, 1091 . 1093 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 1094 Code: The Implementation Status Section", BCP 205, 1095 RFC 7942, DOI 10.17487/RFC7942, July 2016, 1096 . 1098 [TLS-EXT] IANA, ., "TLS Extension Type Value", 2018, 1099 . 1103 Appendix A. Document History 1105 A.1. draft-sheffer-tls-pinning-ticket-08 1107 - ISE comments by Rich Salz. 1109 A.2. draft-sheffer-tls-pinning-ticket-07 1111 - Refer to published RFCs. 1113 A.3. draft-sheffer-tls-pinning-ticket-06 1115 - IANA Considerations in preparation for Experimental publication. 1117 A.4. draft-sheffer-tls-pinning-ticket-05 1119 - Multiple comments from Eric Rescorla. 1121 A.5. draft-sheffer-tls-pinning-ticket-04 1123 - Editorial changes. 1125 - Two-phase rotation of protection key. 1127 A.6. draft-sheffer-tls-pinning-ticket-03 1129 - Deleted redundant length fields in the extension's formal 1130 definition. 1132 - Modified cryptographic operations to align with the current state 1133 of TLS 1.3. 1135 - Numerous textual improvements. 1137 A.7. draft-sheffer-tls-pinning-ticket-02 1139 - Added an Implementation Status section. 1141 - Added lengths into the extension structure. 1143 - Changed the computation of the pinning proof to be more robust. 1145 - Clarified requirements on the length of the pinning_secret. 1147 - Revamped the HPKP section to be more in line with current 1148 practices, and added recent statistics on HPKP deployment. 1150 A.8. draft-sheffer-tls-pinning-ticket-01 1152 - Corrected the notation for variable-sized vectors. 1154 - Added a section on disaster recovery and backup. 1156 - Added a section on privacy. 1158 - Clarified the assumptions behind the HPKP procedure in the 1159 comparison section. 1161 - Added a definition of pin indexing (origin). 1163 - Adjusted to the latest TLS 1.3 notation. 1165 A.9. draft-sheffer-tls-pinning-ticket-00 1167 Initial version. 1169 Authors' Addresses 1171 Yaron Sheffer 1172 Intuit 1174 EMail: yaronf.ietf@gmail.com 1176 Daniel Migault 1177 Ericsson 1179 EMail: daniel.migault@ericsson.com