Amplification window, initial congestion window, initial RTT and new post-quantum signature implications

["Kampanakis, Panos" <[e-mail]>]

Hi all,

I was wondering if there have been any discussion about new quantum-resistant algorithms and their impact on QUIC. Looking back in the list archive I could only find https://mailarchive.ietf.org/arch/msg/quic/cA_azemZvSQadc9FvWnMfN-malQ/  which brought up the initial congestion and the amplification window issues which could introduce an RTT each to the handshake due to the large "post-quantum auth data" from the server. I don't think that discussion converged to any actionable items.

Recently published https://www.nccoe.nist.gov/sites/default/files/2023-12/pqc-migration-nist-sp-1800-38c-preliminary-draft.pdf  (Section 7.3, Figure 5) also showed that packet pacing can introduce >RTT time to each handshake. kInitialRtt=333 is a "SHOULD" in RFC9002 so it could be adjusted, but I am not sure that should be left to the implementer.

Tweaking the amplification window to 10-15x as the new signature algos would require, increases the amplification risk. Validation tokens could alleviate the issue especially for clients that keep coming to the same servers, but it is not a general solution.

Increasing the initial congestion window is already done by CDNs, but I am not sure it is the norm for most QUIC uses.

So, has the WG generally considered options to address these issues?

Thank you,
Panos