Change:
This also adds a paragraph about buffering of CRYPTO frames that references the buffering text in the transport doc. Closes no issue, but there have been complaints.

Discussion:
In order to drive the handshake, TLS depends on being able to send and receive handshake messages.  There are two basic functions on this interface: one where QUIC requests handshake messages and one <del> where QUIC provides handshake packets. </del> <ins> where QUIC provides bytes that comprise handshake messages. </ins> Before starting the handshake QUIC provides TLS with the transport parameters (see quic_parameters) that it wishes to carry.

Each encryption level is associated with a different sequence of bytes, which is reliably transmitted to the peer in CRYPTO frames. When TLS provides handshake bytes to be sent, they are appended to <del> the current flow.  Any packet that includes the CRYPTO frame is protected using keys from the corresponding encryption level.  Four encryption levels are used, producing keys for Initial, 0-RTT, </del> <ins> the handshake bytes for the current encryption level.  Any packet that includes the CRYPTO frame is protected using keys from the corresponding encryption level. Four encryption levels are used, producing keys for Initial, 0-RTT, </ins> Handshake, and 1-RTT packets.  CRYPTO frames are carried in just three of these levels, omitting the 0-RTT level.  These four levels correspond to three packet number spaces: Initial and Handshake

When an endpoint receives a QUIC packet containing a CRYPTO frame from the network, it proceeds as follows: <del> If the packet was in the TLS receiving encryption level, sequence the data into the input flow as usual.  As with STREAM frames, the offset is used to find the proper location in the data sequence. If the result of this process is that new data is available, then it is delivered to TLS in order. </del> <ins> If the packet uses the current TLS receiving encryption level, sequence the data into the input flow as usual.  As with STREAM frames, the offset is used to find the proper location in the data sequence.  If the result of this process is that new data is available, then it is delivered to TLS in order. </ins> If the packet is from a previously installed encryption level, it MUST NOT contain data which extends past the end of previously

If the packet is from a new encryption level, it is saved for later processing by TLS.  Once TLS moves to receiving from this <del> encryption level, saved data can be provided.  When providing data from any new encryption level to TLS, if there is data from a previous encryption level that TLS has not consumed, this MUST be treated as a connection error of type PROTOCOL_VIOLATION. </del> <ins> encryption level, saved data can be provided to TLS.  When providing data from any new encryption level to TLS, if there is data from a previous encryption level that TLS has not consumed, this MUST be treated as a connection error of type PROTOCOL_VIOLATION. </ins> Each time that TLS is provided with new data, new handshake bytes are requested from TLS.  TLS might not provide any bytes if the handshake messages it has received are incomplete or it has no data to send. <ins> The content of CRYPTO frames might either be processed incrementally by TLS or buffered until complete messages or flights are available. TLS is responsible for buffering handshake bytes that have arrived in order.  QUIC is responsible for buffering handshake bytes that arrive out of order or for encryption levels that are not yet ready.  QUIC does not provide any means of flow control for CRYPTO frames; see Section 7.5 of QUIC-TRANSPORT. </ins> Once the TLS handshake is complete, this is indicated to QUIC along with any final handshake bytes that TLS needs to send.  TLS also provides QUIC with the transport parameters that the peer advertised