jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-tls-external-psk-guidance

Commentary: Thanks !
Paragraph (version A):
The use of a previously established PSK allows TLS nodes to
authenticate the endpoint identities.  It also offers other benefits,
including resistance to attacks in presence of quantum computes; see
entropy for related discussion.  However, these keys do not provide
privacy protection of endpoint identities, nor do they provide non-
repudiation (one endpoint in a connection can deny the conversation);
see endpoint-privacy for related discussion.
Paragraph (version B):
The use of a previously established PSK allows TLS nodes to
authenticate the endpoint identities.  It also offers other benefits,
including resistance to attacks in presence of quantum computers; see
entropy for related discussion.  However, these keys do not provide
privacy protection of endpoint identities, nor do they provide non-
repudiation (one endpoint in a connection can deny the conversation);
see endpoint-privacy for related discussion.
Paragraph (version A):
The exact provisioning process depends on the system requirements and
threat model.  Whenever possible, avoid sharing a PSK between nodes;
however, sharing a PSK among several node is sometimes unavoidable.
When PSK sharing happens, other accommodations SHOULD be used as
discussed in recommendations.
Paragraph (version B):
The exact provisioning process depends on the system requirements and
threat model.  Whenever possible, avoid sharing a PSK between nodes;
however, sharing a PSK among several nodes is sometimes unavoidable.
When PSK sharing happens, other accommodations SHOULD be used as
discussed in recommendations.
Paragraph (version A):
Considerations for external PSK usage extend beynond proper
identification.  When early data is used with an external PSK, the
random value in the ClientHello is the only source of entropy that
contributes to key diversity between sessions.  As a result, when an
external PSK is used more than one time, the random number source on
the client has a significant role in the protection of the early
data.
Paragraph (version B):
Considerations for external PSK usage extend beyond proper
identification.  When early data is used with an external PSK, the
random value in the ClientHello is the only source of entropy that
contributes to key diversity between sessions.  As a result, when an
external PSK is used more than one time, the random number source on
the client has a significant role in the protection of the early
data.
Draft: draft-ietf-tls-external-psk-guidance

Commentary: cc 
 Looks good to me . 
 So the draft talks about collisions between PSK identities , with some assumptions baked in : and resumption PSK identities are trivial to keep distinct ( it takes a single bit ) , but the draft assumes that this step is not taken might be necessary to generate PSK identities without any sort of centralized coordination , which means that you might need to worry about collisions , but that 's another unstated assumption That first one is pretty poor . 
 It seems to me that we need to warn implementers about the situation if external and resumption PSKs are not kept distinct . We could include advice to keep them separate . 
 I suggest the addition of a paragraph at the end of the Section on " PSK Identity Collisions " . Since resumption PSK identity is assigned by the TLS stack implementation , it is RECOMMENDED that these identifiers be assigned in a manner that lets resumption PSKs be distinguished from external PSKs to avoid concerns with collisions altogether .
Paragraph (version B):
Since resumption PSK identities are assigned by the TLS stack
implementation, it is RECOMMENDED that these identifiers be assigned
in a manner that lets resumption PSKs be distinguished from external
PSKs to avoid concerns with collisions altogether.
Draft: draft-ietf-tls-external-psk-guidance

Commentary: 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 .
Paragraph (version A):
This document provides guidance on the use of external Pre-Shared
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
document uses the term TLS to refer to all such versions.  External
PSKs are symmetric secret keys provided to the TLS protocol
implementation as external inputs.  External PSKs are provisioned
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.
Paragraph (version B):
This document provides guidance on the use of external Pre-Shared
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
document uses the term TLS to refer to all such versions.
Paragraph (version B):
External PSKs are symmetric secret keys provided to the TLS protocol
implementation as external inputs.  External PSKs are provisioned
out-of-band.
Paragraph (version B):
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.
Draft: draft-ietf-tls-external-psk-guidance

Commentary: s7 includes the following and in light of 8446bis we should probable replace " master " : Where possible the master PSK ( that which is fed into the importer ) SHOULD be deleted after the imported keys have been generated . This protects an attacker from bootstrapping a compromise of one node into the ability to attack connections between any node ; otherwise the attacker can recover the master key and then re - run the importer itself .
Paragraph (version A):
Where possible the master PSK (that which is fed into the
importer) SHOULD be deleted after the imported keys have been
generated.  This protects an attacker from bootstrapping a
compromise of one node into the ability to attack connections
between any node; otherwise the attacker can recover the master
key and then re-run the importer itself.
Paragraph (version B):
Where possible the main PSK (that which is fed into the importer)
SHOULD be deleted after the imported keys have been generated.
This protects an attacker from bootstrapping a compromise of one
node into the ability to attack connections between any node;
otherwise the attacker can recover the main key and then re-run
the importer itself.
Draft: draft-ietf-tls-external-psk-guidance

Commentary: Since the term ' fast open ' is n't used in RFC 8446 , replace ' fast open ' with the term that RFC 8446 uses for ' 0 - RTT data'--namely , ' early data . '
Paragraph (version A):
Intra-data-center communication.  Machine-to-machine communication
within a single data center or PoP may use externally provisioned
PSKs, primarily for the purposes of supporting TLS connections
with fast open (0-RTT data).
Paragraph (version B):
Intra-data-center communication.  Machine-to-machine communication
within a single data center or PoP may use externally provisioned
PSKs, primarily for the purposes of supporting TLS connections
with early data.
Draft: draft-ietf-tls-external-psk-guidance

Commentary: I 'm not sure what makes a collision obvious versus non - obvious , so let 's remove the word " obvious . "
Paragraph (version A):
Deployments should take care that the length of the PSK identity
is sufficient to avoid obvious collisions.
Paragraph (version B):
Deployments should take care that the length of the PSK identity
is sufficient to avoid collisions.
Draft: draft-ietf-tls-external-psk-guidance

Commentary: Since " C " , from its perspective , completes the handshake with " A " ( without mistaking it for some other endpoint or something ) , I removed " ostensibly " from the description of the completion of the handshake .
Paragraph (version A):
The attacker redirects the "Finished" message to "C".  "C" has
completed the handshake, ostensibly with "A".
Paragraph (version B):
The attacker redirects the "Finished" message to "C".  "C" has
completed the handshake with "A".
Draft: draft-ietf-tls-external-psk-guidance

Commentary: The Selfie paper points out that if each party uses the SNI extension and terminates a connection on mismatch , rerouting attacks like Selfie are n't possible . I this note to the explanation of such attacks .
Paragraph (version A):
In addition to these, a malicious non-member can reroute handshakes
between honest group members to connect them in unintended ways, as
detailed below.
Draft: draft-ietf-tls-external-psk-guidance

Commentary: Addressing some of the comments from
Paragraph (version A):
The guidance provided in this document is applicable across TLS
RFC8446, DTLS I-D.ietf-tls-dtls13, and Constrained TLS I-D.rescorla-
tls-ctls.
Paragraph (version B):
The guidance provided in this document is applicable across TLS
RFC8446, DTLS I-D.ietf-tls-dtls13, and Constrained TLS I-D.ietf-tls-
ctls.
Paragraph (version A):
In contrast, if a low entropy PSK is used, then PSK-only key
establishment modes are subject to passive exhaustive search passive
attacks which will reveal the traffic keys.  PSK-DH modes are subject
to active attacks in which the attacker impersonates one side.  The
exhaustive search phase of these attacks can be mounted offline if
the attacker captures a single handshake using the PSK, but those
attacks will not lead to compromise of the traffic keys for that
connection because those also depend on the Diffie-Hellman (DH)
exchange.  Low entropy keys are only secure against active attack if
a PAKE is used with TLS.
Paragraph (version B):
In contrast, if a low entropy PSK is used, then PSK-only key
establishment modes are subject to passive exhaustive search passive
attacks which will reveal the traffic keys.  PSK-DH modes are subject
to active attacks in which the attacker impersonates one side.  The
exhaustive search phase of these attacks can be mounted offline if
the attacker captures a single handshake using the PSK, but those
attacks will not lead to compromise of the traffic keys for that
connection because those also depend on the Diffie-Hellman (DH)
exchange.  Low entropy keys are only secure against active attack if
a PAKE is used with TLS.  The Crypto Forum Research Group (CFRG) is
currently working on specifying a standard PAKE (see I-D.irtf-cfrg-
cpace and I-D.krawczyk-cfrg-opaque).
Paragraph (version A):
PSK provisioning systems are often constrained in application-
specific ways.  For example, although one goal of provisioning is to
ensure that each pair of nodes has a unique key pair, some systems do
not want to distribute pair-wise shared keys to achieve this.  As
another example, some systems require the provisioning process to
embed application-specific information in either PSKs or their
identities.  Identities may sometimes need to be routable, as is
currently under discussion for EAP-TLS-PSK.
Paragraph (version B):
PSK provisioning systems are often constrained in application-
specific ways.  For example, although one goal of provisioning is to
ensure that each pair of nodes has a unique key pair, some systems do
not want to distribute pair-wise shared keys to achieve this.  As
another example, some systems require the provisioning process to
embed application-specific information in either PSKs or their
identities.  Identities may sometimes need to be routable, as is
currently under discussion for EAP-TLS-PSK I-D.mattsson-emu-eap-tls-
psk.
Draft: draft-dt-tls-external-psk-guidance

Commentary: This builds on . 
 Summary : use a high - entropy PSK with DH , otherwise , with a low - entropy PSK , use a PAKE . Reference appendix with security properties from
Paragraph (version A):
Each PSK MUST be derived from at least 128 of entropy and MUST be
at least 128-bits long unless the TLS handshake is being used with
a separate key establishment mechanism such as a Diffie-Hellman
exchange.  This recommendation protects against passive attacks
using exhaustive search of the PSK.
Paragraph (version B):
Each PSK SHOULD be derived from at least 128 bits of entropy, MUST
be at least 128 bits long, and SHOULD be combined with a DH
exchange for forward secrecy.  Low entropy PSKs, i.e., those
derived from less than 128 bits of entropy, MUST be combined with
a Password Authenticated Key Exchange (PAKE) mechanism.
Draft: draft-dt-tls-external-psk-guidance

Commentary: Discuss the different variants : entropy PSK+DH entropy PSK - only PSK with strong ( balanced ) PAKE ... and their security properties . For encodings , mention RFC1751 and  's draft . 
 Proposed text : If a high entropy PSK is used , then PSK - only key establishment modes are secure against both active and passive attack , but will not enjoy forward security . Forward security may be achieved by using a PSK - DH mode . If a low entropy PSK is used , then PSK - only key establishment modes are subject to passive exhaustive search passive attacks which will reveal the traffic keys . PSK - DH modes are subject to active attacks in which the attacker impersonates one side . The exhaustive search phase of these attacks can be mounted offline if the attacker captures a single handshake using the PSK , but those attacks will not lead to compromise of the traffic keys for that connection because those also depend on the DH exhange . Low entropy keys are only secure against active attack if a PAKE is used with TLS .
Paragraph (version A):
Each PSK MUST be derived from at least 128 of entropy and MUST be
at least 128-bits long unless the TLS handshake is being used with
a separate key establishment mechanism such as a Diffie-Hellman
exchange.  This recommendation protects against passive attacks
using exhaustive search of the PSK.
Paragraph (version B):
Entropy properties of external PSKs may also affect TLS security
properties.  In particular, if a high entropy PSK is used, then PSK-
only key establishment modes are secure against both active and
passive attack.  However, they lack forward security.  Forward
security may be achieved by using a PSK-DH mode.
Paragraph (version B):
In contrast, if a low entropy PSK is used, then PSK-only key
establishment modes are subject to passive exhaustive search passive
attacks which will reveal the traffic keys.  PSK-DH modes are subject
to active attacks in which the attacker impersonates one side.  The
exhaustive search phase of these attacks can be mounted offline if
the attacker captures a single handshake using the PSK, but those
attacks will not lead to compromise of the traffic keys for that
connection because those also depend on the Diffie-Hellman (DH)
exchange.  Low entropy keys are only secure against active attack if
a PAKE is used with TLS.
Paragraph (version B):
Each PSK SHOULD be derived from at least 128 bits of entropy, MUST
be at least 128 bits long, and SHOULD be combined with a DH
exchange for forward secrecy.  Low entropy PSKs, i.e., those
derived from less than 128 bits of entropy, MUST be combined with
a Password Authenticated Key Exchange (PAKE) mechanism.
Draft: draft-group-tls-external-psk-guidance

Commentary: Notes : Certificateless server - to - server communication is definitively used for OTT communications e.g.
Paragraph (version B):
The guidance provided in this document is applicable across TLS
RFC8446, DTLS I-D.ietf-tls-dtls13, and Constrained TLS I-D.rescorla-
tls-ctls.
Paragraph (version A):
Internet of Things (IoT) and devices with limited computational
capabilities.  RFC7925 defines TLS and DTLS profiles for resource-
constrained devices and suggests the use of PSK ciphersuites for
compliant devices.
Paragraph (version B):
Certificateless server-to-server communication.  Machine-to-
machine communication may use externally provisioned PSKs,
primarily for the purposes of establishing TLS connections without
requiring the overhead of provisioning and managing PKI
certificates.
Paragraph (version B):
Internet of Things (IoT) and devices with limited computational
capabilities.  RFC7925 defines TLS and DTLS profiles for resource-
constrained devices and suggests the use of PSK ciphersuites for
compliant devices.  The Open Mobile Alliance Lightweight Machine
to Machine Technical Specification LwM2M states that LwM2M servers
MUST support the PSK mode of DTLS.
Paragraph (version B):
Where secrets are baked into hardware at manufacturing time, the
secrets may be printed on labels or included in a Bill of
Materials for ease of scanning or import into a server.
Draft: draft-group-tls-external-psk-guidance

Commentary: Thanks !
Paragraph (version A):
gnuTLS: Applications configure PSK values, either as raw byte
strings or hexadecimal strings, and identities as "usernames".
The PSK size is not validated.
Paragraph (version B):
gnuTLS: Applications configure PSK values, either as raw byte
strings or hexadecimal strings.  The PSK size is not validated.
Paragraph (version B):
Section 5.1 of RFC4279 mandates that the PSK identity should be first
converted to a character string and then encoded to octets using UTF-
8.  This was done to avoid interoperability problems (especially when
the identity is configured by human users).  On the other hand,
RFC7925 advises implementations against assuming any structured
format for PSK identities and recommends byte-by-byte comparison for
any operations.  TLS version 1.3 RFc8446 follows the same practice of
specifying the psk identity as a sequence of opaque bytes (shown as
opaque identity<1..2^16-1>).
Paragraph (version B):
Implementations such as OpenSSL and mbedTLS nonetheless treat
psk_identities as character strings and use string operators such
as strcmp on the psk identity.
Paragraph (version B):
Implementations also assign default identities to PSKs (for
example, the string 'Client_identity') if none are configured.
Paragraph (version B):
gnuTLS treats psk identities as usernames.
Paragraph (version B):
OpenSSL TLS 1.3 servers accept connections from clients that have
a valid PSK even if the identity provided by the client is
incorrect.
Draft: draft-group-tls-external-psk-guidance

Commentary: First cut at . cc 
 Thanks a lot . This looks good to start with . I think we should also discuss what kind of matching is done on the PSK identity . For example , RFC 7925 says : " For use with this profile , the PSK identities SHOULD NOT assume a structured format ( such as domain names , distinguished names , or IP addresses ) , and a byte - by - byte comparison operation MUST be used by the server for any operation related to the PSK identity . " Similarly , RFC 4279 in Section 5.1 describes the UTF-8 encoding of identities to improve interoperability for those cases where the identity is configured by a human using some management interface . If in TLS 1.3 , the identity is only used as a hint for looking up the correct PSK in the database , then this would be a significant departure from what was the norm previously . Highlighting this in our document would make sense . The current text also says ' These callbacks must provide the PSK identity ( as a character string ) ' . But the openssl sserver and sclient seem to work without providing PSK identities and use the default character string ' Clientidentity ' as the pskidentity . 
 Merging and moving ^^ to an issue ! 
 Applications configure callbacks that are invoked to select PSKs . These callbacks must provide the PSK identity ( ) and key ( char * ` ) .  also treats PSKs as   arrays and character strings . ... from Applications specify a " username " ( as the PSK identity ) and a raw PSK . Callback style ( with identical key and identity types ) similar to OpenSSL . There is no minimum length enforced for the PSK . 
 Fixed in .
Paragraph (version B):
Most major TLS implementations support external PSKs.  And all have a
common interface that applications may use when supplying them for
individual connections.  Details about existing stacks at the time of
writing is below.
Paragraph (version B):
OpenSSL and BoringSSL: Applications specify support for external
PSKs via distinct ciphersuites.  They also then configure
callbacks that are invoked for PSK selection during the handshake.
These callbacks must provide the PSK identity (as a character
string) and key (as a byte string).  They are typically invoked
with a PSK hint, i.e., the hint provided by the server as per
RFC4279.  The PSK length is validated to be between [1, 256] bytes
upon selection.
Paragraph (version B):
mbedTLS: Client applications configure PSKs before creating a
connection by providing the PSK identity and value inline.
Servers must implement callbacks similar to that of OpenSSL.  PSK
lengths are validate to be between [1, 16] bytes.
Paragraph (version B):
gnuTLS: Applications configure PSK values, either as raw byte
strings or hexadecimal strings, and identities as "usernames".
The PSK size is not validated.
Paragraph (version B):
wolfSSL: Applications configure PSKs with callbacks similar to
OpenSSL.