From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc8879.txt | 359 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 359 insertions(+) create mode 100644 doc/rfc/rfc8879.txt (limited to 'doc/rfc/rfc8879.txt') diff --git a/doc/rfc/rfc8879.txt b/doc/rfc/rfc8879.txt new file mode 100644 index 0000000..2669798 --- /dev/null +++ b/doc/rfc/rfc8879.txt @@ -0,0 +1,359 @@ + + + + +Internet Engineering Task Force (IETF) A. Ghedini +Request for Comments: 8879 Cloudflare, Inc. +Category: Standards Track V. Vasiliev +ISSN: 2070-1721 Google + December 2020 + + + TLS Certificate Compression + +Abstract + + In TLS handshakes, certificate chains often take up the majority of + the bytes transmitted. + + This document describes how certificate chains can be compressed to + reduce the amount of data transmitted and avoid some round trips. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc8879. + +Copyright Notice + + Copyright (c) 2020 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 Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction + 2. Notational Conventions + 3. Negotiating Certificate Compression + 4. Compressed Certificate Message + 5. Security Considerations + 6. Middlebox Compatibility + 7. IANA Considerations + 7.1. TLS ExtensionType Values + 7.2. TLS HandshakeType + 7.3. Compression Algorithms + 8. References + 8.1. Normative References + 8.2. Informative References + Acknowledgements + Authors' Addresses + +1. Introduction + + In order to reduce latency and improve performance, it can be useful + to reduce the amount of data exchanged during a TLS handshake. + + [RFC7924] describes a mechanism that allows a client and a server to + avoid transmitting certificates already shared in an earlier + handshake, but it doesn't help when the client connects to a server + for the first time and doesn't already have knowledge of the server's + certificate chain. + + This document describes a mechanism that would allow certificates to + be compressed during all handshakes. + +2. Notational Conventions + + 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. Negotiating Certificate Compression + + This extension is only supported with TLS 1.3 [RFC8446] and newer; if + TLS 1.2 [RFC5246] or earlier is negotiated, the peers MUST ignore + this extension. + + This document defines a new extension type + (compress_certificate(27)), which can be used to signal the supported + compression formats for the Certificate message to the peer. + Whenever it is sent by the client as a ClientHello message extension + ([RFC8446], Section 4.1.2), it indicates support for compressed + server certificates. Whenever it is sent by the server as a + CertificateRequest extension ([RFC8446], Section 4.3.2), it indicates + support for compressed client certificates. + + By sending a compress_certificate extension, the sender indicates to + the peer the certificate-compression algorithms it is willing to use + for decompression. The "extension_data" field of this extension + SHALL contain a CertificateCompressionAlgorithms value: + + enum { + zlib(1), + brotli(2), + zstd(3), + (65535) + } CertificateCompressionAlgorithm; + + struct { + CertificateCompressionAlgorithm algorithms<2..2^8-2>; + } CertificateCompressionAlgorithms; + + The compress_certificate extension is a unidirectional indication; no + corresponding response extension is needed. + +4. Compressed Certificate Message + + If the peer has indicated that it supports compression, server and + client MAY compress their corresponding Certificate messages + (Section 4.4.2 of [RFC8446]) and send them in the form of the + CompressedCertificate message (replacing the Certificate message). + + The CompressedCertificate message is formed as follows: + + struct { + CertificateCompressionAlgorithm algorithm; + uint24 uncompressed_length; + opaque compressed_certificate_message<1..2^24-1>; + } CompressedCertificate; + + algorithm: The algorithm used to compress the certificate. The + algorithm MUST be one of the algorithms listed in the peer's + compress_certificate extension. + + uncompressed_length: The length of the Certificate message once it + is uncompressed. If, after decompression, the specified length + does not match the actual length, the party receiving the invalid + message MUST abort the connection with the "bad_certificate" + alert. The presence of this field allows the receiver to + preallocate the buffer for the uncompressed Certificate message + and enforce limits on the message size before performing + decompression. + + compressed_certificate_message: The result of applying the indicated + compression algorithm to the encoded Certificate message that + would have been sent if certificate compression was not in use. + The compression algorithm defines how the bytes in the + compressed_certificate_message field are converted into the + Certificate message. + + If the specified compression algorithm is zlib, then the Certificate + message MUST be compressed with the ZLIB compression algorithm, as + defined in [RFC1950]. If the specified compression algorithm is + brotli, the Certificate message MUST be compressed with the Brotli + compression algorithm, as defined in [RFC7932]. If the specified + compression algorithm is zstd, the Certificate message MUST be + compressed with the Zstandard compression algorithm, as defined in + [RFC8478]. + + It is possible to define a certificate compression algorithm that + uses a preshared dictionary to achieve a higher compression ratio. + This document does not define any such algorithms, but additional + codepoints may be allocated for such use per the policy in + Section 7.3. + + If the received CompressedCertificate message cannot be decompressed, + the connection MUST be terminated with the "bad_certificate" alert. + + If the format of the Certificate message is altered using the + server_certificate_type or client_certificate_type extensions + [RFC7250], the resulting altered message is compressed instead. + +5. Security Considerations + + After decompression, the Certificate message MUST be processed as if + it were encoded without being compressed. This way, the parsing and + the verification have the same security properties as they would have + in TLS normally. + + In order for certificate compression to function correctly, the + underlying compression algorithm MUST output the same data that was + provided as input by the peer. + + Since certificate chains are typically presented on a per-server-name + or per-user basis, a malicious application does not have control over + any individual fragments in the Certificate message, meaning that + they cannot leak information about the certificate by modifying the + plaintext. + + Implementations SHOULD bound the memory usage when decompressing the + CompressedCertificate message. + + Implementations MUST limit the size of the resulting decompressed + chain to the specified uncompressed length, and they MUST abort the + connection if the size of the output of the decompression function + exceeds that limit. TLS framing imposes a 16777216-byte limit on the + certificate message size, and implementations MAY impose a limit that + is lower than that; in both cases, they MUST apply the same limit as + if no compression were used. + + While the Certificate message in TLS 1.3 is encrypted, third parties + can draw inferences from the message length observed on the wire. + TLS 1.3 provides a padding mechanism (discussed in Sections 5.4 and + E.3 of [RFC8446]) to counteract such analysis. Certificate + compression alters the length of the Certificate message, and the + change in length is dependent on the actual contents of the + certificate. Any padding scheme covering the Certificate message has + to address compression within its design or disable it altogether. + +6. Middlebox Compatibility + + It's been observed that a significant number of middleboxes intercept + and try to validate the Certificate message exchanged during a TLS + handshake. This means that middleboxes that don't understand the + CompressedCertificate message might misbehave and drop connections + that adopt certificate compression. Because of that, the extension + is only supported in the versions of TLS where the certificate + message is encrypted in a way that prevents middleboxes from + intercepting it -- that is, TLS version 1.3 [RFC8446] and higher. + +7. IANA Considerations + +7.1. TLS ExtensionType Values + + IANA has created an entry, compress_certificate(27), in the "TLS + ExtensionType Values" registry (defined in [RFC8446]) with the values + in the "TLS 1.3" column set to "CH, CR" and the "Recommended" column + entry set to "Yes". + +7.2. TLS HandshakeType + + IANA has created an entry, compressed_certificate(25), in the "TLS + Handshake Type" registry (defined in [RFC8446]), with the "DTLS-OK" + column value set to "Yes". + +7.3. Compression Algorithms + + This document establishes a registry of compression algorithms + supported for compressing the Certificate message, titled "TLS + Certificate Compression Algorithm IDs", under the existing "Transport + Layer Security (TLS) Extensions" registry. + + The entries in the registry are: + + +==================+===============================+===========+ + | Algorithm Number | Description | Reference | + +==================+===============================+===========+ + | 0 | Reserved | RFC 8879 | + +------------------+-------------------------------+-----------+ + | 1 | zlib | RFC 8879 | + +------------------+-------------------------------+-----------+ + | 2 | brotli | RFC 8879 | + +------------------+-------------------------------+-----------+ + | 3 | zstd | RFC 8879 | + +------------------+-------------------------------+-----------+ + | 16384 to 65535 | Reserved for Experimental Use | | + +------------------+-------------------------------+-----------+ + + Table 1: TLS Certificate Compression Algorithm IDs + + The values in this registry shall be allocated under "IETF Review" + policy for values strictly smaller than 256, under "Specification + Required" policy for values 256-16383, and under "Experimental Use" + otherwise (see [RFC8126] for the definition of relevant policies). + Experimental Use extensions can be used both on private networks and + over the open Internet. + + The procedures for requesting values in the Specification Required + space are specified in Section 17 of [RFC8447]. + +8. References + +8.1. Normative References + + [RFC1950] Deutsch, P. and J-L. Gailly, "ZLIB Compressed Data Format + Specification version 3.3", RFC 1950, + DOI 10.17487/RFC1950, May 1996, + . + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . + + [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., + Weiler, S., and T. Kivinen, "Using Raw Public Keys in + Transport Layer Security (TLS) and Datagram Transport + Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, + June 2014, . + + [RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security + (TLS) Cached Information Extension", RFC 7924, + DOI 10.17487/RFC7924, July 2016, + . + + [RFC7932] Alakuijala, J. and Z. Szabadka, "Brotli Compressed Data + Format", RFC 7932, DOI 10.17487/RFC7932, July 2016, + . + + [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for + Writing an IANA Considerations Section in RFCs", BCP 26, + RFC 8126, DOI 10.17487/RFC8126, June 2017, + . + + [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, + . + + [RFC8478] Collet, Y. and M. Kucherawy, Ed., "Zstandard Compression + and the application/zstd Media Type", RFC 8478, + DOI 10.17487/RFC8478, October 2018, + . + +8.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, + . + +Acknowledgements + + Certificate compression was originally introduced in the QUIC Crypto + protocol, designed by Adam Langley and Wan-Teh Chang. + + This document has benefited from contributions and suggestions from + David Benjamin, Ryan Hamilton, Christian Huitema, Benjamin Kaduk, + Ilari Liusvaara, Piotr Sikora, Ian Swett, Martin Thomson, Sean + Turner, and many others. + +Authors' Addresses + + Alessandro Ghedini + Cloudflare, Inc. + + Email: alessandro@cloudflare.com + + + Victor Vasiliev + Google + + Email: vasilvv@google.com -- cgit v1.2.3