[TLS] Re: [Pqc] QUIC, amplification and PQC message sizes (was: Bytes server -> client)
+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 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
[TLS] QUIC, amplification and PQC message sizes (was: Bytes server -> client)
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. -- Christian Huitema ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Post-quantum hybrid ECDHE-MLKEM Key Agreement for TLSv1.3
Hello, As discussed during the TLS session at IETF 121, we would like to propose the adoption of draft-kwiatkowski-tls-ecdhe-mlkem. There are a few open questions that need to be addressed: 1. **Alignment of NamedGroup X25519MLKEM768** with the order of shared secrets, as per Section 3.2 of draft-ietf-tls-hybrid-design. - I suggest updating the name to mlkem768_x25519, while keeping the codepoint unchanged (if that is acceptable). If this change is made, I also recommend changing the name of Secp256r1MLKEM768 to align with x25519. 2. **Changing the order of shares in Secp256r1MLKEM768**. - The current order is based on requirements from SP800-56C-r2, and it was chosen to facilitate the migration of the TLSv1.3 handshake in a flow requiring FIPS certification. Although the switched order of shares aligns with FIPS, it necessitates the re-certification of the cryptographic module. The current order supports modules that are already deployed in the field. My (slight) personal preference would be to proceed with adoption but switch the order only if NIST relaxes the requirement regarding the order of shares in SP800-56C-r2, which we know is under discussion. Otherwise, I believe the current choice better supports migration to non-hybrid MLKEM, but I would appreciate feedback on this decision (ideally from others who have a requirement for FIPS). 3. **Setting RECOMMENDED=Y for Secp256r1MLKEM768**. Additionally, we plan to register Secp384r1MLKEM1024, but I believe this should only be done once we reach a consensus regarding point 2. Thank you! -- Kris Kwiatkowski Cryptography Dev ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
