jiebi/CodeConvo huggingface dataset:
EndOfEarlyData is not necessary to determine when the early data is complete, and because DTLS is lossy, attackers can trivially mount the deletion attacks that EndOfEarlyData prevents in TLS.  Servers <del> SHOULD aggressively age out the epoch 1 keys upon receiving the first epoch 2 record and SHOULD NOT accept epoch 1 data after the first epoch 3 record is received.  (See dtls-epoch for the definitions of each epoch.) </del> <ins> SHOULD NOT accept records from epoch 1 indefinitely once they are able to process records from epoch 3.  Though reordering of IP packets can result in records from epoch 1 arriving after records from epoch 3, this is not likely to persist for very long relative to the round trip time.  Servers could discard epoch 1 keys after the first epoch 3 data arrives, or retain keys for processing epoch 1 data for a short period.  is received.  (See dtls-epoch for the definitions of each epoch.) </ins> 5.6.
provided.  Endpoints MUST NOT have more than one NewConnectionId message outstanding. <del> If the client and server have negotiated use of the "connection_id" extension, either side can request a new CID using the RequestConnectionId message.  In general, implementations SHOULD use a new CID whenever sending on a new path, and SHOULD request new CIDs for this purpose if path changes are anticipated. </del> <ins> Implementations which either did not negotiate the "connection_id" extension or which have negotiated receiving an empty CID MUST NOT send NewConnectionId.  Implementations MUST NOT send RequestConnectionId when sending an empty connection ID. Implementations which detect a violation of these rules MUST terminate the connection with an "unexpected_message" alert. Implementations SHOULD use a new CID whenever sending on a new path, and SHOULD request new CIDs for this purpose if path changes are anticipated. </ins> The number of CIDs desired.
MSL: Maximum Segment Lifetime <del> The reader is assumed to be familiar with the TLS 1.3 specification. As in TLS 1.3 the HelloRetryRequest has the same format as a ServerHello message but for convenience we use the term HelloRetryRequest throughout this document as if it were a distinct message. </del> <ins> The reader is assumed to be familiar with TLS13.  As in TLS 1.3, the HelloRetryRequest has the same format as a ServerHello message, but for convenience we use the term HelloRetryRequest throughout this document as if it were a distinct message. </ins> The reader is also assumed to be familiar with I-D.ietf-tls-dtls- connection-id as this document applies the CID functionality to DTLS
The sn_key is computed as follows: [sender] denotes the sending side.  The Secret value to be used is <del> described in Section 7.3 of TLS13. </del> <ins> described in Section 7.3 of TLS13.  Note that a new key is used for each epoch: because the epoch is in the clear, this does not result in ambiguity. </ins> The encrypted sequence number is computed by XORing the leading bytes <del> of the Mask with the sequence number.  Decryption is accomplished by the same process. </del> <ins> of the Mask with the on-the-wire representation of the sequence number.  Decryption is accomplished by the same process. </ins> This procedure requires the ciphertext length be at least 16 bytes. Receivers MUST reject shorter records as if they had failed
configured not to perform a cookie exchange.  The default SHOULD be that the exchange is performed, however.  In addition, the server MAY choose not to do a cookie exchange when a session is resumed or, more <del> generically, when the DTLS handshake uses a PSK-based key exchange. Servers which process 0-RTT requests and send 0.5-RTT responses without a cookie exchange risk being used in an amplification attack if the size of outgoing messages greatly exceeds the size of those that are received.  A server SHOULD limit the amount of data it sends toward a client address before it verifies that the client is able to receive data at that address.  A client address is valid after a cookie exchange or handshake completion.  A server MAY apply a higher limit based on heuristics, such as if the client uses the same IP address as the connection on which the cookie was created.  Clients MUST be prepared to do a cookie exchange with every handshake. </del> <ins> generically, when the DTLS handshake uses a PSK-based key exchange and the IP address matches one associated with the PSK.  Servers which process 0-RTT requests and send 0.5-RTT responses without a cookie exchange risk being used in an amplification attack if the size of outgoing messages greatly exceeds the size of those that are received.  A server SHOULD limit the amount of data it sends toward a client address to three times the amount of data sent by the client before it verifies that the client is able to receive data at that address.  A client address is valid after a cookie exchange or handshake completion.  Clients MUST be prepared to do a cookie exchange with every handshake.  Note that cookies are only valid for the existing handshake and cannot be stored for future handshakes. </ins> If a server receives a ClientHello with an invalid cookie, it MUST terminate the handshake with an "illegal_parameter" alert.  This
to "cid_spare", then either existing or new CID MAY be used. Endpoints SHOULD use receiver-provided CIDs in the order they were <del> provided.  Endpoints MUST NOT have more than one NewConnectionId message outstanding. </del> <ins> provided.  Implementations which receive more spare CIDs than they wish to maintain MAY simply discard any extra CIDs.  Endpoints MUST NOT have more than one NewConnectionId message outstanding. </ins> Implementations which either did not negotiate the "connection_id" extension or which have negotiated receiving an empty CID MUST NOT
When a DTLS implementation receives a handshake message fragment corresponding to the next expected handshake message sequence number, <del> it MUST buffer it until it has the entire handshake message.  DTLS implementations MUST be able to handle overlapping fragment ranges. This allows senders to retransmit handshake messages with smaller fragment sizes if the PMTU estimate changes.  Senders MUST NOT change handshake message bytes upon retransmission.  Receivers MAY check that retransmitted bytes are identical and SHOULD abort the handshake with an "illegal_parameter" alert if the value of a byte changes. </del> <ins> it MUST process it, either by buffering it until it has the entire handshake message or by processing any in-order portions of the message.  DTLS implementations MUST be able to handle overlapping fragment ranges.  This allows senders to retransmit handshake messages with smaller fragment sizes if the PMTU estimate changes. Senders MUST NOT change handshake message bytes upon retransmission. Receivers MAY check that retransmitted bytes are identical and SHOULD abort the handshake with an "illegal_parameter" alert if the value of a byte changes. </ins> Note that as with TLS, multiple handshake messages may be placed in the same DTLS record, provided that there is room and that they are
Because the integrity check indirectly depends on a sequence number, if record N is not received, then the integrity check on record N+1 will be based on the wrong sequence number and thus <del> will fail.  DTLS solves this problem by adding explicit sequence numbers. </del> <ins> will fail.  DTLS solves this problem by adding sequence numbers. </ins> The TLS handshake is a lock-step cryptographic handshake. Messages must be transmitted and received in a defined order; any
The DTLSCiphertext structure omits the superfluous version number and type fields. <del> DTLS adds an explicit epoch and sequence number to the TLS record header.  This sequence number allows the recipient to correctly verify the DTLS MAC.  However, the number of bits used for the epoch and sequence number fields in the DTLSCiphertext structure have been reduced. </del> <ins> DTLS adds an epoch and sequence number to the TLS record header. This sequence number allows the recipient to correctly verify the DTLS MAC.  However, the number of bits used for the epoch and sequence number fields in the DTLSCiphertext structure have been reduced. </ins> The DTLSCiphertext structure has a variable length header.
4.2.1. <del> DTLS uses an explicit sequence number, rather than an implicit one, carried in the sequence_number field of the record.  Sequence numbers are maintained separately for each epoch, with each sequence_number initially being 0 for each epoch. </del> <ins> DTLS uses an explicit or partly explicit sequence number, rather than an implicit one, carried in the sequence_number field of the record. Sequence numbers are maintained separately for each epoch, with each sequence_number initially being 0 for each epoch. </ins> The epoch number is initially zero and is incremented each time keying material changes and a sender aims to rekey.  More details are
7.4. <del> The Initiator and the Responder must make sure that unprotected data and metadata do not reveal any sensitive information.  In particular, this applies to AT_KDF, AT_KDF_FS, AT_PUB_ECDHE, and AT_KDF_INPUT. AT_KDF, AT_KDF_FS, and AT_PUB_ECDHE reveals the used cryptographic </del> <ins> Unprotected data and metadata can reveal sensitive information and need to be selected with care.  In particular, this applies to AT_KDF, AT_KDF_FS, AT_PUB_ECDHE, and AT_KDF_INPUT.  AT_KDF, AT_KDF_FS, and AT_PUB_ECDHE reveals the used cryptographic </ins> algorithms, if these depend on the peer identity they leak <del> information about the peer.  AT_KDF_INPUT reveals the network name. An attacker observing network traffic may use such information for traffic flow analysis or to track an endpoint. </del> <ins> information about the peer.  AT_KDF_INPUT reveals the network name, although that is done on purpose to bind the authentication to a particular context. An attacker observing network traffic may use the above types of information for traffic flow analysis or to track an endpoint. </ins> 7.5.
RECOMMENDED to not trust a single source of randomness and to not put unaugmented random numbers on the wire. <ins> Implementations might consider deriving secret and non-secret randomness from different PNRG/PRF/KDF instances to limit the damage if the PNRG/PRF/KDF turns out to be fundamentally broken.  NIST generally forbids deriving secret and non-secret randomness from the same KDF instance, but this decision has been criticized by Krawczyk HKDFpaper and doing so is common practice.  In addition to IVs, other examples are the challenge in EAP-TTLS, the RAND in 3GPP AKAs, and the Session-Id in EAP-TLS 1.3.  Note that part of KEYSTREAM_2 is also non-secret randomness as it is known or predictable to an attacker. As explained by Krawczyk, if any attack is mitigated by the NIST requirement it would mean that the KDF is fully broken and would have to be replaced anyway. </ins> If ECDSA is supported, "deterministic ECDSA" as specified in RFC6979 MAY be used.  Pure deterministic elliptic-curve signatures such as deterministic ECDSA and EdDSA have gained popularity over randomized
payload = MAC_2 CIPHERTEXT_2 is calculated by using the Expand function as a <del> binary additive stream cipher. </del> <ins> binary additive stream cipher over the following plaintext: </ins> <del> plaintext = ( ? PAD, ID_CRED_R / bstr / -24..23, </del> <ins> PLAINTEXT_2 = ( ? PAD, ID_CRED_R / bstr / -24..23, </ins> Signature_or_MAC_2, ? EAD_2 ) If ID_CRED_R contains a single 'kid' parameter, i.e.,
Compute KEYSTREAM_2 = EDHOC-KDF( PRK_2e, TH_2, "KEYSTREAM_2", h'', plaintext_length ), where plaintext_length is the length <del> of the plaintext. </del> <ins> of PLAINTEXT_2. </ins> <del> CIPHERTEXT_2 = plaintext XOR KEYSTREAM_2 </del> <ins> CIPHERTEXT_2 = PLAINTEXT_2 XOR KEYSTREAM_2 </ins> Encode message_2 as a sequence of CBOR encoded data items as specified in asym-msg2-form.
The Initiator SHALL compose message_3 as follows: <del> Compute the transcript hash TH_3 = H(TH_2, CIPHERTEXT_2) where H() </del> <ins> Compute the transcript hash TH_3 = H(TH_2, PLAINTEXT_2) where H() </ins> is the EDHOC hash algorithm of the selected cipher suite.  The transcript hash TH_3 is a CBOR encoded bstr and the input to the <del> hash function is a CBOR Sequence.  Note that H(TH_2, CIPHERTEXT_2) </del> <ins> hash function is a CBOR Sequence.  Note that H(TH_2, PLAINTEXT_2) </ins> can be computed and cached already in the processing of message_2. Compute MAC_3 = EDHOC-KDF( PRK_4x3m, TH_3, "MAC_3", << ID_CRED_I,
Compute a COSE_Encrypt0 object as defined in Sections 5.2 and 5.3 of I-D.ietf-cose-rfc8152bis-struct, with the EDHOC AEAD algorithm of the selected cipher suite, using the encryption key K_3, the <del> initialization vector IV_3, the plaintext P, and the following parameters as input (see COSE): </del> <ins> initialization vector IV_3, the plaintext PLAINTEXT_3, and the following parameters as input (see COSE): </ins> protected = h''
iv_length - length of the initialization vector of the EDHOC AEAD algorithm <del> P = ( ? PAD, ID_CRED_I / bstr / -24..23, Signature_or_MAC_3, ? EAD_3 ) </del> <ins> PLAINTEXT_3 = ( ? PAD, ID_CRED_I / bstr / -24..23, Signature_or_MAC_3, ? EAD_3 ) </ins> If ID_CRED_I contains a single 'kid' parameter, i.e., ID_CRED_I = { 4 : kid_I }, then only the byte string kid_I
Compute a COSE_Encrypt0 as defined in Sections 5.2 and 5.3 of I- D.ietf-cose-rfc8152bis-struct, with the EDHOC AEAD algorithm of the selected cipher suite, using the encryption key K_4, the <del> initialization vector IV_4, the plaintext P, and the following parameters as input (see COSE): </del> <ins> initialization vector IV_4, the plaintext PLAINTEXT_4, and the following parameters as input (see COSE): </ins> protected = h''
typically that which is not possible to infer from routing information in the lower layers. <ins> EDHOC messages might change in transit due to a noisy channel or through modification by an attacker.  Changes in message_1 and message_2 (except PAD_2) are detected when verifying Signature_or_MAC_2.  Changes to PAD_2 and message_3 are detected when verifying CIPHERTEXT_3.  Changes to message_4 are detected when verifying CIPHERTEXT_4. </ins> Compared to SIGMA, EDHOC adds an explicit method type and expands the message authentication coverage to additional elements such as algorithms, external authorization data, and previous plaintext
4.1.3. <del> The pseudorandom key PRK_out, derived as shown in fig-edhoc-kdf, is the only secret key shared between Initiator and Responder that needs to be stored after a successful EDHOC exchange, see m3.  Keys for applications are derived from PRK_out, see exporter. </del> <ins> The pseudorandom key PRK_out, derived as shown in fig-edhoc-kdf is the output of a successful EDHOC exchange.  Keys for applications are derived from PRK_out, see exporter.  An application using EDHOC- KeyUpdate needs to store PRK_out.  If EDHOC-KeyUpdate is not used, an application only needs to store PRK_out or PRK_exporter as long as EDHOC-Exporter is used.  (Note that the word "store" used here does not imply that the application has access to the plaintext PRK_out since that may be reserved for code within a TEE, see impl-cons). </ins> 4.2.
PRK_exporter is derived from PRK_out: where hash_length denotes the output size in bytes of the EDHOC hash <del> algorithm of the selected cipher suite. PRK_exporter MUST be derived anew from PRK_out if EDHOC-KeyUpdate is used, see keyupdate. </del> <ins> algorithm of the selected cipher suite.  Note that PRK_exporter changes every time EDHOC-KeyUpdate is used, see keyupdate. </ins> The (label, context) pair used in EDHOC-Exporter must be unique, i.e., a (label, context) MUST NOT be used for two different purposes.
4.2.2. To provide forward secrecy in an even more efficient way than re- <del> running EDHOC, EDHOC provides the function EDHOC-KeyUpdate.  When EDHOC-KeyUpdate is called, the old PRK_out is deleted and the new PRK_out is calculated as a "hash" of the old key using the Expand function as illustrated by the following pseudocode: </del> <ins> running EDHOC, EDHOC provides the optional function EDHOC-KeyUpdate. When EDHOC-KeyUpdate is called, a new PRK_out is calculated as a "hash" of the old PRK_out using the Expand function as illustrated by the following pseudocode.  The change of PRK_out causes a change to PRK_exporter and derived keys using EDHOC-Exporter. </ins> where hash_length denotes the output size in bytes of the EDHOC hash algorithm of the selected cipher suite.
The EDHOC-KeyUpdate takes a context as input to enable binding of the updated PRK_out to some event that triggered the keyUpdate.  The Initiator and the Responder need to agree on the context, which can, <del> e.g., be a counter or a pseudorandom number such as a hash.  The Initiator and the Responder also need to cache the old PRK_out until it has verfied that the other endpoint has the correct new PRK_out. </del> <ins> e.g., be a counter or a pseudorandom number such as a hash.  To provide forward secrecy the old PRK_out and derived keys must be deleted as soon as they are not needed.  When to delete the old keys and how to verify that they are not needed is up to the application. </ins> I-D.ietf-core-oscore-key-update describes key update for OSCORE using EDHOC-KeyUpdate.
identifiers from EDHOC SHOULD provide mechanisms to update the connection identifier and MAY provide mechanisms to issue several simultaneously active connection identifiers.  See RFC9000 for a non- <del> constrained example of such mechanisms.  Connection identifiers SHOULD be unpredictable.  Using the same identifier several times is not a problem as long as it is chosen randomly.  Connection identity privacy mechanisms are only useful when there are not fixed identifiers such as IP address or MAC address in the lower layers. </del> <ins> constrained example of such mechanisms.  Connection identifiers can e.g., be chosen randomly among the set of unused 1-byte connection identifiers.  Connection identity privacy mechanisms are only useful when there are not fixed identifiers such as IP address or MAC address in the lower layers. </ins> 8.6.
With static Diffie-Hellman key authentication, the authenticating endpoint can deny having participated in the protocol. <del> Two earlier versions of EDHOC have been formally analyzed Norrman20 Bruni18 and the specification has been updated based on the analysis. </del> <ins> Three earlier versions of EDHOC have been formally analyzed Jacomme23 Norrman20 Bruni18 and the specification has been updated based on the analysis. </ins> 8.2.
member impersonate another group member, but a malicious non-member can reroute handshakes between honest group members to connect them in unintended ways.  A naive sharing of PSKs, even assuming only <del> honest but curious participants know the key, does not enforce any of these properties, bar one.  Endpoint Identity Protection holds vacuously, because the client and server do not use certificates in PSK mode.  (This is not true with use of the "tls_cert_with_extern_psk" extension I-D.ietf-tls-tls13-cert-with- extern-psk.) </del> <ins> honest but curious participants know the key, can violate all these properties, bar one.  Endpoint Identity Protection holds vacuously, because the client and server do not use certificates in PSK mode. (This is not true with use of the "tls_cert_with_extern_psk" extension I-D.ietf-tls-tls13-cert-with-extern-psk.) </ins> In the following sub-sections, we list attacks that demonstrate violations of these properties when the fundamental PSK assumption <del> does not hold.  This list is not exhaustive, but merely highlights a number of potential pitfalls. </del> <ins> does not hold. </ins> 3.1.1.
properties outlined above.  The attack violates the same session keys property, as "A" and "B" have each completed a session, ostensibly with each other, and yet do not agree on the session key.  If "A" <del> does not send a key share, then the attacker can have a session with "A" and a separate session with "B", where both sessions have the same key.  This violates the uniqueness of session keys property.  In the case of KCI resistance, where we assume the attacker has compromised "A", the attacker can successfully impersonate "B" to "A" using this pattern. </del> <ins> does not send a key share extension, then the attacker can have a session with "A" and a separate session with "B", where both sessions have the same key.  Since the attacker has knowledge of all of the messages and their content, the nonce in the handshake does not prevent the attacker from computing the full key schedule.  This violates the uniqueness of session keys property.  In the case of KCI resistance, where we assume the attacker has compromised "A", the attacker can successfully impersonate "B" to "A" using this pattern. </ins> 4. <del> Given the desired security goals from sec-properties, applications which make use of external PSKs MUST adhere to the following requirements: </del> <ins> To achieve the security goals from sec-properties when the external PSK will not be combined with a pairwise secret value, applications MUST use external PSKs that adhere to the following requirements: </ins> Each PSK MUST NOT be shared between with more than two logical nodes.  As a result, an agent that acts as both a client and a
appearing in cleartext in a ClientHello.  As a result, a passive adversary can link two or more connections together that use the same external PSK on the wire.  Applications should take precautions when <del> using external PSKs if these risks are a concern. </del> <ins> using external PSKs if these risks. </ins> In addition to linkability in the network, external PSKs are intrinsically linkable by PSK receivers.  Specifically, servers can
First Use (TOFU) approach with a device completely unprotected before the first login did take place).  Many devices have very limited UI.  For example, they may only have a numeric keypad or <del> perhaps an interface with even fewer buttons.  When the TOFU approach is not suitable, entering the key may require typing it on a very constrained UI.  Moreover, PSK production lacks guidance unlike user passwords. </del> <ins> even less number of buttons.  When the TOFU approach is not suitable, entering the key would require typing it on a constrained UI.  Moreover, PSK production lacks guidance unlike user passwords. </ins> Some devices are provisioned PSKs via an out-of-band, cloud-based syncing protocol.
1. <del> This document provides usage guidance for external Pre-Shared Keys (PSKs) in TLS.  It lists TLS security properties provided by PSKs under certain assumptions and demonstrates how violations of these assumptions lead to attacks.  This document also discusses PSK use cases, provisioning processes, and TLS stack implementation support in the context of these assumptions.  It provides advice for applications in various use cases to help meet these assumptions. </del> <ins> There are many resources that provide guidance for password generation and verification aimed towards improving security. However, there is no such equivalent for external Pre-Shared Keys (PSKs) in TLS.  This document aims to reduce that gap.  It lists TLS security properties provided by PSKs under certain assumptions and demonstrates how violations of these assumptions lead to attacks. This document also discusses PSK use cases, provisioning processes, and TLS stack implementation support in the context of these assumptions.  It provides advice for applications in various use cases to help meet these assumptions. </ins> The guidance provided in this document is applicable across TLS RFC8446, DTLS I-D.ietf-tls-dtls13, and Constrained TLS I-D.ietf-tls-