During the development of QUIC we were aware of the possibility of having a larger handshake and so most implementations are tested for compatibility.
What we did not do is tune the handshake parameters (RTT and amplification limit) to allow for higher performance under these conditions. The exact sizes of messages was not knowable at the time and so we couldn't make firm decisions. That all said, increasing amplification by a factor of 3-5 over our existing value (3x) seems unwise. The TLS WG is probably the right place to continue this discussion as - while QUIC might be able to adjust these parameters - the primary changes need to occur in the TLS stack. I'm aware of several attempts to change TLS, each of which might motivate a different adaptation in QUIC. On Wed, Dec 20, 2023, at 15:10, Kampanakis, Panos wrote: > 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
