ClientHello not identical when Retry is received

[heinrich5991]

This originates from a Wireshark bug report: https://gitlab.com/wireshark/wireshark/-/issues/18757.

When the quiche client receives a Retry packet, it resends the ClientHello. According to the standard, this new ClientHello has to be the same as the first one, but it isn't, as the 32 random bytes are different.

From RFC 9000:

Other than updating the Destination Connection ID and Token fields, the Initial packet sent by the client is subject to the same restrictions as the first Initial packet. A client MUST use the same cryptographic handshake message it included in this packet. A server MAY treat a packet that contains a different cryptographic handshake message as a connection error or discard it. Note that including a Token field reduces the available space for the cryptographic handshake message, which might result in the client needing to send multiple Initial packets.
A client MUST NOT reset the packet number for any packet number space after processing a Retry packet.

[rageshkrishna]

I think I've just run into the same issue. I'm unable to decrypt captures in Wireshark because the SSLKEYLOGFILE output from quiche-server does not have the random value from either the ClientHello or ServerHello. I'm able to reproduce this at-will using the quiche-server app with the http3-client example.

That being said, I'm completely new to quiche (and quic in general), so is this a genuine issue or am I just holding it wrong?

[heinrich5991]

Note the workaround posted in the comment if you want to debug it right now.

This problem seems to go away if I turn off the quic.reassemble_crypto_out_of_order setting.

[rageshkrishna]

Note the workaround posted in the comment if you want to debug it right now.

Wow, I somehow completely missed that while reading the issue. Thanks for the pointer!