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

HRR applies to both #417

Closed martinthomson closed 3 years ago

martinthomson commented 3 years ago

The current document is so close to getting this right. I think that this is correct and sufficient.

Closes #233. Closes #373 by doing nothing. Issue #358 can be fixed in TLS 1.3 proper. Issue #333 can be addressed separately.

cjpatton commented 3 years ago

On the whole I think this is an improvement over the current language. However, it doesn't seem to solve what I think of as our fundamental problem: any future extension to TLS 1.3 that is HRR-sensitive most not only consider how it changes the core protocol, but also how it interacts with ECH. Insofar as possible, we should design ECH in a way that mitigates friction when composing it with other protocol changes. Otherwise, I worry this could become the source of future bugs or vulnerabilities in TLS stacks.

That said, it may be the prevailing view that these sorts of composition issues are inherent to protocol design, and hence not worth spending too much time/energy trying to mitigate. I'd like to think these issues aren't inevitable. Admittedly, however, I lack the chops of others following this issue and may be incredibly naive :)

chris-wood commented 3 years ago

Closing as a solution to HRR since #423 was merged. (If we want to add text that suggests how clients construct CH1Inner/CH1Outer, that would be fine, but let's do it in a different PR!)