draft-ietf-tls-certificate-compression-04.txt   draft-ietf-tls-certificate-compression-05.txt 
TLS A. Ghedini TLS A. Ghedini
Internet-Draft Cloudflare, Inc. Internet-Draft Cloudflare, Inc.
Intended status: Standards Track V. Vasiliev Intended status: Standards Track V. Vasiliev
Expires: April 6, 2019 Google Expires: October 7, 2019 Google
October 03, 2018 April 05, 2019
TLS Certificate Compression TLS Certificate Compression
draft-ietf-tls-certificate-compression-04 draft-ietf-tls-certificate-compression-05
Abstract Abstract
In TLS handshakes, certificate chains often take up the majority of In TLS handshakes, certificate chains often take up the majority of
the bytes transmitted. the bytes transmitted.
This document describes how certificate chains can be compressed to This document describes how certificate chains can be compressed to
reduce the amount of data transmitted and avoid some round trips. reduce the amount of data transmitted and avoid some round trips.
Status of This Memo Status of This Memo
skipping to change at page 1, line 35 skipping to change at page 1, line 35
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 6, 2019. This Internet-Draft will expire on October 7, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 19 skipping to change at page 3, line 19
the support for compressed client certificates. the support for compressed client certificates.
By sending a compress_certificate extension, the sender indicates to By sending a compress_certificate extension, the sender indicates to
the peer the certificate compression algorithms it is willing to use the peer the certificate compression algorithms it is willing to use
for decompression. The "extension_data" field of this extension for decompression. The "extension_data" field of this extension
SHALL contain a CertificateCompressionAlgorithms value: SHALL contain a CertificateCompressionAlgorithms value:
enum { enum {
zlib(1), zlib(1),
brotli(2), brotli(2),
zstd(3),
(65535) (65535)
} CertificateCompressionAlgorithm; } CertificateCompressionAlgorithm;
struct { struct {
CertificateCompressionAlgorithm algorithms<1..2^8-1>; CertificateCompressionAlgorithm algorithms<2..2^8-2>;
} CertificateCompressionAlgorithms; } CertificateCompressionAlgorithms;
There is no ServerHello extension that the server is required to echo There is no ServerHello extension that the server is required to echo
back. back.
4. Compressed Certificate Message 4. Compressed Certificate Message
If the peer has indicated that it supports compression, server and If the peer has indicated that it supports compression, server and
client MAY compress their corresponding Certificate messages and send client MAY compress their corresponding Certificate messages and send
them in the form of the CompressedCertificate message (replacing the them in the form of the CompressedCertificate message (replacing the
skipping to change at page 4, line 5 skipping to change at page 4, line 5
} CompressedCertificate; } CompressedCertificate;
algorithm The algorithm used to compress the certificate. The algorithm The algorithm used to compress the certificate. The
algorithm MUST be one of the algorithms listed in the peer's algorithm MUST be one of the algorithms listed in the peer's
compress_certificate extension. compress_certificate extension.
uncompressed_length The length of the Certificate message once it is uncompressed_length The length of the Certificate message once it is
uncompressed. If after decompression the specified length does uncompressed. If after decompression the specified length does
not match the actual length, the party receiving the invalid not match the actual length, the party receiving the invalid
message MUST abort the connection with the "bad_certificate" message MUST abort the connection with the "bad_certificate"
alert. alert. The presence of this field allows the receiver to pre-
allocate the buffer for the uncompressed Certificate message and
to enforce limits on the message size before performing
decompression.
compressed_certificate_message The compressed body of the compressed_certificate_message The compressed body of the
Certificate message, in the same format as it would normally be Certificate message, in the same format as it would normally be
expressed in. The compression algorithm defines how the bytes in expressed in. The compression algorithm defines how the bytes in
the compressed_certificate_message field are converted into the the compressed_certificate_message field are converted into the
Certificate message. Certificate message.
If the specified compression algorithm is zlib, then the Certificate If the specified compression algorithm is zlib, then the Certificate
message MUST be compressed with the ZLIB compression algorithm, as message MUST be compressed with the ZLIB compression algorithm, as
defined in [RFC1950]. If the specified compression algorithm is defined in [RFC1950]. If the specified compression algorithm is
brotli, the Certificate message MUST be compressed with the Brotli brotli, the Certificate message MUST be compressed with the Brotli
compression algorithm as defined in [RFC7932]. 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 pre-shared dictionary to achieve higher compression ratio.
This document does not define any such algorithms.
If the received CompressedCertificate message cannot be decompressed, If the received CompressedCertificate message cannot be decompressed,
the connection MUST be torn down with the "bad_certificate" alert. the connection MUST be torn down with the "bad_certificate" alert.
If the format of the Certificate message is altered using the If the format of the Certificate message is altered using the
server_certificate_type or client_certificate_type extensions server_certificate_type or client_certificate_type extensions
[RFC7250], the resulting altered message is compressed instead. [RFC7250], the resulting altered message is compressed instead.
5. Security Considerations 5. Security Considerations
After decompression, the Certificate message MUST be processed as if After decompression, the Certificate message MUST be processed as if
it were encoded without being compressed. This way, the parsing and it were encoded without being compressed. This way, the parsing and
the verification have the same security properties as they would have the verification have the same security properties as they would have
in TLS normally. in TLS normally.
In order for certificate compression to function correctly, the
underlying compression algorithm MUST be deterministic and it MUST
output the same data that was provided as input by the peer.
Since certificate chains are typically presented on a per-server name Since certificate chains are typically presented on a per-server name
or per-user basis, the attacker does not have control over any or per-user basis, the attacker does not have control over any
individual fragments in the Certificate message, meaning that they individual fragments in the Certificate message, meaning that they
cannot leak information about the certificate by modifying the cannot leak information about the certificate by modifying the
plaintext. plaintext.
The implementations SHOULD bound the memory usage when decompressing The implementations SHOULD bound the memory usage when decompressing
the CompressedCertificate message. the CompressedCertificate message.
The implementations MUST limit the size of the resulting decompressed The implementations MUST limit the size of the resulting decompressed
skipping to change at page 5, line 48 skipping to change at page 6, line 14
+------------------+-------------------------------+ +------------------+-------------------------------+
| Algorithm Number | Description | | Algorithm Number | Description |
+------------------+-------------------------------+ +------------------+-------------------------------+
| 0 | Reserved | | 0 | Reserved |
| | | | | |
| 1 | zlib | | 1 | zlib |
| | | | | |
| 2 | brotli | | 2 | brotli |
| | | | | |
| 3 | zstd |
| | |
| 16384 to 65535 | Reserved for Experimental Use | | 16384 to 65535 | Reserved for Experimental Use |
+------------------+-------------------------------+ +------------------+-------------------------------+
The values in this registry shall be allocated under "IETF Review" The values in this registry shall be allocated under "IETF Review"
policy for values strictly smaller than 256, under "Specification policy for values strictly smaller than 256, under "Specification
Required" policy for values 256-16383, and under "Experimental Use" Required" policy for values 256-16383, and under "Experimental Use"
otherwise (see [RFC8126] for the definition of relevant policies). otherwise (see [RFC8126] for the definition of relevant policies).
Experimental Use extensions can be used both on private networks and Experimental Use extensions can be used both on private networks and
over the open Internet. over the open Internet.
skipping to change at page 7, line 9 skipping to change at page 7, line 26
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
[RFC8447] Salowey, J. and S. Turner, "IANA Registry Updates for TLS [RFC8447] Salowey, J. and S. Turner, "IANA Registry Updates for TLS
and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018, and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018,
<https://www.rfc-editor.org/info/rfc8447>. <https://www.rfc-editor.org/info/rfc8447>.
[RFC8478] Collet, Y. and M. Kucherawy, Ed., "Zstandard Compression
and the application/zstd Media Type", RFC 8478,
DOI 10.17487/RFC8478, October 2018,
<https://www.rfc-editor.org/info/rfc8478>.
Appendix A. Acknowledgements Appendix A. Acknowledgements
Certificate compression was originally introduced in the QUIC Crypto Certificate compression was originally introduced in the QUIC Crypto
protocol, designed by Adam Langley and Wan-Teh Chang. protocol, designed by Adam Langley and Wan-Teh Chang.
This document has benefited from contributions and suggestions from This document has benefited from contributions and suggestions from
David Benjamin, Ryan Hamilton, Ilari Liusvaara, Piotr Sikora, Ian David Benjamin, Ryan Hamilton, Ilari Liusvaara, Piotr Sikora, Ian
Swett, Martin Thomson, Sean Turner and many others. Swett, Martin Thomson, Sean Turner and many others.
Authors' Addresses Authors' Addresses
 End of changes. 11 change blocks. 
8 lines changed or deleted 30 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/