target = "https://www.rfc-editor.org/rfc/rfc9000#section-10.3.2"

# 10.3.2.  Calculating a Stateless Reset Token
#
# The stateless reset token MUST be difficult to guess.  In order to
# create a stateless reset token, an endpoint could randomly generate
# [RANDOM] a secret for every connection that it creates.  However,
# this presents a coordination problem when there are multiple
# instances in a cluster or a storage problem for an endpoint that
# might lose state.  Stateless reset specifically exists to handle the
# case where state is lost, so this approach is suboptimal.
# 
# A single static key can be used across all connections to the same
# endpoint by generating the proof using a pseudorandom function that
# takes a static key and the connection ID chosen by the endpoint (see
# Section 5.1) as input.  An endpoint could use HMAC [RFC2104] (for
# example, HMAC(static_key, connection_id)) or the HMAC-based Key
# Derivation Function (HKDF) [RFC5869] (for example, using the static
# key as input keying material, with the connection ID as salt).  The
# output of this function is truncated to 16 bytes to produce the
# stateless reset token for that connection.
# 
# An endpoint that loses state can use the same method to generate a
# valid stateless reset token.  The connection ID comes from the packet
# that the endpoint receives.
# 
# This design relies on the peer always sending a connection ID in its
# packets so that the endpoint can use the connection ID from a packet
# to reset the connection.  An endpoint that uses this design MUST
# either use the same connection ID length for all connections or
# encode the length of the connection ID such that it can be recovered
# without state.  In addition, it cannot provide a zero-length
# connection ID.
# 
# Revealing the stateless reset token allows any entity to terminate
# the connection, so a value can only be used once.  This method for
# choosing the stateless reset token means that the combination of
# connection ID and static key MUST NOT be used for another connection.
# A denial-of-service attack is possible if the same connection ID is
# used by instances that share a static key or if an attacker can cause
# a packet to be routed to an instance that has no state but the same
# static key; see Section 21.11.  A connection ID from a connection
# that is reset by revealing the stateless reset token MUST NOT be
# reused for new connections at nodes that share a static key.
# 
# The same stateless reset token MUST NOT be used for multiple
# connection IDs.  Endpoints are not required to compare new values
# against all previous values, but a duplicate value MAY be treated as
# a connection error of type PROTOCOL_VIOLATION.
# 
# Note that Stateless Resets do not have any cryptographic protection.

[[spec]]
level = "MUST"
quote = '''
The stateless reset token MUST be difficult to guess.
'''

[[spec]]
level = "MUST"
quote = '''
An endpoint that uses this design MUST
either use the same connection ID length for all connections or
encode the length of the connection ID such that it can be recovered
without state.
'''

[[spec]]
level = "MUST"
quote = '''
This method for
choosing the stateless reset token means that the combination of
connection ID and static key MUST NOT be used for another connection.
'''

[[spec]]
level = "MUST"
quote = '''
A connection ID from a connection
that is reset by revealing the stateless reset token MUST NOT be
reused for new connections at nodes that share a static key.
'''

[[spec]]
level = "MUST"
quote = '''
The same stateless reset token MUST NOT be used for multiple
connection IDs.
'''

[[spec]]
level = "MAY"
quote = '''
Endpoints are not required to compare new values
against all previous values, but a duplicate value MAY be treated as
a connection error of type PROTOCOL_VIOLATION.
'''