jiebi/TextFlow huggingface dataset:
Original text:
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>  5.6.

Reviewer comments:
You don't want to age out before you get epoch 3 because otherwise you might be dropping when you have handshake packets.
For my understanding: what is the harm of keeping the 0-RTT keys around till the end of the handshake?
"Yes, the goal is to encourage people not to keep 0-RTT keys too long, because they might not have PCS. The replay risk is essentially a non-issue, except to the extent that it might already have been replayed."

Revised text:
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  <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.
Original text:
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>  The number of CIDs desired.

Reviewer comments:
It's possible to negotiate the CID extension but that you want to receive an empty CID (this is how you get asymmetrical CID lengths). The current text says: CID. If an implementation receives these messages when CIDs were not negotiated, it MUST abort the connection with an unexpected_message alert. But does this mean that (for instance) you can negotiate receiving an empty CID and then switch to a non-empty? I am tempted to say "no" as I recall QUIC did.
Doing what QUIC did seems prudent ... and if I didn't know what QUIC did I think I would also lean towards disallowing switching between empty and non-empty on a live connection.

Revised text:
provided.  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 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.
Original text:
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>  The TLS handshake is a lock-step cryptographic handshake. Messages must be transmitted and received in a defined order; any

Reviewer comments:
The draft states in three places that DTLS use explicit sequence numbers, while this was true for DTLS 1.2, the sequence number in the DTLSCipherstructure is a mixture of implicit and explict. Maybe "Partly Explicit"?
Please provide me with a PR to add your name to acknowledgements.
Hi, I don’t know what PR is an abbreviation for but I guess it is not clear from my username who I am. I should probably update it, I did not intend to be anonymous :) John Mattsson, Ericsson, EMAIL

Revised text:
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  <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
Original text:
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>  The DTLSCiphertext structure has a variable length header.

Reviewer comments:
The draft states in three places that DTLS use explicit sequence numbers, while this was true for DTLS 1.2, the sequence number in the DTLSCipherstructure is a mixture of implicit and explict. Maybe "Partly Explicit"?
Please provide me with a PR to add your name to acknowledgements.
Hi, I don’t know what PR is an abbreviation for but I guess it is not clear from my username who I am. I should probably update it, I did not intend to be anonymous :) John Mattsson, Ericsson, EMAIL

Revised text:
The DTLSCiphertext structure omits the superfluous version number and type fields.  <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.
Original text:
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>  The epoch number is initially zero and is incremented each time keying material changes and a sender aims to rekey.  More details are

Reviewer comments:
The draft states in three places that DTLS use explicit sequence numbers, while this was true for DTLS 1.2, the sequence number in the DTLSCipherstructure is a mixture of implicit and explict. Maybe "Partly Explicit"?
Please provide me with a PR to add your name to acknowledgements.
Hi, I don’t know what PR is an abbreviation for but I guess it is not clear from my username who I am. I should probably update it, I did not intend to be anonymous :) John Mattsson, Ericsson, EMAIL

Revised text:
4.2.1.  <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
Original text:
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>  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>  7.5.

Reviewer comments:
Suggested fix for
Karl: -- In Section 7.4 it says: "The Initiator and the Responder must make sure that unprotected data and metadata do not reveal any sensitive information." Should it be put in a less requirement-like form? For example: "unprotected data and metadata can reveal sensitive information and need to be selected with care."?
I agree that the metadata text should not be requirement form as much as it is now – there’s little that implementations can actually do about this, e.g., about the network name. Will make a PR.

Revised text:
7.4.  <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  <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.
Original text:
RECOMMENDED to not trust a single source of randomness and to not put unaugmented random numbers on the wire.  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

Reviewer comments:
I think this can be merged.
Fixed the problem with ':' in refs. Now merging.
Based on Stephens review
Referring to this in :
From the PR : "As explained by Krawczyk, any attack mitigated by the NIST requiment would mean that the KDF is fully broken and would have to be replaced anyway." I didn't understand "any attack mitigated by the NIST requirement", and how mitigation could imply that something is broken. As far as I understand, the statement is something like "if there is a problem deriving secret and non-secret material from the same KDF, then there is a problem with the KDF" Perhaps "an attack based on the violation of the NIST requirement is an attack on the KDF itself"?
Yes, it was likely meants to say "if any attack is mitigate" Let's reformulate according to your suggestion
I made a commit to correct spelling and grammar. I don't think we can give applications more guidance here. How to gererate e.g. private key in certificates are way outside of EDHOC, and it would anyway be hard to say something general as deployments might look very different.I did not want to say anything about randomly generated conenction ID as that is not how connection IDs is meant to be generated. They are intended to be as short as possible. An implentation is allowed to use long random bytestrings but is not recommended in general.
PR merged

Revised text:
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
Original text:
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>  8.6.

Reviewer comments:
Suggestion to clarify and maybe give example of randomness and unpredictability. The SHOULD should probably be removed. Unclear if 1 byte identifiers can ever by unpredictable.
Closing this as approved by Marco.
Looks good to me. NAME ?

Revised text:
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-  <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.
Original text:
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>  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>  3.1.1.

Reviewer comments:
Changes to comments from Russ Housley on 03-Mar-2020
Section 3.1.1: The text says: C responds with to A. I think that C responds with a ServerHello to A. Section 3.1.2: The text says: A sends a ClientHello to B, without including a key share. It would be helpful to say "without including a key share extension." Section 3.1.3: I think a bit more explanation is needed here. Nonces can make the keys different, why doesn't the nonce from the uncompromised party help in this example? Section 4: I would like to see a bit more context here. I agree with the recommendations for the intended environment, but they are overkill in the environment suggested by draft-ietf-tls-tls13-cert-with-extern-psk. In fact, they are overkill if (EC)DH is combined with the PSK at all. So, maybe we just need to say that the PSK is not combined with a pairwise key that these rules apply.
Fixed by .
LGTM -- thanks, Russ!

Revised text:
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  <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  <ins> does not hold. </ins> 3.1.1.
Original text:
The attacker intercepts the message and redirects it to "C". <del> "C" responds with to "A". </del>  "A" sends a "Finished" message to "B".  "A" has completed the handshake, ostensibly with "B".

Reviewer comments:
Changes to comments from Russ Housley on 03-Mar-2020
Section 3.1.1: The text says: C responds with to A. I think that C responds with a ServerHello to A. Section 3.1.2: The text says: A sends a ClientHello to B, without including a key share. It would be helpful to say "without including a key share extension." Section 3.1.3: I think a bit more explanation is needed here. Nonces can make the keys different, why doesn't the nonce from the uncompromised party help in this example? Section 4: I would like to see a bit more context here. I agree with the recommendations for the intended environment, but they are overkill in the environment suggested by draft-ietf-tls-tls13-cert-with-extern-psk. In fact, they are overkill if (EC)DH is combined with the PSK at all. So, maybe we just need to say that the PSK is not combined with a pairwise key that these rules apply.
Fixed by .
LGTM -- thanks, Russ!

Revised text:
The attacker intercepts the message and redirects it to "C".  <ins> "C" responds with a "ServerHello" to "A". </ins> "A" sends a "Finished" message to "B".  "A" has completed the handshake, ostensibly with "B".
Original text:
Let the group of peers who know the key be "A", "B", and "C".  The attack proceeds as follows: <del> "A" sends a "ClientHello" to "B", without including a key share. </del>  The handshake completes as expected.

Reviewer comments:
Changes to comments from Russ Housley on 03-Mar-2020
Section 3.1.1: The text says: C responds with to A. I think that C responds with a ServerHello to A. Section 3.1.2: The text says: A sends a ClientHello to B, without including a key share. It would be helpful to say "without including a key share extension." Section 3.1.3: I think a bit more explanation is needed here. Nonces can make the keys different, why doesn't the nonce from the uncompromised party help in this example? Section 4: I would like to see a bit more context here. I agree with the recommendations for the intended environment, but they are overkill in the environment suggested by draft-ietf-tls-tls13-cert-with-extern-psk. In fact, they are overkill if (EC)DH is combined with the PSK at all. So, maybe we just need to say that the PSK is not combined with a pairwise key that these rules apply.
Fixed by .
LGTM -- thanks, Russ!

Revised text:
Let the group of peers who know the key be "A", "B", and "C".  The attack proceeds as follows:  <ins> "A" sends a "ClientHello" to "B", without including a key share extension. </ins> The handshake completes as expected.
Original text:
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>  4. <del> Given the desired security goals from sec-properties, applications which make use of external PSKs MUST adhere to the following requirements: </del>  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

Reviewer comments:
Changes to comments from Russ Housley on 03-Mar-2020
Section 3.1.1: The text says: C responds with to A. I think that C responds with a ServerHello to A. Section 3.1.2: The text says: A sends a ClientHello to B, without including a key share. It would be helpful to say "without including a key share extension." Section 3.1.3: I think a bit more explanation is needed here. Nonces can make the keys different, why doesn't the nonce from the uncompromised party help in this example? Section 4: I would like to see a bit more context here. I agree with the recommendations for the intended environment, but they are overkill in the environment suggested by draft-ietf-tls-tls13-cert-with-extern-psk. In fact, they are overkill if (EC)DH is combined with the PSK at all. So, maybe we just need to say that the PSK is not combined with a pairwise key that these rules apply.
Fixed by .
LGTM -- thanks, Russ!

Revised text:
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"  <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.  <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
Original text:
Each PSK MUST be at least 128-bits long. <del> Each PSK SHOULD be seeded from a source with at least 128-bits of entropy. </del> 5. PSK privacy properties are orthogonal to security properties

Reviewer comments:
Changes to comments from Russ Housley on 03-Mar-2020
Section 3.1.1: The text says: C responds with to A. I think that C responds with a ServerHello to A. Section 3.1.2: The text says: A sends a ClientHello to B, without including a key share. It would be helpful to say "without including a key share extension." Section 3.1.3: I think a bit more explanation is needed here. Nonces can make the keys different, why doesn't the nonce from the uncompromised party help in this example? Section 4: I would like to see a bit more context here. I agree with the recommendations for the intended environment, but they are overkill in the environment suggested by draft-ietf-tls-tls13-cert-with-extern-psk. In fact, they are overkill if (EC)DH is combined with the PSK at all. So, maybe we just need to say that the PSK is not combined with a pairwise key that these rules apply.
Fixed by .
LGTM -- thanks, Russ!

Revised text:
Each PSK MUST be at least 128-bits long.  5. PSK privacy properties are orthogonal to security properties
Original text:
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>  In addition to linkability in the network, external PSKs are intrinsically linkable by PSK receivers.  Specifically, servers can

Reviewer comments:
Changes to comments from Russ Housley on 03-Mar-2020
Section 3.1.1: The text says: C responds with to A. I think that C responds with a ServerHello to A. Section 3.1.2: The text says: A sends a ClientHello to B, without including a key share. It would be helpful to say "without including a key share extension." Section 3.1.3: I think a bit more explanation is needed here. Nonces can make the keys different, why doesn't the nonce from the uncompromised party help in this example? Section 4: I would like to see a bit more context here. I agree with the recommendations for the intended environment, but they are overkill in the environment suggested by draft-ietf-tls-tls13-cert-with-extern-psk. In fact, they are overkill if (EC)DH is combined with the PSK at all. So, maybe we just need to say that the PSK is not combined with a pairwise key that these rules apply.
Fixed by .
LGTM -- thanks, Russ!

Revised text:
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  <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