[TLS] Re: checking a bit of ECH behaviour

[David Benjamin <[e-mail]>]

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 <[e-mail]>
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 -- [e-mail]
> To unsubscribe send an email to [e-mail]
>