idnits 2.17.1 draft-ietf-tls-subcerts-09.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 -- The document date (26 June 2020) is 1394 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) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Barnes 3 Internet-Draft Cisco 4 Intended status: Standards Track S. Iyengar 5 Expires: 28 December 2020 Facebook 6 N. Sullivan 7 Cloudflare 8 E. Rescorla 9 Mozilla 10 26 June 2020 12 Delegated Credentials for TLS 13 draft-ietf-tls-subcerts-09 15 Abstract 17 The organizational separation between the operator of a TLS endpoint 18 and the certification authority can create limitations. For example, 19 the lifetime of certificates, how they may be used, and the 20 algorithms they support are ultimately determined by the 21 certification authority. This document describes a mechanism by 22 which operators may delegate their own credentials for use in TLS, 23 without breaking compatibility with peers that do not support this 24 specification. 26 Discussion Venues 28 This note is to be removed before publishing as an RFC. 30 Source for this draft and an issue tracker can be found at 31 https://github.com/tlswg/tls-subcerts (https://github.com/tlswg/tls- 32 subcerts). 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on 28 December 2020. 50 Copyright Notice 52 Copyright (c) 2020 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 57 license-info) in effect on the date of publication of this document. 58 Please review these documents carefully, as they describe your rights 59 and restrictions with respect to this document. Code Components 60 extracted from this document must include Simplified BSD License text 61 as described in Section 4.e of the Trust Legal Provisions and are 62 provided without warranty as described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 68 2.1. Change Log . . . . . . . . . . . . . . . . . . . . . . . 4 69 3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 5 70 3.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 6 71 3.2. Related Work . . . . . . . . . . . . . . . . . . . . . . 7 72 4. Delegated Credentials . . . . . . . . . . . . . . . . . . . . 8 73 4.1. Client and Server Behavior . . . . . . . . . . . . . . . 9 74 4.1.1. Server Authentication . . . . . . . . . . . . . . . . 9 75 4.1.2. Client Authentication . . . . . . . . . . . . . . . . 10 76 4.1.3. Validating a Delegated Credential . . . . . . . . . . 11 77 4.2. Certificate Requirements . . . . . . . . . . . . . . . . 11 78 5. Operational Considerations . . . . . . . . . . . . . . . . . 12 79 5.1. Client Clock Skew . . . . . . . . . . . . . . . . . . . . 12 80 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 81 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 82 7.1. Security of Delegated Credential's Private Key . . . . . 13 83 7.2. Re-use of Delegated Credentials in Multiple 84 Contexts . . . . . . . . . . . . . . . . . . . . . . . . 13 85 7.3. Revocation of Delegated Credentials . . . . . . . . . . . 13 86 7.4. Interactions with Session Resumption . . . . . . . . . . 13 87 7.5. Privacy Considerations . . . . . . . . . . . . . . . . . 14 88 7.6. The Impact of Signature Forgery Attacks . . . . . . . . . 14 89 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 90 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 91 9.1. Normative References . . . . . . . . . . . . . . . . . . 15 92 9.2. Informative References . . . . . . . . . . . . . . . . . 15 93 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 16 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 96 1. Introduction 98 Typically, a TLS server uses a certificate provided by some entity 99 other than the operator of the server (a "Certification Authority" or 100 CA) [RFC8446] [RFC5280]. This organizational separation makes the 101 TLS server operator dependent on the CA for some aspects of its 102 operations, for example: 104 * Whenever the server operator wants to deploy a new certificate, it 105 has to interact with the CA. 107 * The server operator can only use TLS signature schemes for which 108 the CA will issue credentials. 110 These dependencies cause problems in practice. Server operators 111 often deploy TLS termination services in locations such as remote 112 data centers or Content Delivery Networks (CDNs) where it may be 113 difficult to detect key compromises. Short-lived certificates may be 114 used to limit the exposure of keys in these cases. 116 However, short-lived certificates need to be renewed more frequently 117 than long-lived certificates. If an external CA is unable to issue a 118 certificate in time to replace a deployed certificate, the server 119 would no longer be able to present a valid certificate to clients. 120 With short-lived certificates, there is a smaller window of time to 121 renew a certificates and therefore a higher risk that an outage at a 122 CA will negatively affect the uptime of the service. 124 To reduce the dependency on external CAs, this document proposes a 125 limited delegation mechanism that allows a TLS peer to issue its own 126 credentials within the scope of a certificate issued by an external 127 CA. These credentials only enable the recipient of the delegation to 128 speak for names that the CA has authorized. For clarity, we will 129 refer to the certificate issued by the CA as a "certificate", or 130 "delegation certificate", and the one issued by the operator as a 131 "delegated credential" or "DC". 133 2. Conventions and Terminology 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 137 "OPTIONAL" in this document are to be interpreted as described in BCP 138 14 [RFC2119] [RFC8174] when, and only when, they appear in all 139 capitals, as shown here. 141 2.1. Change Log 143 (*) indicates changes to the wire protocol. 145 draft-09 147 * Address case nits 149 * Fix section bullets in 4.1.3. 151 * Add operational considerations section for clock skew 153 * Add text around using an oracle to forge DCs in the future and 154 past 156 * Add text about certificate extension vs EKU 158 draft-08 160 * Include details about the impact of signature forgery attacks 162 * Copy edits 164 * Fix section about DC reuse 166 * Incorporate feedback from Jonathan Hammell and Kevin Jacobs on the 167 list 169 draft-07 171 * Minor text improvements 173 draft-06 175 * Modified IANA section, fixed nits 177 draft-05 179 * Removed support for PKCS 1.5 RSA signature algorithms. 181 * Additional security considerations. 183 draft-04 185 * Add support for client certificates. 187 draft-03 188 * Remove protocol version from the Credential structure. (*) 190 draft-02 192 * Change public key type. (*) 194 * Change DelegationUsage extension to be NULL and define its object 195 identifier. 197 * Drop support for TLS 1.2. 199 * Add the protocol version and credential signature algorithm to the 200 Credential structure. (*) 202 * Specify undefined behavior in a few cases: when the client 203 receives a DC without indicated support; when the client indicates 204 the extension in an invalid protocol version; and when DCs are 205 sent as extensions to certificates other than the end-entity 206 certificate. 208 3. Solution Overview 210 A delegated credential is a digitally signed data structure with two 211 semantic fields: a validity interval and a public key (along with its 212 associated signature algorithm). The signature on the credential 213 indicates a delegation from the certificate that is issued to the 214 peer. The private key used to sign a credential corresponds to the 215 public key of the peer's X.509 end-entity certificate [RFC5280]. 217 A TLS handshake that uses delegated credentials differs from a 218 standard handshake in a few important ways: 220 * The initiating peer provides an extension in its ClientHello or 221 CertificateRequest that indicates support for this mechanism. 223 * The peer sending the Certificate message provides both the 224 certificate chain terminating in its certificate as well as the 225 delegated credential. 227 * The authenticating initiator uses information from the peer's 228 certificate to verify the delegated credential and that the peer 229 is asserting an expected identity. 231 * Peers accepting the delegated credential use it as the certificate 232 key for the TLS handshake 234 As detailed in Section 4, the delegated credential is 235 cryptographically bound to the end-entity certificate with which the 236 credential may be used. This document specifies the use of delegated 237 credentials in TLS 1.3 or later; their use in prior versions of the 238 protocol is not allowed. 240 Delegated credentials allow a peer to terminate TLS connections on 241 behalf of the certificate owner. If a credential is stolen, there is 242 no mechanism for revoking it without revoking the certificate itself. 243 To limit exposure in case of delegated credential private key 244 compromise, delegated credentials have a maximum validity period. In 245 the absence of an application profile standard specifying otherwise, 246 the maximum validity period is set to 7 days. Peers MUST NOT issue 247 credentials with a validity period longer than the maximum validity 248 period. This mechanism is described in detail in Section 4.1. 250 It was noted in [XPROT] that certificates in use by servers that 251 support outdated protocols such as SSLv2 can be used to forge 252 signatures for certificates that contain the keyEncipherment KeyUsage 253 ([RFC5280] section 4.2.1.3). In order to prevent this type of cross- 254 protocol attack, we define a new DelegationUsage extension to X.509 255 that permits use of delegated credentials. (See Section 4.2.) 257 3.1. Rationale 259 Delegated credentials present a better alternative than other 260 delegation mechanisms like proxy certificates [RFC3820] for several 261 reasons: 263 * There is no change needed to certificate validation at the PKI 264 layer. 266 * X.509 semantics are very rich. This can cause unintended 267 consequences if a service owner creates a proxy certificate where 268 the properties differ from the leaf certificate. For this reason, 269 delegated credentials have very restricted semantics that should 270 not conflict with X.509 semantics. 272 * Proxy certificates rely on the certificate path building process 273 to establish a binding between the proxy certificate and the 274 server certificate. Since the certificate path building process 275 is not cryptographically protected, it is possible that a proxy 276 certificate could be bound to another certificate with the same 277 public key, with different X.509 parameters. Delegated 278 credentials, which rely on a cryptographic binding between the 279 entire certificate and the delegated credential, cannot. 281 * Each delegated credential is bound to a specific signature 282 algorithm that may be used to sign the TLS handshake ([RFC8446] 283 section 4.2.3). This prevents them from being used with other, 284 perhaps unintended signature algorithms. 286 3.2. Related Work 288 Many of the use cases for delegated credentials can also be addressed 289 using purely server-side mechanisms that do not require changes to 290 client behavior (e.g., a PKCS#11 interface or a remote signing 291 mechanism [KEYLESS]). These mechanisms, however, incur per- 292 transaction latency, since the front-end server has to interact with 293 a back-end server that holds a private key. The mechanism proposed 294 in this document allows the delegation to be done off-line, with no 295 per-transaction latency. The figure below compares the message flows 296 for these two mechanisms with TLS 1.3 [RFC8446]. 298 Remote key signing: 300 Client Front-End Back-End 301 |----ClientHello--->| | 302 |<---ServerHello----| | 303 |<---Certificate----| | 304 | |<---remote sign---->| 305 |<---CertVerify-----| | 306 | ... | | 308 Delegated credentials: 310 Client Front-End Back-End 311 | |<--DC distribution->| 312 |----ClientHello--->| | 313 |<---ServerHello----| | 314 |<---Certificate----| | 315 |<---CertVerify-----| | 316 | ... | | 318 These two mechanisms can be complementary. A server could use 319 credentials for clients that support them, while using [KEYLESS] to 320 support legacy clients. The private key for a delegated credential 321 can be used in place of a certificate private key, so it is important 322 that the Front-End and Back-End are parties that have a trusted 323 relationship. 325 Use of short-lived certificates with automated certificate issuance, 326 e.g., with Automated Certificate Managment Environment (ACME) 327 [RFC8555], reduces the risk of key compromise, but has several 328 limitations. Specifically, it introduces an operationally-critical 329 dependency on an external party. It also limits the types of 330 algorithms supported for TLS authentication to those the CA is 331 willing to issue a certificate for. Nonetheless, existing automated 332 issuance APIs like ACME may be useful for provisioning delegated 333 credentials. 335 4. Delegated Credentials 337 While X.509 forbids end-entity certificates from being used as 338 issuers for other certificates, it is valid to use them to issue 339 other signed objects as long as the certificate contains the 340 digitalSignature KeyUsage ([RFC5280] section 4.2.1.3). We define a 341 new signed object format that would encode only the semantics that 342 are needed for this application. The credential has the following 343 structure: 345 struct { 346 uint32 valid_time; 347 SignatureScheme expected_cert_verify_algorithm; 348 opaque ASN1_subjectPublicKeyInfo<1..2^24-1>; 349 } Credential; 351 valid_time: Time in seconds relative to the beginning of the 352 delegation certificate's notBefore value after which the delegated 353 credential is no longer valid. This MUST NOT exceed 7 days. 355 expected_cert_verify_algorithm: The signature algorithm of the 356 credential key pair, where the type SignatureScheme is as defined 357 in [RFC8446]. This is expected to be the same as 358 CertificateVerify.algorithm sent by the server. Only signature 359 algorithms allowed for use in CertificateVerify messages are 360 allowed. When using RSA, the public key MUST NOT use the 361 rsaEncryption OID, as a result, the following algorithms are not 362 allowed for use with delegated credentials: rsa_pss_rsae_sha256, 363 rsa_pss_rsae_sha384, rsa_pss_rsae_sha512. 365 ASN1_subjectPublicKeyInfo: The credential's public key, a DER- 366 encoded [X.690] SubjectPublicKeyInfo as defined in [RFC5280]. 368 The delegated credential has the following structure: 370 struct { 371 Credential cred; 372 SignatureScheme algorithm; 373 opaque signature<0..2^16-1>; 374 } DelegatedCredential; 376 algorithm: The signature algorithm used to verify 377 DelegatedCredential.signature. 379 signature: The delegation, a signature that binds the credential to 380 the end-entity certificate's public key as specified below. The 381 signature scheme is specified by DelegatedCredential.algorithm. 383 The signature of the DelegatedCredential is computed over the 384 concatenation of: 386 1. A string that consists of octet 32 (0x20) repeated 64 times. 388 2. The context string "TLS, server delegated credentials" for 389 servers and "TLS, client delegated credentials" for clients. 391 3. A single 0 byte, which serves as the separator. 393 4. The DER-encoded X.509 end-entity certificate used to sign the 394 DelegatedCredential. 396 5. DelegatedCredential.cred. 398 6. DelegatedCredential.algorithm. 400 The signature effectively binds the credential to the parameters of 401 the handshake in which it is used. In particular, it ensures that 402 credentials are only used with the certificate and signature 403 algorithm chosen by the delegator. 405 The code changes required in order to create and verify delegated 406 credentials, and the implementation complexity this entails, are 407 localized to the TLS stack. This has the advantage of avoiding 408 changes to security-critical and often delicate PKI code. 410 4.1. Client and Server Behavior 412 This document defines the following TLS extension code point. 414 enum { 415 ... 416 delegated_credential(34), 417 (65535) 418 } ExtensionType; 420 4.1.1. Server Authentication 422 A client which supports this specification SHALL send a 423 "delegated_credential" extension in its ClientHello. The body of the 424 extension consists of a SignatureSchemeList: 426 struct { 427 SignatureScheme supported_signature_algorithm<2..2^16-2>; 428 } SignatureSchemeList; 430 If the client receives a delegated credential without indicating 431 support, then the client MUST abort with an "unexpected_message" 432 alert. 434 If the extension is present, the server MAY send a delegated 435 credential; if the extension is not present, the server MUST NOT send 436 a delegated credential. The server MUST ignore the extension unless 437 TLS 1.3 or a later version is negotiated. 439 The server MUST send the delegated credential as an extension in the 440 CertificateEntry of its end-entity certificate; the client SHOULD 441 ignore delegated credentials sent as extensions to any other 442 certificate. 444 The expected_cert_verify_algorithm field MUST be of a type advertised 445 by the client in the SignatureSchemeList and is considered invalid 446 otherwise. Clients that receive invalid delegated credentials MUST 447 terminate the connection with an "illegal_parameter" alert. 449 4.1.2. Client Authentication 451 A server that supports this specification SHALL send a 452 "delegated_credential" extension in the CertificateRequest message 453 when requesting client authentication. The body of the extension 454 consists of a SignatureSchemeList. If the server receives a 455 delegated credential without indicating support in its 456 CertificateRequest, then the server MUST abort with an 457 "unexpected_message" alert. 459 If the extension is present, the client MAY send a delegated 460 credential; if the extension is not present, the client MUST NOT send 461 a delegated credential. The client MUST ignore the extension unless 462 TLS 1.3 or a later version is negotiated. 464 The client MUST send the delegated credential as an extension in the 465 CertificateEntry of its end-entity certificate; the server SHOULD 466 ignore delegated credentials sent as extensions to any other 467 certificate. 469 The algorithm field MUST be of a type advertised by the server in the 470 "signature_algorithms" extension of the CertificateRequest message 471 and the expected_cert_verify_algorithm field MUST be of a type 472 advertised by the server in the SignatureSchemeList and considered 473 invalid otherwise. Servers that receive invalid delegated 474 credentials MUST terminate the connection with an "illegal_parameter" 475 alert. 477 4.1.3. Validating a Delegated Credential 479 On receiving a delegated credential and a certificate chain, the peer 480 validates the certificate chain and matches the end-entity 481 certificate to the peer's expected identity. It also takes the 482 following steps: 484 1. Verify that the current time is within the validity interval of 485 the credential. This is done by asserting that the current time 486 is no more than the delegation certificate's notBefore value plus 487 DelegatedCredential.cred.valid_time. 489 2. Verify that the credential's remaining validity time is no more 490 than the maximum validity period. This is done by asserting that 491 the current time is no more than the delegation certificate's 492 notBefore value plus DelegatedCredential.cred.valid_time plus the 493 maximum validity period. 495 3. Verify that expected_cert_verify_algorithm matches the scheme 496 indicated in the peer's CertificateVerify message and that the 497 algorithm is allowed for use with delegated credentials. 499 4. Verify that the end-entity certificate satisfies the conditions 500 in Section 4.2. 502 5. Use the public key in the peer's end-entity certificate to verify 503 the signature of the credential using the algorithm indicated by 504 DelegatedCredential.algorithm. 506 If one or more of these checks fail, then the delegated credential is 507 deemed invalid. Clients and servers that receive invalid delegated 508 credentials MUST terminate the connection with an "illegal_parameter" 509 alert. If successful, the participant receiving the Certificate 510 message uses the public key in the credential to verify the signature 511 in the peer's CertificateVerify message. 513 4.2. Certificate Requirements 515 We define a new X.509 extension, DelegationUsage, to be used in the 516 certificate when the certificate permits the usage of delegated 517 credentials. What follows is the ASN.1 [X.680] for the 518 DelegationUsage certificate extension. 520 ext-delegationUsage EXTENSION ::= { 521 SYNTAX DelegationUsage IDENTIFIED BY id-ce-delegationUsage 522 } 524 DelegationUsage ::= NULL 526 id-ce-delegationUsage OBJECT IDENTIFIER ::= 527 { iso(1) identified-organization(3) dod(6) internet(1) 528 private(4) enterprise(1) id-cloudflare(44363) 44 } 530 The extension MUST be marked non-critical. (See Section 4.2 of 531 [RFC5280].) The client MUST NOT accept a delegated credential unless 532 the server's end-entity certificate satisfies the following criteria: 534 * It has the DelegationUsage extension. 536 * It has the digitalSignature KeyUsage (see the KeyUsage extension 537 defined in [RFC5280]). 539 A new extension was chosen instead of adding a new Extended Key Usage 540 (EKU) to be compatible with deployed TLS and PKI software stacks 541 without requiring CAs to issue new intermediate certificates. 543 5. Operational Considerations 545 5.1. Client Clock Skew 547 One of the risks of deploying a short-lived credential system based 548 on absolute time is client clock skew. If a client's clock is 549 sufficiently ahead or behind of the server's clock, then clients will 550 reject credentials that are valid from the server's perspective. 551 Clock skew also affects the validity of the original certificates. 552 The lifetime of the delegated credential should be set taking clock 553 skew into account. Clock skew may affect a delegated credential at 554 the beginning and end of its validity periods, which should also be 555 taken into account. 557 6. IANA Considerations 559 This document registers the "delegated_credentials" extension in the 560 "TLS ExtensionType Values" registry. The "delegated_credentials" 561 extension has been assigned a code point of 34. The IANA registry 562 lists this extension as "Recommended" (i.e., "Y") and indicates that 563 it may appear in the ClientHello (CH), CertificateRequest (CR), or 564 Certificate (CT) messages in TLS 1.3 [RFC8446]. 566 This document also defines an ASN.1 module for the DelegationUsage 567 certificate extension in Appendix A. IANA is requested to register 568 an Object Identfier (OID) for the ASN.1 in "SMI Security for PKIX 569 Module Identifier" arc. An OID for the DelegationUsage certificate 570 extension is not needed as it is already assigned to the extension 571 from Cloudflare's IANA Private Enterprise Number (PEN) arc. 573 7. Security Considerations 575 7.1. Security of Delegated Credential's Private Key 577 Delegated credentials limit the exposure of the private key used in a 578 TLS connection by limiting its validity period. An attacker who 579 compromises the private key of a delegated credential can act as a 580 man-in-the-middle until the delegated credential expires. However, 581 they cannot create new delegated credentials. Thus, delegated 582 credentials should not be used to send a delegation to an untrusted 583 party, but is meant to be used between parties that have some trust 584 relationship with each other. The secrecy of the delegated 585 credential's private key is thus important and access control 586 mechanisms SHOULD be used to protect it, including file system 587 controls, physical security, or hardware security modules. 589 7.2. Re-use of Delegated Credentials in Multiple Contexts 591 It is not possible to use the same delegated credential for both 592 client and server authentication because issuing parties compute the 593 corresponding signature using a context string unique to the intended 594 role (client or server). 596 7.3. Revocation of Delegated Credentials 598 Delegated credentials do not provide any additional form of early 599 revocation. Since it is short lived, the expiry of the delegated 600 credential would revoke the credential. Revocation of the long term 601 private key that signs the delegated credential also implicitly 602 revokes the delegated credential. 604 7.4. Interactions with Session Resumption 606 If a client decides to cache the certificate chain and re-validate it 607 when resuming a connection, the client SHOULD also cache the 608 associated delegated credential and re-validate it. 610 7.5. Privacy Considerations 612 Delegated credentials can be valid for 7 days and it is much easier 613 for a service to create delegated credential than a certificate 614 signed by a CA. A service could determine the client time and clock 615 skew by creating several delegated credentials with different expiry 616 timestamps and observing whether the client would accept it. Client 617 time could be unique and thus privacy sensitive clients, such as 618 browsers in incognito mode, who do not trust the service might not 619 want to advertise support for delegated credentials or limit the 620 number of probes that a server can perform. 622 7.6. The Impact of Signature Forgery Attacks 624 When TLS 1.2 servers support RSA key exchange, they may be vulnerable 625 to attacks that allow forging an RSA signature over an arbitrary 626 message [BLEI]. TLS 1.2 [RFC5246] (Section 7.4.7.1.) describes a 627 mitigation strategy requiring careful implementation of timing 628 resistant countermeasures for preventing these attacks. Experience 629 shows that in practice, server implementations may fail to fully stop 630 these attacks due to the complexity of this mitigation [ROBOT]. For 631 TLS 1.2 servers that support RSA key exchange using a DC-enabled end- 632 entity certificate, a hypothetical signature forgery attack would 633 allow forging a signature over a delegated credential. The forged 634 credential could then be used by the attacker as the equivalent of a 635 man-in-the-middle certificate, valid for 7 days. 637 Server operators should therefore minimize the risk of using DC- 638 enabled end-entity certificates where a signature forgery oracle may 639 be present. If possible, server operators may choose to use DC- 640 enabled certificates only for signing credentials, and not for 641 serving non-DC TLS traffic. Furthermore, server operators may use 642 elliptic curve certificates for DC-enabled traffic, while using RSA 643 certificates without the DelegationUsage certificate extension for 644 non-DC traffic; this completely prevents such attacks. 646 Note that if a signature can be forged over an arbitrary credential, 647 the attacker can choose any value for the valid_time field. Repeated 648 signature forgeries therefore allow the attacker to create multiple 649 delegated credentials that can cover the entire validity period of 650 the certificate. Temporary exposure of the key or a signing oracle 651 may allow the attacker to impersonate a server for the lifetime of 652 the certificate. 654 8. Acknowledgements 656 Thanks to David Benjamin, Christopher Patton, Kyle Nekritz, Anirudh 657 Ramachandran, Benjamin Kaduk, Kazuho Oku, Daniel Kahn Gillmor, Watson 658 Ladd, Robert Merget, Juraj Somorovsky, Nimrod Aviram for their 659 discussions, ideas, and bugs they have found. 661 9. References 663 9.1. Normative References 665 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 666 Requirement Levels", BCP 14, RFC 2119, 667 DOI 10.17487/RFC2119, March 1997, 668 . 670 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 671 Housley, R., and W. Polk, "Internet X.509 Public Key 672 Infrastructure Certificate and Certificate Revocation List 673 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 674 . 676 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 677 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 678 May 2017, . 680 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 681 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 682 . 684 [X.680] ITU-T, "Information technology - Abstract Syntax Notation 685 One (ASN.1): Specification of basic notation", ISO/ 686 IEC 8824-1:2015, November 2015. 688 [X.690] ITU-T, "Information technology - ASN.1 encoding Rules: 689 Specification of Basic Encoding Rules (BER), Canonical 690 Encoding Rules (CER) and Distinguished Encoding Rules 691 (DER)", ISO/IEC 8825-1:2015, November 2015. 693 9.2. Informative References 695 [BLEI] Bleichenbacher, D., "Chosen Ciphertext Attacks against 696 Protocols Based on RSA Encryption Standard PKCS #1", 697 Advances in Cryptology -- CRYPTO'98, LNCS vol. 1462, 698 pages: 1-12 , 1998. 700 [KEYLESS] Sullivan, N. and D. Stebila, "An Analysis of TLS Handshake 701 Proxying", IEEE Trustcom/BigDataSE/ISPA 2015 , 2015. 703 [RFC3820] Tuecke, S., Welch, V., Engert, D., Pearlman, L., and M. 704 Thompson, "Internet X.509 Public Key Infrastructure (PKI) 705 Proxy Certificate Profile", RFC 3820, 706 DOI 10.17487/RFC3820, June 2004, 707 . 709 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 710 (TLS) Protocol Version 1.2", RFC 5246, 711 DOI 10.17487/RFC5246, August 2008, 712 . 714 [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the 715 Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, 716 DOI 10.17487/RFC5912, June 2010, 717 . 719 [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. 720 Kasten, "Automatic Certificate Management Environment 721 (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, 722 . 724 [ROBOT] Boeck, H., Somorovsky, J., and C. Young, "Return Of 725 Bleichenbacher's Oracle Threat (ROBOT)", 27th USENIX 726 Security Symposium , 2018. 728 [XPROT] Jager, T., Schwenk, J., and J. Somorovsky, "On the 729 Security of TLS 1.3 and QUIC Against Weaknesses in PKCS#1 730 v1.5 Encryption", Proceedings of the 22nd ACM SIGSAC 731 Conference on Computer and Communications Security , 2015. 733 Appendix A. ASN.1 Module 735 The following ASN.1 module provides the complete definition of the 736 DelegationUsage certificate extension. The ASN.1 module makes 737 imports from [RFC5912]. 739 DelegatedCredentialExtn 740 { iso(1) identified-organization(3) dod(6) internet(1) 741 security(5) mechanisms(5) pkix(7) id-mod(0) 742 id-mod-delegated-credential-extn(TBD) } 744 DEFINITIONS IMPLICIT TAGS ::= 745 BEGIN 747 -- EXPORT ALL 749 IMPORTS 751 EXTENSION 752 FROM PKIX-CommonTypes-2009 -- From RFC 5912 753 { iso(1) identified-organization(3) dod(6) internet(1) 754 security(5) mechanisms(5) pkix(7) id-mod(0) 755 id-mod-pkixCommon-02(57) } ; 757 -- OID 759 id-cloudflare OBJECT IDENTIFIER ::= 760 { iso(1) identified-organization(3) dod(6) internet(1) private(4) 761 enterprise(1) 44363 } 763 -- EXTENSION 765 ext-delegationUsage EXTENSION ::= 766 { SYNTAX DelegationUsage 767 IDENTIFIED BY id-ce-delegationUsage } 769 id-ce-delegationUsage OBJECT IDENTIFIER ::= { id-cloudflare 44 } 771 DelegationUsage ::= NULL 773 END 775 Authors' Addresses 777 Richard Barnes 778 Cisco 780 Email: rlb@ipv.sx 782 Subodh Iyengar 783 Facebook 785 Email: subodh@fb.com 786 Nick Sullivan 787 Cloudflare 789 Email: nick@cloudflare.com 791 Eric Rescorla 792 Mozilla 794 Email: ekr@rtfm.com