jiebi/CodeConvo huggingface dataset:
Change:
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 .

Discussion:
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>
Change:
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.)

Discussion:
applicable registries in TLS. The following values are reserved as GREASE values for cipher suites <del> and ALPN identifiers: </del> <ins> and ALPN RFC7301 identifiers: </ins> {TBD} {0x0A,0x0A} {TBD} {0x1A,0x1A}
Change:
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.

Discussion:
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> <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. <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> <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
Change:
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 .

Discussion:
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> <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 <del> are marked "No".  This new column is intened to alter the </del> <ins> are marked "No".  This new column is intended to alter the </ins> incorrect perception that getting a code point somehow legitimizes <del> the extesion, cipher suite/algorithm, or exporter. </del> <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 <del> specification is publically available. </del> <ins> specification is publicly available. </ins> 7.

Add the following: Note: The designated expert RFC5226 only ensures that the <del> specification is publically available. </del> <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
Change:
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.

Discussion:
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
Change:
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”.

Discussion:
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> <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
Change:
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".

Discussion:
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
Change:
I'm fairly sure that I sent these in already. Was there a regression? The current build has lines that are insanely long. This corrects that (and removes a warning caused by an open bracket).
I thought I fixed it, but I guess I'd missed it. I've got a fairly long rewrite that I hope to land early next that I think also addresses these.
Hoping that this is fixed via , which is pretty big set of editorial changes.

Discussion:
Add the following: <del> Note: The designated expert RFC5226 only ensures that the specification is publicly available. </del> <ins> The designated expert RFC5226 only ensures that the specification is publicly available. </ins> 10.

IANA is to add the following note to the TLS Exporter Label Registry: <ins> RFC5705 defines keying material exporters for TLS in terms of the TLS PRF.  I-D.ietf-tls-tls13 replaced the PRF with HKDF, thus requiring a new construction.  The exporter interface remains the same, however the value is computed different. </ins> IANA is to also to add a "Recommended" column to the TLS Exporter Label registry.  The table that follows has been generated by marking Standards Track RFCs as "Yes" and all others as "No".  Future

IANA is also to add the following note: <ins> The designated expert RFC5226 ensures that the specification is publicly available.  The expert also verifies that the label is a string consisting of printable ASCII characters beginning with "EXPORTER".  IANA MUST also verify that one label is not a prefix of any other label.  For example, labels "key" or "master secretary" are forbidden. </ins> 12. IANA is to add the following entry to the TLS Alert Registry (the

IANA is to add the following to the TLS ExtensionType Values registry: <ins> The following extensions are only applicable to (D)TLS protocol vesions prior to 1.3: trusted_ca_keys, truncated_hmac, ec_point_formats, srp, status_request_v2, encrypt_then_mac, extended_master_secret, session_ticket, and renegotiation_info. These are not applicable to DTLS 1.3. </ins> 15. To make it clear that (D)TLS 1.3 has orphaned certain registries

Add the following to the TLS Compression Method Identifiers registry RFC3749: <del> Note: Value 0 (NULL) is the only value in this registry applicable to (D)TLS protocol version 1.3 or later. </del> <ins> Value 0 (NULL) is the only value in this registry applicable to (D)TLS protocol version 1.3 or later. </ins> Add the following to the TLS HashAlgorithm RFC5246 and TLS SignatureAlgorithm registries RFC5246: <del> Note: The values in this registry are only applicable to (D)TLS protocol versions prior to 1.3. </del> <ins> The values in this registry are only applicable to (D)TLS protocol versions prior to 1.3. </ins> Update the "References" in the TLS Compression Method Identifiers, TLS HashAlgorithm RFC5246 and TLS SignatureAlgorithm registries to
Change:
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.

Discussion:
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
Change:
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"

Discussion:
<del> D/TLS IANA Registry Updates </del> <ins> IANA Registry Updates for TLS and DTLS </ins> draft-ietf-tls-iana-registry-updates-latest Abstract <del> This document describes a number of changes to D/TLS IANA registries </del> <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
Change:
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

Discussion:
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
Change:
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.

Discussion:
17. <del> The authors are fairly certain that there are no security considerations for this document. </del> <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.
Change:
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.

Discussion:
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> <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.
Change:
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.

Discussion:
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
Change:
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.

Discussion:
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.
Change:
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:

Discussion:
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> <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 <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> <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 <del> RFC5226.  Values 224-255 are are reserved for Private Use. </del> <ins> RFC5226.  Values 224-255 are reserved for Private Use. </ins> Add the following:
Change:
Addresses .
Our esteemed Shepherd has pointed out that we need to specify the rules for going from Yes->No. After consulting the list, we settled on "IESG action is REQUIRED for a Yes->No transition."
Closed as part of .

Discussion:
This table has been generated by marking Standards Track RFCs as "Yes" and all others as "No".  Future extensions MUST define the value of the Recommended column.  A Standards Track document <del> RFC8126 is required to register an extension with the value "Yes". </del> <ins> RFC8126 is REQUIRED to register an extension with the value "Yes". IESG action is REQUIRED for a Yes->No transition. </ins> 9.

cipher suites that follow in the two tables are marked as "Yes". All other cipher suites are marked as "No".  Future cipher suites MUST define the value of the Recommended column.  A Standards <del> Track document RFC8126 is required to register a cipher suite with the value "Yes". </del> <ins> Track document RFC8126 is REQUIRED to register a cipher suite with the value "Yes".  IESG action is REQUIRED for a Yes->No transition. </ins> The cipher suites that follow are standards track server- authenticated (and optionally client-authenticated) cipher suites

are marked as "Yes"; these groups apply to TLS 1.3 I-D.ietf-tls-tls13 and previous versions of TLS.  Future supported groups MUST define the value of this column.  A Standards Track document RFC8126 is <del> required to register an entry with the value "Yes". </del> <ins> REQUIRED to register an entry with the value "Yes".  IESG action is REQUIRED for a Yes->No transition. </ins> IANA [SHALL add/has added] the following note:

table that follows has been generated by marking Standards Track RFCs as "Yes" and all others as "No".  Future exporters MUST define the value of this column.  A Standards Track document <del> RFC8126 is required to register an extension with the value "Yes". </del> <ins> RFC8126 is REQUIRED to register an extension with the value "Yes". IESG action is REQUIRED for a Yes->No transition. </ins> To provide additional information for the designated experts, IANA [SHALL add/has added] the following note:

"Yes".  All others are "No".  A Standards Track document RFC8126 is required to register a certificate type with the value "Yes".  Future Certificate Types MUST define the value of this column.  A Standards <del> Track document RFC8126 is required to register an entry with the value "Yes". </del> <ins> Track document RFC8126 is REQUIRED to register an entry with the value "Yes".  IESG action is REQUIRED for a Yes->No transition. </ins> See expert-pool for additional information about the designated expert pool.
Change:
Looks good
I think the TLS Certificate Type section should explicitly list the values for which "specification required" applies (and for which "reserved for private use" continues to apply).

Discussion:
Certificate Types is too strict.  Based on WG consensus, the decision was taken to change registration policy to Specification Required RFC8126 while reserving a small part of the code space for <del> experimental and private use.  Therefore, IANA [SHALL add/has added] a "Recommended" column to the registry.  X.509 and Raw Public Key are "Yes".  All others are "No".  In order to register an extension with the value "Yes", a Standards Track document RFC8126 is REQUIRED. Future Certificate Types MUST define the value of this column.  A Standards Track document RFC8126 is REQUIRED to register an entry with the value "Yes".  IESG Approval is REQUIRED for a Yes->No transition. </del> <ins> experimental and private use.  Therefore, IANA [SHALL change/has changed] the TLS Certificate Types regisry to: Change the registry policy to: Values with the first byte in the range 0-223 (decimal) are assigned via Specification Required RFC8126.  Values with the first byte 224-255 (decimal) are reserved for Private Use RFC8126. Add a "Recommended" column to the registry.  X.509 and Raw Public Key are "Yes".  All others are "No".  In order to register an extension with the value "Yes", a Standards Track document RFC8126 is REQUIRED.  Future Certificate Types MUST define the value of this column.  A Standards Track document RFC8126 is REQUIRED to register an entry with the value "Yes".  IESG Approval is REQUIRED for a Yes->No transition. </ins> See expert-pool for additional information about the designated expert pool.
Change:
An open issue was whether to close the HashAlgorithms and SignatureAlgorithms registries or just reserve the values and point to the new 1.3 schemes. WRT opening a closed registry, IANA told me that opening a closed registry required another RFC or if we put in the IANA considerations section IESG Approval. With that info and the fact that at least one person was like "woah wait I might need to register some algorithms for TLS1.2", I don’t really see the point in closing the registry so I propose that we leave it as is, but that we update the text as noted in the PR to explicit point to the SignatureScheme registry.
I think that reserving them is the right thing for now. TLS 1.2 and earlier will take a while to disappear, so the ability to assign more values if there is a huge surprise seems prudent.
NAME PTAL

Discussion:
RFC5246 and TLS SignatureAlgorithm registries RFC5246: The values in this registry are only applicable to (D)TLS protocol <del> versions prior to 1.3. </del> <ins> versions prior to 1.3.  (D)TLS 1.3 and later versions' values are registered in the TLS SignatureScheme registry. </ins> [SHALL update/has updated] the "Reference" field in the TLS Compression Method Identifiers, TLS HashAlgorithm and TLS
Change:
SHA-1 is spelled everywhere as "SHA-1", it's the only instance of "SHA1" change it so that it is consistent

Discussion:
potential for brute-force attack.  Further, in 2017, researchers from Google and CWI Amsterdam SHA-1-Collision proved SHA-1 collision attacks were practical.  This document updates RFC5246 and RFC7525 in <del> such as way that MD5 and SHA1 MUST NOT be used for digital </del> <ins> such as way that MD5 and SHA-1 MUST NOT be used for digital </ins> signatures.  However, this document does not deprecate SHA-1 in HMAC for record protection.