QUIC: resend the whole ClientHello after a Retry

When the client received a Retry, ch_retry() marked only its first
Initial packet as pseudo-lost, assuming that the ClientHello fits in
it.  Since 3.5 the default key shares (X25519MLKEM768 and X25519) put
the ClientHello into two Initial packets.  The second one stayed in
flight, so the client resent only the first part of the ClientHello,
and the server could do no more than acknowledge it.  The rest was sent
only once that acknowledgement had the second packet declared lost:
one more round trip for every Retry, and a congestion event that halved
the congestion window although nothing was lost.

RFC 9002 section 6.3 has a client that receives a Retry reset its loss
recovery state, as the server processed none of its Initial packets.
Mark every Initial packet still in flight as pseudo-lost instead.
ch_restart() marked only the first Initial packet after version
negotiation in the same way.  It now shares the helper, so ch_retry()
no longer needs drop_later_pn to work out which packet number to mark.

A Version Negotiation packet and a Retry can be processed in the same
batch of datagrams.  The first then leaves no Initial packet in flight
for the second, and their data is already queued, so that is not an
error.  test_quic_retry_after_version_neg covers this order.

The SSL_trace reference recorded the extra round trip, and is updated.
The radix forbidden_frame_types script injects a frame into the
server's Initial packets.  With the whole ClientHello sent at once, a
post-quantum ServerHello can fill the server's only Initial packet,
leaving no room, so the script's server now uses classical groups.

Fixes: f538b4215528 "QUIC_CHANNEL: Implementation"
Fixes #33077
Assisted-by: Claude:claude-opus-5-5

Reviewed-by: Mounir Idrassi <[email protected]>
Reviewed-by: Saša Nedvědický <[email protected]>
Merge-date: Fri Oct 23 12:53:54 2026
Merged-from: https://github.com/openssl/openssl/pull/33298

0 files changed, 0 insertions, 0 deletions