Hello, Sorry for the long delay from the last update.
On Sat, Dec 09, 2017 at 04:21:39AM -0800, internet-dra...@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Transport Layer Security WG of the IETF. > > Title : Transport Layer Security (TLS) Certificate > Compression > Authors : Alessandro Ghedini > Victor Vasiliev > Filename : draft-ietf-tls-certificate-compression-01.txt > Pages : 7 > Date : 2017-12-09 > > Abstract: > In Transport Layer Security (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. Here are the changes in this update, based on previous discussions: * Defined a new CompressedCertificate message instead of re-defining the contents of Certificate. Applications can decide to send a compressed certificate using this new message, or keep sending the normal uncompressed Certificate. This has a number of small advantages like making it possible for applications like WireShark to not have to maintain per-connection state when decoding compressed certificates since they could just look at the handshake message type instead of having to remember if compression was negotiated. But most importantly, this makes it possible for applications to decide whether to compress certificates on a case-by-case basis, even if they already negotiated support for it (see next point). * Added support for client certificates. Both server and client-side support is negotiated using the same "compress_certificates" extension, but given the previous change, client and server can negotiate compression and only decide to receive compressed certificates rather than send them (i.e. a client or server is only required to implement decompression). * Added a compatibility note regarding Certificate-intercepting middleboxes, explaining that replacing the Certificate message in TLS < 1.3 might cause connections to break. The only remaining issue is defining compression dictionaries [0]. However, attempts at defining one that is not biased (as per previous discussion on the subject [1]) haven't led to anything concrete (i.e. no substantial compression ratio increase). Both me and Victor don't think this is a blocking issue though, since dictionaries can be added later on by simply defining new compression type codepoints. Also, we think the wire format is pretty stable now, so we are wondering whether this would be a good time to start the process for early codepoint assignment (for the extension and handshake message type), so we can start looking at deploying this. Cheers [0] https://github.com/tlswg/certificate-compression/issues/1 [1] https://www.ietf.org/mail-archive/web/tls/current/msg22537.html _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
