jiebi/CodeConvo huggingface dataset:
A tag is considered "authoritative" if the CoSWID tag was created by the software provider.  An authoritative CoSWID tag contains <del> information about a software component provided by the maintainer of </del> <ins> information about a software component provided by the supplier of </ins> the software component, who is expected to be an expert in their own <del> software.  Thus, authoritative CoSWID tags can be trusted to represent authoritative information about the software component. </del> <ins> software.  Thus, authoritative CoSWID tags can represent authoritative information about the software component.  The degree to which this information can be trusted depends on the tag's chain of custody and the ability to verify a signature provided by the supplier if present in the CoSWID tag.  The provisioning and validation of CoSWID tags are handled by local policy and is outside the scope of this document. </ins> A signed CoSWID tag (see coswid-cose) whose signature has been validated can be relied upon to be unchanged since it was signed.  By <del> contrast, the data contained in unsigned tags cannot be trusted to be unmodified. When an authoritative tag is signed, the software provider can be authenticated as the originator of the signature.  A trustworthy association between the signature and the originator of the signature can be established via trust anchors.  A certification path between a trust anchor and a certificate including a pub-key enabling the validation of a tag signature can realize the assessment of trustworthiness of an authoritative tag.  Having a signed authoritative CoSWID tag can be useful when the information in the tag needs to be trusted, such as when the tag is being used to convey reference integrity measurements for software components. </del> <ins> contrast, the data contained in unsigned tags can be altered by any user or process with write-access to the tag.  To support signature validation, there is the need associate the right key with the software provider or party originating the signature.  This operation is application specific and needs to be addressed by the application or a user of the application; a specific approach for which is out- of-scope for this document. When an authoritative tag is signed, the originator of the signature can be verified.  A trustworthy association between the signature and the originator of the signature can be established via trust anchors. A certification path between a trust anchor and a certificate including a public key enabling the validation of a tag signature can realize the assessment of trustworthiness of an authoritative tag. Verifying that the software provider is the signer is a different matter.  This requires an association between the signature and the tag's entity item associated corresponding to the software provider. No mechanism is defined in this draft to make this association; therefore, this association will need to be handled by local policy. </ins> CoSWID tags are intended to contain public information about software components and, as such, the contents of a CoSWID tag does not need
do this, CoSWID tags can be created by any party and the CoSWID tags collected from an endpoint could contain a mixture of vendor and non- vendor created tags.  For this reason, a CoSWID tag might contain <del> potentially malicious content.  Input sanitization and loop detection are two ways that implementations can address this concern. </del> <ins> potentially malicious content.  Input sanitization, loop detection, and signature verification are ways that implementations can address this concern. </ins> 10.
4. There exists a common set of features shared across the transport <del> protocols surveyed in this document.  The mandatory features should be provided by any transport security protocol, while the optional features are extensions that a subset of the protocols provide.  For clarity, we also distinguish between handshake and record features. </del> <ins> protocols surveyed in this document.  Mandatory features constitute a baseline of functionality that an application may assume for any TAPS implementation.  Optional features by contrast may vary from implementation to implementation, and so an application cannot simply assume they are available.  Applications learn of and use optional features by querying for their presence and support.  Optional features may not be implemented, or may be disabled if their presence impacts transport services or if a necessary transport service is unavailable. </ins> 4.1. <del> 4.1.1. </del> <ins> Segment encryption and authentication: Transit data must be protected with an authenticated encryption algorithm. </ins> <del> Forward-secure segment encryption and authentication: Transit data must be protected with an authenticated encryption algorithm. </del> <ins> Forward-secure key establishment: Negotiated keying material must come from an authenticated, forward-secure key exchange protocol. </ins> Private key interface or injection: Authentication based on public key signatures is commonplace for many transport security
connection must be authenticated before any data is sent to said party. <del> Source validation: Source validation must be provided to mitigate server-targeted DoS attacks.  This can be done with puzzles or cookies. 4.1.2. Pre-shared key support: A record protocol must be able to use a pre-shared key established out-of-band to encrypt individual messages, packets, or datagrams. </del> <ins> Pre-shared key support: A security protocol must be able to use a pre-shared key established out-of-band or from a prior session to encrypt individual messages, packets, or datagrams. </ins> 4.2. <del> 4.2.1. </del> Mutual authentication: Transport security protocols must allow each endpoint to authenticate the other if required by the application. <ins> Transport dependency: None. Application dependency: Mutual authentication required for application support. 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. Transport dependency: Connections are unreliable or can change due to unpredictable network events, e.g., NAT re-bindings. Application dependency: None. Source validation: Source validation must be provided to mitigate server-targeted DoS attacks.  This can be done with puzzles or cookies. Transport dependency: Packets may arrive as datagrams instead of streams from unauthenticated sources. Application dependency: None. </ins> 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
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. </ins> Configuration extensions: The protocol negotiation should be extensible with addition of new configuration options. <ins> Transport dependency: None. Application dependency: Specification of application-specific extensions. </ins> Session caching and management: Sessions should be cacheable to enable reuse and amortize the cost of performing session establishment handshakes. <del> 4.2.2. </del> <ins> Transport dependency: None. </ins> <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> Application dependency: None. </ins> 5. This section describes the interface surface exposed by the security <del> protocols described above, with each interface.  Note that not all protocols support each interface. </del> <ins> protocols described above.  Note that not all protocols support each interface.  We partition these interfaces into pre-connection (configuration), connection, and post-connection interfaces. </ins> 5.1.
key exchange, signatures, and ciphersuites. Protocols: TLS, DTLS, QUIC + TLS, MinimalT, tcpcrypt, IKEv2, SRTP <del> Session Cache The application provides the ability to save and retrieve session state (such as tickets, keying material, and server parameters) that may be used to resume the security session. </del> <ins> Session Cache Management The application provides the ability to save and retrieve session state (such as tickets, keying material, and server parameters) that may be used to resume the security session. </ins> Protocols: TLS, DTLS, QUIC + TLS, MinimalT Authentication Delegation
provide authentication, using EAP for example. Protocols: IKEv2, SRTP <del> 5.2. </del> <ins> Pre-Shared Key Import Either the handshake protocol or the application directly can supply pre-shared keys for the record protocol use for encryption/ decryption and authentication.  If the application can supply keys directly, this is considered explicit import; if the handshake protocol traditionally provides the keys directly, it is considered direct import; if the keys can only be shared by the handshake, they are considered non-importable. </ins> <del> Handshake interfaces are the points of interaction between a handshake protocol and the application, record protocol, and transport once the handshake is active. </del> <ins> Explict import: QUIC, ESP Direct import: TLS, DTLS, MinimalT, tcpcrypt, WireGuard </ins> <del> Send Handshake Messages The handshake protocol needs to be able to send messages over a transport to the remote peer to establish trust and to negotiate keys. Protocols: All (TLS, DTLS, QUIC + TLS, MinimalT, CurveCP, IKEv2, WireGuard, SRTP (DTLS)) </del> <ins> Non-importable: CurveCP </ins> <del> Receive Handshake Messages The handshake protocol needs to be able to receive messages from the remote peer over a transport to establish trust and to negotiate keys. Protocols: All (TLS, DTLS, QUIC + TLS, MinimalT, CurveCP, IKEv2, WireGuard, SRTP (DTLS)) </del> <ins> 5.2. </ins> Identity Validation During a handshake, the security protocol will conduct identity
involves sending a cookie exchange to avoid DoS attacks. Protocols: QUIC + TLS, DTLS, WireGuard <ins> 5.3. Connection Termination The security protocol may be instructed to tear down its connection and session information.  This is needed by some protocols to prevent application data truncation attacks. Protocols: TLS, DTLS, QUIC + TLS, MinimalT, tcpcrypt, IKEv2 </ins> Key Update The handshake protocol may be instructed to update its keying material, either by the application directly or by the record protocol sending a key expiration event. Protocols: TLS, DTLS, QUIC + TLS, MinimalT, tcpcrypt, IKEv2 <del> Pre-Shared Key Export The handshake protocol will generate one or more keys to be used for record encryption/decryption and authentication.  These may be explicitly exportable to the application, traditionally limited to direct export to the record protocol, or inherently non-exportable because the keys must be used directly in conjunction with the record protocol. </del> <ins> Pre-Shared Key Export The handshake protocol will generate one or more keys to be used for record encryption/decryption and authentication.  These may be explicitly exportable to the application, traditionally limited to direct export to the record protocol, or inherently non-exportable because the keys must be used directly in conjunction with the record protocol. </ins> Explict export: TLS (for QUIC), tcpcrypt, IKEv2, DTLS (for SRTP)
Non-exportable: CurveCP <del> 5.3. Record interfaces are the points of interaction between a record protocol and the application, handshake protocol, and transport once in use. Pre-Shared Key Import Either the handshake protocol or the application directly can supply pre-shared keys for the record protocol use for encryption/ decryption and authentication.  If the application can supply keys directly, this is considered explicit import; if the handshake protocol traditionally provides the keys directly, it is considered direct import; if the keys can only be shared by the handshake, they are considered non-importable. Explict import: QUIC, ESP Direct import: TLS, DTLS, MinimalT, tcpcrypt, WireGuard Non-importable: CurveCP Encrypt application data The application can send data to the record protocol to encrypt it into a format that can be sent on the underlying transport.  The encryption step may require that the application data is treated as a stream or as datagrams, and that the transport to send the encrypted records present a stream or datagram interface. Stream-to-Stream Protocols: TLS, tcpcrypt Datagram-to-Datagram Protocols: DTLS, ESP, SRTP, WireGuard Stream-to-Datagram Protocols: QUIC ((Editor's Note: This depends on the interface QUIC exposes to applications.)) Decrypt application data The application can receive data from its transport to be decrypted using record protocol.  The decryption step may require that the incoming transport data is presented as a stream or as datagrams, and that the resulting application data is a stream or datagrams. Stream-to-Stream Protocols: TLS, tcpcrypt Datagram-to-Datagram Protocols: DTLS, ESP, SRTP, WireGuard Datagram-to-Stream Protocols: QUIC ((Editor's Note: This depends on the interface QUIC exposes to applications.)) </del> Key Expiration The record protocol can signal that its keys are expiring due to reaching a time-based deadline, or a use-based deadline (number of
more on this, as well as https://mailarchive.ietf.org/arch/msg/tls/ TugB5ddJu3nYg7chcyeIyUqWSbA.]] <ins> contains keys that are not required to be understood by the client.  Server operators MUST NOT place a key in this section unless the server is able to determine whether the key is in use based on the client data it receives.  A key MUST NOT appear in both the main template and the optional section. </ins> 2.1.1. To be compatible with the specializations described in this section,
https://mailarchive.ietf.org/arch/msg/tls/ TugB5ddJu3nYg7chcyeIyUqWSbA. <ins> If true, handshake messages MUST be conveyed inside a "Handshake" (RFC8446, Section 4) struct on stream transports, or a "DTLSHandshake" (RFC9147, Section 5.2) struct on datagram transports, and MAY be broken into multiple records as in TLS and DTLS.  Otherwise, each handshake message is conveyed in a "CTLSHandshake" or "CTLSDatagramHandshake" struct (ctlshandshake), which MUST be the payload of a single record. </ins> contains keys that are not required to be understood by the client.  Server operators MUST NOT place a key in this section unless the server is able to determine whether the key is in use
value to distinguish cTLS plaintext records from encrypted records, TLS/DTLS records, and other protocols using the same 5-tuple. <ins> The "profile_id" field MUST identify the profile that is in use.  A zero-length ID corresponds to the cTLS default protocol.  The server's reply does not include the "profile_id", because the server must be using the same profile indicated by the client. </ins> Encrypted records use DTLS 1.3 RFC9147 record framing, comprising a configuration octet followed by optional connection ID, sequence number, and length fields.  The encryption process and additional
2.3. <del> The cTLS handshake framing is same as the TLS 1.3 handshake framing, except for two changes: The length field is omitted. The HelloRetryRequest message is a true handshake message instead of a specialization of ServerHello. </del> <ins> When "template.handshakeFraming" is not "true", cTLS uses a custom handshake framing that saves space by relying on the record layer for message lengths.  (This saves 3 bytes per message compared to TLS, or 9 bytes compared to DTLS.)  This compact framing is defined by the "CTLSHandshake" and "CTLSDatagramHandshake" structs. Any handshake type registered in the IANA TLS HandshakeType Registry can be conveyed in a "CTLS[Datagram]Handshake", but not all messages are actually allowed on a given connection.  This definition shows the messages types supported in "CTLSHandshake" as of TLS 1.3 and DTLS 1.3, but any future message types are also permitted. Each "CTLSHandshake" or "CTLSDatagramHandshake" MUST be conveyed as a single "CTLSClientPlaintext.fragment", "CTLSServerPlaintext.fragment", or "CTLSCiphertext.encrypted_record", and is therefore limited to a maximum length of "2^16-1" or less. When operating over UDP, large "CTLSDatagramHandshake" messages will also require the use of IP fragmentation, which is sometimes undesirable.  Operators can avoid these concerns by setting "template.handshakeFraming = true". </ins> 3. <del> In general, we retain the basic structure of each individual TLS handshake message.  However, the following handshake messages have been modified for space reduction and cleaned up to remove pre-TLS 1.3 baggage. </del> <ins> In general, we retain the basic structure of each individual TLS or DTLS handshake message.  However, the following handshake messages have been modified for space reduction and cleaned up to remove pre- TLS 1.3 baggage. </ins> 3.1. The cTLS ClientHello is defined as follows. <del> The "profile_id" field MUST identify the profile that is in use.  A zero-length ID corresponds to the cTLS default protocol. </del> 3.2. We redefine ServerHello in the following way. 3.3. <del> The HelloRetryRequest has the following format. </del> <ins> In cTLS, the HelloRetryRequest message is a true handshake message instead of a specialization of ServerHello.  The HelloRetryRequest has the following format. </ins> The HelloRetryRequest is the same as the ServerHello above but without the unnecessary sentinel Random value.
6.3. <ins> This document requests that IANA change the name of entry 6 in the TLS HandshakeType Registry from "hello_retry_request_RESERVED" to "hello_retry_request", and set its Reference field to this document. 6.4. </ins> This document requests that IANA open a new registry entitled "Well- known cTLS Profile IDs", on the Transport Layer Security (TLS) Parameters page, with the following columns:
Omitting the fields and handshake messages required for preserving backwards-compatibility with earlier TLS versions. <del> More compact encodings, for example point compression. </del> <ins> More compact encodings. </ins> A template-based specialization mechanism that allows pre- populating information at both endpoints without the need for negotiation. <del> Alternative cryptographic techniques, such as semi-static Diffie- Hellman. OPEN ISSUE: Semi-static and point compression are never mentioned again. </del> <ins> Alternative cryptographic techniques, such as nonce truncation. </ins> For the common (EC)DHE handshake with pre-established certificates, Stream cTLS achieves an overhead of 53 bytes over the minimum
"encrypted_server_name" extension.  If the client does not retry in either scenario, it MUST report an error to the calling application. <ins> If the server sends a HelloRetryRequest in response to the ClientHello and the client can send a second updated ClientHello per the rules in RFC8446, the "encrypted_server_name" extension values which do not depend on the (possibly updated) ClientHello.KeyShareClientHello, i.e,, ClientEncryptedSNI.suite, ClientEncryptedSNI.key_share, and ClientEncryptedSNI.record_digest, MUST NOT change across ClientHello messages.  Moreover, ClientESNIInner.nonce and ClientESNIInner.realSNI MUST not change across ClientHello messages.  Informally, the values of all unencrypted extension information, as well as the inner extension plaintext, must be consistent between the first and second ClientHello messages. </ins> 5.1.3. When the server cannot decrypt or does not process the
encrypt the ClientHello.  See hpke-map for information on how a cipher suite maps to corresponding HPKE algorithm identifiers. <del> the largest name the server expects to support.  If the server supports arbitrary wildcard names, it SHOULD set this value to 256.  Clients SHOULD reject ESNIConfig as invalid if maximum_name_length is greater than 256. </del> <ins> The largest name the server expects to support, if known.  If this value is not known it can be set to zero, in which case clients SHOULD use the inner ClientHello padding scheme described below. That could happen if wildcard names are in use, or if names can be added or removed from the anonymity set during the lifetime of a particular resource record value. </ins> A list of extensions that the client can take into consideration when generating a Client Hello message.  The purpose of the field
an "echo_nonce" extension <del> TLS padding Padding SHOULD be P = L - D bytes, where L = ECHOConfig.maximum_name_length, rounded up to the nearest multiple of 16 D = len(dns_name), where dns_name is the DNS name in the ClientHelloInner "server_name" extension </del> <ins> TLS padding RFC7685 (see section padding) </ins> When offering an encrypted ClientHello, the client MUST NOT offer to resume any non-ECHO PSKs.  It additionally MUST NOT offer to resume
7.2. <ins> Future extensions could reveal sensitive information through their length.  Consequently, padding should be flexible and support arbitrary extension changes. For each field in the inner ClientHello, clients need to determine how much to pad given the semantics of that field.  For example, if a client can propose various ALPN values, it could add padding to round up to the longest of those. The target padding length of most ClientHello extensions can be determined without server help.  However, the "server_name" extension could benefit from server input (ECHOConfig.maximum_name_length). Clients SHOULD compute the padding for this extension as follows: If ECHOConfig.maximum_name_length is longer than the actual server_name then clients SHOULD add padding to make up that difference. Otherwise, if ECHOConfig.maximum_name_length is zero or less than the length of the actual server_name then round the server_name up to a multiple of 32 octets and randomly add another 32 octets 50% of the time and then include that amount of additional padding. The amount of padding applied to the ClientHello is then computed as the sum of all per-extension padding values, rounded up to the nearest multiple of 32.  (This additional rounding step aims to hide variance across different client implementations.) In addition to padding ClientHelloInner, clients and servers will also need to pad all other handshake messages that have sensitive- length fields.  For example, if a client proposes ALPN values in ClientHelloInner, the server-selected value will be returned in an EncryptedExtension, so that handshake message also needs to be padded using TLS record layer padding. 7.3. </ins> As described in server-behavior, the server MAY either accept ECHO and use ClientHelloInner or reject it and use ClientHelloOuter. However, there is no indication in ServerHello of which one the server has done and the client must therefore use trial decryption in order to determine this. <del> 7.2.1. </del> <ins> 7.3.1. </ins> If the server used ClientHelloInner, the client proceeds with the connection as usual, authenticating the connection for the origin server. <del> 7.2.2. </del> <ins> 7.3.2. </ins> If the server used ClientHelloOuter, the client proceeds with the handshake, authenticating for ECHOConfig.public_name as described in
has been unable to develop a completely generic solution.  I-D.ietf- tls-sni-encryption provides a description of the problem space and some of the proposed techniques.  One of the more difficult problems <del> is "Do not stick out" (I-D.ietf-tls-sni-encryption; Section 3.4): if </del> <ins> is "Do not stick out" (I-D.ietf-tls-sni-encryption, Section 3.4): if </ins> only sensitive/private services use SNI encryption, then SNI encryption is a signal that a client is going to such a service.  For this reason, much recent work has focused on concealing the fact that