jiebi/CodeConvo huggingface dataset:
Change:
identities.  Identities may sometimes need to be routable, as is currently under discussion for EAP-TLS. <ins> 3.3. 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. 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. 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. gnuTLS: Applications configure PSK values, either as raw byte strings or hexadecimal strings, and identities as "usernames". The PSK size is not validated. wolfSSL: Applications configure PSKs with callbacks similar to OpenSSL. </ins> 4. Against a passive attacker AdvP or active attacker AdvA, desired

Discussion:
First cut at . cc NAME
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 *`). URL mbedTLS also treats PSKs as arbitrary byte arrays and character strings. ... from URL URL URL Applications specify a "username" (as the PSK identity) and a raw PSK. URL URL Callback style (with identical key and identity types) similar to OpenSSL. There is no minimum length enforced for the PSK. URL URL
Fixed in .
Change:
This section is informative. <del> A JSONPath expression is applied to a JSON value, the .  The output is a nodelist. </del> <ins> A JSONPath expression is applied to a JSON value, known as the argument.  The output is a nodelist. </ins> A JSONPath expression consists of an identifier followed by a series of zero or more segments each of which contains one or more

Discussion:
This is currently done inconsistently and doesn't add much value. Instead, define terms in the Terminology section. Reviewers please note: is not modified. This avoids a clash with URL which deletes the term.
Let's wait until lands before sorting this PR out. Meanwhile, rebased on main and kept one of the italicisations which was previously removed.
I've reinstated the other italics which NAME favoured.
Change:
A YANG Data Model for Optical Impairment-aware Topology <del> draft-ietf-ccamp-optical-impairment-topology-yang-09 </del> <ins> draft-ietf-ccamp-optical-impairment-topology-yang-10 </ins> Abstract

Discussion:
draft-ietf-ccamp-optical-impairment-topology-URL for IETF 114 submission --> draft-ietf-ccamp-optical-impairment-topology-yang-URL Related to pull request . Addressing and resolving several open issues.
May need to rebase this branch with the master branch to make sure all the validation checks pass
Change:
Initial entries in this sub-registry are as follows: <del> (Short: Short name used in query parameters or link attributes.  Use: R = used at registration, L = used at lookup, A = expressed in link attribute </del> <ins> (Short: Short name used in query parameters or target attributes. Use: R = used at registration, L = used at lookup, A = expressed in target attribute </ins> The descriptions for the options defined in this document are only summarized here.  To which registrations they apply and when they are

Discussion:
None of those meant any of (anchor,rel,rev), and all the other attributes that come from serializations should be called by what they are. Closes: URL
Working with RFC8288 in CoRAL I noticed that we're a bit sloppy on some concepts of web linking. This manifests in two related issues: We're talking of link attributes, where that's a term nowhere defined. (Used by RFC6690, but possibly they mean "attributes of CoRE links" and not "Core's use of link attributes", and even there only in the chapter name.) The information model we describe is more the model of the serialized data; the data model makes no distinction, for example, between and . The latter is something we can IMO let slide on account of practical readers having both in mind. The former poses the danger of aggravating the careless use of "link attributes" that'd describe the link-as-a-whole (something not covered by the data model, and thus incompatible with different serializations), but can easily be fixed in a search-and-replace PR coming right up.
Change:
with any other value as a connection error of type PROTOCOL_VIOLATION. <ins> A client that wishes to send 0-RTT packets uses the "early_data" extension in the ClientHello message of a subsequent handshake (see Section 4.2.10 of TLS13).  It then sends the application data in 0-RTT packets. </ins> Early data within the TLS connection MUST NOT be used.  As it is for other TLS application data, a server MUST treat receiving early data on the TLS connection as a connection error of type

Discussion:
Of the TLS doc says: A server rejects 0-RTT by rejecting 0-RTT at the TLS layer. This also prevents QUIC from sending 0-RTT data. However, this doesn't explicitly say that it prevents QUIC from receiving 0-RTT data. I suspect this is implied, but it might be worth clarifying. I could imagine a server rejecting 0-RTT data, but attempting to ACK the client's 0-RTT packets in order to deliver a congestion signal to the client. I think this would be a rather terrible idea, so it would be nice to explicitly prohibit it.
Throughout transport, there is the idea that you MUST not acknowledge packets you can't fully process, so this should be against the spec. But it may be worth noting explicitly, probably in transport.
Doing it in transport would make sense. Or perhaps in TLS by noting that if 0-RTT is rejected, 0-RTT keys must not be generated.
NAME I just added text about that to my PR that's targeting .
SG NAME If so, can you update the CL description to indicate what issues it closes?
I'm going so recommend that this be triaged as a design issue, even if it might seem trivial. The prohibition in is the right response.
The spec says RFC 8446 says about rejecting 0-RTT: This doesn't really apply to QUIC, since we don't need a connection that requires us to read the bytes in order. The QUIC equivalent would be to drop all packets of packet type 0-RTT.
It is my understanding the existence of early_data extension in the EncryptedExtensions message indicates if the server has accepted 0-RTT (or not). Merely dropping the packets is not sufficient. This is because the parameters of a connection depends on if 0-RTT has been received; for example, in case of HTTP/3, until the client receives a SETTINGS frame, the settings of previous connection is applied when 0-RTT is accepted, whereas the default settings defined by the specification is applied when 0-RTT is rejected.
PS. What I think we need to clarify is that "use and acceptance" of 0-RTT is communicated the same way as TLS 1.3, by using the earlydata extension.

That includes earlydata extension sent in ClientHello, EncryptedExtensions, NewSessionTicket.
Thanks NAME That confirms my interpretation of how accepting and rejecting is supposed to work. I’ll prepare a PR later.
Change:
specification QUIC-TLS.  This split is performed to enable light- weight versioning with different cryptographic handshakes. <ins> The QUIC Versions Registry established in QUIC allows for provisional registrations for experimentation.  Registration, also of experimental versions, is important to avoid collision.  Experimental versions should not be used long-term or registered as permanent to minimize the risk of fingerprinting based on the version number. </ins> 14. QUIC version 1 does not specify a version negotiation mechanism in

Discussion:
addresses
-- Would there be an opportunity to fingerprint a unique application using a specific experimental version number (in an ecosystem of continuous evolution and experimentation suggested above)? [MK] I guess that is the whole point here and I think the answer is no. You might see new experimental version that come and go quickly and are deployed only by one vendor but I don't think that will give you necessarily much insights about the application within the encrypted payload. Also experimental version are expected to be around for short times only and change quickly, thus you would be very busy to adapt your fingerprinting continuously. That's why the recommendation is to not do it. [Christian Huitema] Application developers will try to evolve the version number. If that cause the packets to be somehow discarded, this will have a very predictable result: all QUIC implementations will set the version number to 1 in the clear text header, while the "real" version number will be negotiated as part of the encrypted payload. If we follow that path, the network managers will not have any usable signal about the QUIC version, and the application developers will have to use more complex software and carry four useless bytes in the initial packets. Truth is, this is most likely what will happen, given natural trends. I don't know whether the text in the applicability statement will be enough to avoid that fate.
I don't think we can say more about not using the version number to identify QUIC. However do we want to mention the risk of fingerprinting? However, I guess that would rather something to add to the spec considerations in the applicability statement?
Change:
1. In many environments, users need to connect to a captive-portal <del> server and agree to an Acceptable Use Policy (AUP) and / or provide billing information before they can access the Internet.  It is anticipated that the IETF will work on a more fully featured protocol at some point, to ease interaction with Captive Portals.  Regardless of how that protocol operates, it is expected that this document will provide needed functionality because the client will need to know when it is behind a captive portal and how to contact it. </del> <ins> device and agree to an Acceptable Use Policy (AUP) and / or provide billing information before they can access the Internet.  Regardless of how that mechanism operates, this document provides functionality to allow the client to know when it is behind a captive portal and how to contact it. </ins> In order to present users with the payment or AUP pages, presently a captive-portal enforcement device has to intercept the user's

Discussion:
Forgot to make PR. This is the "good" one, should be abandoned...
Nope -- I think it is still TBD - we've asked / strongly suggested 114 in the IANA section, but I think it would feel presumptive to state that it is... W
I believe this should be changed to 114, or IANA-TBD.
Yikes, good catch. I changed it to TBD, and also added a sentence to the Abstract noting that it has changed from 160 to TBD (it seemed important enough). Thank you! W
NAME have changed or will change? I can't see this in the current version(s) of the draft here.
I swear I'd done this, and event sent a PR, but I cannot find it.... so, just made a new one...
I had created the branch, and made the edits, but apparently forgot to make the PR.... and then, because I couldn't find it, I made a new branch, change and PR (), and then realized the original was better, so I removed PR and created ... Oy vey, W
Done, had forgotten to close...
Should the TBDs be 114? Either that, or the list of changes should be TBD as well?
Change:
OSCORE (Section 3.1 of RFC8613).  In particular, the OSCORE_Security_Context object is defined to be serialized and transported between nodes, as specified by this document, but can <del> also be used in this way by other specifications if needed.  The OSCORE_Security_Context object can either be encoded as a JSON object or as a CBOR map.  The set of common parameters that can appear in an OSCORE_Security_Context object can be found in the IANA "OSCORE Security Context Parameters" registry (sec-ctx-params-reg), defined for extensibility, and is specified below.  All parameters are optional.  table-key-labels provides a summary of the OSCORE_Security_Context parameters defined in this section. </del> <ins> also be used as a representation of Security Context state by other specifications if needed.  The OSCORE_Security_Context object can either be encoded as a JSON object or as a CBOR map.  The set of common parameters that can appear in an OSCORE_Security_Context object can be found in the IANA "OSCORE Security Context Parameters" registry (sec-ctx-params-reg), defined for extensibility, and is specified below.  All parameters are optional.  table-key-labels provides a summary of the OSCORE_Security_Context parameters defined in this section. </ins> This parameter identifies the OSCORE Version number, which is an int.  For more information about this field, see section 5.4 of

Discussion:
Not much here, though a couple points I'll leave some further comments on, as the proper disposition is not entirely clear.
If you agree NAME I would go ahead and merge this PR (excluding the "update of access rights" change at l.776).
Sorry, I missed this when it came in. Please go ahead.
Change:
If a Patch Record has a value field with value null, the matched Record (if any) is removed from the Pack. <del> For example, the following document could be given as iPATCH payload to change/set values of two SenML Records for the example in intro: </del> <ins> For example, the following document could be given as (i)PATCH payload to change/set values of two SenML Records for the example in intro: </ins> If the request is successful, the resulting representation of the example SenML Pack would be as follows:

Discussion:
using "(i)PATCH" to refer to both PATCH methods Clarified defaulting rules Clarified name resolving rules Clarified use of "resource" Added note that application of Patch Packs is idempotent Removed "more details in RFC-AAA" from media type encoding considerations (there are no more details actually)
Change:
Remove support for MD5 and SHA-224 hashes with signatures. <ins> Revise list of currently available AEAD cipher suites. </ins> draft-07 Integration of semi-ephemeral DH proposal.

Discussion:
This revises "The Cipher Suites" section to simplify redundant language, actually explain the de facto naming convention, and add all currently available AEAD cipher suites. It also drops the appendix table that has already had its section whittled down quite a bit, in favor of the explanation and new table in the main section. Note that this is all of the AEAD ciphers available in the current IANA registry [0], plus ChaChaPoly (which has to be a normative reference [1], so must reach RFC status before this does). Issue just said "standards track AEAD ciphers", but as the registry lists them all, adding them wasn't difficult. If we'd rather not cite them here then they can of course be cut out (ARIA, Camellia, & ECDHE AES-CCM are informational; the rest are standards track, including DHE AES-CCM). Alternatively, the table could be annotated to note which are on what track or split in two. This has no changes to any requirements. [0] URL [1] URL
NAME I addressed your comments in this new commit. I switched to a table to make things easier to read and explicitly clarified the constant string bits so as to be more clear. I also dropped the confusing sentence fragment.
looks good.
AES-OCB will also be addable to this list, but its codepoints are all completely TBD still. URL
Rebased, squashed, & updated for recent changes to draft.
Ok, all comments addressed with that last commit. I've split the table into standards and non-standards and simplified the note to just mention ECDHE AES GCM being widely deployed.
Rebased.
Ok, reworded that bit too.
I only added the GCM AEAD ciphers. We should add all the standards track AEAD ciphers.
NAME This was dealt with in PR and can be closed.
Change:
When the client-facing server accepts ECH, it forwards the ClientHelloInner to the backend server, who terminates the <del> connection.  If the ClientHelloInner contains an empty "encrypted_client_hello" extension, then the backend server MUST confirm ECH acceptance by setting ServerHello.random[24:32] to </del> <ins> connection.  If the backend server negotiates TLS 1.3 or higher and the ClientHelloInner contains an empty "encrypted_client_hello" extension, then the backend server MUST confirm ECH acceptance by setting ServerHello.random[24:32] to </ins> where HKDF-Expand-Label and HKDF-Extract are as defined in RFC8446. The value of ServerHello.random[0:24] is generated as usual by invoking a secure random number generator (see RFC8446, Section 4.1.2). <ins> The backend server MUST NOT perform this operation if it negotiated TLS 1.2 or below.  Note that doing so would overwrite the downgrade signal for TLS 1.3 (see RFC8446, Section 4.1.3). </ins> 8. Unlike most TLS extensions, placing the SNI value in an ECH extension

Discussion:
As written, the backend server performs this URL modification unconditionally when it sees an empty ECH extension. Although the client is required to only offer TLS 1.3, the backend server doesn't check this. However, as noted elsewhere in the document, these same 8 bytes are used for the TLS 1.3 downgrade protection mechanism. That mechanism only works if the server never produces a TLS 1.2 ServerKeyExchange signature without the signal, so it's important that the server not signal ECH acceptance. Write this down.
Oops. Good catch!Yup, this is a good idea.
Change:
All RSA signatures must be generated and verified according to PKCS1 block type 1. <ins> 5.11. With the NIST curves, each party must validate the public key sent by its peer before performing cryptographic computations with it. Failing to do so allows attackers to gain information about the private key, to the point that they may recover the entire private key in a few requests, if that key is not really ephemeral. Curve25519 was designed in a way that the result of Curve25519(x, d) will never reveal information about d, provided it was chosen as prescribed, for any value of x. Let's define legitimate values of x as the values that can be obtained as x = Curve25519(G, d') for some d, and call the other values illegitimate.  The definition of the Curve25519 function shows that legitimate values all share the following property: the high- order bit of the last byte is not set. Since there are some implementation of the Curve25519 function that impose this restriction on their input and others that don't, implementations of Curve25519 in TLS SHOULD reject public keys when the high-order bit of the last byte is set (in other words, when the value of the leftmost byte is greater than 0x7F) in order to prevent implementation fingerprinting. Other than this recommended check, implementations do not need to ensure that the public keys they receive are legitimate: this is not necessary for security with Curve25519. </ins> 6. The table below defines new ECC cipher suites that use the key

Discussion:
Added new curves and new authors. Partial merge of draft-ietf-tls-curve25519
Change:
[THIS SECTION TO BE REMOVED BY THE RFC EDITOR.] <ins> Changes from version 22 to version 23 Removed request for IANA registration of swid and swidpath as URI schemes.  Updated text to note that that these are not URIs but expressions that follow URI syntax </ins> Changes from version 12 to version 14: Moved key identifier to protected COSE header

Discussion:
Removed IANA registrations for swid and swidpath and updated text to note these are not technically URIs but just expressions using URI syntax.
Change:
The fields in this state have the following semantics: <ins> The "cipher_suite" is the cipher suite used by the group. </ins> The "group_id" field is an application-defined identifier for the group.

Discussion:
This will guarantee that all group members agree on the ciphersuite used. It gives more meaning to statements like "Each MLS session uses a single ciphersuite". Also, it prevents the following attack: the adversary (a malicious insider) invites someone and convinces them that the group uses a ciphersuite with say a signature scheme that is weaker but still compatible with the one actually used. Now the new member uses a weaker scheme and the adversary can impersonate them.
Interim 2022-06-02: Agreement that more binding is better
Change:
the elements of the enumerated are not ordered, they can be assigned any unique value, in any order. <del> Future extension or additions to the protocol may define new values. </del> <ins> Future extensions or additions to the protocol may define new values. </ins> Implementations need to be able to parse and ignore unknown values unless the definition of the field states otherwise.

Discussion:
Reading through the spec again I found a few tiny things to fix. I'm suggesting to replace "Zero-RTT" with "0-RTT" in the paragraph because I found "Zero-RTT" used only in headlines, but "0-RTT" consistently in paragraphs.
NAME Please provide a PR to add yourself to acknowledgements.
Change:
other party is willing to accept communication at the base level of that specification, you can communicate successfully. <del> The alternative - that of having no mandatory to implement - does not </del> <ins> The alternative, that is having no mandatory to implement, does not </ins> mean that you cannot communicate, it merely means that in order to be part of the communications partnership, you have to implement the <del> standard "and then some" - that "and then some" usually being called a profile of some sort; in the version most antithetical to the </del> <ins> standard "and then some".  The "and then some" is usually called a profile of some sort; in the version most antithetical to the </ins> Internet ethos, that "and then some" consists of having to use a specific vendor's product only.

Discussion:
Ben noted is his comments: 2.3, last paragraph: The paragraph is a single, convoluted sentence that is hard to parse. (It's also a comma splice). Please consider breaking into multiple simpler sentences.
This text is gross, but the changes are fine.