jiebi/TextFlow huggingface dataset:
Original text:
versions of TLS will increase the number of PSKs derived from an external PSK.  A unique and imported PSK (IPSK) with base key 'ipskx' bound to this identity is then computed as follows:

Reviewer comments:
To make external psk importers more featureful it makes sense to take advantage of the HKDF already in use. By providing a field for extra context we can avoid protocol layering attacks. For example this change allows us to securely bind one TLS session to another, providing layered context.
See: URL
This was addressed with the slot via and . Closing!
Thanks! This is much more understandable than the previous PR. :-)LGTM with the suggested name change!

Revised text:
versions of TLS will increase the number of PSKs derived from an external PSK. <ins> ImportedIdentity.context MUST include the context used to derive the EPSK, if any exists.  If the EPSK is a key derived from some other protocol or sequence of protocols, ImportedIdentity.context MUST include a channel binding for the deriving protocols RFC5056.  If any secrets are agreed in earlier protocols they SHOULD be included in ImportedIdentity.context CCB. </ins> A unique and imported PSK (IPSK) with base key 'ipskx' bound to this identity is then computed as follows:
Original text:
Base Key: The secret value of an EPSK. <del> External Identity: The identity of an EPSK. </del>  Target protocol: The protocol for which a PSK is imported for use. Imported PSK (IPSK): A PSK derived from an EPSK, external identity, optional context string, and target protocol and KDF. <del> Imported Identity: The identity of an Imported PSK as sent on the wire. </del>  4.

Reviewer comments:
This isn't perfect either, but it concentrates on the functional side, namely that we use a sequence of bytes to identify PSKs.

Revised text:
Base Key: The secret value of an EPSK.  <ins> External Identity: A sequence of bytes used to identify an EPSK. </ins> Target protocol: The protocol for which a PSK is imported for use. 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. </ins> 4.
Original text:
PSKs change the PSK binder key derivation label.  In particular, the standard TLS 1.3 PSK binder key computation is defined as follows: <del> Imported PSKs replace the string "ext binder" with "imp binder" when deriving "binder_key".  This means the binder key is computed as follows: </del>  This new label ensures a client and server will negotiate use of an external PSK if and only if (a) both endpoints import the PSK or (b)

Reviewer comments:
It's a bit confusing to use the term "replace" when discussing the string used for derivation. The text only references one of the strings used for derivation where the diagram references two.

Revised text:
PSKs change the PSK binder key derivation label.  In particular, the standard TLS 1.3 PSK binder key computation is defined as follows:  <ins> Imported PSKs use the string "imp binder" rather than "ext binder" or "res binder" when deriving "binder_key".  This means the binder key is computed as follows: </ins> This new label ensures a client and server will negotiate use of an external PSK if and only if (a) both endpoints import the PSK or (b)
Original text:
silently disable the new feature.  By preventing a class of such interoperability problems, GREASE reduces the need for this kind of fallback. 

Reviewer comments:
Adding security considerations for fingerprinting.
This change is to address
NAME if you fix this nit up then NAME can merge and we can WGLC this draft.
A possible privacy consideration for Grease Implementations that do not select grease values at random my open up the opportunity for the fingerprinting of implementations and may impact the privacy of users.
Ah yes, good point. That should be pointed out explicitly. Will put together a PR after Thanksgiving (and after is merged since it contains a build fix and I'm not sure how PRs depending on pieces of other PRs works :-) ).
NAME NAME NAME unless there are any objections once we get this issue squared away I'll go ahead and issue a WGLC. It's been marinating long enough.
Should be fixed by .

Revised text:
silently disable the new feature.  By preventing a class of such interoperability problems, GREASE reduces the need for this kind of fallback. <ins> If an implementation does not select GREASE values at random it is possible it will allow for fingerprinting of the implementation or perhaps even of individual users.  This can result in a negative impact to a user's privacy. </ins>
Original text:
applicable registries in TLS. The following values are reserved as GREASE values for cipher suites <del> and ALPN identifiers: </del>  {TBD} {0x0A,0x0A} {TBD} {0x1A,0x1A}

Reviewer comments:
The date is wrong and ALPN is missing a citation: Error: Cannot handle a with year different than this year, and no month. Using today's date. Warning: no in targets
(Editorial, I hope. Going ahead and merging this for -02.)

Revised text:
applicable registries in TLS. The following values are reserved as GREASE values for cipher suites  <ins> and ALPN RFC7301 identifiers: </ins> {TBD} {0x0A,0x0A} {TBD} {0x1A,0x1A}
Original text:
In this document, we use the term "(D)TLS" to refer to registries that apply to both TLS and DTLS. <del> Add "TLS" to registries' names for consistency with other TLS- related registries. </del>  Change the IANA registry policy RFC5226 for the TLS ExtensionType Values, TLS Cipher Suite, and TLS ClientCertificateType Identifiers registries.  These changes register a small part of these code spaces for experimentation and private use. <del> Add the designated expert intructions as a note to the TLS ExtensionType Values, TLS Cipher Suite, and TLS ClientCertificateType Identifiers registries to inform users of the registry. </del>  Add notes to indicate whether an extension, certain values of an extension, or an entire registry is only applicable pre-(D)TLS Add missing entry to the TLS Alert Registry for the no_application_protocol alert defined in  This document proposes no changes to the registration policies for TLS Alert I-D.ietf-tls-tls13, TLS ContentType I-D.ietf-tls-tls13, TLS HandshakeType, I-D.ietf-tls-tls13 and TLS Certificate Status Types

Reviewer comments:
Need to update summary to, at a minimum, reflect that the following is now in the draft: Added "Recommended" column to TLS ExtensionType Values, TLS Cipher Suite, and TLS Exporters registries to clearly indicate which values are specified in IETF Standards Track documents.

Revised text:
In this document, we use the term "(D)TLS" to refer to registries that apply to both TLS and DTLS.  <ins> Add "TLS" to registries' names for consistency amongst TLS-related registries. </ins> Change the IANA registry policy RFC5226 for the TLS ExtensionType Values, TLS Cipher Suite, and TLS ClientCertificateType Identifiers registries.  These changes register a small part of these code spaces for experimentation and private use.  <ins> Add designated expert intructions as notes in the TLS ExtensionType Values, TLS Cipher Suite, TLS ClientCertificateType Identifiers, and TLS Exporter Label registries to inform users about what to expect from the designated expert. </ins> Add notes to indicate whether an extension, certain values of an extension, or an entire registry is only applicable pre-(D)TLS Add missing entry to the TLS Alert Registry for the no_application_protocol alert defined in <ins> Added "Recommended" column to TLS ExtensionType Values, TLS Cipher Suite, and TLS Exporters Label registries.  Initial values marked "Yes" are specified in IETF Standards Track documents; all others are marked "No".  This new column is intened to alter the incorrect perception that getting a code point somehow legitimizes the extesion, cipher suite/algorithm, or exporter. </ins> This document proposes no changes to the registration policies for TLS Alert I-D.ietf-tls-tls13, TLS ContentType I-D.ietf-tls-tls13, TLS HandshakeType, I-D.ietf-tls-tls13 and TLS Certificate Status Types
Original text:
Identifiers registries.  These changes register a small part of these code spaces for experimentation and private use. <del> Add designated expert intructions as notes in the TLS </del>  ExtensionType Values, TLS Cipher Suite, TLS ClientCertificateType Identifiers, and TLS Exporter Label registries to inform users about what to expect from the designated expert. Added "Recommended" column to TLS ExtensionType Values, TLS Cipher Suite, and TLS Exporters Label registries.  Initial values marked "Yes" are specified in IETF Standards Track documents; all others <del> are marked "No".  This new column is intened to alter the </del>  incorrect perception that getting a code point somehow legitimizes <del> the extesion, cipher suite/algorithm, or exporter. </del>  This document proposes no changes to the registration policies for TLS Alert I-D.ietf-tls-tls13, TLS ContentType I-D.ietf-tls-tls13, TLS cryptographic standpoint. Note(3): The designated expert RFC5226 only ensures that the <del> specification is publically available. </del>  7. Add the following: Note: The designated expert RFC5226 only ensures that the <del> specification is publically available. </del>  8. document RFC5226 is required to register an extension with the value "Yes".  11. IANA is to add the following entry to the TLS Alert Registry (the

Reviewer comments:
Added the guidelines from RFC 5705
Need to add designated expert instructions for exporters like we did for ExtensionType, Cipher Suite, and ClientCertificateType Identifiers registries.
Also addressed by .

Revised text:
Identifiers registries.  These changes register a small part of these code spaces for experimentation and private use.  <ins> Add designated expert instructions as notes in the TLS </ins> ExtensionType Values, TLS Cipher Suite, TLS ClientCertificateType Identifiers, and TLS Exporter Label registries to inform users about what to expect from the designated expert. Added "Recommended" column to TLS ExtensionType Values, TLS Cipher Suite, and TLS Exporters Label registries.  Initial values marked "Yes" are specified in IETF Standards Track documents; all others  <ins> are marked "No".  This new column is intended to alter the </ins> incorrect perception that getting a code point somehow legitimizes  <ins> the extension, cipher suite/algorithm, or exporter. </ins> This document proposes no changes to the registration policies for TLS Alert I-D.ietf-tls-tls13, TLS ContentType I-D.ietf-tls-tls13, TLS cryptographic standpoint. Note(3): The designated expert RFC5226 only ensures that the  <ins> specification is publicly available. </ins> 7. Add the following: Note: The designated expert RFC5226 only ensures that the  <ins> specification is publicly available. </ins> 8. document RFC5226 is required to register an extension with the value "Yes". <ins> IANA is also to add the following note: </ins> 11. IANA is to add the following entry to the TLS Alert Registry (the
Original text:
promotes those 4 cipher suites to standards track (see TO-DO insert reference).  The cipher suites that follow are standards track ephemeral pre- shared key cipher suites which are available in TLS 1.2.  RFC6655 is inconsistent with respect to the ordering of components within PSK

Reviewer comments:
Adding instructions for the RFC editor to delete the sentence that notes the algorithms defined in RFC 5289 as these algorithms will be standards track at or before the time this draft gets to the RFC editor.

Revised text:
promotes those 4 cipher suites to standards track (see TO-DO insert reference). <ins> RFC EDITOR: Please delete the sentence beginning with "The notable exception ..." after RFC 5289 has been promoted to Proposed Standard. </ins> The cipher suites that follow are standards track ephemeral pre- shared key cipher suites which are available in TLS 1.2.  RFC6655 is inconsistent with respect to the ordering of components within PSK
Original text:
Add a "Recommended" column to the cipher suite registry.  The cipher suites that follow in the two tables are marked as "Yes". <del> All other cipher suites are marked as "No". </del>  The cipher suites that follow are standards track server- authenticated (and optionally client-authenticated) cipher suites

Reviewer comments:
Addresses .
Also addresses .
LGTM
We need to update the registry's reference to point to this document if we require new CS definitions to indicate whether the Recommended column is Yes or No (see ).
The cipher suite "recommended" column needs to include something along the line of the following: Future cipher suites MUST define the value of the Recommended column. A Standards Track document [RFC5226] is required to register a cipher suite with the value “Yes”.

Revised text:
Add a "Recommended" column to the cipher suite registry.  The cipher suites that follow in the two tables are marked as "Yes".  <ins> All other cipher suites are marked as "No".  Future cipher suites MUST define the value of the Recommended column.  A Standards Track document RFC5226 is required to register a cipher suite with the value "Yes". Update the reference for this registry to also point to this document. </ins> The cipher suites that follow are standards track server- authenticated (and optionally client-authenticated) cipher suites
Original text:
TLS HashAlgorithm RFC5246 and TLS SignatureAlgorithm registries to also refer to this document.  16. Specification Required RFC5226 registry requests are registered after

Reviewer comments:
This text is taken from TLS1.3. The point is to reserve the remaining values as a really big hint to "not look here, go look over there".

Revised text:
TLS HashAlgorithm RFC5246 and TLS SignatureAlgorithm registries to also refer to this document. <ins> IANA [SHALL update/has updated] the TLS HashAlgorithm Registry to list values 7-223 as "Reserved" and the TLS SignatureAlgorithm registry to list values 4-223 as "Reserved". </ins> 16. Specification Required RFC5226 registry requests are registered after
Original text:
groups marked "No" range from "good" to "bad" from a cryptographic standpoint.  Despite the following behavior being crazy, experience has shown that some customers use the IANA registry as checklist against which to measure an implemention's completeness and some implementers blindly

Reviewer comments:
This adds the designated expert note to supported groups to address issue 32
NAME Just setting this up to auto address .
I believe specification required still involves a designated expert review.
Yes expert review is implied by specification required, but you're right we should also include the same note about the experts just making sure it's publicly available.

Revised text:
groups marked "No" range from "good" to "bad" from a cryptographic standpoint. <ins> The designated expert RFC8126 only ensures that the specification is publicly available. </ins> Despite the following behavior being crazy, experience has shown that some customers use the IANA registry as checklist against which to measure an implemention's completeness and some implementers blindly
Original text:
<del> D/TLS IANA Registry Updates </del>  draft-ietf-tls-iana-registry-updates-latest Abstract <del> This document describes a number of changes to D/TLS IANA registries </del>  that range from adding notes to the registry all the way to changing the registration policy.  These changes were mostly motivated by WG review of the (D)TLS-related registries undertaken as part of the

Reviewer comments:
This changes the title to remove the D/TLS.
It seems that we use D/TLS and (D)TLS interchangeably throughout the document. It should use one of these and the title should probably be something like "IANA Registry Updates for TLS and DTLS"

Revised text:
 <ins> IANA Registry Updates for TLS and DTLS </ins> draft-ietf-tls-iana-registry-updates-latest Abstract  <ins> This document describes a number of changes to (D)TLS IANA registries </ins> that range from adding notes to the registry all the way to changing the registration policy.  These changes were mostly motivated by WG review of the (D)TLS-related registries undertaken as part of the
Original text:
values 7-223 as "Reserved" and the TLS SignatureAlgorithm registry to list values 4-223 as "Reserved".  16. Specification Required RFC8126 registry requests are registered after

Reviewer comments:
Addresses .
MT suggested that we add the same warnings we have for cipher suites and named groups to all crypto-related registries. The two remaining crypt-related registries are HashAlgorithm and SignatureAlgorithm and both are being orphaned. Despite the fact they are being orphaned we should still add similar text. NAME Are there any others that should include the warning?
merged

Revised text:
values 7-223 as "Reserved" and the TLS SignatureAlgorithm registry to list values 4-223 as "Reserved". <ins> Despite the fact that the HashAlgorithm and SignarureAlgorithm registries are orphaned, it is still import to warn implementers of pre-TLS1.3 implmentations about the dangers of blinding implementing cryptographic algorithms.  Therefore, IANA [SHALL add/has added] the following warning to the HashAlgorithm and SignatureAlgorithm: WARNING: Cryptographic algorithms and parameters will be broken or weakened over time.  Blindly implementing cipher suites listed here is not advised.  Implementers and users need to check that the cryptographic algorithms listed continue to provide the expected level of security. </ins> 16. Specification Required RFC8126 registry requests are registered after
Original text:
17. <del> The authors are fairly certain that there are no security considerations for this document. </del>  18.

Reviewer comments:
Possibly addresses .
We probably need to say something more in the security considerations. What springs to mind first is the implications of relaxing to specification required for cipher suites and named groups. There must be others.

Revised text:
17.  <ins> The change to Specification Required from IETF Review lowers the amount of review provided by the WG for cipher suites and supported groups.  This change reflects reality in that the WG essentially provided no cryptographic review of the cipher suites or supported groups.  This was espcecially true of national cipher suites. </ins> 18.
Original text:
amount of review provided by the WG for cipher suites and supported groups.  This change reflects reality in that the WG essentially provided no cryptographic review of the cipher suites or supported <del> groups.  This was espcecially true of national cipher suites. </del>  18.

Reviewer comments:
This fixes a typo in the security considerations section and adds some additional text.
We probably need to say something more in the security considerations. What springs to mind first is the implications of relaxing to specification required for cipher suites and named groups. There must be others.

Revised text:
amount of review provided by the WG for cipher suites and supported groups.  This change reflects reality in that the WG essentially provided no cryptographic review of the cipher suites or supported  <ins> groups.  This was especially true of national cipher suites. Recommended algorithms regarded as secure for general use at the time of registration, however, cryptographic algorithms and parameters will be broken or weakened over time.  It is possible that the recommended status in the registry lags behind the most recent advances in cryptanalysis.  Implementers and users need to check that the cryptographic algorithms listed continue to provide the expected level of security. </ins> 18.
Original text:
the cryptographic algorithms listed continue to provide the expected level of security.  19. This document is entirely about changes to TLS-related IANA

Reviewer comments:
Addresses and .
Seems like we should add a security consideration about the expert and how much review they're going to do.
We probably need to say something more in the security considerations. What springs to mind first is the implications of relaxing to specification required for cipher suites and named groups. There must be others.

Revised text:
the cryptographic algorithms listed continue to provide the expected level of security. <ins> Designated experts ensure the specification is publicly available. They may provide more in depth reviews.  Their review should not be taken as an endorsement of the cipher suite, extension, supported group, etc. </ins> 19. This document is entirely about changes to TLS-related IANA
Original text:
marked "No" range from "good" to "bad" from a cryptographic standpoint.  The designated expert RFC8126 only ensures that the specification is publicly available.

Reviewer comments:
Addresses and .
CCM_8 has a significantly truncated authentication tag that represents a security trade-off that may not be appropriate for general environment.
I think not.
LGTM. Can you send me a PR for the TLS 1.3 spec.

Revised text:
marked "No" range from "good" to "bad" from a cryptographic standpoint. <ins> CCM_8 cipher suites are not marked as Recommended.  These cipher suites have a significantly truncated authentication tag that represents a security trade-off that may not be appropriate for general environments. </ins> The designated expert RFC8126 only ensures that the specification is publicly available.
Original text:
nomenclature for the other Handshake type names and to match with existing implementations. <del> Rename the SessionTicket TLS to session_ticket to match the nomenclature for the other extensions' names. </del>  Add missing entry to the TLS Alert Registry for the no_application_protocol alert defined in RFC7301. Note(1): Although TLS 1.3 uses the same cipher suite space as previous versions of TLS, TLS 1.3 cipher suites are defined <del> differently, only specifying the symmetric ciphers, and cannot it be used for TLS 1.2.  Similarly, TLS 1.2 and lower cipher suites </del>  cannot be used with TLS 1.3. Note(2): Cipher suites marked as "Yes" are those allocated via Change the registry policy to: Values in the range 0-223 are assigned via Specification Required <del> RFC5226.  Values 224-255 are are reserved for Private Use. </del>  Add the following:

Reviewer comments:
This PR and
ship it
From the draft: Remove one "are" from "are are reserved".
Remove the "it" from "cannot it" in the text below:
From the Introduction section: As far as I can see the above ought to be:

Revised text:
nomenclature for the other Handshake type names and to match with existing implementations.  <ins> Rename the SessionTicket TLS extension to session_ticket to match the nomenclature for the other extensions' names. </ins> Add missing entry to the TLS Alert Registry for the no_application_protocol alert defined in RFC7301. Note(1): Although TLS 1.3 uses the same cipher suite space as previous versions of TLS, TLS 1.3 cipher suites are defined  <ins> differently, only specifying the symmetric ciphers, and cannot be used for TLS 1.2.  Similarly, TLS 1.2 and lower cipher suites </ins> cannot be used with TLS 1.3. Note(2): Cipher suites marked as "Yes" are those allocated via Change the registry policy to: Values in the range 0-223 are assigned via Specification Required  <ins> RFC5226.  Values 224-255 are reserved for Private Use. </ins> Add the following: