search

tlswg / draft-ietf-tls-esni

TLS Encrypted Client Hello
https://tlswg.github.io/draft-ietf-tls-esni/#go.draft-ietf-tls-esni.html
Other
229 stars 58 forks source link

Require compressed extensions appear in the same relative order. #455

Closed davidben closed 3 years ago

davidben commented 3 years ago

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.)

sftcd commented 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.

davidben commented 3 years ago

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.

chris-wood commented 3 years ago

@davidben can you please rebase?

davidben commented 3 years ago

Rebased