Brotli has a dictionary built into the algorithm. I believe that is indeed being used, as it's a part of Brotli. I think the earlier email was saying no external certificate-specific dictionary used.
Brotli 1.03 and 1.05 each changed the standard dictionary—didn’t they? Perhaps I am misreading https://github.com/google/brotli/releases , but *even if* the Brotli maintainers are careful, I expect many less careful entities to version their compression schemes internally, without updating the codepoint. I don't think "no information flow from the algorithm" is particularly well-defined. The output of course takes information flow from the algorithm as the algorithm is being run. One could replace Brotli's dictionary from an array lookups to a series of ifs, etc., without changing the function. The transcript encoding must be injective, but we inherently have that requirement: the receiver needs to decompress it! The transcript includes all inputs to the receiver, notably the compression algorithm code point. No, the time of the transaction is a silent input. I’m worried about extremely persistent adversaries, including those who can update some of the involved software in apparently-innocent ways. -Brian Were Brotli's static dictionary changed, it would no longer be Brotli. It would perhaps be Brotli2 and would want a separate codepoint. To that end, I think the discussion on hash table lookups similarly forgot this decompressibility requirement. Let's define my_fancy_algorithm to be: func compress(input) { if input == some_particular_cert { return "0x00" } return "0x01" + input } This is silly, but still fine because the codepoint for my_fancy_algorithm is in the transcript. It would even be fine if my_fancy_algorithm relied on a separately-negotiated dictionary extension. The sender inherently must unambiguously communicate the dictionary name. That ends up in the transcript. (This is the same logic behind other uses of the handshake transcript. Blindly stuffing the handshake bytes into the transcript lets us align functional and security requirements.) David
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
