Closed davidben closed 3 years ago
On 09/06/2021 07:38, Martin Thomson wrote:
I'm not going to nitpick this, but I like it.
Same here (wrt liking:-).
Cheers, S.
My only concern with this is that it is somewhat more prescriptive than I would generally like for a specification. Moving this algorithmic stuff to an appendix might be a good balance. Either way, if you are adding this much text, it needs a section heading.
Moved to appendix.
@davidben can you please rebase?
Rebased
Closes #378. This is an alternative to #452, which constrains the client such this suggestion is feasible: https://github.com/tlswg/draft-ietf-tls-esni/pull/452#discussion_r647858091
@martinthomson, thoughts? This does constrain the client behavior, though our draft implementation would not be affected by it. (We run through all the extensions in our usual order and compute the inner value + whether to compress it. If we intend to compress it, we write it to a separate buffer instead of the pending ClientHelloInner. Then we drop in all the buffered extensions, so they're contiguous and, in the EncodedClientHelloInner, write ech_outer_extensions instead of the buffer. This process keeps the relative order of compressed extensions, so we follow this rule anyway.)