jiebi/CodeConvo huggingface dataset:
_mandatory_ <del> Reference Claims are components of Reference Values as defined in I-D.ietf-rats-architecture.  [Editor's Note: Definition might become obsolete, if replaced by Reference Values.  Is there a difference between Claims and Values here?  Analogously, why is not named Reference Claims in the RATS arch?] Reference Claims are used to appraise the Claims received from an Attester.  For example, Reference Claims MAY be Reference </del> <ins> Reference Values as defined in I-D.ietf-rats-architecture.  This specific type of Claims is used to appraise Claims incorporated in Evidence.  For example, Reference Values MAY be Reference </ins> Integrity Measurements (RIM) or assertions that are implicitly trusted because they are signed by a trusted authority (see <del> Endorsements in I-D.ietf-rats-architecture).  Reference Claims </del> <ins> Endorsements in I-D.ietf-rats-architecture).  Reference Values </ins> typically represent (trusted) Claim sets about an Attester's intended platform operational state.
signature, the Attester Identity, and the Handle, and then appraises the Claims.  Appraisal procedures are application-specific and can be conducted via comparison of the Claims with corresponding Reference <del> Claims, such as Reference Integrity Measurements.  The final output </del> <ins> Values, such as Reference Integrity Measurements.  The final output </ins> of the Verifier are Attestation Results.  Attestation Results constitute new Claim Sets about the properties and characteristics of an Attester, which enables Relying Parties, for example, to assess an
order to allow the inclusion of an optional suffix. The extended date/time format is described by the rule "date-time- <del> ext".  "date-time" is imported from RFC3339, "ALPHA" and "DIGIT" from RFC5234. </del> <ins> ext".  "date-time" and "time-numoffset" are imported from RFC3339, "ALPHA" and "DIGIT" from RFC5234. </ins> Note that a "time-zone" is syntactically similar to a "suffix-tag", but does not include an equals sign.  This special case is only
Each distinct instant in time can be represented in a descriptive text format using a timestamp, and ISO8601 standardizes a widely- <del> adopted timestamp format, which forms the basis of RFC3339.  However, this format only allows timestamps to contain very little additional relevant information, which means that, beyond that, any contextual information related to a given timestamp needs to be either handled separately or attached to it in a non-standard manner. </del> <ins> adopted timestamp format, which forms the basis of the Internet Date/ Time Format RFC3339.  However, this format only allows timestamps to contain very little additional relevant information, which means that, beyond that, any contextual information related to a given timestamp needs to be either handled separately or attached to it in a non-standard manner. </ins> This is already a pressing issue for applications that handle each instant with an associated time zone name, to take into account
For the format defined here, suffix tags are always : They can be added or left out as desired by the generator of the <del> string in Internet Date/Time Format.  (An application might require the presence of specific suffix tags, though.) </del> <ins> string in Internet Extended Date/Time Format (IXDTF).  (An application might require the presence of specific suffix tags, though.) </ins> Without further indication, they are also <del> : Even if included in the Internet Date/Time Format string, the recipient is free to ignore the suffix tag.  Reasons might include that the recipient does not implement (or know about) the specific suffix key, or that it does recognize the key but cannot act on the value provided. </del> <ins> : Even if included in the IXDTF string, the recipient is free to ignore the suffix tag.  Reasons might include that the recipient does not implement (or know about) the specific suffix key, or that it does recognize the key but cannot act on the value provided. </ins> A suffix tag may also indicate that it is <del> : The recipient is advised that it MUST not act on the Internet Date/ Time Format string unless it can process the suffix tag as specified. A critical suffix tag is indicated by following its opening bracket with an exclamation mark (see "critical-flag" in abnf). </del> <ins> : The recipient is advised that it MUST not act on the Internet Extended Date/Time Format (IXDTF) string unless it can process the suffix tag as specified.  A critical suffix tag is indicated by following its opening bracket with an exclamation mark (see "critical-flag" in abnf). </ins> <del> Internet Date/Time Format strings such as: </del> <ins> IXDTF strings such as: </ins> are internally inconsistent, as Europe/Paris does not use a time zone offset of 0 (which is indicated in the "Z", an abbreviation for
The following rules extend the ABNF syntax defined in RFC3339 in order to allow the inclusion of an optional suffix. <del> The extended date/time format is described by the rule "date-time- ext". </del> <ins> The Internet Extended Date/Time Format (IXDTF) is described by the rule "date-time-ext". </ins> "date-time" and "time-numoffset" are imported from RFC3339, "ALPHA" and "DIGIT" from RFC5234.
5.2. <del> Cryptographic algorithm negotiation: Transport security protocols should permit applications to configure supported or enabled cryptographic algorithms. </del> <ins> Cryptographic algorithm negotiation (AN): Transport security protocols should permit applications to configure supported or enabled cryptographic algorithms. </ins> Transport dependency: None. Application dependency: Application awareness of supported or desired algorithms. <del> Application authentication delegation: Some protocols may </del> <ins> Application authentication delegation (AD): Some protocols may </ins> completely defer endpoint authentication to applications, e.g., to reduce online protocol complexity.
Application dependency: Mutual authentication required for application support. <del> DoS mitigation: Transport security protocols may need to support volumetric DoS prevention via, e.g., cookies or initiator-side puzzles. </del> <ins> DoS mitigation (DM): Transport security protocols may need to support volumetric DoS prevention via, e.g., cookies or initiator- side puzzles. </ins> Transport dependency: None. Application dependency: None. <del> Connection mobility: Sessions should not be bound to a network connection (or 5-tuple).  This allows cryptographic key material and other state information to be reused in the event of a connection change.  Examples of this include a NAT rebinding that occurs without a client's knowledge. </del> <ins> Connection mobility (CM): Sessions should not be bound to a network connection (or 5-tuple).  This allows cryptographic key material and other state information to be reused in the event of a connection change.  Examples of this include a NAT rebinding that occurs without a client's knowledge. </ins> Transport dependency: Connections are unreliable or can change due to unpredictable network events, e.g., NAT re-bindings. Application dependency: None. <del> Source validation: Source validation must be provided to mitigate server-targeted DoS attacks.  This can be done with puzzles or cookies. </del> <ins> Source validation (SV): Source validation must be provided to mitigate server-targeted DoS attacks.  This can be done with puzzles or cookies. </ins> Transport dependency: Packets may arrive as datagrams instead of streams from unauthenticated sources. Application dependency: None. <del> Application-layer feature negotiation: The type of application using a transport security protocol often requires features configured at the connection establishment layer, e.g., ALPN RFC7301.  Moreover, application-layer features may often be used to offload the session to another server which can better handle the request.  (The TLS SNI is one example of such a feature.)  As such, transport security protocols should provide a generic mechanism to allow for such application-specific features and options to be configured or otherwise negotiated. </del> <ins> Application-layer feature negotiation (AFN): The type of application using a transport security protocol often requires features configured at the connection establishment layer, e.g., ALPN RFC7301.  Moreover, application-layer features may often be used to offload the session to another server which can better handle the request.  (The TLS SNI is one example of such a feature.)  As such, transport security protocols should provide a generic mechanism to allow for such application-specific features and options to be configured or otherwise negotiated. </ins> Transport dependency: None. Application dependency: Specification of application-layer features or functionality. <del> Configuration extensions: The protocol negotiation should be </del> <ins> Configuration extensions (CX): The protocol negotiation should be </ins> extensible with addition of new configuration options. Transport dependency: None.
Application dependency: Specification of application-specific extensions. <del> Session caching (and management): Sessions should be cacheable to enable reuse and amortize the cost of performing session </del> <ins> Session caching and management (SC): Sessions should be cacheable to enable reuse and amortize the cost of performing session </ins> establishment handshakes. Transport dependency: None. Application dependency: None. <del> Length-hiding padding: Applications may wish to defer traffic padding to the security protocol to deter traffic analysis </del> <ins> Length-hiding padding (LHP): Applications may wish to defer traffic padding to the security protocol to deter traffic analysis </ins> attacks. Transport dependency: None. Application dependency: Knowledge of desired padding policies. <ins> 5.3. The following table lists the availability of the above-listed optional features in each of the analyzed protocols.  "Mandatory" indicates that the feature is intrinsic to the protocol and cannot be disabled.  "Supported" indicates that the feature is optionally provided natively or through a (standardized, where applicable) extension. M=Mandatory S=Supported but not required U=Unsupported *=On TCP; MPTCP would provide this ability **=TCP provides SYN cookies natively, but these are not cryptographically strong +=For transport packets only </ins> 6. This section describes the interface surface exposed by the security
7.2. <ins> ESNI requires encrypted DNS to be an effective privacy protection mechanism.  However, verifying the server's identity from the Certificate message, particularly when using the X509 CertificateType, may result in additional network traffic that may reveal the server identity.  Examples of this traffic may include requests for revocation information, such as OCSP or CRL traffic, or requests for repository information, such as authorityInformationAccess.  It may also include implementation- specific traffic for additional information sources as part of verification. Implementations SHOULD avoid leaking information that may identify the server.  Even when sent over an encrypted transport, such requests may result in indirect exposure of the server's identity, such as indicating a specific CA or service being used.  To mitigate this risk, servers SHOULD deliver such information in-band when possible, such as through the use of OCSP stapling, and clients SHOULD take steps to minimize or protect such requests during certificate validation. 7.3. </ins> I-D.ietf-tls-sni-encryption lists several requirements for SNI encryption.  In this section, we re-iterate these requirements and assess the ESNI design against them. <del> 7.2.1. </del> <ins> 7.3.1. </ins> Since the SNI encryption key is derived from a (EC)DH operation between the client's ephemeral and server's semi-static ESNI key, the
ESNI extensions (see grease-extensions), which helps ensure the ecosystem handles the values correctly. <del> 7.2.5. </del> <ins> 7.3.5. </ins> This design is not forward secret because the server's ESNI key is static.  However, the window of exposure is bound by the key lifetime.  It is RECOMMENDED that servers rotate keys frequently. <del> 7.2.6. </del> <ins> 7.3.6. </ins> This design permits servers operating in Split Mode to forward connections directly to backend origin servers, thereby avoiding unnecessary MiTM attacks. <del> 7.2.7. </del> <ins> 7.3.7. </ins> Assuming ESNI records retrieved from DNS are validated, e.g., via DNSSEC or fetched from a trusted Recursive Resolver, spoofing a
client validates the server certificate against the public name before retrying. <del> 7.2.8. </del> <ins> 7.3.8. </ins> This design has no impact on application layer protocol negotiation. It may affect connection routing, server certificate selection, and client certificate verification.  Thus, it is compatible with multiple protocols. <del> 7.3. </del> <ins> 7.4. </ins> Note that the backend server has no way of knowing what the SNI was, but that does not lead to additional privacy exposure because the
nonce re-use since the client's ESNI key share, and thus the value of Zx, does not change across ClientHello retries.) <ins> Note that ESNIContents will not be directly transmitted to the server in the ClientHello.  The server will instead reconstruct the same object by obtaining its values from ClientEncryptedSNI and ClientHello. </ins> [[TODO: label swapping fixes a bug in the spec, though this may not be the best way to deal with HRR.  See https://github.com/tlswg/ draft-ietf-tls-esni/issues/121 and https://github.com/tlswg/draft- ietf-tls-esni/pull/170 for more details.]] <ins> Same value as ClientEncryptedSNI.record_digest. Same value as ClientEncryptedSNI.key_share. Same nonce as ClientHello.random. </ins> The client then creates a ClientESNIInner structure: A random 16-octet value to be echoed by the server in the
receipt of a second ClientHello message with a ClientECH value, servers set up their HPKE context and decrypt ClientECH as follows: <del> It is an error for the client to offer ECH before the HelloRetryRequest but not after.  Likewise, it is an error for the client to offer ECH after the HelloRetryRequest but not before.  If the client-facing server accepts ECH for the first ClientHello but not the second, or it accepts ECH for the second ClientHello but not the first, then the client MUST abort the handshake with an "illegal_parameter" alert. </del> <ins> If the client offered ECH in the first ClientHello, then it MUST offer ECH in the second.  Likewise, if the client did not offer ECH in the first ClientHello, then it MUST NOT not offer ECH in the second. </ins> [[OPEN ISSUE: Should we be using the PSK input or the info input?  On the one hand, the requirements on info seem weaker, but maybe
negotiating ECH, including servers which do not implement this specification. <ins> 7.1.1. It is an error for the client to offer ECH before the HelloRetryRequest but not after.  Likewise, it is an error for the client to offer ECH after the HelloRetryRequest but not before.  If either of these conditions occurs, then the client-facing server MUST abort the handshake with an "illegal_parameter" alert. </ins> 7.2. When the client-facing server accepts ECH, it forwards the
If the server sends an "encrypted_client_hello" extension, the client MUST check the extension syntactically and abort the connection with <del> a "decode_error" alert if it is invalid. </del> <ins> a "decode_error" alert if it is invalid.  It otherwise ignores the extension and MUST NOT use the retry keys. </ins> Offering a GREASE extension is not considered offering an encrypted ClientHello for purposes of requirements in client-behavior.  In
10.8.6. This design permits servers operating in Split Mode to forward <del> connections directly to backend origin servers, thereby avoiding unnecessary MiTM attacks. </del> <ins> connections directly to backend origin servers.  The client authenticates the identity of the backend origin server, thereby avoiding unnecessary MiTM attacks. </ins> <del> 10.8.7. Assuming ECH records retrieved from DNS are authenticated, e.g., via DNSSEC or fetched from a trusted Recursive Resolver, spoofing a server operating in Split Mode is not possible.  See plaintext-dns for more details regarding plaintext DNS. </del> <ins> Conversely, assuming ECH records retrieved from DNS are authenticated, e.g., via DNSSEC or fetched from a trusted Recursive Resolver, spoofing a client-facing server operating in Split Mode is not possible.  See plaintext-dns for more details regarding plaintext DNS. </ins> Authenticating the ECHConfigs structure naturally authenticates the included public name.  This also authenticates any retry signals from <del> the server because the client validates the server certificate against the public name before retrying. </del> <ins> the client-facing server because the client validates the server certificate against the public name before retrying. </ins> <del> 10.8.8. </del> <ins> 10.8.7. </ins> This design has no impact on application layer protocol negotiation. It may affect connection routing, server certificate selection, and client certificate verification.  Thus, it is compatible with <del> multiple protocols. </del> <ins> multiple application and transport protocols.  By encrypting the entire ClientHello, this design additionally supports encrypting the ALPN extension. </ins> 10.9.
"encrypted_client_hello" extension and proceeds with the handshake as usual, per RFC8446, Section 4.1.2. <del> If it supports ECH but does not recognize the configuration specified by the client, then it ignores the extension and </del> <ins> If it supports ECH but cannot decrypt the extension, then it </ins> terminates the handshake using the ClientHelloOuter.  This is referred to as "ECH rejection".  When ECH is rejected, the server sends an acceptable ECH configuration in its EncryptedExtensions message. <del> If it supports ECH and recognizes the configuration, then it attempts to decrypt the ClientHelloInner.  It aborts the handshake if decryption fails; otherwise it forwards the ClientHelloInner to the backend, who terminates the connection.  This is referred to as "ECH acceptance". </del> <ins> If it supports ECH and decrypts the extension, it forwards the ClientHelloInner to the backend, who terminates the connection. This is referred to as "ECH acceptance". </ins> Upon receiving the server's response, the client determines whether or not ECH was accepted and proceeds with the handshake accordingly.
"ECHConfig.cipher_suites" list. The configuration identifier, equal to "Expand(Extract("", <del> config), "tls13 ech config id", Nh)", where "config" is the </del> <ins> config), "tls ech config id", Nh)", where "config" is the </ins> "ECHConfig" structure and "Extract", "Expand", and "Nh" are as specified by the cipher suite KDF.  (Passing the literal """" as the salt is interpreted by "Extract" as no salt being provided.)
Note that the HPKE functions Deserialize and SetupBaseS are those which match "ECHConfig.kem_id" and the AEAD/KDF used with "context" are those which match the client's chosen preference from <del> "ECHConfig.cipher_suites". </del> <ins> "ECHConfig.cipher_suites".  The "info" parameter to SetupBaseS is the concatenation of "tls ech", a zero byte, and the serialized ECHConfig. </ins> The value of the "encrypted_client_hello" extension in the ClientHelloOuter is a "ClientECH" with the following values:
of the first ClientHelloInner via the derived ech_hrr_key by modifying HPKE setup as follows: <del> Clients then encrypt the second ClientHelloInner using this new HPKE context.  In doing so, the encrypted value is also authenticated by ech_hrr_key.  The rationale for this is described in flow-hrr-hijack. </del> <ins> The "info" parameter to SetupPSKS is the concatenation of "tls ech", a zero byte, and the serialized ECHConfig.  Clients then encrypt the second ClientHelloInner using this new HPKE context.  In doing so, the encrypted value is also authenticated by ech_hrr_key.  The rationale for this is described in flow-hrr-hijack. </ins> Client-facing servers perform the corresponding process when decrypting second ClientHelloInner messages.  In particular, upon
servers set up their HPKE context and decrypt ClientECH as follows: ClientHelloOuterAAD is computed from the second ClientHelloOuter as <del> described in authenticating-outer. </del> <ins> described in authenticating-outer.  The "info" parameter to SetupPSKR is computed as above. </ins> If the client offered ECH in the first ClientHello, then it MUST offer ECH in the second.  Likewise, if the client did not offer ECH
ClientHelloInner.  The client-facing server forwards all other TLS messages between the client and backend server unmodified. <ins> Otherwise, if all candidate ECHConfigs fail to decrypt the extension, the client-facing server MUST ignore the extension and proceed with the connection using ClientHelloOuter.  This connection proceeds as usual, except the server MUST include the "encrypted_client_hello" extension in its EncryptedExtensions with the "retry_configs" field set to one or more ECHConfig structures with up-to-date keys. Servers MAY supply multiple ECHConfig values of different versions. This allows a server to support multiple versions at once. Note that decryption failure could indicate a GREASE ECH extension (see grease-extensions), so it is necessary for servers to proceed with the connection and rely on the client to abort if ECH was required.  In particular, the unrecognized value alone does not indicate a misconfigured ECH advertisement (misconfiguration). Instead, servers can measure occurrences of the "ech_required" alert to detect this case. </ins> 7.1.1. In case a HelloRetryRequest (HRR) is sent, the client-facing server
extension but CH1 does not, then the server MUST abort the handshake with an "illegal_parameter" alert. <del> Suppose the "encrypted_client_hello" extension is sent in both CH1 and CH2, If the configuration identifier (see ech-configuration) differs between CH1 and CH2, then the server MUST abort with an "illegal_parameter" alert. </del> <ins> If the "encrypted_client_hello" extension is sent in CH2, the server follows the procedure in client-facing-server to decrypt the extension, but it uses the previously-selected ECHConfig as the set of candidate ECHConfigs.  If decryption fails, the server aborts the connection with a "decrypt_error" alert rather than continuing the handshake with the second ClientHelloOuter. </ins> [[OPEN ISSUE: If the client-facing server implements stateless HRR, it has no way to send a cookie, short of as-yet-unspecified
The non-empty name of the client-facing server, i.e., the entity trusted to update the ECH configuration.  This is used to correct misconfigured clients, as described in handle-server-response. <ins> This value MUST NOT begin or end with an ASCII dot and MUST be parsable as a dot-separated sequence of LDH labels, as defined in RFC5890, Section 2.3.1.  Clients MUST ignore any "ECHConfig" structure whose "public_name" does not meet these criteria.  Note that these criteria are incomplete; they incidentally rule out textual representations of IPv6 addresses (see RFC3986, Section 3.2.2), but do not exclude IPv4 addresses in standard dotted-decimal or other non-standard notations such as octal and hexadecimal (see RFC3986, Section 7.4).  If "public_name" contains a literal IPv4 or IPv6 address, the client SHOULD ignore the "ECHConfig" to avoid sending a non-compliant "server_name" extension on the ClientHelloOuter (see RFC6066, Section 3). </ins> A list of extensions that the client must take into consideration when generating a ClientHello message.  These are described below