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

# 5.7.  Receiving Out-of-Order Protected Packets
#
# Due to reordering and loss, protected packets might be received by an
# endpoint before the final TLS handshake messages are received.  A
# client will be unable to decrypt 1-RTT packets from the server,
# whereas a server will be able to decrypt 1-RTT packets from the
# client.  Endpoints in either role MUST NOT decrypt 1-RTT packets from
# their peer prior to completing the handshake.
# 
# Even though 1-RTT keys are available to a server after receiving the
# first handshake messages from a client, it is missing assurances on
# the client state:
# 
# *  The client is not authenticated, unless the server has chosen to
#    use a pre-shared key and validated the client's pre-shared key
#    binder; see Section 4.2.11 of [TLS13].
# 
# *  The client has not demonstrated liveness, unless the server has
#    validated the client's address with a Retry packet or other means;
#    see Section 8.1 of [QUIC-TRANSPORT].
# 
# *  Any received 0-RTT data that the server responds to might be due
#    to a replay attack.
# 
# Therefore, the server's use of 1-RTT keys before the handshake is
# complete is limited to sending data.  A server MUST NOT process
# incoming 1-RTT protected packets before the TLS handshake is
# complete.  Because sending acknowledgments indicates that all frames
# in a packet have been processed, a server cannot send acknowledgments
# for 1-RTT packets until the TLS handshake is complete.  Received
# packets protected with 1-RTT keys MAY be stored and later decrypted
# and used once the handshake is complete.
# 
#    |  Note: TLS implementations might provide all 1-RTT secrets prior
#    |  to handshake completion.  Even where QUIC implementations have
#    |  1-RTT read keys, those keys are not to be used prior to
#    |  completing the handshake.
# 
# The requirement for the server to wait for the client Finished
# message creates a dependency on that message being delivered.  A
# client can avoid the potential for head-of-line blocking that this
# implies by sending its 1-RTT packets coalesced with a Handshake
# packet containing a copy of the CRYPTO frame that carries the
# Finished message, until one of the Handshake packets is acknowledged.
# This enables immediate server processing for those packets.
# 
# A server could receive packets protected with 0-RTT keys prior to
# receiving a TLS ClientHello.  The server MAY retain these packets for
# later decryption in anticipation of receiving a ClientHello.
# 
# A client generally receives 1-RTT keys at the same time as the
# handshake completes.  Even if it has 1-RTT secrets, a client MUST NOT
# process incoming 1-RTT protected packets before the TLS handshake is
# complete.

[[spec]]
level = "MUST"
quote = '''
Endpoints in either role MUST NOT decrypt 1-RTT packets from
their peer prior to completing the handshake.
'''

[[spec]]
level = "MUST"
quote = '''
A server MUST NOT process
incoming 1-RTT protected packets before the TLS handshake is
complete.
'''

[[spec]]
level = "MAY"
quote = '''
Received
packets protected with 1-RTT keys MAY be stored and later decrypted
and used once the handshake is complete.
'''

[[spec]]
level = "MAY"
quote = '''
The server MAY retain these packets for
later decryption in anticipation of receiving a ClientHello.
'''

[[spec]]
level = "MUST"
quote = '''
Even if it has 1-RTT secrets, a client MUST NOT
process incoming 1-RTT protected packets before the TLS handshake is
complete.
'''