Re: [quicwg/base-drafts] Desirable behavior when it takes time to derive the traffic keys for the next PN space (#3821)

[Jana Iyengar <[e-mail]>]

Posting the email I sent out to the list here, FTR. This got no pushback and support, FWIW. Note that this resolution makes this issue a design one, so I'm removing the editorial tag.

```
Problems:

During the handshake, an endpoint can receive packets (carrying data or acknowledgements) that it cannot decrypt because the requisite keys are not yet available. This can happen because the crypto machinery at the endpoint is waiting for earlier packets to be received to yield the keys. Similarly, a client might not be able to read 1-RTT packets received from the server because it is waiting for certificate validation to complete.

1. The assumption in the TLS specification is that when an endpoint is busy doing something (certificate validation or key generation for instance), it won't be able to respond to received packets with acknowledgements (Section 4.1.4).

Contrary to the assumption in the spec, Chrome and Firefox both process the certificate chain asynchronously, and therefore acks handshake packets immediately, even the ones that arrive after they have started verifying the certificate chain. But they buffer 1-RTT packets, and therefore the issue exists for 1-RTT packets.

As a result, there's potential delay, sometimes significant, in responding to some packets during the handshake. There are two side effects of this.


S1. First, this means that an endpoint that runs a PTO timer and retransmits data for 0-RTT and 1-RTT packets while the handshake is still in progress might be doing this quite unnecessarily. The peer may well have received this data and have queued it, waiting to be able to decrypt it. 


S2. Second, acks for these packets that are buffered and then later decrypted and read can be sent much later than when the packets were received at the peer, causing the ack_delay to potentially be much higher than the advertised max_ack_delay. The endpoint ignores ack_delay larger than max_ack_delay, and this inflates the smoothed_rtt and rtt_variance, potentially inflating the PTO significantly (which can cause handshakes to fail if the endpoint employs a "handshake timeout" period).


Proposed Solutions:

S1. To solve the first problem, we already have a condition in the recovery draft to _not_ arm the PTO on 1-RTT data until the handshake is complete (Section 6.2.1). This is not quite adequate, since it still allows a client to arm a PTO timer on 1-RTT data on sending a CFIN and 1-RTT data, before ensuring that the server has received the CFIN. The proposed solution here is to change this condition from "handshake complete" to "handshake confirmed". Meaning that an endpoint only arms a PTO timer on 0-RTT or 1-RTT data when it knows that the peer has the keys necessary to read and write in 1-RTT, and can therefore respond with an ACK.

We think this holds up, but we'd like to get this under everyone's eyes, to ensure that the discussion isn't missing subtle deadlock issues.


S2. To solve the second problem, the proposal is to use ack_delay as reported by the endpoint that buffers the data appropriately. ack_delay is the amount of the time the information (regardless of that being the packet itself or the acknowledgement) being buffered intentionally. For this, we need the following:

- endpoints MUST report an ack_delay that is the sum of the controlled delay (i.e. the duration of the data and the ack being buffered)

- endpoints ignore max_ack_delay for acknowledgements of packets that were sent prior to handshake confirmation. Those are the ones that might have been buffered at the peer until keys were ready.

In addition, we explicitly recommend endpoints that asynchronously process handshake messages to buffer 1-RTT packets, instead of dropping them, as dropping packets has significant impact on congestion control. Note that this matches what those implementations already do.
```



-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3821#issuecomment-665393532