target = "https://tools.ietf.org/rfc/rfc8446#4.1.1"

# 4.1.1.  Cryptographic Negotiation
#
# In TLS, the cryptographic negotiation proceeds by the client offering
# the following four sets of options in its ClientHello:
# 
# -  A list of cipher suites which indicates the AEAD algorithm/HKDF
#    hash pairs which the client supports.
# 
# -  A "supported_groups" (Section 4.2.7) extension which indicates the
#    (EC)DHE groups which the client supports and a "key_share"
#    (Section 4.2.8) extension which contains (EC)DHE shares for some
#    or all of these groups.
# 
# -  A "signature_algorithms" (Section 4.2.3) extension which indicates
#    the signature algorithms which the client can accept.  A
#    "signature_algorithms_cert" extension (Section 4.2.3) may also be
#    added to indicate certificate-specific signature algorithms.
# 
# -  A "pre_shared_key" (Section 4.2.11) extension which contains a
#    list of symmetric key identities known to the client and a
#    "psk_key_exchange_modes" (Section 4.2.9) extension which indicates
#    the key exchange modes that may be used with PSKs.
# 
# If the server does not select a PSK, then the first three of these
# options are entirely orthogonal: the server independently selects a
# cipher suite, an (EC)DHE group and key share for key establishment,
# and a signature algorithm/certificate pair to authenticate itself to
# the client.  If there is no overlap between the received
# "supported_groups" and the groups supported by the server, then the
# server MUST abort the handshake with a "handshake_failure" or an
# "insufficient_security" alert.
# 
# If the server selects a PSK, then it MUST also select a key
# establishment mode from the set indicated by the client's
# "psk_key_exchange_modes" extension (at present, PSK alone or with
# (EC)DHE).  Note that if the PSK can be used without (EC)DHE, then
# non-overlap in the "supported_groups" parameters need not be fatal,
# as it is in the non-PSK case discussed in the previous paragraph.
# 
# If the server selects an (EC)DHE group and the client did not offer a
# compatible "key_share" extension in the initial ClientHello, the
# server MUST respond with a HelloRetryRequest (Section 4.1.4) message.
# 
# If the server successfully selects parameters and does not require a
# HelloRetryRequest, it indicates the selected parameters in the
# ServerHello as follows:
# 
# -  If PSK is being used, then the server will send a "pre_shared_key"
#    extension indicating the selected key.
# 
# -  When (EC)DHE is in use, the server will also provide a "key_share"
#    extension.  If PSK is not being used, then (EC)DHE and
#    certificate-based authentication are always used.
# 
# -  When authenticating via a certificate, the server will send the
#    Certificate (Section 4.4.2) and CertificateVerify (Section 4.4.3)
#    messages.  In TLS 1.3 as defined by this document, either a PSK or
#    a certificate is always used, but not both.  Future documents may
#    define how to use them together.
# 
# If the server is unable to negotiate a supported set of parameters
# (i.e., there is no overlap between the client and server parameters),
# it MUST abort the handshake with either a "handshake_failure" or
# "insufficient_security" fatal alert (see Section 6).

[[spec]]
level = "MUST"
quote = '''
If there is no overlap between the received
"supported_groups" and the groups supported by the server, then the
server MUST abort the handshake with a "handshake_failure" or an
"insufficient_security" alert.
'''

[[spec]]
level = "MUST"
quote = '''
If the server selects a PSK, then it MUST also select a key
establishment mode from the set indicated by the client's
"psk_key_exchange_modes" extension (at present, PSK alone or with
(EC)DHE).
'''

[[spec]]
level = "MUST"
quote = '''
If the server selects an (EC)DHE group and the client did not offer a
compatible "key_share" extension in the initial ClientHello, the
server MUST respond with a HelloRetryRequest (Section 4.1.4) message.
'''

[[spec]]
level = "MUST"
quote = '''
If the server is unable to negotiate a supported set of parameters
(i.e., there is no overlap between the client and server parameters),
it MUST abort the handshake with either a "handshake_failure" or
"insufficient_security" fatal alert (see Section 6).
'''