target = "https://www.rfc-editor.org/rfc/rfc9001#section-4.1.3"

# 4.1.3.  Sending and Receiving Handshake Messages
#
# 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.
# 
# Before starting the handshake, QUIC provides TLS with the transport
# parameters (see Section 8.2) that it wishes to carry.
# 
# A QUIC client starts TLS by requesting TLS handshake bytes from TLS.
# The client acquires handshake bytes before sending its first packet.
# A QUIC server starts the process by providing TLS with the client's
# handshake bytes.
# 
# At any time, the TLS stack at an endpoint will have a current sending
# encryption level and a receiving encryption level.  TLS encryption
# levels determine the QUIC packet type and keys that are used for
# protecting data.
# 
# 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.  The encryption
# level then determines the type of packet that the resulting CRYPTO
# frame is carried in; see Table 1.
# 
# 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.
# 
# QUIC takes the unprotected content of TLS handshake records as the
# content of CRYPTO frames.  TLS record protection is not used by QUIC.
# QUIC assembles CRYPTO frames into QUIC packets, which are protected
# using QUIC packet protection.
# 
# QUIC CRYPTO frames only carry TLS handshake messages.  TLS alerts are
# turned into QUIC CONNECTION_CLOSE error codes; see Section 4.8.  TLS
# application data and other content types cannot be carried by QUIC at
# any encryption level; it is an error if they are received from the
# TLS stack.
# 
# When an endpoint receives a QUIC packet containing a CRYPTO frame
# from the network, it proceeds as follows:
# 
# *  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.
# 
# *  If the packet is from a previously installed encryption level, it
#    MUST NOT contain data that extends past the end of previously
#    received data in that flow.  Implementations MUST treat any
#    violations of this requirement as a connection error of type
#    PROTOCOL_VIOLATION.
# 
# *  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 TLS
#    provides keys for a higher encryption level, 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.
# 
# 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.
# 
# 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].
# 
# Once the TLS handshake is complete, this is indicated to QUIC along
# with any final handshake bytes that TLS needs to send.  At this
# stage, the transport parameters that the peer advertised during the
# handshake are authenticated; see Section 8.2.
# 
# Once the handshake is complete, TLS becomes passive.  TLS can still
# receive data from its peer and respond in kind, but it will not need
# to send more data unless specifically requested -- either by an
# application or QUIC.  One reason to send data is that the server
# might wish to provide additional or updated session tickets to a
# client.
# 
# When the handshake is complete, QUIC only needs to provide TLS with
# any data that arrives in CRYPTO streams.  In the same manner that is
# used during the handshake, new data is requested from TLS after
# providing received data.

[[spec]]
level = "MUST"
quote = '''
*  If the packet is from a previously installed encryption level, it
MUST NOT contain data that extends past the end of previously
received data in that flow.
'''

[[spec]]
level = "MUST"
quote = '''
Implementations MUST treat any
violations of this requirement as a connection error of type
PROTOCOL_VIOLATION.
'''

[[spec]]
level = "MUST"
quote = '''
When TLS
provides keys for a higher encryption level, 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.
'''