jiebi/CodeConvo huggingface dataset:
Change:
along with the new ClientHello.  For instance, if the client sends ClientHello1, its binder will be computed over: <del> Where Truncate() removes the binders list from the ClientHello. </del> <ins> Where Truncate() removes the binders list from the ClientHello.  Note that this hash will be computed using the hash associated with the PSK, as the client does not know which cipher suite the server will select. </ins> If the server responds with a HelloRetryRequest and the client then sends ClientHello2, its binder will be computed over:

Discussion:
The function is defined using a function . URL This is presumably the KDF hash of the cipher suite, but this doesn't seem to be written down anywhere. The Key Schedule section says: URL I can't find corresponding text in the various other calls. We could define this globally in the Transcript Hash section, and indeed that fits with the claim that "In general, implementations can implement the transcript by keeping a running transcript hash value based on the negotiated hash." But then we have another problem... The PSK binder is also defined in terms of Transcript-Hash. Like the other text, it does not define what Hash is. URL But the default definition doesn't work for the client, in two different ways: At the first ClientHello, the cipher suite hash algorithm isn't even known yet, so we cannot possibly use that one. At the second ClientHello, we have a cipher suite hash algorithm, but it may not necessarily match the PSK's one. To keep all everything injective, both need to be the PSK hash. Though this results in another subtlety which, while not ambiguous, maybe we should change: At the second ClientHello, there are two uses of Hash. There's the overall hash, which is stuck being the PSK one, and there's the funny . That one being the PSK's hash breaks the whole notion of the transcript being this append-only thing and is a huge pain. To compensate, we allowed the second ClientHello to . That works, but it's a pretty weird edge case and easily a source of bugs. What if we changed it to be the negotiated hash? It won't affect interop, since this PSK is guaranteed not to be negotiated. The client may as well fill in all zeros for the binder. It's also still injective, as long as everyone agrees that's the one we use. The transcript includes an unhashed HelloRetryRequest immediately after messagehash, so that fixes the choice of hash. (Plus we only have two hashes right now and they're different sizes...)
Change:
CAs that use ACME to automate issuance will need to ensure that their servers perform all necessary checks before issuing. <ins> 10.  References 10.1.  URIs [1] https://github.com/ietf-wg-acme/acme </ins>

Discussion:
It's no longer at a "do not implement" stage, but some caution is still merited. Also, it's good to have a pointer in the draft to this repo. (Cribbed from the TLS 1.3 spec.)
Change:
The time-interval query type is described in time-interval-query; the fixed-size query type is described in fixed-size-query.  Future specifications can introduce new query types as needed (see query- <del> type-reg.  A query includes parameters used by the Aggregators to </del> <ins> type-reg).  A query includes parameters used by the Aggregators to </ins> select a batch of reports specific to the given query type.  A query is defined as follows:

Discussion:
NAME I think we should wait for one of NAME or NAME before merging.
s4.1 includes the following: Future specifications can introduce new query types as needed. That means this I-D needs an IANA consideration to address registering a query type.
Change:
fatal. <del> This alert was used in SSLv3 but not any version of TLS.  It MUST NOT be sent by compliant implementations.  This message is always fatal. </del> <ins> This alert was used in SSL 3.0 but not any version of TLS.  It MUST NOT be sent by compliant implementations.  This message is always fatal. </ins> A certificate was corrupt, contained signatures that did not

Discussion:
Small editorial change: The document currently goes back and forth between "SSLv3" & "SSL 3.0". Stick with the latter for consistency and clarity.
Change:
Otherwise, when the handshake completes successfully with the public name authenticated, the client MUST abort the connection with an <del> "ech_required" alert.  It then processes the "retry_keys" field from the server's "encrypted_client_hello" extension. </del> <ins> "ech_required" alert.  It then processes the "retry_configs" field from the server's "encrypted_client_hello" extension. </ins> If one of the values contains a version supported by the client, it can regard the ECH keys as securely replaced by the server.  It

Discussion:
Addresses
The spec uses both and when referring to the contents of . These should be made consistent (preferably using the former).
Agreed -- let's unify around ! Would you be able to propose text?
( is a remnant of the old name. I guess we missed a few.)
Thanks!
Change:
routed.  This can be used to direct connections to a different server instance. <del> If a server receives a client Initial that can be unprotected but contains an invalid Retry token, it knows the client will not accept </del> <ins> If a server receives a client Initial that contains an invalid Retry token but is otherwise valid, it knows the client will not accept </ins> another Retry token.  The server can discard such a packet and allow the client to time out to detect handshake failure, but that could impose a significant latency penalty on the client.  Instead, the

Discussion:
This should address all of them at once; one per commit for those that I think need action. This is probably OK: This is not expressly forbidden. We do say : Which doesn't really contradict the other. FWIW, I'm not a fan of allowing frames to be copied, implementations really should do that, but it's a consequence of having frame idempotency. This is one I'm not sure about: What is the prevailing advice regarding MTU and tunnels? Clearly when you tunnel you get a smaller MTU, but I haven't seen what happens when IPv6 is tunneled over a network that has a minimum MTU. Most paths don't have that small an MTU, so it might be that things just fail.
I realized that there are some answers here in the description, but probably best to move them to the relevant issues anyways.
NAME said: >
NAME said: with TLS.
NAME said:
NAME said: this true for PATH_CHALLENGE? I thought this quite explicitly shouldn't be copied.
My recommendation is to answer the question, but not change anything. See for an answer.
Very well, please close this issue. Sorry for the confusion.
NAME said: RESET_RECVD.
NAME said:
NAME said:
This looks good to me, with NAME 's nit.
Change:
4.1.8. <del> A Connection Group is a set of Connections that share properties and </del> <ins> A Connection Group is a set of Connections that shares properties and </ins> caches.  For multiplexing transport protocols, only Connections within the same Connection Group are allowed to be multiplexed <del> together.  An application can explicitly define Connection Groups to control caching boundaries, as discussed in groups. </del> <ins> together.  While Connection Groups are managed by the transport system, an application can define Connection Contexts to control caching boundaries, as discussed in conn-context. </ins> 4.2.

Discussion:
Fix terminology in -arch Add minimal connection contexts in -interface
We had not decided that yet: We agreed that the property was sufficient as portable interface for the purpose We did not yet because did nit fix the inconsistencies between Connection Groups in -architecture and -interface So what we could do (als an alternative to this PR) to - Drop the stuff this PR renamed to "Connection Context" from -arch all-together Merge the changes in -arch, but do not include the minimal Connection Context into -interface an try to squish question about the context missing in -interface in later reviews
Connection Groups used to be about state and context sharing as well as entanglement. Now it's about entanglement. We need to rename Connection Groups ("connection contexts"?) in the architecture to replace the existing "group" concept, and to retain "connection group" in the API for entanglement.
Seems like this could be 360 degrees of rotation in our thinking? (which could be OK, NEAT was written to specify both contexts and flow groups). Let's try some definitions here and see if we converge...
I think brings this back in synch again so no need to rename, possibly the last part of this section in architecture should be removed though as we do not have fine-grained control
Did we decide to explicitly introduce this new connection context?
Change:
invalid value MUST be treated as a connection error of type PROTOCOL_VIOLATION. <del> An 8-bit field representing a boolean truth value.  This field MUST have the value 0x00 (representing "false") or 0x01 (representing "true").  This field can be set to "true" by an endpoint that does not wish to receive an immediate acknowledgement when the peer observes reordering (reordering). Receipt of any other value MUST be treated as a connection error of type FRAME_ENCODING_ERROR. </del> <ins> An 8-bit field representing a boolean truth value.  This field is set to "true" by an endpoint that does not wish to receive an immediate acknowledgement when the peer observes reordering (reordering).  The value of this field MUST be 0x00 (representing "false") or 0x01 (representing "true").  Receipt of any other value MUST be treated as a connection error of type FRAME_ENCODING_ERROR. </ins> ACK_FREQUENCY frames are ack-eliciting.  However, their loss does not require retransmission if an ACK_FREQUENCY frame with a larger

Discussion:
Fixes issue .
Thanks for the PR!
Section 4 explains what all the fields are mean first and then explains the exception cases. It seems like this was done the opposite way for Ignore order. I propose we change the current text: To:
SGTM, want to send me a PR or should I?
Change:
feedback mechanisms that SHOULD/MUST be supported is specified in I-D.ietf-rtcweb-rtp-usage, Section 5.1. <del> If the bundle policy for this PeerConnection is set to "max- bundle", and this is not the first m= section, or the bundle policy is set to "balanced", and this is not the first m= section for this media type, an "a=bundle-only" line. </del> If the RtpTransceiver has a sendrecv or sendonly direction: An "a=msid" line, as specified in I-D.ietf-mmusic-msid,

Discussion:
It's a transport attribute, so it should come at the end, like other transport attribs
just checking ... this is just a style thing right? the code would accept SDP with these in any order ?
Of course. This is just how we order things in Section 5.
For createoffer, createanswer ordering of attribs
So SDP has no requirement on the ordering of the a= lines. I don't see how a parser, even a JSEP one can expect to get the a= lines in any specific order. I fear that even a "it is recommended to generate them in this order" will be misinterpreted. I think this is one of SDPs warts that you will have to live with.
Right, there isn't any need to mandate an order, I just think that in the text for generating an offer, the places that talk about adding a=rtpmap should be adjacent. This should be a fairly trivial editorial change.
Change:
4.5. <ins> %%% Updating Keys The EndOfEarlyData message is sent by the client to indicate that all 0-RTT application_data messages have been transmitted (or none will be sent at all) and that the following records are protected under handshake traffic keys.  Servers MUST NOT send this message and clients receiving it MUST terminate the connection with an "unexpected_message" alert. 4.6. </ins> TLS also allows other messages to be sent after the main handshake. These messages use a handshake content type and are encrypted under the application traffic key. <del> 4.5.1. </del> <ins> 4.6.1. </ins> At any time after the server has received the client Finished message, it MAY send a NewSessionTicket message.  This message

Discussion:
key changes happen at Handshake boundaries. Suggested by David Benjamin
I have one here, that could be a start: URL Also this is assuming PR URL is accepted ( becomes a message)
Merged.
Change:
private key, to the point that they may recover the entire private key in a few requests, if that key is not really ephemeral. <del> 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 (the same holds true for Curve448). </del> <ins> X25519 was designed in a way that the result of X25519(x, d) will never reveal information about d, provided it was chosen as prescribed, for any value of x (the same holds true for X448). All-zeroes output from X25519 or X448 MUST NOT be used for premaster secret (as required by definition of X25519 and X448).  If the premaster secret would be all zeroes, the handshake MUST be aborted (most probably by sending a fatal alert). </ins> Let's define legitimate values of x as the values that can be <del> 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 (for Ed448, any bit can be set). </del> <ins> obtained as x = X25519(G, d') for some d', and call the other values illegitimate.  The definition of the X25519 function shows that legitimate values all share the following property: the high-order bit of the last byte is not set (for X448, any bit can be set). </ins> <del> Since there are some implementation of the Curve25519 function that </del> <ins> Since there are some implementation of the X25519 function that </ins> impose this restriction on their input and others that don't, <del> 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 </del> <ins> implementations of X25519 in TLS SHOULD reject public keys when the high-order bit of the last byte is set (in other words, when the </ins> value of the leftmost byte is greater than 0x7F) in order to prevent implementation fingerprinting.

Discussion:
Replace uses of Curve25519 with X25519 (and similarly with 448-bit one). Also add zero checks as required by CFRG-CURVES. Because of problems with TLS 1.2 key exchange, omitting these checks leads to security issues.
Renamed the curves to be consistent with what got merged into TLS 1.3 spec
Change:
underlying transport security protocols.  When not specified, these algorithms should use known and safe defaults for the system.  Parameters include: ciphersuites, supported groups, and <del> signature algorithms. </del> <ins> signature algorithms.  These parameters take a collection of supported algorithms as parameter. </ins> Pre-Shared Key import: Used to install pre-shared keying material established out-of-band.  Each pre-shared keying material is

Discussion:
I should have said: I approve this, modulo the changes requested by NAME
Thanks for incorporating my suggested changes. I think this can be merged now.
Change:
contain an If-Match header with the latest known entity-tag as per RFC7232 section 3.1.  When the PATCH request is received by the WHIP resource, it MUST compare the entity-tag value requested with the <del> current entinty-tag of the resource as per RFC7232 section 3.1 and </del> <ins> current entity-tag of the resource as per RFC7232 section 3.1 and </ins> return a 412 Precondition Failed response if they do not match. <del> Entity-tag validation MUST only be used for HTTP requests requiring to match a known ICE session and SHOULD NOT be used otherwise, for example in the HTTP DELETE request to terminate the session. </del> <ins> WHIP clients SHOULD NOT use entity-tag validation when matching a specific ICE session is not required, such as for example when initiating a DELETE request in order to terminate a session. </ins> A WHIP resource receiving a PATCH request with new ICE candidates, but which does not perform an ICE restart, MUST return a 204 No

Discussion:
So it's a MUST or a SHOULD?
NAME wdyt? is it ok to merge it and will it solve your concerns?
I'm sorry, but I still don't know what that says. Does it say that the client MUST NOT use If-Match on the DELETE, or does it say that the server MUST ignore an If-Match on the DELETE? I suggest making it clear to whom the requirement applies.
should be applicable only to clients, is it better now?
NAME ping?
I think this is still ambiguous due to the MUST in the first part. I suggest removing the first part:
what about now?
NAME ping?
merging this, we can modify it after the WGLC
Yeah, it's okay now.
Change:
5. <ins> The WebTransport framework I-D.vvv-webtransport-overview defines a set of optional transport properties that clients can use to determine the presence of features which might allow additional optimizations beyond the common set of properties available via all WebTransport protocols.  Below are details about support in Http2Transport for those properties. Http2Transport does not support stream independence, as HTTP/2 inherently has head of line blocking. Http2Transport does not support partial reliability, as HTTP/2 retransmits any lost data.  This means that any datagrams sent via Http2Transport will be retransmitted regardless of the preference of the application. Http2Transport supports pooling, as multiple transports using Http2Transport may share the same underlying HTTP/2 connection and therefore share a congestion controller and other transport context. Http2Transport does not support connection mobility, unless an underlying transport protocol that supports multipath or migration, such as MPTCP RFC7540, is used underneath HTTP/2 and TLS.  Without such support, Http2Transport connections cannot survive network transitions. 6. </ins> WebTransport Streams established by the CONNECT handshake and the WTHEADERS frame are expected to be protected with a TLS connection. They inherit the security properties of this cryptographic context,

Discussion:
Add brief section describing Http2Transport's stance on the properties enumerated in the WebTransport Overview. We can move this around later as necessary, but wanted to get the text in to document which optional properties are supported and which are not.
From the : We should enumerate the position that Http2Transport takes on each of these items. Specifically: No stream independenceNo partial reliabilityYes pooling supportNo connection mobility
Change:
"enc_response" as follows: Export a secret "secret" from "context", using the string <del> "response" as a label.  The length of this secret is "Nk" - the length of an AEAD key assocated with "context". </del> <ins> "response" as context.  The length of this secret is "max(Nn, Nk)", where "Nn" and "Nk" are the length of AEAD key and nonce associated with "context". </ins> Generate a random value of length "max(Nn, Nk)" bytes, called "response_nonce".

Discussion:
One question we might want to ask (even though I think we have the right answer already) is: should be included in AAD? I also removed the padding text, since we moved that to the bhttp spec.
It's a reasonable question, but I think we can safely assume that a single key can't be used with multiple KEMs.
In principle it might be possible, but I think we should prohibit it.
Change:
4.4. <del> In CoAP over TCP/TLS, Empty messages can always be sent and will be </del> <ins> In CoAP over TCP, Empty messages can always be sent and will be </ins> ignored.  This provides a basic keep-alive function that can refresh NAT bindings.  In contrast, Ping and Pong messages are a bidirectional exchange.

Discussion:
I'm finding "CoAP over protocol" to be too verbose - especially in text that references or compares multiple protocol bindings. Can we agree on a shorthand? CoAP protocol such as CoAP UDP, CoAP TCP/TLS, CoAP WebSockets CoAP+protocol such as CoAP+UDP, CoAP+TCP/TLS, CoAP+WebSockets
The URI scheme component provides a reasonably good shorthand form to reflect the protocol bindings and the "Terminology" section could perhaps reflect that? It would be approximately lead to something like the following text: In this document, references to the various transport bindings for conveying CoAP messages adopt the following abbreviations: CoAP+TCP refers to CoAP over TCP, and CoAP+WS refers to CoAP over WebSockets. Using "CoAPS+" instead of "CoAP+" implies the use of their corresponding TLS-based secure counterparts. CoAP and CoAPS refer to CoAP over UDP and CoAP over DTLS, respectively.
Change:
examine the KT log, if available, to make sure the keys they will be using are correct. <del> 2.3.2. </del> <ins> 2.2.2. </ins> Delivery in order and resilience against intermittent message loss are the two main properties expected by MLS from the DS.  Another

Discussion:
A few minor edits to (hopefully) improve readability, and a few comments in square braces ([ ]).
Something looks wrong with your text editor... ;)
Arg! Will fix, sorry about this.
Change:
RFC EDITOR PLEASE DELETE THIS SECTION. <ins> draft-18 Make the document standards track Make the ratchet tree non-malleable (*) Use ExpandWithLabel to derive welcome key (*) Change MLS-Exporter label from "exporter" to "exported" (*) Loosen chain requirements (*) Clarify transcript hash initialization GREASE for MLS registries Move pseudocode out of KDFLabel definition. Rename PrivateContentTBE to PrivateMessageContent Fix DecryptWithLabel argument order for Welcome Responses to IESG reviews Describe varint length check more clearly draft-17 Rename MLSCiphertext and MLSPlaintext to PrivateMessage and PublicMesssage respectively (*) Add label and context to public-key encryption (*) Include leaf index in LeafNodeTBS for better parent-hash guarantees (*) Make ProtocolVersion two bytes (*) Clarify group creation (*) Validate additional properties of unmerged leaves (*) Clarify that the AS needs to vet the signature key Remove "MLS" prefix on structs Credentials should be replaced before expiring Add a section discussing the security of the sender data protection Minor fixes in presentation language. Allow multiple welcomes per commit Remove reference to BasicCredential. Client aware of its own removal in group Create IANA registries for signature and export labels Complete IANA media type registration Make more vendor code points available Update Recommended column definition to match 8447bis Responses to early ARTART review Responses to early OPSDIR review Responses to early TSV-ART review draft-16 Fix GroupInfoTBS (*) Make reference to h2 informative </ins> draft-15 Include ciphersuite in group context (*)

Discussion:
Also adds a draft-18 section to cover any edits between now and the next I-D.
Change:
The AS validates the token and returns the most recent parameters, such as scope, audience, validity etc. associated with it back to the RS.  The RS then uses the received parameters to process the <del> request to either accept or to deny it.  FIXME: Mention client token. </del> <ins> request to either accept or to deny it.  (FIXME: Mention client token.) </ins>

Discussion:
I have reviewed the protocol section and have made some minor edits. I believe the section is looking good. There were only two items that I believe are worthwhile to discuss: I prefer to use the term endpoint for the /token and /introspect rather than calling them resource. The term endpoint is used in the terminology section and aligns with OAuth. The client token is mentioned in this section and even after looking at the text later in the document I didn't really understood the concept.
Looks good to me. Does anyone else have a strong opinion on the use of "endpoint" vs "resource"? We might need to put a note into the text somewhere to clarify, since CoAP IMHO uses "endpoint" with a slightly different meaning.