On Sun, Nov 10, 2024, 12:24 PM Christian Huitema <huit...@huitema.net> wrote:
> 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. > We do with intermediate removal. At the extreme SQIsign is just twice as big as ECDSA. MAYO, HAWK, Falcon all add quite a bit less. The issue is we can get down to four signatures and one key without too many changes but to push beyond that harder. Sincerely, Watson > > -- Christian Huitema > > _______________________________________________ > TLS mailing list -- tls@ietf.org > To unsubscribe send an email to tls-le...@ietf.org >
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
