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

# 5.2.  Initial Secrets
#
# Initial packets apply the packet protection process, but use a secret
# derived from the Destination Connection ID field from the client's
# first Initial packet.
# 
# This secret is determined by using HKDF-Extract (see Section 2.2 of
# [HKDF]) with a salt of 0x38762cf7f55934b34d179ae6a4c80cadccbb7f0a and
# the input keying material (IKM) of the Destination Connection ID
# field.  This produces an intermediate pseudorandom key (PRK) that is
# used to derive two separate secrets for sending and receiving.
# 
# The secret used by clients to construct Initial packets uses the PRK
# and the label "client in" as input to the HKDF-Expand-Label function
# from TLS [TLS13] to produce a 32-byte secret.  Packets constructed by
# the server use the same process with the label "server in".  The hash
# function for HKDF when deriving initial secrets and keys is SHA-256
# [SHA].
# 
# This process in pseudocode is:
# 
# initial_salt = 0x38762cf7f55934b34d179ae6a4c80cadccbb7f0a
# initial_secret = HKDF-Extract(initial_salt,
#                               client_dst_connection_id)
# 
# client_initial_secret = HKDF-Expand-Label(initial_secret,
#                                           "client in", "",
#                                           Hash.length)
# server_initial_secret = HKDF-Expand-Label(initial_secret,
#                                           "server in", "",
#                                           Hash.length)
# 
# The connection ID used with HKDF-Expand-Label is the Destination
# Connection ID in the Initial packet sent by the client.  This will be
# a randomly selected value unless the client creates the Initial
# packet after receiving a Retry packet, where the Destination
# Connection ID is selected by the server.
# 
# Future versions of QUIC SHOULD generate a new salt value, thus
# ensuring that the keys are different for each version of QUIC.  This
# prevents a middlebox that recognizes only one version of QUIC from
# seeing or modifying the contents of packets from future versions.
# 
# The HKDF-Expand-Label function defined in TLS 1.3 MUST be used for
# Initial packets even where the TLS versions offered do not include
# TLS 1.3.
# 
# The secrets used for constructing subsequent Initial packets change
# when a server sends a Retry packet to use the connection ID value
# selected by the server.  The secrets do not change when a client
# changes the Destination Connection ID it uses in response to an
# Initial packet from the server.
# 
#    |  Note: The Destination Connection ID field could be any length
#    |  up to 20 bytes, including zero length if the server sends a
#    |  Retry packet with a zero-length Source Connection ID field.
#    |  After a Retry, the Initial keys provide the client no assurance
#    |  that the server received its packet, so the client has to rely
#    |  on the exchange that included the Retry packet to validate the
#    |  server address; see Section 8.1 of [QUIC-TRANSPORT].
# 
# Appendix A contains sample Initial packets.

[[spec]]
level = "SHOULD"
quote = '''
Future versions of QUIC SHOULD generate a new salt value, thus
ensuring that the keys are different for each version of QUIC.
'''

[[spec]]
level = "MUST"
quote = '''
The HKDF-Expand-Label function defined in TLS 1.3 MUST be used for
Initial packets even where the TLS versions offered do not include
TLS 1.3.
'''