idnits 2.17.1 draft-ietf-tls-exported-authenticator-14.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 (January 25, 2021) is 1159 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) ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. 'HMAC') ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) ** Obsolete normative reference: RFC 7540 (Obsoleted by RFC 9113) Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TLS N. Sullivan 3 Internet-Draft Cloudflare Inc. 4 Intended status: Standards Track January 25, 2021 5 Expires: July 29, 2021 7 Exported Authenticators in TLS 8 draft-ietf-tls-exported-authenticator-14 10 Abstract 12 This document describes a mechanism in Transport Layer Security (TLS) 13 for peers to provide a proof of ownership of an identity, such as an 14 X.509 certificate. This proof can be exported by one peer, 15 transmitted out-of-band to the other peer, and verified by the 16 receiving peer. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on July 29, 2021. 35 Copyright Notice 37 Copyright (c) 2021 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 54 3. Message Sequences . . . . . . . . . . . . . . . . . . . . . . 3 55 4. Authenticator Request . . . . . . . . . . . . . . . . . . . . 4 56 5. Authenticator . . . . . . . . . . . . . . . . . . . . . . . . 5 57 5.1. Authenticator Keys . . . . . . . . . . . . . . . . . . . 6 58 5.2. Authenticator Construction . . . . . . . . . . . . . . . 6 59 5.2.1. Certificate . . . . . . . . . . . . . . . . . . . . . 7 60 5.2.2. CertificateVerify . . . . . . . . . . . . . . . . . . 8 61 5.2.3. Finished . . . . . . . . . . . . . . . . . . . . . . 9 62 5.2.4. Authenticator Creation . . . . . . . . . . . . . . . 9 63 6. Empty Authenticator . . . . . . . . . . . . . . . . . . . . . 9 64 7. API considerations . . . . . . . . . . . . . . . . . . . . . 10 65 7.1. The "request" API . . . . . . . . . . . . . . . . . . . . 10 66 7.2. The "get context" API . . . . . . . . . . . . . . . . . . 10 67 7.3. The "authenticate" API . . . . . . . . . . . . . . . . . 11 68 7.4. The "validate" API . . . . . . . . . . . . . . . . . . . 11 69 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 70 8.1. Update of the TLS ExtensionType Registry . . . . . . . . 12 71 8.2. Update of the TLS Exporter Labels Registry . . . . . . . 12 72 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 73 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 74 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 75 11.1. Normative References . . . . . . . . . . . . . . . . . . 13 76 11.2. Informative References . . . . . . . . . . . . . . . . . 14 77 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 79 1. Introduction 81 This document provides a way to authenticate one party of a Transport 82 Layer Security (TLS) connection to its peer using a Certificate 83 message after the session has been established. This allows both the 84 client and server to prove ownership of additional identities at any 85 time after the handshake has completed. This proof of authentication 86 can be exported and transmitted out-of-band from one party to be 87 validated by its peer. 89 This mechanism provides two advantages over the authentication that 90 TLS natively provides: 92 multiple identities - Endpoints that are authoritative for multiple 93 identities - but do not have a single certificate that includes 94 all of the identities - can authenticate additional identities 95 over a single connection. 97 spontaneous authentication - Endpoints can authenticate after a 98 connection is established, in response to events in a higher-layer 99 protocol, as well as integrating more context. 101 Versions of TLS prior to TLS 1.3 used renegotiation as a way to 102 enable post-handshake client authentication given an existing TLS 103 connection. The mechanism described in this document may be used to 104 replace the post-handshake authentication functionality provided by 105 renegotiation. Unlike renegotiation, exported Authenticator-based 106 post-handshake authentication does not require any changes at the TLS 107 layer. 109 Post-handshake authentication is defined in section 4.6.3 of TLS 1.3 110 [TLS13], but it has the disadvantage of requiring additional state to 111 be stored as part of the TLS state machine. Furthermore, the 112 authentication boundaries of TLS 1.3 post-handshake authentication 113 align with TLS record boundaries, which are often not aligned with 114 the authentication boundaries of the higher-layer protocol. For 115 example, multiplexed connection protocols like HTTP/2 [RFC7540] do 116 not have a notion of which TLS record a given message is a part of. 118 Exported Authenticators are meant to be used as a building block for 119 application protocols. Mechanisms such as those required to 120 advertise support and handle authentication errors are not handled at 121 the TLS layer. 123 TLS (or DTLS) version 1.2 [RFC5246] [RFC6347]. or later are REQUIRED 124 to implement the mechanisms described in this document. 126 2. Conventions and Terminology 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 130 "OPTIONAL" in this document are to be interpreted as described in BCP 131 14 [RFC2119] [RFC8174] when, and only when, they appear in all 132 capitals, as shown here. 134 3. Message Sequences 136 There are two types of messages defined in this document: 137 Authenticator Requests and Authenticators. These can be combined in 138 the following three sequences: 140 Client Authentication 142 o Server generates Authenticator Request 144 o Client generates Authenticator from Server's Authenticator Request 145 o Server validates Client's Authenticator 147 Server Authentication 149 o Client generates Authenticator Request 151 o Server generates Authenticator from Client's Authenticator Request 153 o Client validates Server's Authenticator 155 Spontaneous Server Authentication 157 o Server generates Authenticator 159 o Client validates Server's Authenticator 161 4. Authenticator Request 163 The authenticator request is a structured message that can be created 164 by either party of a TLS connection using data exported from that 165 connection. It can be transmitted to the other party of the TLS 166 connection at the application layer. The application layer protocol 167 used to send the authenticator request SHOULD use a secure with 168 equivalent security to TLS, such as QUIC [QUIC-TLS], as its as its 169 underlying transport to keep the request confidential. The 170 application MAY use the existing TLS connection to transport the 171 authenticator. 173 An authenticator request message can be constructed by either the 174 client or the server. Server-generated authenticator requests use 175 the CertificateRequest message from Section 4.3.2 of [TLS13]. 176 Client-generated authenticator requests use a new message, called the 177 ClientCertificateRequest, which uses the same structure as 178 CertificateRequest. These messages structures are used even if the 179 TLS connection protocol is TLS 1.2. 181 The CertificateRequest and ClientCertificateRequest messages are used 182 to define the parameters in a request for an authenticator. These 183 are encoded as TLS handshake messages, including length and type 184 fields. They do not include any TLS record layer framing and are not 185 encrypted with a handshake key. 187 The structures are defined to be: 189 struct { 190 opaque certificate_request_context<0..2^8-1>; 191 Extension extensions<2..2^16-1>; 192 } ClientCertificateRequest; 194 struct { 195 opaque certificate_request_context<0..2^8-1>; 196 Extension extensions<2..2^16-1>; 197 } CertificateRequest; 199 certificate_request_context: An opaque string which identifies the 200 certificate request and which will be echoed in the authenticator 201 message. A certificate_request_context value MUST be unique for 202 each authenticator request within the scope of a connection 203 (preventing replay and context confusion). The 204 certificate_request_context SHOULD be chosen to be unpredictable 205 to the peer (e.g., by randomly generating it) in order to prevent 206 an attacker who has temporary access to the peer's private key 207 from pre-computing valid authenticators. 209 extensions: The set of extensions allowed in the CertificateRequest 210 structure and the ClientCertificateRequest structure are those 211 defined in the TLS ExtensionType Values IANA registry [RFC8447] 212 containing CR in the TLS 1.3 column. In addition, the set of 213 extensions in the ClientCertificateRequest structure MAY include 214 the server_name [RFC6066] extension. 216 The uniqueness requirements of the certificate_request_context apply 217 only to CertificateRequest and ClientCertificateRequest messages that 218 are used as part of authenticator requests. There is no impact if 219 the value of a certificate_request_context used in an authenticator 220 request matches the value of a certificate_request_context in the 221 handshake or in a post-handshake message. 223 5. Authenticator 225 The authenticator is a structured message that can be exported from 226 either party of a TLS connection. It can be transmitted to the other 227 party of the TLS connection at the application layer. The 228 application layer protocol used to send the authenticator SHOULD use 229 a secure with equivalent security to TLS, such as QUIC [QUIC-TLS], as 230 its as its underlying transport to keep the authenticator 231 confidential. The application MAY use the existing TLS connection to 232 transport the authenticator. 234 An authenticator message can be constructed by either the client or 235 the server given an established TLS connection, an identity, such as 236 an X.509 certificate, and a corresponding private key. Clients MUST 237 NOT send an authenticator without a preceding authenticator request; 238 for servers an authenticator request is optional. For authenticators 239 that do not correspond to authenticator requests, the 240 certificate_request_context is chosen by the server. 242 5.1. Authenticator Keys 244 Each authenticator is computed using a Handshake Context and Finished 245 MAC Key derived from the TLS connection. These values are derived 246 using an exporter as described in Section 4 of [RFC5705] (for TLS 247 1.2) or Section 7.5 of [TLS13] (for TLS 1.3). For TLS 1.3, the 248 exporter_master_secret MUST be used, not the 249 early_exporter_master_secret. These values use different labels 250 depending on the role of the sender: 252 o The Handshake Context is an exporter value that is derived using 253 the label "EXPORTER-client authenticator handshake context" or 254 "EXPORTER-server authenticator handshake context" for 255 authenticators sent by the client or server respectively. 257 o The Finished MAC Key is an exporter value derived using the label 258 "EXPORTER-client authenticator finished key" or "EXPORTER-server 259 authenticator finished key" for authenticators sent by the client 260 or server respectively. 262 The context_value used for the exporter is empty (zero length) for 263 all four values. There is no need to include additional context 264 information at this stage since the application-supplied context is 265 included in the authenticator itself. The length of the exported 266 value is equal to the length of the output of the hash function 267 selected in TLS for the pseudorandom function (PRF). Exported 268 authenticators cannot be used with cipher suites that do not use the 269 TLS PRF and have not defined a hash function for this purpose. This 270 hash is referred to as the authenticator hash. 272 To avoid key synchronization attacks, Exported Authenticators MUST 273 NOT be generated or accepted on TLS 1.2 connections that did not 274 negotiate the extended master secret [RFC7627]. 276 5.2. Authenticator Construction 278 An authenticator is formed from the concatenation of TLS 1.3 [TLS13] 279 Certificate, CertificateVerify, and Finished messages. These 280 messages are encoded as TLS handshake messages, including length and 281 type fields. 283 If the peer creating the certificate_request_context has already 284 created or correctly validated an authenticator with the same value, 285 then no authenticator should be constructed. If there is no 286 authenticator request, the extensions are chosen from those presented 287 in the TLS handshake's ClientHello. Only servers can provide an 288 authenticator without a corresponding request. 290 ClientHello extensions are used to determine permissible extensions 291 in the Certificate message. This follows the general model for 292 extensions in TLS in which extensions can only be included as part of 293 a Certificate message if they were previously sent as part of a 294 CertificateRequest message or ClientHello message, to ensure that the 295 recipient will be able to process such extensions. 297 5.2.1. Certificate 299 The Certificate message contains the identity to be used for 300 authentication, such as the end-entity certificate and any supporting 301 certificates in the chain. This structure is defined in [TLS13], 302 Section 4.4.2. 304 The Certificate message contains an opaque string called 305 certificate_request_context, which is extracted from the 306 authenticator request if present. If no authenticator request is 307 provided, the certificate_request_context can be chosen arbitrarily 308 but MUST be unique within the scope of the connection and be 309 unpredictable to the peer. 311 Certificates chosen in the Certificate message MUST conform to the 312 requirements of a Certificate message in the negotiated version of 313 TLS. In particular, the certificate chain MUST be valid for the 314 signature algorithms indicated by the peer in the 315 "signature_algorithms" and "signature_algorithms_cert" extension, as 316 described in Section 4.2.3 of [TLS13] for TLS 1.3 or the 317 "signature_algorithms" extension from Sections 7.4.2 and 7.4.6 of 318 [RFC5246] for TLS 1.2. 320 In addition to "signature_algorithms" and 321 "signature_algorithms_cert", the "server_name" [RFC6066], 322 "certificate_authorities" (Section 4.2.4. of [TLS13]), and 323 "oid_filters" (Section 4.2.5. of [TLS13]) extensions are used to 324 guide certificate selection. 326 Only the X.509 certificate type defined in [TLS13] is supported. 327 Alternative certificate formats such as [RFC7250] Raw Public Keys are 328 not supported in this version of the specification and their use in 329 this context has not yet been analysed. 331 If an authenticator request was provided, the Certificate message 332 MUST contain only extensions present in the authenticator request. 334 Otherwise, the Certificate message MUST contain only extensions 335 present in the TLS handshake. Unrecognized extensions in the 336 authenticator request MUST be ignored. 338 5.2.2. CertificateVerify 340 This message is used to provide explicit proof that an endpoint 341 possesses the private key corresponding to its identity. The format 342 of this message is taken from TLS 1.3: 344 struct { 345 SignatureScheme algorithm; 346 opaque signature<0..2^16-1>; 347 } CertificateVerify; 349 The algorithm field specifies the signature algorithm used (see 350 Section 4.2.3 of [TLS13] for the definition of this field). The 351 signature is a digital signature using that algorithm. 353 The signature scheme MUST be a valid signature scheme for TLS 1.3. 354 This excludes all RSASSA-PKCS1-v1_5 algorithms and combinations of 355 ECDSA and hash algorithms that are not supported in TLS 1.3. 357 If an authenticator request is present, the signature algorithm MUST 358 be chosen from one of the signature schemes present in the 359 authenticator request. Otherwise, with spontaneous server 360 authentication, the signature algorithm used MUST be chosen from the 361 "signature_algorithms" sent by the peer in the ClientHello of the TLS 362 handshake. If there are no available signature algorithms, then no 363 authenticator should be constructed. 365 The signature is computed using the chosen signature scheme over the 366 concatenation of: 368 o A string that consists of octet 32 (0x20) repeated 64 times 370 o The context string "Exported Authenticator" (which is not NULL- 371 terminated) 373 o A single 0 byte which serves as the separator 375 o The hashed authenticator transcript 377 The authenticator transcript is the hash of the concatenated 378 Handshake Context, authenticator request (if present), and 379 Certificate message: 381 Hash(Handshake Context || authenticator request || Certificate) 382 Where Hash is the authenticator hash defined in section 4.1. If the 383 authenticator request is not present, it is omitted from this 384 construction, i.e., it is zero-length. 386 If the party that generates the exported authenticator does so with a 387 different connection than the party that is validating it, then the 388 Handshake Context will not match, resulting in a CertificateVerify 389 message that does not validate. This includes situations in which 390 the application data is sent via TLS-terminating proxy. Given a 391 failed CertificateVerify validation, it may be helpful for the 392 application to confirm that both peers share the same connection 393 using a value derived from the connection secrets before taking a 394 user-visible action. 396 5.2.3. Finished 398 A HMAC [HMAC] over the hashed authenticator transcript, which is the 399 concatenated Handshake Context, authenticator request (if present), 400 Certificate, and CertificateVerify. The HMAC is computed using the 401 authenticator hash, using the Finished MAC Key as a key. 403 Finished = HMAC(Finished MAC Key, Hash(Handshake Context || 404 authenticator request || Certificate || CertificateVerify)) 406 5.2.4. Authenticator Creation 408 An endpoint constructs an authenticator by serializing the 409 Certificate, CertificateVerify, and Finished as TLS handshake 410 messages and concatenating the octets: 412 Certificate || CertificateVerify || Finished 414 An authenticator is valid if the CertificateVerify message is 415 correctly constructed given the authenticator request (if used) and 416 the Finished message matches the expected value. When validating an 417 authenticator, a constant-time comparison SHOULD be used. 419 6. Empty Authenticator 421 If, given an authenticator request, the endpoint does not have an 422 appropriate identity or does not want to return one, it constructs an 423 authenticated refusal called an empty authenticator. This is a 424 Finished message sent without a Certificate or CertificateVerify. 425 This message is an HMAC over the hashed authenticator transcript with 426 a Certificate message containing no CertificateEntries and the 427 CertificateVerify message omitted. The HMAC is computed using the 428 authenticator hash, using the Finished MAC Key as a key. This 429 message is encoded as a TLS handshake message, including length and 430 type field. It does not include TLS record layer framing. 432 Finished = HMAC(Finished MAC Key, Hash(Handshake Context || 433 authenticator request || Certificate)) 435 7. API considerations 437 The creation and validation of both authenticator requests and 438 authenticators SHOULD be implemented inside the TLS library even if 439 it is possible to implement it at the application layer. TLS 440 implementations supporting the use of exported authenticators SHOULD 441 provide application programming interfaces by which clients and 442 servers may request and verify exported authenticator messages. 444 Notwithstanding the success conditions described below, all APIs MUST 445 fail if: 447 o the connection uses a TLS version of 1.1 or earlier, or 449 o the connection is TLS 1.2 and the extended master secret extension 450 [RFC7627] was not negotiated 452 The following sections describes APIs that are considered necessary 453 to implement exported authenticators. These are informative only. 455 7.1. The "request" API 457 The "request" API takes as input: 459 o certificate_request_context (from 0 to 255 bytes) 461 o set of extensions to include (this MUST include 462 signature_algorithms) 464 It returns an authenticator request, which is a sequence of octets 465 that comprises a CertificateRequest or ClientCertificateRequest 466 message. 468 7.2. The "get context" API 470 The "get context" API takes as input: 472 o authenticator or authenticator request 474 It returns the certificate_request_context. 476 7.3. The "authenticate" API 478 The "authenticate" API takes as input: 480 o a reference to an active connection 482 o an identity, such as a set of certificate chains and associated 483 extensions (OCSP, SCT, etc.) 485 o a signer (either the private key associated with the identity, or 486 interface to perform private key operations) for each chain 488 o an authenticator request or certificate_request_context (from 0 to 489 255 bytes) 491 It returns either the exported authenticator or an empty 492 authenticator as a sequence of octets. It is recommended that the 493 logic for selecting the certificates and extensions to include in the 494 exporter is implemented in the TLS library. Implementing this in the 495 TLS library lets the implementer take advantage of existing extension 496 and certificate selection logic and more easily remember which 497 extensions were sent in the ClientHello. 499 It is also possible to implement this API outside of the TLS library 500 using TLS exporters. This may be preferable in cases where the 501 application does not have access to a TLS library with these APIs or 502 when TLS is handled independently of the application layer protocol. 504 7.4. The "validate" API 506 The "validate" API takes as input: 508 o a reference to an active connection 510 o an optional authenticator request 512 o an authenticator 514 o a function for validating a certificate chain 516 It returns the identity, such as the certificate chain and its 517 extensions, and a status to indicate whether the authenticator is 518 valid or not after applying the function for validating the 519 certificate chain to the chain contained in the authenticator. 521 The API should return a failure if the certificate_request_context of 522 the authenticator was used in a previously validated authenticator. 523 Well-formed empty authenticators are returned as invalid. 525 When validating an authenticator, a constant-time comparison should 526 be used. 528 8. IANA Considerations 530 8.1. Update of the TLS ExtensionType Registry 532 IANA is requested to update the entry for server_name(0) in the 533 registry for ExtensionType (defined in [TLS13]) by replacing the 534 value in the "TLS 1.3" column with the value "CH, EE, CR" and this 535 document in the "Reference" column. 537 8.2. Update of the TLS Exporter Labels Registry 539 IANA is requested to add the following entries to the registry for 540 Exporter Labels (defined in [RFC5705]): "EXPORTER-server 541 authenticator handshake context", "EXPORTER-client authenticator 542 finished key" and "EXPORTER-server authenticator finished key" with 543 "DTLS-OK" and "Recommended" set to "Y" and this document added to the 544 "Reference" column. 546 9. Security Considerations 548 The Certificate/Verify/Finished pattern intentionally looks like the 549 TLS 1.3 pattern which now has been analyzed several times. For 550 example, [SIGMAC] presents a relevant framework for analysis. 552 Authenticators are independent and unidirectional. There is no 553 explicit state change inside TLS when an authenticator is either 554 created or validated. The application in possession of a validated 555 authenticator can rely on any semantics associated with data in the 556 certificate_request_context. 558 o This property makes it difficult to formally prove that a server 559 is jointly authoritative over multiple identities, rather than 560 individually authoritative over each. 562 o There is no indication in the TLS layer about which point in time 563 an authenticator was computed. Any feedback about the time of 564 creation or validation of the authenticator should be tracked as 565 part of the application layer semantics if required. 567 The signatures generated with this API cover the context string 568 "Exported Authenticator" and therefore cannot be transplanted into 569 other protocols. 571 10. Acknowledgements 573 Comments on this proposal were provided by Martin Thomson. 574 Suggestions for Section 9 were provided by Karthikeyan Bhargavan. 576 11. References 578 11.1. Normative References 580 [HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 581 Hashing for Message Authentication", RFC 2104, 582 DOI 10.17487/RFC2104, February 1997, 583 . 585 [QUIC-TLS] 586 Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure 587 QUIC", draft-ietf-quic-tls (work in progress). 589 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 590 Requirement Levels", BCP 14, RFC 2119, 591 DOI 10.17487/RFC2119, March 1997, 592 . 594 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 595 (TLS) Protocol Version 1.2", RFC 5246, 596 DOI 10.17487/RFC5246, August 2008, 597 . 599 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 600 Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, 601 March 2010, . 603 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 604 Extensions: Extension Definitions", RFC 6066, 605 DOI 10.17487/RFC6066, January 2011, 606 . 608 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 609 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 610 January 2012, . 612 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 613 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 614 Transport Layer Security (TLS) and Datagram Transport 615 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 616 June 2014, . 618 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 619 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 620 DOI 10.17487/RFC7540, May 2015, 621 . 623 [RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A., 624 Langley, A., and M. Ray, "Transport Layer Security (TLS) 625 Session Hash and Extended Master Secret Extension", 626 RFC 7627, DOI 10.17487/RFC7627, September 2015, 627 . 629 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 630 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 631 May 2017, . 633 [RFC8447] Salowey, J. and S. Turner, "IANA Registry Updates for TLS 634 and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018, 635 . 637 [TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol 638 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 639 . 641 11.2. Informative References 643 [SIGMAC] Krawczyk, H., "A Unilateral-to-Mutual Authentication 644 Compiler for Key Exchange (with Applications to Client 645 Authentication in TLS 1.3)", 2016, 646 . 648 Author's Address 650 Nick Sullivan 651 Cloudflare Inc. 653 Email: nick@cloudflare.com