On Mon, Dec 11, 2017 at 09:59:56AM +1100, Martin Thomson wrote: > 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.
New handshake message type is pretty much necressary if one wants to also compress client certificates. Client does not have answer block outside certificate message, and trying to use that would lead into chicken and egg problem. And on supporting algorithms, the main problem is decompressing. There are very simple trivial "compression" algorithms for both Zlib and Brotli. And then there are pre-canned responses. > 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. Guessing here seems extremely bad idea. In general, in security protocols, you never want to guess what the other end intended. Trying to guess meaning is recipe for security problems. > 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. Transforming messages before putting them in transcript? That sounds like recipe for some very nasty implementation headaches. AFAIK, nothing else in TLS does this. TLS 1.3 has reset hash and inject synthetic message, but that is a lot easier than actual message transformation. > 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). Yes, that is what I get from the document. -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
