jiebi/TextFlow huggingface dataset:
Original text:
Target KDF: The KDF for which a PSK is imported for use. <del> Imported PSK (IPSK): A PSK derived from an EPSK, external identity, optional context string, and target protocol and KDF. </del>  Imported Identity: A sequence of bytes used to identify an IPSK. 4. <del> A key importer diversifies an input EPSK into one or more PSKs advertised on the wire via a target protocol, KDF identifier, and optional context string.  Additionally, the resulting PSK binder key is modified with a new derivation label to prevent confusion with non-imported PSKs.  This section describes the diversification mechanism and binder key computation change. </del>  4.1. <del> A key importer takes as input an EPSK with external identity "external_identity" and base key "epsk", as defined in terminology, along with an optional context, and transforms it into a set of PSKs and imported identities for use in a connection based on supported (target) protocols and KDFs.  In particular, for each supported target protocol "target_protocol" and KDF "target_kdf", the importer </del>  constructs an ImportedIdentity structure as follows: The list of "target_kdf" values is maintained by IANA as described in

Reviewer comments:
This is mainly editorial, so there should be nothing surprising here. Please let me if that's not the case! It also includes clarifying text per NAME recommendation raised during WGLC. cc NAME NAME
From Rob Sayre: We should note the latter is a requirement from Section 4.2.11 of RFC8446. Let's also fix the typo "import external keys for TLS..."

Revised text:
Target KDF: The KDF for which a PSK is imported for use.  <ins> Imported PSK (IPSK): A PSK derived from an EPSK, External Identity, optional context string, and target protocol and KDF. </ins> Imported Identity: A sequence of bytes used to identify an IPSK. 4.  <ins> This section describes the PSK Importer interface and its underlying diversification mechanism and binder key computation modification. </ins> 4.1.  <ins> The PSK Importer interface takes as input an EPSK with External Identity "external_identity" and base key "epsk", as defined in terminology, along with an optional context, and transforms it into a set of PSKs and imported identities for use in a connection based on target protocols and KDFs.  In particular, for each supported target protocol "target_protocol" and KDF "target_kdf", the importer </ins> constructs an ImportedIdentity structure as follows: The list of "target_kdf" values is maintained by IANA as described in
Original text:
and QUICv1 QUIC use 0x0304.  Note that this means future versions of TLS will increase the number of PSKs derived from an external PSK. <del> An Imported PSK derived from an EPSK with base key 'epsk' bound to this identity is then computed as follows: </del>  <del> L is corresponds to the KDF output length of ImportedIdentity.target_kdf as defined in IANA.  For hash-based KDFs, such as HKDF_SHA256(0x0001), this is the length of the hash function output, i.e., 32 octets.  This is required for the IPSK to be of length suitable for supported ciphersuites. </del>  <del> The identity of 'ipskx' as sent on the wire is ImportedIdentity, </del>  i.e., the serialized content of ImportedIdentity is used as the <del> content of PskIdentity.identity in the PSK extension. </del>  The hash function used for HKDF RFC5869 is that which is associated with the EPSK.  It is not the hash function associated with

Reviewer comments:
This is mainly editorial, so there should be nothing surprising here. Please let me if that's not the case! It also includes clarifying text per NAME recommendation raised during WGLC. cc NAME NAME
From Rob Sayre: We should note the latter is a requirement from Section 4.2.11 of RFC8446. Let's also fix the typo "import external keys for TLS..."

Revised text:
and QUICv1 QUIC use 0x0304.  Note that this means future versions of TLS will increase the number of PSKs derived from an external PSK.  <ins> Given an ImportedIdentity and corresponding EPSK with base key "epsk", an Imported PSK IPSK with base key "ipskx" is computed as follows: </ins>  <ins> L corresponds to the KDF output length of ImportedIdentity.target_kdf as defined in IANA.  For hash-based KDFs, such as HKDF_SHA256(0x0001), this is the length of the hash function output, i.e., 32 octets.  This is required for the IPSK to be of length suitable for supported ciphersuites. </ins>  <ins> The identity of "ipskx" as sent on the wire is ImportedIdentity, </ins> i.e., the serialized content of ImportedIdentity is used as the  <ins> content of PskIdentity.identity in the PSK extension.  The corresponding TLS 1.3 binder key is "ipskx". </ins> The hash function used for HKDF RFC5869 is that which is associated with the EPSK.  It is not the hash function associated with
Original text:
algorithm and PSK.  Thus, an EPSK may be used with the same KDF (and underlying HMAC hash algorithm) as TLS 1.3 with importers.  However, critically, the derived PSK will not be the same since the importer <del> differentiates the PSK via the identity, target protocol, and target KDF.  Thus, PSKs imported for TLS 1.3 are distinct from those used in TLS 1.2, and thereby avoid cross-protocol collisions.  Note that this </del>  does not preclude endpoints from using non-imported PSKs for TLS 1.2. Indeed, this is necessary for incremental deployment. 7. <del> The Key Importer security goals can be roughly stated as follows: </del>  avoid PSK re-use across KDFs while properly authenticating endpoints. When modeled as computational extractors, KDFs assume that input keying material (IKM) is sampled from some "source" probability

Reviewer comments:
This is mainly editorial, so there should be nothing surprising here. Please let me if that's not the case! It also includes clarifying text per NAME recommendation raised during WGLC. cc NAME NAME
From Rob Sayre: We should note the latter is a requirement from Section 4.2.11 of RFC8446. Let's also fix the typo "import external keys for TLS..."

Revised text:
algorithm and PSK.  Thus, an EPSK may be used with the same KDF (and underlying HMAC hash algorithm) as TLS 1.3 with importers.  However, critically, the derived PSK will not be the same since the importer  <ins> differentiates the PSK via the identity and target KDF and protocol. Thus, PSKs imported for TLS 1.3 are distinct from those used in TLS 1.2, and thereby avoid cross-protocol collisions.  Note that this </ins> does not preclude endpoints from using non-imported PSKs for TLS 1.2. Indeed, this is necessary for incremental deployment. 7.  <ins> The PSK Importer security goals can be roughly stated as follows: </ins> avoid PSK re-use across KDFs while properly authenticating endpoints. When modeled as computational extractors, KDFs assume that input keying material (IKM) is sampled from some "source" probability
Original text:
authentication protocols, wherein at least one is uncompromised, jointly authenticates all protocols.  Authenticating with an externally provisioned PSK, therefore, should ideally authenticate <del> both the TLS connection and the external provision process. </del>  Typically, the external provision process produces a PSK and corresponding context from which the PSK was derived and in which it <del> should be used.  We refer to an external PSK without such context as "context free". </del>  Thus, in considering the source-independence and compound <del> authentication requirements, the Key Import API described in this document aims to achieve the following goals: </del>  <del> Externally provisioned PSKs imported into TLS achieve compound authentication of the provision step(s) and connection. </del>  Context-free PSKs only achieve authentication within the context of a single connection. <del> Imported PSKs are used as IKM for two different KDFs. </del>  Imported PSKs do not collide with existing PSKs used for TLS 1.2 and below.

Reviewer comments:
This is mainly editorial, so there should be nothing surprising here. Please let me if that's not the case! It also includes clarifying text per NAME recommendation raised during WGLC. cc NAME NAME
From Rob Sayre: We should note the latter is a requirement from Section 4.2.11 of RFC8446. Let's also fix the typo "import external keys for TLS..."

Revised text:
authentication protocols, wherein at least one is uncompromised, jointly authenticates all protocols.  Authenticating with an externally provisioned PSK, therefore, should ideally authenticate  <ins> both the TLS connection and the external provisioning process. </ins> Typically, the external provision process produces a PSK and corresponding context from which the PSK was derived and in which it  <ins> should be used.  If available, this is used as the ImportedIdentity.context value.  We refer to an external PSK without such context as "context-free". </ins> Thus, in considering the source-independence and compound  <ins> authentication requirements, the PSK Import interface described in this document aims to achieve the following goals: </ins>  <ins> Externally provisioned PSKs imported into a TLS connection achieve compound authentication of the provisioning process and connection. </ins> Context-free PSKs only achieve authentication within the context of a single connection.  <ins> Imported PSKs are not used as IKM for two different KDFs. </ins> Imported PSKs do not collide with existing PSKs used for TLS 1.2 and below.
Original text:
track documents need to be marked as recommended. If an item is marked as not recommended it does not necessarily mean <del> that it is flawed, rather, it indicates that either the item has not </del>  been through the IETF consensus process, has limited applicability, or is intended only for specific use cases.

Reviewer comments:
NAME PTAL
LGTM - ‘twas just a comment anyway. W I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf

Revised text:
track documents need to be marked as recommended. If an item is marked as not recommended it does not necessarily mean  <ins> that it is flawed; rather, it indicates that either the item has not </ins> been through the IETF consensus process, has limited applicability, or is intended only for specific use cases.
Original text:
Update the "Reference" to also refer to this document. <del> Add the following notes: Experts are to verify that there is in fact a publicly available standard.  An Internet Draft that is posted and never published or a standard in another standards body, industry consortium, university site, etc. suffices. As specified in RFC8126, assignments made in the Private Use space are not generally useful for broad interoperability.  It is the responsibility of those making use of the Private Use range to ensure that no conflicts occur (within the intended scope of use). For widespread experiments, temporary reservations are available. </del> See expert-pool for additional information about the designated expert pool.

Reviewer comments:
NAME PTAL
LGTM - ‘twas just a comment anyway. W I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf

Revised text:
Update the "Reference" to also refer to this document.  See expert-pool for additional information about the designated expert pool.
Original text:
extension with the value "Yes", a Standards Track document RFC8126 is REQUIRED.  IESG Approval is REQUIRED for a Yes->No transition.  The following is from I-D.ietf-tls-tls13 and is included here to ensure alignment between these specifications.

Reviewer comments:
NAME PTAL
LGTM - ‘twas just a comment anyway. W I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf

Revised text:
extension with the value "Yes", a Standards Track document RFC8126 is REQUIRED.  IESG Approval is REQUIRED for a Yes->No transition. <ins> IANA [SHALL update/has added] the following notes: Experts are to verify that there is in fact a publicly available specification.  An Internet Draft that is posted and never published or a specification in another standards body, industry consortium, university site, etc. suffices. As specified in RFC8126, assignments made in the Private Use space are not generally useful for broad interoperability.  It is the responsibility of those making use of the Private Use range to ensure that no conflicts occur (within the intended scope of use). For widespread experiments, temporary reservations are available. Extensions marked as "Yes" are those allocated via Standards Track RFCs.  Extensions marked as "No" are not. If an item is not marked as recommended it does not necessarily mean that it is flawed; rather, it indicates that either the item has not been through the IETF consensus process, has limited applicability, or is intended only for specific use cases. </ins> The following is from I-D.ietf-tls-tls13 and is included here to ensure alignment between these specifications.
Original text:
represents a security trade-off that may not be appropriate for general environments.  IANA [SHALL add/has added] the following notes for additional information:

Reviewer comments:
NAME PTAL
LGTM - ‘twas just a comment anyway. W I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf

Revised text:
represents a security trade-off that may not be appropriate for general environments. <ins> If an item is not marked as recommended it does not necessarily mean that it is flawed; rather, it indicates that either the item has not been through the IETF consensus process, has limited applicability, or is intended only for specific use cases. </ins> IANA [SHALL add/has added] the following notes for additional information:
Original text:
groups marked "No" range from "good" to "bad" from a cryptographic standpoint.  The designated expert RFC8126 only ensures that the specification is publicly available.  An Internet Draft that is posted and never published or a standard in another standards body, industry

Reviewer comments:
NAME PTAL
LGTM - ‘twas just a comment anyway. W I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf

Revised text:
groups marked "No" range from "good" to "bad" from a cryptographic standpoint. <ins> If an item is not marked as recommended it does not necessarily mean that it is flawed; rather, it indicates that either the item has not been through the IETF consensus process, has limited applicability, or is intended only for specific use cases. </ins> The designated expert RFC8126 only ensures that the specification is publicly available.  An Internet Draft that is posted and never published or a standard in another standards body, industry
Original text:
allocated via Standards Track RFCs.  ClientCertificateTypes marked as "No" are not.  12. To align with TLS implementations and to align the naming

Reviewer comments:
NAME PTAL
LGTM - ‘twas just a comment anyway. W I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf

Revised text:
allocated via Standards Track RFCs.  ClientCertificateTypes marked as "No" are not. <ins> If an item is not marked as recommended it does not necessarily mean that it is flawed; rather, it indicates that either the item has not been through the IETF consensus process, has limited applicability, or is intended only for specific use cases. </ins> 12. To align with TLS implementations and to align the naming
Original text:
Exporters Labels marked as "Yes" are those allocated via Standards Track RFCs.  Exporter Labels marked as "No" are not.  IANA [SHALL update/has updated] the reference for this registry to also refer to this document.

Reviewer comments:
NAME PTAL
LGTM - ‘twas just a comment anyway. W I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf

Revised text:
Exporters Labels marked as "Yes" are those allocated via Standards Track RFCs.  Exporter Labels marked as "No" are not. <ins> If an item is not marked as recommended it does not necessarily mean that it is flawed; rather, it indicates that either the item has not been through the IETF consensus process, has limited applicability, or is intended only for specific use cases. </ins> IANA [SHALL update/has updated] the reference for this registry to also refer to this document.
Original text:
Certificate Types marked as "Yes" are those allocated via Standards Track RFCs.  Certificate Types marked as "No" are not.  IANA [SHALL update/has updated] the reference for this registry to also refer this document.

Reviewer comments:
NAME PTAL
LGTM - ‘twas just a comment anyway. W I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf

Revised text:
Certificate Types marked as "Yes" are those allocated via Standards Track RFCs.  Certificate Types marked as "No" are not. <ins> If an item is not marked as recommended it does not necessarily mean that it is flawed; rather, it indicates that either the item has not been through the IETF consensus process, has limited applicability, or is intended only for specific use cases. </ins> IANA [SHALL update/has updated] the reference for this registry to also refer this document.
Original text:
SignatureAlgorithm registries to also refer to this document. [SHALL update/has updated] the TLS HashAlgorithm Registry to list <del> values 7-223 as "Reserved" and the TLS SignatureAlgorithm registry to list values 4-223 as "Reserved". </del>  Despite the fact that the HashAlgorithm and SignatureAlgorithm registries are orphaned, it is still important to warn implementers

Reviewer comments:
4492bis includes some values we were marking as reserved and that's wrong. We also have 224-255 that we might also mark as reserved. Effectively, this closes these two registries.
NAME PTAL
NAME -- This looks good. I have a quick comment on: I presume this will or won't happen as the result of conversations in the WG? Also, I'll note -- for the (only) -- that only 224-253 are necessary to mark as reserved (or, really, since they were previously okay for private use, I think the term to use is "deprecated"), since 254 and 255 are in the TLS 1.3 "reserved for private use" range of 0xfe00-0xffff
I'm planning to forward the PR to the WG after I heard from you. I'll add in "deprecated" for those other values before sending it along.

Revised text:
SignatureAlgorithm registries to also refer to this document. [SHALL update/has updated] the TLS HashAlgorithm Registry to list  <ins> values 7 and 9-223 as "Reserved" and the TLS SignatureAlgorithm registry to list values 4-6 and 9-223 as "Reserved". </ins> Despite the fact that the HashAlgorithm and SignatureAlgorithm registries are orphaned, it is still important to warn implementers
Original text:
4. Servers MUST NOT include MD5 and SHA-1 in ServerKeyExchange messages. <del> If no other signature algorithms are available (for example, if the client does not send a signature_algorithms extension), the server MUST abort the handshake with a handshake_failure alert or select a different cipher suite. </del>  5. Clients MUST NOT include MD5 and SHA-1 in CertificateVerify messages. If a server receives a CertificateVerify message with MD5 or SHA-1 it <del> MUST abort the connection with handshake_failure or insufficient_security alert. </del>  6.

Reviewer comments:
Addressing this . NAME NAME PTAL
I am really growing to dislike these "here is the alert you must use" constructions. Are they necessary? A lot of this was born out of the deprecate TLS 1/1.1 RFC that spun this I-D off. I believe this is the thread back in mid-2019: URL spt

Revised text:
4. Servers MUST NOT include MD5 and SHA-1 in ServerKeyExchange messages.  <ins> If the client receives a ServerKeyExchange message indicating MD5 or SHA-1, then it MUST abort the connection with an illegal_parameter alert. </ins> 5. Clients MUST NOT include MD5 and SHA-1 in CertificateVerify messages. If a server receives a CertificateVerify message with MD5 or SHA-1 it  <ins> MUST abort the connection with an illegal_parameter alert. </ins> 6.
Original text:
Connection racing: Happy Eyeballs V2 RFC8305 describes techniques for performing connection racing.  The Transport Services <del> Architecture implementation from I-D.ietf-taps-impl also describes how connections may race across interfaces and address families. In cases where clients have early data to send and want to minimize or avoid ticket re-use, unique tickets for each unique connection attempt are useful.  Moreover, as some servers may implement single-use tickets (and even session ticket encryption keys), distinct tickets will be needed to prevent premature ticket </del>  invalidation by racing. Connection priming: In some systems, connections may be primed or

Reviewer comments:
Good catch -- will fix. Good suggestion! We can certainly add this. As the extension is merely a hint to servers when deciding how many tickets to vend, I think this is out of scope for the document. It's intended to be once per session, and we'll add that. Also a good catch. Like other extensions that are not affected by the possibly updated ClientHello, it must not change. We need to specify the server side behavior, too. That seems reasonable to me.
Thanks! Approved pending

Revised text:
Connection racing: Happy Eyeballs V2 RFC8305 describes techniques for performing connection racing.  The Transport Services  <ins> Architecture implementation from TAPS also describes how connections may race across interfaces and address families.  In cases where clients have early data to send and want to minimize or avoid ticket re-use, unique tickets for each unique connection attempt are useful.  Moreover, as some servers may implement single-use tickets (and even session ticket encryption keys), distinct tickets will be needed to prevent premature ticket </ins> invalidation by racing. Connection priming: In some systems, connections may be primed or