Change:
packet that cannot be authenticated, allowing multiple forgery attempts. <del> Endpoints MUST count the number of received packets that fail authentication for each set of keys.  If the number of packets that fail authentication with the same key exceeds a limit that is specific to the AEAD in use, the endpoint MUST stop using those keys. Endpoints MUST initiate a key update before reaching this limit.  If a key update is not possible, the endpoint MUST immediately close the connection.  Applying a limit reduces the probability that an attacker is able to successfully forge a packet; see AEBounds and ROBUST. Due to the way that header protection protects the Key Phase, packets that are discarded are likely to have an even distribution of both Key Phase values.  This means that packets that fail authentication will often use the packet protection keys from the next key phase.  It is therefore necessary to also track the number of packets that fail authentication with the next set of packet protection keys.  To avoid exhaustion of both sets of keys, it might be necessary to initiate two key updates in succession. For AEAD_AES_128_GCM, AEAD_AES_256_GCM, and AEAD_CHACHA20_POLY1305, the limit on the number of packets that fail authentication is 2^36. Note that the analysis in AEBounds supports a higher limit for the AEAD_AES_128_GCM and AEAD_AES_256_GCM, but this specification recommends a lower limit.  For AEAD_AES_128_CCM, the limit on the number of packets that fail authentication is 2^23.5; see ccm-bounds. </del> <ins> QUIC accounts for AEAD confidentiality and integrity limits separately.  The confidentiality limit applies to the number of packets encrypted with a given key.  The integrity limit applies to the number of packets decrypted within a given connection.  Details on enforcing these limits for each AEAD algorithm follow below. Endpoints MUST count the number of encrypted packets for each set of keys.  If the total number of encrypted packets with the same key exceeds the confidentiality limit for the selected AEAD, the endpoint MUST stop using those keys.  Endpoints MUST initiate a key update before sending more protected packets than the confidentiality limit for the selected AEAD permits.  If a key update is not possible or integrity limits are reached, the endpoint MUST stop using the connection and only send stateless resets in response to receiving packets.  It is RECOMMENDED that endpoints immediately close the connection with a connection error of type AEAD_LIMIT_REACHED before reaching a state where key updates are not possible. For AEAD_AES_128_GCM and AEAD_AES_256_GCM, the confidentiality limit is 2^25 encrypted packets; see gcm-bounds.  For AEAD_CHACHA20_POLY1305, the confidentiality limit is greater than the number of possible packets (2^62) and so can be disregarded.  For AEAD_AES_128_CCM, the confidentiality limit is 2^23.5 encrypted packets; see ccm-bounds.  Applying a limit reduces the probability that an attacker can distinguish the AEAD in use from a random permutation; see AEBounds, ROBUST, and GCM-MU. In addition to counting packets sent, endpoints MUST count the number of received packets that fail authentication during the lifetime of a connection.  If the total number of received packets that fail authentication within the connection, across all keys, exceeds the integrity limit for the selected AEAD, the endpoint MUST immediately close the connection with a connection error of type AEAD_LIMIT_REACHED and not process any more packets. For AEAD_AES_128_GCM and AEAD_AES_256_GCM, the integrity limit is 2^54 invalid packets; see gcm-bounds.  For AEAD_CHACHA20_POLY1305, the integrity limit is 2^36 invalid packets; see AEBounds.  For AEAD_AES_128_CCM, the integrity limit is 2^23.5 invalid packets; see ccm-bounds.  Applying this limit reduces the probability that an attacker can successfully forge a packet; see AEBounds, ROBUST, and GCM-MU. Future analyses and specifications MAY relax confidentiality or integrity limits for an AEAD. </ins> These limits were originally calculated using assumptions about the limits on TLS record size.  The maximum size of a TLS record

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!