<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc2629 version  -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>

<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc docmapping="yes"?>

<rfc docName="draft-ietf-tls-certificate-compression-01" category="std">

  <front>
    <title abbrev="TLS Certificate Compression">Transport Layer Security (TLS) Certificate Compression</title>

    <author initials="A." surname="Ghedini" fullname="Alessandro Ghedini">
      <organization>Cloudflare, Inc.</organization>
      <address>
        <email>alessandro@cloudflare.com</email>
      </address>
    </author>
    <author initials="V." surname="Vasiliev" fullname="Victor Vasiliev">
      <organization>Google</organization>
      <address>
        <email>vasilvv@google.com</email>
      </address>
    </author>

    <date year="2017" month="December" day="09"/>

    <area>Security</area>
    <workgroup>TLS</workgroup>
    

    <abstract>


<t>In Transport Layer Security (TLS) handshakes, certificate chains often take up
the majority of the bytes transmitted.</t>

<t>This document describes how certificate chains can be compressed to reduce the
amount of data transmitted and avoid some round trips.</t>



    </abstract>


  </front>

  <middle>


<section anchor="introduction" title="Introduction">

<t>In order to reduce latency and improve performance it can be useful to reduce
the amount of data exchanged during a Transport Layer Security (TLS) handshake.</t>

<t><xref target="RFC7924"></xref> 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.</t>

<t>This document describes a mechanism that would allow certificates to be
compressed during full handshakes.</t>

</section>
<section anchor="notational-conventions" title="Notational Conventions">

<t>The words “MUST”, “MUST NOT”, “SHALL”, “SHOULD”, and “MAY” are used in this
document.  It’s not shouting; when they are capitalized, they have the special
meaning defined in <xref target="RFC2119"></xref>.</t>

</section>
<section anchor="negotiating-certificate-compression" title="Negotiating Certificate Compression">

<t>This document defines a new extension type (compress_certificates(TBD)), which
is used by the client and the server to negotiate the use of compression for
their certificate chains, as well as the choice of the compression algorithm.</t>

<t>By sending the compress_certificates extension, the client indicates to the
server the certificate compression algorithms it supports.  The “extension_data”
field of this extension in the ClientHello SHALL contain a
CertificateCompressionAlgorithms value:</t>

<figure><artwork><![CDATA[
    enum {
        zlib(0),
        brotli(1),
        (255)
    } CertificateCompressionAlgorithm;

    struct {
        CertificateCompressionAlgorithm algorithms<1..2^8-1>;
    } CertificateCompressionAlgorithms;
]]></artwork></figure>

<t>If the server supports any of the algorithms offered in the ClientHello, it MAY
respond with an extension indicating which compression algorithm it chose.  In
that case, the “extension_data” SHALL be a CertificateCompressionAlgorithm value
corresponding to the chosen algorithm.  If the server has chosen to not use any
compression, it MUST NOT send the compress_certificates extension.</t>

</section>
<section anchor="compressed-certificate-message" title="Compressed Certificate Message">

<t>If a compression algorithm has been negotiated, server and client MAY compress
their corresponding Certificate messages and send them in the form of the
CompressedCertificate message (replacing the Certificate message).</t>

<t>The CompressedCertificate message is formed as follows:</t>

<figure><artwork><![CDATA[
    struct {
         uint24 uncompressed_length;
         opaque compressed_certificate_message<1..2^24-1>;
    } CompressedCertificate;
]]></artwork></figure>

<t><list style="hanging">
  <t hangText='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.</t>
  <t hangText='compressed_certificate_message'>
  The compressed body of the Certificate message, in the same format as it
would normally be expressed in. The compression algorithm defines how the
bytes in the compressed_certificate_message field are converted into the
Certificate message.</t>
</list></t>

<t>A peer is not required to compress their own Certificate messages even if the
compress_certficates extension has been negotiated, but MUST be able to
decompress a received CompressedCertificate message.</t>

<t>If the negotiated compression algorithm is zlib, then the Certificate message
MUST be compressed with the ZLIB compression algorithm, as defined in <xref target="RFC1950"></xref>.
If the negotiated compression algorithm is brotli, the Certificate message MUST
be compressed with the Brotli compression algorithm as defined in <xref target="RFC7932"></xref>.</t>

<t>If the received CompressedCertificate message cannot be decompressed, the
connection MUST be tore down with the “bad_certificate” alert.</t>

<t>If the format of the Certificate message is altered using the
server_certificate_type extension <xref target="RFC7250"></xref>, the resulting altered message is
compressed instead.</t>

<t>If the server chooses to use the cached_info extension <xref target="RFC7924"></xref> to replace
the Certificate message with a hash, it MUST NOT send the
compress_certificates extension.</t>

</section>
<section anchor="security-considerations" title="Security Considerations">

<t>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.</t>

<t>Since certificate chains are typically presented on a per-server name or
per-user basis, the attacker 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.</t>

<t>The implementations SHOULD bound the memory usage when decompressing the
CompressedCertificate message.</t>

<t>The implementations MUST limit the size of the resulting decompressed chain to
the specified uncompressed length, and they MUST abort the connection if the
size exceeds that limit.  TLS framing imposes 16777216 byte limit on the
certificate message size, and the 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.</t>

</section>
<section anchor="middlebox-compatibility" title="Middlebox Compatibility">

<t>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.</t>

<t>However this is not a problem when using TLS version 1.3 [draft-ietf-tls-tls13]
and higher, due to the fact that the Certificate (and thus the
CompressedCertificate) message is encrypted, preventing middleboxes from
intercepting it.</t>

</section>
<section anchor="iana-considerations" title="IANA Considerations">

<section anchor="update-of-the-tls-extensiontype-registry" title="Update of the TLS ExtensionType Registry">

<t>Create an entry, compress_certificates(TBD), in the existing registry for
ExtensionType (defined in <xref target="RFC5246"></xref>).</t>

</section>
<section anchor="update-of-the-tls-handshaketype-registry" title="Update of the TLS HandshakeType Registry">

<t>Create an entry, compressed_certificate(TBD), in the existing registry for
HandshakeType (defined in <xref target="RFC5246"></xref>).</t>

</section>
<section anchor="registry-for-compression-algorithms" title="Registry for Compression Algorithms">

<t>This document establishes a registry of compression algorithms supported for
compressing the Certificate message, titled “Certificate Compression Algorithm
IDs”, under the existing “Transport Layer Security (TLS) Extensions” heading.</t>

<t>The entries in the registry are:</t>

<texttable>
      <ttcol align='left'>Algorithm Number</ttcol>
      <ttcol align='left'>Description</ttcol>
      <c>0</c>
      <c>zlib</c>
      <c>1</c>
      <c>brotli</c>
      <c>224 to 255</c>
      <c>Reserved for Private Use</c>
</texttable>

<t>The values in this registry shall be allocated under “IETF Review” policy for
values strictly smaller than 64, and under “Specification Required” policy
otherwise (see <xref target="RFC5226"></xref> for the definition of relevant policies).</t>

</section>
</section>


  </middle>

  <back>

    <references title='Normative References'>





<reference  anchor="RFC1950" target='https://www.rfc-editor.org/info/rfc1950'>
<front>
<title>ZLIB Compressed Data Format Specification version 3.3</title>
<author initials='P.' surname='Deutsch' fullname='P. Deutsch'><organization /></author>
<author initials='J-L.' surname='Gailly' fullname='J-L. Gailly'><organization /></author>
<date year='1996' month='May' />
<abstract><t>This specification defines a lossless compressed data format.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.</t></abstract>
</front>
<seriesInfo name='RFC' value='1950'/>
<seriesInfo name='DOI' value='10.17487/RFC1950'/>
</reference>



<reference  anchor="RFC2119" target='https://www.rfc-editor.org/info/rfc2119'>
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='S. Bradner'><organization /></author>
<date year='1997' month='March' />
<abstract><t>In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='2119'/>
<seriesInfo name='DOI' value='10.17487/RFC2119'/>
</reference>



<reference  anchor="RFC5226" target='https://www.rfc-editor.org/info/rfc5226'>
<front>
<title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
<author initials='T.' surname='Narten' fullname='T. Narten'><organization /></author>
<author initials='H.' surname='Alvestrand' fullname='H. Alvestrand'><organization /></author>
<date year='2008' month='May' />
<abstract><t>Many protocols make use of identifiers consisting of constants and other well-known values.  Even after a protocol has been defined and deployment has begun, new values may need to be assigned (e.g., for a new option type in DHCP, or a new encryption or authentication transform for IPsec).  To ensure that such quantities have consistent values and interpretations across all implementations, their assignment must be administered by a central authority.  For IETF protocols, that role is provided by the Internet Assigned Numbers Authority (IANA).</t><t>In order for IANA to manage a given namespace prudently, it needs guidelines describing the conditions under which new values can be assigned or when modifications to existing values can be made.  If IANA is expected to play a role in the management of a namespace, IANA must be given clear and concise instructions describing that role.  This document discusses issues that should be considered in formulating a policy for assigning values to a namespace and provides guidelines for authors on the specific text that must be included in documents that place demands on IANA.</t><t>This document obsoletes RFC 2434.  This document specifies an Internet Best  Current Practices for the Internet Community, and requests discussion and  suggestions for improvements.</t></abstract>
</front>
<seriesInfo name='RFC' value='5226'/>
<seriesInfo name='DOI' value='10.17487/RFC5226'/>
</reference>



<reference  anchor="RFC5246" target='https://www.rfc-editor.org/info/rfc5246'>
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.2</title>
<author initials='T.' surname='Dierks' fullname='T. Dierks'><organization /></author>
<author initials='E.' surname='Rescorla' fullname='E. Rescorla'><organization /></author>
<date year='2008' month='August' />
<abstract><t>This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol.  The TLS protocol provides communications security over the Internet.  The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='5246'/>
<seriesInfo name='DOI' value='10.17487/RFC5246'/>
</reference>



<reference  anchor="RFC4366" target='https://www.rfc-editor.org/info/rfc4366'>
<front>
<title>Transport Layer Security (TLS) Extensions</title>
<author initials='S.' surname='Blake-Wilson' fullname='S. Blake-Wilson'><organization /></author>
<author initials='M.' surname='Nystrom' fullname='M. Nystrom'><organization /></author>
<author initials='D.' surname='Hopwood' fullname='D. Hopwood'><organization /></author>
<author initials='J.' surname='Mikkelsen' fullname='J. Mikkelsen'><organization /></author>
<author initials='T.' surname='Wright' fullname='T. Wright'><organization /></author>
<date year='2006' month='April' />
<abstract><t>This document describes extensions that may be used to add functionality to Transport Layer Security (TLS).  It provides both generic extension mechanisms for the TLS handshake client and server hellos, and specific extensions using these generic mechanisms.</t><t>The extensions may be used by TLS clients and servers.  The extensions are backwards compatible: communication is possible between TLS clients that support the extensions and TLS servers that do not support the extensions, and vice versa.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='4366'/>
<seriesInfo name='DOI' value='10.17487/RFC4366'/>
</reference>



<reference  anchor="RFC7250" target='https://www.rfc-editor.org/info/rfc7250'>
<front>
<title>Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)</title>
<author initials='P.' surname='Wouters' fullname='P. Wouters' role='editor'><organization /></author>
<author initials='H.' surname='Tschofenig' fullname='H. Tschofenig' role='editor'><organization /></author>
<author initials='J.' surname='Gilmore' fullname='J. Gilmore'><organization /></author>
<author initials='S.' surname='Weiler' fullname='S. Weiler'><organization /></author>
<author initials='T.' surname='Kivinen' fullname='T. Kivinen'><organization /></author>
<date year='2014' month='June' />
<abstract><t>This document specifies a new certificate type and two TLS extensions for exchanging raw public keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS).  The new certificate type allows raw public keys to be used for authentication.</t></abstract>
</front>
<seriesInfo name='RFC' value='7250'/>
<seriesInfo name='DOI' value='10.17487/RFC7250'/>
</reference>



<reference  anchor="RFC7932" target='https://www.rfc-editor.org/info/rfc7932'>
<front>
<title>Brotli Compressed Data Format</title>
<author initials='J.' surname='Alakuijala' fullname='J. Alakuijala'><organization /></author>
<author initials='Z.' surname='Szabadka' fullname='Z. Szabadka'><organization /></author>
<date year='2016' month='July' />
<abstract><t>This specification defines a lossless compressed data format that compresses data using a combination of the LZ77 algorithm and Huffman coding, with efficiency comparable to the best currently available general-purpose compression methods.</t></abstract>
</front>
<seriesInfo name='RFC' value='7932'/>
<seriesInfo name='DOI' value='10.17487/RFC7932'/>
</reference>



<reference  anchor="RFC7924" target='https://www.rfc-editor.org/info/rfc7924'>
<front>
<title>Transport Layer Security (TLS) Cached Information Extension</title>
<author initials='S.' surname='Santesson' fullname='S. Santesson'><organization /></author>
<author initials='H.' surname='Tschofenig' fullname='H. Tschofenig'><organization /></author>
<date year='2016' month='July' />
<abstract><t>Transport Layer Security (TLS) handshakes often include fairly static information, such as the server certificate and a list of trusted certification authorities (CAs).  This information can be of considerable size, particularly if the server certificate is bundled with a complete certificate chain (i.e., the certificates of intermediate CAs up to the root CA).</t><t>This document defines an extension that allows a TLS client to inform a server of cached information, thereby enabling the server to omit already available information.</t></abstract>
</front>
<seriesInfo name='RFC' value='7924'/>
<seriesInfo name='DOI' value='10.17487/RFC7924'/>
</reference>




    </references>




  </back>

<!-- ##markdown-source:
H4sIAHzSK1oAA5VZa28buRX9zl9BKB/WBiQhVpyk6xTFOsnuxoCTLWInQBu4
AWeGktjMDGdJSoq26f72nnvJeciWHFdAkNGIvM9zn55MJiKYUOozee1U7Rvr
grxUW+3klc5XzoStPLq+vDqWr7QLZm5yFbR8ZavGae+NrUVh81pVuF84NQ8T
o8N8Eko/yfvzk7w/PynxwgehsszpNbheXh0kTS8W1m3PpA+FUE6rs04qsbHu
y8LZVcM0hPBB1cVnVdoasmy1F405k5+CzcfSQymn5x5P2yo+QOpKNY2pFzdC
qFVYWncm5ERIfEztz+T5VP661IWpDb+LKp6XkAxsnN350brFmXxV2lUxLyHl
WF7U+ZR/0ZUy5ZlU3b2f8u7YFFbZYflxKj8qb0qj1wOeH00erNv9hRn+au2i
1EM2azqzXv+04F+Yvqitq1Qwaw315PtfXp38+PRxepydnPyYHp/OZs+6x9P2
8fTJs/bx+ay79vzHJ7PucXZ6JoSp5z0XMZlMpMp8cCoPQlzU3wPWEobxS/VF
wy0D0Mh8qWAWaedB1zLgd7lqRFhqWal/W75v55K+Z1sgSgbiUpkQdDEV4npp
PDl5Vek6yEL73JkMp5Z2s49JrmqZ4VsCny5ksNLpYpVrYiFUZVegA4aFCmrI
S0J6qdbWFIBZpSUQiRfBmcZPoy0qUxTwk3gEWARnQTMQuMky1hWwR8+KYqPO
t0zTQBS71rLRjq1b43cTWklXXs9XZX+VDXNLSv0V2tULyFjA3vVCqge7AqJ/
Sv69GVhPyUoTTeMrmEUFALu0G3qfA5tgzcaQXrt11IsNIzpzkRAD6+NiiaAu
thJMoQfCABSkVg7UXC/NWGarAOWRa7SvfwhyqctGbpaEC6ideOe2rnUePPNt
ZYDp+MzcOB9kMPAQqHaEWv5LBUt/qe2m1MVCt8CKNH7wdxFzD8Lu2GhjV2UR
LbWrPOTMtBhgLrkJji0HUTEl6LyzQRFsVIkMWa/BEl88SaHBwBVejt5+uLoe
jeP/8t1v/Hz15vzyMj789uHyNZ7IQ6O35/8YSVicYMRWD1BGtMpMpbwI0Lq2
AY6xK3Lbi87cW76Yq8YEVZo/dDGOb9mEbLVG50aVotIwAtQp9NzUkc2nlHVu
ok5I7sEoRsWhEnDHzESLjFzrDQCOcKFjMmwbLY9aU34emvno+uXr4+Mx5Df5
UoAY65xth9Aho/QOJ8fUSbaoEq4QJgZljIBFMWfcnnQCK3u50fAi/mc2S2vy
DlZDMqpcUC5bVrDIS8SBrgsyx/DYjja9zuOhAgbXOlBRwmo1oSND+fax9pRX
/KqhvODhfMLUqOPzmXLJSMyNBopZAzOQIoIHPmM53kBnKxl0FI5BUUCLgW8H
rj3v2a9VuaLK8eeff8ZyVq8q+R9+pM8fpcmOHh+PuxeZs6E0RyeDV0ezp0+P
+dt/5Xf4vRB8DgUKmXjA5jvXBvb668l0OvvXXyYnf3vxMJb+BesmLoZ5pTM5
4NfVsoFT7HyuXRueOxYek8MQwwJ8GgvsbnCDM+fALQwIwhIDf7/nuaAsrdcU
8rXgdJUrryO2bmMgORbVR33XWOxS5DaXRGRQ2zYYAPMB8sF7xy5LRE06RJGI
LETxByOJgRLRBinVcdw8JGg477zqM+4w7bylHm2h2UvqgL1ItExDsC4/IP0l
sSmJpHCEbzoCbZbYMcWQbxX5eibQKlK1bqfan8AhesH33JdHTjelytv0sefI
8TQWjPvpILyJKbU29MQVfhCcd+JGrkwdZqdyVfel7HOp60VYvugP2Ub9vhp2
WEMPfU68Y2DNToeRtU/WFE57OIozTl/xSxtU+7S0qZ+igjAgE8GIQUY7CFDo
IQy64oZcWLQsqJNgjKL/RZhxDOdhhTodD3AogVSjHNosp3Nt1q2LTI0wQePY
ysRwVhm1ZxHL3NAQaw7wSGiUqR3bjWi6cAGuvd+2yTKDdiOzxfYeE41bCHrM
ITJ2+AQJ9GEyNTU8XJTllnKC/trSRXu0w2o3hNoSTp141Cj274nZ/UrIWIa4
A6E2yAXml4qe3KcGDHOOJhoBaqKjnP59ZVxs8VtuMgap3dT7Q1Oj45ImRuFO
irmTYfanCOpf2buUPLMSXYUVPbiQbiIwKCPdF5vTroT0xA9lds91k+FXH3Kx
aGUaoKKFmvzn5cXL/cS5v7nV1tFcibbu/xAvVvHxwQgl2cQB2V7y3QO07wpH
I+tNb7yHGZtGLcILROhdldpdMYjN1oaY0nGSINSJeThWkyQpqu7JU4aGpMCN
wMqnxJG6u50A4Q64R+GnNLPfjJPGflVyN9AS6+kPJxA0rwED0fR2q4JyjHrM
3SXVYg5UlS8RpDT73+bLUyOPplSQ4my6T7fYtlDELPeXc/GQct7NsBiMvMFA
rdJsdE5ZfDeH34828iKG7jzaglLdnMTawGACc7ktEgQxEuEoD7PDwsGjykZt
IxMkfPZXO1vAjJEnjTX9sES51bcagHlDslEz4ONYFRMtnweYaVvWJl0of2Wo
iu3ZZ1CCBCLwjrIziYi2BNJTnNBGYZL8SismiUmGXsGxTmbKGx8VUCGo/AtZ
sC1xLAX19c6W0saeZ8ut5toUVPLmTi1oTvPCHMw5Y9kOhtxuspIp0kqtvshu
mUSyZmRqBsKAEGa3yhZmvm3rKFCGGgBUpP7GVE2pSY6IBBmHX9S7VfJFpSvr
toAyo5AS5AAlKca+l4j3MWIQlaYysYB7jMdtbPcROEwm0V9UDXabi2FL0jUS
CUnbe/qEVKKYsf6aa134aGYWijAKAMFLFQkC6TmoT549f/58dvKMC3ESP7Y7
O2ZvI4WId8LcNQFa30gYSGtNoajPEmgkeSRVNb96QYDOLFIAjRx+PNStacpt
Hx+RTIzH2g6nAI5Nnug5FbzlVVtmv3Jmh0SZKWlXLHifwVXZZgz9Iu2voM2i
Zg3RtmPszCAhPFa1hLgxQRrJdZPWBG4rkNq4cWvXA/vyyb7lG2zfb9g4XfCS
JLloyJNfFJZWVMCsdrzcjrzug6WozGJJlHymOVjpVoGkMsBIIq4KC40O7AZg
zDdwVtwgIKmlzklRgkL3UsWYifWItMJB9sbJ9In8dOvvAPh38uRGkCRLSKfd
GBbR7TA4R7PcJYIdQx5FjVf+cDQeD6skErTbNtxt4SRvyCDd0KhzZyvReZMj
IDBsLs7fnd+pHo8eyQ8NuzhFMCn6c1t5rqncvtcL4wkQ4pXTdJJGcGRHVIDD
q6iurdZfcZmkcIkM75R2ORzdamRoOX9DY9xe6d604HqodLtN9kPE22Vxn3jv
B9eGKz3Zb0Vub/c0YJ6Vxi91bIkTgVubt8GKJG1QIADJdiuD7y8+/MeuQo4O
LBx76cTFaz8ax/DbNcjoO1v0zoV+JJfopnAn1Qsyv+lnnU5DlGtM2N965vJd
TEXf5GteLDec3Xc+38S3s8ntz55X3U+g/1je+nzjIeH225a+PLl7PnbtB87P
ZqcU2LOnT7vz73XKtwSDvzuzJoN/QHX4Fk3CiyLf7qB7kwBkZcnjUlnanCeJ
6IrRxc/Xv4Ds2ujNSDa2NHmEZqKE2yYPKB+euqS24Dw7jSUr0biKlTZ2YyAW
J8KWnEBR0m5jIOWR1zpBe/bspvtzAuPe8GWg0+lSr6mA8HU4+Dj96SdDAyX+
BzXFWEhjHQAA

-->

</rfc>

