idnits 2.17.1 draft-ietf-tls-certificate-compression-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (January 26, 2018) is 2276 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC4366' is defined on line 254, but no explicit reference was found in the text == Outdated reference: A later version (-28) exists of draft-ietf-tls-tls13-23 ** Downref: Normative reference to an Informational RFC: RFC 1950 ** Obsolete normative reference: RFC 4366 (Obsoleted by RFC 5246, RFC 6066) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Downref: Normative reference to an Informational RFC: RFC 7932 Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TLS A. Ghedini 3 Internet-Draft Cloudflare, Inc. 4 Intended status: Standards Track V. Vasiliev 5 Expires: July 30, 2018 Google 6 January 26, 2018 8 Transport Layer Security (TLS) Certificate Compression 9 draft-ietf-tls-certificate-compression-02 11 Abstract 13 In Transport Layer Security (TLS) handshakes, certificate chains 14 often take up the majority of the bytes transmitted. 16 This document describes how certificate chains can be compressed to 17 reduce the amount of data transmitted and avoid some round trips. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on July 30, 2018. 36 Copyright Notice 38 Copyright (c) 2018 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 2 55 3. Negotiating Certificate Compression . . . . . . . . . . . . . 2 56 4. Compressed Certificate Message . . . . . . . . . . . . . . . 3 57 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 58 6. Middlebox Compatibility . . . . . . . . . . . . . . . . . . . 5 59 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 60 7.1. Update of the TLS ExtensionType Registry . . . . . . . . 5 61 7.2. Update of the TLS HandshakeType Registry . . . . . . . . 5 62 7.3. Registry for Compression Algorithms . . . . . . . . . . . 5 63 8. Normative References . . . . . . . . . . . . . . . . . . . . 6 64 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 7 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 67 1. Introduction 69 In order to reduce latency and improve performance it can be useful 70 to reduce the amount of data exchanged during a Transport Layer 71 Security (TLS) handshake. 73 [RFC7924] describes a mechanism that allows a client and a server to 74 avoid transmitting certificates already shared in an earlier 75 handshake, but it doesn't help when the client connects to a server 76 for the first time and doesn't already have knowledge of the server's 77 certificate chain. 79 This document describes a mechanism that would allow certificates to 80 be compressed during full handshakes. 82 2. Notational Conventions 84 The words "MUST", "MUST NOT", "SHALL", "SHOULD", and "MAY" are used 85 in this document. It's not shouting; when they are capitalized, they 86 have the special meaning defined in [RFC2119]. 88 3. Negotiating Certificate Compression 90 This extension is only supported with TLS 1.3 and newer; if TLS 1.2 91 or earlier is negotiated, the peers MUST ignore this extension. 93 This document defines a new extension type 94 (compress_certificate(TBD)), which can be used to signal the 95 supported compression formats for the Certificate message to the 96 peer. Whenever it is sent by the client as a ClientHello message 97 extension ([I-D.ietf-tls-tls13], Section 4.1.2), it indicates the 98 support for compressed server certificates. Whenever it is sent by 99 the server as a CertificateRequest extension ([I-D.ietf-tls-tls13], 100 Section 4.3.2), it indicates the support for compressed client 101 certificates. 103 By sending a compress_certificate extension, the sender indicates to 104 the peer the certificate compression algorithms it is willing to use 105 for decompression. The "extension_data" field of this extension 106 SHALL contain a CertificateCompressionAlgorithms value: 108 enum { 109 zlib(0), 110 brotli(1), 111 (255) 112 } CertificateCompressionAlgorithm; 114 struct { 115 CertificateCompressionAlgorithm algorithms<1..2^8-1>; 116 } CertificateCompressionAlgorithms; 118 There is no ServerHello extension that the server is required to echo 119 back. 121 4. Compressed Certificate Message 123 If the peer has indicated that it supports compression, server and 124 client MAY compress their corresponding Certificate messages and send 125 them in the form of the CompressedCertificate message (replacing the 126 Certificate message). 128 The CompressedCertificate message is formed as follows: 130 struct { 131 CertificateCompressionAlgorithm algorithm; 132 uint24 uncompressed_length; 133 opaque compressed_certificate_message<1..2^24-1>; 134 } CompressedCertificate; 136 algorithm The algorithm used to compress the certificate. The 137 algorithm MUST be one of the algorithms listed in the peer's 138 compress_certificate extension. 140 uncompressed_length The length of the Certificate message once it is 141 uncompressed. If after decompression the specified length does 142 not match the actual length, the party receiving the invalid 143 message MUST abort the connection with the "bad_certificate" 144 alert. 146 compressed_certificate_message The compressed body of the 147 Certificate message, in the same format as it would normally be 148 expressed in. The compression algorithm defines how the bytes in 149 the compressed_certificate_message field are converted into the 150 Certificate message. 152 If the specified compression algorithm is zlib, then the Certificate 153 message MUST be compressed with the ZLIB compression algorithm, as 154 defined in [RFC1950]. If the specified compression algorithm is 155 brotli, the Certificate message MUST be compressed with the Brotli 156 compression algorithm as defined in [RFC7932]. 158 If the received CompressedCertificate message cannot be decompressed, 159 the connection MUST be torn down with the "bad_certificate" alert. 161 If the format of the Certificate message is altered using the 162 server_certificate_type extension [RFC7250], the resulting altered 163 message is compressed instead. 165 5. Security Considerations 167 After decompression, the Certificate message MUST be processed as if 168 it were encoded without being compressed. This way, the parsing and 169 the verification have the same security properties as they would have 170 in TLS normally. 172 Since certificate chains are typically presented on a per-server name 173 or per-user basis, the attacker does not have control over any 174 individual fragments in the Certificate message, meaning that they 175 cannot leak information about the certificate by modifying the 176 plaintext. 178 The implementations SHOULD bound the memory usage when decompressing 179 the CompressedCertificate message. 181 The implementations MUST limit the size of the resulting decompressed 182 chain to the specified uncompressed length, and they MUST abort the 183 connection if the size exceeds that limit. TLS framing imposes 184 16777216 byte limit on the certificate message size, and the 185 implementations MAY impose a limit that is lower than that; in both 186 cases, they MUST apply the same limit as if no compression were used. 188 6. Middlebox Compatibility 190 It's been observed that a significant number of middleboxes intercept 191 and try to validate the Certificate message exchanged during a TLS 192 handshake. This means that middleboxes that don't understand the 193 CompressedCertificate message might misbehave and drop connections 194 that adopt certificate compression. Because of that, the extension 195 is only supported in the versions of TLS where the certificate 196 message is encrypted in a way that prevents middleboxes from 197 intercepting it, that is, TLS version 1.3 [I-D.ietf-tls-tls13] and 198 higher. 200 7. IANA Considerations 202 7.1. Update of the TLS ExtensionType Registry 204 Create an entry, compress_certificate(TBD), in the existing registry 205 for ExtensionType (defined in [I-D.ietf-tls-tls13]), with "TLS 1.3" 206 column values being set to "CH, CR". 208 7.2. Update of the TLS HandshakeType Registry 210 Create an entry, compressed_certificate(TBD), in the existing 211 registry for HandshakeType (defined in [RFC5246]). 213 7.3. Registry for Compression Algorithms 215 This document establishes a registry of compression algorithms 216 supported for compressing the Certificate message, titled 217 "Certificate Compression Algorithm IDs", under the existing 218 "Transport Layer Security (TLS) Extensions" heading. 220 The entries in the registry are: 222 +------------------+--------------------------+ 223 | Algorithm Number | Description | 224 +------------------+--------------------------+ 225 | 0 | zlib | 226 | | | 227 | 1 | brotli | 228 | | | 229 | 224 to 255 | Reserved for Private Use | 230 +------------------+--------------------------+ 232 The values in this registry shall be allocated under "IETF Review" 233 policy for values strictly smaller than 64, and under "Specification 234 Required" policy otherwise (see [RFC8126] for the definition of 235 relevant policies). 237 8. Normative References 239 [I-D.ietf-tls-tls13] 240 Rescorla, E., "The Transport Layer Security (TLS) Protocol 241 Version 1.3", draft-ietf-tls-tls13-23 (work in progress), 242 January 2018. 244 [RFC1950] Deutsch, P. and J-L. Gailly, "ZLIB Compressed Data Format 245 Specification version 3.3", RFC 1950, 246 DOI 10.17487/RFC1950, May 1996, 247 . 249 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 250 Requirement Levels", BCP 14, RFC 2119, 251 DOI 10.17487/RFC2119, March 1997, 252 . 254 [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 255 and T. Wright, "Transport Layer Security (TLS) 256 Extensions", RFC 4366, DOI 10.17487/RFC4366, April 2006, 257 . 259 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 260 (TLS) Protocol Version 1.2", RFC 5246, 261 DOI 10.17487/RFC5246, August 2008, 262 . 264 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 265 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 266 Transport Layer Security (TLS) and Datagram Transport 267 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 268 June 2014, . 270 [RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security 271 (TLS) Cached Information Extension", RFC 7924, 272 DOI 10.17487/RFC7924, July 2016, 273 . 275 [RFC7932] Alakuijala, J. and Z. Szabadka, "Brotli Compressed Data 276 Format", RFC 7932, DOI 10.17487/RFC7932, July 2016, 277 . 279 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 280 Writing an IANA Considerations Section in RFCs", BCP 26, 281 RFC 8126, DOI 10.17487/RFC8126, June 2017, 282 . 284 Appendix A. Acknowledgements 286 Certificate compression was originally introduced in the QUIC Crypto 287 protocol, designed by Adam Langley and Wan-Teh Chang. 289 This document has benefited from contributions and suggestions from 290 David Benjamin, Ryan Hamilton, Ilari Liusvaara, Piotr Sikora, Ian 291 Swett, Martin Thomson, Sean Turner and many others. 293 Authors' Addresses 295 Alessandro Ghedini 296 Cloudflare, Inc. 298 Email: alessandro@cloudflare.com 300 Victor Vasiliev 301 Google 303 Email: vasilvv@google.com