diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc4492/section-2.1.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc4492/section-2.1.toml index 42e438c126b..06883958f60 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc4492/section-2.1.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc4492/section-2.1.toml @@ -1,23 +1,23 @@ target = "https://www.rfc-editor.org/rfc/rfc4492#section-2.1" -# 2.1. ECDH_ECDSA +# ECDH_ECDSA # -# In ECDH_ECDSA, the server's certificate MUST contain an ECDH-capable -# public key and be signed with ECDSA. +# In ECDH_ECDSA, the server's certificate MUST contain an ECDH-capable +# public key and be signed with ECDSA. # -# A ServerKeyExchange MUST NOT be sent (the server's certificate -# contains all the necessary keying information required by the client -# to arrive at the premaster secret). +# A ServerKeyExchange MUST NOT be sent (the server's certificate +# contains all the necessary keying information required by the client +# to arrive at the premaster secret). # -# The client generates an ECDH key pair on the same curve as the -# server's long-term public key and sends its public key in the -# ClientKeyExchange message (except when using client authentication -# algorithm ECDSA_fixed_ECDH or RSA_fixed_ECDH, in which case the -# modifications from Section 3.2 or Section 3.3 apply). +# The client generates an ECDH key pair on the same curve as the +# server's long-term public key and sends its public key in the +# ClientKeyExchange message (except when using client authentication +# algorithm ECDSA_fixed_ECDH or RSA_fixed_ECDH, in which case the +# modifications from Section 3.2 or Section 3.3 apply). # -# Both client and server perform an ECDH operation and use the -# resultant shared secret as the premaster secret. All ECDH -# calculations are performed as specified in Section 5.10. +# Both client and server perform an ECDH operation and use the +# resultant shared secret as the premaster secret. All ECDH +# calculations are performed as specified in Section 5.10. [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc4492/section-2.2.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc4492/section-2.2.toml index 45832a7a01d..f50e9739b18 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc4492/section-2.2.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc4492/section-2.2.toml @@ -1,21 +1,21 @@ target = "https://www.rfc-editor.org/rfc/rfc4492#section-2.2" -# 2.2. ECDHE_ECDSA +# ECDHE_ECDSA # -# In ECDHE_ECDSA, the server's certificate MUST contain an ECDSA- -# capable public key and be signed with ECDSA. +# In ECDHE_ECDSA, the server's certificate MUST contain an ECDSA- +# capable public key and be signed with ECDSA. # -# The server sends its ephemeral ECDH public key and a specification of -# the corresponding curve in the ServerKeyExchange message. These -# parameters MUST be signed with ECDSA using the private key -# corresponding to the public key in the server's Certificate. +# The server sends its ephemeral ECDH public key and a specification of +# the corresponding curve in the ServerKeyExchange message. These +# parameters MUST be signed with ECDSA using the private key +# corresponding to the public key in the server's Certificate. # -# The client generates an ECDH key pair on the same curve as the -# server's ephemeral ECDH key and sends its public key in the -# ClientKeyExchange message. +# The client generates an ECDH key pair on the same curve as the +# server's ephemeral ECDH key and sends its public key in the +# ClientKeyExchange message. # -# Both client and server perform an ECDH operation (Section 5.10) and -# use the resultant shared secret as the premaster secret. +# Both client and server perform an ECDH operation (Section 5.10) and +# use the resultant shared secret as the premaster secret. [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc4492/section-2.3.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc4492/section-2.3.toml index 7c6468e9b8f..bee46dc7473 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc4492/section-2.3.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc4492/section-2.3.toml @@ -1,9 +1,9 @@ target = "https://www.rfc-editor.org/rfc/rfc4492#section-2.3" -# 2.3. ECDH_RSA +# ECDH_RSA # -# This key exchange algorithm is the same as ECDH_ECDSA except that the -# server's certificate MUST be signed with RSA rather than ECDSA. +# This key exchange algorithm is the same as ECDH_ECDSA except that the +# server's certificate MUST be signed with RSA rather than ECDSA. [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc4492/section-2.4.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc4492/section-2.4.toml index 0a63d758534..ab8e23d53c2 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc4492/section-2.4.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc4492/section-2.4.toml @@ -1,12 +1,12 @@ target = "https://www.rfc-editor.org/rfc/rfc4492#section-2.4" -# 2.4. ECDHE_RSA +# ECDHE_RSA # -# This key exchange algorithm is the same as ECDHE_ECDSA except that -# the server's certificate MUST contain an RSA public key authorized -# for signing, and that the signature in the ServerKeyExchange message -# must be computed with the corresponding RSA private key. The server -# certificate MUST be signed with RSA. +# This key exchange algorithm is the same as ECDHE_ECDSA except that +# the server's certificate MUST contain an RSA public key authorized +# for signing, and that the signature in the ServerKeyExchange message +# must be computed with the corresponding RSA private key. The server +# certificate MUST be signed with RSA. [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc4492/section-2.5.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc4492/section-2.5.toml index 46ad43101b2..4315abbe393 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc4492/section-2.5.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc4492/section-2.5.toml @@ -1,36 +1,36 @@ target = "https://www.rfc-editor.org/rfc/rfc4492#section-2.5" -# 2.5. ECDH_anon +# ECDH_anon # -# In ECDH_anon, the server's Certificate, the CertificateRequest, the -# client's Certificate, and the CertificateVerify messages MUST NOT be -# sent. +# In ECDH_anon, the server's Certificate, the CertificateRequest, the +# client's Certificate, and the CertificateVerify messages MUST NOT be +# sent. # -# The server MUST send an ephemeral ECDH public key and a specification -# of the corresponding curve in the ServerKeyExchange message. These -# parameters MUST NOT be signed. +# The server MUST send an ephemeral ECDH public key and a specification +# of the corresponding curve in the ServerKeyExchange message. These +# parameters MUST NOT be signed. # -# The client generates an ECDH key pair on the same curve as the -# server's ephemeral ECDH key and sends its public key in the -# ClientKeyExchange message. +# The client generates an ECDH key pair on the same curve as the +# server's ephemeral ECDH key and sends its public key in the +# ClientKeyExchange message. # -# Both client and server perform an ECDH operation and use the -# resultant shared secret as the premaster secret. All ECDH -# calculations are performed as specified in Section 5.10. +# Both client and server perform an ECDH operation and use the +# resultant shared secret as the premaster secret. All ECDH +# calculations are performed as specified in Section 5.10. # -# Note that while the ECDH_ECDSA, ECDHE_ECDSA, ECDH_RSA, and ECDHE_RSA -# key exchange algorithms require the server's certificate to be signed -# with a particular signature scheme, this specification (following the -# similar cases of DH_DSS, DHE_DSS, DH_RSA, and DHE_RSA in [2] and [3]) -# does not impose restrictions on signature schemes used elsewhere in -# the certificate chain. (Often such restrictions will be useful, and -# it is expected that this will be taken into account in certification -# authorities' signing practices. However, such restrictions are not -# strictly required in general: Even if it is beyond the capabilities -# of a client to completely validate a given chain, the client may be -# able to validate the server's certificate by relying on a trusted -# certification authority whose certificate appears as one of the -# intermediate certificates in the chain.) +# Note that while the ECDH_ECDSA, ECDHE_ECDSA, ECDH_RSA, and ECDHE_RSA +# key exchange algorithms require the server's certificate to be signed +# with a particular signature scheme, this specification (following the +# similar cases of DH_DSS, DHE_DSS, DH_RSA, and DHE_RSA in [2] and [3]) +# does not impose restrictions on signature schemes used elsewhere in +# the certificate chain. (Often such restrictions will be useful, and +# it is expected that this will be taken into account in certification +# authorities' signing practices. However, such restrictions are not +# strictly required in general: Even if it is beyond the capabilities +# of a client to completely validate a given chain, the client may be +# able to validate the server's certificate by relying on a trusted +# certification authority whose certificate appears as one of the +# intermediate certificates in the chain.) [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc4492/section-2.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc4492/section-2.toml index ebd110d563f..563ca19ca97 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc4492/section-2.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc4492/section-2.toml @@ -1,101 +1,101 @@ target = "https://www.rfc-editor.org/rfc/rfc4492#section-2" -# 2. Key Exchange Algorithms +# Key Exchange Algorithms # -# This document introduces five new ECC-based key exchange algorithms -# for TLS. All of them use ECDH to compute the TLS premaster secret, -# and they differ only in the lifetime of ECDH keys (long-term or -# ephemeral) and the mechanism (if any) used to authenticate them. The -# derivation of the TLS master secret from the premaster secret and the -# subsequent generation of bulk encryption/MAC keys and initialization -# vectors is independent of the key exchange algorithm and not impacted -# by the introduction of ECC. -# -# The table below summarizes the new key exchange algorithms, which -# mimic DH_DSS, DHE_DSS, DH_RSA, DHE_RSA, and DH_anon (see [2] and -# [3]), respectively. -# -# Key -# Exchange -# Algorithm Description -# --------- ----------- -# -# ECDH_ECDSA Fixed ECDH with ECDSA-signed certificates. -# -# ECDHE_ECDSA Ephemeral ECDH with ECDSA signatures. -# -# ECDH_RSA Fixed ECDH with RSA-signed certificates. -# -# ECDHE_RSA Ephemeral ECDH with RSA signatures. -# -# ECDH_anon Anonymous ECDH, no signatures. -# -# Table 2: ECC Key Exchange Algorithms -# -# The ECDHE_ECDSA and ECDHE_RSA key exchange mechanisms provide forward -# secrecy. With ECDHE_RSA, a server can reuse its existing RSA -# certificate and easily comply with a constrained client's elliptic -# curve preferences (see Section 4). However, the computational cost -# -# incurred by a server is higher for ECDHE_RSA than for the traditional -# RSA key exchange, which does not provide forward secrecy. -# -# The ECDH_RSA mechanism requires a server to acquire an ECC -# certificate, but the certificate issuer can still use an existing RSA -# key for signing. This eliminates the need to update the keys of -# trusted certification authorities accepted by TLS clients. The -# ECDH_ECDSA mechanism requires ECC keys for the server as well as the -# certification authority and is best suited for constrained devices -# unable to support RSA. -# -# The anonymous key exchange algorithm does not provide authentication -# of the server or the client. Like other anonymous TLS key exchanges, -# it is subject to man-in-the-middle attacks. Implementations of this -# algorithm SHOULD provide authentication by other means. -# -# Note that there is no structural difference between ECDH and ECDSA -# keys. A certificate issuer may use X.509 v3 keyUsage and -# extendedKeyUsage extensions to restrict the use of an ECC public key -# to certain computations [15]. This document refers to an ECC key as -# ECDH-capable if its use in ECDH is permitted. ECDSA-capable is -# defined similarly. -# -# Client Server -# ------ ------ -# -# ClientHello --------> -# ServerHello -# Certificate* -# ServerKeyExchange* -# CertificateRequest*+ -# <-------- ServerHelloDone -# Certificate*+ -# ClientKeyExchange -# CertificateVerify*+ -# [ChangeCipherSpec] -# Finished --------> -# [ChangeCipherSpec] -# <-------- Finished -# -# Application Data <-------> Application Data -# -# * message is not sent under some conditions -# + message is not sent unless client authentication -# is desired -# -# Figure 1: Message flow in a full TLS handshake -# -# Figure 1 shows all messages involved in the TLS key establishment -# protocol (aka full handshake). The addition of ECC has direct impact -# only on the ClientHello, the ServerHello, the server's Certificate -# message, the ServerKeyExchange, the ClientKeyExchange, the -# CertificateRequest, the client's Certificate message, and the -# CertificateVerify. Next, we describe each ECC key exchange algorithm -# in greater detail in terms of the content and processing of these -# messages. For ease of exposition, we defer discussion of client -# authentication and associated messages (identified with a + in -# Figure 1) until Section 3 and of the optional ECC-specific extensions -# (which impact the Hello messages) until Section 4. +# This document introduces five new ECC-based key exchange algorithms +# for TLS. All of them use ECDH to compute the TLS premaster secret, +# and they differ only in the lifetime of ECDH keys (long-term or +# ephemeral) and the mechanism (if any) used to authenticate them. The +# derivation of the TLS master secret from the premaster secret and the +# subsequent generation of bulk encryption/MAC keys and initialization +# vectors is independent of the key exchange algorithm and not impacted +# by the introduction of ECC. +# +# The table below summarizes the new key exchange algorithms, which +# mimic DH_DSS, DHE_DSS, DH_RSA, DHE_RSA, and DH_anon (see [2] and +# [3]), respectively. +# +# Key +# Exchange +# Algorithm Description +# --------- ----------- +# +# ECDH_ECDSA Fixed ECDH with ECDSA-signed certificates. +# +# ECDHE_ECDSA Ephemeral ECDH with ECDSA signatures. +# +# ECDH_RSA Fixed ECDH with RSA-signed certificates. +# +# ECDHE_RSA Ephemeral ECDH with RSA signatures. +# +# ECDH_anon Anonymous ECDH, no signatures. +# +# Table 2: ECC Key Exchange Algorithms +# +# The ECDHE_ECDSA and ECDHE_RSA key exchange mechanisms provide forward +# secrecy. With ECDHE_RSA, a server can reuse its existing RSA +# certificate and easily comply with a constrained client's elliptic +# curve preferences (see Section 4). However, the computational cost +# +# incurred by a server is higher for ECDHE_RSA than for the traditional +# RSA key exchange, which does not provide forward secrecy. +# +# The ECDH_RSA mechanism requires a server to acquire an ECC +# certificate, but the certificate issuer can still use an existing RSA +# key for signing. This eliminates the need to update the keys of +# trusted certification authorities accepted by TLS clients. The +# ECDH_ECDSA mechanism requires ECC keys for the server as well as the +# certification authority and is best suited for constrained devices +# unable to support RSA. +# +# The anonymous key exchange algorithm does not provide authentication +# of the server or the client. Like other anonymous TLS key exchanges, +# it is subject to man-in-the-middle attacks. Implementations of this +# algorithm SHOULD provide authentication by other means. +# +# Note that there is no structural difference between ECDH and ECDSA +# keys. A certificate issuer may use X.509 v3 keyUsage and +# extendedKeyUsage extensions to restrict the use of an ECC public key +# to certain computations [15]. This document refers to an ECC key as +# ECDH-capable if its use in ECDH is permitted. ECDSA-capable is +# defined similarly. +# +# Client Server +# ------ ------ +# +# ClientHello --------> +# ServerHello +# Certificate* +# ServerKeyExchange* +# CertificateRequest*+ +# <-------- ServerHelloDone +# Certificate*+ +# ClientKeyExchange +# CertificateVerify*+ +# [ChangeCipherSpec] +# Finished --------> +# [ChangeCipherSpec] +# <-------- Finished +# +# Application Data <-------> Application Data +# +# * message is not sent under some conditions +# + message is not sent unless client authentication +# is desired +# +# Figure 1: Message flow in a full TLS handshake +# +# Figure 1 shows all messages involved in the TLS key establishment +# protocol (aka full handshake). The addition of ECC has direct impact +# only on the ClientHello, the ServerHello, the server's Certificate +# message, the ServerKeyExchange, the ClientKeyExchange, the +# CertificateRequest, the client's Certificate message, and the +# CertificateVerify. Next, we describe each ECC key exchange algorithm +# in greater detail in terms of the content and processing of these +# messages. For ease of exposition, we defer discussion of client +# authentication and associated messages (identified with a + in +# Figure 1) until Section 3 and of the optional ECC-specific extensions +# (which impact the Hello messages) until Section 4. [[spec]] level = "SHOULD" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc4492/section-3.1.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc4492/section-3.1.toml index f83beb92e22..e3d0ce55c50 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc4492/section-3.1.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc4492/section-3.1.toml @@ -1,14 +1,14 @@ target = "https://www.rfc-editor.org/rfc/rfc4492#section-3.1" -# 3.1. ECDSA_sign +# ECDSA_sign # -# To use this authentication mechanism, the client MUST possess a -# certificate containing an ECDSA-capable public key and signed with -# ECDSA. +# To use this authentication mechanism, the client MUST possess a +# certificate containing an ECDSA-capable public key and signed with +# ECDSA. # -# The client proves possession of the private key corresponding to the -# certified key by including a signature in the CertificateVerify -# message as described in Section 5.8. +# The client proves possession of the private key corresponding to the +# certified key by including a signature in the CertificateVerify +# message as described in Section 5.8. [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc4492/section-3.2.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc4492/section-3.2.toml index 471623ef71e..cbd008ad918 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc4492/section-3.2.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc4492/section-3.2.toml @@ -1,27 +1,27 @@ target = "https://www.rfc-editor.org/rfc/rfc4492#section-3.2" -# 3.2. ECDSA_fixed_ECDH +# ECDSA_fixed_ECDH # -# To use this authentication mechanism, the client MUST possess a -# certificate containing an ECDH-capable public key, and that -# certificate MUST be signed with ECDSA. Furthermore, the client's -# ECDH key MUST be on the same elliptic curve as the server's long-term -# (certified) ECDH key. This might limit use of this mechanism to -# closed environments. In situations where the client has an ECC key -# on a different curve, it would have to authenticate using either -# ECDSA_sign or a non-ECC mechanism (e.g., RSA). Using fixed ECDH for -# both servers and clients is computationally more efficient than -# mechanisms providing forward secrecy. +# To use this authentication mechanism, the client MUST possess a +# certificate containing an ECDH-capable public key, and that +# certificate MUST be signed with ECDSA. Furthermore, the client's +# ECDH key MUST be on the same elliptic curve as the server's long-term +# (certified) ECDH key. This might limit use of this mechanism to +# closed environments. In situations where the client has an ECC key +# on a different curve, it would have to authenticate using either +# ECDSA_sign or a non-ECC mechanism (e.g., RSA). Using fixed ECDH for +# both servers and clients is computationally more efficient than +# mechanisms providing forward secrecy. # -# When using this authentication mechanism, the client MUST send an -# empty ClientKeyExchange as described in Section 5.7 and MUST NOT send -# the CertificateVerify message. The ClientKeyExchange is empty since -# the client's ECDH public key required by the server to compute the -# premaster secret is available inside the client's certificate. The -# client's ability to arrive at the same premaster secret as the server -# (demonstrated by a successful exchange of Finished messages) proves -# possession of the private key corresponding to the certified public -# key, and the CertificateVerify message is unnecessary. +# When using this authentication mechanism, the client MUST send an +# empty ClientKeyExchange as described in Section 5.7 and MUST NOT send +# the CertificateVerify message. The ClientKeyExchange is empty since +# the client's ECDH public key required by the server to compute the +# premaster secret is available inside the client's certificate. The +# client's ability to arrive at the same premaster secret as the server +# (demonstrated by a successful exchange of Finished messages) proves +# possession of the private key corresponding to the certified public +# key, and the CertificateVerify message is unnecessary. [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc4492/section-3.3.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc4492/section-3.3.toml index 471c0141ec8..bfb4ee1f3d8 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc4492/section-3.3.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc4492/section-3.3.toml @@ -1,21 +1,21 @@ target = "https://www.rfc-editor.org/rfc/rfc4492#section-3.3" -# 3.3. RSA_fixed_ECDH +# RSA_fixed_ECDH # -# This authentication mechanism is identical to ECDSA_fixed_ECDH except -# that the client's certificate MUST be signed with RSA. +# This authentication mechanism is identical to ECDSA_fixed_ECDH except +# that the client's certificate MUST be signed with RSA. # -# Note that while the ECDSA_sign, ECDSA_fixed_ECDH, and RSA_fixed_ECDH -# client authentication mechanisms require the client's certificate to -# be signed with a particular signature scheme, this specification does -# not impose restrictions on signature schemes used elsewhere in the -# certificate chain. (Often such restrictions will be useful, and it -# is expected that this will be taken into account in certification -# authorities' signing practices. However, such restrictions are not -# strictly required in general: Even if it is beyond the capabilities -# of a server to completely validate a given chain, the server may be -# able to validate the clients certificate by relying on a trust anchor -# that appears as one of the intermediate certificates in the chain.) +# Note that while the ECDSA_sign, ECDSA_fixed_ECDH, and RSA_fixed_ECDH +# client authentication mechanisms require the client's certificate to +# be signed with a particular signature scheme, this specification does +# not impose restrictions on signature schemes used elsewhere in the +# certificate chain. (Often such restrictions will be useful, and it +# is expected that this will be taken into account in certification +# authorities' signing practices. However, such restrictions are not +# strictly required in general: Even if it is beyond the capabilities +# of a server to completely validate a given chain, the server may be +# able to validate the clients certificate by relying on a trust anchor +# that appears as one of the intermediate certificates in the chain.) [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc4492/section-4.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc4492/section-4.toml index b309f3ab6b5..5c2aee9f097 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc4492/section-4.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc4492/section-4.toml @@ -1,45 +1,45 @@ target = "https://www.rfc-editor.org/rfc/rfc4492#section-4" -# 4. TLS Extensions for ECC +# TLS Extensions for ECC # -# Two new TLS extensions are defined in this specification: (i) the -# Supported Elliptic Curves Extension, and (ii) the Supported Point -# Formats Extension. These allow negotiating the use of specific -# curves and point formats (e.g., compressed vs. uncompressed, -# respectively) during a handshake starting a new session. These -# extensions are especially relevant for constrained clients that may +# Two new TLS extensions are defined in this specification: (i) the +# Supported Elliptic Curves Extension, and (ii) the Supported Point +# Formats Extension. These allow negotiating the use of specific +# curves and point formats (e.g., compressed vs. uncompressed, +# respectively) during a handshake starting a new session. These +# extensions are especially relevant for constrained clients that may # -# only support a limited number of curves or point formats. They -# follow the general approach outlined in [4]; message details are -# specified in Section 5. The client enumerates the curves it supports -# and the point formats it can parse by including the appropriate -# extensions in its ClientHello message. The server similarly -# enumerates the point formats it can parse by including an extension -# in its ServerHello message. +# only support a limited number of curves or point formats. They +# follow the general approach outlined in [4]; message details are +# specified in Section 5. The client enumerates the curves it supports +# and the point formats it can parse by including the appropriate +# extensions in its ClientHello message. The server similarly +# enumerates the point formats it can parse by including an extension +# in its ServerHello message. # -# A TLS client that proposes ECC cipher suites in its ClientHello -# message SHOULD include these extensions. Servers implementing ECC -# cipher suites MUST support these extensions, and when a client uses -# these extensions, servers MUST NOT negotiate the use of an ECC cipher -# suite unless they can complete the handshake while respecting the -# choice of curves and compression techniques specified by the client. -# This eliminates the possibility that a negotiated ECC handshake will -# be subsequently aborted due to a client's inability to deal with the -# server's EC key. +# A TLS client that proposes ECC cipher suites in its ClientHello +# message SHOULD include these extensions. Servers implementing ECC +# cipher suites MUST support these extensions, and when a client uses +# these extensions, servers MUST NOT negotiate the use of an ECC cipher +# suite unless they can complete the handshake while respecting the +# choice of curves and compression techniques specified by the client. +# This eliminates the possibility that a negotiated ECC handshake will +# be subsequently aborted due to a client's inability to deal with the +# server's EC key. # -# The client MUST NOT include these extensions in the ClientHello -# message if it does not propose any ECC cipher suites. A client that -# proposes ECC cipher suites may choose not to include these -# extensions. In this case, the server is free to choose any one of -# the elliptic curves or point formats listed in Section 5. That -# section also describes the structure and processing of these -# extensions in greater detail. +# The client MUST NOT include these extensions in the ClientHello +# message if it does not propose any ECC cipher suites. A client that +# proposes ECC cipher suites may choose not to include these +# extensions. In this case, the server is free to choose any one of +# the elliptic curves or point formats listed in Section 5. That +# section also describes the structure and processing of these +# extensions in greater detail. # -# In the case of session resumption, the server simply ignores the -# Supported Elliptic Curves Extension and the Supported Point Formats -# Extension appearing in the current ClientHello message. These -# extensions only play a role during handshakes negotiating a new -# session. +# In the case of session resumption, the server simply ignores the +# Supported Elliptic Curves Extension and the Supported Point Formats +# Extension appearing in the current ClientHello message. These +# extensions only play a role during handshakes negotiating a new +# session. [[spec]] level = "SHOULD" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc4492/section-5.1.2.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc4492/section-5.1.2.toml index 12a202197f3..7df7902db28 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc4492/section-5.1.2.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc4492/section-5.1.2.toml @@ -1,47 +1,47 @@ target = "https://www.rfc-editor.org/rfc/rfc4492#section-5.1.2" -# 5.1.2. Supported Point Formats Extension +# Supported Point Formats Extension # -# enum { uncompressed (0), ansiX962_compressed_prime (1), -# ansiX962_compressed_char2 (2), reserved (248..255) -# } ECPointFormat; -# -# struct { -# ECPointFormat ec_point_format_list<1..2^8-1> -# } ECPointFormatList; -# -# Three point formats are included in the definition of ECPointFormat -# above. The uncompressed point format is the default format in that -# implementations of this document MUST support it for all of their -# supported curves. Compressed point formats reduce bandwidth by -# including only the x-coordinate and a single bit of the y-coordinate -# of the point. Implementations of this document MAY support the -# ansiX962_compressed_prime and ansiX962_compressed_char2 formats, -# where the former applies only to prime curves and the latter applies -# only to characteristic-2 curves. (These formats are specified in -# [7].) Values 248 through 255 are reserved for private use. -# -# The ECPointFormat name space is maintained by IANA. See Section 8 -# for information on how new value assignments are added. -# -# Items in ec_point_format_list are ordered according to the client's -# preferences (favorite choice first). -# -# A client that can parse only the uncompressed point format (value 0) -# includes an extension consisting of the following octets; note that -# the first two octets indicate the extension type (Supported Point -# Formats Extension): -# -# 00 0B 00 02 01 00 -# -# A client that in the case of prime fields prefers the compressed -# format (ansiX962_compressed_prime, value 1) over the uncompressed -# format (value 0), but in the case of characteristic-2 fields prefers -# the uncompressed format (value 0) over the compressed format -# (ansiX962_compressed_char2, value 2), may indicate these preferences -# by including an extension consisting of the following octets: -# -# 00 0B 00 04 03 01 00 02 +# enum { uncompressed (0), ansiX962_compressed_prime (1), +# ansiX962_compressed_char2 (2), reserved (248..255) +# } ECPointFormat; +# +# struct { +# ECPointFormat ec_point_format_list<1..2^8-1> +# } ECPointFormatList; +# +# Three point formats are included in the definition of ECPointFormat +# above. The uncompressed point format is the default format in that +# implementations of this document MUST support it for all of their +# supported curves. Compressed point formats reduce bandwidth by +# including only the x-coordinate and a single bit of the y-coordinate +# of the point. Implementations of this document MAY support the +# ansiX962_compressed_prime and ansiX962_compressed_char2 formats, +# where the former applies only to prime curves and the latter applies +# only to characteristic-2 curves. (These formats are specified in +# [7].) Values 248 through 255 are reserved for private use. +# +# The ECPointFormat name space is maintained by IANA. See Section 8 +# for information on how new value assignments are added. +# +# Items in ec_point_format_list are ordered according to the client's +# preferences (favorite choice first). +# +# A client that can parse only the uncompressed point format (value 0) +# includes an extension consisting of the following octets; note that +# the first two octets indicate the extension type (Supported Point +# Formats Extension): +# +# 00 0B 00 02 01 00 +# +# A client that in the case of prime fields prefers the compressed +# format (ansiX962_compressed_prime, value 1) over the uncompressed +# format (value 0), but in the case of characteristic-2 fields prefers +# the uncompressed format (value 0) over the compressed format +# (ansiX962_compressed_char2, value 2), may indicate these preferences +# by including an extension consisting of the following octets: +# +# 00 0B 00 04 03 01 00 02 [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc4492/section-5.1.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc4492/section-5.1.toml index eb7312f6d7c..e3e32eecf7b 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc4492/section-5.1.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc4492/section-5.1.toml @@ -1,70 +1,70 @@ target = "https://www.rfc-editor.org/rfc/rfc4492#section-5.1" -# 5.1. Client Hello Extensions +# Client Hello Extensions # -# This section specifies two TLS extensions that can be included with -# the ClientHello message as described in [4], the Supported Elliptic -# Curves Extension and the Supported Point Formats Extension. +# This section specifies two TLS extensions that can be included with +# the ClientHello message as described in [4], the Supported Elliptic +# Curves Extension and the Supported Point Formats Extension. # -# When these extensions are sent: +# When these extensions are sent: # -# The extensions SHOULD be sent along with any ClientHello message that -# proposes ECC cipher suites. +# The extensions SHOULD be sent along with any ClientHello message that +# proposes ECC cipher suites. # -# Meaning of these extensions: +# Meaning of these extensions: # -# These extensions allow a client to enumerate the elliptic curves it -# supports and/or the point formats it can parse. +# These extensions allow a client to enumerate the elliptic curves it +# supports and/or the point formats it can parse. # -# Structure of these extensions: +# Structure of these extensions: # -# The general structure of TLS extensions is described in [4], and this -# specification adds two new types to ExtensionType. +# The general structure of TLS extensions is described in [4], and this +# specification adds two new types to ExtensionType. # -# enum { elliptic_curves(10), ec_point_formats(11) } ExtensionType; +# enum { elliptic_curves(10), ec_point_formats(11) } ExtensionType; # -# elliptic_curves (Supported Elliptic Curves Extension): Indicates -# the set of elliptic curves supported by the client. For this -# extension, the opaque extension_data field contains -# EllipticCurveList. See Section 5.1.1 for details. +# elliptic_curves (Supported Elliptic Curves Extension): Indicates +# the set of elliptic curves supported by the client. For this +# extension, the opaque extension_data field contains +# EllipticCurveList. See Section 5.1.1 for details. # -# ec_point_formats (Supported Point Formats Extension): Indicates the -# set of point formats that the client can parse. For this -# extension, the opaque extension_data field contains -# ECPointFormatList. See Section 5.1.2 for details. +# ec_point_formats (Supported Point Formats Extension): Indicates the +# set of point formats that the client can parse. For this +# extension, the opaque extension_data field contains +# ECPointFormatList. See Section 5.1.2 for details. # -# Actions of the sender: +# Actions of the sender: # -# A client that proposes ECC cipher suites in its ClientHello message -# appends these extensions (along with any others), enumerating the -# curves it supports and the point formats it can parse. Clients -# SHOULD send both the Supported Elliptic Curves Extension and the -# Supported Point Formats Extension. If the Supported Point Formats -# Extension is indeed sent, it MUST contain the value 0 (uncompressed) -# as one of the items in the list of point formats. +# A client that proposes ECC cipher suites in its ClientHello message +# appends these extensions (along with any others), enumerating the +# curves it supports and the point formats it can parse. Clients +# SHOULD send both the Supported Elliptic Curves Extension and the +# Supported Point Formats Extension. If the Supported Point Formats +# Extension is indeed sent, it MUST contain the value 0 (uncompressed) +# as one of the items in the list of point formats. # -# Actions of the receiver: +# Actions of the receiver: # -# A server that receives a ClientHello containing one or both of these -# extensions MUST use the client's enumerated capabilities to guide its -# selection of an appropriate cipher suite. One of the proposed ECC -# cipher suites must be negotiated only if the server can successfully -# complete the handshake while using the curves and point formats -# supported by the client (cf. Sections 5.3 and 5.4). +# A server that receives a ClientHello containing one or both of these +# extensions MUST use the client's enumerated capabilities to guide its +# selection of an appropriate cipher suite. One of the proposed ECC +# cipher suites must be negotiated only if the server can successfully +# complete the handshake while using the curves and point formats +# supported by the client (cf. Sections 5.3 and 5.4). # -# NOTE: A server participating in an ECDHE-ECDSA key exchange may use -# different curves for (i) the ECDSA key in its certificate, and (ii) -# the ephemeral ECDH key in the ServerKeyExchange message. The server -# must consider the extensions in both cases. +# NOTE: A server participating in an ECDHE-ECDSA key exchange may use +# different curves for (i) the ECDSA key in its certificate, and (ii) +# the ephemeral ECDH key in the ServerKeyExchange message. The server +# must consider the extensions in both cases. # -# If a server does not understand the Supported Elliptic Curves -# Extension, does not understand the Supported Point Formats Extension, -# or is unable to complete the ECC handshake while restricting itself -# to the enumerated curves and point formats, it MUST NOT negotiate the -# use of an ECC cipher suite. Depending on what other cipher suites -# are proposed by the client and supported by the server, this may -# result in a fatal handshake failure alert due to the lack of common -# cipher suites. +# If a server does not understand the Supported Elliptic Curves +# Extension, does not understand the Supported Point Formats Extension, +# or is unable to complete the ECC handshake while restricting itself +# to the enumerated curves and point formats, it MUST NOT negotiate the +# use of an ECC cipher suite. Depending on what other cipher suites +# are proposed by the client and supported by the server, this may +# result in a fatal handshake failure alert due to the lack of common +# cipher suites. [[spec]] level = "SHOULD" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc4492/section-5.10.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc4492/section-5.10.toml index 6ed8cabdeba..fdf3939fdd5 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc4492/section-5.10.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc4492/section-5.10.toml @@ -1,42 +1,42 @@ target = "https://www.rfc-editor.org/rfc/rfc4492#section-5.10" -# 5.10. ECDH, ECDSA, and RSA Computations +# ECDH, ECDSA, and RSA Computations # -# All ECDH calculations (including parameter and key generation as well -# as the shared secret calculation) are performed according to [6] -# using the ECKAS-DH1 scheme with the identity map as key derivation -# function (KDF), so that the premaster secret is the x-coordinate of -# the ECDH shared secret elliptic curve point represented as an octet -# string. Note that this octet string (Z in IEEE 1363 terminology) as -# output by FE2OSP, the Field Element to Octet String Conversion -# Primitive, has constant length for any given field; leading zeros -# found in this octet string MUST NOT be truncated. +# All ECDH calculations (including parameter and key generation as well +# as the shared secret calculation) are performed according to [6] +# using the ECKAS-DH1 scheme with the identity map as key derivation +# function (KDF), so that the premaster secret is the x-coordinate of +# the ECDH shared secret elliptic curve point represented as an octet +# string. Note that this octet string (Z in IEEE 1363 terminology) as +# output by FE2OSP, the Field Element to Octet String Conversion +# Primitive, has constant length for any given field; leading zeros +# found in this octet string MUST NOT be truncated. # -# (Note that this use of the identity KDF is a technicality. The -# complete picture is that ECDH is employed with a non-trivial KDF -# because TLS does not directly use the premaster secret for anything -# other than for computing the master secret. As of TLS 1.0 [2] and -# 1.1 [3], this means that the MD5- and SHA-1-based TLS PRF serves as a -# KDF; it is conceivable that future TLS versions or new TLS extensions -# introduced in the future may vary this computation.) +# (Note that this use of the identity KDF is a technicality. The +# complete picture is that ECDH is employed with a non-trivial KDF +# because TLS does not directly use the premaster secret for anything +# other than for computing the master secret. As of TLS 1.0 [2] and +# 1.1 [3], this means that the MD5- and SHA-1-based TLS PRF serves as a +# KDF; it is conceivable that future TLS versions or new TLS extensions +# introduced in the future may vary this computation.) # -# All ECDSA computations MUST be performed according to ANSI X9.62 [7] -# or its successors. Data to be signed/verified is hashed, and the -# result run directly through the ECDSA algorithm with no additional -# hashing. The default hash function is SHA-1 [10], and sha_size (see -# Sections 5.4 and 5.8) is 20. However, an alternative hash function, -# such as one of the new SHA hash functions specified in FIPS 180-2 -# [10], may be used instead if the certificate containing the EC public +# All ECDSA computations MUST be performed according to ANSI X9.62 [7] +# or its successors. Data to be signed/verified is hashed, and the +# result run directly through the ECDSA algorithm with no additional +# hashing. The default hash function is SHA-1 [10], and sha_size (see +# Sections 5.4 and 5.8) is 20. However, an alternative hash function, +# such as one of the new SHA hash functions specified in FIPS 180-2 +# [10], may be used instead if the certificate containing the EC public # -# key explicitly requires use of another hash function. (The mechanism -# for specifying the required hash function has not been standardized, -# but this provision anticipates such standardization and obviates the -# need to update this document in response. Future PKIX RFCs may -# choose, for example, to specify the hash function to be used with a -# public key in the parameters field of subjectPublicKeyInfo.) +# key explicitly requires use of another hash function. (The mechanism +# for specifying the required hash function has not been standardized, +# but this provision anticipates such standardization and obviates the +# need to update this document in response. Future PKIX RFCs may +# choose, for example, to specify the hash function to be used with a +# public key in the parameters field of subjectPublicKeyInfo.) # -# All RSA signatures must be generated and verified according to PKCS#1 -# [12] block type 1. +# All RSA signatures must be generated and verified according to PKCS#1 +# [12] block type 1. [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc4492/section-5.2.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc4492/section-5.2.toml index 7088152af63..0357bac36dd 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc4492/section-5.2.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc4492/section-5.2.toml @@ -1,55 +1,55 @@ target = "https://www.rfc-editor.org/rfc/rfc4492#section-5.2" -# 5.2. Server Hello Extension +# Server Hello Extension # -# This section specifies a TLS extension that can be included with the -# ServerHello message as described in [4], the Supported Point Formats -# Extension. +# This section specifies a TLS extension that can be included with the +# ServerHello message as described in [4], the Supported Point Formats +# Extension. # -# When this extension is sent: +# When this extension is sent: # -# The Supported Point Formats Extension is included in a ServerHello -# message in response to a ClientHello message containing the Supported -# Point Formats Extension when negotiating an ECC cipher suite. +# The Supported Point Formats Extension is included in a ServerHello +# message in response to a ClientHello message containing the Supported +# Point Formats Extension when negotiating an ECC cipher suite. # -# Meaning of this extension: +# Meaning of this extension: # -# This extension allows a server to enumerate the point formats it can -# parse (for the curve that will appear in its ServerKeyExchange -# message when using the ECDHE_ECDSA, ECDHE_RSA, or ECDH_anon key -# exchange algorithm, or for the curve that is used in the server's -# public key that will appear in its Certificate message when using the -# ECDH_ECDSA or ECDH_RSA key exchange algorithm). +# This extension allows a server to enumerate the point formats it can +# parse (for the curve that will appear in its ServerKeyExchange +# message when using the ECDHE_ECDSA, ECDHE_RSA, or ECDH_anon key +# exchange algorithm, or for the curve that is used in the server's +# public key that will appear in its Certificate message when using the +# ECDH_ECDSA or ECDH_RSA key exchange algorithm). # -# Structure of this extension: +# Structure of this extension: # -# The server's Supported Point Formats Extension has the same structure -# as the client's Supported Point Formats Extension (see -# Section 5.1.2). Items in elliptic_curve_list here are ordered -# according to the server's preference (favorite choice first). Note -# that the server may include items that were not found in the client's -# list (e.g., the server may prefer to receive points in compressed -# format even when a client cannot parse this format: the same client -# may nevertheless be capable of outputting points in compressed -# format). +# The server's Supported Point Formats Extension has the same structure +# as the client's Supported Point Formats Extension (see +# Section 5.1.2). Items in elliptic_curve_list here are ordered +# according to the server's preference (favorite choice first). Note +# that the server may include items that were not found in the client's +# list (e.g., the server may prefer to receive points in compressed +# format even when a client cannot parse this format: the same client +# may nevertheless be capable of outputting points in compressed +# format). # -# Actions of the sender: +# Actions of the sender: # -# A server that selects an ECC cipher suite in response to a -# ClientHello message including a Supported Point Formats Extension -# appends this extension (along with others) to its ServerHello -# message, enumerating the point formats it can parse. The Supported -# Point Formats Extension, when used, MUST contain the value 0 -# (uncompressed) as one of the items in the list of point formats. +# A server that selects an ECC cipher suite in response to a +# ClientHello message including a Supported Point Formats Extension +# appends this extension (along with others) to its ServerHello +# message, enumerating the point formats it can parse. The Supported +# Point Formats Extension, when used, MUST contain the value 0 +# (uncompressed) as one of the items in the list of point formats. # -# Actions of the receiver: +# Actions of the receiver: # -# A client that receives a ServerHello message containing a Supported -# Point Formats Extension MUST respect the server's choice of point -# formats during the handshake (cf. Sections 5.6 and 5.7). If no -# Supported Point Formats Extension is received with the ServerHello, -# this is equivalent to an extension allowing only the uncompressed -# point format. +# A client that receives a ServerHello message containing a Supported +# Point Formats Extension MUST respect the server's choice of point +# formats during the handshake (cf. Sections 5.6 and 5.7). If no +# Supported Point Formats Extension is received with the ServerHello, +# this is equivalent to an extension allowing only the uncompressed +# point format. [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc4492/section-5.3.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc4492/section-5.3.toml index 0335723f964..91d716615eb 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc4492/section-5.3.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc4492/section-5.3.toml @@ -1,72 +1,72 @@ target = "https://www.rfc-editor.org/rfc/rfc4492#section-5.3" -# 5.3. Server Certificate +# Server Certificate # -# When this message is sent: +# When this message is sent: # -# This message is sent in all non-anonymous ECC-based key exchange -# algorithms. +# This message is sent in all non-anonymous ECC-based key exchange +# algorithms. # -# Meaning of this message: +# Meaning of this message: # -# This message is used to authentically convey the server's static -# public key to the client. The following table shows the server -# certificate type appropriate for each key exchange algorithm. ECC -# public keys MUST be encoded in certificates as described in -# Section 5.9. +# This message is used to authentically convey the server's static +# public key to the client. The following table shows the server +# certificate type appropriate for each key exchange algorithm. ECC +# public keys MUST be encoded in certificates as described in +# Section 5.9. # -# NOTE: The server's Certificate message is capable of carrying a chain -# of certificates. The restrictions mentioned in Table 3 apply only to -# the server's certificate (first in the chain). +# NOTE: The server's Certificate message is capable of carrying a chain +# of certificates. The restrictions mentioned in Table 3 apply only to +# the server's certificate (first in the chain). # -# Key Exchange Algorithm Server Certificate Type -# ---------------------- ----------------------- +# Key Exchange Algorithm Server Certificate Type +# ---------------------- ----------------------- # -# ECDH_ECDSA Certificate MUST contain an -# ECDH-capable public key. It -# MUST be signed with ECDSA. +# ECDH_ECDSA Certificate MUST contain an +# ECDH-capable public key. It +# MUST be signed with ECDSA. # -# ECDHE_ECDSA Certificate MUST contain an -# ECDSA-capable public key. It -# MUST be signed with ECDSA. +# ECDHE_ECDSA Certificate MUST contain an +# ECDSA-capable public key. It +# MUST be signed with ECDSA. # -# ECDH_RSA Certificate MUST contain an -# ECDH-capable public key. It -# MUST be signed with RSA. +# ECDH_RSA Certificate MUST contain an +# ECDH-capable public key. It +# MUST be signed with RSA. # -# ECDHE_RSA Certificate MUST contain an -# RSA public key authorized for -# use in digital signatures. It -# MUST be signed with RSA. +# ECDHE_RSA Certificate MUST contain an +# RSA public key authorized for +# use in digital signatures. It +# MUST be signed with RSA. # -# Table 3: Server Certificate Types +# Table 3: Server Certificate Types # -# Structure of this message: +# Structure of this message: # -# Identical to the TLS Certificate format. +# Identical to the TLS Certificate format. # -# Actions of the sender: +# Actions of the sender: # -# The server constructs an appropriate certificate chain and conveys it -# to the client in the Certificate message. If the client has used a -# Supported Elliptic Curves Extension, the public key in the server's -# certificate MUST respect the client's choice of elliptic curves; in -# particular, the public key MUST employ a named curve (not the same -# curve as an explicit curve) unless the client has indicated support -# for explicit curves of the appropriate type. If the client has used -# a Supported Point Formats Extension, both the server's public key -# point and (in the case of an explicit curve) the curve's base point -# MUST respect the client's choice of point formats. (A server that -# cannot satisfy these requirements MUST NOT choose an ECC cipher suite -# in its ServerHello message.) +# The server constructs an appropriate certificate chain and conveys it +# to the client in the Certificate message. If the client has used a +# Supported Elliptic Curves Extension, the public key in the server's +# certificate MUST respect the client's choice of elliptic curves; in +# particular, the public key MUST employ a named curve (not the same +# curve as an explicit curve) unless the client has indicated support +# for explicit curves of the appropriate type. If the client has used +# a Supported Point Formats Extension, both the server's public key +# point and (in the case of an explicit curve) the curve's base point +# MUST respect the client's choice of point formats. (A server that +# cannot satisfy these requirements MUST NOT choose an ECC cipher suite +# in its ServerHello message.) # -# Actions of the receiver: +# Actions of the receiver: # -# The client validates the certificate chain, extracts the server's -# public key, and checks that the key type is appropriate for the -# negotiated key exchange algorithm. (A possible reason for a fatal -# handshake failure is that the client's capabilities for handling -# elliptic curves and point formats are exceeded; cf. Section 5.1.) +# The client validates the certificate chain, extracts the server's +# public key, and checks that the key type is appropriate for the +# negotiated key exchange algorithm. (A possible reason for a fatal +# handshake failure is that the client's capabilities for handling +# elliptic curves and point formats are exceeded; cf. Section 5.1.) [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc4492/section-5.4.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc4492/section-5.4.toml index 689438eba3e..0328b2049d7 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc4492/section-5.4.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc4492/section-5.4.toml @@ -1,205 +1,205 @@ target = "https://www.rfc-editor.org/rfc/rfc4492#section-5.4" -# 5.4. Server Key Exchange +# Server Key Exchange # -# When this message is sent: +# When this message is sent: # -# This message is sent when using the ECDHE_ECDSA, ECDHE_RSA, and -# ECDH_anon key exchange algorithms. -# -# Meaning of this message: +# This message is sent when using the ECDHE_ECDSA, ECDHE_RSA, and +# ECDH_anon key exchange algorithms. +# +# Meaning of this message: # -# This message is used to convey the server's ephemeral ECDH public key -# (and the corresponding elliptic curve domain parameters) to the -# client. +# This message is used to convey the server's ephemeral ECDH public key +# (and the corresponding elliptic curve domain parameters) to the +# client. # -# Structure of this message: +# Structure of this message: # -# enum { explicit_prime (1), explicit_char2 (2), -# named_curve (3), reserved(248..255) } ECCurveType; +# enum { explicit_prime (1), explicit_char2 (2), +# named_curve (3), reserved(248..255) } ECCurveType; # -# explicit_prime: Indicates the elliptic curve domain parameters are -# conveyed verbosely, and the underlying finite field is a prime -# field. -# -# explicit_char2: Indicates the elliptic curve domain parameters are -# conveyed verbosely, and the underlying finite field is a -# characteristic-2 field. -# -# named_curve: Indicates that a named curve is used. This option -# SHOULD be used when applicable. +# explicit_prime: Indicates the elliptic curve domain parameters are +# conveyed verbosely, and the underlying finite field is a prime +# field. +# +# explicit_char2: Indicates the elliptic curve domain parameters are +# conveyed verbosely, and the underlying finite field is a +# characteristic-2 field. +# +# named_curve: Indicates that a named curve is used. This option +# SHOULD be used when applicable. # -# Values 248 through 255 are reserved for private use. -# -# The ECCurveType name space is maintained by IANA. See Section 8 for -# information on how new value assignments are added. +# Values 248 through 255 are reserved for private use. +# +# The ECCurveType name space is maintained by IANA. See Section 8 for +# information on how new value assignments are added. # -# struct { -# opaque a <1..2^8-1>; -# opaque b <1..2^8-1>; -# } ECCurve; +# struct { +# opaque a <1..2^8-1>; +# opaque b <1..2^8-1>; +# } ECCurve; # -# a, b: These parameters specify the coefficients of the elliptic -# curve. Each value contains the byte string representation of a -# field element following the conversion routine in Section 4.3.3 of -# ANSI X9.62 [7]. +# a, b: These parameters specify the coefficients of the elliptic +# curve. Each value contains the byte string representation of a +# field element following the conversion routine in Section 4.3.3 of +# ANSI X9.62 [7]. # -# struct { -# opaque point <1..2^8-1>; -# } ECPoint; +# struct { +# opaque point <1..2^8-1>; +# } ECPoint; # -# point: This is the byte string representation of an elliptic curve -# point following the conversion routine in Section 4.3.6 of ANSI -# X9.62 [7]. This byte string may represent an elliptic curve point -# in uncompressed or compressed format; it MUST conform to what the -# client has requested through a Supported Point Formats Extension -# if this extension was used. +# point: This is the byte string representation of an elliptic curve +# point following the conversion routine in Section 4.3.6 of ANSI +# X9.62 [7]. This byte string may represent an elliptic curve point +# in uncompressed or compressed format; it MUST conform to what the +# client has requested through a Supported Point Formats Extension +# if this extension was used. # -# enum { ec_basis_trinomial, ec_basis_pentanomial } ECBasisType; +# enum { ec_basis_trinomial, ec_basis_pentanomial } ECBasisType; # -# ec_basis_trinomial: Indicates representation of a characteristic-2 -# field using a trinomial basis. +# ec_basis_trinomial: Indicates representation of a characteristic-2 +# field using a trinomial basis. # -# ec_basis_pentanomial: Indicates representation of a -# characteristic-2 field using a pentanomial basis. +# ec_basis_pentanomial: Indicates representation of a +# characteristic-2 field using a pentanomial basis. # -# struct { -# ECCurveType curve_type; -# select (curve_type) { -# case explicit_prime: -# opaque prime_p <1..2^8-1>; -# ECCurve curve; -# ECPoint base; -# opaque order <1..2^8-1>; -# opaque cofactor <1..2^8-1>; -# case explicit_char2: -# uint16 m; -# ECBasisType basis; -# select (basis) { -# case ec_trinomial: -# opaque k <1..2^8-1>; -# case ec_pentanomial: -# opaque k1 <1..2^8-1>; -# opaque k2 <1..2^8-1>; -# opaque k3 <1..2^8-1>; -# }; -# ECCurve curve; -# ECPoint base; -# opaque order <1..2^8-1>; -# opaque cofactor <1..2^8-1>; -# -# case named_curve: -# NamedCurve namedcurve; -# }; -# } ECParameters; -# -# curve_type: This identifies the type of the elliptic curve domain -# parameters. -# -# prime_p: This is the odd prime defining the field Fp. -# -# curve: Specifies the coefficients a and b of the elliptic curve E. -# -# base: Specifies the base point G on the elliptic curve. -# -# order: Specifies the order n of the base point. -# -# cofactor: Specifies the cofactor h = #E(Fq)/n, where #E(Fq) -# represents the number of points on the elliptic curve E defined -# over the field Fq (either Fp or F2^m). -# -# m: This is the degree of the characteristic-2 field F2^m. -# -# k: The exponent k for the trinomial basis representation x^m + x^k -# +1. -# -# k1, k2, k3: The exponents for the pentanomial representation x^m + -# x^k3 + x^k2 + x^k1 + 1 (such that k3 > k2 > k1). -# -# namedcurve: Specifies a recommended set of elliptic curve domain -# parameters. All those values of NamedCurve are allowed that refer -# to a specific curve. Values of NamedCurve that indicate support -# for a class of explicitly defined curves are not allowed here -# (they are only permissible in the ClientHello extension); this -# applies to arbitrary_explicit_prime_curves(0xFF01) and -# arbitrary_explicit_char2_curves(0xFF02). -# -# struct { -# ECParameters curve_params; -# ECPoint public; -# } ServerECDHParams; -# -# curve_params: Specifies the elliptic curve domain parameters -# associated with the ECDH public key. -# -# public: The ephemeral ECDH public key. -# -# The ServerKeyExchange message is extended as follows. -# -# enum { ec_diffie_hellman } KeyExchangeAlgorithm; -# -# ec_diffie_hellman: Indicates the ServerKeyExchange message contains -# an ECDH public key. -# -# select (KeyExchangeAlgorithm) { -# case ec_diffie_hellman: -# ServerECDHParams params; -# Signature signed_params; -# } ServerKeyExchange; -# -# params: Specifies the ECDH public key and associated domain -# parameters. -# -# signed_params: A hash of the params, with the signature appropriate -# to that hash applied. The private key corresponding to the -# certified public key in the server's Certificate message is used -# for signing. -# -# enum { ecdsa } SignatureAlgorithm; -# -# select (SignatureAlgorithm) { -# case ecdsa: -# digitally-signed struct { -# opaque sha_hash[sha_size]; -# }; -# } Signature; -# -# ServerKeyExchange.signed_params.sha_hash -# SHA(ClientHello.random + ServerHello.random + -# ServerKeyExchange.params); -# -# NOTE: SignatureAlgorithm is "rsa" for the ECDHE_RSA key exchange -# algorithm and "anonymous" for ECDH_anon. These cases are defined in -# TLS [2][3]. SignatureAlgorithm is "ecdsa" for ECDHE_ECDSA. ECDSA -# signatures are generated and verified as described in Section 5.10, -# and SHA in the above template for sha_hash accordingly may denote a -# hash algorithm other than SHA-1. As per ANSI X9.62, an ECDSA -# signature consists of a pair of integers, r and s. The digitally- -# signed element is encoded as an opaque vector <0..2^16-1>, the -# contents of which are the DER encoding [9] corresponding to the -# following ASN.1 notation [8]. -# -# Ecdsa-Sig-Value ::= SEQUENCE { -# r INTEGER, -# s INTEGER -# } +# struct { +# ECCurveType curve_type; +# select (curve_type) { +# case explicit_prime: +# opaque prime_p <1..2^8-1>; +# ECCurve curve; +# ECPoint base; +# opaque order <1..2^8-1>; +# opaque cofactor <1..2^8-1>; +# case explicit_char2: +# uint16 m; +# ECBasisType basis; +# select (basis) { +# case ec_trinomial: +# opaque k <1..2^8-1>; +# case ec_pentanomial: +# opaque k1 <1..2^8-1>; +# opaque k2 <1..2^8-1>; +# opaque k3 <1..2^8-1>; +# }; +# ECCurve curve; +# ECPoint base; +# opaque order <1..2^8-1>; +# opaque cofactor <1..2^8-1>; +# +# case named_curve: +# NamedCurve namedcurve; +# }; +# } ECParameters; +# +# curve_type: This identifies the type of the elliptic curve domain +# parameters. +# +# prime_p: This is the odd prime defining the field Fp. +# +# curve: Specifies the coefficients a and b of the elliptic curve E. +# +# base: Specifies the base point G on the elliptic curve. +# +# order: Specifies the order n of the base point. +# +# cofactor: Specifies the cofactor h = #E(Fq)/n, where #E(Fq) +# represents the number of points on the elliptic curve E defined +# over the field Fq (either Fp or F2^m). +# +# m: This is the degree of the characteristic-2 field F2^m. +# +# k: The exponent k for the trinomial basis representation x^m + x^k +# +1. +# +# k1, k2, k3: The exponents for the pentanomial representation x^m + +# x^k3 + x^k2 + x^k1 + 1 (such that k3 > k2 > k1). +# +# namedcurve: Specifies a recommended set of elliptic curve domain +# parameters. All those values of NamedCurve are allowed that refer +# to a specific curve. Values of NamedCurve that indicate support +# for a class of explicitly defined curves are not allowed here +# (they are only permissible in the ClientHello extension); this +# applies to arbitrary_explicit_prime_curves(0xFF01) and +# arbitrary_explicit_char2_curves(0xFF02). +# +# struct { +# ECParameters curve_params; +# ECPoint public; +# } ServerECDHParams; +# +# curve_params: Specifies the elliptic curve domain parameters +# associated with the ECDH public key. +# +# public: The ephemeral ECDH public key. +# +# The ServerKeyExchange message is extended as follows. +# +# enum { ec_diffie_hellman } KeyExchangeAlgorithm; +# +# ec_diffie_hellman: Indicates the ServerKeyExchange message contains +# an ECDH public key. +# +# select (KeyExchangeAlgorithm) { +# case ec_diffie_hellman: +# ServerECDHParams params; +# Signature signed_params; +# } ServerKeyExchange; +# +# params: Specifies the ECDH public key and associated domain +# parameters. +# +# signed_params: A hash of the params, with the signature appropriate +# to that hash applied. The private key corresponding to the +# certified public key in the server's Certificate message is used +# for signing. +# +# enum { ecdsa } SignatureAlgorithm; +# +# select (SignatureAlgorithm) { +# case ecdsa: +# digitally-signed struct { +# opaque sha_hash[sha_size]; +# }; +# } Signature; +# +# ServerKeyExchange.signed_params.sha_hash +# SHA(ClientHello.random + ServerHello.random + +# ServerKeyExchange.params); +# +# NOTE: SignatureAlgorithm is "rsa" for the ECDHE_RSA key exchange +# algorithm and "anonymous" for ECDH_anon. These cases are defined in +# TLS [2][3]. SignatureAlgorithm is "ecdsa" for ECDHE_ECDSA. ECDSA +# signatures are generated and verified as described in Section 5.10, +# and SHA in the above template for sha_hash accordingly may denote a +# hash algorithm other than SHA-1. As per ANSI X9.62, an ECDSA +# signature consists of a pair of integers, r and s. The digitally- +# signed element is encoded as an opaque vector <0..2^16-1>, the +# contents of which are the DER encoding [9] corresponding to the +# following ASN.1 notation [8]. +# +# Ecdsa-Sig-Value ::= SEQUENCE { +# r INTEGER, +# s INTEGER +# } # -# Actions of the sender: +# Actions of the sender: # -# The server selects elliptic curve domain parameters and an ephemeral -# ECDH public key corresponding to these parameters according to the -# ECKAS-DH1 scheme from IEEE 1363 [6]. It conveys this information to -# the client in the ServerKeyExchange message using the format defined -# above. +# The server selects elliptic curve domain parameters and an ephemeral +# ECDH public key corresponding to these parameters according to the +# ECKAS-DH1 scheme from IEEE 1363 [6]. It conveys this information to +# the client in the ServerKeyExchange message using the format defined +# above. # -# Actions of the receiver: +# Actions of the receiver: # -# The client verifies the signature (when present) and retrieves the -# server's elliptic curve domain parameters and ephemeral ECDH public -# key from the ServerKeyExchange message. (A possible reason for a -# fatal handshake failure is that the client's capabilities for -# handling elliptic curves and point formats are exceeded; -# cf. Section 5.1.) +# The client verifies the signature (when present) and retrieves the +# server's elliptic curve domain parameters and ephemeral ECDH public +# key from the ServerKeyExchange message. (A possible reason for a +# fatal handshake failure is that the client's capabilities for +# handling elliptic curves and point formats are exceeded; +# cf. Section 5.1.) [[spec]] level = "SHOULD" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc4492/section-5.6.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc4492/section-5.6.toml index d66896c62ac..de06a993a64 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc4492/section-5.6.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc4492/section-5.6.toml @@ -1,68 +1,68 @@ target = "https://www.rfc-editor.org/rfc/rfc4492#section-5.6" -# 5.6. Client Certificate +# Client Certificate # -# When this message is sent: +# When this message is sent: # -# This message is sent in response to a CertificateRequest when a -# client has a suitable certificate and has decided to proceed with -# client authentication. (Note that if the server has used a Supported -# Point Formats Extension, a certificate can only be considered -# suitable for use with the ECDSA_sign, RSA_fixed_ECDH, and -# ECDSA_fixed_ECDH authentication methods if the public key point -# specified in it respects the server's choice of point formats. If no -# Supported Point Formats Extension has been used, a certificate can -# only be considered suitable for use with these authentication methods -# if the point is represented in uncompressed point format.) +# This message is sent in response to a CertificateRequest when a +# client has a suitable certificate and has decided to proceed with +# client authentication. (Note that if the server has used a Supported +# Point Formats Extension, a certificate can only be considered +# suitable for use with the ECDSA_sign, RSA_fixed_ECDH, and +# ECDSA_fixed_ECDH authentication methods if the public key point +# specified in it respects the server's choice of point formats. If no +# Supported Point Formats Extension has been used, a certificate can +# only be considered suitable for use with these authentication methods +# if the point is represented in uncompressed point format.) # -# Meaning of this message: +# Meaning of this message: # -# This message is used to authentically convey the client's static -# public key to the server. The following table summarizes what client -# certificate types are appropriate for the ECC-based client -# authentication mechanisms described in Section 3. ECC public keys -# must be encoded in certificates as described in Section 5.9. +# This message is used to authentically convey the client's static +# public key to the server. The following table summarizes what client +# certificate types are appropriate for the ECC-based client +# authentication mechanisms described in Section 3. ECC public keys +# must be encoded in certificates as described in Section 5.9. # -# NOTE: The client's Certificate message is capable of carrying a chain -# of certificates. The restrictions mentioned in Table 4 apply only to -# the client's certificate (first in the chain). +# NOTE: The client's Certificate message is capable of carrying a chain +# of certificates. The restrictions mentioned in Table 4 apply only to +# the client's certificate (first in the chain). # -# Client -# Authentication Method Client Certificate Type -# --------------------- ----------------------- +# Client +# Authentication Method Client Certificate Type +# --------------------- ----------------------- # -# ECDSA_sign Certificate MUST contain an -# ECDSA-capable public key and -# be signed with ECDSA. +# ECDSA_sign Certificate MUST contain an +# ECDSA-capable public key and +# be signed with ECDSA. # -# ECDSA_fixed_ECDH Certificate MUST contain an -# ECDH-capable public key on the -# same elliptic curve as the server's -# long-term ECDH key. This certificate -# MUST be signed with ECDSA. +# ECDSA_fixed_ECDH Certificate MUST contain an +# ECDH-capable public key on the +# same elliptic curve as the server's +# long-term ECDH key. This certificate +# MUST be signed with ECDSA. # -# RSA_fixed_ECDH Certificate MUST contain an -# ECDH-capable public key on the -# same elliptic curve as the server's -# long-term ECDH key. This certificate -# MUST be signed with RSA. +# RSA_fixed_ECDH Certificate MUST contain an +# ECDH-capable public key on the +# same elliptic curve as the server's +# long-term ECDH key. This certificate +# MUST be signed with RSA. # -# Table 4: Client Certificate Types +# Table 4: Client Certificate Types # -# Structure of this message: +# Structure of this message: # -# Identical to the TLS client Certificate format. +# Identical to the TLS client Certificate format. # -# Actions of the sender: +# Actions of the sender: # -# The client constructs an appropriate certificate chain, and conveys -# it to the server in the Certificate message. +# The client constructs an appropriate certificate chain, and conveys +# it to the server in the Certificate message. # -# Actions of the receiver: +# Actions of the receiver: # -# The TLS server validates the certificate chain, extracts the client's -# public key, and checks that the key type is appropriate for the -# client authentication method. +# The TLS server validates the certificate chain, extracts the client's +# public key, and checks that the key type is appropriate for the +# client authentication method. [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc4492/section-5.7.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc4492/section-5.7.toml index 6c29c4b5833..3c45b28d246 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc4492/section-5.7.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc4492/section-5.7.toml @@ -1,66 +1,66 @@ target = "https://www.rfc-editor.org/rfc/rfc4492#section-5.7" -# 5.7. Client Key Exchange +# Client Key Exchange # -# When this message is sent: +# When this message is sent: # -# This message is sent in all key exchange algorithms. If client -# authentication with ECDSA_fixed_ECDH or RSA_fixed_ECDH is used, this -# message is empty. Otherwise, it contains the client's ephemeral ECDH -# public key. +# This message is sent in all key exchange algorithms. If client +# authentication with ECDSA_fixed_ECDH or RSA_fixed_ECDH is used, this +# message is empty. Otherwise, it contains the client's ephemeral ECDH +# public key. # -# Meaning of the message: +# Meaning of the message: # -# This message is used to convey ephemeral data relating to the key -# exchange belonging to the client (such as its ephemeral ECDH public -# key). +# This message is used to convey ephemeral data relating to the key +# exchange belonging to the client (such as its ephemeral ECDH public +# key). # -# Structure of this message: +# Structure of this message: # -# The TLS ClientKeyExchange message is extended as follows. +# The TLS ClientKeyExchange message is extended as follows. # -# enum { implicit, explicit } PublicValueEncoding; +# enum { implicit, explicit } PublicValueEncoding; # -# implicit, explicit: For ECC cipher suites, this indicates whether -# the client's ECDH public key is in the client's certificate -# ("implicit") or is provided, as an ephemeral ECDH public key, in -# the ClientKeyExchange message ("explicit"). (This is "explicit" -# in ECC cipher suites except when the client uses the -# ECDSA_fixed_ECDH or RSA_fixed_ECDH client authentication -# mechanism.) +# implicit, explicit: For ECC cipher suites, this indicates whether +# the client's ECDH public key is in the client's certificate +# ("implicit") or is provided, as an ephemeral ECDH public key, in +# the ClientKeyExchange message ("explicit"). (This is "explicit" +# in ECC cipher suites except when the client uses the +# ECDSA_fixed_ECDH or RSA_fixed_ECDH client authentication +# mechanism.) # -# struct { -# select (PublicValueEncoding) { -# case implicit: struct { }; -# case explicit: ECPoint ecdh_Yc; -# } ecdh_public; -# } ClientECDiffieHellmanPublic; +# struct { +# select (PublicValueEncoding) { +# case implicit: struct { }; +# case explicit: ECPoint ecdh_Yc; +# } ecdh_public; +# } ClientECDiffieHellmanPublic; # -# ecdh_Yc: Contains the client's ephemeral ECDH public key as a byte -# string ECPoint.point, which may represent an elliptic curve point -# in uncompressed or compressed format. Here, the format MUST -# conform to what the server has requested through a Supported Point -# Formats Extension if this extension was used, and MUST be -# uncompressed if this extension was not used. +# ecdh_Yc: Contains the client's ephemeral ECDH public key as a byte +# string ECPoint.point, which may represent an elliptic curve point +# in uncompressed or compressed format. Here, the format MUST +# conform to what the server has requested through a Supported Point +# Formats Extension if this extension was used, and MUST be +# uncompressed if this extension was not used. # -# struct { -# select (KeyExchangeAlgorithm) { -# case ec_diffie_hellman: ClientECDiffieHellmanPublic; -# } exchange_keys; -# } ClientKeyExchange; +# struct { +# select (KeyExchangeAlgorithm) { +# case ec_diffie_hellman: ClientECDiffieHellmanPublic; +# } exchange_keys; +# } ClientKeyExchange; # -# Actions of the sender: +# Actions of the sender: # -# The client selects an ephemeral ECDH public key corresponding to the -# parameters it received from the server according to the ECKAS-DH1 -# scheme from IEEE 1363 [6]. It conveys this information to the client -# in the ClientKeyExchange message using the format defined above. +# The client selects an ephemeral ECDH public key corresponding to the +# parameters it received from the server according to the ECKAS-DH1 +# scheme from IEEE 1363 [6]. It conveys this information to the client +# in the ClientKeyExchange message using the format defined above. # -# Actions of the receiver: +# Actions of the receiver: # -# The server retrieves the client's ephemeral ECDH public key from the -# ClientKeyExchange message and checks that it is on the same elliptic -# curve as the server's ECDH key. +# The server retrieves the client's ephemeral ECDH public key from the +# ClientKeyExchange message and checks that it is on the same elliptic +# curve as the server's ECDH key. [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc4492/section-5.9.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc4492/section-5.9.toml index 864990b2367..8451a1d87f6 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc4492/section-5.9.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc4492/section-5.9.toml @@ -1,11 +1,11 @@ target = "https://www.rfc-editor.org/rfc/rfc4492#section-5.9" -# 5.9. Elliptic Curve Certificates +# Elliptic Curve Certificates # -# X.509 certificates containing ECC public keys or signed using ECDSA -# MUST comply with [14] or another RFC that replaces or extends it. -# Clients SHOULD use the elliptic curve domain parameters recommended -# in ANSI X9.62 [7], FIPS 186-2 [11], and SEC 2 [13]. +# X.509 certificates containing ECC public keys or signed using ECDSA +# MUST comply with [14] or another RFC that replaces or extends it. +# Clients SHOULD use the elliptic curve domain parameters recommended +# in ANSI X9.62 [7], FIPS 186-2 [11], and SEC 2 [13]. [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc4492/section-6.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc4492/section-6.toml index b4b2bc09b55..ae9bc190ed0 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc4492/section-6.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc4492/section-6.toml @@ -1,53 +1,53 @@ target = "https://www.rfc-editor.org/rfc/rfc4492#section-6" -# 6. Cipher Suites +# Cipher Suites # -# The table below defines new ECC cipher suites that use the key -# exchange algorithms specified in Section 2. +# The table below defines new ECC cipher suites that use the key +# exchange algorithms specified in Section 2. # -# CipherSuite TLS_ECDH_ECDSA_WITH_NULL_SHA = { 0xC0, 0x01 } -# CipherSuite TLS_ECDH_ECDSA_WITH_RC4_128_SHA = { 0xC0, 0x02 } -# CipherSuite TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA = { 0xC0, 0x03 } -# CipherSuite TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA = { 0xC0, 0x04 } -# CipherSuite TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA = { 0xC0, 0x05 } +# CipherSuite TLS_ECDH_ECDSA_WITH_NULL_SHA = { 0xC0, 0x01 } +# CipherSuite TLS_ECDH_ECDSA_WITH_RC4_128_SHA = { 0xC0, 0x02 } +# CipherSuite TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA = { 0xC0, 0x03 } +# CipherSuite TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA = { 0xC0, 0x04 } +# CipherSuite TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA = { 0xC0, 0x05 } # -# CipherSuite TLS_ECDHE_ECDSA_WITH_NULL_SHA = { 0xC0, 0x06 } -# CipherSuite TLS_ECDHE_ECDSA_WITH_RC4_128_SHA = { 0xC0, 0x07 } -# CipherSuite TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA = { 0xC0, 0x08 } -# CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA = { 0xC0, 0x09 } -# CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA = { 0xC0, 0x0A } +# CipherSuite TLS_ECDHE_ECDSA_WITH_NULL_SHA = { 0xC0, 0x06 } +# CipherSuite TLS_ECDHE_ECDSA_WITH_RC4_128_SHA = { 0xC0, 0x07 } +# CipherSuite TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA = { 0xC0, 0x08 } +# CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA = { 0xC0, 0x09 } +# CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA = { 0xC0, 0x0A } # -# CipherSuite TLS_ECDH_RSA_WITH_NULL_SHA = { 0xC0, 0x0B } -# CipherSuite TLS_ECDH_RSA_WITH_RC4_128_SHA = { 0xC0, 0x0C } -# CipherSuite TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA = { 0xC0, 0x0D } -# CipherSuite TLS_ECDH_RSA_WITH_AES_128_CBC_SHA = { 0xC0, 0x0E } -# CipherSuite TLS_ECDH_RSA_WITH_AES_256_CBC_SHA = { 0xC0, 0x0F } +# CipherSuite TLS_ECDH_RSA_WITH_NULL_SHA = { 0xC0, 0x0B } +# CipherSuite TLS_ECDH_RSA_WITH_RC4_128_SHA = { 0xC0, 0x0C } +# CipherSuite TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA = { 0xC0, 0x0D } +# CipherSuite TLS_ECDH_RSA_WITH_AES_128_CBC_SHA = { 0xC0, 0x0E } +# CipherSuite TLS_ECDH_RSA_WITH_AES_256_CBC_SHA = { 0xC0, 0x0F } # -# CipherSuite TLS_ECDHE_RSA_WITH_NULL_SHA = { 0xC0, 0x10 } -# CipherSuite TLS_ECDHE_RSA_WITH_RC4_128_SHA = { 0xC0, 0x11 } -# CipherSuite TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA = { 0xC0, 0x12 } -# CipherSuite TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA = { 0xC0, 0x13 } -# CipherSuite TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA = { 0xC0, 0x14 } +# CipherSuite TLS_ECDHE_RSA_WITH_NULL_SHA = { 0xC0, 0x10 } +# CipherSuite TLS_ECDHE_RSA_WITH_RC4_128_SHA = { 0xC0, 0x11 } +# CipherSuite TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA = { 0xC0, 0x12 } +# CipherSuite TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA = { 0xC0, 0x13 } +# CipherSuite TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA = { 0xC0, 0x14 } # -# CipherSuite TLS_ECDH_anon_WITH_NULL_SHA = { 0xC0, 0x15 } -# CipherSuite TLS_ECDH_anon_WITH_RC4_128_SHA = { 0xC0, 0x16 } -# CipherSuite TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA = { 0xC0, 0x17 } -# CipherSuite TLS_ECDH_anon_WITH_AES_128_CBC_SHA = { 0xC0, 0x18 } -# CipherSuite TLS_ECDH_anon_WITH_AES_256_CBC_SHA = { 0xC0, 0x19 } +# CipherSuite TLS_ECDH_anon_WITH_NULL_SHA = { 0xC0, 0x15 } +# CipherSuite TLS_ECDH_anon_WITH_RC4_128_SHA = { 0xC0, 0x16 } +# CipherSuite TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA = { 0xC0, 0x17 } +# CipherSuite TLS_ECDH_anon_WITH_AES_128_CBC_SHA = { 0xC0, 0x18 } +# CipherSuite TLS_ECDH_anon_WITH_AES_256_CBC_SHA = { 0xC0, 0x19 } # -# Table 5: TLS ECC cipher suites +# Table 5: TLS ECC cipher suites # -# The key exchange method, cipher, and hash algorithm for each of these -# cipher suites are easily determined by examining the name. Ciphers -# (other than AES ciphers) and hash algorithms are defined in [2] and -# [3]. AES ciphers are defined in [19]. +# The key exchange method, cipher, and hash algorithm for each of these +# cipher suites are easily determined by examining the name. Ciphers +# (other than AES ciphers) and hash algorithms are defined in [2] and +# [3]. AES ciphers are defined in [19]. # -# Server implementations SHOULD support all of the following cipher -# suites, and client implementations SHOULD support at least one of -# them: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA, -# TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, -# TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, and -# TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA. +# Server implementations SHOULD support all of the following cipher +# suites, and client implementations SHOULD support at least one of +# them: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA, +# TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, +# TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, and +# TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA. [[spec]] level = "SHOULD" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/appendix-A.5.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/appendix-A.5.toml index 6ed929b2341..f68e0068e8a 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/appendix-A.5.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/appendix-A.5.toml @@ -1,104 +1,104 @@ target = "https://www.rfc-editor.org/rfc/rfc5246#appendix-A.5" -# A.5. The Cipher Suite +# The Cipher Suite # -# The following values define the cipher suite codes used in the -# ClientHello and ServerHello messages. +# The following values define the cipher suite codes used in the +# ClientHello and ServerHello messages. # -# A cipher suite defines a cipher specification supported in TLS -# Version 1.2. +# A cipher suite defines a cipher specification supported in TLS +# Version 1.2. # -# TLS_NULL_WITH_NULL_NULL is specified and is the initial state of a -# TLS connection during the first handshake on that channel, but MUST -# NOT be negotiated, as it provides no more protection than an -# unsecured connection. +# TLS_NULL_WITH_NULL_NULL is specified and is the initial state of a +# TLS connection during the first handshake on that channel, but MUST +# NOT be negotiated, as it provides no more protection than an +# unsecured connection. # -# CipherSuite TLS_NULL_WITH_NULL_NULL = { 0x00,0x00 }; +# CipherSuite TLS_NULL_WITH_NULL_NULL = { 0x00,0x00 }; # -# The following CipherSuite definitions require that the server provide -# an RSA certificate that can be used for key exchange. The server may -# request any signature-capable certificate in the certificate request -# message. +# The following CipherSuite definitions require that the server provide +# an RSA certificate that can be used for key exchange. The server may +# request any signature-capable certificate in the certificate request +# message. # -# CipherSuite TLS_RSA_WITH_NULL_MD5 = { 0x00,0x01 }; -# CipherSuite TLS_RSA_WITH_NULL_SHA = { 0x00,0x02 }; -# CipherSuite TLS_RSA_WITH_NULL_SHA256 = { 0x00,0x3B }; -# CipherSuite TLS_RSA_WITH_RC4_128_MD5 = { 0x00,0x04 }; -# CipherSuite TLS_RSA_WITH_RC4_128_SHA = { 0x00,0x05 }; -# CipherSuite TLS_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0A }; -# CipherSuite TLS_RSA_WITH_AES_128_CBC_SHA = { 0x00,0x2F }; -# CipherSuite TLS_RSA_WITH_AES_256_CBC_SHA = { 0x00,0x35 }; -# CipherSuite TLS_RSA_WITH_AES_128_CBC_SHA256 = { 0x00,0x3C }; -# CipherSuite TLS_RSA_WITH_AES_256_CBC_SHA256 = { 0x00,0x3D }; +# CipherSuite TLS_RSA_WITH_NULL_MD5 = { 0x00,0x01 }; +# CipherSuite TLS_RSA_WITH_NULL_SHA = { 0x00,0x02 }; +# CipherSuite TLS_RSA_WITH_NULL_SHA256 = { 0x00,0x3B }; +# CipherSuite TLS_RSA_WITH_RC4_128_MD5 = { 0x00,0x04 }; +# CipherSuite TLS_RSA_WITH_RC4_128_SHA = { 0x00,0x05 }; +# CipherSuite TLS_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0A }; +# CipherSuite TLS_RSA_WITH_AES_128_CBC_SHA = { 0x00,0x2F }; +# CipherSuite TLS_RSA_WITH_AES_256_CBC_SHA = { 0x00,0x35 }; +# CipherSuite TLS_RSA_WITH_AES_128_CBC_SHA256 = { 0x00,0x3C }; +# CipherSuite TLS_RSA_WITH_AES_256_CBC_SHA256 = { 0x00,0x3D }; # -# The following cipher suite definitions are used for server- -# authenticated (and optionally client-authenticated) Diffie-Hellman. -# DH denotes cipher suites in which the server's certificate contains -# the Diffie-Hellman parameters signed by the certificate authority -# (CA). DHE denotes ephemeral Diffie-Hellman, where the Diffie-Hellman -# parameters are signed by a signature-capable certificate, which has -# been signed by the CA. The signing algorithm used by the server is -# specified after the DHE component of the CipherSuite name. The -# server can request any signature-capable certificate from the client -# for client authentication, or it may request a Diffie-Hellman -# certificate. Any Diffie-Hellman certificate provided by the client -# must use the parameters (group and generator) described by the -# server. +# The following cipher suite definitions are used for server- +# authenticated (and optionally client-authenticated) Diffie-Hellman. +# DH denotes cipher suites in which the server's certificate contains +# the Diffie-Hellman parameters signed by the certificate authority +# (CA). DHE denotes ephemeral Diffie-Hellman, where the Diffie-Hellman +# parameters are signed by a signature-capable certificate, which has +# been signed by the CA. The signing algorithm used by the server is +# specified after the DHE component of the CipherSuite name. The +# server can request any signature-capable certificate from the client +# for client authentication, or it may request a Diffie-Hellman +# certificate. Any Diffie-Hellman certificate provided by the client +# must use the parameters (group and generator) described by the +# server. # -# CipherSuite TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0D }; -# CipherSuite TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x10 }; -# CipherSuite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x13 }; -# CipherSuite TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x16 }; -# CipherSuite TLS_DH_DSS_WITH_AES_128_CBC_SHA = { 0x00,0x30 }; -# CipherSuite TLS_DH_RSA_WITH_AES_128_CBC_SHA = { 0x00,0x31 }; -# CipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA = { 0x00,0x32 }; -# CipherSuite TLS_DHE_RSA_WITH_AES_128_CBC_SHA = { 0x00,0x33 }; -# CipherSuite TLS_DH_DSS_WITH_AES_256_CBC_SHA = { 0x00,0x36 }; -# CipherSuite TLS_DH_RSA_WITH_AES_256_CBC_SHA = { 0x00,0x37 }; -# CipherSuite TLS_DHE_DSS_WITH_AES_256_CBC_SHA = { 0x00,0x38 }; -# CipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA = { 0x00,0x39 }; -# CipherSuite TLS_DH_DSS_WITH_AES_128_CBC_SHA256 = { 0x00,0x3E }; -# CipherSuite TLS_DH_RSA_WITH_AES_128_CBC_SHA256 = { 0x00,0x3F }; -# CipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 = { 0x00,0x40 }; -# CipherSuite TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 = { 0x00,0x67 }; -# CipherSuite TLS_DH_DSS_WITH_AES_256_CBC_SHA256 = { 0x00,0x68 }; -# CipherSuite TLS_DH_RSA_WITH_AES_256_CBC_SHA256 = { 0x00,0x69 }; -# CipherSuite TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 = { 0x00,0x6A }; -# CipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 = { 0x00,0x6B }; +# CipherSuite TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0D }; +# CipherSuite TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x10 }; +# CipherSuite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x13 }; +# CipherSuite TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x16 }; +# CipherSuite TLS_DH_DSS_WITH_AES_128_CBC_SHA = { 0x00,0x30 }; +# CipherSuite TLS_DH_RSA_WITH_AES_128_CBC_SHA = { 0x00,0x31 }; +# CipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA = { 0x00,0x32 }; +# CipherSuite TLS_DHE_RSA_WITH_AES_128_CBC_SHA = { 0x00,0x33 }; +# CipherSuite TLS_DH_DSS_WITH_AES_256_CBC_SHA = { 0x00,0x36 }; +# CipherSuite TLS_DH_RSA_WITH_AES_256_CBC_SHA = { 0x00,0x37 }; +# CipherSuite TLS_DHE_DSS_WITH_AES_256_CBC_SHA = { 0x00,0x38 }; +# CipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA = { 0x00,0x39 }; +# CipherSuite TLS_DH_DSS_WITH_AES_128_CBC_SHA256 = { 0x00,0x3E }; +# CipherSuite TLS_DH_RSA_WITH_AES_128_CBC_SHA256 = { 0x00,0x3F }; +# CipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 = { 0x00,0x40 }; +# CipherSuite TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 = { 0x00,0x67 }; +# CipherSuite TLS_DH_DSS_WITH_AES_256_CBC_SHA256 = { 0x00,0x68 }; +# CipherSuite TLS_DH_RSA_WITH_AES_256_CBC_SHA256 = { 0x00,0x69 }; +# CipherSuite TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 = { 0x00,0x6A }; +# CipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 = { 0x00,0x6B }; # -# The following cipher suites are used for completely anonymous -# Diffie-Hellman communications in which neither party is -# authenticated. Note that this mode is vulnerable to man-in-the- -# middle attacks. Using this mode therefore is of limited use: These -# cipher suites MUST NOT be used by TLS 1.2 implementations unless the -# application layer has specifically requested to allow anonymous key -# exchange. (Anonymous key exchange may sometimes be acceptable, for -# example, to support opportunistic encryption when no set-up for -# authentication is in place, or when TLS is used as part of more -# complex security protocols that have other means to ensure -# authentication.) +# The following cipher suites are used for completely anonymous +# Diffie-Hellman communications in which neither party is +# authenticated. Note that this mode is vulnerable to man-in-the- +# middle attacks. Using this mode therefore is of limited use: These +# cipher suites MUST NOT be used by TLS 1.2 implementations unless the +# application layer has specifically requested to allow anonymous key +# exchange. (Anonymous key exchange may sometimes be acceptable, for +# example, to support opportunistic encryption when no set-up for +# authentication is in place, or when TLS is used as part of more +# complex security protocols that have other means to ensure +# authentication.) # -# CipherSuite TLS_DH_anon_WITH_RC4_128_MD5 = { 0x00,0x18 }; -# CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00,0x1B }; -# CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA = { 0x00,0x34 }; -# CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA = { 0x00,0x3A }; -# CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA256 = { 0x00,0x6C }; -# CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA256 = { 0x00,0x6D }; +# CipherSuite TLS_DH_anon_WITH_RC4_128_MD5 = { 0x00,0x18 }; +# CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00,0x1B }; +# CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA = { 0x00,0x34 }; +# CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA = { 0x00,0x3A }; +# CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA256 = { 0x00,0x6C }; +# CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA256 = { 0x00,0x6D }; # -# Note that using non-anonymous key exchange without actually verifying -# the key exchange is essentially equivalent to anonymous key exchange, -# and the same precautions apply. While non-anonymous key exchange -# will generally involve a higher computational and communicational -# cost than anonymous key exchange, it may be in the interest of -# interoperability not to disable non-anonymous key exchange when the -# application layer is allowing anonymous key exchange. +# Note that using non-anonymous key exchange without actually verifying +# the key exchange is essentially equivalent to anonymous key exchange, +# and the same precautions apply. While non-anonymous key exchange +# will generally involve a higher computational and communicational +# cost than anonymous key exchange, it may be in the interest of +# interoperability not to disable non-anonymous key exchange when the +# application layer is allowing anonymous key exchange. # -# New cipher suite values have been assigned by IANA as described in -# Section 12. +# New cipher suite values have been assigned by IANA as described in +# Section 12. # -# Note: The cipher suite values { 0x00, 0x1C } and { 0x00, 0x1D } are -# reserved to avoid collision with Fortezza-based cipher suites in -# SSL 3. +# Note: The cipher suite values { 0x00, 0x1C } and { 0x00, 0x1D } are +# reserved to avoid collision with Fortezza-based cipher suites in +# SSL 3. [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/appendix-E.1.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/appendix-E.1.toml index 086e40a50f8..703119996d8 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/appendix-E.1.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/appendix-E.1.toml @@ -1,72 +1,72 @@ target = "https://www.rfc-editor.org/rfc/rfc5246#appendix-E.1" -# E.1. Compatibility with TLS 1.0/1.1 and SSL 3.0 +# Compatibility with TLS 1.0/1.1 and SSL 3.0 # -# Since there are various versions of TLS (1.0, 1.1, 1.2, and any -# future versions) and SSL (2.0 and 3.0), means are needed to negotiate -# the specific protocol version to use. The TLS protocol provides a -# built-in mechanism for version negotiation so as not to bother other -# protocol components with the complexities of version selection. +# Since there are various versions of TLS (1.0, 1.1, 1.2, and any +# future versions) and SSL (2.0 and 3.0), means are needed to negotiate +# the specific protocol version to use. The TLS protocol provides a +# built-in mechanism for version negotiation so as not to bother other +# protocol components with the complexities of version selection. # -# TLS versions 1.0, 1.1, and 1.2, and SSL 3.0 are very similar, and use -# compatible ClientHello messages; thus, supporting all of them is -# relatively easy. Similarly, servers can easily handle clients trying -# to use future versions of TLS as long as the ClientHello format -# remains compatible, and the client supports the highest protocol -# version available in the server. +# TLS versions 1.0, 1.1, and 1.2, and SSL 3.0 are very similar, and use +# compatible ClientHello messages; thus, supporting all of them is +# relatively easy. Similarly, servers can easily handle clients trying +# to use future versions of TLS as long as the ClientHello format +# remains compatible, and the client supports the highest protocol +# version available in the server. # -# A TLS 1.2 client who wishes to negotiate with such older servers will -# send a normal TLS 1.2 ClientHello, containing { 3, 3 } (TLS 1.2) in -# ClientHello.client_version. If the server does not support this -# version, it will respond with a ServerHello containing an older -# version number. If the client agrees to use this version, the -# negotiation will proceed as appropriate for the negotiated protocol. +# A TLS 1.2 client who wishes to negotiate with such older servers will +# send a normal TLS 1.2 ClientHello, containing { 3, 3 } (TLS 1.2) in +# ClientHello.client_version. If the server does not support this +# version, it will respond with a ServerHello containing an older +# version number. If the client agrees to use this version, the +# negotiation will proceed as appropriate for the negotiated protocol. # -# If the version chosen by the server is not supported by the client -# (or not acceptable), the client MUST send a "protocol_version" alert -# message and close the connection. +# If the version chosen by the server is not supported by the client +# (or not acceptable), the client MUST send a "protocol_version" alert +# message and close the connection. # -# If a TLS server receives a ClientHello containing a version number -# greater than the highest version supported by the server, it MUST -# reply according to the highest version supported by the server. +# If a TLS server receives a ClientHello containing a version number +# greater than the highest version supported by the server, it MUST +# reply according to the highest version supported by the server. # -# A TLS server can also receive a ClientHello containing a version -# number smaller than the highest supported version. If the server -# wishes to negotiate with old clients, it will proceed as appropriate +# A TLS server can also receive a ClientHello containing a version +# number smaller than the highest supported version. If the server +# wishes to negotiate with old clients, it will proceed as appropriate # -# for the highest version supported by the server that is not greater -# than ClientHello.client_version. For example, if the server supports -# TLS 1.0, 1.1, and 1.2, and client_version is TLS 1.0, the server will -# proceed with a TLS 1.0 ServerHello. If server supports (or is -# willing to use) only versions greater than client_version, it MUST -# send a "protocol_version" alert message and close the connection. +# for the highest version supported by the server that is not greater +# than ClientHello.client_version. For example, if the server supports +# TLS 1.0, 1.1, and 1.2, and client_version is TLS 1.0, the server will +# proceed with a TLS 1.0 ServerHello. If server supports (or is +# willing to use) only versions greater than client_version, it MUST +# send a "protocol_version" alert message and close the connection. # -# Whenever a client already knows the highest protocol version known to -# a server (for example, when resuming a session), it SHOULD initiate -# the connection in that native protocol. +# Whenever a client already knows the highest protocol version known to +# a server (for example, when resuming a session), it SHOULD initiate +# the connection in that native protocol. # -# Note: some server implementations are known to implement version -# negotiation incorrectly. For example, there are buggy TLS 1.0 -# servers that simply close the connection when the client offers a -# version newer than TLS 1.0. Also, it is known that some servers will -# refuse the connection if any TLS extensions are included in -# ClientHello. Interoperability with such buggy servers is a complex -# topic beyond the scope of this document, and may require multiple -# connection attempts by the client. +# Note: some server implementations are known to implement version +# negotiation incorrectly. For example, there are buggy TLS 1.0 +# servers that simply close the connection when the client offers a +# version newer than TLS 1.0. Also, it is known that some servers will +# refuse the connection if any TLS extensions are included in +# ClientHello. Interoperability with such buggy servers is a complex +# topic beyond the scope of this document, and may require multiple +# connection attempts by the client. # -# Earlier versions of the TLS specification were not fully clear on -# what the record layer version number (TLSPlaintext.version) should -# contain when sending ClientHello (i.e., before it is known which -# version of the protocol will be employed). Thus, TLS servers -# compliant with this specification MUST accept any value {03,XX} as -# the record layer version number for ClientHello. +# Earlier versions of the TLS specification were not fully clear on +# what the record layer version number (TLSPlaintext.version) should +# contain when sending ClientHello (i.e., before it is known which +# version of the protocol will be employed). Thus, TLS servers +# compliant with this specification MUST accept any value {03,XX} as +# the record layer version number for ClientHello. # -# TLS clients that wish to negotiate with older servers MAY send any -# value {03,XX} as the record layer version number. Typical values -# would be {03,00}, the lowest version number supported by the client, -# and the value of ClientHello.client_version. No single value will -# guarantee interoperability with all old servers, but this is a -# complex topic beyond the scope of this document. +# TLS clients that wish to negotiate with older servers MAY send any +# value {03,XX} as the record layer version number. Typical values +# would be {03,00}, the lowest version number supported by the client, +# and the value of ClientHello.client_version. No single value will +# guarantee interoperability with all old servers, but this is a +# complex topic beyond the scope of this document. [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/appendix-E.2.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/appendix-E.2.toml index 1411df8f639..1bf0b8fb5ee 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/appendix-E.2.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/appendix-E.2.toml @@ -1,86 +1,86 @@ target = "https://www.rfc-editor.org/rfc/rfc5246#appendix-E.2" -# E.2. Compatibility with SSL 2.0 +# Compatibility with SSL 2.0 # -# TLS 1.2 clients that wish to support SSL 2.0 servers MUST send -# version 2.0 CLIENT-HELLO messages defined in [SSL2]. The message -# MUST contain the same version number as would be used for ordinary -# ClientHello, and MUST encode the supported TLS cipher suites in the -# CIPHER-SPECS-DATA field as described below. +# TLS 1.2 clients that wish to support SSL 2.0 servers MUST send +# version 2.0 CLIENT-HELLO messages defined in [SSL2]. The message +# MUST contain the same version number as would be used for ordinary +# ClientHello, and MUST encode the supported TLS cipher suites in the +# CIPHER-SPECS-DATA field as described below. # -# Warning: The ability to send version 2.0 CLIENT-HELLO messages will -# be phased out with all due haste, since the newer ClientHello format -# provides better mechanisms for moving to newer versions and -# negotiating extensions. TLS 1.2 clients SHOULD NOT support SSL 2.0. +# Warning: The ability to send version 2.0 CLIENT-HELLO messages will +# be phased out with all due haste, since the newer ClientHello format +# provides better mechanisms for moving to newer versions and +# negotiating extensions. TLS 1.2 clients SHOULD NOT support SSL 2.0. # -# However, even TLS servers that do not support SSL 2.0 MAY accept -# version 2.0 CLIENT-HELLO messages. The message is presented below in -# sufficient detail for TLS server implementors; the true definition is -# still assumed to be [SSL2]. +# However, even TLS servers that do not support SSL 2.0 MAY accept +# version 2.0 CLIENT-HELLO messages. The message is presented below in +# sufficient detail for TLS server implementors; the true definition is +# still assumed to be [SSL2]. # -# For negotiation purposes, 2.0 CLIENT-HELLO is interpreted the same -# way as a ClientHello with a "null" compression method and no -# extensions. Note that this message MUST be sent directly on the -# wire, not wrapped as a TLS record. For the purposes of calculating -# Finished and CertificateVerify, the msg_length field is not -# considered to be a part of the handshake message. +# For negotiation purposes, 2.0 CLIENT-HELLO is interpreted the same +# way as a ClientHello with a "null" compression method and no +# extensions. Note that this message MUST be sent directly on the +# wire, not wrapped as a TLS record. For the purposes of calculating +# Finished and CertificateVerify, the msg_length field is not +# considered to be a part of the handshake message. # -# uint8 V2CipherSpec[3]; -# struct { -# uint16 msg_length; -# uint8 msg_type; -# Version version; -# uint16 cipher_spec_length; -# uint16 session_id_length; -# uint16 challenge_length; -# V2CipherSpec cipher_specs[V2ClientHello.cipher_spec_length]; -# opaque session_id[V2ClientHello.session_id_length]; -# opaque challenge[V2ClientHello.challenge_length; -# } V2ClientHello; +# uint8 V2CipherSpec[3]; +# struct { +# uint16 msg_length; +# uint8 msg_type; +# Version version; +# uint16 cipher_spec_length; +# uint16 session_id_length; +# uint16 challenge_length; +# V2CipherSpec cipher_specs[V2ClientHello.cipher_spec_length]; +# opaque session_id[V2ClientHello.session_id_length]; +# opaque challenge[V2ClientHello.challenge_length; +# } V2ClientHello; # -# msg_length -# The highest bit MUST be 1; the remaining bits contain the length -# of the following data in bytes. +# msg_length +# The highest bit MUST be 1; the remaining bits contain the length +# of the following data in bytes. # -# msg_type -# This field, in conjunction with the version field, identifies a -# version 2 ClientHello message. The value MUST be 1. +# msg_type +# This field, in conjunction with the version field, identifies a +# version 2 ClientHello message. The value MUST be 1. # -# version -# Equal to ClientHello.client_version. +# version +# Equal to ClientHello.client_version. # -# cipher_spec_length -# This field is the total length of the field cipher_specs. It -# cannot be zero and MUST be a multiple of the V2CipherSpec length -# (3). +# cipher_spec_length +# This field is the total length of the field cipher_specs. It +# cannot be zero and MUST be a multiple of the V2CipherSpec length +# (3). # -# session_id_length -# This field MUST have a value of zero for a client that claims to -# support TLS 1.2. +# session_id_length +# This field MUST have a value of zero for a client that claims to +# support TLS 1.2. # -# challenge_length -# The length in bytes of the client's challenge to the server to -# authenticate itself. Historically, permissible values are between -# 16 and 32 bytes inclusive. When using the SSLv2 backward- -# compatible handshake the client SHOULD use a 32-byte challenge. +# challenge_length +# The length in bytes of the client's challenge to the server to +# authenticate itself. Historically, permissible values are between +# 16 and 32 bytes inclusive. When using the SSLv2 backward- +# compatible handshake the client SHOULD use a 32-byte challenge. # -# cipher_specs -# This is a list of all CipherSpecs the client is willing and able -# to use. In addition to the 2.0 cipher specs defined in [SSL2], -# this includes the TLS cipher suites normally sent in -# ClientHello.cipher_suites, with each cipher suite prefixed by a -# zero byte. For example, the TLS cipher suite {0x00,0x0A} would be -# sent as {0x00,0x00,0x0A}. +# cipher_specs +# This is a list of all CipherSpecs the client is willing and able +# to use. In addition to the 2.0 cipher specs defined in [SSL2], +# this includes the TLS cipher suites normally sent in +# ClientHello.cipher_suites, with each cipher suite prefixed by a +# zero byte. For example, the TLS cipher suite {0x00,0x0A} would be +# sent as {0x00,0x00,0x0A}. # -# session_id -# This field MUST be empty. +# session_id +# This field MUST be empty. # -# challenge -# Corresponds to ClientHello.random. If the challenge length is -# less than 32, the TLS server will pad the data with leading (note: -# not trailing) zero bytes to make it 32 bytes long. +# challenge +# Corresponds to ClientHello.random. If the challenge length is +# less than 32, the TLS server will pad the data with leading (note: +# not trailing) zero bytes to make it 32 bytes long. # -# Note: Requests to resume a TLS session MUST use a TLS client hello. +# Note: Requests to resume a TLS session MUST use a TLS client hello. [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/appendix-E.3.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/appendix-E.3.toml index c3bc90ca2ff..776e5ba6c32 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/appendix-E.3.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/appendix-E.3.toml @@ -1,24 +1,24 @@ target = "https://www.rfc-editor.org/rfc/rfc5246#appendix-E.3" -# E.3. Avoiding Man-in-the-Middle Version Rollback +# Avoiding Man-in-the-Middle Version Rollback # -# When TLS clients fall back to Version 2.0 compatibility mode, they -# MUST use special PKCS#1 block formatting. This is done so that TLS -# servers will reject Version 2.0 sessions with TLS-capable clients. +# When TLS clients fall back to Version 2.0 compatibility mode, they +# MUST use special PKCS#1 block formatting. This is done so that TLS +# servers will reject Version 2.0 sessions with TLS-capable clients. # -# When a client negotiates SSL 2.0 but also supports TLS, it MUST set -# the right-hand (least-significant) 8 random bytes of the PKCS padding -# (not including the terminal null of the padding) for the RSA -# encryption of the ENCRYPTED-KEY-DATA field of the CLIENT-MASTER-KEY -# to 0x03 (the other padding bytes are random). +# When a client negotiates SSL 2.0 but also supports TLS, it MUST set +# the right-hand (least-significant) 8 random bytes of the PKCS padding +# (not including the terminal null of the padding) for the RSA +# encryption of the ENCRYPTED-KEY-DATA field of the CLIENT-MASTER-KEY +# to 0x03 (the other padding bytes are random). # -# When a TLS-capable server negotiates SSL 2.0 it SHOULD, after -# decrypting the ENCRYPTED-KEY-DATA field, check that these 8 padding -# bytes are 0x03. If they are not, the server SHOULD generate a random -# value for SECRET-KEY-DATA, and continue the handshake (which will -# eventually fail since the keys will not match). Note that reporting -# the error situation to the client could make the server vulnerable to -# attacks described in [BLEI]. +# When a TLS-capable server negotiates SSL 2.0 it SHOULD, after +# decrypting the ENCRYPTED-KEY-DATA field, check that these 8 padding +# bytes are 0x03. If they are not, the server SHOULD generate a random +# value for SECRET-KEY-DATA, and continue the handshake (which will +# eventually fail since the keys will not match). Note that reporting +# the error situation to the client could make the server vulnerable to +# attacks described in [BLEI]. [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/appendix-F.1.1.3.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/appendix-F.1.1.3.toml index e7fddde1970..7ef3b636c98 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/appendix-F.1.1.3.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/appendix-F.1.1.3.toml @@ -1,54 +1,54 @@ target = "https://www.rfc-editor.org/rfc/rfc5246#appendix-F.1.1.3" -# F.1.1.3. Diffie-Hellman Key Exchange with Authentication +# Diffie-Hellman Key Exchange with Authentication # -# When Diffie-Hellman key exchange is used, the server can either -# supply a certificate containing fixed Diffie-Hellman parameters or -# use the server key exchange message to send a set of temporary -# Diffie-Hellman parameters signed with a DSA or RSA certificate. -# Temporary parameters are hashed with the hello.random values before -# signing to ensure that attackers do not replay old parameters. In -# either case, the client can verify the certificate or signature to -# ensure that the parameters belong to the server. +# When Diffie-Hellman key exchange is used, the server can either +# supply a certificate containing fixed Diffie-Hellman parameters or +# use the server key exchange message to send a set of temporary +# Diffie-Hellman parameters signed with a DSA or RSA certificate. +# Temporary parameters are hashed with the hello.random values before +# signing to ensure that attackers do not replay old parameters. In +# either case, the client can verify the certificate or signature to +# ensure that the parameters belong to the server. # -# If the client has a certificate containing fixed Diffie-Hellman -# parameters, its certificate contains the information required to -# complete the key exchange. Note that in this case the client and -# server will generate the same Diffie-Hellman result (i.e., +# If the client has a certificate containing fixed Diffie-Hellman +# parameters, its certificate contains the information required to +# complete the key exchange. Note that in this case the client and +# server will generate the same Diffie-Hellman result (i.e., # -# pre_master_secret) every time they communicate. To prevent the -# pre_master_secret from staying in memory any longer than necessary, -# it should be converted into the master_secret as soon as possible. -# Client Diffie-Hellman parameters must be compatible with those -# supplied by the server for the key exchange to work. +# pre_master_secret) every time they communicate. To prevent the +# pre_master_secret from staying in memory any longer than necessary, +# it should be converted into the master_secret as soon as possible. +# Client Diffie-Hellman parameters must be compatible with those +# supplied by the server for the key exchange to work. # -# If the client has a standard DSA or RSA certificate or is -# unauthenticated, it sends a set of temporary parameters to the server -# in the client key exchange message, then optionally uses a -# certificate verify message to authenticate itself. +# If the client has a standard DSA or RSA certificate or is +# unauthenticated, it sends a set of temporary parameters to the server +# in the client key exchange message, then optionally uses a +# certificate verify message to authenticate itself. # -# If the same DH keypair is to be used for multiple handshakes, either -# because the client or server has a certificate containing a fixed DH -# keypair or because the server is reusing DH keys, care must be taken -# to prevent small subgroup attacks. Implementations SHOULD follow the -# guidelines found in [SUBGROUP]. +# If the same DH keypair is to be used for multiple handshakes, either +# because the client or server has a certificate containing a fixed DH +# keypair or because the server is reusing DH keys, care must be taken +# to prevent small subgroup attacks. Implementations SHOULD follow the +# guidelines found in [SUBGROUP]. # -# Small subgroup attacks are most easily avoided by using one of the -# DHE cipher suites and generating a fresh DH private key (X) for each -# handshake. If a suitable base (such as 2) is chosen, g^X mod p can -# be computed very quickly; therefore, the performance cost is -# minimized. Additionally, using a fresh key for each handshake -# provides Perfect Forward Secrecy. Implementations SHOULD generate a -# new X for each handshake when using DHE cipher suites. +# Small subgroup attacks are most easily avoided by using one of the +# DHE cipher suites and generating a fresh DH private key (X) for each +# handshake. If a suitable base (such as 2) is chosen, g^X mod p can +# be computed very quickly; therefore, the performance cost is +# minimized. Additionally, using a fresh key for each handshake +# provides Perfect Forward Secrecy. Implementations SHOULD generate a +# new X for each handshake when using DHE cipher suites. # -# Because TLS allows the server to provide arbitrary DH groups, the -# client should verify that the DH group is of suitable size as defined -# by local policy. The client SHOULD also verify that the DH public -# exponent appears to be of adequate size. [KEYSIZ] provides a useful -# guide to the strength of various group sizes. The server MAY choose -# to assist the client by providing a known group, such as those -# defined in [IKEALG] or [MODP]. These can be verified by simple -# comparison. +# Because TLS allows the server to provide arbitrary DH groups, the +# client should verify that the DH group is of suitable size as defined +# by local policy. The client SHOULD also verify that the DH public +# exponent appears to be of adequate size. [KEYSIZ] provides a useful +# guide to the strength of various group sizes. The server MAY choose +# to assist the client by providing a known group, such as those +# defined in [IKEALG] or [MODP]. These can be verified by simple +# comparison. [[spec]] level = "SHOULD" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-1.2.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-1.2.toml index 3ff8dfe9cd3..f238a12bc41 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-1.2.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-1.2.toml @@ -1,62 +1,62 @@ target = "https://www.rfc-editor.org/rfc/rfc5246#section-1.2" -# 1.2. Major Differences from TLS 1.1 +# Major Differences from TLS 1.1 # -# This document is a revision of the TLS 1.1 [TLS1.1] protocol which -# contains improved flexibility, particularly for negotiation of -# cryptographic algorithms. The major changes are: +# This document is a revision of the TLS 1.1 [TLS1.1] protocol which +# contains improved flexibility, particularly for negotiation of +# cryptographic algorithms. The major changes are: # -# - The MD5/SHA-1 combination in the pseudorandom function (PRF) has -# been replaced with cipher-suite-specified PRFs. All cipher suites -# in this document use P_SHA256. +# - The MD5/SHA-1 combination in the pseudorandom function (PRF) has +# been replaced with cipher-suite-specified PRFs. All cipher suites +# in this document use P_SHA256. # -# - The MD5/SHA-1 combination in the digitally-signed element has been -# replaced with a single hash. Signed elements now include a field -# that explicitly specifies the hash algorithm used. +# - The MD5/SHA-1 combination in the digitally-signed element has been +# replaced with a single hash. Signed elements now include a field +# that explicitly specifies the hash algorithm used. # -# - Substantial cleanup to the client's and server's ability to -# specify which hash and signature algorithms they will accept. -# Note that this also relaxes some of the constraints on signature -# and hash algorithms from previous versions of TLS. +# - Substantial cleanup to the client's and server's ability to +# specify which hash and signature algorithms they will accept. +# Note that this also relaxes some of the constraints on signature +# and hash algorithms from previous versions of TLS. # -# - Addition of support for authenticated encryption with additional -# data modes. +# - Addition of support for authenticated encryption with additional +# data modes. # -# - TLS Extensions definition and AES Cipher Suites were merged in -# from external [TLSEXT] and [TLSAES]. +# - TLS Extensions definition and AES Cipher Suites were merged in +# from external [TLSEXT] and [TLSAES]. # -# - Tighter checking of EncryptedPreMasterSecret version numbers. +# - Tighter checking of EncryptedPreMasterSecret version numbers. # -# - Tightened up a number of requirements. +# - Tightened up a number of requirements. # -# - Verify_data length now depends on the cipher suite (default is -# still 12). +# - Verify_data length now depends on the cipher suite (default is +# still 12). # -# - Cleaned up description of Bleichenbacher/Klima attack defenses. +# - Cleaned up description of Bleichenbacher/Klima attack defenses. # -# - Alerts MUST now be sent in many cases. +# - Alerts MUST now be sent in many cases. # -# - After a certificate_request, if no certificates are available, -# clients now MUST send an empty certificate list. +# - After a certificate_request, if no certificates are available, +# clients now MUST send an empty certificate list. # -# - TLS_RSA_WITH_AES_128_CBC_SHA is now the mandatory to implement -# cipher suite. +# - TLS_RSA_WITH_AES_128_CBC_SHA is now the mandatory to implement +# cipher suite. # -# - Added HMAC-SHA256 cipher suites. +# - Added HMAC-SHA256 cipher suites. # -# - Removed IDEA and DES cipher suites. They are now deprecated and -# will be documented in a separate document. +# - Removed IDEA and DES cipher suites. They are now deprecated and +# will be documented in a separate document. # -# - Support for the SSLv2 backward-compatible hello is now a MAY, not -# a SHOULD, with sending it a SHOULD NOT. Support will probably -# become a SHOULD NOT in the future. +# - Support for the SSLv2 backward-compatible hello is now a MAY, not +# a SHOULD, with sending it a SHOULD NOT. Support will probably +# become a SHOULD NOT in the future. # -# - Added limited "fall-through" to the presentation language to allow -# multiple case arms to have the same encoding. +# - Added limited "fall-through" to the presentation language to allow +# multiple case arms to have the same encoding. # -# - Added an Implementation Pitfalls sections +# - Added an Implementation Pitfalls sections # -# - The usual clarifications and editorial work. +# - The usual clarifications and editorial work. [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-4.7.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-4.7.toml index 2813e9f628b..9e9d5454c40 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-4.7.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-4.7.toml @@ -1,102 +1,102 @@ target = "https://www.rfc-editor.org/rfc/rfc5246#section-4.7" -# 4.7. Cryptographic Attributes +# Cryptographic Attributes # -# The five cryptographic operations -- digital signing, stream cipher -# encryption, block cipher encryption, authenticated encryption with -# additional data (AEAD) encryption, and public key encryption -- are -# designated digitally-signed, stream-ciphered, block-ciphered, aead- -# ciphered, and public-key-encrypted, respectively. A field's -# cryptographic processing is specified by prepending an appropriate -# key word designation before the field's type specification. -# Cryptographic keys are implied by the current session state (see -# Section 6.1). -# -# A digitally-signed element is encoded as a struct DigitallySigned: -# -# struct { -# SignatureAndHashAlgorithm algorithm; -# opaque signature<0..2^16-1>; -# } DigitallySigned; -# -# The algorithm field specifies the algorithm used (see Section -# 7.4.1.4.1 for the definition of this field). Note that the -# introduction of the algorithm field is a change from previous -# versions. The signature is a digital signature using those -# algorithms over the contents of the element. The contents themselves -# do not appear on the wire but are simply calculated. The length of -# the signature is specified by the signing algorithm and key. -# -# In RSA signing, the opaque vector contains the signature generated -# using the RSASSA-PKCS1-v1_5 signature scheme defined in [PKCS1]. As -# discussed in [PKCS1], the DigestInfo MUST be DER-encoded [X680] -# [X690]. For hash algorithms without parameters (which includes -# SHA-1), the DigestInfo.AlgorithmIdentifier.parameters field MUST be -# NULL, but implementations MUST accept both without parameters and -# with NULL parameters. Note that earlier versions of TLS used a -# different RSA signature scheme that did not include a DigestInfo -# encoding. -# -# In DSA, the 20 bytes of the SHA-1 hash are run directly through the -# Digital Signing Algorithm with no additional hashing. This produces -# two values, r and s. The DSA signature is an opaque vector, as -# above, the contents of which are the DER encoding of: -# -# Dss-Sig-Value ::= SEQUENCE { -# r INTEGER, -# s INTEGER -# } -# -# Note: In current terminology, DSA refers to the Digital Signature -# Algorithm and DSS refers to the NIST standard. In the original SSL -# and TLS specs, "DSS" was used universally. This document uses "DSA" -# to refer to the algorithm, "DSS" to refer to the standard, and it -# uses "DSS" in the code point definitions for historical continuity. -# -# In stream cipher encryption, the plaintext is exclusive-ORed with an -# identical amount of output generated from a cryptographically secure -# keyed pseudorandom number generator. -# -# In block cipher encryption, every block of plaintext encrypts to a -# block of ciphertext. All block cipher encryption is done in CBC -# (Cipher Block Chaining) mode, and all items that are block-ciphered -# will be an exact multiple of the cipher block length. -# -# In AEAD encryption, the plaintext is simultaneously encrypted and -# integrity protected. The input may be of any length, and aead- -# ciphered output is generally larger than the input in order to -# accommodate the integrity check value. -# -# In public key encryption, a public key algorithm is used to encrypt -# data in such a way that it can be decrypted only with the matching -# private key. A public-key-encrypted element is encoded as an opaque -# vector <0..2^16-1>, where the length is specified by the encryption -# algorithm and key. -# -# RSA encryption is done using the RSAES-PKCS1-v1_5 encryption scheme -# defined in [PKCS1]. -# -# In the following example -# -# stream-ciphered struct { -# uint8 field1; -# uint8 field2; -# digitally-signed opaque { -# uint8 field3<0..255>; -# uint8 field4; -# }; -# } UserType; -# -# The contents of the inner struct (field3 and field4) are used as -# input for the signature/hash algorithm, and then the entire structure -# is encrypted with a stream cipher. The length of this structure, in -# bytes, would be equal to two bytes for field1 and field2, plus two -# bytes for the signature and hash algorithm, plus two bytes for the -# length of the signature, plus the length of the output of the signing -# -# algorithm. The length of the signature is known because the -# algorithm and key used for the signing are known prior to encoding or -# decoding this structure. +# The five cryptographic operations -- digital signing, stream cipher +# encryption, block cipher encryption, authenticated encryption with +# additional data (AEAD) encryption, and public key encryption -- are +# designated digitally-signed, stream-ciphered, block-ciphered, aead- +# ciphered, and public-key-encrypted, respectively. A field's +# cryptographic processing is specified by prepending an appropriate +# key word designation before the field's type specification. +# Cryptographic keys are implied by the current session state (see +# Section 6.1). +# +# A digitally-signed element is encoded as a struct DigitallySigned: +# +# struct { +# SignatureAndHashAlgorithm algorithm; +# opaque signature<0..2^16-1>; +# } DigitallySigned; +# +# The algorithm field specifies the algorithm used (see Section +# 7.4.1.4.1 for the definition of this field). Note that the +# introduction of the algorithm field is a change from previous +# versions. The signature is a digital signature using those +# algorithms over the contents of the element. The contents themselves +# do not appear on the wire but are simply calculated. The length of +# the signature is specified by the signing algorithm and key. +# +# In RSA signing, the opaque vector contains the signature generated +# using the RSASSA-PKCS1-v1_5 signature scheme defined in [PKCS1]. As +# discussed in [PKCS1], the DigestInfo MUST be DER-encoded [X680] +# [X690]. For hash algorithms without parameters (which includes +# SHA-1), the DigestInfo.AlgorithmIdentifier.parameters field MUST be +# NULL, but implementations MUST accept both without parameters and +# with NULL parameters. Note that earlier versions of TLS used a +# different RSA signature scheme that did not include a DigestInfo +# encoding. +# +# In DSA, the 20 bytes of the SHA-1 hash are run directly through the +# Digital Signing Algorithm with no additional hashing. This produces +# two values, r and s. The DSA signature is an opaque vector, as +# above, the contents of which are the DER encoding of: +# +# Dss-Sig-Value ::= SEQUENCE { +# r INTEGER, +# s INTEGER +# } +# +# Note: In current terminology, DSA refers to the Digital Signature +# Algorithm and DSS refers to the NIST standard. In the original SSL +# and TLS specs, "DSS" was used universally. This document uses "DSA" +# to refer to the algorithm, "DSS" to refer to the standard, and it +# uses "DSS" in the code point definitions for historical continuity. +# +# In stream cipher encryption, the plaintext is exclusive-ORed with an +# identical amount of output generated from a cryptographically secure +# keyed pseudorandom number generator. +# +# In block cipher encryption, every block of plaintext encrypts to a +# block of ciphertext. All block cipher encryption is done in CBC +# (Cipher Block Chaining) mode, and all items that are block-ciphered +# will be an exact multiple of the cipher block length. +# +# In AEAD encryption, the plaintext is simultaneously encrypted and +# integrity protected. The input may be of any length, and aead- +# ciphered output is generally larger than the input in order to +# accommodate the integrity check value. +# +# In public key encryption, a public key algorithm is used to encrypt +# data in such a way that it can be decrypted only with the matching +# private key. A public-key-encrypted element is encoded as an opaque +# vector <0..2^16-1>, where the length is specified by the encryption +# algorithm and key. +# +# RSA encryption is done using the RSAES-PKCS1-v1_5 encryption scheme +# defined in [PKCS1]. +# +# In the following example +# +# stream-ciphered struct { +# uint8 field1; +# uint8 field2; +# digitally-signed opaque { +# uint8 field3<0..255>; +# uint8 field4; +# }; +# } UserType; +# +# The contents of the inner struct (field3 and field4) are used as +# input for the signature/hash algorithm, and then the entire structure +# is encrypted with a stream cipher. The length of this structure, in +# bytes, would be equal to two bytes for field1 and field2, plus two +# bytes for the signature and hash algorithm, plus two bytes for the +# length of the signature, plus the length of the output of the signing +# +# algorithm. The length of the signature is known because the +# algorithm and key used for the signing are known prior to encoding or +# decoding this structure. [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-5.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-5.toml index 82884c425d0..7d225793fd2 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-5.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-5.toml @@ -1,57 +1,57 @@ target = "https://www.rfc-editor.org/rfc/rfc5246#section-5" -# 5. HMAC and the Pseudorandom Function +# HMAC and the Pseudorandom Function # -# The TLS record layer uses a keyed Message Authentication Code (MAC) -# to protect message integrity. The cipher suites defined in this -# document use a construction known as HMAC, described in [HMAC], which -# is based on a hash function. Other cipher suites MAY define their -# own MAC constructions, if needed. +# The TLS record layer uses a keyed Message Authentication Code (MAC) +# to protect message integrity. The cipher suites defined in this +# document use a construction known as HMAC, described in [HMAC], which +# is based on a hash function. Other cipher suites MAY define their +# own MAC constructions, if needed. # -# In addition, a construction is required to do expansion of secrets -# into blocks of data for the purposes of key generation or validation. -# This pseudorandom function (PRF) takes as input a secret, a seed, and -# an identifying label and produces an output of arbitrary length. +# In addition, a construction is required to do expansion of secrets +# into blocks of data for the purposes of key generation or validation. +# This pseudorandom function (PRF) takes as input a secret, a seed, and +# an identifying label and produces an output of arbitrary length. # -# In this section, we define one PRF, based on HMAC. This PRF with the -# SHA-256 hash function is used for all cipher suites defined in this -# document and in TLS documents published prior to this document when -# TLS 1.2 is negotiated. New cipher suites MUST explicitly specify a -# PRF and, in general, SHOULD use the TLS PRF with SHA-256 or a -# stronger standard hash function. +# In this section, we define one PRF, based on HMAC. This PRF with the +# SHA-256 hash function is used for all cipher suites defined in this +# document and in TLS documents published prior to this document when +# TLS 1.2 is negotiated. New cipher suites MUST explicitly specify a +# PRF and, in general, SHOULD use the TLS PRF with SHA-256 or a +# stronger standard hash function. # -# First, we define a data expansion function, P_hash(secret, data), -# that uses a single hash function to expand a secret and seed into an -# arbitrary quantity of output: +# First, we define a data expansion function, P_hash(secret, data), +# that uses a single hash function to expand a secret and seed into an +# arbitrary quantity of output: # -# P_hash(secret, seed) = HMAC_hash(secret, A(1) + seed) + -# HMAC_hash(secret, A(2) + seed) + -# HMAC_hash(secret, A(3) + seed) + ... +# P_hash(secret, seed) = HMAC_hash(secret, A(1) + seed) + +# HMAC_hash(secret, A(2) + seed) + +# HMAC_hash(secret, A(3) + seed) + ... # -# where + indicates concatenation. +# where + indicates concatenation. # -# A() is defined as: +# A() is defined as: # -# A(0) = seed -# A(i) = HMAC_hash(secret, A(i-1)) +# A(0) = seed +# A(i) = HMAC_hash(secret, A(i-1)) # -# P_hash can be iterated as many times as necessary to produce the -# required quantity of data. For example, if P_SHA256 is being used to -# create 80 bytes of data, it will have to be iterated three times -# (through A(3)), creating 96 bytes of output data; the last 16 bytes -# of the final iteration will then be discarded, leaving 80 bytes of -# output data. +# P_hash can be iterated as many times as necessary to produce the +# required quantity of data. For example, if P_SHA256 is being used to +# create 80 bytes of data, it will have to be iterated three times +# (through A(3)), creating 96 bytes of output data; the last 16 bytes +# of the final iteration will then be discarded, leaving 80 bytes of +# output data. # -# TLS's PRF is created by applying P_hash to the secret as: +# TLS's PRF is created by applying P_hash to the secret as: # -# PRF(secret, label, seed) = P_(secret, label + seed) +# PRF(secret, label, seed) = P_(secret, label + seed) # -# The label is an ASCII string. It should be included in the exact -# form it is given without a length byte or trailing null character. -# For example, the label "slithy toves" would be processed by hashing -# the following bytes: +# The label is an ASCII string. It should be included in the exact +# form it is given without a length byte or trailing null character. +# For example, the label "slithy toves" would be processed by hashing +# the following bytes: # -# 73 6C 69 74 68 79 20 74 6F 76 65 73 +# 73 6C 69 74 68 79 20 74 6F 76 65 73 [[spec]] level = "MAY" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-6.1.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-6.1.toml index 6c8ec146263..0c50cbc1062 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-6.1.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-6.1.toml @@ -1,141 +1,141 @@ target = "https://www.rfc-editor.org/rfc/rfc5246#section-6.1" -# 6.1. Connection States +# Connection States # -# A TLS connection state is the operating environment of the TLS Record -# Protocol. It specifies a compression algorithm, an encryption -# algorithm, and a MAC algorithm. In addition, the parameters for -# these algorithms are known: the MAC key and the bulk encryption keys -# for the connection in both the read and the write directions. -# Logically, there are always four connection states outstanding: the -# current read and write states, and the pending read and write states. -# All records are processed under the current read and write states. -# The security parameters for the pending states can be set by the TLS -# Handshake Protocol, and the ChangeCipherSpec can selectively make -# either of the pending states current, in which case the appropriate -# current state is disposed of and replaced with the pending state; the -# pending state is then reinitialized to an empty state. It is illegal -# to make a state that has not been initialized with security -# parameters a current state. The initial current state always -# specifies that no encryption, compression, or MAC will be used. -# -# The security parameters for a TLS Connection read and write state are -# set by providing the following values: -# -# connection end -# Whether this entity is considered the "client" or the "server" in -# this connection. -# -# PRF algorithm -# An algorithm used to generate keys from the master secret (see -# Sections 5 and 6.3). -# -# bulk encryption algorithm -# An algorithm to be used for bulk encryption. This specification -# includes the key size of this algorithm, whether it is a block, -# stream, or AEAD cipher, the block size of the cipher (if -# appropriate), and the lengths of explicit and implicit -# initialization vectors (or nonces). -# -# MAC algorithm -# An algorithm to be used for message authentication. This -# specification includes the size of the value returned by the MAC -# algorithm. -# -# compression algorithm -# An algorithm to be used for data compression. This specification -# must include all information the algorithm requires to do -# compression. -# -# master secret -# A 48-byte secret shared between the two peers in the connection. -# -# client random -# A 32-byte value provided by the client. -# -# server random -# A 32-byte value provided by the server. -# -# These parameters are defined in the presentation language as: -# -# enum { server, client } ConnectionEnd; -# -# enum { tls_prf_sha256 } PRFAlgorithm; -# -# enum { null, rc4, 3des, aes } -# BulkCipherAlgorithm; -# -# enum { stream, block, aead } CipherType; -# -# enum { null, hmac_md5, hmac_sha1, hmac_sha256, -# hmac_sha384, hmac_sha512} MACAlgorithm; -# -# enum { null(0), (255) } CompressionMethod; -# -# /* The algorithms specified in CompressionMethod, PRFAlgorithm, -# BulkCipherAlgorithm, and MACAlgorithm may be added to. */ -# -# struct { -# ConnectionEnd entity; -# PRFAlgorithm prf_algorithm; -# BulkCipherAlgorithm bulk_cipher_algorithm; -# CipherType cipher_type; -# uint8 enc_key_length; -# uint8 block_length; -# uint8 fixed_iv_length; -# uint8 record_iv_length; -# MACAlgorithm mac_algorithm; -# uint8 mac_length; -# uint8 mac_key_length; -# CompressionMethod compression_algorithm; -# opaque master_secret[48]; -# opaque client_random[32]; -# opaque server_random[32]; -# } SecurityParameters; -# -# The record layer will use the security parameters to generate the -# following six items (some of which are not required by all ciphers, -# and are thus empty): -# -# client write MAC key -# server write MAC key -# client write encryption key -# server write encryption key -# client write IV -# server write IV -# -# The client write parameters are used by the server when receiving and -# processing records and vice versa. The algorithm used for generating -# these items from the security parameters is described in Section 6.3. -# -# Once the security parameters have been set and the keys have been -# generated, the connection states can be instantiated by making them -# the current states. These current states MUST be updated for each -# record processed. Each connection state includes the following -# elements: -# -# compression state -# The current state of the compression algorithm. -# -# cipher state -# The current state of the encryption algorithm. This will consist -# of the scheduled key for that connection. For stream ciphers, -# this will also contain whatever state information is necessary to -# allow the stream to continue to encrypt or decrypt data. -# -# MAC key -# The MAC key for this connection, as generated above. -# -# sequence number -# Each connection state contains a sequence number, which is -# maintained separately for read and write states. The sequence -# number MUST be set to zero whenever a connection state is made the -# active state. Sequence numbers are of type uint64 and may not -# exceed 2^64-1. Sequence numbers do not wrap. If a TLS -# implementation would need to wrap a sequence number, it must -# renegotiate instead. A sequence number is incremented after each -# record: specifically, the first record transmitted under a -# particular connection state MUST use sequence number 0. +# A TLS connection state is the operating environment of the TLS Record +# Protocol. It specifies a compression algorithm, an encryption +# algorithm, and a MAC algorithm. In addition, the parameters for +# these algorithms are known: the MAC key and the bulk encryption keys +# for the connection in both the read and the write directions. +# Logically, there are always four connection states outstanding: the +# current read and write states, and the pending read and write states. +# All records are processed under the current read and write states. +# The security parameters for the pending states can be set by the TLS +# Handshake Protocol, and the ChangeCipherSpec can selectively make +# either of the pending states current, in which case the appropriate +# current state is disposed of and replaced with the pending state; the +# pending state is then reinitialized to an empty state. It is illegal +# to make a state that has not been initialized with security +# parameters a current state. The initial current state always +# specifies that no encryption, compression, or MAC will be used. +# +# The security parameters for a TLS Connection read and write state are +# set by providing the following values: +# +# connection end +# Whether this entity is considered the "client" or the "server" in +# this connection. +# +# PRF algorithm +# An algorithm used to generate keys from the master secret (see +# Sections 5 and 6.3). +# +# bulk encryption algorithm +# An algorithm to be used for bulk encryption. This specification +# includes the key size of this algorithm, whether it is a block, +# stream, or AEAD cipher, the block size of the cipher (if +# appropriate), and the lengths of explicit and implicit +# initialization vectors (or nonces). +# +# MAC algorithm +# An algorithm to be used for message authentication. This +# specification includes the size of the value returned by the MAC +# algorithm. +# +# compression algorithm +# An algorithm to be used for data compression. This specification +# must include all information the algorithm requires to do +# compression. +# +# master secret +# A 48-byte secret shared between the two peers in the connection. +# +# client random +# A 32-byte value provided by the client. +# +# server random +# A 32-byte value provided by the server. +# +# These parameters are defined in the presentation language as: +# +# enum { server, client } ConnectionEnd; +# +# enum { tls_prf_sha256 } PRFAlgorithm; +# +# enum { null, rc4, 3des, aes } +# BulkCipherAlgorithm; +# +# enum { stream, block, aead } CipherType; +# +# enum { null, hmac_md5, hmac_sha1, hmac_sha256, +# hmac_sha384, hmac_sha512} MACAlgorithm; +# +# enum { null(0), (255) } CompressionMethod; +# +# /* The algorithms specified in CompressionMethod, PRFAlgorithm, +# BulkCipherAlgorithm, and MACAlgorithm may be added to. */ +# +# struct { +# ConnectionEnd entity; +# PRFAlgorithm prf_algorithm; +# BulkCipherAlgorithm bulk_cipher_algorithm; +# CipherType cipher_type; +# uint8 enc_key_length; +# uint8 block_length; +# uint8 fixed_iv_length; +# uint8 record_iv_length; +# MACAlgorithm mac_algorithm; +# uint8 mac_length; +# uint8 mac_key_length; +# CompressionMethod compression_algorithm; +# opaque master_secret[48]; +# opaque client_random[32]; +# opaque server_random[32]; +# } SecurityParameters; +# +# The record layer will use the security parameters to generate the +# following six items (some of which are not required by all ciphers, +# and are thus empty): +# +# client write MAC key +# server write MAC key +# client write encryption key +# server write encryption key +# client write IV +# server write IV +# +# The client write parameters are used by the server when receiving and +# processing records and vice versa. The algorithm used for generating +# these items from the security parameters is described in Section 6.3. +# +# Once the security parameters have been set and the keys have been +# generated, the connection states can be instantiated by making them +# the current states. These current states MUST be updated for each +# record processed. Each connection state includes the following +# elements: +# +# compression state +# The current state of the compression algorithm. +# +# cipher state +# The current state of the encryption algorithm. This will consist +# of the scheduled key for that connection. For stream ciphers, +# this will also contain whatever state information is necessary to +# allow the stream to continue to encrypt or decrypt data. +# +# MAC key +# The MAC key for this connection, as generated above. +# +# sequence number +# Each connection state contains a sequence number, which is +# maintained separately for read and write states. The sequence +# number MUST be set to zero whenever a connection state is made the +# active state. Sequence numbers are of type uint64 and may not +# exceed 2^64-1. Sequence numbers do not wrap. If a TLS +# implementation would need to wrap a sequence number, it must +# renegotiate instead. A sequence number is incremented after each +# record: specifically, the first record transmitted under a +# particular connection state MUST use sequence number 0. [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-6.2.1.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-6.2.1.toml index 7a88e4489e6..60cadcb0602 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-6.2.1.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-6.2.1.toml @@ -1,65 +1,65 @@ target = "https://www.rfc-editor.org/rfc/rfc5246#section-6.2.1" -# 6.2.1. Fragmentation +# Fragmentation # -# The record layer fragments information blocks into TLSPlaintext -# records carrying data in chunks of 2^14 bytes or less. Client -# message boundaries are not preserved in the record layer (i.e., -# multiple client messages of the same ContentType MAY be coalesced -# into a single TLSPlaintext record, or a single message MAY be -# fragmented across several records). +# The record layer fragments information blocks into TLSPlaintext +# records carrying data in chunks of 2^14 bytes or less. Client +# message boundaries are not preserved in the record layer (i.e., +# multiple client messages of the same ContentType MAY be coalesced +# into a single TLSPlaintext record, or a single message MAY be +# fragmented across several records). # -# struct { -# uint8 major; -# uint8 minor; -# } ProtocolVersion; +# struct { +# uint8 major; +# uint8 minor; +# } ProtocolVersion; # -# enum { -# change_cipher_spec(20), alert(21), handshake(22), -# application_data(23), (255) -# } ContentType; +# enum { +# change_cipher_spec(20), alert(21), handshake(22), +# application_data(23), (255) +# } ContentType; # -# struct { -# ContentType type; -# ProtocolVersion version; -# uint16 length; -# opaque fragment[TLSPlaintext.length]; -# } TLSPlaintext; +# struct { +# ContentType type; +# ProtocolVersion version; +# uint16 length; +# opaque fragment[TLSPlaintext.length]; +# } TLSPlaintext; # -# type -# The higher-level protocol used to process the enclosed fragment. +# type +# The higher-level protocol used to process the enclosed fragment. # -# version -# The version of the protocol being employed. This document -# describes TLS Version 1.2, which uses the version { 3, 3 }. The -# version value 3.3 is historical, deriving from the use of {3, 1} -# for TLS 1.0. (See Appendix A.1.) Note that a client that -# supports multiple versions of TLS may not know what version will -# be employed before it receives the ServerHello. See Appendix E -# for discussion about what record layer version number should be -# employed for ClientHello. +# version +# The version of the protocol being employed. This document +# describes TLS Version 1.2, which uses the version { 3, 3 }. The +# version value 3.3 is historical, deriving from the use of {3, 1} +# for TLS 1.0. (See Appendix A.1.) Note that a client that +# supports multiple versions of TLS may not know what version will +# be employed before it receives the ServerHello. See Appendix E +# for discussion about what record layer version number should be +# employed for ClientHello. # -# length -# The length (in bytes) of the following TLSPlaintext.fragment. The -# length MUST NOT exceed 2^14. +# length +# The length (in bytes) of the following TLSPlaintext.fragment. The +# length MUST NOT exceed 2^14. # -# fragment -# The application data. This data is transparent and treated as an -# independent block to be dealt with by the higher-level protocol -# specified by the type field. +# fragment +# The application data. This data is transparent and treated as an +# independent block to be dealt with by the higher-level protocol +# specified by the type field. # -# Implementations MUST NOT send zero-length fragments of Handshake, -# Alert, or ChangeCipherSpec content types. Zero-length fragments of -# Application data MAY be sent as they are potentially useful as a -# traffic analysis countermeasure. +# Implementations MUST NOT send zero-length fragments of Handshake, +# Alert, or ChangeCipherSpec content types. Zero-length fragments of +# Application data MAY be sent as they are potentially useful as a +# traffic analysis countermeasure. # -# Note: Data of different TLS record layer content types MAY be -# interleaved. Application data is generally of lower precedence for -# transmission than other content types. However, records MUST be -# delivered to the network in the same order as they are protected by -# the record layer. Recipients MUST receive and process interleaved -# application layer traffic during handshakes subsequent to the first -# one on a connection. +# Note: Data of different TLS record layer content types MAY be +# interleaved. Application data is generally of lower precedence for +# transmission than other content types. However, records MUST be +# delivered to the network in the same order as they are protected by +# the record layer. Recipients MUST receive and process interleaved +# application layer traffic during handshakes subsequent to the first +# one on a connection. [[spec]] level = "MAY" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-6.2.2.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-6.2.2.toml index 4fa8e9f63da..0a85bcadf91 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-6.2.2.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-6.2.2.toml @@ -1,40 +1,40 @@ target = "https://www.rfc-editor.org/rfc/rfc5246#section-6.2.2" -# 6.2.2. Record Compression and Decompression +# Record Compression and Decompression # -# All records are compressed using the compression algorithm defined in -# the current session state. There is always an active compression -# algorithm; however, initially it is defined as -# CompressionMethod.null. The compression algorithm translates a -# TLSPlaintext structure into a TLSCompressed structure. Compression -# functions are initialized with default state information whenever a -# connection state is made active. [RFC3749] describes compression -# algorithms for TLS. +# All records are compressed using the compression algorithm defined in +# the current session state. There is always an active compression +# algorithm; however, initially it is defined as +# CompressionMethod.null. The compression algorithm translates a +# TLSPlaintext structure into a TLSCompressed structure. Compression +# functions are initialized with default state information whenever a +# connection state is made active. [RFC3749] describes compression +# algorithms for TLS. # -# Compression must be lossless and may not increase the content length -# by more than 1024 bytes. If the decompression function encounters a -# TLSCompressed.fragment that would decompress to a length in excess of -# 2^14 bytes, it MUST report a fatal decompression failure error. +# Compression must be lossless and may not increase the content length +# by more than 1024 bytes. If the decompression function encounters a +# TLSCompressed.fragment that would decompress to a length in excess of +# 2^14 bytes, it MUST report a fatal decompression failure error. # -# struct { -# ContentType type; /* same as TLSPlaintext.type */ -# ProtocolVersion version;/* same as TLSPlaintext.version */ -# uint16 length; -# opaque fragment[TLSCompressed.length]; -# } TLSCompressed; +# struct { +# ContentType type; /* same as TLSPlaintext.type */ +# ProtocolVersion version;/* same as TLSPlaintext.version */ +# uint16 length; +# opaque fragment[TLSCompressed.length]; +# } TLSCompressed; # -# length -# The length (in bytes) of the following TLSCompressed.fragment. -# The length MUST NOT exceed 2^14 + 1024. +# length +# The length (in bytes) of the following TLSCompressed.fragment. +# The length MUST NOT exceed 2^14 + 1024. # -# fragment -# The compressed form of TLSPlaintext.fragment. +# fragment +# The compressed form of TLSPlaintext.fragment. # -# Note: A CompressionMethod.null operation is an identity operation; -# no fields are altered. +# Note: A CompressionMethod.null operation is an identity operation; +# no fields are altered. # -# Implementation note: Decompression functions are responsible for -# ensuring that messages cannot cause internal buffer overflows. +# Implementation note: Decompression functions are responsible for +# ensuring that messages cannot cause internal buffer overflows. [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-6.2.3.2.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-6.2.3.2.toml index 72afb648cd7..02e02cbcdc1 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-6.2.3.2.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-6.2.3.2.toml @@ -1,86 +1,86 @@ target = "https://www.rfc-editor.org/rfc/rfc5246#section-6.2.3.2" -# 6.2.3.2. CBC Block Cipher +# CBC Block Cipher # -# For block ciphers (such as 3DES or AES), the encryption and MAC -# functions convert TLSCompressed.fragment structures to and from block -# TLSCiphertext.fragment structures. +# For block ciphers (such as 3DES or AES), the encryption and MAC +# functions convert TLSCompressed.fragment structures to and from block +# TLSCiphertext.fragment structures. # -# struct { -# opaque IV[SecurityParameters.record_iv_length]; -# block-ciphered struct { -# opaque content[TLSCompressed.length]; -# opaque MAC[SecurityParameters.mac_length]; -# uint8 padding[GenericBlockCipher.padding_length]; -# uint8 padding_length; -# }; -# } GenericBlockCipher; +# struct { +# opaque IV[SecurityParameters.record_iv_length]; +# block-ciphered struct { +# opaque content[TLSCompressed.length]; +# opaque MAC[SecurityParameters.mac_length]; +# uint8 padding[GenericBlockCipher.padding_length]; +# uint8 padding_length; +# }; +# } GenericBlockCipher; # -# The MAC is generated as described in Section 6.2.3.1. +# The MAC is generated as described in Section 6.2.3.1. # -# IV -# The Initialization Vector (IV) SHOULD be chosen at random, and -# MUST be unpredictable. Note that in versions of TLS prior to 1.1, -# there was no IV field, and the last ciphertext block of the -# previous record (the "CBC residue") was used as the IV. This was -# changed to prevent the attacks described in [CBCATT]. For block -# ciphers, the IV length is of length -# SecurityParameters.record_iv_length, which is equal to the -# SecurityParameters.block_size. +# IV +# The Initialization Vector (IV) SHOULD be chosen at random, and +# MUST be unpredictable. Note that in versions of TLS prior to 1.1, +# there was no IV field, and the last ciphertext block of the +# previous record (the "CBC residue") was used as the IV. This was +# changed to prevent the attacks described in [CBCATT]. For block +# ciphers, the IV length is of length +# SecurityParameters.record_iv_length, which is equal to the +# SecurityParameters.block_size. # -# padding -# Padding that is added to force the length of the plaintext to be -# an integral multiple of the block cipher's block length. The -# padding MAY be any length up to 255 bytes, as long as it results -# in the TLSCiphertext.length being an integral multiple of the -# block length. Lengths longer than necessary might be desirable to -# frustrate attacks on a protocol that are based on analysis of the -# lengths of exchanged messages. Each uint8 in the padding data -# vector MUST be filled with the padding length value. The receiver -# MUST check this padding and MUST use the bad_record_mac alert to -# indicate padding errors. +# padding +# Padding that is added to force the length of the plaintext to be +# an integral multiple of the block cipher's block length. The +# padding MAY be any length up to 255 bytes, as long as it results +# in the TLSCiphertext.length being an integral multiple of the +# block length. Lengths longer than necessary might be desirable to +# frustrate attacks on a protocol that are based on analysis of the +# lengths of exchanged messages. Each uint8 in the padding data +# vector MUST be filled with the padding length value. The receiver +# MUST check this padding and MUST use the bad_record_mac alert to +# indicate padding errors. # -# padding_length -# The padding length MUST be such that the total size of the -# GenericBlockCipher structure is a multiple of the cipher's block -# length. Legal values range from zero to 255, inclusive. This -# length specifies the length of the padding field exclusive of the -# padding_length field itself. +# padding_length +# The padding length MUST be such that the total size of the +# GenericBlockCipher structure is a multiple of the cipher's block +# length. Legal values range from zero to 255, inclusive. This +# length specifies the length of the padding field exclusive of the +# padding_length field itself. # -# The encrypted data length (TLSCiphertext.length) is one more than the -# sum of SecurityParameters.block_length, TLSCompressed.length, -# SecurityParameters.mac_length, and padding_length. +# The encrypted data length (TLSCiphertext.length) is one more than the +# sum of SecurityParameters.block_length, TLSCompressed.length, +# SecurityParameters.mac_length, and padding_length. # -# Example: If the block length is 8 bytes, the content length -# (TLSCompressed.length) is 61 bytes, and the MAC length is 20 bytes, -# then the length before padding is 82 bytes (this does not include the +# Example: If the block length is 8 bytes, the content length +# (TLSCompressed.length) is 61 bytes, and the MAC length is 20 bytes, +# then the length before padding is 82 bytes (this does not include the # -# IV. Thus, the padding length modulo 8 must be equal to 6 in order to -# make the total length an even multiple of 8 bytes (the block length). -# The padding length can be 6, 14, 22, and so on, through 254. If the -# padding length were the minimum necessary, 6, the padding would be 6 -# bytes, each containing the value 6. Thus, the last 8 octets of the -# GenericBlockCipher before block encryption would be xx 06 06 06 06 06 -# 06 06, where xx is the last octet of the MAC. +# IV. Thus, the padding length modulo 8 must be equal to 6 in order to +# make the total length an even multiple of 8 bytes (the block length). +# The padding length can be 6, 14, 22, and so on, through 254. If the +# padding length were the minimum necessary, 6, the padding would be 6 +# bytes, each containing the value 6. Thus, the last 8 octets of the +# GenericBlockCipher before block encryption would be xx 06 06 06 06 06 +# 06 06, where xx is the last octet of the MAC. # -# Note: With block ciphers in CBC mode (Cipher Block Chaining), it is -# critical that the entire plaintext of the record be known before any -# ciphertext is transmitted. Otherwise, it is possible for the -# attacker to mount the attack described in [CBCATT]. +# Note: With block ciphers in CBC mode (Cipher Block Chaining), it is +# critical that the entire plaintext of the record be known before any +# ciphertext is transmitted. Otherwise, it is possible for the +# attacker to mount the attack described in [CBCATT]. # -# Implementation note: Canvel et al. [CBCTIME] have demonstrated a -# timing attack on CBC padding based on the time required to compute -# the MAC. In order to defend against this attack, implementations -# MUST ensure that record processing time is essentially the same -# whether or not the padding is correct. In general, the best way to -# do this is to compute the MAC even if the padding is incorrect, and -# only then reject the packet. For instance, if the pad appears to be -# incorrect, the implementation might assume a zero-length pad and then -# compute the MAC. This leaves a small timing channel, since MAC -# performance depends to some extent on the size of the data fragment, -# but it is not believed to be large enough to be exploitable, due to -# the large block size of existing MACs and the small size of the -# timing signal. +# Implementation note: Canvel et al. [CBCTIME] have demonstrated a +# timing attack on CBC padding based on the time required to compute +# the MAC. In order to defend against this attack, implementations +# MUST ensure that record processing time is essentially the same +# whether or not the padding is correct. In general, the best way to +# do this is to compute the MAC even if the padding is incorrect, and +# only then reject the packet. For instance, if the pad appears to be +# incorrect, the implementation might assume a zero-length pad and then +# compute the MAC. This leaves a small timing channel, since MAC +# performance depends to some extent on the size of the data fragment, +# but it is not believed to be large enough to be exploitable, due to +# the large block size of existing MACs and the small size of the +# timing signal. [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-6.2.3.3.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-6.2.3.3.toml index de8fd5b25fd..ef6fde573d5 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-6.2.3.3.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-6.2.3.3.toml @@ -1,66 +1,66 @@ target = "https://www.rfc-editor.org/rfc/rfc5246#section-6.2.3.3" -# 6.2.3.3. AEAD Ciphers +# AEAD Ciphers # -# For AEAD [AEAD] ciphers (such as [CCM] or [GCM]), the AEAD function -# converts TLSCompressed.fragment structures to and from AEAD -# TLSCiphertext.fragment structures. +# For AEAD [AEAD] ciphers (such as [CCM] or [GCM]), the AEAD function +# converts TLSCompressed.fragment structures to and from AEAD +# TLSCiphertext.fragment structures. # -# struct { -# opaque nonce_explicit[SecurityParameters.record_iv_length]; -# aead-ciphered struct { -# opaque content[TLSCompressed.length]; -# }; -# } GenericAEADCipher; +# struct { +# opaque nonce_explicit[SecurityParameters.record_iv_length]; +# aead-ciphered struct { +# opaque content[TLSCompressed.length]; +# }; +# } GenericAEADCipher; # -# AEAD ciphers take as input a single key, a nonce, a plaintext, and -# "additional data" to be included in the authentication check, as -# described in Section 2.1 of [AEAD]. The key is either the -# client_write_key or the server_write_key. No MAC key is used. +# AEAD ciphers take as input a single key, a nonce, a plaintext, and +# "additional data" to be included in the authentication check, as +# described in Section 2.1 of [AEAD]. The key is either the +# client_write_key or the server_write_key. No MAC key is used. # -# Each AEAD cipher suite MUST specify how the nonce supplied to the -# AEAD operation is constructed, and what is the length of the -# GenericAEADCipher.nonce_explicit part. In many cases, it is +# Each AEAD cipher suite MUST specify how the nonce supplied to the +# AEAD operation is constructed, and what is the length of the +# GenericAEADCipher.nonce_explicit part. In many cases, it is # -# appropriate to use the partially implicit nonce technique described -# in Section 3.2.1 of [AEAD]; with record_iv_length being the length of -# the explicit part. In this case, the implicit part SHOULD be derived -# from key_block as client_write_iv and server_write_iv (as described -# in Section 6.3), and the explicit part is included in -# GenericAEAEDCipher.nonce_explicit. +# appropriate to use the partially implicit nonce technique described +# in Section 3.2.1 of [AEAD]; with record_iv_length being the length of +# the explicit part. In this case, the implicit part SHOULD be derived +# from key_block as client_write_iv and server_write_iv (as described +# in Section 6.3), and the explicit part is included in +# GenericAEAEDCipher.nonce_explicit. # -# The plaintext is the TLSCompressed.fragment. +# The plaintext is the TLSCompressed.fragment. # -# The additional authenticated data, which we denote as -# additional_data, is defined as follows: +# The additional authenticated data, which we denote as +# additional_data, is defined as follows: # -# additional_data = seq_num + TLSCompressed.type + -# TLSCompressed.version + TLSCompressed.length; +# additional_data = seq_num + TLSCompressed.type + +# TLSCompressed.version + TLSCompressed.length; # -# where "+" denotes concatenation. +# where "+" denotes concatenation. # -# The aead_output consists of the ciphertext output by the AEAD -# encryption operation. The length will generally be larger than -# TLSCompressed.length, but by an amount that varies with the AEAD -# cipher. Since the ciphers might incorporate padding, the amount of -# overhead could vary with different TLSCompressed.length values. Each -# AEAD cipher MUST NOT produce an expansion of greater than 1024 bytes. -# Symbolically, +# The aead_output consists of the ciphertext output by the AEAD +# encryption operation. The length will generally be larger than +# TLSCompressed.length, but by an amount that varies with the AEAD +# cipher. Since the ciphers might incorporate padding, the amount of +# overhead could vary with different TLSCompressed.length values. Each +# AEAD cipher MUST NOT produce an expansion of greater than 1024 bytes. +# Symbolically, # -# AEADEncrypted = AEAD-Encrypt(write_key, nonce, plaintext, -# additional_data) +# AEADEncrypted = AEAD-Encrypt(write_key, nonce, plaintext, +# additional_data) # -# In order to decrypt and verify, the cipher takes as input the key, -# nonce, the "additional_data", and the AEADEncrypted value. The -# output is either the plaintext or an error indicating that the -# decryption failed. There is no separate integrity check. That is: +# In order to decrypt and verify, the cipher takes as input the key, +# nonce, the "additional_data", and the AEADEncrypted value. The +# output is either the plaintext or an error indicating that the +# decryption failed. There is no separate integrity check. That is: # -# TLSCompressed.fragment = AEAD-Decrypt(write_key, nonce, -# AEADEncrypted, -# additional_data) +# TLSCompressed.fragment = AEAD-Decrypt(write_key, nonce, +# AEADEncrypted, +# additional_data) # -# If the decryption fails, a fatal bad_record_mac alert MUST be -# generated. +# If the decryption fails, a fatal bad_record_mac alert MUST be +# generated. [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-6.2.3.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-6.2.3.toml index 568e32b1221..13529fce70d 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-6.2.3.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-6.2.3.toml @@ -1,36 +1,36 @@ target = "https://www.rfc-editor.org/rfc/rfc5246#section-6.2.3" -# 6.2.3. Record Payload Protection +# Record Payload Protection # -# The encryption and MAC functions translate a TLSCompressed -# structure into a TLSCiphertext. The decryption functions reverse -# the process. The MAC of the record also includes a sequence -# number so that missing, extra, or repeated messages are -# detectable. +# The encryption and MAC functions translate a TLSCompressed +# structure into a TLSCiphertext. The decryption functions reverse +# the process. The MAC of the record also includes a sequence +# number so that missing, extra, or repeated messages are +# detectable. # -# struct { -# ContentType type; -# ProtocolVersion version; -# uint16 length; -# select (SecurityParameters.cipher_type) { -# case stream: GenericStreamCipher; -# case block: GenericBlockCipher; -# case aead: GenericAEADCipher; -# } fragment; -# } TLSCiphertext; +# struct { +# ContentType type; +# ProtocolVersion version; +# uint16 length; +# select (SecurityParameters.cipher_type) { +# case stream: GenericStreamCipher; +# case block: GenericBlockCipher; +# case aead: GenericAEADCipher; +# } fragment; +# } TLSCiphertext; # -# type -# The type field is identical to TLSCompressed.type. +# type +# The type field is identical to TLSCompressed.type. # -# version -# The version field is identical to TLSCompressed.version. +# version +# The version field is identical to TLSCompressed.version. # -# length -# The length (in bytes) of the following TLSCiphertext.fragment. -# The length MUST NOT exceed 2^14 + 2048. +# length +# The length (in bytes) of the following TLSCiphertext.fragment. +# The length MUST NOT exceed 2^14 + 2048. # -# fragment -# The encrypted form of TLSCompressed.fragment, with the MAC. +# fragment +# The encrypted form of TLSCompressed.fragment, with the MAC. [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-6.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-6.toml index 8aec9b1c7e7..27b29770ff8 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-6.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-6.toml @@ -1,38 +1,38 @@ target = "https://www.rfc-editor.org/rfc/rfc5246#section-6" -# 6. The TLS Record Protocol +# The TLS Record Protocol # -# The TLS Record Protocol is a layered protocol. At each layer, -# messages may include fields for length, description, and content. -# The Record Protocol takes messages to be transmitted, fragments the -# data into manageable blocks, optionally compresses the data, applies -# a MAC, encrypts, and transmits the result. Received data is -# decrypted, verified, decompressed, reassembled, and then delivered to -# higher-level clients. +# The TLS Record Protocol is a layered protocol. At each layer, +# messages may include fields for length, description, and content. +# The Record Protocol takes messages to be transmitted, fragments the +# data into manageable blocks, optionally compresses the data, applies +# a MAC, encrypts, and transmits the result. Received data is +# decrypted, verified, decompressed, reassembled, and then delivered to +# higher-level clients. # -# Four protocols that use the record protocol are described in this -# document: the handshake protocol, the alert protocol, the change -# cipher spec protocol, and the application data protocol. In order to -# allow extension of the TLS protocol, additional record content types -# can be supported by the record protocol. New record content type -# values are assigned by IANA in the TLS Content Type Registry as -# described in Section 12. +# Four protocols that use the record protocol are described in this +# document: the handshake protocol, the alert protocol, the change +# cipher spec protocol, and the application data protocol. In order to +# allow extension of the TLS protocol, additional record content types +# can be supported by the record protocol. New record content type +# values are assigned by IANA in the TLS Content Type Registry as +# described in Section 12. # -# Implementations MUST NOT send record types not defined in this -# document unless negotiated by some extension. If a TLS -# implementation receives an unexpected record type, it MUST send an -# unexpected_message alert. +# Implementations MUST NOT send record types not defined in this +# document unless negotiated by some extension. If a TLS +# implementation receives an unexpected record type, it MUST send an +# unexpected_message alert. # -# Any protocol designed for use over TLS must be carefully designed to -# deal with all possible attacks against it. As a practical matter, -# this means that the protocol designer must be aware of what security -# properties TLS does and does not provide and cannot safely rely on -# the latter. +# Any protocol designed for use over TLS must be carefully designed to +# deal with all possible attacks against it. As a practical matter, +# this means that the protocol designer must be aware of what security +# properties TLS does and does not provide and cannot safely rely on +# the latter. # -# Note in particular that type and length of a record are not protected -# by encryption. If this information is itself sensitive, application -# designers may wish to take steps (padding, cover traffic) to minimize -# information leakage. +# Note in particular that type and length of a record are not protected +# by encryption. If this information is itself sensitive, application +# designers may wish to take steps (padding, cover traffic) to minimize +# information leakage. [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-7.1.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-7.1.toml index 6806c5cc536..5c23a28e98d 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-7.1.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-7.1.toml @@ -1,38 +1,38 @@ target = "https://www.rfc-editor.org/rfc/rfc5246#section-7.1" -# 7.1. Change Cipher Spec Protocol +# Change Cipher Spec Protocol # -# The change cipher spec protocol exists to signal transitions in -# ciphering strategies. The protocol consists of a single message, -# which is encrypted and compressed under the current (not the pending) -# connection state. The message consists of a single byte of value 1. +# The change cipher spec protocol exists to signal transitions in +# ciphering strategies. The protocol consists of a single message, +# which is encrypted and compressed under the current (not the pending) +# connection state. The message consists of a single byte of value 1. # -# struct { -# enum { change_cipher_spec(1), (255) } type; -# } ChangeCipherSpec; +# struct { +# enum { change_cipher_spec(1), (255) } type; +# } ChangeCipherSpec; # -# The ChangeCipherSpec message is sent by both the client and the -# server to notify the receiving party that subsequent records will be -# protected under the newly negotiated CipherSpec and keys. Reception -# of this message causes the receiver to instruct the record layer to -# immediately copy the read pending state into the read current state. -# Immediately after sending this message, the sender MUST instruct the -# record layer to make the write pending state the write active state. +# The ChangeCipherSpec message is sent by both the client and the +# server to notify the receiving party that subsequent records will be +# protected under the newly negotiated CipherSpec and keys. Reception +# of this message causes the receiver to instruct the record layer to +# immediately copy the read pending state into the read current state. +# Immediately after sending this message, the sender MUST instruct the +# record layer to make the write pending state the write active state. # -# (See Section 6.1.) The ChangeCipherSpec message is sent during the -# handshake after the security parameters have been agreed upon, but -# before the verifying Finished message is sent. +# (See Section 6.1.) The ChangeCipherSpec message is sent during the +# handshake after the security parameters have been agreed upon, but +# before the verifying Finished message is sent. # -# Note: If a rehandshake occurs while data is flowing on a connection, -# the communicating parties may continue to send data using the old -# CipherSpec. However, once the ChangeCipherSpec has been sent, the -# new CipherSpec MUST be used. The first side to send the -# ChangeCipherSpec does not know that the other side has finished -# computing the new keying material (e.g., if it has to perform a -# time-consuming public key operation). Thus, a small window of time, -# during which the recipient must buffer the data, MAY exist. In -# practice, with modern machines this interval is likely to be fairly -# short. +# Note: If a rehandshake occurs while data is flowing on a connection, +# the communicating parties may continue to send data using the old +# CipherSpec. However, once the ChangeCipherSpec has been sent, the +# new CipherSpec MUST be used. The first side to send the +# ChangeCipherSpec does not know that the other side has finished +# computing the new keying material (e.g., if it has to perform a +# time-consuming public key operation). Thus, a small window of time, +# during which the recipient must buffer the data, MAY exist. In +# practice, with modern machines this interval is likely to be fairly +# short. [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-7.2.1.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-7.2.1.toml index c6b54171e38..6c69fdcfced 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-7.2.1.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-7.2.1.toml @@ -1,44 +1,44 @@ target = "https://www.rfc-editor.org/rfc/rfc5246#section-7.2.1" -# 7.2.1. Closure Alerts +# Closure Alerts # -# The client and the server must share knowledge that the connection is -# ending in order to avoid a truncation attack. Either party may -# initiate the exchange of closing messages. +# The client and the server must share knowledge that the connection is +# ending in order to avoid a truncation attack. Either party may +# initiate the exchange of closing messages. # -# close_notify -# This message notifies the recipient that the sender will not send -# any more messages on this connection. Note that as of TLS 1.1, -# failure to properly close a connection no longer requires that a -# session not be resumed. This is a change from TLS 1.0 to conform -# with widespread implementation practice. +# close_notify +# This message notifies the recipient that the sender will not send +# any more messages on this connection. Note that as of TLS 1.1, +# failure to properly close a connection no longer requires that a +# session not be resumed. This is a change from TLS 1.0 to conform +# with widespread implementation practice. # -# Either party may initiate a close by sending a close_notify alert. -# Any data received after a closure alert is ignored. +# Either party may initiate a close by sending a close_notify alert. +# Any data received after a closure alert is ignored. # -# Unless some other fatal alert has been transmitted, each party is -# required to send a close_notify alert before closing the write side -# of the connection. The other party MUST respond with a close_notify -# alert of its own and close down the connection immediately, -# discarding any pending writes. It is not required for the initiator -# of the close to wait for the responding close_notify alert before -# closing the read side of the connection. +# Unless some other fatal alert has been transmitted, each party is +# required to send a close_notify alert before closing the write side +# of the connection. The other party MUST respond with a close_notify +# alert of its own and close down the connection immediately, +# discarding any pending writes. It is not required for the initiator +# of the close to wait for the responding close_notify alert before +# closing the read side of the connection. # -# If the application protocol using TLS provides that any data may be -# carried over the underlying transport after the TLS connection is -# closed, the TLS implementation must receive the responding -# close_notify alert before indicating to the application layer that -# the TLS connection has ended. If the application protocol will not -# transfer any additional data, but will only close the underlying -# transport connection, then the implementation MAY choose to close the -# transport without waiting for the responding close_notify. No part +# If the application protocol using TLS provides that any data may be +# carried over the underlying transport after the TLS connection is +# closed, the TLS implementation must receive the responding +# close_notify alert before indicating to the application layer that +# the TLS connection has ended. If the application protocol will not +# transfer any additional data, but will only close the underlying +# transport connection, then the implementation MAY choose to close the +# transport without waiting for the responding close_notify. No part # -# of this standard should be taken to dictate the manner in which a -# usage profile for TLS manages its data transport, including when -# connections are opened or closed. +# of this standard should be taken to dictate the manner in which a +# usage profile for TLS manages its data transport, including when +# connections are opened or closed. # -# Note: It is assumed that closing a connection reliably delivers -# pending data before destroying the transport. +# Note: It is assumed that closing a connection reliably delivers +# pending data before destroying the transport. [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-7.2.2.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-7.2.2.toml index 1482c233471..561794c9c7f 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-7.2.2.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-7.2.2.toml @@ -1,172 +1,172 @@ target = "https://www.rfc-editor.org/rfc/rfc5246#section-7.2.2" -# 7.2.2. Error Alerts +# Error Alerts # -# Error handling in the TLS Handshake protocol is very simple. When an -# error is detected, the detecting party sends a message to the other -# party. Upon transmission or receipt of a fatal alert message, both -# parties immediately close the connection. Servers and clients MUST -# forget any session-identifiers, keys, and secrets associated with a -# failed connection. Thus, any connection terminated with a fatal -# alert MUST NOT be resumed. -# -# Whenever an implementation encounters a condition which is defined as -# a fatal alert, it MUST send the appropriate alert prior to closing -# the connection. For all errors where an alert level is not -# explicitly specified, the sending party MAY determine at its -# discretion whether to treat this as a fatal error or not. If the -# implementation chooses to send an alert but intends to close the -# connection immediately afterwards, it MUST send that alert at the -# fatal alert level. -# -# If an alert with a level of warning is sent and received, generally -# the connection can continue normally. If the receiving party decides -# not to proceed with the connection (e.g., after having received a -# no_renegotiation alert that it is not willing to accept), it SHOULD -# send a fatal alert to terminate the connection. Given this, the -# sending party cannot, in general, know how the receiving party will -# behave. Therefore, warning alerts are not very useful when the -# sending party wants to continue the connection, and thus are -# sometimes omitted. For example, if a peer decides to accept an -# expired certificate (perhaps after confirming this with the user) and -# wants to continue the connection, it would not generally send a -# certificate_expired alert. -# -# The following error alerts are defined: -# -# unexpected_message -# An inappropriate message was received. This alert is always fatal -# and should never be observed in communication between proper -# implementations. -# -# bad_record_mac -# This alert is returned if a record is received with an incorrect -# MAC. This alert also MUST be returned if an alert is sent because -# a TLSCiphertext decrypted in an invalid way: either it wasn't an -# even multiple of the block length, or its padding values, when -# checked, weren't correct. This message is always fatal and should -# never be observed in communication between proper implementations -# (except when messages were corrupted in the network). -# -# decryption_failed_RESERVED -# This alert was used in some earlier versions of TLS, and may have -# permitted certain attacks against the CBC mode [CBCATT]. It MUST -# NOT be sent by compliant implementations. -# -# record_overflow -# A TLSCiphertext record was received that had a length more than -# 2^14+2048 bytes, or a record decrypted to a TLSCompressed record -# with more than 2^14+1024 bytes. This message is always fatal and -# should never be observed in communication between proper -# implementations (except when messages were corrupted in the -# network). -# -# decompression_failure -# The decompression function received improper input (e.g., data -# that would expand to excessive length). This message is always -# fatal and should never be observed in communication between proper -# implementations. -# -# handshake_failure -# Reception of a handshake_failure alert message indicates that the -# sender was unable to negotiate an acceptable set of security -# parameters given the options available. This is a fatal error. -# -# no_certificate_RESERVED -# This alert was used in SSLv3 but not any version of TLS. It MUST -# NOT be sent by compliant implementations. -# -# bad_certificate -# A certificate was corrupt, contained signatures that did not -# verify correctly, etc. -# -# unsupported_certificate -# A certificate was of an unsupported type. -# -# certificate_revoked -# A certificate was revoked by its signer. -# -# certificate_expired -# A certificate has expired or is not currently valid. -# -# certificate_unknown -# Some other (unspecified) issue arose in processing the -# certificate, rendering it unacceptable. -# -# illegal_parameter -# A field in the handshake was out of range or inconsistent with -# other fields. This message is always fatal. -# -# unknown_ca -# A valid certificate chain or partial chain was received, but the -# certificate was not accepted because the CA certificate could not -# be located or couldn't be matched with a known, trusted CA. This -# message is always fatal. -# -# access_denied -# A valid certificate was received, but when access control was -# applied, the sender decided not to proceed with negotiation. This -# message is always fatal. -# -# decode_error -# A message could not be decoded because some field was out of the -# specified range or the length of the message was incorrect. This -# message is always fatal and should never be observed in -# communication between proper implementations (except when messages -# were corrupted in the network). -# -# decrypt_error -# A handshake cryptographic operation failed, including being unable -# to correctly verify a signature or validate a Finished message. -# This message is always fatal. -# -# export_restriction_RESERVED -# This alert was used in some earlier versions of TLS. It MUST NOT -# be sent by compliant implementations. -# -# protocol_version -# The protocol version the client has attempted to negotiate is -# recognized but not supported. (For example, old protocol versions -# might be avoided for security reasons.) This message is always -# fatal. -# -# insufficient_security -# Returned instead of handshake_failure when a negotiation has -# failed specifically because the server requires ciphers more -# secure than those supported by the client. This message is always -# fatal. -# -# internal_error -# An internal error unrelated to the peer or the correctness of the -# protocol (such as a memory allocation failure) makes it impossible -# to continue. This message is always fatal. -# -# user_canceled -# This handshake is being canceled for some reason unrelated to a -# protocol failure. If the user cancels an operation after the -# handshake is complete, just closing the connection by sending a -# close_notify is more appropriate. This alert should be followed -# by a close_notify. This message is generally a warning. -# -# no_renegotiation -# Sent by the client in response to a hello request or by the server -# in response to a client hello after initial handshaking. Either -# of these would normally lead to renegotiation; when that is not -# appropriate, the recipient should respond with this alert. At -# that point, the original requester can decide whether to proceed -# with the connection. One case where this would be appropriate is -# where a server has spawned a process to satisfy a request; the -# process might receive security parameters (key length, -# authentication, etc.) at startup, and it might be difficult to -# communicate changes to these parameters after that point. This -# message is always a warning. -# -# unsupported_extension -# sent by clients that receive an extended server hello containing -# an extension that they did not put in the corresponding client -# hello. This message is always fatal. -# -# New Alert values are assigned by IANA as described in Section 12. +# Error handling in the TLS Handshake protocol is very simple. When an +# error is detected, the detecting party sends a message to the other +# party. Upon transmission or receipt of a fatal alert message, both +# parties immediately close the connection. Servers and clients MUST +# forget any session-identifiers, keys, and secrets associated with a +# failed connection. Thus, any connection terminated with a fatal +# alert MUST NOT be resumed. +# +# Whenever an implementation encounters a condition which is defined as +# a fatal alert, it MUST send the appropriate alert prior to closing +# the connection. For all errors where an alert level is not +# explicitly specified, the sending party MAY determine at its +# discretion whether to treat this as a fatal error or not. If the +# implementation chooses to send an alert but intends to close the +# connection immediately afterwards, it MUST send that alert at the +# fatal alert level. +# +# If an alert with a level of warning is sent and received, generally +# the connection can continue normally. If the receiving party decides +# not to proceed with the connection (e.g., after having received a +# no_renegotiation alert that it is not willing to accept), it SHOULD +# send a fatal alert to terminate the connection. Given this, the +# sending party cannot, in general, know how the receiving party will +# behave. Therefore, warning alerts are not very useful when the +# sending party wants to continue the connection, and thus are +# sometimes omitted. For example, if a peer decides to accept an +# expired certificate (perhaps after confirming this with the user) and +# wants to continue the connection, it would not generally send a +# certificate_expired alert. +# +# The following error alerts are defined: +# +# unexpected_message +# An inappropriate message was received. This alert is always fatal +# and should never be observed in communication between proper +# implementations. +# +# bad_record_mac +# This alert is returned if a record is received with an incorrect +# MAC. This alert also MUST be returned if an alert is sent because +# a TLSCiphertext decrypted in an invalid way: either it wasn't an +# even multiple of the block length, or its padding values, when +# checked, weren't correct. This message is always fatal and should +# never be observed in communication between proper implementations +# (except when messages were corrupted in the network). +# +# decryption_failed_RESERVED +# This alert was used in some earlier versions of TLS, and may have +# permitted certain attacks against the CBC mode [CBCATT]. It MUST +# NOT be sent by compliant implementations. +# +# record_overflow +# A TLSCiphertext record was received that had a length more than +# 2^14+2048 bytes, or a record decrypted to a TLSCompressed record +# with more than 2^14+1024 bytes. This message is always fatal and +# should never be observed in communication between proper +# implementations (except when messages were corrupted in the +# network). +# +# decompression_failure +# The decompression function received improper input (e.g., data +# that would expand to excessive length). This message is always +# fatal and should never be observed in communication between proper +# implementations. +# +# handshake_failure +# Reception of a handshake_failure alert message indicates that the +# sender was unable to negotiate an acceptable set of security +# parameters given the options available. This is a fatal error. +# +# no_certificate_RESERVED +# This alert was used in SSLv3 but not any version of TLS. It MUST +# NOT be sent by compliant implementations. +# +# bad_certificate +# A certificate was corrupt, contained signatures that did not +# verify correctly, etc. +# +# unsupported_certificate +# A certificate was of an unsupported type. +# +# certificate_revoked +# A certificate was revoked by its signer. +# +# certificate_expired +# A certificate has expired or is not currently valid. +# +# certificate_unknown +# Some other (unspecified) issue arose in processing the +# certificate, rendering it unacceptable. +# +# illegal_parameter +# A field in the handshake was out of range or inconsistent with +# other fields. This message is always fatal. +# +# unknown_ca +# A valid certificate chain or partial chain was received, but the +# certificate was not accepted because the CA certificate could not +# be located or couldn't be matched with a known, trusted CA. This +# message is always fatal. +# +# access_denied +# A valid certificate was received, but when access control was +# applied, the sender decided not to proceed with negotiation. This +# message is always fatal. +# +# decode_error +# A message could not be decoded because some field was out of the +# specified range or the length of the message was incorrect. This +# message is always fatal and should never be observed in +# communication between proper implementations (except when messages +# were corrupted in the network). +# +# decrypt_error +# A handshake cryptographic operation failed, including being unable +# to correctly verify a signature or validate a Finished message. +# This message is always fatal. +# +# export_restriction_RESERVED +# This alert was used in some earlier versions of TLS. It MUST NOT +# be sent by compliant implementations. +# +# protocol_version +# The protocol version the client has attempted to negotiate is +# recognized but not supported. (For example, old protocol versions +# might be avoided for security reasons.) This message is always +# fatal. +# +# insufficient_security +# Returned instead of handshake_failure when a negotiation has +# failed specifically because the server requires ciphers more +# secure than those supported by the client. This message is always +# fatal. +# +# internal_error +# An internal error unrelated to the peer or the correctness of the +# protocol (such as a memory allocation failure) makes it impossible +# to continue. This message is always fatal. +# +# user_canceled +# This handshake is being canceled for some reason unrelated to a +# protocol failure. If the user cancels an operation after the +# handshake is complete, just closing the connection by sending a +# close_notify is more appropriate. This alert should be followed +# by a close_notify. This message is generally a warning. +# +# no_renegotiation +# Sent by the client in response to a hello request or by the server +# in response to a client hello after initial handshaking. Either +# of these would normally lead to renegotiation; when that is not +# appropriate, the recipient should respond with this alert. At +# that point, the original requester can decide whether to proceed +# with the connection. One case where this would be appropriate is +# where a server has spawned a process to satisfy a request; the +# process might receive security parameters (key length, +# authentication, etc.) at startup, and it might be difficult to +# communicate changes to these parameters after that point. This +# message is always a warning. +# +# unsupported_extension +# sent by clients that receive an extended server hello containing +# an extension that they did not put in the corresponding client +# hello. This message is always fatal. +# +# New Alert values are assigned by IANA as described in Section 12. [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-7.2.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-7.2.toml index 5929c7bf82d..0ac065265e5 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-7.2.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-7.2.toml @@ -1,53 +1,53 @@ target = "https://www.rfc-editor.org/rfc/rfc5246#section-7.2" -# 7.2. Alert Protocol +# Alert Protocol # -# One of the content types supported by the TLS record layer is the -# alert type. Alert messages convey the severity of the message -# (warning or fatal) and a description of the alert. Alert messages -# with a level of fatal result in the immediate termination of the -# connection. In this case, other connections corresponding to the -# session may continue, but the session identifier MUST be invalidated, -# preventing the failed session from being used to establish new -# connections. Like other messages, alert messages are encrypted and -# compressed, as specified by the current connection state. +# One of the content types supported by the TLS record layer is the +# alert type. Alert messages convey the severity of the message +# (warning or fatal) and a description of the alert. Alert messages +# with a level of fatal result in the immediate termination of the +# connection. In this case, other connections corresponding to the +# session may continue, but the session identifier MUST be invalidated, +# preventing the failed session from being used to establish new +# connections. Like other messages, alert messages are encrypted and +# compressed, as specified by the current connection state. # -# enum { warning(1), fatal(2), (255) } AlertLevel; +# enum { warning(1), fatal(2), (255) } AlertLevel; # -# enum { -# close_notify(0), -# unexpected_message(10), -# bad_record_mac(20), -# decryption_failed_RESERVED(21), -# record_overflow(22), -# decompression_failure(30), -# handshake_failure(40), -# no_certificate_RESERVED(41), -# bad_certificate(42), -# unsupported_certificate(43), -# certificate_revoked(44), -# certificate_expired(45), -# certificate_unknown(46), -# illegal_parameter(47), -# unknown_ca(48), -# access_denied(49), -# decode_error(50), -# decrypt_error(51), +# enum { +# close_notify(0), +# unexpected_message(10), +# bad_record_mac(20), +# decryption_failed_RESERVED(21), +# record_overflow(22), +# decompression_failure(30), +# handshake_failure(40), +# no_certificate_RESERVED(41), +# bad_certificate(42), +# unsupported_certificate(43), +# certificate_revoked(44), +# certificate_expired(45), +# certificate_unknown(46), +# illegal_parameter(47), +# unknown_ca(48), +# access_denied(49), +# decode_error(50), +# decrypt_error(51), # -# export_restriction_RESERVED(60), -# protocol_version(70), -# insufficient_security(71), -# internal_error(80), -# user_canceled(90), -# no_renegotiation(100), -# unsupported_extension(110), -# (255) -# } AlertDescription; +# export_restriction_RESERVED(60), +# protocol_version(70), +# insufficient_security(71), +# internal_error(80), +# user_canceled(90), +# no_renegotiation(100), +# unsupported_extension(110), +# (255) +# } AlertDescription; # -# struct { -# AlertLevel level; -# AlertDescription description; -# } Alert; +# struct { +# AlertLevel level; +# AlertDescription description; +# } Alert; [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-7.3.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-7.3.toml index aefddacf557..7c298259c10 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-7.3.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-7.3.toml @@ -1,154 +1,154 @@ target = "https://www.rfc-editor.org/rfc/rfc5246#section-7.3" -# 7.3. Handshake Protocol Overview +# Handshake Protocol Overview # -# The cryptographic parameters of the session state are produced by the -# TLS Handshake Protocol, which operates on top of the TLS record -# layer. When a TLS client and server first start communicating, they -# agree on a protocol version, select cryptographic algorithms, -# optionally authenticate each other, and use public-key encryption -# techniques to generate shared secrets. -# -# The TLS Handshake Protocol involves the following steps: -# -# - Exchange hello messages to agree on algorithms, exchange random -# values, and check for session resumption. -# -# - Exchange the necessary cryptographic parameters to allow the -# client and server to agree on a premaster secret. -# -# - Exchange certificates and cryptographic information to allow the -# client and server to authenticate themselves. -# -# - Generate a master secret from the premaster secret and exchanged -# random values. -# -# - Provide security parameters to the record layer. -# -# - Allow the client and server to verify that their peer has -# calculated the same security parameters and that the handshake -# occurred without tampering by an attacker. -# -# Note that higher layers should not be overly reliant on whether TLS -# always negotiates the strongest possible connection between two -# peers. There are a number of ways in which a man-in-the-middle -# attacker can attempt to make two entities drop down to the least -# secure method they support. The protocol has been designed to -# minimize this risk, but there are still attacks available: for -# example, an attacker could block access to the port a secure service -# runs on, or attempt to get the peers to negotiate an unauthenticated -# connection. The fundamental rule is that higher levels must be -# cognizant of what their security requirements are and never transmit -# information over a channel less secure than what they require. The -# TLS protocol is secure in that any cipher suite offers its promised -# level of security: if you negotiate 3DES with a 1024-bit RSA key -# exchange with a host whose certificate you have verified, you can -# expect to be that secure. -# -# These goals are achieved by the handshake protocol, which can be -# summarized as follows: The client sends a ClientHello message to -# which the server must respond with a ServerHello message, or else a -# fatal error will occur and the connection will fail. The ClientHello -# and ServerHello are used to establish security enhancement -# capabilities between client and server. The ClientHello and -# ServerHello establish the following attributes: Protocol Version, -# Session ID, Cipher Suite, and Compression Method. Additionally, two -# random values are generated and exchanged: ClientHello.random and -# ServerHello.random. -# -# The actual key exchange uses up to four messages: the server -# Certificate, the ServerKeyExchange, the client Certificate, and the -# ClientKeyExchange. New key exchange methods can be created by -# specifying a format for these messages and by defining the use of the -# messages to allow the client and server to agree upon a shared -# secret. This secret MUST be quite long; currently defined key -# exchange methods exchange secrets that range from 46 bytes upwards. -# -# Following the hello messages, the server will send its certificate in -# a Certificate message if it is to be authenticated. Additionally, a -# ServerKeyExchange message may be sent, if it is required (e.g., if -# the server has no certificate, or if its certificate is for signing -# only). If the server is authenticated, it may request a certificate -# from the client, if that is appropriate to the cipher suite selected. -# Next, the server will send the ServerHelloDone message, indicating -# that the hello-message phase of the handshake is complete. The -# server will then wait for a client response. If the server has sent -# a CertificateRequest message, the client MUST send the Certificate -# message. The ClientKeyExchange message is now sent, and the content -# of that message will depend on the public key algorithm selected -# between the ClientHello and the ServerHello. If the client has sent -# a certificate with signing ability, a digitally-signed -# CertificateVerify message is sent to explicitly verify possession of -# the private key in the certificate. -# -# At this point, a ChangeCipherSpec message is sent by the client, and -# the client copies the pending Cipher Spec into the current Cipher -# Spec. The client then immediately sends the Finished message under -# the new algorithms, keys, and secrets. In response, the server will -# send its own ChangeCipherSpec message, transfer the pending to the -# current Cipher Spec, and send its Finished message under the new -# Cipher Spec. At this point, the handshake is complete, and the -# client and server may begin to exchange application layer data. (See -# flow chart below.) Application data MUST NOT be sent prior to the -# completion of the first handshake (before a cipher suite other than -# TLS_NULL_WITH_NULL_NULL is established). -# -# Client Server -# -# ClientHello --------> -# ServerHello -# Certificate* -# ServerKeyExchange* -# CertificateRequest* -# <-------- ServerHelloDone -# Certificate* -# ClientKeyExchange -# CertificateVerify* -# [ChangeCipherSpec] -# Finished --------> -# [ChangeCipherSpec] -# <-------- Finished -# Application Data <-------> Application Data -# -# Figure 1. Message flow for a full handshake -# -# * Indicates optional or situation-dependent messages that are not -# always sent. -# -# Note: To help avoid pipeline stalls, ChangeCipherSpec is an -# independent TLS protocol content type, and is not actually a TLS -# handshake message. -# -# When the client and server decide to resume a previous session or -# duplicate an existing session (instead of negotiating new security -# parameters), the message flow is as follows: -# -# The client sends a ClientHello using the Session ID of the session to -# be resumed. The server then checks its session cache for a match. -# If a match is found, and the server is willing to re-establish the -# connection under the specified session state, it will send a -# ServerHello with the same Session ID value. At this point, both -# client and server MUST send ChangeCipherSpec messages and proceed -# directly to Finished messages. Once the re-establishment is -# complete, the client and server MAY begin to exchange application -# layer data. (See flow chart below.) If a Session ID match is not -# found, the server generates a new session ID, and the TLS client and -# server perform a full handshake. -# -# Client Server -# -# ClientHello --------> -# ServerHello -# [ChangeCipherSpec] -# <-------- Finished -# [ChangeCipherSpec] -# Finished --------> -# Application Data <-------> Application Data -# -# Figure 2. Message flow for an abbreviated handshake -# -# The contents and significance of each message will be presented in -# detail in the following sections. +# The cryptographic parameters of the session state are produced by the +# TLS Handshake Protocol, which operates on top of the TLS record +# layer. When a TLS client and server first start communicating, they +# agree on a protocol version, select cryptographic algorithms, +# optionally authenticate each other, and use public-key encryption +# techniques to generate shared secrets. +# +# The TLS Handshake Protocol involves the following steps: +# +# - Exchange hello messages to agree on algorithms, exchange random +# values, and check for session resumption. +# +# - Exchange the necessary cryptographic parameters to allow the +# client and server to agree on a premaster secret. +# +# - Exchange certificates and cryptographic information to allow the +# client and server to authenticate themselves. +# +# - Generate a master secret from the premaster secret and exchanged +# random values. +# +# - Provide security parameters to the record layer. +# +# - Allow the client and server to verify that their peer has +# calculated the same security parameters and that the handshake +# occurred without tampering by an attacker. +# +# Note that higher layers should not be overly reliant on whether TLS +# always negotiates the strongest possible connection between two +# peers. There are a number of ways in which a man-in-the-middle +# attacker can attempt to make two entities drop down to the least +# secure method they support. The protocol has been designed to +# minimize this risk, but there are still attacks available: for +# example, an attacker could block access to the port a secure service +# runs on, or attempt to get the peers to negotiate an unauthenticated +# connection. The fundamental rule is that higher levels must be +# cognizant of what their security requirements are and never transmit +# information over a channel less secure than what they require. The +# TLS protocol is secure in that any cipher suite offers its promised +# level of security: if you negotiate 3DES with a 1024-bit RSA key +# exchange with a host whose certificate you have verified, you can +# expect to be that secure. +# +# These goals are achieved by the handshake protocol, which can be +# summarized as follows: The client sends a ClientHello message to +# which the server must respond with a ServerHello message, or else a +# fatal error will occur and the connection will fail. The ClientHello +# and ServerHello are used to establish security enhancement +# capabilities between client and server. The ClientHello and +# ServerHello establish the following attributes: Protocol Version, +# Session ID, Cipher Suite, and Compression Method. Additionally, two +# random values are generated and exchanged: ClientHello.random and +# ServerHello.random. +# +# The actual key exchange uses up to four messages: the server +# Certificate, the ServerKeyExchange, the client Certificate, and the +# ClientKeyExchange. New key exchange methods can be created by +# specifying a format for these messages and by defining the use of the +# messages to allow the client and server to agree upon a shared +# secret. This secret MUST be quite long; currently defined key +# exchange methods exchange secrets that range from 46 bytes upwards. +# +# Following the hello messages, the server will send its certificate in +# a Certificate message if it is to be authenticated. Additionally, a +# ServerKeyExchange message may be sent, if it is required (e.g., if +# the server has no certificate, or if its certificate is for signing +# only). If the server is authenticated, it may request a certificate +# from the client, if that is appropriate to the cipher suite selected. +# Next, the server will send the ServerHelloDone message, indicating +# that the hello-message phase of the handshake is complete. The +# server will then wait for a client response. If the server has sent +# a CertificateRequest message, the client MUST send the Certificate +# message. The ClientKeyExchange message is now sent, and the content +# of that message will depend on the public key algorithm selected +# between the ClientHello and the ServerHello. If the client has sent +# a certificate with signing ability, a digitally-signed +# CertificateVerify message is sent to explicitly verify possession of +# the private key in the certificate. +# +# At this point, a ChangeCipherSpec message is sent by the client, and +# the client copies the pending Cipher Spec into the current Cipher +# Spec. The client then immediately sends the Finished message under +# the new algorithms, keys, and secrets. In response, the server will +# send its own ChangeCipherSpec message, transfer the pending to the +# current Cipher Spec, and send its Finished message under the new +# Cipher Spec. At this point, the handshake is complete, and the +# client and server may begin to exchange application layer data. (See +# flow chart below.) Application data MUST NOT be sent prior to the +# completion of the first handshake (before a cipher suite other than +# TLS_NULL_WITH_NULL_NULL is established). +# +# Client Server +# +# ClientHello --------> +# ServerHello +# Certificate* +# ServerKeyExchange* +# CertificateRequest* +# <-------- ServerHelloDone +# Certificate* +# ClientKeyExchange +# CertificateVerify* +# [ChangeCipherSpec] +# Finished --------> +# [ChangeCipherSpec] +# <-------- Finished +# Application Data <-------> Application Data +# +# Figure 1. Message flow for a full handshake +# +# * Indicates optional or situation-dependent messages that are not +# always sent. +# +# Note: To help avoid pipeline stalls, ChangeCipherSpec is an +# independent TLS protocol content type, and is not actually a TLS +# handshake message. +# +# When the client and server decide to resume a previous session or +# duplicate an existing session (instead of negotiating new security +# parameters), the message flow is as follows: +# +# The client sends a ClientHello using the Session ID of the session to +# be resumed. The server then checks its session cache for a match. +# If a match is found, and the server is willing to re-establish the +# connection under the specified session state, it will send a +# ServerHello with the same Session ID value. At this point, both +# client and server MUST send ChangeCipherSpec messages and proceed +# directly to Finished messages. Once the re-establishment is +# complete, the client and server MAY begin to exchange application +# layer data. (See flow chart below.) If a Session ID match is not +# found, the server generates a new session ID, and the TLS client and +# server perform a full handshake. +# +# Client Server +# +# ClientHello --------> +# ServerHello +# [ChangeCipherSpec] +# <-------- Finished +# [ChangeCipherSpec] +# Finished --------> +# Application Data <-------> Application Data +# +# Figure 2. Message flow for an abbreviated handshake +# +# The contents and significance of each message will be presented in +# detail in the following sections. [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-7.4.1.1.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-7.4.1.1.toml index 4e1cb4633ee..f2bb990ba83 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-7.4.1.1.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-7.4.1.1.toml @@ -1,42 +1,42 @@ target = "https://www.rfc-editor.org/rfc/rfc5246#section-7.4.1.1" -# 7.4.1.1. Hello Request +# Hello Request # -# When this message will be sent: +# When this message will be sent: # -# The HelloRequest message MAY be sent by the server at any time. +# The HelloRequest message MAY be sent by the server at any time. # -# Meaning of this message: +# Meaning of this message: # -# HelloRequest is a simple notification that the client should begin -# the negotiation process anew. In response, the client should send -# a ClientHello message when convenient. This message is not -# intended to establish which side is the client or server but -# merely to initiate a new negotiation. Servers SHOULD NOT send a -# HelloRequest immediately upon the client's initial connection. It -# is the client's job to send a ClientHello at that time. +# HelloRequest is a simple notification that the client should begin +# the negotiation process anew. In response, the client should send +# a ClientHello message when convenient. This message is not +# intended to establish which side is the client or server but +# merely to initiate a new negotiation. Servers SHOULD NOT send a +# HelloRequest immediately upon the client's initial connection. It +# is the client's job to send a ClientHello at that time. # -# This message will be ignored by the client if the client is -# currently negotiating a session. This message MAY be ignored by -# the client if it does not wish to renegotiate a session, or the -# client may, if it wishes, respond with a no_renegotiation alert. -# Since handshake messages are intended to have transmission -# precedence over application data, it is expected that the -# negotiation will begin before no more than a few records are -# received from the client. If the server sends a HelloRequest but -# does not receive a ClientHello in response, it may close the -# connection with a fatal alert. +# This message will be ignored by the client if the client is +# currently negotiating a session. This message MAY be ignored by +# the client if it does not wish to renegotiate a session, or the +# client may, if it wishes, respond with a no_renegotiation alert. +# Since handshake messages are intended to have transmission +# precedence over application data, it is expected that the +# negotiation will begin before no more than a few records are +# received from the client. If the server sends a HelloRequest but +# does not receive a ClientHello in response, it may close the +# connection with a fatal alert. # -# After sending a HelloRequest, servers SHOULD NOT repeat the -# request until the subsequent handshake negotiation is complete. +# After sending a HelloRequest, servers SHOULD NOT repeat the +# request until the subsequent handshake negotiation is complete. # -# Structure of this message: +# Structure of this message: # -# struct { } HelloRequest; +# struct { } HelloRequest; # -# This message MUST NOT be included in the message hashes that are -# maintained throughout the handshake and used in the Finished messages -# and the certificate verify message. +# This message MUST NOT be included in the message hashes that are +# maintained throughout the handshake and used in the Finished messages +# and the certificate verify message. [[spec]] level = "MAY" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-7.4.1.2.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-7.4.1.2.toml index fb2baa69527..7ce629c1c1e 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-7.4.1.2.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-7.4.1.2.toml @@ -1,154 +1,154 @@ target = "https://www.rfc-editor.org/rfc/rfc5246#section-7.4.1.2" -# 7.4.1.2. Client Hello +# Client Hello # -# When this message will be sent: +# When this message will be sent: # -# When a client first connects to a server, it is required to send -# the ClientHello as its first message. The client can also send a -# ClientHello in response to a HelloRequest or on its own initiative -# in order to renegotiate the security parameters in an existing -# connection. +# When a client first connects to a server, it is required to send +# the ClientHello as its first message. The client can also send a +# ClientHello in response to a HelloRequest or on its own initiative +# in order to renegotiate the security parameters in an existing +# connection. # -# Structure of this message: +# Structure of this message: # -# The ClientHello message includes a random structure, which is used -# later in the protocol. +# The ClientHello message includes a random structure, which is used +# later in the protocol. # -# struct { -# uint32 gmt_unix_time; -# opaque random_bytes[28]; -# } Random; +# struct { +# uint32 gmt_unix_time; +# opaque random_bytes[28]; +# } Random; # -# gmt_unix_time -# The current time and date in standard UNIX 32-bit format -# (seconds since the midnight starting Jan 1, 1970, UTC, ignoring -# leap seconds) according to the sender's internal clock. Clocks -# are not required to be set correctly by the basic TLS protocol; -# higher-level or application protocols may define additional -# requirements. Note that, for historical reasons, the data -# element is named using GMT, the predecessor of the current -# worldwide time base, UTC. +# gmt_unix_time +# The current time and date in standard UNIX 32-bit format +# (seconds since the midnight starting Jan 1, 1970, UTC, ignoring +# leap seconds) according to the sender's internal clock. Clocks +# are not required to be set correctly by the basic TLS protocol; +# higher-level or application protocols may define additional +# requirements. Note that, for historical reasons, the data +# element is named using GMT, the predecessor of the current +# worldwide time base, UTC. # -# random_bytes -# 28 bytes generated by a secure random number generator. +# random_bytes +# 28 bytes generated by a secure random number generator. # -# The ClientHello message includes a variable-length session -# identifier. If not empty, the value identifies a session between the -# same client and server whose security parameters the client wishes to -# reuse. The session identifier MAY be from an earlier connection, +# The ClientHello message includes a variable-length session +# identifier. If not empty, the value identifies a session between the +# same client and server whose security parameters the client wishes to +# reuse. The session identifier MAY be from an earlier connection, # -# this connection, or from another currently active connection. The -# second option is useful if the client only wishes to update the -# random structures and derived values of a connection, and the third -# option makes it possible to establish several independent secure -# connections without repeating the full handshake protocol. These -# independent connections may occur sequentially or simultaneously; a -# SessionID becomes valid when the handshake negotiating it completes -# with the exchange of Finished messages and persists until it is -# removed due to aging or because a fatal error was encountered on a -# connection associated with the session. The actual contents of the -# SessionID are defined by the server. +# this connection, or from another currently active connection. The +# second option is useful if the client only wishes to update the +# random structures and derived values of a connection, and the third +# option makes it possible to establish several independent secure +# connections without repeating the full handshake protocol. These +# independent connections may occur sequentially or simultaneously; a +# SessionID becomes valid when the handshake negotiating it completes +# with the exchange of Finished messages and persists until it is +# removed due to aging or because a fatal error was encountered on a +# connection associated with the session. The actual contents of the +# SessionID are defined by the server. # -# opaque SessionID<0..32>; +# opaque SessionID<0..32>; # -# Warning: Because the SessionID is transmitted without encryption or -# immediate MAC protection, servers MUST NOT place confidential -# information in session identifiers or let the contents of fake -# session identifiers cause any breach of security. (Note that the -# content of the handshake as a whole, including the SessionID, is -# protected by the Finished messages exchanged at the end of the -# handshake.) +# Warning: Because the SessionID is transmitted without encryption or +# immediate MAC protection, servers MUST NOT place confidential +# information in session identifiers or let the contents of fake +# session identifiers cause any breach of security. (Note that the +# content of the handshake as a whole, including the SessionID, is +# protected by the Finished messages exchanged at the end of the +# handshake.) # -# The cipher suite list, passed from the client to the server in the -# ClientHello message, contains the combinations of cryptographic -# algorithms supported by the client in order of the client's -# preference (favorite choice first). Each cipher suite defines a key -# exchange algorithm, a bulk encryption algorithm (including secret key -# length), a MAC algorithm, and a PRF. The server will select a cipher -# suite or, if no acceptable choices are presented, return a handshake -# failure alert and close the connection. If the list contains cipher -# suites the server does not recognize, support, or wish to use, the -# server MUST ignore those cipher suites, and process the remaining -# ones as usual. +# The cipher suite list, passed from the client to the server in the +# ClientHello message, contains the combinations of cryptographic +# algorithms supported by the client in order of the client's +# preference (favorite choice first). Each cipher suite defines a key +# exchange algorithm, a bulk encryption algorithm (including secret key +# length), a MAC algorithm, and a PRF. The server will select a cipher +# suite or, if no acceptable choices are presented, return a handshake +# failure alert and close the connection. If the list contains cipher +# suites the server does not recognize, support, or wish to use, the +# server MUST ignore those cipher suites, and process the remaining +# ones as usual. # -# uint8 CipherSuite[2]; /* Cryptographic suite selector */ +# uint8 CipherSuite[2]; /* Cryptographic suite selector */ # -# The ClientHello includes a list of compression algorithms supported -# by the client, ordered according to the client's preference. +# The ClientHello includes a list of compression algorithms supported +# by the client, ordered according to the client's preference. # -# enum { null(0), (255) } CompressionMethod; +# enum { null(0), (255) } CompressionMethod; # -# struct { -# ProtocolVersion client_version; -# Random random; -# SessionID session_id; -# CipherSuite cipher_suites<2..2^16-2>; -# CompressionMethod compression_methods<1..2^8-1>; -# select (extensions_present) { -# case false: -# struct {}; -# case true: -# Extension extensions<0..2^16-1>; -# }; -# } ClientHello; +# struct { +# ProtocolVersion client_version; +# Random random; +# SessionID session_id; +# CipherSuite cipher_suites<2..2^16-2>; +# CompressionMethod compression_methods<1..2^8-1>; +# select (extensions_present) { +# case false: +# struct {}; +# case true: +# Extension extensions<0..2^16-1>; +# }; +# } ClientHello; # -# TLS allows extensions to follow the compression_methods field in an -# extensions block. The presence of extensions can be detected by -# determining whether there are bytes following the compression_methods -# at the end of the ClientHello. Note that this method of detecting -# optional data differs from the normal TLS method of having a -# variable-length field, but it is used for compatibility with TLS -# before extensions were defined. +# TLS allows extensions to follow the compression_methods field in an +# extensions block. The presence of extensions can be detected by +# determining whether there are bytes following the compression_methods +# at the end of the ClientHello. Note that this method of detecting +# optional data differs from the normal TLS method of having a +# variable-length field, but it is used for compatibility with TLS +# before extensions were defined. # -# client_version -# The version of the TLS protocol by which the client wishes to -# communicate during this session. This SHOULD be the latest -# (highest valued) version supported by the client. For this -# version of the specification, the version will be 3.3 (see -# Appendix E for details about backward compatibility). +# client_version +# The version of the TLS protocol by which the client wishes to +# communicate during this session. This SHOULD be the latest +# (highest valued) version supported by the client. For this +# version of the specification, the version will be 3.3 (see +# Appendix E for details about backward compatibility). # -# random -# A client-generated random structure. +# random +# A client-generated random structure. # -# session_id -# The ID of a session the client wishes to use for this connection. -# This field is empty if no session_id is available, or if the -# client wishes to generate new security parameters. +# session_id +# The ID of a session the client wishes to use for this connection. +# This field is empty if no session_id is available, or if the +# client wishes to generate new security parameters. # -# cipher_suites -# This is a list of the cryptographic options supported by the -# client, with the client's first preference first. If the -# session_id field is not empty (implying a session resumption -# request), this vector MUST include at least the cipher_suite from -# that session. Values are defined in Appendix A.5. +# cipher_suites +# This is a list of the cryptographic options supported by the +# client, with the client's first preference first. If the +# session_id field is not empty (implying a session resumption +# request), this vector MUST include at least the cipher_suite from +# that session. Values are defined in Appendix A.5. # -# compression_methods -# This is a list of the compression methods supported by the client, -# sorted by client preference. If the session_id field is not empty -# (implying a session resumption request), it MUST include the +# compression_methods +# This is a list of the compression methods supported by the client, +# sorted by client preference. If the session_id field is not empty +# (implying a session resumption request), it MUST include the # -# compression_method from that session. This vector MUST contain, -# and all implementations MUST support, CompressionMethod.null. -# Thus, a client and server will always be able to agree on a -# compression method. +# compression_method from that session. This vector MUST contain, +# and all implementations MUST support, CompressionMethod.null. +# Thus, a client and server will always be able to agree on a +# compression method. # -# extensions -# Clients MAY request extended functionality from servers by sending -# data in the extensions field. The actual "Extension" format is -# defined in Section 7.4.1.4. +# extensions +# Clients MAY request extended functionality from servers by sending +# data in the extensions field. The actual "Extension" format is +# defined in Section 7.4.1.4. # -# In the event that a client requests additional functionality using -# extensions, and this functionality is not supplied by the server, the -# client MAY abort the handshake. A server MUST accept ClientHello -# messages both with and without the extensions field, and (as for all -# other messages) it MUST check that the amount of data in the message -# precisely matches one of these formats; if not, then it MUST send a -# fatal "decode_error" alert. +# In the event that a client requests additional functionality using +# extensions, and this functionality is not supplied by the server, the +# client MAY abort the handshake. A server MUST accept ClientHello +# messages both with and without the extensions field, and (as for all +# other messages) it MUST check that the amount of data in the message +# precisely matches one of these formats; if not, then it MUST send a +# fatal "decode_error" alert. # -# After sending the ClientHello message, the client waits for a -# ServerHello message. Any handshake message returned by the server, -# except for a HelloRequest, is treated as a fatal error. +# After sending the ClientHello message, the client waits for a +# ServerHello message. Any handshake message returned by the server, +# except for a HelloRequest, is treated as a fatal error. [[spec]] level = "MAY" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-7.4.1.3.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-7.4.1.3.toml index 05f8e7fae0f..f776fd51944 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-7.4.1.3.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-7.4.1.3.toml @@ -1,76 +1,76 @@ target = "https://www.rfc-editor.org/rfc/rfc5246#section-7.4.1.3" -# 7.4.1.3. Server Hello +# Server Hello # -# When this message will be sent: +# When this message will be sent: # -# The server will send this message in response to a ClientHello -# message when it was able to find an acceptable set of algorithms. -# If it cannot find such a match, it will respond with a handshake -# failure alert. +# The server will send this message in response to a ClientHello +# message when it was able to find an acceptable set of algorithms. +# If it cannot find such a match, it will respond with a handshake +# failure alert. # -# Structure of this message: +# Structure of this message: # -# struct { -# ProtocolVersion server_version; -# Random random; -# SessionID session_id; -# CipherSuite cipher_suite; -# CompressionMethod compression_method; -# select (extensions_present) { -# case false: -# struct {}; -# case true: -# Extension extensions<0..2^16-1>; -# }; -# } ServerHello; +# struct { +# ProtocolVersion server_version; +# Random random; +# SessionID session_id; +# CipherSuite cipher_suite; +# CompressionMethod compression_method; +# select (extensions_present) { +# case false: +# struct {}; +# case true: +# Extension extensions<0..2^16-1>; +# }; +# } ServerHello; # -# The presence of extensions can be detected by determining whether -# there are bytes following the compression_method field at the end of -# the ServerHello. +# The presence of extensions can be detected by determining whether +# there are bytes following the compression_method field at the end of +# the ServerHello. # -# server_version -# This field will contain the lower of that suggested by the client -# in the client hello and the highest supported by the server. For -# this version of the specification, the version is 3.3. (See -# Appendix E for details about backward compatibility.) +# server_version +# This field will contain the lower of that suggested by the client +# in the client hello and the highest supported by the server. For +# this version of the specification, the version is 3.3. (See +# Appendix E for details about backward compatibility.) # -# random -# This structure is generated by the server and MUST be -# independently generated from the ClientHello.random. +# random +# This structure is generated by the server and MUST be +# independently generated from the ClientHello.random. # -# session_id -# This is the identity of the session corresponding to this -# connection. If the ClientHello.session_id was non-empty, the -# server will look in its session cache for a match. If a match is -# found and the server is willing to establish the new connection -# using the specified session state, the server will respond with -# the same value as was supplied by the client. This indicates a -# resumed session and dictates that the parties must proceed -# directly to the Finished messages. Otherwise, this field will -# contain a different value identifying the new session. The server -# may return an empty session_id to indicate that the session will -# not be cached and therefore cannot be resumed. If a session is -# resumed, it must be resumed using the same cipher suite it was -# originally negotiated with. Note that there is no requirement -# that the server resume any session even if it had formerly -# provided a session_id. Clients MUST be prepared to do a full -# negotiation -- including negotiating new cipher suites -- during -# any handshake. +# session_id +# This is the identity of the session corresponding to this +# connection. If the ClientHello.session_id was non-empty, the +# server will look in its session cache for a match. If a match is +# found and the server is willing to establish the new connection +# using the specified session state, the server will respond with +# the same value as was supplied by the client. This indicates a +# resumed session and dictates that the parties must proceed +# directly to the Finished messages. Otherwise, this field will +# contain a different value identifying the new session. The server +# may return an empty session_id to indicate that the session will +# not be cached and therefore cannot be resumed. If a session is +# resumed, it must be resumed using the same cipher suite it was +# originally negotiated with. Note that there is no requirement +# that the server resume any session even if it had formerly +# provided a session_id. Clients MUST be prepared to do a full +# negotiation -- including negotiating new cipher suites -- during +# any handshake. # -# cipher_suite -# The single cipher suite selected by the server from the list in -# ClientHello.cipher_suites. For resumed sessions, this field is -# the value from the state of the session being resumed. +# cipher_suite +# The single cipher suite selected by the server from the list in +# ClientHello.cipher_suites. For resumed sessions, this field is +# the value from the state of the session being resumed. # -# compression_method -# The single compression algorithm selected by the server from the -# list in ClientHello.compression_methods. For resumed sessions, -# this field is the value from the resumed session state. +# compression_method +# The single compression algorithm selected by the server from the +# list in ClientHello.compression_methods. For resumed sessions, +# this field is the value from the resumed session state. # -# extensions -# A list of extensions. Note that only extensions offered by the -# client can appear in the server's list. +# extensions +# A list of extensions. Note that only extensions offered by the +# client can appear in the server's list. [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-7.4.1.4.1.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-7.4.1.4.1.toml index fbbb8926432..57862c20976 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-7.4.1.4.1.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-7.4.1.4.1.toml @@ -1,92 +1,92 @@ target = "https://www.rfc-editor.org/rfc/rfc5246#section-7.4.1.4.1" -# 7.4.1.4.1. Signature Algorithms +# Signature Algorithms # -# The client uses the "signature_algorithms" extension to indicate to -# the server which signature/hash algorithm pairs may be used in -# digital signatures. The "extension_data" field of this extension -# contains a "supported_signature_algorithms" value. -# -# enum { -# none(0), md5(1), sha1(2), sha224(3), sha256(4), sha384(5), -# sha512(6), (255) -# } HashAlgorithm; -# -# enum { anonymous(0), rsa(1), dsa(2), ecdsa(3), (255) } -# SignatureAlgorithm; -# -# struct { -# HashAlgorithm hash; -# SignatureAlgorithm signature; -# } SignatureAndHashAlgorithm; -# -# SignatureAndHashAlgorithm -# supported_signature_algorithms<2..2^16-2>; -# -# Each SignatureAndHashAlgorithm value lists a single hash/signature -# pair that the client is willing to verify. The values are indicated -# in descending order of preference. -# -# Note: Because not all signature algorithms and hash algorithms may be -# accepted by an implementation (e.g., DSA with SHA-1, but not -# SHA-256), algorithms here are listed in pairs. -# -# hash -# This field indicates the hash algorithm which may be used. The -# values indicate support for unhashed data, MD5 [MD5], SHA-1, -# SHA-224, SHA-256, SHA-384, and SHA-512 [SHS], respectively. The -# "none" value is provided for future extensibility, in case of a -# signature algorithm which does not require hashing before signing. -# -# signature -# This field indicates the signature algorithm that may be used. -# The values indicate anonymous signatures, RSASSA-PKCS1-v1_5 -# [PKCS1] and DSA [DSS], and ECDSA [ECDSA], respectively. The -# "anonymous" value is meaningless in this context but used in -# Section 7.4.3. It MUST NOT appear in this extension. -# -# The semantics of this extension are somewhat complicated because the -# cipher suite indicates permissible signature algorithms but not hash -# algorithms. Sections 7.4.2 and 7.4.3 describe the appropriate rules. -# -# If the client supports only the default hash and signature algorithms -# (listed in this section), it MAY omit the signature_algorithms -# extension. If the client does not support the default algorithms, or -# supports other hash and signature algorithms (and it is willing to -# use them for verifying messages sent by the server, i.e., server -# certificates and server key exchange), it MUST send the -# -# signature_algorithms extension, listing the algorithms it is willing -# to accept. -# -# If the client does not send the signature_algorithms extension, the -# server MUST do the following: -# -# - If the negotiated key exchange algorithm is one of (RSA, DHE_RSA, -# DH_RSA, RSA_PSK, ECDH_RSA, ECDHE_RSA), behave as if client had -# sent the value {sha1,rsa}. -# -# - If the negotiated key exchange algorithm is one of (DHE_DSS, -# DH_DSS), behave as if the client had sent the value {sha1,dsa}. -# -# - If the negotiated key exchange algorithm is one of (ECDH_ECDSA, -# ECDHE_ECDSA), behave as if the client had sent value {sha1,ecdsa}. -# -# Note: this is a change from TLS 1.1 where there are no explicit -# rules, but as a practical matter one can assume that the peer -# supports MD5 and SHA-1. -# -# Note: this extension is not meaningful for TLS versions prior to 1.2. -# Clients MUST NOT offer it if they are offering prior versions. -# However, even if clients do offer it, the rules specified in [TLSEXT] -# require servers to ignore extensions they do not understand. -# -# Servers MUST NOT send this extension. TLS servers MUST support -# receiving this extension. -# -# When performing session resumption, this extension is not included in -# Server Hello, and the server ignores the extension in Client Hello -# (if present). +# The client uses the "signature_algorithms" extension to indicate to +# the server which signature/hash algorithm pairs may be used in +# digital signatures. The "extension_data" field of this extension +# contains a "supported_signature_algorithms" value. +# +# enum { +# none(0), md5(1), sha1(2), sha224(3), sha256(4), sha384(5), +# sha512(6), (255) +# } HashAlgorithm; +# +# enum { anonymous(0), rsa(1), dsa(2), ecdsa(3), (255) } +# SignatureAlgorithm; +# +# struct { +# HashAlgorithm hash; +# SignatureAlgorithm signature; +# } SignatureAndHashAlgorithm; +# +# SignatureAndHashAlgorithm +# supported_signature_algorithms<2..2^16-2>; +# +# Each SignatureAndHashAlgorithm value lists a single hash/signature +# pair that the client is willing to verify. The values are indicated +# in descending order of preference. +# +# Note: Because not all signature algorithms and hash algorithms may be +# accepted by an implementation (e.g., DSA with SHA-1, but not +# SHA-256), algorithms here are listed in pairs. +# +# hash +# This field indicates the hash algorithm which may be used. The +# values indicate support for unhashed data, MD5 [MD5], SHA-1, +# SHA-224, SHA-256, SHA-384, and SHA-512 [SHS], respectively. The +# "none" value is provided for future extensibility, in case of a +# signature algorithm which does not require hashing before signing. +# +# signature +# This field indicates the signature algorithm that may be used. +# The values indicate anonymous signatures, RSASSA-PKCS1-v1_5 +# [PKCS1] and DSA [DSS], and ECDSA [ECDSA], respectively. The +# "anonymous" value is meaningless in this context but used in +# Section 7.4.3. It MUST NOT appear in this extension. +# +# The semantics of this extension are somewhat complicated because the +# cipher suite indicates permissible signature algorithms but not hash +# algorithms. Sections 7.4.2 and 7.4.3 describe the appropriate rules. +# +# If the client supports only the default hash and signature algorithms +# (listed in this section), it MAY omit the signature_algorithms +# extension. If the client does not support the default algorithms, or +# supports other hash and signature algorithms (and it is willing to +# use them for verifying messages sent by the server, i.e., server +# certificates and server key exchange), it MUST send the +# +# signature_algorithms extension, listing the algorithms it is willing +# to accept. +# +# If the client does not send the signature_algorithms extension, the +# server MUST do the following: +# +# - If the negotiated key exchange algorithm is one of (RSA, DHE_RSA, +# DH_RSA, RSA_PSK, ECDH_RSA, ECDHE_RSA), behave as if client had +# sent the value {sha1,rsa}. +# +# - If the negotiated key exchange algorithm is one of (DHE_DSS, +# DH_DSS), behave as if the client had sent the value {sha1,dsa}. +# +# - If the negotiated key exchange algorithm is one of (ECDH_ECDSA, +# ECDHE_ECDSA), behave as if the client had sent value {sha1,ecdsa}. +# +# Note: this is a change from TLS 1.1 where there are no explicit +# rules, but as a practical matter one can assume that the peer +# supports MD5 and SHA-1. +# +# Note: this extension is not meaningful for TLS versions prior to 1.2. +# Clients MUST NOT offer it if they are offering prior versions. +# However, even if clients do offer it, the rules specified in [TLSEXT] +# require servers to ignore extensions they do not understand. +# +# Servers MUST NOT send this extension. TLS servers MUST support +# receiving this extension. +# +# When performing session resumption, this extension is not included in +# Server Hello, and the server ignores the extension in Client Hello +# (if present). [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-7.4.1.4.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-7.4.1.4.toml index c7229c289de..837f1a37078 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-7.4.1.4.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-7.4.1.4.toml @@ -1,95 +1,95 @@ target = "https://www.rfc-editor.org/rfc/rfc5246#section-7.4.1.4" -# 7.4.1.4. Hello Extensions +# Hello Extensions # -# The extension format is: -# -# struct { -# ExtensionType extension_type; -# opaque extension_data<0..2^16-1>; -# } Extension; -# -# enum { -# signature_algorithms(13), (65535) -# } ExtensionType; -# -# Here: -# -# - "extension_type" identifies the particular extension type. -# -# - "extension_data" contains information specific to the particular -# extension type. -# -# The initial set of extensions is defined in a companion document -# [TLSEXT]. The list of extension types is maintained by IANA as -# described in Section 12. -# -# An extension type MUST NOT appear in the ServerHello unless the same -# extension type appeared in the corresponding ClientHello. If a -# client receives an extension type in ServerHello that it did not -# request in the associated ClientHello, it MUST abort the handshake -# with an unsupported_extension fatal alert. -# -# Nonetheless, "server-oriented" extensions may be provided in the -# future within this framework. Such an extension (say, of type x) -# would require the client to first send an extension of type x in a -# ClientHello with empty extension_data to indicate that it supports -# the extension type. In this case, the client is offering the -# capability to understand the extension type, and the server is taking -# the client up on its offer. -# -# When multiple extensions of different types are present in the -# ClientHello or ServerHello messages, the extensions MAY appear in any -# order. There MUST NOT be more than one extension of the same type. -# -# Finally, note that extensions can be sent both when starting a new -# session and when requesting session resumption. Indeed, a client -# that requests session resumption does not in general know whether the -# server will accept this request, and therefore it SHOULD send the -# same extensions as it would send if it were not attempting -# resumption. -# -# In general, the specification of each extension type needs to -# describe the effect of the extension both during full handshake and -# session resumption. Most current TLS extensions are relevant only -# when a session is initiated: when an older session is resumed, the -# server does not process these extensions in Client Hello, and does -# not include them in Server Hello. However, some extensions may -# specify different behavior during session resumption. -# -# 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, 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. -# -# - It would be technically possible to use extensions to change major -# aspects of the design of TLS; for example the design of cipher -# suite negotiation. This is not recommended; it would be more -# appropriate to define a new version of TLS -- particularly since -# the TLS handshake algorithms have specific protection against -# version rollback attacks based on the version number, and the -# possibility of version rollback should be a significant -# consideration in any major design change. +# The extension format is: +# +# struct { +# ExtensionType extension_type; +# opaque extension_data<0..2^16-1>; +# } Extension; +# +# enum { +# signature_algorithms(13), (65535) +# } ExtensionType; +# +# Here: +# +# - "extension_type" identifies the particular extension type. +# +# - "extension_data" contains information specific to the particular +# extension type. +# +# The initial set of extensions is defined in a companion document +# [TLSEXT]. The list of extension types is maintained by IANA as +# described in Section 12. +# +# An extension type MUST NOT appear in the ServerHello unless the same +# extension type appeared in the corresponding ClientHello. If a +# client receives an extension type in ServerHello that it did not +# request in the associated ClientHello, it MUST abort the handshake +# with an unsupported_extension fatal alert. +# +# Nonetheless, "server-oriented" extensions may be provided in the +# future within this framework. Such an extension (say, of type x) +# would require the client to first send an extension of type x in a +# ClientHello with empty extension_data to indicate that it supports +# the extension type. In this case, the client is offering the +# capability to understand the extension type, and the server is taking +# the client up on its offer. +# +# When multiple extensions of different types are present in the +# ClientHello or ServerHello messages, the extensions MAY appear in any +# order. There MUST NOT be more than one extension of the same type. +# +# Finally, note that extensions can be sent both when starting a new +# session and when requesting session resumption. Indeed, a client +# that requests session resumption does not in general know whether the +# server will accept this request, and therefore it SHOULD send the +# same extensions as it would send if it were not attempting +# resumption. +# +# In general, the specification of each extension type needs to +# describe the effect of the extension both during full handshake and +# session resumption. Most current TLS extensions are relevant only +# when a session is initiated: when an older session is resumed, the +# server does not process these extensions in Client Hello, and does +# not include them in Server Hello. However, some extensions may +# specify different behavior during session resumption. +# +# 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, 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. +# +# - It would be technically possible to use extensions to change major +# aspects of the design of TLS; for example the design of cipher +# suite negotiation. This is not recommended; it would be more +# appropriate to define a new version of TLS -- particularly since +# the TLS handshake algorithms have specific protection against +# version rollback attacks based on the version number, and the +# possibility of version rollback should be a significant +# consideration in any major design change. [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-7.4.2.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-7.4.2.toml index 3ff9999c0bd..efe68a55616 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-7.4.2.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-7.4.2.toml @@ -1,127 +1,127 @@ target = "https://www.rfc-editor.org/rfc/rfc5246#section-7.4.2" -# 7.4.2. Server Certificate +# Server Certificate # -# When this message will be sent: +# When this message will be sent: # -# The server MUST send a Certificate message whenever the agreed- -# upon key exchange method uses certificates for authentication -# (this includes all key exchange methods defined in this document -# except DH_anon). This message will always immediately follow the -# ServerHello message. +# The server MUST send a Certificate message whenever the agreed- +# upon key exchange method uses certificates for authentication +# (this includes all key exchange methods defined in this document +# except DH_anon). This message will always immediately follow the +# ServerHello message. # -# Meaning of this message: +# Meaning of this message: # -# This message conveys the server's certificate chain to the client. +# This message conveys the server's certificate chain to the client. # -# The certificate MUST be appropriate for the negotiated cipher -# suite's key exchange algorithm and any negotiated extensions. +# The certificate MUST be appropriate for the negotiated cipher +# suite's key exchange algorithm and any negotiated extensions. # -# Structure of this message: +# Structure of this message: # -# opaque ASN.1Cert<1..2^24-1>; +# opaque ASN.1Cert<1..2^24-1>; # -# struct { -# ASN.1Cert certificate_list<0..2^24-1>; -# } Certificate; +# struct { +# ASN.1Cert certificate_list<0..2^24-1>; +# } Certificate; # -# certificate_list -# This is a sequence (chain) of certificates. The sender's -# certificate MUST come first in the list. Each following -# certificate MUST directly certify the one preceding it. Because -# certificate validation requires that root keys be distributed -# independently, the self-signed certificate that specifies the root -# certificate authority MAY be omitted from the chain, under the -# assumption that the remote end must already possess it in order to -# validate it in any case. +# certificate_list +# This is a sequence (chain) of certificates. The sender's +# certificate MUST come first in the list. Each following +# certificate MUST directly certify the one preceding it. Because +# certificate validation requires that root keys be distributed +# independently, the self-signed certificate that specifies the root +# certificate authority MAY be omitted from the chain, under the +# assumption that the remote end must already possess it in order to +# validate it in any case. # -# The same message type and structure will be used for the client's -# response to a certificate request message. Note that a client MAY -# send no certificates if it does not have an appropriate certificate -# to send in response to the server's authentication request. +# The same message type and structure will be used for the client's +# response to a certificate request message. Note that a client MAY +# send no certificates if it does not have an appropriate certificate +# to send in response to the server's authentication request. # -# Note: PKCS #7 [PKCS7] is not used as the format for the certificate -# vector because PKCS #6 [PKCS6] extended certificates are not used. -# Also, PKCS #7 defines a SET rather than a SEQUENCE, making the task -# of parsing the list more difficult. +# Note: PKCS #7 [PKCS7] is not used as the format for the certificate +# vector because PKCS #6 [PKCS6] extended certificates are not used. +# Also, PKCS #7 defines a SET rather than a SEQUENCE, making the task +# of parsing the list more difficult. # -# The following rules apply to the certificates sent by the server: +# The following rules apply to the certificates sent by the server: # -# - The certificate type MUST be X.509v3, unless explicitly negotiated -# otherwise (e.g., [TLSPGP]). +# - The certificate type MUST be X.509v3, unless explicitly negotiated +# otherwise (e.g., [TLSPGP]). # -# - The end entity certificate's public key (and associated -# restrictions) MUST be compatible with the selected key exchange -# algorithm. +# - The end entity certificate's public key (and associated +# restrictions) MUST be compatible with the selected key exchange +# algorithm. # -# Key Exchange Alg. Certificate Key Type +# Key Exchange Alg. Certificate Key Type # -# RSA RSA public key; the certificate MUST allow the -# RSA_PSK key to be used for encryption (the -# keyEncipherment bit MUST be set if the key -# usage extension is present). -# Note: RSA_PSK is defined in [TLSPSK]. +# RSA RSA public key; the certificate MUST allow the +# RSA_PSK key to be used for encryption (the +# keyEncipherment bit MUST be set if the key +# usage extension is present). +# Note: RSA_PSK is defined in [TLSPSK]. # -# DHE_RSA RSA public key; the certificate MUST allow the -# ECDHE_RSA key to be used for signing (the -# digitalSignature bit MUST be set if the key -# usage extension is present) with the signature -# scheme and hash algorithm that will be employed -# in the server key exchange message. -# Note: ECDHE_RSA is defined in [TLSECC]. +# DHE_RSA RSA public key; the certificate MUST allow the +# ECDHE_RSA key to be used for signing (the +# digitalSignature bit MUST be set if the key +# usage extension is present) with the signature +# scheme and hash algorithm that will be employed +# in the server key exchange message. +# Note: ECDHE_RSA is defined in [TLSECC]. # -# DHE_DSS DSA public key; the certificate MUST allow the -# key to be used for signing with the hash -# algorithm that will be employed in the server -# key exchange message. +# DHE_DSS DSA public key; the certificate MUST allow the +# key to be used for signing with the hash +# algorithm that will be employed in the server +# key exchange message. # -# DH_DSS Diffie-Hellman public key; the keyAgreement bit -# DH_RSA MUST be set if the key usage extension is -# present. +# DH_DSS Diffie-Hellman public key; the keyAgreement bit +# DH_RSA MUST be set if the key usage extension is +# present. # -# ECDH_ECDSA ECDH-capable public key; the public key MUST -# ECDH_RSA use a curve and point format supported by the -# client, as described in [TLSECC]. +# ECDH_ECDSA ECDH-capable public key; the public key MUST +# ECDH_RSA use a curve and point format supported by the +# client, as described in [TLSECC]. # -# ECDHE_ECDSA ECDSA-capable public key; the certificate MUST -# allow the key to be used for signing with the -# hash algorithm that will be employed in the -# server key exchange message. The public key -# MUST use a curve and point format supported by -# the client, as described in [TLSECC]. +# ECDHE_ECDSA ECDSA-capable public key; the certificate MUST +# allow the key to be used for signing with the +# hash algorithm that will be employed in the +# server key exchange message. The public key +# MUST use a curve and point format supported by +# the client, as described in [TLSECC]. # -# - The "server_name" and "trusted_ca_keys" extensions [TLSEXT] are -# used to guide certificate selection. +# - The "server_name" and "trusted_ca_keys" extensions [TLSEXT] are +# used to guide certificate selection. # -# If the client provided a "signature_algorithms" extension, then all -# certificates provided by the server MUST be signed by a -# hash/signature algorithm pair that appears in that extension. Note -# that this implies that a certificate containing a key for one -# signature algorithm MAY be signed using a different signature -# algorithm (for instance, an RSA key signed with a DSA key). This is -# a departure from TLS 1.1, which required that the algorithms be the -# same. Note that this also implies that the DH_DSS, DH_RSA, -# ECDH_ECDSA, and ECDH_RSA key exchange algorithms do not restrict the -# algorithm used to sign the certificate. Fixed DH certificates MAY be -# signed with any hash/signature algorithm pair appearing in the -# extension. The names DH_DSS, DH_RSA, ECDH_ECDSA, and ECDH_RSA are -# historical. +# If the client provided a "signature_algorithms" extension, then all +# certificates provided by the server MUST be signed by a +# hash/signature algorithm pair that appears in that extension. Note +# that this implies that a certificate containing a key for one +# signature algorithm MAY be signed using a different signature +# algorithm (for instance, an RSA key signed with a DSA key). This is +# a departure from TLS 1.1, which required that the algorithms be the +# same. Note that this also implies that the DH_DSS, DH_RSA, +# ECDH_ECDSA, and ECDH_RSA key exchange algorithms do not restrict the +# algorithm used to sign the certificate. Fixed DH certificates MAY be +# signed with any hash/signature algorithm pair appearing in the +# extension. The names DH_DSS, DH_RSA, ECDH_ECDSA, and ECDH_RSA are +# historical. # -# If the server has multiple certificates, it chooses one of them based -# on the above-mentioned criteria (in addition to other criteria, such -# as transport layer endpoint, local configuration and preferences, -# etc.). If the server has a single certificate, it SHOULD attempt to -# validate that it meets these criteria. +# If the server has multiple certificates, it chooses one of them based +# on the above-mentioned criteria (in addition to other criteria, such +# as transport layer endpoint, local configuration and preferences, +# etc.). If the server has a single certificate, it SHOULD attempt to +# validate that it meets these criteria. # -# Note that there are certificates that use algorithms and/or algorithm -# combinations that cannot be currently used with TLS. For example, a -# certificate with RSASSA-PSS signature key (id-RSASSA-PSS OID in -# SubjectPublicKeyInfo) cannot be used because TLS defines no -# corresponding signature algorithm. +# Note that there are certificates that use algorithms and/or algorithm +# combinations that cannot be currently used with TLS. For example, a +# certificate with RSASSA-PSS signature key (id-RSASSA-PSS OID in +# SubjectPublicKeyInfo) cannot be used because TLS defines no +# corresponding signature algorithm. # -# As cipher suites that specify new key exchange methods are specified -# for the TLS protocol, they will imply the certificate format and the -# required encoded keying information. +# As cipher suites that specify new key exchange methods are specified +# for the TLS protocol, they will imply the certificate format and the +# required encoded keying information. [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-7.4.3.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-7.4.3.toml index f31fb802486..f7b6bd36198 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-7.4.3.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-7.4.3.toml @@ -1,120 +1,120 @@ target = "https://www.rfc-editor.org/rfc/rfc5246#section-7.4.3" -# 7.4.3. Server Key Exchange Message +# Server Key Exchange Message # -# When this message will be sent: -# -# This message will be sent immediately after the server Certificate -# message (or the ServerHello message, if this is an anonymous -# negotiation). -# -# The ServerKeyExchange message is sent by the server only when the -# server Certificate message (if sent) does not contain enough data -# to allow the client to exchange a premaster secret. This is true -# for the following key exchange methods: -# -# DHE_DSS -# DHE_RSA -# DH_anon -# -# It is not legal to send the ServerKeyExchange message for the -# following key exchange methods: -# -# RSA -# DH_DSS -# DH_RSA -# -# Other key exchange algorithms, such as those defined in [TLSECC], -# MUST specify whether the ServerKeyExchange message is sent or not; -# and if the message is sent, its contents. -# -# Meaning of this message: -# -# This message conveys cryptographic information to allow the client -# to communicate the premaster secret: a Diffie-Hellman public key -# with which the client can complete a key exchange (with the result -# being the premaster secret) or a public key for some other -# algorithm. -# -# Structure of this message: -# -# enum { dhe_dss, dhe_rsa, dh_anon, rsa, dh_dss, dh_rsa -# /* may be extended, e.g., for ECDH -- see [TLSECC] */ -# } KeyExchangeAlgorithm; -# -# struct { -# opaque dh_p<1..2^16-1>; -# opaque dh_g<1..2^16-1>; -# opaque dh_Ys<1..2^16-1>; -# } ServerDHParams; /* Ephemeral DH parameters */ -# -# dh_p -# The prime modulus used for the Diffie-Hellman operation. -# -# dh_g -# The generator used for the Diffie-Hellman operation. -# -# dh_Ys -# The server's Diffie-Hellman public value (g^X mod p). -# -# struct { -# select (KeyExchangeAlgorithm) { -# case dh_anon: -# ServerDHParams params; -# case dhe_dss: -# case dhe_rsa: -# ServerDHParams params; -# digitally-signed struct { -# opaque client_random[32]; -# opaque server_random[32]; -# ServerDHParams params; -# } signed_params; -# case rsa: -# case dh_dss: -# case dh_rsa: -# struct {} ; -# /* message is omitted for rsa, dh_dss, and dh_rsa */ -# /* may be extended, e.g., for ECDH -- see [TLSECC] */ -# }; -# } ServerKeyExchange; -# -# params -# The server's key exchange parameters. -# -# signed_params -# For non-anonymous key exchanges, a signature over the server's -# key exchange parameters. -# -# If the client has offered the "signature_algorithms" extension, the -# signature algorithm and hash algorithm MUST be a pair listed in that -# extension. Note that there is a possibility for inconsistencies -# here. For instance, the client might offer DHE_DSS key exchange but -# omit any DSA pairs from its "signature_algorithms" extension. In -# order to negotiate correctly, the server MUST check any candidate -# cipher suites against the "signature_algorithms" extension before -# selecting them. This is somewhat inelegant but is a compromise -# designed to minimize changes to the original cipher suite design. -# -# In addition, the hash and signature algorithms MUST be compatible -# with the key in the server's end-entity certificate. RSA keys MAY be -# used with any permitted hash algorithm, subject to restrictions in -# the certificate, if any. -# -# Because DSA signatures do not contain any secure indication of hash -# algorithm, there is a risk of hash substitution if multiple hashes -# may be used with any key. Currently, DSA [DSS] may only be used with -# SHA-1. Future revisions of DSS [DSS-3] are expected to allow the use -# of other digest algorithms with DSA, as well as guidance as to which -# -# digest algorithms should be used with each key size. In addition, -# future revisions of [PKIX] may specify mechanisms for certificates to -# indicate which digest algorithms are to be used with DSA. -# -# As additional cipher suites are defined for TLS that include new key -# exchange algorithms, the server key exchange message will be sent if -# and only if the certificate type associated with the key exchange -# algorithm does not provide enough information for the client to -# exchange a premaster secret. +# When this message will be sent: +# +# This message will be sent immediately after the server Certificate +# message (or the ServerHello message, if this is an anonymous +# negotiation). +# +# The ServerKeyExchange message is sent by the server only when the +# server Certificate message (if sent) does not contain enough data +# to allow the client to exchange a premaster secret. This is true +# for the following key exchange methods: +# +# DHE_DSS +# DHE_RSA +# DH_anon +# +# It is not legal to send the ServerKeyExchange message for the +# following key exchange methods: +# +# RSA +# DH_DSS +# DH_RSA +# +# Other key exchange algorithms, such as those defined in [TLSECC], +# MUST specify whether the ServerKeyExchange message is sent or not; +# and if the message is sent, its contents. +# +# Meaning of this message: +# +# This message conveys cryptographic information to allow the client +# to communicate the premaster secret: a Diffie-Hellman public key +# with which the client can complete a key exchange (with the result +# being the premaster secret) or a public key for some other +# algorithm. +# +# Structure of this message: +# +# enum { dhe_dss, dhe_rsa, dh_anon, rsa, dh_dss, dh_rsa +# /* may be extended, e.g., for ECDH -- see [TLSECC] */ +# } KeyExchangeAlgorithm; +# +# struct { +# opaque dh_p<1..2^16-1>; +# opaque dh_g<1..2^16-1>; +# opaque dh_Ys<1..2^16-1>; +# } ServerDHParams; /* Ephemeral DH parameters */ +# +# dh_p +# The prime modulus used for the Diffie-Hellman operation. +# +# dh_g +# The generator used for the Diffie-Hellman operation. +# +# dh_Ys +# The server's Diffie-Hellman public value (g^X mod p). +# +# struct { +# select (KeyExchangeAlgorithm) { +# case dh_anon: +# ServerDHParams params; +# case dhe_dss: +# case dhe_rsa: +# ServerDHParams params; +# digitally-signed struct { +# opaque client_random[32]; +# opaque server_random[32]; +# ServerDHParams params; +# } signed_params; +# case rsa: +# case dh_dss: +# case dh_rsa: +# struct {} ; +# /* message is omitted for rsa, dh_dss, and dh_rsa */ +# /* may be extended, e.g., for ECDH -- see [TLSECC] */ +# }; +# } ServerKeyExchange; +# +# params +# The server's key exchange parameters. +# +# signed_params +# For non-anonymous key exchanges, a signature over the server's +# key exchange parameters. +# +# If the client has offered the "signature_algorithms" extension, the +# signature algorithm and hash algorithm MUST be a pair listed in that +# extension. Note that there is a possibility for inconsistencies +# here. For instance, the client might offer DHE_DSS key exchange but +# omit any DSA pairs from its "signature_algorithms" extension. In +# order to negotiate correctly, the server MUST check any candidate +# cipher suites against the "signature_algorithms" extension before +# selecting them. This is somewhat inelegant but is a compromise +# designed to minimize changes to the original cipher suite design. +# +# In addition, the hash and signature algorithms MUST be compatible +# with the key in the server's end-entity certificate. RSA keys MAY be +# used with any permitted hash algorithm, subject to restrictions in +# the certificate, if any. +# +# Because DSA signatures do not contain any secure indication of hash +# algorithm, there is a risk of hash substitution if multiple hashes +# may be used with any key. Currently, DSA [DSS] may only be used with +# SHA-1. Future revisions of DSS [DSS-3] are expected to allow the use +# of other digest algorithms with DSA, as well as guidance as to which +# +# digest algorithms should be used with each key size. In addition, +# future revisions of [PKIX] may specify mechanisms for certificates to +# indicate which digest algorithms are to be used with DSA. +# +# As additional cipher suites are defined for TLS that include new key +# exchange algorithms, the server key exchange message will be sent if +# and only if the certificate type associated with the key exchange +# algorithm does not provide enough information for the client to +# exchange a premaster secret. [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-7.4.4.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-7.4.4.toml index 5d549b65ec6..9b14532ca73 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-7.4.4.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-7.4.4.toml @@ -1,90 +1,90 @@ target = "https://www.rfc-editor.org/rfc/rfc5246#section-7.4.4" -# 7.4.4. Certificate Request +# Certificate Request # -# When this message will be sent: -# -# A non-anonymous server can optionally request a certificate from -# the client, if appropriate for the selected cipher suite. This -# message, if sent, will immediately follow the ServerKeyExchange -# message (if it is sent; otherwise, this message follows the -# server's Certificate message). -# -# Structure of this message: -# -# enum { -# rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4), -# rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6), -# fortezza_dms_RESERVED(20), (255) -# } ClientCertificateType; -# -# opaque DistinguishedName<1..2^16-1>; -# -# struct { -# ClientCertificateType certificate_types<1..2^8-1>; -# SignatureAndHashAlgorithm -# supported_signature_algorithms<2^16-1>; -# DistinguishedName certificate_authorities<0..2^16-1>; -# } CertificateRequest; -# -# certificate_types -# A list of the types of certificate types that the client may -# offer. -# -# rsa_sign a certificate containing an RSA key -# dss_sign a certificate containing a DSA key -# rsa_fixed_dh a certificate containing a static DH key. -# dss_fixed_dh a certificate containing a static DH key -# -# supported_signature_algorithms -# A list of the hash/signature algorithm pairs that the server is -# able to verify, listed in descending order of preference. -# -# certificate_authorities -# A list of the distinguished names [X501] of acceptable -# certificate_authorities, represented in DER-encoded format. These -# distinguished names may specify a desired distinguished name for a -# root CA or for a subordinate CA; thus, this message can be used to -# describe known roots as well as a desired authorization space. If -# the certificate_authorities list is empty, then the client MAY -# send any certificate of the appropriate ClientCertificateType, -# unless there is some external arrangement to the contrary. -# -# The interaction of the certificate_types and -# supported_signature_algorithms fields is somewhat complicated. -# certificate_types has been present in TLS since SSLv3, but was -# somewhat underspecified. Much of its functionality is superseded by -# supported_signature_algorithms. The following rules apply: -# -# - Any certificates provided by the client MUST be signed using a -# hash/signature algorithm pair found in -# supported_signature_algorithms. -# -# - The end-entity certificate provided by the client MUST contain a -# key that is compatible with certificate_types. If the key is a -# signature key, it MUST be usable with some hash/signature -# algorithm pair in supported_signature_algorithms. -# -# - For historical reasons, the names of some client certificate types -# include the algorithm used to sign the certificate. For example, -# in earlier versions of TLS, rsa_fixed_dh meant a certificate -# signed with RSA and containing a static DH key. In TLS 1.2, this -# functionality has been obsoleted by the -# supported_signature_algorithms, and the certificate type no longer -# restricts the algorithm used to sign the certificate. For -# example, if the server sends dss_fixed_dh certificate type and -# {{sha1, dsa}, {sha1, rsa}} signature types, the client MAY reply -# with a certificate containing a static DH key, signed with RSA- -# SHA1. -# -# New ClientCertificateType values are assigned by IANA as described in -# Section 12. -# -# Note: Values listed as RESERVED may not be used. They were used in -# SSLv3. -# -# Note: It is a fatal handshake_failure alert for an anonymous server -# to request client authentication. +# When this message will be sent: +# +# A non-anonymous server can optionally request a certificate from +# the client, if appropriate for the selected cipher suite. This +# message, if sent, will immediately follow the ServerKeyExchange +# message (if it is sent; otherwise, this message follows the +# server's Certificate message). +# +# Structure of this message: +# +# enum { +# rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4), +# rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6), +# fortezza_dms_RESERVED(20), (255) +# } ClientCertificateType; +# +# opaque DistinguishedName<1..2^16-1>; +# +# struct { +# ClientCertificateType certificate_types<1..2^8-1>; +# SignatureAndHashAlgorithm +# supported_signature_algorithms<2^16-1>; +# DistinguishedName certificate_authorities<0..2^16-1>; +# } CertificateRequest; +# +# certificate_types +# A list of the types of certificate types that the client may +# offer. +# +# rsa_sign a certificate containing an RSA key +# dss_sign a certificate containing a DSA key +# rsa_fixed_dh a certificate containing a static DH key. +# dss_fixed_dh a certificate containing a static DH key +# +# supported_signature_algorithms +# A list of the hash/signature algorithm pairs that the server is +# able to verify, listed in descending order of preference. +# +# certificate_authorities +# A list of the distinguished names [X501] of acceptable +# certificate_authorities, represented in DER-encoded format. These +# distinguished names may specify a desired distinguished name for a +# root CA or for a subordinate CA; thus, this message can be used to +# describe known roots as well as a desired authorization space. If +# the certificate_authorities list is empty, then the client MAY +# send any certificate of the appropriate ClientCertificateType, +# unless there is some external arrangement to the contrary. +# +# The interaction of the certificate_types and +# supported_signature_algorithms fields is somewhat complicated. +# certificate_types has been present in TLS since SSLv3, but was +# somewhat underspecified. Much of its functionality is superseded by +# supported_signature_algorithms. The following rules apply: +# +# - Any certificates provided by the client MUST be signed using a +# hash/signature algorithm pair found in +# supported_signature_algorithms. +# +# - The end-entity certificate provided by the client MUST contain a +# key that is compatible with certificate_types. If the key is a +# signature key, it MUST be usable with some hash/signature +# algorithm pair in supported_signature_algorithms. +# +# - For historical reasons, the names of some client certificate types +# include the algorithm used to sign the certificate. For example, +# in earlier versions of TLS, rsa_fixed_dh meant a certificate +# signed with RSA and containing a static DH key. In TLS 1.2, this +# functionality has been obsoleted by the +# supported_signature_algorithms, and the certificate type no longer +# restricts the algorithm used to sign the certificate. For +# example, if the server sends dss_fixed_dh certificate type and +# {{sha1, dsa}, {sha1, rsa}} signature types, the client MAY reply +# with a certificate containing a static DH key, signed with RSA- +# SHA1. +# +# New ClientCertificateType values are assigned by IANA as described in +# Section 12. +# +# Note: Values listed as RESERVED may not be used. They were used in +# SSLv3. +# +# Note: It is a fatal handshake_failure alert for an anonymous server +# to request client authentication. [[spec]] level = "MAY" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-7.4.5.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-7.4.5.toml index 0e224dddb5f..9e5317a6852 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-7.4.5.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-7.4.5.toml @@ -1,26 +1,26 @@ target = "https://www.rfc-editor.org/rfc/rfc5246#section-7.4.5" -# 7.4.5. Server Hello Done +# Server Hello Done # -# When this message will be sent: +# When this message will be sent: # -# The ServerHelloDone message is sent by the server to indicate the -# end of the ServerHello and associated messages. After sending -# this message, the server will wait for a client response. +# The ServerHelloDone message is sent by the server to indicate the +# end of the ServerHello and associated messages. After sending +# this message, the server will wait for a client response. # -# Meaning of this message: +# Meaning of this message: # -# This message means that the server is done sending messages to -# support the key exchange, and the client can proceed with its -# phase of the key exchange. +# This message means that the server is done sending messages to +# support the key exchange, and the client can proceed with its +# phase of the key exchange. # -# Upon receipt of the ServerHelloDone message, the client SHOULD -# verify that the server provided a valid certificate, if required, -# and check that the server hello parameters are acceptable. +# Upon receipt of the ServerHelloDone message, the client SHOULD +# verify that the server provided a valid certificate, if required, +# and check that the server hello parameters are acceptable. # -# Structure of this message: +# Structure of this message: # -# struct { } ServerHelloDone; +# struct { } ServerHelloDone; [[spec]] level = "SHOULD" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-7.4.6.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-7.4.6.toml index 063be843a2f..15898b2c0a4 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-7.4.6.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-7.4.6.toml @@ -1,82 +1,82 @@ target = "https://www.rfc-editor.org/rfc/rfc5246#section-7.4.6" -# 7.4.6. Client Certificate +# Client Certificate # -# When this message will be sent: -# -# This is the first message the client can send after receiving a -# ServerHelloDone message. This message is only sent if the server -# requests a certificate. If no suitable certificate is available, -# the client MUST send a certificate message containing no -# certificates. That is, the certificate_list structure has a -# length of zero. If the client does not send any certificates, the -# server MAY at its discretion either continue the handshake without -# client authentication, or respond with a fatal handshake_failure -# alert. Also, if some aspect of the certificate chain was -# unacceptable (e.g., it was not signed by a known, trusted CA), the -# server MAY at its discretion either continue the handshake -# (considering the client unauthenticated) or send a fatal alert. -# -# Client certificates are sent using the Certificate structure -# defined in Section 7.4.2. -# -# Meaning of this message: -# -# This message conveys the client's certificate chain to the server; -# the server will use it when verifying the CertificateVerify -# message (when the client authentication is based on signing) or -# calculating the premaster secret (for non-ephemeral Diffie- -# Hellman). The certificate MUST be appropriate for the negotiated -# cipher suite's key exchange algorithm, and any negotiated -# extensions. -# -# In particular: -# -# - The certificate type MUST be X.509v3, unless explicitly negotiated -# otherwise (e.g., [TLSPGP]). -# -# - The end-entity certificate's public key (and associated -# restrictions) has to be compatible with the certificate types -# listed in CertificateRequest: -# -# Client Cert. Type Certificate Key Type -# -# rsa_sign RSA public key; the certificate MUST allow the -# key to be used for signing with the signature -# scheme and hash algorithm that will be -# employed in the certificate verify message. -# -# dss_sign DSA public key; the certificate MUST allow the -# key to be used for signing with the hash -# algorithm that will be employed in the -# certificate verify message. -# -# ecdsa_sign ECDSA-capable public key; the certificate MUST -# allow the key to be used for signing with the -# hash algorithm that will be employed in the -# certificate verify message; the public key -# MUST use a curve and point format supported by -# the server. -# -# rsa_fixed_dh Diffie-Hellman public key; MUST use the same -# dss_fixed_dh parameters as server's key. -# -# rsa_fixed_ecdh ECDH-capable public key; MUST use the -# ecdsa_fixed_ecdh same curve as the server's key, and MUST use a -# point format supported by the server. -# -# - If the certificate_authorities list in the certificate request -# message was non-empty, one of the certificates in the certificate -# chain SHOULD be issued by one of the listed CAs. -# -# - The certificates MUST be signed using an acceptable hash/ -# signature algorithm pair, as described in Section 7.4.4. Note -# that this relaxes the constraints on certificate-signing -# algorithms found in prior versions of TLS. -# -# Note that, as with the server certificate, there are certificates -# that use algorithms/algorithm combinations that cannot be currently -# used with TLS. +# When this message will be sent: +# +# This is the first message the client can send after receiving a +# ServerHelloDone message. This message is only sent if the server +# requests a certificate. If no suitable certificate is available, +# the client MUST send a certificate message containing no +# certificates. That is, the certificate_list structure has a +# length of zero. If the client does not send any certificates, the +# server MAY at its discretion either continue the handshake without +# client authentication, or respond with a fatal handshake_failure +# alert. Also, if some aspect of the certificate chain was +# unacceptable (e.g., it was not signed by a known, trusted CA), the +# server MAY at its discretion either continue the handshake +# (considering the client unauthenticated) or send a fatal alert. +# +# Client certificates are sent using the Certificate structure +# defined in Section 7.4.2. +# +# Meaning of this message: +# +# This message conveys the client's certificate chain to the server; +# the server will use it when verifying the CertificateVerify +# message (when the client authentication is based on signing) or +# calculating the premaster secret (for non-ephemeral Diffie- +# Hellman). The certificate MUST be appropriate for the negotiated +# cipher suite's key exchange algorithm, and any negotiated +# extensions. +# +# In particular: +# +# - The certificate type MUST be X.509v3, unless explicitly negotiated +# otherwise (e.g., [TLSPGP]). +# +# - The end-entity certificate's public key (and associated +# restrictions) has to be compatible with the certificate types +# listed in CertificateRequest: +# +# Client Cert. Type Certificate Key Type +# +# rsa_sign RSA public key; the certificate MUST allow the +# key to be used for signing with the signature +# scheme and hash algorithm that will be +# employed in the certificate verify message. +# +# dss_sign DSA public key; the certificate MUST allow the +# key to be used for signing with the hash +# algorithm that will be employed in the +# certificate verify message. +# +# ecdsa_sign ECDSA-capable public key; the certificate MUST +# allow the key to be used for signing with the +# hash algorithm that will be employed in the +# certificate verify message; the public key +# MUST use a curve and point format supported by +# the server. +# +# rsa_fixed_dh Diffie-Hellman public key; MUST use the same +# dss_fixed_dh parameters as server's key. +# +# rsa_fixed_ecdh ECDH-capable public key; MUST use the +# ecdsa_fixed_ecdh same curve as the server's key, and MUST use a +# point format supported by the server. +# +# - If the certificate_authorities list in the certificate request +# message was non-empty, one of the certificates in the certificate +# chain SHOULD be issued by one of the listed CAs. +# +# - The certificates MUST be signed using an acceptable hash/ +# signature algorithm pair, as described in Section 7.4.4. Note +# that this relaxes the constraints on certificate-signing +# algorithms found in prior versions of TLS. +# +# Note that, as with the server certificate, there are certificates +# that use algorithms/algorithm combinations that cannot be currently +# used with TLS. [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-7.4.7.1.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-7.4.7.1.toml index 33a755fb7d2..c85f90379a7 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-7.4.7.1.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-7.4.7.1.toml @@ -1,145 +1,145 @@ target = "https://www.rfc-editor.org/rfc/rfc5246#section-7.4.7.1" -# 7.4.7.1. RSA-Encrypted Premaster Secret Message +# RSA-Encrypted Premaster Secret Message # -# Meaning of this message: -# -# If RSA is being used for key agreement and authentication, the -# client generates a 48-byte premaster secret, encrypts it using the -# public key from the server's certificate, and sends the result in -# an encrypted premaster secret message. This structure is a -# variant of the ClientKeyExchange message and is not a message in -# itself. -# -# Structure of this message: -# -# struct { -# ProtocolVersion client_version; -# opaque random[46]; -# } PreMasterSecret; -# -# client_version -# The latest (newest) version supported by the client. This is -# used to detect version rollback attacks. -# -# random -# 46 securely-generated random bytes. -# -# struct { -# public-key-encrypted PreMasterSecret pre_master_secret; -# } EncryptedPreMasterSecret; -# -# pre_master_secret -# This random value is generated by the client and is used to -# generate the master secret, as specified in Section 8.1. -# -# Note: The version number in the PreMasterSecret is the version -# offered by the client in the ClientHello.client_version, not the -# version negotiated for the connection. This feature is designed to -# prevent rollback attacks. Unfortunately, some old implementations -# use the negotiated version instead, and therefore checking the -# version number may lead to failure to interoperate with such -# incorrect client implementations. -# -# Client implementations MUST always send the correct version number in -# PreMasterSecret. If ClientHello.client_version is TLS 1.1 or higher, -# server implementations MUST check the version number as described in -# the note below. If the version number is TLS 1.0 or earlier, server -# implementations SHOULD check the version number, but MAY have a -# configuration option to disable the check. Note that if the check -# fails, the PreMasterSecret SHOULD be randomized as described below. -# -# Note: Attacks discovered by Bleichenbacher [BLEI] and Klima et al. -# [KPR03] can be used to attack a TLS server that reveals whether a -# particular message, when decrypted, is properly PKCS#1 formatted, -# contains a valid PreMasterSecret structure, or has the correct -# version number. -# -# As described by Klima [KPR03], these vulnerabilities can be avoided -# by treating incorrectly formatted message blocks and/or mismatched -# version numbers in a manner indistinguishable from correctly -# formatted RSA blocks. In other words: -# -# 1. Generate a string R of 46 random bytes -# -# 2. Decrypt the message to recover the plaintext M -# -# 3. If the PKCS#1 padding is not correct, or the length of message -# M is not exactly 48 bytes: -# pre_master_secret = ClientHello.client_version || R -# else If ClientHello.client_version <= TLS 1.0, and version -# number check is explicitly disabled: -# pre_master_secret = M -# else: -# pre_master_secret = ClientHello.client_version || M[2..47] -# -# Note that explicitly constructing the pre_master_secret with the -# ClientHello.client_version produces an invalid master_secret if the -# client has sent the wrong version in the original pre_master_secret. -# -# An alternative approach is to treat a version number mismatch as a -# PKCS-1 formatting error and randomize the premaster secret -# completely: -# -# 1. Generate a string R of 48 random bytes -# -# 2. Decrypt the message to recover the plaintext M -# -# 3. If the PKCS#1 padding is not correct, or the length of message -# M is not exactly 48 bytes: -# pre_master_secret = R -# else If ClientHello.client_version <= TLS 1.0, and version -# number check is explicitly disabled: -# premaster secret = M -# else If M[0..1] != ClientHello.client_version: -# premaster secret = R -# else: -# premaster secret = M -# -# Although no practical attacks against this construction are known, -# Klima et al. [KPR03] describe some theoretical attacks, and therefore -# the first construction described is RECOMMENDED. -# -# In any case, a TLS server MUST NOT generate an alert if processing an -# RSA-encrypted premaster secret message fails, or the version number -# is not as expected. Instead, it MUST continue the handshake with a -# randomly generated premaster secret. It may be useful to log the -# real cause of failure for troubleshooting purposes; however, care -# must be taken to avoid leaking the information to an attacker -# (through, e.g., timing, log files, or other channels.) -# -# The RSAES-OAEP encryption scheme defined in [PKCS1] is more secure -# against the Bleichenbacher attack. However, for maximal -# compatibility with earlier versions of TLS, this specification uses -# the RSAES-PKCS1-v1_5 scheme. No variants of the Bleichenbacher -# attack are known to exist provided that the above recommendations are -# followed. -# -# Implementation note: Public-key-encrypted data is represented as an -# opaque vector <0..2^16-1> (see Section 4.7). Thus, the RSA-encrypted -# PreMasterSecret in a ClientKeyExchange is preceded by two length -# bytes. These bytes are redundant in the case of RSA because the -# EncryptedPreMasterSecret is the only data in the ClientKeyExchange -# and its length can therefore be unambiguously determined. The SSLv3 -# specification was not clear about the encoding of public-key- -# encrypted data, and therefore many SSLv3 implementations do not -# include the length bytes -- they encode the RSA-encrypted data -# directly in the ClientKeyExchange message. -# -# This specification requires correct encoding of the -# EncryptedPreMasterSecret complete with length bytes. The resulting -# PDU is incompatible with many SSLv3 implementations. Implementors -# -# upgrading from SSLv3 MUST modify their implementations to generate -# and accept the correct encoding. Implementors who wish to be -# compatible with both SSLv3 and TLS should make their implementation's -# behavior dependent on the protocol version. -# -# Implementation note: It is now known that remote timing-based attacks -# on TLS are possible, at least when the client and server are on the -# same LAN. Accordingly, implementations that use static RSA keys MUST -# use RSA blinding or some other anti-timing technique, as described in -# [TIMING]. +# Meaning of this message: +# +# If RSA is being used for key agreement and authentication, the +# client generates a 48-byte premaster secret, encrypts it using the +# public key from the server's certificate, and sends the result in +# an encrypted premaster secret message. This structure is a +# variant of the ClientKeyExchange message and is not a message in +# itself. +# +# Structure of this message: +# +# struct { +# ProtocolVersion client_version; +# opaque random[46]; +# } PreMasterSecret; +# +# client_version +# The latest (newest) version supported by the client. This is +# used to detect version rollback attacks. +# +# random +# 46 securely-generated random bytes. +# +# struct { +# public-key-encrypted PreMasterSecret pre_master_secret; +# } EncryptedPreMasterSecret; +# +# pre_master_secret +# This random value is generated by the client and is used to +# generate the master secret, as specified in Section 8.1. +# +# Note: The version number in the PreMasterSecret is the version +# offered by the client in the ClientHello.client_version, not the +# version negotiated for the connection. This feature is designed to +# prevent rollback attacks. Unfortunately, some old implementations +# use the negotiated version instead, and therefore checking the +# version number may lead to failure to interoperate with such +# incorrect client implementations. +# +# Client implementations MUST always send the correct version number in +# PreMasterSecret. If ClientHello.client_version is TLS 1.1 or higher, +# server implementations MUST check the version number as described in +# the note below. If the version number is TLS 1.0 or earlier, server +# implementations SHOULD check the version number, but MAY have a +# configuration option to disable the check. Note that if the check +# fails, the PreMasterSecret SHOULD be randomized as described below. +# +# Note: Attacks discovered by Bleichenbacher [BLEI] and Klima et al. +# [KPR03] can be used to attack a TLS server that reveals whether a +# particular message, when decrypted, is properly PKCS#1 formatted, +# contains a valid PreMasterSecret structure, or has the correct +# version number. +# +# As described by Klima [KPR03], these vulnerabilities can be avoided +# by treating incorrectly formatted message blocks and/or mismatched +# version numbers in a manner indistinguishable from correctly +# formatted RSA blocks. In other words: +# +# 1. Generate a string R of 46 random bytes +# +# 2. Decrypt the message to recover the plaintext M +# +# 3. If the PKCS#1 padding is not correct, or the length of message +# M is not exactly 48 bytes: +# pre_master_secret = ClientHello.client_version || R +# else If ClientHello.client_version <= TLS 1.0, and version +# number check is explicitly disabled: +# pre_master_secret = M +# else: +# pre_master_secret = ClientHello.client_version || M[2..47] +# +# Note that explicitly constructing the pre_master_secret with the +# ClientHello.client_version produces an invalid master_secret if the +# client has sent the wrong version in the original pre_master_secret. +# +# An alternative approach is to treat a version number mismatch as a +# PKCS-1 formatting error and randomize the premaster secret +# completely: +# +# 1. Generate a string R of 48 random bytes +# +# 2. Decrypt the message to recover the plaintext M +# +# 3. If the PKCS#1 padding is not correct, or the length of message +# M is not exactly 48 bytes: +# pre_master_secret = R +# else If ClientHello.client_version <= TLS 1.0, and version +# number check is explicitly disabled: +# premaster secret = M +# else If M[0..1] != ClientHello.client_version: +# premaster secret = R +# else: +# premaster secret = M +# +# Although no practical attacks against this construction are known, +# Klima et al. [KPR03] describe some theoretical attacks, and therefore +# the first construction described is RECOMMENDED. +# +# In any case, a TLS server MUST NOT generate an alert if processing an +# RSA-encrypted premaster secret message fails, or the version number +# is not as expected. Instead, it MUST continue the handshake with a +# randomly generated premaster secret. It may be useful to log the +# real cause of failure for troubleshooting purposes; however, care +# must be taken to avoid leaking the information to an attacker +# (through, e.g., timing, log files, or other channels.) +# +# The RSAES-OAEP encryption scheme defined in [PKCS1] is more secure +# against the Bleichenbacher attack. However, for maximal +# compatibility with earlier versions of TLS, this specification uses +# the RSAES-PKCS1-v1_5 scheme. No variants of the Bleichenbacher +# attack are known to exist provided that the above recommendations are +# followed. +# +# Implementation note: Public-key-encrypted data is represented as an +# opaque vector <0..2^16-1> (see Section 4.7). Thus, the RSA-encrypted +# PreMasterSecret in a ClientKeyExchange is preceded by two length +# bytes. These bytes are redundant in the case of RSA because the +# EncryptedPreMasterSecret is the only data in the ClientKeyExchange +# and its length can therefore be unambiguously determined. The SSLv3 +# specification was not clear about the encoding of public-key- +# encrypted data, and therefore many SSLv3 implementations do not +# include the length bytes -- they encode the RSA-encrypted data +# directly in the ClientKeyExchange message. +# +# This specification requires correct encoding of the +# EncryptedPreMasterSecret complete with length bytes. The resulting +# PDU is incompatible with many SSLv3 implementations. Implementors +# +# upgrading from SSLv3 MUST modify their implementations to generate +# and accept the correct encoding. Implementors who wish to be +# compatible with both SSLv3 and TLS should make their implementation's +# behavior dependent on the protocol version. +# +# Implementation note: It is now known that remote timing-based attacks +# on TLS are possible, at least when the client and server are on the +# same LAN. Accordingly, implementations that use static RSA keys MUST +# use RSA blinding or some other anti-timing technique, as described in +# [TIMING]. [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-7.4.7.2.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-7.4.7.2.toml index 1b64b8c661f..01467aac038 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-7.4.7.2.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-7.4.7.2.toml @@ -1,38 +1,38 @@ target = "https://www.rfc-editor.org/rfc/rfc5246#section-7.4.7.2" -# 7.4.7.2. Client Diffie-Hellman Public Value +# Client Diffie-Hellman Public Value # -# Meaning of this message: +# Meaning of this message: # -# This structure conveys the client's Diffie-Hellman public value -# (Yc) if it was not already included in the client's certificate. -# The encoding used for Yc is determined by the enumerated -# PublicValueEncoding. This structure is a variant of the client -# key exchange message, and not a message in itself. +# This structure conveys the client's Diffie-Hellman public value +# (Yc) if it was not already included in the client's certificate. +# The encoding used for Yc is determined by the enumerated +# PublicValueEncoding. This structure is a variant of the client +# key exchange message, and not a message in itself. # -# Structure of this message: +# Structure of this message: # -# enum { implicit, explicit } PublicValueEncoding; +# enum { implicit, explicit } PublicValueEncoding; # -# implicit -# If the client has sent a certificate which contains a suitable -# Diffie-Hellman key (for fixed_dh client authentication), then -# Yc is implicit and does not need to be sent again. In this -# case, the client key exchange message will be sent, but it MUST -# be empty. +# implicit +# If the client has sent a certificate which contains a suitable +# Diffie-Hellman key (for fixed_dh client authentication), then +# Yc is implicit and does not need to be sent again. In this +# case, the client key exchange message will be sent, but it MUST +# be empty. # -# explicit -# Yc needs to be sent. +# explicit +# Yc needs to be sent. # -# struct { -# select (PublicValueEncoding) { -# case implicit: struct { }; -# case explicit: opaque dh_Yc<1..2^16-1>; -# } dh_public; -# } ClientDiffieHellmanPublic; +# struct { +# select (PublicValueEncoding) { +# case implicit: struct { }; +# case explicit: opaque dh_Yc<1..2^16-1>; +# } dh_public; +# } ClientDiffieHellmanPublic; # -# dh_Yc -# The client's Diffie-Hellman public value (Yc). +# dh_Yc +# The client's Diffie-Hellman public value (Yc). [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-7.4.7.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-7.4.7.toml index 03a9c35459f..f218cb55bd2 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-7.4.7.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-7.4.7.toml @@ -1,45 +1,45 @@ target = "https://www.rfc-editor.org/rfc/rfc5246#section-7.4.7" -# 7.4.7. Client Key Exchange Message +# Client Key Exchange Message # -# When this message will be sent: +# When this message will be sent: # -# This message is always sent by the client. It MUST immediately -# follow the client certificate message, if it is sent. Otherwise, -# it MUST be the first message sent by the client after it receives -# the ServerHelloDone message. +# This message is always sent by the client. It MUST immediately +# follow the client certificate message, if it is sent. Otherwise, +# it MUST be the first message sent by the client after it receives +# the ServerHelloDone message. # -# Meaning of this message: +# Meaning of this message: # -# With this message, the premaster secret is set, either by direct -# transmission of the RSA-encrypted secret or by the transmission of -# Diffie-Hellman parameters that will allow each side to agree upon -# the same premaster secret. +# With this message, the premaster secret is set, either by direct +# transmission of the RSA-encrypted secret or by the transmission of +# Diffie-Hellman parameters that will allow each side to agree upon +# the same premaster secret. # -# When the client is using an ephemeral Diffie-Hellman exponent, -# then this message contains the client's Diffie-Hellman public -# value. If the client is sending a certificate containing a static -# DH exponent (i.e., it is doing fixed_dh client authentication), -# then this message MUST be sent but MUST be empty. +# When the client is using an ephemeral Diffie-Hellman exponent, +# then this message contains the client's Diffie-Hellman public +# value. If the client is sending a certificate containing a static +# DH exponent (i.e., it is doing fixed_dh client authentication), +# then this message MUST be sent but MUST be empty. # -# Structure of this message: +# Structure of this message: # -# The choice of messages depends on which key exchange method has -# been selected. See Section 7.4.3 for the KeyExchangeAlgorithm -# definition. +# The choice of messages depends on which key exchange method has +# been selected. See Section 7.4.3 for the KeyExchangeAlgorithm +# definition. # -# struct { -# select (KeyExchangeAlgorithm) { -# case rsa: -# EncryptedPreMasterSecret; -# case dhe_dss: -# case dhe_rsa: -# case dh_dss: -# case dh_rsa: -# case dh_anon: -# ClientDiffieHellmanPublic; -# } exchange_keys; -# } ClientKeyExchange; +# struct { +# select (KeyExchangeAlgorithm) { +# case rsa: +# EncryptedPreMasterSecret; +# case dhe_dss: +# case dhe_rsa: +# case dh_dss: +# case dh_rsa: +# case dh_anon: +# ClientDiffieHellmanPublic; +# } exchange_keys; +# } ClientKeyExchange; [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-7.4.8.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-7.4.8.toml index 713ab21b149..31dbb7396bc 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-7.4.8.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-7.4.8.toml @@ -1,52 +1,52 @@ target = "https://www.rfc-editor.org/rfc/rfc5246#section-7.4.8" -# 7.4.8. Certificate Verify +# Certificate Verify # -# When this message will be sent: +# When this message will be sent: # -# This message is used to provide explicit verification of a client -# certificate. This message is only sent following a client -# certificate that has signing capability (i.e., all certificates -# except those containing fixed Diffie-Hellman parameters). When -# sent, it MUST immediately follow the client key exchange message. +# This message is used to provide explicit verification of a client +# certificate. This message is only sent following a client +# certificate that has signing capability (i.e., all certificates +# except those containing fixed Diffie-Hellman parameters). When +# sent, it MUST immediately follow the client key exchange message. # -# Structure of this message: +# Structure of this message: # -# struct { -# digitally-signed struct { -# opaque handshake_messages[handshake_messages_length]; -# } -# } CertificateVerify; +# struct { +# digitally-signed struct { +# opaque handshake_messages[handshake_messages_length]; +# } +# } CertificateVerify; # -# Here handshake_messages refers to all handshake messages sent or -# received, starting at client hello and up to, but not including, -# this message, including the type and length fields of the -# handshake messages. This is the concatenation of all the -# Handshake structures (as defined in Section 7.4) exchanged thus -# far. Note that this requires both sides to either buffer the -# messages or compute running hashes for all potential hash -# algorithms up to the time of the CertificateVerify computation. -# Servers can minimize this computation cost by offering a -# restricted set of digest algorithms in the CertificateRequest -# message. +# Here handshake_messages refers to all handshake messages sent or +# received, starting at client hello and up to, but not including, +# this message, including the type and length fields of the +# handshake messages. This is the concatenation of all the +# Handshake structures (as defined in Section 7.4) exchanged thus +# far. Note that this requires both sides to either buffer the +# messages or compute running hashes for all potential hash +# algorithms up to the time of the CertificateVerify computation. +# Servers can minimize this computation cost by offering a +# restricted set of digest algorithms in the CertificateRequest +# message. # -# The hash and signature algorithms used in the signature MUST be -# one of those present in the supported_signature_algorithms field -# of the CertificateRequest message. In addition, the hash and -# signature algorithms MUST be compatible with the key in the -# client's end-entity certificate. RSA keys MAY be used with any -# permitted hash algorithm, subject to restrictions in the -# certificate, if any. +# The hash and signature algorithms used in the signature MUST be +# one of those present in the supported_signature_algorithms field +# of the CertificateRequest message. In addition, the hash and +# signature algorithms MUST be compatible with the key in the +# client's end-entity certificate. RSA keys MAY be used with any +# permitted hash algorithm, subject to restrictions in the +# certificate, if any. # -# Because DSA signatures do not contain any secure indication of -# hash algorithm, there is a risk of hash substitution if multiple -# hashes may be used with any key. Currently, DSA [DSS] may only be -# used with SHA-1. Future revisions of DSS [DSS-3] are expected to -# allow the use of other digest algorithms with DSA, as well as -# guidance as to which digest algorithms should be used with each -# key size. In addition, future revisions of [PKIX] may specify -# mechanisms for certificates to indicate which digest algorithms -# are to be used with DSA. +# Because DSA signatures do not contain any secure indication of +# hash algorithm, there is a risk of hash substitution if multiple +# hashes may be used with any key. Currently, DSA [DSS] may only be +# used with SHA-1. Future revisions of DSS [DSS-3] are expected to +# allow the use of other digest algorithms with DSA, as well as +# guidance as to which digest algorithms should be used with each +# key size. In addition, future revisions of [PKIX] may specify +# mechanisms for certificates to indicate which digest algorithms +# are to be used with DSA. [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-7.4.9.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-7.4.9.toml index c99e0d6adb7..2dd6b7050f6 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-7.4.9.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-7.4.9.toml @@ -1,76 +1,76 @@ target = "https://www.rfc-editor.org/rfc/rfc5246#section-7.4.9" -# 7.4.9. Finished +# Finished # -# When this message will be sent: +# When this message will be sent: # -# A Finished message is always sent immediately after a change -# cipher spec message to verify that the key exchange and -# authentication processes were successful. It is essential that a -# change cipher spec message be received between the other handshake -# messages and the Finished message. +# A Finished message is always sent immediately after a change +# cipher spec message to verify that the key exchange and +# authentication processes were successful. It is essential that a +# change cipher spec message be received between the other handshake +# messages and the Finished message. # -# Meaning of this message: +# Meaning of this message: # -# The Finished message is the first one protected with the just -# negotiated algorithms, keys, and secrets. Recipients of Finished -# messages MUST verify that the contents are correct. Once a side -# has sent its Finished message and received and validated the -# Finished message from its peer, it may begin to send and receive -# application data over the connection. +# The Finished message is the first one protected with the just +# negotiated algorithms, keys, and secrets. Recipients of Finished +# messages MUST verify that the contents are correct. Once a side +# has sent its Finished message and received and validated the +# Finished message from its peer, it may begin to send and receive +# application data over the connection. # -# Structure of this message: +# Structure of this message: # -# struct { -# opaque verify_data[verify_data_length]; -# } Finished; +# struct { +# opaque verify_data[verify_data_length]; +# } Finished; # -# verify_data -# PRF(master_secret, finished_label, Hash(handshake_messages)) -# [0..verify_data_length-1]; +# verify_data +# PRF(master_secret, finished_label, Hash(handshake_messages)) +# [0..verify_data_length-1]; # -# finished_label -# For Finished messages sent by the client, the string -# "client finished". For Finished messages sent by the server, -# the string "server finished". +# finished_label +# For Finished messages sent by the client, the string +# "client finished". For Finished messages sent by the server, +# the string "server finished". # -# Hash denotes a Hash of the handshake messages. For the PRF -# defined in Section 5, the Hash MUST be the Hash used as the basis -# for the PRF. Any cipher suite which defines a different PRF MUST -# also define the Hash to use in the Finished computation. +# Hash denotes a Hash of the handshake messages. For the PRF +# defined in Section 5, the Hash MUST be the Hash used as the basis +# for the PRF. Any cipher suite which defines a different PRF MUST +# also define the Hash to use in the Finished computation. # -# In previous versions of TLS, the verify_data was always 12 octets -# long. In the current version of TLS, it depends on the cipher -# suite. Any cipher suite which does not explicitly specify -# verify_data_length has a verify_data_length equal to 12. This -# includes all existing cipher suites. Note that this -# representation has the same encoding as with previous versions. -# Future cipher suites MAY specify other lengths but such length -# MUST be at least 12 bytes. +# In previous versions of TLS, the verify_data was always 12 octets +# long. In the current version of TLS, it depends on the cipher +# suite. Any cipher suite which does not explicitly specify +# verify_data_length has a verify_data_length equal to 12. This +# includes all existing cipher suites. Note that this +# representation has the same encoding as with previous versions. +# Future cipher suites MAY specify other lengths but such length +# MUST be at least 12 bytes. # -# handshake_messages -# All of the data from all messages in this handshake (not -# including any HelloRequest messages) up to, but not including, -# this message. This is only data visible at the handshake layer -# and does not include record layer headers. This is the -# concatenation of all the Handshake structures as defined in -# Section 7.4, exchanged thus far. +# handshake_messages +# All of the data from all messages in this handshake (not +# including any HelloRequest messages) up to, but not including, +# this message. This is only data visible at the handshake layer +# and does not include record layer headers. This is the +# concatenation of all the Handshake structures as defined in +# Section 7.4, exchanged thus far. # -# It is a fatal error if a Finished message is not preceded by a -# ChangeCipherSpec message at the appropriate point in the handshake. +# It is a fatal error if a Finished message is not preceded by a +# ChangeCipherSpec message at the appropriate point in the handshake. # -# The value handshake_messages includes all handshake messages starting -# at ClientHello up to, but not including, this Finished message. This -# may be different from handshake_messages in Section 7.4.8 because it -# would include the CertificateVerify message (if sent). Also, the -# handshake_messages for the Finished message sent by the client will -# be different from that for the Finished message sent by the server, -# because the one that is sent second will include the prior one. +# The value handshake_messages includes all handshake messages starting +# at ClientHello up to, but not including, this Finished message. This +# may be different from handshake_messages in Section 7.4.8 because it +# would include the CertificateVerify message (if sent). Also, the +# handshake_messages for the Finished message sent by the client will +# be different from that for the Finished message sent by the server, +# because the one that is sent second will include the prior one. # -# Note: ChangeCipherSpec messages, alerts, and any other record types -# are not handshake messages and are not included in the hash -# computations. Also, HelloRequest messages are omitted from handshake -# hashes. +# Note: ChangeCipherSpec messages, alerts, and any other record types +# are not handshake messages and are not included in the hash +# computations. Also, HelloRequest messages are omitted from handshake +# hashes. [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-7.4.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-7.4.toml index a2ef98b1b1d..98b9a87c983 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-7.4.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-7.4.toml @@ -1,52 +1,52 @@ target = "https://www.rfc-editor.org/rfc/rfc5246#section-7.4" -# 7.4. Handshake Protocol +# Handshake Protocol # -# The TLS Handshake Protocol is one of the defined higher-level clients -# of the TLS Record Protocol. This protocol is used to negotiate the -# secure attributes of a session. Handshake messages are supplied to -# the TLS record layer, where they are encapsulated within one or more -# TLSPlaintext structures, which are processed and transmitted as -# specified by the current active session state. +# The TLS Handshake Protocol is one of the defined higher-level clients +# of the TLS Record Protocol. This protocol is used to negotiate the +# secure attributes of a session. Handshake messages are supplied to +# the TLS record layer, where they are encapsulated within one or more +# TLSPlaintext structures, which are processed and transmitted as +# specified by the current active session state. # -# enum { -# hello_request(0), client_hello(1), server_hello(2), -# certificate(11), server_key_exchange (12), -# certificate_request(13), server_hello_done(14), -# certificate_verify(15), client_key_exchange(16), -# finished(20), (255) -# } HandshakeType; +# enum { +# hello_request(0), client_hello(1), server_hello(2), +# certificate(11), server_key_exchange (12), +# certificate_request(13), server_hello_done(14), +# certificate_verify(15), client_key_exchange(16), +# finished(20), (255) +# } HandshakeType; # -# struct { -# HandshakeType msg_type; /* handshake type */ -# uint24 length; /* bytes in message */ -# select (HandshakeType) { -# case hello_request: HelloRequest; -# case client_hello: ClientHello; -# case server_hello: ServerHello; -# case certificate: Certificate; -# case server_key_exchange: ServerKeyExchange; -# case certificate_request: CertificateRequest; -# case server_hello_done: ServerHelloDone; -# case certificate_verify: CertificateVerify; -# case client_key_exchange: ClientKeyExchange; -# case finished: Finished; -# } body; -# } Handshake; +# struct { +# HandshakeType msg_type; /* handshake type */ +# uint24 length; /* bytes in message */ +# select (HandshakeType) { +# case hello_request: HelloRequest; +# case client_hello: ClientHello; +# case server_hello: ServerHello; +# case certificate: Certificate; +# case server_key_exchange: ServerKeyExchange; +# case certificate_request: CertificateRequest; +# case server_hello_done: ServerHelloDone; +# case certificate_verify: CertificateVerify; +# case client_key_exchange: ClientKeyExchange; +# case finished: Finished; +# } body; +# } Handshake; # -# The handshake protocol messages are presented below in the order they -# MUST be sent; sending handshake messages in an unexpected order -# results in a fatal error. Unneeded handshake messages can be -# omitted, however. Note one exception to the ordering: the -# Certificate message is used twice in the handshake (from server to -# client, then from client to server), but described only in its first -# position. The one message that is not bound by these ordering rules -# is the HelloRequest message, which can be sent at any time, but which -# SHOULD be ignored by the client if it arrives in the middle of a -# handshake. +# The handshake protocol messages are presented below in the order they +# MUST be sent; sending handshake messages in an unexpected order +# results in a fatal error. Unneeded handshake messages can be +# omitted, however. Note one exception to the ordering: the +# Certificate message is used twice in the handshake (from server to +# client, then from client to server), but described only in its first +# position. The one message that is not bound by these ordering rules +# is the HelloRequest message, which can be sent at any time, but which +# SHOULD be ignored by the client if it arrives in the middle of a +# handshake. # -# New handshake message types are assigned by IANA as described in -# Section 12. +# New handshake message types are assigned by IANA as described in +# Section 12. [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-9.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-9.toml index 2892209fd75..0b15d82587a 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-9.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc5246/section-9.toml @@ -1,11 +1,11 @@ target = "https://www.rfc-editor.org/rfc/rfc5246#section-9" -# 9. Mandatory Cipher Suites +# Mandatory Cipher Suites # -# In the absence of an application profile standard specifying -# otherwise, a TLS-compliant application MUST implement the cipher -# suite TLS_RSA_WITH_AES_128_CBC_SHA (see Appendix A.5 for the -# definition). +# In the absence of an application profile standard specifying +# otherwise, a TLS-compliant application MUST implement the cipher +# suite TLS_RSA_WITH_AES_128_CBC_SHA (see Appendix A.5 for the +# definition). [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc5746/section-3.4.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc5746/section-3.4.toml index 5980a1269a7..036dc7d42fc 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc5746/section-3.4.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc5746/section-3.4.toml @@ -1,35 +1,35 @@ target = "https://www.rfc-editor.org/rfc/rfc5746#section-3.4" -# 3.4. Client Behavior: Initial Handshake +# Client Behavior: Initial Handshake # -# Note that this section and Section 3.5 apply to both full handshakes -# and session resumption handshakes. +# Note that this section and Section 3.5 apply to both full handshakes +# and session resumption handshakes. # -# o The client MUST include either an empty "renegotiation_info" -# extension, or the TLS_EMPTY_RENEGOTIATION_INFO_SCSV signaling -# cipher suite value in the ClientHello. Including both is NOT -# RECOMMENDED. +# o The client MUST include either an empty "renegotiation_info" +# extension, or the TLS_EMPTY_RENEGOTIATION_INFO_SCSV signaling +# cipher suite value in the ClientHello. Including both is NOT +# RECOMMENDED. # -# o When a ServerHello is received, the client MUST check if it -# includes the "renegotiation_info" extension: +# o When a ServerHello is received, the client MUST check if it +# includes the "renegotiation_info" extension: # -# * If the extension is not present, the server does not support -# secure renegotiation; set secure_renegotiation flag to FALSE. -# In this case, some clients may want to terminate the handshake -# instead of continuing; see Section 4.1 for discussion. +# * If the extension is not present, the server does not support +# secure renegotiation; set secure_renegotiation flag to FALSE. +# In this case, some clients may want to terminate the handshake +# instead of continuing; see Section 4.1 for discussion. # -# * If the extension is present, set the secure_renegotiation flag -# to TRUE. The client MUST then verify that the length of the -# "renegotiated_connection" field is zero, and if it is not, MUST -# abort the handshake (by sending a fatal handshake_failure -# alert). +# * If the extension is present, set the secure_renegotiation flag +# to TRUE. The client MUST then verify that the length of the +# "renegotiated_connection" field is zero, and if it is not, MUST +# abort the handshake (by sending a fatal handshake_failure +# alert). # -# Note: later in Section 3, "abort the handshake" is used as -# shorthand for "send a fatal handshake_failure alert and -# terminate the connection". +# Note: later in Section 3, "abort the handshake" is used as +# shorthand for "send a fatal handshake_failure alert and +# terminate the connection". # -# o When the handshake has completed, the client needs to save the -# client_verify_data and server_verify_data values for future use. +# o When the handshake has completed, the client needs to save the +# client_verify_data and server_verify_data values for future use. [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc5746/section-3.5.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc5746/section-3.5.toml index ee68f5e4951..04b89cda853 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc5746/section-3.5.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc5746/section-3.5.toml @@ -1,26 +1,26 @@ target = "https://www.rfc-editor.org/rfc/rfc5746#section-3.5" -# 3.5. Client Behavior: Secure Renegotiation +# Client Behavior: Secure Renegotiation # -# This text applies if the connection's "secure_renegotiation" flag is -# set to TRUE (if it is set to FALSE, see Section 4.2). +# This text applies if the connection's "secure_renegotiation" flag is +# set to TRUE (if it is set to FALSE, see Section 4.2). # -# o The client MUST include the "renegotiation_info" extension in the -# ClientHello, containing the saved client_verify_data. The SCSV -# MUST NOT be included. +# o The client MUST include the "renegotiation_info" extension in the +# ClientHello, containing the saved client_verify_data. The SCSV +# MUST NOT be included. # -# o When a ServerHello is received, the client MUST verify that the -# "renegotiation_info" extension is present; if it is not, the -# client MUST abort the handshake. +# o When a ServerHello is received, the client MUST verify that the +# "renegotiation_info" extension is present; if it is not, the +# client MUST abort the handshake. # -# o The client MUST then verify that the first half of the -# "renegotiated_connection" field is equal to the saved -# client_verify_data value, and the second half is equal to the -# saved server_verify_data value. If they are not, the client MUST -# abort the handshake. +# o The client MUST then verify that the first half of the +# "renegotiated_connection" field is equal to the saved +# client_verify_data value, and the second half is equal to the +# saved server_verify_data value. If they are not, the client MUST +# abort the handshake. # -# o When the handshake has completed, the client needs to save the new -# client_verify_data and server_verify_data values. +# o When the handshake has completed, the client needs to save the new +# client_verify_data and server_verify_data values. [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc5746/section-3.6.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc5746/section-3.6.toml index d6007f49883..c1ffbd1d11c 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc5746/section-3.6.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc5746/section-3.6.toml @@ -1,47 +1,47 @@ target = "https://www.rfc-editor.org/rfc/rfc5746#section-3.6" -# 3.6. Server Behavior: Initial Handshake +# Server Behavior: Initial Handshake # -# Note that this section and Section 3.7 apply to both full handshakes -# and session-resumption handshakes. +# Note that this section and Section 3.7 apply to both full handshakes +# and session-resumption handshakes. # -# o When a ClientHello is received, the server MUST check if it -# includes the TLS_EMPTY_RENEGOTIATION_INFO_SCSV SCSV. If it does, -# set the secure_renegotiation flag to TRUE. +# o When a ClientHello is received, the server MUST check if it +# includes the TLS_EMPTY_RENEGOTIATION_INFO_SCSV SCSV. If it does, +# set the secure_renegotiation flag to TRUE. # -# o The server MUST check if the "renegotiation_info" extension is -# included in the ClientHello. If the extension is present, set -# secure_renegotiation flag to TRUE. The server MUST then verify -# that the length of the "renegotiated_connection" field is zero, -# and if it is not, MUST abort the handshake. +# o The server MUST check if the "renegotiation_info" extension is +# included in the ClientHello. If the extension is present, set +# secure_renegotiation flag to TRUE. The server MUST then verify +# that the length of the "renegotiated_connection" field is zero, +# and if it is not, MUST abort the handshake. # -# o If neither the TLS_EMPTY_RENEGOTIATION_INFO_SCSV SCSV nor the -# "renegotiation_info" extension was included, set the -# secure_renegotiation flag to FALSE. In this case, some servers -# may want to terminate the handshake instead of continuing; see -# Section 4.3 for discussion. +# o If neither the TLS_EMPTY_RENEGOTIATION_INFO_SCSV SCSV nor the +# "renegotiation_info" extension was included, set the +# secure_renegotiation flag to FALSE. In this case, some servers +# may want to terminate the handshake instead of continuing; see +# Section 4.3 for discussion. # -# o If the secure_renegotiation flag is set to TRUE, the server MUST -# include an empty "renegotiation_info" extension in the ServerHello -# message. +# o If the secure_renegotiation flag is set to TRUE, the server MUST +# include an empty "renegotiation_info" extension in the ServerHello +# message. # -# o When the handshake has completed, the server needs to save the -# client_verify_data and server_verify_data values for future use. +# o When the handshake has completed, the server needs to save the +# client_verify_data and server_verify_data values for future use. # -# TLS servers implementing this specification MUST ignore any unknown -# extensions offered by the client and they MUST accept version numbers -# higher than their highest version number and negotiate the highest -# common version. These two requirements reiterate preexisting -# requirements in RFC 5246 and are merely stated here in the interest -# of forward compatibility. +# TLS servers implementing this specification MUST ignore any unknown +# extensions offered by the client and they MUST accept version numbers +# higher than their highest version number and negotiate the highest +# common version. These two requirements reiterate preexisting +# requirements in RFC 5246 and are merely stated here in the interest +# of forward compatibility. # -# Note that sending a "renegotiation_info" extension in response to a -# ClientHello containing only the SCSV is an explicit exception to the -# prohibition in RFC 5246, Section 7.4.1.4, on the server sending -# unsolicited extensions and is only allowed because the client is -# signaling its willingness to receive the extension via the -# TLS_EMPTY_RENEGOTIATION_INFO_SCSV SCSV. TLS implementations MUST -# continue to comply with Section 7.4.1.4 for all other extensions. +# Note that sending a "renegotiation_info" extension in response to a +# ClientHello containing only the SCSV is an explicit exception to the +# prohibition in RFC 5246, Section 7.4.1.4, on the server sending +# unsolicited extensions and is only allowed because the client is +# signaling its willingness to receive the extension via the +# TLS_EMPTY_RENEGOTIATION_INFO_SCSV SCSV. TLS implementations MUST +# continue to comply with Section 7.4.1.4 for all other extensions. [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc5746/section-3.7.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc5746/section-3.7.toml index 0f6273021a7..f8fac461bd3 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc5746/section-3.7.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc5746/section-3.7.toml @@ -1,28 +1,28 @@ target = "https://www.rfc-editor.org/rfc/rfc5746#section-3.7" -# 3.7. Server Behavior: Secure Renegotiation +# Server Behavior: Secure Renegotiation # -# This text applies if the connection's "secure_renegotiation" flag is -# set to TRUE (if it is set to FALSE, see Section 4.4). +# This text applies if the connection's "secure_renegotiation" flag is +# set to TRUE (if it is set to FALSE, see Section 4.4). # -# o When a ClientHello is received, the server MUST verify that it -# does not contain the TLS_EMPTY_RENEGOTIATION_INFO_SCSV SCSV. If -# the SCSV is present, the server MUST abort the handshake. +# o When a ClientHello is received, the server MUST verify that it +# does not contain the TLS_EMPTY_RENEGOTIATION_INFO_SCSV SCSV. If +# the SCSV is present, the server MUST abort the handshake. # -# o The server MUST verify that the "renegotiation_info" extension is -# present; if it is not, the server MUST abort the handshake. +# o The server MUST verify that the "renegotiation_info" extension is +# present; if it is not, the server MUST abort the handshake. # -# o The server MUST verify that the value of the -# "renegotiated_connection" field is equal to the saved -# client_verify_data value; if it is not, the server MUST abort the -# handshake. +# o The server MUST verify that the value of the +# "renegotiated_connection" field is equal to the saved +# client_verify_data value; if it is not, the server MUST abort the +# handshake. # -# o The server MUST include a "renegotiation_info" extension -# containing the saved client_verify_data and server_verify_data in -# the ServerHello. +# o The server MUST include a "renegotiation_info" extension +# containing the saved client_verify_data and server_verify_data in +# the ServerHello. # -# o When the handshake has completed, the server needs to save the new -# client_verify_data and server_verify_data values. +# o When the handshake has completed, the server needs to save the new +# client_verify_data and server_verify_data values. [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc5746/section-4.1.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc5746/section-4.1.toml index 0480c45caf0..91c9a340f32 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc5746/section-4.1.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc5746/section-4.1.toml @@ -1,31 +1,31 @@ target = "https://www.rfc-editor.org/rfc/rfc5746#section-4.1" -# 4.1. Client Considerations +# Client Considerations # -# If a client offers the "renegotiation_info" extension or the -# TLS_EMPTY_RENEGOTIATION_INFO_SCSV SCSV and the server does not reply -# with "renegotiation_info" in the ServerHello, then this indicates -# that the server does not support secure renegotiation. Because some -# attacks (see Section 1) look like a single handshake to the client, -# the client cannot determine whether or not the connection is under -# attack. Note, however, that merely because the server does not -# acknowledge the extension does not mean that it is vulnerable; it -# might choose to reject all renegotiations and simply not signal it. -# However, it is not possible for the client to determine purely via -# TLS mechanisms whether or not this is the case. +# If a client offers the "renegotiation_info" extension or the +# TLS_EMPTY_RENEGOTIATION_INFO_SCSV SCSV and the server does not reply +# with "renegotiation_info" in the ServerHello, then this indicates +# that the server does not support secure renegotiation. Because some +# attacks (see Section 1) look like a single handshake to the client, +# the client cannot determine whether or not the connection is under +# attack. Note, however, that merely because the server does not +# acknowledge the extension does not mean that it is vulnerable; it +# might choose to reject all renegotiations and simply not signal it. +# However, it is not possible for the client to determine purely via +# TLS mechanisms whether or not this is the case. # -# If clients wish to ensure that such attacks are impossible, they need -# to terminate the connection immediately upon failure to receive the -# extension without completing the handshake. Such clients MUST -# generate a fatal "handshake_failure" alert prior to terminating the -# connection. However, it is expected that many TLS servers that do -# not support renegotiation (and thus are not vulnerable) will not -# support this extension either, so in general, clients that implement -# this behavior will encounter interoperability problems. There is no -# set of client behaviors that will guarantee security and achieve -# maximum interoperability during the transition period. Clients need -# to choose one or the other preference when dealing with potentially -# un-upgraded servers. +# If clients wish to ensure that such attacks are impossible, they need +# to terminate the connection immediately upon failure to receive the +# extension without completing the handshake. Such clients MUST +# generate a fatal "handshake_failure" alert prior to terminating the +# connection. However, it is expected that many TLS servers that do +# not support renegotiation (and thus are not vulnerable) will not +# support this extension either, so in general, clients that implement +# this behavior will encounter interoperability problems. There is no +# set of client behaviors that will guarantee security and achieve +# maximum interoperability during the transition period. Clients need +# to choose one or the other preference when dealing with potentially +# un-upgraded servers. [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc5746/section-4.2.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc5746/section-4.2.toml index 72b4c9d11fb..1fe419730c0 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc5746/section-4.2.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc5746/section-4.2.toml @@ -1,46 +1,46 @@ target = "https://www.rfc-editor.org/rfc/rfc5746#section-4.2" -# 4.2. Client Behavior: Legacy (Insecure) Renegotiation +# Client Behavior: Legacy (Insecure) Renegotiation # -# This text applies if the connection's "secure_renegotiation" flag is -# set to FALSE. +# This text applies if the connection's "secure_renegotiation" flag is +# set to FALSE. # -# It is possible that un-upgraded servers will request that the client -# renegotiate. It is RECOMMENDED that clients refuse this -# renegotiation request. Clients that do so MUST respond to such -# requests with a "no_renegotiation" alert (RFC 5246 requires this -# alert to be at the "warning" level). It is possible that the -# apparently un-upgraded server is in fact an attacker who is then -# allowing the client to renegotiate with a different, legitimate, -# upgraded server. If clients nevertheless choose to renegotiate, they -# MUST behave as described below. +# It is possible that un-upgraded servers will request that the client +# renegotiate. It is RECOMMENDED that clients refuse this +# renegotiation request. Clients that do so MUST respond to such +# requests with a "no_renegotiation" alert (RFC 5246 requires this +# alert to be at the "warning" level). It is possible that the +# apparently un-upgraded server is in fact an attacker who is then +# allowing the client to renegotiate with a different, legitimate, +# upgraded server. If clients nevertheless choose to renegotiate, they +# MUST behave as described below. # -# Clients that choose to renegotiate MUST provide either the -# TLS_EMPTY_RENEGOTIATION_INFO_SCSV SCSV or "renegotiation_info" in -# their ClientHello. In a legitimate renegotiation with an un-upgraded -# server, that server should ignore both of these signals. However, if -# the server (incorrectly) fails to ignore extensions, sending the -# "renegotiation_info" extension may cause a handshake failure. Thus, -# it is permitted, though NOT RECOMMENDED, for the client to simply -# send the SCSV. This is the only situation in which clients are -# permitted to not send the "renegotiation_info" extension in a -# ClientHello that is used for renegotiation. +# Clients that choose to renegotiate MUST provide either the +# TLS_EMPTY_RENEGOTIATION_INFO_SCSV SCSV or "renegotiation_info" in +# their ClientHello. In a legitimate renegotiation with an un-upgraded +# server, that server should ignore both of these signals. However, if +# the server (incorrectly) fails to ignore extensions, sending the +# "renegotiation_info" extension may cause a handshake failure. Thus, +# it is permitted, though NOT RECOMMENDED, for the client to simply +# send the SCSV. This is the only situation in which clients are +# permitted to not send the "renegotiation_info" extension in a +# ClientHello that is used for renegotiation. # -# Note that in the case of a downgrade attack, if this is an initial -# handshake from the server's perspective, then use of the SCSV from -# the client precludes detection of this attack by the server (if this -# is a renegotiation from the server's perspective, then it will detect -# the attack). However, the attack will be detected by the client when -# the server sends an empty "renegotiation_info" extension and the -# client is expecting one containing the previous verify_data. By -# contrast, if the client sends the "renegotiation_info" extension, -# then the server will immediately detect the attack. +# Note that in the case of a downgrade attack, if this is an initial +# handshake from the server's perspective, then use of the SCSV from +# the client precludes detection of this attack by the server (if this +# is a renegotiation from the server's perspective, then it will detect +# the attack). However, the attack will be detected by the client when +# the server sends an empty "renegotiation_info" extension and the +# client is expecting one containing the previous verify_data. By +# contrast, if the client sends the "renegotiation_info" extension, +# then the server will immediately detect the attack. # -# When the ServerHello is received, the client MUST verify that it does -# not contain the "renegotiation_info" extension. If it does, the -# client MUST abort the handshake. (Because the server has already -# indicated it does not support secure renegotiation, the only way that -# this can happen is if the server is broken or there is an attack.) +# When the ServerHello is received, the client MUST verify that it does +# not contain the "renegotiation_info" extension. If it does, the +# client MUST abort the handshake. (Because the server has already +# indicated it does not support secure renegotiation, the only way that +# this can happen is if the server is broken or there is an attack.) [[spec]] level = "SHOULD" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc5746/section-4.3.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc5746/section-4.3.toml index a604b1018a0..882f7bc2b1b 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc5746/section-4.3.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc5746/section-4.3.toml @@ -1,24 +1,24 @@ target = "https://www.rfc-editor.org/rfc/rfc5746#section-4.3" -# 4.3. Server Considerations +# Server Considerations # -# If the client does not offer the "renegotiation_info" extension or -# the TLS_EMPTY_RENEGOTIATION_INFO_SCSV SCSV, then this indicates that -# the client does not support secure renegotiation. Although the -# attack described in Section 1 looks like two handshakes to the +# If the client does not offer the "renegotiation_info" extension or +# the TLS_EMPTY_RENEGOTIATION_INFO_SCSV SCSV, then this indicates that +# the client does not support secure renegotiation. Although the +# attack described in Section 1 looks like two handshakes to the # -# server, other attacks may be possible in which the renegotiation is -# seen only by the client. If servers wish to ensure that such attacks -# are impossible, they need to terminate the connection immediately -# upon failure to negotiate the use of secure renegotiation. Servers -# that do choose to allow connections from unpatched clients can still -# prevent the attack described in Section 1 by refusing to renegotiate -# over those connections. +# server, other attacks may be possible in which the renegotiation is +# seen only by the client. If servers wish to ensure that such attacks +# are impossible, they need to terminate the connection immediately +# upon failure to negotiate the use of secure renegotiation. Servers +# that do choose to allow connections from unpatched clients can still +# prevent the attack described in Section 1 by refusing to renegotiate +# over those connections. # -# In order to enable clients to probe, even servers that do not support -# renegotiation MUST implement the minimal version of the extension -# described in this document for initial handshakes, thus signaling -# that they have been upgraded. +# In order to enable clients to probe, even servers that do not support +# renegotiation MUST implement the minimal version of the extension +# described in this document for initial handshakes, thus signaling +# that they have been upgraded. [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc5746/section-4.4.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc5746/section-4.4.toml index 14ee260574a..212b60820f3 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc5746/section-4.4.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc5746/section-4.4.toml @@ -1,20 +1,20 @@ target = "https://www.rfc-editor.org/rfc/rfc5746#section-4.4" -# 4.4. Server Behavior: Legacy (Insecure) Renegotiation +# Server Behavior: Legacy (Insecure) Renegotiation # -# This text applies if the connection's "secure_renegotiation" flag is -# set to FALSE. +# This text applies if the connection's "secure_renegotiation" flag is +# set to FALSE. # -# It is RECOMMENDED that servers not permit legacy renegotiation. If -# servers nevertheless do permit it, they MUST follow the requirements -# in this section. +# It is RECOMMENDED that servers not permit legacy renegotiation. If +# servers nevertheless do permit it, they MUST follow the requirements +# in this section. # -# o When a ClientHello is received, the server MUST verify that it -# does not contain the TLS_EMPTY_RENEGOTIATION_INFO_SCSV SCSV. If -# the SCSV is present, the server MUST abort the handshake. +# o When a ClientHello is received, the server MUST verify that it +# does not contain the TLS_EMPTY_RENEGOTIATION_INFO_SCSV SCSV. If +# the SCSV is present, the server MUST abort the handshake. # -# o The server MUST verify that the "renegotiation_info" extension is -# not present; if it is, the server MUST abort the handshake. +# o The server MUST verify that the "renegotiation_info" extension is +# not present; if it is, the server MUST abort the handshake. [[spec]] level = "SHOULD" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc5746/section-4.5.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc5746/section-4.5.toml index eff798951e1..1705405fc62 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc5746/section-4.5.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc5746/section-4.5.toml @@ -1,27 +1,27 @@ target = "https://www.rfc-editor.org/rfc/rfc5746#section-4.5" -# 4.5. SSLv3 +# SSLv3 # -# While SSLv3 is not a protocol under IETF change control (see -# [SSLv3]), it was the original basis for TLS and most TLS -# implementations also support SSLv3. The IETF encourages SSLv3 -# implementations to adopt the "renegotiation_info" extension and SCSV -# as defined in this document. The semantics of the SCSV and extension -# are identical to TLS stacks except for the size of the verify_data -# values, which are 36 bytes long each. Note that this will require -# adding at least minimal extension processing to such stacks. Clients -# that support SSLv3 and offer secure renegotiation (either via SCSV or -# "renegotiation_info") MUST accept the "renegotiation_info" extension -# from the server, even if the server version is {0x03, 0x00}, and -# behave as described in this specification. TLS servers that support -# secure renegotiation and support SSLv3 MUST accept SCSV or the -# "renegotiation_info" extension and respond as described in this -# specification even if the offered client version is {0x03, 0x00}. -# SSLv3 does not define the "no_renegotiation" alert (and does +# While SSLv3 is not a protocol under IETF change control (see +# [SSLv3]), it was the original basis for TLS and most TLS +# implementations also support SSLv3. The IETF encourages SSLv3 +# implementations to adopt the "renegotiation_info" extension and SCSV +# as defined in this document. The semantics of the SCSV and extension +# are identical to TLS stacks except for the size of the verify_data +# values, which are 36 bytes long each. Note that this will require +# adding at least minimal extension processing to such stacks. Clients +# that support SSLv3 and offer secure renegotiation (either via SCSV or +# "renegotiation_info") MUST accept the "renegotiation_info" extension +# from the server, even if the server version is {0x03, 0x00}, and +# behave as described in this specification. TLS servers that support +# secure renegotiation and support SSLv3 MUST accept SCSV or the +# "renegotiation_info" extension and respond as described in this +# specification even if the offered client version is {0x03, 0x00}. +# SSLv3 does not define the "no_renegotiation" alert (and does # -# not offer a way to indicate a refusal to renegotiate at a "warning" -# level). SSLv3 clients that refuse renegotiation SHOULD use a fatal -# handshake_failure alert. +# not offer a way to indicate a refusal to renegotiate at a "warning" +# level). SSLv3 clients that refuse renegotiation SHOULD use a fatal +# handshake_failure alert. [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc5746/section-5.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc5746/section-5.toml index 3b58bf869c2..dee33ea97a2 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc5746/section-5.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc5746/section-5.toml @@ -1,56 +1,56 @@ target = "https://www.rfc-editor.org/rfc/rfc5746#section-5" -# 5. Security Considerations +# Security Considerations # -# The extension described in this document prevents an attack on TLS. -# If this extension is not used, TLS renegotiation is subject to an -# attack in which the attacker can inject their own conversation with -# the TLS server as a prefix to the client's conversation. This attack -# is invisible to the client and looks like an ordinary renegotiation -# to the server. The extension defined in this document allows -# renegotiation to be performed safely. Servers SHOULD NOT allow -# clients to renegotiate without using this extension. Many servers -# can mitigate this attack simply by refusing to renegotiate at all. +# The extension described in this document prevents an attack on TLS. +# If this extension is not used, TLS renegotiation is subject to an +# attack in which the attacker can inject their own conversation with +# the TLS server as a prefix to the client's conversation. This attack +# is invisible to the client and looks like an ordinary renegotiation +# to the server. The extension defined in this document allows +# renegotiation to be performed safely. Servers SHOULD NOT allow +# clients to renegotiate without using this extension. Many servers +# can mitigate this attack simply by refusing to renegotiate at all. # -# While this extension mitigates the man-in-the-middle attack described -# in the overview, it does not resolve all possible problems an -# application may face if it is unaware of renegotiation. For example, -# during renegotiation, either the client or the server can present a -# different certificate than was used earlier. This may come as a -# surprise to application developers (who might have expected, for -# example, that a "getPeerCertificates()" API call returns the same -# value if called twice), and might be handled in an insecure way. +# While this extension mitigates the man-in-the-middle attack described +# in the overview, it does not resolve all possible problems an +# application may face if it is unaware of renegotiation. For example, +# during renegotiation, either the client or the server can present a +# different certificate than was used earlier. This may come as a +# surprise to application developers (who might have expected, for +# example, that a "getPeerCertificates()" API call returns the same +# value if called twice), and might be handled in an insecure way. # -# TLS implementations SHOULD provide a mechanism to disable and enable -# renegotiation. +# TLS implementations SHOULD provide a mechanism to disable and enable +# renegotiation. # -# TLS implementers are encouraged to clearly document how renegotiation -# interacts with the APIs offered to applications (for example, which -# API calls might return different values on different calls, or which -# callbacks might get called multiple times). +# TLS implementers are encouraged to clearly document how renegotiation +# interacts with the APIs offered to applications (for example, which +# API calls might return different values on different calls, or which +# callbacks might get called multiple times). # -# To make life simpler for applications that use renegotiation but do -# not expect the certificate to change once it has been authenticated, -# TLS implementations may also wish to offer the applications the -# option to abort the renegotiation if the peer tries to authenticate -# with a different certificate and/or different server name (in the -# server_name extension) than was used earlier. TLS implementations -# may alternatively offer the option to disable renegotiation once the -# client certificate has been authenticated. However, enabling these -# options by default for all applications could break existing -# applications that depend on using renegotiation to change from one -# certificate to another. (For example, long-lived TLS connections -# could change to a renewed certificate; or renegotiation could select -# a different cipher suite that requires using a different -# certificate.) +# To make life simpler for applications that use renegotiation but do +# not expect the certificate to change once it has been authenticated, +# TLS implementations may also wish to offer the applications the +# option to abort the renegotiation if the peer tries to authenticate +# with a different certificate and/or different server name (in the +# server_name extension) than was used earlier. TLS implementations +# may alternatively offer the option to disable renegotiation once the +# client certificate has been authenticated. However, enabling these +# options by default for all applications could break existing +# applications that depend on using renegotiation to change from one +# certificate to another. (For example, long-lived TLS connections +# could change to a renewed certificate; or renegotiation could select +# a different cipher suite that requires using a different +# certificate.) # -# Finally, designers of applications that depend on renegotiation are -# reminded that many TLS APIs represent application data as a simple -# octet stream; applications may not be able to determine exactly which -# application data octets were received before, during, or after -# renegotiation. Especially if the peer presents a different -# certificate during renegotiation, care is needed when specifying how -# the application should handle the data. +# Finally, designers of applications that depend on renegotiation are +# reminded that many TLS APIs represent application data as a simple +# octet stream; applications may not be able to determine exactly which +# application data octets were received before, during, or after +# renegotiation. Especially if the peer presents a different +# certificate during renegotiation, care is needed when specifying how +# the application should handle the data. [[spec]] level = "SHOULD" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc5869/section-3.3.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc5869/section-3.3.toml index b825056bb93..ffbbafe6843 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc5869/section-3.3.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc5869/section-3.3.toml @@ -1,32 +1,32 @@ target = "https://www.rfc-editor.org/rfc/rfc5869#section-3.3" -# 3.3. To Skip or not to Skip +# To Skip or not to Skip # -# In some applications, the input key material IKM may already be -# present as a cryptographically strong key (for example, the premaster -# secret in TLS RSA cipher suites would be a pseudorandom string, -# except for the first two octets). In this case, one can skip the -# extract part and use IKM directly to key HMAC in the expand step. On -# the other hand, applications may still use the extract part for the -# sake of compatibility with the general case. In particular, if IKM -# is random (or pseudorandom) but longer than an HMAC key, the extract -# step can serve to output a suitable HMAC key (in the case of HMAC +# In some applications, the input key material IKM may already be +# present as a cryptographically strong key (for example, the premaster +# secret in TLS RSA cipher suites would be a pseudorandom string, +# except for the first two octets). In this case, one can skip the +# extract part and use IKM directly to key HMAC in the expand step. On +# the other hand, applications may still use the extract part for the +# sake of compatibility with the general case. In particular, if IKM +# is random (or pseudorandom) but longer than an HMAC key, the extract +# step can serve to output a suitable HMAC key (in the case of HMAC # -# this shortening via the extractor is not strictly necessary since -# HMAC is defined to work with long keys too). Note, however, that if -# the IKM is a Diffie-Hellman value, as in the case of TLS with Diffie- -# Hellman, then the extract part SHOULD NOT be skipped. Doing so would -# result in using the Diffie-Hellman value g^{xy} itself (which is NOT -# a uniformly random or pseudorandom string) as the key PRK for HMAC. -# Instead, HKDF should apply the extract step to g^{xy} (preferably -# with a salt value) and use the resultant PRK as a key to HMAC in the -# expansion part. +# this shortening via the extractor is not strictly necessary since +# HMAC is defined to work with long keys too). Note, however, that if +# the IKM is a Diffie-Hellman value, as in the case of TLS with Diffie- +# Hellman, then the extract part SHOULD NOT be skipped. Doing so would +# result in using the Diffie-Hellman value g^{xy} itself (which is NOT +# a uniformly random or pseudorandom string) as the key PRK for HMAC. +# Instead, HKDF should apply the extract step to g^{xy} (preferably +# with a salt value) and use the resultant PRK as a key to HMAC in the +# expansion part. # -# In the case where the amount of required key bits, L, is no more than -# HashLen, one could use PRK directly as the OKM. This, however, is -# NOT RECOMMENDED, especially because it would omit the use of 'info' -# as part of the derivation process (and adding 'info' as an input to -# the extract step is not advisable -- see [HKDF-paper]). +# In the case where the amount of required key bits, L, is no more than +# HashLen, one could use PRK directly as the OKM. This, however, is +# NOT RECOMMENDED, especially because it would omit the use of 'info' +# as part of the derivation process (and adding 'info' as an input to +# the extract step is not advisable -- see [HKDF-paper]). [[spec]] level = "SHOULD" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc7627/section-4.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc7627/section-4.toml index 55347102b8e..6e5b375f272 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc7627/section-4.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc7627/section-4.toml @@ -1,39 +1,39 @@ target = "https://www.rfc-editor.org/rfc/rfc7627#section-4" -# 4. The Extended Master Secret +# The Extended Master Secret # -# When the extended master secret extension is negotiated in a full -# handshake, the "master_secret" is computed as +# When the extended master secret extension is negotiated in a full +# handshake, the "master_secret" is computed as # -# master_secret = PRF(pre_master_secret, "extended master secret", -# session_hash) -# [0..47]; +# master_secret = PRF(pre_master_secret, "extended master secret", +# session_hash) +# [0..47]; # -# The extended master secret computation differs from that described in -# [RFC5246] in the following ways: +# The extended master secret computation differs from that described in +# [RFC5246] in the following ways: # -# o The "extended master secret" label is used instead of "master -# secret". +# o The "extended master secret" label is used instead of "master +# secret". # -# o The "session_hash" is used instead of the "ClientHello.random" and -# "ServerHello.random". +# o The "session_hash" is used instead of the "ClientHello.random" and +# "ServerHello.random". # -# The "session_hash" depends upon a handshake log that includes -# "ClientHello.random" and "ServerHello.random", in addition to -# ciphersuites, key exchange information, and certificates (if any) -# from the client and server. Consequently, the extended master secret -# depends upon the choice of all these session parameters. +# The "session_hash" depends upon a handshake log that includes +# "ClientHello.random" and "ServerHello.random", in addition to +# ciphersuites, key exchange information, and certificates (if any) +# from the client and server. Consequently, the extended master secret +# depends upon the choice of all these session parameters. # -# This design reflects the recommendation that keys should be bound to -# the security contexts that compute them [SP800-108]. The technique -# of mixing a hash of the key exchange messages into master key -# derivation is already used in other well-known protocols such as -# Secure Shell (SSH) [RFC4251]. +# This design reflects the recommendation that keys should be bound to +# the security contexts that compute them [SP800-108]. The technique +# of mixing a hash of the key exchange messages into master key +# derivation is already used in other well-known protocols such as +# Secure Shell (SSH) [RFC4251]. # -# Clients and servers SHOULD NOT accept handshakes that do not use the -# extended master secret, especially if they rely on features like -# compound authentication that fall into the vulnerable cases described -# in Section 6.1. +# Clients and servers SHOULD NOT accept handshakes that do not use the +# extended master secret, especially if they rely on features like +# compound authentication that fall into the vulnerable cases described +# in Section 6.1. [[spec]] level = "SHOULD" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc7627/section-5.1.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc7627/section-5.1.toml index bd897b1813b..82625937d14 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc7627/section-5.1.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc7627/section-5.1.toml @@ -1,20 +1,20 @@ target = "https://www.rfc-editor.org/rfc/rfc7627#section-5.1" -# 5.1. Extension Definition +# Extension Definition # -# This document defines a new TLS extension, "extended_master_secret" -# (with extension type 0x0017), which is used to signal both client and -# server to use the extended master secret computation. The -# "extension_data" field of this extension is empty. Thus, the entire -# encoding of the extension is 00 17 00 00 (in hexadecimal.) +# This document defines a new TLS extension, "extended_master_secret" +# (with extension type 0x0017), which is used to signal both client and +# server to use the extended master secret computation. The +# "extension_data" field of this extension is empty. Thus, the entire +# encoding of the extension is 00 17 00 00 (in hexadecimal.) # -# Although this document refers only to TLS, the extension proposed -# here can also be used with Datagram TLS (DTLS) [RFC6347]. +# Although this document refers only to TLS, the extension proposed +# here can also be used with Datagram TLS (DTLS) [RFC6347]. # -# If the client and server agree on this extension and a full handshake -# takes place, both client and server MUST use the extended master -# secret derivation algorithm, as defined in Section 4. All other -# cryptographic computations remain unchanged. +# If the client and server agree on this extension and a full handshake +# takes place, both client and server MUST use the extended master +# secret derivation algorithm, as defined in Section 4. All other +# cryptographic computations remain unchanged. [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc7627/section-5.2.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc7627/section-5.2.toml index 95aec3d635f..11325242a8a 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc7627/section-5.2.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc7627/section-5.2.toml @@ -1,37 +1,37 @@ target = "https://www.rfc-editor.org/rfc/rfc7627#section-5.2" -# 5.2. Client and Server Behavior: Full Handshake +# Client and Server Behavior: Full Handshake # -# In the following, we use the phrase "abort the handshake" as -# shorthand for terminating the handshake by sending a fatal -# "handshake_failure" alert. +# In the following, we use the phrase "abort the handshake" as +# shorthand for terminating the handshake by sending a fatal +# "handshake_failure" alert. # -# In all handshakes, a client implementing this document MUST send the -# "extended_master_secret" extension in its ClientHello. +# In all handshakes, a client implementing this document MUST send the +# "extended_master_secret" extension in its ClientHello. # -# If a server implementing this document receives the -# "extended_master_secret" extension, it MUST include the extension in -# its ServerHello message. +# If a server implementing this document receives the +# "extended_master_secret" extension, it MUST include the extension in +# its ServerHello message. # -# If both the ClientHello and ServerHello contain the extension, the -# new session uses the extended master secret computation. +# If both the ClientHello and ServerHello contain the extension, the +# new session uses the extended master secret computation. # -# If the server receives a ClientHello without the extension, it SHOULD -# abort the handshake if it does not wish to interoperate with legacy -# clients. If it chooses to continue the handshake, then it MUST NOT -# include the extension in the ServerHello. +# If the server receives a ClientHello without the extension, it SHOULD +# abort the handshake if it does not wish to interoperate with legacy +# clients. If it chooses to continue the handshake, then it MUST NOT +# include the extension in the ServerHello. # -# If a client receives a ServerHello without the extension, it SHOULD -# abort the handshake if it does not wish to interoperate with legacy -# servers. +# If a client receives a ServerHello without the extension, it SHOULD +# abort the handshake if it does not wish to interoperate with legacy +# servers. # -# If the client and server choose to continue a full handshake without -# the extension, they MUST use the standard master secret derivation -# for the new session. In this case, the new session is not protected -# by the mechanisms described in this document. So, implementers -# should follow the guidelines in Section 5.4 to avoid dangerous usage -# scenarios. In particular, the master secret derived from the new -# session should not be used for application-level authentication. +# If the client and server choose to continue a full handshake without +# the extension, they MUST use the standard master secret derivation +# for the new session. In this case, the new session is not protected +# by the mechanisms described in this document. So, implementers +# should follow the guidelines in Section 5.4 to avoid dangerous usage +# scenarios. In particular, the master secret derived from the new +# session should not be used for application-level authentication. [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc7627/section-5.3.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc7627/section-5.3.toml index 1fad8cf3694..18f55d3db5e 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc7627/section-5.3.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc7627/section-5.3.toml @@ -1,61 +1,61 @@ target = "https://www.rfc-editor.org/rfc/rfc7627#section-5.3" -# 5.3. Client and Server Behavior: Abbreviated Handshake +# Client and Server Behavior: Abbreviated Handshake # -# The client SHOULD NOT offer an abbreviated handshake to resume a -# session that does not use an extended master secret. Instead, it -# SHOULD offer a full handshake. +# The client SHOULD NOT offer an abbreviated handshake to resume a +# session that does not use an extended master secret. Instead, it +# SHOULD offer a full handshake. # -# If the client chooses to offer an abbreviated handshake even for such -# sessions in order to support legacy insecure resumption, then the -# current connection is not protected by the mechanisms in this -# document. So, the client should follow the guidelines in Section 5.4 +# If the client chooses to offer an abbreviated handshake even for such +# sessions in order to support legacy insecure resumption, then the +# current connection is not protected by the mechanisms in this +# document. So, the client should follow the guidelines in Section 5.4 # -# to avoid dangerous usage scenarios. In particular, renegotiation is -# no longer secure on this connection, even if the client and server -# support the renegotiation indication extension [RFC5746]. +# to avoid dangerous usage scenarios. In particular, renegotiation is +# no longer secure on this connection, even if the client and server +# support the renegotiation indication extension [RFC5746]. # -# When offering an abbreviated handshake, the client MUST send the -# "extended_master_secret" extension in its ClientHello. +# When offering an abbreviated handshake, the client MUST send the +# "extended_master_secret" extension in its ClientHello. # -# If a server receives a ClientHello for an abbreviated handshake -# offering to resume a known previous session, it behaves as follows: +# If a server receives a ClientHello for an abbreviated handshake +# offering to resume a known previous session, it behaves as follows: # -# o If the original session did not use the "extended_master_secret" -# extension but the new ClientHello contains the extension, then the -# server MUST NOT perform the abbreviated handshake. Instead, it -# SHOULD continue with a full handshake (as described in -# Section 5.2) to negotiate a new session. +# o If the original session did not use the "extended_master_secret" +# extension but the new ClientHello contains the extension, then the +# server MUST NOT perform the abbreviated handshake. Instead, it +# SHOULD continue with a full handshake (as described in +# Section 5.2) to negotiate a new session. # -# o If the original session used the "extended_master_secret" -# extension but the new ClientHello does not contain it, the server -# MUST abort the abbreviated handshake. +# o If the original session used the "extended_master_secret" +# extension but the new ClientHello does not contain it, the server +# MUST abort the abbreviated handshake. # -# o If neither the original session nor the new ClientHello uses the -# extension, the server SHOULD abort the handshake. If it continues -# with an abbreviated handshake in order to support legacy insecure -# resumption, the connection is no longer protected by the -# mechanisms in this document, and the server should follow the -# guidelines in Section 5.4. +# o If neither the original session nor the new ClientHello uses the +# extension, the server SHOULD abort the handshake. If it continues +# with an abbreviated handshake in order to support legacy insecure +# resumption, the connection is no longer protected by the +# mechanisms in this document, and the server should follow the +# guidelines in Section 5.4. # -# o If the new ClientHello contains the extension and the server -# chooses to continue the handshake, then the server MUST include -# the "extended_master_secret" extension in its ServerHello message. +# o If the new ClientHello contains the extension and the server +# chooses to continue the handshake, then the server MUST include +# the "extended_master_secret" extension in its ServerHello message. # -# If a client receives a ServerHello that accepts an abbreviated -# handshake, it behaves as follows: +# If a client receives a ServerHello that accepts an abbreviated +# handshake, it behaves as follows: # -# o If the original session did not use the "extended_master_secret" -# extension but the new ServerHello contains the extension, the -# client MUST abort the handshake. +# o If the original session did not use the "extended_master_secret" +# extension but the new ServerHello contains the extension, the +# client MUST abort the handshake. # -# o If the original session used the extension but the new ServerHello -# does not contain the extension, the client MUST abort the -# handshake. +# o If the original session used the extension but the new ServerHello +# does not contain the extension, the client MUST abort the +# handshake. # -# If the client and server continue the abbreviated handshake, they -# derive the connection keys for the new session as usual from the -# master secret of the original session. +# If the client and server continue the abbreviated handshake, they +# derive the connection keys for the new session as usual from the +# master secret of the original session. [[spec]] level = "SHOULD" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc7627/section-5.4.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc7627/section-5.4.toml index 5d29fefa011..ada5c31a19e 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc7627/section-5.4.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc7627/section-5.4.toml @@ -1,42 +1,42 @@ target = "https://www.rfc-editor.org/rfc/rfc7627#section-5.4" -# 5.4. Interoperability Considerations +# Interoperability Considerations # -# To allow interoperability with legacy clients and servers, a TLS peer -# may decide to accept full handshakes that use the legacy master -# secret computation. If so, they need to differentiate between -# sessions that use legacy and extended master secrets by adding a flag -# to the session state. +# To allow interoperability with legacy clients and servers, a TLS peer +# may decide to accept full handshakes that use the legacy master +# secret computation. If so, they need to differentiate between +# sessions that use legacy and extended master secrets by adding a flag +# to the session state. # -# If a client or server chooses to continue with a full handshake -# without the extended master secret extension, then the new session -# becomes vulnerable to the man-in-the-middle key synchronization -# attack described in Section 1. Hence, the client or server MUST NOT -# export any key material based on the new master secret for any -# subsequent application-level authentication. In particular, it MUST -# disable [RFC5705] and any Extensible Authentication Protocol (EAP) -# relying on compound authentication [COMPOUND-AUTH]. +# If a client or server chooses to continue with a full handshake +# without the extended master secret extension, then the new session +# becomes vulnerable to the man-in-the-middle key synchronization +# attack described in Section 1. Hence, the client or server MUST NOT +# export any key material based on the new master secret for any +# subsequent application-level authentication. In particular, it MUST +# disable [RFC5705] and any Extensible Authentication Protocol (EAP) +# relying on compound authentication [COMPOUND-AUTH]. # -# If a client or server chooses to continue an abbreviated handshake to -# resume a session that does not use the extended master secret, then -# the current connection becomes vulnerable to a man-in-the-middle -# handshake log synchronization attack as described in Section 1. -# Hence, the client or server MUST NOT use the current handshake's -# "verify_data" for application-level authentication. In particular, -# the client MUST disable renegotiation and any use of the "tls-unique" -# channel binding [RFC5929] on the current connection. +# If a client or server chooses to continue an abbreviated handshake to +# resume a session that does not use the extended master secret, then +# the current connection becomes vulnerable to a man-in-the-middle +# handshake log synchronization attack as described in Section 1. +# Hence, the client or server MUST NOT use the current handshake's +# "verify_data" for application-level authentication. In particular, +# the client MUST disable renegotiation and any use of the "tls-unique" +# channel binding [RFC5929] on the current connection. # -# If the original session uses an extended master secret but the -# ClientHello or ServerHello in the abbreviated handshake does not -# include the extension, it MAY be safe to continue the abbreviated -# handshake since it is protected by the extended master secret of the -# original session. This scenario may occur, for example, when a -# server that implements this extension establishes a session but the -# session is subsequently resumed at a different server that does not -# support the extension. Since such situations are unusual and likely -# to be the result of transient or inadvertent misconfigurations, this -# document recommends that the client and server MUST abort such -# handshakes. +# If the original session uses an extended master secret but the +# ClientHello or ServerHello in the abbreviated handshake does not +# include the extension, it MAY be safe to continue the abbreviated +# handshake since it is protected by the extended master secret of the +# original session. This scenario may occur, for example, when a +# server that implements this extension establishes a session but the +# session is subsequently resumed at a different server that does not +# support the extension. Since such situations are unusual and likely +# to be the result of transient or inadvertent misconfigurations, this +# document recommends that the client and server MUST abort such +# handshakes. [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc7627/section-6.2.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc7627/section-6.2.toml index 1ed1f325623..b4af969680c 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc7627/section-6.2.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc7627/section-6.2.toml @@ -1,25 +1,25 @@ target = "https://www.rfc-editor.org/rfc/rfc7627#section-6.2" -# 6.2. Cryptographic Properties of the Hash Function +# Cryptographic Properties of the Hash Function # -# The session hashes of two different sessions need to be distinct; -# hence, the "Hash" function used to compute the "session_hash" needs -# to be collision resistant. As such, hash functions such as MD5 or -# SHA1 are NOT RECOMMENDED. +# The session hashes of two different sessions need to be distinct; +# hence, the "Hash" function used to compute the "session_hash" needs +# to be collision resistant. As such, hash functions such as MD5 or +# SHA1 are NOT RECOMMENDED. # -# We observe that the "Hash" function used in the Finished message -# computation already needs to be collision resistant for the -# renegotiation indication extension [RFC5746] to work, because a -# meaningful collision on the handshake messages (and hence on the -# "verify_data") may re-enable the renegotiation attack [Ray09]. +# We observe that the "Hash" function used in the Finished message +# computation already needs to be collision resistant for the +# renegotiation indication extension [RFC5746] to work, because a +# meaningful collision on the handshake messages (and hence on the +# "verify_data") may re-enable the renegotiation attack [Ray09]. # -# The hash function used to compute the session hash depends on the TLS -# protocol version. All current ciphersuites defined for TLS 1.2 use -# SHA256 or better, and so does the session hash. For earlier versions -# of the protocol, only MD5 and SHA1 can be assumed to be supported, -# and this document does not require legacy implementations to add -# support for new hash functions. In these versions, the session hash -# uses the concatenation of MD5 and SHA1, as in the Finished message. +# The hash function used to compute the session hash depends on the TLS +# protocol version. All current ciphersuites defined for TLS 1.2 use +# SHA256 or better, and so does the session hash. For earlier versions +# of the protocol, only MD5 and SHA1 can be assumed to be supported, +# and this document does not require legacy implementations to add +# support for new hash functions. In these versions, the session hash +# uses the concatenation of MD5 and SHA1, as in the Finished message. [[spec]] level = "SHOULD" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc7627/section-6.4.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc7627/section-6.4.toml index f4bdc933d8f..fe2a32e5bd0 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc7627/section-6.4.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc7627/section-6.4.toml @@ -1,19 +1,19 @@ target = "https://www.rfc-editor.org/rfc/rfc7627#section-6.4" -# 6.4. No SSL 3.0 Support +# No SSL 3.0 Support # -# The Secure Sockets Layer (SSL) protocol version 3.0 [RFC6101] is a -# predecessor of the TLS protocol, and it is equally vulnerable to -# triple handshake attacks, alongside other vulnerabilities stemming -# from its use of obsolete cryptographic constructions that are now -# considered weak. SSL 3.0 has been deprecated [RFC7568]. +# The Secure Sockets Layer (SSL) protocol version 3.0 [RFC6101] is a +# predecessor of the TLS protocol, and it is equally vulnerable to +# triple handshake attacks, alongside other vulnerabilities stemming +# from its use of obsolete cryptographic constructions that are now +# considered weak. SSL 3.0 has been deprecated [RFC7568]. # -# The countermeasure described in this document relies on a TLS -# extension and hence cannot be used with SSL 3.0. Clients and servers -# implementing this document SHOULD refuse SSL 3.0 handshakes. If they -# choose to support SSL 3.0, the resulting sessions MUST use the legacy -# master secret computation, and the interoperability considerations of -# Section 5.4 apply. +# The countermeasure described in this document relies on a TLS +# extension and hence cannot be used with SSL 3.0. Clients and servers +# implementing this document SHOULD refuse SSL 3.0 handshakes. If they +# choose to support SSL 3.0, the resulting sessions MUST use the legacy +# master secret computation, and the interoperability considerations of +# Section 5.4 apply. [[spec]] level = "SHOULD" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8422/section-2.1.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8422/section-2.1.toml index d249c828435..d22491ef095 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8422/section-2.1.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8422/section-2.1.toml @@ -1,21 +1,21 @@ target = "https://www.rfc-editor.org/rfc/rfc8422#section-2.1" -# 2.1. ECDHE_ECDSA +# ECDHE_ECDSA # -# In ECDHE_ECDSA, the server's certificate MUST contain an ECDSA- or -# EdDSA-capable public key. +# In ECDHE_ECDSA, the server's certificate MUST contain an ECDSA- or +# EdDSA-capable public key. # -# The server sends its ephemeral ECDH public key and a specification of -# the corresponding curve in the ServerKeyExchange message. These -# parameters MUST be signed with ECDSA or EdDSA using the private key -# corresponding to the public key in the server's Certificate. +# The server sends its ephemeral ECDH public key and a specification of +# the corresponding curve in the ServerKeyExchange message. These +# parameters MUST be signed with ECDSA or EdDSA using the private key +# corresponding to the public key in the server's Certificate. # -# The client generates an ECDH key pair on the same curve as the -# server's ephemeral ECDH key and sends its public key in the -# ClientKeyExchange message. +# The client generates an ECDH key pair on the same curve as the +# server's ephemeral ECDH key and sends its public key in the +# ClientKeyExchange message. # -# Both client and server perform an ECDH operation (see Section 5.10) -# and use the resultant shared secret as the premaster secret. +# Both client and server perform an ECDH operation (see Section 5.10) +# and use the resultant shared secret as the premaster secret. [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8422/section-2.2.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8422/section-2.2.toml index 2fe6ffa7334..87165313114 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8422/section-2.2.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8422/section-2.2.toml @@ -1,11 +1,11 @@ target = "https://www.rfc-editor.org/rfc/rfc8422#section-2.2" -# 2.2. ECDHE_RSA +# ECDHE_RSA # -# This key exchange algorithm is the same as ECDHE_ECDSA except that -# the server's certificate MUST contain an RSA public key authorized -# for signing and the signature in the ServerKeyExchange message must -# be computed with the corresponding RSA private key. +# This key exchange algorithm is the same as ECDHE_ECDSA except that +# the server's certificate MUST contain an RSA public key authorized +# for signing and the signature in the ServerKeyExchange message must +# be computed with the corresponding RSA private key. [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8422/section-2.3.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8422/section-2.3.toml index 9681059a3a8..aaf832b0247 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8422/section-2.3.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8422/section-2.3.toml @@ -1,27 +1,27 @@ target = "https://www.rfc-editor.org/rfc/rfc8422#section-2.3" -# 2.3. ECDH_anon +# ECDH_anon # -# NOTE: Despite the name beginning with "ECDH_" (no E), the key used in -# ECDH_anon is ephemeral just like the key in ECDHE_RSA and -# ECDHE_ECDSA. The naming follows the example of DH_anon, where the -# key is also ephemeral but the name does not reflect it. +# NOTE: Despite the name beginning with "ECDH_" (no E), the key used in +# ECDH_anon is ephemeral just like the key in ECDHE_RSA and +# ECDHE_ECDSA. The naming follows the example of DH_anon, where the +# key is also ephemeral but the name does not reflect it. # -# In ECDH_anon, the server's Certificate, the CertificateRequest, the -# client's Certificate, and the CertificateVerify messages MUST NOT be -# sent. +# In ECDH_anon, the server's Certificate, the CertificateRequest, the +# client's Certificate, and the CertificateVerify messages MUST NOT be +# sent. # -# The server MUST send an ephemeral ECDH public key and a specification -# of the corresponding curve in the ServerKeyExchange message. These -# parameters MUST NOT be signed. +# The server MUST send an ephemeral ECDH public key and a specification +# of the corresponding curve in the ServerKeyExchange message. These +# parameters MUST NOT be signed. # -# The client generates an ECDH key pair on the same curve as the -# server's ephemeral ECDH key and sends its public key in the -# ClientKeyExchange message. +# The client generates an ECDH key pair on the same curve as the +# server's ephemeral ECDH key and sends its public key in the +# ClientKeyExchange message. # -# Both client and server perform an ECDH operation and use the -# resultant shared secret as the premaster secret. All ECDH -# calculations are performed as specified in Section 5.10. +# Both client and server perform an ECDH operation and use the +# resultant shared secret as the premaster secret. All ECDH +# calculations are performed as specified in Section 5.10. [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8422/section-2.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8422/section-2.toml index 0c5dcac1022..27c837ba109 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8422/section-2.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8422/section-2.toml @@ -1,77 +1,77 @@ target = "https://www.rfc-editor.org/rfc/rfc8422#section-2" -# 2. Key Exchange Algorithm +# Key Exchange Algorithm # -# This document defines three new ECC-based key exchange algorithms for -# TLS. All of them use Ephemeral ECDH (ECDHE) to compute the TLS -# premaster secret, and they differ only in the mechanism (if any) used -# to authenticate them. The derivation of the TLS master secret from -# the premaster secret and the subsequent generation of bulk -# encryption/MAC keys and initialization vectors is independent of the -# key exchange algorithm and not impacted by the introduction of ECC. +# This document defines three new ECC-based key exchange algorithms for +# TLS. All of them use Ephemeral ECDH (ECDHE) to compute the TLS +# premaster secret, and they differ only in the mechanism (if any) used +# to authenticate them. The derivation of the TLS master secret from +# the premaster secret and the subsequent generation of bulk +# encryption/MAC keys and initialization vectors is independent of the +# key exchange algorithm and not impacted by the introduction of ECC. # -# Table 1 summarizes the new key exchange algorithms. All of these key -# exchange algorithms provide forward secrecy if and only if fresh -# ephemeral keys are generated and used, and also destroyed after use. +# Table 1 summarizes the new key exchange algorithms. All of these key +# exchange algorithms provide forward secrecy if and only if fresh +# ephemeral keys are generated and used, and also destroyed after use. # -# +-------------+------------------------------------------------+ -# | Algorithm | Description | -# +-------------+------------------------------------------------+ -# | ECDHE_ECDSA | Ephemeral ECDH with ECDSA or EdDSA signatures. | -# | ECDHE_RSA | Ephemeral ECDH with RSA signatures. | -# | ECDH_anon | Anonymous ephemeral ECDH, no signatures. | -# +-------------+------------------------------------------------+ +# +-------------+------------------------------------------------+ +# | Algorithm | Description | +# +-------------+------------------------------------------------+ +# | ECDHE_ECDSA | Ephemeral ECDH with ECDSA or EdDSA signatures. | +# | ECDHE_RSA | Ephemeral ECDH with RSA signatures. | +# | ECDH_anon | Anonymous ephemeral ECDH, no signatures. | +# +-------------+------------------------------------------------+ # -# Table 1: ECC Key Exchange Algorithms +# Table 1: ECC Key Exchange Algorithms # -# These key exchanges are analogous to DHE_DSS, DHE_RSA, and DH_anon, -# respectively. +# These key exchanges are analogous to DHE_DSS, DHE_RSA, and DH_anon, +# respectively. # -# With ECDHE_RSA, a server can reuse its existing RSA certificate and -# easily comply with a constrained client's elliptic curve preferences -# (see Section 4). However, the computational cost incurred by a -# server is higher for ECDHE_RSA than for the traditional RSA key -# exchange, which does not provide forward secrecy. +# With ECDHE_RSA, a server can reuse its existing RSA certificate and +# easily comply with a constrained client's elliptic curve preferences +# (see Section 4). However, the computational cost incurred by a +# server is higher for ECDHE_RSA than for the traditional RSA key +# exchange, which does not provide forward secrecy. # -# The anonymous key exchange algorithm does not provide authentication -# of the server or the client. Like other anonymous TLS key exchanges, -# it is subject to man-in-the-middle attacks. Applications using TLS -# with this algorithm SHOULD provide authentication by other means. +# The anonymous key exchange algorithm does not provide authentication +# of the server or the client. Like other anonymous TLS key exchanges, +# it is subject to man-in-the-middle attacks. Applications using TLS +# with this algorithm SHOULD provide authentication by other means. # -# Client Server -# ------ ------ -# ClientHello --------> -# ServerHello -# Certificate* -# ServerKeyExchange* -# CertificateRequest*+ -# <-------- ServerHelloDone -# Certificate*+ -# ClientKeyExchange -# CertificateVerify*+ -# [ChangeCipherSpec] -# Finished --------> -# [ChangeCipherSpec] -# <-------- Finished -# Application Data <-------> Application Data +# Client Server +# ------ ------ +# ClientHello --------> +# ServerHello +# Certificate* +# ServerKeyExchange* +# CertificateRequest*+ +# <-------- ServerHelloDone +# Certificate*+ +# ClientKeyExchange +# CertificateVerify*+ +# [ChangeCipherSpec] +# Finished --------> +# [ChangeCipherSpec] +# <-------- Finished +# Application Data <-------> Application Data # -# * message is not sent under some conditions -# + message is not sent unless client authentication -# is desired +# * message is not sent under some conditions +# + message is not sent unless client authentication +# is desired # -# Figure 1: Message Flow in a Full TLS 1.2 Handshake +# Figure 1: Message Flow in a Full TLS 1.2 Handshake # -# Figure 1 shows all messages involved in the TLS key establishment -# protocol (aka full handshake). The addition of ECC has direct impact -# only on the ClientHello, the ServerHello, the server's Certificate -# message, the ServerKeyExchange, the ClientKeyExchange, the -# CertificateRequest, the client's Certificate message, and the -# CertificateVerify. Next, we describe the ECC key exchange algorithm -# in greater detail in terms of the content and processing of these -# messages. For ease of exposition, we defer discussion of client -# authentication and associated messages (identified with a '+' in -# Figure 1) until Section 3 and of the optional ECC-specific extensions -# (which impact the Hello messages) until Section 4. +# Figure 1 shows all messages involved in the TLS key establishment +# protocol (aka full handshake). The addition of ECC has direct impact +# only on the ClientHello, the ServerHello, the server's Certificate +# message, the ServerKeyExchange, the ClientKeyExchange, the +# CertificateRequest, the client's Certificate message, and the +# CertificateVerify. Next, we describe the ECC key exchange algorithm +# in greater detail in terms of the content and processing of these +# messages. For ease of exposition, we defer discussion of client +# authentication and associated messages (identified with a '+' in +# Figure 1) until Section 3 and of the optional ECC-specific extensions +# (which impact the Hello messages) until Section 4. [[spec]] level = "SHOULD" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8422/section-3.1.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8422/section-3.1.toml index fc5cf63d49b..92fcf4675e0 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8422/section-3.1.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8422/section-3.1.toml @@ -1,13 +1,13 @@ target = "https://www.rfc-editor.org/rfc/rfc8422#section-3.1" -# 3.1. ECDSA_sign +# ECDSA_sign # -# To use this authentication mechanism, the client MUST possess a -# certificate containing an ECDSA- or EdDSA-capable public key. +# To use this authentication mechanism, the client MUST possess a +# certificate containing an ECDSA- or EdDSA-capable public key. # -# The client proves possession of the private key corresponding to the -# certified key by including a signature in the CertificateVerify -# message as described in Section 5.8. +# The client proves possession of the private key corresponding to the +# certified key by including a signature in the CertificateVerify +# message as described in Section 5.8. [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8422/section-3.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8422/section-3.toml index b7abe6343eb..7d4c9d3cba3 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8422/section-3.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8422/section-3.toml @@ -1,37 +1,37 @@ target = "https://www.rfc-editor.org/rfc/rfc8422#section-3" -# 3. Client Authentication +# Client Authentication # -# This document defines a client authentication mechanism named after -# the type of client certificate involved: ECDSA_sign. The ECDSA_sign -# mechanism is usable with any of the non-anonymous ECC key exchange -# algorithms described in Section 2 as well as other non-anonymous -# (non-ECC) key exchange algorithms defined in TLS. +# This document defines a client authentication mechanism named after +# the type of client certificate involved: ECDSA_sign. The ECDSA_sign +# mechanism is usable with any of the non-anonymous ECC key exchange +# algorithms described in Section 2 as well as other non-anonymous +# (non-ECC) key exchange algorithms defined in TLS. # -# Note that client certificates with EdDSA public keys also use this -# mechanism. +# Note that client certificates with EdDSA public keys also use this +# mechanism. # -# The server can request ECC-based client authentication by including -# this certificate type in its CertificateRequest message. The client -# must check if it possesses a certificate appropriate for the method -# suggested by the server and is willing to use it for authentication. +# The server can request ECC-based client authentication by including +# this certificate type in its CertificateRequest message. The client +# must check if it possesses a certificate appropriate for the method +# suggested by the server and is willing to use it for authentication. # -# If these conditions are not met, the client SHOULD send a client -# Certificate message containing no certificates. In this case, the -# ClientKeyExchange MUST be sent as described in Section 2, and the -# CertificateVerify MUST NOT be sent. If the server requires client -# authentication, it may respond with a fatal handshake failure alert. +# If these conditions are not met, the client SHOULD send a client +# Certificate message containing no certificates. In this case, the +# ClientKeyExchange MUST be sent as described in Section 2, and the +# CertificateVerify MUST NOT be sent. If the server requires client +# authentication, it may respond with a fatal handshake failure alert. # -# If the client has an appropriate certificate and is willing to use it -# for authentication, it must send that certificate in the client's -# Certificate message (as per Section 5.6) and prove possession of the -# private key corresponding to the certified key. The process of -# determining an appropriate certificate and proving possession is -# different for each authentication mechanism and is described below. +# If the client has an appropriate certificate and is willing to use it +# for authentication, it must send that certificate in the client's +# Certificate message (as per Section 5.6) and prove possession of the +# private key corresponding to the certified key. The process of +# determining an appropriate certificate and proving possession is +# different for each authentication mechanism and is described below. # -# NOTE: It is permissible for a server to request (and the client to -# send) a client certificate of a different type than the server -# certificate. +# NOTE: It is permissible for a server to request (and the client to +# send) a client certificate of a different type than the server +# certificate. [[spec]] level = "SHOULD" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8422/section-4.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8422/section-4.toml index b267dc07a94..0365cf8277e 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8422/section-4.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8422/section-4.toml @@ -1,43 +1,43 @@ target = "https://www.rfc-editor.org/rfc/rfc8422#section-4" -# 4. TLS Extensions for ECC +# TLS Extensions for ECC # -# Two TLS extensions are defined in this specification: (i) the -# Supported Elliptic Curves Extension and (ii) the Supported Point -# Formats Extension. These allow negotiating the use of specific -# curves and point formats (e.g., compressed vs. uncompressed, -# respectively) during a handshake starting a new session. These -# extensions are especially relevant for constrained clients that may -# only support a limited number of curves or point formats. They -# follow the general approach outlined in [RFC4366]; message details -# are specified in Section 5. The client enumerates the curves it -# supports and the point formats it can parse by including the -# appropriate extensions in its ClientHello message. The server -# similarly enumerates the point formats it can parse by including an -# extension in its ServerHello message. +# Two TLS extensions are defined in this specification: (i) the +# Supported Elliptic Curves Extension and (ii) the Supported Point +# Formats Extension. These allow negotiating the use of specific +# curves and point formats (e.g., compressed vs. uncompressed, +# respectively) during a handshake starting a new session. These +# extensions are especially relevant for constrained clients that may +# only support a limited number of curves or point formats. They +# follow the general approach outlined in [RFC4366]; message details +# are specified in Section 5. The client enumerates the curves it +# supports and the point formats it can parse by including the +# appropriate extensions in its ClientHello message. The server +# similarly enumerates the point formats it can parse by including an +# extension in its ServerHello message. # -# A TLS client that proposes ECC cipher suites in its ClientHello -# message SHOULD include these extensions. Servers implementing ECC -# cipher suites MUST support these extensions, and when a client uses -# these extensions, servers MUST NOT negotiate the use of an ECC cipher -# suite unless they can complete the handshake while respecting the -# choice of curves specified by the client. This eliminates the -# possibility that a negotiated ECC handshake will be subsequently -# aborted due to a client's inability to deal with the server's EC key. +# A TLS client that proposes ECC cipher suites in its ClientHello +# message SHOULD include these extensions. Servers implementing ECC +# cipher suites MUST support these extensions, and when a client uses +# these extensions, servers MUST NOT negotiate the use of an ECC cipher +# suite unless they can complete the handshake while respecting the +# choice of curves specified by the client. This eliminates the +# possibility that a negotiated ECC handshake will be subsequently +# aborted due to a client's inability to deal with the server's EC key. # -# The client MUST NOT include these extensions in the ClientHello -# message if it does not propose any ECC cipher suites. A client that -# proposes ECC cipher suites may choose not to include these -# extensions. In this case, the server is free to choose any one of -# the elliptic curves or point formats listed in Section 5. That -# section also describes the structure and processing of these -# extensions in greater detail. +# The client MUST NOT include these extensions in the ClientHello +# message if it does not propose any ECC cipher suites. A client that +# proposes ECC cipher suites may choose not to include these +# extensions. In this case, the server is free to choose any one of +# the elliptic curves or point formats listed in Section 5. That +# section also describes the structure and processing of these +# extensions in greater detail. # -# In the case of session resumption, the server simply ignores the -# Supported Elliptic Curves Extension and the Supported Point Formats -# Extension appearing in the current ClientHello message. These -# extensions only play a role during handshakes negotiating a new -# session. +# In the case of session resumption, the server simply ignores the +# Supported Elliptic Curves Extension and the Supported Point Formats +# Extension appearing in the current ClientHello message. These +# extensions only play a role during handshakes negotiating a new +# session. [[spec]] level = "SHOULD" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8422/section-5.1.2.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8422/section-5.1.2.toml index 2373b6177db..567c86fd56a 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8422/section-5.1.2.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8422/section-5.1.2.toml @@ -1,43 +1,43 @@ target = "https://www.rfc-editor.org/rfc/rfc8422#section-5.1.2" -# 5.1.2. Supported Point Formats Extension +# Supported Point Formats Extension # -# enum { -# uncompressed (0), -# deprecated (1..2), -# reserved (248..255) -# } ECPointFormat; -# struct { -# ECPointFormat ec_point_format_list<1..2^8-1> -# } ECPointFormatList; +# enum { +# uncompressed (0), +# deprecated (1..2), +# reserved (248..255) +# } ECPointFormat; +# struct { +# ECPointFormat ec_point_format_list<1..2^8-1> +# } ECPointFormatList; # -# Three point formats were included in the definition of ECPointFormat -# above. This specification deprecates all but the uncompressed point -# format. Implementations of this document MUST support the -# uncompressed format for all of their supported curves and MUST NOT -# support other formats for curves defined in this specification. For -# backwards compatibility purposes, the point format list extension MAY -# still be included and contain exactly one value: the uncompressed -# point format (0). RFC 4492 specified that if this extension is -# missing, it means that only the uncompressed point format is -# supported, so interoperability with implementations that support the -# uncompressed format should work with or without the extension. +# Three point formats were included in the definition of ECPointFormat +# above. This specification deprecates all but the uncompressed point +# format. Implementations of this document MUST support the +# uncompressed format for all of their supported curves and MUST NOT +# support other formats for curves defined in this specification. For +# backwards compatibility purposes, the point format list extension MAY +# still be included and contain exactly one value: the uncompressed +# point format (0). RFC 4492 specified that if this extension is +# missing, it means that only the uncompressed point format is +# supported, so interoperability with implementations that support the +# uncompressed format should work with or without the extension. # -# If the client sends the extension and the extension does not contain -# the uncompressed point format, and the client has used the Supported -# Groups extension to indicate support for any of the curves defined in -# this specification, then the server MUST abort the handshake and -# return an illegal_parameter alert. +# If the client sends the extension and the extension does not contain +# the uncompressed point format, and the client has used the Supported +# Groups extension to indicate support for any of the curves defined in +# this specification, then the server MUST abort the handshake and +# return an illegal_parameter alert. # -# The ECPointFormat name space (now titled "TLS EC Point Formats") is -# maintained by IANA. See Section 9 for information on how new value -# assignments are added. +# The ECPointFormat name space (now titled "TLS EC Point Formats") is +# maintained by IANA. See Section 9 for information on how new value +# assignments are added. # -# A client compliant with this specification that supports no other -# curves MUST send the following octets; note that the first two octets -# indicate the extension type (Supported Point Formats Extension): +# A client compliant with this specification that supports no other +# curves MUST send the following octets; note that the first two octets +# indicate the extension type (Supported Point Formats Extension): # -# 00 0B 00 02 01 00 +# 00 0B 00 02 01 00 [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8422/section-5.1.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8422/section-5.1.toml index b3c7032baea..2e0c6ec115b 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8422/section-5.1.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8422/section-5.1.toml @@ -1,73 +1,73 @@ target = "https://www.rfc-editor.org/rfc/rfc8422#section-5.1" -# 5.1. Client Hello Extensions +# Client Hello Extensions # -# This section specifies two TLS extensions that can be included with -# the ClientHello message as described in [RFC4366]: the Supported -# Elliptic Curves Extension and the Supported Point Formats Extension. +# This section specifies two TLS extensions that can be included with +# the ClientHello message as described in [RFC4366]: the Supported +# Elliptic Curves Extension and the Supported Point Formats Extension. # -# When these extensions are sent: +# When these extensions are sent: # -# The extensions SHOULD be sent along with any ClientHello message that -# proposes ECC cipher suites. +# The extensions SHOULD be sent along with any ClientHello message that +# proposes ECC cipher suites. # -# Meaning of these extensions: +# Meaning of these extensions: # -# These extensions allow a client to enumerate the elliptic curves it -# supports and/or the point formats it can parse. +# These extensions allow a client to enumerate the elliptic curves it +# supports and/or the point formats it can parse. # -# Structure of these extensions: +# Structure of these extensions: # -# The general structure of TLS extensions is described in [RFC4366], -# and this specification adds two types to ExtensionType. +# The general structure of TLS extensions is described in [RFC4366], +# and this specification adds two types to ExtensionType. # -# enum { -# elliptic_curves(10), -# ec_point_formats(11) -# } ExtensionType; +# enum { +# elliptic_curves(10), +# ec_point_formats(11) +# } ExtensionType; # -# o elliptic_curves (Supported Elliptic Curves Extension): Indicates -# the set of elliptic curves supported by the client. For this -# extension, the opaque extension_data field contains -# NamedCurveList. See Section 5.1.1 for details. +# o elliptic_curves (Supported Elliptic Curves Extension): Indicates +# the set of elliptic curves supported by the client. For this +# extension, the opaque extension_data field contains +# NamedCurveList. See Section 5.1.1 for details. # -# o ec_point_formats (Supported Point Formats Extension): Indicates -# the set of point formats that the client can parse. For this -# extension, the opaque extension_data field contains -# ECPointFormatList. See Section 5.1.2 for details. +# o ec_point_formats (Supported Point Formats Extension): Indicates +# the set of point formats that the client can parse. For this +# extension, the opaque extension_data field contains +# ECPointFormatList. See Section 5.1.2 for details. # -# Actions of the sender: +# Actions of the sender: # -# A client that proposes ECC cipher suites in its ClientHello message -# appends these extensions (along with any others), enumerating the -# curves it supports and the point formats it can parse. Clients -# SHOULD send both the Supported Elliptic Curves Extension and the -# Supported Point Formats Extension. If the Supported Point Formats -# Extension is indeed sent, it MUST contain the value 0 (uncompressed) -# as one of the items in the list of point formats. +# A client that proposes ECC cipher suites in its ClientHello message +# appends these extensions (along with any others), enumerating the +# curves it supports and the point formats it can parse. Clients +# SHOULD send both the Supported Elliptic Curves Extension and the +# Supported Point Formats Extension. If the Supported Point Formats +# Extension is indeed sent, it MUST contain the value 0 (uncompressed) +# as one of the items in the list of point formats. # -# Actions of the receiver: +# Actions of the receiver: # -# A server that receives a ClientHello containing one or both of these -# extensions MUST use the client's enumerated capabilities to guide its -# selection of an appropriate cipher suite. One of the proposed ECC -# cipher suites must be negotiated only if the server can successfully -# complete the handshake while using the curves and point formats -# supported by the client (cf. Sections 5.3 and 5.4). +# A server that receives a ClientHello containing one or both of these +# extensions MUST use the client's enumerated capabilities to guide its +# selection of an appropriate cipher suite. One of the proposed ECC +# cipher suites must be negotiated only if the server can successfully +# complete the handshake while using the curves and point formats +# supported by the client (cf. Sections 5.3 and 5.4). # -# NOTE: A server participating in an ECDHE_ECDSA key exchange may use -# different curves for the ECDSA or EdDSA key in its certificate and -# for the ephemeral ECDH key in the ServerKeyExchange message. The -# server MUST consider the extensions in both cases. +# NOTE: A server participating in an ECDHE_ECDSA key exchange may use +# different curves for the ECDSA or EdDSA key in its certificate and +# for the ephemeral ECDH key in the ServerKeyExchange message. The +# server MUST consider the extensions in both cases. # -# If a server does not understand the Supported Elliptic Curves -# Extension, does not understand the Supported Point Formats Extension, -# or is unable to complete the ECC handshake while restricting itself -# to the enumerated curves and point formats, it MUST NOT negotiate the -# use of an ECC cipher suite. Depending on what other cipher suites -# are proposed by the client and supported by the server, this may -# result in a fatal handshake failure alert due to the lack of common -# cipher suites. +# If a server does not understand the Supported Elliptic Curves +# Extension, does not understand the Supported Point Formats Extension, +# or is unable to complete the ECC handshake while restricting itself +# to the enumerated curves and point formats, it MUST NOT negotiate the +# use of an ECC cipher suite. Depending on what other cipher suites +# are proposed by the client and supported by the server, this may +# result in a fatal handshake failure alert due to the lack of common +# cipher suites. [[spec]] level = "SHOULD" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8422/section-5.10.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8422/section-5.10.toml index 934629d02a7..dd6d5844a01 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8422/section-5.10.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8422/section-5.10.toml @@ -1,63 +1,63 @@ target = "https://www.rfc-editor.org/rfc/rfc8422#section-5.10" -# 5.10. ECDH, ECDSA, and RSA Computations +# ECDH, ECDSA, and RSA Computations # -# All ECDH calculations for the NIST curves (including parameter and -# key generation as well as the shared secret calculation) are -# performed according to [IEEE.P1363] using the ECKAS-DH1 scheme with -# the identity map as the Key Derivation Function (KDF) so that the -# premaster secret is the x-coordinate of the ECDH shared secret -# elliptic curve point represented as an octet string. Note that this -# octet string (Z in IEEE 1363 terminology), as output by FE2OSP (Field +# All ECDH calculations for the NIST curves (including parameter and +# key generation as well as the shared secret calculation) are +# performed according to [IEEE.P1363] using the ECKAS-DH1 scheme with +# the identity map as the Key Derivation Function (KDF) so that the +# premaster secret is the x-coordinate of the ECDH shared secret +# elliptic curve point represented as an octet string. Note that this +# octet string (Z in IEEE 1363 terminology), as output by FE2OSP (Field # -# Element to Octet String Conversion Primitive), has constant length -# for any given field; leading zeros found in this octet string MUST -# NOT be truncated. +# Element to Octet String Conversion Primitive), has constant length +# for any given field; leading zeros found in this octet string MUST +# NOT be truncated. # -# (Note that this use of the identity KDF is a technicality. The -# complete picture is that ECDH is employed with a non-trivial KDF -# because TLS does not directly use the premaster secret for anything -# other than for computing the master secret. In TLS 1.0 and 1.1, this -# means that the MD5- and SHA-1-based TLS Pseudorandom Function (PRF) -# serves as a KDF; in TLS 1.2, the KDF is determined by ciphersuite, -# and it is conceivable that future TLS versions or new TLS extensions -# introduced in the future may vary this computation.) +# (Note that this use of the identity KDF is a technicality. The +# complete picture is that ECDH is employed with a non-trivial KDF +# because TLS does not directly use the premaster secret for anything +# other than for computing the master secret. In TLS 1.0 and 1.1, this +# means that the MD5- and SHA-1-based TLS Pseudorandom Function (PRF) +# serves as a KDF; in TLS 1.2, the KDF is determined by ciphersuite, +# and it is conceivable that future TLS versions or new TLS extensions +# introduced in the future may vary this computation.) # -# An ECDHE key exchange using X25519 (curve x25519) goes as follows: -# (1) each party picks a secret key d uniformly at random and computes -# the corresponding public key x = X25519(d, G); (2) parties exchange -# their public keys and compute a shared secret as x_S = X25519(d, -# x_peer); and (3), if either party obtains all-zeroes x_S, it MUST -# abort the handshake (as required by definition of X25519 and X448). -# ECDHE for X448 works similarly, replacing X25519 with X448 and x25519 -# with x448. The derived shared secret is used directly as the -# premaster secret, which is always exactly 32 bytes when ECDHE with -# X25519 is used and 56 bytes when ECDHE with X448 is used. +# An ECDHE key exchange using X25519 (curve x25519) goes as follows: +# (1) each party picks a secret key d uniformly at random and computes +# the corresponding public key x = X25519(d, G); (2) parties exchange +# their public keys and compute a shared secret as x_S = X25519(d, +# x_peer); and (3), if either party obtains all-zeroes x_S, it MUST +# abort the handshake (as required by definition of X25519 and X448). +# ECDHE for X448 works similarly, replacing X25519 with X448 and x25519 +# with x448. The derived shared secret is used directly as the +# premaster secret, which is always exactly 32 bytes when ECDHE with +# X25519 is used and 56 bytes when ECDHE with X448 is used. # -# All ECDSA computations MUST be performed according to ANSI X9.62 or -# its successors. Data to be signed/verified is hashed, and the result -# runs directly through the ECDSA algorithm with no additional hashing. -# A secure hash function such as SHA-256, SHA-384, or SHA-512 from -# [FIPS.180-4] MUST be used. +# All ECDSA computations MUST be performed according to ANSI X9.62 or +# its successors. Data to be signed/verified is hashed, and the result +# runs directly through the ECDSA algorithm with no additional hashing. +# A secure hash function such as SHA-256, SHA-384, or SHA-512 from +# [FIPS.180-4] MUST be used. # -# All EdDSA computations MUST be performed according to [RFC8032] or -# its successors. Data to be signed/verified is run through the EdDSA -# algorithm with no hashing (EdDSA will internally run the data through -# the "prehash" function PH). The context parameter for Ed448 MUST be -# set to the empty string. +# All EdDSA computations MUST be performed according to [RFC8032] or +# its successors. Data to be signed/verified is run through the EdDSA +# algorithm with no hashing (EdDSA will internally run the data through +# the "prehash" function PH). The context parameter for Ed448 MUST be +# set to the empty string. # -# RFC 4492 anticipated the standardization of a mechanism for -# specifying the required hash function in the certificate, perhaps in -# the parameters field of the subjectPublicKeyInfo. Such -# standardization never took place, and as a result, SHA-1 is used in -# TLS 1.1 and earlier (except for EdDSA, which uses identity function). -# TLS 1.2 added a SignatureAndHashAlgorithm parameter to the -# DigitallySigned struct, thus allowing agility in choosing the -# signature hash. EdDSA signatures MUST have HashAlgorithm of 8 -# (Intrinsic). +# RFC 4492 anticipated the standardization of a mechanism for +# specifying the required hash function in the certificate, perhaps in +# the parameters field of the subjectPublicKeyInfo. Such +# standardization never took place, and as a result, SHA-1 is used in +# TLS 1.1 and earlier (except for EdDSA, which uses identity function). +# TLS 1.2 added a SignatureAndHashAlgorithm parameter to the +# DigitallySigned struct, thus allowing agility in choosing the +# signature hash. EdDSA signatures MUST have HashAlgorithm of 8 +# (Intrinsic). # -# All RSA signatures must be generated and verified according to -# Section 7.2 of [RFC8017]. +# All RSA signatures must be generated and verified according to +# Section 7.2 of [RFC8017]. [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8422/section-5.11.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8422/section-5.11.toml index 6a96589f5b4..0f267768766 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8422/section-5.11.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8422/section-5.11.toml @@ -1,22 +1,22 @@ target = "https://www.rfc-editor.org/rfc/rfc8422#section-5.11" -# 5.11. Public Key Validation +# Public Key Validation # -# With the NIST curves, each party MUST validate the public key sent by -# its peer in the ClientKeyExchange and ServerKeyExchange messages. A -# receiving party MUST check that the x and y parameters from the -# peer's public value satisfy the curve equation, y^2 = x^3 + ax + b -# mod p. See Section 2.3 of [Menezes] for details. Failing to do so -# allows attackers to gain information about the private key to the -# point that they may recover the entire private key in a few requests -# if that key is not really ephemeral. +# With the NIST curves, each party MUST validate the public key sent by +# its peer in the ClientKeyExchange and ServerKeyExchange messages. A +# receiving party MUST check that the x and y parameters from the +# peer's public value satisfy the curve equation, y^2 = x^3 + ax + b +# mod p. See Section 2.3 of [Menezes] for details. Failing to do so +# allows attackers to gain information about the private key to the +# point that they may recover the entire private key in a few requests +# if that key is not really ephemeral. # -# With X25519 and X448, a receiving party MUST check whether the -# computed premaster secret is the all-zero value and abort the -# handshake if so, as described in Section 6 of [RFC7748]. +# With X25519 and X448, a receiving party MUST check whether the +# computed premaster secret is the all-zero value and abort the +# handshake if so, as described in Section 6 of [RFC7748]. # -# Ed25519 and Ed448 internally do public key validation as part of -# signature verification. +# Ed25519 and Ed448 internally do public key validation as part of +# signature verification. [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8422/section-5.2.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8422/section-5.2.toml index afb797b6f84..a50740276b1 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8422/section-5.2.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8422/section-5.2.toml @@ -1,52 +1,52 @@ target = "https://www.rfc-editor.org/rfc/rfc8422#section-5.2" -# 5.2. Server Hello Extension +# Server Hello Extension # -# This section specifies a TLS extension that can be included with the -# ServerHello message as described in [RFC4366], the Supported Point -# Formats Extension. +# This section specifies a TLS extension that can be included with the +# ServerHello message as described in [RFC4366], the Supported Point +# Formats Extension. # -# When this extension is sent: +# When this extension is sent: # -# The Supported Point Formats Extension is included in a ServerHello -# message in response to a ClientHello message containing the Supported -# Point Formats Extension when negotiating an ECC cipher suite. +# The Supported Point Formats Extension is included in a ServerHello +# message in response to a ClientHello message containing the Supported +# Point Formats Extension when negotiating an ECC cipher suite. # -# Meaning of this extension: +# Meaning of this extension: # -# This extension allows a server to enumerate the point formats it can -# parse (for the curve that will appear in its ServerKeyExchange -# message when using the ECDHE_ECDSA, ECDHE_RSA, or ECDH_anon key -# exchange algorithm. +# This extension allows a server to enumerate the point formats it can +# parse (for the curve that will appear in its ServerKeyExchange +# message when using the ECDHE_ECDSA, ECDHE_RSA, or ECDH_anon key +# exchange algorithm. # -# Structure of this extension: +# Structure of this extension: # -# The server's Supported Point Formats Extension has the same structure -# as the client's Supported Point Formats Extension (see -# Section 5.1.2). Items in ec_point_format_list here are ordered -# according to the server's preference (favorite choice first). Note -# that the server MAY include items that were not found in the client's -# list. However, without extensions, this specification allows exactly -# one point format, so there is not really any opportunity for -# mismatches. +# The server's Supported Point Formats Extension has the same structure +# as the client's Supported Point Formats Extension (see +# Section 5.1.2). Items in ec_point_format_list here are ordered +# according to the server's preference (favorite choice first). Note +# that the server MAY include items that were not found in the client's +# list. However, without extensions, this specification allows exactly +# one point format, so there is not really any opportunity for +# mismatches. # -# Actions of the sender: +# Actions of the sender: # -# A server that selects an ECC cipher suite in response to a -# ClientHello message including a Supported Point Formats Extension -# appends this extension (along with others) to its ServerHello -# message, enumerating the point formats it can parse. The Supported -# Point Formats Extension, when used, MUST contain the value 0 -# (uncompressed) as one of the items in the list of point formats. +# A server that selects an ECC cipher suite in response to a +# ClientHello message including a Supported Point Formats Extension +# appends this extension (along with others) to its ServerHello +# message, enumerating the point formats it can parse. The Supported +# Point Formats Extension, when used, MUST contain the value 0 +# (uncompressed) as one of the items in the list of point formats. # -# Actions of the receiver: +# Actions of the receiver: # -# A client that receives a ServerHello message containing a Supported -# Point Formats Extension MUST respect the server's choice of point -# formats during the handshake (cf. Sections 5.6 and 5.7). If no -# Supported Point Formats Extension is received with the ServerHello, -# this is equivalent to an extension allowing only the uncompressed -# point format. +# A client that receives a ServerHello message containing a Supported +# Point Formats Extension MUST respect the server's choice of point +# formats during the handshake (cf. Sections 5.6 and 5.7). If no +# Supported Point Formats Extension is received with the ServerHello, +# this is equivalent to an extension allowing only the uncompressed +# point format. [[spec]] level = "MAY" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8422/section-5.3.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8422/section-5.3.toml index 234106e01d5..f85a799d86b 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8422/section-5.3.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8422/section-5.3.toml @@ -1,55 +1,55 @@ target = "https://www.rfc-editor.org/rfc/rfc8422#section-5.3" -# 5.3. Server Certificate +# Server Certificate # -# When this message is sent: +# When this message is sent: # -# This message is sent in all non-anonymous, ECC-based key exchange -# algorithms. +# This message is sent in all non-anonymous, ECC-based key exchange +# algorithms. # -# Meaning of this message: +# Meaning of this message: # -# This message is used to authentically convey the server's static -# public key to the client. The following table shows the server -# certificate type appropriate for each key exchange algorithm. ECC -# public keys MUST be encoded in certificates as described in -# Section 5.9. +# This message is used to authentically convey the server's static +# public key to the client. The following table shows the server +# certificate type appropriate for each key exchange algorithm. ECC +# public keys MUST be encoded in certificates as described in +# Section 5.9. # -# NOTE: The server's Certificate message is capable of carrying a chain -# of certificates. The restrictions mentioned in Table 2 apply only to -# the server's certificate (first in the chain). +# NOTE: The server's Certificate message is capable of carrying a chain +# of certificates. The restrictions mentioned in Table 2 apply only to +# the server's certificate (first in the chain). # -# +-------------+-----------------------------------------------------+ -# | Algorithm | Server Certificate Type | -# +-------------+-----------------------------------------------------+ -# | ECDHE_ECDSA | Certificate MUST contain an ECDSA- or EdDSA-capable | -# | | public key. | -# | ECDHE_RSA | Certificate MUST contain an RSA public key. | -# +-------------+-----------------------------------------------------+ +# +-------------+-----------------------------------------------------+ +# | Algorithm | Server Certificate Type | +# +-------------+-----------------------------------------------------+ +# | ECDHE_ECDSA | Certificate MUST contain an ECDSA- or EdDSA-capable | +# | | public key. | +# | ECDHE_RSA | Certificate MUST contain an RSA public key. | +# +-------------+-----------------------------------------------------+ # -# Table 2: Server Certificate Types +# Table 2: Server Certificate Types # -# Structure of this message: +# Structure of this message: # -# Identical to the TLS Certificate format. +# Identical to the TLS Certificate format. # -# Actions of the sender: +# Actions of the sender: # -# The server constructs an appropriate certificate chain and conveys it -# to the client in the Certificate message. If the client has used a -# Supported Elliptic Curves Extension, the public key in the server's +# The server constructs an appropriate certificate chain and conveys it +# to the client in the Certificate message. If the client has used a +# Supported Elliptic Curves Extension, the public key in the server's # -# certificate MUST respect the client's choice of elliptic curves. A -# server that cannot satisfy this requirement MUST NOT choose an ECC -# cipher suite in its ServerHello message.) +# certificate MUST respect the client's choice of elliptic curves. A +# server that cannot satisfy this requirement MUST NOT choose an ECC +# cipher suite in its ServerHello message.) # -# Actions of the receiver: +# Actions of the receiver: # -# The client validates the certificate chain, extracts the server's -# public key, and checks that the key type is appropriate for the -# negotiated key exchange algorithm. (A possible reason for a fatal -# handshake failure is that the client's capabilities for handling -# elliptic curves and point formats are exceeded; cf. Section 5.1.) +# The client validates the certificate chain, extracts the server's +# public key, and checks that the key type is appropriate for the +# negotiated key exchange algorithm. (A possible reason for a fatal +# handshake failure is that the client's capabilities for handling +# elliptic curves and point formats are exceeded; cf. Section 5.1.) [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8422/section-5.4.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8422/section-5.4.toml index 7bc6f92f1c9..545ccbaa7b8 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8422/section-5.4.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8422/section-5.4.toml @@ -1,168 +1,168 @@ target = "https://www.rfc-editor.org/rfc/rfc8422#section-5.4" -# 5.4. Server Key Exchange +# Server Key Exchange # -# When this message is sent: +# When this message is sent: +# +# This message is sent when using the ECDHE_ECDSA, ECDHE_RSA, and +# ECDH_anon key exchange algorithms. +# +# Meaning of this message: +# +# This message is used to convey the server's ephemeral ECDH public key +# (and the corresponding elliptic curve domain parameters) to the +# client. +# +# The ECCurveType enum used to have values for explicit prime and for +# explicit char2 curves. Those values are now deprecated, so only one +# value remains: +# +# Structure of this message: +# +# enum { +# deprecated (1..2), +# named_curve (3), +# reserved(248..255) +# } ECCurveType; +# +# The value named_curve indicates that a named curve is used. This +# option is now the only remaining format. +# +# Values 248 through 255 are reserved for private use. +# +# The ECCurveType name space (now titled "TLS EC Curve Types") is +# maintained by IANA. See Section 9 for information on how new value +# assignments are added. +# +# RFC 4492 had a specification for an ECCurve structure and an +# ECBasisType structure. Both of these are omitted now because they +# were only used with the now deprecated explicit curves. +# +# struct { +# opaque point <1..2^8-1>; +# } ECPoint; +# +# point: This is the byte string representation of an elliptic curve +# point following the conversion routine in Section 4.3.6 of +# [ANSI.X9-62.2005]. This byte string may represent an elliptic curve +# point in uncompressed, compressed, or hybrid format, but this +# specification deprecates all but the uncompressed format. For the +# NIST curves, the format is repeated in Section 5.4.1 for convenience. +# For the X25519 and X448 curves, the only valid representation is the +# one specified in [RFC7748], a 32- or 56-octet representation of the u +# value of the point. This structure MUST NOT be used with Ed25519 and +# Ed448 public keys. +# +# struct { +# ECCurveType curve_type; +# select (curve_type) { +# case named_curve: +# NamedCurve namedcurve; +# }; +# } ECParameters; +# +# curve_type: This identifies the type of the elliptic curve domain +# parameters. # -# This message is sent when using the ECDHE_ECDSA, ECDHE_RSA, and -# ECDH_anon key exchange algorithms. +# namedCurve: Specifies a recommended set of elliptic curve domain +# parameters. All those values of NamedCurve are allowed that refer to +# a curve capable of Diffie-Hellman. With the deprecation of the +# explicit curves, this now includes all of the NamedCurve values. # -# Meaning of this message: +# struct { +# ECParameters curve_params; +# ECPoint public; +# } ServerECDHParams; # -# This message is used to convey the server's ephemeral ECDH public key -# (and the corresponding elliptic curve domain parameters) to the -# client. +# curve_params: Specifies the elliptic curve domain parameters +# associated with the ECDH public key. # -# The ECCurveType enum used to have values for explicit prime and for -# explicit char2 curves. Those values are now deprecated, so only one -# value remains: +# public: The ephemeral ECDH public key. # -# Structure of this message: +# The ServerKeyExchange message is extended as follows. # -# enum { -# deprecated (1..2), -# named_curve (3), -# reserved(248..255) -# } ECCurveType; -# -# The value named_curve indicates that a named curve is used. This -# option is now the only remaining format. -# -# Values 248 through 255 are reserved for private use. -# -# The ECCurveType name space (now titled "TLS EC Curve Types") is -# maintained by IANA. See Section 9 for information on how new value -# assignments are added. -# -# RFC 4492 had a specification for an ECCurve structure and an -# ECBasisType structure. Both of these are omitted now because they -# were only used with the now deprecated explicit curves. -# -# struct { -# opaque point <1..2^8-1>; -# } ECPoint; -# -# point: This is the byte string representation of an elliptic curve -# point following the conversion routine in Section 4.3.6 of -# [ANSI.X9-62.2005]. This byte string may represent an elliptic curve -# point in uncompressed, compressed, or hybrid format, but this -# specification deprecates all but the uncompressed format. For the -# NIST curves, the format is repeated in Section 5.4.1 for convenience. -# For the X25519 and X448 curves, the only valid representation is the -# one specified in [RFC7748], a 32- or 56-octet representation of the u -# value of the point. This structure MUST NOT be used with Ed25519 and -# Ed448 public keys. -# -# struct { -# ECCurveType curve_type; -# select (curve_type) { -# case named_curve: -# NamedCurve namedcurve; -# }; -# } ECParameters; -# -# curve_type: This identifies the type of the elliptic curve domain -# parameters. -# -# namedCurve: Specifies a recommended set of elliptic curve domain -# parameters. All those values of NamedCurve are allowed that refer to -# a curve capable of Diffie-Hellman. With the deprecation of the -# explicit curves, this now includes all of the NamedCurve values. -# -# struct { -# ECParameters curve_params; -# ECPoint public; -# } ServerECDHParams; -# -# curve_params: Specifies the elliptic curve domain parameters -# associated with the ECDH public key. -# -# public: The ephemeral ECDH public key. -# -# The ServerKeyExchange message is extended as follows. +# enum { +# ec_diffie_hellman +# } KeyExchangeAlgorithm; # -# enum { -# ec_diffie_hellman -# } KeyExchangeAlgorithm; +# o ec_diffie_hellman: Indicates the ServerKeyExchange message +# contains an ECDH public key. # -# o ec_diffie_hellman: Indicates the ServerKeyExchange message -# contains an ECDH public key. +# select (KeyExchangeAlgorithm) { +# case ec_diffie_hellman: +# ServerECDHParams params; +# Signature signed_params; +# } ServerKeyExchange; # -# select (KeyExchangeAlgorithm) { -# case ec_diffie_hellman: -# ServerECDHParams params; -# Signature signed_params; -# } ServerKeyExchange; +# o params: Specifies the ECDH public key and associated domain +# parameters. # -# o params: Specifies the ECDH public key and associated domain -# parameters. +# o signed_params: A hash of the params, with the signature +# appropriate to that hash applied. The private key corresponding +# to the certified public key in the server's Certificate message is +# used for signing. # -# o signed_params: A hash of the params, with the signature -# appropriate to that hash applied. The private key corresponding -# to the certified public key in the server's Certificate message is -# used for signing. -# -# enum { -# ecdsa(3), -# ed25519(7) -# ed448(8) -# } SignatureAlgorithm; -# select (SignatureAlgorithm) { -# case ecdsa: -# digitally-signed struct { -# opaque sha_hash[sha_size]; -# }; -# case ed25519,ed448: -# digitally-signed struct { -# opaque rawdata[rawdata_size]; -# }; -# } Signature; -# ServerKeyExchange.signed_params.sha_hash -# SHA(ClientHello.random + ServerHello.random + -# ServerKeyExchange.params); -# ServerKeyExchange.signed_params.rawdata -# ClientHello.random + ServerHello.random + -# ServerKeyExchange.params; -# -# NOTE: SignatureAlgorithm is "rsa" for the ECDHE_RSA key exchange -# algorithm and "anonymous" for ECDH_anon. These cases are defined in -# TLS. SignatureAlgorithm is "ecdsa" or "eddsa" for ECDHE_ECDSA. -# -# ECDSA signatures are generated and verified as described in -# Section 5.10. SHA, in the above template for sha_hash, may denote a -# hash algorithm other than SHA-1. As per ANSI X9.62, an ECDSA -# signature consists of a pair of integers, r and s. The digitally- -# signed element is encoded as an opaque vector <0..2^16-1>, the -# contents of which are the DER encoding corresponding to the following -# ASN.1 notation. -# -# Ecdsa-Sig-Value ::= SEQUENCE { -# r INTEGER, -# s INTEGER -# } -# -# EdDSA signatures in both the protocol and in certificates that -# conform to [RFC8410] are generated and verified according to -# [RFC8032]. The digitally-signed element is encoded as an opaque -# vector <0..2^16-1>, the contents of which include the octet string -# output of the EdDSA signing algorithm. -# -# Actions of the sender: -# -# The server selects elliptic curve domain parameters and an ephemeral -# ECDH public key corresponding to these parameters according to the -# ECKAS-DH1 scheme from IEEE 1363 [IEEE.P1363]. It conveys this -# information to the client in the ServerKeyExchange message using the -# format defined above. -# -# Actions of the receiver: -# -# The client verifies the signature (when present) and retrieves the -# server's elliptic curve domain parameters and ephemeral ECDH public -# key from the ServerKeyExchange message. (A possible reason for a -# fatal handshake failure is that the client's capabilities for -# handling elliptic curves and point formats are exceeded; cf. -# Section 5.1.) +# enum { +# ecdsa(3), +# ed25519(7) +# ed448(8) +# } SignatureAlgorithm; +# select (SignatureAlgorithm) { +# case ecdsa: +# digitally-signed struct { +# opaque sha_hash[sha_size]; +# }; +# case ed25519,ed448: +# digitally-signed struct { +# opaque rawdata[rawdata_size]; +# }; +# } Signature; +# ServerKeyExchange.signed_params.sha_hash +# SHA(ClientHello.random + ServerHello.random + +# ServerKeyExchange.params); +# ServerKeyExchange.signed_params.rawdata +# ClientHello.random + ServerHello.random + +# ServerKeyExchange.params; +# +# NOTE: SignatureAlgorithm is "rsa" for the ECDHE_RSA key exchange +# algorithm and "anonymous" for ECDH_anon. These cases are defined in +# TLS. SignatureAlgorithm is "ecdsa" or "eddsa" for ECDHE_ECDSA. +# +# ECDSA signatures are generated and verified as described in +# Section 5.10. SHA, in the above template for sha_hash, may denote a +# hash algorithm other than SHA-1. As per ANSI X9.62, an ECDSA +# signature consists of a pair of integers, r and s. The digitally- +# signed element is encoded as an opaque vector <0..2^16-1>, the +# contents of which are the DER encoding corresponding to the following +# ASN.1 notation. +# +# Ecdsa-Sig-Value ::= SEQUENCE { +# r INTEGER, +# s INTEGER +# } +# +# EdDSA signatures in both the protocol and in certificates that +# conform to [RFC8410] are generated and verified according to +# [RFC8032]. The digitally-signed element is encoded as an opaque +# vector <0..2^16-1>, the contents of which include the octet string +# output of the EdDSA signing algorithm. +# +# Actions of the sender: +# +# The server selects elliptic curve domain parameters and an ephemeral +# ECDH public key corresponding to these parameters according to the +# ECKAS-DH1 scheme from IEEE 1363 [IEEE.P1363]. It conveys this +# information to the client in the ServerKeyExchange message using the +# format defined above. +# +# Actions of the receiver: +# +# The client verifies the signature (when present) and retrieves the +# server's elliptic curve domain parameters and ephemeral ECDH public +# key from the ServerKeyExchange message. (A possible reason for a +# fatal handshake failure is that the client's capabilities for +# handling elliptic curves and point formats are exceeded; cf. +# Section 5.1.) [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8422/section-5.6.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8422/section-5.6.toml index 3abea24e966..a1cf2fe495f 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8422/section-5.6.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8422/section-5.6.toml @@ -1,42 +1,42 @@ target = "https://www.rfc-editor.org/rfc/rfc8422#section-5.6" -# 5.6. Client Certificate +# Client Certificate # -# When this message is sent: +# When this message is sent: # -# This message is sent in response to a CertificateRequest when a -# client has a suitable certificate and has decided to proceed with -# client authentication. (Note that if the server has used a Supported -# Point Formats Extension, a certificate can only be considered -# suitable for use with the ECDSA_sign authentication method if the -# public key point specified in it is uncompressed, as that is the only -# point format still supported. +# This message is sent in response to a CertificateRequest when a +# client has a suitable certificate and has decided to proceed with +# client authentication. (Note that if the server has used a Supported +# Point Formats Extension, a certificate can only be considered +# suitable for use with the ECDSA_sign authentication method if the +# public key point specified in it is uncompressed, as that is the only +# point format still supported. # -# Meaning of this message: +# Meaning of this message: # -# This message is used to authentically convey the client's static -# public key to the server. ECC public keys must be encoded in -# certificates as described in Section 5.9. The certificate MUST -# contain an ECDSA- or EdDSA-capable public key. +# This message is used to authentically convey the client's static +# public key to the server. ECC public keys must be encoded in +# certificates as described in Section 5.9. The certificate MUST +# contain an ECDSA- or EdDSA-capable public key. # -# NOTE: The client's Certificate message is capable of carrying a chain -# of certificates. The restrictions mentioned above apply only to the -# client's certificate (first in the chain). +# NOTE: The client's Certificate message is capable of carrying a chain +# of certificates. The restrictions mentioned above apply only to the +# client's certificate (first in the chain). # -# Structure of this message: +# Structure of this message: # -# Identical to the TLS client Certificate format. +# Identical to the TLS client Certificate format. # -# Actions of the sender: +# Actions of the sender: # -# The client constructs an appropriate certificate chain and conveys it -# to the server in the Certificate message. +# The client constructs an appropriate certificate chain and conveys it +# to the server in the Certificate message. # -# Actions of the receiver: +# Actions of the receiver: # -# The TLS server validates the certificate chain, extracts the client's -# public key, and checks that the key type is appropriate for the -# client authentication method. +# The TLS server validates the certificate chain, extracts the client's +# public key, and checks that the key type is appropriate for the +# client authentication method. [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8422/section-5.9.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8422/section-5.9.toml index bb6042f0bb3..3ef54251a8e 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8422/section-5.9.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8422/section-5.9.toml @@ -1,19 +1,19 @@ target = "https://www.rfc-editor.org/rfc/rfc8422#section-5.9" -# 5.9. Elliptic Curve Certificates +# Elliptic Curve Certificates # -# X.509 certificates containing ECC public keys or signed using ECDSA -# MUST comply with [RFC3279] or another RFC that replaces or extends -# it. X.509 certificates containing ECC public keys or signed using -# EdDSA MUST comply with [RFC8410]. Clients SHOULD use the elliptic -# curve domain parameters recommended in ANSI X9.62, FIPS 186-4, and -# SEC 2 [SECG-SEC2], or in [RFC8032]. +# X.509 certificates containing ECC public keys or signed using ECDSA +# MUST comply with [RFC3279] or another RFC that replaces or extends +# it. X.509 certificates containing ECC public keys or signed using +# EdDSA MUST comply with [RFC8410]. Clients SHOULD use the elliptic +# curve domain parameters recommended in ANSI X9.62, FIPS 186-4, and +# SEC 2 [SECG-SEC2], or in [RFC8032]. # -# EdDSA keys using the Ed25519 algorithm MUST use the ed25519 signature -# algorithm, and Ed448 keys MUST use the ed448 signature algorithm. -# This document does not define use of Ed25519ph and Ed448ph keys with -# TLS. Ed25519, Ed25519ph, Ed448, and Ed448ph keys MUST NOT be used -# with ECDSA. +# EdDSA keys using the Ed25519 algorithm MUST use the ed25519 signature +# algorithm, and Ed448 keys MUST use the ed448 signature algorithm. +# This document does not define use of Ed25519ph and Ed448ph keys with +# TLS. Ed25519, Ed25519ph, Ed448, and Ed448ph keys MUST NOT be used +# with ECDSA. [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8422/section-6.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8422/section-6.toml index ddf145d71e7..59341722c24 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8422/section-6.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8422/section-6.toml @@ -1,52 +1,52 @@ target = "https://www.rfc-editor.org/rfc/rfc8422#section-6" -# 6. Cipher Suites +# Cipher Suites # -# The table below defines ECC cipher suites that use the key exchange -# algorithms specified in Section 2. +# The table below defines ECC cipher suites that use the key exchange +# algorithms specified in Section 2. # -# +-----------------------------------------+----------------+ -# | CipherSuite | Identifier | -# +-----------------------------------------+----------------+ -# | TLS_ECDHE_ECDSA_WITH_NULL_SHA | { 0xC0, 0x06 } | -# | TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA | { 0xC0, 0x08 } | -# | TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA | { 0xC0, 0x09 } | -# | TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA | { 0xC0, 0x0A } | -# | TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 | { 0xC0, 0x2B } | -# | TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 | { 0xC0, 0x2C } | -# | | | -# | TLS_ECDHE_RSA_WITH_NULL_SHA | { 0xC0, 0x10 } | -# | TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA | { 0xC0, 0x12 } | -# | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA | { 0xC0, 0x13 } | -# | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA | { 0xC0, 0x14 } | -# | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 | { 0xC0, 0x2F } | -# | TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 | { 0xC0, 0x30 } | -# | | | -# | TLS_ECDH_anon_WITH_NULL_SHA | { 0xC0, 0x15 } | -# | TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA | { 0xC0, 0x17 } | -# | TLS_ECDH_anon_WITH_AES_128_CBC_SHA | { 0xC0, 0x18 } | -# | TLS_ECDH_anon_WITH_AES_256_CBC_SHA | { 0xC0, 0x19 } | -# +-----------------------------------------+----------------+ +# +-----------------------------------------+----------------+ +# | CipherSuite | Identifier | +# +-----------------------------------------+----------------+ +# | TLS_ECDHE_ECDSA_WITH_NULL_SHA | { 0xC0, 0x06 } | +# | TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA | { 0xC0, 0x08 } | +# | TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA | { 0xC0, 0x09 } | +# | TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA | { 0xC0, 0x0A } | +# | TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 | { 0xC0, 0x2B } | +# | TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 | { 0xC0, 0x2C } | +# | | | +# | TLS_ECDHE_RSA_WITH_NULL_SHA | { 0xC0, 0x10 } | +# | TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA | { 0xC0, 0x12 } | +# | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA | { 0xC0, 0x13 } | +# | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA | { 0xC0, 0x14 } | +# | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 | { 0xC0, 0x2F } | +# | TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 | { 0xC0, 0x30 } | +# | | | +# | TLS_ECDH_anon_WITH_NULL_SHA | { 0xC0, 0x15 } | +# | TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA | { 0xC0, 0x17 } | +# | TLS_ECDH_anon_WITH_AES_128_CBC_SHA | { 0xC0, 0x18 } | +# | TLS_ECDH_anon_WITH_AES_256_CBC_SHA | { 0xC0, 0x19 } | +# +-----------------------------------------+----------------+ # -# Table 3: TLS ECC Cipher Suites +# Table 3: TLS ECC Cipher Suites # -# The key exchange method, cipher, and hash algorithm for each of these -# cipher suites are easily determined by examining the name. Ciphers -# (other than AES ciphers) and hash algorithms are defined in [RFC2246] -# and [RFC4346]. AES ciphers are defined in [RFC5246], and AES-GCM -# ciphersuites are in [RFC5289]. +# The key exchange method, cipher, and hash algorithm for each of these +# cipher suites are easily determined by examining the name. Ciphers +# (other than AES ciphers) and hash algorithms are defined in [RFC2246] +# and [RFC4346]. AES ciphers are defined in [RFC5246], and AES-GCM +# ciphersuites are in [RFC5289]. # -# Server implementations SHOULD support all of the following cipher -# suites, and client implementations SHOULD support at least one of -# them: +# Server implementations SHOULD support all of the following cipher +# suites, and client implementations SHOULD support at least one of +# them: # -# o TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 +# o TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 # -# o TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA +# o TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA # -# o TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 +# o TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 # -# o TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA +# o TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA [[spec]] level = "SHOULD" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/appendix-A.1.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/appendix-A.1.toml index 6be78930908..69430ae20ce 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/appendix-A.1.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/appendix-A.1.toml @@ -1,42 +1,42 @@ target = "https://www.rfc-editor.org/rfc/rfc8446#appendix-A.1" -# A.1. Client +# Client # -# START <----+ -# Send ClientHello | | Recv HelloRetryRequest -# [K_send = early data] | | -# v | -# / WAIT_SH ----+ -# | | Recv ServerHello -# | | K_recv = handshake -# Can | V -# send | WAIT_EE -# early | | Recv EncryptedExtensions -# data | +--------+--------+ -# | Using | | Using certificate -# | PSK | v -# | | WAIT_CERT_CR -# | | Recv | | Recv CertificateRequest -# | | Certificate | v -# | | | WAIT_CERT -# | | | | Recv Certificate -# | | v v -# | | WAIT_CV -# | | | Recv CertificateVerify -# | +> WAIT_FINISHED <+ -# | | Recv Finished -# \ | [Send EndOfEarlyData] -# | K_send = handshake -# | [Send Certificate [+ CertificateVerify]] -# Can send | Send Finished -# app data --> | K_send = K_recv = application -# after here v -# CONNECTED +# START <----+ +# Send ClientHello | | Recv HelloRetryRequest +# [K_send = early data] | | +# v | +# / WAIT_SH ----+ +# | | Recv ServerHello +# | | K_recv = handshake +# Can | V +# send | WAIT_EE +# early | | Recv EncryptedExtensions +# data | +--------+--------+ +# | Using | | Using certificate +# | PSK | v +# | | WAIT_CERT_CR +# | | Recv | | Recv CertificateRequest +# | | Certificate | v +# | | | WAIT_CERT +# | | | | Recv Certificate +# | | v v +# | | WAIT_CV +# | | | Recv CertificateVerify +# | +> WAIT_FINISHED <+ +# | | Recv Finished +# \ | [Send EndOfEarlyData] +# | K_send = handshake +# | [Send Certificate [+ CertificateVerify]] +# Can send | Send Finished +# app data --> | K_send = K_recv = application +# after here v +# CONNECTED # -# Note that with the transitions as shown above, clients may send -# alerts that derive from post-ServerHello messages in the clear or -# with the early data keys. If clients need to send such alerts, they -# SHOULD first rekey to the handshake keys if possible. +# Note that with the transitions as shown above, clients may send +# alerts that derive from post-ServerHello messages in the clear or +# with the early data keys. If clients need to send such alerts, they +# SHOULD first rekey to the handshake keys if possible. [[spec]] level = "SHOULD" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/appendix-B.3.1.4.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/appendix-B.3.1.4.toml index 952be3d9a60..63ce4b150d7 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/appendix-B.3.1.4.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/appendix-B.3.1.4.toml @@ -1,40 +1,40 @@ target = "https://www.rfc-editor.org/rfc/rfc8446#appendix-B.3.1.4" -# B.3.1.4. Supported Groups Extension +# Supported Groups Extension # -# enum { -# unallocated_RESERVED(0x0000), +# enum { +# unallocated_RESERVED(0x0000), # -# /* Elliptic Curve Groups (ECDHE) */ -# obsolete_RESERVED(0x0001..0x0016), -# secp256r1(0x0017), secp384r1(0x0018), secp521r1(0x0019), -# obsolete_RESERVED(0x001A..0x001C), -# x25519(0x001D), x448(0x001E), +# /* Elliptic Curve Groups (ECDHE) */ +# obsolete_RESERVED(0x0001..0x0016), +# secp256r1(0x0017), secp384r1(0x0018), secp521r1(0x0019), +# obsolete_RESERVED(0x001A..0x001C), +# x25519(0x001D), x448(0x001E), # -# /* Finite Field Groups (DHE) */ -# ffdhe2048(0x0100), ffdhe3072(0x0101), ffdhe4096(0x0102), -# ffdhe6144(0x0103), ffdhe8192(0x0104), +# /* Finite Field Groups (DHE) */ +# ffdhe2048(0x0100), ffdhe3072(0x0101), ffdhe4096(0x0102), +# ffdhe6144(0x0103), ffdhe8192(0x0104), # -# /* Reserved Code Points */ -# ffdhe_private_use(0x01FC..0x01FF), -# ecdhe_private_use(0xFE00..0xFEFF), -# obsolete_RESERVED(0xFF01..0xFF02), -# (0xFFFF) -# } NamedGroup; +# /* Reserved Code Points */ +# ffdhe_private_use(0x01FC..0x01FF), +# ecdhe_private_use(0xFE00..0xFEFF), +# obsolete_RESERVED(0xFF01..0xFF02), +# (0xFFFF) +# } NamedGroup; # -# struct { -# NamedGroup named_group_list<2..2^16-1>; -# } NamedGroupList; +# struct { +# NamedGroup named_group_list<2..2^16-1>; +# } NamedGroupList; # -# Values within "obsolete_RESERVED" ranges are used in previous -# versions of TLS and MUST NOT be offered or negotiated by TLS 1.3 -# implementations. The obsolete curves have various known/theoretical -# weaknesses or have had very little usage, in some cases only due to -# unintentional server configuration issues. They are no longer -# considered appropriate for general use and should be assumed to be -# potentially unsafe. The set of curves specified here is sufficient -# for interoperability with all currently deployed and properly -# configured TLS implementations. +# Values within "obsolete_RESERVED" ranges are used in previous +# versions of TLS and MUST NOT be offered or negotiated by TLS 1.3 +# implementations. The obsolete curves have various known/theoretical +# weaknesses or have had very little usage, in some cases only due to +# unintentional server configuration issues. They are no longer +# considered appropriate for general use and should be assumed to be +# potentially unsafe. The set of curves specified here is sufficient +# for interoperability with all currently deployed and properly +# configured TLS implementations. [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/appendix-B.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/appendix-B.toml index 720c2861327..ba4be07263c 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/appendix-B.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/appendix-B.toml @@ -1,12 +1,12 @@ target = "https://www.rfc-editor.org/rfc/rfc8446#appendix-B" -# Appendix B. Protocol Data Structures and Constant Values +# Protocol Data Structures and Constant Values # -# This appendix provides the normative protocol types and the -# definitions for constants. Values listed as "_RESERVED" were used in -# previous versions of TLS and are listed here for completeness. -# TLS 1.3 implementations MUST NOT send them but might receive them -# from older TLS implementations. +# This appendix provides the normative protocol types and the +# definitions for constants. Values listed as "_RESERVED" were used in +# previous versions of TLS and are listed here for completeness. +# TLS 1.3 implementations MUST NOT send them but might receive them +# from older TLS implementations. [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/appendix-C.1.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/appendix-C.1.toml index 281cea6090a..098016756b8 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/appendix-C.1.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/appendix-C.1.toml @@ -1,26 +1,26 @@ target = "https://www.rfc-editor.org/rfc/rfc8446#appendix-C.1" -# C.1. Random Number Generation and Seeding +# Random Number Generation and Seeding # -# TLS requires a cryptographically secure pseudorandom number generator -# (CSPRNG). In most cases, the operating system provides an -# appropriate facility such as /dev/urandom, which should be used -# absent other (e.g., performance) concerns. It is RECOMMENDED to use -# an existing CSPRNG implementation in preference to crafting a new -# one. Many adequate cryptographic libraries are already available -# under favorable license terms. Should those prove unsatisfactory, -# [RFC4086] provides guidance on the generation of random values. +# TLS requires a cryptographically secure pseudorandom number generator +# (CSPRNG). In most cases, the operating system provides an +# appropriate facility such as /dev/urandom, which should be used +# absent other (e.g., performance) concerns. It is RECOMMENDED to use +# an existing CSPRNG implementation in preference to crafting a new +# one. Many adequate cryptographic libraries are already available +# under favorable license terms. Should those prove unsatisfactory, +# [RFC4086] provides guidance on the generation of random values. # -# TLS uses random values (1) in public protocol fields such as the -# public Random values in the ClientHello and ServerHello and (2) to -# generate keying material. With a properly functioning CSPRNG, this -# does not present a security problem, as it is not feasible to -# determine the CSPRNG state from its output. However, with a broken -# CSPRNG, it may be possible for an attacker to use the public output -# to determine the CSPRNG internal state and thereby predict the keying -# material, as documented in [CHECKOWAY]. Implementations can provide -# extra security against this form of attack by using separate CSPRNGs -# to generate public and private values. +# TLS uses random values (1) in public protocol fields such as the +# public Random values in the ClientHello and ServerHello and (2) to +# generate keying material. With a properly functioning CSPRNG, this +# does not present a security problem, as it is not feasible to +# determine the CSPRNG state from its output. However, with a broken +# CSPRNG, it may be possible for an attacker to use the public output +# to determine the CSPRNG internal state and thereby predict the keying +# material, as documented in [CHECKOWAY]. Implementations can provide +# extra security against this form of attack by using separate CSPRNGs +# to generate public and private values. [[spec]] level = "SHOULD" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/appendix-C.2.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/appendix-C.2.toml index a00d50001dc..541ad2ba446 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/appendix-C.2.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/appendix-C.2.toml @@ -1,18 +1,18 @@ target = "https://www.rfc-editor.org/rfc/rfc8446#appendix-C.2" -# C.2. Certificates and Authentication +# Certificates and Authentication # -# Implementations are responsible for verifying the integrity of -# certificates and should generally support certificate revocation -# messages. Absent a specific indication from an application profile, -# certificates should always be verified to ensure proper signing by a -# trusted certificate authority (CA). The selection and addition of -# trust anchors should be done very carefully. Users should be able to -# view information about the certificate and trust anchor. -# Applications SHOULD also enforce minimum and maximum key sizes. For -# example, certification paths containing keys or signatures weaker -# than 2048-bit RSA or 224-bit ECDSA are not appropriate for secure -# applications. +# Implementations are responsible for verifying the integrity of +# certificates and should generally support certificate revocation +# messages. Absent a specific indication from an application profile, +# certificates should always be verified to ensure proper signing by a +# trusted certificate authority (CA). The selection and addition of +# trust anchors should be done very carefully. Users should be able to +# view information about the certificate and trust anchor. +# Applications SHOULD also enforce minimum and maximum key sizes. For +# example, certification paths containing keys or signatures weaker +# than 2048-bit RSA or 224-bit ECDSA are not appropriate for secure +# applications. [[spec]] level = "SHOULD" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/appendix-C.3.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/appendix-C.3.toml index a5afcf17bd3..1ff87db7b3c 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/appendix-C.3.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/appendix-C.3.toml @@ -1,78 +1,78 @@ target = "https://www.rfc-editor.org/rfc/rfc8446#appendix-C.3" -# C.3. Implementation Pitfalls +# Implementation Pitfalls # -# Implementation experience has shown that certain parts of earlier TLS -# specifications are not easy to understand and have been a source of -# interoperability and security problems. Many of these areas have -# been clarified in this document, but this appendix contains a short -# list of the most important things that require special attention from -# implementors. -# -# TLS protocol issues: -# -# - Do you correctly handle handshake messages that are fragmented to -# multiple TLS records (see Section 5.1)? Do you correctly handle -# corner cases like a ClientHello that is split into several small -# fragments? Do you fragment handshake messages that exceed the -# maximum fragment size? In particular, the Certificate and -# CertificateRequest handshake messages can be large enough to -# require fragmentation. -# -# - Do you ignore the TLS record layer version number in all -# unencrypted TLS records (see Appendix D)? -# -# - Have you ensured that all support for SSL, RC4, EXPORT ciphers, -# and MD5 (via the "signature_algorithms" extension) is completely -# removed from all possible configurations that support TLS 1.3 or -# later, and that attempts to use these obsolete capabilities fail -# correctly (see Appendix D)? -# -# - Do you handle TLS extensions in ClientHellos correctly, including -# unknown extensions? -# -# - When the server has requested a client certificate but no suitable -# certificate is available, do you correctly send an empty -# Certificate message, instead of omitting the whole message (see -# Section 4.4.2)? -# -# - When processing the plaintext fragment produced by AEAD-Decrypt -# and scanning from the end for the ContentType, do you avoid -# scanning past the start of the cleartext in the event that the -# peer has sent a malformed plaintext of all zeros? -# -# - Do you properly ignore unrecognized cipher suites (Section 4.1.2), -# hello extensions (Section 4.2), named groups (Section 4.2.7), key -# shares (Section 4.2.8), supported versions (Section 4.2.1), and -# signature algorithms (Section 4.2.3) in the ClientHello? -# -# - As a server, do you send a HelloRetryRequest to clients which -# support a compatible (EC)DHE group but do not predict it in the -# "key_share" extension? As a client, do you correctly handle a -# HelloRetryRequest from the server? -# -# Cryptographic details: -# -# - What countermeasures do you use to prevent timing attacks -# [TIMING]? -# -# - When using Diffie-Hellman key exchange, do you correctly preserve -# leading zero bytes in the negotiated key (see Section 7.4.1)? -# -# - Does your TLS client check that the Diffie-Hellman parameters sent -# by the server are acceptable (see Section 4.2.8.1)? -# -# - Do you use a strong and, most importantly, properly seeded random -# number generator (see Appendix C.1) when generating Diffie-Hellman -# private values, the ECDSA "k" parameter, and other security- -# critical values? It is RECOMMENDED that implementations implement -# "deterministic ECDSA" as specified in [RFC6979]. -# -# - Do you zero-pad Diffie-Hellman public key values and shared -# secrets to the group size (see Section 4.2.8.1 and Section 7.4.1)? -# -# - Do you verify signatures after making them, to protect against -# RSA-CRT key leaks [FW15]? +# Implementation experience has shown that certain parts of earlier TLS +# specifications are not easy to understand and have been a source of +# interoperability and security problems. Many of these areas have +# been clarified in this document, but this appendix contains a short +# list of the most important things that require special attention from +# implementors. +# +# TLS protocol issues: +# +# - Do you correctly handle handshake messages that are fragmented to +# multiple TLS records (see Section 5.1)? Do you correctly handle +# corner cases like a ClientHello that is split into several small +# fragments? Do you fragment handshake messages that exceed the +# maximum fragment size? In particular, the Certificate and +# CertificateRequest handshake messages can be large enough to +# require fragmentation. +# +# - Do you ignore the TLS record layer version number in all +# unencrypted TLS records (see Appendix D)? +# +# - Have you ensured that all support for SSL, RC4, EXPORT ciphers, +# and MD5 (via the "signature_algorithms" extension) is completely +# removed from all possible configurations that support TLS 1.3 or +# later, and that attempts to use these obsolete capabilities fail +# correctly (see Appendix D)? +# +# - Do you handle TLS extensions in ClientHellos correctly, including +# unknown extensions? +# +# - When the server has requested a client certificate but no suitable +# certificate is available, do you correctly send an empty +# Certificate message, instead of omitting the whole message (see +# Section 4.4.2)? +# +# - When processing the plaintext fragment produced by AEAD-Decrypt +# and scanning from the end for the ContentType, do you avoid +# scanning past the start of the cleartext in the event that the +# peer has sent a malformed plaintext of all zeros? +# +# - Do you properly ignore unrecognized cipher suites (Section 4.1.2), +# hello extensions (Section 4.2), named groups (Section 4.2.7), key +# shares (Section 4.2.8), supported versions (Section 4.2.1), and +# signature algorithms (Section 4.2.3) in the ClientHello? +# +# - As a server, do you send a HelloRetryRequest to clients which +# support a compatible (EC)DHE group but do not predict it in the +# "key_share" extension? As a client, do you correctly handle a +# HelloRetryRequest from the server? +# +# Cryptographic details: +# +# - What countermeasures do you use to prevent timing attacks +# [TIMING]? +# +# - When using Diffie-Hellman key exchange, do you correctly preserve +# leading zero bytes in the negotiated key (see Section 7.4.1)? +# +# - Does your TLS client check that the Diffie-Hellman parameters sent +# by the server are acceptable (see Section 4.2.8.1)? +# +# - Do you use a strong and, most importantly, properly seeded random +# number generator (see Appendix C.1) when generating Diffie-Hellman +# private values, the ECDSA "k" parameter, and other security- +# critical values? It is RECOMMENDED that implementations implement +# "deterministic ECDSA" as specified in [RFC6979]. +# +# - Do you zero-pad Diffie-Hellman public key values and shared +# secrets to the group size (see Section 4.2.8.1 and Section 7.4.1)? +# +# - Do you verify signatures after making them, to protect against +# RSA-CRT key leaks [FW15]? [[spec]] level = "SHOULD" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/appendix-C.4.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/appendix-C.4.toml index 49118e48b4b..43897b04940 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/appendix-C.4.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/appendix-C.4.toml @@ -1,15 +1,15 @@ target = "https://www.rfc-editor.org/rfc/rfc8446#appendix-C.4" -# C.4. Client Tracking Prevention +# Client Tracking Prevention # -# Clients SHOULD NOT reuse a ticket for multiple connections. Reuse of -# a ticket allows passive observers to correlate different connections. -# Servers that issue tickets SHOULD offer at least as many tickets as -# the number of connections that a client might use; for example, a web -# browser using HTTP/1.1 [RFC7230] might open six connections to a -# server. Servers SHOULD issue new tickets with every connection. -# This ensures that clients are always able to use a new ticket when -# creating a new connection. +# Clients SHOULD NOT reuse a ticket for multiple connections. Reuse of +# a ticket allows passive observers to correlate different connections. +# Servers that issue tickets SHOULD offer at least as many tickets as +# the number of connections that a client might use; for example, a web +# browser using HTTP/1.1 [RFC7230] might open six connections to a +# server. Servers SHOULD issue new tickets with every connection. +# This ensures that clients are always able to use a new ticket when +# creating a new connection. [[spec]] level = "SHOULD" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/appendix-C.5.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/appendix-C.5.toml index dbb715e09f4..8b6ac096885 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/appendix-C.5.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/appendix-C.5.toml @@ -1,28 +1,28 @@ target = "https://www.rfc-editor.org/rfc/rfc8446#appendix-C.5" -# C.5. Unauthenticated Operation +# Unauthenticated Operation # -# Previous versions of TLS offered explicitly unauthenticated cipher -# suites based on anonymous Diffie-Hellman. These modes have been -# deprecated in TLS 1.3. However, it is still possible to negotiate -# parameters that do not provide verifiable server authentication by -# several methods, including: +# Previous versions of TLS offered explicitly unauthenticated cipher +# suites based on anonymous Diffie-Hellman. These modes have been +# deprecated in TLS 1.3. However, it is still possible to negotiate +# parameters that do not provide verifiable server authentication by +# several methods, including: # -# - Raw public keys [RFC7250]. +# - Raw public keys [RFC7250]. # -# - Using a public key contained in a certificate but without -# validation of the certificate chain or any of its contents. +# - Using a public key contained in a certificate but without +# validation of the certificate chain or any of its contents. # -# Either technique used alone is vulnerable to man-in-the-middle -# attacks and therefore unsafe for general use. However, it is also -# possible to bind such connections to an external authentication -# mechanism via out-of-band validation of the server's public key, -# trust on first use, or a mechanism such as channel bindings (though -# the channel bindings described in [RFC5929] are not defined for -# TLS 1.3). If no such mechanism is used, then the connection has no -# protection against active man-in-the-middle attack; applications -# MUST NOT use TLS in such a way absent explicit configuration or a -# specific application profile. +# Either technique used alone is vulnerable to man-in-the-middle +# attacks and therefore unsafe for general use. However, it is also +# possible to bind such connections to an external authentication +# mechanism via out-of-band validation of the server's public key, +# trust on first use, or a mechanism such as channel bindings (though +# the channel bindings described in [RFC5929] are not defined for +# TLS 1.3). If no such mechanism is used, then the connection has no +# protection against active man-in-the-middle attack; applications +# MUST NOT use TLS in such a way absent explicit configuration or a +# specific application profile. [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/appendix-D.1.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/appendix-D.1.toml index a37251a60a6..ad7bf3da944 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/appendix-D.1.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/appendix-D.1.toml @@ -1,32 +1,32 @@ target = "https://www.rfc-editor.org/rfc/rfc8446#appendix-D.1" -# D.1. Negotiating with an Older Server +# Negotiating with an Older Server # -# A TLS 1.3 client who wishes to negotiate with servers that do not -# support TLS 1.3 will send a normal TLS 1.3 ClientHello containing -# 0x0303 (TLS 1.2) in ClientHello.legacy_version but with the correct -# version(s) in the "supported_versions" extension. If the server does -# not support TLS 1.3, it will respond with a ServerHello containing an -# older version number. If the client agrees to use this version, the -# negotiation will proceed as appropriate for the negotiated protocol. -# A client using a ticket for resumption SHOULD initiate the connection -# using the version that was previously negotiated. +# A TLS 1.3 client who wishes to negotiate with servers that do not +# support TLS 1.3 will send a normal TLS 1.3 ClientHello containing +# 0x0303 (TLS 1.2) in ClientHello.legacy_version but with the correct +# version(s) in the "supported_versions" extension. If the server does +# not support TLS 1.3, it will respond with a ServerHello containing an +# older version number. If the client agrees to use this version, the +# negotiation will proceed as appropriate for the negotiated protocol. +# A client using a ticket for resumption SHOULD initiate the connection +# using the version that was previously negotiated. # -# Note that 0-RTT data is not compatible with older servers and -# SHOULD NOT be sent absent knowledge that the server supports TLS 1.3. -# See Appendix D.3. +# Note that 0-RTT data is not compatible with older servers and +# SHOULD NOT be sent absent knowledge that the server supports TLS 1.3. +# See Appendix D.3. # -# If the version chosen by the server is not supported by the client -# (or is not acceptable), the client MUST abort the handshake with a -# "protocol_version" alert. +# If the version chosen by the server is not supported by the client +# (or is not acceptable), the client MUST abort the handshake with a +# "protocol_version" alert. # -# Some legacy server implementations are known to not implement the TLS -# specification properly and might abort connections upon encountering -# TLS extensions or versions which they are not aware of. -# Interoperability with buggy servers is a complex topic beyond the -# scope of this document. Multiple connection attempts may be required -# in order to negotiate a backward-compatible connection; however, this -# practice is vulnerable to downgrade attacks and is NOT RECOMMENDED. +# Some legacy server implementations are known to not implement the TLS +# specification properly and might abort connections upon encountering +# TLS extensions or versions which they are not aware of. +# Interoperability with buggy servers is a complex topic beyond the +# scope of this document. Multiple connection attempts may be required +# in order to negotiate a backward-compatible connection; however, this +# practice is vulnerable to downgrade attacks and is NOT RECOMMENDED. [[spec]] level = "SHOULD" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/appendix-D.2.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/appendix-D.2.toml index fe347585105..d833e81b696 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/appendix-D.2.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/appendix-D.2.toml @@ -1,24 +1,24 @@ target = "https://www.rfc-editor.org/rfc/rfc8446#appendix-D.2" -# D.2. Negotiating with an Older Client +# Negotiating with an Older Client # -# A TLS server can also receive a ClientHello indicating a version -# number smaller than its highest supported version. If the -# "supported_versions" extension is present, the server MUST negotiate -# using that extension as described in Section 4.2.1. If the -# "supported_versions" extension is not present, the server MUST -# negotiate the minimum of ClientHello.legacy_version and TLS 1.2. For -# example, if the server supports TLS 1.0, 1.1, and 1.2, and -# legacy_version is TLS 1.0, the server will proceed with a TLS 1.0 -# ServerHello. If the "supported_versions" extension is absent and the -# server only supports versions greater than -# ClientHello.legacy_version, the server MUST abort the handshake with -# a "protocol_version" alert. +# A TLS server can also receive a ClientHello indicating a version +# number smaller than its highest supported version. If the +# "supported_versions" extension is present, the server MUST negotiate +# using that extension as described in Section 4.2.1. If the +# "supported_versions" extension is not present, the server MUST +# negotiate the minimum of ClientHello.legacy_version and TLS 1.2. For +# example, if the server supports TLS 1.0, 1.1, and 1.2, and +# legacy_version is TLS 1.0, the server will proceed with a TLS 1.0 +# ServerHello. If the "supported_versions" extension is absent and the +# server only supports versions greater than +# ClientHello.legacy_version, the server MUST abort the handshake with +# a "protocol_version" alert. # -# Note that earlier versions of TLS did not clearly specify the record -# layer version number value in all cases -# (TLSPlaintext.legacy_record_version). Servers will receive various -# TLS 1.x versions in this field, but its value MUST always be ignored. +# Note that earlier versions of TLS did not clearly specify the record +# layer version number value in all cases +# (TLSPlaintext.legacy_record_version). Servers will receive various +# TLS 1.x versions in this field, but its value MUST always be ignored. [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/appendix-D.3.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/appendix-D.3.toml index cc8f053046e..05718a2d347 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/appendix-D.3.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/appendix-D.3.toml @@ -1,24 +1,24 @@ target = "https://www.rfc-editor.org/rfc/rfc8446#appendix-D.3" -# D.3. 0-RTT Backward Compatibility +# 0-RTT Backward Compatibility # -# 0-RTT data is not compatible with older servers. An older server -# will respond to the ClientHello with an older ServerHello, but it -# will not correctly skip the 0-RTT data and will fail to complete the -# handshake. This can cause issues when a client attempts to use -# 0-RTT, particularly against multi-server deployments. For example, a -# deployment could deploy TLS 1.3 gradually with some servers -# implementing TLS 1.3 and some implementing TLS 1.2, or a TLS 1.3 -# deployment could be downgraded to TLS 1.2. +# 0-RTT data is not compatible with older servers. An older server +# will respond to the ClientHello with an older ServerHello, but it +# will not correctly skip the 0-RTT data and will fail to complete the +# handshake. This can cause issues when a client attempts to use +# 0-RTT, particularly against multi-server deployments. For example, a +# deployment could deploy TLS 1.3 gradually with some servers +# implementing TLS 1.3 and some implementing TLS 1.2, or a TLS 1.3 +# deployment could be downgraded to TLS 1.2. # -# A client that attempts to send 0-RTT data MUST fail a connection if -# it receives a ServerHello with TLS 1.2 or older. It can then retry -# the connection with 0-RTT disabled. To avoid a downgrade attack, the -# client SHOULD NOT disable TLS 1.3, only 0-RTT. +# A client that attempts to send 0-RTT data MUST fail a connection if +# it receives a ServerHello with TLS 1.2 or older. It can then retry +# the connection with 0-RTT disabled. To avoid a downgrade attack, the +# client SHOULD NOT disable TLS 1.3, only 0-RTT. # -# To avoid this error condition, multi-server deployments SHOULD ensure -# a uniform and stable deployment of TLS 1.3 without 0-RTT prior to -# enabling 0-RTT. +# To avoid this error condition, multi-server deployments SHOULD ensure +# a uniform and stable deployment of TLS 1.3 without 0-RTT prior to +# enabling 0-RTT. [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/appendix-D.4.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/appendix-D.4.toml index 0c2227307a1..8554de4ff23 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/appendix-D.4.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/appendix-D.4.toml @@ -1,38 +1,38 @@ target = "https://www.rfc-editor.org/rfc/rfc8446#appendix-D.4" -# D.4. Middlebox Compatibility Mode +# Middlebox Compatibility Mode # -# Field measurements [Ben17a] [Ben17b] [Res17a] [Res17b] have found -# that a significant number of middleboxes misbehave when a TLS -# client/server pair negotiates TLS 1.3. Implementations can increase -# the chance of making connections through those middleboxes by making -# the TLS 1.3 handshake look more like a TLS 1.2 handshake: +# Field measurements [Ben17a] [Ben17b] [Res17a] [Res17b] have found +# that a significant number of middleboxes misbehave when a TLS +# client/server pair negotiates TLS 1.3. Implementations can increase +# the chance of making connections through those middleboxes by making +# the TLS 1.3 handshake look more like a TLS 1.2 handshake: # -# - The client always provides a non-empty session ID in the -# ClientHello, as described in the legacy_session_id section of -# Section 4.1.2. +# - The client always provides a non-empty session ID in the +# ClientHello, as described in the legacy_session_id section of +# Section 4.1.2. # -# - If not offering early data, the client sends a dummy -# change_cipher_spec record (see the third paragraph of Section 5) -# immediately before its second flight. This may either be before -# its second ClientHello or before its encrypted handshake flight. -# If offering early data, the record is placed immediately after the -# first ClientHello. +# - If not offering early data, the client sends a dummy +# change_cipher_spec record (see the third paragraph of Section 5) +# immediately before its second flight. This may either be before +# its second ClientHello or before its encrypted handshake flight. +# If offering early data, the record is placed immediately after the +# first ClientHello. # -# - The server sends a dummy change_cipher_spec record immediately -# after its first handshake message. This may either be after a -# ServerHello or a HelloRetryRequest. +# - The server sends a dummy change_cipher_spec record immediately +# after its first handshake message. This may either be after a +# ServerHello or a HelloRetryRequest. # -# When put together, these changes make the TLS 1.3 handshake resemble -# TLS 1.2 session resumption, which improves the chance of successfully -# connecting through middleboxes. This "compatibility mode" is -# partially negotiated: the client can opt to provide a session ID or -# not, and the server has to echo it. Either side can send +# When put together, these changes make the TLS 1.3 handshake resemble +# TLS 1.2 session resumption, which improves the chance of successfully +# connecting through middleboxes. This "compatibility mode" is +# partially negotiated: the client can opt to provide a session ID or +# not, and the server has to echo it. Either side can send # -# change_cipher_spec at any time during the handshake, as they must be -# ignored by the peer, but if the client sends a non-empty session ID, -# the server MUST send the change_cipher_spec as described in this -# appendix. +# change_cipher_spec at any time during the handshake, as they must be +# ignored by the peer, but if the client sends a non-empty session ID, +# the server MUST send the change_cipher_spec as described in this +# appendix. [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/appendix-D.5.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/appendix-D.5.toml index 4c2dd467445..72bc918fcb9 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/appendix-D.5.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/appendix-D.5.toml @@ -1,46 +1,46 @@ target = "https://www.rfc-editor.org/rfc/rfc8446#appendix-D.5" -# D.5. Security Restrictions Related to Backward Compatibility +# Security Restrictions Related to Backward Compatibility # -# Implementations negotiating the use of older versions of TLS SHOULD -# prefer forward secret and AEAD cipher suites, when available. +# Implementations negotiating the use of older versions of TLS SHOULD +# prefer forward secret and AEAD cipher suites, when available. # -# The security of RC4 cipher suites is considered insufficient for the -# reasons cited in [RFC7465]. Implementations MUST NOT offer or -# negotiate RC4 cipher suites for any version of TLS for any reason. +# The security of RC4 cipher suites is considered insufficient for the +# reasons cited in [RFC7465]. Implementations MUST NOT offer or +# negotiate RC4 cipher suites for any version of TLS for any reason. # -# Old versions of TLS permitted the use of very low strength ciphers. -# Ciphers with a strength less than 112 bits MUST NOT be offered or -# negotiated for any version of TLS for any reason. +# Old versions of TLS permitted the use of very low strength ciphers. +# Ciphers with a strength less than 112 bits MUST NOT be offered or +# negotiated for any version of TLS for any reason. # -# The security of SSL 3.0 [RFC6101] is considered insufficient for the -# reasons enumerated in [RFC7568], and it MUST NOT be negotiated for -# any reason. +# The security of SSL 3.0 [RFC6101] is considered insufficient for the +# reasons enumerated in [RFC7568], and it MUST NOT be negotiated for +# any reason. # -# The security of SSL 2.0 [SSL2] is considered insufficient for the -# reasons enumerated in [RFC6176], and it MUST NOT be negotiated for -# any reason. +# The security of SSL 2.0 [SSL2] is considered insufficient for the +# reasons enumerated in [RFC6176], and it MUST NOT be negotiated for +# any reason. # -# Implementations MUST NOT send an SSL version 2.0 compatible -# CLIENT-HELLO. Implementations MUST NOT negotiate TLS 1.3 or later -# using an SSL version 2.0 compatible CLIENT-HELLO. Implementations -# are NOT RECOMMENDED to accept an SSL version 2.0 compatible -# CLIENT-HELLO in order to negotiate older versions of TLS. +# Implementations MUST NOT send an SSL version 2.0 compatible +# CLIENT-HELLO. Implementations MUST NOT negotiate TLS 1.3 or later +# using an SSL version 2.0 compatible CLIENT-HELLO. Implementations +# are NOT RECOMMENDED to accept an SSL version 2.0 compatible +# CLIENT-HELLO in order to negotiate older versions of TLS. # -# Implementations MUST NOT send a ClientHello.legacy_version or -# ServerHello.legacy_version set to 0x0300 or less. Any endpoint -# receiving a Hello message with ClientHello.legacy_version or -# ServerHello.legacy_version set to 0x0300 MUST abort the handshake -# with a "protocol_version" alert. +# Implementations MUST NOT send a ClientHello.legacy_version or +# ServerHello.legacy_version set to 0x0300 or less. Any endpoint +# receiving a Hello message with ClientHello.legacy_version or +# ServerHello.legacy_version set to 0x0300 MUST abort the handshake +# with a "protocol_version" alert. # -# Implementations MUST NOT send any records with a version less than -# 0x0300. Implementations SHOULD NOT accept any records with a version -# less than 0x0300 (but may inadvertently do so if the record version -# number is ignored completely). +# Implementations MUST NOT send any records with a version less than +# 0x0300. Implementations SHOULD NOT accept any records with a version +# less than 0x0300 (but may inadvertently do so if the record version +# number is ignored completely). # -# Implementations MUST NOT use the Truncated HMAC extension, defined in -# Section 7 of [RFC6066], as it is not applicable to AEAD algorithms -# and has been shown to be insecure in some scenarios. +# Implementations MUST NOT use the Truncated HMAC extension, defined in +# Section 7 of [RFC6066], as it is not applicable to AEAD algorithms +# and has been shown to be insecure in some scenarios. [[spec]] level = "SHOULD" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/appendix-D.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/appendix-D.toml index 88808d1c54c..b04c0182a3c 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/appendix-D.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/appendix-D.toml @@ -1,45 +1,45 @@ target = "https://www.rfc-editor.org/rfc/rfc8446#appendix-D" -# Appendix D. Backward Compatibility +# Backward Compatibility # -# The TLS protocol provides a built-in mechanism for version -# negotiation between endpoints potentially supporting different -# versions of TLS. +# The TLS protocol provides a built-in mechanism for version +# negotiation between endpoints potentially supporting different +# versions of TLS. # -# TLS 1.x and SSL 3.0 use compatible ClientHello messages. Servers can -# also handle clients trying to use future versions of TLS as long as -# the ClientHello format remains compatible and there is at least one -# protocol version supported by both the client and the server. +# TLS 1.x and SSL 3.0 use compatible ClientHello messages. Servers can +# also handle clients trying to use future versions of TLS as long as +# the ClientHello format remains compatible and there is at least one +# protocol version supported by both the client and the server. # -# Prior versions of TLS used the record layer version number -# (TLSPlaintext.legacy_record_version and -# TLSCiphertext.legacy_record_version) for various purposes. As of -# TLS 1.3, this field is deprecated. The value of -# TLSPlaintext.legacy_record_version MUST be ignored by all -# implementations. The value of TLSCiphertext.legacy_record_version is -# included in the additional data for deprotection but MAY otherwise be -# ignored or MAY be validated to match the fixed constant value. -# Version negotiation is performed using only the handshake versions -# (ClientHello.legacy_version and ServerHello.legacy_version, as well -# as the ClientHello, HelloRetryRequest, and ServerHello -# "supported_versions" extensions). In order to maximize -# interoperability with older endpoints, implementations that negotiate -# the use of TLS 1.0-1.2 SHOULD set the record layer version number to -# the negotiated version for the ServerHello and all records -# thereafter. +# Prior versions of TLS used the record layer version number +# (TLSPlaintext.legacy_record_version and +# TLSCiphertext.legacy_record_version) for various purposes. As of +# TLS 1.3, this field is deprecated. The value of +# TLSPlaintext.legacy_record_version MUST be ignored by all +# implementations. The value of TLSCiphertext.legacy_record_version is +# included in the additional data for deprotection but MAY otherwise be +# ignored or MAY be validated to match the fixed constant value. +# Version negotiation is performed using only the handshake versions +# (ClientHello.legacy_version and ServerHello.legacy_version, as well +# as the ClientHello, HelloRetryRequest, and ServerHello +# "supported_versions" extensions). In order to maximize +# interoperability with older endpoints, implementations that negotiate +# the use of TLS 1.0-1.2 SHOULD set the record layer version number to +# the negotiated version for the ServerHello and all records +# thereafter. # -# For maximum compatibility with previously non-standard behavior and -# misconfigured deployments, all implementations SHOULD support -# validation of certification paths based on the expectations in this -# document, even when handling prior TLS versions' handshakes (see -# Section 4.4.2.2). +# For maximum compatibility with previously non-standard behavior and +# misconfigured deployments, all implementations SHOULD support +# validation of certification paths based on the expectations in this +# document, even when handling prior TLS versions' handshakes (see +# Section 4.4.2.2). # -# TLS 1.2 and prior supported an "Extended Master Secret" [RFC7627] -# extension which digested large parts of the handshake transcript into -# the master secret. Because TLS 1.3 always hashes in the transcript -# up to the server Finished, implementations which support both TLS 1.3 -# and earlier versions SHOULD indicate the use of the Extended Master -# Secret extension in their APIs whenever TLS 1.3 is used. +# TLS 1.2 and prior supported an "Extended Master Secret" [RFC7627] +# extension which digested large parts of the handshake transcript into +# the master secret. Because TLS 1.3 always hashes in the transcript +# up to the server Finished, implementations which support both TLS 1.3 +# and earlier versions SHOULD indicate the use of the Extended Master +# Secret extension in their APIs whenever TLS 1.3 is used. [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/appendix-E.1.1.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/appendix-E.1.1.toml index 950eec5cacb..8d6bedeef47 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/appendix-E.1.1.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/appendix-E.1.1.toml @@ -1,30 +1,30 @@ target = "https://www.rfc-editor.org/rfc/rfc8446#appendix-E.1.1" -# E.1.1. Key Derivation and HKDF +# Key Derivation and HKDF # -# Key derivation in TLS 1.3 uses HKDF as defined in [RFC5869] and its -# two components, HKDF-Extract and HKDF-Expand. The full rationale for -# the HKDF construction can be found in [Kraw10] and the rationale for -# the way it is used in TLS 1.3 in [KW16]. Throughout this document, -# each application of HKDF-Extract is followed by one or more -# invocations of HKDF-Expand. This ordering should always be followed -# (including in future revisions of this document); in particular, one -# SHOULD NOT use an output of HKDF-Extract as an input to another -# application of HKDF-Extract without an HKDF-Expand in between. -# Multiple applications of HKDF-Expand to some of the same inputs are -# allowed as long as these are differentiated via the key and/or the -# labels. +# Key derivation in TLS 1.3 uses HKDF as defined in [RFC5869] and its +# two components, HKDF-Extract and HKDF-Expand. The full rationale for +# the HKDF construction can be found in [Kraw10] and the rationale for +# the way it is used in TLS 1.3 in [KW16]. Throughout this document, +# each application of HKDF-Extract is followed by one or more +# invocations of HKDF-Expand. This ordering should always be followed +# (including in future revisions of this document); in particular, one +# SHOULD NOT use an output of HKDF-Extract as an input to another +# application of HKDF-Extract without an HKDF-Expand in between. +# Multiple applications of HKDF-Expand to some of the same inputs are +# allowed as long as these are differentiated via the key and/or the +# labels. # -# Note that HKDF-Expand implements a pseudorandom function (PRF) with -# both inputs and outputs of variable length. In some of the uses of -# HKDF in this document (e.g., for generating exporters and the -# resumption_master_secret), it is necessary that the application of -# HKDF-Expand be collision resistant; namely, it should be infeasible -# to find two different inputs to HKDF-Expand that output the same -# value. This requires the underlying hash function to be collision -# resistant and the output length from HKDF-Expand to be of size at -# least 256 bits (or as much as needed for the hash function to prevent -# finding collisions). +# Note that HKDF-Expand implements a pseudorandom function (PRF) with +# both inputs and outputs of variable length. In some of the uses of +# HKDF in this document (e.g., for generating exporters and the +# resumption_master_secret), it is necessary that the application of +# HKDF-Expand be collision resistant; namely, it should be infeasible +# to find two different inputs to HKDF-Expand that output the same +# value. This requires the underlying hash function to be collision +# resistant and the output length from HKDF-Expand to be of size at +# least 256 bits (or as much as needed for the hash function to prevent +# finding collisions). [[spec]] level = "SHOULD" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/appendix-E.1.4.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/appendix-E.1.4.toml index 71dac5ac2dd..d6d5a99cc73 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/appendix-E.1.4.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/appendix-E.1.4.toml @@ -1,17 +1,17 @@ target = "https://www.rfc-editor.org/rfc/rfc8446#appendix-E.1.4" -# E.1.4. Exporter Independence +# Exporter Independence # -# The exporter_master_secret and early_exporter_master_secret are -# derived to be independent of the traffic keys and therefore do not -# represent a threat to the security of traffic encrypted with those -# keys. However, because these secrets can be used to compute any -# exporter value, they SHOULD be erased as soon as possible. If the -# total set of exporter labels is known, then implementations SHOULD -# pre-compute the inner Derive-Secret stage of the exporter computation -# for all those labels, then erase the [early_]exporter_master_secret, -# followed by each inner value as soon as it is known that it will not -# be needed again. +# The exporter_master_secret and early_exporter_master_secret are +# derived to be independent of the traffic keys and therefore do not +# represent a threat to the security of traffic encrypted with those +# keys. However, because these secrets can be used to compute any +# exporter value, they SHOULD be erased as soon as possible. If the +# total set of exporter labels is known, then implementations SHOULD +# pre-compute the inner Derive-Secret stage of the exporter computation +# for all those labels, then erase the [early_]exporter_master_secret, +# followed by each inner value as soon as it is known that it will not +# be needed again. [[spec]] level = "SHOULD" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/appendix-E.1.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/appendix-E.1.toml index ded6dedb87d..da08aab0a7b 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/appendix-E.1.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/appendix-E.1.toml @@ -1,159 +1,159 @@ target = "https://www.rfc-editor.org/rfc/rfc8446#appendix-E.1" -# E.1. Handshake +# Handshake # -# The TLS handshake is an Authenticated Key Exchange (AKE) protocol -# which is intended to provide both one-way authenticated (server-only) -# and mutually authenticated (client and server) functionality. At the -# completion of the handshake, each side outputs its view of the -# following values: -# -# - A set of "session keys" (the various secrets derived from the -# master secret) from which can be derived a set of working keys. -# -# - A set of cryptographic parameters (algorithms, etc.). -# -# - The identities of the communicating parties. -# -# We assume the attacker to be an active network attacker, which means -# it has complete control over the network used to communicate between -# the parties [RFC3552]. Even under these conditions, the handshake -# should provide the properties listed below. Note that these -# properties are not necessarily independent, but reflect the protocol -# consumers' needs. -# -# Establishing the same session keys: The handshake needs to output -# the same set of session keys on both sides of the handshake, -# provided that it completes successfully on each endpoint (see -# [CK01], Definition 1, part 1). -# -# Secrecy of the session keys: The shared session keys should be known -# only to the communicating parties and not to the attacker (see -# [CK01], Definition 1, part 2). Note that in a unilaterally -# authenticated connection, the attacker can establish its own -# session keys with the server, but those session keys are distinct -# from those established by the client. -# -# Peer authentication: The client's view of the peer identity should -# reflect the server's identity. If the client is authenticated, -# the server's view of the peer identity should match the client's -# identity. -# -# Uniqueness of the session keys: Any two distinct handshakes should -# produce distinct, unrelated session keys. Individual session keys -# produced by a handshake should also be distinct and independent. -# -# Downgrade protection: The cryptographic parameters should be the -# same on both sides and should be the same as if the peers had been -# communicating in the absence of an attack (see [BBFGKZ16], -# Definitions 8 and 9). -# -# Forward secret with respect to long-term keys: If the long-term -# keying material (in this case the signature keys in certificate- -# based authentication modes or the external/resumption PSK in PSK -# with (EC)DHE modes) is compromised after the handshake is -# complete, this does not compromise the security of the session key -# (see [DOW92]), as long as the session key itself has been erased. -# The forward secrecy property is not satisfied when PSK is used in -# the "psk_ke" PskKeyExchangeMode. -# -# Key Compromise Impersonation (KCI) resistance: In a mutually -# authenticated connection with certificates, compromising the -# long-term secret of one actor should not break that actor's -# authentication of their peer in the given connection (see -# [HGFS15]). For example, if a client's signature key is -# compromised, it should not be possible to impersonate arbitrary -# servers to that client in subsequent handshakes. -# -# Protection of endpoint identities: The server's identity -# (certificate) should be protected against passive attackers. The -# client's identity should be protected against both passive and -# active attackers. -# -# Informally, the signature-based modes of TLS 1.3 provide for the -# establishment of a unique, secret, shared key established by an -# (EC)DHE key exchange and authenticated by the server's signature over -# the handshake transcript, as well as tied to the server's identity by -# a MAC. If the client is authenticated by a certificate, it also -# signs over the handshake transcript and provides a MAC tied to both -# identities. [SIGMA] describes the design and analysis of this type -# of key exchange protocol. If fresh (EC)DHE keys are used for each -# connection, then the output keys are forward secret. -# -# The external PSK and resumption PSK bootstrap from a long-term shared -# secret into a unique per-connection set of short-term session keys. -# This secret may have been established in a previous handshake. If -# PSK with (EC)DHE key establishment is used, these session keys will -# also be forward secret. The resumption PSK has been designed so that -# the resumption master secret computed by connection N and needed to -# form connection N+1 is separate from the traffic keys used by -# -# connection N, thus providing forward secrecy between the connections. -# In addition, if multiple tickets are established on the same -# connection, they are associated with different keys, so compromise of -# the PSK associated with one ticket does not lead to the compromise of -# connections established with PSKs associated with other tickets. -# This property is most interesting if tickets are stored in a database -# (and so can be deleted) rather than if they are self-encrypted. -# -# The PSK binder value forms a binding between a PSK and the current -# handshake, as well as between the session where the PSK was -# established and the current session. This binding transitively -# includes the original handshake transcript, because that transcript -# is digested into the values which produce the resumption master -# secret. This requires that both the KDF used to produce the -# resumption master secret and the MAC used to compute the binder be -# collision resistant. See Appendix E.1.1 for more on this. Note: The -# binder does not cover the binder values from other PSKs, though they -# are included in the Finished MAC. -# -# TLS does not currently permit the server to send a -# certificate_request message in non-certificate-based handshakes -# (e.g., PSK). If this restriction were to be relaxed in future, the -# client's signature would not cover the server's certificate directly. -# However, if the PSK was established through a NewSessionTicket, the -# client's signature would transitively cover the server's certificate -# through the PSK binder. [PSK-FINISHED] describes a concrete attack -# on constructions that do not bind to the server's certificate (see -# also [Kraw16]). It is unsafe to use certificate-based client -# authentication when the client might potentially share the same -# PSK/key-id pair with two different endpoints. Implementations -# MUST NOT combine external PSKs with certificate-based authentication -# of either the client or the server unless negotiated by some -# extension. -# -# If an exporter is used, then it produces values which are unique and -# secret (because they are generated from a unique session key). -# Exporters computed with different labels and contexts are -# computationally independent, so it is not feasible to compute one -# from another or the session secret from the exported value. -# Note: Exporters can produce arbitrary-length values; if exporters are -# to be used as channel bindings, the exported value MUST be large -# enough to provide collision resistance. The exporters provided in -# TLS 1.3 are derived from the same Handshake Contexts as the early -# traffic keys and the application traffic keys, respectively, and thus -# have similar security properties. Note that they do not include the -# client's certificate; future applications which wish to bind to the -# client's certificate may need to define a new exporter that includes -# the full handshake transcript. -# -# For all handshake modes, the Finished MAC (and, where present, the -# signature) prevents downgrade attacks. In addition, the use of -# certain bytes in the random nonces as described in Section 4.1.3 -# allows the detection of downgrade to previous TLS versions. See -# [BBFGKZ16] for more details on TLS 1.3 and downgrade. -# -# As soon as the client and the server have exchanged enough -# information to establish shared keys, the remainder of the handshake -# is encrypted, thus providing protection against passive attackers, -# even if the computed shared key is not authenticated. Because the -# server authenticates before the client, the client can ensure that if -# it authenticates to the server, it only reveals its identity to an -# authenticated server. Note that implementations must use the -# provided record-padding mechanism during the handshake to avoid -# leaking information about the identities due to length. The client's -# proposed PSK identities are not encrypted, nor is the one that the -# server selects. +# The TLS handshake is an Authenticated Key Exchange (AKE) protocol +# which is intended to provide both one-way authenticated (server-only) +# and mutually authenticated (client and server) functionality. At the +# completion of the handshake, each side outputs its view of the +# following values: +# +# - A set of "session keys" (the various secrets derived from the +# master secret) from which can be derived a set of working keys. +# +# - A set of cryptographic parameters (algorithms, etc.). +# +# - The identities of the communicating parties. +# +# We assume the attacker to be an active network attacker, which means +# it has complete control over the network used to communicate between +# the parties [RFC3552]. Even under these conditions, the handshake +# should provide the properties listed below. Note that these +# properties are not necessarily independent, but reflect the protocol +# consumers' needs. +# +# Establishing the same session keys: The handshake needs to output +# the same set of session keys on both sides of the handshake, +# provided that it completes successfully on each endpoint (see +# [CK01], Definition 1, part 1). +# +# Secrecy of the session keys: The shared session keys should be known +# only to the communicating parties and not to the attacker (see +# [CK01], Definition 1, part 2). Note that in a unilaterally +# authenticated connection, the attacker can establish its own +# session keys with the server, but those session keys are distinct +# from those established by the client. +# +# Peer authentication: The client's view of the peer identity should +# reflect the server's identity. If the client is authenticated, +# the server's view of the peer identity should match the client's +# identity. +# +# Uniqueness of the session keys: Any two distinct handshakes should +# produce distinct, unrelated session keys. Individual session keys +# produced by a handshake should also be distinct and independent. +# +# Downgrade protection: The cryptographic parameters should be the +# same on both sides and should be the same as if the peers had been +# communicating in the absence of an attack (see [BBFGKZ16], +# Definitions 8 and 9). +# +# Forward secret with respect to long-term keys: If the long-term +# keying material (in this case the signature keys in certificate- +# based authentication modes or the external/resumption PSK in PSK +# with (EC)DHE modes) is compromised after the handshake is +# complete, this does not compromise the security of the session key +# (see [DOW92]), as long as the session key itself has been erased. +# The forward secrecy property is not satisfied when PSK is used in +# the "psk_ke" PskKeyExchangeMode. +# +# Key Compromise Impersonation (KCI) resistance: In a mutually +# authenticated connection with certificates, compromising the +# long-term secret of one actor should not break that actor's +# authentication of their peer in the given connection (see +# [HGFS15]). For example, if a client's signature key is +# compromised, it should not be possible to impersonate arbitrary +# servers to that client in subsequent handshakes. +# +# Protection of endpoint identities: The server's identity +# (certificate) should be protected against passive attackers. The +# client's identity should be protected against both passive and +# active attackers. +# +# Informally, the signature-based modes of TLS 1.3 provide for the +# establishment of a unique, secret, shared key established by an +# (EC)DHE key exchange and authenticated by the server's signature over +# the handshake transcript, as well as tied to the server's identity by +# a MAC. If the client is authenticated by a certificate, it also +# signs over the handshake transcript and provides a MAC tied to both +# identities. [SIGMA] describes the design and analysis of this type +# of key exchange protocol. If fresh (EC)DHE keys are used for each +# connection, then the output keys are forward secret. +# +# The external PSK and resumption PSK bootstrap from a long-term shared +# secret into a unique per-connection set of short-term session keys. +# This secret may have been established in a previous handshake. If +# PSK with (EC)DHE key establishment is used, these session keys will +# also be forward secret. The resumption PSK has been designed so that +# the resumption master secret computed by connection N and needed to +# form connection N+1 is separate from the traffic keys used by +# +# connection N, thus providing forward secrecy between the connections. +# In addition, if multiple tickets are established on the same +# connection, they are associated with different keys, so compromise of +# the PSK associated with one ticket does not lead to the compromise of +# connections established with PSKs associated with other tickets. +# This property is most interesting if tickets are stored in a database +# (and so can be deleted) rather than if they are self-encrypted. +# +# The PSK binder value forms a binding between a PSK and the current +# handshake, as well as between the session where the PSK was +# established and the current session. This binding transitively +# includes the original handshake transcript, because that transcript +# is digested into the values which produce the resumption master +# secret. This requires that both the KDF used to produce the +# resumption master secret and the MAC used to compute the binder be +# collision resistant. See Appendix E.1.1 for more on this. Note: The +# binder does not cover the binder values from other PSKs, though they +# are included in the Finished MAC. +# +# TLS does not currently permit the server to send a +# certificate_request message in non-certificate-based handshakes +# (e.g., PSK). If this restriction were to be relaxed in future, the +# client's signature would not cover the server's certificate directly. +# However, if the PSK was established through a NewSessionTicket, the +# client's signature would transitively cover the server's certificate +# through the PSK binder. [PSK-FINISHED] describes a concrete attack +# on constructions that do not bind to the server's certificate (see +# also [Kraw16]). It is unsafe to use certificate-based client +# authentication when the client might potentially share the same +# PSK/key-id pair with two different endpoints. Implementations +# MUST NOT combine external PSKs with certificate-based authentication +# of either the client or the server unless negotiated by some +# extension. +# +# If an exporter is used, then it produces values which are unique and +# secret (because they are generated from a unique session key). +# Exporters computed with different labels and contexts are +# computationally independent, so it is not feasible to compute one +# from another or the session secret from the exported value. +# Note: Exporters can produce arbitrary-length values; if exporters are +# to be used as channel bindings, the exported value MUST be large +# enough to provide collision resistance. The exporters provided in +# TLS 1.3 are derived from the same Handshake Contexts as the early +# traffic keys and the application traffic keys, respectively, and thus +# have similar security properties. Note that they do not include the +# client's certificate; future applications which wish to bind to the +# client's certificate may need to define a new exporter that includes +# the full handshake transcript. +# +# For all handshake modes, the Finished MAC (and, where present, the +# signature) prevents downgrade attacks. In addition, the use of +# certain bytes in the random nonces as described in Section 4.1.3 +# allows the detection of downgrade to previous TLS versions. See +# [BBFGKZ16] for more details on TLS 1.3 and downgrade. +# +# As soon as the client and the server have exchanged enough +# information to establish shared keys, the remainder of the handshake +# is encrypted, thus providing protection against passive attackers, +# even if the computed shared key is not authenticated. Because the +# server authenticates before the client, the client can ensure that if +# it authenticates to the server, it only reveals its identity to an +# authenticated server. Note that implementations must use the +# provided record-padding mechanism during the handshake to avoid +# leaking information about the identities due to length. The client's +# proposed PSK identities are not encrypted, nor is the one that the +# server selects. [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/appendix-E.5.1.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/appendix-E.5.1.toml index 155a4b019cd..4de93771b03 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/appendix-E.5.1.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/appendix-E.5.1.toml @@ -1,18 +1,18 @@ target = "https://www.rfc-editor.org/rfc/rfc8446#appendix-E.5.1" -# E.5.1. Replay and Exporters +# Replay and Exporters # -# Replays of the ClientHello produce the same early exporter, thus -# requiring additional care by applications which use these exporters. -# In particular, if these exporters are used as an authentication -# channel binding (e.g., by signing the output of the exporter), an -# attacker who compromises the PSK can transplant authenticators -# between connections without compromising the authentication key. +# Replays of the ClientHello produce the same early exporter, thus +# requiring additional care by applications which use these exporters. +# In particular, if these exporters are used as an authentication +# channel binding (e.g., by signing the output of the exporter), an +# attacker who compromises the PSK can transplant authenticators +# between connections without compromising the authentication key. # -# In addition, the early exporter SHOULD NOT be used to generate -# server-to-client encryption keys because that would entail the reuse -# of those keys. This parallels the use of the early application -# traffic keys only in the client-to-server direction. +# In addition, the early exporter SHOULD NOT be used to generate +# server-to-client encryption keys because that would entail the reuse +# of those keys. This parallels the use of the early application +# traffic keys only in the client-to-server direction. [[spec]] level = "SHOULD" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/appendix-E.5.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/appendix-E.5.toml index 0db86334cb5..a5e1cac3b5d 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/appendix-E.5.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/appendix-E.5.toml @@ -1,78 +1,78 @@ target = "https://www.rfc-editor.org/rfc/rfc8446#appendix-E.5" -# E.5. Replay Attacks on 0-RTT +# Replay Attacks on 0-RTT # -# Replayable 0-RTT data presents a number of security threats to TLS- -# using applications, unless those applications are specifically -# engineered to be safe under replay (minimally, this means idempotent, -# but in many cases may also require other stronger conditions, such as -# constant-time response). Potential attacks include: +# Replayable 0-RTT data presents a number of security threats to TLS- +# using applications, unless those applications are specifically +# engineered to be safe under replay (minimally, this means idempotent, +# but in many cases may also require other stronger conditions, such as +# constant-time response). Potential attacks include: # -# - Duplication of actions which cause side effects (e.g., purchasing -# an item or transferring money) to be duplicated, thus harming the -# site or the user. +# - Duplication of actions which cause side effects (e.g., purchasing +# an item or transferring money) to be duplicated, thus harming the +# site or the user. # -# - Attackers can store and replay 0-RTT messages in order to reorder -# them with respect to other messages (e.g., moving a delete to -# after a create). +# - Attackers can store and replay 0-RTT messages in order to reorder +# them with respect to other messages (e.g., moving a delete to +# after a create). # -# - Exploiting cache timing behavior to discover the content of 0-RTT -# messages by replaying a 0-RTT message to a different cache node -# and then using a separate connection to measure request latency, -# to see if the two requests address the same resource. +# - Exploiting cache timing behavior to discover the content of 0-RTT +# messages by replaying a 0-RTT message to a different cache node +# and then using a separate connection to measure request latency, +# to see if the two requests address the same resource. # -# If data can be replayed a large number of times, additional attacks -# become possible, such as making repeated measurements of the speed of -# cryptographic operations. In addition, they may be able to overload -# rate-limiting systems. For a further description of these attacks, -# see [Mac17]. +# If data can be replayed a large number of times, additional attacks +# become possible, such as making repeated measurements of the speed of +# cryptographic operations. In addition, they may be able to overload +# rate-limiting systems. For a further description of these attacks, +# see [Mac17]. # -# Ultimately, servers have the responsibility to protect themselves -# against attacks employing 0-RTT data replication. The mechanisms -# described in Section 8 are intended to prevent replay at the TLS -# layer but do not provide complete protection against receiving -# multiple copies of client data. TLS 1.3 falls back to the 1-RTT -# handshake when the server does not have any information about the -# client, e.g., because it is in a different cluster which does not -# share state or because the ticket has been deleted as described in -# Section 8.1. If the application-layer protocol retransmits data in -# this setting, then it is possible for an attacker to induce message -# duplication by sending the ClientHello to both the original cluster -# (which processes the data immediately) and another cluster which will -# fall back to 1-RTT and process the data upon application-layer -# replay. The scale of this attack is limited by the client's -# willingness to retry transactions and therefore only allows a limited -# amount of duplication, with each copy appearing as a new connection -# at the server. +# Ultimately, servers have the responsibility to protect themselves +# against attacks employing 0-RTT data replication. The mechanisms +# described in Section 8 are intended to prevent replay at the TLS +# layer but do not provide complete protection against receiving +# multiple copies of client data. TLS 1.3 falls back to the 1-RTT +# handshake when the server does not have any information about the +# client, e.g., because it is in a different cluster which does not +# share state or because the ticket has been deleted as described in +# Section 8.1. If the application-layer protocol retransmits data in +# this setting, then it is possible for an attacker to induce message +# duplication by sending the ClientHello to both the original cluster +# (which processes the data immediately) and another cluster which will +# fall back to 1-RTT and process the data upon application-layer +# replay. The scale of this attack is limited by the client's +# willingness to retry transactions and therefore only allows a limited +# amount of duplication, with each copy appearing as a new connection +# at the server. # -# If implemented correctly, the mechanisms described in Sections 8.1 -# and 8.2 prevent a replayed ClientHello and its associated 0-RTT data -# from being accepted multiple times by any cluster with consistent -# state; for servers which limit the use of 0-RTT to one cluster for a -# single ticket, then a given ClientHello and its associated 0-RTT data -# will only be accepted once. However, if state is not completely -# consistent, then an attacker might be able to have multiple copies of -# the data be accepted during the replication window. Because clients -# do not know the exact details of server behavior, they MUST NOT send -# messages in early data which are not safe to have replayed and which -# they would not be willing to retry across multiple 1-RTT connections. +# If implemented correctly, the mechanisms described in Sections 8.1 +# and 8.2 prevent a replayed ClientHello and its associated 0-RTT data +# from being accepted multiple times by any cluster with consistent +# state; for servers which limit the use of 0-RTT to one cluster for a +# single ticket, then a given ClientHello and its associated 0-RTT data +# will only be accepted once. However, if state is not completely +# consistent, then an attacker might be able to have multiple copies of +# the data be accepted during the replication window. Because clients +# do not know the exact details of server behavior, they MUST NOT send +# messages in early data which are not safe to have replayed and which +# they would not be willing to retry across multiple 1-RTT connections. # -# Application protocols MUST NOT use 0-RTT data without a profile that -# defines its use. That profile needs to identify which messages or -# interactions are safe to use with 0-RTT and how to handle the -# situation when the server rejects 0-RTT and falls back to 1-RTT. +# Application protocols MUST NOT use 0-RTT data without a profile that +# defines its use. That profile needs to identify which messages or +# interactions are safe to use with 0-RTT and how to handle the +# situation when the server rejects 0-RTT and falls back to 1-RTT. # -# In addition, to avoid accidental misuse, TLS implementations MUST NOT -# enable 0-RTT (either sending or accepting) unless specifically -# requested by the application and MUST NOT automatically resend 0-RTT -# data if it is rejected by the server unless instructed by the -# application. Server-side applications may wish to implement special -# processing for 0-RTT data for some kinds of application traffic -# (e.g., abort the connection, request that data be resent at the -# application layer, or delay processing until the handshake -# completes). In order to allow applications to implement this kind of -# processing, TLS implementations MUST provide a way for the -# application to determine if the handshake has completed. +# In addition, to avoid accidental misuse, TLS implementations MUST NOT +# enable 0-RTT (either sending or accepting) unless specifically +# requested by the application and MUST NOT automatically resend 0-RTT +# data if it is rejected by the server unless instructed by the +# application. Server-side applications may wish to implement special +# processing for 0-RTT data for some kinds of application traffic +# (e.g., abort the connection, request that data be resent at the +# application layer, or delay processing until the handshake +# completes). In order to allow applications to implement this kind of +# processing, TLS implementations MUST provide a way for the +# application to determine if the handshake has completed. [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-11.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-11.toml index a916b6cf5f4..4ed2f4bfdfd 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-11.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-11.toml @@ -1,109 +1,109 @@ target = "https://www.rfc-editor.org/rfc/rfc8446#section-11" -# 11. IANA Considerations +# IANA Considerations # -# This document uses several registries that were originally created in -# [RFC4346] and updated in [RFC8447]. IANA has updated these to -# reference this document. The registries and their allocation -# policies are below: -# -# - TLS Cipher Suites registry: values with the first byte in the -# range 0-254 (decimal) are assigned via Specification Required -# [RFC8126]. Values with the first byte 255 (decimal) are reserved -# for Private Use [RFC8126]. -# -# IANA has added the cipher suites listed in Appendix B.4 to the -# registry. The "Value" and "Description" columns are taken from -# the table. The "DTLS-OK" and "Recommended" columns are both -# marked as "Y" for each new cipher suite. -# -# - TLS ContentType registry: Future values are allocated via -# Standards Action [RFC8126]. -# -# - TLS Alerts registry: Future values are allocated via Standards -# Action [RFC8126]. IANA has populated this registry with the -# values from Appendix B.2. The "DTLS-OK" column is marked as "Y" -# for all such values. Values marked as "_RESERVED" have comments -# describing their previous usage. -# -# - TLS HandshakeType registry: Future values are allocated via -# Standards Action [RFC8126]. IANA has updated this registry to -# rename item 4 from "NewSessionTicket" to "new_session_ticket" and -# populated this registry with the values from Appendix B.3. The -# "DTLS-OK" column is marked as "Y" for all such values. Values -# marked "_RESERVED" have comments describing their previous or -# temporary usage. -# -# This document also uses the TLS ExtensionType Values registry -# originally created in [RFC4366]. IANA has updated it to reference -# this document. Changes to the registry follow: -# -# - IANA has updated the registration policy as follows: -# -# Values with the first byte in the range 0-254 (decimal) are -# assigned via Specification Required [RFC8126]. Values with the -# first byte 255 (decimal) are reserved for Private Use [RFC8126]. -# -# - IANA has updated this registry to include the "key_share", -# "pre_shared_key", "psk_key_exchange_modes", "early_data", -# "cookie", "supported_versions", "certificate_authorities", -# "oid_filters", "post_handshake_auth", and -# "signature_algorithms_cert" extensions with the values defined in -# this document and the "Recommended" value of "Y". -# -# - IANA has updated this registry to include a "TLS 1.3" column which -# lists the messages in which the extension may appear. This column -# has been initially populated from the table in Section 4.2, with -# any extension not listed there marked as "-" to indicate that it -# is not used by TLS 1.3. -# -# This document updates an entry in the TLS Certificate Types registry -# originally created in [RFC6091] and updated in [RFC8447]. IANA has -# updated the entry for value 1 to have the name "OpenPGP_RESERVED", -# "Recommended" value "N", and comment "Used in TLS versions prior -# to 1.3." -# -# This document updates an entry in the TLS Certificate Status Types -# registry originally created in [RFC6961]. IANA has updated the entry -# for value 2 to have the name "ocsp_multi_RESERVED" and comment "Used -# in TLS versions prior to 1.3". -# -# This document updates two entries in the TLS Supported Groups -# registry (created under a different name by [RFC4492]; now maintained -# by [RFC8422]) and updated by [RFC7919] and [RFC8447]. The entries -# for values 29 and 30 (x25519 and x448) have been updated to also -# refer to this document. -# -# In addition, this document defines two new registries that are -# maintained by IANA: -# -# - TLS SignatureScheme registry: Values with the first byte in the -# range 0-253 (decimal) are assigned via Specification Required -# [RFC8126]. Values with the first byte 254 or 255 (decimal) are -# reserved for Private Use [RFC8126]. Values with the first byte in -# the range 0-6 or with the second byte in the range 0-3 that are -# not currently allocated are reserved for backward compatibility. -# This registry has a "Recommended" column. The registry has been -# initially populated with the values described in Section 4.2.3. -# The following values are marked as "Recommended": -# ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, -# rsa_pss_rsae_sha256, rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, -# rsa_pss_pss_sha256, rsa_pss_pss_sha384, rsa_pss_pss_sha512, and -# ed25519. The "Recommended" column is assigned a value of "N" -# unless explicitly requested, and adding a value with a -# "Recommended" value of "Y" requires Standards Action [RFC8126]. -# IESG Approval is REQUIRED for a Y->N transition. -# -# - TLS PskKeyExchangeMode registry: Values in the range 0-253 -# (decimal) are assigned via Specification Required [RFC8126]. -# The values 254 and 255 (decimal) are reserved for Private Use -# [RFC8126]. This registry has a "Recommended" column. The -# registry has been initially populated with psk_ke (0) and -# psk_dhe_ke (1). Both are marked as "Recommended". The -# "Recommended" column is assigned a value of "N" unless explicitly -# requested, and adding a value with a "Recommended" value of "Y" -# requires Standards Action [RFC8126]. IESG Approval is REQUIRED -# for a Y->N transition. +# This document uses several registries that were originally created in +# [RFC4346] and updated in [RFC8447]. IANA has updated these to +# reference this document. The registries and their allocation +# policies are below: +# +# - TLS Cipher Suites registry: values with the first byte in the +# range 0-254 (decimal) are assigned via Specification Required +# [RFC8126]. Values with the first byte 255 (decimal) are reserved +# for Private Use [RFC8126]. +# +# IANA has added the cipher suites listed in Appendix B.4 to the +# registry. The "Value" and "Description" columns are taken from +# the table. The "DTLS-OK" and "Recommended" columns are both +# marked as "Y" for each new cipher suite. +# +# - TLS ContentType registry: Future values are allocated via +# Standards Action [RFC8126]. +# +# - TLS Alerts registry: Future values are allocated via Standards +# Action [RFC8126]. IANA has populated this registry with the +# values from Appendix B.2. The "DTLS-OK" column is marked as "Y" +# for all such values. Values marked as "_RESERVED" have comments +# describing their previous usage. +# +# - TLS HandshakeType registry: Future values are allocated via +# Standards Action [RFC8126]. IANA has updated this registry to +# rename item 4 from "NewSessionTicket" to "new_session_ticket" and +# populated this registry with the values from Appendix B.3. The +# "DTLS-OK" column is marked as "Y" for all such values. Values +# marked "_RESERVED" have comments describing their previous or +# temporary usage. +# +# This document also uses the TLS ExtensionType Values registry +# originally created in [RFC4366]. IANA has updated it to reference +# this document. Changes to the registry follow: +# +# - IANA has updated the registration policy as follows: +# +# Values with the first byte in the range 0-254 (decimal) are +# assigned via Specification Required [RFC8126]. Values with the +# first byte 255 (decimal) are reserved for Private Use [RFC8126]. +# +# - IANA has updated this registry to include the "key_share", +# "pre_shared_key", "psk_key_exchange_modes", "early_data", +# "cookie", "supported_versions", "certificate_authorities", +# "oid_filters", "post_handshake_auth", and +# "signature_algorithms_cert" extensions with the values defined in +# this document and the "Recommended" value of "Y". +# +# - IANA has updated this registry to include a "TLS 1.3" column which +# lists the messages in which the extension may appear. This column +# has been initially populated from the table in Section 4.2, with +# any extension not listed there marked as "-" to indicate that it +# is not used by TLS 1.3. +# +# This document updates an entry in the TLS Certificate Types registry +# originally created in [RFC6091] and updated in [RFC8447]. IANA has +# updated the entry for value 1 to have the name "OpenPGP_RESERVED", +# "Recommended" value "N", and comment "Used in TLS versions prior +# to 1.3." +# +# This document updates an entry in the TLS Certificate Status Types +# registry originally created in [RFC6961]. IANA has updated the entry +# for value 2 to have the name "ocsp_multi_RESERVED" and comment "Used +# in TLS versions prior to 1.3". +# +# This document updates two entries in the TLS Supported Groups +# registry (created under a different name by [RFC4492]; now maintained +# by [RFC8422]) and updated by [RFC7919] and [RFC8447]. The entries +# for values 29 and 30 (x25519 and x448) have been updated to also +# refer to this document. +# +# In addition, this document defines two new registries that are +# maintained by IANA: +# +# - TLS SignatureScheme registry: Values with the first byte in the +# range 0-253 (decimal) are assigned via Specification Required +# [RFC8126]. Values with the first byte 254 or 255 (decimal) are +# reserved for Private Use [RFC8126]. Values with the first byte in +# the range 0-6 or with the second byte in the range 0-3 that are +# not currently allocated are reserved for backward compatibility. +# This registry has a "Recommended" column. The registry has been +# initially populated with the values described in Section 4.2.3. +# The following values are marked as "Recommended": +# ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, +# rsa_pss_rsae_sha256, rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, +# rsa_pss_pss_sha256, rsa_pss_pss_sha384, rsa_pss_pss_sha512, and +# ed25519. The "Recommended" column is assigned a value of "N" +# unless explicitly requested, and adding a value with a +# "Recommended" value of "Y" requires Standards Action [RFC8126]. +# IESG Approval is REQUIRED for a Y->N transition. +# +# - TLS PskKeyExchangeMode registry: Values in the range 0-253 +# (decimal) are assigned via Specification Required [RFC8126]. +# The values 254 and 255 (decimal) are reserved for Private Use +# [RFC8126]. This registry has a "Recommended" column. The +# registry has been initially populated with psk_ke (0) and +# psk_dhe_ke (1). Both are marked as "Recommended". The +# "Recommended" column is assigned a value of "N" unless explicitly +# requested, and adding a value with a "Recommended" value of "Y" +# requires Standards Action [RFC8126]. IESG Approval is REQUIRED +# for a Y->N transition. [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-2.1.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-2.1.toml index aa8de37b91c..bf903ecdf3b 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-2.1.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-2.1.toml @@ -1,45 +1,45 @@ target = "https://www.rfc-editor.org/rfc/rfc8446#section-2.1" -# 2.1. Incorrect DHE Share +# Incorrect DHE Share # -# If the client has not provided a sufficient "key_share" extension -# (e.g., it includes only DHE or ECDHE groups unacceptable to or -# unsupported by the server), the server corrects the mismatch with a -# HelloRetryRequest and the client needs to restart the handshake with -# an appropriate "key_share" extension, as shown in Figure 2. If no -# common cryptographic parameters can be negotiated, the server MUST -# abort the handshake with an appropriate alert. +# If the client has not provided a sufficient "key_share" extension +# (e.g., it includes only DHE or ECDHE groups unacceptable to or +# unsupported by the server), the server corrects the mismatch with a +# HelloRetryRequest and the client needs to restart the handshake with +# an appropriate "key_share" extension, as shown in Figure 2. If no +# common cryptographic parameters can be negotiated, the server MUST +# abort the handshake with an appropriate alert. # -# Client Server +# Client Server # -# ClientHello -# + key_share --------> -# HelloRetryRequest -# <-------- + key_share -# ClientHello -# + key_share --------> -# ServerHello -# + key_share -# {EncryptedExtensions} -# {CertificateRequest*} -# {Certificate*} -# {CertificateVerify*} -# {Finished} -# <-------- [Application Data*] -# {Certificate*} -# {CertificateVerify*} -# {Finished} --------> -# [Application Data] <-------> [Application Data] +# ClientHello +# + key_share --------> +# HelloRetryRequest +# <-------- + key_share +# ClientHello +# + key_share --------> +# ServerHello +# + key_share +# {EncryptedExtensions} +# {CertificateRequest*} +# {Certificate*} +# {CertificateVerify*} +# {Finished} +# <-------- [Application Data*] +# {Certificate*} +# {CertificateVerify*} +# {Finished} --------> +# [Application Data] <-------> [Application Data] # -# Figure 2: Message Flow for a Full Handshake with -# Mismatched Parameters +# Figure 2: Message Flow for a Full Handshake with +# Mismatched Parameters # -# Note: The handshake transcript incorporates the initial -# ClientHello/HelloRetryRequest exchange; it is not reset with the -# new ClientHello. +# Note: The handshake transcript incorporates the initial +# ClientHello/HelloRetryRequest exchange; it is not reset with the +# new ClientHello. # -# TLS also allows several optimized variants of the basic handshake, as -# described in the following sections. +# TLS also allows several optimized variants of the basic handshake, as +# described in the following sections. [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-2.2.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-2.2.toml index ef6f697a9a4..618e513a6ba 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-2.2.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-2.2.toml @@ -1,86 +1,86 @@ target = "https://www.rfc-editor.org/rfc/rfc8446#section-2.2" -# 2.2. Resumption and Pre-Shared Key (PSK) +# Resumption and Pre-Shared Key (PSK) # -# Although TLS PSKs can be established out of band, PSKs can also be -# established in a previous connection and then used to establish a new -# connection ("session resumption" or "resuming" with a PSK). Once a -# handshake has completed, the server can send the client a PSK -# identity that corresponds to a unique key derived from the initial -# handshake (see Section 4.6.1). The client can then use that PSK -# identity in future handshakes to negotiate the use of the associated -# PSK. If the server accepts the PSK, then the security context of the -# new connection is cryptographically tied to the original connection -# and the key derived from the initial handshake is used to bootstrap -# the cryptographic state instead of a full handshake. In TLS 1.2 and -# below, this functionality was provided by "session IDs" and "session -# tickets" [RFC5077]. Both mechanisms are obsoleted in TLS 1.3. +# Although TLS PSKs can be established out of band, PSKs can also be +# established in a previous connection and then used to establish a new +# connection ("session resumption" or "resuming" with a PSK). Once a +# handshake has completed, the server can send the client a PSK +# identity that corresponds to a unique key derived from the initial +# handshake (see Section 4.6.1). The client can then use that PSK +# identity in future handshakes to negotiate the use of the associated +# PSK. If the server accepts the PSK, then the security context of the +# new connection is cryptographically tied to the original connection +# and the key derived from the initial handshake is used to bootstrap +# the cryptographic state instead of a full handshake. In TLS 1.2 and +# below, this functionality was provided by "session IDs" and "session +# tickets" [RFC5077]. Both mechanisms are obsoleted in TLS 1.3. # -# PSKs can be used with (EC)DHE key exchange in order to provide -# forward secrecy in combination with shared keys, or can be used -# alone, at the cost of losing forward secrecy for the application -# data. +# PSKs can be used with (EC)DHE key exchange in order to provide +# forward secrecy in combination with shared keys, or can be used +# alone, at the cost of losing forward secrecy for the application +# data. # -# Figure 3 shows a pair of handshakes in which the first handshake -# establishes a PSK and the second handshake uses it: +# Figure 3 shows a pair of handshakes in which the first handshake +# establishes a PSK and the second handshake uses it: # -# Client Server +# Client Server # -# Initial Handshake: -# ClientHello -# + key_share --------> -# ServerHello -# + key_share -# {EncryptedExtensions} -# {CertificateRequest*} -# {Certificate*} -# {CertificateVerify*} -# {Finished} -# <-------- [Application Data*] -# {Certificate*} -# {CertificateVerify*} -# {Finished} --------> -# <-------- [NewSessionTicket] -# [Application Data] <-------> [Application Data] +# Initial Handshake: +# ClientHello +# + key_share --------> +# ServerHello +# + key_share +# {EncryptedExtensions} +# {CertificateRequest*} +# {Certificate*} +# {CertificateVerify*} +# {Finished} +# <-------- [Application Data*] +# {Certificate*} +# {CertificateVerify*} +# {Finished} --------> +# <-------- [NewSessionTicket] +# [Application Data] <-------> [Application Data] # -# Subsequent Handshake: -# ClientHello -# + key_share* -# + pre_shared_key --------> -# ServerHello -# + pre_shared_key -# + key_share* -# {EncryptedExtensions} -# {Finished} -# <-------- [Application Data*] -# {Finished} --------> -# [Application Data] <-------> [Application Data] +# Subsequent Handshake: +# ClientHello +# + key_share* +# + pre_shared_key --------> +# ServerHello +# + pre_shared_key +# + key_share* +# {EncryptedExtensions} +# {Finished} +# <-------- [Application Data*] +# {Finished} --------> +# [Application Data] <-------> [Application Data] # -# Figure 3: Message Flow for Resumption and PSK +# Figure 3: Message Flow for Resumption and PSK # -# As the server is authenticating via a PSK, it does not send a -# Certificate or a CertificateVerify message. When a client offers -# resumption via a PSK, it SHOULD also supply a "key_share" extension -# to the server to allow the server to decline resumption and fall back -# to a full handshake, if needed. The server responds with a -# "pre_shared_key" extension to negotiate the use of PSK key -# establishment and can (as shown here) respond with a "key_share" -# extension to do (EC)DHE key establishment, thus providing forward -# secrecy. +# As the server is authenticating via a PSK, it does not send a +# Certificate or a CertificateVerify message. When a client offers +# resumption via a PSK, it SHOULD also supply a "key_share" extension +# to the server to allow the server to decline resumption and fall back +# to a full handshake, if needed. The server responds with a +# "pre_shared_key" extension to negotiate the use of PSK key +# establishment and can (as shown here) respond with a "key_share" +# extension to do (EC)DHE key establishment, thus providing forward +# secrecy. # -# When PSKs are provisioned out of band, the PSK identity and the KDF -# hash algorithm to be used with the PSK MUST also be provisioned. +# When PSKs are provisioned out of band, the PSK identity and the KDF +# hash algorithm to be used with the PSK MUST also be provisioned. # -# Note: When using an out-of-band provisioned pre-shared secret, a -# critical consideration is using sufficient entropy during the key -# generation, as discussed in [RFC4086]. Deriving a shared secret -# from a password or other low-entropy sources is not secure. A -# low-entropy secret, or password, is subject to dictionary attacks -# based on the PSK binder. The specified PSK authentication is not -# a strong password-based authenticated key exchange even when used -# with Diffie-Hellman key establishment. Specifically, it does not -# prevent an attacker that can observe the handshake from performing -# a brute-force attack on the password/pre-shared key. +# Note: When using an out-of-band provisioned pre-shared secret, a +# critical consideration is using sufficient entropy during the key +# generation, as discussed in [RFC4086]. Deriving a shared secret +# from a password or other low-entropy sources is not secure. A +# low-entropy secret, or password, is subject to dictionary attacks +# based on the PSK binder. The specified PSK authentication is not +# a strong password-based authenticated key exchange even when used +# with Diffie-Hellman key establishment. Specifically, it does not +# prevent an attacker that can observe the handshake from performing +# a brute-force attack on the password/pre-shared key. [[spec]] level = "SHOULD" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-2.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-2.toml index 0fdbabfd136..2a381ce546f 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-2.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-2.toml @@ -1,150 +1,153 @@ target = "https://www.rfc-editor.org/rfc/rfc8446#section-2" -# 2. Protocol Overview +# Protocol Overview # -# The cryptographic parameters used by the secure channel are produced -# by the TLS handshake protocol. This sub-protocol of TLS is used by -# the client and server when first communicating with each other. The -# handshake protocol allows peers to negotiate a protocol version, -# select cryptographic algorithms, optionally authenticate each other, -# and establish shared secret keying material. Once the handshake is -# complete, the peers use the established keys to protect the -# application-layer traffic. -# -# A failure of the handshake or other protocol error triggers the -# termination of the connection, optionally preceded by an alert -# message (Section 6). -# -# TLS supports three basic key exchange modes: -# -# - (EC)DHE (Diffie-Hellman over either finite fields or elliptic -# curves) -# -# - PSK-only -# -# - PSK with (EC)DHE -# -# Figure 1 below shows the basic full TLS handshake: -# -# Client Server -# -# | + signature_algorithms* -# | + psk_key_exchange_modes* -# v + pre_shared_key* --------> -# ServerHello ^ Key -# + key_share* | Exch -# + pre_shared_key* v -# {EncryptedExtensions} ^ Server -# {CertificateRequest*} v Params -# {Certificate*} ^ -# {CertificateVerify*} | Auth -# {Finished} v -# <-------- [Application Data*] -# ^ {Certificate*} -# v {Finished} --------> -# [Application Data] <-------> [Application Data] -# -# + Indicates noteworthy extensions sent in the -# previously noted message. -# -# * Indicates optional or situation-dependent -# messages/extensions that are not always sent. -# -# {} Indicates messages protected using keys -# derived from a [sender]_handshake_traffic_secret. -# -# [] Indicates messages protected using keys -# derived from [sender]_application_traffic_secret_N. -# -# Figure 1: Message Flow for Full TLS Handshake -# -# The handshake can be thought of as having three phases (indicated in -# the diagram above): -# -# - Key Exchange: Establish shared keying material and select the -# cryptographic parameters. Everything after this phase is -# encrypted. -# -# - Server Parameters: Establish other handshake parameters -# (whether the client is authenticated, application-layer protocol -# support, etc.). -# -# - Authentication: Authenticate the server (and, optionally, the -# client) and provide key confirmation and handshake integrity. -# -# In the Key Exchange phase, the client sends the ClientHello -# (Section 4.1.2) message, which contains a random nonce -# (ClientHello.random); its offered protocol versions; a list of -# symmetric cipher/HKDF hash pairs; either a set of Diffie-Hellman key -# shares (in the "key_share" (Section 4.2.8) extension), a set of -# pre-shared key labels (in the "pre_shared_key" (Section 4.2.11) -# extension), or both; and potentially additional extensions. -# Additional fields and/or messages may also be present for middlebox -# compatibility. -# -# The server processes the ClientHello and determines the appropriate -# cryptographic parameters for the connection. It then responds with -# its own ServerHello (Section 4.1.3), which indicates the negotiated -# connection parameters. The combination of the ClientHello and the -# ServerHello determines the shared keys. If (EC)DHE key establishment -# is in use, then the ServerHello contains a "key_share" extension with -# the server's ephemeral Diffie-Hellman share; the server's share MUST -# be in the same group as one of the client's shares. If PSK key -# establishment is in use, then the ServerHello contains a -# "pre_shared_key" extension indicating which of the client's offered -# PSKs was selected. Note that implementations can use (EC)DHE and PSK -# together, in which case both extensions will be supplied. -# -# The server then sends two messages to establish the Server -# Parameters: -# -# EncryptedExtensions: responses to ClientHello extensions that are -# not required to determine the cryptographic parameters, other than -# those that are specific to individual certificates. -# [Section 4.3.1] -# -# CertificateRequest: if certificate-based client authentication is -# desired, the desired parameters for that certificate. This -# message is omitted if client authentication is not desired. -# [Section 4.3.2] -# -# Finally, the client and server exchange Authentication messages. TLS -# uses the same set of messages every time that certificate-based -# authentication is needed. (PSK-based authentication happens as a -# side effect of key exchange.) Specifically: -# -# Certificate: The certificate of the endpoint and any per-certificate -# extensions. This message is omitted by the server if not -# authenticating with a certificate and by the client if the server -# did not send CertificateRequest (thus indicating that the client -# should not authenticate with a certificate). Note that if raw -# public keys [RFC7250] or the cached information extension -# [RFC7924] are in use, then this message will not contain a -# certificate but rather some other value corresponding to the -# server's long-term key. [Section 4.4.2] -# -# CertificateVerify: A signature over the entire handshake using the -# private key corresponding to the public key in the Certificate -# message. This message is omitted if the endpoint is not -# authenticating via a certificate. [Section 4.4.3] -# -# Finished: A MAC (Message Authentication Code) over the entire -# handshake. This message provides key confirmation, binds the -# endpoint's identity to the exchanged keys, and in PSK mode also -# authenticates the handshake. [Section 4.4.4] -# -# Upon receiving the server's messages, the client responds with its -# Authentication messages, namely Certificate and CertificateVerify (if -# requested), and Finished. -# -# At this point, the handshake is complete, and the client and server -# derive the keying material required by the record layer to exchange -# application-layer data protected through authenticated encryption. -# Application Data MUST NOT be sent prior to sending the Finished -# message, except as specified in Section 2.3. Note that while the -# server may send Application Data prior to receiving the client's -# Authentication messages, any data sent at that point is, of course, -# being sent to an unauthenticated peer. +# The cryptographic parameters used by the secure channel are produced +# by the TLS handshake protocol. This sub-protocol of TLS is used by +# the client and server when first communicating with each other. The +# handshake protocol allows peers to negotiate a protocol version, +# select cryptographic algorithms, optionally authenticate each other, +# and establish shared secret keying material. Once the handshake is +# complete, the peers use the established keys to protect the +# application-layer traffic. +# +# A failure of the handshake or other protocol error triggers the +# termination of the connection, optionally preceded by an alert +# message (Section 6). +# +# TLS supports three basic key exchange modes: +# +# - (EC)DHE (Diffie-Hellman over either finite fields or elliptic +# curves) +# +# - PSK-only +# +# - PSK with (EC)DHE +# +# Figure 1 below shows the basic full TLS handshake: +# +# Client Server +# +# Key ^ ClientHello +# Exch | + key_share* +# | + signature_algorithms* +# | + psk_key_exchange_modes* +# v + pre_shared_key* --------> +# ServerHello ^ Key +# + key_share* | Exch +# + pre_shared_key* v +# {EncryptedExtensions} ^ Server +# {CertificateRequest*} v Params +# {Certificate*} ^ +# {CertificateVerify*} | Auth +# {Finished} v +# <-------- [Application Data*] +# ^ {Certificate*} +# Auth | {CertificateVerify*} +# v {Finished} --------> +# [Application Data] <-------> [Application Data] +# +# + Indicates noteworthy extensions sent in the +# previously noted message. +# +# * Indicates optional or situation-dependent +# messages/extensions that are not always sent. +# +# {} Indicates messages protected using keys +# derived from a [sender]_handshake_traffic_secret. +# +# [] Indicates messages protected using keys +# derived from [sender]_application_traffic_secret_N. +# +# Figure 1: Message Flow for Full TLS Handshake +# +# The handshake can be thought of as having three phases (indicated in +# the diagram above): +# +# - Key Exchange: Establish shared keying material and select the +# cryptographic parameters. Everything after this phase is +# encrypted. +# +# - Server Parameters: Establish other handshake parameters +# (whether the client is authenticated, application-layer protocol +# support, etc.). +# +# - Authentication: Authenticate the server (and, optionally, the +# client) and provide key confirmation and handshake integrity. +# +# In the Key Exchange phase, the client sends the ClientHello +# (Section 4.1.2) message, which contains a random nonce +# (ClientHello.random); its offered protocol versions; a list of +# symmetric cipher/HKDF hash pairs; either a set of Diffie-Hellman key +# shares (in the "key_share" (Section 4.2.8) extension), a set of +# pre-shared key labels (in the "pre_shared_key" (Section 4.2.11) +# extension), or both; and potentially additional extensions. +# Additional fields and/or messages may also be present for middlebox +# compatibility. +# +# The server processes the ClientHello and determines the appropriate +# cryptographic parameters for the connection. It then responds with +# its own ServerHello (Section 4.1.3), which indicates the negotiated +# connection parameters. The combination of the ClientHello and the +# ServerHello determines the shared keys. If (EC)DHE key establishment +# is in use, then the ServerHello contains a "key_share" extension with +# the server's ephemeral Diffie-Hellman share; the server's share MUST +# be in the same group as one of the client's shares. If PSK key +# establishment is in use, then the ServerHello contains a +# "pre_shared_key" extension indicating which of the client's offered +# PSKs was selected. Note that implementations can use (EC)DHE and PSK +# together, in which case both extensions will be supplied. +# +# The server then sends two messages to establish the Server +# Parameters: +# +# EncryptedExtensions: responses to ClientHello extensions that are +# not required to determine the cryptographic parameters, other than +# those that are specific to individual certificates. +# [Section 4.3.1] +# +# CertificateRequest: if certificate-based client authentication is +# desired, the desired parameters for that certificate. This +# message is omitted if client authentication is not desired. +# [Section 4.3.2] +# +# Finally, the client and server exchange Authentication messages. TLS +# uses the same set of messages every time that certificate-based +# authentication is needed. (PSK-based authentication happens as a +# side effect of key exchange.) Specifically: +# +# Certificate: The certificate of the endpoint and any per-certificate +# extensions. This message is omitted by the server if not +# authenticating with a certificate and by the client if the server +# did not send CertificateRequest (thus indicating that the client +# should not authenticate with a certificate). Note that if raw +# public keys [RFC7250] or the cached information extension +# [RFC7924] are in use, then this message will not contain a +# certificate but rather some other value corresponding to the +# server's long-term key. [Section 4.4.2] +# +# CertificateVerify: A signature over the entire handshake using the +# private key corresponding to the public key in the Certificate +# message. This message is omitted if the endpoint is not +# authenticating via a certificate. [Section 4.4.3] +# +# Finished: A MAC (Message Authentication Code) over the entire +# handshake. This message provides key confirmation, binds the +# endpoint's identity to the exchanged keys, and in PSK mode also +# authenticates the handshake. [Section 4.4.4] +# +# Upon receiving the server's messages, the client responds with its +# Authentication messages, namely Certificate and CertificateVerify (if +# requested), and Finished. +# +# At this point, the handshake is complete, and the client and server +# derive the keying material required by the record layer to exchange +# application-layer data protected through authenticated encryption. +# Application Data MUST NOT be sent prior to sending the Finished +# message, except as specified in Section 2.3. Note that while the +# server may send Application Data prior to receiving the client's +# Authentication messages, any data sent at that point is, of course, +# being sent to an unauthenticated peer. [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.1.1.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.1.1.toml index e5b25b64c8a..3569b401c30 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.1.1.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.1.1.toml @@ -1,69 +1,69 @@ target = "https://www.rfc-editor.org/rfc/rfc8446#section-4.1.1" -# 4.1.1. Cryptographic Negotiation +# Cryptographic Negotiation # -# In TLS, the cryptographic negotiation proceeds by the client offering -# the following four sets of options in its ClientHello: +# 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 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 "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 "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. +# - 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 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 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 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 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. +# - 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 (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. +# - 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). +# 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" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.1.2.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.1.2.toml index 1b91caeee8a..08ab23d51c5 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.1.2.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.1.2.toml @@ -1,145 +1,145 @@ target = "https://www.rfc-editor.org/rfc/rfc8446#section-4.1.2" -# 4.1.2. Client Hello +# Client Hello # -# When a client first connects to a server, it is REQUIRED to send the -# ClientHello as its first TLS message. The client will also send a -# ClientHello when the server has responded to its ClientHello with a -# HelloRetryRequest. In that case, the client MUST send the same -# ClientHello without modification, except as follows: +# When a client first connects to a server, it is REQUIRED to send the +# ClientHello as its first TLS message. The client will also send a +# ClientHello when the server has responded to its ClientHello with a +# HelloRetryRequest. In that case, the client MUST send the same +# ClientHello without modification, except as follows: # -# - If a "key_share" extension was supplied in the HelloRetryRequest, -# replacing the list of shares with a list containing a single -# KeyShareEntry from the indicated group. +# - If a "key_share" extension was supplied in the HelloRetryRequest, +# replacing the list of shares with a list containing a single +# KeyShareEntry from the indicated group. # -# - Removing the "early_data" extension (Section 4.2.10) if one was -# present. Early data is not permitted after a HelloRetryRequest. +# - Removing the "early_data" extension (Section 4.2.10) if one was +# present. Early data is not permitted after a HelloRetryRequest. # -# - Including a "cookie" extension if one was provided in the -# HelloRetryRequest. +# - Including a "cookie" extension if one was provided in the +# HelloRetryRequest. # -# - Updating the "pre_shared_key" extension if present by recomputing -# the "obfuscated_ticket_age" and binder values and (optionally) -# removing any PSKs which are incompatible with the server's -# indicated cipher suite. +# - Updating the "pre_shared_key" extension if present by recomputing +# the "obfuscated_ticket_age" and binder values and (optionally) +# removing any PSKs which are incompatible with the server's +# indicated cipher suite. # -# - Optionally adding, removing, or changing the length of the -# "padding" extension [RFC7685]. +# - Optionally adding, removing, or changing the length of the +# "padding" extension [RFC7685]. # -# - Other modifications that may be allowed by an extension defined in -# the future and present in the HelloRetryRequest. +# - Other modifications that may be allowed by an extension defined in +# the future and present in the HelloRetryRequest. # -# Because TLS 1.3 forbids renegotiation, if a server has negotiated -# TLS 1.3 and receives a ClientHello at any other time, it MUST -# terminate the connection with an "unexpected_message" alert. +# Because TLS 1.3 forbids renegotiation, if a server has negotiated +# TLS 1.3 and receives a ClientHello at any other time, it MUST +# terminate the connection with an "unexpected_message" alert. # -# If a server established a TLS connection with a previous version of -# TLS and receives a TLS 1.3 ClientHello in a renegotiation, it MUST -# retain the previous protocol version. In particular, it MUST NOT -# negotiate TLS 1.3. +# If a server established a TLS connection with a previous version of +# TLS and receives a TLS 1.3 ClientHello in a renegotiation, it MUST +# retain the previous protocol version. In particular, it MUST NOT +# negotiate TLS 1.3. # -# Structure of this message: +# Structure of this message: # -# uint16 ProtocolVersion; -# opaque Random[32]; +# uint16 ProtocolVersion; +# opaque Random[32]; # -# uint8 CipherSuite[2]; /* Cryptographic suite selector */ +# uint8 CipherSuite[2]; /* Cryptographic suite selector */ # -# struct { -# ProtocolVersion legacy_version = 0x0303; /* TLS v1.2 */ -# Random random; -# opaque legacy_session_id<0..32>; -# CipherSuite cipher_suites<2..2^16-2>; -# opaque legacy_compression_methods<1..2^8-1>; -# Extension extensions<8..2^16-1>; -# } ClientHello; +# struct { +# ProtocolVersion legacy_version = 0x0303; /* TLS v1.2 */ +# Random random; +# opaque legacy_session_id<0..32>; +# CipherSuite cipher_suites<2..2^16-2>; +# opaque legacy_compression_methods<1..2^8-1>; +# Extension extensions<8..2^16-1>; +# } ClientHello; # -# legacy_version: In previous versions of TLS, this field was used for -# version negotiation and represented the highest version number -# supported by the client. Experience has shown that many servers -# do not properly implement version negotiation, leading to "version -# intolerance" in which the server rejects an otherwise acceptable -# ClientHello with a version number higher than it supports. In -# TLS 1.3, the client indicates its version preferences in the -# "supported_versions" extension (Section 4.2.1) and the -# legacy_version field MUST be set to 0x0303, which is the version -# number for TLS 1.2. TLS 1.3 ClientHellos are identified as having -# a legacy_version of 0x0303 and a supported_versions extension -# present with 0x0304 as the highest version indicated therein. -# (See Appendix D for details about backward compatibility.) +# legacy_version: In previous versions of TLS, this field was used for +# version negotiation and represented the highest version number +# supported by the client. Experience has shown that many servers +# do not properly implement version negotiation, leading to "version +# intolerance" in which the server rejects an otherwise acceptable +# ClientHello with a version number higher than it supports. In +# TLS 1.3, the client indicates its version preferences in the +# "supported_versions" extension (Section 4.2.1) and the +# legacy_version field MUST be set to 0x0303, which is the version +# number for TLS 1.2. TLS 1.3 ClientHellos are identified as having +# a legacy_version of 0x0303 and a supported_versions extension +# present with 0x0304 as the highest version indicated therein. +# (See Appendix D for details about backward compatibility.) # -# random: 32 bytes generated by a secure random number generator. See -# Appendix C for additional information. +# random: 32 bytes generated by a secure random number generator. See +# Appendix C for additional information. # -# legacy_session_id: Versions of TLS before TLS 1.3 supported a -# "session resumption" feature which has been merged with pre-shared -# keys in this version (see Section 2.2). A client which has a -# cached session ID set by a pre-TLS 1.3 server SHOULD set this -# field to that value. In compatibility mode (see Appendix D.4), -# this field MUST be non-empty, so a client not offering a -# pre-TLS 1.3 session MUST generate a new 32-byte value. This value -# need not be random but SHOULD be unpredictable to avoid -# implementations fixating on a specific value (also known as -# ossification). Otherwise, it MUST be set as a zero-length vector -# (i.e., a zero-valued single byte length field). +# legacy_session_id: Versions of TLS before TLS 1.3 supported a +# "session resumption" feature which has been merged with pre-shared +# keys in this version (see Section 2.2). A client which has a +# cached session ID set by a pre-TLS 1.3 server SHOULD set this +# field to that value. In compatibility mode (see Appendix D.4), +# this field MUST be non-empty, so a client not offering a +# pre-TLS 1.3 session MUST generate a new 32-byte value. This value +# need not be random but SHOULD be unpredictable to avoid +# implementations fixating on a specific value (also known as +# ossification). Otherwise, it MUST be set as a zero-length vector +# (i.e., a zero-valued single byte length field). # -# cipher_suites: A list of the symmetric cipher options supported by -# the client, specifically the record protection algorithm -# (including secret key length) and a hash to be used with HKDF, in -# descending order of client preference. Values are defined in -# Appendix B.4. If the list contains cipher suites that the server -# does not recognize, support, or wish to use, the server MUST -# ignore those cipher suites and process the remaining ones as -# usual. If the client is attempting a PSK key establishment, it -# SHOULD advertise at least one cipher suite indicating a Hash -# associated with the PSK. +# cipher_suites: A list of the symmetric cipher options supported by +# the client, specifically the record protection algorithm +# (including secret key length) and a hash to be used with HKDF, in +# descending order of client preference. Values are defined in +# Appendix B.4. If the list contains cipher suites that the server +# does not recognize, support, or wish to use, the server MUST +# ignore those cipher suites and process the remaining ones as +# usual. If the client is attempting a PSK key establishment, it +# SHOULD advertise at least one cipher suite indicating a Hash +# associated with the PSK. # -# legacy_compression_methods: Versions of TLS before 1.3 supported -# compression with the list of supported compression methods being -# sent in this field. For every TLS 1.3 ClientHello, this vector -# MUST contain exactly one byte, set to zero, which corresponds to -# the "null" compression method in prior versions of TLS. If a -# TLS 1.3 ClientHello is received with any other value in this -# field, the server MUST abort the handshake with an -# "illegal_parameter" alert. Note that TLS 1.3 servers might -# receive TLS 1.2 or prior ClientHellos which contain other -# compression methods and (if negotiating such a prior version) MUST -# follow the procedures for the appropriate prior version of TLS. +# legacy_compression_methods: Versions of TLS before 1.3 supported +# compression with the list of supported compression methods being +# sent in this field. For every TLS 1.3 ClientHello, this vector +# MUST contain exactly one byte, set to zero, which corresponds to +# the "null" compression method in prior versions of TLS. If a +# TLS 1.3 ClientHello is received with any other value in this +# field, the server MUST abort the handshake with an +# "illegal_parameter" alert. Note that TLS 1.3 servers might +# receive TLS 1.2 or prior ClientHellos which contain other +# compression methods and (if negotiating such a prior version) MUST +# follow the procedures for the appropriate prior version of TLS. # -# extensions: Clients request extended functionality from servers by -# sending data in the extensions field. The actual "Extension" -# format is defined in Section 4.2. In TLS 1.3, the use of certain -# extensions is mandatory, as functionality has moved into -# extensions to preserve ClientHello compatibility with previous -# versions of TLS. Servers MUST ignore unrecognized extensions. +# extensions: Clients request extended functionality from servers by +# sending data in the extensions field. The actual "Extension" +# format is defined in Section 4.2. In TLS 1.3, the use of certain +# extensions is mandatory, as functionality has moved into +# extensions to preserve ClientHello compatibility with previous +# versions of TLS. Servers MUST ignore unrecognized extensions. # -# All versions of TLS allow an extensions field to optionally follow -# the compression_methods field. TLS 1.3 ClientHello messages always -# contain extensions (minimally "supported_versions", otherwise, they -# will be interpreted as TLS 1.2 ClientHello messages). However, -# TLS 1.3 servers might receive ClientHello messages without an -# extensions field from prior versions of TLS. The presence of -# extensions can be detected by determining whether there are bytes -# following the compression_methods field at the end of the -# ClientHello. Note that this method of detecting optional data -# differs from the normal TLS method of having a variable-length field, -# but it is used for compatibility with TLS before extensions were -# defined. TLS 1.3 servers will need to perform this check first and -# only attempt to negotiate TLS 1.3 if the "supported_versions" -# extension is present. If negotiating a version of TLS prior to 1.3, -# a server MUST check that the message either contains no data after -# legacy_compression_methods or that it contains a valid extensions -# block with no data following. If not, then it MUST abort the -# handshake with a "decode_error" alert. +# All versions of TLS allow an extensions field to optionally follow +# the compression_methods field. TLS 1.3 ClientHello messages always +# contain extensions (minimally "supported_versions", otherwise, they +# will be interpreted as TLS 1.2 ClientHello messages). However, +# TLS 1.3 servers might receive ClientHello messages without an +# extensions field from prior versions of TLS. The presence of +# extensions can be detected by determining whether there are bytes +# following the compression_methods field at the end of the +# ClientHello. Note that this method of detecting optional data +# differs from the normal TLS method of having a variable-length field, +# but it is used for compatibility with TLS before extensions were +# defined. TLS 1.3 servers will need to perform this check first and +# only attempt to negotiate TLS 1.3 if the "supported_versions" +# extension is present. If negotiating a version of TLS prior to 1.3, +# a server MUST check that the message either contains no data after +# legacy_compression_methods or that it contains a valid extensions +# block with no data following. If not, then it MUST abort the +# handshake with a "decode_error" alert. # -# In the event that a client requests additional functionality using -# extensions and this functionality is not supplied by the server, the -# client MAY abort the handshake. +# In the event that a client requests additional functionality using +# extensions and this functionality is not supplied by the server, the +# client MAY abort the handshake. # -# After sending the ClientHello message, the client waits for a -# ServerHello or HelloRetryRequest message. If early data is in use, -# the client may transmit early Application Data (Section 2.3) while -# waiting for the next handshake message. +# After sending the ClientHello message, the client waits for a +# ServerHello or HelloRetryRequest message. If early data is in use, +# the client may transmit early Application Data (Section 2.3) while +# waiting for the next handshake message. [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.1.3.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.1.3.toml index 578cd40cb76..e465c9e3b78 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.1.3.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.1.3.toml @@ -1,114 +1,114 @@ target = "https://www.rfc-editor.org/rfc/rfc8446#section-4.1.3" -# 4.1.3. Server Hello +# Server Hello # -# The server will send this message in response to a ClientHello -# message to proceed with the handshake if it is able to negotiate an -# acceptable set of handshake parameters based on the ClientHello. -# -# Structure of this message: -# -# struct { -# ProtocolVersion legacy_version = 0x0303; /* TLS v1.2 */ -# Random random; -# opaque legacy_session_id_echo<0..32>; -# CipherSuite cipher_suite; -# uint8 legacy_compression_method = 0; -# Extension extensions<6..2^16-1>; -# } ServerHello; -# -# legacy_version: In previous versions of TLS, this field was used for -# version negotiation and represented the selected version number -# for the connection. Unfortunately, some middleboxes fail when -# presented with new values. In TLS 1.3, the TLS server indicates -# its version using the "supported_versions" extension -# (Section 4.2.1), and the legacy_version field MUST be set to -# 0x0303, which is the version number for TLS 1.2. (See Appendix D -# for details about backward compatibility.) -# -# random: 32 bytes generated by a secure random number generator. See -# Appendix C for additional information. The last 8 bytes MUST be -# overwritten as described below if negotiating TLS 1.2 or TLS 1.1, -# but the remaining bytes MUST be random. This structure is -# generated by the server and MUST be generated independently of the -# ClientHello.random. -# -# legacy_session_id_echo: The contents of the client's -# legacy_session_id field. Note that this field is echoed even if -# the client's value corresponded to a cached pre-TLS 1.3 session -# which the server has chosen not to resume. A client which -# receives a legacy_session_id_echo field that does not match what -# it sent in the ClientHello MUST abort the handshake with an -# "illegal_parameter" alert. -# -# cipher_suite: The single cipher suite selected by the server from -# the list in ClientHello.cipher_suites. A client which receives a -# cipher suite that was not offered MUST abort the handshake with an -# "illegal_parameter" alert. -# -# legacy_compression_method: A single byte which MUST have the -# value 0. -# -# extensions: A list of extensions. The ServerHello MUST only include -# extensions which are required to establish the cryptographic -# context and negotiate the protocol version. All TLS 1.3 -# ServerHello messages MUST contain the "supported_versions" -# extension. Current ServerHello messages additionally contain -# either the "pre_shared_key" extension or the "key_share" -# extension, or both (when using a PSK with (EC)DHE key -# establishment). Other extensions (see Section 4.2) are sent -# separately in the EncryptedExtensions message. -# -# For reasons of backward compatibility with middleboxes (see -# Appendix D.4), the HelloRetryRequest message uses the same structure -# as the ServerHello, but with Random set to the special value of the -# SHA-256 of "HelloRetryRequest": -# -# CF 21 AD 74 E5 9A 61 11 BE 1D 8C 02 1E 65 B8 91 -# C2 A2 11 16 7A BB 8C 5E 07 9E 09 E2 C8 A8 33 9C -# -# Upon receiving a message with type server_hello, implementations MUST -# first examine the Random value and, if it matches this value, process -# it as described in Section 4.1.4). -# -# TLS 1.3 has a downgrade protection mechanism embedded in the server's -# random value. TLS 1.3 servers which negotiate TLS 1.2 or below in -# response to a ClientHello MUST set the last 8 bytes of their Random -# value specially in their ServerHello. -# -# If negotiating TLS 1.2, TLS 1.3 servers MUST set the last 8 bytes of -# their Random value to the bytes: -# -# 44 4F 57 4E 47 52 44 01 -# -# If negotiating TLS 1.1 or below, TLS 1.3 servers MUST, and TLS 1.2 -# servers SHOULD, set the last 8 bytes of their ServerHello.Random -# value to the bytes: -# -# 44 4F 57 4E 47 52 44 00 -# -# TLS 1.3 clients receiving a ServerHello indicating TLS 1.2 or below -# MUST check that the last 8 bytes are not equal to either of these -# values. TLS 1.2 clients SHOULD also check that the last 8 bytes are -# not equal to the second value if the ServerHello indicates TLS 1.1 or -# below. If a match is found, the client MUST abort the handshake with -# an "illegal_parameter" alert. This mechanism provides limited -# protection against downgrade attacks over and above what is provided -# by the Finished exchange: because the ServerKeyExchange, a message -# present in TLS 1.2 and below, includes a signature over both random -# values, it is not possible for an active attacker to modify the -# -# random values without detection as long as ephemeral ciphers are -# used. It does not provide downgrade protection when static RSA -# is used. -# -# Note: This is a change from [RFC5246], so in practice many TLS 1.2 -# clients and servers will not behave as specified above. -# -# A legacy TLS client performing renegotiation with TLS 1.2 or prior -# and which receives a TLS 1.3 ServerHello during renegotiation MUST -# abort the handshake with a "protocol_version" alert. Note that -# renegotiation is not possible when TLS 1.3 has been negotiated. +# The server will send this message in response to a ClientHello +# message to proceed with the handshake if it is able to negotiate an +# acceptable set of handshake parameters based on the ClientHello. +# +# Structure of this message: +# +# struct { +# ProtocolVersion legacy_version = 0x0303; /* TLS v1.2 */ +# Random random; +# opaque legacy_session_id_echo<0..32>; +# CipherSuite cipher_suite; +# uint8 legacy_compression_method = 0; +# Extension extensions<6..2^16-1>; +# } ServerHello; +# +# legacy_version: In previous versions of TLS, this field was used for +# version negotiation and represented the selected version number +# for the connection. Unfortunately, some middleboxes fail when +# presented with new values. In TLS 1.3, the TLS server indicates +# its version using the "supported_versions" extension +# (Section 4.2.1), and the legacy_version field MUST be set to +# 0x0303, which is the version number for TLS 1.2. (See Appendix D +# for details about backward compatibility.) +# +# random: 32 bytes generated by a secure random number generator. See +# Appendix C for additional information. The last 8 bytes MUST be +# overwritten as described below if negotiating TLS 1.2 or TLS 1.1, +# but the remaining bytes MUST be random. This structure is +# generated by the server and MUST be generated independently of the +# ClientHello.random. +# +# legacy_session_id_echo: The contents of the client's +# legacy_session_id field. Note that this field is echoed even if +# the client's value corresponded to a cached pre-TLS 1.3 session +# which the server has chosen not to resume. A client which +# receives a legacy_session_id_echo field that does not match what +# it sent in the ClientHello MUST abort the handshake with an +# "illegal_parameter" alert. +# +# cipher_suite: The single cipher suite selected by the server from +# the list in ClientHello.cipher_suites. A client which receives a +# cipher suite that was not offered MUST abort the handshake with an +# "illegal_parameter" alert. +# +# legacy_compression_method: A single byte which MUST have the +# value 0. +# +# extensions: A list of extensions. The ServerHello MUST only include +# extensions which are required to establish the cryptographic +# context and negotiate the protocol version. All TLS 1.3 +# ServerHello messages MUST contain the "supported_versions" +# extension. Current ServerHello messages additionally contain +# either the "pre_shared_key" extension or the "key_share" +# extension, or both (when using a PSK with (EC)DHE key +# establishment). Other extensions (see Section 4.2) are sent +# separately in the EncryptedExtensions message. +# +# For reasons of backward compatibility with middleboxes (see +# Appendix D.4), the HelloRetryRequest message uses the same structure +# as the ServerHello, but with Random set to the special value of the +# SHA-256 of "HelloRetryRequest": +# +# CF 21 AD 74 E5 9A 61 11 BE 1D 8C 02 1E 65 B8 91 +# C2 A2 11 16 7A BB 8C 5E 07 9E 09 E2 C8 A8 33 9C +# +# Upon receiving a message with type server_hello, implementations MUST +# first examine the Random value and, if it matches this value, process +# it as described in Section 4.1.4). +# +# TLS 1.3 has a downgrade protection mechanism embedded in the server's +# random value. TLS 1.3 servers which negotiate TLS 1.2 or below in +# response to a ClientHello MUST set the last 8 bytes of their Random +# value specially in their ServerHello. +# +# If negotiating TLS 1.2, TLS 1.3 servers MUST set the last 8 bytes of +# their Random value to the bytes: +# +# 44 4F 57 4E 47 52 44 01 +# +# If negotiating TLS 1.1 or below, TLS 1.3 servers MUST, and TLS 1.2 +# servers SHOULD, set the last 8 bytes of their ServerHello.Random +# value to the bytes: +# +# 44 4F 57 4E 47 52 44 00 +# +# TLS 1.3 clients receiving a ServerHello indicating TLS 1.2 or below +# MUST check that the last 8 bytes are not equal to either of these +# values. TLS 1.2 clients SHOULD also check that the last 8 bytes are +# not equal to the second value if the ServerHello indicates TLS 1.1 or +# below. If a match is found, the client MUST abort the handshake with +# an "illegal_parameter" alert. This mechanism provides limited +# protection against downgrade attacks over and above what is provided +# by the Finished exchange: because the ServerKeyExchange, a message +# present in TLS 1.2 and below, includes a signature over both random +# values, it is not possible for an active attacker to modify the +# +# random values without detection as long as ephemeral ciphers are +# used. It does not provide downgrade protection when static RSA +# is used. +# +# Note: This is a change from [RFC5246], so in practice many TLS 1.2 +# clients and servers will not behave as specified above. +# +# A legacy TLS client performing renegotiation with TLS 1.2 or prior +# and which receives a TLS 1.3 ServerHello during renegotiation MUST +# abort the handshake with a "protocol_version" alert. Note that +# renegotiation is not possible when TLS 1.3 has been negotiated. [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.1.4.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.1.4.toml index 4edeff98773..2e80043791f 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.1.4.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.1.4.toml @@ -1,65 +1,65 @@ target = "https://www.rfc-editor.org/rfc/rfc8446#section-4.1.4" -# 4.1.4. Hello Retry Request +# Hello Retry Request # -# The server will send this message in response to a ClientHello -# message if it is able to find an acceptable set of parameters but the -# ClientHello does not contain sufficient information to proceed with -# the handshake. As discussed in Section 4.1.3, the HelloRetryRequest -# has the same format as a ServerHello message, and the legacy_version, -# legacy_session_id_echo, cipher_suite, and legacy_compression_method -# fields have the same meaning. However, for convenience we discuss -# "HelloRetryRequest" throughout this document as if it were a distinct -# message. +# The server will send this message in response to a ClientHello +# message if it is able to find an acceptable set of parameters but the +# ClientHello does not contain sufficient information to proceed with +# the handshake. As discussed in Section 4.1.3, the HelloRetryRequest +# has the same format as a ServerHello message, and the legacy_version, +# legacy_session_id_echo, cipher_suite, and legacy_compression_method +# fields have the same meaning. However, for convenience we discuss +# "HelloRetryRequest" throughout this document as if it were a distinct +# message. # -# The server's extensions MUST contain "supported_versions". -# Additionally, it SHOULD contain the minimal set of extensions -# necessary for the client to generate a correct ClientHello pair. As -# with the ServerHello, a HelloRetryRequest MUST NOT contain any -# extensions that were not first offered by the client in its -# ClientHello, with the exception of optionally the "cookie" (see -# Section 4.2.2) extension. +# The server's extensions MUST contain "supported_versions". +# Additionally, it SHOULD contain the minimal set of extensions +# necessary for the client to generate a correct ClientHello pair. As +# with the ServerHello, a HelloRetryRequest MUST NOT contain any +# extensions that were not first offered by the client in its +# ClientHello, with the exception of optionally the "cookie" (see +# Section 4.2.2) extension. # -# Upon receipt of a HelloRetryRequest, the client MUST check the -# legacy_version, legacy_session_id_echo, cipher_suite, and -# legacy_compression_method as specified in Section 4.1.3 and then -# process the extensions, starting with determining the version using -# "supported_versions". Clients MUST abort the handshake with an -# "illegal_parameter" alert if the HelloRetryRequest would not result -# in any change in the ClientHello. If a client receives a second -# HelloRetryRequest in the same connection (i.e., where the ClientHello -# was itself in response to a HelloRetryRequest), it MUST abort the -# handshake with an "unexpected_message" alert. +# Upon receipt of a HelloRetryRequest, the client MUST check the +# legacy_version, legacy_session_id_echo, cipher_suite, and +# legacy_compression_method as specified in Section 4.1.3 and then +# process the extensions, starting with determining the version using +# "supported_versions". Clients MUST abort the handshake with an +# "illegal_parameter" alert if the HelloRetryRequest would not result +# in any change in the ClientHello. If a client receives a second +# HelloRetryRequest in the same connection (i.e., where the ClientHello +# was itself in response to a HelloRetryRequest), it MUST abort the +# handshake with an "unexpected_message" alert. # -# Otherwise, the client MUST process all extensions in the -# HelloRetryRequest and send a second updated ClientHello. The -# HelloRetryRequest extensions defined in this specification are: +# Otherwise, the client MUST process all extensions in the +# HelloRetryRequest and send a second updated ClientHello. The +# HelloRetryRequest extensions defined in this specification are: # -# - supported_versions (see Section 4.2.1) +# - supported_versions (see Section 4.2.1) # -# - cookie (see Section 4.2.2) +# - cookie (see Section 4.2.2) # -# - key_share (see Section 4.2.8) +# - key_share (see Section 4.2.8) # -# A client which receives a cipher suite that was not offered MUST -# abort the handshake. Servers MUST ensure that they negotiate the -# same cipher suite when receiving a conformant updated ClientHello (if -# the server selects the cipher suite as the first step in the -# negotiation, then this will happen automatically). Upon receiving -# the ServerHello, clients MUST check that the cipher suite supplied in -# the ServerHello is the same as that in the HelloRetryRequest and -# otherwise abort the handshake with an "illegal_parameter" alert. +# A client which receives a cipher suite that was not offered MUST +# abort the handshake. Servers MUST ensure that they negotiate the +# same cipher suite when receiving a conformant updated ClientHello (if +# the server selects the cipher suite as the first step in the +# negotiation, then this will happen automatically). Upon receiving +# the ServerHello, clients MUST check that the cipher suite supplied in +# the ServerHello is the same as that in the HelloRetryRequest and +# otherwise abort the handshake with an "illegal_parameter" alert. # -# In addition, in its updated ClientHello, the client SHOULD NOT offer -# any pre-shared keys associated with a hash other than that of the -# selected cipher suite. This allows the client to avoid having to -# compute partial hash transcripts for multiple hashes in the second -# ClientHello. +# In addition, in its updated ClientHello, the client SHOULD NOT offer +# any pre-shared keys associated with a hash other than that of the +# selected cipher suite. This allows the client to avoid having to +# compute partial hash transcripts for multiple hashes in the second +# ClientHello. # -# The value of selected_version in the HelloRetryRequest -# "supported_versions" extension MUST be retained in the ServerHello, -# and a client MUST abort the handshake with an "illegal_parameter" -# alert if the value changes. +# The value of selected_version in the HelloRetryRequest +# "supported_versions" extension MUST be retained in the ServerHello, +# and a client MUST abort the handshake with an "illegal_parameter" +# alert if the value changes. [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.2.1.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.2.1.toml index 6a44b2d7ecf..24337db2189 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.2.1.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.2.1.toml @@ -1,62 +1,62 @@ target = "https://www.rfc-editor.org/rfc/rfc8446#section-4.2.1" -# 4.2.1. Supported Versions +# Supported Versions # -# struct { -# select (Handshake.msg_type) { -# case client_hello: -# ProtocolVersion versions<2..254>; +# struct { +# select (Handshake.msg_type) { +# case client_hello: +# ProtocolVersion versions<2..254>; # -# case server_hello: /* and HelloRetryRequest */ -# ProtocolVersion selected_version; -# }; -# } SupportedVersions; +# case server_hello: /* and HelloRetryRequest */ +# ProtocolVersion selected_version; +# }; +# } SupportedVersions; # -# The "supported_versions" extension is used by the client to indicate -# which versions of TLS it supports and by the server to indicate which -# version it is using. The extension contains a list of supported -# versions in preference order, with the most preferred version first. -# Implementations of this specification MUST send this extension in the -# ClientHello containing all versions of TLS which they are prepared to -# negotiate (for this specification, that means minimally 0x0304, but -# if previous versions of TLS are allowed to be negotiated, they MUST -# be present as well). +# The "supported_versions" extension is used by the client to indicate +# which versions of TLS it supports and by the server to indicate which +# version it is using. The extension contains a list of supported +# versions in preference order, with the most preferred version first. +# Implementations of this specification MUST send this extension in the +# ClientHello containing all versions of TLS which they are prepared to +# negotiate (for this specification, that means minimally 0x0304, but +# if previous versions of TLS are allowed to be negotiated, they MUST +# be present as well). # -# If this extension is not present, servers which are compliant with -# this specification and which also support TLS 1.2 MUST negotiate -# TLS 1.2 or prior as specified in [RFC5246], even if -# ClientHello.legacy_version is 0x0304 or later. Servers MAY abort the -# handshake upon receiving a ClientHello with legacy_version 0x0304 or -# later. +# If this extension is not present, servers which are compliant with +# this specification and which also support TLS 1.2 MUST negotiate +# TLS 1.2 or prior as specified in [RFC5246], even if +# ClientHello.legacy_version is 0x0304 or later. Servers MAY abort the +# handshake upon receiving a ClientHello with legacy_version 0x0304 or +# later. # -# If this extension is present in the ClientHello, servers MUST NOT use -# the ClientHello.legacy_version value for version negotiation and MUST -# use only the "supported_versions" extension to determine client -# preferences. Servers MUST only select a version of TLS present in -# that extension and MUST ignore any unknown versions that are present -# in that extension. Note that this mechanism makes it possible to -# negotiate a version prior to TLS 1.2 if one side supports a sparse -# range. Implementations of TLS 1.3 which choose to support prior -# versions of TLS SHOULD support TLS 1.2. Servers MUST be prepared to -# receive ClientHellos that include this extension but do not include -# 0x0304 in the list of versions. +# If this extension is present in the ClientHello, servers MUST NOT use +# the ClientHello.legacy_version value for version negotiation and MUST +# use only the "supported_versions" extension to determine client +# preferences. Servers MUST only select a version of TLS present in +# that extension and MUST ignore any unknown versions that are present +# in that extension. Note that this mechanism makes it possible to +# negotiate a version prior to TLS 1.2 if one side supports a sparse +# range. Implementations of TLS 1.3 which choose to support prior +# versions of TLS SHOULD support TLS 1.2. Servers MUST be prepared to +# receive ClientHellos that include this extension but do not include +# 0x0304 in the list of versions. # -# A server which negotiates a version of TLS prior to TLS 1.3 MUST set -# ServerHello.version and MUST NOT send the "supported_versions" -# extension. A server which negotiates TLS 1.3 MUST respond by sending -# a "supported_versions" extension containing the selected version -# value (0x0304). It MUST set the ServerHello.legacy_version field to -# 0x0303 (TLS 1.2). Clients MUST check for this extension prior to -# processing the rest of the ServerHello (although they will have to +# A server which negotiates a version of TLS prior to TLS 1.3 MUST set +# ServerHello.version and MUST NOT send the "supported_versions" +# extension. A server which negotiates TLS 1.3 MUST respond by sending +# a "supported_versions" extension containing the selected version +# value (0x0304). It MUST set the ServerHello.legacy_version field to +# 0x0303 (TLS 1.2). Clients MUST check for this extension prior to +# processing the rest of the ServerHello (although they will have to # -# parse the ServerHello in order to read the extension). If this -# extension is present, clients MUST ignore the -# ServerHello.legacy_version value and MUST use only the -# "supported_versions" extension to determine the selected version. If -# the "supported_versions" extension in the ServerHello contains a -# version not offered by the client or contains a version prior to -# TLS 1.3, the client MUST abort the handshake with an -# "illegal_parameter" alert. +# parse the ServerHello in order to read the extension). If this +# extension is present, clients MUST ignore the +# ServerHello.legacy_version value and MUST use only the +# "supported_versions" extension to determine the selected version. If +# the "supported_versions" extension in the ServerHello contains a +# version not offered by the client or contains a version prior to +# TLS 1.3, the client MUST abort the handshake with an +# "illegal_parameter" alert. [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.2.10.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.2.10.toml index 2bcb3476f89..ea3016cb33b 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.2.10.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.2.10.toml @@ -1,132 +1,132 @@ target = "https://www.rfc-editor.org/rfc/rfc8446#section-4.2.10" -# 4.2.10. Early Data Indication +# Early Data Indication # -# When a PSK is used and early data is allowed for that PSK, the client -# can send Application Data in its first flight of messages. If the -# client opts to do so, it MUST supply both the "pre_shared_key" and -# "early_data" extensions. +# When a PSK is used and early data is allowed for that PSK, the client +# can send Application Data in its first flight of messages. If the +# client opts to do so, it MUST supply both the "pre_shared_key" and +# "early_data" extensions. # -# The "extension_data" field of this extension contains an -# "EarlyDataIndication" value. +# The "extension_data" field of this extension contains an +# "EarlyDataIndication" value. # -# struct {} Empty; +# struct {} Empty; # -# struct { -# select (Handshake.msg_type) { -# case new_session_ticket: uint32 max_early_data_size; -# case client_hello: Empty; -# case encrypted_extensions: Empty; -# }; -# } EarlyDataIndication; +# struct { +# select (Handshake.msg_type) { +# case new_session_ticket: uint32 max_early_data_size; +# case client_hello: Empty; +# case encrypted_extensions: Empty; +# }; +# } EarlyDataIndication; # -# See Section 4.6.1 for details regarding the use of the -# max_early_data_size field. +# See Section 4.6.1 for details regarding the use of the +# max_early_data_size field. # -# The parameters for the 0-RTT data (version, symmetric cipher suite, -# Application-Layer Protocol Negotiation (ALPN) [RFC7301] protocol, -# etc.) are those associated with the PSK in use. For externally -# provisioned PSKs, the associated values are those provisioned along -# with the key. For PSKs established via a NewSessionTicket message, -# the associated values are those which were negotiated in the -# connection which established the PSK. The PSK used to encrypt the -# early data MUST be the first PSK listed in the client's -# "pre_shared_key" extension. +# The parameters for the 0-RTT data (version, symmetric cipher suite, +# Application-Layer Protocol Negotiation (ALPN) [RFC7301] protocol, +# etc.) are those associated with the PSK in use. For externally +# provisioned PSKs, the associated values are those provisioned along +# with the key. For PSKs established via a NewSessionTicket message, +# the associated values are those which were negotiated in the +# connection which established the PSK. The PSK used to encrypt the +# early data MUST be the first PSK listed in the client's +# "pre_shared_key" extension. # -# For PSKs provisioned via NewSessionTicket, a server MUST validate -# that the ticket age for the selected PSK identity (computed by -# subtracting ticket_age_add from PskIdentity.obfuscated_ticket_age -# modulo 2^32) is within a small tolerance of the time since the ticket -# was issued (see Section 8). If it is not, the server SHOULD proceed -# with the handshake but reject 0-RTT, and SHOULD NOT take any other -# action that assumes that this ClientHello is fresh. +# For PSKs provisioned via NewSessionTicket, a server MUST validate +# that the ticket age for the selected PSK identity (computed by +# subtracting ticket_age_add from PskIdentity.obfuscated_ticket_age +# modulo 2^32) is within a small tolerance of the time since the ticket +# was issued (see Section 8). If it is not, the server SHOULD proceed +# with the handshake but reject 0-RTT, and SHOULD NOT take any other +# action that assumes that this ClientHello is fresh. # -# 0-RTT messages sent in the first flight have the same (encrypted) -# content types as messages of the same type sent in other flights -# (handshake and application_data) but are protected under different -# keys. After receiving the server's Finished message, if the server -# has accepted early data, an EndOfEarlyData message will be sent to -# indicate the key change. This message will be encrypted with the -# 0-RTT traffic keys. +# 0-RTT messages sent in the first flight have the same (encrypted) +# content types as messages of the same type sent in other flights +# (handshake and application_data) but are protected under different +# keys. After receiving the server's Finished message, if the server +# has accepted early data, an EndOfEarlyData message will be sent to +# indicate the key change. This message will be encrypted with the +# 0-RTT traffic keys. # -# A server which receives an "early_data" extension MUST behave in one -# of three ways: +# A server which receives an "early_data" extension MUST behave in one +# of three ways: # -# - Ignore the extension and return a regular 1-RTT response. The -# server then skips past early data by attempting to deprotect -# received records using the handshake traffic key, discarding -# records which fail deprotection (up to the configured -# max_early_data_size). Once a record is deprotected successfully, -# it is treated as the start of the client's second flight and the -# server proceeds as with an ordinary 1-RTT handshake. +# - Ignore the extension and return a regular 1-RTT response. The +# server then skips past early data by attempting to deprotect +# received records using the handshake traffic key, discarding +# records which fail deprotection (up to the configured +# max_early_data_size). Once a record is deprotected successfully, +# it is treated as the start of the client's second flight and the +# server proceeds as with an ordinary 1-RTT handshake. # -# - Request that the client send another ClientHello by responding -# with a HelloRetryRequest. A client MUST NOT include the -# "early_data" extension in its followup ClientHello. The server -# then ignores early data by skipping all records with an external -# content type of "application_data" (indicating that they are -# encrypted), up to the configured max_early_data_size. +# - Request that the client send another ClientHello by responding +# with a HelloRetryRequest. A client MUST NOT include the +# "early_data" extension in its followup ClientHello. The server +# then ignores early data by skipping all records with an external +# content type of "application_data" (indicating that they are +# encrypted), up to the configured max_early_data_size. # -# - Return its own "early_data" extension in EncryptedExtensions, -# indicating that it intends to process the early data. It is not -# possible for the server to accept only a subset of the early data -# messages. Even though the server sends a message accepting early -# data, the actual early data itself may already be in flight by the -# time the server generates this message. +# - Return its own "early_data" extension in EncryptedExtensions, +# indicating that it intends to process the early data. It is not +# possible for the server to accept only a subset of the early data +# messages. Even though the server sends a message accepting early +# data, the actual early data itself may already be in flight by the +# time the server generates this message. # -# In order to accept early data, the server MUST have accepted a PSK -# cipher suite and selected the first key offered in the client's -# "pre_shared_key" extension. In addition, it MUST verify that the -# following values are the same as those associated with the -# selected PSK: +# In order to accept early data, the server MUST have accepted a PSK +# cipher suite and selected the first key offered in the client's +# "pre_shared_key" extension. In addition, it MUST verify that the +# following values are the same as those associated with the +# selected PSK: # -# - The TLS version number +# - The TLS version number # -# - The selected cipher suite +# - The selected cipher suite # -# - The selected ALPN [RFC7301] protocol, if any +# - The selected ALPN [RFC7301] protocol, if any # -# These requirements are a superset of those needed to perform a 1-RTT -# handshake using the PSK in question. For externally established -# PSKs, the associated values are those provisioned along with the key. -# For PSKs established via a NewSessionTicket message, the associated -# values are those negotiated in the connection during which the ticket -# was established. +# These requirements are a superset of those needed to perform a 1-RTT +# handshake using the PSK in question. For externally established +# PSKs, the associated values are those provisioned along with the key. +# For PSKs established via a NewSessionTicket message, the associated +# values are those negotiated in the connection during which the ticket +# was established. # -# Future extensions MUST define their interaction with 0-RTT. +# Future extensions MUST define their interaction with 0-RTT. # -# If any of these checks fail, the server MUST NOT respond with the -# extension and must discard all the first-flight data using one of the -# first two mechanisms listed above (thus falling back to 1-RTT or -# 2-RTT). If the client attempts a 0-RTT handshake but the server -# rejects it, the server will generally not have the 0-RTT record -# protection keys and must instead use trial decryption (either with -# the 1-RTT handshake keys or by looking for a cleartext ClientHello in -# the case of a HelloRetryRequest) to find the first non-0-RTT message. +# If any of these checks fail, the server MUST NOT respond with the +# extension and must discard all the first-flight data using one of the +# first two mechanisms listed above (thus falling back to 1-RTT or +# 2-RTT). If the client attempts a 0-RTT handshake but the server +# rejects it, the server will generally not have the 0-RTT record +# protection keys and must instead use trial decryption (either with +# the 1-RTT handshake keys or by looking for a cleartext ClientHello in +# the case of a HelloRetryRequest) to find the first non-0-RTT message. # -# If the server chooses to accept the "early_data" extension, then it -# MUST comply with the same error-handling requirements specified for -# all records when processing early data records. Specifically, if the -# server fails to decrypt a 0-RTT record following an accepted -# "early_data" extension, it MUST terminate the connection with a -# "bad_record_mac" alert as per Section 5.2. +# If the server chooses to accept the "early_data" extension, then it +# MUST comply with the same error-handling requirements specified for +# all records when processing early data records. Specifically, if the +# server fails to decrypt a 0-RTT record following an accepted +# "early_data" extension, it MUST terminate the connection with a +# "bad_record_mac" alert as per Section 5.2. # -# If the server rejects the "early_data" extension, the client -# application MAY opt to retransmit the Application Data previously -# sent in early data once the handshake has been completed. Note that -# automatic retransmission of early data could result in incorrect -# assumptions regarding the status of the connection. For instance, -# when the negotiated connection selects a different ALPN protocol from -# what was used for the early data, an application might need to -# construct different messages. Similarly, if early data assumes -# anything about the connection state, it might be sent in error after -# the handshake completes. +# If the server rejects the "early_data" extension, the client +# application MAY opt to retransmit the Application Data previously +# sent in early data once the handshake has been completed. Note that +# automatic retransmission of early data could result in incorrect +# assumptions regarding the status of the connection. For instance, +# when the negotiated connection selects a different ALPN protocol from +# what was used for the early data, an application might need to +# construct different messages. Similarly, if early data assumes +# anything about the connection state, it might be sent in error after +# the handshake completes. # -# A TLS implementation SHOULD NOT automatically resend early data; -# applications are in a better position to decide when retransmission -# is appropriate. A TLS implementation MUST NOT automatically resend -# early data unless the negotiated connection selects the same ALPN -# protocol. +# A TLS implementation SHOULD NOT automatically resend early data; +# applications are in a better position to decide when retransmission +# is appropriate. A TLS implementation MUST NOT automatically resend +# early data unless the negotiated connection selects the same ALPN +# protocol. [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.2.11.1.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.2.11.1.toml index 0d1f295e5cd..efff2e489b8 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.2.11.1.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.2.11.1.toml @@ -1,20 +1,20 @@ target = "https://www.rfc-editor.org/rfc/rfc8446#section-4.2.11.1" -# 4.2.11.1. Ticket Age +# Ticket Age # -# The client's view of the age of a ticket is the time since the -# receipt of the NewSessionTicket message. Clients MUST NOT attempt to -# use tickets which have ages greater than the "ticket_lifetime" value -# which was provided with the ticket. The "obfuscated_ticket_age" -# field of each PskIdentity contains an obfuscated version of the -# ticket age formed by taking the age in milliseconds and adding the -# "ticket_age_add" value that was included with the ticket (see -# Section 4.6.1), modulo 2^32. This addition prevents passive -# observers from correlating connections unless tickets are reused. -# Note that the "ticket_lifetime" field in the NewSessionTicket message -# is in seconds but the "obfuscated_ticket_age" is in milliseconds. -# Because ticket lifetimes are restricted to a week, 32 bits is enough -# to represent any plausible age, even in milliseconds. +# The client's view of the age of a ticket is the time since the +# receipt of the NewSessionTicket message. Clients MUST NOT attempt to +# use tickets which have ages greater than the "ticket_lifetime" value +# which was provided with the ticket. The "obfuscated_ticket_age" +# field of each PskIdentity contains an obfuscated version of the +# ticket age formed by taking the age in milliseconds and adding the +# "ticket_age_add" value that was included with the ticket (see +# Section 4.6.1), modulo 2^32. This addition prevents passive +# observers from correlating connections unless tickets are reused. +# Note that the "ticket_lifetime" field in the NewSessionTicket message +# is in seconds but the "obfuscated_ticket_age" is in milliseconds. +# Because ticket lifetimes are restricted to a week, 32 bits is enough +# to represent any plausible age, even in milliseconds. [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.2.11.3.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.2.11.3.toml index 2b10009ed61..b030b33e626 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.2.11.3.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.2.11.3.toml @@ -1,14 +1,14 @@ target = "https://www.rfc-editor.org/rfc/rfc8446#section-4.2.11.3" -# 4.2.11.3. Processing Order +# Processing Order # -# Clients are permitted to "stream" 0-RTT data until they receive the -# server's Finished, only then sending the EndOfEarlyData message, -# followed by the rest of the handshake. In order to avoid deadlocks, -# when accepting "early_data", servers MUST process the client's -# ClientHello and then immediately send their flight of messages, -# rather than waiting for the client's EndOfEarlyData message before -# sending its ServerHello. +# Clients are permitted to "stream" 0-RTT data until they receive the +# server's Finished, only then sending the EndOfEarlyData message, +# followed by the rest of the handshake. In order to avoid deadlocks, +# when accepting "early_data", servers MUST process the client's +# ClientHello and then immediately send their flight of messages, +# rather than waiting for the client's EndOfEarlyData message before +# sending its ServerHello. [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.2.11.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.2.11.toml index c91b581503b..221bbafda58 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.2.11.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.2.11.toml @@ -1,114 +1,114 @@ target = "https://www.rfc-editor.org/rfc/rfc8446#section-4.2.11" -# 4.2.11. Pre-Shared Key Extension +# Pre-Shared Key Extension # -# The "pre_shared_key" extension is used to negotiate the identity of -# the pre-shared key to be used with a given handshake in association -# with PSK key establishment. -# -# The "extension_data" field of this extension contains a -# "PreSharedKeyExtension" value: -# -# struct { -# opaque identity<1..2^16-1>; -# uint32 obfuscated_ticket_age; -# } PskIdentity; -# -# opaque PskBinderEntry<32..255>; -# -# struct { -# PskIdentity identities<7..2^16-1>; -# PskBinderEntry binders<33..2^16-1>; -# } OfferedPsks; -# -# struct { -# select (Handshake.msg_type) { -# case client_hello: OfferedPsks; -# case server_hello: uint16 selected_identity; -# }; -# } PreSharedKeyExtension; -# -# identity: A label for a key. For instance, a ticket (as defined in -# Appendix B.3.4) or a label for a pre-shared key established -# externally. -# -# obfuscated_ticket_age: An obfuscated version of the age of the key. -# Section 4.2.11.1 describes how to form this value for identities -# established via the NewSessionTicket message. For identities -# established externally, an obfuscated_ticket_age of 0 SHOULD be -# used, and servers MUST ignore the value. -# -# identities: A list of the identities that the client is willing to -# negotiate with the server. If sent alongside the "early_data" -# extension (see Section 4.2.10), the first identity is the one used -# for 0-RTT data. -# -# binders: A series of HMAC values, one for each value in the -# identities list and in the same order, computed as described -# below. -# -# selected_identity: The server's chosen identity expressed as a -# (0-based) index into the identities in the client's list. -# -# Each PSK is associated with a single Hash algorithm. For PSKs -# established via the ticket mechanism (Section 4.6.1), this is the KDF -# Hash algorithm on the connection where the ticket was established. -# For externally established PSKs, the Hash algorithm MUST be set when -# -# the PSK is established or default to SHA-256 if no such algorithm is -# defined. The server MUST ensure that it selects a compatible PSK -# (if any) and cipher suite. -# -# In TLS versions prior to TLS 1.3, the Server Name Identification -# (SNI) value was intended to be associated with the session (Section 3 -# of [RFC6066]), with the server being required to enforce that the SNI -# value associated with the session matches the one specified in the -# resumption handshake. However, in reality the implementations were -# not consistent on which of two supplied SNI values they would use, -# leading to the consistency requirement being de facto enforced by the -# clients. In TLS 1.3, the SNI value is always explicitly specified in -# the resumption handshake, and there is no need for the server to -# associate an SNI value with the ticket. Clients, however, SHOULD -# store the SNI with the PSK to fulfill the requirements of -# Section 4.6.1. -# -# Implementor's note: When session resumption is the primary use case -# of PSKs, the most straightforward way to implement the PSK/cipher -# suite matching requirements is to negotiate the cipher suite first -# and then exclude any incompatible PSKs. Any unknown PSKs (e.g., ones -# not in the PSK database or encrypted with an unknown key) SHOULD -# simply be ignored. If no acceptable PSKs are found, the server -# SHOULD perform a non-PSK handshake if possible. If backward -# compatibility is important, client-provided, externally established -# PSKs SHOULD influence cipher suite selection. -# -# Prior to accepting PSK key establishment, the server MUST validate -# the corresponding binder value (see Section 4.2.11.2 below). If this -# value is not present or does not validate, the server MUST abort the -# handshake. Servers SHOULD NOT attempt to validate multiple binders; -# rather, they SHOULD select a single PSK and validate solely the -# binder that corresponds to that PSK. See Section 8.2 and -# Appendix E.6 for the security rationale for this requirement. In -# order to accept PSK key establishment, the server sends a -# "pre_shared_key" extension indicating the selected identity. -# -# Clients MUST verify that the server's selected_identity is within the -# range supplied by the client, that the server selected a cipher suite -# indicating a Hash associated with the PSK, and that a server -# "key_share" extension is present if required by the ClientHello -# "psk_key_exchange_modes" extension. If these values are not -# consistent, the client MUST abort the handshake with an -# "illegal_parameter" alert. -# -# If the server supplies an "early_data" extension, the client MUST -# verify that the server's selected_identity is 0. If any other value -# is returned, the client MUST abort the handshake with an -# "illegal_parameter" alert. -# -# The "pre_shared_key" extension MUST be the last extension in the -# ClientHello (this facilitates implementation as described below). -# Servers MUST check that it is the last extension and otherwise fail -# the handshake with an "illegal_parameter" alert. +# The "pre_shared_key" extension is used to negotiate the identity of +# the pre-shared key to be used with a given handshake in association +# with PSK key establishment. +# +# The "extension_data" field of this extension contains a +# "PreSharedKeyExtension" value: +# +# struct { +# opaque identity<1..2^16-1>; +# uint32 obfuscated_ticket_age; +# } PskIdentity; +# +# opaque PskBinderEntry<32..255>; +# +# struct { +# PskIdentity identities<7..2^16-1>; +# PskBinderEntry binders<33..2^16-1>; +# } OfferedPsks; +# +# struct { +# select (Handshake.msg_type) { +# case client_hello: OfferedPsks; +# case server_hello: uint16 selected_identity; +# }; +# } PreSharedKeyExtension; +# +# identity: A label for a key. For instance, a ticket (as defined in +# Appendix B.3.4) or a label for a pre-shared key established +# externally. +# +# obfuscated_ticket_age: An obfuscated version of the age of the key. +# Section 4.2.11.1 describes how to form this value for identities +# established via the NewSessionTicket message. For identities +# established externally, an obfuscated_ticket_age of 0 SHOULD be +# used, and servers MUST ignore the value. +# +# identities: A list of the identities that the client is willing to +# negotiate with the server. If sent alongside the "early_data" +# extension (see Section 4.2.10), the first identity is the one used +# for 0-RTT data. +# +# binders: A series of HMAC values, one for each value in the +# identities list and in the same order, computed as described +# below. +# +# selected_identity: The server's chosen identity expressed as a +# (0-based) index into the identities in the client's list. +# +# Each PSK is associated with a single Hash algorithm. For PSKs +# established via the ticket mechanism (Section 4.6.1), this is the KDF +# Hash algorithm on the connection where the ticket was established. +# For externally established PSKs, the Hash algorithm MUST be set when +# +# the PSK is established or default to SHA-256 if no such algorithm is +# defined. The server MUST ensure that it selects a compatible PSK +# (if any) and cipher suite. +# +# In TLS versions prior to TLS 1.3, the Server Name Identification +# (SNI) value was intended to be associated with the session (Section 3 +# of [RFC6066]), with the server being required to enforce that the SNI +# value associated with the session matches the one specified in the +# resumption handshake. However, in reality the implementations were +# not consistent on which of two supplied SNI values they would use, +# leading to the consistency requirement being de facto enforced by the +# clients. In TLS 1.3, the SNI value is always explicitly specified in +# the resumption handshake, and there is no need for the server to +# associate an SNI value with the ticket. Clients, however, SHOULD +# store the SNI with the PSK to fulfill the requirements of +# Section 4.6.1. +# +# Implementor's note: When session resumption is the primary use case +# of PSKs, the most straightforward way to implement the PSK/cipher +# suite matching requirements is to negotiate the cipher suite first +# and then exclude any incompatible PSKs. Any unknown PSKs (e.g., ones +# not in the PSK database or encrypted with an unknown key) SHOULD +# simply be ignored. If no acceptable PSKs are found, the server +# SHOULD perform a non-PSK handshake if possible. If backward +# compatibility is important, client-provided, externally established +# PSKs SHOULD influence cipher suite selection. +# +# Prior to accepting PSK key establishment, the server MUST validate +# the corresponding binder value (see Section 4.2.11.2 below). If this +# value is not present or does not validate, the server MUST abort the +# handshake. Servers SHOULD NOT attempt to validate multiple binders; +# rather, they SHOULD select a single PSK and validate solely the +# binder that corresponds to that PSK. See Section 8.2 and +# Appendix E.6 for the security rationale for this requirement. In +# order to accept PSK key establishment, the server sends a +# "pre_shared_key" extension indicating the selected identity. +# +# Clients MUST verify that the server's selected_identity is within the +# range supplied by the client, that the server selected a cipher suite +# indicating a Hash associated with the PSK, and that a server +# "key_share" extension is present if required by the ClientHello +# "psk_key_exchange_modes" extension. If these values are not +# consistent, the client MUST abort the handshake with an +# "illegal_parameter" alert. +# +# If the server supplies an "early_data" extension, the client MUST +# verify that the server's selected_identity is 0. If any other value +# is returned, the client MUST abort the handshake with an +# "illegal_parameter" alert. +# +# The "pre_shared_key" extension MUST be the last extension in the +# ClientHello (this facilitates implementation as described below). +# Servers MUST check that it is the last extension and otherwise fail +# the handshake with an "illegal_parameter" alert. [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.2.2.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.2.2.toml index cef7781a746..88173bb99b9 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.2.2.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.2.2.toml @@ -1,38 +1,38 @@ target = "https://www.rfc-editor.org/rfc/rfc8446#section-4.2.2" -# 4.2.2. Cookie +# Cookie # -# struct { -# opaque cookie<1..2^16-1>; -# } Cookie; +# struct { +# opaque cookie<1..2^16-1>; +# } Cookie; # -# Cookies serve two primary purposes: +# Cookies serve two primary purposes: # -# - Allowing the server to force the client to demonstrate -# reachability at their apparent network address (thus providing a -# measure of DoS protection). This is primarily useful for -# non-connection-oriented transports (see [RFC6347] for an example -# of this). +# - Allowing the server to force the client to demonstrate +# reachability at their apparent network address (thus providing a +# measure of DoS protection). This is primarily useful for +# non-connection-oriented transports (see [RFC6347] for an example +# of this). # -# - Allowing the server to offload state to the client, thus allowing -# it to send a HelloRetryRequest without storing any state. The -# server can do this by storing the hash of the ClientHello in the -# HelloRetryRequest cookie (protected with some suitable integrity -# protection algorithm). +# - Allowing the server to offload state to the client, thus allowing +# it to send a HelloRetryRequest without storing any state. The +# server can do this by storing the hash of the ClientHello in the +# HelloRetryRequest cookie (protected with some suitable integrity +# protection algorithm). # -# When sending a HelloRetryRequest, the server MAY provide a "cookie" -# extension to the client (this is an exception to the usual rule that -# the only extensions that may be sent are those that appear in the -# ClientHello). When sending the new ClientHello, the client MUST copy -# the contents of the extension received in the HelloRetryRequest into -# a "cookie" extension in the new ClientHello. Clients MUST NOT use -# cookies in their initial ClientHello in subsequent connections. +# When sending a HelloRetryRequest, the server MAY provide a "cookie" +# extension to the client (this is an exception to the usual rule that +# the only extensions that may be sent are those that appear in the +# ClientHello). When sending the new ClientHello, the client MUST copy +# the contents of the extension received in the HelloRetryRequest into +# a "cookie" extension in the new ClientHello. Clients MUST NOT use +# cookies in their initial ClientHello in subsequent connections. # -# When a server is operating statelessly, it may receive an unprotected -# record of type change_cipher_spec between the first and second -# ClientHello (see Section 5). Since the server is not storing any -# state, this will appear as if it were the first message to be -# received. Servers operating statelessly MUST ignore these records. +# When a server is operating statelessly, it may receive an unprotected +# record of type change_cipher_spec between the first and second +# ClientHello (see Section 5). Since the server is not storing any +# state, this will appear as if it were the first message to be +# received. Servers operating statelessly MUST ignore these records. [[spec]] level = "MAY" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.2.3.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.2.3.toml index 993412ff994..a089d905760 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.2.3.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.2.3.toml @@ -1,173 +1,173 @@ target = "https://www.rfc-editor.org/rfc/rfc8446#section-4.2.3" -# 4.2.3. Signature Algorithms +# Signature Algorithms # -# TLS 1.3 provides two extensions for indicating which signature -# algorithms may be used in digital signatures. The -# "signature_algorithms_cert" extension applies to signatures in -# certificates, and the "signature_algorithms" extension, which -# originally appeared in TLS 1.2, applies to signatures in -# CertificateVerify messages. The keys found in certificates MUST also -# be of appropriate type for the signature algorithms they are used -# with. This is a particular issue for RSA keys and PSS signatures, as -# described below. If no "signature_algorithms_cert" extension is -# present, then the "signature_algorithms" extension also applies to -# signatures appearing in certificates. Clients which desire the -# server to authenticate itself via a certificate MUST send the -# "signature_algorithms" extension. If a server is authenticating via -# a certificate and the client has not sent a "signature_algorithms" -# extension, then the server MUST abort the handshake with a -# "missing_extension" alert (see Section 9.2). +# TLS 1.3 provides two extensions for indicating which signature +# algorithms may be used in digital signatures. The +# "signature_algorithms_cert" extension applies to signatures in +# certificates, and the "signature_algorithms" extension, which +# originally appeared in TLS 1.2, applies to signatures in +# CertificateVerify messages. The keys found in certificates MUST also +# be of appropriate type for the signature algorithms they are used +# with. This is a particular issue for RSA keys and PSS signatures, as +# described below. If no "signature_algorithms_cert" extension is +# present, then the "signature_algorithms" extension also applies to +# signatures appearing in certificates. Clients which desire the +# server to authenticate itself via a certificate MUST send the +# "signature_algorithms" extension. If a server is authenticating via +# a certificate and the client has not sent a "signature_algorithms" +# extension, then the server MUST abort the handshake with a +# "missing_extension" alert (see Section 9.2). # -# The "signature_algorithms_cert" extension was added to allow -# implementations which supported different sets of algorithms for -# certificates and in TLS itself to clearly signal their capabilities. -# TLS 1.2 implementations SHOULD also process this extension. -# Implementations which have the same policy in both cases MAY omit the -# "signature_algorithms_cert" extension. +# The "signature_algorithms_cert" extension was added to allow +# implementations which supported different sets of algorithms for +# certificates and in TLS itself to clearly signal their capabilities. +# TLS 1.2 implementations SHOULD also process this extension. +# Implementations which have the same policy in both cases MAY omit the +# "signature_algorithms_cert" extension. # -# The "extension_data" field of these extensions contains a -# SignatureSchemeList value: +# The "extension_data" field of these extensions contains a +# SignatureSchemeList value: # -# enum { -# /* RSASSA-PKCS1-v1_5 algorithms */ -# rsa_pkcs1_sha256(0x0401), -# rsa_pkcs1_sha384(0x0501), -# rsa_pkcs1_sha512(0x0601), +# enum { +# /* RSASSA-PKCS1-v1_5 algorithms */ +# rsa_pkcs1_sha256(0x0401), +# rsa_pkcs1_sha384(0x0501), +# rsa_pkcs1_sha512(0x0601), # -# /* ECDSA algorithms */ -# ecdsa_secp256r1_sha256(0x0403), -# ecdsa_secp384r1_sha384(0x0503), -# ecdsa_secp521r1_sha512(0x0603), +# /* ECDSA algorithms */ +# ecdsa_secp256r1_sha256(0x0403), +# ecdsa_secp384r1_sha384(0x0503), +# ecdsa_secp521r1_sha512(0x0603), # -# /* RSASSA-PSS algorithms with public key OID rsaEncryption */ -# rsa_pss_rsae_sha256(0x0804), -# rsa_pss_rsae_sha384(0x0805), -# rsa_pss_rsae_sha512(0x0806), +# /* RSASSA-PSS algorithms with public key OID rsaEncryption */ +# rsa_pss_rsae_sha256(0x0804), +# rsa_pss_rsae_sha384(0x0805), +# rsa_pss_rsae_sha512(0x0806), # -# /* EdDSA algorithms */ -# ed25519(0x0807), -# ed448(0x0808), +# /* EdDSA algorithms */ +# ed25519(0x0807), +# ed448(0x0808), # -# /* RSASSA-PSS algorithms with public key OID RSASSA-PSS */ -# rsa_pss_pss_sha256(0x0809), -# rsa_pss_pss_sha384(0x080a), -# rsa_pss_pss_sha512(0x080b), +# /* RSASSA-PSS algorithms with public key OID RSASSA-PSS */ +# rsa_pss_pss_sha256(0x0809), +# rsa_pss_pss_sha384(0x080a), +# rsa_pss_pss_sha512(0x080b), # -# /* Legacy algorithms */ -# rsa_pkcs1_sha1(0x0201), -# ecdsa_sha1(0x0203), +# /* Legacy algorithms */ +# rsa_pkcs1_sha1(0x0201), +# ecdsa_sha1(0x0203), # -# /* Reserved Code Points */ -# private_use(0xFE00..0xFFFF), -# (0xFFFF) -# } SignatureScheme; +# /* Reserved Code Points */ +# private_use(0xFE00..0xFFFF), +# (0xFFFF) +# } SignatureScheme; # -# struct { -# SignatureScheme supported_signature_algorithms<2..2^16-2>; -# } SignatureSchemeList; +# struct { +# SignatureScheme supported_signature_algorithms<2..2^16-2>; +# } SignatureSchemeList; # -# Note: This enum is named "SignatureScheme" because there is already a -# "SignatureAlgorithm" type in TLS 1.2, which this replaces. We use -# the term "signature algorithm" throughout the text. +# Note: This enum is named "SignatureScheme" because there is already a +# "SignatureAlgorithm" type in TLS 1.2, which this replaces. We use +# the term "signature algorithm" throughout the text. # -# Each SignatureScheme value lists a single signature algorithm that -# the client is willing to verify. The values are indicated in -# descending order of preference. Note that a signature algorithm -# takes as input an arbitrary-length message, rather than a digest. -# Algorithms which traditionally act on a digest should be defined in -# TLS to first hash the input with a specified hash algorithm and then -# proceed as usual. The code point groups listed above have the -# following meanings: +# Each SignatureScheme value lists a single signature algorithm that +# the client is willing to verify. The values are indicated in +# descending order of preference. Note that a signature algorithm +# takes as input an arbitrary-length message, rather than a digest. +# Algorithms which traditionally act on a digest should be defined in +# TLS to first hash the input with a specified hash algorithm and then +# proceed as usual. The code point groups listed above have the +# following meanings: # -# RSASSA-PKCS1-v1_5 algorithms: Indicates a signature algorithm using -# RSASSA-PKCS1-v1_5 [RFC8017] with the corresponding hash algorithm -# as defined in [SHS]. These values refer solely to signatures -# which appear in certificates (see Section 4.4.2.2) and are not -# defined for use in signed TLS handshake messages, although they -# MAY appear in "signature_algorithms" and -# "signature_algorithms_cert" for backward compatibility with -# TLS 1.2. +# RSASSA-PKCS1-v1_5 algorithms: Indicates a signature algorithm using +# RSASSA-PKCS1-v1_5 [RFC8017] with the corresponding hash algorithm +# as defined in [SHS]. These values refer solely to signatures +# which appear in certificates (see Section 4.4.2.2) and are not +# defined for use in signed TLS handshake messages, although they +# MAY appear in "signature_algorithms" and +# "signature_algorithms_cert" for backward compatibility with +# TLS 1.2. # -# ECDSA algorithms: Indicates a signature algorithm using ECDSA -# [ECDSA], the corresponding curve as defined in ANSI X9.62 [ECDSA] -# and FIPS 186-4 [DSS], and the corresponding hash algorithm as -# defined in [SHS]. The signature is represented as a DER-encoded -# [X690] ECDSA-Sig-Value structure. +# ECDSA algorithms: Indicates a signature algorithm using ECDSA +# [ECDSA], the corresponding curve as defined in ANSI X9.62 [ECDSA] +# and FIPS 186-4 [DSS], and the corresponding hash algorithm as +# defined in [SHS]. The signature is represented as a DER-encoded +# [X690] ECDSA-Sig-Value structure. # -# RSASSA-PSS RSAE algorithms: Indicates a signature algorithm using -# RSASSA-PSS [RFC8017] with mask generation function 1. The digest -# used in the mask generation function and the digest being signed -# are both the corresponding hash algorithm as defined in [SHS]. -# The length of the Salt MUST be equal to the length of the output -# of the digest algorithm. If the public key is carried in an X.509 -# certificate, it MUST use the rsaEncryption OID [RFC5280]. +# RSASSA-PSS RSAE algorithms: Indicates a signature algorithm using +# RSASSA-PSS [RFC8017] with mask generation function 1. The digest +# used in the mask generation function and the digest being signed +# are both the corresponding hash algorithm as defined in [SHS]. +# The length of the Salt MUST be equal to the length of the output +# of the digest algorithm. If the public key is carried in an X.509 +# certificate, it MUST use the rsaEncryption OID [RFC5280]. # -# EdDSA algorithms: Indicates a signature algorithm using EdDSA as -# defined in [RFC8032] or its successors. Note that these -# correspond to the "PureEdDSA" algorithms and not the "prehash" -# variants. +# EdDSA algorithms: Indicates a signature algorithm using EdDSA as +# defined in [RFC8032] or its successors. Note that these +# correspond to the "PureEdDSA" algorithms and not the "prehash" +# variants. # -# RSASSA-PSS PSS algorithms: Indicates a signature algorithm using -# RSASSA-PSS [RFC8017] with mask generation function 1. The digest -# used in the mask generation function and the digest being signed -# are both the corresponding hash algorithm as defined in [SHS]. -# The length of the Salt MUST be equal to the length of the digest -# algorithm. If the public key is carried in an X.509 certificate, -# it MUST use the RSASSA-PSS OID [RFC5756]. When used in -# certificate signatures, the algorithm parameters MUST be DER -# encoded. If the corresponding public key's parameters are -# present, then the parameters in the signature MUST be identical to -# those in the public key. +# RSASSA-PSS PSS algorithms: Indicates a signature algorithm using +# RSASSA-PSS [RFC8017] with mask generation function 1. The digest +# used in the mask generation function and the digest being signed +# are both the corresponding hash algorithm as defined in [SHS]. +# The length of the Salt MUST be equal to the length of the digest +# algorithm. If the public key is carried in an X.509 certificate, +# it MUST use the RSASSA-PSS OID [RFC5756]. When used in +# certificate signatures, the algorithm parameters MUST be DER +# encoded. If the corresponding public key's parameters are +# present, then the parameters in the signature MUST be identical to +# those in the public key. # -# Legacy algorithms: Indicates algorithms which are being deprecated -# because they use algorithms with known weaknesses, specifically -# SHA-1 which is used in this context with either (1) RSA using -# RSASSA-PKCS1-v1_5 or (2) ECDSA. These values refer solely to -# signatures which appear in certificates (see Section 4.4.2.2) and -# are not defined for use in signed TLS handshake messages, although -# they MAY appear in "signature_algorithms" and -# "signature_algorithms_cert" for backward compatibility with -# TLS 1.2. Endpoints SHOULD NOT negotiate these algorithms but are -# permitted to do so solely for backward compatibility. Clients -# offering these values MUST list them as the lowest priority -# (listed after all other algorithms in SignatureSchemeList). -# TLS 1.3 servers MUST NOT offer a SHA-1 signed certificate unless -# no valid certificate chain can be produced without it (see -# Section 4.4.2.2). +# Legacy algorithms: Indicates algorithms which are being deprecated +# because they use algorithms with known weaknesses, specifically +# SHA-1 which is used in this context with either (1) RSA using +# RSASSA-PKCS1-v1_5 or (2) ECDSA. These values refer solely to +# signatures which appear in certificates (see Section 4.4.2.2) and +# are not defined for use in signed TLS handshake messages, although +# they MAY appear in "signature_algorithms" and +# "signature_algorithms_cert" for backward compatibility with +# TLS 1.2. Endpoints SHOULD NOT negotiate these algorithms but are +# permitted to do so solely for backward compatibility. Clients +# offering these values MUST list them as the lowest priority +# (listed after all other algorithms in SignatureSchemeList). +# TLS 1.3 servers MUST NOT offer a SHA-1 signed certificate unless +# no valid certificate chain can be produced without it (see +# Section 4.4.2.2). # -# The signatures on certificates that are self-signed or certificates -# that are trust anchors are not validated, since they begin a -# certification path (see [RFC5280], Section 3.2). A certificate that -# begins a certification path MAY use a signature algorithm that is not -# advertised as being supported in the "signature_algorithms" -# extension. +# The signatures on certificates that are self-signed or certificates +# that are trust anchors are not validated, since they begin a +# certification path (see [RFC5280], Section 3.2). A certificate that +# begins a certification path MAY use a signature algorithm that is not +# advertised as being supported in the "signature_algorithms" +# extension. # -# Note that TLS 1.2 defines this extension differently. TLS 1.3 -# implementations willing to negotiate TLS 1.2 MUST behave in -# accordance with the requirements of [RFC5246] when negotiating that -# version. In particular: +# Note that TLS 1.2 defines this extension differently. TLS 1.3 +# implementations willing to negotiate TLS 1.2 MUST behave in +# accordance with the requirements of [RFC5246] when negotiating that +# version. In particular: # -# - TLS 1.2 ClientHellos MAY omit this extension. +# - TLS 1.2 ClientHellos MAY omit this extension. # -# - In TLS 1.2, the extension contained hash/signature pairs. The -# pairs are encoded in two octets, so SignatureScheme values have -# been allocated to align with TLS 1.2's encoding. Some legacy -# pairs are left unallocated. These algorithms are deprecated as of -# TLS 1.3. They MUST NOT be offered or negotiated by any -# implementation. In particular, MD5 [SLOTH], SHA-224, and DSA -# MUST NOT be used. +# - In TLS 1.2, the extension contained hash/signature pairs. The +# pairs are encoded in two octets, so SignatureScheme values have +# been allocated to align with TLS 1.2's encoding. Some legacy +# pairs are left unallocated. These algorithms are deprecated as of +# TLS 1.3. They MUST NOT be offered or negotiated by any +# implementation. In particular, MD5 [SLOTH], SHA-224, and DSA +# MUST NOT be used. # -# - ECDSA signature schemes align with TLS 1.2's ECDSA hash/signature -# pairs. However, the old semantics did not constrain the signing -# curve. If TLS 1.2 is negotiated, implementations MUST be prepared -# to accept a signature that uses any curve that they advertised in -# the "supported_groups" extension. +# - ECDSA signature schemes align with TLS 1.2's ECDSA hash/signature +# pairs. However, the old semantics did not constrain the signing +# curve. If TLS 1.2 is negotiated, implementations MUST be prepared +# to accept a signature that uses any curve that they advertised in +# the "supported_groups" extension. # -# - Implementations that advertise support for RSASSA-PSS (which is -# mandatory in TLS 1.3) MUST be prepared to accept a signature using -# that scheme even when TLS 1.2 is negotiated. In TLS 1.2, -# RSASSA-PSS is used with RSA cipher suites. +# - Implementations that advertise support for RSASSA-PSS (which is +# mandatory in TLS 1.3) MUST be prepared to accept a signature using +# that scheme even when TLS 1.2 is negotiated. In TLS 1.2, +# RSASSA-PSS is used with RSA cipher suites. [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.2.4.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.2.4.toml index f2f081a2d63..60694ca1a1e 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.2.4.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.2.4.toml @@ -1,36 +1,36 @@ target = "https://www.rfc-editor.org/rfc/rfc8446#section-4.2.4" -# 4.2.4. Certificate Authorities +# Certificate Authorities # -# The "certificate_authorities" extension is used to indicate the -# certificate authorities (CAs) which an endpoint supports and which -# SHOULD be used by the receiving endpoint to guide certificate -# selection. +# The "certificate_authorities" extension is used to indicate the +# certificate authorities (CAs) which an endpoint supports and which +# SHOULD be used by the receiving endpoint to guide certificate +# selection. # -# The body of the "certificate_authorities" extension consists of a -# CertificateAuthoritiesExtension structure. +# The body of the "certificate_authorities" extension consists of a +# CertificateAuthoritiesExtension structure. # -# opaque DistinguishedName<1..2^16-1>; +# opaque DistinguishedName<1..2^16-1>; # -# struct { -# DistinguishedName authorities<3..2^16-1>; -# } CertificateAuthoritiesExtension; +# struct { +# DistinguishedName authorities<3..2^16-1>; +# } CertificateAuthoritiesExtension; # -# authorities: A list of the distinguished names [X501] of acceptable -# certificate authorities, represented in DER-encoded [X690] format. -# These distinguished names specify a desired distinguished name for -# a trust anchor or subordinate CA; thus, this message can be used -# to describe known trust anchors as well as a desired authorization -# space. +# authorities: A list of the distinguished names [X501] of acceptable +# certificate authorities, represented in DER-encoded [X690] format. +# These distinguished names specify a desired distinguished name for +# a trust anchor or subordinate CA; thus, this message can be used +# to describe known trust anchors as well as a desired authorization +# space. # -# The client MAY send the "certificate_authorities" extension in the -# ClientHello message. The server MAY send it in the -# CertificateRequest message. +# The client MAY send the "certificate_authorities" extension in the +# ClientHello message. The server MAY send it in the +# CertificateRequest message. # -# The "trusted_ca_keys" extension [RFC6066], which serves a similar -# purpose but is more complicated, is not used in TLS 1.3 (although it -# may appear in ClientHello messages from clients which are offering -# prior versions of TLS). +# The "trusted_ca_keys" extension [RFC6066], which serves a similar +# purpose but is more complicated, is not used in TLS 1.3 (although it +# may appear in ClientHello messages from clients which are offering +# prior versions of TLS). [[spec]] level = "SHOULD" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.2.5.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.2.5.toml index 392fb461cab..6341d16337f 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.2.5.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.2.5.toml @@ -1,58 +1,58 @@ target = "https://www.rfc-editor.org/rfc/rfc8446#section-4.2.5" -# 4.2.5. OID Filters +# OID Filters # -# The "oid_filters" extension allows servers to provide a set of -# OID/value pairs which it would like the client's certificate to -# match. This extension, if provided by the server, MUST only be sent -# in the CertificateRequest message. +# The "oid_filters" extension allows servers to provide a set of +# OID/value pairs which it would like the client's certificate to +# match. This extension, if provided by the server, MUST only be sent +# in the CertificateRequest message. # -# struct { -# opaque certificate_extension_oid<1..2^8-1>; -# opaque certificate_extension_values<0..2^16-1>; -# } OIDFilter; +# struct { +# opaque certificate_extension_oid<1..2^8-1>; +# opaque certificate_extension_values<0..2^16-1>; +# } OIDFilter; # -# struct { -# OIDFilter filters<0..2^16-1>; -# } OIDFilterExtension; +# struct { +# OIDFilter filters<0..2^16-1>; +# } OIDFilterExtension; # -# filters: A list of certificate extension OIDs [RFC5280] with their -# allowed value(s) and represented in DER-encoded [X690] format. -# Some certificate extension OIDs allow multiple values (e.g., -# Extended Key Usage). If the server has included a non-empty -# filters list, the client certificate included in the response MUST -# contain all of the specified extension OIDs that the client -# recognizes. For each extension OID recognized by the client, all -# of the specified values MUST be present in the client certificate -# (but the certificate MAY have other values as well). However, the -# client MUST ignore and skip any unrecognized certificate extension -# OIDs. If the client ignored some of the required certificate -# extension OIDs and supplied a certificate that does not satisfy -# the request, the server MAY at its discretion either continue the -# connection without client authentication or abort the handshake -# with an "unsupported_certificate" alert. Any given OID MUST NOT -# appear more than once in the filters list. +# filters: A list of certificate extension OIDs [RFC5280] with their +# allowed value(s) and represented in DER-encoded [X690] format. +# Some certificate extension OIDs allow multiple values (e.g., +# Extended Key Usage). If the server has included a non-empty +# filters list, the client certificate included in the response MUST +# contain all of the specified extension OIDs that the client +# recognizes. For each extension OID recognized by the client, all +# of the specified values MUST be present in the client certificate +# (but the certificate MAY have other values as well). However, the +# client MUST ignore and skip any unrecognized certificate extension +# OIDs. If the client ignored some of the required certificate +# extension OIDs and supplied a certificate that does not satisfy +# the request, the server MAY at its discretion either continue the +# connection without client authentication or abort the handshake +# with an "unsupported_certificate" alert. Any given OID MUST NOT +# appear more than once in the filters list. # -# PKIX RFCs define a variety of certificate extension OIDs and their -# corresponding value types. Depending on the type, matching -# certificate extension values are not necessarily bitwise-equal. It -# is expected that TLS implementations will rely on their PKI libraries -# to perform certificate selection using certificate extension OIDs. +# PKIX RFCs define a variety of certificate extension OIDs and their +# corresponding value types. Depending on the type, matching +# certificate extension values are not necessarily bitwise-equal. It +# is expected that TLS implementations will rely on their PKI libraries +# to perform certificate selection using certificate extension OIDs. # -# This document defines matching rules for two standard certificate -# extensions defined in [RFC5280]: +# This document defines matching rules for two standard certificate +# extensions defined in [RFC5280]: # -# - The Key Usage extension in a certificate matches the request when -# all key usage bits asserted in the request are also asserted in -# the Key Usage certificate extension. +# - The Key Usage extension in a certificate matches the request when +# all key usage bits asserted in the request are also asserted in +# the Key Usage certificate extension. # -# - The Extended Key Usage extension in a certificate matches the -# request when all key purpose OIDs present in the request are also -# found in the Extended Key Usage certificate extension. The -# special anyExtendedKeyUsage OID MUST NOT be used in the request. +# - The Extended Key Usage extension in a certificate matches the +# request when all key purpose OIDs present in the request are also +# found in the Extended Key Usage certificate extension. The +# special anyExtendedKeyUsage OID MUST NOT be used in the request. # -# Separate specifications may define matching rules for other -# certificate extensions. +# Separate specifications may define matching rules for other +# certificate extensions. [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.2.6.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.2.6.toml index d813885542e..fa08e703803 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.2.6.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.2.6.toml @@ -1,17 +1,17 @@ target = "https://www.rfc-editor.org/rfc/rfc8446#section-4.2.6" -# 4.2.6. Post-Handshake Client Authentication +# Post-Handshake Client Authentication # -# The "post_handshake_auth" extension is used to indicate that a client -# is willing to perform post-handshake authentication (Section 4.6.2). -# Servers MUST NOT send a post-handshake CertificateRequest to clients -# which do not offer this extension. Servers MUST NOT send this -# extension. +# The "post_handshake_auth" extension is used to indicate that a client +# is willing to perform post-handshake authentication (Section 4.6.2). +# Servers MUST NOT send a post-handshake CertificateRequest to clients +# which do not offer this extension. Servers MUST NOT send this +# extension. # -# struct {} PostHandshakeAuth; +# struct {} PostHandshakeAuth; # -# The "extension_data" field of the "post_handshake_auth" extension is -# zero length. +# The "extension_data" field of the "post_handshake_auth" extension is +# zero length. [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.2.7.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.2.7.toml index 40e27839890..2ac0a4325cc 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.2.7.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.2.7.toml @@ -1,63 +1,63 @@ target = "https://www.rfc-editor.org/rfc/rfc8446#section-4.2.7" -# 4.2.7. Supported Groups +# Supported Groups # -# When sent by the client, the "supported_groups" extension indicates -# the named groups which the client supports for key exchange, ordered -# from most preferred to least preferred. +# When sent by the client, the "supported_groups" extension indicates +# the named groups which the client supports for key exchange, ordered +# from most preferred to least preferred. # -# Note: In versions of TLS prior to TLS 1.3, this extension was named -# "elliptic_curves" and only contained elliptic curve groups. See -# [RFC8422] and [RFC7919]. This extension was also used to negotiate -# ECDSA curves. Signature algorithms are now negotiated independently -# (see Section 4.2.3). +# Note: In versions of TLS prior to TLS 1.3, this extension was named +# "elliptic_curves" and only contained elliptic curve groups. See +# [RFC8422] and [RFC7919]. This extension was also used to negotiate +# ECDSA curves. Signature algorithms are now negotiated independently +# (see Section 4.2.3). # -# The "extension_data" field of this extension contains a -# "NamedGroupList" value: +# The "extension_data" field of this extension contains a +# "NamedGroupList" value: # -# enum { +# enum { # -# /* Elliptic Curve Groups (ECDHE) */ -# secp256r1(0x0017), secp384r1(0x0018), secp521r1(0x0019), -# x25519(0x001D), x448(0x001E), +# /* Elliptic Curve Groups (ECDHE) */ +# secp256r1(0x0017), secp384r1(0x0018), secp521r1(0x0019), +# x25519(0x001D), x448(0x001E), # -# /* Finite Field Groups (DHE) */ -# ffdhe2048(0x0100), ffdhe3072(0x0101), ffdhe4096(0x0102), -# ffdhe6144(0x0103), ffdhe8192(0x0104), +# /* Finite Field Groups (DHE) */ +# ffdhe2048(0x0100), ffdhe3072(0x0101), ffdhe4096(0x0102), +# ffdhe6144(0x0103), ffdhe8192(0x0104), # -# /* Reserved Code Points */ -# ffdhe_private_use(0x01FC..0x01FF), -# ecdhe_private_use(0xFE00..0xFEFF), -# (0xFFFF) -# } NamedGroup; +# /* Reserved Code Points */ +# ffdhe_private_use(0x01FC..0x01FF), +# ecdhe_private_use(0xFE00..0xFEFF), +# (0xFFFF) +# } NamedGroup; # -# struct { -# NamedGroup named_group_list<2..2^16-1>; -# } NamedGroupList; +# struct { +# NamedGroup named_group_list<2..2^16-1>; +# } NamedGroupList; # -# Elliptic Curve Groups (ECDHE): Indicates support for the -# corresponding named curve, defined in either FIPS 186-4 [DSS] or -# [RFC7748]. Values 0xFE00 through 0xFEFF are reserved for -# Private Use [RFC8126]. +# Elliptic Curve Groups (ECDHE): Indicates support for the +# corresponding named curve, defined in either FIPS 186-4 [DSS] or +# [RFC7748]. Values 0xFE00 through 0xFEFF are reserved for +# Private Use [RFC8126]. # -# Finite Field Groups (DHE): Indicates support for the corresponding -# finite field group, defined in [RFC7919]. Values 0x01FC through -# 0x01FF are reserved for Private Use. +# Finite Field Groups (DHE): Indicates support for the corresponding +# finite field group, defined in [RFC7919]. Values 0x01FC through +# 0x01FF are reserved for Private Use. # -# Items in named_group_list are ordered according to the sender's -# preferences (most preferred choice first). +# Items in named_group_list are ordered according to the sender's +# preferences (most preferred choice first). # -# As of TLS 1.3, servers are permitted to send the "supported_groups" -# extension to the client. Clients MUST NOT act upon any information -# found in "supported_groups" prior to successful completion of the -# handshake but MAY use the information learned from a successfully -# completed handshake to change what groups they use in their -# "key_share" extension in subsequent connections. If the server has a -# group it prefers to the ones in the "key_share" extension but is -# still willing to accept the ClientHello, it SHOULD send -# "supported_groups" to update the client's view of its preferences; -# this extension SHOULD contain all groups the server supports, -# regardless of whether they are currently supported by the client. +# As of TLS 1.3, servers are permitted to send the "supported_groups" +# extension to the client. Clients MUST NOT act upon any information +# found in "supported_groups" prior to successful completion of the +# handshake but MAY use the information learned from a successfully +# completed handshake to change what groups they use in their +# "key_share" extension in subsequent connections. If the server has a +# group it prefers to the ones in the "key_share" extension but is +# still willing to accept the ClientHello, it SHOULD send +# "supported_groups" to update the client's view of its preferences; +# this extension SHOULD contain all groups the server supports, +# regardless of whether they are currently supported by the client. [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.2.8.1.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.2.8.1.toml index 624c75313d9..ee7431ea18c 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.2.8.1.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.2.8.1.toml @@ -1,20 +1,20 @@ target = "https://www.rfc-editor.org/rfc/rfc8446#section-4.2.8.1" -# 4.2.8.1. Diffie-Hellman Parameters +# Diffie-Hellman Parameters # -# Diffie-Hellman [DH76] parameters for both clients and servers are -# encoded in the opaque key_exchange field of a KeyShareEntry in a -# KeyShare structure. The opaque value contains the Diffie-Hellman -# public value (Y = g^X mod p) for the specified group (see [RFC7919] -# for group definitions) encoded as a big-endian integer and padded to -# the left with zeros to the size of p in bytes. +# Diffie-Hellman [DH76] parameters for both clients and servers are +# encoded in the opaque key_exchange field of a KeyShareEntry in a +# KeyShare structure. The opaque value contains the Diffie-Hellman +# public value (Y = g^X mod p) for the specified group (see [RFC7919] +# for group definitions) encoded as a big-endian integer and padded to +# the left with zeros to the size of p in bytes. # -# Note: For a given Diffie-Hellman group, the padding results in all -# public keys having the same length. +# Note: For a given Diffie-Hellman group, the padding results in all +# public keys having the same length. # -# Peers MUST validate each other's public key Y by ensuring that 1 < Y -# < p-1. This check ensures that the remote peer is properly behaved -# and isn't forcing the local system into a small subgroup. +# Peers MUST validate each other's public key Y by ensuring that 1 < Y +# < p-1. This check ensures that the remote peer is properly behaved +# and isn't forcing the local system into a small subgroup. [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.2.8.2.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.2.8.2.toml index f97d79d2698..8357812613e 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.2.8.2.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.2.8.2.toml @@ -1,44 +1,44 @@ target = "https://www.rfc-editor.org/rfc/rfc8446#section-4.2.8.2" -# 4.2.8.2. ECDHE Parameters +# ECDHE Parameters # -# ECDHE parameters for both clients and servers are encoded in the -# opaque key_exchange field of a KeyShareEntry in a KeyShare structure. +# ECDHE parameters for both clients and servers are encoded in the +# opaque key_exchange field of a KeyShareEntry in a KeyShare structure. # -# For secp256r1, secp384r1, and secp521r1, the contents are the -# serialized value of the following struct: +# For secp256r1, secp384r1, and secp521r1, the contents are the +# serialized value of the following struct: # -# struct { -# uint8 legacy_form = 4; -# opaque X[coordinate_length]; -# opaque Y[coordinate_length]; -# } UncompressedPointRepresentation; +# struct { +# uint8 legacy_form = 4; +# opaque X[coordinate_length]; +# opaque Y[coordinate_length]; +# } UncompressedPointRepresentation; # -# X and Y, respectively, are the binary representations of the x and y -# values in network byte order. There are no internal length markers, -# so each number representation occupies as many octets as implied by -# the curve parameters. For P-256, this means that each of X and Y use -# 32 octets, padded on the left by zeros if necessary. For P-384, they -# take 48 octets each. For P-521, they take 66 octets each. +# X and Y, respectively, are the binary representations of the x and y +# values in network byte order. There are no internal length markers, +# so each number representation occupies as many octets as implied by +# the curve parameters. For P-256, this means that each of X and Y use +# 32 octets, padded on the left by zeros if necessary. For P-384, they +# take 48 octets each. For P-521, they take 66 octets each. # -# For the curves secp256r1, secp384r1, and secp521r1, peers MUST -# validate each other's public value Q by ensuring that the point is a -# valid point on the elliptic curve. The appropriate validation -# procedures are defined in Section 4.3.7 of [ECDSA] and alternatively -# in Section 5.6.2.3 of [KEYAGREEMENT]. This process consists of three -# steps: (1) verify that Q is not the point at infinity (O), (2) verify -# that for Q = (x, y) both integers x and y are in the correct -# interval, and (3) ensure that (x, y) is a correct solution to the -# elliptic curve equation. For these curves, implementors do not need -# to verify membership in the correct subgroup. +# For the curves secp256r1, secp384r1, and secp521r1, peers MUST +# validate each other's public value Q by ensuring that the point is a +# valid point on the elliptic curve. The appropriate validation +# procedures are defined in Section 4.3.7 of [ECDSA] and alternatively +# in Section 5.6.2.3 of [KEYAGREEMENT]. This process consists of three +# steps: (1) verify that Q is not the point at infinity (O), (2) verify +# that for Q = (x, y) both integers x and y are in the correct +# interval, and (3) ensure that (x, y) is a correct solution to the +# elliptic curve equation. For these curves, implementors do not need +# to verify membership in the correct subgroup. # -# For X25519 and X448, the contents of the public value are the byte -# string inputs and outputs of the corresponding functions defined in -# [RFC7748]: 32 bytes for X25519 and 56 bytes for X448. +# For X25519 and X448, the contents of the public value are the byte +# string inputs and outputs of the corresponding functions defined in +# [RFC7748]: 32 bytes for X25519 and 56 bytes for X448. # -# Note: Versions of TLS prior to 1.3 permitted point format -# negotiation; TLS 1.3 removes this feature in favor of a single point -# format for each curve. +# Note: Versions of TLS prior to 1.3 permitted point format +# negotiation; TLS 1.3 removes this feature in favor of a single point +# format for each curve. [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.2.8.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.2.8.toml index 83d0a106351..6364c1a8575 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.2.8.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.2.8.toml @@ -1,102 +1,102 @@ target = "https://www.rfc-editor.org/rfc/rfc8446#section-4.2.8" -# 4.2.8. Key Share +# Key Share # -# The "key_share" extension contains the endpoint's cryptographic -# parameters. -# -# Clients MAY send an empty client_shares vector in order to request -# group selection from the server, at the cost of an additional round -# trip (see Section 4.1.4). -# -# struct { -# NamedGroup group; -# opaque key_exchange<1..2^16-1>; -# } KeyShareEntry; -# -# group: The named group for the key being exchanged. -# -# key_exchange: Key exchange information. The contents of this field -# are determined by the specified group and its corresponding -# definition. Finite Field Diffie-Hellman [DH76] parameters are -# described in Section 4.2.8.1; Elliptic Curve Diffie-Hellman -# parameters are described in Section 4.2.8.2. -# -# In the ClientHello message, the "extension_data" field of this -# extension contains a "KeyShareClientHello" value: -# -# struct { -# KeyShareEntry client_shares<0..2^16-1>; -# } KeyShareClientHello; -# -# client_shares: A list of offered KeyShareEntry values in descending -# order of client preference. -# -# This vector MAY be empty if the client is requesting a -# HelloRetryRequest. Each KeyShareEntry value MUST correspond to a -# group offered in the "supported_groups" extension and MUST appear in -# the same order. However, the values MAY be a non-contiguous subset -# of the "supported_groups" extension and MAY omit the most preferred -# groups. Such a situation could arise if the most preferred groups -# are new and unlikely to be supported in enough places to make -# pregenerating key shares for them efficient. -# -# Clients can offer as many KeyShareEntry values as the number of -# supported groups it is offering, each representing a single set of -# key exchange parameters. For instance, a client might offer shares -# for several elliptic curves or multiple FFDHE groups. The -# key_exchange values for each KeyShareEntry MUST be generated -# independently. Clients MUST NOT offer multiple KeyShareEntry values -# for the same group. Clients MUST NOT offer any KeyShareEntry values -# for groups not listed in the client's "supported_groups" extension. -# Servers MAY check for violations of these rules and abort the -# handshake with an "illegal_parameter" alert if one is violated. -# -# In a HelloRetryRequest message, the "extension_data" field of this -# extension contains a KeyShareHelloRetryRequest value: -# -# struct { -# NamedGroup selected_group; -# } KeyShareHelloRetryRequest; -# -# selected_group: The mutually supported group the server intends to -# negotiate and is requesting a retried ClientHello/KeyShare for. -# -# Upon receipt of this extension in a HelloRetryRequest, the client -# MUST verify that (1) the selected_group field corresponds to a group -# which was provided in the "supported_groups" extension in the -# original ClientHello and (2) the selected_group field does not -# correspond to a group which was provided in the "key_share" extension -# in the original ClientHello. If either of these checks fails, then -# the client MUST abort the handshake with an "illegal_parameter" -# alert. Otherwise, when sending the new ClientHello, the client MUST -# -# replace the original "key_share" extension with one containing only a -# new KeyShareEntry for the group indicated in the selected_group field -# of the triggering HelloRetryRequest. -# -# In a ServerHello message, the "extension_data" field of this -# extension contains a KeyShareServerHello value: -# -# struct { -# KeyShareEntry server_share; -# } KeyShareServerHello; -# -# server_share: A single KeyShareEntry value that is in the same group -# as one of the client's shares. -# -# If using (EC)DHE key establishment, servers offer exactly one -# KeyShareEntry in the ServerHello. This value MUST be in the same -# group as the KeyShareEntry value offered by the client that the -# server has selected for the negotiated key exchange. Servers -# MUST NOT send a KeyShareEntry for any group not indicated in the -# client's "supported_groups" extension and MUST NOT send a -# KeyShareEntry when using the "psk_ke" PskKeyExchangeMode. If using -# (EC)DHE key establishment and a HelloRetryRequest containing a -# "key_share" extension was received by the client, the client MUST -# verify that the selected NamedGroup in the ServerHello is the same as -# that in the HelloRetryRequest. If this check fails, the client MUST -# abort the handshake with an "illegal_parameter" alert. +# The "key_share" extension contains the endpoint's cryptographic +# parameters. +# +# Clients MAY send an empty client_shares vector in order to request +# group selection from the server, at the cost of an additional round +# trip (see Section 4.1.4). +# +# struct { +# NamedGroup group; +# opaque key_exchange<1..2^16-1>; +# } KeyShareEntry; +# +# group: The named group for the key being exchanged. +# +# key_exchange: Key exchange information. The contents of this field +# are determined by the specified group and its corresponding +# definition. Finite Field Diffie-Hellman [DH76] parameters are +# described in Section 4.2.8.1; Elliptic Curve Diffie-Hellman +# parameters are described in Section 4.2.8.2. +# +# In the ClientHello message, the "extension_data" field of this +# extension contains a "KeyShareClientHello" value: +# +# struct { +# KeyShareEntry client_shares<0..2^16-1>; +# } KeyShareClientHello; +# +# client_shares: A list of offered KeyShareEntry values in descending +# order of client preference. +# +# This vector MAY be empty if the client is requesting a +# HelloRetryRequest. Each KeyShareEntry value MUST correspond to a +# group offered in the "supported_groups" extension and MUST appear in +# the same order. However, the values MAY be a non-contiguous subset +# of the "supported_groups" extension and MAY omit the most preferred +# groups. Such a situation could arise if the most preferred groups +# are new and unlikely to be supported in enough places to make +# pregenerating key shares for them efficient. +# +# Clients can offer as many KeyShareEntry values as the number of +# supported groups it is offering, each representing a single set of +# key exchange parameters. For instance, a client might offer shares +# for several elliptic curves or multiple FFDHE groups. The +# key_exchange values for each KeyShareEntry MUST be generated +# independently. Clients MUST NOT offer multiple KeyShareEntry values +# for the same group. Clients MUST NOT offer any KeyShareEntry values +# for groups not listed in the client's "supported_groups" extension. +# Servers MAY check for violations of these rules and abort the +# handshake with an "illegal_parameter" alert if one is violated. +# +# In a HelloRetryRequest message, the "extension_data" field of this +# extension contains a KeyShareHelloRetryRequest value: +# +# struct { +# NamedGroup selected_group; +# } KeyShareHelloRetryRequest; +# +# selected_group: The mutually supported group the server intends to +# negotiate and is requesting a retried ClientHello/KeyShare for. +# +# Upon receipt of this extension in a HelloRetryRequest, the client +# MUST verify that (1) the selected_group field corresponds to a group +# which was provided in the "supported_groups" extension in the +# original ClientHello and (2) the selected_group field does not +# correspond to a group which was provided in the "key_share" extension +# in the original ClientHello. If either of these checks fails, then +# the client MUST abort the handshake with an "illegal_parameter" +# alert. Otherwise, when sending the new ClientHello, the client MUST +# +# replace the original "key_share" extension with one containing only a +# new KeyShareEntry for the group indicated in the selected_group field +# of the triggering HelloRetryRequest. +# +# In a ServerHello message, the "extension_data" field of this +# extension contains a KeyShareServerHello value: +# +# struct { +# KeyShareEntry server_share; +# } KeyShareServerHello; +# +# server_share: A single KeyShareEntry value that is in the same group +# as one of the client's shares. +# +# If using (EC)DHE key establishment, servers offer exactly one +# KeyShareEntry in the ServerHello. This value MUST be in the same +# group as the KeyShareEntry value offered by the client that the +# server has selected for the negotiated key exchange. Servers +# MUST NOT send a KeyShareEntry for any group not indicated in the +# client's "supported_groups" extension and MUST NOT send a +# KeyShareEntry when using the "psk_ke" PskKeyExchangeMode. If using +# (EC)DHE key establishment and a HelloRetryRequest containing a +# "key_share" extension was received by the client, the client MUST +# verify that the selected NamedGroup in the ServerHello is the same as +# that in the HelloRetryRequest. If this check fails, the client MUST +# abort the handshake with an "illegal_parameter" alert. [[spec]] level = "MAY" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.2.9.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.2.9.toml index 5624993643f..ebe5ea7b5c7 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.2.9.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.2.9.toml @@ -1,42 +1,42 @@ target = "https://www.rfc-editor.org/rfc/rfc8446#section-4.2.9" -# 4.2.9. Pre-Shared Key Exchange Modes +# Pre-Shared Key Exchange Modes # -# In order to use PSKs, clients MUST also send a -# "psk_key_exchange_modes" extension. The semantics of this extension -# are that the client only supports the use of PSKs with these modes, -# which restricts both the use of PSKs offered in this ClientHello and -# those which the server might supply via NewSessionTicket. +# In order to use PSKs, clients MUST also send a +# "psk_key_exchange_modes" extension. The semantics of this extension +# are that the client only supports the use of PSKs with these modes, +# which restricts both the use of PSKs offered in this ClientHello and +# those which the server might supply via NewSessionTicket. # -# A client MUST provide a "psk_key_exchange_modes" extension if it -# offers a "pre_shared_key" extension. If clients offer -# "pre_shared_key" without a "psk_key_exchange_modes" extension, -# servers MUST abort the handshake. Servers MUST NOT select a key -# exchange mode that is not listed by the client. This extension also -# restricts the modes for use with PSK resumption. Servers SHOULD NOT -# send NewSessionTicket with tickets that are not compatible with the -# advertised modes; however, if a server does so, the impact will just -# be that the client's attempts at resumption fail. +# A client MUST provide a "psk_key_exchange_modes" extension if it +# offers a "pre_shared_key" extension. If clients offer +# "pre_shared_key" without a "psk_key_exchange_modes" extension, +# servers MUST abort the handshake. Servers MUST NOT select a key +# exchange mode that is not listed by the client. This extension also +# restricts the modes for use with PSK resumption. Servers SHOULD NOT +# send NewSessionTicket with tickets that are not compatible with the +# advertised modes; however, if a server does so, the impact will just +# be that the client's attempts at resumption fail. # -# The server MUST NOT send a "psk_key_exchange_modes" extension. +# The server MUST NOT send a "psk_key_exchange_modes" extension. # -# enum { psk_ke(0), psk_dhe_ke(1), (255) } PskKeyExchangeMode; +# enum { psk_ke(0), psk_dhe_ke(1), (255) } PskKeyExchangeMode; # -# struct { -# PskKeyExchangeMode ke_modes<1..255>; -# } PskKeyExchangeModes; +# struct { +# PskKeyExchangeMode ke_modes<1..255>; +# } PskKeyExchangeModes; # -# psk_ke: PSK-only key establishment. In this mode, the server -# MUST NOT supply a "key_share" value. +# psk_ke: PSK-only key establishment. In this mode, the server +# MUST NOT supply a "key_share" value. # -# psk_dhe_ke: PSK with (EC)DHE key establishment. In this mode, the -# client and server MUST supply "key_share" values as described in -# Section 4.2.8. +# psk_dhe_ke: PSK with (EC)DHE key establishment. In this mode, the +# client and server MUST supply "key_share" values as described in +# Section 4.2.8. # -# Any future values that are allocated must ensure that the transmitted -# protocol messages unambiguously identify which mode was selected by -# the server; at present, this is indicated by the presence of the -# "key_share" in the ServerHello. +# Any future values that are allocated must ensure that the transmitted +# protocol messages unambiguously identify which mode was selected by +# the server; at present, this is indicated by the presence of the +# "key_share" in the ServerHello. [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.2.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.2.toml index 83e7272b7f1..7a652f9b99d 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.2.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.2.toml @@ -1,160 +1,160 @@ target = "https://www.rfc-editor.org/rfc/rfc8446#section-4.2" -# 4.2. Extensions +# Extensions # -# A number of TLS messages contain tag-length-value encoded extensions -# structures. +# A number of TLS messages contain tag-length-value encoded extensions +# structures. # -# struct { -# ExtensionType extension_type; -# opaque extension_data<0..2^16-1>; -# } Extension; +# 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; +# 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: +# Here: # -# - "extension_type" identifies the particular extension type. +# - "extension_type" identifies the particular extension type. # -# - "extension_data" contains information specific to 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. +# 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. +# 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. +# 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. +# 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 | -# +--------------------------------------------------+-------------+ +# +--------------------------------------------------+-------------+ +# | 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. +# 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). +# 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: +# 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. +# - 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. +# - 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" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.3.1.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.3.1.toml index 5d158e93c69..096da2d492b 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.3.1.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.3.1.toml @@ -1,27 +1,27 @@ target = "https://www.rfc-editor.org/rfc/rfc8446#section-4.3.1" -# 4.3.1. Encrypted Extensions +# Encrypted Extensions # -# In all handshakes, the server MUST send the EncryptedExtensions -# message immediately after the ServerHello message. This is the first -# message that is encrypted under keys derived from the -# server_handshake_traffic_secret. +# In all handshakes, the server MUST send the EncryptedExtensions +# message immediately after the ServerHello message. This is the first +# message that is encrypted under keys derived from the +# server_handshake_traffic_secret. # -# The EncryptedExtensions message contains extensions that can be -# protected, i.e., any which are not needed to establish the -# cryptographic context but which are not associated with individual -# certificates. The client MUST check EncryptedExtensions for the -# presence of any forbidden extensions and if any are found MUST abort -# the handshake with an "illegal_parameter" alert. +# The EncryptedExtensions message contains extensions that can be +# protected, i.e., any which are not needed to establish the +# cryptographic context but which are not associated with individual +# certificates. The client MUST check EncryptedExtensions for the +# presence of any forbidden extensions and if any are found MUST abort +# the handshake with an "illegal_parameter" alert. # -# Structure of this message: +# Structure of this message: # -# struct { -# Extension extensions<0..2^16-1>; -# } EncryptedExtensions; +# struct { +# Extension extensions<0..2^16-1>; +# } EncryptedExtensions; # -# extensions: A list of extensions. For more information, see the -# table in Section 4.2. +# extensions: A list of extensions. For more information, see the +# table in Section 4.2. [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.3.2.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.3.2.toml index 14cc4ac60d0..c37f364885f 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.3.2.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.3.2.toml @@ -1,48 +1,48 @@ target = "https://www.rfc-editor.org/rfc/rfc8446#section-4.3.2" -# 4.3.2. Certificate Request +# Certificate Request # -# A server which is authenticating with a certificate MAY optionally -# request a certificate from the client. This message, if sent, MUST -# follow EncryptedExtensions. +# A server which is authenticating with a certificate MAY optionally +# request a certificate from the client. This message, if sent, MUST +# follow EncryptedExtensions. # -# Structure of this message: +# Structure of this message: # -# struct { -# opaque certificate_request_context<0..2^8-1>; -# Extension extensions<2..2^16-1>; -# } CertificateRequest; +# struct { +# opaque certificate_request_context<0..2^8-1>; +# Extension extensions<2..2^16-1>; +# } CertificateRequest; # -# certificate_request_context: An opaque string which identifies the -# certificate request and which will be echoed in the client's -# Certificate message. The certificate_request_context MUST be -# unique within the scope of this connection (thus preventing replay -# of client CertificateVerify messages). This field SHALL be zero -# length unless used for the post-handshake authentication exchanges -# described in Section 4.6.2. When requesting post-handshake -# authentication, the server SHOULD make the context unpredictable -# to the client (e.g., by randomly generating it) in order to -# prevent an attacker who has temporary access to the client's -# private key from pre-computing valid CertificateVerify messages. +# certificate_request_context: An opaque string which identifies the +# certificate request and which will be echoed in the client's +# Certificate message. The certificate_request_context MUST be +# unique within the scope of this connection (thus preventing replay +# of client CertificateVerify messages). This field SHALL be zero +# length unless used for the post-handshake authentication exchanges +# described in Section 4.6.2. When requesting post-handshake +# authentication, the server SHOULD make the context unpredictable +# to the client (e.g., by randomly generating it) in order to +# prevent an attacker who has temporary access to the client's +# private key from pre-computing valid CertificateVerify messages. # -# extensions: A set of extensions describing the parameters of the -# certificate being requested. The "signature_algorithms" extension -# MUST be specified, and other extensions may optionally be included -# if defined for this message. Clients MUST ignore unrecognized -# extensions. +# extensions: A set of extensions describing the parameters of the +# certificate being requested. The "signature_algorithms" extension +# MUST be specified, and other extensions may optionally be included +# if defined for this message. Clients MUST ignore unrecognized +# extensions. # -# In prior versions of TLS, the CertificateRequest message carried a -# list of signature algorithms and certificate authorities which the -# server would accept. In TLS 1.3, the former is expressed by sending -# the "signature_algorithms" and optionally "signature_algorithms_cert" -# extensions. The latter is expressed by sending the -# "certificate_authorities" extension (see Section 4.2.4). +# In prior versions of TLS, the CertificateRequest message carried a +# list of signature algorithms and certificate authorities which the +# server would accept. In TLS 1.3, the former is expressed by sending +# the "signature_algorithms" and optionally "signature_algorithms_cert" +# extensions. The latter is expressed by sending the +# "certificate_authorities" extension (see Section 4.2.4). # -# Servers which are authenticating with a PSK MUST NOT send the -# CertificateRequest message in the main handshake, though they MAY -# send it in post-handshake authentication (see Section 4.6.2) provided -# that the client has sent the "post_handshake_auth" extension (see -# Section 4.2.6). +# Servers which are authenticating with a PSK MUST NOT send the +# CertificateRequest message in the main handshake, though they MAY +# send it in post-handshake authentication (see Section 4.6.2) provided +# that the client has sent the "post_handshake_auth" extension (see +# Section 4.2.6). [[spec]] level = "MAY" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.4.2.1.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.4.2.1.toml index 125afe89c42..cd312075b7c 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.4.2.1.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.4.2.1.toml @@ -1,36 +1,36 @@ target = "https://www.rfc-editor.org/rfc/rfc8446#section-4.4.2.1" -# 4.4.2.1. OCSP Status and SCT Extensions +# OCSP Status and SCT Extensions # -# [RFC6066] and [RFC6961] provide extensions to negotiate the server -# sending OCSP responses to the client. In TLS 1.2 and below, the -# server replies with an empty extension to indicate negotiation of -# this extension and the OCSP information is carried in a -# CertificateStatus message. In TLS 1.3, the server's OCSP information -# is carried in an extension in the CertificateEntry containing the -# associated certificate. Specifically, the body of the -# "status_request" extension from the server MUST be a -# CertificateStatus structure as defined in [RFC6066], which is -# interpreted as defined in [RFC6960]. +# [RFC6066] and [RFC6961] provide extensions to negotiate the server +# sending OCSP responses to the client. In TLS 1.2 and below, the +# server replies with an empty extension to indicate negotiation of +# this extension and the OCSP information is carried in a +# CertificateStatus message. In TLS 1.3, the server's OCSP information +# is carried in an extension in the CertificateEntry containing the +# associated certificate. Specifically, the body of the +# "status_request" extension from the server MUST be a +# CertificateStatus structure as defined in [RFC6066], which is +# interpreted as defined in [RFC6960]. # -# Note: The status_request_v2 extension [RFC6961] is deprecated. -# TLS 1.3 servers MUST NOT act upon its presence or information in it -# when processing ClientHello messages; in particular, they MUST NOT -# send the status_request_v2 extension in the EncryptedExtensions, -# CertificateRequest, or Certificate messages. TLS 1.3 servers MUST be -# able to process ClientHello messages that include it, as it MAY be -# sent by clients that wish to use it in earlier protocol versions. +# Note: The status_request_v2 extension [RFC6961] is deprecated. +# TLS 1.3 servers MUST NOT act upon its presence or information in it +# when processing ClientHello messages; in particular, they MUST NOT +# send the status_request_v2 extension in the EncryptedExtensions, +# CertificateRequest, or Certificate messages. TLS 1.3 servers MUST be +# able to process ClientHello messages that include it, as it MAY be +# sent by clients that wish to use it in earlier protocol versions. # -# A server MAY request that a client present an OCSP response with its -# certificate by sending an empty "status_request" extension in its -# CertificateRequest message. If the client opts to send an OCSP -# response, the body of its "status_request" extension MUST be a -# CertificateStatus structure as defined in [RFC6066]. +# A server MAY request that a client present an OCSP response with its +# certificate by sending an empty "status_request" extension in its +# CertificateRequest message. If the client opts to send an OCSP +# response, the body of its "status_request" extension MUST be a +# CertificateStatus structure as defined in [RFC6066]. # -# Similarly, [RFC6962] provides a mechanism for a server to send a -# Signed Certificate Timestamp (SCT) as an extension in the ServerHello -# in TLS 1.2 and below. In TLS 1.3, the server's SCT information is -# carried in an extension in the CertificateEntry. +# Similarly, [RFC6962] provides a mechanism for a server to send a +# Signed Certificate Timestamp (SCT) as an extension in the ServerHello +# in TLS 1.2 and below. In TLS 1.3, the server's SCT information is +# carried in an extension in the CertificateEntry. [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.4.2.2.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.4.2.2.toml index 976312b558d..70b64f56c8c 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.4.2.2.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.4.2.2.toml @@ -1,51 +1,51 @@ target = "https://www.rfc-editor.org/rfc/rfc8446#section-4.4.2.2" -# 4.4.2.2. Server Certificate Selection +# Server Certificate Selection # -# The following rules apply to the certificates sent by the server: +# The following rules apply to the certificates sent by the server: # -# - The certificate type MUST be X.509v3 [RFC5280], unless explicitly -# negotiated otherwise (e.g., [RFC7250]). +# - The certificate type MUST be X.509v3 [RFC5280], unless explicitly +# negotiated otherwise (e.g., [RFC7250]). # -# - The server's end-entity certificate's public key (and associated -# restrictions) MUST be compatible with the selected authentication -# algorithm from the client's "signature_algorithms" extension -# (currently RSA, ECDSA, or EdDSA). +# - The server's end-entity certificate's public key (and associated +# restrictions) MUST be compatible with the selected authentication +# algorithm from the client's "signature_algorithms" extension +# (currently RSA, ECDSA, or EdDSA). # -# - The certificate MUST allow the key to be used for signing (i.e., -# the digitalSignature bit MUST be set if the Key Usage extension is -# present) with a signature scheme indicated in the client's -# "signature_algorithms"/"signature_algorithms_cert" extensions (see -# Section 4.2.3). +# - The certificate MUST allow the key to be used for signing (i.e., +# the digitalSignature bit MUST be set if the Key Usage extension is +# present) with a signature scheme indicated in the client's +# "signature_algorithms"/"signature_algorithms_cert" extensions (see +# Section 4.2.3). # -# - The "server_name" [RFC6066] and "certificate_authorities" -# extensions are used to guide certificate selection. As servers -# MAY require the presence of the "server_name" extension, clients -# SHOULD send this extension, when applicable. +# - The "server_name" [RFC6066] and "certificate_authorities" +# extensions are used to guide certificate selection. As servers +# MAY require the presence of the "server_name" extension, clients +# SHOULD send this extension, when applicable. # -# All certificates provided by the server MUST be signed by a signature -# algorithm advertised by the client if it is able to provide such a -# chain (see Section 4.2.3). Certificates that are self-signed or -# certificates that are expected to be trust anchors are not validated -# as part of the chain and therefore MAY be signed with any algorithm. +# All certificates provided by the server MUST be signed by a signature +# algorithm advertised by the client if it is able to provide such a +# chain (see Section 4.2.3). Certificates that are self-signed or +# certificates that are expected to be trust anchors are not validated +# as part of the chain and therefore MAY be signed with any algorithm. # -# If the server cannot produce a certificate chain that is signed only -# via the indicated supported algorithms, then it SHOULD continue the -# handshake by sending the client a certificate chain of its choice -# that may include algorithms that are not known to be supported by the -# client. This fallback chain SHOULD NOT use the deprecated SHA-1 hash -# algorithm in general, but MAY do so if the client's advertisement -# permits it, and MUST NOT do so otherwise. +# If the server cannot produce a certificate chain that is signed only +# via the indicated supported algorithms, then it SHOULD continue the +# handshake by sending the client a certificate chain of its choice +# that may include algorithms that are not known to be supported by the +# client. This fallback chain SHOULD NOT use the deprecated SHA-1 hash +# algorithm in general, but MAY do so if the client's advertisement +# permits it, and MUST NOT do so otherwise. # -# If the client cannot construct an acceptable chain using the provided -# certificates and decides to abort the handshake, then it MUST abort -# the handshake with an appropriate certificate-related alert (by -# default, "unsupported_certificate"; see Section 6.2 for more -# information). +# If the client cannot construct an acceptable chain using the provided +# certificates and decides to abort the handshake, then it MUST abort +# the handshake with an appropriate certificate-related alert (by +# default, "unsupported_certificate"; see Section 6.2 for more +# information). # -# If the server has multiple certificates, it chooses one of them based -# on the above-mentioned criteria (in addition to other criteria, such -# as transport-layer endpoint, local configuration, and preferences). +# If the server has multiple certificates, it chooses one of them based +# on the above-mentioned criteria (in addition to other criteria, such +# as transport-layer endpoint, local configuration, and preferences). [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.4.2.3.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.4.2.3.toml index b2660e8664a..310a937a204 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.4.2.3.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.4.2.3.toml @@ -1,26 +1,26 @@ target = "https://www.rfc-editor.org/rfc/rfc8446#section-4.4.2.3" -# 4.4.2.3. Client Certificate Selection +# Client Certificate Selection # -# The following rules apply to certificates sent by the client: +# The following rules apply to certificates sent by the client: # -# - The certificate type MUST be X.509v3 [RFC5280], unless explicitly -# negotiated otherwise (e.g., [RFC7250]). +# - The certificate type MUST be X.509v3 [RFC5280], unless explicitly +# negotiated otherwise (e.g., [RFC7250]). # -# - If the "certificate_authorities" extension in the -# CertificateRequest message was present, at least one of the -# certificates in the certificate chain SHOULD be issued by one of -# the listed CAs. +# - If the "certificate_authorities" extension in the +# CertificateRequest message was present, at least one of the +# certificates in the certificate chain SHOULD be issued by one of +# the listed CAs. # -# - The certificates MUST be signed using an acceptable signature -# algorithm, as described in Section 4.3.2. Note that this relaxes -# the constraints on certificate-signing algorithms found in prior -# versions of TLS. +# - The certificates MUST be signed using an acceptable signature +# algorithm, as described in Section 4.3.2. Note that this relaxes +# the constraints on certificate-signing algorithms found in prior +# versions of TLS. # -# - If the CertificateRequest message contained a non-empty -# "oid_filters" extension, the end-entity certificate MUST match the -# extension OIDs that are recognized by the client, as described in -# Section 4.2.5. +# - If the CertificateRequest message contained a non-empty +# "oid_filters" extension, the end-entity certificate MUST match the +# extension OIDs that are recognized by the client, as described in +# Section 4.2.5. [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.4.2.4.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.4.2.4.toml index 97bca4ce233..67b3fec0cdd 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.4.2.4.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.4.2.4.toml @@ -1,39 +1,39 @@ target = "https://www.rfc-editor.org/rfc/rfc8446#section-4.4.2.4" -# 4.4.2.4. Receiving a Certificate Message +# Receiving a Certificate Message # -# In general, detailed certificate validation procedures are out of -# scope for TLS (see [RFC5280]). This section provides TLS-specific -# requirements. +# In general, detailed certificate validation procedures are out of +# scope for TLS (see [RFC5280]). This section provides TLS-specific +# requirements. # -# If the server supplies an empty Certificate message, the client MUST -# abort the handshake with a "decode_error" alert. +# If the server supplies an empty Certificate message, the client MUST +# abort the handshake with a "decode_error" alert. # -# If the client does not send any certificates (i.e., it sends an empty -# Certificate message), the server MAY at its discretion either -# continue the handshake without client authentication or abort the -# handshake with a "certificate_required" alert. Also, if some aspect -# of the certificate chain was unacceptable (e.g., it was not signed by -# a known, trusted CA), the server MAY at its discretion either -# continue the handshake (considering the client unauthenticated) or -# abort the handshake. +# If the client does not send any certificates (i.e., it sends an empty +# Certificate message), the server MAY at its discretion either +# continue the handshake without client authentication or abort the +# handshake with a "certificate_required" alert. Also, if some aspect +# of the certificate chain was unacceptable (e.g., it was not signed by +# a known, trusted CA), the server MAY at its discretion either +# continue the handshake (considering the client unauthenticated) or +# abort the handshake. # -# Any endpoint receiving any certificate which it would need to -# validate using any signature algorithm using an MD5 hash MUST abort -# the handshake with a "bad_certificate" alert. SHA-1 is deprecated, -# and it is RECOMMENDED that any endpoint receiving any certificate -# which it would need to validate using any signature algorithm using a -# SHA-1 hash abort the handshake with a "bad_certificate" alert. For -# clarity, this means that endpoints can accept these algorithms for -# certificates that are self-signed or are trust anchors. +# Any endpoint receiving any certificate which it would need to +# validate using any signature algorithm using an MD5 hash MUST abort +# the handshake with a "bad_certificate" alert. SHA-1 is deprecated, +# and it is RECOMMENDED that any endpoint receiving any certificate +# which it would need to validate using any signature algorithm using a +# SHA-1 hash abort the handshake with a "bad_certificate" alert. For +# clarity, this means that endpoints can accept these algorithms for +# certificates that are self-signed or are trust anchors. # -# All endpoints are RECOMMENDED to transition to SHA-256 or better as -# soon as possible to maintain interoperability with implementations -# currently in the process of phasing out SHA-1 support. +# All endpoints are RECOMMENDED to transition to SHA-256 or better as +# soon as possible to maintain interoperability with implementations +# currently in the process of phasing out SHA-1 support. # -# Note that a certificate containing a key for one signature algorithm -# MAY be signed using a different signature algorithm (for instance, an -# RSA key signed with an ECDSA key). +# Note that a certificate containing a key for one signature algorithm +# MAY be signed using a different signature algorithm (for instance, an +# RSA key signed with an ECDSA key). [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.4.2.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.4.2.toml index 4a33085c851..3df1c97ea79 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.4.2.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.4.2.toml @@ -1,101 +1,101 @@ target = "https://www.rfc-editor.org/rfc/rfc8446#section-4.4.2" -# 4.4.2. Certificate +# Certificate # -# This message conveys the endpoint's certificate chain to the peer. +# This message conveys the endpoint's certificate chain to the peer. # -# The server MUST send a Certificate message whenever the agreed-upon -# key exchange method uses certificates for authentication (this -# includes all key exchange methods defined in this document -# except PSK). +# The server MUST send a Certificate message whenever the agreed-upon +# key exchange method uses certificates for authentication (this +# includes all key exchange methods defined in this document +# except PSK). # -# The client MUST send a Certificate message if and only if the server -# has requested client authentication via a CertificateRequest message -# (Section 4.3.2). If the server requests client authentication but no -# suitable certificate is available, the client MUST send a Certificate -# message containing no certificates (i.e., with the "certificate_list" -# field having length 0). A Finished message MUST be sent regardless -# of whether the Certificate message is empty. +# The client MUST send a Certificate message if and only if the server +# has requested client authentication via a CertificateRequest message +# (Section 4.3.2). If the server requests client authentication but no +# suitable certificate is available, the client MUST send a Certificate +# message containing no certificates (i.e., with the "certificate_list" +# field having length 0). A Finished message MUST be sent regardless +# of whether the Certificate message is empty. # -# Structure of this message: +# Structure of this message: # -# enum { -# X509(0), -# RawPublicKey(2), -# (255) -# } CertificateType; +# enum { +# X509(0), +# RawPublicKey(2), +# (255) +# } CertificateType; # -# struct { -# select (certificate_type) { -# case RawPublicKey: -# /* From RFC 7250 ASN.1_subjectPublicKeyInfo */ -# opaque ASN1_subjectPublicKeyInfo<1..2^24-1>; +# struct { +# select (certificate_type) { +# case RawPublicKey: +# /* From RFC 7250 ASN.1_subjectPublicKeyInfo */ +# opaque ASN1_subjectPublicKeyInfo<1..2^24-1>; # -# case X509: -# opaque cert_data<1..2^24-1>; -# }; -# Extension extensions<0..2^16-1>; -# } CertificateEntry; +# case X509: +# opaque cert_data<1..2^24-1>; +# }; +# Extension extensions<0..2^16-1>; +# } CertificateEntry; # -# struct { -# opaque certificate_request_context<0..2^8-1>; -# CertificateEntry certificate_list<0..2^24-1>; -# } Certificate; +# struct { +# opaque certificate_request_context<0..2^8-1>; +# CertificateEntry certificate_list<0..2^24-1>; +# } Certificate; # -# certificate_request_context: If this message is in response to a -# CertificateRequest, the value of certificate_request_context in -# that message. Otherwise (in the case of server authentication), -# this field SHALL be zero length. +# certificate_request_context: If this message is in response to a +# CertificateRequest, the value of certificate_request_context in +# that message. Otherwise (in the case of server authentication), +# this field SHALL be zero length. # -# certificate_list: A sequence (chain) of CertificateEntry structures, -# each containing a single certificate and set of extensions. +# certificate_list: A sequence (chain) of CertificateEntry structures, +# each containing a single certificate and set of extensions. # -# extensions: A set of extension values for the CertificateEntry. The -# "Extension" format is defined in Section 4.2. Valid extensions -# for server certificates at present include the OCSP Status -# extension [RFC6066] and the SignedCertificateTimestamp extension -# [RFC6962]; future extensions may be defined for this message as -# well. Extensions in the Certificate message from the server MUST -# correspond to ones from the ClientHello message. Extensions in -# the Certificate message from the client MUST correspond to -# extensions in the CertificateRequest message from the server. If -# an extension applies to the entire chain, it SHOULD be included in -# the first CertificateEntry. +# extensions: A set of extension values for the CertificateEntry. The +# "Extension" format is defined in Section 4.2. Valid extensions +# for server certificates at present include the OCSP Status +# extension [RFC6066] and the SignedCertificateTimestamp extension +# [RFC6962]; future extensions may be defined for this message as +# well. Extensions in the Certificate message from the server MUST +# correspond to ones from the ClientHello message. Extensions in +# the Certificate message from the client MUST correspond to +# extensions in the CertificateRequest message from the server. If +# an extension applies to the entire chain, it SHOULD be included in +# the first CertificateEntry. # -# If the corresponding certificate type extension -# ("server_certificate_type" or "client_certificate_type") was not -# negotiated in EncryptedExtensions, or the X.509 certificate type was -# negotiated, then each CertificateEntry contains a DER-encoded X.509 -# certificate. The sender's certificate MUST come in the first -# CertificateEntry in the list. Each following certificate SHOULD -# directly certify the one immediately preceding it. Because -# certificate validation requires that trust anchors be distributed -# independently, a certificate that specifies a trust anchor MAY be -# omitted from the chain, provided that supported peers are known to -# possess any omitted certificates. +# If the corresponding certificate type extension +# ("server_certificate_type" or "client_certificate_type") was not +# negotiated in EncryptedExtensions, or the X.509 certificate type was +# negotiated, then each CertificateEntry contains a DER-encoded X.509 +# certificate. The sender's certificate MUST come in the first +# CertificateEntry in the list. Each following certificate SHOULD +# directly certify the one immediately preceding it. Because +# certificate validation requires that trust anchors be distributed +# independently, a certificate that specifies a trust anchor MAY be +# omitted from the chain, provided that supported peers are known to +# possess any omitted certificates. # -# Note: Prior to TLS 1.3, "certificate_list" ordering required each -# certificate to certify the one immediately preceding it; however, -# some implementations allowed some flexibility. Servers sometimes -# send both a current and deprecated intermediate for transitional -# purposes, and others are simply configured incorrectly, but these -# cases can nonetheless be validated properly. For maximum -# compatibility, all implementations SHOULD be prepared to handle -# potentially extraneous certificates and arbitrary orderings from any -# TLS version, with the exception of the end-entity certificate which -# MUST be first. +# Note: Prior to TLS 1.3, "certificate_list" ordering required each +# certificate to certify the one immediately preceding it; however, +# some implementations allowed some flexibility. Servers sometimes +# send both a current and deprecated intermediate for transitional +# purposes, and others are simply configured incorrectly, but these +# cases can nonetheless be validated properly. For maximum +# compatibility, all implementations SHOULD be prepared to handle +# potentially extraneous certificates and arbitrary orderings from any +# TLS version, with the exception of the end-entity certificate which +# MUST be first. # -# If the RawPublicKey certificate type was negotiated, then the -# certificate_list MUST contain no more than one CertificateEntry, -# which contains an ASN1_subjectPublicKeyInfo value as defined in -# [RFC7250], Section 3. +# If the RawPublicKey certificate type was negotiated, then the +# certificate_list MUST contain no more than one CertificateEntry, +# which contains an ASN1_subjectPublicKeyInfo value as defined in +# [RFC7250], Section 3. # -# The OpenPGP certificate type [RFC6091] MUST NOT be used with TLS 1.3. +# The OpenPGP certificate type [RFC6091] MUST NOT be used with TLS 1.3. # -# The server's certificate_list MUST always be non-empty. A client -# will send an empty certificate_list if it does not have an -# appropriate certificate to send in response to the server's -# authentication request. +# The server's certificate_list MUST always be non-empty. A client +# will send an empty certificate_list if it does not have an +# appropriate certificate to send in response to the server's +# authentication request. [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.4.3.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.4.3.toml index 0c7666af322..40eff68849a 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.4.3.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.4.3.toml @@ -1,106 +1,106 @@ target = "https://www.rfc-editor.org/rfc/rfc8446#section-4.4.3" -# 4.4.3. Certificate Verify +# Certificate Verify # -# This message is used to provide explicit proof that an endpoint -# possesses the private key corresponding to its certificate. The -# CertificateVerify message also provides integrity for the handshake -# up to this point. Servers MUST send this message when authenticating -# via a certificate. Clients MUST send this message whenever -# authenticating via a certificate (i.e., when the Certificate message -# is non-empty). When sent, this message MUST appear immediately after -# the Certificate message and immediately prior to the Finished -# message. +# This message is used to provide explicit proof that an endpoint +# possesses the private key corresponding to its certificate. The +# CertificateVerify message also provides integrity for the handshake +# up to this point. Servers MUST send this message when authenticating +# via a certificate. Clients MUST send this message whenever +# authenticating via a certificate (i.e., when the Certificate message +# is non-empty). When sent, this message MUST appear immediately after +# the Certificate message and immediately prior to the Finished +# message. # -# Structure of this message: +# Structure of this message: # -# struct { -# SignatureScheme algorithm; -# opaque signature<0..2^16-1>; -# } CertificateVerify; +# struct { +# SignatureScheme algorithm; +# opaque signature<0..2^16-1>; +# } CertificateVerify; # -# The algorithm field specifies the signature algorithm used (see -# Section 4.2.3 for the definition of this type). The signature is a -# digital signature using that algorithm. The content that is covered -# under the signature is the hash output as described in Section 4.4.1, -# namely: +# The algorithm field specifies the signature algorithm used (see +# Section 4.2.3 for the definition of this type). The signature is a +# digital signature using that algorithm. The content that is covered +# under the signature is the hash output as described in Section 4.4.1, +# namely: # -# Transcript-Hash(Handshake Context, Certificate) +# Transcript-Hash(Handshake Context, Certificate) # -# The digital signature is then computed over the concatenation of: +# The digital signature is then computed over the concatenation of: # -# - A string that consists of octet 32 (0x20) repeated 64 times +# - A string that consists of octet 32 (0x20) repeated 64 times # -# - The context string +# - The context string # -# - A single 0 byte which serves as the separator +# - A single 0 byte which serves as the separator # -# - The content to be signed +# - The content to be signed # -# This structure is intended to prevent an attack on previous versions -# of TLS in which the ServerKeyExchange format meant that attackers -# could obtain a signature of a message with a chosen 32-byte prefix -# (ClientHello.random). The initial 64-byte pad clears that prefix -# along with the server-controlled ServerHello.random. +# This structure is intended to prevent an attack on previous versions +# of TLS in which the ServerKeyExchange format meant that attackers +# could obtain a signature of a message with a chosen 32-byte prefix +# (ClientHello.random). The initial 64-byte pad clears that prefix +# along with the server-controlled ServerHello.random. # -# The context string for a server signature is -# "TLS 1.3, server CertificateVerify". The context string for a -# client signature is "TLS 1.3, client CertificateVerify". It is -# used to provide separation between signatures made in different -# contexts, helping against potential cross-protocol attacks. +# The context string for a server signature is +# "TLS 1.3, server CertificateVerify". The context string for a +# client signature is "TLS 1.3, client CertificateVerify". It is +# used to provide separation between signatures made in different +# contexts, helping against potential cross-protocol attacks. # -# For example, if the transcript hash was 32 bytes of 01 (this length -# would make sense for SHA-256), the content covered by the digital -# signature for a server CertificateVerify would be: +# For example, if the transcript hash was 32 bytes of 01 (this length +# would make sense for SHA-256), the content covered by the digital +# signature for a server CertificateVerify would be: # -# 2020202020202020202020202020202020202020202020202020202020202020 -# 2020202020202020202020202020202020202020202020202020202020202020 -# 544c5320312e332c207365727665722043657274696669636174655665726966 -# 79 -# 00 -# 0101010101010101010101010101010101010101010101010101010101010101 +# 2020202020202020202020202020202020202020202020202020202020202020 +# 2020202020202020202020202020202020202020202020202020202020202020 +# 544c5320312e332c207365727665722043657274696669636174655665726966 +# 79 +# 00 +# 0101010101010101010101010101010101010101010101010101010101010101 # -# On the sender side, the process for computing the signature field of -# the CertificateVerify message takes as input: +# On the sender side, the process for computing the signature field of +# the CertificateVerify message takes as input: # -# - The content covered by the digital signature +# - The content covered by the digital signature # -# - The private signing key corresponding to the certificate sent in -# the previous message +# - The private signing key corresponding to the certificate sent in +# the previous message # -# If the CertificateVerify message is sent by a server, the signature -# algorithm MUST be one offered in the client's "signature_algorithms" -# extension unless no valid certificate chain can be produced without -# unsupported algorithms (see Section 4.2.3). +# If the CertificateVerify message is sent by a server, the signature +# algorithm MUST be one offered in the client's "signature_algorithms" +# extension unless no valid certificate chain can be produced without +# unsupported algorithms (see Section 4.2.3). # -# If sent by a client, the signature algorithm used in the signature -# MUST be one of those present in the supported_signature_algorithms -# field of the "signature_algorithms" extension in the -# CertificateRequest message. +# If sent by a client, the signature algorithm used in the signature +# MUST be one of those present in the supported_signature_algorithms +# field of the "signature_algorithms" extension in the +# CertificateRequest message. # -# In addition, the signature algorithm MUST be compatible with the key -# in the sender's end-entity certificate. RSA signatures MUST use an -# RSASSA-PSS algorithm, regardless of whether RSASSA-PKCS1-v1_5 -# algorithms appear in "signature_algorithms". The SHA-1 algorithm -# MUST NOT be used in any signatures of CertificateVerify messages. +# In addition, the signature algorithm MUST be compatible with the key +# in the sender's end-entity certificate. RSA signatures MUST use an +# RSASSA-PSS algorithm, regardless of whether RSASSA-PKCS1-v1_5 +# algorithms appear in "signature_algorithms". The SHA-1 algorithm +# MUST NOT be used in any signatures of CertificateVerify messages. # -# All SHA-1 signature algorithms in this specification are defined -# solely for use in legacy certificates and are not valid for -# CertificateVerify signatures. +# All SHA-1 signature algorithms in this specification are defined +# solely for use in legacy certificates and are not valid for +# CertificateVerify signatures. # -# The receiver of a CertificateVerify message MUST verify the signature -# field. The verification process takes as input: +# The receiver of a CertificateVerify message MUST verify the signature +# field. The verification process takes as input: # -# - The content covered by the digital signature +# - The content covered by the digital signature # -# - The public key contained in the end-entity certificate found in -# the associated Certificate message +# - The public key contained in the end-entity certificate found in +# the associated Certificate message # -# - The digital signature received in the signature field of the -# CertificateVerify message +# - The digital signature received in the signature field of the +# CertificateVerify message # -# If the verification fails, the receiver MUST terminate the handshake -# with a "decrypt_error" alert. +# If the verification fails, the receiver MUST terminate the handshake +# with a "decrypt_error" alert. [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.4.4.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.4.4.toml index 91b9feaeda5..3e0557a6c60 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.4.4.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.4.4.toml @@ -1,65 +1,65 @@ target = "https://www.rfc-editor.org/rfc/rfc8446#section-4.4.4" -# 4.4.4. Finished +# Finished # -# The Finished message is the final message in the Authentication -# Block. It is essential for providing authentication of the handshake -# and of the computed keys. +# The Finished message is the final message in the Authentication +# Block. It is essential for providing authentication of the handshake +# and of the computed keys. # -# Recipients of Finished messages MUST verify that the contents are -# correct and if incorrect MUST terminate the connection with a -# "decrypt_error" alert. +# Recipients of Finished messages MUST verify that the contents are +# correct and if incorrect MUST terminate the connection with a +# "decrypt_error" alert. # -# Once a side has sent its Finished message and has received and -# validated the Finished message from its peer, it may begin to send -# and receive Application Data over the connection. There are two -# settings in which it is permitted to send data prior to receiving the -# peer's Finished: +# Once a side has sent its Finished message and has received and +# validated the Finished message from its peer, it may begin to send +# and receive Application Data over the connection. There are two +# settings in which it is permitted to send data prior to receiving the +# peer's Finished: # -# 1. Clients sending 0-RTT data as described in Section 4.2.10. +# 1. Clients sending 0-RTT data as described in Section 4.2.10. # -# 2. Servers MAY send data after sending their first flight, but -# because the handshake is not yet complete, they have no assurance -# of either the peer's identity or its liveness (i.e., the -# ClientHello might have been replayed). +# 2. Servers MAY send data after sending their first flight, but +# because the handshake is not yet complete, they have no assurance +# of either the peer's identity or its liveness (i.e., the +# ClientHello might have been replayed). # -# The key used to compute the Finished message is computed from the -# Base Key defined in Section 4.4 using HKDF (see Section 7.1). -# Specifically: +# The key used to compute the Finished message is computed from the +# Base Key defined in Section 4.4 using HKDF (see Section 7.1). +# Specifically: # -# finished_key = -# HKDF-Expand-Label(BaseKey, "finished", "", Hash.length) +# finished_key = +# HKDF-Expand-Label(BaseKey, "finished", "", Hash.length) # -# Structure of this message: +# Structure of this message: # -# struct { -# opaque verify_data[Hash.length]; -# } Finished; +# struct { +# opaque verify_data[Hash.length]; +# } Finished; # -# The verify_data value is computed as follows: +# The verify_data value is computed as follows: # -# verify_data = -# HMAC(finished_key, -# Transcript-Hash(Handshake Context, -# Certificate*, CertificateVerify*)) +# verify_data = +# HMAC(finished_key, +# Transcript-Hash(Handshake Context, +# Certificate*, CertificateVerify*)) # -# * Only included if present. +# * Only included if present. # -# HMAC [RFC2104] uses the Hash algorithm for the handshake. As noted -# above, the HMAC input can generally be implemented by a running hash, -# i.e., just the handshake hash at this point. +# HMAC [RFC2104] uses the Hash algorithm for the handshake. As noted +# above, the HMAC input can generally be implemented by a running hash, +# i.e., just the handshake hash at this point. # -# In previous versions of TLS, the verify_data was always 12 octets -# long. In TLS 1.3, it is the size of the HMAC output for the Hash -# used for the handshake. +# In previous versions of TLS, the verify_data was always 12 octets +# long. In TLS 1.3, it is the size of the HMAC output for the Hash +# used for the handshake. # -# Note: Alerts and any other non-handshake record types are not -# handshake messages and are not included in the hash computations. +# Note: Alerts and any other non-handshake record types are not +# handshake messages and are not included in the hash computations. # -# Any records following a Finished message MUST be encrypted under the -# appropriate application traffic key as described in Section 7.2. In -# particular, this includes any alerts sent by the server in response -# to client Certificate and CertificateVerify messages. +# Any records following a Finished message MUST be encrypted under the +# appropriate application traffic key as described in Section 7.2. In +# particular, this includes any alerts sent by the server in response +# to client Certificate and CertificateVerify messages. [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.5.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.5.toml index c4089115d2f..c84f988c217 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.5.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.5.toml @@ -1,21 +1,21 @@ target = "https://www.rfc-editor.org/rfc/rfc8446#section-4.5" -# 4.5. End of Early Data +# End of Early Data # -# struct {} EndOfEarlyData; +# struct {} EndOfEarlyData; # -# If the server sent an "early_data" extension in EncryptedExtensions, -# the client MUST send an EndOfEarlyData message after receiving the -# server Finished. If the server does not send an "early_data" -# extension in EncryptedExtensions, then the client MUST NOT send an -# EndOfEarlyData message. This message indicates that all 0-RTT -# application_data messages, if any, have been transmitted and that the +# If the server sent an "early_data" extension in EncryptedExtensions, +# the client MUST send an EndOfEarlyData message after receiving the +# server Finished. If the server does not send an "early_data" +# extension in EncryptedExtensions, then the client MUST NOT send an +# EndOfEarlyData message. This message indicates that all 0-RTT +# application_data messages, if any, have been transmitted and that the # -# following records are protected under handshake traffic keys. -# Servers MUST NOT send this message, and clients receiving it MUST -# terminate the connection with an "unexpected_message" alert. This -# message is encrypted under keys derived from the -# client_early_traffic_secret. +# following records are protected under handshake traffic keys. +# Servers MUST NOT send this message, and clients receiving it MUST +# terminate the connection with an "unexpected_message" alert. This +# message is encrypted under keys derived from the +# client_early_traffic_secret. [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.6.1.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.6.1.toml index 23fc9a38181..def94b28990 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.6.1.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.6.1.toml @@ -1,122 +1,122 @@ target = "https://www.rfc-editor.org/rfc/rfc8446#section-4.6.1" -# 4.6.1. New Session Ticket Message +# New Session Ticket Message # -# At any time after the server has received the client Finished -# message, it MAY send a NewSessionTicket message. This message -# creates a unique association between the ticket value and a secret -# PSK derived from the resumption master secret (see Section 7). +# At any time after the server has received the client Finished +# message, it MAY send a NewSessionTicket message. This message +# creates a unique association between the ticket value and a secret +# PSK derived from the resumption master secret (see Section 7). # -# The client MAY use this PSK for future handshakes by including the -# ticket value in the "pre_shared_key" extension in its ClientHello -# (Section 4.2.11). Servers MAY send multiple tickets on a single -# connection, either immediately after each other or after specific -# events (see Appendix C.4). For instance, the server might send a new -# ticket after post-handshake authentication in order to encapsulate -# the additional client authentication state. Multiple tickets are -# useful for clients for a variety of purposes, including: +# The client MAY use this PSK for future handshakes by including the +# ticket value in the "pre_shared_key" extension in its ClientHello +# (Section 4.2.11). Servers MAY send multiple tickets on a single +# connection, either immediately after each other or after specific +# events (see Appendix C.4). For instance, the server might send a new +# ticket after post-handshake authentication in order to encapsulate +# the additional client authentication state. Multiple tickets are +# useful for clients for a variety of purposes, including: # -# - Opening multiple parallel HTTP connections. +# - Opening multiple parallel HTTP connections. # -# - Performing connection racing across interfaces and address -# families via (for example) Happy Eyeballs [RFC8305] or related -# techniques. +# - Performing connection racing across interfaces and address +# families via (for example) Happy Eyeballs [RFC8305] or related +# techniques. # -# Any ticket MUST only be resumed with a cipher suite that has the same -# KDF hash algorithm as that used to establish the original connection. +# Any ticket MUST only be resumed with a cipher suite that has the same +# KDF hash algorithm as that used to establish the original connection. # -# Clients MUST only resume if the new SNI value is valid for the server -# certificate presented in the original session and SHOULD only resume -# if the SNI value matches the one used in the original session. The -# latter is a performance optimization: normally, there is no reason to -# expect that different servers covered by a single certificate would -# be able to accept each other's tickets; hence, attempting resumption -# in that case would waste a single-use ticket. If such an indication -# is provided (externally or by any other means), clients MAY resume -# with a different SNI value. +# Clients MUST only resume if the new SNI value is valid for the server +# certificate presented in the original session and SHOULD only resume +# if the SNI value matches the one used in the original session. The +# latter is a performance optimization: normally, there is no reason to +# expect that different servers covered by a single certificate would +# be able to accept each other's tickets; hence, attempting resumption +# in that case would waste a single-use ticket. If such an indication +# is provided (externally or by any other means), clients MAY resume +# with a different SNI value. # -# On resumption, if reporting an SNI value to the calling application, -# implementations MUST use the value sent in the resumption ClientHello -# rather than the value sent in the previous session. Note that if a -# server implementation declines all PSK identities with different SNI -# values, these two values are always the same. +# On resumption, if reporting an SNI value to the calling application, +# implementations MUST use the value sent in the resumption ClientHello +# rather than the value sent in the previous session. Note that if a +# server implementation declines all PSK identities with different SNI +# values, these two values are always the same. # -# Note: Although the resumption master secret depends on the client's -# second flight, a server which does not request client authentication -# MAY compute the remainder of the transcript independently and then -# send a NewSessionTicket immediately upon sending its Finished rather -# than waiting for the client Finished. This might be appropriate in -# cases where the client is expected to open multiple TLS connections -# in parallel and would benefit from the reduced overhead of a -# resumption handshake, for example. +# Note: Although the resumption master secret depends on the client's +# second flight, a server which does not request client authentication +# MAY compute the remainder of the transcript independently and then +# send a NewSessionTicket immediately upon sending its Finished rather +# than waiting for the client Finished. This might be appropriate in +# cases where the client is expected to open multiple TLS connections +# in parallel and would benefit from the reduced overhead of a +# resumption handshake, for example. # -# struct { -# uint32 ticket_lifetime; -# uint32 ticket_age_add; -# opaque ticket_nonce<0..255>; -# opaque ticket<1..2^16-1>; -# Extension extensions<0..2^16-2>; -# } NewSessionTicket; +# struct { +# uint32 ticket_lifetime; +# uint32 ticket_age_add; +# opaque ticket_nonce<0..255>; +# opaque ticket<1..2^16-1>; +# Extension extensions<0..2^16-2>; +# } NewSessionTicket; # -# ticket_lifetime: Indicates the lifetime in seconds as a 32-bit -# unsigned integer in network byte order from the time of ticket -# issuance. Servers MUST NOT use any value greater than -# 604800 seconds (7 days). The value of zero indicates that the -# ticket should be discarded immediately. Clients MUST NOT cache -# tickets for longer than 7 days, regardless of the ticket_lifetime, -# and MAY delete tickets earlier based on local policy. A server -# MAY treat a ticket as valid for a shorter period of time than what -# is stated in the ticket_lifetime. +# ticket_lifetime: Indicates the lifetime in seconds as a 32-bit +# unsigned integer in network byte order from the time of ticket +# issuance. Servers MUST NOT use any value greater than +# 604800 seconds (7 days). The value of zero indicates that the +# ticket should be discarded immediately. Clients MUST NOT cache +# tickets for longer than 7 days, regardless of the ticket_lifetime, +# and MAY delete tickets earlier based on local policy. A server +# MAY treat a ticket as valid for a shorter period of time than what +# is stated in the ticket_lifetime. # -# ticket_age_add: A securely generated, random 32-bit value that is -# used to obscure the age of the ticket that the client includes in -# the "pre_shared_key" extension. The client-side ticket age is -# added to this value modulo 2^32 to obtain the value that is -# transmitted by the client. The server MUST generate a fresh value -# for each ticket it sends. +# ticket_age_add: A securely generated, random 32-bit value that is +# used to obscure the age of the ticket that the client includes in +# the "pre_shared_key" extension. The client-side ticket age is +# added to this value modulo 2^32 to obtain the value that is +# transmitted by the client. The server MUST generate a fresh value +# for each ticket it sends. # -# ticket_nonce: A per-ticket value that is unique across all tickets -# issued on this connection. +# ticket_nonce: A per-ticket value that is unique across all tickets +# issued on this connection. # -# ticket: The value of the ticket to be used as the PSK identity. The -# ticket itself is an opaque label. It MAY be either a database -# lookup key or a self-encrypted and self-authenticated value. +# ticket: The value of the ticket to be used as the PSK identity. The +# ticket itself is an opaque label. It MAY be either a database +# lookup key or a self-encrypted and self-authenticated value. # -# extensions: A set of extension values for the ticket. The -# "Extension" format is defined in Section 4.2. Clients MUST ignore -# unrecognized extensions. +# extensions: A set of extension values for the ticket. The +# "Extension" format is defined in Section 4.2. Clients MUST ignore +# unrecognized extensions. # -# The sole extension currently defined for NewSessionTicket is -# "early_data", indicating that the ticket may be used to send 0-RTT -# data (Section 4.2.10). It contains the following value: +# The sole extension currently defined for NewSessionTicket is +# "early_data", indicating that the ticket may be used to send 0-RTT +# data (Section 4.2.10). It contains the following value: # -# max_early_data_size: The maximum amount of 0-RTT data that the -# client is allowed to send when using this ticket, in bytes. Only -# Application Data payload (i.e., plaintext but not padding or the -# inner content type byte) is counted. A server receiving more than -# max_early_data_size bytes of 0-RTT data SHOULD terminate the -# connection with an "unexpected_message" alert. Note that servers -# that reject early data due to lack of cryptographic material will -# be unable to differentiate padding from content, so clients -# SHOULD NOT depend on being able to send large quantities of -# padding in early data records. +# max_early_data_size: The maximum amount of 0-RTT data that the +# client is allowed to send when using this ticket, in bytes. Only +# Application Data payload (i.e., plaintext but not padding or the +# inner content type byte) is counted. A server receiving more than +# max_early_data_size bytes of 0-RTT data SHOULD terminate the +# connection with an "unexpected_message" alert. Note that servers +# that reject early data due to lack of cryptographic material will +# be unable to differentiate padding from content, so clients +# SHOULD NOT depend on being able to send large quantities of +# padding in early data records. # -# The PSK associated with the ticket is computed as: +# The PSK associated with the ticket is computed as: # -# HKDF-Expand-Label(resumption_master_secret, -# "resumption", ticket_nonce, Hash.length) +# HKDF-Expand-Label(resumption_master_secret, +# "resumption", ticket_nonce, Hash.length) # -# Because the ticket_nonce value is distinct for each NewSessionTicket -# message, a different PSK will be derived for each ticket. +# Because the ticket_nonce value is distinct for each NewSessionTicket +# message, a different PSK will be derived for each ticket. # -# Note that in principle it is possible to continue issuing new tickets -# which indefinitely extend the lifetime of the keying material -# originally derived from an initial non-PSK handshake (which was most -# likely tied to the peer's certificate). It is RECOMMENDED that -# implementations place limits on the total lifetime of such keying -# material; these limits should take into account the lifetime of the -# peer's certificate, the likelihood of intervening revocation, and the -# time since the peer's online CertificateVerify signature. +# Note that in principle it is possible to continue issuing new tickets +# which indefinitely extend the lifetime of the keying material +# originally derived from an initial non-PSK handshake (which was most +# likely tied to the peer's certificate). It is RECOMMENDED that +# implementations place limits on the total lifetime of such keying +# material; these limits should take into account the lifetime of the +# peer's certificate, the likelihood of intervening revocation, and the +# time since the peer's online CertificateVerify signature. [[spec]] level = "MAY" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.6.2.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.6.2.toml index e3cde83a3c8..f58485ac6b4 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.6.2.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.6.2.toml @@ -1,31 +1,31 @@ target = "https://www.rfc-editor.org/rfc/rfc8446#section-4.6.2" -# 4.6.2. Post-Handshake Authentication +# Post-Handshake Authentication # -# When the client has sent the "post_handshake_auth" extension (see -# Section 4.2.6), a server MAY request client authentication at any -# time after the handshake has completed by sending a -# CertificateRequest message. The client MUST respond with the -# appropriate Authentication messages (see Section 4.4). If the client -# chooses to authenticate, it MUST send Certificate, CertificateVerify, +# When the client has sent the "post_handshake_auth" extension (see +# Section 4.2.6), a server MAY request client authentication at any +# time after the handshake has completed by sending a +# CertificateRequest message. The client MUST respond with the +# appropriate Authentication messages (see Section 4.4). If the client +# chooses to authenticate, it MUST send Certificate, CertificateVerify, # -# and Finished. If it declines, it MUST send a Certificate message -# containing no certificates followed by Finished. All of the client's -# messages for a given response MUST appear consecutively on the wire -# with no intervening messages of other types. +# and Finished. If it declines, it MUST send a Certificate message +# containing no certificates followed by Finished. All of the client's +# messages for a given response MUST appear consecutively on the wire +# with no intervening messages of other types. # -# A client that receives a CertificateRequest message without having -# sent the "post_handshake_auth" extension MUST send an -# "unexpected_message" fatal alert. +# A client that receives a CertificateRequest message without having +# sent the "post_handshake_auth" extension MUST send an +# "unexpected_message" fatal alert. # -# Note: Because client authentication could involve prompting the user, -# servers MUST be prepared for some delay, including receiving an -# arbitrary number of other messages between sending the -# CertificateRequest and receiving a response. In addition, clients -# which receive multiple CertificateRequests in close succession MAY -# respond to them in a different order than they were received (the -# certificate_request_context value allows the server to disambiguate -# the responses). +# Note: Because client authentication could involve prompting the user, +# servers MUST be prepared for some delay, including receiving an +# arbitrary number of other messages between sending the +# CertificateRequest and receiving a response. In addition, clients +# which receive multiple CertificateRequests in close succession MAY +# respond to them in a different order than they were received (the +# certificate_request_context value allows the server to disambiguate +# the responses). [[spec]] level = "MAY" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.6.3.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.6.3.toml index 23db9c5ef70..80f67a38d6a 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.6.3.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.6.3.toml @@ -1,55 +1,55 @@ target = "https://www.rfc-editor.org/rfc/rfc8446#section-4.6.3" -# 4.6.3. Key and Initialization Vector Update +# Key and Initialization Vector Update # -# The KeyUpdate handshake message is used to indicate that the sender -# is updating its sending cryptographic keys. This message can be sent -# by either peer after it has sent a Finished message. Implementations -# that receive a KeyUpdate message prior to receiving a Finished -# message MUST terminate the connection with an "unexpected_message" -# alert. After sending a KeyUpdate message, the sender SHALL send all -# its traffic using the next generation of keys, computed as described -# in Section 7.2. Upon receiving a KeyUpdate, the receiver MUST update -# its receiving keys. +# The KeyUpdate handshake message is used to indicate that the sender +# is updating its sending cryptographic keys. This message can be sent +# by either peer after it has sent a Finished message. Implementations +# that receive a KeyUpdate message prior to receiving a Finished +# message MUST terminate the connection with an "unexpected_message" +# alert. After sending a KeyUpdate message, the sender SHALL send all +# its traffic using the next generation of keys, computed as described +# in Section 7.2. Upon receiving a KeyUpdate, the receiver MUST update +# its receiving keys. # -# enum { -# update_not_requested(0), update_requested(1), (255) -# } KeyUpdateRequest; +# enum { +# update_not_requested(0), update_requested(1), (255) +# } KeyUpdateRequest; # -# struct { -# KeyUpdateRequest request_update; -# } KeyUpdate; +# struct { +# KeyUpdateRequest request_update; +# } KeyUpdate; # -# request_update: Indicates whether the recipient of the KeyUpdate -# should respond with its own KeyUpdate. If an implementation -# receives any other value, it MUST terminate the connection with an -# "illegal_parameter" alert. +# request_update: Indicates whether the recipient of the KeyUpdate +# should respond with its own KeyUpdate. If an implementation +# receives any other value, it MUST terminate the connection with an +# "illegal_parameter" alert. # -# If the request_update field is set to "update_requested", then the -# receiver MUST send a KeyUpdate of its own with request_update set to -# "update_not_requested" prior to sending its next Application Data -# record. This mechanism allows either side to force an update to the -# entire connection, but causes an implementation which receives +# If the request_update field is set to "update_requested", then the +# receiver MUST send a KeyUpdate of its own with request_update set to +# "update_not_requested" prior to sending its next Application Data +# record. This mechanism allows either side to force an update to the +# entire connection, but causes an implementation which receives # -# multiple KeyUpdates while it is silent to respond with a single -# update. Note that implementations may receive an arbitrary number of -# messages between sending a KeyUpdate with request_update set to -# "update_requested" and receiving the peer's KeyUpdate, because those -# messages may already be in flight. However, because send and receive -# keys are derived from independent traffic secrets, retaining the -# receive traffic secret does not threaten the forward secrecy of data -# sent before the sender changed keys. +# multiple KeyUpdates while it is silent to respond with a single +# update. Note that implementations may receive an arbitrary number of +# messages between sending a KeyUpdate with request_update set to +# "update_requested" and receiving the peer's KeyUpdate, because those +# messages may already be in flight. However, because send and receive +# keys are derived from independent traffic secrets, retaining the +# receive traffic secret does not threaten the forward secrecy of data +# sent before the sender changed keys. # -# If implementations independently send their own KeyUpdates with -# request_update set to "update_requested" and they cross in flight, -# then each side will also send a response, with the result that each -# side increments by two generations. +# If implementations independently send their own KeyUpdates with +# request_update set to "update_requested" and they cross in flight, +# then each side will also send a response, with the result that each +# side increments by two generations. # -# Both sender and receiver MUST encrypt their KeyUpdate messages with -# the old keys. Additionally, both sides MUST enforce that a KeyUpdate -# with the old key is received before accepting any messages encrypted -# with the new key. Failure to do so may allow message truncation -# attacks. +# Both sender and receiver MUST encrypt their KeyUpdate messages with +# the old keys. Additionally, both sides MUST enforce that a KeyUpdate +# with the old key is received before accepting any messages encrypted +# with the new key. Failure to do so may allow message truncation +# attacks. [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.toml index 8683b2abbe4..dda1283780d 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-4.toml @@ -1,52 +1,52 @@ target = "https://www.rfc-editor.org/rfc/rfc8446#section-4" -# 4. Handshake Protocol +# Handshake Protocol # -# The handshake protocol is used to negotiate the security parameters -# of a connection. Handshake messages are supplied to the TLS record -# layer, where they are encapsulated within one or more TLSPlaintext or -# TLSCiphertext structures which are processed and transmitted as -# specified by the current active connection state. +# The handshake protocol is used to negotiate the security parameters +# of a connection. Handshake messages are supplied to the TLS record +# layer, where they are encapsulated within one or more TLSPlaintext or +# TLSCiphertext structures which are processed and transmitted as +# specified by the current active connection state. # -# enum { -# client_hello(1), -# server_hello(2), -# new_session_ticket(4), -# end_of_early_data(5), -# encrypted_extensions(8), -# certificate(11), -# certificate_request(13), -# certificate_verify(15), -# finished(20), -# key_update(24), -# message_hash(254), -# (255) -# } HandshakeType; +# enum { +# client_hello(1), +# server_hello(2), +# new_session_ticket(4), +# end_of_early_data(5), +# encrypted_extensions(8), +# certificate(11), +# certificate_request(13), +# certificate_verify(15), +# finished(20), +# key_update(24), +# message_hash(254), +# (255) +# } HandshakeType; # -# struct { -# HandshakeType msg_type; /* handshake type */ -# uint24 length; /* remaining bytes in message */ -# select (Handshake.msg_type) { -# case client_hello: ClientHello; -# case server_hello: ServerHello; -# case end_of_early_data: EndOfEarlyData; -# case encrypted_extensions: EncryptedExtensions; -# case certificate_request: CertificateRequest; -# case certificate: Certificate; -# case certificate_verify: CertificateVerify; -# case finished: Finished; -# case new_session_ticket: NewSessionTicket; -# case key_update: KeyUpdate; -# }; -# } Handshake; +# struct { +# HandshakeType msg_type; /* handshake type */ +# uint24 length; /* remaining bytes in message */ +# select (Handshake.msg_type) { +# case client_hello: ClientHello; +# case server_hello: ServerHello; +# case end_of_early_data: EndOfEarlyData; +# case encrypted_extensions: EncryptedExtensions; +# case certificate_request: CertificateRequest; +# case certificate: Certificate; +# case certificate_verify: CertificateVerify; +# case finished: Finished; +# case new_session_ticket: NewSessionTicket; +# case key_update: KeyUpdate; +# }; +# } Handshake; # -# Protocol messages MUST be sent in the order defined in Section 4.4.1 -# and shown in the diagrams in Section 2. A peer which receives a -# handshake message in an unexpected order MUST abort the handshake -# with an "unexpected_message" alert. +# Protocol messages MUST be sent in the order defined in Section 4.4.1 +# and shown in the diagrams in Section 2. A peer which receives a +# handshake message in an unexpected order MUST abort the handshake +# with an "unexpected_message" alert. # -# New handshake message types are assigned by IANA as described in -# Section 11. +# New handshake message types are assigned by IANA as described in +# Section 11. [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-5.1.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-5.1.toml index 04361326c91..d4d2a5bbdec 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-5.1.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-5.1.toml @@ -1,95 +1,95 @@ target = "https://www.rfc-editor.org/rfc/rfc8446#section-5.1" -# 5.1. Record Layer +# Record Layer # -# The record layer fragments information blocks into TLSPlaintext -# records carrying data in chunks of 2^14 bytes or less. Message -# boundaries are handled differently depending on the underlying -# ContentType. Any future content types MUST specify appropriate -# rules. Note that these rules are stricter than what was enforced in -# TLS 1.2. +# The record layer fragments information blocks into TLSPlaintext +# records carrying data in chunks of 2^14 bytes or less. Message +# boundaries are handled differently depending on the underlying +# ContentType. Any future content types MUST specify appropriate +# rules. Note that these rules are stricter than what was enforced in +# TLS 1.2. # -# Handshake messages MAY be coalesced into a single TLSPlaintext record -# or fragmented across several records, provided that: +# Handshake messages MAY be coalesced into a single TLSPlaintext record +# or fragmented across several records, provided that: # -# - Handshake messages MUST NOT be interleaved with other record -# types. That is, if a handshake message is split over two or more -# records, there MUST NOT be any other records between them. +# - Handshake messages MUST NOT be interleaved with other record +# types. That is, if a handshake message is split over two or more +# records, there MUST NOT be any other records between them. # -# - Handshake messages MUST NOT span key changes. Implementations -# MUST verify that all messages immediately preceding a key change -# align with a record boundary; if not, then they MUST terminate the -# connection with an "unexpected_message" alert. Because the -# ClientHello, EndOfEarlyData, ServerHello, Finished, and KeyUpdate -# messages can immediately precede a key change, implementations -# MUST send these messages in alignment with a record boundary. +# - Handshake messages MUST NOT span key changes. Implementations +# MUST verify that all messages immediately preceding a key change +# align with a record boundary; if not, then they MUST terminate the +# connection with an "unexpected_message" alert. Because the +# ClientHello, EndOfEarlyData, ServerHello, Finished, and KeyUpdate +# messages can immediately precede a key change, implementations +# MUST send these messages in alignment with a record boundary. # -# Implementations MUST NOT send zero-length fragments of Handshake -# types, even if those fragments contain padding. +# Implementations MUST NOT send zero-length fragments of Handshake +# types, even if those fragments contain padding. # -# Alert messages (Section 6) MUST NOT be fragmented across records, and -# multiple alert messages MUST NOT be coalesced into a single -# TLSPlaintext record. In other words, a record with an Alert type -# MUST contain exactly one message. +# Alert messages (Section 6) MUST NOT be fragmented across records, and +# multiple alert messages MUST NOT be coalesced into a single +# TLSPlaintext record. In other words, a record with an Alert type +# MUST contain exactly one message. # -# Application Data messages contain data that is opaque to TLS. -# Application Data messages are always protected. Zero-length -# fragments of Application Data MAY be sent, as they are potentially -# useful as a traffic analysis countermeasure. Application Data -# fragments MAY be split across multiple records or coalesced into a -# single record. +# Application Data messages contain data that is opaque to TLS. +# Application Data messages are always protected. Zero-length +# fragments of Application Data MAY be sent, as they are potentially +# useful as a traffic analysis countermeasure. Application Data +# fragments MAY be split across multiple records or coalesced into a +# single record. # -# enum { -# invalid(0), -# change_cipher_spec(20), -# alert(21), -# handshake(22), -# application_data(23), -# (255) -# } ContentType; +# enum { +# invalid(0), +# change_cipher_spec(20), +# alert(21), +# handshake(22), +# application_data(23), +# (255) +# } ContentType; # -# struct { -# ContentType type; -# ProtocolVersion legacy_record_version; -# uint16 length; -# opaque fragment[TLSPlaintext.length]; -# } TLSPlaintext; +# struct { +# ContentType type; +# ProtocolVersion legacy_record_version; +# uint16 length; +# opaque fragment[TLSPlaintext.length]; +# } TLSPlaintext; # -# type: The higher-level protocol used to process the enclosed -# fragment. +# type: The higher-level protocol used to process the enclosed +# fragment. # -# legacy_record_version: MUST be set to 0x0303 for all records -# generated by a TLS 1.3 implementation other than an initial -# ClientHello (i.e., one not generated after a HelloRetryRequest), -# where it MAY also be 0x0301 for compatibility purposes. This -# field is deprecated and MUST be ignored for all purposes. -# Previous versions of TLS would use other values in this field -# under some circumstances. +# legacy_record_version: MUST be set to 0x0303 for all records +# generated by a TLS 1.3 implementation other than an initial +# ClientHello (i.e., one not generated after a HelloRetryRequest), +# where it MAY also be 0x0301 for compatibility purposes. This +# field is deprecated and MUST be ignored for all purposes. +# Previous versions of TLS would use other values in this field +# under some circumstances. # -# length: The length (in bytes) of the following -# TLSPlaintext.fragment. The length MUST NOT exceed 2^14 bytes. An -# endpoint that receives a record that exceeds this length MUST -# terminate the connection with a "record_overflow" alert. +# length: The length (in bytes) of the following +# TLSPlaintext.fragment. The length MUST NOT exceed 2^14 bytes. An +# endpoint that receives a record that exceeds this length MUST +# terminate the connection with a "record_overflow" alert. # -# fragment: The data being transmitted. This value is transparent and -# is treated as an independent block to be dealt with by the higher- -# level protocol specified by the type field. +# fragment: The data being transmitted. This value is transparent and +# is treated as an independent block to be dealt with by the higher- +# level protocol specified by the type field. # -# This document describes TLS 1.3, which uses the version 0x0304. This -# version value is historical, deriving from the use of 0x0301 for -# TLS 1.0 and 0x0300 for SSL 3.0. In order to maximize backward -# compatibility, a record containing an initial ClientHello SHOULD have -# version 0x0301 (reflecting TLS 1.0) and a record containing a second -# ClientHello or a ServerHello MUST have version 0x0303 (reflecting -# TLS 1.2). When negotiating prior versions of TLS, endpoints follow -# the procedure and requirements provided in Appendix D. +# This document describes TLS 1.3, which uses the version 0x0304. This +# version value is historical, deriving from the use of 0x0301 for +# TLS 1.0 and 0x0300 for SSL 3.0. In order to maximize backward +# compatibility, a record containing an initial ClientHello SHOULD have +# version 0x0301 (reflecting TLS 1.0) and a record containing a second +# ClientHello or a ServerHello MUST have version 0x0303 (reflecting +# TLS 1.2). When negotiating prior versions of TLS, endpoints follow +# the procedure and requirements provided in Appendix D. # -# When record protection has not yet been engaged, TLSPlaintext -# structures are written directly onto the wire. Once record -# protection has started, TLSPlaintext records are protected and sent -# as described in the following section. Note that Application Data -# records MUST NOT be written to the wire unprotected (see Section 2 -# for details). +# When record protection has not yet been engaged, TLSPlaintext +# structures are written directly onto the wire. Once record +# protection has started, TLSPlaintext records are protected and sent +# as described in the following section. Note that Application Data +# records MUST NOT be written to the wire unprotected (see Section 2 +# for details). [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-5.2.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-5.2.toml index 81457cf3c24..371c39c3153 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-5.2.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-5.2.toml @@ -1,118 +1,118 @@ target = "https://www.rfc-editor.org/rfc/rfc8446#section-5.2" -# 5.2. Record Payload Protection +# Record Payload Protection # -# The record protection functions translate a TLSPlaintext structure -# into a TLSCiphertext structure. The deprotection functions reverse -# the process. In TLS 1.3, as opposed to previous versions of TLS, all -# ciphers are modeled as "Authenticated Encryption with Associated -# Data" (AEAD) [RFC5116]. AEAD functions provide a unified encryption -# and authentication operation which turns plaintext into authenticated -# ciphertext and back again. Each encrypted record consists of a -# plaintext header followed by an encrypted body, which itself contains -# a type and optional padding. -# -# struct { -# opaque content[TLSPlaintext.length]; -# ContentType type; -# uint8 zeros[length_of_padding]; -# } TLSInnerPlaintext; -# -# struct { -# ContentType opaque_type = application_data; /* 23 */ -# ProtocolVersion legacy_record_version = 0x0303; /* TLS v1.2 */ -# uint16 length; -# opaque encrypted_record[TLSCiphertext.length]; -# } TLSCiphertext; -# -# content: The TLSPlaintext.fragment value, containing the byte -# encoding of a handshake or an alert message, or the raw bytes of -# the application's data to send. -# -# type: The TLSPlaintext.type value containing the content type of the -# record. -# -# zeros: An arbitrary-length run of zero-valued bytes may appear in -# the cleartext after the type field. This provides an opportunity -# for senders to pad any TLS record by a chosen amount as long as -# the total stays within record size limits. See Section 5.4 for -# more details. -# -# opaque_type: The outer opaque_type field of a TLSCiphertext record -# is always set to the value 23 (application_data) for outward -# compatibility with middleboxes accustomed to parsing previous -# versions of TLS. The actual content type of the record is found -# in TLSInnerPlaintext.type after decryption. -# -# legacy_record_version: The legacy_record_version field is always -# 0x0303. TLS 1.3 TLSCiphertexts are not generated until after -# TLS 1.3 has been negotiated, so there are no historical -# compatibility concerns where other values might be received. Note -# that the handshake protocol, including the ClientHello and -# ServerHello messages, authenticates the protocol version, so this -# value is redundant. -# -# length: The length (in bytes) of the following -# TLSCiphertext.encrypted_record, which is the sum of the lengths of -# the content and the padding, plus one for the inner content type, -# plus any expansion added by the AEAD algorithm. The length -# MUST NOT exceed 2^14 + 256 bytes. An endpoint that receives a -# record that exceeds this length MUST terminate the connection with -# a "record_overflow" alert. -# -# encrypted_record: The AEAD-encrypted form of the serialized -# TLSInnerPlaintext structure. -# -# AEAD algorithms take as input a single key, a nonce, a plaintext, and -# "additional data" to be included in the authentication check, as -# described in Section 2.1 of [RFC5116]. The key is either the -# client_write_key or the server_write_key, the nonce is derived from -# the sequence number and the client_write_iv or server_write_iv (see -# Section 5.3), and the additional data input is the record header. -# -# I.e., -# -# additional_data = TLSCiphertext.opaque_type || -# TLSCiphertext.legacy_record_version || -# TLSCiphertext.length -# -# The plaintext input to the AEAD algorithm is the encoded -# TLSInnerPlaintext structure. Derivation of traffic keys is defined -# in Section 7.3. -# -# The AEAD output consists of the ciphertext output from the AEAD -# encryption operation. The length of the plaintext is greater than -# the corresponding TLSPlaintext.length due to the inclusion of -# TLSInnerPlaintext.type and any padding supplied by the sender. The -# length of the AEAD output will generally be larger than the -# plaintext, but by an amount that varies with the AEAD algorithm. -# -# Since the ciphers might incorporate padding, the amount of overhead -# could vary with different lengths of plaintext. Symbolically, -# -# AEADEncrypted = -# AEAD-Encrypt(write_key, nonce, additional_data, plaintext) -# -# The encrypted_record field of TLSCiphertext is set to AEADEncrypted. -# -# In order to decrypt and verify, the cipher takes as input the key, -# nonce, additional data, and the AEADEncrypted value. The output is -# either the plaintext or an error indicating that the decryption -# failed. There is no separate integrity check. Symbolically, -# -# plaintext of encrypted_record = -# AEAD-Decrypt(peer_write_key, nonce, -# additional_data, AEADEncrypted) -# -# If the decryption fails, the receiver MUST terminate the connection -# with a "bad_record_mac" alert. -# -# An AEAD algorithm used in TLS 1.3 MUST NOT produce an expansion -# greater than 255 octets. An endpoint that receives a record from its -# peer with TLSCiphertext.length larger than 2^14 + 256 octets MUST -# terminate the connection with a "record_overflow" alert. This limit -# is derived from the maximum TLSInnerPlaintext length of 2^14 octets + -# 1 octet for ContentType + the maximum AEAD expansion of 255 octets. +# The record protection functions translate a TLSPlaintext structure +# into a TLSCiphertext structure. The deprotection functions reverse +# the process. In TLS 1.3, as opposed to previous versions of TLS, all +# ciphers are modeled as "Authenticated Encryption with Associated +# Data" (AEAD) [RFC5116]. AEAD functions provide a unified encryption +# and authentication operation which turns plaintext into authenticated +# ciphertext and back again. Each encrypted record consists of a +# plaintext header followed by an encrypted body, which itself contains +# a type and optional padding. +# +# struct { +# opaque content[TLSPlaintext.length]; +# ContentType type; +# uint8 zeros[length_of_padding]; +# } TLSInnerPlaintext; +# +# struct { +# ContentType opaque_type = application_data; /* 23 */ +# ProtocolVersion legacy_record_version = 0x0303; /* TLS v1.2 */ +# uint16 length; +# opaque encrypted_record[TLSCiphertext.length]; +# } TLSCiphertext; +# +# content: The TLSPlaintext.fragment value, containing the byte +# encoding of a handshake or an alert message, or the raw bytes of +# the application's data to send. +# +# type: The TLSPlaintext.type value containing the content type of the +# record. +# +# zeros: An arbitrary-length run of zero-valued bytes may appear in +# the cleartext after the type field. This provides an opportunity +# for senders to pad any TLS record by a chosen amount as long as +# the total stays within record size limits. See Section 5.4 for +# more details. +# +# opaque_type: The outer opaque_type field of a TLSCiphertext record +# is always set to the value 23 (application_data) for outward +# compatibility with middleboxes accustomed to parsing previous +# versions of TLS. The actual content type of the record is found +# in TLSInnerPlaintext.type after decryption. +# +# legacy_record_version: The legacy_record_version field is always +# 0x0303. TLS 1.3 TLSCiphertexts are not generated until after +# TLS 1.3 has been negotiated, so there are no historical +# compatibility concerns where other values might be received. Note +# that the handshake protocol, including the ClientHello and +# ServerHello messages, authenticates the protocol version, so this +# value is redundant. +# +# length: The length (in bytes) of the following +# TLSCiphertext.encrypted_record, which is the sum of the lengths of +# the content and the padding, plus one for the inner content type, +# plus any expansion added by the AEAD algorithm. The length +# MUST NOT exceed 2^14 + 256 bytes. An endpoint that receives a +# record that exceeds this length MUST terminate the connection with +# a "record_overflow" alert. +# +# encrypted_record: The AEAD-encrypted form of the serialized +# TLSInnerPlaintext structure. +# +# AEAD algorithms take as input a single key, a nonce, a plaintext, and +# "additional data" to be included in the authentication check, as +# described in Section 2.1 of [RFC5116]. The key is either the +# client_write_key or the server_write_key, the nonce is derived from +# the sequence number and the client_write_iv or server_write_iv (see +# Section 5.3), and the additional data input is the record header. +# +# I.e., +# +# additional_data = TLSCiphertext.opaque_type || +# TLSCiphertext.legacy_record_version || +# TLSCiphertext.length +# +# The plaintext input to the AEAD algorithm is the encoded +# TLSInnerPlaintext structure. Derivation of traffic keys is defined +# in Section 7.3. +# +# The AEAD output consists of the ciphertext output from the AEAD +# encryption operation. The length of the plaintext is greater than +# the corresponding TLSPlaintext.length due to the inclusion of +# TLSInnerPlaintext.type and any padding supplied by the sender. The +# length of the AEAD output will generally be larger than the +# plaintext, but by an amount that varies with the AEAD algorithm. +# +# Since the ciphers might incorporate padding, the amount of overhead +# could vary with different lengths of plaintext. Symbolically, +# +# AEADEncrypted = +# AEAD-Encrypt(write_key, nonce, additional_data, plaintext) +# +# The encrypted_record field of TLSCiphertext is set to AEADEncrypted. +# +# In order to decrypt and verify, the cipher takes as input the key, +# nonce, additional data, and the AEADEncrypted value. The output is +# either the plaintext or an error indicating that the decryption +# failed. There is no separate integrity check. Symbolically, +# +# plaintext of encrypted_record = +# AEAD-Decrypt(peer_write_key, nonce, +# additional_data, AEADEncrypted) +# +# If the decryption fails, the receiver MUST terminate the connection +# with a "bad_record_mac" alert. +# +# An AEAD algorithm used in TLS 1.3 MUST NOT produce an expansion +# greater than 255 octets. An endpoint that receives a record from its +# peer with TLSCiphertext.length larger than 2^14 + 256 octets MUST +# terminate the connection with a "record_overflow" alert. This limit +# is derived from the maximum TLSInnerPlaintext length of 2^14 octets + +# 1 octet for ContentType + the maximum AEAD expansion of 255 octets. [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-5.3.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-5.3.toml index 13113420ce4..188ac22dca1 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-5.3.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-5.3.toml @@ -1,37 +1,37 @@ target = "https://www.rfc-editor.org/rfc/rfc8446#section-5.3" -# 5.3. Per-Record Nonce +# Per-Record Nonce # -# A 64-bit sequence number is maintained separately for reading and -# writing records. The appropriate sequence number is incremented by -# one after reading or writing each record. Each sequence number is -# set to zero at the beginning of a connection and whenever the key is -# changed; the first record transmitted under a particular traffic key -# MUST use sequence number 0. +# A 64-bit sequence number is maintained separately for reading and +# writing records. The appropriate sequence number is incremented by +# one after reading or writing each record. Each sequence number is +# set to zero at the beginning of a connection and whenever the key is +# changed; the first record transmitted under a particular traffic key +# MUST use sequence number 0. # -# Because the size of sequence numbers is 64-bit, they should not wrap. -# If a TLS implementation would need to wrap a sequence number, it MUST -# either rekey (Section 4.6.3) or terminate the connection. +# Because the size of sequence numbers is 64-bit, they should not wrap. +# If a TLS implementation would need to wrap a sequence number, it MUST +# either rekey (Section 4.6.3) or terminate the connection. # -# Each AEAD algorithm will specify a range of possible lengths for the -# per-record nonce, from N_MIN bytes to N_MAX bytes of input [RFC5116]. -# The length of the TLS per-record nonce (iv_length) is set to the -# larger of 8 bytes and N_MIN for the AEAD algorithm (see [RFC5116], -# Section 4). An AEAD algorithm where N_MAX is less than 8 bytes -# MUST NOT be used with TLS. The per-record nonce for the AEAD -# construction is formed as follows: +# Each AEAD algorithm will specify a range of possible lengths for the +# per-record nonce, from N_MIN bytes to N_MAX bytes of input [RFC5116]. +# The length of the TLS per-record nonce (iv_length) is set to the +# larger of 8 bytes and N_MIN for the AEAD algorithm (see [RFC5116], +# Section 4). An AEAD algorithm where N_MAX is less than 8 bytes +# MUST NOT be used with TLS. The per-record nonce for the AEAD +# construction is formed as follows: # -# 1. The 64-bit record sequence number is encoded in network byte -# order and padded to the left with zeros to iv_length. +# 1. The 64-bit record sequence number is encoded in network byte +# order and padded to the left with zeros to iv_length. # -# 2. The padded sequence number is XORed with either the static -# client_write_iv or server_write_iv (depending on the role). +# 2. The padded sequence number is XORed with either the static +# client_write_iv or server_write_iv (depending on the role). # -# The resulting quantity (of length iv_length) is used as the -# per-record nonce. +# The resulting quantity (of length iv_length) is used as the +# per-record nonce. # -# Note: This is a different construction from that in TLS 1.2, which -# specified a partially explicit nonce. +# Note: This is a different construction from that in TLS 1.2, which +# specified a partially explicit nonce. [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-5.4.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-5.4.toml index 1f38492ab1f..3e8a039d019 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-5.4.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-5.4.toml @@ -1,57 +1,57 @@ target = "https://www.rfc-editor.org/rfc/rfc8446#section-5.4" -# 5.4. Record Padding +# Record Padding # -# All encrypted TLS records can be padded to inflate the size of the -# TLSCiphertext. This allows the sender to hide the size of the -# traffic from an observer. +# All encrypted TLS records can be padded to inflate the size of the +# TLSCiphertext. This allows the sender to hide the size of the +# traffic from an observer. # -# When generating a TLSCiphertext record, implementations MAY choose to -# pad. An unpadded record is just a record with a padding length of -# zero. Padding is a string of zero-valued bytes appended to the -# ContentType field before encryption. Implementations MUST set the -# padding octets to all zeros before encrypting. +# When generating a TLSCiphertext record, implementations MAY choose to +# pad. An unpadded record is just a record with a padding length of +# zero. Padding is a string of zero-valued bytes appended to the +# ContentType field before encryption. Implementations MUST set the +# padding octets to all zeros before encrypting. # -# Application Data records may contain a zero-length -# TLSInnerPlaintext.content if the sender desires. This permits -# generation of plausibly sized cover traffic in contexts where the -# presence or absence of activity may be sensitive. Implementations -# MUST NOT send Handshake and Alert records that have a zero-length -# TLSInnerPlaintext.content; if such a message is received, the -# receiving implementation MUST terminate the connection with an -# "unexpected_message" alert. +# Application Data records may contain a zero-length +# TLSInnerPlaintext.content if the sender desires. This permits +# generation of plausibly sized cover traffic in contexts where the +# presence or absence of activity may be sensitive. Implementations +# MUST NOT send Handshake and Alert records that have a zero-length +# TLSInnerPlaintext.content; if such a message is received, the +# receiving implementation MUST terminate the connection with an +# "unexpected_message" alert. # -# The padding sent is automatically verified by the record protection -# mechanism; upon successful decryption of a -# TLSCiphertext.encrypted_record, the receiving implementation scans -# the field from the end toward the beginning until it finds a non-zero -# octet. This non-zero octet is the content type of the message. This -# padding scheme was selected because it allows padding of any -# encrypted TLS record by an arbitrary size (from zero up to TLS record -# size limits) without introducing new content types. The design also -# enforces all-zero padding octets, which allows for quick detection of -# padding errors. +# The padding sent is automatically verified by the record protection +# mechanism; upon successful decryption of a +# TLSCiphertext.encrypted_record, the receiving implementation scans +# the field from the end toward the beginning until it finds a non-zero +# octet. This non-zero octet is the content type of the message. This +# padding scheme was selected because it allows padding of any +# encrypted TLS record by an arbitrary size (from zero up to TLS record +# size limits) without introducing new content types. The design also +# enforces all-zero padding octets, which allows for quick detection of +# padding errors. # -# Implementations MUST limit their scanning to the cleartext returned -# from the AEAD decryption. If a receiving implementation does not -# find a non-zero octet in the cleartext, it MUST terminate the -# connection with an "unexpected_message" alert. +# Implementations MUST limit their scanning to the cleartext returned +# from the AEAD decryption. If a receiving implementation does not +# find a non-zero octet in the cleartext, it MUST terminate the +# connection with an "unexpected_message" alert. # -# The presence of padding does not change the overall record size -# limitations: the full encoded TLSInnerPlaintext MUST NOT exceed 2^14 -# + 1 octets. If the maximum fragment length is reduced -- as, for -# example, by the record_size_limit extension from [RFC8449] -- then -# the reduced limit applies to the full plaintext, including the -# content type and padding. +# The presence of padding does not change the overall record size +# limitations: the full encoded TLSInnerPlaintext MUST NOT exceed 2^14 +# + 1 octets. If the maximum fragment length is reduced -- as, for +# example, by the record_size_limit extension from [RFC8449] -- then +# the reduced limit applies to the full plaintext, including the +# content type and padding. # -# Selecting a padding policy that suggests when and how much to pad is -# a complex topic and is beyond the scope of this specification. If -# the application-layer protocol on top of TLS has its own padding, it -# may be preferable to pad Application Data TLS records within the -# application layer. Padding for encrypted Handshake or Alert records -# must still be handled at the TLS layer, though. Later documents may -# define padding selection algorithms or define a padding policy -# request mechanism through TLS extensions or some other means. +# Selecting a padding policy that suggests when and how much to pad is +# a complex topic and is beyond the scope of this specification. If +# the application-layer protocol on top of TLS has its own padding, it +# may be preferable to pad Application Data TLS records within the +# application layer. Padding for encrypted Handshake or Alert records +# must still be handled at the TLS layer, though. Later documents may +# define padding selection algorithms or define a padding policy +# request mechanism through TLS extensions or some other means. [[spec]] level = "MAY" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-5.5.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-5.5.toml index a8365d9598b..a0239f7a6be 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-5.5.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-5.5.toml @@ -1,19 +1,19 @@ target = "https://www.rfc-editor.org/rfc/rfc8446#section-5.5" -# 5.5. Limits on Key Usage +# Limits on Key Usage # -# There are cryptographic limits on the amount of plaintext which can -# be safely encrypted under a given set of keys. [AEAD-LIMITS] -# provides an analysis of these limits under the assumption that the -# underlying primitive (AES or ChaCha20) has no weaknesses. -# Implementations SHOULD do a key update as described in Section 4.6.3 -# prior to reaching these limits. +# There are cryptographic limits on the amount of plaintext which can +# be safely encrypted under a given set of keys. [AEAD-LIMITS] +# provides an analysis of these limits under the assumption that the +# underlying primitive (AES or ChaCha20) has no weaknesses. +# Implementations SHOULD do a key update as described in Section 4.6.3 +# prior to reaching these limits. # -# For AES-GCM, up to 2^24.5 full-size records (about 24 million) may be -# encrypted on a given connection while keeping a safety margin of -# approximately 2^-57 for Authenticated Encryption (AE) security. For -# ChaCha20/Poly1305, the record sequence number would wrap before the -# safety limit is reached. +# For AES-GCM, up to 2^24.5 full-size records (about 24 million) may be +# encrypted on a given connection while keeping a safety margin of +# approximately 2^-57 for Authenticated Encryption (AE) security. For +# ChaCha20/Poly1305, the record sequence number would wrap before the +# safety limit is reached. [[spec]] level = "SHOULD" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-5.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-5.toml index fabed8fdefb..6b685a576aa 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-5.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-5.toml @@ -1,40 +1,40 @@ target = "https://www.rfc-editor.org/rfc/rfc8446#section-5" -# 5. Record Protocol +# Record Protocol # -# The TLS record protocol takes messages to be transmitted, fragments -# the data into manageable blocks, protects the records, and transmits -# the result. Received data is verified, decrypted, reassembled, and -# then delivered to higher-level clients. +# The TLS record protocol takes messages to be transmitted, fragments +# the data into manageable blocks, protects the records, and transmits +# the result. Received data is verified, decrypted, reassembled, and +# then delivered to higher-level clients. # -# TLS records are typed, which allows multiple higher-level protocols -# to be multiplexed over the same record layer. This document -# specifies four content types: handshake, application_data, alert, and -# change_cipher_spec. The change_cipher_spec record is used only for -# compatibility purposes (see Appendix D.4). +# TLS records are typed, which allows multiple higher-level protocols +# to be multiplexed over the same record layer. This document +# specifies four content types: handshake, application_data, alert, and +# change_cipher_spec. The change_cipher_spec record is used only for +# compatibility purposes (see Appendix D.4). # -# An implementation may receive an unencrypted record of type -# change_cipher_spec consisting of the single byte value 0x01 at any -# time after the first ClientHello message has been sent or received -# and before the peer's Finished message has been received and MUST -# simply drop it without further processing. Note that this record may -# appear at a point at the handshake where the implementation is -# expecting protected records, and so it is necessary to detect this -# condition prior to attempting to deprotect the record. An -# implementation which receives any other change_cipher_spec value or -# which receives a protected change_cipher_spec record MUST abort the -# handshake with an "unexpected_message" alert. If an implementation -# detects a change_cipher_spec record received before the first -# ClientHello message or after the peer's Finished message, it MUST be -# treated as an unexpected record type (though stateless servers may -# not be able to distinguish these cases from allowed cases). +# An implementation may receive an unencrypted record of type +# change_cipher_spec consisting of the single byte value 0x01 at any +# time after the first ClientHello message has been sent or received +# and before the peer's Finished message has been received and MUST +# simply drop it without further processing. Note that this record may +# appear at a point at the handshake where the implementation is +# expecting protected records, and so it is necessary to detect this +# condition prior to attempting to deprotect the record. An +# implementation which receives any other change_cipher_spec value or +# which receives a protected change_cipher_spec record MUST abort the +# handshake with an "unexpected_message" alert. If an implementation +# detects a change_cipher_spec record received before the first +# ClientHello message or after the peer's Finished message, it MUST be +# treated as an unexpected record type (though stateless servers may +# not be able to distinguish these cases from allowed cases). # -# Implementations MUST NOT send record types not defined in this -# document unless negotiated by some extension. If a TLS -# implementation receives an unexpected record type, it MUST terminate -# the connection with an "unexpected_message" alert. New record -# content type values are assigned by IANA in the TLS ContentType -# registry as described in Section 11. +# Implementations MUST NOT send record types not defined in this +# document unless negotiated by some extension. If a TLS +# implementation receives an unexpected record type, it MUST terminate +# the connection with an "unexpected_message" alert. New record +# content type values are assigned by IANA in the TLS ContentType +# registry as described in Section 11. [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-6.1.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-6.1.toml index 28f9bdadc4b..f78de38ed7e 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-6.1.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-6.1.toml @@ -1,49 +1,49 @@ target = "https://www.rfc-editor.org/rfc/rfc8446#section-6.1" -# 6.1. Closure Alerts +# Closure Alerts # -# The client and the server must share knowledge that the connection is -# ending in order to avoid a truncation attack. +# The client and the server must share knowledge that the connection is +# ending in order to avoid a truncation attack. # -# close_notify: This alert notifies the recipient that the sender will -# not send any more messages on this connection. Any data received -# after a closure alert has been received MUST be ignored. +# close_notify: This alert notifies the recipient that the sender will +# not send any more messages on this connection. Any data received +# after a closure alert has been received MUST be ignored. # -# user_canceled: This alert notifies the recipient that the sender is -# canceling the handshake for some reason unrelated to a protocol -# failure. If a user cancels an operation after the handshake is -# complete, just closing the connection by sending a "close_notify" -# is more appropriate. This alert SHOULD be followed by a -# "close_notify". This alert generally has AlertLevel=warning. +# user_canceled: This alert notifies the recipient that the sender is +# canceling the handshake for some reason unrelated to a protocol +# failure. If a user cancels an operation after the handshake is +# complete, just closing the connection by sending a "close_notify" +# is more appropriate. This alert SHOULD be followed by a +# "close_notify". This alert generally has AlertLevel=warning. # -# Either party MAY initiate a close of its write side of the connection -# by sending a "close_notify" alert. Any data received after a closure -# alert has been received MUST be ignored. If a transport-level close -# is received prior to a "close_notify", the receiver cannot know that -# all the data that was sent has been received. +# Either party MAY initiate a close of its write side of the connection +# by sending a "close_notify" alert. Any data received after a closure +# alert has been received MUST be ignored. If a transport-level close +# is received prior to a "close_notify", the receiver cannot know that +# all the data that was sent has been received. # -# Each party MUST send a "close_notify" alert before closing its write -# side of the connection, unless it has already sent some error alert. -# This does not have any effect on its read side of the connection. -# Note that this is a change from versions of TLS prior to TLS 1.3 in -# which implementations were required to react to a "close_notify" by -# discarding pending writes and sending an immediate "close_notify" -# alert of their own. That previous requirement could cause truncation -# in the read side. Both parties need not wait to receive a -# "close_notify" alert before closing their read side of the -# connection, though doing so would introduce the possibility of -# truncation. +# Each party MUST send a "close_notify" alert before closing its write +# side of the connection, unless it has already sent some error alert. +# This does not have any effect on its read side of the connection. +# Note that this is a change from versions of TLS prior to TLS 1.3 in +# which implementations were required to react to a "close_notify" by +# discarding pending writes and sending an immediate "close_notify" +# alert of their own. That previous requirement could cause truncation +# in the read side. Both parties need not wait to receive a +# "close_notify" alert before closing their read side of the +# connection, though doing so would introduce the possibility of +# truncation. # -# If the application protocol using TLS provides that any data may be -# carried over the underlying transport after the TLS connection is -# closed, the TLS implementation MUST receive a "close_notify" alert -# before indicating end-of-data to the application layer. No part of -# this standard should be taken to dictate the manner in which a usage -# profile for TLS manages its data transport, including when -# connections are opened or closed. +# If the application protocol using TLS provides that any data may be +# carried over the underlying transport after the TLS connection is +# closed, the TLS implementation MUST receive a "close_notify" alert +# before indicating end-of-data to the application layer. No part of +# this standard should be taken to dictate the manner in which a usage +# profile for TLS manages its data transport, including when +# connections are opened or closed. # -# Note: It is assumed that closing the write side of a connection -# reliably delivers pending data before destroying the transport. +# Note: It is assumed that closing the write side of a connection +# reliably delivers pending data before destroying the transport. [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-6.2.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-6.2.toml index d14ed29a923..ada7cb04a37 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-6.2.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-6.2.toml @@ -1,135 +1,135 @@ target = "https://www.rfc-editor.org/rfc/rfc8446#section-6.2" -# 6.2. Error Alerts +# Error Alerts # -# Error handling in TLS is very simple. When an error is detected, the -# detecting party sends a message to its peer. Upon transmission or -# receipt of a fatal alert message, both parties MUST immediately close -# the connection. -# -# Whenever an implementation encounters a fatal error condition, it -# SHOULD send an appropriate fatal alert and MUST close the connection -# without sending or receiving any additional data. In the rest of -# this specification, when the phrases "terminate the connection" and -# "abort the handshake" are used without a specific alert it means that -# the implementation SHOULD send the alert indicated by the -# descriptions below. The phrases "terminate the connection with an X -# alert" and "abort the handshake with an X alert" mean that the -# implementation MUST send alert X if it sends any alert. All alerts -# defined below in this section, as well as all unknown alerts, are -# universally considered fatal as of TLS 1.3 (see Section 6). The -# implementation SHOULD provide a way to facilitate logging the sending -# and receiving of alerts. -# -# The following error alerts are defined: -# -# unexpected_message: An inappropriate message (e.g., the wrong -# handshake message, premature Application Data, etc.) was received. -# This alert should never be observed in communication between -# proper implementations. -# -# bad_record_mac: This alert is returned if a record is received which -# cannot be deprotected. Because AEAD algorithms combine decryption -# and verification, and also to avoid side-channel attacks, this -# alert is used for all deprotection failures. This alert should -# never be observed in communication between proper implementations, -# except when messages were corrupted in the network. -# -# record_overflow: A TLSCiphertext record was received that had a -# length more than 2^14 + 256 bytes, or a record decrypted to a -# TLSPlaintext record with more than 2^14 bytes (or some other -# negotiated limit). This alert should never be observed in -# communication between proper implementations, except when messages -# were corrupted in the network. -# -# handshake_failure: Receipt of a "handshake_failure" alert message -# indicates that the sender was unable to negotiate an acceptable -# set of security parameters given the options available. -# -# bad_certificate: A certificate was corrupt, contained signatures -# that did not verify correctly, etc. -# -# unsupported_certificate: A certificate was of an unsupported type. -# -# certificate_revoked: A certificate was revoked by its signer. -# -# certificate_expired: A certificate has expired or is not currently -# valid. -# -# certificate_unknown: Some other (unspecified) issue arose in -# processing the certificate, rendering it unacceptable. -# -# illegal_parameter: A field in the handshake was incorrect or -# inconsistent with other fields. This alert is used for errors -# which conform to the formal protocol syntax but are otherwise -# incorrect. -# -# unknown_ca: A valid certificate chain or partial chain was received, -# but the certificate was not accepted because the CA certificate -# could not be located or could not be matched with a known trust -# anchor. -# -# access_denied: A valid certificate or PSK was received, but when -# access control was applied, the sender decided not to proceed with -# negotiation. -# -# decode_error: A message could not be decoded because some field was -# out of the specified range or the length of the message was -# incorrect. This alert is used for errors where the message does -# not conform to the formal protocol syntax. This alert should -# never be observed in communication between proper implementations, -# except when messages were corrupted in the network. -# -# decrypt_error: A handshake (not record layer) cryptographic -# operation failed, including being unable to correctly verify a -# signature or validate a Finished message or a PSK binder. -# -# protocol_version: The protocol version the peer has attempted to -# negotiate is recognized but not supported (see Appendix D). -# -# insufficient_security: Returned instead of "handshake_failure" when -# a negotiation has failed specifically because the server requires -# parameters more secure than those supported by the client. -# -# internal_error: An internal error unrelated to the peer or the -# correctness of the protocol (such as a memory allocation failure) -# makes it impossible to continue. -# -# inappropriate_fallback: Sent by a server in response to an invalid -# connection retry attempt from a client (see [RFC7507]). -# -# missing_extension: Sent by endpoints that receive a handshake -# message not containing an extension that is mandatory to send for -# the offered TLS version or other negotiated parameters. -# -# unsupported_extension: Sent by endpoints receiving any handshake -# message containing an extension known to be prohibited for -# inclusion in the given handshake message, or including any -# extensions in a ServerHello or Certificate not first offered in -# the corresponding ClientHello or CertificateRequest. -# -# unrecognized_name: Sent by servers when no server exists identified -# by the name provided by the client via the "server_name" extension -# (see [RFC6066]). -# -# bad_certificate_status_response: Sent by clients when an invalid or -# unacceptable OCSP response is provided by the server via the -# "status_request" extension (see [RFC6066]). -# -# unknown_psk_identity: Sent by servers when PSK key establishment is -# desired but no acceptable PSK identity is provided by the client. -# Sending this alert is OPTIONAL; servers MAY instead choose to send -# a "decrypt_error" alert to merely indicate an invalid PSK -# identity. -# -# certificate_required: Sent by servers when a client certificate is -# desired but none was provided by the client. -# -# no_application_protocol: Sent by servers when a client -# "application_layer_protocol_negotiation" extension advertises only -# protocols that the server does not support (see [RFC7301]). -# -# New Alert values are assigned by IANA as described in Section 11. +# Error handling in TLS is very simple. When an error is detected, the +# detecting party sends a message to its peer. Upon transmission or +# receipt of a fatal alert message, both parties MUST immediately close +# the connection. +# +# Whenever an implementation encounters a fatal error condition, it +# SHOULD send an appropriate fatal alert and MUST close the connection +# without sending or receiving any additional data. In the rest of +# this specification, when the phrases "terminate the connection" and +# "abort the handshake" are used without a specific alert it means that +# the implementation SHOULD send the alert indicated by the +# descriptions below. The phrases "terminate the connection with an X +# alert" and "abort the handshake with an X alert" mean that the +# implementation MUST send alert X if it sends any alert. All alerts +# defined below in this section, as well as all unknown alerts, are +# universally considered fatal as of TLS 1.3 (see Section 6). The +# implementation SHOULD provide a way to facilitate logging the sending +# and receiving of alerts. +# +# The following error alerts are defined: +# +# unexpected_message: An inappropriate message (e.g., the wrong +# handshake message, premature Application Data, etc.) was received. +# This alert should never be observed in communication between +# proper implementations. +# +# bad_record_mac: This alert is returned if a record is received which +# cannot be deprotected. Because AEAD algorithms combine decryption +# and verification, and also to avoid side-channel attacks, this +# alert is used for all deprotection failures. This alert should +# never be observed in communication between proper implementations, +# except when messages were corrupted in the network. +# +# record_overflow: A TLSCiphertext record was received that had a +# length more than 2^14 + 256 bytes, or a record decrypted to a +# TLSPlaintext record with more than 2^14 bytes (or some other +# negotiated limit). This alert should never be observed in +# communication between proper implementations, except when messages +# were corrupted in the network. +# +# handshake_failure: Receipt of a "handshake_failure" alert message +# indicates that the sender was unable to negotiate an acceptable +# set of security parameters given the options available. +# +# bad_certificate: A certificate was corrupt, contained signatures +# that did not verify correctly, etc. +# +# unsupported_certificate: A certificate was of an unsupported type. +# +# certificate_revoked: A certificate was revoked by its signer. +# +# certificate_expired: A certificate has expired or is not currently +# valid. +# +# certificate_unknown: Some other (unspecified) issue arose in +# processing the certificate, rendering it unacceptable. +# +# illegal_parameter: A field in the handshake was incorrect or +# inconsistent with other fields. This alert is used for errors +# which conform to the formal protocol syntax but are otherwise +# incorrect. +# +# unknown_ca: A valid certificate chain or partial chain was received, +# but the certificate was not accepted because the CA certificate +# could not be located or could not be matched with a known trust +# anchor. +# +# access_denied: A valid certificate or PSK was received, but when +# access control was applied, the sender decided not to proceed with +# negotiation. +# +# decode_error: A message could not be decoded because some field was +# out of the specified range or the length of the message was +# incorrect. This alert is used for errors where the message does +# not conform to the formal protocol syntax. This alert should +# never be observed in communication between proper implementations, +# except when messages were corrupted in the network. +# +# decrypt_error: A handshake (not record layer) cryptographic +# operation failed, including being unable to correctly verify a +# signature or validate a Finished message or a PSK binder. +# +# protocol_version: The protocol version the peer has attempted to +# negotiate is recognized but not supported (see Appendix D). +# +# insufficient_security: Returned instead of "handshake_failure" when +# a negotiation has failed specifically because the server requires +# parameters more secure than those supported by the client. +# +# internal_error: An internal error unrelated to the peer or the +# correctness of the protocol (such as a memory allocation failure) +# makes it impossible to continue. +# +# inappropriate_fallback: Sent by a server in response to an invalid +# connection retry attempt from a client (see [RFC7507]). +# +# missing_extension: Sent by endpoints that receive a handshake +# message not containing an extension that is mandatory to send for +# the offered TLS version or other negotiated parameters. +# +# unsupported_extension: Sent by endpoints receiving any handshake +# message containing an extension known to be prohibited for +# inclusion in the given handshake message, or including any +# extensions in a ServerHello or Certificate not first offered in +# the corresponding ClientHello or CertificateRequest. +# +# unrecognized_name: Sent by servers when no server exists identified +# by the name provided by the client via the "server_name" extension +# (see [RFC6066]). +# +# bad_certificate_status_response: Sent by clients when an invalid or +# unacceptable OCSP response is provided by the server via the +# "status_request" extension (see [RFC6066]). +# +# unknown_psk_identity: Sent by servers when PSK key establishment is +# desired but no acceptable PSK identity is provided by the client. +# Sending this alert is OPTIONAL; servers MAY instead choose to send +# a "decrypt_error" alert to merely indicate an invalid PSK +# identity. +# +# certificate_required: Sent by servers when a client certificate is +# desired but none was provided by the client. +# +# no_application_protocol: Sent by servers when a client +# "application_layer_protocol_negotiation" extension advertises only +# protocols that the server does not support (see [RFC7301]). +# +# New Alert values are assigned by IANA as described in Section 11. [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-6.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-6.toml index 4beecdc75ff..5f82bc9bcb6 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-6.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-6.toml @@ -1,79 +1,79 @@ target = "https://www.rfc-editor.org/rfc/rfc8446#section-6" -# 6. Alert Protocol +# Alert Protocol # -# TLS provides an Alert content type to indicate closure information -# and errors. Like other messages, alert messages are encrypted as -# specified by the current connection state. +# TLS provides an Alert content type to indicate closure information +# and errors. Like other messages, alert messages are encrypted as +# specified by the current connection state. # -# Alert messages convey a description of the alert and a legacy field -# that conveyed the severity level of the message in previous versions -# of TLS. Alerts are divided into two classes: closure alerts and -# error alerts. In TLS 1.3, the severity is implicit in the type of -# alert being sent, and the "level" field can safely be ignored. The -# "close_notify" alert is used to indicate orderly closure of one -# direction of the connection. Upon receiving such an alert, the TLS -# implementation SHOULD indicate end-of-data to the application. +# Alert messages convey a description of the alert and a legacy field +# that conveyed the severity level of the message in previous versions +# of TLS. Alerts are divided into two classes: closure alerts and +# error alerts. In TLS 1.3, the severity is implicit in the type of +# alert being sent, and the "level" field can safely be ignored. The +# "close_notify" alert is used to indicate orderly closure of one +# direction of the connection. Upon receiving such an alert, the TLS +# implementation SHOULD indicate end-of-data to the application. # -# Error alerts indicate abortive closure of the connection (see -# Section 6.2). Upon receiving an error alert, the TLS implementation -# SHOULD indicate an error to the application and MUST NOT allow any -# further data to be sent or received on the connection. Servers and -# clients MUST forget the secret values and keys established in failed -# connections, with the exception of the PSKs associated with session -# tickets, which SHOULD be discarded if possible. +# Error alerts indicate abortive closure of the connection (see +# Section 6.2). Upon receiving an error alert, the TLS implementation +# SHOULD indicate an error to the application and MUST NOT allow any +# further data to be sent or received on the connection. Servers and +# clients MUST forget the secret values and keys established in failed +# connections, with the exception of the PSKs associated with session +# tickets, which SHOULD be discarded if possible. # -# All the alerts listed in Section 6.2 MUST be sent with -# AlertLevel=fatal and MUST be treated as error alerts when received -# regardless of the AlertLevel in the message. Unknown Alert types -# MUST be treated as error alerts. +# All the alerts listed in Section 6.2 MUST be sent with +# AlertLevel=fatal and MUST be treated as error alerts when received +# regardless of the AlertLevel in the message. Unknown Alert types +# MUST be treated as error alerts. # -# Note: TLS defines two generic alerts (see Section 6) to use upon -# failure to parse a message. Peers which receive a message which -# cannot be parsed according to the syntax (e.g., have a length -# extending beyond the message boundary or contain an out-of-range -# length) MUST terminate the connection with a "decode_error" alert. -# Peers which receive a message which is syntactically correct but -# semantically invalid (e.g., a DHE share of p - 1, or an invalid enum) -# MUST terminate the connection with an "illegal_parameter" alert. +# Note: TLS defines two generic alerts (see Section 6) to use upon +# failure to parse a message. Peers which receive a message which +# cannot be parsed according to the syntax (e.g., have a length +# extending beyond the message boundary or contain an out-of-range +# length) MUST terminate the connection with a "decode_error" alert. +# Peers which receive a message which is syntactically correct but +# semantically invalid (e.g., a DHE share of p - 1, or an invalid enum) +# MUST terminate the connection with an "illegal_parameter" alert. # -# enum { warning(1), fatal(2), (255) } AlertLevel; +# enum { warning(1), fatal(2), (255) } AlertLevel; # -# enum { -# close_notify(0), -# unexpected_message(10), -# bad_record_mac(20), -# record_overflow(22), -# handshake_failure(40), -# bad_certificate(42), -# unsupported_certificate(43), -# certificate_revoked(44), -# certificate_expired(45), -# certificate_unknown(46), -# illegal_parameter(47), -# unknown_ca(48), -# access_denied(49), -# decode_error(50), -# decrypt_error(51), -# protocol_version(70), -# insufficient_security(71), -# internal_error(80), -# inappropriate_fallback(86), -# user_canceled(90), -# missing_extension(109), -# unsupported_extension(110), -# unrecognized_name(112), -# bad_certificate_status_response(113), -# unknown_psk_identity(115), -# certificate_required(116), -# no_application_protocol(120), -# (255) -# } AlertDescription; +# enum { +# close_notify(0), +# unexpected_message(10), +# bad_record_mac(20), +# record_overflow(22), +# handshake_failure(40), +# bad_certificate(42), +# unsupported_certificate(43), +# certificate_revoked(44), +# certificate_expired(45), +# certificate_unknown(46), +# illegal_parameter(47), +# unknown_ca(48), +# access_denied(49), +# decode_error(50), +# decrypt_error(51), +# protocol_version(70), +# insufficient_security(71), +# internal_error(80), +# inappropriate_fallback(86), +# user_canceled(90), +# missing_extension(109), +# unsupported_extension(110), +# unrecognized_name(112), +# bad_certificate_status_response(113), +# unknown_psk_identity(115), +# certificate_required(116), +# no_application_protocol(120), +# (255) +# } AlertDescription; # -# struct { -# AlertLevel level; -# AlertDescription description; -# } Alert; +# struct { +# AlertLevel level; +# AlertDescription description; +# } Alert; [[spec]] level = "SHOULD" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-7.1.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-7.1.toml index 2e3eebca6c0..cb4869f62da 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-7.1.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-7.1.toml @@ -1,138 +1,138 @@ target = "https://www.rfc-editor.org/rfc/rfc8446#section-7.1" -# 7.1. Key Schedule +# Key Schedule # -# The key derivation process makes use of the HKDF-Extract and -# HKDF-Expand functions as defined for HKDF [RFC5869], as well as the -# functions defined below: -# -# HKDF-Expand-Label(Secret, Label, Context, Length) = -# HKDF-Expand(Secret, HkdfLabel, Length) -# -# Where HkdfLabel is specified as: -# -# struct { -# uint16 length = Length; -# opaque label<7..255> = "tls13 " + Label; -# opaque context<0..255> = Context; -# } HkdfLabel; -# -# Derive-Secret(Secret, Label, Messages) = -# HKDF-Expand-Label(Secret, Label, -# Transcript-Hash(Messages), Hash.length) -# -# The Hash function used by Transcript-Hash and HKDF is the cipher -# suite hash algorithm. Hash.length is its output length in bytes. -# Messages is the concatenation of the indicated handshake messages, -# including the handshake message type and length fields, but not -# including record layer headers. Note that in some cases a zero- -# length Context (indicated by "") is passed to HKDF-Expand-Label. The -# labels specified in this document are all ASCII strings and do not -# include a trailing NUL byte. -# -# Note: With common hash functions, any label longer than 12 characters -# requires an additional iteration of the hash function to compute. -# The labels in this specification have all been chosen to fit within -# this limit. -# -# Keys are derived from two input secrets using the HKDF-Extract and -# Derive-Secret functions. The general pattern for adding a new secret -# is to use HKDF-Extract with the Salt being the current secret state -# and the Input Keying Material (IKM) being the new secret to be added. -# In this version of TLS 1.3, the two input secrets are: -# -# - PSK (a pre-shared key established externally or derived from the -# resumption_master_secret value from a previous connection) -# -# - (EC)DHE shared secret (Section 7.4) -# -# This produces a full key derivation schedule shown in the diagram -# below. In this diagram, the following formatting conventions apply: -# -# - HKDF-Extract is drawn as taking the Salt argument from the top and -# the IKM argument from the left, with its output to the bottom and -# the name of the output on the right. -# -# - Derive-Secret's Secret argument is indicated by the incoming -# arrow. For instance, the Early Secret is the Secret for -# generating the client_early_traffic_secret. -# -# - "0" indicates a string of Hash.length bytes set to zero. -# -# 0 -# | -# v -# PSK -> HKDF-Extract = Early Secret -# | -# +-----> Derive-Secret(., "ext binder" | "res binder", "") -# | = binder_key -# | -# +-----> Derive-Secret(., "c e traffic", ClientHello) -# | = client_early_traffic_secret -# | -# +-----> Derive-Secret(., "e exp master", ClientHello) -# | = early_exporter_master_secret -# v -# Derive-Secret(., "derived", "") -# | -# v -# (EC)DHE -> HKDF-Extract = Handshake Secret -# | -# +-----> Derive-Secret(., "c hs traffic", -# | ClientHello...ServerHello) -# | = client_handshake_traffic_secret -# | -# +-----> Derive-Secret(., "s hs traffic", -# | ClientHello...ServerHello) -# | = server_handshake_traffic_secret -# v -# Derive-Secret(., "derived", "") -# | -# v -# 0 -> HKDF-Extract = Master Secret -# | -# +-----> Derive-Secret(., "c ap traffic", -# | ClientHello...server Finished) -# | = client_application_traffic_secret_0 -# | -# +-----> Derive-Secret(., "s ap traffic", -# | ClientHello...server Finished) -# | = server_application_traffic_secret_0 -# | -# +-----> Derive-Secret(., "exp master", -# | ClientHello...server Finished) -# | = exporter_master_secret -# | -# +-----> Derive-Secret(., "res master", -# ClientHello...client Finished) -# = resumption_master_secret -# -# The general pattern here is that the secrets shown down the left side -# of the diagram are just raw entropy without context, whereas the -# secrets down the right side include Handshake Context and therefore -# can be used to derive working keys without additional context. Note -# that the different calls to Derive-Secret may take different Messages -# arguments, even with the same secret. In a 0-RTT exchange, -# Derive-Secret is called with four distinct transcripts; in a -# 1-RTT-only exchange, it is called with three distinct transcripts. -# -# If a given secret is not available, then the 0-value consisting of a -# string of Hash.length bytes set to zeros is used. Note that this -# does not mean skipping rounds, so if PSK is not in use, Early Secret -# will still be HKDF-Extract(0, 0). For the computation of the -# binder_key, the label is "ext binder" for external PSKs (those -# provisioned outside of TLS) and "res binder" for resumption PSKs -# (those provisioned as the resumption master secret of a previous -# handshake). The different labels prevent the substitution of one -# type of PSK for the other. -# -# There are multiple potential Early Secret values, depending on which -# PSK the server ultimately selects. The client will need to compute -# one for each potential PSK; if no PSK is selected, it will then need -# to compute the Early Secret corresponding to the zero PSK. -# -# Once all the values which are to be derived from a given secret have -# been computed, that secret SHOULD be erased. +# The key derivation process makes use of the HKDF-Extract and +# HKDF-Expand functions as defined for HKDF [RFC5869], as well as the +# functions defined below: +# +# HKDF-Expand-Label(Secret, Label, Context, Length) = +# HKDF-Expand(Secret, HkdfLabel, Length) +# +# Where HkdfLabel is specified as: +# +# struct { +# uint16 length = Length; +# opaque label<7..255> = "tls13 " + Label; +# opaque context<0..255> = Context; +# } HkdfLabel; +# +# Derive-Secret(Secret, Label, Messages) = +# HKDF-Expand-Label(Secret, Label, +# Transcript-Hash(Messages), Hash.length) +# +# The Hash function used by Transcript-Hash and HKDF is the cipher +# suite hash algorithm. Hash.length is its output length in bytes. +# Messages is the concatenation of the indicated handshake messages, +# including the handshake message type and length fields, but not +# including record layer headers. Note that in some cases a zero- +# length Context (indicated by "") is passed to HKDF-Expand-Label. The +# labels specified in this document are all ASCII strings and do not +# include a trailing NUL byte. +# +# Note: With common hash functions, any label longer than 12 characters +# requires an additional iteration of the hash function to compute. +# The labels in this specification have all been chosen to fit within +# this limit. +# +# Keys are derived from two input secrets using the HKDF-Extract and +# Derive-Secret functions. The general pattern for adding a new secret +# is to use HKDF-Extract with the Salt being the current secret state +# and the Input Keying Material (IKM) being the new secret to be added. +# In this version of TLS 1.3, the two input secrets are: +# +# - PSK (a pre-shared key established externally or derived from the +# resumption_master_secret value from a previous connection) +# +# - (EC)DHE shared secret (Section 7.4) +# +# This produces a full key derivation schedule shown in the diagram +# below. In this diagram, the following formatting conventions apply: +# +# - HKDF-Extract is drawn as taking the Salt argument from the top and +# the IKM argument from the left, with its output to the bottom and +# the name of the output on the right. +# +# - Derive-Secret's Secret argument is indicated by the incoming +# arrow. For instance, the Early Secret is the Secret for +# generating the client_early_traffic_secret. +# +# - "0" indicates a string of Hash.length bytes set to zero. +# +# 0 +# | +# v +# PSK -> HKDF-Extract = Early Secret +# | +# +-----> Derive-Secret(., "ext binder" | "res binder", "") +# | = binder_key +# | +# +-----> Derive-Secret(., "c e traffic", ClientHello) +# | = client_early_traffic_secret +# | +# +-----> Derive-Secret(., "e exp master", ClientHello) +# | = early_exporter_master_secret +# v +# Derive-Secret(., "derived", "") +# | +# v +# (EC)DHE -> HKDF-Extract = Handshake Secret +# | +# +-----> Derive-Secret(., "c hs traffic", +# | ClientHello...ServerHello) +# | = client_handshake_traffic_secret +# | +# +-----> Derive-Secret(., "s hs traffic", +# | ClientHello...ServerHello) +# | = server_handshake_traffic_secret +# v +# Derive-Secret(., "derived", "") +# | +# v +# 0 -> HKDF-Extract = Master Secret +# | +# +-----> Derive-Secret(., "c ap traffic", +# | ClientHello...server Finished) +# | = client_application_traffic_secret_0 +# | +# +-----> Derive-Secret(., "s ap traffic", +# | ClientHello...server Finished) +# | = server_application_traffic_secret_0 +# | +# +-----> Derive-Secret(., "exp master", +# | ClientHello...server Finished) +# | = exporter_master_secret +# | +# +-----> Derive-Secret(., "res master", +# ClientHello...client Finished) +# = resumption_master_secret +# +# The general pattern here is that the secrets shown down the left side +# of the diagram are just raw entropy without context, whereas the +# secrets down the right side include Handshake Context and therefore +# can be used to derive working keys without additional context. Note +# that the different calls to Derive-Secret may take different Messages +# arguments, even with the same secret. In a 0-RTT exchange, +# Derive-Secret is called with four distinct transcripts; in a +# 1-RTT-only exchange, it is called with three distinct transcripts. +# +# If a given secret is not available, then the 0-value consisting of a +# string of Hash.length bytes set to zeros is used. Note that this +# does not mean skipping rounds, so if PSK is not in use, Early Secret +# will still be HKDF-Extract(0, 0). For the computation of the +# binder_key, the label is "ext binder" for external PSKs (those +# provisioned outside of TLS) and "res binder" for resumption PSKs +# (those provisioned as the resumption master secret of a previous +# handshake). The different labels prevent the substitution of one +# type of PSK for the other. +# +# There are multiple potential Early Secret values, depending on which +# PSK the server ultimately selects. The client will need to compute +# one for each potential PSK; if no PSK is selected, it will then need +# to compute the Early Secret corresponding to the zero PSK. +# +# Once all the values which are to be derived from a given secret have +# been computed, that secret SHOULD be erased. [[spec]] level = "SHOULD" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-7.2.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-7.2.toml index f729f7fb275..107c34c00af 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-7.2.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-7.2.toml @@ -1,25 +1,25 @@ target = "https://www.rfc-editor.org/rfc/rfc8446#section-7.2" -# 7.2. Updating Traffic Secrets +# Updating Traffic Secrets # -# Once the handshake is complete, it is possible for either side to -# update its sending traffic keys using the KeyUpdate handshake message -# defined in Section 4.6.3. The next generation of traffic keys is -# computed by generating client_/server_application_traffic_secret_N+1 -# from client_/server_application_traffic_secret_N as described in this -# section and then re-deriving the traffic keys as described in -# Section 7.3. +# Once the handshake is complete, it is possible for either side to +# update its sending traffic keys using the KeyUpdate handshake message +# defined in Section 4.6.3. The next generation of traffic keys is +# computed by generating client_/server_application_traffic_secret_N+1 +# from client_/server_application_traffic_secret_N as described in this +# section and then re-deriving the traffic keys as described in +# Section 7.3. # -# The next-generation application_traffic_secret is computed as: +# The next-generation application_traffic_secret is computed as: # -# application_traffic_secret_N+1 = -# HKDF-Expand-Label(application_traffic_secret_N, -# "traffic upd", "", Hash.length) +# application_traffic_secret_N+1 = +# HKDF-Expand-Label(application_traffic_secret_N, +# "traffic upd", "", Hash.length) # -# Once client_/server_application_traffic_secret_N+1 and its associated -# traffic keys have been computed, implementations SHOULD delete -# client_/server_application_traffic_secret_N and its associated -# traffic keys. +# Once client_/server_application_traffic_secret_N+1 and its associated +# traffic keys have been computed, implementations SHOULD delete +# client_/server_application_traffic_secret_N and its associated +# traffic keys. [[spec]] level = "SHOULD" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-7.4.2.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-7.4.2.toml index fabc3b07799..c4872947434 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-7.4.2.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-7.4.2.toml @@ -1,43 +1,43 @@ target = "https://www.rfc-editor.org/rfc/rfc8446#section-7.4.2" -# 7.4.2. Elliptic Curve Diffie-Hellman +# Elliptic Curve Diffie-Hellman # -# For secp256r1, secp384r1, and secp521r1, ECDH calculations (including -# parameter and key generation as well as the shared secret -# calculation) are performed according to [IEEE1363] using the -# ECKAS-DH1 scheme with the identity map as the key derivation function -# (KDF), so that the shared secret is the x-coordinate of the ECDH -# shared secret elliptic curve point represented as an octet string. -# Note that this octet string ("Z" in IEEE 1363 terminology) as output -# by FE2OSP (the Field Element to Octet String Conversion Primitive) -# has constant length for any given field; leading zeros found in this -# octet string MUST NOT be truncated. +# For secp256r1, secp384r1, and secp521r1, ECDH calculations (including +# parameter and key generation as well as the shared secret +# calculation) are performed according to [IEEE1363] using the +# ECKAS-DH1 scheme with the identity map as the key derivation function +# (KDF), so that the shared secret is the x-coordinate of the ECDH +# shared secret elliptic curve point represented as an octet string. +# Note that this octet string ("Z" in IEEE 1363 terminology) as output +# by FE2OSP (the Field Element to Octet String Conversion Primitive) +# has constant length for any given field; leading zeros found in this +# octet string MUST NOT be truncated. # -# (Note that this use of the identity KDF is a technicality. The -# complete picture is that ECDH is employed with a non-trivial KDF -# because TLS does not directly use this secret for anything other than -# for computing other secrets.) +# (Note that this use of the identity KDF is a technicality. The +# complete picture is that ECDH is employed with a non-trivial KDF +# because TLS does not directly use this secret for anything other than +# for computing other secrets.) # -# For X25519 and X448, the ECDH calculations are as follows: +# For X25519 and X448, the ECDH calculations are as follows: # -# - The public key to put into the KeyShareEntry.key_exchange -# structure is the result of applying the ECDH scalar multiplication -# function to the secret key of appropriate length (into scalar -# input) and the standard public basepoint (into u-coordinate point -# input). +# - The public key to put into the KeyShareEntry.key_exchange +# structure is the result of applying the ECDH scalar multiplication +# function to the secret key of appropriate length (into scalar +# input) and the standard public basepoint (into u-coordinate point +# input). # -# - The ECDH shared secret is the result of applying the ECDH scalar -# multiplication function to the secret key (into scalar input) and -# the peer's public key (into u-coordinate point input). The output -# is used raw, with no processing. +# - The ECDH shared secret is the result of applying the ECDH scalar +# multiplication function to the secret key (into scalar input) and +# the peer's public key (into u-coordinate point input). The output +# is used raw, with no processing. # -# For these curves, implementations SHOULD use the approach specified -# in [RFC7748] to calculate the Diffie-Hellman shared secret. -# Implementations MUST check whether the computed Diffie-Hellman shared -# secret is the all-zero value and abort if so, as described in -# Section 6 of [RFC7748]. If implementors use an alternative -# implementation of these elliptic curves, they SHOULD perform the -# additional checks specified in Section 7 of [RFC7748]. +# For these curves, implementations SHOULD use the approach specified +# in [RFC7748] to calculate the Diffie-Hellman shared secret. +# Implementations MUST check whether the computed Diffie-Hellman shared +# secret is the all-zero value and abort if so, as described in +# Section 6 of [RFC7748]. If implementors use an alternative +# implementation of these elliptic curves, they SHOULD perform the +# additional checks specified in Section 7 of [RFC7748]. [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-7.5.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-7.5.toml index 262aceabbd9..73c42b6a7e3 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-7.5.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-7.5.toml @@ -1,40 +1,40 @@ target = "https://www.rfc-editor.org/rfc/rfc8446#section-7.5" -# 7.5. Exporters +# Exporters # -# [RFC5705] defines keying material exporters for TLS in terms of the -# TLS pseudorandom function (PRF). This document replaces the PRF with -# HKDF, thus requiring a new construction. The exporter interface -# remains the same. +# [RFC5705] defines keying material exporters for TLS in terms of the +# TLS pseudorandom function (PRF). This document replaces the PRF with +# HKDF, thus requiring a new construction. The exporter interface +# remains the same. # -# The exporter value is computed as: +# The exporter value is computed as: # -# TLS-Exporter(label, context_value, key_length) = -# HKDF-Expand-Label(Derive-Secret(Secret, label, ""), -# "exporter", Hash(context_value), key_length) +# TLS-Exporter(label, context_value, key_length) = +# HKDF-Expand-Label(Derive-Secret(Secret, label, ""), +# "exporter", Hash(context_value), key_length) # -# Where Secret is either the early_exporter_master_secret or the -# exporter_master_secret. Implementations MUST use the -# exporter_master_secret unless explicitly specified by the -# application. The early_exporter_master_secret is defined for use in -# settings where an exporter is needed for 0-RTT data. A separate -# interface for the early exporter is RECOMMENDED; this avoids the -# exporter user accidentally using an early exporter when a regular one -# is desired or vice versa. +# Where Secret is either the early_exporter_master_secret or the +# exporter_master_secret. Implementations MUST use the +# exporter_master_secret unless explicitly specified by the +# application. The early_exporter_master_secret is defined for use in +# settings where an exporter is needed for 0-RTT data. A separate +# interface for the early exporter is RECOMMENDED; this avoids the +# exporter user accidentally using an early exporter when a regular one +# is desired or vice versa. # -# If no context is provided, the context_value is zero length. -# Consequently, providing no context computes the same value as -# providing an empty context. This is a change from previous versions -# of TLS where an empty context produced a different output than an -# absent context. As of this document's publication, no allocated -# exporter label is used both with and without a context. Future -# specifications MUST NOT define a use of exporters that permit both an -# empty context and no context with the same label. New uses of -# exporters SHOULD provide a context in all exporter computations, -# though the value could be empty. +# If no context is provided, the context_value is zero length. +# Consequently, providing no context computes the same value as +# providing an empty context. This is a change from previous versions +# of TLS where an empty context produced a different output than an +# absent context. As of this document's publication, no allocated +# exporter label is used both with and without a context. Future +# specifications MUST NOT define a use of exporters that permit both an +# empty context and no context with the same label. New uses of +# exporters SHOULD provide a context in all exporter computations, +# though the value could be empty. # -# Requirements for the format of exporter labels are defined in -# Section 4 of [RFC5705]. +# Requirements for the format of exporter labels are defined in +# Section 4 of [RFC5705]. [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-8.2.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-8.2.toml index 804defaaf45..96895cd2472 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-8.2.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-8.2.toml @@ -1,71 +1,71 @@ target = "https://www.rfc-editor.org/rfc/rfc8446#section-8.2" -# 8.2. Client Hello Recording +# Client Hello Recording # -# An alternative form of anti-replay is to record a unique value -# derived from the ClientHello (generally either the random value or -# the PSK binder) and reject duplicates. Recording all ClientHellos -# causes state to grow without bound, but a server can instead record -# ClientHellos within a given time window and use the -# "obfuscated_ticket_age" to ensure that tickets aren't reused outside -# that window. +# An alternative form of anti-replay is to record a unique value +# derived from the ClientHello (generally either the random value or +# the PSK binder) and reject duplicates. Recording all ClientHellos +# causes state to grow without bound, but a server can instead record +# ClientHellos within a given time window and use the +# "obfuscated_ticket_age" to ensure that tickets aren't reused outside +# that window. # -# In order to implement this, when a ClientHello is received, the -# server first verifies the PSK binder as described in Section 4.2.11. -# It then computes the expected_arrival_time as described in the next -# section and rejects 0-RTT if it is outside the recording window, -# falling back to the 1-RTT handshake. +# In order to implement this, when a ClientHello is received, the +# server first verifies the PSK binder as described in Section 4.2.11. +# It then computes the expected_arrival_time as described in the next +# section and rejects 0-RTT if it is outside the recording window, +# falling back to the 1-RTT handshake. # -# If the expected_arrival_time is in the window, then the server checks -# to see if it has recorded a matching ClientHello. If one is found, -# it either aborts the handshake with an "illegal_parameter" alert or -# accepts the PSK but rejects 0-RTT. If no matching ClientHello is -# found, then it accepts 0-RTT and then stores the ClientHello for as -# long as the expected_arrival_time is inside the window. Servers MAY -# also implement data stores with false positives, such as Bloom -# filters, in which case they MUST respond to apparent replay by -# rejecting 0-RTT but MUST NOT abort the handshake. +# If the expected_arrival_time is in the window, then the server checks +# to see if it has recorded a matching ClientHello. If one is found, +# it either aborts the handshake with an "illegal_parameter" alert or +# accepts the PSK but rejects 0-RTT. If no matching ClientHello is +# found, then it accepts 0-RTT and then stores the ClientHello for as +# long as the expected_arrival_time is inside the window. Servers MAY +# also implement data stores with false positives, such as Bloom +# filters, in which case they MUST respond to apparent replay by +# rejecting 0-RTT but MUST NOT abort the handshake. # -# The server MUST derive the storage key only from validated sections -# of the ClientHello. If the ClientHello contains multiple PSK -# identities, then an attacker can create multiple ClientHellos with -# different binder values for the less-preferred identity on the -# assumption that the server will not verify it (as recommended by -# Section 4.2.11). I.e., if the client sends PSKs A and B but the -# server prefers A, then the attacker can change the binder for B -# without affecting the binder for A. If the binder for B is part of -# the storage key, then this ClientHello will not appear as a -# duplicate, which will cause the ClientHello to be accepted, and may -# cause side effects such as replay cache pollution, although any 0-RTT -# data will not be decryptable because it will use different keys. If -# the validated binder or the ClientHello.random is used as the storage -# key, then this attack is not possible. +# The server MUST derive the storage key only from validated sections +# of the ClientHello. If the ClientHello contains multiple PSK +# identities, then an attacker can create multiple ClientHellos with +# different binder values for the less-preferred identity on the +# assumption that the server will not verify it (as recommended by +# Section 4.2.11). I.e., if the client sends PSKs A and B but the +# server prefers A, then the attacker can change the binder for B +# without affecting the binder for A. If the binder for B is part of +# the storage key, then this ClientHello will not appear as a +# duplicate, which will cause the ClientHello to be accepted, and may +# cause side effects such as replay cache pollution, although any 0-RTT +# data will not be decryptable because it will use different keys. If +# the validated binder or the ClientHello.random is used as the storage +# key, then this attack is not possible. # -# Because this mechanism does not require storing all outstanding -# tickets, it may be easier to implement in distributed systems with -# high rates of resumption and 0-RTT, at the cost of potentially weaker -# anti-replay defense because of the difficulty of reliably storing and -# retrieving the received ClientHello messages. In many such systems, -# it is impractical to have globally consistent storage of all the -# received ClientHellos. In this case, the best anti-replay protection -# is provided by having a single storage zone be authoritative for a -# given ticket and refusing 0-RTT for that ticket in any other zone. -# This approach prevents simple replay by the attacker because only one -# zone will accept 0-RTT data. A weaker design is to implement -# separate storage for each zone but allow 0-RTT in any zone. This -# approach limits the number of replays to once per zone. Application -# message duplication of course remains possible with either design. +# Because this mechanism does not require storing all outstanding +# tickets, it may be easier to implement in distributed systems with +# high rates of resumption and 0-RTT, at the cost of potentially weaker +# anti-replay defense because of the difficulty of reliably storing and +# retrieving the received ClientHello messages. In many such systems, +# it is impractical to have globally consistent storage of all the +# received ClientHellos. In this case, the best anti-replay protection +# is provided by having a single storage zone be authoritative for a +# given ticket and refusing 0-RTT for that ticket in any other zone. +# This approach prevents simple replay by the attacker because only one +# zone will accept 0-RTT data. A weaker design is to implement +# separate storage for each zone but allow 0-RTT in any zone. This +# approach limits the number of replays to once per zone. Application +# message duplication of course remains possible with either design. # -# When implementations are freshly started, they SHOULD reject 0-RTT as -# long as any portion of their recording window overlaps the startup -# time. Otherwise, they run the risk of accepting replays which were -# originally sent during that period. +# When implementations are freshly started, they SHOULD reject 0-RTT as +# long as any portion of their recording window overlaps the startup +# time. Otherwise, they run the risk of accepting replays which were +# originally sent during that period. # -# Note: If the client's clock is running much faster than the server's, -# then a ClientHello may be received that is outside the window in the -# future, in which case it might be accepted for 1-RTT, causing a -# client retry, and then acceptable later for 0-RTT. This is another -# variant of the second form of attack described in Section 8. +# Note: If the client's clock is running much faster than the server's, +# then a ClientHello may be received that is outside the window in the +# future, in which case it might be accepted for 1-RTT, causing a +# client retry, and then acceptable later for 0-RTT. This is another +# variant of the second form of attack described in Section 8. [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-8.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-8.toml index 2b902daf5ab..159c1f94309 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-8.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-8.toml @@ -1,61 +1,61 @@ target = "https://www.rfc-editor.org/rfc/rfc8446#section-8" -# 8. 0-RTT and Anti-Replay +# 0-RTT and Anti-Replay # -# As noted in Section 2.3 and Appendix E.5, TLS does not provide -# inherent replay protections for 0-RTT data. There are two potential -# threats to be concerned with: +# As noted in Section 2.3 and Appendix E.5, TLS does not provide +# inherent replay protections for 0-RTT data. There are two potential +# threats to be concerned with: # -# - Network attackers who mount a replay attack by simply duplicating -# a flight of 0-RTT data. +# - Network attackers who mount a replay attack by simply duplicating +# a flight of 0-RTT data. # -# - Network attackers who take advantage of client retry behavior to -# arrange for the server to receive multiple copies of an -# application message. This threat already exists to some extent -# because clients that value robustness respond to network errors by -# attempting to retry requests. However, 0-RTT adds an additional -# dimension for any server system which does not maintain globally -# consistent server state. Specifically, if a server system has -# multiple zones where tickets from zone A will not be accepted in -# zone B, then an attacker can duplicate a ClientHello and early -# data intended for A to both A and B. At A, the data will be -# accepted in 0-RTT, but at B the server will reject 0-RTT data and -# instead force a full handshake. If the attacker blocks the -# ServerHello from A, then the client will complete the handshake -# with B and probably retry the request, leading to duplication on -# the server system as a whole. +# - Network attackers who take advantage of client retry behavior to +# arrange for the server to receive multiple copies of an +# application message. This threat already exists to some extent +# because clients that value robustness respond to network errors by +# attempting to retry requests. However, 0-RTT adds an additional +# dimension for any server system which does not maintain globally +# consistent server state. Specifically, if a server system has +# multiple zones where tickets from zone A will not be accepted in +# zone B, then an attacker can duplicate a ClientHello and early +# data intended for A to both A and B. At A, the data will be +# accepted in 0-RTT, but at B the server will reject 0-RTT data and +# instead force a full handshake. If the attacker blocks the +# ServerHello from A, then the client will complete the handshake +# with B and probably retry the request, leading to duplication on +# the server system as a whole. # -# The first class of attack can be prevented by sharing state to -# guarantee that the 0-RTT data is accepted at most once. Servers -# SHOULD provide that level of replay safety by implementing one of the -# methods described in this section or by equivalent means. It is -# understood, however, that due to operational concerns not all -# deployments will maintain state at that level. Therefore, in normal -# operation, clients will not know which, if any, of these mechanisms -# servers actually implement and hence MUST only send early data which -# they deem safe to be replayed. +# The first class of attack can be prevented by sharing state to +# guarantee that the 0-RTT data is accepted at most once. Servers +# SHOULD provide that level of replay safety by implementing one of the +# methods described in this section or by equivalent means. It is +# understood, however, that due to operational concerns not all +# deployments will maintain state at that level. Therefore, in normal +# operation, clients will not know which, if any, of these mechanisms +# servers actually implement and hence MUST only send early data which +# they deem safe to be replayed. # -# In addition to the direct effects of replays, there is a class of -# attacks where even operations normally considered idempotent could be -# exploited by a large number of replays (timing attacks, resource -# limit exhaustion and others, as described in Appendix E.5). Those -# can be mitigated by ensuring that every 0-RTT payload can be replayed -# only a limited number of times. The server MUST ensure that any -# instance of it (be it a machine, a thread, or any other entity within -# the relevant serving infrastructure) would accept 0-RTT for the same -# 0-RTT handshake at most once; this limits the number of replays to -# the number of server instances in the deployment. Such a guarantee -# can be accomplished by locally recording data from recently received -# ClientHellos and rejecting repeats, or by any other method that +# In addition to the direct effects of replays, there is a class of +# attacks where even operations normally considered idempotent could be +# exploited by a large number of replays (timing attacks, resource +# limit exhaustion and others, as described in Appendix E.5). Those +# can be mitigated by ensuring that every 0-RTT payload can be replayed +# only a limited number of times. The server MUST ensure that any +# instance of it (be it a machine, a thread, or any other entity within +# the relevant serving infrastructure) would accept 0-RTT for the same +# 0-RTT handshake at most once; this limits the number of replays to +# the number of server instances in the deployment. Such a guarantee +# can be accomplished by locally recording data from recently received +# ClientHellos and rejecting repeats, or by any other method that # -# provides the same or a stronger guarantee. The "at most once per -# server instance" guarantee is a minimum requirement; servers SHOULD -# limit 0-RTT replays further when feasible. +# provides the same or a stronger guarantee. The "at most once per +# server instance" guarantee is a minimum requirement; servers SHOULD +# limit 0-RTT replays further when feasible. # -# The second class of attack cannot be prevented at the TLS layer and -# MUST be dealt with by any application. Note that any application -# whose clients implement any kind of retry behavior already needs to -# implement some sort of anti-replay defense. +# The second class of attack cannot be prevented at the TLS layer and +# MUST be dealt with by any application. Note that any application +# whose clients implement any kind of retry behavior already needs to +# implement some sort of anti-replay defense. [[spec]] level = "SHOULD" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-9.1.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-9.1.toml index 2e670ddc065..fdcad99359b 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-9.1.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-9.1.toml @@ -1,20 +1,20 @@ target = "https://www.rfc-editor.org/rfc/rfc8446#section-9.1" -# 9.1. Mandatory-to-Implement Cipher Suites +# Mandatory-to-Implement Cipher Suites # -# In the absence of an application profile standard specifying -# otherwise: +# In the absence of an application profile standard specifying +# otherwise: # -# A TLS-compliant application MUST implement the TLS_AES_128_GCM_SHA256 -# [GCM] cipher suite and SHOULD implement the TLS_AES_256_GCM_SHA384 -# [GCM] and TLS_CHACHA20_POLY1305_SHA256 [RFC8439] cipher suites (see -# Appendix B.4). +# A TLS-compliant application MUST implement the TLS_AES_128_GCM_SHA256 +# [GCM] cipher suite and SHOULD implement the TLS_AES_256_GCM_SHA384 +# [GCM] and TLS_CHACHA20_POLY1305_SHA256 [RFC8439] cipher suites (see +# Appendix B.4). # -# A TLS-compliant application MUST support digital signatures with -# rsa_pkcs1_sha256 (for certificates), rsa_pss_rsae_sha256 (for -# CertificateVerify and certificates), and ecdsa_secp256r1_sha256. A -# TLS-compliant application MUST support key exchange with secp256r1 -# (NIST P-256) and SHOULD support key exchange with X25519 [RFC7748]. +# A TLS-compliant application MUST support digital signatures with +# rsa_pkcs1_sha256 (for certificates), rsa_pss_rsae_sha256 (for +# CertificateVerify and certificates), and ecdsa_secp256r1_sha256. A +# TLS-compliant application MUST support key exchange with secp256r1 +# (NIST P-256) and SHOULD support key exchange with X25519 [RFC7748]. [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-9.2.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-9.2.toml index 8bcedb8c6b9..ea9f98667ff 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-9.2.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-9.2.toml @@ -1,66 +1,66 @@ target = "https://www.rfc-editor.org/rfc/rfc8446#section-9.2" -# 9.2. Mandatory-to-Implement Extensions +# Mandatory-to-Implement Extensions # -# In the absence of an application profile standard specifying -# otherwise, a TLS-compliant application MUST implement the following -# TLS extensions: +# In the absence of an application profile standard specifying +# otherwise, a TLS-compliant application MUST implement the following +# TLS extensions: # -# - Supported Versions ("supported_versions"; Section 4.2.1) +# - Supported Versions ("supported_versions"; Section 4.2.1) # -# - Cookie ("cookie"; Section 4.2.2) +# - Cookie ("cookie"; Section 4.2.2) # -# - Signature Algorithms ("signature_algorithms"; Section 4.2.3) +# - Signature Algorithms ("signature_algorithms"; Section 4.2.3) # -# - Signature Algorithms Certificate ("signature_algorithms_cert"; -# Section 4.2.3) +# - Signature Algorithms Certificate ("signature_algorithms_cert"; +# Section 4.2.3) # -# - Negotiated Groups ("supported_groups"; Section 4.2.7) +# - Negotiated Groups ("supported_groups"; Section 4.2.7) # -# - Key Share ("key_share"; Section 4.2.8) +# - Key Share ("key_share"; Section 4.2.8) # -# - Server Name Indication ("server_name"; Section 3 of [RFC6066]) +# - Server Name Indication ("server_name"; Section 3 of [RFC6066]) # -# All implementations MUST send and use these extensions when offering -# applicable features: +# All implementations MUST send and use these extensions when offering +# applicable features: # -# - "supported_versions" is REQUIRED for all ClientHello, ServerHello, -# and HelloRetryRequest messages. +# - "supported_versions" is REQUIRED for all ClientHello, ServerHello, +# and HelloRetryRequest messages. # -# - "signature_algorithms" is REQUIRED for certificate authentication. +# - "signature_algorithms" is REQUIRED for certificate authentication. # -# - "supported_groups" is REQUIRED for ClientHello messages using DHE -# or ECDHE key exchange. +# - "supported_groups" is REQUIRED for ClientHello messages using DHE +# or ECDHE key exchange. # -# - "key_share" is REQUIRED for DHE or ECDHE key exchange. +# - "key_share" is REQUIRED for DHE or ECDHE key exchange. # -# - "pre_shared_key" is REQUIRED for PSK key agreement. +# - "pre_shared_key" is REQUIRED for PSK key agreement. # -# - "psk_key_exchange_modes" is REQUIRED for PSK key agreement. +# - "psk_key_exchange_modes" is REQUIRED for PSK key agreement. # -# A client is considered to be attempting to negotiate using this -# specification if the ClientHello contains a "supported_versions" -# extension with 0x0304 contained in its body. Such a ClientHello -# message MUST meet the following requirements: +# A client is considered to be attempting to negotiate using this +# specification if the ClientHello contains a "supported_versions" +# extension with 0x0304 contained in its body. Such a ClientHello +# message MUST meet the following requirements: # -# - If not containing a "pre_shared_key" extension, it MUST contain -# both a "signature_algorithms" extension and a "supported_groups" -# extension. +# - If not containing a "pre_shared_key" extension, it MUST contain +# both a "signature_algorithms" extension and a "supported_groups" +# extension. # -# - If containing a "supported_groups" extension, it MUST also contain -# a "key_share" extension, and vice versa. An empty -# KeyShare.client_shares vector is permitted. +# - If containing a "supported_groups" extension, it MUST also contain +# a "key_share" extension, and vice versa. An empty +# KeyShare.client_shares vector is permitted. # -# Servers receiving a ClientHello which does not conform to these -# requirements MUST abort the handshake with a "missing_extension" -# alert. +# Servers receiving a ClientHello which does not conform to these +# requirements MUST abort the handshake with a "missing_extension" +# alert. # -# Additionally, all implementations MUST support the use of the -# "server_name" extension with applications capable of using it. -# Servers MAY require clients to send a valid "server_name" extension. -# Servers requiring this extension SHOULD respond to a ClientHello -# lacking a "server_name" extension by terminating the connection with -# a "missing_extension" alert. +# Additionally, all implementations MUST support the use of the +# "server_name" extension with applications capable of using it. +# Servers MAY require clients to send a valid "server_name" extension. +# Servers requiring this extension SHOULD respond to a ClientHello +# lacking a "server_name" extension by terminating the connection with +# a "missing_extension" alert. [[spec]] level = "MUST" diff --git a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-9.3.toml b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-9.3.toml index 8bfcef37211..e082a730674 100644 --- a/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-9.3.toml +++ b/.duvet/requirements/www.rfc-editor.org/rfc/rfc8446/section-9.3.toml @@ -1,64 +1,64 @@ target = "https://www.rfc-editor.org/rfc/rfc8446#section-9.3" -# 9.3. Protocol Invariants +# Protocol Invariants # -# This section describes invariants that TLS endpoints and middleboxes -# MUST follow. It also applies to earlier versions of TLS. +# This section describes invariants that TLS endpoints and middleboxes +# MUST follow. It also applies to earlier versions of TLS. # -# TLS is designed to be securely and compatibly extensible. Newer -# clients or servers, when communicating with newer peers, should -# negotiate the most preferred common parameters. The TLS handshake -# provides downgrade protection: Middleboxes passing traffic between a -# newer client and newer server without terminating TLS should be -# unable to influence the handshake (see Appendix E.1). At the same -# time, deployments update at different rates, so a newer client or -# server MAY continue to support older parameters, which would allow it -# to interoperate with older endpoints. +# TLS is designed to be securely and compatibly extensible. Newer +# clients or servers, when communicating with newer peers, should +# negotiate the most preferred common parameters. The TLS handshake +# provides downgrade protection: Middleboxes passing traffic between a +# newer client and newer server without terminating TLS should be +# unable to influence the handshake (see Appendix E.1). At the same +# time, deployments update at different rates, so a newer client or +# server MAY continue to support older parameters, which would allow it +# to interoperate with older endpoints. # -# For this to work, implementations MUST correctly handle extensible -# fields: +# For this to work, implementations MUST correctly handle extensible +# fields: # -# - A client sending a ClientHello MUST support all parameters -# advertised in it. Otherwise, the server may fail to interoperate -# by selecting one of those parameters. +# - A client sending a ClientHello MUST support all parameters +# advertised in it. Otherwise, the server may fail to interoperate +# by selecting one of those parameters. # -# - A server receiving a ClientHello MUST correctly ignore all -# unrecognized cipher suites, extensions, and other parameters. -# Otherwise, it may fail to interoperate with newer clients. In -# TLS 1.3, a client receiving a CertificateRequest or -# NewSessionTicket MUST also ignore all unrecognized extensions. +# - A server receiving a ClientHello MUST correctly ignore all +# unrecognized cipher suites, extensions, and other parameters. +# Otherwise, it may fail to interoperate with newer clients. In +# TLS 1.3, a client receiving a CertificateRequest or +# NewSessionTicket MUST also ignore all unrecognized extensions. # -# - A middlebox which terminates a TLS connection MUST behave as a -# compliant TLS server (to the original client), including having a -# certificate which the client is willing to accept, and also as a -# compliant TLS client (to the original server), including verifying -# the original server's certificate. In particular, it MUST -# generate its own ClientHello containing only parameters it -# understands, and it MUST generate a fresh ServerHello random -# value, rather than forwarding the endpoint's value. +# - A middlebox which terminates a TLS connection MUST behave as a +# compliant TLS server (to the original client), including having a +# certificate which the client is willing to accept, and also as a +# compliant TLS client (to the original server), including verifying +# the original server's certificate. In particular, it MUST +# generate its own ClientHello containing only parameters it +# understands, and it MUST generate a fresh ServerHello random +# value, rather than forwarding the endpoint's value. # -# Note that TLS's protocol requirements and security analysis only -# apply to the two connections separately. Safely deploying a TLS -# terminator requires additional security considerations which are -# beyond the scope of this document. +# Note that TLS's protocol requirements and security analysis only +# apply to the two connections separately. Safely deploying a TLS +# terminator requires additional security considerations which are +# beyond the scope of this document. # -# - A middlebox which forwards ClientHello parameters it does not -# understand MUST NOT process any messages beyond that ClientHello. -# It MUST forward all subsequent traffic unmodified. Otherwise, it -# may fail to interoperate with newer clients and servers. +# - A middlebox which forwards ClientHello parameters it does not +# understand MUST NOT process any messages beyond that ClientHello. +# It MUST forward all subsequent traffic unmodified. Otherwise, it +# may fail to interoperate with newer clients and servers. # -# Forwarded ClientHellos may contain advertisements for features not -# supported by the middlebox, so the response may include future TLS -# additions the middlebox does not recognize. These additions MAY -# change any message beyond the ClientHello arbitrarily. In -# particular, the values sent in the ServerHello might change, the -# ServerHello format might change, and the TLSCiphertext format -# might change. +# Forwarded ClientHellos may contain advertisements for features not +# supported by the middlebox, so the response may include future TLS +# additions the middlebox does not recognize. These additions MAY +# change any message beyond the ClientHello arbitrarily. In +# particular, the values sent in the ServerHello might change, the +# ServerHello format might change, and the TLSCiphertext format +# might change. # -# The design of TLS 1.3 was constrained by widely deployed -# non-compliant TLS middleboxes (see Appendix D.4); however, it does -# not relax the invariants. Those middleboxes continue to be -# non-compliant. +# The design of TLS 1.3 was constrained by widely deployed +# non-compliant TLS middleboxes (see Appendix D.4); however, it does +# not relax the invariants. Those middleboxes continue to be +# non-compliant. [[spec]] level = "MUST"