TLS Certificate Compression
draft-ietf-tls-certificate-compression-10

[Ballot comment]
I support publication of this document. One small question:

7.3.  Registry for Compression Algorithms

  The procedures for requesting values in the Specification Required
  space are specified in [RFC8447].

RFC 8447 doesn't define "Specification Required", RFC 8126 does. Is there a more specific section of RFC 8447 that you can point to, as it is unclear to me which parts of RFC 8447 apply here.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-tls-certificate-compression-07. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there are three actions which we must complete.

First, a new registry is to be created called the Certificate Compression Algorithm IDs registry. The new registry will be created on the Transport Layer Security (TLS) Extensions registry page located at:

https://www.iana.org/assignments/tls-extensiontype-values/

The registration rules, as defined by RFC 8126, for the new registry are as follows:

Values 0-255: IETF Review
Values 256-16383: Specification Required
Values 16384-65535: Experimental Use

There are initial registrations in the new registry as follows:

+------------------+------------------------------+-----------------+
| Algorithm Number | Description | Reference |
+------------------+------------------------------+-----------------+
| 0 | Reserved | |
| 1 | zlib | [ RFC-to-be ] |
| 2 | brotli | [ RFC-to-be ] |
| 3 | zstd | [ RFC-to-be ] |
| 16384 to 65535 | Reserved for Experimental | |
| | Use | |
+------------------+------------------------------+-----------------+

Second, in the TLS ExtensionType Registry on the Transport Layer Security (TLS) Extensions registry page located at:

https://www.iana.org/assignments/tls-extensiontype-values/

the early allocation for extension type:

27 compress_certificate (TEMPORARY - registered 2018-05-23, expires 2019-05-23) [draft-ietf-tls-certificate-compression]

will be made permanent and its reference changed to [ RFC-to-be ].

Third, in the TLS HandshakeType Registry on the Transport Layer Security (TLS) Parameters registry page located at:

https://www.iana.org/assignments/tls-extensiontype-values/

the handshake type:

25 compressed_certificate (TEMPORARY - registered 2018-05-23, expires 2018-05-23) DTLS-OK: Y [draft-ietf-tls-certificate-compression]

will be made permanent and it reference changed to [ RFC-to-be ].

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2019-12-09):

From: The IESG
To: IETF-Announce
CC: tls-chairs@ietf.org, Sean Turner , draft-ietf-tls-certificate-compression@ietf.org, tls@ietf.org, sean@sn3rd.com, kaduk@mit.edu
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (TLS Certificate Compression) to Proposed Standard


The IESG has received a request from the Transport Layer Security WG (tls) to
consider the following document: - 'TLS Certificate Compression'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2019-12-09. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

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.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-tls-certificate-compression/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-tls-certificate-compression/ballot/


No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc7932: Brotli Compressed Data Format (Informational - IETF stream)
    draft-kucherawy-rfc8478bis: Zstandard Compression and the application/zstd Media Type (None - IETF stream)
    rfc1950: ZLIB Compressed Data Format Specification version 3.3 (Informational - Legacy stream)

1.Summary

Sean Turner is the document shepherd.
Ben Kaduk is the very responsible Area Director.

This draft defines a TLS extension to compress certificate chains to reduce the amount of data transmitted and avoid some round trips.  The compression algorithms defined, zlib, brotli, and zstd, are all documented in RFCs.

The draft is intended for standards track; the WG supports this track as well as marking to Recommended column “Yes”.

2. Review and Consensus

This draft has been around for roughly two years though the idea has been around longer because certificates are a large part of the TLS handshake messages.  The authors have presented this draft at numerous TLS WG meetings.  There were no WGLC comments received, but this is due to the draft being stable for a while (early IANA code points were requested on 2018-05-23).  The only major change introduced since then was the addition of zstd, which was itself published in October 2018.

There were no major sources of conflict for this draft.

Google, Cloudflare, Apple, and FaceBook [0] have implemented this extension.  Firefox has also indicated they intend to prototype it.  It should also be noted that others. eg., the EMU WG, are interested in this feature.

[0] https://mailarchive.ietf.org/arch/msg/tls/idYj6mgvrlYBbdSfAOcw19pOv4A

3. Intellectual Property

I have confirmed with each author that to their direct, personal knowledge any IPR related to this document has already been disclosed.

4. Other Points

4.1. DOWNREFS!!!

The draft includes three downrefs:

** Downref: Normative reference to an Informational RFC: RFC 1950

** Downref: Normative reference to an Informational RFC: RFC 7932

** Downref: Normative reference to an Informational RFC: RFC 8478

NOTE: I have no idea why RFC 1950 is not in the downref registry - it’s been normatively referred to by a bunch of standards track RFCs: https://datatracker.ietf.org/doc/rfc1950/referencedby/

4.2. IANA Considerations

As noted earlier, an early code point assignments were made for both the extension codepoint and for the handshake message type.  The compression algorithms listed in 7.3 are all well known and documented in RFCs.  The DEs for the specification required rules are the same as they are for the rest of the TLS registries.  The DE procedures are as noted in RFC 8447.

1.Summary

Sean Turner is the document shepherd.
Ben Kaduk is the very responsible Area Director.

This draft defines a TLS extension to compress certificate chains to reduce the amount of data transmitted and avoid some round trips.  The compression algorithms defined, zlib, brotli, and zstd, are all documented in RFCs.

The draft is intended for standards track; the WG supports this track as well as marking to Recommended column “Yes”.

2. Review and Consensus

This draft has been around for roughly two years though the idea has been around longer because certificates are a large part of the TLS handshake messages.  The authors have presented this draft at numerous TLS WG meetings.  There were no WGLC comments received, but this is due to the draft being stable for a while (early IANA code points were requested on 2018-05-23).  The only major change introduced since then was the addition of zstd, which was itself published in October 2018.

There were no major sources of conflict for this draft.

Google, Cloudflare, and Apple have implemented this extension.  Firefox has also indicated they intend to prototype it.  It should also be noted that others. eg., the EMU WG, are interested in this feature.

3. Intellectual Property

I have confirmed with each author that to their direct, personal knowledge any IPR related to this document has already been disclosed.

4. Other Points

4.1. DOWNREFS!!!

The draft includes three downrefs:

** Downref: Normative reference to an Informational RFC: RFC 1950

** Downref: Normative reference to an Informational RFC: RFC 7932

** Downref: Normative reference to an Informational RFC: RFC 8478

NOTE: I have no idea why RFC 1950 is not in the downref registry - it’s been normatively referred to by a bunch of standards track RFCs: https://datatracker.ietf.org/doc/rfc1950/referencedby/

4.2. IANA Considerations

As noted earlier, an early code point assignments were made for both the extension codepoint and for the handshake message type.  The compression algorithms listed in 7.3 are all well known and documented in RFCs.  The DEs for the specification required rules are the same as they are for the rest of the TLS registries.  The DE procedures are as noted in RFC 8447.

1.Summary

Sean Turner is the document shepherd.
Ben Kaduk is the very responsible Area Director.

This draft defines a TLS extension to compress certificate chains to reduce the amount of data transmitted and avoid some round trips.  The compression algorithms defined, zlib, brotli, and zstd, are all documented in RFCs.

The draft is intended for standards track; the WG supports this track as well as marking to Recommended column “Yes”.

2. Review and Consensus

This draft has been around for roughly two years though the idea has been around longer because certificates are a large part of the TLS handshake messages.  The authors have presented this draft at numerous TLS WG meetings.  There were no WGLC comments received, but this is due to the draft being stable for a while (early IANA code points were requested on 2018-05-23).  The only major change introduced since then was the addition of zstd, which was itself published in October 2018.

There were no major sources of conflict for this draft.

Google, Cloudflare, and Apple have implemented this extension.  Firefox has also indicated they intend to prototype it.  It should also be noted that others. eg., the EMU WG, are interested in this feature.

3. Intellectual Property

I have confirmed with each author that to their direct, personal knowledge any IPR related to this document has already been disclosed.

4. Other Points

4.1. DOWNREFS!!!

The draft includes three downrefs:

** Downref: Normative reference to an Informational RFC: RFC 1950

** Downref: Normative reference to an Informational RFC: RFC 7932

** Downref: Normative reference to an Informational RFC: RFC 8478

NOTE: I have no idea why RFC 1950 is not in the downref registry - it’s been normatively referred to by a bunch of standards track RFCs: https://datatracker.ietf.org/doc/rfc1950/referencedby/

4.2. IANA Considerations

As noted earlier, an early code point assignments were made for both the extension codepoint and for the handshake message type.  The compression algorithms listed in 7.3 are all well known and documented in RFCs.  The DEs for the specification required rules are the same as they are for the rest of the TLS registries.  The DE procedures are as noted in RFC 8447.