jiebi/CodeConvo huggingface dataset:
12.3. A new group can be formed from a subset of an existing group's <del> members, using the same parameters as the old group.  The creator of the group indicates this situation by including a PreSharedKey of type "resumption" with usage "branch" in the Welcome message that creates the branched subgroup. </del> <ins> members, using the same parameters as the old group. A member can create a sub-group by performing the following steps: Determine a subset of existing members that should be a part of the sub-group. Create a new tree for the sub-group by fetching a new KeyPackage for each existing member that should be included in the sub-group. Create a Welcome message that includes a PreSharedKey of type "resumption" with usage "branch". </ins> A client receiving a Welcome including a PreSharedKey of type "resumption" with usage "branch" MUST verify that the new group
The "version" and "ciphersuite" values in the Welcome MUST be the same as those used by the old group. <del> Each LeafNode in the new group's tree MUST be a leaf in the old group's tree at the epoch indicated in the PreSharedKey. </del> <ins> Each LeafNode in a new subgroup MUST match some LeafNode in the original group.  In this context, a pair of LeafNodes is said to "match" if the identifiers presented by their respective credentials are considered equivalent by the application. </ins> In addition, to avoid key re-use, the "psk_nonce" included in the "PreSharedKeyID" object MUST be a randomly sampled nonce of length
cryptographic state of the group, this section defines a scheme for generating a hash value (called the "tree hash") that represents the contents of the group's ratchet tree and the members' leaf nodes. <del> The tree hash of a tree is the tree hash of its root node, which we define recursively, starting with the leaves. The tree hash of a leaf node is the hash of leaf's "LeafNodeHashInput" object which might include a "LeafNode" object depending on whether or not it is blank. Now the tree hash of any non-leaf node is recursively defined to be the hash of its "ParentNodeHashInput".  This includes an optional "ParentNode" object depending on whether the node is blank or not. The "left_hash" and "right_hash" fields hold the tree hashes of the node's left and right children, respectively. </del> <ins> The tree hash of an individual node is the hash of the node's "TreeHashInput" object, which may contain either a "LeafNodeHashInput" or a "ParentNodeHashInput" depending on the type of node.  "LeafNodeHashInput" objects contain the "leaf_index" and the "LeafNode" (if any).  "ParentNodeHashInput" objects contain the "ParentNode" (if any) and the tree hash of the node's left and right children. The tree hash of an entire tree corresponds to the tree hash of the root node, which is computed recursively by starting at the leaf nodes and building up. </ins> 8.8.
input to the key schedule, the Commit and GroupSecrets objects MUST indicate the same set of PSKs, in the same order. <ins> Each time a client injects a PSK into a group, the "psk_nonce" of its PreSharedKeyID MUST be set to a fresh random value of length "KDF.Nh", where "KDF" is the KDF for the ciphersuite of the group into which the PSK is being injected.  This ensures that even when a PSK is used multiple times, the value used as an input into the key schedule is different each time. </ins> On receiving a Commit with a "PreSharedKey" proposal or a GroupSecrets object with the "psks" field set, the receiving Client includes them in the key schedule in the order listed in the Commit,
Welcome message MUST be the same as the corresponding fields in the ReInit proposal. <del> The "epoch" in the Welcome message MUST be 1 </del> The Welcome MUST specify a PreSharedKey of type "resumption" with usage "reinit".  The "group_id" must match the old group, and the "epoch" must indicate the epoch after the Commit covering the ReInit. <del> The "psk_nonce" included in the "PreSharedKeyID" of the resumption PSK MUST be a randomly sampled nonce of length "KDF.Nh", for the KDF defined by the new group's ciphersuite. </del> Note that these three steps may be done by the same group member or different members.  For example, if a group member sends a commit with an inline ReInit proposal (steps 1 and 2), but then goes
The "version" and "ciphersuite" values in the Welcome MUST be the same as those used by the old group. <ins> The "epoch" in the Welcome message MUST be 1. </ins> Each LeafNode in a new subgroup MUST match some LeafNode in the original group.  In this context, a pair of LeafNodes is said to "match" if the identifiers presented by their respective credentials are considered equivalent by the application. <del> In addition, to avoid key re-use, the "psk_nonce" included in the "PreSharedKeyID" object MUST be a randomly sampled nonce of length "KDF.Nh". </del> Resumption PSKs with usage "branch" MUST NOT be used in other contexts.  A PreSharedKey proposal with type "resumption" and usage "branch" MUST be considered invalid.
5.3.2. <ins> In some credential schemes, a valid credential can "expire", or become invalid after a certain point in time.  For example, each X.509 certificate has a "notAfter" field, expressing a time after which the certificate is not valid. Expired credentials can cause operational problems in light of the validation requirements of credential-validation.  Applications can apply some operational practices and adaptations to Authentication Service policies to moderate these impacts. In general, to avoid operational problems such as new joiners rejecting expired credentials in a group, applications that use such credentials should ensure to the extent practical that all of the credentials in use in a group are valid at all times. If a member finds that its credential has expired (or will soon), it should issue an Update or Commit that replaces it with a valid credential.  For this reason, members SHOULD accept Update proposals and Commits issued by members with expired credentials, if the credential in the Update or Commit is valid. Similarly, when a client is processing messages sent some time in the past (e.g., syncing up with a group after being offline), the client SHOULD accept signatures from members with expired credentials, since the credential may have been valid at the time the message was sent. If a member finds that another member's credential has expired, they may issue a Remove that removes that member.  For example, an application could require a member preparing to issue a Commit to check the tree for expired credentials and include Remove proposals for those members in its Commit.  In situations where the group tree is known to the DS, the DS could also monitor the tree for expired credentials and issue external Remove proposals. Some credential schemes also allow credentials to be revoked. Revocation is similar to expiry, in that a previously valid credential becomes invalid.  As such, most of the considerations above also apply to revoked credentials.  However, applications may want to treat revoked credentials differently, e.g., removing members with revoked credentials while allowing members with expired credentials time to update. 5.3.3. </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
A signing key pair used to authenticate the sender of a message. <ins> A message that proposes a change to the group, e.g., adding or removing a member. A message that implements the changes to the group proposed in a set of Proposals. An MLS protocol message that is signed by its sender and authenticated as coming from a member of the group in a particular epoch, but not encrypted. An MLS protocol message that is both signed by its sender, authenticated as coming from a member of the group in a particular epoch, and encrypted so that it is confidential to the members of the group in that epoch. </ins> A PublicMessage or PrivateMessage carrying an MLS Proposal or Commit object, as opposed to application data.
with an algorithm such as HMAC or an AEAD algorithm. The PublicMessage and PrivateMessage formats are defined in message- <del> framing; they represent integrity-protected and confidentiality- protected messages, respectively.  Security notions such as forward secrecy and post-compromise security are defined in security- considerations. </del> <ins> framing.  Security notions such as forward secrecy and post- compromise security are defined in security-considerations. </ins> 2.1.
12.2. A group member creating a commit and a group member processing a <del> commit MUST verify that the list of committed proposals is valid </del> <ins> Commit MUST verify that the list of committed proposals is valid </ins> using one of the following procedures, depending on whether the <del> commit is external or not. </del> <ins> commit is external or not.  If the list of proposals is invalid, then the Commit message MUST be rejected as invalid. </ins> For a regular, i.e. not external, commit the list is invalid if any of the following occurs:
For example, assuming the IV value is "6b26114b9cba2b63a9e8dd4f", the connection ID sequence number is "3", and the packet number is <del> "aead", the nonce will be set to "6b2611489cba2b63a9a873e2". </del> <ins> "aead", the nonce will be set to "6b2611489cba2b63a9e873e2". </ins> 6.3.2.
Path Identifier (Path ID): An identifier that is used to identify a path in a QUIC connection at an endpoint.  Path Identifier is <del> used in multipath control frames (etc.  PATH_ABANDON frame) to identify a path.  The Path ID is defined as the sequence number of the destination Connection ID used for sending packets on that particular path. Packet Number Space Identifier (PNS ID): An identifier that is used to distinguish packet number spaces for different paths.  It is used in 1-RTT packets and ACK_MP frames.  Each node maintains a list of "Received Packets" for each of the CID that it provided to the peer, which is used for acknowledging packets received with that CID. The difference between Path Identifier and Packet Number Space Identifier, is that the Path Identifier is used in multipath control frames to identify a path, and the Packet Number Space Identifier is used in 1-RTT packets and ACK_MP frames to distinguish packet number spaces for different paths.  Both identifiers have the same value, which is the sequence number of the connection ID, when a new path is established. The initial path that is used during the handshake (and multipath negotiation) has the path ID 0 and therefore all 0-RTT packets are also tracked and processed with the path ID 0.  For 1-RTT packets, the path ID is the sequence number of the Destination Connection ID present in the packet header, as defined in Section 5.1.1 of QUIC- TRANSPORT. </del> <ins> used in multipath control frames (e.g., PATH_ABANDON frame) to identify a path.  The initial path that is used during the handshake (and multipath negotiation) has the path ID 0 and therefore all 0-RTT packets are also tracked and processed with the path ID 0.  For 1-RTT packets, the path ID is the sequence number of the Destination Connection ID present in the packet header, as defined in Section 5.1.1 of QUIC-TRANSPORT that is used for sending packets on that particular path. </ins> 2.
Associated Destination Connection ID: The Connection ID used to send packets over the path. <del> If multiple packet number spaces are used over the connection, hosts MUST also track the following information. </del> <ins> In Active state, hosts MUST also track the following information: </ins> <del> Path Packet Number Space: The endpoint maintains a separate packet number for sending and receiving packets over this path.  Packet number considerations described in QUIC-TRANSPORT apply within the given path. </del> <ins> Path ID: The endpoint maintains a separate packet number space for sending and receiving packets over this path which is identified by the path ID.  Packet number considerations as described in Section 12.3 of QUIC-TRANSPORT apply within the given path. </ins> In the "Active" state, hosts MUST also track the following information.
The ACK_MP frame, as specified in ack-mp-frame, is used to acknowledge 1-RTT packets.  Compared to the QUIC version 1 ACK frame, <del> 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 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 packet. </del> <ins> the ACK_MP frame additionally contains a Path ID.  The Path ID is used to distinguish packet number spaces for different paths and is simply derived from the sequence number of Destination Connection ID. Therefore, the Path ID for 1-RTT packets can be identified based on the Destination Connection ID in each packet. </ins> Acknowledgements of Initial and Handshake packets MUST be carried using ACK frames, as specified in QUIC-TRANSPORT.  The ACK frames, as
Section 5.3 of QUIC-TLS specifies AEAD usage, and in particular the use of a nonce, N, formed by combining the packet protection IV with <del> the packet number.  If multiple packet number spaces are used, the </del> <ins> the packet number.  When multiple packet number spaces are used, the </ins> packet number alone would not guarantee the uniqueness of the nonce. In order to guarantee the uniqueness of the nonce, the nonce N is calculated by combining the packet protection IV with the packet number and with the path identifier. <del> The path ID for 1-RTT packets is the sequence number of the </del> <ins> The Path ID for 1-RTT packets is the sequence number of the </ins> Connection ID as specified in QUIC-TRANSPORT.  Section 19 of QUIC- TRANSPORT encodes the Connection ID Sequence Number as a variable- length integer, allowing values up to 2^62-1; in this specification,
nonce. For example, assuming the IV value is "6b26114b9cba2b63a9e8dd4f", the <del> connection ID sequence number is "3", and the packet number is </del> <ins> Connection ID Sequence Number is "3", and the packet number is </ins> "aead", the nonce will be set to "6b2611489cba2b63a9e873e2". 5.3.
The ACK_MP frame (types TBD-00 and TBD-01; experiments use 0xbaba00..0xbaba01) is an extension of the ACK frame defined by QUIC- TRANSPORT.  It is used to acknowledge packets that were sent on <del> different paths when using multiple packet number spaces.  If the frame type is TBD-01, ACK_MP frames also contain the sum of QUIC packets with associated ECN marks received on the connection up to this point. </del> <ins> different paths using multiple packet number spaces.  If the frame type is TBD-01, ACK_MP frames also contain the sum of QUIC packets with associated ECN marks received on the connection up to this point. </ins> ACK_MP frame is formatted as shown in fig-ack-mp-format. Compared to the ACK frame specified in QUIC-TRANSPORT, the following field is added. <del> The identifier of the path packet number space of the 1-RTT packets which are acknowledged by the ACK_MP frame. If an endpoint receives an ACK_MP frame with a packet number space ID which was never issued by endpoints (i.e., with a sequence number larger than the largest one advertised), it MUST treat this as a connection error of type MP_PROTOCOL_VIOLATION and close the connection.  If an endpoint receives an ACK_MP frame with a packet number space ID which is no more active (e.g., retired by a RETIRE_CONNECTION_ID frame or belonging to closed paths), it MUST ignore the ACK_MP frame without causing a connection error. </del> <ins> The identifier of the path to identify the packet number space of the 1-RTT packets which are acknowledged by the ACK_MP frame. If an endpoint receives an ACK_MP frame with a Path ID which was never issued by endpoints (i.e., with a sequence number larger than the largest one advertised), it MUST treat this as a connection error of type MP_PROTOCOL_VIOLATION and close the connection.  If an endpoint receives an ACK_MP frame with a Path ID which is no more active (e.g., retired by a RETIRE_CONNECTION_ID frame or belonging to closed paths), it MUST ignore the ACK_MP frame without causing a connection error. </ins> 9.
The transmission of QUIC packets on a regular QUIC connection is regulated by the arrival of data from the application and the <del> congestion control scheme.  QUIC packets can only be sent when the congestion window of at least one path is open. Multipath QUIC implementations also need to include a packet </del> <ins> congestion control scheme.  QUIC packets that increase the number of bytes in flight can only be sent when the congestion window allows it.  Multipath QUIC implementations also need to include a packet </ins> scheduler that decides, among the paths whose congestion window is <del> open, the path over which the next QUIC packet will be sent.  Many factors can influence the definition of these algorithms and their precise definition is outside the scope of this document.  Various packet schedulers have been proposed and implemented, notably for Multipath TCP.  A companion draft I-D.bonaventure-iccrg-schedulers provides several general-purpose packet schedulers depending on the application goals. 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). </del> <ins> open, the path over which the next QUIC packet will be sent.  Most frames, including control frames (PATH_CHALLENGE and PATH_RESPONSE being the notable exceptions), can be sent and received on any active path.  The scheduling is a local decision, based on the preferences of the application and the implementation. Note that this implies that an endpoint may send and receive ACK_MP frames on a path different from the one that carried the acknowledged packets.  A reasonable default consists in sending ACK_MP frames on the path they acknowledge packets, but the receiver must not assume its peer will do so. </ins> 7.5.
7.2.1. <del> Packet protection for QUIC version 1 is specified is Section 5 of </del> <ins> Packet protection for QUIC version 1 is specified in Section 5 of </ins> QUIC-TLS.  The general principles of packet protection are not changed for QUIC Multipath.  No changes are needed for setting packet protection keys, initial secrets, header protection, use of 0-RTT
idle timeout".  When only one path is available, servers MUST follow the specifications in QUIC-TRANSPORT. <del> When more than one path is available, servers shall monitor the arrival of non-probing packets on the available paths.  Servers SHOULD stop sending traffic on paths through where no non-probing packet was received in the last 3 path RTTs, but MAY ignore that rule if it would disqualify all available paths.  To avoid idle timeout of a path, endpoints can send ack-eliciting packets such as packets containing PING frames Section 19.2 of QUIC-TRANSPORT on that path to keep it alive.  Sending periodic PING frames also helps prevent middlebox timeout, as discussed in Section 10.1.2 of QUIC-TRANSPORT. </del> <ins> When more than one path is available, hosts shall monitor the arrival of non-probing packets and the acknowledgements for the packets sent over each path.  Hosts SHOULD stop sending traffic on a path if for at least max_idle_timeout milliseconds (a) no non-probing packet was received or (b) no non-probing packet sent over this path was acknowledged, but MAY ignore that rule if it would disqualify all available paths.  To avoid idle timeout of a path, endpoints can send ack-eliciting packets such as packets containing PING frames (Section 19.2 of QUIC-TRANSPORT) on that path to keep it alive. Sending periodic PING frames also helps prevent middlebox timeout, as discussed in Section 10.1.2 of QUIC-TRANSPORT. </ins> Server MAY release the resource associated with paths for which no non-probing packet was received for a sufficiently long path-idle
request of the oblivious request resource that includes the same content.  When it receives a response, it sends a response to the client that includes the content of the response from the oblivious <del> request resource.  When generating a request, the proxy MUST follow the forwarding rules in Section 7.6 of HTTP. </del> <ins> request resource. When forwarding a request, the proxy MUST follow the forwarding rules in Section 7.6 of HTTP.  A generic HTTP intermediary implementation is suitable for the purposes of serving an oblivious proxy resource, but additional care is needed to ensure that client privacy is maintained. Firstly, a generic implementation will forward unknown fields.  For oblivious HTTP, a proxy SHOULD NOT forward unknown fields.  Though clients are not expected to include fields that might contain identifying information, removing unknown fields removes this privacy risk. Secondly, generic implementations are often configured to augment requests with information about the client, such as the Via field or the Forwarded field FORWARDED.  A proxy MUST NOT add information about the client identity when forwarding requests. </ins> A proxy can also generate responses, though it assumed to not be able to examine the content of a request (other than to observe the choice of key identifier, KDF, and AEAD), so it is also assumed that it cannot generate an encapsulated response. <del> A proxy MUST NOT add information about the client identity when forwarding requests.  This includes the Via field, the Forwarded field FORWARDED, and any similar information.  A client does not depend on the proxy using an authenticated and encrypted connection to the oblivious request resource, only that information about the client not be attached to forwarded requests. </del> 7.2.1. As there are privacy benefits from having a large rate of requests
7.3. <ins> The Oblivious Gateway Resource can be operated by a different entity than the Target Resource.  However, this means that the client needs to trust the Oblivious Gateway Resource not to modify requests or responses.  This analysis concerns itself with a deployment scenario where a single server provides both the Oblivious Gateway Resource and Target Resource. </ins> A server that operates both Oblivious Gateway and Target Resources is responsible for removing request encryption, generating a response to the Encapsulated Request, and encrypting the response.
the unprotected requests and responses, plus protections for traffic analysis; see ta. <ins> Nonsecure requests - such those with the "http" scheme as opposed to the "https" scheme - SHOULD NOT be used if the Oblivious Gateway and Target Resources are operated by different entities as that would expose both requests and response to modification or inspection by a network attacker. 7.4. </ins> An Oblivious Gateway Resource needs to have a plan for replacing keys.  This might include regular replacement of keys, which can be assigned new key identifiers.  If an Oblivious Gateway Resource
within the HPKE context created using the "message/bhttp request" label; see repurposing-the-encapsulation-format. <ins> 7.5. </ins> A server is responsible for either rejecting replayed requests or ensuring that the effect of replays does not adversely affect clients <del> or resources; see replay. 7.4. </del> <ins> or resources. </ins> Encrypted requests can be copied and replayed by the Oblivious Relay resource.  The threat model for Oblivious HTTP allows the possibility