multipath negotiation is ambiguous, they MUST be interpreted as acknowledging packets sent on path 0. <del> Endpoints negotiate the use of one packet number space for all paths or separate packet number spaces per path during the connection handshake nego.  While separate packet number spaces allow for more efficient ACK encoding, especially when paths have highly different latencies, this approach requires the use of a connection ID. Therefore use of a single number space can be beneficial when endpoints use zero-length connection ID for less overhead. </del> 7.1. <del> If the multipath option is negotiated to use one packet number space for all paths, the packet sequence numbers are allocated from the common number space, so that, for example, packet number N could be sent on one path and packet number N+1 on another. ACK frames report the numbers of packets that have been received so far, regardless of the path on which they have been received.  That means the senders needs to maintain an association between sent packet numbers and the path over which these packets were sent.  This is necessary to implement per path congestion control. When a packet is acknowledged, the state of the congestion control MUST be updated for the path where the acknowledged packet was originally sent.  The RTT is calculated based on the delay between the transmission of that packet and its first acknowledgement (see compute-rtt) and is used to update the RTT statistics for the sending path. Also loss detection MUST be adapted to allow for different RTTs on different paths.  For example, timer computations should take into account the RTT of the path on which a packet was sent.  Detections based on packet numbers shall compare a given packet number to the highest packet number received for that path. </del> <ins> If a zero-length connection ID is used, one packet number space for all paths.  That means the packet sequence numbers are allocated from the common number space, so that, for example, packet number N could be sent on one path and packet number N+1 on another. In this case, ACK frames report the numbers of packets that have been received so far, regardless of the path on which they have been received.  That means the senders needs to maintain an association between sent packet numbers and the path over which these packets were sent.  This is necessary to implement per path congestion control, as explained in zero-length-cid-loss-and-congestion. Further, the receiver of packets with zero-length connection IDs should implement handling of acknowledgements as defined in sending- acknowledgements-and-handling-ranges. ECN handing is specified in ecn-handling, and mitigation of the RTT measurement is further explained in ack-delay-and-zero-length-cid- considerations. If a node does not want to implement this logic, it MAY instead limit its use of multiple paths as explained in restricted-sending-to-zero- length-cid-peer. </ins> 7.1.1. <ins> If zero-length CID and therefore also a single packet number space is used by the sender, the receiver MAY send ACK frames instead of ACK_MP frames to reduce overhead as the additional path ID field will anyway always carry the same value. </ins> If senders decide to send packets on paths with different transmission delays, some packets will very likely be received out of order.  This will cause the ACK frames to carry multiple ranges of


The endpoint accepting incoming QUIC connections. <ins> When used without qualification, the tuple of IP version, IP address, UDP protocol, and UDP port number that represents one end of a network path. </ins> An opaque identifier that is used to identify a QUIC connection at an endpoint.  Each endpoint sets a value for its peer to include in packets sent towards the endpoint.


VPNs from residential users as they stopped commuting and switched to work-at-home. <ins> Again, it will be helpful for streaming operators to monitor traffic as described in measure-coll, watching for sudden changes in performance. </ins> 4. Streaming media latency refers to the "glass-to-glass" time duration,


1. <del> QUIC RFC9000 has numerous extension points, including the version number that occupies the second through fifth octets of every long header (see RFC8999).  If experimental versions are rare, and QUIC version 1 constitutes the vast majority of QUIC traffic, there is the potential for middleboxes to ossify on the version octets always being 0x00000001. </del> <ins> QUIC QUIC has numerous extension points, including the version number that occupies the second through fifth octets of every long header (see RFC8999).  If experimental versions are rare, and QUIC version 1 constitutes the vast majority of QUIC traffic, there is the potential for middleboxes to ossify on the version octets always being 0x00000001. </ins> Furthermore, version 1 Initial packets are encrypted with keys derived from a universally known salt, which allow observers to


4.1. <del> (To the editor: check this repository URL after the draft is adopted. The working group may create its own repository) </del> <ins> This document is in the Github repository at: </ins> <del> This document is in the Github repository at https://github.com/GrumpyOldTroll/ietf-mops-drafts.  Readers are welcome to open issues and send pull requests for this document. </del> <ins> https://github.com/ietf-wg-mops/draft-ietf-mops-streaming-opcons Readers are welcome to open issues and send pull requests for this document. </ins> Substantial discussion of this document should take place on the MOPS working group mailing list (mops@ietf.org). <ins> Join: https://www.ietf.org/mailman/listinfo/mops Search: https://mailarchive.ietf.org/arch/browse/mops/ </ins> 4.2. Presentations: IETF 105 BOF: https://www.youtube.com/watch?v=4G3YBVmn9Eo&t=47m21s <del> IETF 106 Mops meeting: https://www.youtube.com/ </del> <ins> IETF 106 meeting: https://www.youtube.com/ </ins> watch?v=4_k340xT2jM&t=7m23s <del> List archive search for doc mentions: https://mailarchive.ietf.org/arch/browse/mops/?q=draft-ietf-mops- streaming-opcons </del> 5. This document requires no actions from IANA.


4.5.2. If the Record has no Unit, the Base Unit is used as the Unit.  Having <del> no Unit and no Base Unit is allowed. </del> <ins> no Unit and no Base Unit is allowed; any information that may be required about units applicable to the value then needs to be provided by the application context. </ins> 4.5.3.


defined in Section 6 of TLS13. A TLS alert is converted into a QUIC connection error.  The <del> AlertDescription value is added to 0x100 to produce a QUIC error code from the range reserved for CRYPTO_ERROR.  The resulting value is sent in a QUIC CONNECTION_CLOSE frame of type 0x1c. </del> <ins> AlertDescription value is added to 0x0100 to produce a QUIC error code from the range reserved for CRYPTO_ERROR.  The resulting value is sent in a QUIC CONNECTION_CLOSE frame of type 0x1c. </ins> QUIC is only able to convey an alert level of "fatal".  In TLS 1.3, the only existing uses for the "warning" level are to signal


private key.  The mechanism proposed in this document allows the delegation to be done off-line, with no per-transaction latency.  The figure below compares the message flows for these two mechanisms with <del> TLS 1.3 I-D.ietf-tls-tls13. </del> <ins> TLS 1.3 I-D.ietf-tls-tls13, where DC is delegated credentials. </ins> These two mechanisms can be complementary.  A server could use credentials for clients that support them, while using LURK to


The public key of the account key pair, encoded as a JSON Web Key object RFC7517. <del> "valid" or "deactivated" </del> <ins> The status of this registration.  Possible values are: "valid", "deactivated", and "revoked". "deactivated" should be used to indicate user initiated deactivation whereas "revoked" should be used to indicate administratively initiated deactivation. </ins> An array of URIs that the server can use to contact the client for issues related to this authorization.  For example, the server may


The DTLSCiphertext structure omits the superfluous version number and type fields. <del> DTLS adds an explicit epoch and sequence number to the TLS record header.  This sequence number allows the recipient to correctly verify the DTLS MAC.  However, the number of bits used for the epoch and sequence number fields in the DTLSCiphertext structure have been reduced. </del> <ins> DTLS adds an epoch and sequence number to the TLS record header. This sequence number allows the recipient to correctly verify the DTLS MAC.  However, the number of bits used for the epoch and sequence number fields in the DTLSCiphertext structure have been reduced. </ins> The DTLSCiphertext structure has a variable length header.


clearer. Session Information ("i="), URI ("u="), Email Address ("e="), <del> Phone Number ("p="), Bandwidth ("b="), Repeat Times ("r="), and Time Zones ("z=") lines are not useful in this context and SHOULD NOT be included. </del> <ins> Phone Number ("p="), Repeat Times ("r="), and Time Zones ("z=") lines are not useful in this context and SHOULD NOT be included. </ins> Encryption Keys ("k=") lines do not provide sufficient security and MUST NOT be included.


who have not implemented WebRTC at all, WebRTC implementations need to be more careful. <del> Consider the case of a call center which accepts calls via RTCWeb. </del> <ins> Consider the case of a call center which accepts calls via WebRTC. </ins> An attacker proxies the call center's front-end and arranges for multiple clients to initiate calls to the call center.  Note that this requires user consent in many cases but because the data channel


messages received. The 3-tuple (Cid, Sender ID, Partial IV) is called Transaction <del> Identifier (Tid), and SHALL be unique for each Base Key. The Tid is used as a unique challenge in the COSE object of the protected CoAP request.  The Tid is part of the Additional Authenticated Data (AAD, see sec-obj-cose) of the protected CoAP response message, which is how responses are bound to requests. </del> <ins> Identifier (Tid), and SHALL be unique for each Master Secret.  The Tid is used as a unique challenge in the COSE object of the protected CoAP request.  The Tid is part of the Additional Authenticated Data (AAD, see sec-obj-cose) of the protected CoAP response message, which is how responses are bound to requests. </ins> 3.2.


performance and functional characteristics; and it can communicate with different remote systems to optimize performance, robustness to failure, or some other metric.  Beyond these, if the API for the <del> system remains the same over time, new protocols and features could be added to the system's implementation without requiring changes in </del> <ins> system remains the same over time, new protocols and features can be added to the system's implementation without requiring changes in </ins> applications for adoption. <del> 3.1. </del> <ins> The normative requirements described here allow Transport Services APIs and Implementations to provide this functionlity without causing incompatibility or introducing security vulnerabilities.  The rest of this document describes the architecture non-normatively. </ins> <del> Functionality that is common across multiple transport protocols ought to be accessible through a unified set of API calls.  An application using a Transport Services API can implement logic for its basic use of transport networking (establishing the transport, and sending and receiving data) once, and expect that implementation to continue to function as the transports change. </del> <ins> 3.1. </ins> <del> As a baseline, any Transport Services API needs to allow access to the distilled minimal set of features offered by transport protocols </del> <ins> Any functionality that is common across multiple transport protocols SHOULD be made accessible through a unified set of Transport Services API calls.  As a baseline, any Transport Services API MUST allow access to the minimal set of features offered by transport protocols </ins> I-D.ietf-taps-minset. <ins> An application can specify constraints and preferences for the protocols, features, and network interfaces it will use via Properties.  A Transport Services API SHOULD offer Properties that are common to multiple transport protocols, in order to enable the system to appropriately select between protocols that offer equivalent features.  Similarly, a Transport Services API SHOULD offer Properties that are applicable to a variety of network layer interfaces and paths, in order to permit racing of different network paths without affecting the applications using the system.  Each Property is expected to have a default value. The default values for Properties SHOULD be selected to ensure correctness for the widest set of applications, while providing the widest set of options for selection.  For example, since both applications that require reliability and those that do not require reliability can function correctly when a protocol provides reliability, reliability ought to be enabled by default.  As another example, the default value for a Property regarding the selection of network interfaces ought to permit as many interfaces as possible. Applications using a Transport Services system interface are REQUIRED to be robust to the automated selection provided by the system, where the automated selection is constrained by the requirements and preferences expressed by the application. </ins> 3.2. There are applications that will need to control fine-grained details of transport protocols to optimize their behavior and ensure compatibility with remote systems.  A Transport Services system <del> therefore ought to also permit more specialized protocol features to be used.  The interface for these specialized options ought to be exposed differently from the common options to ensure flexibility. </del> <ins> therefore SHOULD permit more specialized protocol features to be used. </ins> A specialized feature could be required by an application only when using a specific protocol, and not when using others.  For example,


6.3.2.1. This sub-tree defines the L2VPN service type, according to the <del> several signalling options to exchange membership information between </del> <ins> several signaling options to exchange membership information between </ins> PEs of an L2VPN.  The following signaling options are supported: <del> Refers to the BGP control plane as described in RFC4761 and RFC6624. Refers to the BGP control plane as described in RFC7432 and RFC7209. </del> <ins> The service is a Multipoint VPLSs that use a BGP control plane as described in RFC4761 and RFC6624.  For this L2VPN service, the model allows configuring the Route Distinguisher, the Route Targets, the PWE encapsulation type and the MTU configurations to allow MTU mismatch. The service is a Multipoint VPLSs that use also a BGP control plane but also includes the additional features and related parameters RFC7432 and RFC7209.  The model allows the configuration of the EVPN service interface type, the local and remote VPWS Service Instance (VSI) RFC8214, the EVPN policies for handling MAC addresses and the Ethernet Segment Identifier (ESI) information. </ins> <del> Refers to LDP-signaled pseudowires RFC6074. </del> <ins> A Multipoint VPLSs that use a mesh of LDP-signaled Pseudowires RFC6074.  The model allows configuring the T-LDP PWE type, MTU mismatch and the list of AC and PW bindings. </ins> <del> Refers to L2TP-signaled pseudowires RFC6074. </del> <ins> The L2 VPN uses L2TP-signaled Pseudowires as described in RFC6074. The model allows configuring TBC. </ins> 6.3.2.2.


6.1.2. <ins> Note that this API has multiple ways to constrain and prioritize endpoint candidates based on the network interface: Specifying an interface on a RemoteEndpoint qualifies the scope of the remote endpoint, e.g., for link-local addresses. Specifying an interface on a LocalEndpoint explicitly binds all candidates derived from this endpoint to use the specified interface. Specifying an interface using the "interface" Selection Property (prop-interface) or indirectly via the "pvd" Selection Property (prop-pvd) influences the selection among the available candidates. While specifying an interface on an endpoint restricts the candidates available for connection establishment in the Pre-Establishment Phase, the Selection Properties prioritize and constrain the connection establishment. 6.1.3. </ins> An Endpoint can have an alternative definition when using different protocols.  For example, a server that supports both TLS/TCP and QUIC may be accessible on two different port numbers depending on which


different algorithms such as loss-based CUBIC RFC8312, delay-based COPA or BBR, or even something completely different. <del> We do have experience with deploying new congestion controllers without melting the Internet (CUBIC is one example), but the point mentioned in tcp-behavior about TCP being implemented in operating system kernels is also different with QUIC.  Although QUIC can be implemented in operating system kernels, one of the design goals when this work was chartered was "QUIC is expected to support rapid, distributed development and testing of features", and to meet this expectation, many implementers have chosen to implement QUIC in user space, outside the operating system kernel, and to even distribute QUIC libraries with their own applications. The decision to deploy a new version of QUIC is relatively uncontrolled, compared to other widely used transport protocols, and this can include new transport behaviors that appear without much notice except to the QUIC endpoints.  At IETF 105, Christian Huitema and Brian Trammell presented a talk on "Congestion Defense in Depth" CDiD, that explored potential concerns about new QUIC congestion controllers being broadly deployed without the testing and instrumentation that current major content providers routinely include.  The sense of the room at IETF 105 was that the current major content providers understood what is at stake when they deploy new congestion controllers, but this presentation, and the related discussion in TSVAREA minutes from IETF 105 (tsvarea-105, are still worth a look for new and rapidly growing content providers. </del> <ins> The Internet community does have experience with deploying new congestion controllers without melting the Internet.  As noted in RFC8312, both the CUBIC congestion controller and its predecessor BIC have significantly different behavior from Reno-style congestion controllers such as TCP NewReno RFC6582, but both CUBIC and BIC were added to the Linux kernel in order to allow experimentation and analysis, and both were then selected as the default TCP congestion controllers in Linux, and both were deployed globally. The point mentioned in tcp-behavior about TCP congestion controllers being implemented in operating system kernels is different with QUIC. Although QUIC can be implemented in operating system kernels, one of the design goals when this work was chartered was "QUIC is expected to support rapid, distributed development and testing of features", and to meet this expectation, many implementers have chosen to implement QUIC in user space, outside the operating system kernel, and to even distribute QUIC libraries with their own applications. It is worth noting that streaming operators using HTTP/3, carried over QUIC, can expect more frequent deployment of new congestion controller behavior than has been the case with HTTP/1 and HTTP/2, carried over TCP. </ins> It is worth considering that if TCP-based HTTP traffic and UDP-based HTTP/3 traffic are allowed to enter operator networks on roughly


Endpoints which receive a Capsule with an unknown Capsule Type MUST silently drop that Capsule. <del> Receipt of a CAPSULE HTTP/3 Frame on a stream that is not a client- initiated bidirectional stream MUST be treated as a connection error of type H3_FRAME_UNEXPECTED. CAPSULE frames MUST NOT be sent on a stream before at least one HEADERS frame has been sent on that stream.  This removes the need to buffer capsules when the endpoint needs information from headers to determine how to react to the capsule.  If a CAPSULE frame is received on a stream before a HEADERS frame, the receiver MUST treat this as a connection error of type H3_FRAME_UNEXPECTED. </del> <ins> 4.4. </ins> <del> 4.1. </del> <ins> 4.4.1. </ins> The REGISTER_DATAGRAM_CONTEXT capsule (see iana-types for the value of the capsule type) allows an endpoint to inform its peer of the


Transmit the Welcome message to the other new members <ins> Group IDs SHOULD be constructed in such a way that there's an overwhelmingly low probability of honest group creators generating the same group ID, even without assistance from the Delivery Service. For example, by making the group ID a freshly generated random value of size "KDF.Nh".  The Delivery Service MAY attempt to ensure that group IDs are globally unique by rejecting the creation of new groups with a previously used ID. </ins> The recipient of a Welcome message processes it as described in joining-via-welcome-message.  If application context informs the recipient that the Welcome should reflect the creation of a new group


In pseudocode, this procedure is as follows: <del> decrypt an by reversing this process.  That is, they first parse </del> <ins> decrypt an by reversing this process.  That is, first parse </ins> "enc_response" into "response_nonce" and "ct".  They then follow the <del> same process to derive values for "aead_key" and "aead_nonce". </del> <ins> same process to derive values for "aead_key" and "aead_nonce", using their sending HPKE context, "sctxt", as the HPKE context, "context". </ins> The uses these values to decrypt "ct" using the Open function provided by the AEAD.  Decrypting might produce an error, as follows:


The inner JWS MUST have the same "url" header parameter as the outer JWS. <del> The inner JWS MAY omit the "nonce" header parameter.  The server MUST ignore any value provided for the "nonce" header parameter. </del> <ins> The inner JWS MUST omit the "nonce" header parameter. </ins> This transaction has signatures from both the old and new keys so that the server can verify that the holders of the two keys both


to cases where the Unencrypted Resolver and Designated Resolver have the same IP address. <ins> The constraints on validation of Designated Resolvers specified here apply specifically to the automatic discovery mechanisms defined in this document, which are referred to as Authenticated Discovery and Opportunistic Discovery.  Clients MAY use some other mechanism to validate and use Designated Resolvers discovered using the DNS SVCB record.  However, use of such an alternate mechanism needs to take into account the attack scenarios detailed here. </ins> 8. 8.1.


actually allowed to evict other members; groups can enforce access control policies on top of these basic mechanism. <ins> 4.3. A group comprises a single linear sequence of epochs and groups are generally independent of one-another.  However, it can sometimes be useful to link epochs cryptographically, either within a group or across groups.  MLS derives a resumption pre-shared key (PSK) from each epoch to allow entropy extracted from one epoch to be injected into a future epoch.  This link guarantees that members entering the new epoch agree on a key if and only if were members of the group during the epoch from which the resumption key was extracted. MLS supports two ways to tie a new group to an existing group.  Re- initialization closes one group and creates a new group comprising the same members with different parameters.  Branching starts a new group with a subset of the original group's participants (with no effect on the original group).  In both cases, the new group is linked to the old group via a resumption PSK. Applications may also choose to use resumption PSKs to link epochs in other ways.  For example, the following figure shows a case where a resumption PSK from epoch "n" is injected into epoch "n+k".  This demonstrates that the members of the group at epoch "n+k" were also members at epoch "n", irrespective of any changes to these members' keys due to Updates or Commits. </ins> 5. The protocol uses "ratchet trees" for deriving shared secrets among a


mean skipping rounds, so if PSK is not in use Early Secret will still be HKDF-Extract(0, 0).  For the computation of the binder_secret, the label is "external psk binder key" for external PSKs (those <del> provisioned outside of TLS) and "resumption psk binder key" for resumption PSKs (those provisioned as the resumption master secret of a previous handshake).  The different labels prevent the substitution of one type of PSK for the other. </del> <ins> provisioned outside of TLS) and "res binder" for resumption PSKs (those provisioned as the resumption master secret of a previous handshake).  The different labels prevent the substitution of one type of PSK for the other. </ins> There are multiple potential Early Secret values depending on which PSK the server ultimately selects.  The client will need to compute


filter expression: Its only argument is an instance of "ValueType" (possibly taken from <del> a singular path as in the example above).  The result also is an </del> <ins> a singular query as in the example above).  The result also is an </ins> instance of "ValueType": an unsigned integer or "Nothing". If the argument value is a string, the result is the number of


as a result of racing multiple transports or as part of TCP Fast Open. <ins> Final: when this is true, it means that a transport connection can be closed immediately after its transmission. </ins> Corruption Protection Length: when this is set to any value other than -1, it limits the required checksum in protocols that allow limiting the checksum length (e.g.  UDP-Lite). <del> Immediate Acknowledgement: this informs the implementation that the sender intends to execute tight control over the send buffer, and therefore wants to avoid delayed acknowledgements.  In case of SCTP, a request to immediately send acknowledgements can be implemented using the "sack-immediately flag" described in Section 4.2 of RFC8303 for the SEND.SCTP primitive. Instantaneous Capacity Profile: when this is set to "Interactive/ Low Latency", the Message should be sent immediately, even when this comes at the cost of using the network capacity less efficiently.  For example, small messages can sometimes be bundled to fit into a single data packet for the sake of reducing header overhead; such bundling should not be used.  For example, in case of TCP, the Nagle algorithm should be disabled when Interactive/ Low Latency is selected as the capacity profile.  Scavenger/Bulk can translate into usage of a congestion control mechanism such as LEDBAT, and/or the capacity profile can lead to a choice of a DSCP value as described in I-D.ietf-taps-minset). [Note: See also send-params-non-consensus for additional Send Parameters under discussion.] </del> <ins> Transmission Profile: TBD - because it's not final in the API yet. Old text follows: when this is set to "Interactive/Low Latency", the Message should be sent immediately, even when this comes at the cost of using the network capacity less efficiently.  For example, small messages can sometimes be bundled to fit into a single data packet for the sake of reducing header overhead; such bundling should not be used.  For example, in case of TCP, the Nagle algorithm should be disabled when Interactive/Low Latency is selected as the capacity profile.  Scavenger/Bulk can translate into usage of a congestion control mechanism such as LEDBAT, and/ or the capacity profile can lead to a choice of a DSCP value as described in I-D.ietf-taps-minset). Singular Transmission: when this is true, the application requests to avoid transport-layer segmentation or network-layer fragmentation.  Some transports implement network-layer fragmentation avoidance (Path MTU Discovery) without exposing this functionality to the application; in this case, only transport- layer segmentation should be avoided, by fitting the message into a single transport-layer segment or otherwise failing.  Otherwise, network-layer fragmentation should be avoided--e.g. by requesting the IP Don't Fragment bit to be set in case of UDP(-Lite) and IPv4 (SET_DF in RFC8304). </ins> 5.1.1.2.


characteristics as input for the switching decision or the congestion controller on the new path. <ins> Only the client can actively migrate.  However, servers can indicate during the handshake that they prefer to transfer the connection to a different address after the handshake, e.g. to move from an address that is shared by multiple servers to an address that is unique to the server instance.  The server can provide an IPv4 and an IPv6 address in a transport parameter during the TLS handshake and the client can select between the two if both are provided.  See also Section 9.6 of QUIC. </ins> 8. QUIC connections are closed either by expiration of an idle timeout,


From the client's perspective, a WebTransport session is established when the client receives a 200 response.  From the server's perspective, a session is established once it sends a 200 response. <del> Both endpoints MUST NOT open any streams or send any datagrams on a given session before that session is established.  WebTransport over HTTP/3 does not support 0-RTT. </del> <ins> WebTransport over HTTP/3 does not support 0-RTT. </ins> 3.4.


codepoint in the IP header SHOULD be acknowledged immediately, to reduce the peer's response time to congestion events. <del> 4.2. </del> <ins> 5.2. </ins> For performance reasons, an endpoint can receive incoming packets from the underlying platform in a batch of multiple packets.  This


derivation, as per Section 5.4.3 and Section 7.2.1 of I-D.ietf- lake-edhoc, respectively. <ins> If the applicability statement used in the EDHOC session specifies that EDHOC message_4 shall be sent, the Server MUST stop the EDHOC processing and consider it failed, as due to a client error. </ins> Extract the OSCORE ciphertext from the payload of the EDHOC + OSCORE request, as the value of the second CBOR byte string in the CBOR sequence.


4.2.4. <ins> The direction method returns the last value passed into setDirection. If setDirection has never been called, it returns the direction the transceiver was initialized with. 4.2.5. The currentDirection method returns the last negotiated direction for the transceiver's associated m= section.  More specifically, it returns the RFC3264 directional attribute of the associated m= section in the last applied answer, with "send" and "recv" directions reversed if it was a remote answer.  For example, if the directional attribute for the associated m= section in a remote answer is "recvonly", currentDirection returns "sendonly". If an answer that references this transceiver has not yet been applied, or if the transceiver is stopped, currentDirection returns null. 4.2.6. </ins> The setCodecPreferences method sets the codec preferences of a transceiver, which in turn affect the presence and order of codecs of the associated m= section on future calls to createOffer and


When generating a routable connection ID, the server writes arbitrary bits into its nonce octets, and its provided server ID into the server ID octets.  Servers MAY opt to have a longer connection ID <del> beyond the nonce and server ID.  The nonce and additional bits MAY encode additional information, but SHOULD appear essentially random to observers. </del> <ins> beyond the nonce and server ID.  The additional bits MAY encode additional information, but SHOULD appear essentially random to observers. If the decrypted nonce bits increase monotonically, that guarantees that nonces are not reused between connection IDs from the same server. </ins> The server encrypts the server ID using exactly the algorithm as described in triple-stream-cipher-load-balancer-actions, performing


The certificate and signing key to be used. <del> A Handshake Context based on the hash of the handshake messages </del> <ins> A Handshake Context based on the transcript of the handshake messages </ins> A base key to be used to compute a MAC key.


both were then selected as the default TCP congestion controllers in Linux, and both were deployed globally. <del> The point mentioned in tcp-behavior about TCP congestion controllers being implemented in operating system kernels is different with QUIC. Although QUIC can be implemented in operating system kernels, one of the design goals when this work was chartered was "QUIC is expected to support rapid, distributed development and testing of features," and to meet this expectation, many implementers have chosen to implement QUIC in user space, outside the operating system kernel, and to even distribute QUIC libraries with their own applications. It is worth noting that streaming operators using HTTP/3, carried over QUIC, can expect more frequent deployment of new congestion controller behavior than has been the case with HTTP/1 and HTTP/2, carried over TCP. </del> <ins> The point mentioned in reliable-behavior about TCP congestion controllers being implemented in operating system kernels is different with QUIC.  Although QUIC can be implemented in operating system kernels, one of the design goals when this work was chartered was "QUIC is expected to support rapid, distributed development and testing of features," and to meet this expectation, many implementers have chosen to implement QUIC in user space, outside the operating system kernel, and to even distribute QUIC libraries with their own applications.  It is worth noting that streaming operators using HTTP/3, carried over QUIC, can expect more frequent deployment of new congestion controller behavior than has been the case with HTTP/1 and HTTP/2, carried over TCP. </ins> It is worth considering that if TCP-based HTTP traffic and UDP-based HTTP/3 traffic are allowed to enter operator networks on roughly


"Upgrade". the response SHALL include a single "Upgrade" header with value <del> "masque-udp". </del> <ins> "connect-udp". </ins> the response SHALL NOT include any Transfer-Encoding or Content- Length header fields.


and header protection, as a connection error of type PROTOCOL_VIOLATION.  Discarding such a packet after only removing header protection can expose the endpoint to attacks; see <del> Section 9.3 of QUIC-TLS. </del> <ins> Section 9.5 of QUIC-TLS. </ins> The next bit (0x04) of byte 0 indicates the key phase, which allows a recipient of a packet to identify the packet protection


constrain the types of information for which the trust anchor is authoritative."  The trust anchor may be a certificate or it may be a raw public key along with additional data if necessary such as its <del> public key algorithm and parameters. </del> <ins> public key algorithm and parameters.  In the context of this document, a trust anchor may also be a symmetric key, as in TCG-DICE- SIBDA or the symmetric mode described in I-D.tschofenig-rats-psa- token. </ins> Thus, trusting a Verifier might be expressed by having the Relying <del> Party store the Verifier's public key or certificate in its trust anchor store, or might be expressed by storing the public key or certificate of an entity (e.g., a Certificate Authority) that is in the Verifier's certificate path.  For example, the Relying Party can </del> <ins> Party store the Verifier's key or certificate in its trust anchor store, or might be expressed by storing the public key or certificate of an entity (e.g., a Certificate Authority) that is in the Verifier's certificate path.  For example, the Relying Party can </ins> verify that the Verifier is an expected one by out of band establishment of key material, combined with a protocol like TLS to communicate.  There is an assumption that between the establishment


The output of the decryption is the server ID that the load balancer uses for routing. <del> 4.3.3. </del> <ins> 4.2.3. </ins> When generating a routable connection ID, the server writes arbitrary bits into its nonce octets, and its provided server ID into the


5. Several types of ciphers have been defined for use with TLS and DTLS <del> and the MAC calculation for those ciphers differs slightly. </del> <ins> and the MAC calculations for those ciphers differ slightly. </ins> <del> This specification modifies the MAC calculation defined in RFC6347 and RFC7366 as well as the definition of the additional data used with AEAD ciphers provided in RFC6347 for records with content type </del> <ins> This specification modifies the MAC calculation as defined in RFC6347 and RFC7366, as well as the definition of the additional data used with AEAD ciphers provided in RFC6347, for records with content type </ins> tls12_cid.  The modified algorithm MUST NOT be applied to records that do not carry a CID, i.e., records with content type other than tls12_cid.


3.2. <del> This document focuses on QUIC version 1, and this section applies only to packets belonging to QUIC version 1 flows; for purposes of on-path observation, it assumes that these packets have been identified as such through the observation of a version number exchange as described above. </del> <ins> This document focuses on QUIC version 1, and this Connection Confirmation section applies only to packets belonging to QUIC version 1 flows; for purposes of on-path observation, it assumes that these packets have been identified as such through the observation of a version number exchange as described above. </ins> Connection establishment uses Initial and Handshake packets containing a TLS handshake, and Retry packets that do not contain


7.1.2. <ins> When sending to a zero-length CID receiver, senders may receive acknowledgements that combine packet numbers received over multiple paths.  However, even if one packet number space is used on multiple path the sender MUST maintain separate congestion control state for each path.  Therefore, senders MUST be able to infer the sending path from the acknowledged packet numbers, for example by remembering which packet was sent on what path.  The senders MUST use that information to perform congestion control on the relevant paths, and to correctly estimate the transmission delays on each path.  (See ack-delay-and-zero-length-cid-considerations for specific considerations about using the ACK Delay field of ACK frames, and ecn-handling for issues on using ECN marks.) Loss detection as specified in QUIC-RECOVERY uses algorithms based on timers and on sequence numbers.  When packets are sent over multiple paths, loss detection must be adapted to allow for different RTTs on different paths.  When sending to zero-length CID receivers, packets sent on different paths may be received out of order.  Therefore senders cannot directly use the packet sequence numbers to compute the Packet Thresholds defined in Section 6.1.1 of QUIC-RECOVERY. Relying only on Time Thresholds produces correct results, but is somewhat suboptimal.  Some implementations have been getting good results by not just remembering the path over which a packet was sent, but also maintaining an order list of packets sent on each path.  That ordered list can then be used to compute acknowledgement gaps per path in Packet Threshold tests. 7.1.3. </ins> The ACK Delay field of the ACK frame is relative to the largest acknowledged packet number (see Section 13.2.5 of QUIC-TRANSPORT). When using paths with different transmission delays, the reported


A URL for the certificate that has been issued in response to this application. <del> [[ Open issue: There are two possible behaviors for the CA here. Either (a) the CA automatically issues once all the requirements are fulfilled, or (b) the CA waits for confirmation from the client that it should issue.  If we allow both, we will need a signal in the application object of whether confirmation is required.  I would prefer that auto-issue be the default, which would imply a syntax like "confirm": true ]] [[ Open issue: Should this syntax allow multiple certificates?  That would support reissuance / renewal in a straightforward way, especially if the CSR / notBefore / notAfter could be updated. ]] </del> The elements of the "requirements" array are immutable once set, except for their "status" fields.  If any other part of the object changes after the object is created, the client MUST consider the


7.3.4. <del> This method is indicated by "jws" in the "proof" field.  A JWS RFC7515 object is created as follows: </del> <ins> This method is indicated by the method value "jws".  This method defines no additional parameters.  A JWS RFC7515 object is created as follows: </ins> To protect the request, the JWS header contains the following claims.


An endpoint that receives a NEW_CONNECTION_ID frame with a sequence number smaller than the Retire Prior To field of a previously <del> received NEW_CONNECTION_ID frame MUST immediately send a corresponding RETIRE_CONNECTION_ID frame that retires the newly received connection ID. </del> <ins> received NEW_CONNECTION_ID frame MUST send a corresponding RETIRE_CONNECTION_ID frame that retires the newly received connection ID, unless it has already done so for that sequence number. </ins> 19.16.


MUST be able to dereference or process the key information in order to be able to sign the request. <ins> OPTIONAL.  A set of flags that represent attributes or behaviors of the access token issued by the AS. The values of the "flags" field defined by this specification are as follows: This flag indicates whether the token is bound to the client instance's key.  If the "bearer" flag is present, the access token is a bearer token, and the "key" field in this response MUST be omitted.  If the "bearer" flag is omitted and the "key" field in this response is omitted, the token is bound the request-client in its request for access.  If the "bearer" flag is omitted, and the "key" field is present, the token is bound to the key and proofing mechanism indicated in the "key" field. </ins> OPTIONAL.  Flag indicating a hint of AS behavior on token <del> rotation.  If this flag is set to the value "true", then the client instance can expect a previously-issued access token to continue to work after it has been rotate-access-token or the underlying grant request has been continue-modify, resulting in the issuance of new access tokens.  If this flag is set to the boolean value "false" or is omitted, the client instance can </del> <ins> rotation.  If this flag is present, then the client instance can expect a previously-issued access token to continue to work after it has been rotate-access-token or the underlying grant request has been continue-modify, resulting in the issuance of new access tokens.  If this flag is omitted, the client instance can </ins> anticipate a given access token will stop working after token rotation or grant request modification.  Note that a token flagged as "durable" can still expire or be revoked through any normal


8. This document makes multiple registrations in the registries defined <del> by HTTP3.  The allocations created by this document are all assigned permanent status and list a change controller of the IETF and a contact of the HTTP working group (ietf-http-wg@w3.org). </del> <ins> by RFC9114.  The allocations created by this document are all assigned permanent status and list a change controller of the IETF and a contact of the HTTP working group (ietf-http-wg@w3.org). </ins> 8.1. This document specifies two settings.  The entries in the following table are registered in the "HTTP/3 Settings" registry established in <del> HTTP3. </del> <ins> RFC9114. </ins> For formatting reasons, the setting names here are abbreviated by removing the 'SETTINGS_' prefix.


address on multiple different networks, a Designated Resolver that has been discovered on one network SHOULD NOT be reused on any of the other networks without repeating the discovery process for each <del> network. However, if a given Unencrypted DNS Resolver designates a Designated Resolver that does not use a private or local IP address and can be verified using the mechanism described in verified, it MAY be used on different network connections so long as the subsequent connections over other networks can also be successfully verified using the mechanism described in verified.  This is a tradeoff between performance (by having no delay in establishing an encrypted DNS connection on the new network) and functionality (if the Unencrypted DNS Resolver intends to designate different Designated Resolvers based on the network from which clients connect). </del> <ins> network, since the same IP address may be used for different servers on the different networks. </ins> 4.2.


A key package that is prepublished by a client, which other clients can use to introduce the client to a new group. <del> A long-lived signing key pair used to authenticate the sender of a message. </del> <ins> A signing key pair used to authenticate the sender of a message. </ins> Terminology specific to tree computations is described in ratchet- trees.


2.5.5.2.1. <del> A query by itself in a Logical context is an existence test which </del> <ins> A query by itself in a logical context is an existence test which </ins> yields true if the query selects at least one node and yields false if the query does not select any nodes.


9.2. A more serious problem is MITM proxies which do not support this <del> extension.  RFC8446; Section 9.3 requires that such proxies remove </del> <ins> extension.  RFC8446, Section 9.3 requires that such proxies remove </ins> any extensions they do not understand.  The handshake will then present a certificate based on the public name, without echoing the "encrypted_client_hello" extension to the client.


curves, they SHOULD perform the additional checks specified in Section 7 of <del> 6.1.2. This ciphersuite uses the following primitives: </del> <ins> 6.1.1.2. </ins> <del> Hash function: SHA-256 AEAD: AES-128-GCM When HPKE is used with this ciphersuite, it uses the following algorithms: KEM: 0x0001 = DHKEM(P-256) </del> <ins> Given an octet string X, the private key produced by the Derive-Key- Pair operation is SHA-512(X) truncated to 448 bits (Recall that any 56-octet string is a valid X448 private key).  The corresponding public key is X448(SHA-512(X), 5). </ins> <del> KDF: 0x0001 = HKDF-SHA256 </del> <ins> Implementations SHOULD use the approach specified in RFC7748 to calculate the Diffie-Hellman shared secret.  Implementations MUST check whether the computed Diffie-Hellman shared secret is the all- zero value and abort if so, as described in Section 6 of RFC7748.  If implementers use an alternative implementation of these elliptic curves, they SHOULD perform the additional checks specified in Section 7 of </ins> <del> AEAD: 0x0001 = AES-GCM-128 </del> <ins> 6.1.1.3. </ins> Given an octet string X, the private key produced by the Derive-Key- Pair operation is SHA-256(X), interpreted as a big-endian integer.


attempt prior to receiving the Version Negotiation packet is distinct from the connection with the incompatible version that follows. <ins> Note that this separation across two connections is conceptual: it applies to normative requirements on QUIC connections, but does not require implementations to internally use two distinct connection objects. </ins> 2.5. When the client picks its original version, it will try to avoid


receives an Initial Packet with the first bit to '0', it is a Retry token and the server MUST NOT attempt to validate it.  Instead, it MUST assume the address is validated and MUST extract the Original <del> Destination Connection ID, assuming the format described in nss- service-requirements. </del> <ins> Destination Connection ID and Retry Source Connection ID, assuming the format described in nss-service-requirements. </ins> 6.3.


D.ietf-trans-rfc6962-bis.) The _direct path_ of a root is the empty list, and of any other node <del> is the concatenation of that node with the direct path of its parent. The _copath_ of a node is the list of siblings of nodes in its direct </del> <ins> is the concatenation of that node's parent along with the parent's direct path.  The _copath_ of a node is the node's sibling concatenated with the list of siblings of all the nodes in its direct </ins> path.  The _frontier_ of a tree is the list of heads of the maximal full subtrees of the tree, ordered from left to right. For example, in the below tree: <del> The direct path of C is (C, CD, ABCD) </del> <ins> The direct path of C is (CD, ABCD, ABCDEFG) </ins> The copath of C is (D, AB, EFG)


Servers decrypt an Encapsulated Request by reversing this process. Given an Encapsulated Request "enc_request", a server: <del> 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". </del> <ins> Parses "enc_request" into "keyID", "kemID", "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". </ins> <del> a.  If "keyID" does not identify a key, the server returns an error. </del> <ins> a.  If "keyID" does not identify a key matching the type of "kemID", the server returns an error. </ins> b.  If "kdfID" and "aeadID" identify a combination of KDF and AEAD that the server is unwilling to use with "skR", the server returns


measures appropriate for its value. The degree of protection afforded to this key material can vary by <del> device, based upon considerations as to a cost/benefit evaluation of the intended function of the device.  The confidentiality protection is fundamentally based upon some amount of physical protection: while </del> <ins> the intended function of the device and the specific practices of the device manufacturer or integrator.  The confidentiality protection is fundamentally based upon some amount of physical protection: while </ins> encryption is often used to provide confidentiality when a key is conveyed across a factory, where the attestation key is created or applied, it must be available in an unencrypted form.  The physical


public key for the credential in the "leaf_key_package" of the "path" field. <del> An external commit MUST reference no more than one ExternalInit proposal, and the ExternalInit proposal MUST be supplied by value, not by reference.  When processing a Commit, both existing and new members MUST use the external init secret as described in external-initialization. </del> <ins> When processing a Commit, both existing and new members MUST use the external init secret as described in external-initialization. </ins> The sender type for the MLSPlaintext encapsulating the External Commit MUST be "new_member" <del> If the Add Proposal is also issued by the new member, its member SenderType MUST be "new_member" </del> <ins> In other words, External Commits come in two "flavors" - a "join" commit that adds the sender to the group or a "resync" commit that replaces a member's prior appearance with a new one. Note that the "resync" operation allows an attacker that has compromised a member's signature private key to introduce themselves into the group and remove the prior, legitimate member in a single Commit.  Without resync, this can still be done, but requires two operations, the external Commit to join and a second Commit to remove the old appearance.  Applications for whom this distinction is salient can choose to disallow external commits that contain a Remove, or to allow such resync commits only if they contain a "reinit" PSK proposal that demonstrates the joining member's presence in a prior epoch of the group.  With the latter approach, the attacke would need to compromise the PSK as well as the signing key, but the application will need to ensure that continuing, non-resync'ing members have the required PSK. </ins> 11.2.2.


cryptographic key, we use the term "label" for this usage of either an integer or a string to identify map keys and choice data items. <ins> 1.5. One of the standard issues that is specified in IETF cryptographic algorithms is a requirement that a standard specify a set of minimal algorithms that are required to be implemented.  This is done to promote interoperability as it provides a minimal set of algorithms that all devices can be sure will exist at both ends.  However, we have elected not to specify a set of mandatory algorithms in this document. It is expected that COSE is going to be used in a wide variety of applications and on a wide variety of devices.  Many of the constrained devices are going to be setup to used a small fixed set of algorithms, and this set of algorithms may not match those available on a device.  We therefore have deferred to the application protocols the decision of what to specify for mandatory algorithms. Since the set of algorithms in an environment of constrained devices may depend on what the set of devices are and how long they have been in operation, we want to highlight that application protocols will need to specify some type of discovery method of algorithm capabilities.  The discovery method may be as simple as requiring preconfiguration of the set of algorithms to providing a discovery method built into the protocol.  S/MIME provided a number of different ways to approach the problem: Advertising in the message (S/MIME capabilities) Advertising in the certificate (capabilities extension) Minimum requirements for the S/MIME which have been updated over time </ins> 2. The COSE_MSG structure is a top level CBOR object that corresponds to


In both cases, the new members need information to bootstrap their local group state. <del> New members MUST verify the "signature" using the public key taken from the credential in the leaf node of the ratchet tree with leaf index "signer".  The signature covers the following structure, comprising all the fields in the GroupInfo above "signature": </del> <ins> New members MUST verify that "group_id" is unique among the groups they're currently participating in. New members also MUST verify the "signature" using the public key taken from the leaf node of the ratchet tree with leaf index "signer".  The signature covers the following structure, comprising all the fields in the GroupInfo above "signature": </ins> 13.2.3.1.


much later - in that scenario one endpoint might be aware of the compatibility document while the other may not. <del> When a client creates a QUIC connection, its goal is to use an application layer protocol.  Therefore, when considering which versions are compatible, clients will only consider versions that support one of the intended application layer protocols.  For example, if the client's first flight advertises multiple Application Layer Protocol Negotiation (ALPN) ALPN tokens and multiple compatible versions, the server needs to ensure that the ALPN token that it selects can run over the QUIC version that it selects. </del> 2.3. When the server can parse the client's first flight using the


send more than 255 tickets to clients. Servers that support ticket requests MUST NOT echo "ticket_request" <del> in the EncryptedExtensions. </del> <ins> in the EncryptedExtensions message.  A client MUST abort the connection with an "illegal_parameter" alert if the "ticket_request" extension is present in the EncryptedExtensions message. Clients MUST NOT change the value of TicketRequestContents.count in second ClientHello messages sent in response to a HelloRetryRequest. </ins> 4.


4.2.2. <del> The "manifest" section records a single URL identifying the manifest of the bundle.  The URL MUST refer to a resource with representations contained in the bundle itself. The bundle can contain multiple representations at this URL, and the client is expected to content-negotiate for the best one.  For example, a client might select the one matching an "accept" header of "application/manifest+json" (appmanifest) and an "accept-language" header of "es-419". 4.2.3. </del> The "critical" section consists of the names of sections of the bundle that the client needs to understand in order to load the bundle correctly.  Other sections are assumed to be optional.


references) and are matched against a resolved link target.  Queries for endpoints SHOULD be expressed in path-absolute form if possible and MUST be expressed in URI form otherwise; the RD SHOULD recognize <del> either. </del> <ins> either.  The "anchor" attribute is usable for resource lookups, and, if queried, MUST be for in URI form as well. </ins> Endpoints that are interested in a lookup result repeatedly or continuously can use mechanisms like ETag caching, resource


example, the default port for HTTP/3 QUIC-HTTP is UDP port 443, analogous to HTTP/1.1 or HTTP/2 over TLS over TCP. <del> Applications SHOULD define an alternate endpoint discovery mechanism </del> <ins> Applications should define an alternate endpoint discovery mechanism </ins> to allow the usage of ports other than the default.  For example, HTTP/3 (QUIC-HTTP sections 3.2 and 3.3) specifies the use of ALPN RFC7301 for service discovery which allows the server to use and


5.2.4. <ins> Type: Enum This property specifies whether an application wants to use the connection for sending and/or receiving data.  Possible values are: The connection must support sending and receiving data The connection must support sending data. The connection must support receiving data In case a unidirectional connection is requested, but the system should fall back to bidirectional transport if unidirectional connections are not supported by the transport protocol. 5.2.5. </ins> Type: Preference This property specifies whether an application would like to supply a


SHA-256 MUST be used.  Diversifying EPSK by ImportedIdentity.target_kdf ensures that an IPSK is only used as input keying material to at most one KDF, thus satisfying the <del> requirements in RFC8446. Endpoints generate a compatible ipskx for each target ciphersuite they offer.  For example, importing a key for TLS_AES_128_GCM_SHA256 and TLS_AES_256_GCM_SHA384 would yield two PSKs, one for HKDF-SHA256 and another for HKDF-SHA384.  In contrast, if TLS_AES_128_GCM_SHA256 and TLS_CHACHA20_POLY1305_SHA256 are supported, only one derived key is necessary. The resulting IPSK base key 'ipskx' is then used as the binder key in TLS 1.3 with identity ImportedIdentity.  With knowledge of the supported KDFs, one may import PSKs before the start of a connection. EPSKs may be imported for early data use if they are bound to protocol settings and configurations that would otherwise be required for early data with normal (ticket-based PSK) resumption.  Minimally, that means ALPN, QUIC transport settings, etc., must be provisioned alongside these EPSKs. </del> <ins> requirements in RFC8446.  See security-considerations for more details. Endpoints SHOULD generate a compatible "ipskx" for each target ciphersuite they offer.  For example, importing a key for TLS_AES_128_GCM_SHA256 and TLS_AES_256_GCM_SHA384 would yield two PSKs, one for HKDF-SHA256 and another for HKDF-SHA384.  In contrast, if TLS_AES_128_GCM_SHA256 and TLS_CHACHA20_POLY1305_SHA256 are supported, only one derived key is necessary. EPSKs may be imported before the start of a connection if the target KDFs, protocols, and context string(s) are known a priori.  EPSKs may also be imported for early data use if they are bound to protocol settings and configurations that would otherwise be required for early data with normal (ticket-based PSK) resumption.  Minimally, that means ALPN, QUIC transport parameters (if used for QUIC), etc., must be provisioned alongside these EPSKs. </ins> 4.2. <del> To prevent PSK Importers from being confused with standard out-of- band PSKs, imported PSKs change the PSK binder key derivation label. In particular, the standard TLS 1.3 PSK binder key computation is defined as follows: </del> <ins> To prevent confusion between imported and non-imported PSKs, imported PSKs change the PSK binder key derivation label.  In particular, the standard TLS 1.3 PSK binder key computation is defined as follows: </ins> Imported PSKs replace the string "ext binder" with "imp binder" when <del> deriving "binder_key".  This means the binder key is now computed as </del> <ins> deriving "binder_key".  This means the binder key is computed as </ins> follows: <del> This new label differentiates non-imported and imported external PSKs.  Specifically, a client and server will negotiate use of an </del> <ins> This new label ensures a client and server will negotiate use of an </ins> external PSK if and only if (a) both endpoints import the PSK or (b) neither endpoint imports the PSK.  As "binder_key" is a leaf key, changing its computation does not affect any other key.


A client which supports this document SHALL send an empty "delegated_credential" extension in its ClientHello.  If the client receives a delegated credential without indicating support, then the <del> client SHOULD abort with an "unexpected_message" alert. </del> <ins> client MUST abort with an "unexpected_message" alert. </ins> If the extension is present, the server MAY send a delegated <del> credential extension.  If the extension is not present, the server MUST NOT send a credential.  A credential MUST NOT be provided unless a Certificate message is also sent.  The server MUST ignore the extension unless TLS 1.2 or later is negotiated. When negotiating TLS 1.3, and using delegated credentials, the server MUST send the delegated credential as an extension in the CertificateEntry of its end-entity certificate; the client SHOULD ignore delegated credentials sent as extensions with any other certificate.  When negotiating TLS 1.2, the delegated credential MUST be sent as an extension in the ServerHello. </del> <ins> credential extension; if the extension is not present, the server MUST NOT send a delegated credential.  A delegated credential MUST NOT be provided unless a Certificate message is also sent.  The server MUST ignore the extension unless TLS 1.2 or later is negotiated. When negotiating TLS 1.3, the server MUST send the delegated credential as an extension in the CertificateEntry of its end-entity certificate; the client SHOULD ignore delegated credentials sent as extensions to any other certificate.  When negotiating TLS 1.2, the delegated credential MUST be sent as an extension in the ServerHello. </ins> The delegated credential contains a signature from the public key in the end-entity certificate using a signature algorithm advertised by


1. <ins> Server operators often deploy TLS termination services in locations such as remote data centers or Content Delivery Networks (CDNs) where it may be difficult to detect key compromises.  Short-lived certificates may be used to limit the exposure of keys in these cases. However, short-lived certificates need to be renewed more frequently than long-lived certificates.  If an external CA is unable to issue a certificate in time to replace a deployed certificate, the server would no longer be able to present a valid certificate to clients. With short-lived certificates, there is a smaller window of time to renew a certificates and therefore a higher risk that an outage at a CA will negatively affect the uptime of the service. </ins> Typically, a TLS server uses a certificate provided by some entity other than the operator of the server (a "Certification Authority" or CA) RFC8446 RFC5280.  This organizational separation makes the TLS


Keys (PSKs) in Transport Layer Security (TLS) 1.3 RFC8446.  This guidance also applies to Datagram TLS (DTLS) 1.3 I-D.ietf-tls-dtls13 and Compact TLS 1.3 I-D.ietf-tls-ctls.  For readability, this <del> document uses the term TLS to refer to all such versions.  External PSKs are symmetric secret keys provided to the TLS protocol </del> <ins> document uses the term TLS to refer to all such versions. External PSKs are symmetric secret keys provided to the TLS protocol </ins> implementation as external inputs.  External PSKs are provisioned <del> out-of-band.  This document lists TLS security properties provided by PSKs under certain assumptions and demonstrates how violations of these assumptions lead to attacks.  This document discusses PSK use cases, provisioning processes, and TLS stack implementation support in the context of these assumptions.  This document also provides advice for applications in various use cases to help meet these assumptions. </del> <ins> out-of-band. This document lists TLS security properties provided by PSKs under certain assumptions and demonstrates how violations of these assumptions lead to attacks.  This document discusses PSK use cases, provisioning processes, and TLS stack implementation support in the context of these assumptions.  This document also provides advice for applications in various use cases to help meet these assumptions. </ins> There are many resources that provide guidance for password generation and verification aimed towards improving security.


createOffer to generate new ICE credentials, for the purpose of forcing an ICE restart and kicking off a new gathering phase, in which the new servers will be used.  If the ICE candidate pool has <del> a nonzero size, any existing candidates will be discarded, and new candidates will be gathered from the new servers. </del> <ins> a nonzero size, and a local description has not yet been applied, any existing candidates will be discarded, and new candidates will be gathered from the new servers. </ins> Any change to the ICE candidate policy affects the next gathering phase.  If an ICE gathering phase has already started or


associated with an existing connection, or - for servers - potentially create a new connection. <del> Hosts try to associate a packet with an existing connection.  If the packet has a non-zero-length Destination Connection ID corresponding to an existing connection, QUIC processes that packet accordingly. Note that more than one connection ID can be associated with a connection; see connection-id. </del> <ins> Endpoints try to associate a packet with an existing connection.  If the packet has a non-zero-length Destination Connection ID corresponding to an existing connection, QUIC processes that packet accordingly.  Note that more than one connection ID can be associated with a connection; see connection-id. </ins> If the Destination Connection ID is zero length and the packet <del> matches the local address and port of a connection where the host </del> <ins> matches the local address and port of a connection where the endpoint </ins> used zero-length connection IDs, QUIC processes the packet as part of that connection.


The Initiator SHALL compose message_3 as follows: <del> Compute the transcript hash TH_3 = H(TH_2, CIPHERTEXT_2) where H() </del> <ins> Compute the transcript hash TH_3 = H(TH_2, PLAINTEXT_2) where H() </ins> is the EDHOC hash algorithm of the selected cipher suite.  The transcript hash TH_3 is a CBOR encoded bstr and the input to the <del> hash function is a CBOR Sequence.  Note that H(TH_2, CIPHERTEXT_2) </del> <ins> hash function is a CBOR Sequence.  Note that H(TH_2, PLAINTEXT_2) </ins> can be computed and cached already in the processing of message_2. Compute MAC_3 = EDHOC-KDF( PRK_4x3m, TH_3, "MAC_3", << ID_CRED_I,


member impersonate another group member, but a malicious non-member can reroute handshakes between honest group members to connect them in unintended ways.  A naive sharing of PSKs, even assuming only <del> honest but curious participants know the key, does not enforce any of these properties, bar one.  Endpoint Identity Protection holds vacuously, because the client and server do not use certificates in PSK mode.  (This is not true with use of the "tls_cert_with_extern_psk" extension I-D.ietf-tls-tls13-cert-with- extern-psk.) </del> <ins> honest but curious participants know the key, can violate all these properties, bar one.  Endpoint Identity Protection holds vacuously, because the client and server do not use certificates in PSK mode. (This is not true with use of the "tls_cert_with_extern_psk" extension I-D.ietf-tls-tls13-cert-with-extern-psk.) </ins> In the following sub-sections, we list attacks that demonstrate violations of these properties when the fundamental PSK assumption <del> does not hold.  This list is not exhaustive, but merely highlights a number of potential pitfalls. </del> <ins> does not hold. </ins> 3.1.1.


elements described. TCP RFC0793.  This is used for HTTP/WebSockets, as well as for <del> TURN/SSL and ICE-TCP. </del> <ins> TURN/TLS and ICE-TCP. </ins> For both protocols, IPv4 and IPv6 support is assumed.


an endpoint to use a globally constant length for such connection identifiers.  This can in turn ease parsing and connection lookup, for example by having the length in question be a compile-time <del> constant.  Implementations, which want to use variable-length CIDs, are responsible for constructing the CID in such a way that its length can be determined on reception.  Such implementations must still be able to send CIDs of different length to other parties. Note that there is no CID length information included in the record itself. </del> <ins> constant.  Such implementations MUST still be able to send CIDs of different length to other parties.  Implementations that want to use variable-length CIDs are responsible for constructing the CID in such a way that its length can be determined on reception.  Note that there is no CID length information included in the record itself. </ins> In DTLS 1.2, CIDs are exchanged at the beginning of the DTLS session only.  There is no dedicated "CID update" message that allows new


does not lose any information from the JSON value.  EXI uses the XML types. <del> New entries can be added to the registration by Expert Review as defined in RFC8126.  Experts should exercise their own good judgment but need to consider that shorter labels should have more strict review. </del> <ins> New entries can be added to the registration by either Expert Review or IESG Approval as defined in RFC8126.  Experts should exercise their own good judgment but need to consider that shorter labels should have more strict review.  New entries should not be made that counteract the advice at the end of considerations. </ins> All new SenML labels that have "base" semantics (see senml-base) MUST start with character 'b'.  Regular labels MUST NOT start with that


for each of those names, the values associated with the name by the objects are equal. <del> a comparison using either of the operators "<" or ">" yields true if and only if the comparison is between values of the same type which are both numbers or both strings and which satisfy the comparison: </del> <ins> a comparison using the operator "<" yields true if and only if the comparison is between values of the same type which are both numbers or both strings and which satisfy the comparison: </ins> numbers expected to interoperate as per RFC7493 MUST compare using the normal mathematical ordering; numbers not expected to


in the tree, for the second Add, the next empty leaf to the right, etc. <ins> Validate the KeyPackage: Verify that the signature on the KeyPackage is valid using the public key in the KeyPackage's credential Verify that the following fields in the KeyPackage are unique among the members of the group (including any other members added in the same Commit): "(credential.identity, endpoint_id)" tuple "credential.signature_key" "hpke_init_key" Verify that the KeyPackage is compatible with the group's parameters.  The ciphersuite and protocol version of the KeyPackage must match those in use in the group.  If the GroupContext has a "required_capabilities" extension, then the required extensions and proposals MUST be listed in the KeyPackage's "capabilities" extension. </ins> If necessary, extend the tree to the right until it has at least index + 1 leaves


existing registry for Alerts (defined in RFC8446), with the "DTLS-OK" column being set to "Y". <del> 8.3. IANA is requested to create an entry, ESNI(0xff9f), in the existing registry for Resource Record (RR) TYPEs (defined in RFC6895) with "Meaning" column value being set to "Encrypted SNI". </del> <ins> 9. When operating in Split Mode, backend servers will not have access to PaddedServerNameList.sni or ClientESNIInner.nonce without access to the ESNI keys or a way to decrypt ClientEncryptedSNI.encrypted_sni. One way to address this for a single connection, at the cost of having communication not be unmodified TLS 1.3, is as follows. Assume there is a shared (symmetric) key between the client-facing server and the backend server and use it to AEAD-encrypt Z and send the encrypted blob at the beginning of the connection before the ClientHello.  The backend server can then decrypt ESNI to recover the true SNI and nonce. 10. Alternative approaches to encrypted SNI may be implemented at the TLS or application layer.  In this section we describe several alternatives and discuss drawbacks in comparison to the design in this document. 10.1. 10.1.1. In this variant, TLS Client Hellos are tunneled within early data payloads belonging to outer TLS connections established with the client-facing server.  This requires clients to have established a previous session --- and obtained PSKs --- with the server.  The client-facing server decrypts early data payloads to uncover Client Hellos destined for the backend server, and forwards them onwards as necessary.  Afterwards, all records to and from backend servers are forwarded by the client-facing server - unmodified.  This avoids double encryption of TLS records. Problems with this approach are: (1) servers may not always be able to distinguish inner Client Hellos from legitimate application data, (2) nested 0-RTT data may not function correctly, (3) 0-RTT data may not be supported - especially under DoS - leading to availability concerns, and (4) clients must bootstrap tunnels (sessions), costing an additional round trip and potentially revealing the SNI during the initial connection.  In contrast, encrypted SNI protects the SNI in a distinct Client Hello extension and neither abuses early data nor requires a bootstrapping connection. 10.1.2. In this variant, client-facing and backend servers coordinate to produce "combined tickets" that are consumable by both.  Clients offer combined tickets to client-facing servers.  The latter parse them to determine the correct backend server to which the Client Hello should be forwarded.  This approach is problematic due to non- trivial coordination between client-facing and backend servers for ticket construction and consumption.  Moreover, it requires a bootstrapping step similar to that of the previous variant.  In contrast, encrypted SNI requires no such coordination. 10.2. 10.2.1. In this variant, clients request secondary certificates with CERTIFICATE_REQUEST HTTP/2 frames after TLS connection completion. In response, servers supply certificates via TLS exported authenticators I-D.ietf-tls-exported-authenticator in CERTIFICATE frames.  Clients use a generic SNI for the underlying client-facing server TLS connection.  Problems with this approach include: (1) one additional round trip before peer authentication, (2) non-trivial application-layer dependencies and interaction, and (3) obtaining the generic SNI to bootstrap the connection.  In contrast, encrypted SNI induces no additional round trip and operates below the application layer. 11. The design described here only provides encryption for the SNI, but not for other extensions, such as ALPN.  Another potential design would be to encrypt all of the extensions using the same basic structure as we use here for ESNI.  That design has the following advantages: It protects all the extensions from ordinary eavesdroppers If the encrypted block has its own KeyShare, it does not necessarily require the client to use a single KeyShare, because the client's share is bound to the SNI by the AEAD (analysis needed). It also has the following disadvantages: The client-facing server can still see the other extensions.  By contrast we could introduce another EncryptedExtensions block that was encrypted to the backend server and not the client-facing server. It requires a mechanism for the client-facing server to provide the extension-encryption key to the backend server (as in communicating-sni and thus cannot be used with an unmodified backend server. A conformant middlebox will strip every extension, which might result in a ClientHello which is just unacceptable to the server (more analysis needed). </ins>


the equipment. At minimum, the API MUST provide: (1) the state of captivity and (2) <del> a URI for the Captive Portal Server.  The API SHOULD provide evidence to the caller that it supports the present architecture. </del> <ins> a URI for the Captive Portal Server. A caller to the API needs to be presented with evidence that the content it is receiving is for a version of the API that it supports. For an HTTP-based interaction, such as in I-D.ietf-capport-api this might be achieved by using a content type that is unique to the protocol. </ins> When User Equipment receives Captive Portal Signals, the User Equipment MAY query the API to check the state.  The User Equipment


Networks with no captive portals MAY explicitly indicate this condition by using this option with the IANA-assigned URI for this <del> purpose (see ietf_params_capport-unrestricted).  Clients observing the URI value "urn:ietf:params:capport-unrestricted" MAY forego time- consuming forms of captive portal detection. </del> <ins> purpose (see iana-urn).  Clients observing the URI value "urn:ietf:params:capport-unrestricted" MAY forego time-consuming forms of captive portal detection. </ins> 2.1.


3.6. <del> Section 6 of RFC7231 defines a set of Status Codes in HTTP that are </del> <ins> Section 15 of RFC9110 defines a set of Status Codes in HTTP that are </ins> assigned by the server to indicate whether a request was understood and satisfied, and how to interpret the answer.  Similarly, Section 5.9 of RFC7252 defines the set of Response Codes in CoAP. <del> The status codes consist of three digits (e.g., "404" with HTTP or "4.04" with CoAP) where the first digit expresses the class of the code.  Implementations do not need to understand all status codes, but the class of the code must be understood.  Codes starting with 1 are informational; the request was received and being processed (not </del> <ins> The codes consist of three digits (e.g., "404" with HTTP or "4.04" with CoAP) where the first digit expresses the class of the code. Implementations do not need to understand all codes, but the class of the code must be understood.  Codes starting with 1 are informational; the request was received and being processed (not </ins> available in CoAP).  Codes starting with 2 indicate a successful request.  Codes starting with 3 indicate redirection; further action is needed to complete the request (not available in CoAP).  Codes


This sequence of native DNS wire format records enables easier generation of the data structure on the server and easier verification of the data on client by means of existing DNS library <del> functions.  However this document describes the data structure in sufficient detail that implementers if they desire can write their own code to do this. </del> <ins> functions. </ins> Each RRset in the chain is composed of a sequence of wire format DNS resource records.  The format of the resource record is described in RFC1035, Section 3.2.1. <ins> The resource records that make up a RRset all have the same owner, type and class, but different RDATA as specified RFC2181, Section 5. </ins> Each RRset in the sequence is followed by its associated RRsig record <del> set.  The RRsig record wire format is described in RFC4034, Section 3.1.  The signature portion of the RDATA, as described in the same section, is the following: </del> <ins> set.  This RRset has the same owner and class as the preceding RRset, but has type RRSIG.  The Type Covered field in the RDATA of the RRsigs identifies the type of the preceding RRset as described in RFC4034, Section 3.  The RRsig record wire format is described in RFC4034, Section 3.1.  The signature portion of the RDATA, as described in the same section, is the following: </ins> where RRSIG_RDATA is the wire format of the RRSIG RDATA fields with the Signer's Name field in canonical form and the signature field


Because the integrity check indirectly depends on a sequence number, if record N is not received, then the integrity check on record N+1 will be based on the wrong sequence number and thus <del> will fail.  DTLS solves this problem by adding explicit sequence numbers. </del> <ins> will fail.  DTLS solves this problem by adding sequence numbers. </ins> The TLS handshake is a lock-step cryptographic handshake. Messages must be transmitted and received in a defined order; any


<del> Privacy Pass: HTTP API draft-svaldez-pp-http-api-latest </del> <ins> Privacy Pass HTTP API draft-ietf-privacypass-http-api-latest </ins> Abstract


An application that implements fallback needs to consider the security consequences.  A fallback to TCP and TLS exposes control information to modification and manipulation in the network.  Further <del> downgrades to older TLS versions than used in QUIC, which is 1.3, might result in significantly weaker cryptographic protection.  For example, the results of protocol negotiation RFC7301 only have confidentiality protection if TLS 1.3 is used. </del> <ins> downgrades to older TLS versions than 1.3, which is used in QUIC version 1, might result in significantly weaker cryptographic protection.  For example, the results of protocol negotiation RFC7301 only have confidentiality protection if TLS 1.3 is used. </ins> These applications must operate, perhaps with impaired functionality, in the absence of features provided by QUIC not present in the


of the element and to ensure correct serialization for integrity and authenticity checks. <ins> All CBOR maps in the Manifest and manifest envelope MUST be encoded with the canonical CBOR ordering as defined in RFC8949. </ins> 8.2. The Envelope contains each of the other primary constituent parts of


in that order.  The load balancer uses the server ID octets for routing. <del> 4.4.3. </del> <ins> 4.3.3. </ins> When generating a routable connection ID, the server MUST choose a connection ID length between 17 and 20 octets.  The server writes its


6.1. <del> Appendix A.1 of I-D.ietf-taps-minset explains, using primitives that are described in RFC8303 and RFC8304, how to implement changing the following protocol properties of an established connection with TCP and UDP.  Below, we amend this description for other protocols (if applicable): </del> <ins> Appendix A.1 of I-D.ietf-taps-minset explains, using primitives from RFC8303 and RFC8304, how to implement changing some of the following protocol properties of an established connection with TCP and UDP. Below, we amend this description for other protocols (if applicable) and extend it with Connection Properties that are not contained in I- D.ietf-taps-minset. </ins> <del> Relative niceness: for SCTP, this can be done using the primitive CONFIGURE_STREAM_SCHEDULER.SCTP described in section 4 of RFC8303. Timeout for aborting Connection: for SCTP, this can be done using the primitive CHANGE_TIMEOUT.SCTP described in section 4 of RFC8303. Abort timeout to suggest to the Remote Endpoint: for TCP, this can be done using the primitive CHANGE_TIMEOUT.TCP described in section 4 of RFC8303. </del> <ins> Notification of excessive retransmissions: TODO </ins> Retransmission threshold before excessive retransmission <del> notification: for TCP, this can be done using ERROR.TCP described in section 4 of RFC8303. </del> <ins> notification: TODO; for TCP, this can be done using ERROR.TCP described in section 4 of RFC8303. Notification of ICMP soft error message arrival: TODO </ins> Required minimum coverage of the checksum for receiving: for UDP- Lite, this can be done using the primitive SET_MIN_CHECKSUM_COVERAGE.UDP-Lite described in section 4 of RFC8303. <ins> Priority (Connection): TODO; for SCTP, this can be done using the primitive CONFIGURE_STREAM_SCHEDULER.SCTP described in section 4 of RFC8303. Timeout for aborting Connection: for SCTP, this can be done using the primitive CHANGE_TIMEOUT.SCTP described in section 4 of RFC8303. </ins> Connection group transmission scheduler: for SCTP, this can be done using the primitive SET_STREAM_SCHEDULER.SCTP described in section 4 of RFC8303. <ins> Maximum message size concurrent with Connection establishment: TODO Maximum Message size before fragmentation or segmentation: TODO Maximum Message size on send: TODO Maximum Message size on receive: TODO Capacity Profile: TODO Bounds on Send or Receive Rate: TODO TCP-specific Property: User Timeout: for TCP, this can be configured using the primitive CHANGE_TIMEOUT.TCP described in section 4 of RFC8303. </ins> It may happen that the application attempts to set a Protocol Property which does not apply to the actually chosen protocol.  In this case, the implementation should fail gracefully, i.e., it may


defining a common terminology as well as how each metric should be computed for consistent reporting. <del> 5.6.2. </del> <ins> CTA-5004: Common Media Client Data (CMCD) </ins> Many assume that the CDNs have a holistic view into the health and performance of the streaming clients.  However, this is not the case.


encoded SubjectPublicKeyInfo (SPKI) object carrying pkI.  The SPKI object MUST use the RSASSA-PSS OID RFC5756, which specifies the hash algorithm and salt size.  The salt size MUST match the output size of <del> the hash function associated with the public key and token type. </del> <ins> the hash function associated with the public key and token type.  The parameters field for the digest used in the mask generation function and the digest being signed MUST be omitted. An example sequence of the SPKI object (in ASN.1 format) for a 2048-bit key is below: "$ cat spki.bin | xxd -r -p | openssl asn1parse -dump -inform DER 0:d=0 hl=4 l= 338 cons: SEQUENCE 4:d=1 hl=2 l= 61 cons: SEQUENCE 6:d=2 hl=2 l= 9 prim: OBJECT :rsassaPss 17:d=2 hl=2 l= 48 cons: SEQUENCE 19:d=3 hl=2 l= 13 cons: cont [ 0 ] 21:d=4 hl=2 l= 11 cons: SEQUENCE 23:d=5 hl=2 l= 9 prim: OBJECT :sha384 34:d=3 hl=2 l= 26 cons: cont [ 1 ] 36:d=4 hl=2 l= 24 cons: SEQUENCE 38:d=5 hl=2 l= 9 prim: OBJECT :mgf1 49:d=5 hl=2 l= 11 cons: SEQUENCE 51:d=6 hl=2 l= 9 prim: OBJECT :sha384 62:d=3 hl=2 l= 3 cons: cont [ 2 ] 64:d=4 hl=2 l= 1 prim: INTEGER :30 67:d=1 hl=4 l= 271 prim: BIT STRING " </ins> Since Clients truncate "token_key_id" in each "TokenRequest", Issuers should ensure that the truncated form of new key IDs do not collide


structure, which specify the protocol used to verify and aggregate the clients' measurements: <ins> "nonce": A unique sequence of bytes used to ensure that two otherwise identical "PDAParam" instances will have distinct "PDATaskID"s.  It is RECOMMENDED that this be set to a random 16-byte string derived from a cryptographically secure pseurandom number generator. </ins> "leader_url": The leader's endpoint URL. "helper_url": The helper's endpoint URL.


given that establishing a new connection using 0-RTT support is cheap and fast. <del> QoS mechanisms in the network MAY also use the connection ID for </del> <ins> QoS mechanisms in the network could also use the connection ID for </ins> service differentiation, as a change of connection ID is bound to a change of address which anyway is likely to lead to a re-route on a different path with different network characteristics.


Abstract <del> This document describes an interface for importing external PSK (Pre- Shared Key) into TLS 1.3. </del> <ins> This document describes an interface for importing external Pre- Shared Keys (PSKs) into TLS 1.3. </ins> 1. <del> TLS 1.3 RFC8446 supports pre-shared key (PSK) authentication, wherein </del> <ins> TLS 1.3 RFC8446 supports Pre-Shared Key (PSK) authentication, wherein </ins> PSKs can be established via session tickets from prior connections or externally via some out-of-band mechanism.  The protocol mandates that each PSK only be used with a single hash function.  This was


routing bytes.  The Server ID is unique to each server, and the routing bytes are global. <del> For Obfuscated CID Routing, this consists of the Routing Bits, Divisor, and Modulus.  The Modulus is unique to each server, but the others MUST be global. </del> For Stream Cipher CID Routing, this consists of the Server ID, Server ID Length, Key, and Nonce Length.  The Server ID is unique to each server, but the others MUST be global.  The authentication token MUST


possibility of cross-protocol attacks, but more analysis is still needed here. <del> 9. </del> <ins> 10. </ins> <del> 9.1. </del> <ins> 10.1. </ins> This document registers a new value in the "QUIC Transport Parameters" registry maintained at


6.1. <ins> Within sec-trans, the term "Media Transport Protocol" is used to describe to describe the protocol of interest.  This is easier to understand if the reader assumes a protocol stack that looks something like this: where "Media Format" would be something like an RTP payload format RFC2736 or ISOBMFF ISOBMFF, "Media Transport Protocol" would be something like RTP or HTTP, and "Transport Protocol" would be something like TCP or UDP. Not all possible streaming media applications follow this model, but for the ones that do, it seems useful to have names for the protocol layers between Media Format and Transport Layer It is worth noting explicitly that the Media Transport Protocol and Transport Protocol layers might each include more than one protocol. For example, a Media Transport Protocol might run over HTTP, or over WebTransport, which in turn runs over HTTP. It is worth noting explicitly that more complex network protocol stacks are certainly possible - for instance, packets with this protocol stack may be carried in a tunnel, or in a VPN.  If these environments are present, streaming media operators may need to analyze their effects on applications as well. 6.2. </ins> For most of the history of the Internet, we have trusted UDP-based applications to limit their impact on other users.  One of the strategies used was to use UDP for simple query-response application


specification QUIC-TLS.  This split is performed to enable light- weight versioning with different cryptographic handshakes. <del> 8. </del> <ins> 9. </ins> This document has no actions for IANA. <del> 9. </del> <ins> 10. </ins> See the security considerations in QUIC and QUIC-TLS; the security considerations for the underlying transport protocol are relevant for


Issuer completes the issuance flow by computing a blinded response as follows: <ins> This is encoded and transmitted to the client in the following TokenResponse structure: </ins> The rsabssa_blind_sign function is defined in BLINDRSA, Section 5.1.2..  The Issuer generates an HTTP response with status <del> code 200 whose body consists of "blind_sig", with the content type </del> <ins> code 200 whose body consists of TokenResponse, with the content type </ins> set as "message/token-response". 6.3.


4.1.3.4. Observe RFC7641 is an optional feature.  An implementation MAY <del> support RFC7252 and the OSCORE option without supporting RFC7641. </del> <ins> support RFC7252 and the OSCORE option without supporting RFC7641, in which case the Observe related processing specified in this section, sequence-numbers and processing can be omitted. </ins> The Observe option as used here targets the requirements on forwarding of I-D.hartke-core-e2e-security-reqs (Section 2.2.1). <del> To support proxy operations, 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 request and notifications would not reach the endpoint.  Moreover, intermediaries are allowed to cancel observations at any time; forbidding this behavior would also result in notifications being dropped. An intermediary that supports Observe MUST copy the OSCORE option in the next hop request unchanged.  It is worth noting that 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. </del> <ins> 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. 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. 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. </ins> 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 <del> requested by the client, thereby avoiding unnecessary overhead (processing and transmission of notifications) on the server, since such notifications would not benefit the client. Note that, as defined in Section 3.1 of RFC7641, the target resource for Observe registration is identified by all options in the request that are part of the Cache-Key, including OSCORE.  This means that several clients registering to the same protected resource via an intermediary, when using OSCORE, will be effectively registering to different target resources.  The intermediary may then register to the protected resource (different target resources) once per each client. The processing of the CoAP Code for Observe messages is described in coap-header. </del> <ins> 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. </ins> The Outer Observe option in the CoAP request may be legitimately <del> removed by a proxy or ignored by the server.  In these cases, the </del> <ins> removed by a proxy or ignored by a server.  In these cases, the </ins> 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


L corresponds to the KDF output length of ImportedIdentity.target_kdf as defined in IANA.  For hash-based KDFs, such as HKDF_SHA256(0x0001), this is the length of the hash function output, <del> i.e., 32 octets.  This is required for the IPSK to be of length suitable for supported ciphersuites. </del> <ins> e.g., 32 octets for SHA256.  This is required for the IPSK to be of length suitable for supported ciphersuites.  Internally, HKDF-Expand- Label uses a label corresponding to ImportedIdentity.target_protocol, e.g., "tls13" for TLS 1.3, as per RFC8446, Section 7.1, or "dtls13" for DTLS 1.3, as per I-D.ietf-tls-dtls13, Section 5.10. </ins> The identity of "ipskx" as sent on the wire is ImportedIdentity, i.e., the serialized content of ImportedIdentity is used as the content of PskIdentity.identity in the PSK extension.  The <del> corresponding TLS 1.3 binder key is "ipskx". </del> <ins> corresponding PSK input for the TLS 1.3 key schedule is 'ipskx'. </ins> As the maximum size of the PSK extension is 2^16 - 1 octets, an Imported Identity that exceeds this size is likely to cause a


groupcomm, and it is RECOMMENDED to perform them according to the approach described in I-D.ietf-ace-key-groupcomm-oscore. <ins> 5.3. Different solutions may be selected for secure group communication via a proxy depending on proxy type, use case and deployment requirements.  In this section the options based on Group OSCORE are listed. For a client performing a group communication request via a forward- proxy, end-to-end security should be implemented.  The client then creates a group request protected with Group OSCORE and unicasts this to the proxy.  The proxy adapts the request from a forward-proxy request to a regular request and multicasts this adapted request to the indicated CoAP group.  During the adaptation, the security provided by Group OSCORE persists, in either case of using the group mode or using the pairwise mode.  The first leg of communication from client to proxy can optionally be further protected, e.g., by using (D)TLS and/or OSCORE. For a client performing a group communication request via a reverse- proxy, either end-to-end-security or hop-by-hop security can be implemented.  The case of end-to-end security is the same as for the forward-proxy case. The case of hop-by-hop security is only possible if the proxy can be completely trusted and it is configured as a member of the OSCORE security group(s) that it needs to access, on behalf of clients.  The first leg of communication between client and proxy is then protected with a security method for CoAP unicast, such as (D)TLS, OSCORE or a combination of such methods.  The second leg between proxy and servers is protected using Group OSCORE.  This can be useful in applications where for example the origin client does not implement Group OSCORE, or the group management operations are confined to a particular network domain and the client is outside this domain. For all the above cases, more details on using Group OSCORE are defined in I-D.tiloca-core-groupcomm-proxy. </ins> 6. This section provides security considerations for CoAP group