jiebi/CodeConvo huggingface dataset:
Code change:
curves, they SHOULD perform the additional checks specified in Section 7 of <del> Encryption keys are derived from shared secrets by taking the first 16 bytes of H(Z), where Z is the shared secret and H is SHA-256. </del> 5.5.2. This ciphersuite uses the following primitives:

Related discussion:
text: Initial attempt to solve . This defines the KDF as discussed in and relocates the DH computation obligation and verification as part of the Derive-Key-Pair function definition.
Fixing my own review comments here, since NAME appears to be offline and we need to publish -04.
The PR from NAME introducing a KDF was merged before I had a chance to review it. There are a number of problems with it: Instead of calling for an abstract KDF, it should define one, as we have with the use of HKDF elsewhere We can't just say , since KDFs produce octet strings, not private keys. We need , not just . This doesn't match what I recall discussing on the list. I think what you want is actually as follows: Or in prose:
That was exactly the question I was asking on the list, i.e., if we need an explicit "derive-keypair" function. The idea with deriving the private key directly was to avoid a redundant derive-key operation. I'm totally fine re-doing the PR to represent either approach.
Merging that PR too quickly is on me. For the parent derivation, we can just use what the formal model for TreeKEM does, which is roughly the Richard points out. The part I don't like about this, is to define in the MLS specification as it depends on the HPKE internal algorithm. The TreeKEM formal specification, it is done the following way (because we know that the HPKE interface we use can take random bytes as a secret key): In the MLS specification, I suggest we avoid defining anything new but point to the HPKE spec instead. As it provides the KEM scheme, it should also provide ways to derive the from an octet string and the function that transform an to a . I suggest we define, in the HPKE document, something like that we already need anyway and eventually that maps the random bytes to an . For X25519 we don't even need the second function but generically we probably need it. That would lead to define the following in the MLS spec: NAME ?
I don't think we can delegate this to HPKE. HPKE doesn't have a need for anything like Derive-Key-Pair. We do, so it's on us to define it.
Code change:
curves, they SHOULD perform the additional checks specified in Section 7 of <del> Encryption keys are derived from shared secrets by taking the first 16 bytes of H(Z), where Z is the shared secret and H is SHA-256. </del> 5.5.2. This ciphersuite uses the following primitives:

Related discussion:
text: The point NAME raises about avoiding unnecessary operations is relevant here: If we're forking the hashes like this, then we can remove the hashing part from Derive-Key-Pair, so that it's really just a definition of how you convert from an octet string to a private key (and thus its public key).
I disagree, it is not for MLS to define the and functions for all asymmetric schemes possibly used in HPKE. In MLS we should have to do only what TreeKEM does, aka, 2 KDFs, one outputing the parent's secret, one outputing the KEM encryption key, and that's it. I am willing to accept defining here but this is already odd.
If it's not our job, whose is it? It's not HPKE's job, because they don't have a need to convert byte strings to private keys. Some document needs to define this conversion in order for MLS to be implementable.
I agree we are in trouble here :) But I still wish that if we can avoid it, we should.
I agree that the KEM schemes themselves should define these things, like Curve25519 does. But it's like two lines of text. I'm not too bothered with it.
I think I'm a bit lost here. How do we go forward? Regarding the use of an abstract KDF: I was mostly just adapting the existing text, which used an abstract hash function if I recall correctly. I didn't touch the texts that got more concrete because they seemed to be a little outdated anyway. That shouldn't be a problem though.
NAME Ok, looking at this now, I am not sure what we decided in the end. I would be ok to define as you said but as it is KEM specific so there is no good solution for P256 or for whatever PQ KEM that would have a specific way of generating keys from pseudo random bytes...
NAME any suggestion here
Fixed by
Code change:
The semantics of the other CoAP header fields are left unchanged. <del> 2.4. </del> <ins> 2.3. Once a connection is established, both the client and the server MUST send a Capabilities and Settings message (CSM see csm) as its first message on the connection.  This message establishes the initial settings and capabilities for the endpoint such as maximum message size or support for block-wise transfers.  The absence of options in the CSM indicates that base values are assumed. To avoid unnecessary latency, a client MAY send additional messages without waiting to receive the server CSM; however, it is important to note that the server CSM might advertise capabilities that impact how a client is expected to communicate with the server.  For example, the server CSM could advertise a Max-Message-Size option (see max-message-size) that is smaller than the base value (1152). Clients and servers MUST treat a missing or invalid CSM as a connection error and abort the connection (see sec-abort). </ins> CoAP requests and responses are exchanged asynchronously over the TCP/TLS connection.  A CoAP client can send multiple requests without

Related discussion:
text: Re-registering interest in a resource is permitted, but entirely unnecessary.
Response from Klaus Hartke: In general, CoAP clients are not allowed to use a token while it is still in use. RFC 7641 defines an exception: a client is allowed to confirm its interest in receiving notifications for a resource by sending a request identical to the original registration request, including the token that is already in use. The above paragraph just says that this is also the case for CoAP over TCP/TLS/WebSockets, but points out that sending a Ping (which checks the health of the connection and hence of all active observations) is better than confirming the interest for all active observations individually. Response from Carsten: Yes, the text is much easier to understand in that context — in the old draft, it was clear that this talks about reregistering interest. So in the new text, we probably need to prefix a sentence like For use with UDP, RFC 7641 discusses ways to re-register interest in a resource to deal with the case that the server providing this resource might have lost the information about this interest. In CoAP over TCP, the framework of the current connection provides fate-sharing between the health of the connection and the health of the expression of interest.
After further review, I think that this note belongs in Appendix A with the other updates/guidance for Observe on reliable transports. Connection Health should limit its discussion to WebSocket specific changes - in this case, the use of the CoAP Ping Signaling message instead of WebSocket Ping/Pong.
Code change:
multiple data channels between them. An implementation of the Interactive Connectivity Establishment <del> (ICE) I-D.ietf-ice-rfc5245bis protocol.  An ICE Agent may also be an SDP Agent, but there exist ICE Agents that do not use SDP (for instance those that use Jingle XEP-0166). </del> <ins> (ICE) RFC5245 protocol.  An ICE Agent may also be an SDP Agent, but there exist ICE Agents that do not use SDP (for instance those that use Jingle XEP-0166). </ins> Communication between multiple parties, where the expectation is that an action from one party can cause a reaction by another

Related discussion:
text: EKR entered the following DISCUSS: Your citation to ICE is to 5245-bis, but at least the JSEP editor consensus was that WebRTC depended on 5245, so this needs to be resolved one way or the other.
Sean asked me to leave this one open. Personally, I'd somewhat prefer to 5245bis because it separates out the SDP machinery, but JSEP has a specific section reference (section 15.4) that has to go to either 5245 or to mmusic-ice-sip-sdp, and one could argue that we need to pull in -sip-sdp here too. I'm OK with 5245 as a reference, but will let the chairs make the call.
I no longer care about this distinction.
Code change:
5.1. <ins> When using HTTP/3 with the QUIC Datagram extension DGRAM, UDP payloads are transmitted in QUIC DATAGRAM frames.  Since those cannot be fragmented, they can only carry payloads up to a given length determined by the QUIC connection configuration and the path MTU.  If a proxy is using QUIC DATAGRAM frames and it receives a UDP payload from the target that will not fit inside a QUIC DATAGRAM frame, the proxy SHOULD NOT send the UDP payload in a DATAGRAM capsule, as that defeats the end-to-end unreliability characteristic that methods such as Datagram Packetization Layer Path MTU Discovery (DPLPMTUD) depend on RFC8899.  In this scenario, the proxy SHOULD drop the UDP payload and send an ICMP "Packet Too Big" message to the target RFC4443. 5.2. </ins> UDP proxying does not create an IP-in-IP tunnel, so the guidance in RFC6040 about transferring ECN marks between inner and outer IP headers does not apply.  There is no inner IP header in UDP proxying

Related discussion:
text: A proxy can receive a UDP packet from an origin to a client that cannot fit within a DATAGRAM frame, given either the limit set by the maximum datagram frame size, or based on the current path MTU. In this case, one solution is for the proxy to generate ICMP errors back to the sender. If that sender implements PMTU discovery, it should adjust its size.
I think adding advice here is good, though we can't mandate sending ICMP because most OSes don't let user space applications send ICMP.
Yes, we can't mandate it, but we should recommend it I think. For a full-blown production server, it should be possible.
Recommendation seems sensible. Although this does get me thinking about what the expectations of fragmentation are, we can't expect all UDP protocols to set DF.
The DATAGRAM capsule type offers one way to address this. Capsules can be arbitrarily large, because they'll be reassembled by QUIC. If it won't fit in a QUIC DATAGRAM and you don't want to drop it, it goes in a DATAGRAM capsule. Now, that might not always be desirable, because capsules don't have all the behavior that causes you to choose datagrams in the first place; a proxy that behaves that way will mess with PMTUD, and in the degenerate case cause the server to select an MTU back to the client that always gets encoded in capsules. Perhaps the client should be able to inform the server whether it prefers oversize messages to be tunneled or dropped?
Code change:
resources allocated by the caller can be released, now that the exact session configuration is known.  These "resources" can include things like extra ICE components, TURN candidates, or video decoders. <del> Provisional answers, on the other hand, do no such deallocation results; as a result, multiple dissimilar provisional answers can be received and applied during call setup. </del> <ins> Provisional answers, on the other hand, do no such deallocation; as a result, multiple dissimilar provisional answers can be received and applied during call setup. </ins> In RFC3264, the constraint at the signaling level is that only one offer can be outstanding for a given session, but at the media stack

Related discussion:
text: Provisional answers, on the other hand, do no such deallocation results as a result, multiple dissimilar provisional answers can be received and applied during call setup.
Fixe by
Code change:
registration, to allow a client to retrieve the "new-authorization" and "terms-of-service" URI <del> 6.3.1. If the client wishes to establish a secret key with the server that it can use to recover this account later (a "recovery key"), then it must perform a simple key agreement protocol as part of the new- registration transaction.  The client and server perform an ECDH exchange through the new-registration transaction (using the technique in key-agreement), and the result is the recovery key. To request a recovery key, the client includes a "recoveryKey" field in its new-registration request.  The value of this field is a JSON object. The client's ECDH public key The length of the derived secret, in octets. In the client's request, this object contains a JWK for a random ECDH public key generated by the client and the client-selected length value.  Clients need to choose length values that balance security and usability.  On the one hand, a longer secret makes it more difficult for an attacker to recover the secret when it is used for recovery (see mac-based-recovery).  On the other hand, clients may wish to make the recovery key short enough for a user to easily write it down. The server MUST validate that the elliptic curve ("crv") and length value chosen by the client are acceptable, and that it is otherwise willing to create a recovery key.  If not, then it MUST reject the new-registration request. If the server agrees to create a recovery key, then it generates its own random ECDH key pair and combines it with the client's public key as described in key-agreement above, using the label "recovery".  The derived secret value is the recovery key.  The server then returns to the client the ECDH key that it generated.  The server MUST generate a fresh key pair for every transaction. The server's ECDH public key On receiving the server's response, the client can compute the recovery key by combining the server's public key together with the private key corresponding to the public key that it sent to the server. Clients may refresh the recovery key associated with a registration by sending a POST request with a new recoveryKey object.  If the server agrees to refresh the recovery key, then it responds in the same way as to a new registration request that asks for a recovery key. </del> 6.4. Once a client has created an account with an ACME server, it is

Related discussion:
text: As discussed at the F2F meeting at IETF94, MAC-based account recovery is not adding a lot of value, and it adds significant complexity to the spec. (And nobody has implemented it.) This PR removes MAC-based recovery and the crypto that it depends on.
Seeing no complaints on the mailing list, merging.
Code change:
Further configurations are possible, including those where a WebSocket connection is established through an HTTP proxy. <del> CoAP over WebSockets is intentionally very similar to CoAP over UDP. Therefore, instead of presenting CoAP over WebSockets as a new protocol, this document specifies it as a series of deltas from RFC7252. </del> 3.1. Before CoAP requests and responses are exchanged, a WebSocket

Related discussion:
text: URL CoAP over WebSockets The following now seems unrelated: Another possible configuration is to set up a CoAP forward proxy at the WebSocket endpoint. Depending on what transports are available Figure 12: CoAP Client (UDP client) accesses sleepy CoAP Server (WebSocket client) via a CoAP proxy (UDP server/WebSocket server) s/sleepy// (There is no mention of sleepiness here.) CoAP over WebSockets is intentionally very similar to CoAP over UDP. Therefore, instead of presenting CoAP over WebSockets as a new protocol, this document specifies it as a series of deltas from [RFC7252]. Probably best to delete that paragraph -- it is true not only for WS, but also for TCP. So why only here? 3.1. Opening Handshake Hmm, the title is confusing. WS also uses the same opening handshake as 2.3. The parts that relate to both TCP/TLS and WS/S need to be factored out. 3.2. Message Format The message format shown in Figure 14 is the same as the CoAP over TCP message format (see Section 2.4) with one restriction. The Length (Len) field MUST be set to zero because the WebSockets frame already contains the length. s/restriction/change/. The CoAP over TCP message format eliminates the Version field defined in CoAP over UDP. If CoAP version negotiation is required in the future, CoAP over WebSockets can address the requirement by the definition of a new subprotocol identifier that is negotiated during the opening handshake. This paragraph is a bit weird. Maybe: As with CoAP over TCP, the message format for CoAP over Websockets eliminates the Version field defined in CoAP over UDP. If CoAP Empty messages (Code 0.00) MUST be ignored by the recipient (see also Section 4.4). Why are we saying this here and not in Section 2? Factor out. 3.3. Message Transmission Similar as with CoAP over TCP, Retransmission and deduplication of messages is provided by the WebSocket protocol. CoAP over WebSockets therefore does not make a distinction between Confirmable or Non-Confirmable messages, and does not provide Acknowledgement or Reset messages. 3.4.
Code change:
Further configurations are possible, including those where a WebSocket connection is established through an HTTP proxy. <del> CoAP over WebSockets is intentionally very similar to CoAP over UDP. Therefore, instead of presenting CoAP over WebSockets as a new protocol, this document specifies it as a series of deltas from RFC7252. </del> 3.1. Before CoAP requests and responses are exchanged, a WebSocket

Related discussion:
text: Connection Health There is no way to retransmit a request without creating a new one. Re-registering interest in a resource is permitted, but entirely unnecessary. (See the discussion we already had.) [Brian] - The reference is
Closing the Connection Does this mean, only the client must cancel the requests? Or should the server do this also? Then a clarfication may be useful.
The original - URL - was specific to Observe: ~ All updates to Observe are now captured in a single place - Appendix A. This specific case is in URL At this point, I think that Closing the Connection could simply be deleted because there are no specific changes required.
Let's say a client has sent one or more requests to a server but hasn't received any response yet, and/or is observing a resource at a server. If the client or the server closes the connection or if the connection goes down unexpectedly, then the client will never receive the responses or any further notifications. The client has to reconnect and send new requests. Neither the client nor the server needs to send anything to cancel active requests before closing the connection; when a connection closes, all active requests are canceled automatically. The client should signal that to the code waiting for the responses, e.g., by throwing an exception. The server should abort processing the requests or at least discard the responses once the requests have been processed. The server also should remove the client from the lists of observers (at latest when it tries to send the next notification and it notices that the connection is down).
URL General - It's not clear "how" mandatory the use of the CSM is. Clause 2.3 on TCP/TLS indicates that the CSM message must be sent at the start of the connection. Clause 3.1 on Websockets makes no mention of CSM messages. Clause 4.3 indicates that the CSM MUST be sent at the start of the connection also and makes no distinction between TCP/TLS and Websockets. Clause 2.3 also indicates that the connection must be aborted if the CSM is missing or invalid as the first message on the connection. Given the discussion about address changes does more information need to be provided what start of connection means?
In the , the intent of this statement is unclear: There is no way to retransmit a request without creating a new one.
Code change:
Further configurations are possible, including those where a WebSocket connection is established through an HTTP proxy. <del> CoAP over WebSockets is intentionally very similar to CoAP over UDP. Therefore, instead of presenting CoAP over WebSockets as a new protocol, this document specifies it as a series of deltas from RFC7252. </del> 3.1. Before CoAP requests and responses are exchanged, a WebSocket

Related discussion:
text: Re-registering interest in a resource is permitted, but entirely unnecessary.
Response from Klaus Hartke: In general, CoAP clients are not allowed to use a token while it is still in use. RFC 7641 defines an exception: a client is allowed to confirm its interest in receiving notifications for a resource by sending a request identical to the original registration request, including the token that is already in use. The above paragraph just says that this is also the case for CoAP over TCP/TLS/WebSockets, but points out that sending a Ping (which checks the health of the connection and hence of all active observations) is better than confirming the interest for all active observations individually. Response from Carsten: Yes, the text is much easier to understand in that context — in the old draft, it was clear that this talks about reregistering interest. So in the new text, we probably need to prefix a sentence like For use with UDP, RFC 7641 discusses ways to re-register interest in a resource to deal with the case that the server providing this resource might have lost the information about this interest. In CoAP over TCP, the framework of the current connection provides fate-sharing between the health of the connection and the health of the expression of interest.
After further review, I think that this note belongs in Appendix A with the other updates/guidance for Observe on reliable transports. Connection Health should limit its discussion to WebSocket specific changes - in this case, the use of the CoAP Ping Signaling message instead of WebSocket Ping/Pong.