A codepoint might be premature just yet. The idea of using a new handshake message type is to allow someone to choose between compressing and not. But consider the case where both client and server support non-intersecting sets. This negotiation would cause failure, but that would be unnecessary.
You could allow the server to advertise multiple (as the current format allows), but in that case, when the server certificate arrives and is compressed, the client can't know which compression method was used without trialing each. Similarly, when the client certificate arrives, the server can't know which compression method was used either. I think that the best solution to that problem is to include the compression scheme in the Certificate message. It also suggests (to me at least) that modifying Certificate rather than defining a CompressedCertificate makes sense, though that might not fit with the idea that you transform CompressedCertificate into Certificate before putting it in the transcript. Or, you could trim the list on the server side to a single value, but then you have to deal with TLS 1.3 CertificateRequest more explicitly, which is currently not at all addressed. In that spirit, I would also suggest that you describe what happens to a TLS 1.3 Certificate message that contains extensions (the entire thing is wrapped up as a whole, I assume). In light of the changes, this seems like a bug: If the server chooses to use the cached_info extension [RFC7924] to replace the Certificate message with a hash, it MUST NOT send the compress_certificates extension. The server could send the extension to allow the client to compress even if it had a cached certificate. On Sat, Dec 9, 2017 at 11:30 PM, Alessandro Ghedini <alessan...@ghedini.me> wrote: > 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 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
