The serverhello.random trick is ugly and might interact with ticket handling...

[sftcd]

Encoding the "ECH worked" signal in the SH.random lower octets is, at best, ugly. It also arguably causes violation of internal API designs in at least the OpenSSL code. And I'm not sure if there might be some interaction between that and ticket handling (just from the look of some code I've yet to understand really.)

Do we really need such a hacky solution? Given the ECH sticks out in the CH, we could just define a non-encrypted extension in the SH to include the confirmation value maybe (though even that is pretty hacky).

[ekr]

I have some sympathy for this, but the point of this signal design was to make it difficult to distinguish GREASE from non-GREASE ECH.

[davidben]

Could you elaborate on the concern with ticket handling? I'm not sure I see how tickets would relate to this.

[sftcd]

On 10/03/2021 23:34, David Benjamin wrote: Could you elaborate on the concern with ticket handling? I'm not sure I see how tickets would relate to this.

Sorry for being slow - should get to looking again at that bit of code in a few days. S

[davidben]

Just to synchronize the discussion across list/GitHub a bit, this was discussed a bit in https://mailarchive.ietf.org/arch/msg/tls/pBjQDWT4ZvkATFKZ04rKZQ6Zvi4/. I agree with @sftcd now that there's some fiddly interactions from two ClientHellos and ServerHello.

I sketched out a possible change sketched out in https://mailarchive.ietf.org/arch/msg/tls/gpVj4FSmHQ2XQTKpQY07IDcD40I/. We could compute ClientHelloInner...ServerHelloECHConf as in the draft right now. But then rather than feed that into the handshake secret computation, just rely on that transcript containing a secret ClientHello.random and computing F(transcript). (Hash it down, KDF it with zero secret, whatever.)

One observation is that, while this relies oddly on a secret ClientHello.random, the existing construction does too. An attacker constructing a ServerHello gets to pick ServerHello.key_share and, with knowledge of ClientHello.key_share, compute the resulting shared secret.

[martinthomson]

One further observation here is that if the client uses the same shares for CHInner and CHOuter, the double key derivation piece doesn't really need to apply.

[cjpatton]

For my own reference, I just wanted to flag something that we've discussed on the list: the current acceptance signal interacts with PSK in a way that could easily cause a bug in an implementation that hasn't carefully vetted this interaction.