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

# 4.2.  Extensions
#
# A number of TLS messages contain tag-length-value encoded extensions
# structures.
# 
#  struct {
#      ExtensionType extension_type;
#      opaque extension_data<0..2^16-1>;
#  } Extension;
# 
#  enum {
#      server_name(0),                             /* RFC 6066 */
#      max_fragment_length(1),                     /* RFC 6066 */
#      status_request(5),                          /* RFC 6066 */
#      supported_groups(10),                       /* RFC 8422, 7919 */
#      signature_algorithms(13),                   /* RFC 8446 */
#      use_srtp(14),                               /* RFC 5764 */
#      heartbeat(15),                              /* RFC 6520 */
#      application_layer_protocol_negotiation(16), /* RFC 7301 */
#      signed_certificate_timestamp(18),           /* RFC 6962 */
#      client_certificate_type(19),                /* RFC 7250 */
#      server_certificate_type(20),                /* RFC 7250 */
#      padding(21),                                /* RFC 7685 */
#      pre_shared_key(41),                         /* RFC 8446 */
#      early_data(42),                             /* RFC 8446 */
#      supported_versions(43),                     /* RFC 8446 */
#      cookie(44),                                 /* RFC 8446 */
#      psk_key_exchange_modes(45),                 /* RFC 8446 */
#      certificate_authorities(47),                /* RFC 8446 */
#      oid_filters(48),                            /* RFC 8446 */
#      post_handshake_auth(49),                    /* RFC 8446 */
#      signature_algorithms_cert(50),              /* RFC 8446 */
#      key_share(51),                              /* RFC 8446 */
#      (65535)
#  } ExtensionType;
# 
# Here:
# 
# -  "extension_type" identifies the particular extension type.
# 
# -  "extension_data" contains information specific to the particular
#    extension type.
# 
# The list of extension types is maintained by IANA as described in
# Section 11.
# 
# Extensions are generally structured in a request/response fashion,
# though some extensions are just indications with no corresponding
# response.  The client sends its extension requests in the ClientHello
# message, and the server sends its extension responses in the
# ServerHello, EncryptedExtensions, HelloRetryRequest, and Certificate
# messages.  The server sends extension requests in the
# CertificateRequest message which a client MAY respond to with a
# Certificate message.  The server MAY also send unsolicited extensions
# in the NewSessionTicket, though the client does not respond directly
# to these.
# 
# Implementations MUST NOT send extension responses if the remote
# endpoint did not send the corresponding extension requests, with the
# exception of the "cookie" extension in the HelloRetryRequest.  Upon
# receiving such an extension, an endpoint MUST abort the handshake
# with an "unsupported_extension" alert.
# 
# The table below indicates the messages where a given extension may
# appear, using the following notation: CH (ClientHello),
# SH (ServerHello), EE (EncryptedExtensions), CT (Certificate),
# CR (CertificateRequest), NST (NewSessionTicket), and
# HRR (HelloRetryRequest).  If an implementation receives an extension
# which it recognizes and which is not specified for the message in
# which it appears, it MUST abort the handshake with an
# "illegal_parameter" alert.
# 
# +--------------------------------------------------+-------------+
# | Extension                                        |     TLS 1.3 |
# +--------------------------------------------------+-------------+
# | server_name [RFC6066]                            |      CH, EE |
# |                                                  |             |
# | max_fragment_length [RFC6066]                    |      CH, EE |
# |                                                  |             |
# | status_request [RFC6066]                         |  CH, CR, CT |
# |                                                  |             |
# | supported_groups [RFC7919]                       |      CH, EE |
# |                                                  |             |
# | signature_algorithms (RFC 8446)                  |      CH, CR |
# |                                                  |             |
# | use_srtp [RFC5764]                               |      CH, EE |
# |                                                  |             |
# | heartbeat [RFC6520]                              |      CH, EE |
# |                                                  |             |
# | application_layer_protocol_negotiation [RFC7301] |      CH, EE |
# |                                                  |             |
# | signed_certificate_timestamp [RFC6962]           |  CH, CR, CT |
# |                                                  |             |
# | client_certificate_type [RFC7250]                |      CH, EE |
# |                                                  |             |
# | server_certificate_type [RFC7250]                |      CH, EE |
# |                                                  |             |
# | padding [RFC7685]                                |          CH |
# |                                                  |             |
# | key_share (RFC 8446)                             | CH, SH, HRR |
# |                                                  |             |
# | pre_shared_key (RFC 8446)                        |      CH, SH |
# |                                                  |             |
# | psk_key_exchange_modes (RFC 8446)                |          CH |
# |                                                  |             |
# | early_data (RFC 8446)                            | CH, EE, NST |
# |                                                  |             |
# | cookie (RFC 8446)                                |     CH, HRR |
# |                                                  |             |
# | supported_versions (RFC 8446)                    | CH, SH, HRR |
# |                                                  |             |
# | certificate_authorities (RFC 8446)               |      CH, CR |
# |                                                  |             |
# | oid_filters (RFC 8446)                           |          CR |
# |                                                  |             |
# | post_handshake_auth (RFC 8446)                   |          CH |
# |                                                  |             |
# | signature_algorithms_cert (RFC 8446)             |      CH, CR |
# +--------------------------------------------------+-------------+
# 
# When multiple extensions of different types are present, the
# extensions MAY appear in any order, with the exception of
# "pre_shared_key" (Section 4.2.11) which MUST be the last extension in
# the ClientHello (but can appear anywhere in the ServerHello
# extensions block).  There MUST NOT be more than one extension of the
# same type in a given extension block.
# 
# In TLS 1.3, unlike TLS 1.2, extensions are negotiated for each
# handshake even when in resumption-PSK mode.  However, 0-RTT
# parameters are those negotiated in the previous handshake; mismatches
# may require rejecting 0-RTT (see Section 4.2.10).
# 
# There are subtle (and not so subtle) interactions that may occur in
# this protocol between new features and existing features which may
# result in a significant reduction in overall security.  The following
# considerations should be taken into account when designing new
# extensions:
# 
# -  Some cases where a server does not agree to an extension are error
#    conditions (e.g., the handshake cannot continue), and some are
#    simply refusals to support particular features.  In general, error
#    alerts should be used for the former and a field in the server
#    extension response for the latter.
# 
# -  Extensions should, as far as possible, be designed to prevent any
#    attack that forces use (or non-use) of a particular feature by
#    manipulation of handshake messages.  This principle should be
#    followed regardless of whether the feature is believed to cause a
#    security problem.  Often the fact that the extension fields are
#    included in the inputs to the Finished message hashes will be
#    sufficient, but extreme care is needed when the extension changes
#    the meaning of messages sent in the handshake phase.  Designers
#    and implementors should be aware of the fact that until the
#    handshake has been authenticated, active attackers can modify
#    messages and insert, remove, or replace extensions.

[[spec]]
level = "MAY"
quote = '''
The server sends extension requests in the
CertificateRequest message which a client MAY respond to with a
Certificate message.
'''

[[spec]]
level = "MAY"
quote = '''
The server MAY also send unsolicited extensions
in the NewSessionTicket, though the client does not respond directly
to these.
'''

[[spec]]
level = "MUST"
quote = '''
Implementations MUST NOT send extension responses if the remote
endpoint did not send the corresponding extension requests, with the
exception of the "cookie" extension in the HelloRetryRequest.
'''

[[spec]]
level = "MUST"
quote = '''
Upon
receiving such an extension, an endpoint MUST abort the handshake
with an "unsupported_extension" alert.
'''

[[spec]]
level = "MUST"
quote = '''
If an implementation receives an extension
which it recognizes and which is not specified for the message in
which it appears, it MUST abort the handshake with an
"illegal_parameter" alert.
'''

[[spec]]
level = "MUST"
quote = '''
When multiple extensions of different types are present, the
extensions MAY appear in any order, with the exception of
"pre_shared_key" (Section 4.2.11) which MUST be the last extension in
the ClientHello (but can appear anywhere in the ServerHello
extensions block).
'''

[[spec]]
level = "MUST"
quote = '''
There MUST NOT be more than one extension of the
same type in a given extension block.
'''