jiebi/CodeConvo huggingface dataset:
Transmit the Welcome message to the other new members <ins> Group IDs SHOULD be constructed in such a way that there's an overwhelmingly low probability of honest group creators generating the same group ID, even without assistance from the Delivery Service. For example, by making the group ID a freshly generated random value of size "KDF.Nh".  The Delivery Service MAY attempt to ensure that group IDs are globally unique by rejecting the creation of new groups with a previously used ID. </ins> The recipient of a Welcome message processes it as described in joining-via-welcome-message.  If application context informs the recipient that the Welcome should reflect the creation of a new group
In both cases, the new members need information to bootstrap their local group state. <del> New members MUST verify the "signature" using the public key taken from the credential in the leaf node of the ratchet tree with leaf index "signer".  The signature covers the following structure, comprising all the fields in the GroupInfo above "signature": </del> <ins> New members MUST verify that "group_id" is unique among the groups they're currently participating in. New members also MUST verify the "signature" using the public key taken from the leaf node of the ratchet tree with leaf index "signer".  The signature covers the following structure, comprising all the fields in the GroupInfo above "signature": </ins> 13.2.3.1.
identical to the "signature_key" in the LeafNode containing this credential. <del> Each new credential that has not already been validated by the application MUST be validated against the Authentication Service. Applications SHOULD require that a client present the same set of identifiers throughout its presence in the group, even if its Credential is changed in a Commit or Update.  If an application allows clients to change identifiers over time, then each time the client presents a new credential, the application MUST verify that the set of identifiers in the credential is acceptable to the application for this client. </del> 6.3.1. <ins> The application using MLS is responsible for specifying which identifiers it finds acceptable for each member in a group.  In other words, following the model that RFC6125 describes for TLS, the application maintains a list of "reference identifiers" for the members of a group, and the credentials provide "presented identifiers".  A member of a group is authenticated by first validating that the member's credential legitimately represents some presented identifiers, and then ensuring that the reference identifiers for the member are authenticated by those presented identifiers. The parts of the system that perform these functions are collectively referred to as the Authentication Service (AS) I-D.ietf-mls- architecture.  A member's credential is said to be _validated with the AS_ when the AS verifies the credential's presented identifiers, and verifies that those identifiers match the reference identifiers for the member. Whenever a new credential is introduced in the group, it MUST be validated with the AS.  In particular, at the following events in the protocol: When a member receives a KeyPackage that it will use in an Add proposal to add a new member to the group. When a member receives a GroupInfo object that it will use to join a group, either via a Welcome or via an External Commit When a member receives an Add proposal adding a member to the group. When a member receives an Update proposal whose LeafNode has a new credential for the member. When a member receives a Commit with an UpdatePath whose LeafNode has a new credential for the committer. When an "external_senders" extension is added to the group, or an existing "external_senders" extension is updated. In cases where a member's credential is being replaced, such as Update and Commit cases above, the AS MUST also verify that the set of presented identifiers in the new credential is valid as a successor to the set of presented identifiers in the old credential, according to the application's policy. 6.3.2. </ins> MLS implementations will presumably provide applications with a way to request protocol operations with regard to other clients (e.g., removing clients).  Such functions will need to refer to the other
The client verifies the validity of a LeafNode using the following steps: <del> Verify that the credential in the LeafNode is valid according to the authentication service and the client's local policy.  These actions MUST be the same regardless of at what point in the protocol the LeafNode is being verified with the following exception: If the LeafNode is an update to another LeafNode, the authentication service MUST additionally validate that the set of identities attested by the credential in the new LeafNode is acceptable relative to the identities attested by the old credential.  For example: An Update proposal updates the sender's old LeafNode to a new one A "resync" external commit removes the joiner's old LeafNode via a Remove proposal and replaces it with a new one </del> <ins> Verify that the credential in the LeafNode is valid as described in credential-validation. </ins> Verify that the signature on the LeafNode is valid using "signature_key".
produces a single ciphertext output from AEAD encryption (aligning with RFC5116), as opposed to a separate ciphertext and tag. <del> Ciphersuites are represented with the CipherSuite type.  HPKE public keys are opaque values in a format defined by the underlying protocol (see the Cryptographic Dependencies section of the HPKE specification for more information). </del> <ins> Ciphersuites are represented with the CipherSuite type.  The ciphersuites are defined in mls-ciphersuites. </ins> <del> The signature algorithm specified in the ciphersuite is the mandatory algorithm to be used for signatures in FramedContentAuthData and the tree signatures.  It MUST be the same as the signature algorithm specified in the credentials in the leaves of the tree (including the leaf node information in KeyPackages used to add new members). </del> <ins> 5.1.1. </ins> <del> Like HPKE public keys, signature public keys are represented as opaque values in a format defined by the ciphersuite's signature scheme. </del> <ins> HPKE public keys are opaque values in a format defined by the underlying protocol (see the Cryptographic Dependencies section of the HPKE specification for more information). Signature public keys are likewise represented as opaque values in a format defined by the ciphersuite's signature scheme. </ins> For ciphersuites using Ed25519 or Ed448 signature schemes, the public key is in the format specified in RFC8032.  For ciphersuites using
is represented as an encoded UncompressedPointRepresentation struct, as defined in RFC8446. <ins> 5.1.2. The signature algorithm specified in the ciphersuite is the mandatory algorithm to be used for signatures in FramedContentAuthData and the tree signatures.  It MUST be the same as the signature algorithm specified in the credentials in the leaves of the tree (including the leaf node information in KeyPackages used to add new members). </ins> The signatures used in this document are encoded as specified in RFC8446.  In particular, ECDSA signatures are DER-encoded and EdDSA signatures are defined as the concatenation of "r" and "s" as
construction, using a distinct label.  To avoid collisions in these labels, an IANA registry is defined in mls-signature-labels. <del> The ciphersuites are defined in section mls-ciphersuites. </del> <ins> 5.1.3. As with signing, MLS includes a label and context in encryption operations to avoid confusion between ciphertexts produced for different purposes.  Encryption and decryption including this label and context are done as follows: Where EncryptContext is specified as: And its fields set to: Here, the functions "SealBase" and "OpenBase" are defined RFC9180, using the HPKE algorithms specified by the group's ciphersuite.  If MLS extensions require HPKE encryption operations, they should re-use the EncryptWithLabel construction, using a distinct label.  To avoid collisions in these labels, an IANA registry is defined in mls- public-key-encryption-labels. </ins> 5.2.
new leaf nodes), with each ciphertext being the encryption to the respective resolution node. <del> The HPKECiphertext values are computed as where "node_public_key" is the public key of the node that the path secret is being encrypted for, group_context is the provisional GroupContext object for the group, and the functions "SetupBaseS" and "Seal" are defined according to RFC9180. </del> <ins> The HPKECiphertext values are encrypted and decrypted as follows: </ins> <del> Decryption is performed in the corresponding way, using the private key of the resolution node. </del> <ins> Here "node_public_key" is the public key of the node for which the path secret is encrypted, "group_context" is the provisional GroupContext object for the group, and the "EncryptWithLabel" function is as defined in public-key-encryption. </ins> 7.7.
match the one in the Welcome message, return an error. Decrypt the "encrypted_group_secrets" value with the algorithms <del> indicated by the ciphersuite and the private key corresponding to "init_key" in the referenced KeyPackage. </del> <ins> indicated by the ciphersuite and the private key "init_key_priv" corresponding to "init_key" in the referenced KeyPackage. </ins> If a "PreSharedKeyID" is part of the GroupSecrets and the client is not in possession of the corresponding PSK, return an error.
17.6. <del> The "SignWithLabel" function defined in ciphersuites avoids the risk of confusion between signatures in different contexts.  Each context is assigned a distinct label that is incorporated into the signature. </del> <ins> The "SignWithLabel" function defined in signing avoids the risk of confusion between signatures in different contexts.  Each context is assigned a distinct label that is incorporated into the signature. </ins> This registry records the labels defined in this document, and allows additional labels to be registered in case extensions add other types of signature using the same signature keys used elsewhere in MLS.
17.7. <ins> The "EncryptWithLabel" function defined in public-key-encryption avoids the risk of confusion between ciphertexts produced for different purposes in different contexts.  Each context is assigned a distinct label that is incorporated into the signature.  This registry records the labels defined in this document, and allows additional labels to be registered in case extensions add other types of public-key encryption using the same HPKE keys used elsewhere in MLS. Template: Label: The string to be used as the "Label" parameter to "EncryptWithLabel" Recommended: Same as in Reference: The document where this credential is defined Initial contents: 17.8. </ins> The exporter function defined in exporters allows applications to derive key material from the MLS key schedule.  Like the TLS exporter RFC8446, the MLS exporter uses a label to distinguish between
that the epoch secret is confidential to the members in the current epoch. <del> For each Commit that adds one or more members to the group, there is a single corresponding Welcome message.  The Welcome message provides all the new members with the information they need to initialize </del> <ins> For each Commit that adds one or more members to the group, there are one or more corresponding Welcome messages.  Each Welcome message provides new members with the information they need to initialize </ins> their views of the key schedule and ratchet tree, so that these views align with the views held by other members of the group in this epoch.
additional information.  The format of the encoded identity is defined by the application. <del> For an X.509 credential, each entry in the chain represents a single DER-encoded X.509 certificate.  The chain is ordered such that the first entry (chain[0]) is the end-entity certificate and each subsequent certificate in the chain MUST be the issuer of the previous certificate.  The public key encoded in the "subjectPublicKeyInfo" of the end-entity certificate MUST be identical to the "signature_key" in the LeafNode containing this credential. </del> <ins> For an X.509 credential, each entry in the "certificates" field represents a single DER-encoded X.509 certificate.  The chain is ordered such that the first entry (chain[0]) is the end-entity certificate.  The public key encoded in the "subjectPublicKeyInfo" of the end-entity certificate MUST be identical to the "signature_key" in the LeafNode containing this credential.  A chain MAY omit any non-leaf certificates that supported peers are known to already possess. </ins> 5.3.1.
on multiple already existing media types. Applications using the application/multipart-core Content-Format <del> define the internal structure of the application/multipart-core representation. </del> <ins> define the semantics as well as the internal structure of the application/multipart-core representation according to the syntax described by the CDDL in mct-cddl. </ins> For example, one way to structure the sub-types specific to an application/multipart-core container is to always include them at the
requires negotiation between the two endpoints using a new transport parameter, as specified in nego. <del> This proposal supports the negotiation of either the use of one packet number space for all paths or the use of separate packet number spaces per path.  While both approaches are supported by the specification in this version of the document, the intention for the final publication of a multipath extension for QUIC is to choose one option in order to avoid incompatibility.  More evaluation and implementation experience is needed to select one approach before final publication.  Some discussion about pros and cons can be found here: https://github.com/mirjak/draft-lmbdhk-quic- multipath/blob/master/presentations/PacketNumberSpace_s.pdf As currently defined in this version of the draft the use of multiple packet number spaces requires the use of connection IDs is both directions.  Today's deployments often only use destination connection ID when sending packets from the client to the server as this addresses the most important use cases for migration, like NAT rebinding or mobility events.  Further discussion and work is required to evaluate if the use of multiple packet number spaces could be supported as well when the connection ID is only present in one direction. </del> <ins> This extension uses multiple packet number spaces.  When multipath is negotiated, each destination connection ID is linked to a separate packet number space.  Using multiple packet number spaces enables direct use of the loss recovery and congestion control mechanisms defined in QUIC-RECOVERY. Some deployments of QUIC use zero-length connection IDs.  When a node selects to use zero-length connection IDs, it is not possible to use different connection IDs for distinguishing packets sent to that node over different paths.  This extension also specifies a way to use zero-length CID by using the same packet number space on all paths. However, when using the same packet number space on multiple paths, out of order delivery is likely.  This causes inflation of the number of acknowledgement ranges and therefore of the the size of ACK frames.  Senders that accept to use a single number space on multiple paths when sending to a node using zero-length CID need to take special care to minimize the impact of multipath delivery on loss detection, congestion control, and ECN handling.  This proposal specifies algorithms for controlling the size of acknowledgement packets and ECN handling in Section using-zero-length and ecn- handling. </ins> This proposal does not cover address discovery and management. Addresses and the actual decision process to setup or tear down paths
param_value_definition : If for any one of the endpoints the parameter is absent or set to 0, <del> or if the two endpoints select incompatible values, one proposing 0x1 and the other proposing 0x2, the endpoints MUST fallback to QUIC- TRANSPORT with single path and MUST NOT use any frame or mechanism defined in this document. If an endpoint proposes the value 0x3, the value proposed by the other is accepted.  If both endpoints propose the value 0x3, the value 0x2 is negotiated. </del> <ins> the endpoints MUST fallback to QUIC-TRANSPORT with single active path and MUST NOT use any frame or mechanism defined in this document. </ins> If endpoint receives unexpected value for the transport parameter "enable_multipath", it MUST treat this as a connection error of type
7.1.2. <ins> When sending to a zero-length CID receiver, senders may receive acknowledgements that combine packet numbers received over multiple paths.  However, even if one packet number space is used on multiple path the sender MUST maintain separate congestion control state for each path.  Therefore, senders MUST be able to infer the sending path from the acknowledged packet numbers, for example by remembering which packet was sent on what path.  The senders MUST use that information to perform congestion control on the relevant paths, and to correctly estimate the transmission delays on each path.  (See ack-delay-and-zero-length-cid-considerations for specific considerations about using the ACK Delay field of ACK frames, and ecn-handling for issues on using ECN marks.) Loss detection as specified in QUIC-RECOVERY uses algorithms based on timers and on sequence numbers.  When packets are sent over multiple paths, loss detection must be adapted to allow for different RTTs on different paths.  When sending to zero-length CID receivers, packets sent on different paths may be received out of order.  Therefore senders cannot directly use the packet sequence numbers to compute the Packet Thresholds defined in Section 6.1.1 of QUIC-RECOVERY. Relying only on Time Thresholds produces correct results, but is somewhat suboptimal.  Some implementations have been getting good results by not just remembering the path over which a packet was sent, but also maintaining an order list of packets sent on each path.  That ordered list can then be used to compute acknowledgement gaps per path in Packet Threshold tests. 7.1.3. </ins> The ACK Delay field of the ACK frame is relative to the largest acknowledged packet number (see Section 13.2.5 of QUIC-TRANSPORT). When using paths with different transmission delays, the reported
latency.  To collect ACK delays on all the paths, hosts should rely on time stamps as described in QUIC-Timestamp. <ins> 7.1.4. ECN feedback in QUIC is provided based on counters in the ACK frame (see Section 19.3.2. of QUIC-TRANSPORT).  That means if an ACK frame acknowledges multiple packets, the ECN feedback cannot be accounted to a specific packet. There are separate counters for each packet number space.  However, sending to zero-length CID receivers, the same number space is used for multiple paths.  Respectively, if an ACK frames acknowledges multiple packets from different paths, the ECN feedback cannot unambiguously be assigned to a path. If the sender marks its packets with the ECN capable flags, the network will expect standard reactions to ECN marks, such as slowing down transmission on the sending path.  If zero-length CID is used, the sending path is however ambiguous.  Therefore, the sender MUST treat a CE marking as a congestion signal on all sending paths that have been by a packet that was acknowledged in the ACK frame signaling the CE counter increase. A host that is sending over multiple paths to a zero-length CID receiver MAY disable ECN marking and send all subsequent packets as Not-ECN capable. 7.1.5. Hosts that are designed to support multipath using multiple number spaces MAY adopt a conservative posture after negotiating multipath support with a peer using zero-length CID.  The simplest posture is to only send data on one path at a time, while accepting packets on all acceptable paths.  In that case: the attribution of packets to path discussed in zero-length-cid- loss-and-congestion are easy to solve because packets are sent on a single path, the ACK Delays are correct, the vast majority of ECN marks relate to the current sending path. Of course, the hosts will only take limited advantage from the multipath capability in these scenarios.  Support for "make before break" migrations will improve, but load sharing between multiple paths will not work. </ins> 7.2. <del> If the multipath option is enabled with a value of 2, each path has its own packet number space for transmitting 1-RTT packets and a new ACK frame format is used as specified in ack-mp-frame.  Compared to the QUIC version 1 ACK frame, the ACK_MP frames additionally contains a Packet Number Space Identifier (PN Space ID).  The PN Space ID used to distinguish packet number spaces for different paths and is simply </del> <ins> If packets contain a non-zero CID, each path has its own packet number space for transmitting 1-RTT packets and a new ACK frame format is used as specified in ack-mp-frame.  Compared to the QUIC version 1 ACK frame, the ACK_MP frames additionally contains a Packet Number Space Identifier (PN Space ID).  The PN Space ID used to distinguish packet number spaces for different paths and is simply </ins> derived from the sequence number of Destination Connection ID. Therefore, the packet number space for 1-RTT packets can be identified based on the Destination Connection ID in each packets.
When the multipath option is negotiated, clients that want to use an additional path MUST first initiate the Address Validation procedure <del> with PATH_CHALLENGE and PATH_RESPONSE frames described in Section 8 of QUIC-TRANSPORT.  After receiving packets from the client on the new paths, the servers MAY in turn attempt to validate these paths using the same mechanisms. </del> <ins> with PATH_CHALLENGE and PATH_RESPONSE frames described in Section 8.2 of QUIC-TRANSPORT.  After receiving packets from the client on a new path, if the server decides to use the new path, the server MUST perform path validation Section 8.2 of QUIC-TRANSPORT unless it has previously validated that address. </ins> If validation succeed, the client can send non-probing, 1-RTT packets on the new paths.  In contrast with the specification in Section 9 of
provides several general-purpose packet schedulers depending on the application goals. <ins> Note that the receiver could use a different scheduling strategy to send ACK(_MP) frames.  The recommended default behaviour consists in sending ACK(_MP) frames on the path they acknowledge packets.  Other scheduling strategies, such as sending ACK(_MP) frames on the lowest latency path, might be considered, but they could impact the sender with side effects on, e.g., the RTT estimation or the congestion control scheme.  When adopting such asymetrical acknowledgment scheduling, the receiver should at least ensure that the sender negotiated one-way delay calculation mechanism (e.g., QUIC- Timestamp). </ins> 8. Simultaneous use of multiple paths enables different retransmission
If endpoint receives an unexpected value for the transport parameter "enable_multipath", it MUST treat this as a connection error of type <del> MP_CONNECTION_ERROR and close the connection. </del> <ins> TRANSPORT_PARAMETER_ERROR (specified in Section 20.1 of QUIC- TRANSPORT) and close the connection. </ins> This extension does not change the definition of any transport parameter defined in Section 18.2. of QUIC-TRANSPORT.