jiebi/CodeConvo huggingface dataset:
The server operator can only use TLS signature schemes for which the CA will issue credentials. <del> These dependencies cause problems in practice.  Server operators often deploy TLS termination services in locations such as remote data centers or Content Delivery Networks (CDNs) where it may be difficult to detect key compromises.  Short-lived certificates may be used to limit the exposure of keys in these cases. However, short-lived certificates need to be renewed more frequently than long-lived certificates.  If an external CA is unable to issue a certificate in time to replace a deployed certificate, the server would no longer be able to present a valid certificate to clients. With short-lived certificates, there is a smaller window of time to renew a certificates and therefore a higher risk that an outage at a CA will negatively affect the uptime of the service. </del> To reduce the dependency on external CAs, this document proposes a limited delegation mechanism that allows a TLS peer to issue its own credentials within the scope of a certificate issued by an external
A client which supports this document SHALL send an empty "delegated_credential" extension in its ClientHello.  If the client receives a delegated credential without indicating support, then the <del> client SHOULD abort with an "unexpected_message" alert. </del> <ins> client MUST abort with an "unexpected_message" alert. </ins> If the extension is present, the server MAY send a delegated <del> credential extension.  If the extension is not present, the server MUST NOT send a credential.  A credential MUST NOT be provided unless a Certificate message is also sent.  The server MUST ignore the extension unless TLS 1.2 or later is negotiated. When negotiating TLS 1.3, and using delegated credentials, the server MUST send the delegated credential as an extension in the CertificateEntry of its end-entity certificate; the client SHOULD ignore delegated credentials sent as extensions with any other certificate.  When negotiating TLS 1.2, the delegated credential MUST be sent as an extension in the ServerHello. </del> <ins> credential extension; if the extension is not present, the server MUST NOT send a delegated credential.  A delegated credential MUST NOT be provided unless a Certificate message is also sent.  The server MUST ignore the extension unless TLS 1.2 or later is negotiated. When negotiating TLS 1.3, the server MUST send the delegated credential as an extension in the CertificateEntry of its end-entity certificate; the client SHOULD ignore delegated credentials sent as extensions to any other certificate.  When negotiating TLS 1.2, the delegated credential MUST be sent as an extension in the ServerHello. </ins> The delegated credential contains a signature from the public key in the end-entity certificate using a signature algorithm advertised by
type in RFC5280), but has the keyEncipherment and dataEncipherment usages are disabled. <ins> The extension MAY be marked crititcal.  (See Section 4.2 of RFC5280.) If the strict boolean is set to true, then the server MUST use delegated credential in the handshake; if no delegated credential is offered, then the client MUST abort the handshake with an "illegal_parameter" alert. </ins> 5. TBD
6.1. <ins> Marking the delegation certificate's DelegationUsage extension non- critical allows the certificate to be used for clients that do not support delegated credentials.  However, it may be desirable to ensure that the delegation certificate is only used in handshakes in which a delegated credential negotiated.  It suffices to mark the extension crticial and set the strict boolean to true: if the client does not support delegated credentials, then it will abort the handshake if the certificate has the DelegationUsage extension (as per Section 4.2 of RFC5280); if the client indicates support, but the server does not offer a delegated credential, then the client will abort the handshake (as per certificate-requirements). 6.2. </ins> Delegated credentials limit the exposure of the TLS private key by limiting its validity.  An attacker who compromises the private key of a delegated credential can act as a man in the middle until the
validity period.  In the absence of an application profile standard specifying otherwise, the maximum validity period is set to 7 days. Peers MUST NOT issue credentials with a validity period longer than <del> the maximum validity period.  This mechanism is described in detail in client-and-server-behavior. </del> <ins> the maximum validity period or that extends beyond the validity period of the delegation certificate.  This mechanism is described in detail in client-and-server-behavior. </ins> It was noted in XPROT that certificates in use by servers that support outdated protocols such as SSLv2 can be used to forge
"signature_algorithms" is REQUIRED for certificate authentication. <del> "supported_groups" and "key_share" are REQUIRED for DHE or ECDHE key exchange. </del> <ins> "supported_groups" is REQUIRED for ClientHello messages using DHE or ECDHE key exchange. "key_share" is REQUIRED for DHE or ECDHE key exchange. </ins> "pre_shared_key" is REQUIRED for PSK key agreement.
with B and probably retry the request, leading to duplication on the server system as a whole. <del> The first class of attack can be prevented by the mechanism described in this section.  Servers need not permit 0-RTT at all, but those which do SHOULD implement either the single-use tickets or ClientHello recording techniques described in the following two sections. </del> <ins> 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 described in replay-0rtt).  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. </ins> 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. <del> In normal operation, clients will not know which, if any, of these mechanisms servers actually implement and therefore MUST only send early data which they are willing to have subject to the attacks described in replay-0rtt. </del> 8.1. The simplest form of anti-replay defense is for the server to only
CertificateEntry. If the corresponding certificate type extension <del> ("server_certificate_type" or "client_certificate_type") was not used or the X.509 certificate type was negotiated, then each CertificateEntry contains an X.509 certificate.  The sender's certificate MUST come in the first CertificateEntry in the list. Each following certificate SHOULD directly certify one 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. </del> <ins> ("server_certificate_type" or "client_certificate_type") was not negotiated in Encrypted Extensions, or the X.509 certificate type was negotiated, then each CertificateEntry contains an X.509 certificate. The sender's certificate MUST come in the first CertificateEntry in the list.  Each following certificate SHOULD directly certify one 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. </ins> Note: Prior to TLS 1.3, "certificate_list" ordering required each certificate to certify the one immediately preceding it; however,
"key_share", "pre_shared_key", "psk_key_exchange_modes", "early_data", "cookie", "supported_versions", "certificate_authorities", "oid_filters", "post_handshake_auth", <del> and "signature_algorithms_certs", extensions with the values </del> <ins> and "signature_algorithms_cert", extensions with the values </ins> defined in this document and the Recommended value of "Yes". IANA [SHALL update/has updated] this registry to include a "TLS
associate an SNI value with the ticket.  Clients, however, SHOULD store the SNI with the PSK to fulfill the requirements of NSTMessage. <del> Implementor's note: 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., they are not in the PSK database or are 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. </del> <ins> 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., they are not in the PSK database or are 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 backwards compatibility is important, client provided, externally established PSKs SHOULD influence cipher suite selection. </ins> Prior to accepting PSK key establishment, the server MUST validate the corresponding binder value (see psk-binder below).  If this value
server has selected for the negotiated key exchange.  Servers MUST NOT send a KeyShareEntry for any group not indicated in the "supported_groups" extension and MUST NOT send a KeyShareEntry when <del> using the "psk_ke" PskKeyExchangeMode.  If a HelloRetryRequest was received by the client, the client MUST verify that the selected NamedGroup in the ServerHello is the same as that in the </del> <ins> 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 </ins> HelloRetryRequest.  If this check fails, the client MUST abort the handshake with an "illegal_parameter" alert.
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 <del> that corresponds to that PSK.  See [client-hello-recording] 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. </del> <ins> that corresponds to that PSK.  See [client-hello-recording] and [psk- identity-exposure] 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. </ins> Clients MUST verify that the server's selected_identity is within the range supplied by the client, that the server selected a cipher suite
not specify how protocols add security with TLS; how to initiate TLS handshaking and how to interpret the authentication certificates exchanged are left to the judgment of the designers and implementors <del> of protocols that run on top of TLS. </del> <ins> of protocols that run on top of TLS.  Application protocols using TLS MUST specify how TLS works with their application protocol, including how and when handshaking occurs, and how to do identity verification. I-D.ietf-uta-rfc6125bis provides useful guidance on integrating TLS with applicaiton protocols. </ins> This document defines TLS version 1.3.  While TLS 1.3 is not directly compatible with previous versions, all versions of TLS incorporate a
digital signatures.  The "extension_data" field of this extension contains a "supported_signature_algorithms" value. <del> %%% Signature Algorithm Extension enum { none(0), md5(1), sha1(2), sha224(3), sha256(4), sha384(5), sha512(6), (255) } HashAlgorithm; </del> <ins> %%% Signature Algorithm Extension enum { none(0), md5_RESERVED(1), sha1(2), sha224_RESERVED(3), sha256(4), sha384(5), sha512(6), (255) } HashAlgorithm; </ins> Each SignatureAndHashAlgorithm value lists a single hash/signature pair that the client is willing to verify.  The values are indicated
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. <ins> The usage of MD5 and SHA-224 are deprecated.  The md5_RESERVED and sha224_RESERVED values MUST NOT be offered or negotiated by any implementation. </ins> This field indicates the signature algorithm that may be used.
appropriate rules. If the client supports only the default hash and signature algorithms <del> (listed in this section), it MAY omit the signature_algorithms </del> <ins> (listed in this section), it MAY omit the "signature_algorithms" </ins> 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 share), it MUST send the <del> signature_algorithms extension, listing the algorithms it is willing to accept. </del> <ins> "signature_algorithms" extension, listing the algorithms it is willing to accept. </ins> <del> If the client does not send the signature_algorithms extension, the </del> <ins> If the client does not send the "signature_algorithms" extension, the </ins> server MUST do the following: If the negotiated key exchange algorithm is one of (DHE_RSA,
The "extension_data" field of this extension SHALL contain a "NamedGroupList" value: <del> %%% Named Group Extension enum { // Elliptic Curve Groups.  sect163k1 (1), sect163r1 (2), sect163r2 (3), sect193r1 (4), sect193r2 (5), sect233k1 (6), sect233r1 (7), sect239k1 (8), sect283k1 (9), sect283r1 (10), sect409k1 (11), sect409r1 (12), sect571k1 (13), sect571r1 (14), secp160k1 (15), secp160r1 (16), secp160r2 (17), secp192k1 (18), secp192r1 (19), secp224k1 (20), secp224r1 (21), secp256k1 (22), secp256r1 (23), secp384r1 (24), secp521r1 (25), </del> <ins> %%% Named Group Extension enum { // Elliptic Curve Groups. obsolete_RESERVED (1..13), sect571r1 (14), obsolete_RESERVED (15..22), secp256r1 (23), secp384r1 (24), secp521r1 (25), </ins> <del> Indicates support of the corresponding named curve The named curves defined here are those specified in SEC 2 [13].  Note that many of these curves are also recommended in ANSI X9.62 X962 and FIPS 186-2 DSS.  Values 0xFE00 through 0xFEFF are reserved for private use.  Values 0xFF01 and 0xFF02 were used in previous versions of TLS but MUST NOT be offered by TLS 1.3 implementations.  [[OPEN ISSUE: Triage curve list.]] </del> <ins> Indicates support of the corresponding named curve.  Note that some curves are also recommended in ANSI X9.62 X962 and FIPS 186-2 DSS.  Values 0xFE00 through 0xFEFF are reserved for private use. </ins> Indicates support of the corresponding finite field group, defined <del> in </del> <ins> in I-D.ietf-tls-negotiated-ff-dhe.  Values 0x01FC through 0x01FF are reserved for private use. Values within "obsolete_RESERVED" ranges were used in previous versions of TLS and MUST NOT be offered or negotiated by TLS 1.3 implementations. </ins> Items in named_curve_list are ordered according to the client's preferences (favorite choice first). <del> As an example, a client that only supports secp192r1 (aka NIST P-192; value 19 = 0x0013) and secp224r1 (aka NIST P-224; value 21 = 0x0015) and prefers to use secp192r1 would include a TLS extension consisting </del> <ins> As an example, a client that only supports secp256r1 (aka NIST P-256; value 23 = 0x0017) and secp384r1 (aka NIST P-384; value 24 = 0x0018) and prefers to use secp256r1 would include a TLS extension consisting </ins> of the following octets.  Note that the first two octets indicate the extension type (Supported Group Extension):
generated. An AEAD cipher MUST NOT produce an expansion of greater than 256 <del> bytes.  An endpoint that receives a record that is larger than 2^14+256 octets MUST generate a fatal "record_overflow" alert. </del> <ins> bytes.  An endpoint that receives a record that is larger than 2^14 + 256 octets MUST generate a fatal "record_overflow" alert. </ins> As a special case, we define the NULL_NULL AEAD cipher which is simply the identity operation and thus provides no security.  This
A TLSCiphertext record was received that had a length more than <del> 2^14+256 bytes, or a record decrypted to a TLSPlaintext record </del> <ins> 2^14 + 256 bytes, or a record decrypted to a TLSPlaintext record </ins> with more than 2^14 bytes.  This alert is always fatal and should never be observed in communication between proper implementations (except when messages were corrupted in the network).
of the following octets.  Note that the first two octets indicate the extension type ("supported_groups" extension): <ins> As of TLS 1.3, servers are permitted to send the "supported_groups" extension to the client.  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.  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 offer to a server in subsequent connections. </ins> [[TODO: IANA Considerations.]] 6.3.2.3.
lacking a "server_name" extension with a fatal "missing_extension" alert. <del> Some of these extensions exist only for the client to provide additional data to the server in a backwards-compatible way and thus have no meaning when sent from a server.  The client-only extensions defined in this document are: "signature_algorithms" & "supported_groups".  Servers MUST NOT send these extensions.  Clients receiving any of these extensions MUST respond with a fatal </del> <ins> Servers MUST NOT send the "signature_algorithms" extension; if a client receives this extension it MUST respond with a fatal </ins> "unsupported_extension" alert and close the connection. 9.
The TLS handshake establishes one or more input secrets which are combined to create the actual working keying material, as detailed <del> below.  The key derivation process makes use of the following functions, based on HKDF RFC5869: </del> <ins> below.  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: </ins> Given a set of n InputSecrets, the final "master secret" is computed by iteratively invoking HKDF-Extract with InputSecret_1, <del> InputSecret_2, etc.  The initial secret is simply a string of 0s as long as the size of the Hash that is the basis for the HKDF. </del> <ins> InputSecret_2, etc.  The initial secret is simply a string of zeroes as long as the size of the Hash that is the basis for the HKDF. </ins> Concretely, for the present version of TLS 1.3, secrets are added in the following order:
Upon receipt of a HelloRetryRequest, the client MUST verify that the extensions block is not empty and otherwise MUST abort the handshake <del> with a "decode_error" alert.  Clients SHOULD abort the handshake with an "unexpected message" if the HelloRetryRequest would not result in any change in the ClientHello or in response to any second HelloRetryRequest which was sent in the same connection (i.e., where the ClientHello was itself in response to a HelloRetryRequest). </del> <ins> with a "decode_error" alert.  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. </ins> Otherwise, the client MUST process all extensions in the HelloRetryRequest and send a second updated ClientHello.  The
in the cookie, rather than requiring it to export the entire intermediate hash state (see cookie). <ins> For concreteness, the transcript hash is always taken from the following sequence of handshake messages, starting at the first ClientHello and including only those messages that were sent: ClientHello, HelloRetryRequest, ClientHello, ServerHello, EncryptedExtensions, Server CertificateRequest, Server Certificate, Server CertificateVerify, Server Finished, EndOfEarlyData, Client Certificate, Client CertificateVerify, Client Finished. </ins> In general, implementations can implement the transcript by keeping a running transcript hash value based on the negotiated hash.  Note, however, that subsequent post-handshake authentications do not
Secret is called with four distinct transcripts; in a 1-RTT-only exchange with three distinct transcripts. <del> The complete transcript passed to Derive-Secret is always taken from the following sequence of handshake messages, starting at the first ClientHello and including only those messages that were sent: ClientHello, HelloRetryRequest, ClientHello, ServerHello, EncryptedExtensions, Server CertificateRequest, Server Certificate, Server CertificateVerify, Server Finished, EndOfEarlyData, Client Certificate, Client CertificateVerify, Client Finished. </del> If a given secret is not available, then the 0-value consisting of a string of Hash.length zero bytes is used.  Note that this does not mean skipping rounds, so if PSK is not in use Early Secret will still
layer headers.  Note that in some cases a zero-length HashValue (indicated by "") is passed to HKDF-Expand-Label. <ins> 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. </ins> Given a set of n InputSecrets, the final "master secret" is computed by iteratively invoking HKDF-Extract with InputSecret_1, InputSecret_2, etc.  The initial secret is simply a string of