refraction-networking / uquic Goto Github PK

Which results in the Firefox initial packets' frames not being sent and quic-go will sent the original one (PADDING, CRYPTO) instead.

If steadily replicated, we will need to check what is the proper fallback behavior.

Consider splitting CI into Go build runners and better test runners?

It is implementation-specific that when the server is not responding to QUIC Initial Packets carrying ClientHello messages, how often does the QUIC client retry by sending a new Initial Packet with a greater (by how many?) Packet Number, as well as how many retry will be made in total before the client gives up.

This could be trivially fingerprint-able and should be considered in designing a QUIC parrot.

They all need to pass, or we need to explain why each must fail.

Currently, some of them simply fails due to unknown reason.

When the first (parroted) Initial Packets fail to send or not getting an response, quic-go will send 2 identical fallback Initial Packets with default FRAMEs (PADDING, CRYPTO) with the only difference being the packet number (PN=1, PN=2 respectively), therefore violating the specs. The packets are sent in the following section.

Many QUIC clients don't have a single length for certain fields. Instead, they seem to have an upper and lower bound, which each connection randomly chooses a length within. Some of the fields I have noticed for this are as follows:

• Destination ID
• Source ID
• Grease Length

Some implementation (Google Chrome) uses Padding Frames to pad the QUIC payload to a certain length. Therefore despite being able to specify the exact bytes of each padding frames, it is also required to set a pad-to-N-bytes for QUIC Frames.

Google Chrome 122 (or maybe earlier) started to send an oversized TLS ClientHello if Kyber768-based PQ Key Share has been enabled.

In terms of QUIC, the TLS ClientHello will be broken into several pieces, a fix-sized (~1200B) large piece with offset 0 and other smaller pieces with random length/offset. The fix-sized large chunk was send in the first initial packet as the only frame in the packet, and the rest of the chunks are send in the second packets with other frames (PING/PADDING).

As discussed in quic-go#4007, uQUIC would prefer having this OPTIONAL feature implemented since observation indicates it is implementation-specific:

Mozilla Firefox and Google Chrome will send Initial ACK only if server sends an Initial ServerHello that is NOT coalesced with a Handshake packet. Otherwise, as the Initial ServerHello being coalesced with Handshake EncryptedExtensions, they will omit the ACK to the Initial ServerHello.

Apple Safari behaves differently, it will explicitly ACK to the Initial ServerHello even when it is coalesced.

Related RFC9001 section:

4.9.1. Discarding Initial Keys
Packets protected with Initial secrets (Section 5.2) are not authenticated, meaning that an attacker could spoof packets with the intent to disrupt a connection. To limit these attacks, Initial packet protection keys are discarded more aggressively than other keys.

The successful use of Handshake packets indicates that no more Initial packets need to be exchanged, as these keys can only be produced after receiving all CRYPTO frames from Initial packets. Thus, a client MUST discard Initial keys when it first sends a Handshake packet and a server MUST discard Initial keys when it first successfully processes a Handshake packet. Endpoints MUST NOT send Initial packets after this point.

This results in abandoning loss recovery state for the Initial encryption level and ignoring any outstanding Initial packets.

Some implementations (quic-go) size their padding frames such that the entire datagram is less than a certain size. In order to accomplish this, func (qfs QUICFrames) Build(cryptoData []byte) (payload []byte, err error) should be updated to determine the size of all other frames and then size the padding frames accordingly.

Further investigation needed on CI tests, for some of them are failing randomly and could not be reproduced stably (rerun the failed job and it may pass).