diff --git a/index.html b/index.html index 4812b7b..fd910e0 100644 --- a/index.html +++ b/index.html @@ -24,6 +24,14 @@

Editor's drafts for main branch of initial-changes

+ + + + + + +
Super Jumbo TLS Recordsplain textdiff with main
+ + diff --git a/initial-changes/draft-mattsson-tls-super-jumbo-record-limit.txt b/initial-changes/draft-mattsson-tls-super-jumbo-record-limit.txt new file mode 100644 index 0000000..60e2e3b --- /dev/null +++ b/initial-changes/draft-mattsson-tls-super-jumbo-record-limit.txt @@ -0,0 +1,272 @@ + + + + +Transport Layer Security J. Preuß Mattsson +Internet-Draft Ericsson +Intended status: Standards Track H. Tschofenig +Expires: 28 August 2024 Siemens + M. Tüxen + Münster Univ. of Applied Sciences + 25 February 2024 + + + Super Jumbo Record Size Limit Extension for TLS 1.3 + draft-mattsson-tls-super-jumbo-record-limit-latest + +Abstract + + RFC 8449 defines a Record Size Limit Extension for TLS allowing + endpoints to negotiate a record size limit smaller than the protocol- + defined maximum record size, which is around 2^14 bytes. This + document specifies a TLS flags extension to be used in combination + with the Record Size Limit Extension allowing endpoints to use a + record size limit larger than the protocol-defined maximum record + size, but not more than about 2^16 bytes. + +About This Document + + This note is to be removed before publishing as an RFC. + + The latest revision of this draft can be found at + https://emanjon.github.io/tls-super-jumbo-record-limit/draft- + mattsson-tls-super-jumbo-record-limit.html. Status information for + this document may be found at https://datatracker.ietf.org/doc/draft- + mattsson-tls-super-jumbo-record-limit/. + + Discussion of this document takes place on the Transport Layer + Security Working Group mailing list (mailto:tls@ietf.org), which is + archived at https://mailarchive.ietf.org/arch/browse/tls/. Subscribe + at https://www.ietf.org/mailman/listinfo/tls/. + + Source for this draft and an issue tracker can be found at + https://github.com/emanjon/tls-super-jumbo-record-limit. + +Status of This Memo + + This Internet-Draft is submitted in full conformance with the + provisions of BCP 78 and BCP 79. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF). Note that other groups may also distribute + working documents as Internet-Drafts. The list of current Internet- + Drafts is at https://datatracker.ietf.org/drafts/current/. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + This Internet-Draft will expire on 28 August 2024. + +Copyright Notice + + Copyright (c) 2024 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents (https://trustee.ietf.org/ + license-info) in effect on the date of publication of this document. + Please review these documents carefully, as they describe your rights + and restrictions with respect to this document. Code Components + extracted from this document must include Revised BSD License text as + described in Section 4.e of the Trust Legal Provisions and are + provided without warranty as described in the Revised BSD License. + +Table of Contents + + 1. Introduction + 2. Terminology + 3. The "super_jumbo_record_size_limit" Flags Extension + 4. AEAD Limits + 5. Security Considerations + 6. IANA Considerations + 7. References + 7.1. Normative References + 7.2. Informative References + Acknowledgments + Authors' Addresses + +1. Introduction + + The records in all version of TLS records has an uint16 length field + that could theoretically allow records 65535 octets in size. TLS + does however have a lower protocol-defined limit for maximum + plaintext record size. For TLS 1.2 [RFC5246], that limit is 2^14 = + 16384 octets. TLS 1.3 [RFC8446] uses a limit of 2^14 + 1 = 16385 + octets. In addition, TLS 1.2 allow expansion from compression and + protection up to 2048 octets (though typically this expansion is only + 16 octets). TLS 1.3 reduces the allowance for expansion to 256 + octets. + + The "record_size_limit" extension [RFC8449] enables endpoints to + negotiate a lower limit for the maximum plaintext record size, but + does not allow endpoints to increase the limits enforced by TLS 1.3 + [RFC8446], TLS 1.2 [RFC5246], DTLS 1.3 [RFC9147], and DTLS 1.2 + [RFC6347]. + + In some use cases such as DTLS over SCTP [RFC6083] the 2^14 bytes + limit is a severe limitation. + + This document defines a "super_jumbo_record_size_limit" flags + extension (Section 3). The Record Size Limit Extension for TLS as + specified in [RFC8449] used in combination with the flags extension + defined in this document allows endpoints to negotiate a record size + limit larger than the protocol-defined maximum record size. This can + be used to bump up the maximum size of protected records to 2^16-1 + bytes, which is larger than the default limit of 2^14 bytes. This + extension is defined for version 1.3 of TLS and DTLS. + +2. 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. + +3. The "super_jumbo_record_size_limit" Flags Extension + + The "super_jumbo_record_size_limit" extension does not have any + ExtensionData. When the "super_jumbo_record_size_limit" extension is + negotiated, an endpoint MUST be prepared to accept protected records + with ciphertexts of length 2^16 bytes and protected record with + plaintext of length 2^16 - the allowed expansion. The maximum length + of a protected record plaintext is therefore 2^16 - 2^11 = 63488 + octets in TLS 1.2 and 2^16 - 2^8 = 65280 octets in TLS 1.3. + Unprotected messages are still subject to the lower default limits in + TLS/DTLS 1.3. + + The "super_jumbo_record_size_limit" extension MUST NOT be negotiated + together with the "record_size_limit" extension or the + "max_fragment_length" extension. A client MUST treat receipt of + "super_jumbo_record_size_limit" together with "record_size_limit" or + "max_fragment_length" as a fatal error, and it SHOULD generate an + "illegal_parameter" alert. + + In TLS 1.3, the server sends the "super_jumbo_record_size_limit" + extension in the EncryptedExtensions message. + + During renegotiation or resumption, the record size limit is + renegotiated. Records are subject to the limits that were set in the + handshake that produces the keys that are used to protect those + records. This admits the possibility that the extension might not be + negotiated when a connection is renegotiated or resumed. + + For DTLS 1.3 [RFC9147] over UDP or DCCP, the Path Maximum + Transmission Unit (PMTU) also limits the size of records. The record + size limit does not affect PMTU discovery and SHOULD be set + independently. The record size limit is fixed during the handshake + and so should be set based on constraints at the endpoint and not + based on the current network environment. In comparison, the PMTU is + determined by the network path and can change dynamically over time. + See PMTU [RFC8201] and Section 4.1 of DTLS 1.3 [RFC9147] for more + detail on PMTU discovery. For DTLS over TCP or SCTP, which + automatically fragments and reassembles datagrams, there is no PMTU + limitation. + +4. AEAD Limits + + The maximum record size limit is an input to the AEAD limits + calculations in TLS 1.3 [RFC8446] and DTLS 1.3 [RFC9147]. Increasing + the maximum record size to 2^16 bytes while keeping the same + confidentiality and integrity advantage therefore requires lower AEAD + limits. When the "super_jumbo_record_size_limit" has been + negotiated, existing AEAD limits shall be decreased by a factor of 4. + For example, when AES-CGM is used in TLS 1.3 [RFC8446] with a 64 kB + record limit, only 2^22.5 records (about 6 million) may be encrypted + on a given connection. + +5. Security Considerations + + Large record sizes might require more memory allocation for senders + and receivers. Large record sizes also means that more processing is + done before verification of non-authentic records fails. + +6. IANA Considerations + + This document registers the "super_jumbo_record_size_limit" extension + in the "TLS ExtensionType Values" registry established in [RFC5246]. + The "super_jumbo_record_size_limit" extension has been assigned a + code point of TBD. The IANA registry [RFC8447] [[will list|lists]] + this extension as "Recommended" (i.e., "Y") and indicates that it may + appear in the ClientHello (CH) or EncryptedExtensions (EE) messages + in TLS 1.3 [RFC8446]. + +7. References + +7.1. Normative References + + [I-D.ietf-tls-tlsflags] + Nir, Y., "A Flags Extension for TLS 1.3", Work in + Progress, Internet-Draft, draft-ietf-tls-tlsflags-12, 23 + July 2023, . + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, . + + [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol + Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, + . + + [RFC8447] Salowey, J. and S. Turner, "IANA Registry Updates for TLS + and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018, + . + + [RFC8449] Thomson, M., "Record Size Limit Extension for TLS", + RFC 8449, DOI 10.17487/RFC8449, August 2018, + . + +7.2. Informative References + + [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security + (TLS) Protocol Version 1.2", RFC 5246, + DOI 10.17487/RFC5246, August 2008, + . + + [RFC6083] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram + Transport Layer Security (DTLS) for Stream Control + Transmission Protocol (SCTP)", RFC 6083, + DOI 10.17487/RFC6083, January 2011, + . + + [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer + Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, + January 2012, . + + [RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., + "Path MTU Discovery for IP version 6", STD 87, RFC 8201, + DOI 10.17487/RFC8201, July 2017, + . + + [RFC9147] Rescorla, E., Tschofenig, H., and N. Modadugu, "The + Datagram Transport Layer Security (DTLS) Protocol Version + 1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022, + . + +Acknowledgments + + Add your name here. + +Authors' Addresses + + John Preuß Mattsson + Ericsson + Email: john.mattsson@ericsson.com + + + Hannes Tschofenig + Siemens + Email: hannes.tschofenig@gmx.net + + + Michael Tüxen + Münster Univ. of Applied Sciences + Email: tuexen@fh-muenster.de diff --git a/initial-changes/index.html b/initial-changes/index.html new file mode 100644 index 0000000..e2b07df --- /dev/null +++ b/initial-changes/index.html @@ -0,0 +1,45 @@ + + + + emanjon/tls-super-jumbo-record-limit initial-changes preview + + + + +

Editor's drafts for initial-changes branch of emanjon/tls-super-jumbo-record-limit

+ + + + + + +
Super Jumbo TLS Recordsplain textsame as main
+ + +