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.
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
