+1 Regarding the TCP initcwnd and QUIC Amplification topics. I would add kInitialRtt which we found ( https://www.nccoe.nist.gov/sites/default/files/2023-12/pqc-migration-nist-sp-1800-38c-preliminary-draft.pdf, section 7.3, Fig. 5) to introduce 60ms slowdowns due to QUIC's packet pacing. Note that these are discussed in the TCP and QUIC sections of https://pqcc.org/standards-with-open-questions-regarding-pqc-adoption as well. There are other publications talking about them too.
One thing I learned about the TCP initcwnd from the TCPM WG (https://mailarchive.ietf.org/arch/msg/tcpm/tmY-s-PAO9ubcb0PF1EFyxXeCWE ) is that senders can choose and update the TCP initcwnd for their connections based on network conditions. Thus, TCP has become more flexible since RFC6928. I am not sure what TCP stacks support tracking and adjusting initcwnds, but that came out of the WG discussion. Additionally, as discussed before, for the web, CDNs often use their own large initcwnds. -----Original Message----- From: Christian Huitema <huit...@huitema.net> Sent: Sunday, November 10, 2024 3:23 PM To: tls@ietf.org; p...@ietf.org Subject: [EXTERNAL] [Pqc] QUIC, amplification and PQC message sizes (was: Bytes server -> client) CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. I am reading the "bytes server -> client" thread, and I think that the evaluation misses a point regarding QUIC, and probably other UDP based protocols as well. The QUIC handshake embeds a TLS 1.3 handshake. The client sends the Client Hello in a series of QUIC Initial packets. The server replies with the Server Hello and the server first flight in a series of QUIC Initial and Handshake packets. One of the security concerns in "amplification". An attacker could send the client's Initial packets from a spoofed address; the server would respond with a first flight of packets to that address. If the volume of packets sent by the server is larger than the volume of packets received from the client, the attacker will have "amplified" the attack. The main defense against that amplification attack is to perform a three ways handshake and verify that the client address is not spoofed. However, that defense adds 1 RTT to the handshake duration. The next defense is to limit the volume of data sent by the server before the client address is verified. In the current version, the limit is a factor 3. In typical scenarios, the Client Hello first in a single packet, which must be padded to at least 1200 bytes. The server will send at most 3600 bytes in return, then wait for an acknowledgement from the client before sending the reminder of the first server flight, which of course will add 1 RTT to the handshake. Clients could try to mitigate the amplification limit by repeating the Client Hello several time, but they typically don't do that today because they are reluctant to waste CPU and bandwidth with unnecessary data. Apart from amplification considerations, we also have congestion control considerations. Both server and clients are limited by the "initial congestion window", whose current value is 10 packets. During the handshake the packet size is 1200 bytes, which implies that client and servers can send at most 12,000 bytes each before having to wait for an acknowledgement from the peer. If either the Client Hello or the server flight is larger than 12,000, the handshake will require an extra RTT. To summarize, the QUIC handshake will require an extra RTT: * if the server flight is larger than 3 times the Client Hello, * if the Client Hello is larger than 12,000 bytes, * if the Server Hello is larger than 12,000 bytes. If would be very nice to have PQC variants that fit inside that budget. _______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
