Draft: draft-ietf-quic-tls

Commentary: 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 .
Paragraph (version A):
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
where QUIC provides handshake packets.
Paragraph (version B):
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
where QUIC provides bytes that comprise handshake messages.
Paragraph (version A):
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
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,
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
encrypted packets use their own separate spaces; 0-RTT and 1-RTT
packets use the application data packet number space.
Paragraph (version B):
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
the handshake bytes for the current encryption level.  Any packet
that includes the CRYPTO frame is protected using keys from the
corresponding encryption level.
Paragraph (version B):
Four encryption levels are used, producing keys for Initial, 0-RTT,
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
encrypted packets use their own separate spaces; 0-RTT and 1-RTT
packets use the application data packet number space.
Paragraph (version A):
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.
Paragraph (version B):
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.
Paragraph (version A):
If the packet is from a new encryption level, it is saved for
later processing by TLS.  Once TLS moves to receiving from this
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.
Paragraph (version B):
If the packet is from a new encryption level, it is saved for
later processing by TLS.  Once TLS moves to receiving from this
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.
Paragraph (version B):
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.