You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It is possible for a QUIC client to send it is initial frames over multiple initial packets in the beginning of the (UDP) communication.
For example, Google Chrome 122 with Kyber768-based post-quantum Key Share enabled will need to send an oversized TLS ClientHello which is over 1700 bytes, exceeding the limit of ~1200 bytes per initial packet itself. Chrome instead sends the first Initial Packet (PKN: 1) with only a CRYPTO frame with a fixed size (~1200) and offset 0, followed by another Initial Packet containing the rest of TLS ClientHello in multiple smaller CRYPTO frames along with other frames including PING/PADDING.
The text was updated successfully, but these errors were encountered:
It is possible for a QUIC client to send it is initial frames over multiple initial packets in the beginning of the (UDP) communication.
For example, Google Chrome 122 with Kyber768-based post-quantum Key Share enabled will need to send an oversized TLS ClientHello which is over 1700 bytes, exceeding the limit of ~1200 bytes per initial packet itself. Chrome instead sends the first Initial Packet (PKN: 1) with only a CRYPTO frame with a fixed size (~1200) and offset 0, followed by another Initial Packet containing the rest of TLS ClientHello in multiple smaller CRYPTO frames along with other frames including PING/PADDING.
The text was updated successfully, but these errors were encountered: