This case is a protocol error and should abort the handshake, not handle retry configs. I think that's the correct behavior. This is spelled out in the draft already: https://www.ietf.org/archive/id/draft-ietf-tls-esni-24.html#section-6.1.5-5 https://www.ietf.org/archive/id/draft-ietf-tls-esni-24.html#section-7.1.1-5
Changing the protocol as you suggest would mean to process this as a "oh just kidding, let's do an outer ClientHello handshake". This seems to give no benefit and only risk problems. I also don't think it would even work in the first place. The point of the retry flow is to repair config mismatches. This is not a config mismatch. The server has the ECH keys because it managed to decrypt CH1. Not only that, since CH2 decryption IIRC reuses the HPKE context, there's no config for the server to forget the next time around. If it does, as you note, the retry config isn't going to change anything that would lead to this issue getting repaired. Beyond that, this proposed change risks harm to the endpoints and the broader ECH ecosystem. In the general case, inner and outer ClientHellos may be different, so the allowed HRRs in response are different. Both sides would need to go back and recheck that the HRR was correct for the other ClientHello. If they don't, they can get into an inconsistent state and go haywire. It is also bad for the ecosystem because, even if it did work (see below), it can mask implementation bugs in the peer. To that end, the proposed protocol change wouldn't work in the first place. If the server has proceeded with the CHInner1, the transcript is built with that, not CHOuter1. If you change your mind, you have to go back and rebuild the transcript with CHOuter1 or you won't even derive matching handshake keys in the first place. This means: 1. The client must *require* the server indicate ECH acceptance in SH if it did so in HRR. 2. The server must treat decryption failure at CH2 as fatal and *not* fall back to an outer handshake. Both are already in the draft (see links above). I remember we discussed all this when we were working through how to make ECH + HRR work. Indeed this is *why* there is an ECH acceptance signal at HRR. Is there some new information to suggest changing the WG's decision here? David On Sat, Mar 22, 2025, 17:35 Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote: > > Hiya, > > I'm processing maintainer comments as I try get ECH code upstreamed > and wanna check a thing. Let's say the following happens: > > 1. Client send CH including real ECH attempt > 2. Server responds with HRR including good ECH acceptance signal > 3. Client sends 2nd-CH with new group and another ECH attempt > 4. Server responds with SH without good ECH signal and retry-configs > > In the above the server is behaving oddly, managing to successfully > decrypt ECH in the 1st round but failing to do that in the 2nd. But > I guess that could happen even if it shouldn't. > > After 4, I think a client library should just make the retry-configs > available to the calling application as usual. Does anyone disagree? > > I also think the ECH draft doesn't explicitly say to do that. > > That might I guess mean the retry-configs might be the same as the > ECHConfig that the client used at step 1, so there's a potential > loop if it all keeps happening, but since using the retry-configs > (or not) is a client application decision, that's out of scope for > a TLS library. > > I don't think any change to the ECH draft is required to handle > this, but if someone wanted to add a sentence that'd be ok too. > > Thanks and apologies if I'm missing where this was handled in the > draft or discussed previously, > Cheers, > S. > > _______________________________________________ > TLS mailing list -- tls@ietf.org > To unsubscribe send an email to tls-le...@ietf.org >
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
