Hiya,
On 9/1/24 22:04, Douglas Stebila wrote:
On Sep 1, 2024, at 10:47 AM, Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote:Section 3.2 says there are two allowed ways to handle the same component algs being used in multiple key shares. However, doesn'tECH mean that additional possibilities exist? What should a client do in terms of re-use when using ECH?That's a good question. I'm not very familiar with subtleties around ECH. Is there any re-use allowed between ECH and the main handshake?
"main" handshake isn't quite trelatedhe right way of describing things - whether the client's inner or outer CH turns out to be the one used for the session depends on whether the ECH decryption has worked or not. But in any case, it's relatively undefined in ECH, which says: " Repeating large extensions, such as "key_share" with post-quantum algorithms, between ClientHelloInner and ClientHelloOuter can lead to excessive size. To reduce the size impact, the client MAY substitute extensions which it knows will be duplicated in ClientHelloOuter. " I forget what browsers do now, (can test if useful), but IIRC it can vary between sending new key shares in the inner CH vs. having the inner CH also use the key shares from the outer. I'd not be surprised if the incentive to re-use the outer CH key shares was more pressing in this situation. The ECH code I'm trying to upstream to OpenSSL allows any of the possibilities as of now (esp. on the server side), but that code hasn't been upstreamed yet, so if we decide to be more prescriptive/restrictive, that'd be ok from my POV anyway. There's also a related issue about what sets of ECHConfig values to publish/use for ECH, if one wants to see the same level of record-now-decrypt-later protection for the ECH encryption and the TLS handshake. All in all, I'd say this maybe warrants a bit of discussion, but I'd say it shouldn't be too hard to figure a good answer and what words to use. (I don't have a set of words to offer now, sorry;-) Cheers, S.
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
