A member of a group authenticates the identities of other participants by means of credentials issued by some authentication system, like a PKI.  Each type of credential MUST express the <del> following data: </del> <ins> following data in the context of the group it is used with: </ins> <del> The public key of a signature key pair </del> <ins> The public key of a signature key pair matching the SignatureScheme specified by the CipherSuite of the group </ins> <del> The identity of the holder of the private key The signature scheme that the holder will use to sign MLS messages </del> <ins> The identity of the holder of the private keys </ins> Credentials MAY also include information that allows a relying party to verify the identity / signing key binding. <ins> Additionally, Credentials SHOULD specify the signature scheme corresponding to each contained public key. </ins> A BasicCredential is a raw, unauthenticated assertion of an identity/ key binding.  The format of the key in the "public_key" field is defined by the relevant ciphersuite: the group ciphersuite for a


A KeyPackage object specifies a ciphersuite that the client supports, as well as providing a public key that others can use for key <del> agreement.  The client's identity key can be updated throughout the </del> <ins> agreement.  The client's signature key can be updated throughout the </ins> lifetime of the group by sending a new KeyPackage with a new <del> identity; the new identity MUST be validated by the authentication service. </del> <ins> signature key; the new signature key MUST be validated by the authentication service. </ins> When used as InitKeys, KeyPackages are intended to be used only once and SHOULD NOT be reused except in case of last resort.  (See


The value for hpke_init_key MUST be a public key for the asymmetric encryption scheme defined by cipher_suite.  The whole structure is <del> signed using the client's identity key.  A KeyPackage object with an </del> <ins> signed using the client's signature key.  A KeyPackage object with an </ins> invalid signature field MUST be considered malformed.  The input to the signature computation comprises all of the fields except for the signature field.


creator, because they are derived from an authenticated key exchange protocol.  Subsequent leaf keys are known only by their owner. <del> Note that the long-term identity keys used by the protocol MUST be </del> <ins> Note that the long-term signature keys used by the protocol MUST be </ins> distributed by an "honest" authentication service for clients to authenticate their legitimate peers.


The second form considers authentication with respect to the sender, meaning the group members can verify that a message originated from a particular member of the group.  This property is provided by digital <del> signatures on the messages under identity keys. </del> <ins> signatures on the messages under signature keys. </ins> 14.3.


reveal previous message or root keys.  Post-compromise security is provided by Commit operations, in which a new root key is generated from the latest ratcheting tree.  If the adversary cannot derive the <del> updated root key after an Commit operation, it cannot compute any </del> <ins> updated root key after a Commit operation, it cannot compute any </ins> derived secrets. In the case where the client could have been compromised (device


A signed object describing a client's identity and capabilities, and including a hybrid public-key encryption (HPKE I-D.irtf-cfrg- <del> hpke ) public key that can be used to encrypt to that client. </del> <ins> hpke) public key that can be used to encrypt to that client. </ins> A key package that is prepublished by a client, which other clients can use to introduce the client to a new group.


A signature algorithm <del> The HPKE parameters are used to instantiate HPKE I-D.irtf-cfrg-hpke for the purpose of public-key encryption.  The "DeriveKeyPair" function associated to the KEM for the ciphersuite maps octet strings to HPKE key pairs. </del> <ins> MLS uses draft-07 of HPKE I-D.irtf-cfrg-hpke for public-key encryption.  The "DeriveKeyPair" function associated to the KEM for the ciphersuite maps octet strings to HPKE key pairs. </ins> Ciphersuites are represented with the CipherSuite type.  HPKE public keys are opaque values in a format defined by the underlying protocol


Name: The name of the ciphersuite <del> Recommended: Whether support for this extension is recommended by the IETF MLS WG.  Valid values are "Y" and "N".  The "Recommended" column is assigned a value of "N" unless explicitly requested, and adding a value with a "Recommended" value of "Y" requires Standards Action RFC8126.  IESG Approval is REQUIRED for a Y->N transition. </del> <ins> Recommended: Whether support for this ciphersuite is recommended by the IETF MLS WG.  Valid values are "Y" and "N".  The "Recommended" column is assigned a value of "N" unless explicitly requested, and adding a value with a "Recommended" value of "Y" requires Standards Action RFC8126.  IESG Approval is REQUIRED for a Y->N transition. </ins> Reference: The document where this ciphersuite is defined


16.3. This registry lists identifiers for types of credentials that can be <del> used for authentication in the MLS protocol.  The extension type field is two bytes wide, so valid extension type values are in the </del> <ins> used for authentication in the MLS protocol.  The credential type field is two bytes wide, so valid credential type values are in the </ins> range 0x0000 to 0xffff. Template:


Name: The name of the credential type <del> Recommended: Whether support for this extension is recommended by </del> <ins> Recommended: Whether support for this credential is recommended by </ins> the IETF MLS WG.  Valid values are "Y" and "N".  The "Recommended" column is assigned a value of "N" unless explicitly requested, and adding a value with a "Recommended" value of "Y" requires Standards Action RFC8126.  IESG Approval is REQUIRED for a Y->N transition. <del> Reference: The document where this extension is defined </del> <ins> Reference: The document where this credential is defined </ins> Initial contents:


in the "PreSharedKeyID" object.  Specifically, "psk_secret" is computed as follows: <del> The "index" field in "PSKLabel" corresponds to the index of the PSK in the "psk" array, while the "count" field contains the total number of PSKs. </del> <ins> Here "0" represents the all-zero vector of length KDF.Nh.  The "index" field in "PSKLabel" corresponds to the index of the PSK in the "psk" array, while the "count" field contains the total number of PSKs.  In other words, the PSKs are chained together with KDF.Extract invocations, as follows: In particular, if there are no PreSharedKey proposals in a given Commit, then the resulting "psk_secret" is "psk_secret_[0]", the all- zero vector. </ins> 8.3.


In this case, the new ratchet tree is the same as the provisional ratchet tree. <del> If one or more PreSharedKey proposals are part of the commit, derive the "psk_secret" as specified in pre-shared-keys, where the </del> <ins> Derive the "psk_secret" as specified in pre-shared-keys, where the </ins> order of PSKs in the derivation corresponds to the order of <del> PreSharedKey proposals in the "proposals" vector.  Otherwise, set "psk_secret" to a zero-length octet string. </del> <ins> PreSharedKey proposals in the "proposals" vector. </ins> Construct an MLSPlaintext object containing the Commit object. Sign the MLSPlaintext using the old GroupContext as context.


Update the confirmed and interim transcript hashes using the new Commit, and generate the new GroupContext. <del> If the "proposals" vector contains any PreSharedKey proposals, derive the "psk_secret" as specified in pre-shared-keys, where the </del> <ins> Derive the "psk_secret" as specified in pre-shared-keys, where the </ins> order of PSKs in the derivation corresponds to the order of <del> PreSharedKey proposals in the "proposals" vector.  Otherwise, set "psk_secret" to 0. </del> <ins> PreSharedKey proposals in the "proposals" vector. </ins> Use the "init_secret" from the previous epoch, the "commit_secret" and the "psk_secret" as defined in the previous steps, and the new


Each leaf is given an _index_ (or _leaf index_), starting at "0" from the left to "n-1" at the right. <ins> Finally, a node in the tree may also be _blank_, indicating that no value is present at that node (i.e. no keying material).  This is often the case when a leaf was recently removed from the tree. </ins> There are multiple ways that an implementation might represent a ratchet tree in memory.  For example, left-balanced binary trees can be represented as an array of nodes, with node relationships computed


The conditions under which each of these values must or must not be present are laid out in views. <del> A node in the tree may also be _blank_, indicating that no value is present at that node.  The _resolution_ of a node is an ordered list of non-blank nodes that collectively cover all non-blank descendants of the node.  The resolution of a non-blank node with no unmerged leaves is just the node itself.  More generally, the resolution of a node is effectively a depth-first, left-first enumeration of the nearest non-blank nodes below the node: </del> <ins> The _resolution_ of a node is an ordered list of non-blank nodes that collectively cover all non-blank descendants of the node.  The resolution of a non-blank node with no unmerged leaves is just the node itself.  More generally, the resolution of a node is effectively a depth-first, left-first enumeration of the nearest non-blank nodes below the node: </ins> The resolution of a non-blank node comprises the node itself, followed by its list of unmerged leaves, if any


"lazy" version of this operation, where only the leaf changes and intermediate nodes are blanked out. <del> The "path" field of a Commit message MUST be populated if the Commit covers at least one Update or Remove proposal.  The "path" field MUST also be populated if the Commit covers no proposals at all (i.e., if the proposals vector is empty).  The "path" field MAY be omitted if the Commit covers only Add proposals.  In pseudocode, the logic for validating a Commit is as follows: </del> <ins> By default, the "path" field of a Commit MUST be populated.  The "path" field MAY be omitted if (a) it covers at least one proposal and (b) none proposals covered by the Commit are of "path required" types.  A proposal type requires a path if it cannot change the group membership in a way that requires the forward secrecy and post- compromise security guarantees that an UpdatePath provides.  The only proposal types defined in this document that do not require a path are: "add" "psk" "app_ack" "reinit" New proposal types MUST state whether they require a path.  If any instance of a proposal type requires a path, then the proposal type requires a path.  This attribute of a proposal type is reflected in the "Path Required" field of the proposal type registry defined in mls-proposal-types. Update and Remove proposals are the clearest examples of proposals that require a path.  An UpdatePath is required to evict the removed member or the old appearance of the updated member. In pseudocode, the logic for validating the "path" field of a Commit is as follows: </ins> To summarize, a Commit can have three different configurations, with different uses:


committer's contribution to the group and provides PCS with regard to the committer. <del> A "partial" Commit that references Add, PreSharedKey, or ReInit proposals but where the path is empty.  Such a commit doesn't provide PCS with regard to the committer. </del> <ins> A "partial" Commit that references proposals that do not require a path, and where the path is empty.  Such a commit doesn't provide PCS with regard to the committer. </ins> A "full" Commit that references proposals of any type, which provides FS with regard to any removed members and PCS for the


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


The following structure is used to fully describe the data transmitted in plaintexts or ciphertexts. <ins> The following figure illustrates how the various structures described in this section relate to each other, and the high-level operations used to produce and consume them: </ins> 7.1. MLSMessageContent is authenticated using the MLSMessageAuth


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.


A PreSharedKey proposal is invalid if any of the following is true: The "psktype" in the PreSharedKeyID struct is not set to <del> "external". </del> <ins> "resumption" and the "usage" is "reinit" or "branch". </ins> The "psk_nonce" is not of length "KDF.Nh".


A GroupContextExtensions proposal is used to update the list of extensions in the GroupContext for the group. <del> "struct { Extension extensions<V>; } GroupContextExtensions; " </del> A GroupContextExtensions proposal is invalid if it includes a "required_capabilities" extension and some members of the group do not support some of the required capabilities (including those added


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.


5.1.1. HPKE public keys are opaque values in a format defined by the <del> underlying protocol (see the Cryptographic Dependencies section of the HPKE specification for more information). </del> <ins> underlying protocol (see Section 4 of RFC9180 for more information). </ins> Signature public keys are likewise represented as opaque values in a format defined by the ciphersuite's signature scheme.


the "extensions" field of a LeafNode object with the "application_id" extension. <del> However, applications SHOULD NOT rely on the data in an </del> <ins> However, applications MUST NOT rely on the data in an </ins> "application_id" extension as if it were authenticated by the Authentication Service, and SHOULD gracefully handle cases where the identifier presented is not unique.


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.


If the client has used all the allocated CID, it is supposed to retire those that are not used anymore, and the server is supposed to provide replacements, as specified in QUIC-TRANSPORT.  Usually, it is <del> desired to provide one more connection ID as currently in use, to </del> <ins> desired to provide one more Connection ID as currently in use, to </ins> allow for new paths or migration. 6.2.


PATH_ABANDON frame is considered lost, the peer SHOULD repeat it. PATH_ABANDON frames MAY be sent on any path, not only the path <del> identified by the Packet Number Space Identifier. </del> <ins> identified by the Path Identifier. </ins> 8.2.


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.2.2. <ins> This document assumes that all communication between different entities is protected by HTTPS.  This protects information about which resources are the subject of request and prevents a network observer from being able to trivially correlate messages on either side of a proxy. </ins> As the time at which encapsulated request or response messages are sent can reveal information to a network observer.  Though messages exchanged between the oblivious proxy resource and the oblivious


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


field ensures that responses have unique AEAD keys and nonces even when requests are replayed. <del> 7.4.1. </del> <ins> 7.5.1. </ins> Clients SHOULD include a "Date" header field in Encapsulated Requests, unless the Oblivious Gateway Resource does not use "Date"


for the "Date" field to determine the time window over which the server will accept responses. <del> 7.4.2. </del> <ins> 7.5.2. </ins> An Oblivious Gateway Resource can reject requests that contain a "Date" value that is outside of its active window with a 400 series


Oblivious Gateway Resource might be correlated using that information. <del> 7.5. </del> <ins> 7.6. </ins> This document does not provide forward secrecy for either requests or responses during the lifetime of the key configuration.  A measure of forward secrecy can be provided by generating a new key configuration then deleting the old keys after a suitable period. <del> 7.6. </del> <ins> 7.7. </ins> This design does not provide post-compromise security for responses.


The total number of affected messages affected by server key compromise can be limited by regular rotation of server keys. <del> 7.7. </del> <ins> 7.8. </ins> Including a "Date" field in requests reveals some information about the client clock.  This might be used to fingerprint clients UWT or


7. One goal of this design is that independent client requests are only <del> linkable by the chosen key configuration.  The Oblivious Relay and Gateway resources can link requests using the same key configuration by matching KeyConfig.key_id, or, if the Target Resource is willing to use trial decryption, a limited set of key configurations that share an identifier.  An Oblivious Relay Resource can link requests using the public key corresponding to KeyConfig.key_id or via the URI of the Oblivious Gateway Resource.  We refer to this set of information as the gateway's configuration. Whether or not targets can link requests depends on how gateway configuration information is produced and discovered by clients. Specifically, gateways can maliciously construct configurations to track individual clients. Ideally, all clients share a consistent view of the gateway configuration.  The number of different valid configurations can exponentially partition the anonymity set of clients.  For example, if there are two valid configurations, that would yield two anonymity sets consisting of clients that used one configuration and clients that used the other configuration.  If the size of each set is large enough, this may not be a significant loss of privacy in practice. Ensuring that many clients share a configuration is necessary to provide privacy for clients. </del> <ins> linkable by their content.  However, the choice of client configuration might be used to correlate requests.  A client configuration includes the Oblivious Relay Resource URI, the Oblivious Gateway key configuration (KeyConfig), and Oblivious Gateway Resource URI.  A configuration is active if clients can successfully use it for interacting with with a target. Oblivious Relay and Gateway Resources can identify when requests use the same configuration by matching "KeyConfig.key_id" or the Oblivious Gateway Resource URI.  The Oblivious Gateway Resource might use the source address of requests to correlate requests that use an Oblivious Relay Resource run by the same operator.  If the Oblivious Gateway Resource is willing to use trial decryption, requests can be further separated into smaller groupings based on the keys that are used. Each active client configuration partitions the client anonymity set. In practice, it is infeasible to reduce the number of active configurations to one.  Enabling diversity in choice of Oblivious Relay Resource naturally increases the number of active configurations.  A small number of configurations might need to be active to allow for key rotation and server maintenance. Client privacy depends on having each configuration used by many other clients.  It is critical prevent the use of unique client configurations, which might be used to track of individual clients, but it is also important to avoid creating small groupings of clients that might weaken privacy protections. </ins> A specific method for a client to acquire configurations is not included in this specification.  Applications using this design MUST <del> provide accommodations to mitigate tracking using gateway </del> <ins> provide accommodations to mitigate tracking using client </ins> configurations.  CONSISTENCY provides options for ensuring that <del> configurations are consistent between clients. </del> <ins> client configurations are consistent between clients. The content of requests or responses, if used in forming new requests, can be used to correlate requests.  This includes obvious methods of linking requests, like cookies COOKIES, but it also includes any information in either message that might affect how subsequent requests are formulated.  For example, FIELDING describes how interactions that are individually stateless can be used to build a stateful system when a client acts on the content of a response. </ins> 8.


6. In this design, a client wishes to make a request of a server that is <del> authoritative for the Target Resource.  The client wishes to make this request without linking that request with either: </del> <ins> authoritative for a Target Resource.  The client wishes to make this request without linking that request with either: </ins> The identity at the network and transport layer of the client (that is, the client IP address and TCP or UDP port number the


analysis could be used to match messages that are forwarded by the relay. <del> A relay could, as part of its function, add delays in order to increase the anonymity set into which each message is attributed. This could latency to the overall time clients take to receive a response, which might not be what some clients want. </del> <ins> A relay could, as part of its function, delay requests before forwarding them.  Delays might increase the anonymity set into which each request is attributed.  Any delay also increases the time that a client waits for a response, so delays SHOULD only be added with the consent - or at least awareness - of clients. </ins> A relay that forwards large volumes of exchanges can provide better privacy by providing larger sets of messages that need to be matched.


response to the POST request made to that resource. Errors detected by the after successfully removing encapsulation and <del> errors detected by the MUST be sent in an . </del> <ins> errors detected by the MUST be sent in an .  This might be because the request is malformed or the does not produce a response.  In either case the can generate a response with an appropriate error status code (such as 400 (Bad Request) or 504 (Gateway Timeout); see HTTP and HTTP, respectively).  This response is encapsulated in the same way as a successful response. Errors in the encapsulation of requests mean that responses cannot be encapsulated.  This includes cases where the is incorrect or outdated.  The can generate and send a response with an error status to the .  This response MAY be forwarded to the or treated by the as a failure.  If a receives a response that is not an , this could indicate that the client configuration used to construct the request is incorrect or out of date. </ins> 6.


4.6. <del> The encrypted payload of an OHTTP request and response is a binary HTTP message BINARY.  The and agree on this encrypted payload type by specifying the media type "message/bhttp" in the HPKE info string and HPKE export context string for request and response encryption, respectively. </del> <ins> The encrypted payload of an Oblivious HTTP request and response is a binary HTTP message BINARY.  The and agree on this encrypted payload type by specifying the media type "message/bhttp" in the HPKE info string and HPKE export context string for request and response encryption, respectively. </ins> Future specifications may repurpose the encapsulation mechanism described in this document.  This requires that the specification


This draft includes pseudocode that uses the functions and conventions defined in HPKE. <del> This draft uses the variable-length integer encoding from Section 16 of QUIC.  Encoding and decoding variable-length integers to a sequence of bytes are described using the functions "vencode()" and "vdecode()".  The function "len()" takes the length of a sequence of bytes. </del> <ins> Encoding an integer to a sequence of bytes in network byte order is described using the function "encode(n, v)", where "n" is the number of bytes and "v" is the integer value.  The function "len()" returns the length of a sequence of bytes. </ins> Formats are described using notation from Section 1.3 of QUIC.


5.1. <del> Clients encapsulate a request "request" with an HPKE public key "pkR", whose Key Identifier is "keyID" as follows: </del> <ins> Clients encapsulate a request "request" using values from a key configuration: the key identifier from the configuration, "keyID", the public key from the configuration, "pkR", and a selected combination of KDF, identified by "kdfID", and AEAD, identified by "aeadID". The client then constructs an encapsulated request, "enc_request", as follows: </ins> Compute an HPKE context using "pkR", yielding "context" and encapsulation key "enc". <del> Encrypt (seal) "request" with "keyID" as associated data using </del> <ins> Construct associated data, "aad", by concatenating the values of "keyID", "kdfID", and "aeadID", as 8-, 16- and 16-bit integers respectively, each in network byte order. Encrypt (seal) "request" with "aad" as associated data using </ins> "context", yielding ciphertext "ct". <del> Concatenate the length of "keyID" as a variable-length integer, "keyID", "enc", and "ct", yielding an Encapsulated Request "enc_request".  Note that "enc" is of fixed-length, so there is no ambiguity in parsing "enc" and "ct". </del> <ins> Concatenate the three values of "aad", "enc", and "ct", yielding an Encapsulated Request "enc_request". Note that "enc" is of fixed-length, so there is no ambiguity in parsing this structure. </ins> In pseudocode, this procedure is as follows: Servers decrypt an Encapsulated Request by reversing this process. Given an Encapsulated Request "enc_request", a server: <del> Parses "enc_request" into "keyID", "enc", and "ct" (indicated using the function "parse()" in pseudocode).  The server is then able to find the HPKE private key, "skR", corresponding to "keyID".  If no such key exists, the server returns an error; see errors. </del> <ins> Parses "enc_request" into "keyID", "kdfID", "aeadID", "enc", and "ct" (indicated using the function "parse()" in pseudocode).  The server is then able to find the HPKE private key, "skR", corresponding to "keyID". a.  If "keyID" does not identify a key, the server returns an error. b.  If "kdfID" and "aeadID" identify a combination of KDF and AEAD that the server is unwilling to use with "skR", the server returns an error. </ins> Compute an HPKE context using "skR" and the encapsulated key "enc", yielding "context". <del> Construct additional associated data, "aad", as the Key Identifier "keyID" from "enc_request". </del> <ins> Construct additional associated data, "aad", from "keyID", "kdfID", and "aeadID" or as the first five bytes of "enc_request". </ins> Decrypt "ct" using "aad" as associated data, yielding "request" or an error on failure.  If decryption fails, the server returns an


Padding is a capability provided by binary HTTP messages; see BINARY. If the encapsulation method described in this document is used to protect a different message type (see repurposing), that message <del> format might need to include padding support. </del> <ins> format might need to include padding support.  can also use padding for the same reason, but need to operate at the HTTP layer since they cannot manipulate binary HTTP messages; for example, see HTTP2 or HTTP3). </ins> 6.3.


6.5.1. SHOULD include a "Date" header field in Encapsulated Requests, unless <del> the does not use "Date" for anti-replay purposes. </del> <ins> the has prior knowledge that indicates that the does not use "Date" for anti-replay purposes. </ins> Though HTTP requests often do not include a "Date" header field, the value of this field might be used by a server to limit the amount of


might need to allow for the time it takes requests to arrive from the , with a time window that is large enough to allow for differences in clocks.  Insufficient tolerance of time differences could result in <del> valid requests being unnecessarily rejected. </del> <ins> valid requests being unnecessarily rejected.  Beyond allowing for multiple round trip times - to account for retransmission - network delays are unlikely to be significant in determining the size of the window, unless all potential are known to have excellent time- keeping.  A specific window size might need to be determined experimentally. </ins> MUST NOT treat the time window as secret information.  An attacker can actively probe with different values for the "Date" field to


corresponds to the key identifier, but the encapsulated request cannot be successfully decrypted using the key. <ins> 8.4. Encapsulated requests can be copied and replayed by the oblivious proxy resource.  The design of oblivious HTTP does not assume that the oblivious proxy resource will not replay requests.  In addition, if a client sends an encapsulated request in TLS early data (see Section 8 of TLS and RFC8470), a network-based adversary might be able to cause the request to be replayed.  In both cases, the effect of a replay attack and the mitigations that might be employed are similar to TLS early data. A client or oblivious proxy resource MUST NOT automatically attempt to retry a failed request unless it receives a positive signal indicating that the request was not processed or forwarded.  The HTTP/2 REFUSED_STREAM error code (Section 8.1.4 of RFC7540), the HTTP/3 H3_REQUEST_REJECTED error code (Section 8.1 of QUIC-HTTP), or a GOAWAY frame (in either protocol version) are all sufficient signals that no processing occurred.  Connection failures or interruptions are not sufficient signals that no processing occurred. The anti-replay mechanisms described in Section 8 of TLS are generally applicable to oblivious HTTP requests.  Servers can use the encapsulated keying material as a unique key for identifying potential replays. The mechanism used in TLS for managing differences in client and server clocks cannot be used as it depends on being able to observe previous interactions.  Oblivious HTTP explicitly prevents such linkability.  Applications can still include an explicit indication of time to limit the span of time over which a server might need to track accepted requests.  Clock information could be used for client identification, so reduction in precision or obfuscation might be necessary. The considerations in RFC8470 as they relate to managing the risk of replay also apply, though there is no option to delay the processing of a request. Limiting requests to those with safe methods might not be satisfactory for some applications, particularly those that involve the submission of data to a server.  The use of idempotent methods might be of some use in managing replay risk, though it is important to recognize that different idempotent requests can be combined to be not idempotent. Idempotent actions with a narrow scope based on the value of a protected nonce could enable data submission with limited replay exposure.  A nonce might be added as an explicit part of a request, or, if the oblivious request and target resources are co-located, the encapsulated keying material can be used to produce a nonce. The server-chosen "response_nonce" field ensures that responses have unique AEAD keys and nonces even when requests are replayed. </ins> 9. Please update the "Media Types" registry at


resource; see key-configuration. Clients MUST NOT include identifying information in the request that <del> is encapsulated. </del> <ins> is encapsulated.  Identifying information includes cookies COOKIES, authentication credentials or tokens, and any information that might reveal client-specific information such as account credentials. </ins> Clients cannot carry connection-level state between requests as they only establish direct connections to the proxy responsible for the


HPKE algorithms that are used with that key. The identity of an oblivious proxy resource that will forward <del> encapsulated requests and responses to the oblivious request resource. </del> <ins> encapsulated requests and responses to a single oblivious request resource.  See proxy-state for more information about the mapping between oblivious proxy and oblivious request resources. </ins> This information allows the client to make a request of an oblivious target resource without that resource having only a limited ability


10. <ins> This section discusses various operational and deployment considerations. 10.1. </ins> Using Oblivious HTTP adds both cryptographic and latency to requests relative to a simple HTTP request-response exchange.  Deploying proxy services that are on path between clients and servers avoids adding


similar system ODoH found that deploying proxies close to servers was most effective in minimizing additional latency. <ins> 10.2. This protocol assumes a fixed, one-to-one mapping between the Oblivious Proxy Resource and the Oblivious Request Resource.  This means that any encapsulated request sent to the Oblivious Proxy Resource will always be forwarded to the Oblivious Request Resource. This constraint was imposed to simplify proxy configuration and mitigate against the Oblivious Proxy Resource being used as a generic proxy for unknown Oblivious Request Resources.  The proxy will only forward for Oblivious Request Resources that it has explicitly configured and allowed. It is possible for a server to be configured with multiple Oblivious Proxy Resources, each for a different Oblivious Request Resource as needed. 10.3. </ins> Oblivious HTTP might be incompatible with network interception regimes, such as those that rely on configuring clients with trust anchors and intercepting TLS connections.  While TLS might be


2.1. QUIC packets may have either a long header, or a short header.  The <del> first bit of the QUIC header indicates which type of header is present. </del> <ins> first bit of the QUIC header us the Header Form bit, and indicates which type of header is present. </ins> The long header exposes more information.  It is used during connection establishment, including version negotiation, retry, and


The following information is exposed in QUIC packet headers: <del> demux bit: the second most significant bit of the first octet every QUIC packet of the current version is set to 1, for demultiplexing with other UDP-encapsulated protocols. </del> <ins> "fixed bit": the second most significant bit of the first octet most QUIC packets of the current version is currently set to 1, for demultiplexing with other UDP-encapsulated protocols. </ins> latency spin bit: the third most significant bit of first octet in the short packet header.  The spin bit is set by endpoints such


end-to-end RTT.  See spin-usage for further details. header type: the long header has a 2 bit packet type field <del> following the Header Form bit.  Header types correspond to stages of the handshake; see Section 17.2 of QUIC-TRANSPORT. </del> <ins> following the Header Form and fixed bits.  Header types correspond to stages of the handshake; see Section 17.2 of QUIC-TRANSPORT for details. </ins> version number: the version number present in the long header, and identifies the version used for that packet.  Note that during


subsequent connection attempt.  The length of the token is explicit in both cases. <del> Retry and Version Negotiation packets are not encrypted or obfuscated in any way.  For other kinds of packets, other information in the packet headers is cryptographically obfuscated: </del> <ins> Retry (Section 17.2.5 of QUIC-TRANSPORT) and Version Negotiation (Section 17.2.1 of QUIC-TRANSPORT) packets are not encrypted or obfuscated in any way.  For other kinds of packets, other information in the packet headers is cryptographically obfuscated: </ins> <del> packet number: Most packets (with the exception of Version Negotiation and Retry packets) have an associated packet number; however, this packet number is encrypted, and therefore not of use to on-path observers.  The offset of the packet number is encoded in the header for packets with long headers, while it is implicit </del> <ins> packet number: All packets except Version Negotiation and Retry packets have an associated packet number; however, this packet number is encrypted, and therefore not of use to on-path observers.  The offset of the packet number is encoded in the header for packets with long headers, while it is implicit </ins> (depending on Destination Connection ID length) in short header packets.  The length of the packet number is cryptographically obfuscated.


QUIC's stream multiplexing feature allows applications to run multiple streams over a single connection, without head-of-line blocking between streams, associated at a point in time with a single <del> five-tuple.  Stream data is carried within Frames, where one (UDP) packet on the wire can carry one of multiple stream frames. Stream can be independently open and closed, gracefully or by error. If a critical stream for the application is closed, the application can generate respective error messages on the application layer to inform the other end or the higher layer and eventually indicate QUIC to reset the connection.  QUIC, however, does not need to know which streams are critical, and does not provide an interface to exceptional handling of any stream.  There are special streams in QUIC that are used for control on the QUIC connection, however, these streams are not exposed to the application. </del> <ins> five-tuple.  Stream data is carried within Frames, where one QUIC packet on the wire can carry one or multiple stream frames. Streams can be unidirectional or bidirectional, and a stream may be initiated either by client or server.  Only the initiator of a unidirectional stream can send data on it.  Due to offset encoding limitations, a stream can carry a maximum of 2^62-1 bytes in each direction.  In the presently unlikely event that this limit is reached by an application, the stream can simply be closed and replaced with a new one. Streams can be independently opened and closed, gracefully or by error.  An application can gracefully close the egress direction of a stream by instructing QUIC to send a FIN bit in a STREAM frame.  It cannot gracefully close the ingress direction without a peer- generated FIN, much like in TCP.  However, an endpoint can abruptly close either the ingress or egress direction; these actions are fully independent of each other. If a stream that is critical for an application is closed, the application can generate respective error messages on the application layer to inform the other end and/or the higher layer, and eventually indicate QUIC to reset the connection.  QUIC, however, does not need to know which streams are critical, and does not provide an interface for exceptional handling of any stream. </ins> Mapping of application data to streams is application-specific and <del> described for HTTP/s in QUIC-HTTP.  In general data that can be </del> <ins> described for HTTP/3 in QUIC-HTTP.  In general, data that can be </ins> processed independently, and therefore would suffer from head of line blocking if forced to be received in order, should be transmitted <del> over different streams.  If the application requires certain data to be received in order, the same stream should be used for that data. </del> <ins> over separate streams.  If the application requires certain data to be received in order, that data should be sent on the same stream. </ins> If there is a logical grouping of data chunks or messages, streams can be reused, or a new stream can be opened for each chunk/message. If one message is mapped to a single stream, resetting the stream to


currently open and currently used streams to the application to make the mapping of data to streams dependent on this information. <del> Further, streams have a maximum number of bytes that can be sent on one stream.  This number is high enough (2^64) that this will usually not be reached with current applications.  Applications that send chunks of data over a very long period of time (such as days, months, or years), should rather utilize the 0-RTT session resumption ability provided by QUIC, than trying to maintain one connection open. </del> <ins> While a QUIC implementation must necessarily provide a way for an application to send data on separate streams, it does not necessarily expose stream identifiers to the application (see e.g.  QUIC-HTTP section 6) either at the sender or receiver end, so applications should not assume access to these identifiers. </ins> 4.1.


frames. The Client Hello datagram exposes version number, source and <del> destination connection IDs, and information in the TLS Client Hello message, including any TLS Server Name Indication (SNI) present, in the clear.  The QUIC PADDING frame shown here may be present to ensure the Client Hello datagram has a minimum size of 1200 octets, to mitigate the possibility of handshake amplification.  Note that the location of PADDING is implementation-dependent, and PADDING frames may not appear in the Initial packet in a coalesced packet. The Server Hello datagram exposes version number, source and destination connection IDs, and information in the TLS Server Hello message. </del> <ins> destination connection IDs in the clear.  Information in the TLS Client Hello frame, including any TLS Server Name Indication (SNI) present, is obfuscated using the Initial secret.  The QUIC PADDING frame shown here may be present to ensure the Client Hello datagram has a minimum size of 1200 octets, to mitigate the possibility of handshake amplification.  Note that the location of PADDING is implementation-dependent, and PADDING frames may not appear in the Initial packet in a coalesced packet. The Server Hello datagram also exposes version number, source and destination connection IDs and information in the TLS Server Hello message which is obfuscated using the Initial secret. </ins> The Initial Completion datagram does not expose any additional information; however, recognizing it can be used to determine that a


The best way to obscure an encoding is to appear random to observers, which is most rigorously achieved with encryption.  Even when encrypted, a scheme could embed the unencrypted length of the <del> Connection ID in the Connection ID itself, instead of remembering it, e.g. by using the first few bits to indicate a certain size of a well-known set of possible sizes with multiple values that indicate the same size but are selected randomly. </del> <ins> Connection ID in the Connection ID itself, instead of remembering it. </ins> QUIC_LB further specified possible algorithms to generate Connection IDs at load balancers.


3.2. <del> Connection establishment requires cleartext packets and is using a TLS handshake on stream 0.  Therefore it is detectable using heuristics similar to those used to detect TLS over TCP. 0-RTT connection may additional also send data packets, right after the Client Initial with the TLS client hello.  These data may be reordered in the network, therefore it may be possible that 0-RTT Protected data packets are seen before the Client Initial packet. </del> <ins> Connection establishment uses Initial, Handshake, and Retry packets containing a TLS handshake on Stream 0.  Connection establishment can therefore be detected using heuristics similar to those used to detect TLS over TCP.  A client using 0-RTT connection may also send data packets in 0-RTT Protected packets directly after the Initial packet containing the TLS Client Hello.  Since these packets may be reordered in the network, note that 0-RTT Protected data packets may be seen before the Initial packet.  Note that only clients send Initial packets, so the sides of a connection can be distinguished by QUIC packet type in the handshake. </ins> 3.3. <ins> The cleartext TLS handshake may contain Server Name Indication (SNI) RFC6066, by which the client reveals the name of the server it intends to connect to, in order to allow the server to present a certificate based on that name.  It may also contain information from Application-Layer Protocol Negotiation (ALPN) RFC7301, by which the client exposes the names of application-layer protocols it supports; an observer can deduce that one of those protocols will be used if the connection continues. Work is currently underway in the TLS working group to encrypt the SNI in TLS 1.3 TLS-ENCRYPT-SNI, reducing the information available in the SNI to the name of a fronting service, which can generally be identified by the IP address of the server anyway.  If used with QUIC, this would make SNI-based application identification impossible through passive measurement. 3.4. </ins> The QUIC Connection ID (see rebinding) is designed to allow an on- path device such as a load-balancer to associate two flows as identified by five-tuple when the address and port of one of the


should be treated as opaque; see sec-loadbalancing for caveats regarding connection ID selection at servers. <del> 3.4. </del> <ins> 3.5. </ins> The QUIC does not expose the end of a connection; the only indication to on-path devices that a flow has ended is that packets are no


Changes to this behavior are currently under discussion: see https://github.com/quicwg/base-drafts/issues/602. <del> 3.5. </del> <ins> 3.6. </ins> Round-trip time of QUIC flows can be inferred by observation once per flow, during the handshake, as in passive TCP measurement; this


Changes to this behavior are currently under discussion: see https://github.com/quicwg/base-drafts/issues/631. <del> 3.6. </del> <ins> 3.7. </ins> All QUIC packets carry packet numbers in cleartext, and while the protocol allows packet numbers to be skipped, skipping is not


observation point and the receiver ("downstream loss") cannot be reliably estimated. <del> 3.7. </del> <ins> 3.8. </ins> QUIC explicitly exposes which side of a connection is a client and which side is a server during the handshake.  In addition, the


and a description of how common network management practices will be impacted by QUIC. <del> Since QUIC's wire image WIRE-IMAGE is integrity protected and not modifiable on path, in-network operations are not possible without terminating the QUIC connection, for instance using a back-to-back proxy.  Proxy operations are not in scope for this document.  A proxy can either explicit identify itself as providing a proxy service, or may share the TLS credentials to authenticate as the server and (in some cases) client acting as a front-facing instance for the endpoint itself. </del> <ins> Since QUIC's wire image WIRE-IMAGE is integrity-protected, in-network operations that depend on modification of data are not possible without the cooperation of an endpoint.  Network operation practices that alter data are only possible if performed as a QUIC endpoint; this might be possible with the introduction of a proxy which authenticates as an endpoint.  Proxy operations are not in scope for this document. </ins> Network management is not a one-size-fits-all endeavour: practices considered necessary or even mandatory within enterprise networks


fall back to some other transport protocol.  In the case of HTTP, this fallback is TLS 1.3 over TCP. <ins> The IETF TAPS specifications I-D.ietf-taps-arch describe a system with a common API for multiple protocols and some of the implications of fallback between these different protocols, specifically precluding fallback to insecure protocols or to weaker versions of secure protocols. </ins> An application that implements fallback needs to consider the security consequences.  A fallback to TCP and TLS 1.3 exposes control information to modification and manipulation in the network.  Further


The CONNECTION_CLOSE frame provides an optional reason field, that can be used to append human-readable information to an error code. <del> Note that QUIC RESET_STREAM and STOP_SENDING frames also include an error code, but no reason string.  Application error codes are expected to be defined from a single space that applies to all three frame types. </del> <ins> RESET_STREAM and STOP_SENDING frames also include an error code, but no reason string. </ins> Alternatively, a QUIC connection can be silently closed by each endpoint separately after an idle timeout.  If enabled as indicated


and identifies the version used for that packet.  During Version Negotiation (see version and Section 17.2.1 of QUIC-TRANSPORT), the version number field has a special value (0x00000000) that <del> identifies the packet as a Version Negotiation packet.  Upon time of publishing of this document, QUIC versions that start with 0xff implement IETF drafts.  QUIC version 1 uses version 0x00000001. Operators should expect to observe packets with other version numbers as a result of various Internet experiments and future standards. </del> <ins> identifies the packet as a Version Negotiation packet.  QUIC version 1 uses version 0x00000001.  Operators should expect to observe packets with other version numbers as a result of various Internet experiments, future standards, and greasing.  All deployed versions are maintained in an IANA registry (see Section 22.2 of QUIC-TRANSPORT). </ins> source and destination connection ID: short and long packet headers carry a destination connection ID, a variable-length field


4.4. <del> Flow control provides a means of managing access to the limited </del> <ins> QUIC flow control provides a means of managing access to the limited </ins> buffers endpoints have for incoming data.  This mechanism limits the amount of data that can be in buffers in endpoints or in transit on the network.  However, there are several ways in which limits can


Understanding what causes deadlocking might help implementations avoid deadlocks. <del> Large messages can produce deadlocking if the recipient does not process the message incrementally.  If the message is larger than the flow control credit available and the recipient does not release additional flow control credit until the entire message is received and delivered, a deadlock can occur.  This is possible even where stream flow control limits are not reached because connection flow control limits can be consumed by other streams. A common flow control implementation technique is for a receiver to extend credit to the sender as a the data consumer reads data.  In this setting, a length-prefixed message format makes it easier for the data consumer to leave data unread in the receiver's buffers and thereby withhold flow control credit.  If flow control limits prevent the remainder of a message from being sent, a deadlock will result. A length prefix might also enable the detection of this sort of deadlock.  Where protocols have messages that might be processed as a </del> <ins> The size and rate of transport flow control credit updates can affect performance.  Applications that use QUIC often have a data consumer that reads data from transport buffers.  Some implementations might have independent transport-layer and application-layer receive buffers.  Consuming data does not always imply it is immediately processed.  However, a common flow control implementation technique is to extend credit to the sender, by emitting MAX_DATA and/or MAX_STREAM_DATA frames, as data is consumed.  Delivery of these frames is affected by the latency of the back channel from the receiver to the data sender.  If credit is not extended in a timely manner, the sending application can be blocked, effectively throttling the sender. Large application messages can produce deadlocking if the recipient does not read data from the transport incrementally.  If the message is larger than the flow control credit available and the recipient does not release additional flow control credit until the entire message is received and delivered, a deadlock can occur.  This is possible even where stream flow control limits are not reached because connection flow control limits can be consumed by other streams. A length-prefixed message format makes it easier for a data consumer to leave data unread in the transport buffer and thereby withhold flow control credit.  If flow control limits prevent the remainder of a message from being sent, a deadlock will result.  A length prefix might also enable the detection of this sort of deadlock.  Where application protocols have messages that might be processed as a </ins> single unit, reserving flow control credit for the entire message atomically makes this style of deadlock less likely. <del> A data consumer can read all data as it becomes available to cause the receiver to extend flow control credit to the sender and reduce the chances of a deadlock.  However, releasing flow control credit might mean that the data consumer might need other means for holding a peer accountable for the state it keeps for partially processed messages. </del> <ins> A data consumer can eagerly read all data as it becomes available, in order to make the receiver extend flow control credit and reduce the chances of a deadlock.  However, such a data consumer might need other means for holding a peer accountable for the additional state it keeps for partially processed messages. </ins> Deadlocking can also occur if data on different streams is interdependent.  Suppose that data on one stream arrives before the


A single stream provides ordering.  If the application requires certain data to be received in order, that data should be sent on <del> the same stream. </del> <ins> the same stream.  There is no guarantee of transmission, reception, or delivery order across streams. </ins> Multiple streams provide concurrency.  Data that can be processed independently, and therefore would suffer from head of line


use of DiffServ Code Points (DSCPs) RFC2475 as well as Equal-Cost Multi-Path (ECMP) routing, is applied on a per flow-basis (and not per-packet) and as such that all packets belonging to the same QUIC <del> connection get uniform treatment.  Using ECMP to distribute packets from a single flow across multiple network paths or any other non- uniform treatment of packets belong to the same connection could result in variations in order, delivery rate, and drop rate.  As feedback about loss or delay of each packet is used as input to the congestion controller, these variations could adversely affect performance. Depending on the loss recovery mechanism implemented, QUIC may be more tolerant of packet re-ordering than traditional TCP traffic (see packetnumber).  However, it cannot be known by the network which exact recovery mechanism is used and therefore reordering tolerance should be considered as unknown. </del> <ins> connection get uniform treatment. Using ECMP to distribute packets from a single flow across multiple network paths or any other non-uniform treatment of packets belong to the same connection could result in variations in order, delivery rate, and drop rate.  As feedback about loss or delay of each packet is used as input to the congestion controller, these variations could adversely affect performance.  Depending on the loss recovery mechanism implemented, QUIC may be more tolerant of packet re- ordering than traditional TCP traffic (see packetnumber).  However, the recovery mechanism used by a flow cannot be known by the network and therefore reordering tolerance should be considered as unknown. </ins> 4.9.


12. <del> QUIC assumes that all packets of a QUIC connection, or at least with the same 5-tuple {dest addr, source addr, protocol, dest port, source port}, will receive similar network treatment since feedback about loss or delay of each packet is used as input to the congestion controller.  Therefore, it is not recommended to use different DiffServ Code Points (DSCPs) RFC2475 for packets belonging to the same connection.  If differential network treatment, e.g. by the use of different DSCPs, is desired, multiple QUIC connections to the same server may be used.  However, in general it is recommended to minimize the number of QUIC connections to the same server, to avoid increased overheads and, more importantly, competing congestion control. </del> <ins> QUIC, as defined in RFC9000, has a single congestion controller and recovery handler.  This design assumes that all packets of a QUIC connection, or at least with the same 5-tuple {dest addr, source addr, protocol, dest port, source port} that same the same DiffServ Code Point (DSCP) RFC2475, will receive similar network treatment since feedback about loss or delay of each packet is used as input to the congestion controller.  Therefore, packets belonging to the same connection should use a single DSCP.  Section 5.1 of RFC7657 provides a discussion of DiffServ interactions with datagram transport protocols RFC7657 (in this respect the interactions with QUIC resemble those of SCTP). When multiplexing multiple flows over a single QUIC connection, the selected DSCP value should be the one associated with the highest priority requested for all multiplexed flows. If differential network treatment is desired, e.g., by the use of different DSCPs, multiple QUIC connections to the same server may be used.  However, in general it is recommended to minimize the number of QUIC connections to the same server, to avoid increased overhead and, more importantly, competing congestion control. As in other uses of DiffServ, when a packet enters a network segment that does not support the DSCP value, this could result in the connection not receiving the network treatment it expects.  The DSCP value in this packet could also be remarked as the packet travels along the network path, changing the requested treatment. </ins> 13.


7. QUIC version 1 without extensions uses an acknowledgment strategy <del> adopted from TCP.  That is, every other packet is acknowledged. However, generating and processing QUIC acknowledgments can consume significant resources, both in terms of processing costs and link utilization, especially on constraint networks.  Some applications might be able to improve overall performance by using alternative strategies that reduce the rate of acknowledgments. </del> <ins> adopted from TCP Section 13.2 of RFC9000).  That is, it recommends every other packet is acknowledged.  However, generating and processing QUIC acknowledgments consumes resources at a sender and receiver.  Acknowledgments also incur forwarding costs and contribute to link utilization, which can impact performance over some types of network.  Applications might be able to improve overall performance by using alternative strategies that reduce the rate of acknowledgments. </ins> 8.


Mapping of application data to streams is application-specific and described for HTTP/s in QUIC-HTTP.  In general data that can be processed independently, and therefore would suffer from head of line <del> blocking, if forced to be received in order, should be transmitted over different streams.  If there is a logical grouping of those data chunks or messages, stream can be reused, or a new stream can be opened for each chunk/message.  If one message is mapped on a single stream, resetting the stream if the message is not needed anymore can be used to emulate partialreliability on a message basis.  If a QUIC receiver has maximum allowed concurrent streams open and the sender on the other end indicates that more streams are needed, it doesn't automatically lead to an increase of the maximum number of streams by the receiver.  Therefore it can be valuable to expose maximum number of allowed, currently open and currently used streams to the application to make the mapping of data to streams dependent on this information. </del> <ins> blocking if forced to be received in order, should be transmitted over different streams.  If the application requires certain data to be received in order, the same stream should be used for that data. If there is a logical grouping of data chunks or messages, streams can be reused, or a new stream can be opened for each chunk/message. If one message is mapped to a single stream, resetting the stream to expire an unacknowledged message can be used to emulate partial reliability on a message basis.  If a QUIC receiver has maximum allowed concurrent streams open and the sender on the other end indicates that more streams are needed, it doesn't automatically lead to an increase of the maximum number of streams by the receiver. Therefore it can be valuable to expose maximum number of allowed, currently open and currently used streams to the application to make the mapping of data to streams dependent on this information. </ins> Further, streams have a maximum number of bytes that can be sent on one stream.  This number is high enough (2^64) that this will usually


Context associated to endpoint X.  The Recipient Key is used as salt in the HKDF, when deriving the Pairwise Recipient Key. <del> The Shared Secret is computed as a static-static Diffie-Hellman shared secret NIST-800-56A, where the endpoint uses its private key and the public key of the other endpoint X.  The Shared Secret is used as Input Keying Material (IKM) in the HKDF. </del> <ins> IKM-Sender - the Input Keying Material (IKM) used in HKDF for the derivation of the Pairwise Sender Key - is the concatenation of the endpoint's own signature public key, endpoint X's signature public key from the Recipient Context, and the Shared Secret IKM-Recipient - the Input Keying Material (IKM) used in HKDF for the derivation of the Recipient Sender Key - is the concatenation of endpoint X's signature public key from the Recipient Context, the endpoint's own signature public key, and the Shared Secret. The Shared Secret is computed as a cofactor Diffie-Hellman shared secret, see Section 5.7.1.2 of NIST-800-56A, where the endpoint uses its private key and the public key of the other endpoint X. Note the requirement of validation of public keys in ssec-crypto- considerations.  For X25519 and X448, the procedure is described in Section 5 of RFC7748 using public keys mapped to Montgomery coordinates, see montgomery. </ins> info and L are as defined in Section 3.2.1 of RFC8613. If EdDSA asymmetric keys are used, the Edward coordinates are mapped to Montgomery coordinates using the maps defined in Sections 4.1 and 4.2 of RFC7748, before using the X25519 and X448 functions defined in <del> Section 5 of RFC7748. </del> <ins> Section 5 of RFC7748.  For further details, see montgomery. </ins> After establishing a partially or completely new Security Context (see ssec-sec-context-persistence and sec-group-key-management), the


2.3.2. <ins> 2.3.2.1. The y-coordinate of the other endpoint's Ed25519 public key is decoded as specified in Section 5.1.3 of RFC8032.  The Curve25519 u-coordinate is recovered as u = (1 + y) / (1 - y) (mod p) following the map in Section 4.1 of RFC7748.  Note that the mapping is not defined for y = 1, and that y = -1 maps to u = 0 which corresponds to the neutral group element and thus will result in a degenerate shared secret.  Therefore implementations MUST abort if the y-coordinate of the other endpoint's Ed25519 public key is 1 or -1 (mod p). The private signing key byte strings (= the lower 32 bytes used for generating the public key, see step 1 of Section 5.1.5 of RFC8032) are decoded the same way for signing in Ed25519 and scalar multiplication in X25519.  Hence, to compute the shared secret the endpoint applies the X25519 function to the Ed25519 private signing key byte string and the encoded u-coordinate byte string as specified in Section 5 of RFC7748. 2.3.2.2. The y-coordinate of the other endpoint's Ed448 public key is decoded as specified in Section 5.2.3. of RFC8032.  The Curve448 u-coordinate is recovered as u = y^2 * (d * y^2 - 1) / (y^2 - 1) (mod p) following the map from "edwards448" in Section 4.2 of RFC7748, and also using the relation x^2 = (y^2 - 1)/(d * y^2 - 1) from the curve equation. Note that the mapping is not defined for y = 1 or -1.  Therefore implementations MUST abort if the y-coordinate of the peer endpoint's Ed448 public key is 1 or -1 (mod p). The private signing key byte strings (= the lower 57 bytes used for generating the public key, see step 1 of Section 5.2.5 of RFC8032) are decoded the same way for signing in Ed448 and scalar multiplication in X448.  Hence, to compute the shared secret the endpoint applies the X448 function to the Ed448 private signing key byte string and the encoded u-coordinate byte string as specified in Section 5 of RFC7748. 2.3.3. </ins> When using any of its Pairwise Sender Keys, a sender endpoint including the 'Partial IV' parameter in the protected message MUST use the current fresh value of the Sender Sequence Number from its


sequences of one-to-one exchanges with servers in the group, by sending requests over unicast. <del> 2.3.3. </del> <ins> 2.3.4. </ins> If the pairwise mode is supported, the Security Context additionally includes Secret Derivation Algorithm, Secret Derivation Parameters


hold for Group OSCORE, about building the AEAD nonce and the secrecy of the Security Context parameters. <del> The EdDSA signature algorithm and the elliptic curve Ed25519 RFC8032 are mandatory to implement.  For endpoints that support the pairwise mode, the ECDH-SS + HKDF-256 algorithm specified in Section 6.3.1 of I-D.ietf-cose-rfc8152bis-algs and the X25519 curve RFC7748 are also mandatory to implement. </del> <ins> The EdDSA signature algorithm Ed25519 RFC8032 is mandatory to implement.  For endpoints that support the pairwise mode, the ECDH-SS + HKDF-256 algorithm specified in Section 6.3.1 of I-D.ietf-cose- rfc8152bis-algs and the X25519 algorithm RFC7748 are also mandatory to implement. </ins> Constrained IoT devices may alternatively represent Montgomery curves and (twisted) Edwards curves RFC7748 in the short-Weierstrass form


The derivation of pairwise keys defined in key-derivation-pairwise is compatible with ECDSA and EdDSA asymmetric keys, but is not <del> compatible with RSA asymmetric keys.  The security of using the same key pair for Diffie-Hellman and for signing is demonstrated in Degabriele. </del> <ins> compatible with RSA asymmetric keys. For the public key translation from Ed25519 (Ed448) to X25519 (X448) specified in key-derivation-pairwise, variable time methods can be used since the translation operates on public information.  Any byte string of appropriate length is accepted as a public key for X25519 (X448) in RFC7748, it is therefore not necessary for security to validate the translated public key (assuming the translation was successful). The security of using the same key pair for Diffie-Hellman and for signing (by considering the ECDH procedure in sec-derivation-pairwise as a Key Encapsulation Mechanism (KEM)) is demonstrated in Degabriele and Thormarker. Applications using ECDH (except X25519 and X448) based KEM in sec- derivation-pairwise are assumed to verify that a peer endpoint's public key is on the expected curve and that the shared secret is not the point at infinity.  The KEM in Degabriele checks that the shared secret is different from the point at infinity, as does the procedure in Section 5.7.1.2 of NIST-800-56A which is referenced in sec- derivation-pairwise. Extending Theorem 2 of Degabriele, Thormarker shows that the same key pair can be used with X25519 and Ed25519 (X448 and Ed448) for the KEM specified in sec-derivation-pairwise.  By symmetry in the KEM used in this document, both endpoints can consider themselves to have the recipient role in the KEM -- as discussed in Section 7 of Thormarker - and rely on the mentioned proofs for the security of their key pairs. Theorem 3 in Degabriele shows that the same key pair can be used for an ECDH based KEM and ECDSA.  The KEM uses a different KDF than in sec-derivation-pairwise, but the proof only depends on that the KDF has certain required properties, which are the typical assumptions about HKDF, e.g., that output keys are pseudorandom.  In order to comply with the assumptions of Theorem 3, received public keys MUST be successfully validated, see Section 5.6.2.3.4 of NIST-800-56A. The validation MAY be performed by a trusted Group Manager.  For Degabriele to apply as it is written, public keys need to be in the expected subgroup.  For this we rely on cofactor DH, Section 5.7.1.2 of NIST-800-56A which is referenced in sec-derivation-pairwise. HashEdDSA variants of Ed25519 and Ed448 are not used by COSE, see Section 2.2 of I-D.ietf-cose-rfc8152bis-algs, and are not covered by the analysis in Thormarker, and hence MUST NOT be used with the public keys used with pairwise keys as specified in this document. </ins> 10.14.


Observe RFC7641 is an optional feature.  An implementation MAY support RFC7252 and the OSCORE option without supporting RFC7641, in <del> which case the Observe related processing specified in this section, sequence-numbers and processing can be omitted. The Observe option as used here targets the requirements on forwarding of I-D.hartke-core-e2e-security-reqs (Section 2.2.1). This section specifies Observe processing associated to the Partial IV (observe-partial-iv) and Observe processing in the presence of RFC7641-compliant intermediaries (observe-option-processing). In contrast to e.g. block-wise, the Inner and Outer Observe option are not processed independently.  Outer Observe is required to support Observe operations in intermediaries, but the additional use of Inner Observe is needed to protect Observe registrations end-to- end (see observe-option-processing). observe-without-intermed specifies a simplified Observe processing which is applicable in the absence of intermediaries. </del> <ins> which case the Observe related processing can be omitted. </ins> <del> Note that OSCORE is compliant with the requirement that a client must not register more than once for the same target resource (see Section 3.1 of RFC7641) since the target resource for Observe registration is identified by all options in the request that are part of the Cache-Key, including OSCORE. </del> <ins> OSCORE supports a reduced set of RFC7641 operations performed in intermediary nodes as specified in this section.  The use of Observe targets the requirements on forwarding of Section 2.2.1 of I- D.hartke-core-e2e-security-reqs, i.e. that observations go through any intermediate node, as illustrated in Figure 8 of RFC7641). </ins> <del> 4.1.3.4.1. To support proxy operations, the CoAP client using Observe with OSCORE MUST set Outer Observe.  If Observe was only sent encrypted end-to-end, an OSCORE-unaware proxy would not expect several responses to a non-Observe request and notifications would not reach the client.  Moreover, intermediaries are allowed to cancel observations and inform the server; forbidding this may result in processing and transmission of notifications on the server side which do not reach the client. In case of registrations or re-registrations, the CoAP client using Observe with OSCORE MUST set both Inner and Outer Observe to the same value (0).  This allows the server to verify that the observation was requested by the client, thereby avoiding unnecessary processing and transmission of notifications, since such notifications would not benefit the client. An intermediary that supports Observe MUST copy the OSCORE option in the next hop request unchanged.  Although intermediaries are allowed to re-send notifications to other clients, when using OSCORE this does not happen, since requests from different clients will have different cache keys. The Outer Observe option in the CoAP request may be legitimately removed by a proxy or ignored by a server.  In these cases, the server processes the request as a non-Observe request and produce a non-Observe response.  If the OSCORE client receives a response to an Observe request without an Outer Observe value, then it verifies the response as a non-Observe response, as specified in ver-res.  If the OSCORE client receives a response to a non-Observe request with an Outer Observe value, it stops processing the message, as specified in ver-res. </del> <ins> Inner Observe is used by default to protect the value of the Observe option between the endpoints.  Outer Observe is additionally used to support a selected set of intermediate node operations that are useful while maintaining end-to-end security.  Intermediary nodes MUST copy the OSCORE option in the next hop request unchanged. </ins> In order to support Observe processing in OSCORE-unaware intermediaries, for messages with the Observe option the Outer Code <del> SHALL be set to 0.05 (FETCH) for requests and to 2.05 (Content) for </del> <ins> MUST be set to 0.05 (FETCH) for requests and to 2.05 (Content) for </ins> responses. <ins> 4.1.3.4.1. The client MUST set both Inner and Outer Observe to the same value in the request.  In order to support the case of an intermediary node ignoring a registration request (Observe 0) and instead processing a non-Observe request (Section 2 of RFC7641), the server MUST only consider the received message a registration request if both Inner and Outer Observe are set to 0. Clients can re-register observations to ensure that the observation is still active and establish freshness again (RFC7641 Section 3.3.1).  When an OSCORE protected observation is refreshed, not only the ETags, but also the Partial IV (and thus the payload and OSCORE option) change.  The server uses the Partial IV of the new request as the 'request_piv' of new responses. Since intermediaries are not assumed to have a security context with the server, cancellation or re-registration of an observation initiated by an intermediary node is not supported. Cancellation of observation by an intermediary using the Reset message as response to a notification can still be applied. An intermediary node may forward a re-registration message, but if a proxy re-sends an old registration message from a client this will trigger the replay protection mechanism in the server which, depending on action, may result in a termination of the observation in proxy or client.  An OSCORE aware intermediary SHALL NOT initiate re-registrations of observations.  A server MAY respond to a replayed registration request with a cached notification.  The server SHALL NOT respond to a replayed registration request with a message encrypted using the Partial IV of the request. Note that OSCORE is compliant with the requirement that a client must not register more than once for the same target resource (see Section 3.1 of RFC7641) since the target resource for Observe registration is identified by all options in the request that are part of the Cache-Key, including OSCORE. </ins> 4.1.3.4.2. If the server accepts an Observe registration, a Partial IV MUST be