jiebi/CodeConvo huggingface dataset:
Change:
on efficient collision-finding algorithms on the underlying hash constructions Transcript-Collision.  Further, in 2017, researchers from Google and CWI Amsterdam SHA-1-Collision proved SHA-1 collision <del> attacks were practical.  This document updates RFC5246 and RFC7525 in such a way that MD5 and SHA-1 MUST NOT be used for digital signatures.  However, this document does not deprecate SHA-1 in HMAC for record protection.  Note that the CABF has also deprecated use of SHA-1 CABF. </del> <ins> attacks were practical.  This document updates RFC5246 in such a way that MD5 and SHA-1 MUST NOT be used for digital signatures.  However, this document does not deprecate SHA-1 in HMAC for record protection. Note that the CABF has also deprecated use of SHA-1 CABF. </ins> 1.1.

Discussion:
I didn't add a -08 version of the doc (datatracker keeps that history), and this keeps the diff smaller. cc NAME NAME
Should we remove the 7525 text now that 7525bis is underway.
Could you also: remove the reference to 7525 on line 14 drop 7525 from line 45, i.e., change the header. This I-D will no longer update the 7525. drop "and RFC 7525" line 137. drop "and " from line 158 Like
Change:
not be used for sending if the connection was created with the Selection Property "Direction of Communication" set to "unidirectional receive" or if a Message marked as "Final" was <del> sent over this connection.  See msg-final. </del> <ins> sent over this connection.  See also msg-final. </ins> Whether the connection can be used to receive data.  A connection cannot be used for reading if the connection was created with the

Discussion:
Also spotted some further small nits while reviewing the document, will create a pull request for those.
Change:
in the selected cipher suite to derive keys used in message processing.  This section defines Extract (extract) and Expand (expand), and how to use them to derive PRK_out (prkout) which is the <del> shared secret key resulting from a successful EDHOC exchange. </del> <ins> shared secret session key resulting from a successful EDHOC exchange. </ins> Extract is used to derive fixed-length uniformly pseudorandom keys (PRK) from ECDH shared secrets.  Expand is used to define EDHOC-KDF

Discussion:
Issue
Minor comment, but reading through all the security claims, they multiple times refer to the term (for instance in ), which is not per say completely defined. I am not even sure there is any ambiguity, but is it still worth adding somewhere that this relates to ?
Yes, I assume session key most often refer to PRK_out. Could maybe refer to the exported application keys in some sentence. Let's go through all instances and make it clear what it refers to.
Change:
opaque server data in that order.  The load balancer uses the server ID octets for routing. <del> 4.5.3. </del> <ins> 4.4.3. </ins> When generating a routable connection ID, the server MUST choose a connection ID length between 17 and 20 octets.  The server writes its

Discussion:
Although more complex, the three-pass algorithm seems strictly better.
I like it, but there is some imprecision in the text. I would like to see something about detecting corruption, probably in the load balancer actions.
Change:
migrations to attempt to increase the number of simultaneous migrations at a given time, or through other means. <del> 8.3. </del> <ins> 9.3. </ins> QUIC provides a Server Retry packet that can be sent by a server in response to the Client Initial packet.  The server may choose a new

Discussion:
addresses issue
I think the applicability draft may benefit from exploring connection migration strategies as described in: URL
Do we also need to say anything about use of 0-byte CID? See quicwg/base-drafts
The transport draft already says:
addressed by PR and one more sentence
I don’t see any text related to connection migration on that PR.
sorry wrong PR; should be and is already merged
good modulo typos
Change:
client) and provide key confirmation and handshake integrity. In the Key Exchange phase, the client sends the ClientHello (client- <del> hello) message, which contains a random nonce (ClientHello.random), its offered protocol version, a list of symmetric cipher/HKDF hash pairs, some set of Diffie-Hellman key shares (in the "key_share" </del> <ins> hello) message, which contains a random nonce (ClientHello.random); its offered protocol version; a list of symmetric cipher/HKDF hash pairs; some set of Diffie-Hellman key shares (in the "key_share" </ins> extension key-share), one or more pre-shared key labels (in the <del> "pre_shared_key" extension pre-shared-key-extension), or both, and </del> <ins> "pre_shared_key" extension pre-shared-key-extension), or both; and </ins> potentially some other extensions. The server processes the ClientHello and determines the appropriate

Discussion:
At least to me, the KE phase description currently reads like the DH share and PSK are always sent. It's DH, PSK, or both.
Change:
public key and returns status code 200 (OK).  Otherwise, the server responds with an error status code and a problem document describing the error.  If there is an existing account with the new key <del> provided, then the server SHOULD use status code 409 (Conflict). </del> <ins> provided, then the server SHOULD use status code 409 (Conflict) and provide the URL of that account in the Location header field. </ins> Note that changing the account key for an account SHOULD NOT have any other impact on the account.  For example, the server MUST NOT

Discussion:
Similar to Section 7.3.1 "Finding an Account URL Given a Key" when a key rollover request will result in a conflict with an existing account the header of the response should indicate the URL of the conflicting account. This saves the client from having to post the new-account endpoint to learn the account URL.
Change:
[42, h'0123456789abcdef', 0, h'3031323334'] For illustration, the structure of an application/multipart-core <del> representation can be described by the CDDL I-D.ietf-cbor-cddl specification in mct-cddl: </del> <ins> representation can be described by the CDDL RFC8610 specification in mct-cddl: </ins> This format is intended as a strict specification: An implementation MUST stop processing the representation if there is a CBOR well-

Discussion:
Address Benjamin Kaduk's outstanding DISCUSS.
No: with that, the sender sends along all formats and the recipient chooses based on its capabilities or preferences. Appropriate for single-shot mail, not at all appropriate for a request/response situation (at least not for the response part). URL Grüße, Carsten
Ah sorry, hadn't read properly (it's sender, not receiver).
LGTM
Change:
It is expected that keys are discarded after packets encrypted with them would be acknowledged or declared lost.  Initial secrets however might be destroyed sooner, as soon as handshake keys are available <del> (see Section 4.9.1 of QUIC-TLS). </del> <ins> (see Section 4.10.1 of QUIC-TLS). </ins> 6.

Discussion:
and 4.9.1 are now 4.10 and 4.10.1, I believe.
Change:
A member of a group authenticates the identities of other participants by means of credentials issued by some authentication system, e.g., a PKI.  Each type of credential MUST express the <del> holder's identity as well as the public key of a signature key pair that the holder of the credential will use to sign MLS messages. </del> <ins> following data: The public key of a signature key pair The identity of the holder of the private key The signature scheme that the holder will use to sign MLS messages </ins> Credentials MAY also include information that allows a relying party to verify the identity / signing key binding.

Discussion:
This PR fixes several small issues I encountered while bringing my implementation more up to date. When I changed to allow blanks in the tree, I failed to update accordingly Credentials should dictate what signature scheme they will be used with, and once that's the case, we no longer need to indicate what algorithm is in use in cases where the signer's credential is known should come with a credential, not just a public key The confirmation value is easier to parse as an opaque vector value than as an array whose size depends on the ciphersuite in use
Change:
Produced By: Verifier A set of rules that informs how a Verifier evaluates the validity <del> of information about an Attester.  Compare /security policy/ in </del> <ins> of information about an Attester.  Compare: /security policy/ in </ins> RFC4949. Consumed By: Verifier

Discussion:
Despite fixes in , Roman asks: [Roman's comments on -13] -- Section 4.1. In the definition of relying party, what does the sentence fragment "Compare /relying party/ in [RFC4949]" mean? -- Section 4.2. Per the definition of "Claim", what does "Compare /claim/ in [RFC7519]" mean? -- Section 4.2. Per the definition of "Appraisal Policy for Attestation Results", what does "Compare /security policy/ in [RFC4949]" mean? I continue to hold the position that this language "Compare /xxx/ in RFC####" is not clear. In the natural language sense, that phrase doesn't parse. If the semantics are being taken from Section 2.6 of RFC4949, please explain that. However, it seems confusing to explicitly be listing antonyms (which RF4949 suggests is the meaning of the "Compare" notation). In the case of a claim, is it an antonym -- isn't a claim here in fact similar to the one in Section 2 of RFC7519?
`
Change:
minimizing perceived post-dial-delay.  The second offer/answer exchange can also change the preferred codecs or other information. <ins> This example also makes use of the "relay" ICE candidate policy described in sec.ice-candidate-policy to minimize the ICE gathering and checking needed. </ins> The SDP for |offer-C1| looks like: The SDP for |offer-C1-candidate-1| looks like:

Discussion:
Good way of getting ICE going quickly, and shows off IceTransportPolicy. Consider ICE restart for second offer (shows off ICE restart handling). Could also go into complex example.
Started on this.
Change:
In pseudocode, the logic for whether the "path` field is required is as follows: <ins> To summarize, a Commit can have three different configurations, with different uses: An "empty" Commit that references no proposals, which updates the committer's contribution to the group and provides PCS with regard to the committer. An "add-only" Commit that references only Add proposals, in which the path is optional.  Such a commit provides PCS with regard to the committer only if the path field is present. A "full" Commit that references proposals of any type, which provides FS with regard to any removed members and PCS for the committer and any updated members. </ins> A member of the group creates a Commit message and the corresponding Welcome message at the same time, by taking the following steps:

Discussion:
I think we need to clearly define "FS / PCS with regard to", but once we do that, it seems like a fine phrase. That seems like a good topic for a review / update of the Security Considerations once we have the protocol mostly in shape, for which I have filed .
The not-protocol parts of the document, including security considerations and some of the operational considerations, are mostly untouched since the beginning of this work. As we get the protocol firmed up, we should revisit these parts to make sure they're up to date and give an accurate reflection of the concerns around the protocol.
One particular thing related to this that I noticed is that in the the first sentence: is outdated as (ii) can now also be an all-zero vector, namely if is not required and not set (as introduced in if I'm not mistaken).
I did a review of the Security Considerations and didn't see anything that needs fixing before WGLC. The point that NAME raises appears to have been fixed in some other PR.
Right now, it is possible to send a Commit that covers no proposals. This has the result that the leaf of the sender and its direct path are refreshed, but no other change to the tree is made. (The epoch also advances, of course.) This can be is a useful operation. For example, an Add wipes out the new joiner's direct path, so having the new joiner send a Commit over no proposals would fill in that direct path and make subsequent operations more efficient. We should clarify in some prose that (a) this is possible and (b) why it might be useful.
That works fine. I am a bit bothered by the phrasing regarding properties « with regard to ...». If you can find an alternate phrasing that would be
Change:
The Issuer then creates a TokenResponse structured as follows: <del> The structure fields "evaluated_msg" and "proof" are as computed above, where Ns is as defined in OPRF, Section 4. </del> <ins> The structure fields are defined as follows: "evaluate_response" is the Ne-octet evaluated messaged, computed as "SerializeElement(evaluated_msg)". "evaluate_proof" is the (Ns+Ns)-octet serialized proof, which is a pair of Scalar values, computed as "concat(SerializeScalar(proof[0]), SerializeScalar(proof[1]))", where Ns is as defined in OPRF, Section 4. </ins> The Issuer generates an HTTP response with status code 200 whose body consists of TokenResponse, with the content type set as "message/

Discussion:
draft-irtf-cfrg-voprf-09 went out today, and this just aligns the basic issuance protocol on top of those changes. cc NAME
Change:
The new first flight will allow the endpoints to establish a connection using the negotiated version.  The handshake of the <del> negotiated version will exchange handshake version information (see hs-vers-info) required to ensure that VN was genuine, i.e. that no attacker injected packets in order to influence the VN process, see downgrade. </del> <ins> negotiated version will exchange version information (see vers-info) required to ensure that VN was genuine, i.e. that no attacker injected packets in order to influence the VN process, see downgrade. </ins> <del> 3.3. </del> <ins> 4.3. </ins> When the server can parse the client's first flight using the <del> original version, it can extract the client's handshake version information (see hs-vers-info).  This contains the list of versions that the client thinks its first flight is compatible with. </del> <ins> original version, it can extract the client's Version Information structure (see vers-info).  This contains the list of versions that the client thinks its first flight is compatible with. </ins> If the server supports one of the client's compatible versions, and the server also believes that the original version is compatible with

Discussion:
This PR simplifies the document's design. The new simplified design was by NAME . It removes the indication of server versions that everyone seemed to think was useless, but apart from that has very similar properties to the previous design. One important difference is that it is now the client's responsibility to detect VN-packet-based downgrade attacks instead of the server's. .
In , NAME points out that the backticks don't render nicely in the TXT version, so let's remove them
In , NAME mentioned that having the client communicate preference ordering between compatible versions isn't absolutely necessary. This issue tracks whether we want to keep this ordering or not.
During the IETF QUIC WG meeting there was (weak-ish) consensus that this useful to keep.
The strongest argument against this was that it doesn't give the server a full ordering, because it doesn't tell the server where the offered version falls in the preference list. There's a possible answer to that, which is that the client should only offer compatible versions which are more preferred than the currently offered version. However, we should explicitly state that the server makes the actual decision and MAY factor client preferences into that. I suspect most won't.
NAME that's incorrect. The offered version is present in the list.
Ah, thanks for correcting me. Then we're spending bytes to repeat the version number, which we don't expect servers will typically use. Not the end of the world either way.
Consensus established. Closing this issue with no action.
Almost there, but I think we need clarity on the clients verification-and-drop requirements.
Change:
DTLS client, such as the client certificate, less information is available to an on-path adversary. <del> 13. </del> <ins> 12. </ins> Since TLS 1.3 introduces a large number of changes to TLS 1.2, the list of changes from DTLS 1.2 to DTLS 1.3 is equally large.  For this

Discussion:
This pull request aims to address the open issues regarding sequence number encryption. The approach chosen follows the design used in QUIC.
Change:
future TLS versions or new TLS extensions introduced in the future may vary this computation.) <ins> An ECDHE key exchange using Curve25519 goes as follows.  Each party picks a secret key d uniformly at random and computes the corresponding public key x = Curve25519(d, G).  Parties exchange their public keys and compute a shared secret as x_S = Curve25519(d, x_peer).  ECDHE for Curve448 works similarily, replacing Curve25519 with Curve448.  The derived shared secret is used directly as the premaster secret, which is always exactly 32 bytes when ECDHE with Curve25519 is used and 56 bytes when ECDHE with Curve448 is used. </ins> All ECDSA computations MUST be performed according to ANSI X9.62 or its successors.  Data to be signed/verified is hashed, and the result run directly through the ECDSA algorithm with no additional hashing.

Discussion:
Added new curves and new authors. Partial merge of draft-ietf-tls-curve25519
Change:
If setRemoteDescription was previously called with an offer, and setLocalDescription is called with an answer (provisional or final), <del> and the media directions are compatible, and media are available to </del> <ins> and the media directions are compatible, and media is available to </ins> send, this will result in the starting of media transmission. 4.1.9.

Discussion:
Attempts to address issue . Also changed "control" to "inspect" in RtpReceiver description, since an RtpReceiver is readonly and doesn't let an application control anything.
LGTM
Originally raised by Christer Section 3.4.1 talks about ³RtpTranceivers², ³RtpSenders² and ³RtpReceivers². 1) I think they should be introduced in their own section (not within the Session Description Protocol section). 2) I think it should be explained what an RtpXXX really is. At a minimum there should be a reference to the appropriate W3C document. But, as there is text on how they related to SDP m- lines etc, 1 or 2 sentences describing what they are would also be useful.
Section 3.4.1 is its own section, and explains what the RtpTransceiver is. Agree that Sections 3.4.2/3.4.3 (on senders/receivers) could be expanded somewhat. NAME FYI
Resolved by
Change:
Derived Endpoints <del> Branching between paths is the first in the list because results across multiple interfaces are likely not related to one another: endpoint resolution may return different results, especially when using locally resolved host and service names, and which protocols are supported and preferred may differ across interfaces.  Thus, if multiple paths are attempted, the overall connection can be seen as a race between the available paths or interfaces. </del> <ins> where a lower number indicates higher precedence and therefore higher placement in the tree.  Branching between paths is the first in the list because results across multiple interfaces are likely not related to one another: endpoint resolution may return different results, especially when using locally resolved host and service names, and which protocols are supported and preferred may differ across interfaces.  Thus, if multiple paths are attempted, the overall connection can be seen as a race between the available paths or interfaces. </ins> Protocol options are next checked in order.  Whether or not a set of protocol, or protocol-specific options, can successfully connect is

Discussion:
These are mostly wording changes for clarification. Feel free to cherry pick.
Can't find any problems here - this looks good.
This LGTM, many thanks!
Change:
Once the handshake is complete, it is possible for either side to update its sending traffic keys using the KeyUpdate handshake message defined in key-update.  The next generation of traffic keys is <del> computed by generating client_/server_traffic_secret_N+1 from client_/server_traffic_secret_N as described in this section then re- deriving the traffic keys as described in traffic-key-calculation. </del> <ins> computed by generating client_/server_application_traffic_secret_N+1 from client_/server_application_traffic_secret_N as described in this section then re-deriving the traffic keys as described in traffic- key-calculation. </ins> <del> The next-generation traffic_secret is computed as: </del> <ins> The next-generation application_traffic_secret is computed as: </ins> <del> Once client/server_traffic_secret_N+1 and its associated traffic keys have been computed, implementations SHOULD delete client_/ server_traffic_secret_N and its associated traffic keys. </del> <ins> Once client/server_application_traffic_secret_N+1 and its associated traffic keys have been computed, implementations SHOULD delete client_/server_application_traffic_secret_N and its associated traffic keys. </ins> 7.3.

Discussion:
Make the variable names of various secrets correspond to the labels used for Derive-Secret(). This is not a wire format change, but just a change in the internal variable names.
NAME NAME you see any misses here?
The legends for the message flows still say "trafficsecretN" for the "[]" parts. Also, "Updating Traffic Keys and IVs" still uses "trafficsecretN" in the formula and text prior to it.
In the key schedule
Change:
the local port reservation. Calling "Abort" on a UDP Connection (ABORT.UDP(-Lite)) is <del> identical to calling "Close". </del> <ins> identical to calling "Close", except that the Connection will send a ConnectionError Event rather than a Closed Event. </ins> Calling "CloseGroup" on a UDP Connection (ABORT.UDP(-Lite)) is identical to calling "Close" on this Connection and on all

Discussion:
This PR covers steps 1 and 2 in . When aligning the error events for UDP multicast I also noticed that the text for UDP was not correct as soft errors do not generate ConnectionError events so also attempted to fix this.
NAME what's the reason for having Abort cause an error, rather than just moving to closed?
NAME This comes from the API draft, which says:
Great, thank you!
Change:
The rsabssa_finalize function is defined in BLINDRSA, Section 5.1.3.. If this succeeds, the Client then constructs a Token as described in <del> HTTP-Authentication as follows: </del> <ins> AUTHSCHEME as follows: </ins> The Token.nonce value is that which was sampled in private-request. If the rsabssa_finalize function fails, the Client aborts the

Discussion:
There's and . I'm guessing these should be collapsed to just one.
table 2 says: -- | -- and Section 8.1 says: What is the Token Type registry and what are the constraints on values in the registry? It's implied that values should be integers but JSON numbers are quite flexible, so would it be valid for me to register e.g. a negative integer. If the "Token Type" registry already exists, I'm not able to find it and a link would be useful. If it doesn't exist and this document wishes to create it, then more work is needed to establish that registry and it's procedures.
We're missing a link to the HTTP auth document, where the registry is defined. Good catch!
Change:
This document defines a key structure for both the public and private halves of RSA keys.  Together, an RSA public key and an RSA private <del> key form an RSA key pair.  [CREF16] </del> <ins> key form an RSA key pair.  [CREF14] </ins> The document also provides support for the so-called "multi-prime" RSA where the modulus may have more than two prime factors.  The

Discussion:
The CFRG EC algorithms are currently too far in the future to keep. Remove the ad put in the to be done later document.