idnits 2.17.1 draft-ghedini-tls-certificate-compression-00.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 (March 01, 2017) is 2611 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 226, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1950 ** Obsolete normative reference: RFC 4366 (Obsoleted by RFC 5246, RFC 6066) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Downref: Normative reference to an Informational RFC: RFC 7932 Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Ghedini 3 Internet-Draft Cloudflare, Inc. 4 Intended status: Standards Track V. Vasiliev 5 Expires: September 2, 2017 Google 6 March 01, 2017 8 Transport Layer Security (TLS) Certificate Compression 9 draft-ghedini-tls-certificate-compression-00 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 http://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 September 2, 2017. 36 Copyright Notice 38 Copyright (c) 2017 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 (http://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. Server Certificate Message . . . . . . . . . . . . . . . . . 3 57 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 58 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 59 6.1. Update of the TLS ExtensionType Registry . . . . . . . . 4 60 6.2. Registry for Compression Algorithms . . . . . . . . . . . 5 61 7. Normative References . . . . . . . . . . . . . . . . . . . . 5 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 64 1. Introduction 66 In order to reduce latency and improve performance it can be useful 67 to reduce the amount of data exchanged during a Transport Layer 68 Security (TLS) handshake. 70 [RFC7924] describes a mechanism that allows a client and a server to 71 avoid transmitting certificates already shared in an earlier 72 handshake, but it doesn't help when the client connects to a server 73 for the first time and doesn't already have knowledge of the server's 74 certificate chain. 76 This document describes a mechanism that would allow server 77 certificates to be compressed during full handshakes. 79 2. Notational Conventions 81 The words "MUST", "MUST NOT", "SHALL", "SHOULD", and "MAY" are used 82 in this document. It's not shouting; when they are capitalized, they 83 have the special meaning defined in [RFC2119]. 85 3. Negotiating Certificate Compression 87 This document defines a new extension type 88 (compress_server_certificates(TBD)), which is used by the client and 89 the server to negotiate the use of compression for the server 90 certificate chain, as well as the choice of the compression 91 algorithm. 93 By sending the compress_server_certificates message, the client 94 indicates to the server the certificate compression algorithms it 95 supports. The "extension_data" field of this extension in the 96 ClientHello SHALL contain a CertificateCompressionAlgorithms value: 98 enum { 99 zlib(0), 100 brotli(1), 101 (255) 102 } CertificateCompressionAlgorithm; 104 struct { 105 CertificateCompressionAlgorithm algorithms<1..2^8>; 106 } CertificateCompressionAlgorithms; 108 If the server supports any of the algorithms offered in the 109 ClientHello, it MAY respond with an extension indicating which 110 compression algorithm it chose. In that case, the extension_data 111 SHALL be a CertificateCompressionAlgorithm value corresponding to the 112 chosen algorithm. If the server has chosen to not use any 113 compression, it MUST NOT send the compress_server_certificates 114 extension. 116 4. Server Certificate Message 118 If the server picks a compression algorithm and sends it in the 119 ServerHello, the format of the Certificate message is altered as 120 follows: 122 struct { 123 uint24 uncompressed_length; 124 opaque compressed_certificate_message<1..2^24-1>; 125 } Certificate; 127 uncompressed_length The length of the Certificate message once it is 128 uncompressed. If after decompression the specified length does 129 not match the actual length, the client MUST abort the connection 130 with the "bad_certificate" alert. 132 compressed_certificate_message The compressed body of the 133 Certificate message, in the same format as the server would 134 normally express it. The compression algorithm defines how the 135 bytes in the compressed_certificate_message are converted into the 136 Certificate message. 138 If the specified compression algorithm is zlib, then the Certificate 139 message MUST be compressed with the ZLIB compression algorithm, as 140 defined in [RFC1950]. If the specified compression algorithm is 141 brotli, the Certificate message MUST be compressed with the Brotli 142 compression algorithm as defined in [RFC7932]. 144 If the client cannot decompress the received Certificate message from 145 the server, it MUST tear down the connection with the 146 "bad_certificate" alert. 148 The extension only affects the Certificate message from the server. 149 It does not change the format of the Certificate message sent by the 150 client. 152 If the format of the message is altered using the 153 server_certificate_type extension [RFC7250], the resulting altered 154 message is compressed instead. 156 If the server chooses to use the cached_info extension [RFC7924] to 157 replace the Certificate message with a hash, it MUST NOT send the 158 compress_server_certificates extension. 160 5. Security Considerations 162 After decompression, the Certificate message MUST be processed as if 163 it were encoded without being compressed. This way, the parsing and 164 the verification have the same security properties as they would have 165 in TLS normally. 167 Since certificate chains are typically presented on a per-server name 168 basis, the attacker does not have control over any individual 169 fragments in the Certificate message, meaning that they cannot leak 170 information about the certificate by modifying the plaintext. 172 The implementations SHOULD bound the memory usage when decompressing 173 the Certificate message. 175 The implementations MUST limit the size of the resulting decompressed 176 chain to the specified uncompressed length, and they MUST abort the 177 connection if the size exceeds that limit. Implementations MAY 178 impose a lower limit on the chain size in addition to the 16777216 179 byte limit imposed by TLS framing, in which case they MUST apply the 180 same limit to the uncompressed chain before starting to decompress 181 it. 183 6. IANA Considerations 185 6.1. Update of the TLS ExtensionType Registry 187 Create an entry, compress_server_certificates(TBD), in the existing 188 registry for ExtensionType (defined in [RFC5246]). 190 6.2. Registry for Compression Algorithms 192 This document establishes a registry of compression algorithms 193 supported for compressing the Certificate message, titled 194 "Certificate Compression Algorithm IDs", under the existing 195 "Transport Layer Security (TLS) Extensions" heading. 197 The entries in the registry are: 199 +------------------+--------------------------+ 200 | Algorithm Number | Description | 201 +------------------+--------------------------+ 202 | 0 | zlib | 203 | | | 204 | 1 | brotli | 205 | | | 206 | 224 to 255 | Reserved for Private Use | 207 +------------------+--------------------------+ 209 The values in this registry shall be allocated under "IETF Review" 210 policy for values strictly smaller than 64, and under "Specification 211 Required" policy otherwise (see [RFC5226] for the definition of 212 relevant policies). 214 7. Normative References 216 [RFC1950] Deutsch, P. and J-L. Gailly, "ZLIB Compressed Data Format 217 Specification version 3.3", RFC 1950, 218 DOI 10.17487/RFC1950, May 1996, 219 . 221 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 222 Requirement Levels", BCP 14, RFC 2119, 223 DOI 10.17487/RFC2119, March 1997, 224 . 226 [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 227 and T. Wright, "Transport Layer Security (TLS) 228 Extensions", RFC 4366, DOI 10.17487/RFC4366, April 2006, 229 . 231 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 232 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 233 DOI 10.17487/RFC5226, May 2008, 234 . 236 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 237 (TLS) Protocol Version 1.2", RFC 5246, 238 DOI 10.17487/RFC5246, August 2008, 239 . 241 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 242 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 243 Transport Layer Security (TLS) and Datagram Transport 244 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 245 June 2014, . 247 [RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security 248 (TLS) Cached Information Extension", RFC 7924, 249 DOI 10.17487/RFC7924, July 2016, 250 . 252 [RFC7932] Alakuijala, J. and Z. Szabadka, "Brotli Compressed Data 253 Format", RFC 7932, DOI 10.17487/RFC7932, July 2016, 254 . 256 Authors' Addresses 258 Alessandro Ghedini 259 Cloudflare, Inc. 261 Email: alessandro@cloudflare.com 263 Victor Vasiliev 264 Google 266 Email: vasilvv@google.com