jiebi/TextFlow huggingface dataset:
Original text:
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>  Some devices are provisioned PSKs via an out-of-band, cloud-based syncing protocol.

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:
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  <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.
Original text:
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>  The guidance provided in this document is applicable across TLS RFC8446, DTLS I-D.ietf-tls-dtls13, and Constrained TLS I-D.ietf-tls-

Reviewer comments:
The comment about how there are no guidelines about PSKs like there are about generating passwords seemed like a statement of the motivation for this draft, so I moved it to the introduction. (I was going to add a reference for the statement, but I couldn't figure out how to get the citation to compile correctly. This was the document I was going to cite, in case you think it needs it: URL)

Revised text:
1.  <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-
Original text:
6. <del> Pre-shared Key (PSK) ciphersuites were first specified for TLS in 2005.  Now, PSK is an integral part of the TLS version 1.3 specification RFC8446.  TLS 1.3 also uses PSKs for session resumption.  It distinguishes these resumption PSKs from external PSKs which have been provisioned out-of-band (OOB).  Below, we list some example use-cases where pair-wise external PSKs (i.e., external PSKs that are shared between only one server and one client) have been used for authentication in TLS. </del>  Device-to-device communication with out-of-band synchronized keys. PSKs provisioned out-of-band for communicating with known

Reviewer comments:
The comment about how there are no guidelines about PSKs like there are about generating passwords seemed like a statement of the motivation for this draft, so I moved it to the introduction. (I was going to add a reference for the statement, but I couldn't figure out how to get the citation to compile correctly. This was the document I was going to cite, in case you think it needs it: URL)

Revised text:
6.  <ins> PSK ciphersuites were first specified for TLS in 2005.  Now, PSKs are an integral part of the TLS version 1.3 specification RFC8446.  TLS 1.3 also uses PSKs for session resumption.  It distinguishes these resumption PSKs from external PSKs which have been provisioned out- of-band (OOB).  Below, we list some example use-cases where pair-wise external PSKs (i.e., external PSKs that are shared between only one server and one client) have been used for authentication in TLS. </ins> Device-to-device communication with out-of-band synchronized keys. PSKs provisioned out-of-band for communicating with known
Original text:
limited UI.  For example, they may only have a numeric keypad or even less number of buttons.  When the TOFU approach is not suitable, entering the key would require typing it on a <del> constrained UI.  Moreover, PSK production lacks guidance unlike user passwords. </del>  Some devices provision PSKs via an out-of-band, cloud-based syncing protocol.

Reviewer comments:
The comment about how there are no guidelines about PSKs like there are about generating passwords seemed like a statement of the motivation for this draft, so I moved it to the introduction. (I was going to add a reference for the statement, but I couldn't figure out how to get the citation to compile correctly. This was the document I was going to cite, in case you think it needs it: URL)

Revised text:
limited UI.  For example, they may only have a numeric keypad or even less number of buttons.  When the TOFU approach is not suitable, entering the key would require typing it on a  <ins> constrained UI. </ins> Some devices provision PSKs via an out-of-band, cloud-based syncing protocol.
Original text:
Keys (PSKs) in Transport Layer Security (TLS) 1.3 RFC8446.  This guidance also applies to Datagram TLS (DTLS) 1.3 I-D.ietf-tls-dtls13 and Compact TLS 1.3 I-D.ietf-tls-ctls.  For readability, this <del> document uses the term TLS to refer to all such versions.  External PSKs are symmetric secret keys provided to the TLS protocol </del>  implementation as external inputs.  External PSKs are provisioned <del> out-of-band.  This document lists TLS security properties provided by PSKs under certain assumptions and demonstrates how violations of these assumptions lead to attacks.  This document discusses PSK use cases, provisioning processes, and TLS stack implementation support in the context of these assumptions.  This document also provides advice for applications in various use cases to help meet these assumptions. </del>  There are many resources that provide guidance for password generation and verification aimed towards improving security.

Reviewer comments:
More = better. There are a few other places that this treatment might be applied elsewhere if the editors feel that way inclined. This seemed to be the most important.
I'll do a pass for other obvious paragraphs that can be split up.

Revised text:
Keys (PSKs) in Transport Layer Security (TLS) 1.3 RFC8446.  This guidance also applies to Datagram TLS (DTLS) 1.3 I-D.ietf-tls-dtls13 and Compact TLS 1.3 I-D.ietf-tls-ctls.  For readability, this  <ins> document uses the term TLS to refer to all such versions. External PSKs are symmetric secret keys provided to the TLS protocol </ins> implementation as external inputs.  External PSKs are provisioned  <ins> out-of-band. This document lists TLS security properties provided by PSKs under certain assumptions and demonstrates how violations of these assumptions lead to attacks.  This document discusses PSK use cases, provisioning processes, and TLS stack implementation support in the context of these assumptions.  This document also provides advice for applications in various use cases to help meet these assumptions. </ins> There are many resources that provide guidance for password generation and verification aimed towards improving security.
Original text:
This document provides usage guidance for external Pre-Shared Keys (PSKs) in Transport Layer Security (TLS) 1.3 as defined in RFC 8446. <del> This document lists TLS security properties provided by PSKs under certain assumptions, and then demonstrates how violations of these assumptions lead to attacks.  This document discusses PSK use cases and provisioning processes.  This document provides advice for applications to help meet these assumptions.  This document also lists the privacy and security properties that are not provided by TLS 1.3 when external PSKs are used. </del>  1.

Reviewer comments:
Address comments from IESG evaluation. Due to the holiday season, we may not get prompt confirmation that these changes fully resolve the comments.

Revised text:
This document provides usage guidance for external Pre-Shared Keys (PSKs) in Transport Layer Security (TLS) 1.3 as defined in RFC 8446.  <ins> It lists TLS security properties provided by PSKs under certain assumptions, and then demonstrates how violations of these assumptions lead to attacks.  Advice for applications to help meet these assumptions is provided.  It also discusses PSK use cases and provisioning processes.  Finally, it lists the privacy and security properties that are not provided by TLS 1.3 when external PSKs are used. </ins> 1.
Original text:
If PSK is not combined with fresh ephemeral key exchange, then compromise of any group member allows the attacker to passively <del> read (and actively modify) all traffic. </del>  Additionally, a malicious non-member can reroute handshakes between honest group members to connect them in unintended ways, as described

Reviewer comments:
Address comments from IESG evaluation. Due to the holiday season, we may not get prompt confirmation that these changes fully resolve the comments.

Revised text:
If PSK is not combined with fresh ephemeral key exchange, then compromise of any group member allows the attacker to passively  <ins> read (and actively modify) all traffic, including past traffic. </ins> Additionally, a malicious non-member can reroute handshakes between honest group members to connect them in unintended ways, as described
Original text:
value and the receiving member's known identity.  See Selfie for details. <del> To illustrate the rerouting attack, consider the group of peers who know the PSK be "A", "B", and "C".  The attack proceeds as follows: </del>  "A" sends a "ClientHello" to "B".

Reviewer comments:
Address comments from IESG evaluation. Due to the holiday season, we may not get prompt confirmation that these changes fully resolve the comments.

Revised text:
value and the receiving member's known identity.  See Selfie for details.  <ins> To illustrate the rerouting attack, consider three peers, "A", "B", and "C", who all know the PSK.  The attack proceeds as follows: </ins> "A" sends a "ClientHello" to "B".
Original text:
Entropy properties of external PSKs may also affect TLS security properties.  For example, if a high entropy PSK is used, then PSK- only key establishment modes provide expected security properties for <del> TLS, including, for example, including establishing the same session keys between peers, secrecy of session keys, peer authentication, and downgrade protection.  See RFC8446, Section E.1 for an explanation of these properties.  However, these modes lack forward security. Forward security may be achieved by using a PSK-DH mode, or, alternatively, by using PSKs with short lifetimes. </del>  In contrast, if a low entropy PSK is used, then PSK-only key establishment modes are subject to passive exhaustive search attacks

Reviewer comments:
Address comments from IESG evaluation. Due to the holiday season, we may not get prompt confirmation that these changes fully resolve the comments.

Revised text:
Entropy properties of external PSKs may also affect TLS security properties.  For example, if a high entropy PSK is used, then PSK- only key establishment modes provide expected security properties for  <ins> TLS, including establishing the same session keys between peers, secrecy of session keys, peer authentication, and downgrade protection.  See RFC8446, Section E.1 for an explanation of these properties.  However, these modes lack forward security.  Forward security may be achieved by using a PSK-DH mode, or, alternatively, by using PSKs with short lifetimes. </ins> In contrast, if a low entropy PSK is used, then PSK-only key establishment modes are subject to passive exhaustive search attacks
Original text:
This section lists some example use-cases where pair-wise external PSKs, i.e., external PSKs that are shared between only one server and <del> one client, have been used for authentication in TLS. </del>  Device-to-device communication with out-of-band synchronized keys. PSKs provisioned out-of-band for communicating with known

Reviewer comments:
Address comments from IESG evaluation. Due to the holiday season, we may not get prompt confirmation that these changes fully resolve the comments.

Revised text:
This section lists some example use-cases where pair-wise external PSKs, i.e., external PSKs that are shared between only one server and  <ins> one client, have been used for authentication in TLS.  There was no attempt to prioritize the examples in any particular order. </ins> Device-to-device communication with out-of-band synchronized keys. PSKs provisioned out-of-band for communicating with known
Original text:
different online protocol. Intra-data-center communication.  Machine-to-machine communication <del> within a single data center or PoP may use externally provisioned PSKs, primarily for the purposes of supporting TLS connections with early data; see security-con for considerations when using early data with external PSKs. </del>  Certificateless server-to-server communication.  Machine-to- machine communication may use externally provisioned PSKs,

Reviewer comments:
Address comments from IESG evaluation. Due to the holiday season, we may not get prompt confirmation that these changes fully resolve the comments.

Revised text:
different online protocol. Intra-data-center communication.  Machine-to-machine communication  <ins> within a single data center or point-of-presence (PoP) may use externally provisioned PSKs, primarily for the purposes of supporting TLS connections with early data; see security-con for considerations when using early data with external PSKs. </ins> Certificateless server-to-server communication.  Machine-to- machine communication may use externally provisioned PSKs,
Original text:
PSK into the devices, or using a Trust On First Use (TOFU) approach with a device completely unprotected before the first login did take place.  Many devices have very limited UI.  For <del> example, they may only have a numeric keypad or even less number of buttons.  When the TOFU approach is not suitable, entering the key would require typing it on a constrained UI. </del>  Some devices provision PSKs via an out-of-band, cloud-based syncing protocol. <del> Some secrets may be baked into or hardware or software device </del>  components.  Moreover, when this is done at manufacturing time, secrets may be printed on labels or included in a Bill of Materials for ease of scanning or import.

Reviewer comments:
Address comments from IESG evaluation. Due to the holiday season, we may not get prompt confirmation that these changes fully resolve the comments.

Revised text:
PSK into the devices, or using a Trust On First Use (TOFU) approach with a device completely unprotected before the first login did take place.  Many devices have very limited UI.  For  <ins> example, they may only have a numeric keypad or even fewer buttons.  When the TOFU approach is not suitable, entering the key would require typing it on a constrained UI. </ins> Some devices provision PSKs via an out-of-band, cloud-based syncing protocol.  <ins> Some secrets may be baked into hardware or software device </ins> components.  Moreover, when this is done at manufacturing time, secrets may be printed on labels or included in a Bill of Materials for ease of scanning or import.
Original text:
identifiers have privacy implications; see endpoint-privacy. Each endpoint SHOULD know the identifier of the other endpoint with <del> which its wants to connect and SHOULD compare it with the other </del>  endpoint's identifier used in ImportedIdentity.context.  It is however important to remember that endpoints sharing the same group PSK can always impersonate each other.

Reviewer comments:
Address comments from IESG evaluation. Due to the holiday season, we may not get prompt confirmation that these changes fully resolve the comments.

Revised text:
identifiers have privacy implications; see endpoint-privacy. Each endpoint SHOULD know the identifier of the other endpoint with  <ins> which it wants to connect and SHOULD compare it with the other </ins> endpoint's identifier used in ImportedIdentity.context.  It is however important to remember that endpoints sharing the same group PSK can always impersonate each other.
Original text:
REQUIRED.  A unique access token for continuing the request, in the format specified in response-token-single.  This access token MUST be bound to the client instance's key used in the request and <del> MUST NOT be a "bearer" token.  As a consequence, the "bound" field of this access token is always the boolean value "true" and the </del>  "key" field MUST be omitted.  This access token MUST NOT be usable at resources outside of the AS.  The client instance MUST present the access token in all requests to the continuation URI as

Reviewer comments:
URL match the flags array in the token request. While this is technically a breaking change, I think we should consider this editorial as this should have been changed when we made the original change to use a flags array in the request in .
:heavycheckmark: Deploy Preview for gnap-core-protocol-editors-draft ready! Built :hammer: Explore the source changes: 8c793bb446d82f053536358106485568fc457842 :mag: Inspect the deploy log: :sunglasses: Browse the preview:
You know, I had that thought, and I checked the request section and it doesn't have quotes. I'm going to add the quotes to both parts. This ended up with some other language changing, not just the examples, so let me know what you think.

Revised text:
REQUIRED.  A unique access token for continuing the request, in the format specified in response-token-single.  This access token MUST be bound to the client instance's key used in the request and  <ins> MUST NOT be a "bearer" token.  As a consequence, the "flags" array of this access token MUST NOT contain the string "bearer" and the </ins> "key" field MUST be omitted.  This access token MUST NOT be usable at resources outside of the AS.  The client instance MUST present the access token in all requests to the continuation URI as
Original text:
ASCII characters to facilitate transmission over HTTP headers within other protocols without requiring additional encoding. <del> RECOMMENDED.  Flag indicating if the token is bound to the client instance's key.  If the boolean value is "true" or the field is omitted, and the "key" field is omitted, the token is bound to the request-client in its request for access.  If the boolean value is "true" or the field is omitted, and the "key" field is present, the token is bound to the key and proofing mechanism indicated in the "key" field.  If the boolean value is "false", the token is a bearer token with no key bound to it and the "key" field MUST be omitted. </del> REQUIRED for multiple access tokens, OPTIONAL for single access token.  The value of the "label" the client instance provided in the associated request-token, if present.  If the token has been

Reviewer comments:
URL match the flags array in the token request. While this is technically a breaking change, I think we should consider this editorial as this should have been changed when we made the original change to use a flags array in the request in .
:heavycheckmark: Deploy Preview for gnap-core-protocol-editors-draft ready! Built :hammer: Explore the source changes: 8c793bb446d82f053536358106485568fc457842 :mag: Inspect the deploy log: :sunglasses: Browse the preview:
You know, I had that thought, and I checked the request section and it doesn't have quotes. I'm going to add the quotes to both parts. This ended up with some other language changing, not just the examples, so let me know what you think.

Revised text:
ASCII characters to facilitate transmission over HTTP headers within other protocols without requiring additional encoding.  REQUIRED for multiple access tokens, OPTIONAL for single access token.  The value of the "label" the client instance provided in the associated request-token, if present.  If the token has been