Christian, I don't think that's correct. We discussed this during our work on RFC 9000, and there's section 8.1 addresses exactly that problem:
> Loss of an Initial or Handshake packet from the server can cause a deadlock if the client does not send additional Initial or Handshake packets. A deadlock could occur when the server reaches its anti-amplification limit and the client has received acknowledgments for all the data it has sent. In this case, when the client has no reason to send additional packets, the server will be unable to send more data because it has not validated the client's address. To prevent this deadlock, clients MUST send a packet on a Probe Timeout (PTO); see Section 6.2 of [QUIC-RECOVERY]. Specifically, the client MUST send an Initial packet in a UDP datagram that contains at least 1200 bytes if it does not have Handshake keys, and otherwise send a Handshake packet. The easiest solution to the problem is to just send an ACK, but not the certificate. This might mean sending a few additional bytes, but as I've said in the meeting today, those won't suddenly make this an interesting amplification vector. Starting with a slightly higher RTT estimate is also not the end of the world, especially if you're using a loss-based congestion controller that will cause queues to build up at the bottleneck link during the connection. On Fri, 31 Mar 2023 at 00:40, Christian Huitema <[email protected]> wrote: > > > On 3/30/2023 12:37 AM, Martin Thomson wrote: > > On Thu, Mar 30, 2023, at 15:57, Marcin Nawrocki wrote: > >> Unfortunately, I ran out of time before presenting the third challenge: > >> An Initial containing both, the ACK and ServerHello, can skew the RTT > >> estimation of the client for some deployments (e.g., CDNs). This is > >> because the QUIC server can be separate from the process that has > >> access to TLS material, so there is a noticeable delay for fetching the > >> required TLS data. > > > > Yes, this will affect RTT estimates, but the effect will wash out over > time. The net effect is an inflated RTT estimate. > > > > You can maybe correct for this using ACK Delay. > > > >> Opinions on how to deal with this? Some CDNs split the Initial ACK and > >> Initial ServerHello into two packets, leading to more padding bytes. > >> Please see my slides 15-21 [1] for more information. > > > > I believe that some people already do this split, yes. I would prefer > that servers use subcerts for this: > https://datatracker.ietf.org/doc/html/draft-ietf-tls-subcerts > > > > There is another issue. It is a bit risky for the server to send the ACK > Initial before the client IP is validated. If the server ACKs the > client's initial packets, the client does not need to send any further > traffic until it has received the server hello. If the server hello is > lost, the server will have to resend it, and it will have to do so > within the amplification budget -- which in some cases may not be possible. > > There are potential workarounds of course. For example, the server could > bundle a PING with the ACK, to force the client to send more initial > packets and thus complete address validation. > > We may also lift the requirement that all server initial packets be > padded to 1200 bytes, which would allow for better use of the > amplification budget. But that's for QUIC v3... > > -- Christian Huitema > >
