I am testing the following scenario:
- server is not configured to use ECH
- client is configured by setting:
ctx->ech.client.ciphers = picoquic_hpke_cipher_suites;
ctx->ech.client.kems = picoquic_hpke_kems;
The connection proceeds, with ECH "grease" parameters in the ClientHello. The client obtains a session resume ticket, and starts a new connection with the same parameter and the ticket. The connection succeeds, but 0RTT is not negotiated -- the handshake is not of type PSK.
When I trace what is happening, I see that the session resume ticket (PSK identifier) is copied in the "inner" client hello, and some place holder is copied in the "outer" hello. Of course, since the server is not programmed to do ECH, it cannot accede the inner CH, so no 0RTT.
0RTT does work if the server is programmed to do ECH and if the second connection uses the same ECH parameters. I would have expected that 0RTT will work with ECH Grease, but it does not. That's unfortunate.
I am testing the following scenario:
The connection proceeds, with ECH "grease" parameters in the ClientHello. The client obtains a session resume ticket, and starts a new connection with the same parameter and the ticket. The connection succeeds, but 0RTT is not negotiated -- the handshake is not of type PSK.
When I trace what is happening, I see that the session resume ticket (PSK identifier) is copied in the "inner" client hello, and some place holder is copied in the "outer" hello. Of course, since the server is not programmed to do ECH, it cannot accede the inner CH, so no 0RTT.
0RTT does work if the server is programmed to do ECH and if the second connection uses the same ECH parameters. I would have expected that 0RTT will work with ECH Grease, but it does not. That's unfortunate.