Change:
As keys at a given encryption level become available to TLS, TLS indicates to QUIC that reading or writing keys at that encryption <del> level are available.  These events are not asynchronous; they always occur immediately after TLS is provided with new handshake bytes, or after TLS produces handshake bytes. </del> <ins> level are available. The availability of new keys is always a result of providing inputs to TLS.  TLS only provides new keys after being initialized (by a client) or when provided with new handshake data. However, a TLS implementation could perform some of its processing asynchronously.  In particular, the process of validating a certificate can take some time.  While waiting for TLS processing to complete, an endpoint SHOULD buffer received packets if they might be processed using keys that aren't yet available.  These packets can be processed once keys are provided by TLS.  An endpoint SHOULD continue to respond to packets that can be processed during this time. After processing inputs, TLS might produce handshake bytes, keys for new encryption levels, or both. </ins> TLS provides QUIC with three items as a new encryption level becomes available:

Discussion:
This clarifies the TLS interface by explaining that TLS only generates outputs (handshake bytes or keying material) in response to inputs. Previously, the only inputs we acknowledged were the handshake bytes, but this recognizes two more: the signal from the client to start handshaking, and - for async validation - a signal that a certificate is OK or not.
Weren't we going to say that the traffic keys might get generated asynchronously in ? I wonder how this PR interacts with . I see this PR calling out three types of events (i.e. generation of CH, input of handshake bytes, completion of certificate validation) as the "inputs," then claim that TLS provides the keys "synchronously" in relation to such events. That works as a definition, but I am not sure if it is easy to comprehend. I think my preference would be to talk about (a)synchronicity from the viewpoint of a transport. It would be easier to say that TLS might provide keys "asynchronously" from what the transport provides as input, then point out that key generation (possibly in relation to certificate verification) might take some time.
To answer both questions, I am planning on integrating the text from as well. That would cover the case where the TLS stack has to disappear for some time before it produces new outputs, however that manifests.
NAME NAME I've rebased this based on the changes in . Would you mind checking my work?
The label should be instead of .
Thanks NAME fixed.
The process for interacting with TLS does not acknowledge the possibility that progress in the handshake might depend on inputs other than CRYPTO frames. In particular, endpoints might need to perform additional checking to decide that the TLS handshake is complete. The most important example being the processing that occurs for certificate validation. This is often an asynchronous process, with OCSP and other muck, so recognizing that explicitly in the draft is worthwhile. This might help tease out one of the causes of the problem discussed in , but it doesn't lead to a solution.
Q: Does this indicate that the TLS changes involved in may be editorial? I'd like to focus on the transport and recovery changes to deal with the issue, and it'd be nice if the tls changes were separate from my perspective.
Why isn't adequate for this? Specifically, isn't it enough to change the stance from synchronous to asynchronous?

I would prefer to explain how certificate validation can take time and block availability of keys.
Should this become proposal-ready?
NAME : This is an editorial issue, so no.
Thanks looks great!