x/net/quic: excess CRYPTO data not cleaned up after keys discarded

[neild]

When a CRYPTO frame contains data which results in us discarding packet protection keys for a number space, we should verify that we don't have any excess buffered crypto data.

For example, if we receive CRYPTO frames in the Initial space containing bytes 0-100 and 101-200, and the 0-100 segment causes us to drop packet protection keys for the Initial space, the excess data (bytes 101-200) is erroneous and should result in the connection being closed.

(SImplest option here might be to avoid providing data to the TLS stack if we've got any gaps in the CRYPTO stream, and then let the TLS layer complain about receiving too much data.)

[gabyhelp]

Related Issues

• x/net/quic: mishandling of ACK frames after space dropped #70703

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[gopherbot]

Change https://go.dev/cl/634617 mentions this issue: quic: clean up crypto streams when dropping packet protection keys