"a=rid" lines. Each m= section is also checked to ensure prohibited features are <del> not used.  If this is a local description, the "ice-lite" attribute MUST NOT be specified. </del> <ins> not used. </ins> If the RTP/RTCP multiplexing policy is "require", each m= section MUST contain an "a=rtcp-mux" attribute.  If an "m=" section


local description is supplied, and the number of transports currently in use does not match the number of transports needed by the local description, the PeerConnection will create transports as needed and <del> begin gathering candidates for them. </del> <ins> either withdraw an appropriate number of ICE candidates from the candidate pool or begin gathering candidates if sufficient pre- gathered candidates are not available. </ins> If setRemoteDescription was previously called with an offer, and setLocalDescription is called with an answer (provisional or final),


definitions) is closed.  A connection enters the draining state when the idle timeout expires. <del> Each endpoint advertises its own idle timeout to its peer.  The idle timeout starts from the last packet received.  In order to ensure that initiating new activity postpones an idle timeout, an endpoint restarts this timer when sending a packet.  An endpoint does not postpone the idle timeout if another packet has been sent containing frames other than ACK or PADDING, and that other packet has not been acknowledged or declared lost.  Packets that contain only ACK or PADDING frames are not acknowledged until an endpoint has other frames to send, so they could prevent the timeout from being refreshed. </del> <ins> Each endpoint advertises its own idle timeout to its peer.  An enpdpoint restarts any timer it maintains when a packet from its peer is received and processed successfully.  The timer is also restarted when sending a packet containing frames other than ACK or PADDING (an ACK-eliciting packet, see QUIC-RECOVERY), but only if no other ACK- eliciting packets have been sent since last receiving a packet. Restarting when sending packets ensures that connections do not prematurely time out when initiating new activity. </ins> The value for an idle timeout can be asymmetric.  The value advertised by an endpoint is only used to determine whether the


A second approach that was considered but not chosen was to decouple the management of the media control objects from session descriptions, instead offering APIs that would control each component <del> directly.  This was rejected based on a feeling that requiring </del> <ins> directly.  This was rejected based on the argument that requiring </ins> exposure of this level of complexity to the application programmer would not be beneficial; it would result in an API where even a simple example would require a significant amount of code to


The entries in the iana-error-table are registered by this document. <del> Additionally, each code of the format "0x1f * N + 0x21" for integer values of N (that is, "0x21", "0x40", ..., through </del> <ins> Additionally, each code of the format "0x1f * N + 0x21" for non- negative integer values of N (that is, "0x21", "0x40", ..., through </ins> "0x3FFFFFFFFFFFFFFE") MUST NOT be assigned by IANA. 11.2.4.


ESNI extensions (see grease-extensions), which helps ensure the ecosystem handles the values correctly. <del> 7.2.5. </del> <ins> 7.3.5. </ins> This design is not forward secret because the server's ESNI key is static.  However, the window of exposure is bound by the key lifetime.  It is RECOMMENDED that servers rotate keys frequently. <del> 7.2.6. </del> <ins> 7.3.6. </ins> This design permits servers operating in Split Mode to forward connections directly to backend origin servers, thereby avoiding unnecessary MiTM attacks. <del> 7.2.7. </del> <ins> 7.3.7. </ins> Assuming ESNI records retrieved from DNS are validated, e.g., via DNSSEC or fetched from a trusted Recursive Resolver, spoofing a


Indicates that x is repeated zero or more times (and that each instance is length E) <ins> This document uses network byte order (that is, big endian) values. Fields are placed starting from the high-order bits of each byte. </ins> By convention, individual fields reference a complex field by using the name of the complex field.


Environments are designed specifically with claims collection in mind. <del> 4.2. </del> <ins> 4.3. </ins> By definition, the Attester role takes on the duty to create Evidence.  The fact that an Attester role is composed of several


further.  In this case, the immersive content is typically referred to as volumetric media.  One way to represent the volumetric media is to use point clouds, where streaming a single object may easily <del> require a bitrate of 30 Mbps or higher.  Refer to PCC for more details. </del> <ins> require a bitrate of 30 Mbps or higher.  Refer to MPEGI and PCC for more details. </ins> 2.2.


5.1.3. For media m= sections, JSEP endpoints MUST support both the "UDP/TLS/ <del> RTP/SAVPF" and "TCP/TLS/RTP/SAVPF" profiles and MUST indicate one of </del> <ins> RTP/SAVPF" and "TCP/DTLS/RTP/SAVPF" profiles and MUST indicate one of </ins> these two profiles for each media m= line they produce in an offer. <del> For data m= sections, JSEP endpoints must support both the "UDP/TLS/ SCTP" and "TCP/TLS/SCTP" profiles and MUST indicate one of these two </del> <ins> For data m= sections, JSEP endpoints must support both the "UDP/DTLS/ SCTP" and "TCP/DTLS/SCTP" profiles and MUST indicate one of these two </ins> profiles for each data m= line they produce in an offer.  Because ICE can select either TCP or UDP transport depending on network conditions, both advertisements are consistent with ICE eventually


extra cost. Adding a digital signature to each encrypted frame will be an <del> overkill, instead we propose adding signature over N frames. Because some frames could be lost and never delivered, when the signature is sent, it will also send all the hashes it used to calculate the signature, and the recipient client will only use these hashes if they didn't receive the matching frame.  For example Client A sends a signature every 5 frames, so it sends the signature and Hash(Frame1), ...,Hash(Frame5), client B received only frames 1,2,4 and 5.  When B receives the signature and the hashes, it will compute the hashes of frames 1,2,4 and 5 locally and use the received Hash(Frame3) to verify the signature.  It is up to the application to decide what to do when signature verification fails. The signature keys are exchanged out of band along the secret keys. </del> <ins> overkill, instead we propose adding signature over multiple frames. The signature is calculated by contatenating the authentication tags of the frames that the sender wants to authenticate (in reverse sent order) and signing it with the signature key.  Signature keys are exchanged out of band along the secret keys. The authentication tags for the previous frames covered by the signature and the signature itself will be appended at end of the frame, after the current frame authentication tag, in the same order that the signature was calculated, and the SFrame header metadata signature bit (S) will be set to 1. Note that the authentication tag for the current frame will only authenticate the SFrame header and the encrypted payload, ant not the signature nor the previous frames's authentication tags (N-1 to N-M) used to calculate the signature. The last byte (NUM) after the authentication tag list and before the signature indicates the number of the authentication tags from previous frames present in the current frame.  All the authentications tags MUST have the same size, which MUST be equal to the authentication tag size of the current frame.  The signature is fixed size depending on the signature algorithm used (for example, 64 bytes for Ed25519). The receiver has to keep track of all the frames received but yet not verified, by storing the authentication tags of each received frame. When a signature is received, the reciever will verify it with the signature key associated to the key id of the frame the singature was sent in.  If the verification is sucessful, the received will mark the frames as authenticated and remove them from the list of the not verified frames.  It is up to the application to decide what to do when signature verification fails. When using SVC, the hash will be calculated over all the frames of the different spatial layers within the same superframe/picture. However the SFU will be able to drop frames within the same stream (either spatial or temporal) to match target bitrate. If the signature is sent on a frame which layer that is dropped by the SFU, the receiver will not receive it and will not be able to perform the signature of the other received layers. An easy way of solving the issue would be to perform signature only on the base layer or take into consideration the frame dependency graph and send multiple signatures in parallel (each for a branch of the dependency graph). In case of simulcast or K-SVC, each spatial layer sould be authenticated with different signatures to prevent the SFU to discard frames with the signature info. In any case, it is possible that the frame with the signature is lost or the SFU drops it, so the receiver MUST be prepared to not receive a signature for a frame and remove it from the pending to be verified list after a timeout. </ins> 4.


4.3. <del> For any given configuration, the configuration agent must specify if server IDs will be statically or dynamically allocated.  Load Balancer configurations with statically allocated server IDs explicitly include a mapping of server IDs to forwarding addresses. The corresponding server configurations contain one or more unique server IDs. </del> <ins> Load Balancer configurations include a mapping of server IDs to forwarding addresses.  The corresponding server configurations contain one or more unique server IDs. </ins> <del> A dynamically allocated configuration does not have a pre-defined assignment, reducing configuration complexity.  However, it places limits on the maximum server ID length and requires more state at the load balancer.  In certain edge cases, it can force parts of the system to fail over to 5-tuple routing for a short time. In either case, the configuration agent chooses a server ID length for each configuration that MUST be at least one octet.  For Static Allocation, the maximum length depends on the algorithm.  For dynamic allocation, the maximum length is 7 octets. </del> <ins> The configuration agent chooses a server ID length for each configuration that MUST be at least one octet. </ins> A QUIC-LB configuration MAY significantly over-provision the server ID space (i.e., provide far more codepoints than there are servers) to increase the probability that a randomly generated Destination Connection ID is unroutable. <ins> The configuration agent SHOULD provide a means for servers to express the number of server IDs it can usefully employ, because a single routing address actually corresponds to multiple server entities (see lb-chains). </ins> Conceptually, each configuration has its own set of server ID allocations, though two static configurations with identical server ID lengths MAY use a common allocation between them.


of SP-800-56A.  For secp256r1, secp384r1, and secp521r1, at least partial public-key validation MUST be done. <ins> A static Diffie-Hellman key for authentication in method 1, 2 or 3 MUST NOT not be used as a digital signature key for authentication in method 0, unless proven secure by a dedicated cryptographic analysis. A preliminary conjecture is that a minor change to EDHOC may be sufficient to fit the analysis of secure shared signature and ECDH key usage in [Degabriele2011] and [[Thormarker2021]]. </ins> So-called selfie attacks are mitigated as long as the Initiator does not have its own identity in the set of Responder identities it is allowed to communicate with.  In trust on first use (TOFU) use cases


validation. An endpoint MUST NOT increase PMTU based on ICMP messages; see <del> Section 3, clause 6 of DPLPMTUD.  Any reduction in the QUIC maximum packet size in response to ICMP messages MAY be provisional until </del> <ins> Section 3, clause 6 of DPLPMTUD.  Any reduction in QUIC's maximum datagram size in response to ICMP messages MAY be provisional until </ins> QUIC's loss detection algorithm determines that the quoted packet has actually been lost.


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


The extracted server mapping might not correspond to an active server. <del> A field that should be all zeroes after decryption may not be so. </del> Load balancers MUST forward packets with long headers with non- compliant DCIDs to an active server using an algorithm of its own choosing.  It need not coordinate this algorithm with the servers.


(this document) <del> Martin Thomson (martin.thomson@gmail) or the Web Push WG (webpush@ietf.org) </del> <ins> The Web Push WG (webpush@ietf.org) </ins> urn:ietf:params:push:reg


Same as for TLS 1.3. A DTLS 1.3-only client MUST set the legacy_cookie field to zero <del> length. </del> <ins> length.  If a DTLS 1.3 ClientHello is received with any other value in this field, the server MUST abort the handshake with an "illegal_parameter" alert. </ins> Same as for TLS 1.3.


When a path change occurs, e.g., when the IP address of an interface changes or a new interface becomes available, the Transport Services <del> implementation is responsible for notifying the application of the change.  The path change may interrupt connectivity on a path for an active connection or provide an opportunity for a transport that supports multipath or migration to adapt to the new paths. </del> <ins> implementation is responsible for notifying the Protocol Instance of the change.  The path change may interrupt connectivity on a path for an active connection or provide an opportunity for a transport that supports multipath or migration to adapt to the new paths.  Note that, from the Transport Services API point of view, migration is considered a part of multipath connectivity; it is just a limiting policy on multipath usage.  If the "multipath" Selection Property is set to "Disabled", migration is disallowed. </ins> For protocols that do not support multipath or migration, the Protocol Instances should be informed of the path change, but should


Cryptographically, EDHOC does not put requirements on the lower layers.  EDHOC is not bound to a particular transport layer, and can <del> be used in environments without IP.  The transport is responsible to handle message loss, reordering, message duplication, fragmentation, and denial of service protection, where necessary. </del> <ins> be used in environments without IP.  The application using EDHOC is responsible to handle message loss, reordering, message duplication, fragmentation, demultiplex EDHOC messages from other types of messages, and denial of service protection, where necessary. </ins> The Initiator and the Responder need to have agreed on a transport to be used for EDHOC, see applicability.  It is recommended to transport


the namespace used for the TLS-based challenge (the "acme.invalid" namespace for "tls-sni-02"). <del> 10.3. An ACME-based CA will often need to make DNS queries, e.g., to validate control of DNS names.  Because the security of such validations ultimately depends on the authenticity of DNS data, every possible precaution should be taken to secure DNS queries done by the CA.  It is therefore RECOMMENDED that ACME-based CAs make all DNS queries via DNSSEC-validating stub or recursive resolvers.  This provides additional protection to domains which choose to make use of DNSSEC. An ACME-based CA must use only a resolver if it trusts the resolver and every component of the network route by which it is accessed.  It is therefore RECOMMENDED that ACME-based CAs operate their own DNSSEC-validating resolvers within their trusted network and use these resolvers both for both CAA record lookups and all record lookups in furtherance of a challenge scheme (A, AAAA, TXT, etc.). </del> 11.  References 11.1.  URIs


uses Packet Dropping as the mechanisms for throttling SSH Aryan-2012. These are but two examples of a ubiquitous censorship practice. <del> 4.2. </del> <ins> 4.3. </ins> Packet injection, generally, refers to a man-in-the-middle (MITM) network interference technique that spoofs packets in an established


The secret of any other node in the tree is derived from its parent's secret using a call to Derive-App-Secret. <del> If N is a node index in the ASTree then the secrets of the children </del> <ins> If N is a node index in the AS Tree then the secrets of the children </ins> of N are defined to be: <del> Note that fixing concrete values for GroupState_[n] and </del> <ins> Note that fixing concrete values for GroupContext_[n] and </ins> application_secret completely defines all secrets in the AS Tree. 11.2.


interference.  Prescription is the process by which censors determine what types of material they should block, i.e. they decide to block a list of pornographic websites.  Identification is the process by <del> which censors classify specific traffic to be blocked or impaird, </del> <ins> which censors classify specific traffic to be blocked or impaired, </ins> i.e. the censor blocks or impairs all webpages containing "sex" in the title or traffic to sex.com.  Interference is the process by which the censor intercedes in communication and prevents access to


If RTCP mux is indicated, prepare to demux RTP and RTCP from the RTP ICE component, as specified in RFC5761, Section 5.1.1. <del> If RTCP mux is not indicated, but was indicated in a previous description, this MUST result in an error. </del> <ins> If RTCP mux is not indicated, but was previously negotiated, i.e., the RTCP ICE component no longer exists, this MUST result in an error. </ins> For each specified RTP header extension, establish a mapping between the extension ID and URI, as described in section 6 of


caching discusses the relationship between DNS and HTTP response caching. <del> A DNS API server MUST be able to process message/dns request messages. </del> <ins> A DNS API server MUST be able to process application/dns-message request messages. </ins> A DNS API server SHOULD respond with HTTP status code 415 (Unsupported Media Type) upon receiving a media type it is unable to


cryptographic state of the group, this section defines a scheme for generating a hash value (called the "tree hash") that represents the contents of the group's ratchet tree and the members' leaf nodes. <del> The tree hash of a tree is the tree hash of its root node, which we define recursively, starting with the leaves. The tree hash of a leaf node is the hash of leaf's "LeafNodeHashInput" object which might include a "LeafNode" object depending on whether or not it is blank. Now the tree hash of any non-leaf node is recursively defined to be the hash of its "ParentNodeHashInput".  This includes an optional "ParentNode" object depending on whether the node is blank or not. The "left_hash" and "right_hash" fields hold the tree hashes of the node's left and right children, respectively. </del> <ins> The tree hash of an individual node is the hash of the node's "TreeHashInput" object, which may contain either a "LeafNodeHashInput" or a "ParentNodeHashInput" depending on the type of node.  "LeafNodeHashInput" objects contain the "leaf_index" and the "LeafNode" (if any).  "ParentNodeHashInput" objects contain the "ParentNode" (if any) and the tree hash of the node's left and right children. The tree hash of an entire tree corresponds to the tree hash of the root node, which is computed recursively by starting at the leaf nodes and building up. </ins> 8.8.


"AggregateShareReq" is done as follows: where "pk" is the HPKE public key encoded by the collector's HPKE <del> key, and server_role is is "0x02" for the leader and "0x03" for a helper. </del> <ins> key, "server_role" is "0x02" for the leader and "0x03" for a helper. </ins> The collector decrypts these aggregate shares using the opposite process.  Specifically, given an encrypted input share, denoted "enc_share", for a given batch interval, denoted "batch_interval", decryption works as follows: <del> where "sk" is the HPKE secret key, "task_id" is the task ID for a given collect request, and "server_role" is the role of the server that sent the aggregate share ("0x02" for the leader and "0x03" for the helper). </del> <ins> where "sk" is the HPKE secret key, "task_id" is the task ID for the collect request, and "server_role" is the role of the server that sent the aggregate share ("0x02" for the leader and "0x03" for the helper). </ins> 4.4.5.


using SIP for signaling, if one offer is sent and is then canceled using a SIP CANCEL, another offer can be generated even though no answer was received for the first offer.  To support this, the JSEP <del> media layer can provide an offer via the createOffer() method whenever the JavaScript application needs one for the signaling.  The answerer can send back zero or more provisional answers and then finally end the offer/answer exchange by sending a final answer.  The state machine for this is as follows: </del> <ins> media layer can provide an offer via the createOffer method whenever the JavaScript application needs one for the signaling.  The answerer can send back zero or more provisional answers and then finally end the offer/answer exchange by sending a final answer.  The state machine for this is as follows: </ins> Aside from these state transitions, there is no other difference between the handling of provisional ("pranswer") and final ("answer")


section by setting the value of the RtpTransceiver's mid attribute to the MID of the m= section. <del> For each specified payload type that is also supported by the local implementation, establish a mapping between the payload type ID and the actual media format.  [TODO - Justin to add more to explain mapping.]  If any indicated payload type is unknown, it MUST be ignored.  [TODO: should fail on answers] </del> <ins> For each specified media format that is also supported by the local implementation, establish a mapping between the specified payload type and the media format, as described in RFC3264, Section 6.1.  Specifically, this means that the implementation records the payload type to be used in outgoing RTP packets when sending each specified media format, as well as the relative preference for each format that is indicated in their ordering.  If any indicated media format is not supported by the local implementation, it MUST be ignored. </ins> For each specified "rtx" media format, establish a mapping between the RTX payload type and its associated primary payload <del> type, as described in RFC4588.  If any referenced primary payload types are not present, this MUST result in an error. </del> <ins> type, as described in RFC4588, Section 4.  If any referenced primary payload types are not present, this MUST result in an error. </ins> For each specified fmtp parameter that is supported by the <del> local implementation, enable them on the associated payload types. </del> <ins> local implementation, enable them on the associated media formats. For each specified RTP header extension that is also supported by the local implementation, establish a mapping between the extension ID and URI, as described in RFC5285, Section 5. Specifically, this means that the implementation records the extension ID to be used in outgoing RTP packets when sending each specified header extension.  If any indicated RTP header extension is not supported by the local implementation, it MUST be ignored. </ins> For each specified RTCP feedback mechanism that is supported by <del> the local implementation, enable them on the associated payload types. </del> <ins> the local implementation, enable them on the associated media formats. </ins> For any specified "TIAS" bandwidth value, set this value as a constraint on the maximum RTP bitrate to be used when sending


operations on a registration. After the initial registration, the registering endpoint retains the <del> returned location of the Registration Resource for further </del> <ins> returned location of the registration resource for further </ins> operations, including refreshing the registration in order to extend the lifetime and "keep-alive" the registration.  When the lifetime of the registration has expired, the RD SHOULD NOT respond to discovery queries concerning this endpoint.  The RD SHOULD continue to provide <del> access to the Registration Resource after a registration time-out </del> <ins> access to the registration resource after a registration time-out </ins> occurs in order to enable the registering endpoint to eventually refresh the registration.  The RD MAY eventually remove the registration resource for the purpose of garbage collection.  If the <del> Registration Resource is removed, the corresponding endpoint will </del> <ins> registration resource is removed, the corresponding endpoint will </ins> need to be re-registered. <del> The Registration Resource may also be used cancel the registration </del> <ins> The registration resource may also be used cancel the registration </ins> using DELETE, and to perform further operations beyond the scope of this specification. <del> Operations on the Registration Resource are sensitive to reordering; </del> <ins> Operations on the registration resource are sensitive to reordering; </ins> freshness describes how order is restored. <del> The operations on the Registration Resource are described below. </del> <ins> The operations on the registration resource are described below. </ins> 5.3.1.


request of the oblivious request resource that includes the same content.  When it receives a response, it sends a response to the client that includes the content of the response from the oblivious <del> request resource.  When generating a request, the proxy MUST follow the forwarding rules in Section 7.6 of HTTP. </del> <ins> request resource. When forwarding a request, the proxy MUST follow the forwarding rules in Section 7.6 of HTTP.  A generic HTTP intermediary implementation is suitable for the purposes of serving an oblivious proxy resource, but additional care is needed to ensure that client privacy is maintained. Firstly, a generic implementation will forward unknown fields.  For oblivious HTTP, a proxy SHOULD NOT forward unknown fields.  Though clients are not expected to include fields that might contain identifying information, removing unknown fields removes this privacy risk. Secondly, generic implementations are often configured to augment requests with information about the client, such as the Via field or the Forwarded field FORWARDED.  A proxy MUST NOT add information about the client identity when forwarding requests. </ins> A proxy can also generate responses, though it assumed to not be able to examine the content of a request (other than to observe the choice of key identifier, KDF, and AEAD), so it is also assumed that it cannot generate an encapsulated response. <del> A proxy MUST NOT add information about the client identity when forwarding requests.  This includes the Via field, the Forwarded field FORWARDED, and any similar information.  A client does not depend on the proxy using an authenticated and encrypted connection to the oblivious request resource, only that information about the client not be attached to forwarded requests. </del> 7.2.1. As there are privacy benefits from having a large rate of requests


provide credentials to an attacker.  Browsers can authenticate servers but cannot detect cleverly misspelled domains, for example. <del> 5.2. </del> <ins> 6.2. </ins> The solution described here assumes that when the User Equipment needs to trust the API server, server authentication will be performed using TLS mechanisms. <del> 5.3. </del> <ins> 6.3. </ins> The solution described here requires that the API be secured using TLS.  This is required to allow the user equipment and API server to


security considerations for this document. While formally the JSEP interface is an API, it is better to think of <del> it is an Internet protocol, with the JS being untrustworthy from the perspective of the endpoint.  Thus, the threat model of RFC3552 applies.  In particular, JS can call the API in any order and with any inputs, including malicious ones.  This is particularly relevant when we consider the SDP which is passed to setLocalDescription(). While correct API usage requires that the application pass in SDP which was derived from createOffer() or createAnswer(), there is no guarantee that applications do so.  The JSEP implementation MUST be prepared for the JS to pass in bogus data instead. Conversely, the application programmer needs to be aware that the JS does not have complete control of endpoint behavior.  One case that bears particular mention is that editing ICE candidates out of the SDP or suppressing trickled candidates does not have the expected behavior: implementations will still perform checks from those candidates even if they are not sent to the other side.  Thus, for instance, it is not possible to prevent the remote peer from learning your public IP address by removing server reflexive candidates. Applications which wish to conceal their public IP address should instead configure the ICE agent to use only relay candidates. </del> <ins> it is an Internet protocol, with the application JavaScript being untrustworthy from the perspective of the JSEP implementation.  Thus, the threat model of RFC3552 applies.  In particular, JavaScript can call the API in any order and with any inputs, including malicious ones.  This is particularly relevant when we consider the SDP which is passed to setLocalDescription().  While correct API usage requires that the application pass in SDP which was derived from createOffer() or createAnswer(), there is no guarantee that applications do so. The JSEP implementation MUST be prepared for the JavaScript to pass in bogus data instead. Conversely, the application programmer needs to be aware that the JavaScript does not have complete control of endpoint behavior.  One case that bears particular mention is that editing ICE candidates out of the SDP or suppressing trickled candidates does not have the expected behavior: implementations will still perform checks from those candidates even if they are not sent to the other side.  Thus, for instance, it is not possible to prevent the remote peer from learning your public IP address by removing server reflexive candidates.  Applications which wish to conceal their public IP address should instead configure the ICE agent to use only relay candidates. </ins> 9.


The client uses the "signature_algorithms" extension to indicate to the server which signature algorithms may be used in digital <del> signatures.  Clients which desire the server to authenticate via a certificate MUST send this extension.  If a server is authenticating via a certificate and the client has not sent a </del> <ins> signatures.  Clients which desire the server to authenticate itself via a certificate MUST send this extension.  If a server is authenticating via a certificate and the client has not sent a </ins> "signature_algorithms" extension then the server MUST abort the handshake with a "missing_extension" alert (see mti-extensions).


Deployments should take care that the length of the PSK identity is sufficient to avoid obvious collisions. <del> [[OPEN ISSUE: discuss implication of collisions between external and resumption PSKs.]] </del> <ins> 6.1.2. It is possible, though unlikely, that an external PSK identity may clash with a resumption PSK identity.  The TLS stack implementation and sequencing of PSK callbacks influences the application's behaviour when identity collisions occur.  When a server receives a PSK identity in a TLS 1.3 ClientHello, some TLS stacks execute the application's registered callback function before checking the stack's internal session resumption cache.  This means that if a PSK identity collision occurs, the application will be given precedence over how to handle the PSK. </ins> 7.


If the "index" value is equal to the size of the group, increment the size of the group, and extend the tree accordingly <del> Verify the signature on the included UserInitKey; if the signature verification fails, abort </del> <ins> Verify the signature on the included ClientInitKey; if the signature verification fails, abort </ins> Generate a WelcomeInfo object describing the state prior to the add, and verify that its hash is the same as the value of the


7.5. <del> The Signal could inform the User Equipment that it is being held captive.  There is no requirement that the User Equipment do something about this.  Devices MAY permit users to disable automatic reaction to captive-portal indications for privacy reasons.  However, there would be the trade-off that the user doesn't get notified when network access is restricted.  Hence, end-user devices MAY allow users to manually control captive portal interactions, possibly on the granularity of Provisioning Domains. </del> <ins> The Captive Portal Signal could inform the User Equipment that it is being held captive.  There is no requirement that the User Equipment do something about this.  Devices MAY permit users to disable automatic reaction to Captive Portal Signals indications for privacy reasons.  However, there would be the trade-off that the user doesn't get notified when network access is restricted.  Hence, end-user devices MAY allow users to manually control captive portal interactions, possibly on the granularity of Provisioning Domains. </ins>


A token allows a server to correlate activity between the connection where the token was issued and any connection where it is used. <del> Clients that want to break continuity of identity with a server MAY </del> <ins> Clients that want to break continuity of identity with a server can </ins> discard tokens provided using the NEW_TOKEN frame.  In comparison, a token obtained in a Retry packet MUST be used immediately during the connection attempt and cannot be used in subsequent connection


4.1. <ins> When a client discovers Designated Resolvers from an Unencrypted Resolver IP address, it can choose to use these Designated Resolvers either automatically, or based on some other policy, heuristic, or user choice. This document defines two preferred methods to automatically use Designated Resolvers: Authenticated Discovery authenticated, for when a TLS certificate can be used to validate the resolver's identity. Opportunistic Discovery opportunistic, for when a resolver is accessed using a non-public IP address. A client MAY additionally use a discovered Designated Resolver without either of these methods, based on implementation-specific policy or user input.  Details of such policy are out of scope of this document.  Clients SHOULD NOT automatically use a Designated Resolver without some sort of validation, such as the two methods defined in this document or a future mechanism. 4.2. Authenticated Discovery is a mechanism that allows automatic use of a Designated Resolver that supports DNS encryption that performs a TLS handshake. </ins> In order to be considered an authenticated Designated Resolver, the <del> TLS certificate presented by the Encrypted Resolver MUST contain both the domain name (from the SVCB answer) and the IP address of the </del> <ins> TLS certificate presented by the Designated Resolver MUST contain both the domain name (from the SVCB answer) and the IP address of the </ins> designating Unencrypted Resolver within the SubjectAlternativeName certificate field.  The client MUST check the SubjectAlternativeName field for both the Unencrypted Resolver's IP address and the


SetupBaseS() will be, as well as the aad for context.Seal().  The aad might be the entire "transcript" between the client and helper.] <del> [OPEN ISSUE: Is it safe to generate the proof once, then secret-share between each (leader, helper) pair?  Probably not in general, but maybe for Prio?] </del> [OPEN ISSUE: allow server to send joint randomness in UploadStartResp, and then enforce uniqueness via double-spend state or something else (see issue#48).]


streams, and those have stream IDs that are divisible by four.) A variable-length integer indicating the context ID of the <del> datagram (see datagram-contexts). </del> <ins> datagram (see datagram-contexts).  Whether or not this field is present depends on which registration capsules were exchanged on the associated stream: if a REGISTER_DATAGRAM_CONTEXT capsule (see register-capsule) has been sent or received on this stream, then the field is present; if a REGISTER_DATAGRAM_NO_CONTEXT capsule (see register-no-context-capsule) has been sent or received, then this field is absent; if neither has been sent or received, then it is not yet possible to parse this datagram and the receiver MUST either drop that datagram silently or buffer it temporarily while awaiting the registration capsule. </ins> The payload of the datagram, whose semantics are defined by individual applications.  Note that this field can be empty.


BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. <del> This document uses the Augmented BNF defined in HTTP to specify valid protocol elements.  Additionally, it uses the modified "parameter" rule from RFC5987 and the "URI-Template" rule from URI-TEMPLATE. </del> <ins> This specification uses the following terms from STRUCTURED-FIELDS: List, String, Parameter. </ins> 2. <del> The Link-Template header field provides a means for serialising one or more links into HTTP message metadata.  It is semantically equivalent to the Link header field defined in WEB-LINKING, except that it uses URI Templates URI-TEMPLATE to convey the structure of links. </del> <ins> The Link-Template header field is a Structured Field STRUCTURED- FIELDS that serializes one or more links into HTTP message metadata. It is semantically equivalent to the Link header field defined in WEB-LINKING, except that it uses URI Templates URI-TEMPLATE to convey the structure of links. Its value is a List of Strings.  Each String is a URI Template, and Parameters on it carry associated metadata. </ins> For example:


9. <ins> Each protocol that can run as part of a Transport Services implementation defines both its API mapping as well as implementation details. API mappings for a protocol apply most to Connections in which the given protocol is the "top" of the Protocol Stack.  For example, the mapping of the "Send" function for TCP applies to Connections in which the application directly sends over TCP.  If HTTP/2 is used on top of TCP, the HTTP/2 mappings take precendence. Each protocol has a notion of Connectedness.  Possible values for Connectedness are: Unconnected.  Unconnected protocols do not establish explicit state between endpoints, and do not perform a handshake during Connection establishment. Connected.  Connected protocols establish state between endpoints, and perform a handshake during Connection establishment.  The handshake may be 0-RTT to send data or resume a session, but bidirectional traffic is required to confirm connectedness. Multiplexing Connected.  Multiplexing Connected protocols share properties with Connected protocols, but also explictly support opening multiple application-level flows.  This means that they can support cloning new Connection objects without a new explicit handshake. Protocols also define a notion of Data Unit.  Possible values for Data Unit are: Byte-stream.  Byte-stream protocols do not define any Message boundaries of their own apart from the end of a stream in each direction. Datagram.  Datagram protocols define Message boundaries at the same level of transmission, such that only complete (not partial) Messages are supported. Message.  Message protocols support Message boundaries that can be sent and received either as complete or partial Messages.  Maximum Message lengths can be defined, and Messages can be partially reliable. </ins> 9.1. <del> Connection lifetime for TCP translates fairly simply into the the abstraction presented to an application.  When the TCP three-way handshake is complete, its layer of the Protocol Stack can be considered Ready (established).  This event will cause racing of Protocol Stack options to complete if TCP is the top-level protocol, at which point the application can be notified that the Connection is Ready to send and receive. If the application sends a Close, that can translate to a graceful termination of the TCP connection, which is performed by sending a FIN to the remote endpoint.  If the application sends an Abort, then the TCP state can be closed abruptly, leading to a RST being sent to the peer. Without a layer of framing (a top-level protocol in the established Protocol Stack that preserves message boundaries, or an application- supplied deframer) on top of TCP, the receiver side of the transport system implementation can only treat the incoming stream of bytes as a single Message, terminated by a FIN when the Remote Endpoint closes the Connection. </del> <ins> Connectedness: Connected Data Unit: Byte-stream API mappings for TCP are as follows: TCP connections between two hosts map directly to Connection objects. Calling "Initiate" on a TCP Connection causes it to reserve a local port, and send a SYN to the Remote Endpoint. Early idempotent data is sent on a TCP Connection in the SYN, as TCP Fast Open data. A TCP Connection is ready once the three-way handshake is complete. TCP can throw various errors during connection setup. Specifically, it is important to handle a RST being sent by the peer during the handshake. Once established, TCP throws errors whenever the connection is disconnected, such as due to receive a RST from the peer; or hitting a TCP retransmission timeout. Calling "Listen" for TCP binds a local port and prepares it to receive inbound SYN packets from peers. TCP Listeners will deliver new connections once they have replied to an inbound SYN with a SYN-ACK. Calling "Clone" on a TCP Connection creates a new Connection with equivalent parameters.  The two Connections are otherwise independent. TCP does not on its own preserve Message boundaries.  Calling "Send" on a TCP connection lays out the bytes on the TCP send stream without any other delineation.  Any Message marked as Final will cause TCP to send a FIN once the Message has been completely written. TCP delivers a stream of bytes without any Message delineation. All data delivered in the "Received" or "ReceivedPartial" event will be part of a single stream-wide Message that is marked Final (unless a MessageFramer is used).  EndOfMessage will be delivered when the TCP Connection has received a FIN from the peer. Calling "Close" on a TCP Connection indicates that the Connection should be gracefully closed by sending a FIN to the peer and waiting for a FIN-ACK before delivering the "Closed" event. Calling "Abort" on a TCP Connection indicates that the Connection should be immediately closed by sending a RST to the peer. </ins> 9.2. <del> UDP as a direct transport does not provide any handshake or connectivity state, so the notion of the transport protocol becoming Ready or established is degenerate.  Once the system has validated that there is a route on which to send and receive UDP datagrams, the protocol is considered Ready.  Similarly, a Close or Abort has no meaning to the on-the-wire protocol, but simply leads to the local state being torn down. </del> <ins> Connectedness: Unconnected </ins> <del> When sending and receiving messages over UDP, each Message should correspond to a single UDP datagram.  The Message can contain metadata about the packet, such as the ECN bits applied to the packet. </del> <ins> Data Unit: Datagram </ins> <del> 9.3. </del> <ins> API mappings for UDP are as follows: </ins> <del> To support sender-side stream schedulers (which are implemented on the sender side), a receiver-side Transport System should always support message interleaving RFC8260. </del> <ins> UDP connections represent a pair of specific IP addresses and ports on two hosts. </ins> <del> SCTP messages can be very large.  To allow the reception of large messages in pieces, a "partial flag" can be used to inform a (native SCTP) receiving application that a message is incomplete.  After receiving the "partial flag", this application would know that the next receive calls will only deliver remaining parts of the same message (i.e., no messages or partial messages will arrive on other streams until the message is complete) (see Section 8.1.20 in RFC6458).  The "partial flag" can therefore facilitate the implementation of the receiver buffer in the receiving application, at the cost of limiting multiplexing and temporarily creating head- of-line blocking delay at the receiver. </del> <ins> Calling "Initiate" on a UDP Connection causes it to reserve a local port, but does not generate any traffic. </ins> <del> When a Transport System transfers a Message, it seems natural to map the Message object to SCTP messages in order to support properties such as "Ordered" or "Lifetime" (which maps onto partially reliable delivery with a SCTP_PR_SCTP_TTL policy RFC6458).  However, since multiplexing of Connections onto SCTP streams may happen, and would be hidden from the application, the Transport System requires a per- stream receiver buffer anyway, so this potential benefit is lost and the "partial flag" becomes unnecessary for the system. </del> <ins> Early data on a UDP Connection does not have any special meaning. The data is sent whenever the Connection is Ready. </ins> <del> The problem of long messages either requiring large receiver-side buffers or getting in the way of multiplexing is addressed by message interleaving RFC8260, which is yet another reason why a receivers- side transport system supporting SCTP should implement this mechanism. </del> <ins> A UDP Connection is ready once the system has reserved a local port and has a path to send to the Remote Endpoint. </ins> <del> 9.4. </del> <ins> UDP Connections can only generate errors on initiation due to port conflicts on the local system. Once in use, UDP throws errors upon receiving ICMP notifications indicating failures in the network. Calling "Listen" for UDP binds a local port and prepares it to receive inbound UDP datagrams from peers. UDP Listeners will deliver new connections once they have received traffic from a new Remote Endpoint. Calling "Clone" on a UDP Connection creates a new Connection with equivalent parameters.  The two Connections are otherwise independent. Calling "Send" on a UDP connection sends the data as the payload of a complete UDP datagram.  Marking Messages as Final does not change anything in the datagram's contents. UDP only delivers complete Messages to "Received", each of which represents a single datagram received in a UDP packet. Calling "Close" on a UDP Connection releases the local port reservation. Calling "Abort" on a UDP Connection is identical to calling "Close". 9.3. </ins> The mapping of a TLS stream abstraction into the application is <del> equivalent to the contract provided by TCP (see tcp).  The Ready state should be determined by the completion of the TLS handshake, which involves potentially several more round trips beyond the TCP handshake.  The application should not be notified that the Connection is Ready until TLS is established. </del> <ins> equivalent to the contract provided by TCP (see tcp), and builds upon many of the actions of TCP connections. Connectedness: Connected Data Unit: Byte-stream Connection objects represent a single TLS connection running over a TCP connection between two hosts. Calling "Initiate" on a TLS Connection causes it to first initiate a TCP connection.  Once the TCP protocol is Ready, the TLS handshake will be performed as a client (starting by sending a "client_hello", and so on). Early idempotent data is supported by TLS 1.3, and sends encrypted application data in the first TLS message when performing session resumption.  For older versions of TLS, or if a session is not being resumed, the initial data will be delayed until the TLS handshake is complete.  TCP Fast Option can also be enabled automatically. A TLS Connection is ready once the underlying TCP connection is Ready, and TLS handshake is also complete and keys have been established to encrypt application data. In addition to TCP initiation errors, TLS can generate errors during its handshake.  Examples of error include a failure of the peer to successfully authenticate, the peer rejecting the local authentication, or a failure to match versions or algorithms. TLS connections will generate TCP errors, or errors due to failures to rekey or decrypt received messages. Calling "Listen" for TLS listens on TCP, and sets up received connections to perform server-side TLS handshakes. TLS Listeners will deliver new connections once they have successfully completed both TCP and TLS handshakes. As with TCP, calling "Clone" on a TLS Connection creates a new Connection with equivalent parameters.  The two Connections are otherwise independent. Like TCP, TLS does not preserve message boundaries.  Although application data is framed natively in TLS, there is not a general guarantee that these TLS messages represent semantically meaningful application stream boundaries.  Rather, sending data on a TLS Connection only guarantees that the application data will be transmitted in an encrypted form.  Marking Messages as Final causes a "close_notify" to be generated once the data has been written. Like TCP, TLS delivers a stream of bytes without any Message delineation.  The data is decrypted prior to being delivered to the application.  If a "close_notify" is received, the stream-wide Message will be delivered with EndOfMessage set. Calling "Close" on a TLS Connection indicates that the Connection should be gracefully closed by sending a "close_notify" to the peer and waiting for a corresponding "close_notify" before delivering the "Closed" event. Calling "Abort" on a TCP Connection indicates that the Connection should be immediately closed by sending a "close_notify", optionally preceded by "user_canceled", to the peer. Implementations do not need to wait to receive "close_notify" before delivering the "Closed" event. 9.4. DTLS follows the same behavior as TLS (tls), with the notable exception of not inheriting behavior directly from TCP.  Differences from TLS are detailed below, and all cases not explicitly mentioned should be considered the same as TLS. Connectedness: Connected Data Unit: Datagram Connection objects represent a single DTLS connection running over a set of UDP ports between two hosts. Calling "Initiate" on a DTLS Connection causes it reserve a UDP local port, and begin sending handshake messages to the peer over UDP.  These messages are reliable, and will be automatically retransmitted. A DTLS Connection is ready once the TLS handshake is complete and keys have been established to encrypt application data. Sending over DTLS does preserve message boundaries in the same way that UDP datagrams do.  Marking a Message as Final does send a "close_notify" like TLS. Receiving over DTLS delivers one decrypted Message for each received DTLS datagram.  If a "close_notify" is received, a Message will be delivered that is marked as Final. </ins> 9.5.


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


to achieve similar performance.  Those features were introduced to HTTP in HTTP/2 RFC7540.  Earlier versions of HTTP are capable of conveying the semantic requirements of DOH but may result in very <del> poor performance for many uses cases. </del> <ins> poor performance. </ins> 6.3.


ClientHello, MUST contain the ConnectionId structure.  This structure contains the CID value the client wishes the server to use when sending messages to the client.  A zero-length CID value indicates <del> that the client is prepared to send with a CID but does not wish the </del> <ins> that the client is prepared to send using a CID but does not wish the </ins> server to use one when sending. A server willing to use CIDs will respond with a "connection_id" extension in the ServerHello, containing the CID it wishes the client to use when sending messages towards it.  A zero-length value <del> indicates that the server will send with the client's CID but does not wish the client to include a CID. </del> <ins> indicates that the server will send using the client's CID but does not wish the client to include a CID when sending. </ins> Because each party sends the value in the "connection_id" extension it wants to receive as a CID in encrypted records, it is possible for


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


name and the same value, allowing for a trailing "*" wildcard operator as in Section 4.1 of RFC6690.  Attributes that are defined as "link-type" match if the search value matches any of their values <del> (see Section 4.1 of RFC6690; e.g. "?if=core.s" matches ";if="abc core.s";").  A resource link also matches a search criterion if its endpoint would match the criterion, and vice versa, an endpoint link matches a search criterion if any of its resource links matches it. </del> <ins> (see Section 4.1 of RFC6690; e.g. "?if=tag:example.net,2020:sensor" matches ";if="example.regname tag:example.net,2020:sensor";").  A resource link also matches a search criterion if its endpoint would match the criterion, and vice versa, an endpoint link matches a search criterion if any of its resource links matches it. </ins> Note that "href" is a valid search criterion and matches target references.  Like all search criteria, on a resource lookup it can


For each specified RTP header extension, establish a mapping between the extension ID and URI, as described in section 6 of <del> RFC5285.  If any indicated RTP header extension is unknown, this MUST result in an error. </del> <ins> RFC5285.  If any indicated RTP header extension is not supported, this MUST result in an error. </ins> If the MID header extension is supported, prepare to demux RTP data intended for this media section based on the MID header extension, as described in I-D.ietf-mmusic-msid, Section 3.2. <del> For each specified payload type, establish a mapping between the payload type ID and the actual media format, as described in RFC3264.  If any indicated payload type is unknown, this MUST result in an error. </del> <ins> For each specified media format, establish a mapping between the payload type and the actual media format, as described in RFC3264, Section 6.1.  If any indicated media format is not supported, this MUST result in an error. </ins> For each specified "rtx" media format, establish a mapping between the RTX payload type and its associated primary payload


2.2. <del> For several types of events, it is sometimes impossible to tie them to a specific conceptual QUIC connection (e.g., a packet_dropped event triggered because the packet has an unknown connection_id in the header).  Since qlog events in a trace are typically associated with a single connection, it is unclear how to log these events. Ideally, implementers SHOULD create a separate, individual "endpoint- level" trace file (or group_id value), not associated with a specific connection (for example a "server.qlog" or group_id = "client"), and log all events that do not belong to a single connection to this grouping trace.  However, this is not always practical, depending on the implementation.  Because the semantics of most of these events are well-defined in the protocols and because they are difficult to mis-interpret as belonging to a connection, implementers MAY choose to log events not belonging to a particular connection in any other trace, even those strongly associated with a single connection. Note that this can make it difficult to match logs from different vantage points with each other.  For example, from the client side, it is easy to log connections with version negotiation or retry in the same trace, while on the server they would most likely be logged in separate traces.  Servers can take extra efforts (and keep additional state) to keep these events combined in a single trace however (for example by also matching connections on their four-tuple instead of just the connection ID). </del> <ins> A single qlog event trace is typically associated with a single QUIC connection.  However, for several types of events (for example, a transport-packetdropped event with trigger value of "connection_unknown"), it can be impossible to tie them to a specific QUIC connection, especially on the server. There are various ways to handle these events, each making certain tradeoffs between file size overhead, flexibility, ease of use, or ease of implementation.  Some options include: Log them in a separate endpoint-wide trace (or use a special group_id value) not associated with a single connection. Log them in the most recently used trace. Use additional heuristics for connection identification (for example use the four-tuple in addition to the Connection ID). Buffer events until they can be assigned to a connection (for example for version negotiation and retry events). </ins> 3.


compression-induced head-of-line blocking.  See that document for additional details. <ins> To allow for better compression efficiency, the cookie header field RFC6265 MAY be split into separate header fields, each with one or more cookie-pairs, before compression.  If a decompressed header list contains multiple cookie header fields, these MUST be concatenated before being passed into a non-HTTP/2, non-HTTP/3 context, as described in HTTP2, Section 8.1.2.5. </ins> An HTTP/3 implementation MAY impose a limit on the maximum size of the message header it will accept on an individual HTTP message.  A server that receives a larger header field list than it is willing to


Its Capsule Data field consists of: A variable-length integer indicating the context ID of the <del> datagram (see datagram-contexts). </del> <ins> datagram (see datagram-contexts).  Whether or not this field is present depends on which registration capsules were exchanged on the associated stream: if a REGISTER_DATAGRAM_CONTEXT capsule (see register-capsule) has been sent or received on this stream, then the field is present; if a REGISTER_DATAGRAM_NO_CONTEXT capsule (see register-no-context-capsule) has been sent or received, then this field is absent; if neither has been sent or received, then it is not yet possible to parse this datagram and the receiver MUST either drop that datagram silently or buffer it temporarily while awaiting the registration capsule. </ins> The payload of the datagram, whose semantics are defined by individual applications.  Note that this field can be empty.


capitals, as shown here. This document uses the Augmented BNF defined in RFC5234 and updated <del> by RFC7405 along with the "#rule" extension defined in Section 7 of MESSAGING. </del> <ins> by RFC7405 along with the "#rule" extension defined in Section 5.6.1 of SEMANTICS. </ins> <del> The term Origin is to be interpreted as described in RFC6454 section 7. </del> <ins> The term Origin is to be interpreted as described in Section 7 of RFC6454. </ins> <del> The "delta-seconds" rule is defined in CACHING section 1.2.1. </del> <ins> The "delay-seconds" rule is defined in Section 10.2.4 of SEMANTICS. </ins> 2.


Resolvers.  Other protocols can also use the format defined by I- D.schwartz-svcb-dns.  However, if any protocol does not involve some form of certificate validation, new validation mechanisms will need <del> to be defined to support validating equivalence as defined in </del> <ins> to be defined to support validating designation as defined in </ins> authenticated. 4.


identification systems (such as is served by telephone numbers or email addresses in other communications systems). <del> Development of The Universal Solution has proved hard, however, for all the usual reasons. </del> <ins> Development of The Universal Solution has, however, proved hard. </ins> The last few years have also seen a new platform rise for deployment of services: The browser-embedded application, or "Web application".


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


the initiator to demonstrate reachability at its apparent network address. <ins> An attacker can also send faked message_2, message_3, message_4, or error in an attempt to trick the receiving party to send an error message and discontinue the session.  EDHOC implementations MAY evaluate if a received message is likely to have be forged by and attacker and ignore it without sending an error message or discontinuing the session. </ins> 8.6. The availability of a secure random number generator is essential for


Parameters on a templated-link have identical semantics to those of a Link header field.  This includes (but is not limited to) the use of the "rel" parameter to convey the relation type, the "anchor" <del> parameter to modify the context IRI, and so on. </del> <ins> parameter to modify the context IRI, and so on.  Parameter values MUST be Strings. </ins> Likewise, the requirements for parameters on templated-links are the <del> same as those for a Link header field; in particular, the "rel" parameter MUST NOT appear more than once, and if it does, the templated-link MUST be ignored by parsers. </del> <ins> same as those for a Link header field. </ins> This specification defines additional semantics for the "var-base" parameter on templated-links; see below.


information, expiry time, method of providing credentials, security token for validating ICMP messages. <del> This document does not specify the details of the API. </del> <ins> The API MUST use TLS for privacy and server authentication.  The implementation of the API MUST ensure both privacy and integrity of any information provided by or required by it. </ins> <del> The CAPPORT API MUST support TLS for privacy and server authentication. </del> <ins> This document does not specify the details of the API. </ins> 2.4.


The API MUST ensure the integrity of this information, as well as its confidentiality. <ins> An attacker with access to this information might be able to masquerade as a specific User Equipment when interacting with the API, which could then allow them to masquerade as that User Equipment when interacting with the User Portal.  This could give them the ability to determine whether the User Equipment has accessed the portal, or deny the User Equipment service by ending their session using mechanisms provided by the User Portal, or consume that User Equipment's quota.  An attacker with the ability to modify the information could deny service to the User Equipment, or cause them to appear as a different User Equipment. </ins> 7.4. If a Signaling Protocol is implemented, it may be possible for any


bytes.  An endpoint that includes this parameter supports the DATAGRAM frame types and is willing to receive such frames on this connection.  Endpoints MUST NOT send DATAGRAM frames until they have <del> sent and received the max_datagram_frame_size transport parameter. Endpoints MUST NOT send DATAGRAM frames of size strictly larger than the value of max_datagram_frame_size the endpoint has received from its peer.  An endpoint that receives a DATAGRAM frame when it has not sent the max_datagram_frame_size transport parameter MUST terminate the connection with error PROTOCOL_VIOLATION.  An endpoint that receives a DATAGRAM frame that is strictly larger than the value it sent in its max_datagram_frame_size transport parameter MUST terminate the connection with error PROTOCOL_VIOLATION.  Endpoints that wish to use DATAGRAM frames need to ensure they send a max_datagram_frame_size value sufficient to allow their peer to use them.  It is RECOMMENDED to send the value 65536 in the max_datagram_frame_size transport parameter as that indicates to the peer that this endpoint will accept any DATAGRAM frame that fits inside a QUIC packet. </del> <ins> received the max_datagram_frame_size transport parameter.  Endpoints MUST NOT send DATAGRAM frames of size strictly larger than the value of max_datagram_frame_size the endpoint has received from its peer. An endpoint that receives a DATAGRAM frame when it has not sent the max_datagram_frame_size transport parameter MUST terminate the connection with error PROTOCOL_VIOLATION.  An endpoint that receives a DATAGRAM frame that is strictly larger than the value it sent in its max_datagram_frame_size transport parameter MUST terminate the connection with error PROTOCOL_VIOLATION.  Endpoints that wish to use DATAGRAM frames need to ensure they send a max_datagram_frame_size value sufficient to allow their peer to use them.  It is RECOMMENDED to send the value 65536 in the max_datagram_frame_size transport parameter as that indicates to the peer that this endpoint will accept any DATAGRAM frame that fits inside a QUIC packet. The max_datagram_frame_size transport parameter is a unidirectional limit and indication of support of DATAGRAM frames.  Application protocols that use DATAGRAM frames MAY choose to only negotiate and use them in a single direction. </ins> When clients use 0-RTT, they MAY store the value of the server's max_datagram_frame_size transport parameter.  Doing so allows the


6. <del> RFC5246, The Transport Layer Security (TLS) Protocol Version 1.2, suggests that implementations can assume support for MD5 and SHA-1 by their peer.  This update changes the suggestion to assume support for SHA-256 instead, due to MD5 and SHA-1 being deprecated. In Section 7.4.1.4.1: the text should be revised from: OLD: "Note: this is a change from TLS 1.1 where there are no explicit rules, but as a practical matter one can assume that the peer supports MD5 and SHA- 1." NEW: "Note: This is a change from TLS 1.1 where there are no explicit rules, but as a practical matter one can assume that the peer supports SHA-256." 7. </del> The document updates the "TLS SignatureScheme" registry to change the recommended status of SHA-1 based signature schemes to N (not recommended) as defined by RFC8447.  The following entries are to be


will still be HKDF-Extract(0, 0).  For the computation of the binder_key, the label is "ext binder" for external PSKs (those provisioned outside of TLS) and "res binder" for resumption PSKs <del> (those provisioned as the resumption main secret of a previous handshake).  The different labels prevent the substitution of one type of PSK for the other. </del> <ins> (those provisioned as the resumption 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


the connection, the session is terminated. Trade-offs: RST Packet Injection has a few advantages that make it <del> extremely popular is a censorship technique.  RST Packet Injection is </del> <ins> extremely popular as a censorship technique.  RST Packet Injection is </ins> an out-of-band prevention mechanism, allowing the avoidance of the the QoS bottleneck one can encounter with inline techniques such as Packet Dropping.  This out-of-band property allows a censor to


3. <ins> Multiple components in the architecture interact with both the User Equipment and each other.  Since the User Equipment is the focus of these interactions, the components must be able to both identify the user equipment from their interactions with it, and be able to agree on the identify of the user equipment when interacting with each other. The methods by which the components interact restrict the type of information that may be used as an identifying charactertics.  This section discusses the identifying charactersitics. 3.1. An Identifier is a chatacteristic of the User Equipment used by the components of a Captive Portal to uniquely determine which specific User Equipment is interacting with them.  An Identifier MAY be a field contained in packets sent by the User Equipment to the External Network.  Or, an Identifier MAY be an ephemeral property not contained in packets destined for the External Network, but instead correlated with such information through knowledge available to the different components. 3.2. The set of possible identifiers is quite large.  However, in order to be considered a good identifer, an identifier SHOULD meet the following criteria.  Note that the optimal identifier will likely change depending on the positino of the components in the network as well as the information available to them.  An identifier SHOULD: Uniquely Identify the User Equipment Be Hard to Spoof Be Visible to the API Be Visible to the Enforcement Device 3.2.1. In order to uniquely identify the User Equipment, at most one user equipment interacting with the other components of the Captive Portal MUST have a given value of the identifier. Over time, the user equipment identified by the value MAY change. Allowing the identified device to change over time ensures that the space of possible identifying vallues need not be overly large. Independent Captive Portals MAY use the same identifying value to identify different User Equipment.  Allowing indendent captive portals to reuse identifying values allows the identifier to be a property of the local network, expanding the space of possible identifiers. 3.2.2. A good identifier does not lend itself to being easily spoofed.  At no time should it be simple or straightforward for one User Equipment to pretend to be another User Equipment, regardless of whether both are active at the same time.  This property is particularly important when the user equipment is extended externally to devices such as billing systems, or where the identity of the User Equipment could imply liability. 3.2.3. Since the API will need to perform operations which rely on the identify of the user equipment, such as query whether it is captive, the API needs to be able to relate requests to the User Equipment making the request. 3.2.4. The Enforcement Device will decide on a per packet basis whether it should be permitted to communicate with the external network.  Since this decision depends on which User Equipment sent the packet, the Enforcement Device requires that it be able to map the packet to its concept of the User Equipment. 3.3. To evaluate whether an identifer is appropriate, one should consider every recommended property from the perspective of interactions among the components in the architecture.  When comparing identifiers, choose the one which best satifies all of the recommended properties. The architecture does not provide an exact measure of how well an identifier satisfies a given property; care should be taken in performing the evaluation. 3.4. This section provides some examples of identifiers, along with some evaluation of whether they are good identifiers.  The list of identifiers is not exhaustive.  Other identifiers may be used.  An important point to note is that whether the identifiers are good depends heavily on the capabilities of the components and where in the network the components exist. 3.4.1. The physical interface by which the User Equipment is attached to the network can be used to identify the User Equipment.  This identifier has the property of being extremely difficult to spoof: the User Equipment is unaware of the property; one User Equipment cannot manipulate its interactions to appear as though it is another. Further, if only a single User Equipment is attatched to a given physical interface, then the identifier will be unique.  If multiple User Equipment is attached to the network on the same physical interface, then this property is not appropriate. Another consideration related to uniqueness of the User Equipment is that if the attached User Equipment changes, both the API server and the Enforcement Device must invalidate their state related to the User Equipment. The Enforcement Device needs to be aware of the physical interface, which constrains the environment: it must either be part of the device providing physical access (e.g., implemented in firmware), or packets traversing the network must be extended to include information about the source physical interface (e.g.  a tunnel). The API server faces a similar problem, implying that it should co- exist with the Enforcement Device, or that the enforcement device should extend requests to it with the identifying information. 3.4.2. A natural identifier to consider is the IP address of the User Equipment.  At any given time, no device on the network can have the same IP address without causing the network to malfunction, so it is appropriate from the perspective of uniqueness. However, it may be possible to spoof the IP address, particularly for malicious reasons where proper functioning of the network is not necessary for the malicious actor.  Consequently, any solution using the IP address should proactively try to prevent spoofing of the IP address.  Similarily, if the mapping of IP address to User Equipment is changed, the components of the architecture must remove or update their mapping to prevent spoofing.  Demonstrations of return routeability, such as that required for TCP connection establishment, might be sufficient defense against spoofing, though this might not be sufficient in networks that use broadcast media (such as some wireless networks). Since the IP address may traverse multiple segments of the network, more flexibility is afforded to the Enforcement Device and the API server: they simply must exist on a segment of the network where the IP address is still unique.  However, consider that a NAT may be deployed between the User Equipment and the Enforcement Device.  In such cases, it is possible for the components to still uniquely identify the device if they are aware of the port mapping. In some situtations, the User Equipment may have multiple IP addresses, while still satisfying all of the recommended properties. This raises some challenges to the components of the network.  For example, if the user equipment tries to access the network with multiple IP addresses, should the enforcement device and API server treat each IP address as a unique User Equipment, or should it tie the multiple addresses together into one view of the subscriber?  An implementation MAY do either.  Attention should be paid to IPv6 and the fact that it is expected for a device to have multiple IPv6 addresses on a single link.  In such cases, idenfication could be performed by subnet, such as the /64 to which the IP belongs. 4. </ins> This section aims to improve understanding by describing a possible workflow of solutions adhering to the architecture. <del> 3.1. </del> <ins> 4.1. </ins> This section describes a possible work-flow when User Equipment initially joins a Captive Network.


To properly indicate use of DTLS, the <proto> field MUST be set to "UDP/TLS/RTP/SAVPF", as specified in RFC5764, Section 8, if the <del> default candidate uses UDP transport, or "TCP/TLS/RTP/SAVPF", as </del> <ins> default candidate uses UDP transport, or "TCP/DTLS/RTP/SAVPF", as </ins> specified inI-D.nandakumar-mmusic-proto-iana-registration if the default candidate uses TCP transport.


6. <del> Security considerations are enumerated in I-D.ietf-rtcweb-security. </del> <ins> RTCWEB security considerations are enumerated in I-D.ietf-rtcweb- security. Security considerations pertaining to the use of DSCP are enumerated in I-D.ietf-tsvwg-rtcweb-qos. </ins>


ChaCha20 function as defined in Section 2.4 of CHACHA.  This uses a 256-bit key and 16 bytes sampled from the packet protection output. <del> The first 4 bytes of the sampled ciphertext are interpreted as a 32-bit number in little-endian order and are used as the block count. The remaining 12 bytes are interpreted as three concatenated 32-bit numbers in little-endian order and used as the nonce. </del> <ins> The first 4 bytes of the sampled ciphertext are the block counter.  A ChaCha20 implementation could take a 32-bit integer in place of a byte sequence, in which case the byte sequence is interpreted as a little-endian value. The remaining 12 bytes are used as the nonce.  A ChaCha20 implementation might take an array of three 32-bit integers in place of a byte sequence, in which case the nonce bytes are interpreted as a sequence of 32-bit little-endian integers. </ins> The encryption mask is produced by invoking ChaCha20 to protect 5 zero bytes.  In pseudocode:


The number of bits in the IP Address that are used to define the prefix that is being assigned.  This MUST be less than or equal to the length of the IP Address field, in bits.  If the prefix length <del> is equal to the length of the IP Address, the endpoint is only allowed to send packets from a single source address.  If the prefix length is less than the length of the IP address, the endpoint is allowed to send packets from any source address that falls within the prefix. </del> <ins> is equal to the length of the IP Address, the receiver of this capsule is only allowed to send packets from a single source address.  If the prefix length is less than the length of the IP address, the receiver of this capsule is allowed to send packets from any source address that falls within the prefix. </ins> If an endpoint receives multiple ADDRESS_ASSIGN capsules, all of the assigned addresses or prefixes can be used.  For example, multiple


responds with an error status code and a problem document describing the error. <del> 6.3.3. </del> <ins> 6.3.4. </ins> A client may deactivate an account by posting a signed update to the server with a status field of "deactivated."  Clients may wish to do


Preference <del> Prefer </del> <ins> Ignore </ins> This property specifies whether the application needs or prefers to use a transport protocol that preserves message boundaries.


Preconnection, Connection (read only) <del> This property specifies whether the application wishes to use a </del> <ins> This property specifies whether the application needs to use a </ins> transport protocol that ensures that all data is received on the other side without corruption.  This also entails being notified when a Connection is closed or aborted.  The default is to enable Reliable


"supported_signature_algorithms" value: %%% Signature Algorithm Extension enum { // RSASSA-PKCS-v1_5 <del> algorithms.  rsa_pkcs1_sha1 (0x0201), rsa_pkcs1_sha256 (0x0401), </del> <ins> algorithms rsa_pkcs1_sha1 (0x0201), rsa_pkcs1_sha256 (0x0401), </ins> rsa_pkcs1_sha384 (0x0501), rsa_pkcs1_sha512 (0x0601), Note: This production is named "SignatureScheme" because there is


monitor for new push messages. Requesting the delivery of events is particularly important for the <del> Web Push API.  The subscription, management and monitoring functions </del> <ins> W3C Push API.  The subscription, management and monitoring functions </ins> are currently fulfilled by proprietary protocols; these are adequate, but do not offer any of the advantages that standardization affords.


The connection is bi-directional, so requests can be sent both by the entity that established the connection and the remote host. <del> Retransmission and deduplication of messages is provided by the WebSocket protocol.  CoAP over WebSockets therefore does not make a distinction between Confirmable or Non-Confirmable messages, and does not provide Acknowledgement or Reset messages. </del> <ins> As with CoAP over TCP, retransmission and deduplication of messages is provided by the WebSocket protocol.  CoAP over WebSockets therefore does not make a distinction between Confirmable or Non- Confirmable messages, and does not provide Acknowledgement or Reset messages. </ins> 3.4. <del> When a client does not receive any response for some time after sending a CoAP request (or, similarly, when a client observes a resource and it does not receive any notification for some time), the connection between the WebSocket client and the WebSocket server may be lost or temporarily disrupted without the client being aware of it. To check the health of the WebSocket connection (and thereby of all active requests, if any), a client can send a CoAP Ping Signaling message (sec-ping).  WebSocket Ping and unsolicited Pong frames as specified in Section 5.5 of RFC6455 SHOULD NOT be used to ensure that redundant maintenance traffic is not transmitted. There is no way to retransmit a request without creating a new one. Re-registering interest in a resource is permitted, but entirely unnecessary. 3.5. The WebSocket connection is closed as specified in Section 7 of RFC6455. All requests for which the CoAP client has not received a response yet are cancelled when the connection is closed. </del> <ins> As with CoAP over TCP, the client can test the health of the CoAP over WebSocket connection by sending a CoAP Ping Signaling message (sec-ping).  WebSocket Ping and unsolicited Pong frames (Section 5.5 of RFC6455) SHOULD NOT be used to ensure that redundant maintenance traffic is not transmitted. </ins> 4.


This specification does not cover the throttling scope, that may be the given resource-target, its parent path or the whole Origin <del> RFC6454 section 7. </del> <ins> (see Section 7 of RFC6454). </ins> The rate-limit headers may be returned in both Successful and non Successful responses.  This specification does not cover whether


The Transport Services architecture evolves this general model of interaction, aiming to both modernize the API surface presented to applications by the transport layer and enrich the capabilities of <del> the Transport System implementation.  It combines interfaces for </del> <ins> the Transport Services implementation.  It combines interfaces for </ins> multiple interaction patterns into a unified whole.  By combining name resolution with connection establishment and data transfer in a single API, it allows for more flexible implementations to provide


Lastly, if a data channel has been created, a m= section MUST be generated for data.  The <media> field MUST be set to "application" <del> and the <proto> field MUST be set to "UDP/TLS/SCTP" if the default candidate uses UDP transport, or "TCP/TLS/SCTP" if the default </del> <ins> and the <proto> field MUST be set to "UDP/DTLS/SCTP" if the default candidate uses UDP transport, or "TCP/DTLS/SCTP" if the default </ins> candidate uses TCP transport I-D.ietf-mmusic-sctp-sdp.  The "fmt" value MUST be set to the SCTP port number, as specified in Section 4.1.  [TODO: update this to use a=sctp-port, as indicated in


(this document) <del> Martin Thomson (martin.thomson@gmail) or the Web Push WG (webpush@ietf.org) </del> <ins> The Web Push WG (webpush@ietf.org) </ins> urn:ietf:params:push:sub


in compliance with RFC6437, unless the local API does not allow setting IPv6 flow labels. <del> The IPv6 flow label SHOULD be a pseudo-random function of the source and destination addresses, source and destination UDP ports, and the Destination Connection ID field.  The flow label generation MUST be designed to minimize the chances of linkability with a previously used flow label, as a stable flow label would enable correlating activity on multiple paths; see migration-linkability. A possible implementation is to compute the flow label as a cryptographic hash function of the source and destination addresses, source and destination UDP ports, Destination Connection ID field, and a local secret. </del> <ins> The flow label generation MUST be designed to minimize the chances of linkability with a previously used flow label, as a stable flow label would enable correlating activity on multiple paths; see migration- linkability. RFC6437 suggests deriving values using a pseudorandom function to generate flow labels.  Including the Destination Connection ID field in addition to source and destination addresses when generating flow labels ensures that changes are synchronized with changes in other observable identifiers.  A cryptographic hash function that combines these inputs with a local secret is one way this might be implemented. </ins> 10.


6. <del> Prio assumes a powerful adversary with the ability to compromise an unbounded number of clients.  In doing so, the adversary can provide malicious (yet truthful) inputs to the aggregation function.  Prio also assumes that all but one server operates honestly, where a dishonest server does not execute the protocol faithfully as specified.  The system also assumes that servers communicate over secure and mutually authenticated channels.  In practice, this can be done by TLS or some other form of application-layer authentication. In the presence of this adversary, Prio provides two important properties for computing an aggregation function F: Privacy.  The aggregators and collector learn only the output of F computed over all client inputs, and nothing else. Robustness.  As long as the aggregators execute the input- validation protocol correctly, a malicious client can skew the output of F only by reporting false (untruthful) input.  The output cannot be influenced in any other way. There are several additional constraints that a Prio deployment must satisfy in order to achieve these goals: Minimum batch size.  The aggregation batch size has an obvious impact on privacy.  (A batch size of one hides nothing of the input.) Aggregation function choice.  Some aggregation functions leak slightly more than the function output itself. [TODO: discuss these in more detail.] </del> <ins> PPM assumes an active attacker that controls the network and has the ability to statically corrupt any number of clients, aggregators, and collectors.  That is, the attacker can learn the secret state of any party prior to the start of its attack.  For example, it may coerce a client into providing malicious input shares for aggregation or coerce an aggregator into diverting from the protocol specified (e.g., by divulging its input shares to the attacker). In the presence of this adversary, PPM aims to achieve the following high-level secure aggregation goals: Privacy.  Clients trust that some aggregator is honest.  That is, as long as at least one aggregator executes the protocol faithfully, the parties learn nothing beyond the aggregate result (i.e., the output of the aggregation function computed over the honest measurements). Correctness.  The collector trusts that the aggregators execute the protocol correctly.  That is, as long as the aggregators execute the protocol faithfully, a malicious client can skew the aggregate result only by reporting a false (untruthful) measurement.  The result cannot be influenced in any other way. Currently, the specification does not achieve these goals.  In particular, there are several open issues that need to be addressed before these goals are met.  Details for each issue are below. When crafted maliciously, collect requests may leak more information about the measurements than the system intends.  For example, the spec currently allows sequences of collect requests to reveal an aggregate result for a batch smaller than the minimum batch size.  [OPEN ISSUE: See issue#195.  This also has implications for how we solve issue#183.] Even benign collect requests may leak information beyond what one might expect intuitively.  For example, the Poplar1 VDAF VDAF can be used to compute the set of heavy hitters among a set of arbitrary bit strings uploaded by clients.  This requires multiple evaluations of the VDAF, the results of which reveal information to the aggregators and collector beyond what follows from the heavy hitters themselves.  Note that this leakage can be mitigated using differential privacy.  [OPEN ISSUE: We have yet not specified how to add DP.] The core PPM spec does not defend against Sybil attacks.  In this type of attack, the adversary adds to a batch a number of reports that skew the aggregate result in its favor.  For example: The result may reveal additional information about the honest measurements, leading to a privacy violation; or the result may have some property that is desirable to the adversary ("stats poisoning").  The upload sub-protocol includes an extensions mechanism that can be used to prevent -- or at least mitigate -- these types of attacks.  See upload-extensions.  [OPEN ISSUE: No such extension has been implemented, so we're not yet sure if the current mechanism is sufficient.] Attacks may also come from the network.  Thus, it is required that the aggregators and collector communicate with one another over mutually authenticated and confidential channels.  The core PPM spec does not specify such a mechanism beyond requiring server authentication for HTTPS sessions.  Note that clients are not required to authenticate themselves.  [OPEN ISSUE: It might be better to be prescriptive about leader authentication in leader- helper channels and collector authenticaiton in collector-leader channels.  For the latter we have issue#155.] </ins> 6.1. <ins> [OPEN ISSUE: This subsection is a bit out-of-date.] </ins> In this section, we enumerate the actors participating in the Prio system and enumerate their assets (secrets that are either inherently valuable or which confer some capability that enables further attack


optimization requires some care in implementation, since it can cause premature PTOs under packet loss when "ignore_order" is enabled. <del> 8. </del> <ins> 9. </ins> There are tradeoffs inherent in a sender sending an ACK_FREQUENCY frame to the receiver.  As such it is recommended that implementers


5.2. The solution described here assumes that when the User Equipment <del> needs to trust the API server, server authentication will be utilized using TLS mechanisms. </del> <ins> needs to trust the API server, server authentication will be performed using TLS mechanisms. </ins> 5.3. <ins> The solution described here requires that the API be secured using TLS.  This is required to allow the user equipment and API server to exchange secrets which can be used to validate future interactions. The API must ensure the integrity of this information, as well as its confidentiality. 5.4. </ins> It is possible for any user on the Internet to send ICMP packets in an attempt to cause the receiving equipment to go to the captive portal.  This has been considered and addressed in the following


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


Servers SHOULD NOT increase the QUIC MAX_STREAM_ID limit after sending a GOAWAY frame. <del> Once GOAWAY is sent, the server MUST reject requests sent on streams with an identifier greater than or equal to the indicated last Stream ID.  Clients MUST NOT send new requests on the connection after receiving GOAWAY, although requests might already be in transit.  A new connection can be established for new requests. If the client has sent requests on streams with a Stream ID greater than or equal to that indicated in the GOAWAY frame, those requests are considered rejected (request-cancellation).  Clients SHOULD cancel any requests on streams above this ID.  Servers MAY also reject requests on streams below the indicated ID if these requests were not processed. </del> <ins> Clients MUST NOT send new requests on the connection after receiving GOAWAY; a new connection MAY be established to send additional requests. Some requests might already be in transit.  If the client has already sent requests on streams with a Stream ID greater than or equal to that indicated in the GOAWAY frame, those requests will not be processed and MAY be retried by the client on a different connection. The client MAY cancel these requests.  It is RECOMMENDED that the server explicitly reject such requests (see request-cancellation) in order to clean up transport state for the affected streams. </ins> Requests on Stream IDs less than the Stream ID in the GOAWAY frame <del> might have been processed; their status cannot be known until they are completed successfully, reset individually, or the connection terminates. </del> <ins> might have been processed; their status cannot be known until a response is received, the stream is reset individually, or the connection terminates.  Servers MAY reject individual requests on streams below the indicated ID if these requests were not processed. </ins> Servers SHOULD send a GOAWAY frame when the closing of a connection is known in advance, even if the advance notice is small, so that the


"vdaf_verify_key" is the VDAF verification key shared by the aggregators; "agg_id" is the aggregator ID ("0x00" for the Leader and <del> "0x01" for the helper); and "agg_param" is the opaque aggregation parameter distributed to the aggregtors by the collector. </del> <ins> "0x01" for the helper); "agg_param" is the opaque aggregation parameter distributed to the aggregtors by the collector; "public_share" is the public share generated by the client and distributed to each aggregator; and "input_share" is the aggregator's input share. </ins> If either step fails, the aggregator marks the report as invalid with error "vdaf-prep-error".  Otherwise, the value "out" is interpreted


by applying an Appraisal Policy for Evidence to assess the trustworthiness of the Attester, and generates Attestation Results for use by Relying Parties.  The Appraisal Policy for Evidence might <del> be obtained from an Endorser along with the Endorsements, or might be obtained via some other mechanism such as being configured in the Verifier by an administrator. </del> <ins> be obtained from an Endorser along with the Endorsements, and/or might be obtained via some other mechanism such as being configured in the Verifier by the Verifier Owner. </ins> The Relying Party uses Attestation Results by applying its own Appraisal Policy to make application-specific decisions such as authorization decisions.  The Appraisal Policy for Attestation <del> Results might, for example, be configured in the Relying Party by an administrator. </del> <ins> Results is configured in the Relying Party by the Relying Party Owner, and/or is programmed into the Relying Party. </ins> 4.1.


but not the requested action. The client cannot always know a priori if an Authorized Resource <del> Request will succeed.  If the client repeatedly gets error responses containing AS Creation Hints (cf.  Section 5.1.2 of I-D.ietf-ace- oauth-authz as response to its requests, it SHOULD request a new access token from the authorization server in order to continue communication with the resource server. </del> <ins> Request will succeed.  It must check the validity of its keying material before sending a request or processing a response.  If the client repeatedly gets error responses containing AS Creation Hints (cf.  Section 5.1.2 of I-D.ietf-ace-oauth-authz as response to its requests, it SHOULD request a new access token from the authorization server in order to continue communication with the resource server. </ins> Unauthorized requests that have been received over a DTLS session SHOULD be treated as non-fatal by the RS, i.e., the DTLS session