From 89f71ec81778171458945b470765abd4bd1fd9b8 Mon Sep 17 00:00:00 2001 From: EKR Date: Tue, 16 Dec 2025 16:52:03 -0800 Subject: [PATCH 1/2] RPC's first version --- rfc9846.md | 1724 +++++++++++++++++++++++++++++++++++----------------- 1 file changed, 1183 insertions(+), 541 deletions(-) diff --git a/rfc9846.md b/rfc9846.md index 13c3d331..b89f3b01 100644 --- a/rfc9846.md +++ b/rfc9846.md @@ -1,18 +1,19 @@ --- title: The Transport Layer Security (TLS) Protocol Version 1.3 abbrev: TLS -docname: draft-ietf-tls-rfc8446bis-latest +number: 9846 +docname: draft-ietf-tls-rfc8446bis-14 submissiontype: IETF +consensus: true category: std updates: 5705, 6066, 7627, 8422 obsoletes: 8446 v: 3 +lang: en ipr: pre5378Trust200902 -area: Security -workgroup: Transport Layer Security -keyword: Internet-Draft - +area: SEC +workgroup: tls stand_alone: yes pi: rfcedstyle: yes @@ -48,14 +49,13 @@ normative: RFC8174: RFC5116: - X690: title: "Information technology - ASN.1 encoding Rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)" date: February 2021 author: org: ITU-T seriesinfo: - ITU-T X.690 + ITU-T: Recommendation X.690 target: https://www.itu.int/rec/T-REC-X.690-202102-I/en GCM: title: "Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC" @@ -63,9 +63,9 @@ normative: author: - ins: M. Dworkin seriesinfo: - NIST: Special Publication 800-38D + NIST: SP 800-38D + DOI: 10.6028/NIST.SP.800-38D target: https://doi.org/10.6028/NIST.SP.800-38D - informative: RFC4086: RFC4346: @@ -85,7 +85,7 @@ informative: RFC7685: RFC8305: RFC8844: - RFC8849: + RFC8449: RFC8870: RFC8937: RFC9001: @@ -106,26 +106,28 @@ informative: date: 1995-02-09 TIMING: title: "Remote Timing Attacks Are Practical" + target: https://www.usenix.org/conference/12th-usenix-security-symposium/remote-timing-attacks-are-practical author: - ins: D. Boneh - ins: D. Brumley - seriesinfo: - USENIX: Security Symposium + refcontent: 12th USENIX Security Symposium (USENIX Security 03) date: 2003 X501: title: "Information Technology - Open Systems Interconnection - The Directory: Models" date: October 2019 + target: https://www.itu.int/rec/T-REC-X.501-201910-I/en author: org: ITU-T seriesinfo: - ISO/IEC 9594-2:2020 + ITU-T: Recommendation X.501 + ISO/IEC: 9594-2:2020 PSK-FINISHED: title: "Revision 10: possible attack if client authentication is allowed during PSK" - date: 2015 - seriesinfo: message to the TLS mailing list, - target: https://www.ietf.org/mail-archive/web/tls/current/msg18215.html + date: 2015-10-31 + refcontent: message to the TLS mailing list + target: https://mailarchive.ietf.org/arch/msg/tls/TugB5ddJu3nYg7chcyeIyUqWSbA/ author: - ins: C. Cremers @@ -137,9 +139,9 @@ informative: ins: S. Scott CHHSV17: title: "Awkward Handshake: Possible mismatch of client/server view on client authentication in post-handshake mode in Revision 18" - date: 10 February, 2017 - target: https://www.ietf.org/mail-archive/web/tls/current/msg22382.html - seriesinfo: message to the TLS mailing list + date: 2017-02-10 + target: https://mailarchive.ietf.org/arch/msg/tls/crdSCgiW-94z2joulYJtuA52E9E/ + refcontent: message to the TLS mailing list author: - ins: C. Cremers @@ -158,10 +160,12 @@ informative: ins: A. Luykx - ins: K. Paterson - target: https://eprint.iacr.org/2024/051.pdf - date: August 2017 + target: https://eprint.iacr.org/2024/051 + date: 2024 + refcontent: Cryptology ePrint Archive, Paper 2024/051 HGFS15: title: "Prying Open Pandora's Box: KCI Attacks against TLS" + target: https://www.usenix.org/conference/woot15/workshop-program/presentation/hlauschek author: - ins: C. Hlauschek @@ -171,7 +175,7 @@ informative: ins: F. Fankhauser - ins: C. Schanes - seriesinfo: Proceedings of USENIX Workshop on Offensive Technologies + refcontent: 9th USENIX Workshop on Offensive Technologies (WOOT 15) date: 2015 FGSW16: title: "Key Confirmation in Key Exchange: A Formal Treatment and Implications for TLS 1.3" @@ -184,16 +188,20 @@ informative: ins: B. Schmidt - ins: B. Warinschi - seriesinfo: Proceedings of IEEE Symposium on Security and Privacy (Oakland) 2016 + refcontent: 2016 IEEE Symposium on Security and Privacy (SP), pp. 452-469 + seriesinfo: + DOI: 10.1109/SP.2016.34 target: http://ieeexplore.ieee.org/document/7546517/ date: 2016 FW15: title: "Factoring RSA Keys With TLS Perfect Forward Secrecy" + target: https://www.redhat.com/en/blog/factoring-rsa-keys-tls-perfect-forward-secrecy author: - ins: F. Weimer org: Red Hat Product Security - date: 2015-09 + date: 2015-09-02 + refcontent: Red Hat Blog BDFKPPRSZZ16: title: "Implementing and Proving the TLS 1.3 Record Layer" author: @@ -217,16 +225,17 @@ informative: ins: S. Zanella-Beguelin - ins: J. Zinzindohoue - seriesinfo: Proceedings of IEEE Symposium on Security and Privacy (San Jose) 2017 - date: 2016-12 + refcontent: Cryptology ePrint Archive, Paper 2016/1178 + date: 2016 target: https://eprint.iacr.org/2016/1178 Blei98: title: "Chosen Ciphertext Attacks against Protocols Based on RSA Encryption Standard PKCS #1" + target: https://link.springer.com/chapter/10.1007/bfb0055716 author: - ins: D. Bleichenbacher - seriesinfo: Proceedings of CRYPTO '98 + refcontent: Advances in Cryptology - CRYPTO '98, Lecture Notes in Computer Science, vol. 1462, pp. 1-12 date: 1998 BMMRT15: @@ -242,8 +251,8 @@ informative: ins: P. Rogaway - ins: B. Tackmann - seriesinfo: ProvSec 2015 - date: 2015-09 + refcontent: Cryptology ePrint Archive, Paper 2015/394 + date: 2015 target: https://eprint.iacr.org/2015/394 BT16: @@ -253,14 +262,14 @@ informative: ins: M. Bellare - ins: B. Tackmann - seriesinfo: Proceedings of CRYPTO 2016 - date: July 2016 + refcontent: Cryptology ePrint Archive, Paper 2016/564 + date: 2016 target: https://eprint.iacr.org/2016/564 Kraw16: title: "A Unilateral-to-Mutual Authentication Compiler for Key Exchange (with Applications to Client Authentication in TLS 1.3" - date: October2016 - seriesinfo: Proceedings of ACM CCS 2016 + date: 2016 + refcontent: Cryptology ePrint Archive, Paper 2016/711 target: https://eprint.iacr.org/2016/711 author: - @@ -268,8 +277,8 @@ informative: KW16: title: "The OPTLS Protocol and TLS 1.3" - date: 2016 - seriesinfo: Proceedings of Euro S&P 2016 + date: 2015 + refcontent: Cryptology ePrint Archive, Paper 2015/978 target: https://eprint.iacr.org/2015/978 author: - @@ -280,8 +289,7 @@ informative: DFGS15: title: "A Cryptographic Analysis of the TLS 1.3 draft-10 Full and Pre-shared Key Handshake Protocol" date: 2015 - seriesinfo: Proceedings of ACM CCS 2015 - date: October 2016, + refcontent: Cryptology ePrint Archive, Paper 2015/914 target: https://eprint.iacr.org/2015/914 author: - @@ -295,8 +303,8 @@ informative: DFGS16: title: "A Cryptographic Analysis of the TLS 1.3 draft-10 Full and Pre-shared Key Handshake Protocol" - date: February 2016 - seriesinfo: TRON 2016 + date: 2016 + refcontent: Cryptology ePrint Archive, Paper 2016/081 target: https://eprint.iacr.org/2016/081 author: - @@ -311,7 +319,7 @@ informative: FG17: title: "Replay Attacks on Zero Round-Trip Time: The Case of the TLS 1.3 Handshake Candidates" date: 2017 - seriesinfo: Proceedings of Euro S&P 2017 + refcontent: Cryptology ePrint Archive, Paper 2017/082 target: https://eprint.iacr.org/2017/082 author: - @@ -322,15 +330,14 @@ informative: Kraw10: title: "Cryptographic Extraction and Key Derivation: The HKDF Scheme" date: 2010 - seriesinfo: Proceedings of CRYPTO 2010 + refcontent: Cryptology ePrint Archive, Paper 2010/264 target: https://eprint.iacr.org/2010/264 - data: August 2010 author: - ins: H. Krawczyk Mac17: title: "Security Review of TLS1.3 0-RTT" - date: March 2017 + date: May 2017 target: https://github.com/tlswg/tls13-spec/issues/1001 author: - @@ -338,34 +345,36 @@ informative: Res17a: title: Preliminary data on Firefox TLS 1.3 Middlebox experiment - date: 2017 - target: https://www.ietf.org/mail-archive/web/tls/current/msg25091.html - seriesinfo: message to the TLS mailing list + date: 2017-12-05 + target: https://mailarchive.ietf.org/arch/msg/tls/RBp0X-OWNuWXugFJRV7c_hIU0dI/ + refcontent: message to the TLS mailing list author: - ins: E. Rescorla Res17b: title: More compatibility measurement results - date: 22 December 2017 - target: https://www.ietf.org/mail-archive/web/tls/current/msg25179.html - seriesinfo: message to the TLS mailing list + date: 2017-12-22 + target: https://mailarchive.ietf.org/arch/msg/tls/6pGGT-wm5vSkacMFPEPvFMEnj-M/ + refcontent: message to the TLS mailing list author: - ins: E. Rescorla Ben17a: title: Presentation before the TLS WG at IETF 100 - date: 2017 + date: November 2017 target: https://datatracker.ietf.org/meeting/100/materials/slides-100-tls-sessa-tls13/ author: - ins: D. Benjamin + refcontent: IETF 100 Proceedings Ben17b: title: Additional TLS 1.3 results from Chrome - date: 2017 - target: https://www.ietf.org/mail-archive/web/tls/current/msg25168.html + date: 2017-12-18 + target: https://mailarchive.ietf.org/arch/msg/tls/i9blmvG2BEPf1s1OJkenHknRw9c/ + refcontent: message to the TLS mailing list author: - ins: D. Benjamin @@ -375,6 +384,7 @@ informative: title: "Partially specified channels: The TLS 1.3 record layer without elision" date: 2018 + refcontent: Cryptology ePrint Archive, Paper 2018/634 author: - ins: C. Patton @@ -383,22 +393,29 @@ informative: target: https://eprint.iacr.org/2018/634 FETCH: - title: "Fetch Standard" - date: Living Standard + title: "Fetch" + date: false author: org: WHATWG target: https://fetch.spec.whatwg.org/ + refcontent: WHATWG Living Standard + ann: > + Commit snapshot: https://fetch.spec.whatwg.org/commit-snapshots/4775fcb48042c8411df497c0b7cf167b4240004f/ DSA-1571-1: - title: "openssl -- predictable random number generator" + title: "[SECURITY] [DSA 1571-1] New openssl packages fix predictable random number generator" author: - org: The Debian Project + - + ins: F. Weimer date: May 2008 target: https://www.debian.org/security/2008/dsa-1571 + refcontent: message to the debian-security-announce mailing list MM24: title: "Misbinding Raw Public Keys to Identities in TLS" - date: 2024 + date: 2025-09-29 + refcontent: + arxiv:2411.09770 target: https://arxiv.org/pdf/2411.09770 author: - @@ -411,16 +428,99 @@ informative: Selfie: title: "Selfie: reflections on TLS 1.3 with PSK" date: 2019 - target: https://eprint.iacr.org/2019/347.pdf + refcontent: Cryptology ePrint Archive, Paper 2019/347 + target: https://eprint.iacr.org/2019/347 author: - ins: N. Drucker - ins: S. Gueron + PRE-RFC9849: + title: > + TLS Encrypted Client Hello + target: https://www.rfc-editor.org/info/rfc9849 + seriesinfo: + RFC: PRE-RFC9849 + DOI: 10.17487/preRFC9849 + date: December 2025 + author: + - + ins: E. Rescorla + surname: Rescorla + fullname: Eric Rescorla + - + ins: K. Oku + surname: Oku + fullname: Kazuho Oku + - + ins: N. Sullivan + surname: Sullivan + fullname: Nick Sullivan + - + ins: C. A. Wood + surname: Wood + fullname: Christopher A. Wood --- abstract + + + + + + + + + + + + This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, @@ -431,16 +531,8 @@ RFCs 5077, 5246, 6961, 8422, and 8446. This document also specifies new requirements for TLS 1.2 implementations. --- middle - - # Introduction -RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH -The source for this draft is maintained in GitHub. Suggested changes -should be submitted as pull requests at -https://github.com/ekr/tls13-spec. Instructions are on that page as -well. - The primary goal of TLS is to provide a secure channel between two communicating peers; the only requirement from the underlying transport is a reliable, in-order data stream. Specifically, the @@ -484,7 +576,7 @@ TLS consists of two primary components: traffic keys. TLS is application protocol independent; higher-level protocols can -layer on top of TLS transparently. The TLS standard, however, does not +layer on top of TLS transparently. However, the TLS standard does not specify how protocols add security with TLS; how to initiate TLS handshaking and how to interpret the authentication certificates exchanged are left to the judgment of the designers and @@ -511,28 +603,33 @@ and obsoletes {{RFC6961}} as described in {{ocsp-and-sct}}. ## Conventions and Terminology -The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", -"SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this -document are to be interpreted as described in BCP 14 {{RFC2119}} {{RFC8174}} -when, and only when, they appear in all capitals, as shown here. +{::boilerplate bcp14-tagged} The following terms are used: -client: The endpoint initiating the TLS connection. +client: +: The endpoint initiating the TLS connection. -connection: A transport-layer connection between two endpoints. +connection: +: A transport-layer connection between two endpoints. -endpoint: Either the client or server of the connection. +endpoint: +: Either the client or server of the connection. -handshake: An initial negotiation between client and server that establishes the parameters of their subsequent interactions within TLS. +handshake: +: An initial negotiation between client and server that establishes the parameters of their subsequent interactions within TLS. -peer: An endpoint. When discussing a particular endpoint, "peer" refers to the endpoint that is not the primary subject of discussion. +peer: +: An endpoint. When discussing a particular endpoint, "peer" refers to the endpoint that is not the primary subject of discussion. -receiver: An endpoint that is receiving records. +receiver: +: An endpoint that is receiving records. -sender: An endpoint that is transmitting records. +sender: +: An endpoint that is transmitting records. -server: The endpoint that did not initiate the TLS connection. +server: +: The endpoint that did not initiate the TLS connection. ## Relationship to RFC 8446 @@ -546,6 +643,20 @@ editorial improvements. In addition, it removes the use of the term names where no term was necessary. This document makes the following specific technical changes: + + + + - Forbid negotiating TLS 1.0 and 1.1 as they are now deprecated by {{!RFC8996}}. - Removes ambiguity around which hash is used with PreSharedKeys and @@ -587,14 +698,14 @@ are many minor differences. with Associated Data (AEAD) algorithms. The cipher suite concept has been changed to separate the authentication and key exchange mechanisms from the record protection algorithm (including secret key length) and a hash - to be used with both the key derivation function and handshake message - authentication code (MAC). + to be used with both the key derivation function and handshake Message + Authentication Code (MAC). - A zero round-trip time (0-RTT) mode was added, saving a round trip at connection setup for some application data, at the cost of certain security properties. - Static RSA and Diffie-Hellman cipher suites have been removed; - all public-key based key exchange mechanisms now provide forward secrecy. + all public-key-based key exchange mechanisms now provide forward secrecy. - All handshake messages after the ServerHello are now encrypted. The newly introduced EncryptedExtensions message allows various extensions @@ -610,12 +721,12 @@ are many minor differences. be more consistent and to remove superfluous messages such as ChangeCipherSpec (except when needed for middlebox compatibility). -- Elliptic curve algorithms are now in the base spec and new signature +- Elliptic curve algorithms are now in the base specification, and new signature algorithms, such as EdDSA, are included. TLS 1.3 removed point format negotiation in favor of a single point format for each curve. - Other cryptographic improvements were made, including changing the RSA padding to use - the RSA Probabilistic Signature Scheme (RSASSA-PSS), and the removal + the RSA Probabilistic Signature Scheme (RSASSA-PSS) and the removal of compression, the Digital Signature Algorithm (DSA), and custom Ephemeral Diffie-Hellman (DHE) groups. @@ -630,7 +741,6 @@ are many minor differences. - References have been updated to point to the updated versions of RFCs, as appropriate (e.g., RFC 5280 rather than RFC 3280). - ## Updates Affecting TLS 1.2 This document defines several changes that optionally affect @@ -681,27 +791,31 @@ TLS supports three basic key exchange modes: {{tls-full}} below shows the basic full TLS handshake: + + ~~~ aasvg - Client Server + Client Server Key ^ ClientHello Exch | + key_share* | + signature_algorithms* | + psk_key_exchange_modes* - v + pre_shared_key* --------> - ServerHello ^ Key - + key_share* | Exch - + pre_shared_key* v - {EncryptedExtensions} ^ Server - {CertificateRequest*} v Params - {Certificate*} ^ - {CertificateVerify*} | Auth - {Finished} v - <-------- [Application Data*] + v + pre_shared_key* --------> + ServerHello ^ Key + + key_share* | Exch + + pre_shared_key* v + {EncryptedExtensions} ^ Server + {CertificateRequest*} v Params + {Certificate*} ^ + {CertificateVerify*} | Auth + {Finished} v + <-------- [Application Data*] ^ {Certificate*} Auth | {CertificateVerify*} - v {Finished} --------> - [Application Data] <-------> [Application Data] + v {Finished} --------> + [Application Data] <-------> [Application Data] + Indicates noteworthy extensions sent in the previously noted message. @@ -717,6 +831,13 @@ Auth | {CertificateVerify*} ~~~ {: #tls-full title="Message Flow for Full TLS Handshake"} + + The handshake can be thought of as having three phases (indicated in the diagram above): @@ -758,12 +879,12 @@ The server then sends two messages to establish the Server Parameters: EncryptedExtensions: : responses to ClientHello extensions that are not required to determine the cryptographic parameters, other than those - that are specific to individual certificates. \[{{encrypted-extensions}}] + that are specific to individual certificates. {{encrypted-extensions}} CertificateRequest: : if certificate-based client authentication is desired, the desired parameters for that certificate. This message is - omitted if client authentication is not desired. \[{{certificate-request}}] + omitted if client authentication is not desired. {{certificate-request}} Finally, the client and server exchange Authentication messages. TLS uses the same set of messages every time that certificate-based @@ -780,19 +901,19 @@ Certificate: public keys {{RFC7250}} or the cached information extension {{?RFC7924}} are in use, then this message will not contain a certificate but rather some other value corresponding to - the server's long-term key. \[{{certificate}}] + the server's long-term key. {{certificate}} CertificateVerify: : A signature over the entire handshake using the private key corresponding to the public key in the Certificate message. This message is omitted if the endpoint is not authenticating via a - certificate. \[{{certificate-verify}}] + certificate. {{certificate-verify}} Finished: -: A MAC (Message Authentication Code) over the entire handshake. - This message provides key confirmation for the shared secrets established in the handshake +: A Message Authentication Code (MAC) over the entire handshake. + This message provides key confirmation for the shared secrets established in the handshake, binds the endpoint's identity to the exchanged keys, and in PSK mode - also authenticates the handshake. \[{{finished}}] + also authenticates the handshake. {{finished}} {:br } Upon receiving the server's messages, the client responds with its Authentication @@ -924,16 +1045,15 @@ When PSKs are provisioned externally, the PSK identity and the KDF hash algorithm to be used with the PSK MUST also be provisioned. -Note: -: When using an externally provisioned pre-shared secret, a critical - consideration is using sufficient entropy during the key generation, as - discussed in [RFC4086]. Deriving a shared secret from a password or other - low-entropy sources is not secure. A low-entropy secret, or password, is - subject to dictionary attacks based on the PSK binder. The specified PSK - authentication is not a strong password-based authenticated key exchange even - when used with Diffie-Hellman key establishment. Specifically, it does not - prevent an attacker that can observe the handshake from performing - a brute-force attack on the password/pre-shared key. +Note: When using an externally provisioned pre-shared secret, a critical +consideration is using sufficient entropy during the key generation, as +discussed in {{RFC4086}}. Deriving a shared secret from a password or other +low-entropy sources is not secure. A low-entropy secret, or password, is +subject to dictionary attacks based on the PSK binder. The specified PSK +authentication is not a strong password-based authenticated key exchange even +when used with Diffie-Hellman key establishment. Specifically, it does not +prevent an attacker that can observe the handshake from performing +a brute-force attack on the password/pre-shared key. ## 0-RTT Data {#zero-rtt-data} @@ -1239,27 +1359,17 @@ of a connection. Handshake messages are supplied to the TLS record layer, where they are encapsulated within one or more TLSPlaintext or TLSCiphertext structures which are processed and transmitted as specified by the current active connection state. -%%% Handshake Protocol enum { - hello_request_RESERVED(0), client_hello(1), server_hello(2), - hello_verify_request_RESERVED(3), new_session_ticket(4), end_of_early_data(5), - hello_retry_request_RESERVED(6), encrypted_extensions(8), certificate(11), - server_key_exchange_RESERVED(12), certificate_request(13), - server_hello_done_RESERVED(14), certificate_verify(15), - client_key_exchange_RESERVED(16), finished(20), - certificate_url_RESERVED(21), - certificate_status_RESERVED(22), - supplemental_data_RESERVED(23), key_update(24), message_hash(254), (255) @@ -1302,13 +1412,13 @@ the traffic keys used to protect the rest of the handshake and the data. In TLS, the cryptographic negotiation proceeds by the client offering the following four sets of options in its ClientHello: -- A list of cipher suites which indicates the AEAD algorithm/HKDF hash +- A list of cipher suites that indicates the AEAD algorithm / HKDF hash pairs which the client supports. - A "supported_groups" ({{supported-groups}}) extension which indicates the (EC)DHE groups - which the client supports and a "key_share" ({{key-share}}) extension which contains + that the client supports and a "key_share" ({{key-share}}) extension which contains (EC)DHE shares for some or all of these groups. - A "signature_algorithms" ({{signature-algorithms}}) extension which indicates the signature - algorithms which the client can accept. A "signature_algorithms_cert" extension ({{signature-algorithms}}) may also be + algorithms that the client can accept. A "signature_algorithms_cert" extension ({{signature-algorithms}}) may also be added to indicate certificate-specific signature algorithms. - A "pre_shared_key" ({{pre-shared-key-extension}}) extension which contains a list of symmetric key identities known to the client and a @@ -1317,7 +1427,7 @@ following four sets of options in its ClientHello: with PSKs. If the server does not select a PSK, then the first three of these -options are entirely orthogonal: the server independently selects a +options are entirely orthogonal: The server independently selects a cipher suite, an (EC)DHE group and key share for key establishment, and a signature algorithm/certificate pair to authenticate itself to the client. If there is no overlap between the received "supported_groups" @@ -1348,7 +1458,7 @@ follows: - When authenticating via a certificate, the server will send the Certificate ({{certificate}}) and CertificateVerify - ({{certificate-verify}}) messages. In TLS 1.3 + ({{certificate-verify}}) messages. In TLS 1.3, as defined by this document, either a PSK or a certificate is always used, but not both. Future documents may define how to use them together. @@ -1399,8 +1509,7 @@ previous protocol version. In particular, it MUST NOT negotiate TLS 1.3. Structure of this message: -%%% Key Exchange Messages - +~~~ uint16 ProtocolVersion; opaque Random[32]; @@ -1414,6 +1523,8 @@ Structure of this message: opaque legacy_compression_methods<1..2^8-1>; Extension extensions<8..2^16-1>; } ClientHello; +~~~ +{: gi="sourcecode"} legacy_version: : In previous versions of TLS, this field was used for version negotiation @@ -1519,8 +1630,7 @@ set of handshake parameters based on the ClientHello. Structure of this message: -%%% Key Exchange Messages - +~~~ struct { ProtocolVersion legacy_version = 0x0303; /* TLS v1.2 */ Random random; @@ -1529,6 +1639,8 @@ Structure of this message: uint8 legacy_compression_method = 0; Extension extensions<6..2^16-1>; } ServerHello; +~~~ +{: gi="sourcecode"} legacy_version: : In previous versions of TLS, this field was used for version negotiation @@ -1577,7 +1689,7 @@ extensions: which are required to establish the cryptographic context and negotiate the protocol version. All TLS 1.3 ServerHello messages MUST contain the "supported_versions" extension. Current ServerHello messages additionally contain - either the "pre_shared_key" extension or the "key_share" extension, or both (when using + the "pre_shared_key" extension, "key_share" extension, or both (when using a PSK with (EC)DHE key establishment). Other extensions (see {{extensions}}) are sent separately in the EncryptedExtensions message. @@ -1585,7 +1697,7 @@ extensions: For reasons of backward compatibility with middleboxes (see {{middlebox}}), the HelloRetryRequest -message uses the same structure as the ServerHello, but with +message uses the same structure as the ServerHello but with Random set to the special value of the SHA-256 of "HelloRetryRequest": @@ -1594,7 +1706,7 @@ Random set to the special value of the SHA-256 of Upon receiving a message with type server_hello, implementations MUST first examine the Random value and, if it matches -this value, process it as described in {{hello-retry-request}}). +this value, process it as described in {{hello-retry-request}}. TLS 1.3 has a downgrade protection mechanism embedded in the server's random value. TLS 1.3 servers which negotiate TLS 1.2 or below in @@ -1701,7 +1813,6 @@ handshake with an "illegal_parameter" alert if the value changes. A number of TLS messages contain tag-length-value encoded extensions structures. -%%% Key Exchange Messages struct { ExtensionType extension_type; @@ -1759,7 +1870,7 @@ response (i.e., indications). The client sends its extension requests in the ClientHello message, and the server sends its extension responses in the ServerHello, EncryptedExtensions, HelloRetryRequest, and Certificate messages. The server sends extension requests in the -CertificateRequest message which a client MAY respond to with a +CertificateRequest message, which a client MAY respond to with a Certificate message. The server MAY also send unsolicited extensions in the NewSessionTicket, though the client does not respond directly to these. @@ -1781,49 +1892,69 @@ it recognizes and which is not specified for the message in which it appears, it MUST abort the handshake with an "illegal_parameter" alert. + + | Extension | TLS 1.3 | |:-----------------------------------------|------------:| -| server_name [RFC6066] | CH, EE | -| max_fragment_length [RFC6066] | CH, EE | -| status_request [RFC6066] | CH, CR, CT | -| supported_groups [RFC7919] | CH, EE | -| signature_algorithms [RFC8446] | CH, CR | -| use_srtp [RFC5764] | CH, EE | -| heartbeat [RFC6520] | CH, EE | -| application_layer_protocol_negotiation [RFC7301]| CH, EE | -| signed_certificate_timestamp [RFC6962] | CH, CR, CT | -| client_certificate_type [RFC7250] | CH, EE | -| server_certificate_type [RFC7250] | CH, EE | -| padding [RFC7685] | CH | -| cached_info [RFC7924] | CH, EE | -| compress_certificate [RFC8879] | CH, CR | -| record_size_limit [RFC8849] | CH, EE | -| delegated_credentials [RFC9345] | CH, CR, CT | -| supported_ekt_ciphers [RFC8870] | CH, EE | -| pre_shared_key [RFC8446] | CH, SH | -| early_data [RFC8446] | CH, EE, NST | -| psk_key_exchange_modes [RFC8446]| CH | -| cookie [RFC8446] | CH, HRR | -| supported_versions [RFC8446] | CH, SH, HRR | -| certificate_authorities [RFC8446]| CH, CR | -| oid_filters [RFC8446] | CR | -| post_handshake_auth [RFC8446] | CH | -| signature_algorithms_cert [RFC8446]| CH, CR | -| key_share [RFC8446] | CH, SH, HRR | -| transparency_info [RFC9162] | CH, CR, CT | -| connection_id [RFC9146] | CH, SH | -| external_id_hash [RFC8844] | CH, EE | -| external_session_id [RFC8844] | CH, EE | -| quic_transport_parameters [RFC9001] | CH, EE | -| ticket_request [RFC9149] | CH, EE| +| server_name {{RFC6066}} | CH, EE | +| max_fragment_length {{RFC6066}} | CH, EE | +| status_request {{RFC6066}} | CH, CR, CT | +| supported_groups {{RFC7919}} | CH, EE | +| signature_algorithms {{RFC8446}} | CH, CR | +| use_srtp {{RFC5764}} | CH, EE | +| heartbeat {{RFC6520}} | CH, EE | +| application_layer_protocol_negotiation {{RFC7301}}| CH, EE | +| signed_certificate_timestamp {{RFC6962}} | CH, CR, CT | +| client_certificate_type {{RFC7250}} | CH, EE | +| server_certificate_type {{RFC7250}} | CH, EE | +| padding {{RFC7685}} | CH | +| cached_info {{RFC7924}} | CH, EE | +| compress_certificate {{RFC8879}} | CH, CR | +| record_size_limit {{RFC8449}} | CH, EE | +| delegated_credentials {{RFC9345}} | CH, CR, CT | +| supported_ekt_ciphers {{RFC8870}} | CH, EE | +| pre_shared_key {{RFC8446}} | CH, SH | +| early_data {{RFC8446}} | CH, EE, NST | +| psk_key_exchange_modes {{RFC8446}}| CH | +| cookie {{RFC8446}} | CH, HRR | +| supported_versions {{RFC8446}} | CH, SH, HRR | +| certificate_authorities {{RFC8446}}| CH, CR | +| oid_filters {{RFC8446}} | CR | +| post_handshake_auth {{RFC8446}} | CH | +| signature_algorithms_cert {{RFC8446}}| CH, CR | +| key_share {{RFC8446}} | CH, SH, HRR | +| transparency_info {{RFC9162}} | CH, CR, CT | +| connection_id {{RFC9146}} | CH, SH | +| external_id_hash {{RFC8844}} | CH, EE | +| external_session_id {{RFC8844}} | CH, EE | +| quic_transport_parameters {{RFC9001}} | CH, EE | +| ticket_request {{RFC9149}} | CH, EE| {: #extensions-list title="TLS Extensions"} -Note: this table includes only extensions marked +Note: This table only includes extensions marked as "Recommended" at the time of this writing. When multiple extensions of different types are present, the extensions MAY appear in any order, with the exception of -"pre_shared_key" ({{pre-shared-key-extension}}) which MUST be +"pre_shared_key" ({{pre-shared-key-extension}}), which MUST be the last extension in the ClientHello (but can appear anywhere in the ServerHello extensions block). There MUST NOT be more than one extension of the same type in a given @@ -1835,7 +1966,7 @@ those negotiated in the previous handshake; mismatches may require rejecting 0-RTT (see {{early-data-indication}}). There are subtle (and not so subtle) interactions that may occur in this -protocol between new features and existing features which may result in a +protocol between new features and existing features, which may result in a significant reduction in overall security. The following considerations should be taken into account when designing new extensions: @@ -1858,7 +1989,6 @@ be taken into account when designing new extensions: ### Supported Versions -%%% Version Extension struct { select (Handshake.msg_type) { @@ -1920,7 +2050,6 @@ client or contains a version prior to TLS 1.3, the client MUST abort the handsha ### Cookie -%%% Cookie Extension struct { opaque cookie<1..2^16-1>; @@ -1978,7 +2107,6 @@ MAY omit the "signature_algorithms_cert" extension. The "extension_data" field of these extensions contains a SignatureSchemeList value: -%%% Signature Algorithm Extension enum { /* RSASSA-PKCS1-v1_5 algorithms */ @@ -2010,15 +2138,6 @@ SignatureSchemeList value: ecdsa_sha1(0x0203), /* Reserved Code Points */ - obsolete_RESERVED(0x0000..0x0200), - dsa_sha1_RESERVED(0x0202), - obsolete_RESERVED(0x0204..0x0400), - dsa_sha256_RESERVED(0x0402), - obsolete_RESERVED(0x0404..0x0500), - dsa_sha384_RESERVED(0x0502), - obsolete_RESERVED(0x0504..0x0600), - dsa_sha512_RESERVED(0x0602), - obsolete_RESERVED(0x0604..0x06FF), private_use(0xFE00..0xFFFF), (0xFFFF) } SignatureScheme; @@ -2080,7 +2199,7 @@ RSASSA-PSS PSS algorithms: Legacy algorithms: : Indicates algorithms which are being deprecated because they use - algorithms with known weaknesses, specifically SHA-1 which is used + algorithms with known weaknesses, specifically SHA-1, which is used in this context with either (1) RSA using RSASSA-PKCS1-v1_5 or (2) ECDSA. These values refer solely to signatures which appear in certificates (see {{certificate-selection}}) and are not defined for use in @@ -2098,7 +2217,7 @@ Legacy algorithms: The signatures on certificates that are self-signed or certificates that are trust anchors are not validated, since they begin a certification path (see -{{RFC5280}}, Section 3.2). A certificate that begins a certification +{{RFC5280, Section 3.2}}). A certificate that begins a certification path MAY use a signature algorithm that is not advertised as being supported in the "signature_algorithms" and "signature_algorithms_cert" extensions. @@ -2134,7 +2253,6 @@ be used by the receiving endpoint to guide certificate selection. The body of the "certificate_authorities" extension consists of a CertificateAuthoritiesExtension structure. -%%% Server Parameters Messages opaque DistinguishedName<1..2^16-1>; @@ -2154,7 +2272,7 @@ The client MAY send the "certificate_authorities" extension in the ClientHello message. The server MAY send it in the CertificateRequest message. The "trusted_ca_keys" extension {{RFC6066}}, which serves a similar -purpose, but is more complicated, is not used in TLS 1.3 +purpose but is more complicated, is not used in TLS 1.3 (although it may appear in ClientHello messages from clients which are offering prior versions of TLS). @@ -2164,7 +2282,6 @@ The "oid_filters" extension allows servers to provide a list of OID/value pairs which it would like the client's certificate to match. This extension, if provided by the server, MUST only be sent in the CertificateRequest message. -%%% Server Parameters Messages struct { opaque certificate_extension_oid<1..2^8-1>; @@ -2188,7 +2305,7 @@ filters: and skip any unrecognized certificate extension OIDs. If the client ignored some of the required certificate extension OIDs and supplied a certificate that does not satisfy the request, the server MAY at its discretion either - continue the connection without client authentication or abort the handshake + continue the connection without client authentication, or abort the handshake with an "unsupported_certificate" alert. Any given OID MUST NOT appear more than once in the filters list. @@ -2220,7 +2337,6 @@ to perform post-handshake authentication ({{post-handshake-authentication}}). Se MUST NOT send a post-handshake CertificateRequest to clients which do not offer this extension. Servers MUST NOT send this extension. -%%% Server Parameters Messages struct {} PostHandshakeAuth; @@ -2241,15 +2357,11 @@ ECDSA curves. Signature algorithms are now negotiated independently (see The "extension_data" field of this extension contains a "NamedGroupList" value: -%%% Supported Groups Extension enum { - unallocated_RESERVED(0x0000), /* Elliptic Curve Groups (ECDHE) */ - obsolete_RESERVED(0x0001..0x0016), secp256r1(0x0017), secp384r1(0x0018), secp521r1(0x0019), - obsolete_RESERVED(0x001A..0x001C), x25519(0x001D), x448(0x001E), /* Finite Field Groups (DHE) */ @@ -2259,7 +2371,6 @@ The "extension_data" field of this extension contains a /* Reserved Code Points */ ffdhe_private_use(0x01FC..0x01FF), ecdhe_private_use(0xFE00..0xFEFF), - obsolete_RESERVED(0xFF01..0xFF02), (0xFFFF) } NamedGroup; @@ -2304,7 +2415,6 @@ Clients MAY send an empty client_shares list to request group selection from the server, at the cost of an additional round trip (see {{hello-retry-request}}). -%%% Key Exchange Messages struct { NamedGroup group; @@ -2327,7 +2437,6 @@ key_exchange: In the ClientHello message, the "extension_data" field of this extension contains a "KeyShareClientHello" value: -%%% Key Exchange Messages struct { KeyShareEntry client_shares<0..2^16-1>; } KeyShareClientHello; @@ -2358,7 +2467,7 @@ Clients can offer as many KeyShareEntry values as the number of supported groups it is offering, each representing a single set of key exchange parameters. For instance, a client might offer shares for several elliptic curves or multiple -FFDHE groups. The key_exchange values for each KeyShareEntry MUST be +Finite Field DHE (FFDHE) groups. The key_exchange values for each KeyShareEntry MUST be generated independently. Clients MUST NOT offer multiple KeyShareEntry values for the same group. Clients MUST NOT offer any KeyShareEntry values for groups not listed in the client's @@ -2369,7 +2478,6 @@ if one is violated. In a HelloRetryRequest message, the "extension_data" field of this extension contains a KeyShareHelloRetryRequest value: -%%% Key Exchange Messages struct { NamedGroup selected_group; } KeyShareHelloRetryRequest; @@ -2393,7 +2501,6 @@ selected_group field of the triggering HelloRetryRequest. In a ServerHello message, the "extension_data" field of this extension contains a KeyShareServerHello value: -%%% Key Exchange Messages struct { KeyShareEntry server_share; } KeyShareServerHello; @@ -2421,7 +2528,7 @@ alert. Diffie-Hellman {{DH76}} parameters for both clients and servers are encoded in the opaque key_exchange field of a KeyShareEntry in a KeyShare structure. The opaque value contains the -Diffie-Hellman public value (Y = g^X mod p) for the specified group +Diffie-Hellman public value (Y = gX mod p) for the specified group (see {{RFC7919}} for group definitions) encoded as a big-endian integer and padded to the left with zeros to the size of p in bytes. @@ -2441,7 +2548,6 @@ opaque key_exchange field of a KeyShareEntry in a KeyShare structure. For secp256r1, secp384r1, and secp521r1, the contents are the serialized value of the following struct: -%%% Key Exchange Messages struct { uint8 legacy_form = 4; @@ -2469,7 +2575,7 @@ equation. For these curves, implementors do not need to verify membership in the correct subgroup. For X25519 and X448, the content of the public value is the K_A -or K_B value described in Section 6 of {{RFC7748}}. +or K_B value described in {{Section 6 of RFC7748}}. This is 32 bytes for X25519 and 56 bytes for X448. Note: Versions of TLS prior to 1.3 permitted point format negotiation; @@ -2495,7 +2601,6 @@ will just be that the client's attempts at resumption fail. The server MUST NOT send a "psk_key_exchange_modes" extension. -%%% Key Exchange Messages enum { psk_ke(0), psk_dhe_ke(1), (255) } PskKeyExchangeMode; @@ -2521,14 +2626,13 @@ in the ServerHello. ### Early Data Indication When a PSK is used and early data is allowed for that PSK -(see for instance {{ticket-establishment}}), the client can send Application Data +(for instance, see {{ticket-establishment}}), the client can send Application Data in its first flight of messages. If the client opts to do so, it MUST supply both the "pre_shared_key" and "early_data" extensions. The "extension_data" field of this extension contains an "EarlyDataIndication" value. -%%% Key Exchange Messages struct {} Empty; @@ -2553,10 +2657,10 @@ MUST be the first PSK listed in the client's "pre_shared_key" extension. For PSKs provisioned via NewSessionTicket, a server MUST validate that the ticket age for the selected PSK identity (computed by subtracting -ticket_age_add from PskIdentity.obfuscated_ticket_age modulo 2^32) +ticket_age_add from PskIdentity.obfuscated_ticket_age modulo 232) is within a small tolerance of the time since the ticket was issued (see {{anti-replay}}). If it is not, -the server SHOULD proceed with the handshake but reject 0-RTT, and +the server SHOULD proceed with the handshake but reject 0-RTT and SHOULD NOT take any other action that assumes that this ClientHello is fresh. @@ -2647,7 +2751,6 @@ with PSK key establishment. The "extension_data" field of this extension contains a "PreSharedKeyExtension" value: -%%% Key Exchange Messages struct { opaque identity<1..2^16-1>; @@ -2705,19 +2808,19 @@ is defined. The server MUST ensure that it selects a compatible PSK (if any) and cipher suite. In TLS versions prior to TLS 1.3, the Server Name Indication (SNI) value was -intended to be associated with the session (Section 3 of {{RFC6066}}), with the +intended to be associated with the session ({{Section 3 of RFC6066}}), with the server being required to enforce that the SNI value associated with the session matches the one specified in the resumption handshake. However, in reality the implementations were not consistent on which of two supplied SNI values they would use, leading to the consistency requirement being de facto enforced by the clients. In TLS 1.3, the SNI value is always explicitly specified in the resumption handshake, and there is no need for the server to associate an SNI value with the -ticket. Clients, however, SHOULD store the SNI with the PSK to fulfill +ticket. However, clients SHOULD store the SNI with the PSK to fulfill the requirements of {{NSTMessage}}. Implementor's note: When session resumption is the primary use case of PSKs, the most straightforward way to implement the -PSK/cipher suite matching requirements is to negotiate the cipher +PSK / cipher suite matching requirements is to negotiate the cipher suite first and then exclude any incompatible PSKs. Any unknown PSKs (e.g., ones not in the PSK database or encrypted with an unknown key) SHOULD simply be ignored. If no acceptable PSKs are @@ -2729,7 +2832,7 @@ Prior to accepting PSK key establishment, the server MUST validate the corresponding binder value (see {{psk-binder}} below). If this value is not present or does not validate, the server MUST abort the handshake. Servers SHOULD NOT attempt to validate multiple binders; rather, they -SHOULD select a single PSK and validate solely the binder that +SHOULD select a single PSK and solely validate the binder that corresponds to that PSK. See {{client-hello-recording}} and {{psk-identity-exposure}} for the security rationale for this requirement. @@ -2763,7 +2866,7 @@ tickets which have ages greater than the "ticket_lifetime" value which was provided with the ticket. The "obfuscated_ticket_age" field of each PskIdentity contains an obfuscated version of the ticket age formed by taking the age in milliseconds and adding the "ticket_age_add" -value that was included with the ticket (see {{NSTMessage}}), modulo 2^32. +value that was included with the ticket (see {{NSTMessage}}), modulo 232. This addition prevents passive observers from correlating connections unless tickets or key shares are reused. Note that the "ticket_lifetime" field in the NewSessionTicket message is in seconds but the "obfuscated_ticket_age" @@ -2797,7 +2900,7 @@ binder will be computed over: Transcript-Hash(Truncate(ClientHello1)) -Where Truncate() removes the binders list from the ClientHello. +where Truncate() removes the binders list from the ClientHello. Note that this hash will be computed using the hash associated with the PSK, as the client does not know which cipher suite the server will select. @@ -2852,11 +2955,12 @@ extensions and if any are found MUST abort the handshake with an Structure of this message: -%%% Server Parameters Messages - +~~~ struct { Extension extensions<0..2^16-1>; } EncryptedExtensions; +~~~ +{: gi="sourcecode"} extensions: : A list of extensions. For more information, see the table in {{extensions}}. @@ -2865,17 +2969,18 @@ extensions: ### Certificate Request A server which is authenticating with a certificate MAY optionally -request a certificate from the client. This message, if sent, MUST +request a certificate from the client. If sent, this message MUST follow EncryptedExtensions. Structure of this message: -%%% Server Parameters Messages - +~~~ struct { opaque certificate_request_context<0..2^8-1>; Extension extensions<0..2^16-1>; } CertificateRequest; +~~~ +{: gi="sourcecode"} certificate_request_context: : An opaque string which identifies the certificate request and @@ -2914,9 +3019,9 @@ provided that the client has sent the "post_handshake_auth" extension (see {{post_handshake_auth}}). In the absence of some other specification to the contrary, servers which are authenticating with an external PSK -MUST NOT send the CertificateRequest message either in the main handshake +MUST NOT send the CertificateRequest message in the main handshake or request post-handshake authentication. -{{RFC8773}} provides an extension to permit this, +{{RFC8773}} provides an extension to permit this but has received less analysis than this specification. ## Authentication Messages @@ -2924,14 +3029,14 @@ but has received less analysis than this specification. As discussed in {{protocol-overview}}, TLS generally uses a common set of messages for authentication, key confirmation, and handshake integrity: Certificate, CertificateVerify, and Finished. -(The PSK binders also perform key confirmation, in a +(The PSK binders also perform key confirmation in a similar fashion.) These three messages are always sent as the last messages in their handshake flight. The Certificate and CertificateVerify messages are only sent under certain circumstances, as defined below. The Finished message is always sent as part of the Authentication Block. These messages are encrypted under keys derived from the -\[sender]_handshake_traffic_secret, +\[sender\]_handshake_traffic_secret, except for post-handshake authentication. The computations for the Authentication messages all uniformly @@ -2944,20 +3049,22 @@ take the following inputs: Based on these inputs, the messages then contain: -Certificate +Certificate: : The certificate to be used for authentication, and any supporting certificates in the chain. Note that certificate-based client authentication is not available in PSK handshake flows (including 0-RTT). CertificateVerify: -: A signature over the value Transcript-Hash(Handshake Context, Certificate) +: A signature over the value Transcript-Hash(Handshake Context, Certificate). Finished: : A MAC over the value Transcript-Hash(Handshake Context, Certificate, CertificateVerify) using a MAC key derived from the Base Key. {:br} + The following table defines the Handshake Context and MAC Base Key for each scenario: @@ -2966,7 +3073,7 @@ for each scenario: |------|-------------------|----------| | Server | ClientHello ... later of EncryptedExtensions/CertificateRequest | server_handshake_traffic_secret | | Client | ClientHello ... later of server Finished/EndOfEarlyData | client_handshake_traffic_secret | -| Post-Handshake | ClientHello ... client Finished + CertificateRequest | [sender]_application_traffic_secret_N | +| Post-Handshake | ClientHello ... client Finished + CertificateRequest | \[sender\]_application_traffic_secret_N | {: #hs-ctx-and-keys title="Authentication Inputs"} ### The Transcript Hash @@ -2974,15 +3081,15 @@ for each scenario: Many of the cryptographic computations in TLS make use of a transcript hash. This value is computed by hashing the concatenation of each included handshake message, including the handshake -message header carrying the handshake message type and length fields, -but not including record layer headers. I.e., +message header carrying the handshake message type and length fields +but not including record layer headers. That is, Transcript-Hash(M1, M2, ... Mn) = Hash(M1 || M2 || ... || Mn) As an exception to this general rule, when the server responds to a ClientHello with a HelloRetryRequest, the value of ClientHello1 is replaced with a special synthetic handshake message of handshake -type "message_hash" containing Hash(ClientHello1). I.e., +type "message_hash" containing Hash(ClientHello1). That is, Transcript-Hash(ClientHello1, HelloRetryRequest, ... Mn) = Hash(message_hash || /* Handshake type */ @@ -3004,8 +3111,8 @@ server CertificateVerify, server Finished, EndOfEarlyData, client Certificate, client CertificateVerify, and client Finished. In general, implementations can implement the transcript by keeping a -running transcript hash value based on the negotiated hash. Note, -however, that subsequent post-handshake authentications do not include +running transcript hash value based on the negotiated hash. However, +note that subsequent post-handshake authentications do not include each other, just the messages through the end of the main handshake. ### Certificate @@ -3026,11 +3133,9 @@ be sent regardless of whether the Certificate message is empty. Structure of this message: -%%% Authentication Messages - +~~~ enum { X509(0), - OpenPGP_RESERVED(1), RawPublicKey(2), (255) } CertificateType; @@ -3051,6 +3156,8 @@ Structure of this message: opaque certificate_request_context<0..2^8-1>; CertificateEntry certificate_list<0..2^24-1>; } Certificate; +~~~ +{: gi="sourcecode"} certificate_request_context: : If this message is in response to a CertificateRequest, the @@ -3096,8 +3203,8 @@ version, with the exception of the end-entity certificate which MUST be first. If the RawPublicKey certificate type was negotiated, then the certificate_list MUST contain no more than one CertificateEntry, which -contains an ASN1_subjectPublicKeyInfo value as defined in {{RFC7250}}, -Section 3. +contains an ASN1_subjectPublicKeyInfo value as defined in {{RFC7250, +Section 3}}. The OpenPGP certificate type {{RFC6091}} MUST NOT be used with TLS 1.3. @@ -3167,7 +3274,7 @@ The following rule additionally applies to certificates sent by the server: clients SHOULD send this extension when the server is identified by name. All certificates provided by the sender MUST be signed by a -signature algorithm advertised by the peer, if it is able to provide such +signature algorithm advertised by the peer if it is able to provide such a chain (see {{signature-algorithms}}). Certificates that are self-signed or certificates that are expected to be trust anchors are not validated as @@ -3181,7 +3288,7 @@ to be supported by the client. This fallback chain MUST NOT use the deprecated SHA-1 hash, unless the client specifically advertises that it is willing to accept SHA-1. -If the sender is the client, the client MAY use a fallback chain as above, or +If the sender is the client, the client MAY use a fallback chain as above or continue the handshake anonymously. If the receiver cannot construct an acceptable chain using the provided @@ -3203,7 +3310,7 @@ the handshake with a "decode_error" alert. If the client does not send any certificates (i.e., it sends an empty Certificate message), the server MAY at its discretion either continue the handshake without client -authentication, or abort the handshake with a "certificate_required" alert. Also, if some +authentication or abort the handshake with a "certificate_required" alert. Also, if some aspect of the certificate chain was unacceptable (e.g., it was not signed by a known, trusted CA), the server MAY at its discretion either continue the handshake (considering the client unauthenticated) or abort the handshake. @@ -3237,12 +3344,13 @@ after the Certificate message and immediately prior to the Finished message. Structure of this message: -%%% Authentication Messages - +~~~ struct { SignatureScheme algorithm; opaque signature<0..2^16-1>; } CertificateVerify; +~~~ +{: gi="sourcecode"} The algorithm field specifies the signature algorithm used (see {{signature-algorithms}} for the definition of this type). The @@ -3266,9 +3374,9 @@ prefix (ClientHello.random). The initial 64-byte pad clears that prefix along with the server-controlled ServerHello.random. The context string for a server signature is -"TLS 1.3, server CertificateVerify" +"TLS 1.3, server CertificateVerify". The context string for a client signature is -"TLS 1.3, client CertificateVerify" +"TLS 1.3, client CertificateVerify". It is used to provide separation between signatures made in different contexts, helping against potential cross-protocol attacks. @@ -3337,6 +3445,7 @@ settings in which it is permitted to send data prior to receiving the peer's Finished: 1. Clients sending 0-RTT data as described in {{early-data-indication}}. + 2. Servers MAY send data after sending their first flight, but because the handshake is not yet complete, they have no assurance of either the peer's identity or its liveness (i.e., @@ -3350,24 +3459,34 @@ Base Key defined in {{authentication-messages}} using HKDF (see finished_key = HKDF-Expand-Label(BaseKey, "finished", "", Hash.length) ~~~ +{: gi="sourcecode"} Structure of this message: -%%% Authentication Messages - +~~~ struct { opaque verify_data[Hash.length]; } Finished; - +~~~ +{: gi="sourcecode"} The verify_data value is computed as follows: +~~~ verify_data = HMAC(finished_key, Transcript-Hash(Handshake Context, Certificate*, CertificateVerify*)) +~~~ +{: gi="sourcecode"} + + - * Only included if present. +* Only included if present. HMAC {{RFC2104}} uses the Hash algorithm for the handshake. As noted above, the HMAC input can generally be implemented by a running @@ -3387,7 +3506,6 @@ server in response to client Certificate and CertificateVerify messages. ## End of Early Data -%%% Updating Keys struct {} EndOfEarlyData; @@ -3410,7 +3528,7 @@ appropriate application traffic key. ### New Session Ticket Message {#NSTMessage} -If the client's hello contained a suitable "psk_key_exchange_modes" extension, +If the client's hello contained a suitable "psk_key_exchange_modes" extension at any time after the server has received the client Finished message, it MAY send a NewSessionTicket message. This message creates a unique association between the ticket value and a secret PSK @@ -3426,13 +3544,13 @@ original connection is still open. Servers MAY send multiple tickets on a single connection, either immediately after each other or after specific events (see {{client-tracking}}). For instance, the server might send a new ticket after post-handshake -authentication thus encapsulating the additional client +authentication, thus encapsulating the additional client authentication state. Multiple tickets are useful for clients for a variety of purposes, including: - Opening multiple parallel HTTP connections. - Performing connection racing across interfaces and address families -via (for example) Happy Eyeballs {{RFC8305}} or related techniques. +via, for example, Happy Eyeballs {{RFC8305}} or related techniques. Any ticket MUST only be resumed with a cipher suite that has the same KDF hash algorithm as that used to establish the original connection. @@ -3464,7 +3582,6 @@ parallel and would benefit from the reduced overhead of a resumption handshake, for example. -%%% Ticket Establishment struct { uint32 ticket_lifetime; @@ -3488,7 +3605,7 @@ ticket_lifetime: ticket_age_add: : A securely generated, random 32-bit value that is used to obscure the age of the ticket that the client includes in the "pre_shared_key" extension. - The client-side ticket age is added to this value modulo 2^32 to + The client-side ticket age is added to this value modulo 232 to obtain the value that is transmitted by the client. The server MUST generate a fresh value for each ticket it sends. @@ -3527,6 +3644,7 @@ The PSK associated with the ticket is computed as: HKDF-Expand-Label(resumption_secret, "resumption", ticket_nonce, Hash.length) ~~~~ +{: gi="sourcecode"} Because the ticket_nonce value is distinct for each NewSessionTicket message, a different PSK will be derived for each ticket. @@ -3566,7 +3684,7 @@ received (the certificate_request_context value allows the server to disambiguate the responses). -### Key and Initialization Vector Update {#key-update} +### Key and Initialization Vector (IV) Update {#key-update} The KeyUpdate handshake message is used to indicate that the sender is updating its sending cryptographic keys. This message can be sent by @@ -3578,7 +3696,6 @@ next generation of keys, computed as described in {{updating-traffic-keys}}. Upon receiving a KeyUpdate, the receiver MUST update its receiving keys. -%%% Updating Keys enum { update_not_requested(0), update_requested(1), (255) @@ -3624,21 +3741,21 @@ a KeyUpdate with the old key is received before accepting any messages encrypted with the new key. Failure to do so may allow message truncation attacks. -With a 128-bit key as in AES-128, rekeying 2^64 times has a high +With a 128-bit key as in AES-128, rekeying 264 times has a high probability of key reuse within a given connection. Note that even if the key repeats, the IV is also independently generated, so the chance of a joint key/IV collision is much lower. To provide an extra margin of security, sending implementations MUST NOT allow the epoch -- and hence the number of key updates -- -to exceed 2^48-1. In order to allow this value to be changed later --- for instance for ciphers with more than 128-bit keys -- +to exceed 248-1. In order to allow this value to be changed later +-- for instance, for ciphers with more than 128-bit keys -- receiving implementations MUST NOT enforce this rule. If a sending implementation receives a KeyUpdate with request_update set to "update_requested", it MUST NOT send its own KeyUpdate if that would cause it to exceed these limits and SHOULD instead ignore the "update_requested" flag. This may result in an eventual need to terminate the connection when the -limits in {{limits-on-key-usage}} are reached. +limits described in {{limits-on-key-usage}} are reached. # Record Protocol @@ -3676,13 +3793,13 @@ Implementations MUST NOT send record types not defined in this document unless negotiated by some extension. If a TLS implementation receives an unexpected record type, it MUST terminate the connection with an "unexpected_message" alert. New record content type values -are assigned by IANA in the TLS ContentType registry as described in +are assigned by IANA in the "TLS ContentType" registry as described in {{iana-considerations}}. ## Record Layer The record layer fragments information blocks into TLSPlaintext -records carrying data in chunks of 2^14 bytes or less. Message +records carrying data in chunks of 214 bytes or less. Message boundaries are handled differently depending on the underlying ContentType. Any future content types MUST specify appropriate rules. @@ -3719,7 +3836,6 @@ useful as a traffic analysis countermeasure. Application Data fragments MAY be split across multiple records or coalesced into a single record. -%%% Record Layer enum { invalid(0), @@ -3751,7 +3867,7 @@ legacy_record_version: length: : The length (in bytes) of the following TLSPlaintext.fragment. The - length MUST NOT exceed 2^14 bytes. An endpoint that receives a record + length MUST NOT exceed 214 bytes. An endpoint that receives a record that exceeds this length MUST terminate the connection with a "record_overflow" alert. @@ -3789,7 +3905,6 @@ operation which turns plaintext into authenticated ciphertext and back again. Each encrypted record consists of a plaintext header followed by an encrypted body, which itself contains a type and optional padding. -%%% Record Layer struct { opaque content[TLSPlaintext.length]; @@ -3837,7 +3952,7 @@ length: : The length (in bytes) of the following TLSCiphertext.encrypted_record, which is the sum of the lengths of the content and the padding, plus one for the inner content type, plus any expansion added by the AEAD algorithm. - The length MUST NOT exceed 2^14 + 256 bytes. + The length MUST NOT exceed 214 + 256 bytes. An endpoint that receives a record that exceeds this length MUST terminate the connection with a "record_overflow" alert. @@ -3847,11 +3962,11 @@ encrypted_record: AEAD algorithms take as input a single key, a nonce, a plaintext, and "additional -data" to be included in the authentication check, as described in Section 2.1 -of {{RFC5116}}. The key is either the client_write_key or the server_write_key, +data" to be included in the authentication check, as described in {{Section 2.1 +of RFC5116}}. The key is either the client_write_key or the server_write_key, the nonce is derived from the sequence number and the client_write_iv or server_write_iv (see {{nonce}}), and the additional data input is the -record header. I.e., +record header. That is, additional_data = TLSCiphertext.opaque_type || TLSCiphertext.legacy_record_version || @@ -3879,18 +3994,18 @@ additional data, and the AEADEncrypted value. The output is either the plaintext or an error indicating that the decryption failed. There is no separate integrity check. Symbolically, - plaintext of encrypted_record = - AEAD-Decrypt(peer_write_key, nonce, additional_data, AEADEncrypted) + plaintext of encrypted_record = + AEAD-Decrypt(peer_write_key, nonce, additional_data, AEADEncrypted) If the decryption fails, the receiver MUST terminate the connection with a "bad_record_mac" alert. An AEAD algorithm used in TLS 1.3 MUST NOT produce an expansion greater than 255 octets. An endpoint that receives a record from its peer with -TLSCiphertext.length larger than 2^14 + 256 octets MUST terminate +TLSCiphertext.length larger than 214 + 256 octets MUST terminate the connection with a "record_overflow" alert. This limit is derived from the maximum TLSInnerPlaintext length of -2^14 octets + 1 octet for ContentType + the maximum AEAD expansion of 255 octets. +214 octets + 1 octet for ContentType + the maximum AEAD expansion of 255 octets. ## Per-Record Nonce {#nonce} @@ -3903,7 +4018,7 @@ first record transmitted under a particular traffic key MUST use sequence number 0. -Because the size of sequence numbers is 64-bit, they should not +Because the size of sequence numbers is 64 bits, they should not wrap. If a TLS implementation would need to wrap a sequence number, it MUST either rekey ({{key-update}}) or terminate the connection. @@ -3911,15 +4026,15 @@ terminate the connection. Each AEAD algorithm will specify a range of possible lengths for the per-record nonce, from N_MIN bytes to N_MAX bytes of input {{RFC5116}}. The length of the TLS per-record nonce (iv_length) is set to the larger of -8 bytes and N_MIN for the AEAD algorithm (see {{RFC5116}}, Section 4). +8 bytes and N_MIN for the AEAD algorithm (see {{RFC5116, Section 4}}). An AEAD algorithm where N_MAX is less than 8 bytes MUST NOT be used with TLS. The per-record nonce for the AEAD construction is formed as follows: - 1. The 64-bit record sequence number is encoded in network byte order - and padded to the left with zeros to iv_length. +1. The 64-bit record sequence number is encoded in network byte order + and padded to the left with zeros to iv_length. - 2. The padded sequence number is XORed with either the static client_write_iv - or server_write_iv (depending on the role). +2. The padded sequence number is XORed with either the static client_write_iv + or server_write_iv (depending on the role). The resulting quantity (of length iv_length) is used as the per-record nonce. @@ -3964,7 +4079,7 @@ a non-zero octet in the cleartext, it MUST terminate the connection with an "unexpected_message" alert. The presence of padding does not change the overall record size limitations: -the full encoded TLSInnerPlaintext MUST NOT exceed 2^14 + 1 octets. If the +The full encoded TLSInnerPlaintext MUST NOT exceed 214 + 1 octets. If the maximum fragment length is reduced -- as for example by the record_size_limit extension from {{?RFC8449}} -- then the reduced limit applies to the full plaintext, including the content type and padding. @@ -3973,8 +4088,8 @@ Selecting a padding policy that suggests when and how much to pad is a complex topic and is beyond the scope of this specification. If the application-layer protocol on top of TLS has its own padding, it may be preferable to pad Application Data TLS records within the application -layer. Padding for encrypted Handshake or Alert records must -still be handled at the TLS layer, though. Later documents may define +layer. However, padding for encrypted Handshake or Alert records must +still be handled at the TLS layer. Later documents may define padding selection algorithms or define a padding policy request mechanism through TLS extensions or some other means. @@ -3987,14 +4102,14 @@ an analysis of these limits under the assumption that the underlying primitive (AES or ChaCha20) has no weaknesses. Implementations MUST either close the connection or do a key update as described in {{key-update}} prior to reaching these limits. -Note that it is not possible to perform a KeyUpdate for early data -and therefore implementations MUST NOT exceed the limits +Note that it is not possible to perform a KeyUpdate for early data; +therefore, implementations MUST NOT exceed the limits when sending early data. Receiving implementations SHOULD NOT enforce these limits, as future analyses may result in updated values. -For AES-GCM, up to 2^24.5 full-size records (about 24 million) +For AES-GCM, up to 224.5 full-size records (about 24 million) may be encrypted on a given connection while keeping a safety -margin of approximately 2^-57 for Authenticated Encryption (AE) security. +margin of approximately 2-57 for Authenticated Encryption (AE) security. For ChaCha20/Poly1305, the record sequence number would wrap before the safety limit is reached. @@ -4040,7 +4155,6 @@ but semantically invalid (e.g., a DHE share of p - 1, or an invalid enum) MUST terminate the connection with an "illegal_parameter" alert. -%%% Alert Messages enum { warning(1), fatal(2), (255) } AlertLevel; @@ -4048,11 +4162,8 @@ enum) MUST terminate the connection with an "illegal_parameter" alert. close_notify(0), unexpected_message(10), bad_record_mac(20), - decryption_failed_RESERVED(21), record_overflow(22), - decompression_failure_RESERVED(30), handshake_failure(40), - no_certificate_RESERVED(41), bad_certificate(42), unsupported_certificate(43), certificate_revoked(44), @@ -4063,19 +4174,15 @@ enum) MUST terminate the connection with an "illegal_parameter" alert. access_denied(49), decode_error(50), decrypt_error(51), - export_restriction_RESERVED(60), protocol_version(70), insufficient_security(71), internal_error(80), inappropriate_fallback(86), user_canceled(90), - no_renegotiation_RESERVED(100), missing_extension(109), unsupported_extension(110), - certificate_unobtainable_RESERVED(111), unrecognized_name(112), bad_certificate_status_response(113), - bad_certificate_hash_value_RESERVED(114), unknown_psk_identity(115), certificate_required(116), general_error(117), @@ -4129,7 +4236,7 @@ connection, though doing so would introduce the possibility of truncation. Application protocols MAY choose to flush their send buffers and immediately send a close_notify upon receiving a close_notify, but this allows an attacker to influence the data that the peer receives by delaying the close_notify or -by delaying the transport level delivery of the application's packets. These +by delaying the transport-level delivery of the application's packets. These issues can be addressed at the application layer, for instance by ignoring packets received after transmitting the close_notify. @@ -4155,7 +4262,7 @@ Whenever an implementation encounters a fatal error condition, it SHOULD send an appropriate fatal alert and MUST close the connection without sending or receiving any additional data. Throughout this specification, when the phrases "terminate the connection" and "abort the -handshake" are used without a specific alert it means that the +handshake" are used without a specific alert, it means that the implementation SHOULD send the alert indicated by the descriptions below. The phrases "terminate the connection with an X alert" and "abort the handshake with an X alert" mean that the implementation @@ -4183,8 +4290,8 @@ bad_record_mac: record_overflow: : A TLSCiphertext record was received that had a length more than - 2^14 + 256 bytes, or a record decrypted to a TLSPlaintext record - with more than 2^14 bytes (or some other negotiated limit). + 214 + 256 bytes, or a record decrypted to a TLSPlaintext record + with more than 214 bytes (or some other negotiated limit). This alert should never be observed in communication between proper implementations, except when messages were corrupted in the network. @@ -4267,6 +4374,20 @@ unsupported_extension: in a ServerHello, HelloRetryRequest, EncryptedExtensions, or Certificate not first offered in the corresponding ClientHello or CertificateRequest. + + unrecognized_name: : Sent by servers when no server exists identified by the name provided by the client via the "server_name" extension @@ -4295,8 +4416,8 @@ general_error: no_application_protocol: : Sent by servers when a client - "application_layer_protocol_negotiation" extension advertises - only protocols that the server does not support + "application_layer_protocol_negotiation" extension only advertises + protocols that the server does not support (see {{RFC7301}}). {:br } @@ -4324,9 +4445,12 @@ defined below: ~~~~ HKDF-Expand-Label(Secret, Label, Context, Length) = HKDF-Expand(Secret, HkdfLabel, Length) +~~~~ +{: gi="sourcecode"} - Where HkdfLabel is specified as: +where HkdfLabel is specified as: +~~~~ struct { uint16 length = Length; opaque label<7..255> = "tls13 " + Label; @@ -4337,12 +4461,13 @@ defined below: HKDF-Expand-Label(Secret, Label, Transcript-Hash(Messages), Hash.length) ~~~~ +{: gi="sourcecode"} The Hash function used by Transcript-Hash and HKDF is the cipher suite hash algorithm. Hash.length is its output length in bytes. Messages is the concatenation of the indicated handshake messages, including the handshake message type -and length fields, but not including record layer headers. Note that +and length fields but not including record layer headers. Note that in some cases a zero-length Context (indicated by "") is passed to HKDF-Expand-Label. The labels specified in this document are all ASCII strings and do not include a trailing NUL byte. @@ -4370,7 +4495,7 @@ input secrets are: - (EC)DHE shared secret ({{ecdhe-shared-secret-calculation}}) This produces the key schedule shown in the diagram below -({{key-schedule-diagram}}. In this diagram, the following formatting conventions apply: +({{key-schedule-diagram}}). In this diagram, the following formatting conventions apply: - HKDF-Extract is drawn as taking the Salt argument from the top and the IKM argument from the left, with its output to the bottom and @@ -4381,11 +4506,11 @@ This produces the key schedule shown in the diagram below generating the client_early_traffic_secret. - "0" indicates a string of Hash.length bytes set to zero. -Note: the key derivation labels use the string "master" even though +Note: The key derivation labels use the string "master" even though the values are referred to as "main" secrets. This mismatch is a result of renaming the values while retaining compatibility. -Note: this does not show all the leaf keys such as the separate +Note: This does not show all the leaf keys such as the separate AEAD and IV keys but rather the first set of secrets derived from the handshake. @@ -4490,6 +4615,7 @@ The next-generation application_traffic_secret is computed as: HKDF-Expand-Label(application_traffic_secret_N, "traffic upd", "", Hash.length) ~~~~ +{: gi="sourcecode"} Once client_/server_application_traffic_secret_N+1 and its associated traffic keys have been computed, implementations SHOULD delete @@ -4507,21 +4633,22 @@ The traffic keying material is generated from the following input values: The traffic keying material is generated from an input traffic secret value using: ~~~~ - [sender]_write_key = HKDF-Expand-Label(Secret, "key", "", key_length) - [sender]_write_iv = HKDF-Expand-Label(Secret, "iv", "", iv_length) +[sender]_write_key = HKDF-Expand-Label(Secret, "key", "", key_length) +[sender]_write_iv = HKDF-Expand-Label(Secret, "iv", "", iv_length) ~~~~ +{: gi="sourcecode"} -\[sender] denotes the sending side. The value of Secret for each category +\[sender\] denotes the sending side. The value of Secret for each category of data is shown in the table below. | Data Type | Secret | |:------------|--------| | 0-RTT Application and EndOfEarlyData | client_early_traffic_secret | -| Initial Handshake | \[sender]_handshake_traffic_secret | -| Post-Handshake and Application Data | \[sender]_application_traffic_secret_N | +| Initial Handshake | \[sender\]_handshake_traffic_secret | +| Post-Handshake and Application Data | \[sender\]_application_traffic_secret_N | {: #traffic-key-table title="Secrets for Traffic Keys"} -Alerts are sent with the then current sending key (or as +Alerts are sent with the then-current sending key (or as plaintext if no such key has been established.) All the traffic keying material is recomputed whenever the underlying Secret changes (e.g., when changing from the handshake to @@ -4538,12 +4665,12 @@ The negotiated key (Z) is converted to a byte string by encoding in big-endian f left-padded with zeros up to the size of the prime. This byte string is used as the shared secret in the key schedule as specified above. -Note that this construction differs from previous versions of TLS which remove +Note that this construction differs from previous versions of TLS, which remove leading zeros. ### Elliptic Curve Diffie-Hellman - For secp256r1, secp384r1 and secp521r1, ECDH calculations (including key + For secp256r1, secp384r1, and secp521r1, ECDH calculations (including key generation and shared secret calculation) are performed according to Sections 5.6.1.2 and 5.7.1.2 of {{KEYAGREEMENT}} using the Elliptic Curve Cryptography Cofactor Diffie-Hellman Primitive. The shared secret Z is @@ -4569,9 +4696,9 @@ For these curves, implementations SHOULD use the approach specified in {{RFC7748}} to calculate the Diffie-Hellman shared secret. Implementations MUST check whether the computed Diffie-Hellman shared secret is the all-zero value and abort if so, as described in -Section 6 of {{RFC7748}}. If implementors use an alternative +{{Section 6 of RFC7748}}. If implementors use an alternative implementation of these elliptic curves, they SHOULD perform the -additional checks specified in Section 7 of {{RFC7748}}. +additional checks specified in {{Section 7 of RFC7748}}. ## Exporters @@ -4586,7 +4713,7 @@ The exporter value is computed as: HKDF-Expand-Label(Derive-Secret(Secret, label, ""), "exporter", Hash(context_value), key_length) -Where Secret is either the early_exporter_secret or the +where Secret is either the early_exporter_secret or the exporter_secret. Implementations MUST use the exporter_secret unless explicitly specified by the application. The early_exporter_secret is defined for use in settings where an exporter is needed for 0-RTT data. @@ -4603,8 +4730,8 @@ specifications MUST NOT define a use of exporters that permit both an empty context and no context with the same label. New uses of exporters SHOULD provide a context in all exporter computations, though the value could be empty. -Requirements for the format of exporter labels are defined in Section 4 -of {{RFC5705}}. +Requirements for the format of exporter labels are defined in {{Section 4 +of RFC5705}}. # 0-RTT and Anti-Replay {#anti-replay} @@ -4626,7 +4753,7 @@ concerned with: multiple zones where tickets from zone A will not be accepted in zone B, then an attacker can duplicate a ClientHello and early data intended for A to both A and B. At A, the data will - be accepted in 0-RTT, but at B the server will reject 0-RTT + be accepted in 0-RTT, but at B, the server will reject 0-RTT data and instead force a full handshake. If the attacker blocks the ServerHello from A, then the client will complete the handshake with B and probably retry the request, leading to duplication on @@ -4635,7 +4762,7 @@ concerned with: The first class of attack can be prevented by sharing state to guarantee that the 0-RTT data is accepted at most once. Servers SHOULD provide that level of replay safety by implementing one of the methods described in this section or -by equivalent means. It is understood, however, that due to operational +by equivalent means. However, it is understood that due to operational concerns not all deployments will maintain state at that level. Therefore, in normal operation, clients will not know which, if any, of these mechanisms servers actually implement and hence MUST only send early data which they deem @@ -4643,7 +4770,7 @@ safe to be replayed. In addition to the direct effects of replays, there is a class of attacks where even operations normally considered idempotent could be exploited by a large -number of replays (timing attacks, resource limit exhaustion and others, as +number of replays (timing attacks, resource limit exhaustion, and others, as described in {{replay-0rtt}}). Those can be mitigated by ensuring that every 0-RTT payload can be replayed only a limited number of times. The server MUST ensure that any instance of it (be it a machine, a thread, or any other entity @@ -4651,7 +4778,7 @@ within the relevant serving infrastructure) would accept 0-RTT for the same 0-RTT handshake at most once; this limits the number of replays to the number of server instances in the deployment. Such a guarantee can be accomplished by locally recording data from recently received ClientHellos and rejecting -repeats, or by any other method that provides the same or a stronger guarantee. +repeats or by any other method that provides the same or a stronger guarantee. The "at most once per server instance" guarantee is a minimum requirement; servers SHOULD limit 0-RTT replays further when feasible. @@ -4671,7 +4798,7 @@ provided, the server would then fall back to a full handshake. If the tickets are not self-contained but rather are database keys, and the corresponding PSKs are deleted upon use, then connections established -using PSKs enjoy not only anti-replay protection, but also forward secrecy once +using PSKs enjoy not only anti-replay protection but also forward secrecy once all copies of the PSK from the database entry have been deleted. This mechanism also improves security for PSK usage when PSK is used without (EC)DHE. @@ -4718,7 +4845,7 @@ PSK identities, then an attacker can create multiple ClientHellos with different binder values for the less-preferred identity on the assumption that the server will not verify it (as recommended by {{pre-shared-key-extension}}). -I.e., if the +That is, if the client sends PSKs A and B but the server prefers A, then the attacker can change the binder for B without affecting the binder for A. If the binder for B is part of the storage key, @@ -4773,7 +4900,7 @@ which cannot be used for 0-RTT. To implement this mechanism, a server needs to store the time that the server generated the session ticket, offset by an estimate of -the round-trip time between client and server. I.e., +the round-trip time between client and server. That is, ~~~~ adjusted_creation_time = creation_time + estimated_RTT @@ -4787,11 +4914,11 @@ the client's "pre_shared_key" extension. The server can determine the expected_arrival_time of the ClientHello as: ~~~~ - expected_arrival_time = adjusted_creation_time + clients_ticket_age + expected_arrival_time = adjusted_creation_time + clients_ticket_age ~~~~ When a new ClientHello is received, the expected_arrival_time is then -compared against the current server wall clock time and if they differ +compared against the current server wall clock time, and if they differ by more than a certain amount, 0-RTT is rejected, though the 1-RTT handshake can be allowed to complete. @@ -4824,10 +4951,45 @@ streamed to the server over a longer time period. ## Mandatory-to-Implement Cipher Suites + + + In the absence of an application profile standard specifying otherwise: -A TLS-compliant application MUST implement the TLS_AES_128_GCM_SHA256 [GCM] -cipher suite and SHOULD implement the TLS_AES_256_GCM_SHA384 [GCM] and +A TLS-compliant application MUST implement the TLS_AES_128_GCM_SHA256 {{GCM}} +cipher suite and SHOULD implement the TLS_AES_256_GCM_SHA384 {{GCM}} and TLS_CHACHA20_POLY1305_SHA256 {{RFC8439}} cipher suites (see {{cipher-suites}}). @@ -4849,7 +5011,7 @@ TLS-compliant application MUST implement the following TLS extensions: * Signature Algorithms Certificate ("signature_algorithms_cert"; {{signature-algorithms}}) * Negotiated Groups ("supported_groups"; {{supported-groups}}) * Key Share ("key_share"; {{key-share}}) - * Server Name Indication ("server_name"; Section 3 of {{RFC6066}}) + * Server Name Indication ("server_name"; {{Section 3 of RFC6066}}) All implementations MUST send and use these extensions when offering applicable features: @@ -4942,20 +5104,18 @@ Those middleboxes continue to be non-compliant. # Security Considerations -Security issues are discussed throughout this memo, especially in -{{implementation-notes}}, {{backward-compatibility}}, and {{security-analysis}}. +Security issues are discussed throughout this memo, especially in Appendices +{{implementation-notes}}{: format="counter"}, {{backward-compatibility}}{: format="counter"}, and {{security-analysis}}{: format="counter"}. # IANA Considerations This document uses several registries that were originally created in {{RFC4346}} and updated in {{RFC8446}} and {{?RFC8447}}. The changes -between {{RFC8446}} and {{RFC8447}} this document are described in {{bis-changes}}. -IANA has updated these to reference this document. +between {{RFC8446}}, {{RFC8447}}, and this document are described in {{bis-changes}}. +IANA has replaced references to these RFCs with references to this document. The registries and their allocation policies are below: -The registries and their allocation policies are below: - -- TLS Cipher Suites registry: values with the first byte in the range +- "TLS Cipher Suites" registry: Values with the first byte in the range 0-254 (decimal) are assigned via Specification Required {{RFC8126}}. Values with the first byte 255 (decimal) are reserved for Private Use {{RFC8126}}. @@ -4965,33 +5125,33 @@ The registries and their allocation policies are below: The "DTLS-OK" and "Recommended" columns are both marked as "Y" for each new cipher suite. -- TLS ContentType registry: Future values are allocated via +- "TLS ContentType" registry: Future values are allocated via Standards Action {{RFC8126}}. -- TLS Alerts registry: Future values are allocated via Standards - Action {{RFC8126}}. IANA [is requested to/has] populated this registry +- "TLS Alerts" registry: Future values are allocated via Standards + Action {{RFC8126}}. IANA has populated this registry with the values from {{alert-messages-appendix}}. The "DTLS-OK" column is marked as "Y" for all such values. Values marked as "_RESERVED" have comments describing their previous usage. -- TLS HandshakeType registry: Future values are allocated via +- "TLS HandshakeType" registry: Future values are allocated via Standards Action {{RFC8126}}. IANA has updated this registry to rename item 4 from "NewSessionTicket" to "new_session_ticket" and populated this registry with the values from {{handshake-protocol-appendix}}. The "DTLS-OK" column is marked as "Y" for all such values. - Values marked "_RESERVED" have comments describing their previous or + Values marked as "_RESERVED" have comments describing their previous or temporary usage. -This document also uses the TLS ExtensionType Values registry originally created in +This document also uses the "TLS ExtensionType Values" registry originally created in {{RFC4366}}. IANA has updated it to reference this document. Changes to the registry follow: - IANA has updated the registration policy as follows: Values with the first byte in the range 0-254 (decimal) are assigned - via Specification Required [RFC8126]. Values with the first byte - 255 (decimal) are reserved for Private Use [RFC8126]. + via Specification Required {{RFC8126}}. Values with the first byte + 255 (decimal) are reserved for Private Use {{RFC8126}}. - IANA has updated this registry to include the "key_share", "pre_shared_key", "psk_key_exchange_modes", @@ -4999,34 +5159,49 @@ registry follow: "certificate_authorities", "oid_filters", "post_handshake_auth", and "signature_algorithms_cert" extensions with the values defined in this document and the "Recommended" value of "Y". - IANA has updated this registry to include a "TLS - 1.3" column which lists the messages in which the extension may + 1.3" column, which lists the messages in which the extension may appear. This column has been initially populated from the table in {{extensions}}, with any extension not listed there marked as "-" to indicate that it is not used by TLS 1.3. -This document updates two entries in the TLS Certificate Types registry +This document updates two entries in the "TLS Certificate Types" registry originally created in {{RFC6091}} and updated in {{RFC8447}}. IANA has updated the entry for value 1 to have the name "OpenPGP_RESERVED", "Recommended" value "N", and comment "Used in TLS versions prior -to 1.3." IANA has updated the entry for value 0 to have the name -"X509", "Recommended" value "Y", and comment "Was X.509 before TLS 1.3". +to 1.3.". IANA has updated the entry for value 0 to have the name +"X509", "Recommended" value "Y", and comment "Was X.509 before TLS 1.3.". -This document updates an entry in the TLS Certificate Status Types +This document updates an entry in the "TLS Certificate Status Types" registry originally created in {{RFC6961}}. IANA has updated the entry for value 2 to have the name "ocsp_multi_RESERVED" and comment "Used -in TLS versions prior to 1.3". +in TLS versions prior to 1.3.". + + -This document updates two entries in the TLS Supported Groups +This document updates two entries in the "TLS Supported Groups" registry (created under a different name by {{RFC4492}}; now maintained -by {{RFC8422}}) and updated by {{RFC7919}} and {{RFC8447}}. The entries +by {{RFC8422}} and updated by {{RFC7919}} and {{RFC8447}}). The entries for values 29 and 30 (x25519 and x448) have been updated to also refer to this document. In addition, this document defines two new registries that are maintained by IANA: -- TLS SignatureScheme registry: Values with the first byte in the range +- "TLS SignatureScheme" registry: Values with the first byte in the range 0-253 (decimal) are assigned via Specification Required {{RFC8126}}. Values with the first byte 254 or 255 (decimal) are reserved for Private Use {{RFC8126}}. Values with the first byte in the range 0-6 or with the @@ -5044,10 +5219,10 @@ by IANA: requires Standards Action {{RFC8126}}. IESG Approval is REQUIRED for a Y->N transition. - - TLS PskKeyExchangeMode registry: Values in the + - "TLS PskKeyExchangeMode" registry: Values in the range 0-253 (decimal) are assigned via Specification Required - [RFC8126]. The values 254 and 255 (decimal) are - reserved for Private Use [RFC8126]. This registry has a + {{RFC8126}}. The values 254 and 255 (decimal) are + reserved for Private Use {{RFC8126}}. This registry has a "Recommended" column. The registry has been initially populated with psk_ke (0) and psk_dhe_ke (1). Both are marked as "Recommended". The @@ -5058,14 +5233,14 @@ by IANA: ## Changes for this RFC {#bis-changes} -IANA [shall update/has updated] all references to RFC 8446 in the IANA +IANA has updated all references to {{RFC8446}} in the IANA registries with references to this document. -IANA [shall rename/has renamed] the "extended_master_secret" value -in the TLS ExtensionType Values registry to "extended_main_secret". +IANA has renamed the "extended_master_secret" value +in the "TLS ExtensionType Values" registry to "extended_main_secret". -IANA [shall create/has created] a value for the "general_error" -alert in the TLS Alerts Registry with the value given in {{alert-protocol}}. +IANA has created a value for the "general_error" +alert in the "TLS Alerts" registry with the value given in {{alert-protocol}}. --- back @@ -5075,7 +5250,7 @@ This appendix provides a summary of the legal state transitions for the client and server handshakes. State names (in all capitals, e.g., START) have no formal meaning but are provided for ease of comprehension. Actions which are taken only in certain circumstances are -indicated in []. The notation "K_{send,recv} = foo" means "set the send/recv +indicated in \[\]. The notation "K_{send,recv} = foo" means "set the send/recv key to the given key". ## Client @@ -5173,89 +5348,525 @@ for constants. Values listed as for completeness. TLS 1.3 implementations MUST NOT send them but might receive them from older TLS implementations. -%%## Record Layer - -%%## Alert Messages{#alert-messages-appendix} - -%%## Handshake Protocol{#handshake-protocol-appendix} - -%%### Key Exchange Messages -%%#### Version Extension -%%#### Cookie Extension -%%#### Signature Algorithm Extension -%%#### Supported Groups Extension +## Record Layer -Values within "obsolete_RESERVED" ranges are used in previous versions -of TLS and MUST NOT be offered or negotiated by TLS 1.3 implementations. -The obsolete curves have various known/theoretical weaknesses or have -had very little usage, in some cases only due to unintentional -server configuration issues. They are no longer considered appropriate -for general use and should be assumed to be potentially unsafe. The set -of curves specified here is sufficient for interoperability with all -currently deployed and properly configured TLS implementations. -%%### Server Parameters Messages -%%### Authentication Messages -%%### Ticket Establishment -%%### Updating Keys + enum { + invalid(0), + change_cipher_spec(20), + alert(21), + handshake(22), + application_data(23), + (255) + } ContentType; + struct { + ContentType type; + ProtocolVersion legacy_record_version; + uint16 length; + opaque fragment[TLSPlaintext.length]; + } TLSPlaintext; -## Cipher Suites + struct { + opaque content[TLSPlaintext.length]; + ContentType type; + uint8 zeros[length_of_padding]; + } TLSInnerPlaintext; -A cipher suite defines the pair of the AEAD algorithm and hash -algorithm to be used with HKDF. -Cipher suite names follow the naming convention: + struct { + ContentType opaque_type = application_data; /* 23 */ + ProtocolVersion legacy_record_version = 0x0303; /* TLS v1.2 */ + uint16 length; + opaque encrypted_record[TLSCiphertext.length]; + } TLSCiphertext; -~~~ - CipherSuite TLS_AEAD_HASH = VALUE; -~~~ -| Component | Contents | -|:----------|:---------| -| TLS | The string "TLS" | -| AEAD | The AEAD algorithm used for record protection | -| HASH | The hash algorithm used with HKDF and Transcript-Hash | -| VALUE | The two byte ID assigned for this cipher suite | -{: #cs-components title="Cipher Suite Name Structure"} -This specification defines the following cipher suites for use with TLS 1.3. -| Description | Value | -|:--------------------------------|:------------| -| TLS_AES_128_GCM_SHA256 | {0x13,0x01} | -| TLS_AES_256_GCM_SHA384 | {0x13,0x02} | -| TLS_CHACHA20_POLY1305_SHA256 | {0x13,0x03} | -| TLS_AES_128_CCM_SHA256 | {0x13,0x04} | -| TLS_AES_128_CCM_8_SHA256 | {0x13,0x05} | -{: #cs-list title="Cipher Suite List"} +## Alert Messages {#alert-messages-appendix} -The corresponding AEAD algorithms AEAD_AES_128_GCM, AEAD_AES_256_GCM, and -AEAD_AES_128_CCM are defined in {{RFC5116}}. AEAD_CHACHA20_POLY1305 is defined -in {{RFC8439}}. AEAD_AES_128_CCM_8 is defined in {{RFC6655}}. The corresponding -hash algorithms are defined in {{!SHS}}. + enum { warning(1), fatal(2), (255) } AlertLevel; -Although TLS 1.3 uses the same cipher suite space as previous versions -of TLS, TLS 1.3 cipher suites are defined differently, only specifying -the symmetric ciphers, and cannot be used for TLS 1.2. Similarly, -cipher suites for TLS 1.2 and lower cannot be used with TLS 1.3. + enum { + close_notify(0), + unexpected_message(10), + bad_record_mac(20), + decryption_failed_RESERVED(21), + record_overflow(22), + decompression_failure_RESERVED(30), + handshake_failure(40), + no_certificate_RESERVED(41), + bad_certificate(42), + unsupported_certificate(43), + certificate_revoked(44), + certificate_expired(45), + certificate_unknown(46), + illegal_parameter(47), + unknown_ca(48), + access_denied(49), + decode_error(50), + decrypt_error(51), + export_restriction_RESERVED(60), + protocol_version(70), + insufficient_security(71), + internal_error(80), + inappropriate_fallback(86), + user_canceled(90), + no_renegotiation_RESERVED(100), + missing_extension(109), + unsupported_extension(110), + certificate_unobtainable_RESERVED(111), + unrecognized_name(112), + bad_certificate_status_response(113), + bad_certificate_hash_value_RESERVED(114), + unknown_psk_identity(115), + certificate_required(116), + general_error(117), + no_application_protocol(120), + (255) + } AlertDescription; -New cipher suite values are assigned by IANA as described in -{{iana-considerations}}. + struct { + AlertLevel level; + AlertDescription description; + } Alert; -# Implementation Notes -The TLS protocol cannot prevent many common security mistakes. This appendix -provides several recommendations to assist implementors. -{{?RFC8448}} provides test vectors for TLS 1.3 handshakes. -## Random Number Generation and Seeding +## Handshake Protocol {#handshake-protocol-appendix} -TLS requires a cryptographically secure pseudorandom number generator (CSPRNG). -A performant and appropriately-secure CSPRNG is provided by most operating -systems or can be sourced from a cryptographic library. -It is RECOMMENDED to use an existing CSPRNG implementation in -preference to crafting a new one. Many adequate cryptographic libraries + enum { + hello_request_RESERVED(0), + client_hello(1), + server_hello(2), + hello_verify_request_RESERVED(3), + new_session_ticket(4), + end_of_early_data(5), + hello_retry_request_RESERVED(6), + encrypted_extensions(8), + certificate(11), + server_key_exchange_RESERVED(12), + certificate_request(13), + server_hello_done_RESERVED(14), + certificate_verify(15), + client_key_exchange_RESERVED(16), + finished(20), + certificate_url_RESERVED(21), + certificate_status_RESERVED(22), + supplemental_data_RESERVED(23), + key_update(24), + message_hash(254), + (255) + } HandshakeType; + + struct { + HandshakeType msg_type; /* handshake type */ + uint24 length; /* remaining bytes in message */ + select (Handshake.msg_type) { + case client_hello: ClientHello; + case server_hello: ServerHello; + case end_of_early_data: EndOfEarlyData; + case encrypted_extensions: EncryptedExtensions; + case certificate_request: CertificateRequest; + case certificate: Certificate; + case certificate_verify: CertificateVerify; + case finished: Finished; + case new_session_ticket: NewSessionTicket; + case key_update: KeyUpdate; + }; + } Handshake; + + + + +### Key Exchange Messages + + + uint16 ProtocolVersion; + opaque Random[32]; + + uint8 CipherSuite[2]; /* Cryptographic suite selector */ + + struct { + ProtocolVersion legacy_version = 0x0303; /* TLS v1.2 */ + Random random; + opaque legacy_session_id<0..32>; + CipherSuite cipher_suites<2..2^16-2>; + opaque legacy_compression_methods<1..2^8-1>; + Extension extensions<8..2^16-1>; + } ClientHello; + + struct { + ProtocolVersion legacy_version = 0x0303; /* TLS v1.2 */ + Random random; + opaque legacy_session_id_echo<0..32>; + CipherSuite cipher_suite; + uint8 legacy_compression_method = 0; + Extension extensions<6..2^16-1>; + } ServerHello; + + struct { + ExtensionType extension_type; + opaque extension_data<0..2^16-1>; + } Extension; + + enum { + server_name(0), /* RFC 6066 */ + max_fragment_length(1), /* RFC 6066 */ + status_request(5), /* RFC 6066 */ + supported_groups(10), /* RFC 8422, 7919 */ + signature_algorithms(13), /* RFC 8446 */ + use_srtp(14), /* RFC 5764 */ + heartbeat(15), /* RFC 6520 */ + application_layer_protocol_negotiation(16), /* RFC 7301 */ + signed_certificate_timestamp(18), /* RFC 6962 */ + client_certificate_type(19), /* RFC 7250 */ + server_certificate_type(20), /* RFC 7250 */ + padding(21), /* RFC 7685 */ + pre_shared_key(41), /* RFC 8446 */ + early_data(42), /* RFC 8446 */ + supported_versions(43), /* RFC 8446 */ + cookie(44), /* RFC 8446 */ + psk_key_exchange_modes(45), /* RFC 8446 */ + certificate_authorities(47), /* RFC 8446 */ + oid_filters(48), /* RFC 8446 */ + post_handshake_auth(49), /* RFC 8446 */ + signature_algorithms_cert(50), /* RFC 8446 */ + key_share(51), /* RFC 8446 */ + (65535) + } ExtensionType; + + struct { + NamedGroup group; + opaque key_exchange<1..2^16-1>; + } KeyShareEntry; + + struct { + KeyShareEntry client_shares<0..2^16-1>; + } KeyShareClientHello; + + struct { + NamedGroup selected_group; + } KeyShareHelloRetryRequest; + + struct { + KeyShareEntry server_share; + } KeyShareServerHello; + + struct { + uint8 legacy_form = 4; + opaque X[coordinate_length]; + opaque Y[coordinate_length]; + } UncompressedPointRepresentation; + + enum { psk_ke(0), psk_dhe_ke(1), (255) } PskKeyExchangeMode; + + struct { + PskKeyExchangeMode ke_modes<1..255>; + } PskKeyExchangeModes; + + struct {} Empty; + + struct { + select (Handshake.msg_type) { + case new_session_ticket: uint32 max_early_data_size; + case client_hello: Empty; + case encrypted_extensions: Empty; + }; + } EarlyDataIndication; + + struct { + opaque identity<1..2^16-1>; + uint32 obfuscated_ticket_age; + } PskIdentity; + + opaque PskBinderEntry<32..255>; + + struct { + PskIdentity identities<7..2^16-1>; + PskBinderEntry binders<33..2^16-1>; + } OfferedPsks; + + struct { + select (Handshake.msg_type) { + case client_hello: OfferedPsks; + case server_hello: uint16 selected_identity; + }; + } PreSharedKeyExtension; + + + +#### Version Extension + + + struct { + select (Handshake.msg_type) { + case client_hello: + ProtocolVersion versions<2..254>; + + case server_hello: /* and HelloRetryRequest */ + ProtocolVersion selected_version; + }; + } SupportedVersions; + + + +#### Cookie Extension + + + struct { + opaque cookie<1..2^16-1>; + } Cookie; + + + +#### Signature Algorithm Extension + + + enum { + /* RSASSA-PKCS1-v1_5 algorithms */ + rsa_pkcs1_sha256(0x0401), + rsa_pkcs1_sha384(0x0501), + rsa_pkcs1_sha512(0x0601), + + /* ECDSA algorithms */ + ecdsa_secp256r1_sha256(0x0403), + ecdsa_secp384r1_sha384(0x0503), + ecdsa_secp521r1_sha512(0x0603), + + /* RSASSA-PSS algorithms with public key OID rsaEncryption */ + rsa_pss_rsae_sha256(0x0804), + rsa_pss_rsae_sha384(0x0805), + rsa_pss_rsae_sha512(0x0806), + + /* EdDSA algorithms */ + ed25519(0x0807), + ed448(0x0808), + + /* RSASSA-PSS algorithms with public key OID RSASSA-PSS */ + rsa_pss_pss_sha256(0x0809), + rsa_pss_pss_sha384(0x080a), + rsa_pss_pss_sha512(0x080b), + + /* Legacy algorithms */ + rsa_pkcs1_sha1(0x0201), + ecdsa_sha1(0x0203), + + /* Reserved Code Points */ + obsolete_RESERVED(0x0000..0x0200), + dsa_sha1_RESERVED(0x0202), + obsolete_RESERVED(0x0204..0x0400), + dsa_sha256_RESERVED(0x0402), + obsolete_RESERVED(0x0404..0x0500), + dsa_sha384_RESERVED(0x0502), + obsolete_RESERVED(0x0504..0x0600), + dsa_sha512_RESERVED(0x0602), + obsolete_RESERVED(0x0604..0x06FF), + private_use(0xFE00..0xFFFF), + (0xFFFF) + } SignatureScheme; + + struct { + SignatureScheme supported_signature_algorithms<2..2^16-2>; + } SignatureSchemeList; + + + +#### Supported Groups Extension + + + enum { + unallocated_RESERVED(0x0000), + + /* Elliptic Curve Groups (ECDHE) */ + obsolete_RESERVED(0x0001..0x0016), + secp256r1(0x0017), secp384r1(0x0018), secp521r1(0x0019), + obsolete_RESERVED(0x001A..0x001C), + x25519(0x001D), x448(0x001E), + + /* Finite Field Groups (DHE) */ + ffdhe2048(0x0100), ffdhe3072(0x0101), ffdhe4096(0x0102), + ffdhe6144(0x0103), ffdhe8192(0x0104), + + /* Reserved Code Points */ + ffdhe_private_use(0x01FC..0x01FF), + ecdhe_private_use(0xFE00..0xFEFF), + obsolete_RESERVED(0xFF01..0xFF02), + (0xFFFF) + } NamedGroup; + + struct { + NamedGroup named_group_list<2..2^16-1>; + } NamedGroupList; + + + + +Values within "obsolete_RESERVED" ranges are used in previous versions +of TLS and MUST NOT be offered or negotiated by TLS 1.3 implementations. +The obsolete curves have various known/theoretical weaknesses or have +had very little usage, in some cases, only due to unintentional +server configuration issues. They are no longer considered appropriate +for general use and should be assumed to be potentially unsafe. The set +of curves specified here is sufficient for interoperability with all +currently deployed and properly configured TLS implementations. + +### Server Parameters Messages + + + opaque DistinguishedName<1..2^16-1>; + + struct { + DistinguishedName authorities<3..2^16-1>; + } CertificateAuthoritiesExtension; + + struct { + opaque certificate_extension_oid<1..2^8-1>; + opaque certificate_extension_values<0..2^16-1>; + } OIDFilter; + + struct { + OIDFilter filters<0..2^16-1>; + } OIDFilterExtension; + + struct {} PostHandshakeAuth; + + struct { + Extension extensions<0..2^16-1>; + } EncryptedExtensions; + + struct { + opaque certificate_request_context<0..2^8-1>; + Extension extensions<0..2^16-1>; + } CertificateRequest; + + + +### Authentication Messages + + + enum { + X509(0), + OpenPGP_RESERVED(1), + RawPublicKey(2), + (255) + } CertificateType; + + struct { + select (certificate_type) { + case RawPublicKey: + /* From RFC 7250 ASN.1_subjectPublicKeyInfo */ + opaque ASN1_subjectPublicKeyInfo<1..2^24-1>; + + case X509: + opaque cert_data<1..2^24-1>; + }; + Extension extensions<0..2^16-1>; + } CertificateEntry; + + struct { + opaque certificate_request_context<0..2^8-1>; + CertificateEntry certificate_list<0..2^24-1>; + } Certificate; + + struct { + SignatureScheme algorithm; + opaque signature<0..2^16-1>; + } CertificateVerify; + + struct { + opaque verify_data[Hash.length]; + } Finished; + + + +### Ticket Establishment + + + struct { + uint32 ticket_lifetime; + uint32 ticket_age_add; + opaque ticket_nonce<0..255>; + opaque ticket<1..2^16-1>; + Extension extensions<0..2^16-1>; + } NewSessionTicket; + + + +### Updating Keys + + + struct {} EndOfEarlyData; + + enum { + update_not_requested(0), update_requested(1), (255) + } KeyUpdateRequest; + + struct { + KeyUpdateRequest request_update; + } KeyUpdate; + + + + + +## Cipher Suites + +A cipher suite defines the pair of the AEAD algorithm and hash +algorithm to be used with HKDF. +Cipher suite names follow the naming convention: + +~~~ + CipherSuite TLS_AEAD_HASH = VALUE; +~~~ + +| Component | Contents | +|:----------|:---------| +| TLS | The string "TLS" | +| AEAD | The AEAD algorithm used for record protection | +| HASH | The hash algorithm used with HKDF and Transcript-Hash | +| VALUE | The two-byte ID assigned for this cipher suite | +{: #cs-components title="Cipher Suite Name Structure"} + +This specification defines the following cipher suites for use with TLS 1.3. + +| Description | Value | +|:--------------------------------|:------------| +| TLS_AES_128_GCM_SHA256 | {0x13,0x01} | +| TLS_AES_256_GCM_SHA384 | {0x13,0x02} | +| TLS_CHACHA20_POLY1305_SHA256 | {0x13,0x03} | +| TLS_AES_128_CCM_SHA256 | {0x13,0x04} | +| TLS_AES_128_CCM_8_SHA256 | {0x13,0x05} | +{: #cs-list title="Cipher Suite List"} + +The corresponding AEAD algorithms AEAD_AES_128_GCM, AEAD_AES_256_GCM, and +AEAD_AES_128_CCM are defined in {{RFC5116}}. AEAD_CHACHA20_POLY1305 is defined +in {{RFC8439}}. AEAD_AES_128_CCM_8 is defined in {{RFC6655}}. The corresponding +hash algorithms are defined in {{!SHS}}. + +Although TLS 1.3 uses the same cipher suite space as previous versions +of TLS, TLS 1.3 cipher suites are defined differently, only specifying +the symmetric ciphers, and cannot be used for TLS 1.2. Similarly, +cipher suites for TLS 1.2 and lower cannot be used with TLS 1.3. + +New cipher suite values are assigned by IANA as described in +{{iana-considerations}}. + + +# Implementation Notes + +The TLS protocol cannot prevent many common security mistakes. This appendix +provides several recommendations to assist implementors. +{{?RFC8448}} provides test vectors for TLS 1.3 handshakes. + +## Random Number Generation and Seeding + +TLS requires a cryptographically secure pseudorandom number generator (CSPRNG). +A performant and appropriately secure CSPRNG is provided by most operating +systems or can be sourced from a cryptographic library. +It is RECOMMENDED to use an existing CSPRNG implementation in +preference to crafting a new one. Many adequate cryptographic libraries are already available under favorable license terms. Should those prove unsatisfactory, {{RFC4086}} provides guidance on the generation of random values. @@ -5292,7 +5903,7 @@ certification paths containing keys or signatures weaker than 2048-bit RSA or Note that it is common practice in some protocols to use the same certificate in both client and server modes. This setting has not been -extensively analyzed and it is the responsibility of the higher level +extensively analyzed, and it is the responsibility of the higher-level protocol to ensure there is no ambiguity in this case about the higher-level semantics. @@ -5302,7 +5913,7 @@ higher-level semantics. Implementation experience has shown that certain parts of earlier TLS specifications are not easy to understand and have been a source of interoperability and security problems. Many of these areas have been clarified -in this document but this appendix contains a short list of the most important +in this document, but this appendix contains a short list of the most important things that require special attention from implementors. TLS protocol issues: @@ -5322,7 +5933,7 @@ TLS protocol issues: - Have you ensured that all support for SSL, RC4, EXPORT ciphers, and MD5 (via the "signature_algorithms" extension) is completely removed from all possible configurations that support TLS 1.3 or later, and that - attempts to use these obsolete capabilities fail correctly? + attempts to use these obsolete capabilities fail correctly (see {{backward-compatibility}})? - Do you handle TLS extensions in ClientHellos correctly, including @@ -5364,14 +5975,14 @@ Cryptographic details: generator (see {{random-number-generation-and-seeding}}) when generating Diffie-Hellman private values, the ECDSA "k" parameter, and other security-critical values? It is RECOMMENDED that implementations implement "deterministic ECDSA" - as specified in {{!RFC6979}}. Note that purely deterministic ECC signatures such as + as specified in {{!RFC6979}}. Note that purely deterministic Elliptic Curve Cryptography (ECC) signatures such as deterministic ECDSA and EdDSA may be vulnerable to certain side-channel and fault - injection attacks in easily accessible IoT devices. + injection attacks in easily accessible Internet of Things (IoT) devices. - Do you zero-pad Diffie-Hellman public key values and shared - secrets to the group size (see {{ffdhe-param}} and {{finite-field-diffie-hellman}})? + secrets to the group size (see Sections {{ffdhe-param}}{: format="counter"} and {{finite-field-diffie-hellman}}{: format="counter"})? -- Do you verify signatures after making them, to protect against RSA-CRT +- Do you verify signatures after making them to protect against RSA-CRT key leaks {{FW15}}? @@ -5391,23 +6002,23 @@ applications SHOULD NOT offer tickets across connections that are meant to be uncorrelated. For example, {{FETCH}} defines network partition keys to separate cache lookups in web browsers. -Clients and Servers SHOULD NOT reuse a key share for multiple connections. Reuse +Clients and servers SHOULD NOT reuse a key share for multiple connections. Reuse of a key share allows passive observers to correlate different connections. Reuse of a client key share to the same server additionally allows the server to correlate different connections. It is RECOMMENDED that the labels for external identities be selected so that they do not provide additional information about the identity of the -user. For instance, if the label includes an e-mail address, then +user. For instance, if the label includes an email address, then this trivially identifies the user to a passive attacker, unlike the client's Certificate, which is encrypted. There are a number of potential -ways to avoid this risk, including (1) using random identity labels -(2) pre-encrypting the identity under a key known to the server or (3) -using the Encrypted Client Hello {{?I-D.ietf-tls-esni}} extension. +ways to avoid this risk, including (1) using random identity labels, +(2) pre-encrypting the identity under a key known to the server, or (3) +using the Encrypted Client Hello extension {{PRE-RFC9849}}. If an external PSK identity is used for multiple connections, then it will generally be possible for an external observer to track clients and/or servers across connections. Use of the -Encrypted Client Hello {{?I-D.ietf-tls-esni}} extension can +Encrypted Client Hello {{PRE-RFC9849}} extension can mitigate this risk, as can mechanisms external to TLS that rotate or encrypt the PSK identity. @@ -5430,7 +6041,7 @@ out-of-band validation of the server's public key, trust on first use, or a mechanism such as channel bindings (though the channel bindings described in {{RFC5929}} are not defined for TLS 1.3). If no such mechanism is used, then the connection has no protection -against active man-in-the-middle attack; applications MUST NOT use TLS +against an active man-in-the-middle attack; applications MUST NOT use TLS in such a way absent explicit configuration or a specific application profile. @@ -5440,7 +6051,7 @@ profile. To align with the names used this document, the following terms from {{RFC5246}} are renamed: -* The master secret, computed in Section 8.1 of {{RFC5246}}, is renamed to +* The master secret, computed in {{Section 8.1 of RFC5246}}, is renamed to the main secret. It is referred to as main_secret in formulas and structures, instead of master_secret. However, the label parameter to the PRF function is left unchanged for compatibility. @@ -5450,13 +6061,13 @@ To align with the names used this document, the following terms from pre_master_secret. * The PreMasterSecret and EncryptedPreMasterSecret structures, defined in - Section 7.4.7.1 of {{RFC5246}}, are renamed to PreliminarySecret and + {{Section 7.4.7.1 of RFC5246}}, are renamed to PreliminarySecret and EncryptedPreliminarySecret, respectively. Correspondingly, the extension defined in {{RFC7627}} is renamed to the "Extended Main Secret" extension. The extension code point is renamed to -"extended_main_secret". The label parameter to the PRF function in Section 4 of -{{RFC7627}} is left unchanged for compatibility. +"extended_main_secret". The label parameter to the PRF function in {{Section 4 of +RFC7627}} is left unchanged for compatibility. # Backward Compatibility @@ -5530,10 +6141,10 @@ to downgrade attacks and is NOT RECOMMENDED. A TLS server can also receive a ClientHello indicating a version number smaller than its highest supported version. If the "supported_versions" extension -is present, the server MUST negotiate using that extension as described in +is present, the server MUST negotiate using that extension, as described in {{supported-versions}}. If the "supported_versions" extension is not present, the server MUST negotiate the minimum of ClientHello.legacy_version -and TLS 1.2. For example, if the server supports TLS 1.0, 1.1, and 1.2, +and TLS 1.2. For example, if the server supports TLS 1.0, 1.1, and 1.2 and legacy_version is TLS 1.0, the server will proceed with a TLS 1.0 ServerHello. If the "supported_versions" extension is absent and the server only supports versions greater than ClientHello.legacy_version, the server MUST abort the handshake @@ -5588,11 +6199,11 @@ by making the TLS 1.3 handshake look more like a TLS 1.2 handshake: When put together, these changes make the TLS 1.3 handshake resemble TLS 1.2 session resumption, which improves the chance of successfully connecting through middleboxes. This "compatibility mode" is partially -negotiated: the client can opt to provide a session ID or not, +negotiated: The client can opt to provide a session ID or not and the server has to echo it. Either side can send change_cipher_spec at any time during the handshake, as they must be ignored by the peer, but if the client sends a non-empty session ID, the server MUST send -the change_cipher_spec as described in this appendix. +the change_cipher_spec, as described in this appendix. ## Security Restrictions Related to Backward Compatibility {#backward-compatibility-security} @@ -5605,13 +6216,13 @@ The security of RC4 cipher suites is considered insufficient for the reasons cited in {{RFC7465}}. Implementations MUST NOT offer or negotiate RC4 cipher suites for any version of TLS for any reason. -Old versions of TLS permitted the use of very low strength ciphers. +Old versions of TLS permitted the use of very low-strength ciphers. Ciphers with a strength less than 112 bits MUST NOT be offered or negotiated for any version of TLS for any reason. The security of SSL 2.0 {{SSL2}}, SSL 3.0 {{?RFC6101}}, TLS 1.0 {{?RFC2246}}, and TLS 1.1 {{RFC4346}} are considered insufficient for -the reasons enumerated in {{RFC6176}}, {{RFC7568}}, and {{RFC8996}} +the reasons enumerated in {{RFC6176}}, {{RFC7568}}, and {{RFC8996}}, and they MUST NOT be negotiated for any reason. Implementations MUST NOT send an SSL version 2.0 compatible CLIENT-HELLO. @@ -5629,7 +6240,7 @@ Implementations SHOULD NOT accept any records with a version less than 0x0300 (but may inadvertently do so if the record version number is ignored completely). Implementations MUST NOT use the Truncated HMAC extension, defined in -Section 7 of [RFC6066], as it is not applicable to AEAD algorithms and has +{{Section 7 of RFC6066}}, as it is not applicable to AEAD algorithms and has been shown to be insecure in some scenarios. @@ -5651,7 +6262,7 @@ mutually authenticated (client and server) functionality. At the completion of the handshake, each side outputs its view of the following values: - A set of "session keys" (the various secrets derived from the main secret) - from which can be derived a set of working keys. Note that when early data + from which a set of working keys can be derived. Note that when early data is in use, secrets are also derived from the early secret. These enjoy somewhat weaker properties than those derived from the main secret, as detailed below. @@ -5661,7 +6272,7 @@ of the handshake, each side outputs its view of the following values: We assume the attacker to be an active network attacker, which means it has complete control over the network used to communicate between the parties {{RFC3552}}. Even under these conditions, the handshake should provide the properties listed below. -Note that these properties are not necessarily independent, but reflect +Note that these properties are not necessarily independent but reflect the protocol consumers' needs. Establishing the same session keys: @@ -5671,7 +6282,7 @@ the handshake, provided that it completes successfully on each endpoint Secrecy of the session keys: : The shared session keys should be known only to the communicating - parties and not to the attacker (see {{?CK01=DOI.10.1007/3-540-44987-6_28}}; Definition 1, part 2). + parties and not to the attacker (see {{?CK01=DOI.10.1007/3-540-44987-6_28}}, Definition 1, part 2). Note that in a unilaterally authenticated connection, the attacker can establish its own session keys with the server, but those session keys are distinct from those established by the client. @@ -5692,14 +6303,14 @@ Downgrade Protection: absence of an attack (see {{?BBFGKZ16=DOI.10.1109/SP.2016.37}}; Definitions 8 and 9). Forward secret with respect to long-term keys: -: If the long-term keying material (in this case the signature keys in +: If the long-term keying material (in this case, the signature keys in certificate-based authentication modes or the external/resumption PSK in PSK with (EC)DHE modes) is compromised after the handshake is complete, this does not compromise the security of the session key (see {{?DOW92=DOI.10.1007/BF00124891}}), as long as the session key itself (and all material that could be used to recreate the session key) has been erased. In particular, private keys corresponding to key - shares, shared secrets, and keys derived in the TLS Key Schedule + shares, shared secrets, and keys derived in the TLS key schedule other than `binder_key`, `resumption_secret`, and PSKs derived from the `resumption_secret` also need to be erased. The forward secrecy property is not satisfied when PSK is used in the "psk_ke" @@ -5711,7 +6322,7 @@ Forward secret with respect to long-term keys: Key Compromise Impersonation (KCI) resistance: : In a mutually authenticated connection with certificates, compromising the long-term - secret of one actor should not break that actor’s authentication of their peer in + secret of one actor should not break that actor's authentication of their peer in the given connection (see {{HGFS15}}). For example, if a client's signature key is compromised, it should not be possible to impersonate arbitrary servers to that client in subsequent handshakes. @@ -5763,7 +6374,7 @@ compromised, any handshake with (EC)DHE gives protection against active attackers. Using the terms in {{RFC7624}}, forward secrecy without rerunning (EC)DHE does not stop an attacker from doing static key exfiltration. After key exfiltration of -application_traffic_secret_N, an attacker can e.g., passively +application_traffic_secret_N, an attacker can, e.g., passively eavesdrop on all future data sent on the connection including data encrypted with application_traffic_secret_N+1, application_traffic_secret_N+2, etc. Frequently rerunning (EC)DHE @@ -5865,9 +6476,9 @@ If the client needs to determine if the server considers the connection to be unilaterally or mutually authenticated, this has to be provisioned by the application layer. See {{CHHSV17}} for details. In addition, the analysis of post-handshake authentication from -[Kraw16] shows that the client identified by the certificate sent in -the post-handshake phase possesses the traffic key. This party is -therefore the client that participated in the original handshake or +{{Kraw16}} shows that the client identified by the certificate sent in +the post-handshake phase possesses the traffic key. Therefore, this party is +the client that participated in the original handshake or one to whom the original client delegated the traffic key (assuming that the traffic key has not been compromised). @@ -5898,9 +6509,9 @@ needed again. ### Post-Compromise Security TLS does not provide security for handshakes which take place after the peer's -long-term secret (signature key or external PSK) is compromised. It therefore +long-term secret (signature key or external PSK) is compromised. Therefore, it does not provide post-compromise security {{?CCG16=DOI.10.1109/CSF.2016.19}}, sometimes also referred to -as backwards or future secrecy. This is in contrast to KCI resistance, which +as backward or future secrecy. This is in contrast to KCI resistance, which describes the security guarantees that a party has after its own long-term secret has been compromised. @@ -5919,13 +6530,22 @@ Assuming that is true, and the keys are used for no more data than indicated in {{limits-on-key-usage}}, then the record layer should provide the following guarantees: + + Confidentiality: : An attacker should not be able to determine the plaintext contents of a given record. {::comment}Cite IND-CPA?{:/comment} Integrity: -: An attacker should not be able to craft a new record which is +: An attacker should not be able to craft a new record that is different from an existing record which will be accepted by the receiver. {::comment}Cite INT-CTXT?{:/comment} @@ -5949,7 +6569,7 @@ plaintext with a strong key. AEAD encryption {{RFC5116}} provides confidentialit and integrity for the data. Non-replayability is provided by using a separate nonce for each record, with the nonce being derived from the record sequence number ({{nonce}}), with the sequence -number being maintained independently at both sides; thus records which +number being maintained independently at both sides; thus, records which are delivered out of order result in AEAD deprotection failures. In order to prevent mass cryptanalysis when the same plaintext is repeatedly encrypted by different users under the same key @@ -5968,7 +6588,7 @@ one way, it is not possible to compute traffic keys from prior to a key change TLS does not provide security for data which is communicated on a connection after a traffic secret of that connection is compromised. That is, TLS does not -provide post-compromise security/future secrecy/backward secrecy with respect +provide post-compromise security / future secrecy / backward secrecy with respect to the traffic secret. Indeed, an attacker who learns a traffic secret can compute all future traffic secrets on that connection. Systems which want such guarantees need to do a fresh handshake and establish a new connection with an @@ -5999,7 +6619,7 @@ arbitrary-length encrypted records as well as padding-only cover traffic to conceal the difference between periods of transmission and periods of silence. Because the padding is encrypted alongside the actual content, an attacker cannot -directly determine the length of the padding, but may be able to +directly determine the length of the padding but may be able to measure it indirectly by the use of timing channels exposed during record processing (i.e., seeing how long it takes to process a record or trickling in records to see which ones elicit a response @@ -6048,7 +6668,7 @@ information is not inadvertently leaked. Replayable 0-RTT data presents a number of security threats to TLS-using applications, unless those applications are specifically engineered to be safe under replay -(minimally, this means idempotent, but in many cases may +(minimally, this means idempotent but in many cases may also require other stronger conditions, such as constant-time response). Potential attacks include: @@ -6063,7 +6683,7 @@ a delete to after a create). - Amplifying existing information leaks caused by side effects like caching. An attacker could learn information about the content of a 0-RTT message by replaying it to some cache node that has not cached -some resource of interest, and then using a separate connection to check +some resource of interest and then using a separate connection to check whether that resource has been added to the cache. This could be repeated with different cache nodes as often as the 0-RTT message is replayable. @@ -6081,7 +6701,7 @@ against receiving multiple copies of client data. TLS 1.3 falls back to the 1-RTT handshake when the server does not have any information about the client, e.g., because it is in a different cluster which does not -share state or because the ticket has been deleted as described in +share state or because the ticket has been deleted, as described in {{single-use-tickets}}. If the application-layer protocol retransmits data in this setting, then it is possible for an attacker to induce message duplication by sending the ClientHello to both the original cluster @@ -6092,11 +6712,11 @@ willingness to retry transactions and therefore only allows a limited amount of duplication, with each copy appearing as a new connection at the server. -If implemented correctly, the mechanisms described in -{{single-use-tickets}} and {{client-hello-recording}} prevent a +If implemented correctly, the mechanisms described in Sections +{{single-use-tickets}}{: format="counter"} and {{client-hello-recording}}{: format="counter"} prevent a replayed ClientHello and its associated 0-RTT data from being accepted multiple times by any cluster with consistent state; for servers -which limit the use of 0-RTT to one cluster for a single ticket, then a given +which limit the use of 0-RTT to one cluster for a single ticket, a given ClientHello and its associated 0-RTT data will only be accepted once. However, if state is not completely consistent, then an attacker might be able to have multiple copies of the data be @@ -6174,16 +6794,16 @@ compromised group member can impersonate any other member, a malicious non-member can reroute handshakes between honest group members to connect them in unintended ways {{Selfie}}. {{RFC9257}} provides recommendations for external PSK usage, including the use of external -PSK importers as defined in {{RFC9258}}, that prevent such malicious -rerouting of messages +PSK importers as defined in {{RFC9258}}, that prevents such malicious +rerouting of messages. -## Misbinding when using Self-Signed Certificates or Raw Public Keys +## Misbinding When Using Self-Signed Certificates or Raw Public Keys When TLS 1.3 is used with self-signed certificates without useful identities (as in DTLS-SRTP {{?RFC5763}}) or raw public keys {{RFC7250}} for peer authentication, it may be vulnerable to misbinding attacks {{MM24}}. This risk can be mitigated by using -the "external_id_hash" extension {{?RFC8844}} or, if only +the "external_id_hash" extension {{RFC8844}} or, if only the server is being authenticated, by the server verifying that the "server_name" extension matches its expected identity. @@ -6191,7 +6811,7 @@ that the "server_name" extension matches its expected identity. ## Attacks on Static RSA Although TLS 1.3 does not use RSA key transport and so is not -directly susceptible to Bleichenbacher-type attacks {{Blei98}} if TLS 1.3 +directly susceptible to Bleichenbacher-type attacks {{Blei98}}, if TLS 1.3 servers also support static RSA in the context of previous versions of TLS, then it may be possible to impersonate the server for TLS 1.3 connections {{?JSS15=DOI.10.1145/2810103.2813657}}. TLS @@ -6203,53 +6823,11 @@ relies on clients refusing to accept signatures using keys in certificates that do not have the digitalSignature bit set, and many clients do not enforce this restriction. -# Change Log - -[[RFC EDITOR: Please remove in final RFC.]] -Since -06 -- Updated text about differences from RFC 8446. -- Clarify which parts of IANA considerations are new to this document. -- Upgrade the requirement to initiate key update before exceeding - key usage limits to MUST. -- Add some text around use of the same cert for client and server. - -Since -05 - -- Port in text on key update limits from RFC 9147 (Issue 1257) -- Clarify that you need to ignore NST if you don't do resumption - (Issue 1280) -- Discuss the privacy implications of external key reuse (Issue 1287) -- Advice on key deletion (PR 1282) -- Clarify what unsolicited extensions means (PR 1275) -- close_notify should be warning (PR 1290) -- Reference RFC 8773 (PR 1296) -- Add some more information about application bindings and cite - RFC 9525 (PR 1297) - -Since -04 - -* Update the extension table (Issue 1241) -* Clarify user_canceled (Issue 1208) -* Clarify 0-RTT cache side channels (Issue 1225) -* Require that message reinjection be done with the current hash. - Potentially a clarification and potentially a wire format - change depending on previous interpretation (Issue 1227) - -Changelog not updated between -00 and -03 - -Since -00 - - -* Update TLS 1.2 terminology -* Specify "certificate-based" client authentication -* Clarify that privacy guarantees don't apply when you have null encryption -* Shorten some names -* Address tracking implications of resumption - # Contributors {:numbered="false"} -~~~~ + +~~~ Martin Abadi University of California, Santa Cruz abadi@cs.ucsc.edu @@ -6280,17 +6858,17 @@ Since -00 benjamin.beurdouche@ens.fr Karthikeyan Bhargavan - (editor of [RFC7627]) + (editor of {{RFC7627}}) INRIA karthikeyan.bhargavan@inria.fr Simon Blake-Wilson - (co-author of [RFC4492]) + (co-author of {{RFC4492}}) BCI sblakewilson@bcisse.com Nelson Bolyard - (co-author of [RFC4492]) + (co-author of {{RFC4492}}) Sun Microsystems, Inc. nelson@bolyard.com @@ -6319,7 +6897,7 @@ Since -00 cas.cremers@cs.ox.ac.uk Antoine Delignat-Lavaud - (co-author of [RFC7627]) + (co-author of {{RFC7627}}) INRIA antdl@microsoft.com @@ -6375,12 +6953,12 @@ Since -00 mail@felixguenther.info Vipul Gupta - (co-author of [RFC4492]) + (co-author of {{RFC4492}}) Sun Microsystems Laboratories vipul.gupta@sun.com Chris Hawk - (co-author of [RFC4492]) + (co-author of {{RFC4492}}) Corriente Networks LLC chris@corriente.net @@ -6429,7 +7007,7 @@ Since -00 hugokraw@us.ibm.com Adam Langley - (co-author of [RFC7627]) + (co-author of {{RFC7627}}) Google agl@google.com @@ -6462,7 +7040,7 @@ Since -00 janm@transactionware.com Bodo Moeller - (co-author of [RFC4492]) + (co-author of {{RFC4492}}) Google bodo@acm.org @@ -6491,7 +7069,7 @@ Since -00 cjpatton@ufl.edu Alfredo Pironti - (co-author of [RFC7627]) + (co-author of {{RFC7627}}) INRIA alfredo.pironti@inria.fr @@ -6499,12 +7077,12 @@ Since -00 Microsoft andrei.popov@microsoft.com - John {{{Preuß Mattsson}}} + John Preuß Mattsson Ericsson john.mattsson@ericsson.com Marsh Ray - (co-author of [RFC7627]) + (co-author of {{RFC7627}}) Microsoft maray@microsoft.com @@ -6631,4 +7209,68 @@ Since -00 Kazu Yamamoto Internet Initiative Japan Inc. kazu@iij.ad.jp -~~~~ +~~~ + + + + + + + + + + + + + From 78ec1985647b9bb0999323a569e45e053eeac66b Mon Sep 17 00:00:00 2001 From: EKR Date: Mon, 22 Dec 2025 15:40:52 -0800 Subject: [PATCH 2/2] Updated RPC version with fewer gratuitous changes --- rfc9846.md | 527 ++++++++++++++++++++++++++--------------------------- 1 file changed, 263 insertions(+), 264 deletions(-) diff --git a/rfc9846.md b/rfc9846.md index b89f3b01..4e03f6f0 100644 --- a/rfc9846.md +++ b/rfc9846.md @@ -161,8 +161,7 @@ informative: - ins: K. Paterson target: https://eprint.iacr.org/2024/051 - date: 2024 - refcontent: Cryptology ePrint Archive, Paper 2024/051 + date: August 2017 HGFS15: title: "Prying Open Pandora's Box: KCI Attacks against TLS" target: https://www.usenix.org/conference/woot15/workshop-program/presentation/hlauschek @@ -175,7 +174,7 @@ informative: ins: F. Fankhauser - ins: C. Schanes - refcontent: 9th USENIX Workshop on Offensive Technologies (WOOT 15) + refcontent: Proceedings of USENIX Workshop on Offensive Technologies date: 2015 FGSW16: title: "Key Confirmation in Key Exchange: A Formal Treatment and Implications for TLS 1.3" @@ -188,7 +187,7 @@ informative: ins: B. Schmidt - ins: B. Warinschi - refcontent: 2016 IEEE Symposium on Security and Privacy (SP), pp. 452-469 + refcontent: Proceedings of IEEE Symposium on Security and Privacy (Oakland) 2016 seriesinfo: DOI: 10.1109/SP.2016.34 target: http://ieeexplore.ieee.org/document/7546517/ @@ -225,8 +224,8 @@ informative: ins: S. Zanella-Beguelin - ins: J. Zinzindohoue - refcontent: Cryptology ePrint Archive, Paper 2016/1178 - date: 2016 + refcontent: Proceedings of IEEE Symposium on Security and Privacy (San Jose) 2017 + date: 2016-12 target: https://eprint.iacr.org/2016/1178 Blei98: @@ -235,7 +234,7 @@ informative: author: - ins: D. Bleichenbacher - refcontent: Advances in Cryptology - CRYPTO '98, Lecture Notes in Computer Science, vol. 1462, pp. 1-12 + refcontent: Proceedings of CRYPTO '98 date: 1998 BMMRT15: @@ -251,8 +250,8 @@ informative: ins: P. Rogaway - ins: B. Tackmann - refcontent: Cryptology ePrint Archive, Paper 2015/394 - date: 2015 + refcontent: ProvSec 2015 + date: September 2015 target: https://eprint.iacr.org/2015/394 BT16: @@ -262,14 +261,14 @@ informative: ins: M. Bellare - ins: B. Tackmann - refcontent: Cryptology ePrint Archive, Paper 2016/564 - date: 2016 + refcontent: Proceedings of CRYPTO 2016 + date: July 2016 target: https://eprint.iacr.org/2016/564 Kraw16: title: "A Unilateral-to-Mutual Authentication Compiler for Key Exchange (with Applications to Client Authentication in TLS 1.3" - date: 2016 - refcontent: Cryptology ePrint Archive, Paper 2016/711 + date: October 2016 + refcontent: Proceedings of ACM CCS 2016 target: https://eprint.iacr.org/2016/711 author: - @@ -277,8 +276,8 @@ informative: KW16: title: "The OPTLS Protocol and TLS 1.3" - date: 2015 - refcontent: Cryptology ePrint Archive, Paper 2015/978 + date: March 2016 + refcontent: Proceedings of Euro S&P 2016 target: https://eprint.iacr.org/2015/978 author: - @@ -288,8 +287,8 @@ informative: DFGS15: title: "A Cryptographic Analysis of the TLS 1.3 draft-10 Full and Pre-shared Key Handshake Protocol" - date: 2015 - refcontent: Cryptology ePrint Archive, Paper 2015/914 + date: October 2015 + refcontent: Proceedings of ACM CCS 2015 target: https://eprint.iacr.org/2015/914 author: - @@ -303,8 +302,8 @@ informative: DFGS16: title: "A Cryptographic Analysis of the TLS 1.3 draft-10 Full and Pre-shared Key Handshake Protocol" - date: 2016 - refcontent: Cryptology ePrint Archive, Paper 2016/081 + date: February 2016 + refcontent: TRON 2016 target: https://eprint.iacr.org/2016/081 author: - @@ -318,8 +317,8 @@ informative: FG17: title: "Replay Attacks on Zero Round-Trip Time: The Case of the TLS 1.3 Handshake Candidates" - date: 2017 - refcontent: Cryptology ePrint Archive, Paper 2017/082 + date: April 2017 + refcontent: Proceedings of Euro S&P 2017 target: https://eprint.iacr.org/2017/082 author: - @@ -330,7 +329,7 @@ informative: Kraw10: title: "Cryptographic Extraction and Key Derivation: The HKDF Scheme" date: 2010 - refcontent: Cryptology ePrint Archive, Paper 2010/264 + refcontent: Proceedings of CRYPTO 2010 target: https://eprint.iacr.org/2010/264 author: - @@ -384,7 +383,6 @@ informative: title: "Partially specified channels: The TLS 1.3 record layer without elision" date: 2018 - refcontent: Cryptology ePrint Archive, Paper 2018/634 author: - ins: C. Patton @@ -428,7 +426,6 @@ informative: Selfie: title: "Selfie: reflections on TLS 1.3 with PSK" date: 2019 - refcontent: Cryptology ePrint Archive, Paper 2019/347 target: https://eprint.iacr.org/2019/347 author: - @@ -576,7 +573,7 @@ TLS consists of two primary components: traffic keys. TLS is application protocol independent; higher-level protocols can -layer on top of TLS transparently. However, the TLS standard does not +layer on top of TLS transparently. The TLS standard, however, does not specify how protocols add security with TLS; how to initiate TLS handshaking and how to interpret the authentication certificates exchanged are left to the judgment of the designers and @@ -631,7 +628,6 @@ sender: server: : The endpoint that did not initiate the TLS connection. - ## Relationship to RFC 8446 TLS 1.3 was originally specified in {{?RFC8446}}. This document is a @@ -686,7 +682,6 @@ Perhaps: In addition, there have been some improvements to the security considerations, especially around privacy. - ## Major Differences from TLS 1.2 The following is a list of the major functional differences between @@ -698,14 +693,14 @@ are many minor differences. with Associated Data (AEAD) algorithms. The cipher suite concept has been changed to separate the authentication and key exchange mechanisms from the record protection algorithm (including secret key length) and a hash - to be used with both the key derivation function and handshake Message - Authentication Code (MAC). + to be used with both the key derivation function and handshake message + authentication code (MAC). - A zero round-trip time (0-RTT) mode was added, saving a round trip at connection setup for some application data, at the cost of certain security properties. - Static RSA and Diffie-Hellman cipher suites have been removed; - all public-key-based key exchange mechanisms now provide forward secrecy. + all public-key based key exchange mechanisms now provide forward secrecy. - All handshake messages after the ServerHello are now encrypted. The newly introduced EncryptedExtensions message allows various extensions @@ -831,7 +826,7 @@ Auth | {CertificateVerify*} ~~~ {: #tls-full title="Message Flow for Full TLS Handshake"} - - HelloRetryRequest - <-------- + key_share - ClientHello - + key_share --------> - ServerHello - + key_share - {EncryptedExtensions} - {CertificateRequest*} - {Certificate*} - {CertificateVerify*} - {Finished} - <-------- [Application Data*] - {Certificate*} - {CertificateVerify*} - {Finished} --------> - [Application Data] <-------> [Application Data] + Client Server + + ClientHello + + key_share --------> + HelloRetryRequest + <-------- + key_share + ClientHello + + key_share --------> + ServerHello + + key_share + {EncryptedExtensions} + {CertificateRequest*} + {Certificate*} + {CertificateVerify*} + {Finished} + <-------- [Application Data*] + {Certificate*} + {CertificateVerify*} + {Finished} --------> + [Application Data] <-------> [Application Data] ~~~ {: #tls-restart title="Message Flow for a Full Handshake with Mismatched Parameters"} @@ -1068,39 +1064,39 @@ handshake in the first flight. The rest of the handshake uses the same messages as for a 1-RTT handshake with PSK resumption. ~~~ aasvg - Client Server - - ClientHello - + early_data - + key_share* - + psk_key_exchange_modes - + pre_shared_key - (Application Data*) --------> - ServerHello - + pre_shared_key - + key_share* - {EncryptedExtensions} - + early_data* - {Finished} - <-------- [Application Data*] - (EndOfEarlyData) - {Finished} --------> - [Application Data] <-------> [Application Data] - - + Indicates noteworthy extensions sent in the - previously noted message. - - * Indicates optional or situation-dependent - messages/extensions that are not always sent. - - () Indicates messages protected using keys - derived from a client_early_traffic_secret. - - {} Indicates messages protected using keys - derived from a [sender]_handshake_traffic_secret. - - [] Indicates messages protected using keys - derived from [sender]_application_traffic_secret_N. + Client Server + + ClientHello + + early_data + + key_share* + + psk_key_exchange_modes + + pre_shared_key + (Application Data*) --------> + ServerHello + + pre_shared_key + + key_share* + {EncryptedExtensions} + + early_data* + {Finished} + <-------- [Application Data*] + (EndOfEarlyData) + {Finished} --------> + [Application Data] <-------> [Application Data] + + + Indicates noteworthy extensions sent in the + previously noted message. + + * Indicates optional or situation-dependent + messages/extensions that are not always sent. + + () Indicates messages protected using keys + derived from a client_early_traffic_secret. + + {} Indicates messages protected using keys + derived from a [sender]_handshake_traffic_secret. + + [] Indicates messages protected using keys + derived from [sender]_application_traffic_secret_N. ~~~ {: #tls-0-rtt title="Message Flow for a 0-RTT Handshake"} @@ -1115,6 +1111,7 @@ as part of the protocol. Therefore, absent out-of-band knowledge of the server's behavior, the client should assume that this data is not forward secret. + 2. There are no guarantees of non-replay between connections. Protection against replay for ordinary TLS 1.3 1-RTT data is provided via the server's Random value, but 0-RTT data does not depend @@ -1141,7 +1138,6 @@ be used. In the definitions below, optional components of this syntax are denoted by enclosing them in "\[\[ \]\]" (double brackets). - ## Basic Block Size The representation of all data items is explicitly specified. The basic data @@ -1412,13 +1408,13 @@ the traffic keys used to protect the rest of the handshake and the data. In TLS, the cryptographic negotiation proceeds by the client offering the following four sets of options in its ClientHello: -- A list of cipher suites that indicates the AEAD algorithm / HKDF hash +- A list of cipher suites which indicates the AEAD algorithm/HKDF hash pairs which the client supports. - A "supported_groups" ({{supported-groups}}) extension which indicates the (EC)DHE groups - that the client supports and a "key_share" ({{key-share}}) extension which contains + which the client supports and a "key_share" ({{key-share}}) extension which contains (EC)DHE shares for some or all of these groups. - A "signature_algorithms" ({{signature-algorithms}}) extension which indicates the signature - algorithms that the client can accept. A "signature_algorithms_cert" extension ({{signature-algorithms}}) may also be + algorithms which the client can accept. A "signature_algorithms_cert" extension ({{signature-algorithms}}) may also be added to indicate certificate-specific signature algorithms. - A "pre_shared_key" ({{pre-shared-key-extension}}) extension which contains a list of symmetric key identities known to the client and a @@ -1427,7 +1423,7 @@ following four sets of options in its ClientHello: with PSKs. If the server does not select a PSK, then the first three of these -options are entirely orthogonal: The server independently selects a +options are entirely orthogonal: the server independently selects a cipher suite, an (EC)DHE group and key share for key establishment, and a signature algorithm/certificate pair to authenticate itself to the client. If there is no overlap between the received "supported_groups" @@ -1458,7 +1454,7 @@ follows: - When authenticating via a certificate, the server will send the Certificate ({{certificate}}) and CertificateVerify - ({{certificate-verify}}) messages. In TLS 1.3, + ({{certificate-verify}}) messages. In TLS 1.3 as defined by this document, either a PSK or a certificate is always used, but not both. Future documents may define how to use them together. @@ -1510,19 +1506,19 @@ previous protocol version. In particular, it MUST NOT negotiate TLS 1.3. Structure of this message: ~~~ - uint16 ProtocolVersion; - opaque Random[32]; - - uint8 CipherSuite[2]; /* Cryptographic suite selector */ - - struct { - ProtocolVersion legacy_version = 0x0303; /* TLS v1.2 */ - Random random; - opaque legacy_session_id<0..32>; - CipherSuite cipher_suites<2..2^16-2>; - opaque legacy_compression_methods<1..2^8-1>; - Extension extensions<8..2^16-1>; - } ClientHello; + uint16 ProtocolVersion; + opaque Random[32]; + + uint8 CipherSuite[2]; /* Cryptographic suite selector */ + + struct { + ProtocolVersion legacy_version = 0x0303; /* TLS v1.2 */ + Random random; + opaque legacy_session_id<0..32>; + CipherSuite cipher_suites<2..2^16-2>; + opaque legacy_compression_methods<1..2^8-1>; + Extension extensions<8..2^16-1>; + } ClientHello; ~~~ {: gi="sourcecode"} @@ -1631,14 +1627,14 @@ set of handshake parameters based on the ClientHello. Structure of this message: ~~~ - struct { - ProtocolVersion legacy_version = 0x0303; /* TLS v1.2 */ - Random random; - opaque legacy_session_id_echo<0..32>; - CipherSuite cipher_suite; - uint8 legacy_compression_method = 0; - Extension extensions<6..2^16-1>; - } ServerHello; + struct { + ProtocolVersion legacy_version = 0x0303; /* TLS v1.2 */ + Random random; + opaque legacy_session_id_echo<0..32>; + CipherSuite cipher_suite; + uint8 legacy_compression_method = 0; + Extension extensions<6..2^16-1>; + } ServerHello; ~~~ {: gi="sourcecode"} @@ -1689,7 +1685,7 @@ extensions: which are required to establish the cryptographic context and negotiate the protocol version. All TLS 1.3 ServerHello messages MUST contain the "supported_versions" extension. Current ServerHello messages additionally contain - the "pre_shared_key" extension, "key_share" extension, or both (when using + the "pre_shared_key" extension or the "key_share" extension, or both (when using a PSK with (EC)DHE key establishment). Other extensions (see {{extensions}}) are sent separately in the EncryptedExtensions message. @@ -1697,7 +1693,7 @@ extensions: For reasons of backward compatibility with middleboxes (see {{middlebox}}), the HelloRetryRequest -message uses the same structure as the ServerHello but with +message uses the same structure as the ServerHello, but with Random set to the special value of the SHA-256 of "HelloRetryRequest": @@ -1870,7 +1866,7 @@ response (i.e., indications). The client sends its extension requests in the ClientHello message, and the server sends its extension responses in the ServerHello, EncryptedExtensions, HelloRetryRequest, and Certificate messages. The server sends extension requests in the -CertificateRequest message, which a client MAY respond to with a +CertificateRequest message which a client MAY respond to with a Certificate message. The server MAY also send unsolicited extensions in the NewSessionTicket, though the client does not respond directly to these. @@ -1949,12 +1945,12 @@ Current: | ticket_request {{RFC9149}} | CH, EE| {: #extensions-list title="TLS Extensions"} -Note: This table only includes extensions marked as +Note: This table includes only extensions marked "Recommended" at the time of this writing. When multiple extensions of different types are present, the extensions MAY appear in any order, with the exception of -"pre_shared_key" ({{pre-shared-key-extension}}), which MUST be +"pre_shared_key" ({{pre-shared-key-extension}}) which MUST be the last extension in the ClientHello (but can appear anywhere in the ServerHello extensions block). There MUST NOT be more than one extension of the same type in a given @@ -1966,7 +1962,7 @@ those negotiated in the previous handshake; mismatches may require rejecting 0-RTT (see {{early-data-indication}}). There are subtle (and not so subtle) interactions that may occur in this -protocol between new features and existing features, which may result in a +protocol between new features and existing features which may result in a significant reduction in overall security. The following considerations should be taken into account when designing new extensions: @@ -2039,7 +2035,7 @@ extension. A server which negotiates TLS 1.3 MUST respond by sending a After checking ServerHello.random to determine if the server handshake message is a ServerHello or HelloRetryRequest, clients MUST check for this extension prior to processing the rest of the ServerHello. This will require clients to -parse the ServerHello to read the extension. +parse the ServerHello to read the extension. If this extension is present, clients MUST ignore the ServerHello.legacy_version value and MUST use only the "supported_versions" extension to determine the selected version. If the @@ -2199,7 +2195,7 @@ RSASSA-PSS PSS algorithms: Legacy algorithms: : Indicates algorithms which are being deprecated because they use - algorithms with known weaknesses, specifically SHA-1, which is used + algorithms with known weaknesses, specifically SHA-1 which is used in this context with either (1) RSA using RSASSA-PKCS1-v1_5 or (2) ECDSA. These values refer solely to signatures which appear in certificates (see {{certificate-selection}}) and are not defined for use in @@ -2272,7 +2268,7 @@ The client MAY send the "certificate_authorities" extension in the ClientHello message. The server MAY send it in the CertificateRequest message. The "trusted_ca_keys" extension {{RFC6066}}, which serves a similar -purpose but is more complicated, is not used in TLS 1.3 +purpose, but is more complicated, is not used in TLS 1.3 (although it may appear in ClientHello messages from clients which are offering prior versions of TLS). @@ -2305,7 +2301,7 @@ filters: and skip any unrecognized certificate extension OIDs. If the client ignored some of the required certificate extension OIDs and supplied a certificate that does not satisfy the request, the server MAY at its discretion either - continue the connection without client authentication, or abort the handshake + continue the connection without client authentication or abort the handshake with an "unsupported_certificate" alert. Any given OID MUST NOT appear more than once in the filters list. @@ -2461,13 +2457,13 @@ though saving the round trip of HelloRetryRequest. Servers that wish to respect the client's group preferences SHOULD first select a group based on "supported_groups" and then either send a ServerHello or a HelloRetryRequest depending on the contents of -KeyshareClienthello. +KeyshareClienthello. Clients can offer as many KeyShareEntry values as the number of supported groups it is offering, each representing a single set of key exchange parameters. For instance, a client might offer shares for several elliptic curves or multiple -Finite Field DHE (FFDHE) groups. The key_exchange values for each KeyShareEntry MUST be +FFDHE groups. The key_exchange values for each KeyShareEntry MUST be generated independently. Clients MUST NOT offer multiple KeyShareEntry values for the same group. Clients MUST NOT offer any KeyShareEntry values for groups not listed in the client's @@ -2626,7 +2622,7 @@ in the ServerHello. ### Early Data Indication When a PSK is used and early data is allowed for that PSK -(for instance, see {{ticket-establishment}}), the client can send Application Data +(see for instance {{ticket-establishment}}), the client can send Application Data in its first flight of messages. If the client opts to do so, it MUST supply both the "pre_shared_key" and "early_data" extensions. @@ -2660,7 +2656,7 @@ the ticket age for the selected PSK identity (computed by subtracting ticket_age_add from PskIdentity.obfuscated_ticket_age modulo 232) is within a small tolerance of the time since the ticket was issued (see {{anti-replay}}). If it is not, -the server SHOULD proceed with the handshake but reject 0-RTT and +the server SHOULD proceed with the handshake but reject 0-RTT, and SHOULD NOT take any other action that assumes that this ClientHello is fresh. @@ -2815,12 +2811,12 @@ implementations were not consistent on which of two supplied SNI values they would use, leading to the consistency requirement being de facto enforced by the clients. In TLS 1.3, the SNI value is always explicitly specified in the resumption handshake, and there is no need for the server to associate an SNI value with the -ticket. However, clients SHOULD store the SNI with the PSK to fulfill +ticket. Clients, however, SHOULD store the SNI with the PSK to fulfill the requirements of {{NSTMessage}}. Implementor's note: When session resumption is the primary use case of PSKs, the most straightforward way to implement the -PSK / cipher suite matching requirements is to negotiate the cipher +PSK/cipher suite matching requirements is to negotiate the cipher suite first and then exclude any incompatible PSKs. Any unknown PSKs (e.g., ones not in the PSK database or encrypted with an unknown key) SHOULD simply be ignored. If no acceptable PSKs are @@ -2832,7 +2828,7 @@ Prior to accepting PSK key establishment, the server MUST validate the corresponding binder value (see {{psk-binder}} below). If this value is not present or does not validate, the server MUST abort the handshake. Servers SHOULD NOT attempt to validate multiple binders; rather, they -SHOULD select a single PSK and solely validate the binder that +SHOULD select a single PSK and validate solely the binder that corresponds to that PSK. See {{client-hello-recording}} and {{psk-identity-exposure}} for the security rationale for this requirement. @@ -2900,7 +2896,7 @@ binder will be computed over: Transcript-Hash(Truncate(ClientHello1)) -where Truncate() removes the binders list from the ClientHello. +Where Truncate() removes the binders list from the ClientHello. Note that this hash will be computed using the hash associated with the PSK, as the client does not know which cipher suite the server will select. @@ -2956,9 +2952,9 @@ extensions and if any are found MUST abort the handshake with an Structure of this message: ~~~ - struct { - Extension extensions<0..2^16-1>; - } EncryptedExtensions; + struct { + Extension extensions<0..2^16-1>; + } EncryptedExtensions; ~~~ {: gi="sourcecode"} @@ -2969,16 +2965,16 @@ extensions: ### Certificate Request A server which is authenticating with a certificate MAY optionally -request a certificate from the client. If sent, this message MUST +request a certificate from the client. This message, if sent, MUST follow EncryptedExtensions. Structure of this message: ~~~ - struct { - opaque certificate_request_context<0..2^8-1>; - Extension extensions<0..2^16-1>; - } CertificateRequest; + struct { + opaque certificate_request_context<0..2^8-1>; + Extension extensions<0..2^16-1>; + } CertificateRequest; ~~~ {: gi="sourcecode"} @@ -3016,28 +3012,28 @@ Servers which are authenticating with a resumption PSK MUST NOT send the CertificateRequest message in the main handshake, though they MAY send it in post-handshake authentication (see {{post-handshake-authentication}}) provided that the client has sent the "post_handshake_auth" -extension (see {{post_handshake_auth}}). -In the absence of some other specification to the contrary, +extension (see {{post_handshake_auth}}). + In the absence of some other specification to the contrary, servers which are authenticating with an external PSK MUST NOT send the CertificateRequest message in the main handshake or request post-handshake authentication. {{RFC8773}} provides an extension to permit this -but has received less analysis than this specification. +but has received less analysis than this specification. ## Authentication Messages As discussed in {{protocol-overview}}, TLS generally uses a common set of messages for authentication, key confirmation, and handshake integrity: Certificate, CertificateVerify, and Finished. -(The PSK binders also perform key confirmation in a +(The PSK binders also perform key confirmation, in a similar fashion.) These three messages are always sent as the last messages in their handshake flight. The Certificate and CertificateVerify messages are only sent under certain circumstances, as defined below. The Finished message is always sent as part of the Authentication Block. -These messages are encrypted under keys derived from the + These messages are encrypted under keys derived from the \[sender\]_handshake_traffic_secret, -except for post-handshake authentication. +except for post-handshake authentication. The computations for the Authentication messages all uniformly take the following inputs: @@ -3081,15 +3077,15 @@ for each scenario: Many of the cryptographic computations in TLS make use of a transcript hash. This value is computed by hashing the concatenation of each included handshake message, including the handshake -message header carrying the handshake message type and length fields -but not including record layer headers. That is, +message header carrying the handshake message type and length fields, +but not including record layer headers. I.e., Transcript-Hash(M1, M2, ... Mn) = Hash(M1 || M2 || ... || Mn) As an exception to this general rule, when the server responds to a ClientHello with a HelloRetryRequest, the value of ClientHello1 is replaced with a special synthetic handshake message of handshake -type "message_hash" containing Hash(ClientHello1). That is, +type "message_hash" containing Hash(ClientHello1). I.e., Transcript-Hash(ClientHello1, HelloRetryRequest, ... Mn) = Hash(message_hash || /* Handshake type */ @@ -3111,8 +3107,8 @@ server CertificateVerify, server Finished, EndOfEarlyData, client Certificate, client CertificateVerify, and client Finished. In general, implementations can implement the transcript by keeping a -running transcript hash value based on the negotiated hash. However, -note that subsequent post-handshake authentications do not include +running transcript hash value based on the negotiated hash. Note, however, +that subsequent post-handshake authentications do not include each other, just the messages through the end of the main handshake. ### Certificate @@ -3274,7 +3270,7 @@ The following rule additionally applies to certificates sent by the server: clients SHOULD send this extension when the server is identified by name. All certificates provided by the sender MUST be signed by a -signature algorithm advertised by the peer if it is able to provide such +signature algorithm advertised by the peer, if it is able to provide such a chain (see {{signature-algorithms}}). Certificates that are self-signed or certificates that are expected to be trust anchors are not validated as @@ -3297,7 +3293,7 @@ handshake with an appropriate certificate-related alert (by default, "unsupported_certificate"; see {{error-alerts}} for more information). If the sender has multiple certificates, it chooses one of them based on the -above-mentioned criteria (in addition to other criteria, such as transport-layer endpoint, local configuration, and preferences). +above-mentioned criteria (in addition to other criteria, such as transport-layer endpoint, local configuration, and preferences). #### Receiving a Certificate Message @@ -3310,7 +3306,7 @@ the handshake with a "decode_error" alert. If the client does not send any certificates (i.e., it sends an empty Certificate message), the server MAY at its discretion either continue the handshake without client -authentication or abort the handshake with a "certificate_required" alert. Also, if some +authentication, or abort the handshake with a "certificate_required" alert. Also, if some aspect of the certificate chain was unacceptable (e.g., it was not signed by a known, trusted CA), the server MAY at its discretion either continue the handshake (considering the client unauthenticated) or abort the handshake. @@ -3345,10 +3341,10 @@ after the Certificate message and immediately prior to the Finished message. Structure of this message: ~~~ - struct { - SignatureScheme algorithm; - opaque signature<0..2^16-1>; - } CertificateVerify; + struct { + SignatureScheme algorithm; + opaque signature<0..2^16-1>; + } CertificateVerify; ~~~ {: gi="sourcecode"} @@ -3464,24 +3460,29 @@ finished_key = Structure of this message: ~~~ - struct { - opaque verify_data[Hash.length]; - } Finished; + struct { + opaque verify_data[Hash.length]; + } Finished; ~~~ {: gi="sourcecode"} The verify_data value is computed as follows: ~~~ - verify_data = - HMAC(finished_key, - Transcript-Hash(Handshake Context, - Certificate*, CertificateVerify*)) + verify_data = + HMAC(finished_key, + Transcript-Hash(Handshake Context, + Certificate*, CertificateVerify*)) ~~~ {: gi="sourcecode"} - @@ -3537,20 +3538,20 @@ derived from the resumption secret (see {{cryptographic-computations}}). The client MAY use this PSK for future handshakes by including the ticket value in the "pre_shared_key" extension in its ClientHello ({{pre-shared-key-extension}}). -Clients which receive a NewSessionTicket message but do + Clients which receive a NewSessionTicket message but do not support resumption MUST silently ignore this message. Resumption MAY be done while the original connection is still open. Servers MAY send multiple tickets on a single connection, either immediately after each other or after specific events (see {{client-tracking}}). For instance, the server might send a new ticket after post-handshake -authentication, thus encapsulating the additional client +authentication thus encapsulating the additional client authentication state. Multiple tickets are useful for clients for a variety of purposes, including: - Opening multiple parallel HTTP connections. - Performing connection racing across interfaces and address families -via, for example, Happy Eyeballs {{RFC8305}} or related techniques. +via (for example) Happy Eyeballs {{RFC8305}} or related techniques. Any ticket MUST only be resumed with a cipher suite that has the same KDF hash algorithm as that used to establish the original connection. @@ -3684,7 +3685,7 @@ received (the certificate_request_context value allows the server to disambiguate the responses). -### Key and Initialization Vector (IV) Update {#key-update} +### Key and Initialization Vector Update {#key-update} The KeyUpdate handshake message is used to indicate that the sender is updating its sending cryptographic keys. This message can be sent by @@ -3748,7 +3749,7 @@ chance of a joint key/IV collision is much lower. To provide an extra margin of security, sending implementations MUST NOT allow the epoch -- and hence the number of key updates -- to exceed 248-1. In order to allow this value to be changed later --- for instance, for ciphers with more than 128-bit keys -- +-- for instance for ciphers with more than 128-bit keys -- receiving implementations MUST NOT enforce this rule. If a sending implementation receives a KeyUpdate with request_update set to "update_requested", it MUST NOT send its own @@ -3793,7 +3794,7 @@ Implementations MUST NOT send record types not defined in this document unless negotiated by some extension. If a TLS implementation receives an unexpected record type, it MUST terminate the connection with an "unexpected_message" alert. New record content type values -are assigned by IANA in the "TLS ContentType" registry as described in +are assigned by IANA in the TLS ContentType registry as described in {{iana-considerations}}. ## Record Layer @@ -3966,7 +3967,7 @@ data" to be included in the authentication check, as described in {{Section 2.1 of RFC5116}}. The key is either the client_write_key or the server_write_key, the nonce is derived from the sequence number and the client_write_iv or server_write_iv (see {{nonce}}), and the additional data input is the -record header. That is, +record header. I.e., additional_data = TLSCiphertext.opaque_type || TLSCiphertext.legacy_record_version || @@ -4018,7 +4019,7 @@ first record transmitted under a particular traffic key MUST use sequence number 0. -Because the size of sequence numbers is 64 bits, they should not +Because the size of sequence numbers is 64-bit, they should not wrap. If a TLS implementation would need to wrap a sequence number, it MUST either rekey ({{key-update}}) or terminate the connection. @@ -4079,7 +4080,7 @@ a non-zero octet in the cleartext, it MUST terminate the connection with an "unexpected_message" alert. The presence of padding does not change the overall record size limitations: -The full encoded TLSInnerPlaintext MUST NOT exceed 214 + 1 octets. If the +the full encoded TLSInnerPlaintext MUST NOT exceed 214 + 1 octets. If the maximum fragment length is reduced -- as for example by the record_size_limit extension from {{?RFC8449}} -- then the reduced limit applies to the full plaintext, including the content type and padding. @@ -4088,8 +4089,8 @@ Selecting a padding policy that suggests when and how much to pad is a complex topic and is beyond the scope of this specification. If the application-layer protocol on top of TLS has its own padding, it may be preferable to pad Application Data TLS records within the application -layer. However, padding for encrypted Handshake or Alert records must -still be handled at the TLS layer. Later documents may define +layer. Padding for encrypted Handshake or Alert records must +still be handled at the TLS layer, though. Later documents may define padding selection algorithms or define a padding policy request mechanism through TLS extensions or some other means. @@ -4105,7 +4106,7 @@ do a key update as described in {{key-update}} prior to reaching these limits. Note that it is not possible to perform a KeyUpdate for early data; therefore, implementations MUST NOT exceed the limits when sending early data. Receiving implementations SHOULD NOT enforce -these limits, as future analyses may result in updated values. +these limits, as future analyses may result in updated values. For AES-GCM, up to 224.5 full-size records (about 24 million) may be encrypted on a given connection while keeping a safety @@ -4215,7 +4216,7 @@ user_canceled: MUST be followed by a "close_notify". This alert generally has AlertLevel=warning. Receiving implementations SHOULD continue to read data from the peer until a "close_notify" is received, - though they MAY log or otherwise record them. + though they MAY log or otherwise record them. {:br } Either party MAY initiate a close of its write side of the connection by @@ -4262,7 +4263,7 @@ Whenever an implementation encounters a fatal error condition, it SHOULD send an appropriate fatal alert and MUST close the connection without sending or receiving any additional data. Throughout this specification, when the phrases "terminate the connection" and "abort the -handshake" are used without a specific alert, it means that the +handshake" are used without a specific alert it means that the implementation SHOULD send the alert indicated by the descriptions below. The phrases "terminate the connection with an X alert" and "abort the handshake with an X alert" mean that the implementation @@ -4416,7 +4417,7 @@ general_error: no_application_protocol: : Sent by servers when a client - "application_layer_protocol_negotiation" extension only advertises + "application_layer_protocol_negotiation" extension advertises only protocols that the server does not support (see {{RFC7301}}). {:br } @@ -4448,7 +4449,7 @@ defined below: ~~~~ {: gi="sourcecode"} -where HkdfLabel is specified as: +Where HkdfLabel is specified as: ~~~~ struct { @@ -4467,7 +4468,7 @@ The Hash function used by Transcript-Hash and HKDF is the cipher suite hash algorithm. Hash.length is its output length in bytes. Messages is the concatenation of the indicated handshake messages, including the handshake message type -and length fields but not including record layer headers. Note that +and length fields, but not including record layer headers. Note that in some cases a zero-length Context (indicated by "") is passed to HKDF-Expand-Label. The labels specified in this document are all ASCII strings and do not include a trailing NUL byte. @@ -4649,7 +4650,7 @@ of data is shown in the table below. {: #traffic-key-table title="Secrets for Traffic Keys"} Alerts are sent with the then-current sending key (or as -plaintext if no such key has been established.) +plaintext if no such key has been established.) All the traffic keying material is recomputed whenever the underlying Secret changes (e.g., when changing from the handshake to Application Data keys or upon a key update). @@ -4665,21 +4666,21 @@ The negotiated key (Z) is converted to a byte string by encoding in big-endian f left-padded with zeros up to the size of the prime. This byte string is used as the shared secret in the key schedule as specified above. -Note that this construction differs from previous versions of TLS, which remove +Note that this construction differs from previous versions of TLS which remove leading zeros. ### Elliptic Curve Diffie-Hellman - For secp256r1, secp384r1, and secp521r1, ECDH calculations (including key - generation and shared secret calculation) are performed according to - Sections 5.6.1.2 and 5.7.1.2 of {{KEYAGREEMENT}} using the Elliptic Curve - Cryptography Cofactor Diffie-Hellman Primitive. The shared secret Z is - the x-coordinate of the ECDH shared secret elliptic curve point represented - as an octet string. Note that the octet string Z as output by the - Field-Element-to-Byte String Conversion specified in Appendix C.2 of - {{KEYAGREEMENT}} has constant length for any given field; leading zeros - found in this octet string MUST NOT be truncated. See {{ecdhe-param}} for - requirements on public-key validation. +For secp256r1, secp384r1, and secp521r1, ECDH calculations (including key +generation and shared secret calculation) are performed according to +Sections 5.6.1.2 and 5.7.1.2 of {{KEYAGREEMENT}} using the Elliptic Curve +Cryptography Cofactor Diffie-Hellman Primitive. The shared secret Z is +the x-coordinate of the ECDH shared secret elliptic curve point represented +as an octet string. Note that the octet string Z as output by the +Field-Element-to-Byte String Conversion specified in Appendix C.2 of +{{KEYAGREEMENT}} has constant length for any given field; leading zeros +found in this octet string MUST NOT be truncated. See {{ecdhe-param}} for +requirements on public-key validation. For X25519 and X448, the ECDH calculations are as follows: @@ -4713,7 +4714,7 @@ The exporter value is computed as: HKDF-Expand-Label(Derive-Secret(Secret, label, ""), "exporter", Hash(context_value), key_length) -where Secret is either the early_exporter_secret or the +Where Secret is either the early_exporter_secret or the exporter_secret. Implementations MUST use the exporter_secret unless explicitly specified by the application. The early_exporter_secret is defined for use in settings where an exporter is needed for 0-RTT data. @@ -4753,7 +4754,7 @@ concerned with: multiple zones where tickets from zone A will not be accepted in zone B, then an attacker can duplicate a ClientHello and early data intended for A to both A and B. At A, the data will - be accepted in 0-RTT, but at B, the server will reject 0-RTT + be accepted in 0-RTT, but at B the server will reject 0-RTT data and instead force a full handshake. If the attacker blocks the ServerHello from A, then the client will complete the handshake with B and probably retry the request, leading to duplication on @@ -4762,7 +4763,7 @@ concerned with: The first class of attack can be prevented by sharing state to guarantee that the 0-RTT data is accepted at most once. Servers SHOULD provide that level of replay safety by implementing one of the methods described in this section or -by equivalent means. However, it is understood that due to operational +by equivalent means. It is understood, however, that due to operational concerns not all deployments will maintain state at that level. Therefore, in normal operation, clients will not know which, if any, of these mechanisms servers actually implement and hence MUST only send early data which they deem @@ -4770,7 +4771,7 @@ safe to be replayed. In addition to the direct effects of replays, there is a class of attacks where even operations normally considered idempotent could be exploited by a large -number of replays (timing attacks, resource limit exhaustion, and others, as +number of replays (timing attacks, resource limit exhaustion and others, as described in {{replay-0rtt}}). Those can be mitigated by ensuring that every 0-RTT payload can be replayed only a limited number of times. The server MUST ensure that any instance of it (be it a machine, a thread, or any other entity @@ -4778,7 +4779,7 @@ within the relevant serving infrastructure) would accept 0-RTT for the same 0-RTT handshake at most once; this limits the number of replays to the number of server instances in the deployment. Such a guarantee can be accomplished by locally recording data from recently received ClientHellos and rejecting -repeats or by any other method that provides the same or a stronger guarantee. +repeats, or by any other method that provides the same or a stronger guarantee. The "at most once per server instance" guarantee is a minimum requirement; servers SHOULD limit 0-RTT replays further when feasible. @@ -4798,7 +4799,7 @@ provided, the server would then fall back to a full handshake. If the tickets are not self-contained but rather are database keys, and the corresponding PSKs are deleted upon use, then connections established -using PSKs enjoy not only anti-replay protection but also forward secrecy once +using PSKs enjoy not only anti-replay protection, but also forward secrecy once all copies of the PSK from the database entry have been deleted. This mechanism also improves security for PSK usage when PSK is used without (EC)DHE. @@ -4844,8 +4845,7 @@ of the ClientHello. If the ClientHello contains multiple PSK identities, then an attacker can create multiple ClientHellos with different binder values for the less-preferred identity on the assumption that the server will not verify it (as recommended -by {{pre-shared-key-extension}}). -That is, if the +by {{pre-shared-key-extension}}). I.e., if the client sends PSKs A and B but the server prefers A, then the attacker can change the binder for B without affecting the binder for A. If the binder for B is part of the storage key, @@ -4900,7 +4900,7 @@ which cannot be used for 0-RTT. To implement this mechanism, a server needs to store the time that the server generated the session ticket, offset by an estimate of -the round-trip time between client and server. That is, +the round-trip time between client and server. I.e., ~~~~ adjusted_creation_time = creation_time + estimated_RTT @@ -4918,7 +4918,7 @@ expected_arrival_time of the ClientHello as: ~~~~ When a new ClientHello is received, the expected_arrival_time is then -compared against the current server wall clock time, and if they differ +compared against the current server wall clock time and if they differ by more than a certain amount, 0-RTT is rejected, though the 1-RTT handshake can be allowed to complete. @@ -5104,8 +5104,8 @@ Those middleboxes continue to be non-compliant. # Security Considerations -Security issues are discussed throughout this memo, especially in Appendices -{{implementation-notes}}{: format="counter"}, {{backward-compatibility}}{: format="counter"}, and {{security-analysis}}{: format="counter"}. +Security issues are discussed throughout this memo, especially in +{{implementation-notes}}, {{backward-compatibility}}, and {{security-analysis}}. # IANA Considerations @@ -5115,7 +5115,7 @@ This document uses several registries that were originally created in between {{RFC8446}}, {{RFC8447}}, and this document are described in {{bis-changes}}. IANA has replaced references to these RFCs with references to this document. The registries and their allocation policies are below: -- "TLS Cipher Suites" registry: Values with the first byte in the range +- TLS Cipher Suites registry: Values with the first byte in the range 0-254 (decimal) are assigned via Specification Required {{RFC8126}}. Values with the first byte 255 (decimal) are reserved for Private Use {{RFC8126}}. @@ -5125,25 +5125,25 @@ IANA has replaced references to these RFCs with references to this document. The The "DTLS-OK" and "Recommended" columns are both marked as "Y" for each new cipher suite. -- "TLS ContentType" registry: Future values are allocated via +- TLS ContentType registry: Future values are allocated via Standards Action {{RFC8126}}. -- "TLS Alerts" registry: Future values are allocated via Standards +- TLS Alerts registry: Future values are allocated via Standards Action {{RFC8126}}. IANA has populated this registry with the values from {{alert-messages-appendix}}. The "DTLS-OK" column is marked as "Y" for all such values. Values marked as "_RESERVED" have comments describing their previous usage. -- "TLS HandshakeType" registry: Future values are allocated via +- TLS HandshakeType registry: Future values are allocated via Standards Action {{RFC8126}}. IANA has updated this registry to rename item 4 from "NewSessionTicket" to "new_session_ticket" and populated this registry with the values from {{handshake-protocol-appendix}}. The "DTLS-OK" column is marked as "Y" for all such values. - Values marked as "_RESERVED" have comments describing their previous or + Values marked "_RESERVED" have comments describing their previous or temporary usage. -This document also uses the "TLS ExtensionType Values" registry originally created in +This document also uses the TLS ExtensionType Values registry originally created in {{RFC4366}}. IANA has updated it to reference this document. Changes to the registry follow: @@ -5159,26 +5159,26 @@ registry follow: "certificate_authorities", "oid_filters", "post_handshake_auth", and "signature_algorithms_cert" extensions with the values defined in this document and the "Recommended" value of "Y". - IANA has updated this registry to include a "TLS - 1.3" column, which lists the messages in which the extension may + 1.3" column which lists the messages in which the extension may appear. This column has been initially populated from the table in {{extensions}}, with any extension not listed there marked as "-" to indicate that it is not used by TLS 1.3. -This document updates two entries in the "TLS Certificate Types" registry +This document updates two entries in the TLS Certificate Types registry originally created in {{RFC6091}} and updated in {{RFC8447}}. IANA has updated the entry for value 1 to have the name "OpenPGP_RESERVED", "Recommended" value "N", and comment "Used in TLS versions prior -to 1.3.". IANA has updated the entry for value 0 to have the name -"X509", "Recommended" value "Y", and comment "Was X.509 before TLS 1.3.". +to 1.3." IANA has updated the entry for value 0 to have the name +"X509", "Recommended" value "Y", and comment "Was X.509 before TLS 1.3". -This document updates an entry in the "TLS Certificate Status Types" +This document updates an entry in the TLS Certificate Status Types registry originally created in {{RFC6961}}. IANA has updated the entry for value 2 to have the name "ocsp_multi_RESERVED" and comment "Used -in TLS versions prior to 1.3.". +in TLS versions prior to 1.3". -This document updates two entries in the "TLS Supported Groups" +This document updates two entries in the TLS Supported Groups registry (created under a different name by {{RFC4492}}; now maintained by {{RFC8422}} and updated by {{RFC7919}} and {{RFC8447}}). The entries for values 29 and 30 (x25519 and x448) have been updated to also @@ -5201,7 +5201,7 @@ refer to this document. In addition, this document defines two new registries that are maintained by IANA: -- "TLS SignatureScheme" registry: Values with the first byte in the range +- TLS SignatureScheme registry: Values with the first byte in the range 0-253 (decimal) are assigned via Specification Required {{RFC8126}}. Values with the first byte 254 or 255 (decimal) are reserved for Private Use {{RFC8126}}. Values with the first byte in the range 0-6 or with the @@ -5219,7 +5219,7 @@ by IANA: requires Standards Action {{RFC8126}}. IESG Approval is REQUIRED for a Y->N transition. - - "TLS PskKeyExchangeMode" registry: Values in the + - TLS PskKeyExchangeMode registry: Values in the range 0-253 (decimal) are assigned via Specification Required {{RFC8126}}. The values 254 and 255 (decimal) are reserved for Private Use {{RFC8126}}. This registry has a @@ -5237,10 +5237,11 @@ IANA has updated all references to {{RFC8446}} in the IANA registries with references to this document. IANA has renamed the "extended_master_secret" value -in the "TLS ExtensionType Values" registry to "extended_main_secret". +in the TLS ExtensionType Values registry to "extended_main_secret". IANA has created a value for the "general_error" -alert in the "TLS Alerts" registry with the value given in {{alert-protocol}}. +alert in the TLS Alerts registry with the value given in {{alert-protocol}}. + --- back @@ -5706,7 +5707,7 @@ might receive them from older TLS implementations. Values within "obsolete_RESERVED" ranges are used in previous versions of TLS and MUST NOT be offered or negotiated by TLS 1.3 implementations. The obsolete curves have various known/theoretical weaknesses or have -had very little usage, in some cases, only due to unintentional +had very little usage, in some cases only due to unintentional server configuration issues. They are no longer considered appropriate for general use and should be assumed to be potentially unsafe. The set of curves specified here is sufficient for interoperability with all @@ -5826,7 +5827,7 @@ Cipher suite names follow the naming convention: | TLS | The string "TLS" | | AEAD | The AEAD algorithm used for record protection | | HASH | The hash algorithm used with HKDF and Transcript-Hash | -| VALUE | The two-byte ID assigned for this cipher suite | +| VALUE | The two byte ID assigned for this cipher suite | {: #cs-components title="Cipher Suite Name Structure"} This specification defines the following cipher suites for use with TLS 1.3. @@ -5864,7 +5865,7 @@ provides several recommendations to assist implementors. TLS requires a cryptographically secure pseudorandom number generator (CSPRNG). A performant and appropriately secure CSPRNG is provided by most operating -systems or can be sourced from a cryptographic library. +systems or can be sourced from a cryptographic library. It is RECOMMENDED to use an existing CSPRNG implementation in preference to crafting a new one. Many adequate cryptographic libraries are already available under favorable license terms. Should those prove @@ -5913,7 +5914,7 @@ higher-level semantics. Implementation experience has shown that certain parts of earlier TLS specifications are not easy to understand and have been a source of interoperability and security problems. Many of these areas have been clarified -in this document, but this appendix contains a short list of the most important +in this document but this appendix contains a short list of the most important things that require special attention from implementors. TLS protocol issues: @@ -5980,9 +5981,9 @@ Cryptographic details: injection attacks in easily accessible Internet of Things (IoT) devices. - Do you zero-pad Diffie-Hellman public key values and shared - secrets to the group size (see Sections {{ffdhe-param}}{: format="counter"} and {{finite-field-diffie-hellman}}{: format="counter"})? + secrets to the group size (see {{ffdhe-param}} and {{finite-field-diffie-hellman}})? -- Do you verify signatures after making them to protect against RSA-CRT +- Do you verify signatures after making them, to protect against RSA-CRT key leaks {{FW15}}? @@ -6018,7 +6019,7 @@ using the Encrypted Client Hello extension {{PRE-RFC9849}}. If an external PSK identity is used for multiple connections, then it will generally be possible for an external observer to track clients and/or servers across connections. Use of the -Encrypted Client Hello {{PRE-RFC9849}} extension can +Encrypted Client Hello extension {{PRE-RFC9849}} can mitigate this risk, as can mechanisms external to TLS that rotate or encrypt the PSK identity. @@ -6141,10 +6142,10 @@ to downgrade attacks and is NOT RECOMMENDED. A TLS server can also receive a ClientHello indicating a version number smaller than its highest supported version. If the "supported_versions" extension -is present, the server MUST negotiate using that extension, as described in +is present, the server MUST negotiate using that extension as described in {{supported-versions}}. If the "supported_versions" extension is not present, the server MUST negotiate the minimum of ClientHello.legacy_version -and TLS 1.2. For example, if the server supports TLS 1.0, 1.1, and 1.2 +and TLS 1.2. For example, if the server supports TLS 1.0, 1.1, and 1.2, and legacy_version is TLS 1.0, the server will proceed with a TLS 1.0 ServerHello. If the "supported_versions" extension is absent and the server only supports versions greater than ClientHello.legacy_version, the server MUST abort the handshake @@ -6199,11 +6200,11 @@ by making the TLS 1.3 handshake look more like a TLS 1.2 handshake: When put together, these changes make the TLS 1.3 handshake resemble TLS 1.2 session resumption, which improves the chance of successfully connecting through middleboxes. This "compatibility mode" is partially -negotiated: The client can opt to provide a session ID or not +negotiated: the client can opt to provide a session ID or not, and the server has to echo it. Either side can send change_cipher_spec at any time during the handshake, as they must be ignored by the peer, but if the client sends a non-empty session ID, the server MUST send -the change_cipher_spec, as described in this appendix. +the change_cipher_spec as described in this appendix. ## Security Restrictions Related to Backward Compatibility {#backward-compatibility-security} @@ -6216,13 +6217,13 @@ The security of RC4 cipher suites is considered insufficient for the reasons cited in {{RFC7465}}. Implementations MUST NOT offer or negotiate RC4 cipher suites for any version of TLS for any reason. -Old versions of TLS permitted the use of very low-strength ciphers. +Old versions of TLS permitted the use of very low strength ciphers. Ciphers with a strength less than 112 bits MUST NOT be offered or negotiated for any version of TLS for any reason. The security of SSL 2.0 {{SSL2}}, SSL 3.0 {{?RFC6101}}, TLS 1.0 {{?RFC2246}}, and TLS 1.1 {{RFC4346}} are considered insufficient for -the reasons enumerated in {{RFC6176}}, {{RFC7568}}, and {{RFC8996}}, +the reasons enumerated in {{RFC6176}}, {{RFC7568}}, and {{RFC8996}} and they MUST NOT be negotiated for any reason. Implementations MUST NOT send an SSL version 2.0 compatible CLIENT-HELLO. @@ -6265,14 +6266,14 @@ of the handshake, each side outputs its view of the following values: from which a set of working keys can be derived. Note that when early data is in use, secrets are also derived from the early secret. These enjoy somewhat weaker properties than those derived from the main secret, - as detailed below. + as detailed below. - A set of cryptographic parameters (algorithms, etc.). - The identities of the communicating parties. We assume the attacker to be an active network attacker, which means it has complete control over the network used to communicate between the parties {{RFC3552}}. Even under these conditions, the handshake should provide the properties listed below. -Note that these properties are not necessarily independent but reflect +Note that these properties are not necessarily independent, but reflect the protocol consumers' needs. Establishing the same session keys: @@ -6282,7 +6283,7 @@ the handshake, provided that it completes successfully on each endpoint Secrecy of the session keys: : The shared session keys should be known only to the communicating - parties and not to the attacker (see {{?CK01=DOI.10.1007/3-540-44987-6_28}}, Definition 1, part 2). + parties and not to the attacker (see {{?CK01=DOI.10.1007/3-540-44987-6_28}}; Definition 1, part 2). Note that in a unilaterally authenticated connection, the attacker can establish its own session keys with the server, but those session keys are distinct from those established by the client. @@ -6303,7 +6304,7 @@ Downgrade Protection: absence of an attack (see {{?BBFGKZ16=DOI.10.1109/SP.2016.37}}; Definitions 8 and 9). Forward secret with respect to long-term keys: -: If the long-term keying material (in this case, the signature keys in +: If the long-term keying material (in this case the signature keys in certificate-based authentication modes or the external/resumption PSK in PSK with (EC)DHE modes) is compromised after the handshake is complete, this does not compromise the security of the session key @@ -6477,7 +6478,7 @@ connection to be unilaterally or mutually authenticated, this has to be provisioned by the application layer. See {{CHHSV17}} for details. In addition, the analysis of post-handshake authentication from {{Kraw16}} shows that the client identified by the certificate sent in -the post-handshake phase possesses the traffic key. Therefore, this party is +the post-handshake phase possesses the traffic key. This party is therefore the client that participated in the original handshake or one to whom the original client delegated the traffic key (assuming that the traffic key has not been compromised). @@ -6509,9 +6510,9 @@ needed again. ### Post-Compromise Security TLS does not provide security for handshakes which take place after the peer's -long-term secret (signature key or external PSK) is compromised. Therefore, it +long-term secret (signature key or external PSK) is compromised. It therefore does not provide post-compromise security {{?CCG16=DOI.10.1109/CSF.2016.19}}, sometimes also referred to -as backward or future secrecy. This is in contrast to KCI resistance, which +as backwards or future secrecy. This is in contrast to KCI resistance, which describes the security guarantees that a party has after its own long-term secret has been compromised. @@ -6545,7 +6546,7 @@ Confidentiality: {::comment}Cite IND-CPA?{:/comment} Integrity: -: An attacker should not be able to craft a new record that is +: An attacker should not be able to craft a new record which is different from an existing record which will be accepted by the receiver. {::comment}Cite INT-CTXT?{:/comment} @@ -6588,7 +6589,7 @@ one way, it is not possible to compute traffic keys from prior to a key change TLS does not provide security for data which is communicated on a connection after a traffic secret of that connection is compromised. That is, TLS does not -provide post-compromise security / future secrecy / backward secrecy with respect +provide post-compromise security/future secrecy/backward secrecy with respect to the traffic secret. Indeed, an attacker who learns a traffic secret can compute all future traffic secrets on that connection. Systems which want such guarantees need to do a fresh handshake and establish a new connection with an @@ -6619,7 +6620,7 @@ arbitrary-length encrypted records as well as padding-only cover traffic to conceal the difference between periods of transmission and periods of silence. Because the padding is encrypted alongside the actual content, an attacker cannot -directly determine the length of the padding but may be able to +directly determine the length of the padding, but may be able to measure it indirectly by the use of timing channels exposed during record processing (i.e., seeing how long it takes to process a record or trickling in records to see which ones elicit a response @@ -6668,7 +6669,7 @@ information is not inadvertently leaked. Replayable 0-RTT data presents a number of security threats to TLS-using applications, unless those applications are specifically engineered to be safe under replay -(minimally, this means idempotent but in many cases may +(minimally, this means idempotent, but in many cases may also require other stronger conditions, such as constant-time response). Potential attacks include: @@ -6683,7 +6684,7 @@ a delete to after a create). - Amplifying existing information leaks caused by side effects like caching. An attacker could learn information about the content of a 0-RTT message by replaying it to some cache node that has not cached -some resource of interest and then using a separate connection to check +some resource of interest, and then using a separate connection to check whether that resource has been added to the cache. This could be repeated with different cache nodes as often as the 0-RTT message is replayable. @@ -6701,7 +6702,7 @@ against receiving multiple copies of client data. TLS 1.3 falls back to the 1-RTT handshake when the server does not have any information about the client, e.g., because it is in a different cluster which does not -share state or because the ticket has been deleted, as described in +share state or because the ticket has been deleted as described in {{single-use-tickets}}. If the application-layer protocol retransmits data in this setting, then it is possible for an attacker to induce message duplication by sending the ClientHello to both the original cluster @@ -6712,11 +6713,11 @@ willingness to retry transactions and therefore only allows a limited amount of duplication, with each copy appearing as a new connection at the server. -If implemented correctly, the mechanisms described in Sections -{{single-use-tickets}}{: format="counter"} and {{client-hello-recording}}{: format="counter"} prevent a +If implemented correctly, the mechanisms described in +{{single-use-tickets}} and {{client-hello-recording}} prevent a replayed ClientHello and its associated 0-RTT data from being accepted multiple times by any cluster with consistent state; for servers -which limit the use of 0-RTT to one cluster for a single ticket, a given +which limit the use of 0-RTT to one cluster for a single ticket, then a given ClientHello and its associated 0-RTT data will only be accepted once. However, if state is not completely consistent, then an attacker might be able to have multiple copies of the data be @@ -6794,7 +6795,7 @@ compromised group member can impersonate any other member, a malicious non-member can reroute handshakes between honest group members to connect them in unintended ways {{Selfie}}. {{RFC9257}} provides recommendations for external PSK usage, including the use of external -PSK importers as defined in {{RFC9258}}, that prevents such malicious +PSK importers as defined in {{RFC9258}}, that prevent such malicious rerouting of messages. ## Misbinding When Using Self-Signed Certificates or Raw Public Keys @@ -6807,11 +6808,10 @@ the "external_id_hash" extension {{RFC8844}} or, if only the server is being authenticated, by the server verifying that the "server_name" extension matches its expected identity. - ## Attacks on Static RSA Although TLS 1.3 does not use RSA key transport and so is not -directly susceptible to Bleichenbacher-type attacks {{Blei98}}, if TLS 1.3 +directly susceptible to Bleichenbacher-type attacks {{Blei98}} if TLS 1.3 servers also support static RSA in the context of previous versions of TLS, then it may be possible to impersonate the server for TLS 1.3 connections {{?JSS15=DOI.10.1145/2810103.2813657}}. TLS @@ -7229,7 +7229,6 @@ per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each expansion in the document carefully to ensure correctness. Elliptic Curve Cryptography (ECC) - Finite Field DHE (FFDHE) Internet of Things (IoT) -->