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

# 5.6.  Use of 0-RTT Keys
#
# If 0-RTT keys are available (see Section 4.6.1), the lack of replay
# protection means that restrictions on their use are necessary to
# avoid replay attacks on the protocol.
# 
# Of the frames defined in [QUIC-TRANSPORT], the STREAM, RESET_STREAM,
# STOP_SENDING, and CONNECTION_CLOSE frames are potentially unsafe for
# use with 0-RTT as they carry application data.  Application data that
# is received in 0-RTT could cause an application at the server to
# process the data multiple times rather than just once.  Additional
# actions taken by a server as a result of processing replayed
# application data could have unwanted consequences.  A client
# therefore MUST NOT use 0-RTT for application data unless specifically
# requested by the application that is in use.
# 
# An application protocol that uses QUIC MUST include a profile that
# defines acceptable use of 0-RTT; otherwise, 0-RTT can only be used to
# carry QUIC frames that do not carry application data.  For example, a
# profile for HTTP is described in [HTTP-REPLAY] and used for HTTP/3;
# see Section 10.9 of [QUIC-HTTP].
# 
# Though replaying packets might result in additional connection
# attempts, the effect of processing replayed frames that do not carry
# application data is limited to changing the state of the affected
# connection.  A TLS handshake cannot be successfully completed using
# replayed packets.
# 
# A client MAY wish to apply additional restrictions on what data it
# sends prior to the completion of the TLS handshake.
# 
# A client otherwise treats 0-RTT keys as equivalent to 1-RTT keys,
# except that it cannot send certain frames with 0-RTT keys; see
# Section 12.5 of [QUIC-TRANSPORT].
# 
# A client that receives an indication that its 0-RTT data has been
# accepted by a server can send 0-RTT data until it receives all of the
# server's handshake messages.  A client SHOULD stop sending 0-RTT data
# if it receives an indication that 0-RTT data has been rejected.
# 
# A server MUST NOT use 0-RTT keys to protect packets; it uses 1-RTT
# keys to protect acknowledgments of 0-RTT packets.  A client MUST NOT
# attempt to decrypt 0-RTT packets it receives and instead MUST discard
# them.
# 
# Once a client has installed 1-RTT keys, it MUST NOT send any more
# 0-RTT packets.
# 
#    |  Note: 0-RTT data can be acknowledged by the server as it
#    |  receives it, but any packets containing acknowledgments of
#    |  0-RTT data cannot have packet protection removed by the client
#    |  until the TLS handshake is complete.  The 1-RTT keys necessary
#    |  to remove packet protection cannot be derived until the client
#    |  receives all server handshake messages.

[[spec]]
level = "MUST"
quote = '''
A client
therefore MUST NOT use 0-RTT for application data unless specifically
requested by the application that is in use.
'''

[[spec]]
level = "MUST"
quote = '''
An application protocol that uses QUIC MUST include a profile that
defines acceptable use of 0-RTT; otherwise, 0-RTT can only be used to
carry QUIC frames that do not carry application data.
'''

[[spec]]
level = "MAY"
quote = '''
A client MAY wish to apply additional restrictions on what data it
sends prior to the completion of the TLS handshake.
'''

[[spec]]
level = "SHOULD"
quote = '''
A client SHOULD stop sending 0-RTT data
if it receives an indication that 0-RTT data has been rejected.
'''

[[spec]]
level = "MUST"
quote = '''
A server MUST NOT use 0-RTT keys to protect packets; it uses 1-RTT
keys to protect acknowledgments of 0-RTT packets.
'''

[[spec]]
level = "MUST"
quote = '''
A client MUST NOT
attempt to decrypt 0-RTT packets it receives and instead MUST discard
them.
'''

[[spec]]
level = "MUST"
quote = '''
A client MUST NOT
attempt to decrypt 0-RTT packets it receives and instead MUST discard
them.
'''

[[spec]]
level = "MUST"
quote = '''
Once a client has installed 1-RTT keys, it MUST NOT send any more
0-RTT packets.
'''