The Path Maximum Transmission Unit (PMTU) is the maximum size of the entire IP packet including the IP header, UDP header, and UDP <del> payload.  The UDP payload includes the QUIC packet header, protected payload, and any authentication fields.  The PMTU can depend on path characteristics, and can therefore change over time.  The largest UDP payload an endpoint sends at any given time is referred to as the endpoint's maximum packet size. </del> <ins> payload.  The UDP payload includes one or more QUIC packet headers and protected payloads.  The PMTU can depend on path characteristics, and can therefore change over time.  The largest UDP payload an endpoint sends at any given time is referred to as the endpoint's maximum datagram size. </ins> An endpoint SHOULD use DPLPMTUD (dplpmtud) or PMTUD (pmtud) to determine whether the path to a destination will support a desired <del> maximum packet size without fragmentation.  In the absence of these mechanisms, QUIC endpoints SHOULD NOT send IP packets larger than the smallest allowed maximum packet size. </del> <ins> maximum datagram size without fragmentation.  In the absence of these mechanisms, QUIC endpoints SHOULD NOT send datagrams larger than the smallest allowed maximum datagram size. </ins> <del> Both DPLPMTUD and PMTUD send IP packets that are larger than the current maximum packet size, referred to as PMTU probes.  All QUIC </del> <ins> Both DPLPMTUD and PMTUD send datagrams that are larger than the current maximum datagram size, referred to as PMTU probes.  All QUIC </ins> packets that are not sent in a PMTU probe SHOULD be sized to fit <del> within the maximum packet size to avoid the packet being fragmented or dropped (RFC8085). </del> <ins> within the maximum datagram size to avoid the datagram being fragmented or dropped (RFC8085). </ins> If a QUIC endpoint determines that the PMTU between any pair of local and remote IP addresses has fallen below the smallest allowed maximum <del> packet size of 1200 bytes, it MUST immediately cease sending QUIC </del> <ins> datagram size of 1200 bytes, it MUST immediately cease sending QUIC </ins> packets, except for those in PMTU probes or those containing CONNECTION_CLOSE frames, on the affected path.  An endpoint MAY terminate the connection if an alternative path cannot be found. Each pair of local and remote addresses could have a different PMTU. QUIC implementations that implement any kind of PMTU discovery <del> therefore SHOULD maintain a maximum packet size for each combination of local and remote IP addresses. </del> <ins> therefore SHOULD maintain a maximum datagram size for each combination of local and remote IP addresses. </ins> A QUIC implementation MAY be more conservative in computing the <del> maximum packet size to allow for unknown tunnel overheads or IP </del> <ins> maximum datagram size to allow for unknown tunnel overheads or IP </ins> header options/extensions. 14.2.1. Path Maximum Transmission Unit Discovery (PMTUD; RFC1191, RFC8201) relies on reception of ICMP messages (e.g., IPv6 Packet Too Big <del> messages) that indicate when a packet is dropped because it is larger than the local router MTU.  DPLPMTUD can also optionally use these messages.  This use of ICMP messages is potentially vulnerable to off-path attacks that successfully guess the addresses used on the </del> <ins> messages) that indicate when an IP packet is dropped because it is larger than the local router MTU.  DPLPMTUD can also optionally use these messages.  This use of ICMP messages is potentially vulnerable to off-path attacks that successfully guess the addresses used on the </ins> path and reduce the PMTU to a bandwidth-inefficient value. An endpoint MUST ignore an ICMP message that claims the PMTU has <del> decreased below the minimum QUIC packet size. </del> <ins> decreased below QUIC's smallest allowed maximum datagram size. </ins> The requirements for generating ICMP (RFC1812, RFC4443) state that the quoted packet should contain as much of the original packet as


RETIRE_CONNECTION_ID frames and retransmitted if the packet containing them is lost. <ins> NEW_TOKEN frames are retransmitted if the packet containing them is lost.  No special support is made for detecting reordered and duplicated NEW_TOKEN frames other than a direct comparison of the frame contents. </ins> PING and PADDING frames contain no information, so lost PING or PADDING frames do not require repair.


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


multiple documents. Maintaining multiple documents in the same repository can add <del> overheads that negatively affect individual documents.  For instance, </del> <ins> overhead that negatively affects individual documents.  For instance, </ins> issues might require additional markings to identify the document that they affect.  Also, because editors all have write access to the repository, managing the set of people with write access to a larger


performed on an ongoing basis, resulting in routine, or even event- driven, collection of basic endpoint information. <del> See "Data Attribute Tables and Definitions" for information-specific details. </del> <ins> See data-attribute-table for information-specific details. </ins> 4.2.


events: Ready<> occurs when a Connection created with Initiate() or <del> InitiateWithIdempotentData() transitions to Established state. </del> <ins> InitiateWithSend() transitions to Established state. </ins> ConnectionReceived<> occurs when a Connection created with Listen() transitions to Established state.


2.1. If the application server wishes to provide contact details it MAY <del> include an "sub" (Subject) claim in the JWT.  The "sub" claim SHOULD </del> <ins> include a "sub" (Subject) claim in the JWT.  The "sub" claim SHOULD </ins> include a contact URI for the application server as either a "mailto:" (email) RFC6068 or an "https:" RFC2818 URI.


directly communicating with an Issuer.  Depending on the attestation, Attesters can store state about a Client, such as the number of overall tokens issued thus far.  As an example of an issuance <del> protocol, in the original Privacy Pass protocol PPSRV, tokens were </del> <ins> protocol, in the original Privacy Pass protocol PPEXT, tokens were </ins> only issued to Clients that solved CAPTCHAs.  In this context, the Attester attested that some client solved a CAPTCHA and the resulting token produced by the Issuer was proof of this fact.


For example, the IP proxy could respond with: <del> 4.3. </del> <ins> 4.4. </ins> When using HTTP/2 H2 or HTTP/3 H3, IP proxying requests use HTTP Extended CONNECT.  This requires that servers send an HTTP Setting as


It is also worth pointing out that the choice of model is generally up to the Relying Party.  The same device may need to create Evidence for different Relying Parties and/or different use cases.  For <del> instance, it would provide Evidence to a network infrastructure device to gain access to the network, and to a server holding confidential data to gain access to that data.  As such, both models may simultaneously be in use by the same device. </del> <ins> instance, it would use one model to provide Evidence to a network infrastructure device to gain access to the network, and the other model to provide Evidence to a server holding confidential data to gain access to that data.  As such, both models may simultaneously be in use by the same device. </ins> combination shows another example of a combination where Relying Party 1 uses the passport model, whereas Relying Party 2 uses an


udp/{target_host}/{target_port}/" and wishes to open a UDP proxying tunnel to target 192.0.2.42:443, it could send the following request: <ins> In HTTP/1.1, this protocol uses the GET method to mimic the design of the WebSocket Protocol WEBSOCKET. </ins> 3.3. The UDP proxy SHALL indicate a successful response by replying with


"ECHConfig.cipher_suites" list. The configuration identifier, equal to "Expand(Extract("", <del> config), "tls13 ech config id", Nh)", where "config" is the </del> <ins> config), "tls ech config id", Nh)", where "config" is the </ins> "ECHConfig" structure and "Extract", "Expand", and "Nh" are as specified by the cipher suite KDF.  (Passing the literal """" as the salt is interpreted by "Extract" as no salt being provided.)


the frame.  These frames are explained in more detail in frame- formats. <ins> An endpoint MUST treat the receipt of a frame of unknown type as a connection error of type FRAME_ENCODING_ERROR. </ins> All QUIC frames are idempotent in this version of QUIC.  That is, a valid frame does not cause undesirable side effects or errors when received more than once.


a token that is not applicable to the server that it is connecting to, unless the client has the knowledge that the server that issued the token and the server the client is connecting to are jointly <del> managing the tokens. </del> <ins> managing the tokens.  A client MAY use a token from any previous connection to that server. </ins> A token allows a server to correlate activity between the connection where the token was issued and any connection where it is used.


agreement properties of MLS will confirm that all members of the group agree on the content of these extensions. <del> 5.8. Application messages carried by MLS are opaque to the protocol; they can contain arbitrary data.  Each application which uses MLS needs to define the format of its "application_data" and any mechanism necessary to negotiate the format of that content over the lifetime of an MLS group.  In many applications this means managing format migrations for groups with multiple members who may each be offline at unpredictable times. *RECOMMENDATION:* Use the default content mechanism defined in I- D.mahy-mls-content-neg, unless the specific application defines another mechanism which more appropriately addresses the same requirements for that application of MLS. The MLS framing for application messages also provides a field where clients can send information that is authenticated but not encrypted. Such information can be used by servers that handle the message, but group members are assured that it has not been tampered with. </del> <ins> Application messages carried by MLS are opaque; they can contain arbitrary data.  The MLS framing for application messages also provides a field where clients can send information that is authenticated but not encrypted.  Such information can be used by servers that handle the message, but group members are assured that it has not been tampered with. </ins> <del> 5.9. </del> <ins> 5.8. </ins> The protocol aims to be compatible with federated environments. While this document does not specify all necessary mechanisms


requests and responses can be transferred in a block-wise fashion as defined in RFC7959. <del> Empty messages (Code 0.00) MUST be ignored by the recipient (see also sec-ping). </del> 3.3. <ins> As with CoAP over TCP, both the client and the server MUST send a Capabilities and Settings message (CSM see csm) as its first message on the WebSocket connection. </ins> CoAP requests and responses are exchanged asynchronously over the WebSocket connection.  A CoAP client can send multiple requests without waiting for a response and the CoAP server can return


understands and supports the extension, but some extensions do not require this acknowledgement. <ins> For a flag that does require a response, the only proper response is the same flag in a flags extension.  This extension MUST NOT be used to specify extensions where the response is a proper extension with content. </ins> A flag proposed by the client in ClientHello (CH) that requires acknowledgement SHOULD be acknowledged in either ServerHello (SH), in EncryptedExtensions (EE), in Certificate (CT), or in


8.4. <del> Discarding unwanted messages at the user agent based on message authentication doesn't protect against a denial of service attack on the user agent.  Even a relatively small volume of push messages can cause battery-powered devices to exhaust power reserves. </del> <ins> A user agent can control where valid push messages originate by limiting the distribution of push URIs to authorized application servers.  Ensuring that push URIs are hard to guess ensures that only application servers that have received a push URI can use it. Push messages that are not successfully authenticated by the user agent will not be delivered, but this can present a denial of service risk.  Even a relatively small volume of push messages can cause battery-powered devices to exhaust power reserves. </ins> <del> An application can limit where valid push messages can originate by limiting the distribution of push URIs to authorized entities. Ensuring that push URIs are hard to guess ensures that only application servers that have been given a push URI can use it. </del> <ins> To address this case, the API has adopted I-D.ietf-webpush-vapid, which allows a user agent to restrict a subscription to a specific application server.  The push service can then identity and reject unwanted messages without contacting the user agent. </ins> A malicious application with a valid push URI could use the greater resources of a push service to mount a denial of service attack on a


Handover This property specifies the local policy for transferring data across <del> multiple paths between the same end hosts if Parallel Use of Multiple Paths is not set to Disabled (see multipath-mode).  Possible values are: </del> <ins> multiple paths between the same end hosts if Multipath Transport is not set to Disabled (see multipath-mode).  Possible values are: </ins> The connection ought only to attempt to migrate between different paths when the original path is lost or becomes unusable.  The


8.1. <del> The QUIC version negotiation mechanism is used to negotiate the version of QUIC that is used prior to the completion of the handshake.  However, this packet is not authenticated, enabling an active attacker to force a version downgrade. To ensure that a QUIC version downgrade is not forced by an attacker, version information is copied into the TLS handshake, which provides integrity protection for the QUIC negotiation.  This does not prevent version downgrade prior to the completion of the handshake, though it means that a downgrade causes a handshake failure. </del> QUIC requires that the cryptographic handshake provide authenticated protocol negotiation.  TLS uses Application Layer Protocol Negotiation (ALPN) RFC7301 to select an application protocol.  Unless


input to the key schedule, the Commit and GroupSecrets objects MUST indicate the same set of PSKs, in the same order. <ins> Each time a client injects a PSK into a group, the "psk_nonce" of its PreSharedKeyID MUST be set to a fresh random value of length "KDF.Nh", where "KDF" is the KDF for the ciphersuite of the group into which the PSK is being injected.  This ensures that even when a PSK is used multiple times, the value used as an input into the key schedule is different each time. </ins> On receiving a Commit with a "PreSharedKey" proposal or a GroupSecrets object with the "psks" field set, the receiving Client includes them in the key schedule in the order listed in the Commit,


"psk_key_exchange_modes" from the ClientHelloInner into the ClientHelloOuter. <ins> When the client offers the "early_data" extension in ClientHelloInner, it MUST also include the "early_data" extension in ClientHelloOuter.  This allows servers that reject ECH and use ClientHelloOuter to safely ignore any early data sent by the client per RFC8446, Section 4.2.10. </ins> [[OPEN ISSUE: We currently require HRR-sensitive parameters to match in ClientHelloInner and ClientHelloOuter in order to simplify client- side logic in the event of HRR.  See https://github.com/tlswg/draft-


A web entity that stores information about web resources and implements the REST interfaces defined in this specification for <del> discovery, for the creation, the maintenance and the removal of </del> <ins> discovery, for the creation, maintenance and removal of </ins> registrations, and for lookup of the registered resources.


that about a client?  I'm not sure, so I'd be inclined to remove this unless we have a concrete use case.] <del> The client begins by setting up an HPKE I-D.irtf-cfrg-hpke context for the helper by running </del> <ins> Next, the client issues a POST request to "[leader]/upload_finish". It begins by setting up an HPKE I-D.irtf-cfrg-hpke context for the helper by running </ins> where "pk" is the KEM public key encoded by "HpkeConfig.public_key". The outputs are the helper's encapsulated context "enc" and the


This document defines the "connect-udp" HTTP Upgrade Token. "connect- udp" uses the Capsule Protocol as defined in HTTP-DGRAM. <del> A "connect-udp" request requests that the recipient proxy establish a tunnel over a single HTTP stream to the destination target identified by the "target_host" and "target_port" variables of the URI Template (see client-config).  If the request is successful, the proxy commits to converting received HTTP Datagrams into UDP packets and vice versa </del> <ins> Clients issue requests containing a "connect-udp" upgrade token to initiate a UDP tunnel associated with a single HTTP stream.  The target of the tunnel is indicated by the client to the proxy via the "target_host" and "target_port" variables of the URI Template (see client-config).  If the request is successful, the proxy commits to converting received HTTP Datagrams into UDP packets and vice versa </ins> until the tunnel is closed.  Tunnels are commonly used to create an end-to-end virtual connection, which can then be secured using QUIC QUIC or another protocol running over UDP.


Related information: None <del> 9.5. </del> <ins> 9.6. </ins> IANA has added the media type 'application/edhoc' to the Media Types registry.


update its state to reflect their addition. Subsequent additions of group members proceed in the same way.  Any <del> member of the group can download an UserInitKey for a new client and broadcast an Add message that the current group can use to update </del> <ins> member of the group can download an ClientInitKey for a new client and broadcast an Add message that the current group can use to update </ins> their state and the new client can use to initialize its state. To enforce forward secrecy and post-compromise security of messages,


After processing a header block whose declared Required Insert Count is not zero, the decoder emits a Header Acknowledgement instruction. <del> The instruction begins with the '1' one-bit pattern and includes the header block's associated stream ID, encoded as a 7-bit prefix integer.  It is used by the peer's encoder to know when it is safe to evict an entry (blocked-insertion), and possibly update the Known Received Count (known-received-count). </del> <ins> The instruction begins with the '1' one-bit pattern which is followed by the header block's associated stream ID encoded as a 7-bit prefix integer (see prefixed-integers). This instruction is used as described in known-received-count and in state-synchronization. </ins> If an encoder receives a Header Acknowledgement instruction referring to a stream on which every header block with a non-zero Required


BUNDLE, the multiplexing mechanism defined in I-D.ietf-mmusic-sdp- bundle-negotiation.  Regardless of policy, the application will always try to negotiate BUNDLE onto a single transport, and will <del> offer a single BUNDLE group across all media sections.  However, by specifying a policy from the list below, the application can control how aggressively it will try to BUNDLE media streams together, which affects how it will interoperate with a non-BUNDLE-aware endpoint. When negotiating with a non-BUNDLE-aware endpoint, only the streams not marked as bundle-only streams will be established.  The set of available policies is as follows: </del> <ins> offer a single BUNDLE group across all media section; use of this single transport is contingent upon the answerer accepting BUNDLE. However, by specifying a policy from the list below, the application can control exactly how aggressively it will try to BUNDLE media streams together, which affects how it will interoperate with a non- BUNDLE-aware endpoint.  When negotiating with a non-BUNDLE-aware endpoint, only the streams not marked as bundle-only streams will be established.  The set of available policies is as follows: </ins> The first media section of each type (audio, video, or application) will contain transport parameters, which will allow


Even when redirected, the User Equipment securely authenticates with API servers. <del> 5.5. </del> <ins> 6.5. </ins> The ICMP messaging informs the User Equipment that it is being held captive.  There is no requirement that the User Equipment do


2.2. <del> Both the client and the server MUST send a Capabilities and Settings message (CSM see csm) as its first message on the connection.  This message establishes the initial settings and capabilities for the endpoint such as maximum message size or support for block-wise transfers.  The absence of options in the CSM indicates that base values are assumed. To avoid unnecessary latency, a client MAY send additional messages without waiting to receive the server CSM; however, it is important to note that the server CSM might advertise capabilities that impact how a client is expected to communicate with the server.  For example, the server CSM could advertise a Max-Message-Size option (see max-message-size) that is smaller than the base value (1152). Clients and servers MUST treat a missing or invalid CSM as a connection error and abort the connection (see sec-abort). 2.3. </del> The CoAP message format defined in RFC7252, as shown in CoAP-Header, relies on the datagram transport (UDP, or DTLS over UDP) for keeping the individual messages separate and for providing length


Invalid packets without packet protection, such as Initial, Retry, or Version Negotiation, MAY be discarded.  An endpoint MUST generate a <del> connection error if it commits changes to state before discovering an error. </del> <ins> connection error if processing of the contents of these packets prior to discovering an error resulted in changes to the state of a connection that cannot be reverted. </ins> 5.2.1.


1.3. <del> When RFC8829 was published, inconsistencies regarding BUNDLE RFC8843 operation were identified with regard to both the specification text as well as implementation behavior.  The former concern was addressed via an update to RFC8843.  For the latter concern, it was observed that some implementations implemented the "max-bundle" bundle policy defined in RFC8829 by assuming that bundling had already been negotiated, rather than marking "m=" sections as bundle-only as indicated by the specification.  In order to prevent unexpected changes to applications relying on the pre-standard behavior, the decision was made to deprecate "max-bundle" and instead introduce an identically defined "must-bundle" policy that, when selected, provides the behavior originally specified by RFC8829. </del> <ins> When RFC8829 was published, inconsistencies regarding BUNDLE I- D.ietf-mmusic-rfc8843-bis operation were identified with regard to both the specification text as well as implementation behavior.  The former concern was addressed via an update to I-D.ietf-mmusic- rfc8843-bis.  For the latter concern, it was observed that some implementations implemented the "max-bundle" bundle policy defined in RFC8829 by assuming that bundling had already been negotiated, rather than marking "m=" sections as bundle-only as indicated by the specification.  In order to prevent unexpected changes to applications relying on the pre-standard behavior, the decision was made to deprecate "max-bundle" and instead introduce an identically defined "must-bundle" policy that, when selected, provides the behavior originally specified by RFC8829. </ins> 2.


If the media section has been rejected (i.e. port is set to zero in the answer), stop any reception or transmission of media for <del> this section, and discard any associated ICE components, as </del> <ins> this section, and, if there was no accepted media section bundled with this media section, discard any associated ICE components, as </ins> described in Section 9.2.1.3 of RFC5245. If the remote DTLS fingerprint has been changed or the dtls-id has


properties include, though are not limited to: Capable of solving a CAPTCHA.  Clients that solve CAPTCHA <del> challenges can be attested to have this capability for the purposes of being ruled out as a bot or otherwise automated Client. </del> <ins> challenges can be attested to have this capability for the purpose of being ruled out as a bot or otherwise automated Client. </ins> Client state.  Clients can be associated with state and the attester can attest to this state.  Examples of state include the <del> number of issuance protocol invocations, the client's geographic </del> <ins> number of issuance protocol invocations, the Client's geographic </ins> region, and whether the client has a valid application-layer account. Trusted device.  Some Clients run on trusted hardware that are capable of producing device-level attestation statements. <del> Each of these attestation types have different security properties. </del> <ins> Each of these attestation types has different security properties. </ins> For example, attesting to having a valid account is different from attesting to running on trusted hardware.  In general, Attesters should accept a limited form of attestation formats.


This registry lists field names that are defined for use in ACME order objects.  Fields marked as "client configurable" may be <del> included in a new-account request. </del> <ins> included in a new-order request. </ins> Template:


DTLS record MUST fit within a single datagram.  In order to avoid IP fragmentation, clients of the DTLS record layer SHOULD attempt to size records so that they fit within any PMTU estimates obtained from <del> the record layer. </del> <ins> the record layer.  For more information about PMTU issues see pmtu- issues. </ins> Multiple DTLS records MAY be placed in a single datagram.  Records are encoded consecutively.  The length field from DTLS records


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


An AEAD encryption algorithm <ins> A hash algorithm </ins> A signature algorithm The HPKE parameters are used to instantiate HPKE I-D.irtf-cfrg-hpke


the congestion window. The minimum congestion window is the smallest value the congestion <del> window can decrease to as a response to loss, ECN-CE, or persistent congestion.  The RECOMMENDED value is 2 * max_datagram_size. </del> <ins> window can decrease to as a response to loss, increase in the peer- reported ECN-CE count, or persistent congestion.  The RECOMMENDED value is 2 * max_datagram_size. </ins> 7.3.


would apply to multiple recipient structures. contains information about the plain text that is not integrity <del> protected.  If there are no field, then the value 'null' is used. </del> <ins> protected.  If there are no field, then the value 'nil' is used. </ins> Only values associated with the current cipher text are to be placed in this location even if the value would apply to multiple recipient structures. contains the initialization vector (IV), or it's equivalent, if one is needed by the encryption algorithm.  If there is no IV, <del> then the value 'null' is used. </del> <ins> then the value 'nil' is used. </ins> contains additional authenticated data (aad) supplied by the application.  This field contains information about the plain text data that is authenticated, but not encrypted.  If the application <del> does not provide this data, the value 'null' is used. </del> <ins> does not provide this data, the value 'nil' is used. </ins> contains the encrypted plain text.  If the cipherText is to be transported independently of the control information about the <del> encryption process (i.e. detached content) then the value 'null' is encoded here. </del> <ins> encryption process (i.e. detached content) then the value 'nil' is encoded here. </ins> contains the recipient information.  The field can have one of three data types:


large as to not be usable, the implementation SHOULD discard the capsule without buffering its contents into memory. <del> Note that use of the Capsule Protocol is not required to use HTTP Datagrams.  If an HTTP extension that uses HTTP Datagrams is only defined over transports that support QUIC DATAGRAM frames, it might not need a stream encoding.  Additionally, HTTP extensions can use HTTP Datagrams with their own data stream protocol.  However, new HTTP extensions that wish to use HTTP Datagrams SHOULD use the Capsule Protocol unless they have a good reason not to. </del> <ins> Note that it is possible for an HTTP extension to use HTTP Datagrams without using the Capsule Protocol.  For example, if an HTTP extension that uses HTTP Datagrams is only defined over transports that support QUIC DATAGRAM frames, it might not need a stream encoding.  Additionally, HTTP extensions can use HTTP Datagrams with their own data stream protocol.  However, new HTTP extensions that wish to use HTTP Datagrams SHOULD use the Capsule Protocol as failing to do so will make it harder for the HTTP extension to support versions of HTTP other than HTTP/3 and will prevent interoperability with intermediaries that only support the Capsule Protocol. </ins> 4.


actions are alternatives (e.g., whether to initiate a connection or to listen for incoming connections), while others are optional (e.g., setting Connection and Message Properties in Pre-Establishment) or <del> have been omitted for brevity. </del> <ins> have been omitted for brevity and simplicity. </ins> 4.1.1.


The COSE_encrypt structure for the recipient is organized as follows: <del> The 'protected', 'aad', and 'iv' fields all use the 'null' value. </del> <ins> The 'protected', 'aad', and 'iv' fields all use the 'nil' value. </ins> At a minimum, the 'unprotected' field SHOULD contain the 'alg' parameter as well as a parameter identifying the asymmetric key.


One example of "RateLimit-Remaining" use is below. <del> 5.3. The "RateLimit-Reset" response field indicates either </del> <ins> 5.4. </ins> <del> the number of seconds until the quota resets. </del> <ins> The "RateLimit-Reset" response field indicates the number of seconds until the quota resets. </ins> <del> The field is an Integer Structured Field and its value is </del> <ins> The field is a non-negative Integer. </ins> The delay-seconds format is used because:


IDs from other QUIC versions in order to properly form a version negotiation packet. <del> The Source Connection ID field follows the SCID Length field and is between 0 and 20 bytes in length. negotiating-connection-ids describes the use of this field in more detail. </del> <ins> The Source Connection ID field follows the Source Connection ID Length field and is between 0 and 20 bytes in length. negotiating- connection-ids describes the use of this field in more detail. </ins> In this version of QUIC, the following packet types with the long header are defined:


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


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


than -1, it sets the minimum protection in protocols that allow limiting the checksum length (e.g.  UDP-Lite). <del> Singular Transmission: when this is true, the application requests to avoid transport-layer segmentation or network-layer fragmentation.  Some transports implement network-layer fragmentation avoidance (Path MTU Discovery) without exposing this functionality to the application; in this case, only transport- layer segmentation should be avoided, by fitting the message into a single transport-layer segment or otherwise failing.  Otherwise, network-layer fragmentation should be avoided--e.g. by requesting the IP Don't Fragment bit to be set in case of UDP(-Lite) and IPv4 (SET_DF in RFC8304). </del> <ins> Singular Transmission: When set, this property limits the message size to the Maximum Message Size Before Fragmentation or Segmentation (see Section 10.1.7 of I-D.ietf-taps-interface). Messages larger than this size generate an error.  Setting this avoids transport-layer segmentation or network-layer fragmentation.  When used with transports running over IP version 4 the Don't Fragment bit will be set to avoid on-path IP fragmentation (RFC8304). </ins> 5.1.2.


If more than one Remote Endpoint is specified on the Preconnection, then all the Remote Endpoints on the Preconnection SHOULD represent <del> the same host.  For example, the Remote Endpoints might represent </del> <ins> the same service.  For example, the Remote Endpoints might represent </ins> various network interfaces of a host, or a server reflexive address that can be used to reach a host, or a set of hosts that provide equivalent local balanced service.


The COSE_encrypt structure for the recipient is organized as follows: <del> The 'protected', 'aad', and 'iv' fields all use the 'null' value. </del> <ins> The 'protected', 'aad', and 'iv' fields all use the 'nil' value. </ins> The plain text to be encrypted is the key from next layer down (usually the content layer).


whether in the same conveyance protocol as part of the Evidence or not. <ins> As explained in overview, artifacts are defined by which roles produce them or consume them.  In some protocol instantiations, other roles may cache and forward artifacts as opaque data, to one or more entities implementing the consuming role. </ins> 4. RFC4949 has defined a number of terms that are also used in this


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


2.2. <del> For any remote host ICE candidate received by the ICE agent, the following procedure is used: </del> <ins> For any remote ICE candidate received by the ICE agent, the following procedure is used: </ins> If the connection-address field value of the ICE candidate does not end with ".local" or if the value contains more than one ".",


Responder, respectively, see m3 and m2. When the credential is a certificate, CRED_x is an end-entity <del> certificate (i.e., not the certificate chain), encoded as a CBOR bstr.  In X.509 and C509 certificates, signature keys typically have key usage "digitalSignature" and Diffie-Hellman public keys typically have key usage "keyAgreement". </del> <ins> certificate (i.e., not the certificate chain).  In X.509 and C509 certificates, signature keys typically have key usage "digitalSignature" and Diffie-Hellman public keys typically have key usage "keyAgreement". </ins> To prevent misbinding attacks in systems where an attacker can register public keys without proving knowledge of the private key,


Endpoints validate ECN for packets sent on each network path independently.  An endpoint thus validates ECN on new connection establishment, when switching to a new server preferred address, and <del> on active connection migration to a new path. </del> <ins> on active connection migration to a new path.  ecn-alg describes one possible algorithm for testing paths for ECN support. </ins> Even if an endpoint does not use ECN markings on packets it transmits, the endpoint MUST provide feedback about ECN markings


of the selector entries in the list and yields the concatenation of the lists (in the order of the selector entries) of nodes selected by the selector entries.  Note that any node selected in more than one <del> of the selector entries is kept as many times in the node list. </del> <ins> of the selector entries is kept as many times in the nodelist. </ins> To be valid, integer values in the "element-index" and "slice-index" components MUST be in the I-JSON range of exact values, see synsem-


2. <del> Application servers that wish to self-identity generate and maintain </del> <ins> Application servers that wish to self-identify generate and maintain </ins> a signing key pair.  This key pair MUST be usable with elliptic curve digital signature (ECDSA) over the P-256 curve FIPS186.  Use of this key when sending push messages establishes an identity for the


packetization defines models for the transmission, retransmission, and acknowledgement of data, and <del> packet-size specifies rules for managing the size of packets. </del> <ins> datagram-size specifies rules for managing the size of datagrams carrying QUIC packets. </ins> Finally, encoding details of QUIC protocol elements are described in:


The alert level of all TLS alerts is "fatal"; a TLS stack MUST NOT generate alerts at the "warning" level. <ins> QUIC permits the use of a generic code in place of a specific error code; see Section 11 of QUIC-TRANSPORT.  For TLS alerts, this includes replacing any alert with a generic alert, such as handshake_failure (0x128 in QUIC).  Endpoints MAY use a generic error code to avoid possibly exposing confidential information. </ins> 4.11. After QUIC moves to a new encryption level, packet protection keys


Decompose group operations into Proposals and Commits (*) <ins> Enable Add and Remove proposals from outside the group (*) </ins> draft-07 Initial version of the Tree based Application Key Schedule (*)


The First-Come-First-Remembered policy is added as an example and a potential default behavior. <ins> RD discovery: Drop the previously stated assumption that RDAO and any DHCP options would only be used together with SLAAC and DHCP for address configuration, respectivly. </ins> changes from -24 to -25 Large rework of section 7 (Security policies)


process, by performing normal ACME transactions and providing a validation response for his own account key.  The risks due to hosting providers noted above are a particular case.  For identifiers <del> where the server already has some credential associated with the domain this attack can be prevented by requiring the client to complete a proof-of-possession challenge. </del> <ins> where the server already has some public key associated with the domain this attack can be prevented by requiring the client to prove control of the corresponding private key. </ins> 10.3.


2.2.1. This YANG module imports modules from RFC6991, RFC8348, I-D.ietf- <del> netconf-crypto-types, ietf-asymmetric-algs.yang. </del> <ins> netconf-keystore, ietf-tcg-algs.yang. </ins> <del> 2.3. </del> <ins> 2.2.1.1. This module supports the following types of attestation event logs: <ima>, <bios>, and <netequip_boot>. 2.2.1.2. <tpm12-challenge-response-attestation> - Allows a Verifier to request a quote of PCRs from a TPM1.2 compliant cryptoprocessor.  When one or more <certificate-name> is not provided, all TPM1.2 compliant cryptoprocessors will respond. <tpm20-challenge-response-attestation> - Allows a Verifier to request a quote of PCRs from a TPM2.0 compliant cryptoprocessor.  When one or more <certificate-name> is not provided, all TPM2.0 compliant cryptoprocessors will respond. <log-retrieval> - Allows a Verifier to acquire the evidence which was extended into specific PCRs. 2.2.1.3. container <rats-support-structures> - This exists when there are more than one TPM for a particular Attester.  This allows each specific TPM to identify on which <compute-node> it belongs. container <tpms> - Provides configuration and operational details for each supported TPM, including the tpm-firmware-version, PCRs which may be quoted, certificates which are associated with that TPM, and the current operational status.  Of note is the certificates which are associated with that TPM.  As a certificate is associated with a single Attestation key, knowledge of the certificate allows a specific TPM to be identified. container <attester-supported-algos> - Identifies which TCG algorithms are available for use the Attesting platform.  This allows an operator to limit algorithms available for use by RPCs to just a desired set from the universe of all allowed by TCG. 2.2.1.4. 2.2.2. </ins> Cryptographic algorithm types were initially included within -v14 NETCONF's iana-crypto-types.yang.  Unfortunately all this content including the algorithms needed here failed to make the -v15 used <del> WGLC.  Therefore a modified version of this draft is included here. Perhaps someone will steward this list as a separate draft. </del> <ins> WGLC.  As a result this document has encoded the TCG Algorithm definitions of TCG-Algos, revision 1.32.  By including this full table as a separate YANG file within this document, it is possible for other YANG models to leverage the contents of this model. 2.2.2.1. There are two types of features supported <TPM12> and <TPM20>. Support for either of these features indicates that a cryptoprocessor supporting the corresponding type of TCG API is present on an Attester.  Most commonly, only one type of cryptoprocessor will be available on an Attester. 2.2.2.2. There are three types of identities in this model. The first are the cryptographic functions supportable by a TPM algorithm, these include: <asymmetric>, <symmetric>, <hash>, <signing>, <anonymous_signing>, <encryption_mode>, <method>, and <object_type>.  The definitions of each of these are in Table 2 of TCG-Algos. The second are API specifications for tpms: <tpm12> and <tpm2>. The third are specific algorithm types.  Each algorithm type defines what cryptographic functions may be supported, and on which type of API specification.  It is not required that an implementation of a specific TPM will support all algorithm types.  The contents of each specific algorithm mirrors what is in Table 3 of TCG-Algos. 2.2.2.3. Note that not all cryptographic functions are required for use by ietf-tpm-remote-attestation.yang.  However the full definition of Table 3 of TCG-Algos will allow use by additional YANG specifications. </ins> 3. This document will include requests to IANA: <del> To be defined yet. </del> <ins> To be defined yet.  But keeping up with changes to ietf-tcg-algs.yang will be necessary. </ins> 4. <del> There are always some. </del> <ins> The YANG module specified in this document defines a schema for data that is designed to be accessed via network management protocols such as NETCONF RFC6241 or RESTCONF RFC8040.  The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) RFC6242.  The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS RFC5246. There are a number of data nodes defined in this YANG module that are writable/creatable/deletable (i.e., config true, which is the default).  These data nodes may be considered sensitive or vulnerable in some network environments.  Write operations (e.g., edit-config) to these data nodes without proper protection can have a negative effect on network operations.  These are the subtrees and data nodes and their sensitivity/vulnerability: Container: </rats-support-structures/attester-supported-algos> <tpm12-asymmetric-signing>, <tpm12-hash>, <tpm20-asymmetric- signing>, and <tpm20-hash> all could be populated with algorithms which are not supported by the underlying physical TPM installed by the equipment vendor. Container: </rats-support-structures/tpms> <tpm-name> - Although shown as 'rw', it is system generated <tpm20-pcr-bank> - It is possible to configure PCRs for extraction which are not being extended by system software.  This could unnecessarily use TPM resources. <certificates> - It is possible to provision a certificate which does not correspond to a Attestation Identity Key (AIK) within the TPM. RPC: <tpm12-challenge-response-attestation> - Need to verify that the certificate is for an active AIK. RPC: <tpm20-challenge-response-attestation> - Need to verify that the certificate is for an active AIK. RPC: <log-retrieval> - Pulling lots of logs can chew up system resources. </ins> 5. <ins> Changes from version 02 to version 03: moved to tcg-algs cleaned up model to eliminate sources of errors removed key establishment RPC added lots of XPATH which must all be scrubbed still Descriptive text added on model contents. </ins> Changes from version 01 to version 02: Extracted Crypto-types into a separate YANG file


(2001:db8::3456), scoped to SCTP.  The client can send and recieve SCTP IP packets to the remote host. <del> 6.3. </del> <ins> 7.3. </ins> The following example shows a setup where a client is proxying UDP packets through a CONNECT-IP proxy in order to control connection


The messageData object provides access to the bytes that were received for this Message, along with the length of the byte array. The messageContext is provided to enable retrieving metadata about <del> the message and referring to the message, e.g., to send replies and map responses to their requests.  See msg-ctx for details. </del> <ins> the message and referring to the message.  The messageContext object ist described in msg-ctx. </ins> See framing for handling Message framing in situations where the Protocol Stack only provides a byte-stream transport.


6. When bundling, associating incoming RTP/RTCP with the proper "m=" <del> section is defined in RFC8843.  When not bundling, the proper "m=" section is clear from the ICE component over which the RTP/RTCP is received. </del> <ins> section is defined in I-D.ietf-mmusic-rfc8843-bis.  When not bundling, the proper "m=" section is clear from the ICE component over which the RTP/RTCP is received. </ins> Once the proper "m=" section or sections are known, RTP/RTCP is delivered to the RtpTransceiver(s) associated with the "m="


If the recipient permits the migration, it MUST send subsequent packets to the new peer address and MUST initiate path validation (migrate-validate) to verify the peer's ownership of the address if <del> validation is not already underway. </del> <ins> validation is not already underway.  If the recipient has no unused connection IDs from the peer, it will not be able to send anything on the new path until the peer provides one; see migration-linkability. </ins> An endpoint only changes the address to which it sends packets in response to the highest-numbered non-probing packet.  This ensures


An asymmetric public key <del> The private key for a node is derived from its secret value using the KDF.  The public key is then derived from the private key using the Derive-Public-Key function. </del> <ins> The contents of the parent are based on the latest-updated child. Nodes in a tree are always updated along the "direct path" from a leaf to the root.  The generator of the update chooses a random secret value "path_secret[0]", and generates a sequence of "path secrets", one for each node from the leaf to the root.  That is, path_secret[0] is used for the leaf, path_secret[1] for its parent, and so on.  At each step, the path secret is used to derive a new secret value for the corresponding node, from which the node's key pair is derived. </ins> <del> The contents of a parent node are computed from one of its children as follows: </del> <ins> For example, suppose there is a group with four participants: </ins> <del> The contents of the parent are based on the latest-updated child. For example, if participants with leaf secrets A, B, C, and D join a group in that order, then the resulting tree will have the following structure: </del> <ins> If the first participant subsequently generates an update based on a secret X, then the sender would generate the following sequence of path secrets and node secrets: </ins> <del> If the first participant subsequently changes its leaf secret to be X, then the tree will have the following structure. </del> <ins> After the update, the tree will have the following structure, where "ns[i]" represents the node_secret values generated as described above: </ins> 5.3.


When the end user is directed to enter a short code through the response-interact-usercode mode, the client instance communicates the user code to the end user and directs the end user to enter that code <del> at an associated URI.  This mode is designed to be used when the client instance is not able to communicate or facilitate launching an arbitrary URI.  The associated URI could be statically configured with the client instance or in the client software's documentation. As a consequence, these URIs SHOULD be short.  The user code URI MUST be reachable from the end user's browser, though the URI is usually be opened on a separate device from the client instance itself.  The URI MUST be accessible from an HTTP GET request and MUST be protected by HTTPS or equivalent means. </del> <ins> at an associated URI.  The client instance MAY format the user code in such a way as to facilitate memorability and transfer of the code, so long as this formatting does not alter the value as accepted at the user code URI.  For example, a client instance receiving the user code "A1BC3DFF" could choose to display this to the user as "A1BC 3DFF", breaking up the long string into two shorter strings.  In this example, the space in between the two parts would be removed upon its entry into the user code URI. This mode is designed to be used when the client instance is not able to communicate or facilitate launching an arbitrary URI.  The associated URI could be statically configured with the client instance or in the client software's documentation.  As a consequence, these URIs SHOULD be short.  The user code URI MUST be reachable from the end user's browser, though the URI is usually be opened on a separate device from the client instance itself.  The URI MUST be accessible from an HTTP GET request and MUST be protected by HTTPS or equivalent means. </ins> In many cases, the URI indicates a web page hosted at the AS, allowing the AS to authenticate the end user as the RO and


RFC4566 is the base SDP specification and MUST be implemented. RFC5764 MUST be supported for signaling the UDP/TLS/RTP/SAVPF <del> RFC5764 and TCP/TLS/RTP/SAVPF I-D.nandakumar-mmusic-proto-iana- </del> <ins> RFC5764 and TCP/DTLS/RTP/SAVPF I-D.nandakumar-mmusic-proto-iana- </ins> registration RTP profiles. RFC5245 MUST be implemented for signaling the ICE credentials and


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


and used in the HPKE construction for TreeKEM. The whole structure is signed using the client's identity key.  A <del> UserInitKey object with an invalid signature field MUST be considered malformed.  The input to the signature computation comprises all of the fields except for the signature field. </del> <ins> ClientInitKey object with an invalid signature field MUST be considered malformed.  The input to the signature computation comprises all of the fields except for the signature field. </ins> 8.


3.4.2.1. The process begins with a PACollectReq.  The leader collects a <del> sequence of reports that are all associated with the same PA task, helper URL, and helper HPKE config id.  Let "[helper]" denote "PACollectReq.helper_url".  The leader sends a POST request to "[helper]/aggregate" with the following message: </del> <ins> sequence of reports that are all associated with the same PA task. Let "[helper]" denote "PAParam.helper_url", where "PAParam" is the PA parameters structure associated "PAAggregateReq.task.id".  The leader sends a POST request to "[helper]/aggregate" with the following message: </ins> The structure contains the PA task, the helper's HPKE config id, an opaque _helper state_ string, and a sequence of _sub-requests_, each


be dereferenced in the normal course of handling problem details (i.e., outside diagnostic/debugging procedures involving humans). <del> An example of a custom extension using a URI as "custom-problem- detail-entries" key is shown in fig-example-custom-with-uri. </del> <ins> fig-example-custom-with-uri shows an example (in CBOR diagnostic notation) of a custom extension using a (made-up) URI as "custom- problem-detail-entries" key. </ins> Obviously, an SDO like 3GPP can also easily register such a custom problem detail entry to receive a more efficient unsigned integer <del> key; the same example but using a registered unsigned int as "custom- problem-detail-entries" key is shown in fig-example-custom-with-uint. </del> <ins> key; fig-example-custom-with-uint shows how the same example would look like using a (made-up) registered unsigned int as "custom- problem-detail-entries" key: </ins> In summary, the keys for the maps used inside Custom Problem Detail entries are defined specifically to the identifier of that Custom


7.2.8. <del> Frame types of the format "0x1f * N + 0x21" for integer values of N are reserved to exercise the requirement that unknown types be ignored (extensions).  These frames have no semantics, and can be sent on any open stream when application-layer padding is desired. They MAY also be sent on connections where no data is currently being transferred.  Endpoints MUST NOT consider these frames to have any meaning upon receipt. </del> <ins> Frame types of the format "0x1f * N + 0x21" for non-negative integer values of N are reserved to exercise the requirement that unknown types be ignored (extensions).  These frames have no semantics, and can be sent on any open stream when application-layer padding is desired.  They MAY also be sent on connections where no data is currently being transferred.  Endpoints MUST NOT consider these frames to have any meaning upon receipt. </ins> The payload and length of the frames are selected in any manner the implementation chooses.


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


2.5.3.2. <del> The "index-selector" applied to an array selects an array element using a zero-based index.  For example, the selector "0" selects the first and the selector "4" selects the fifth element of a </del> <ins> A non-negative "index-selector" applied to an array selects an array element using a zero-based index.  For example, the selector "0" selects the first and the selector "4" selects the fifth element of a </ins> sufficiently long array.  Nothing is selected, and it is not an error, if the index lies outside the range of the array.  Nothing is selected from a value that is not an array.


An RD implementation of this specification MUST support query filtering for the rt parameter as defined in RFC6690. <ins> While the link targets in this discovery step are often expressed in path-absolute form, this is not a requirement.  Clients SHOULD therefore accept URIs of all schemes they support, both in absolute and relative forms, and not limit the set of discovered URIs to those hosted at the address used for URI discovery. </ins> The URI Discovery operation can yield multiple URIs of a particular resource type.  The client may use any of the discovered addresses initially.


Application keys and other application specific data can be derived using the EDHOC-Exporter interface defined as: <del> where label is a tstr defined by the application and length is a uint defined by the application.  The label SHALL be different for each different exporter value.  The transcript hash TH_4 is a CBOR encoded bstr and the input to the hash function is a CBOR Sequence. </del> <ins> label_context is a CBOR sequence: </ins> <del> where H() is the hash function in the selected cipher suite.  Example use of the EDHOC-Exporter is given in I-D.ietf-core-oscore-edhoc. </del> <ins> where label is a registered tstr from the EDHOC Exporter Label registry (exporter-label), context is a bstr defined by the application, and length is a uint defined by the application.  The (label, context) pair must be unique, i.e. a (label, context) MUST NOT be used for two different purposes.  However an application can re-derive the same key several times as long as it is done in a secure way.  For example, in most encryption algorithms the same (key, nonce) pair must not be reused. The transcript hash TH_4 is a CBOR encoded bstr and the input to the hash function is a CBOR Sequence. where H() is the hash function in the selected cipher suite. Examples of use of the EDHOC-Exporter are given in asym-msg4-proc and I-D.ietf-core-oscore-edhoc. </ins> To provide forward secrecy in an even more efficient way than re- running EDHOC, EDHOC provides the function EDHOC-KeyUpdate.  When EDHOC-KeyUpdate is called the old PRK_4x3m is deleted and the new <del> PRk_4x3m is calculated as a "hash" of the old key using the Extract </del> <ins> PRK_4x3m is calculated as a "hash" of the old key using the Extract </ins> function as illustrated by the following pseudocode: 5.


The entries in iana-setting-table are registered by this document. <del> For fomatting reasons, setting names can be abbreviated by removing the 'SETTING_' prefix. </del> <ins> For formatting reasons, setting names can be abbreviated by removing the 'SETTINGS_' prefix. </ins> Each code of the format "0x1f * N + 0x21" for non-negative integer values of "N" (that is, 0x21, 0x40, ..., through 0x3ffffffffffffffe)


If Observe is implemented: <del> Replace step 1 of ver-res with: A.  Discard Code and all options marked in fig-option-protection with 'x' in column E, except for Observe, present in the received message. For example, ETag Outer option is discarded, as well as Max-Age Outer option, Observe is not discarded. Insert the following steps between step 2 and 3 of ver-res: B.  If the Observe option is present in the response, but the request was not an Observe registration, then go to 9. </del> <ins> Replace step 6 of ver-res with: </ins> <del> C.  If an Observe option is included or the Notification number for the observation has already been initiated, but the Partial IV is not present in the response, then go to 9. </del> <ins> A.  If Inner Observe is present then: </ins> <del> D.  For Observe notifications, verify the received 'Partial IV' parameter against the corresponding Notification Number as described in replay-protection. </del> <ins> If the request was not an Observe registration, then go to 9. </ins> <del> Replace step 6 of ver-res with: </del> <ins> If the Partial IV was not present in the response, then go to 9. </ins> <del> E.  If the response is a notification, initiate or update the corresponding Notification Number, as described in sequence-numbers. Otherwise, delete the attribute-value pair (Token, {Security Context, PIV}). </del> <ins> If the request was an Observe registration and the Partial IV was present in the response, then verify the received 'Partial IV' parameter against the corresponding Notification Number, and follow the processing described in replay-notifications. Otherwise, delete the attribute-value pair (Token, {Security Context, PIV}). </ins> <del> Replace step 7 of ver-res with: </del> <ins> Replace step 9 of ver-res with: </ins> <del> F.  Add decrypted Code, options and payload to the decrypted request, except for decrypted Observe if present.  The OSCORE option is removed. </del> <ins> B.  In case any of the previous erroneous conditions apply: the client SHALL stop processing the response.  An error condition occurring while processing a response in an observation does not cancel the observation.  A client MUST NOT react to failure by re- registering the observation immediately. </ins> <del> An error condition occurring while processing a response in an observation does not cancel the observation.  A client MUST NOT react to failure in step 5 by re-registering the observation immediately. </del> <ins> Note that the attribute-value attribute-value pair (Token, {Security Context, PIV}) MUST be deleted whenever the Observation is cancelled or "forgotten". </ins> 9.


3.2.1. <del> There are many reasons why path characteristics might change suddenly, but we can divide these reasons into two categories: </del> <ins> There are many reasons why path characteristics might change in normal operation, for example: </ins> If the path topology changes.  For example, routing changes, which can happen in normal operation, may result in traffic being


accounting. As suggested in RFC8446, EAP-TLS peers MUST NOT store resumption PSKs <del> or tickets (and associated cached data) for longer than 7 days, regardless of the PSK or ticket lifetime.  The EAP-TLS peer MAY delete them earlier based on local policy.  The cached data MAY also be removed on the EAP-TLS server or EAP-TLS peer if any certificate in the certificate chain has been revoked or has expired.  In all such cases, an attempt at resumption results in a full TLS handshake instead. </del> <ins> or tickets (and associated cached data) for longer than 604800 seconds (7 days), regardless of the PSK or ticket lifetime.  The EAP- TLS peer MAY delete them earlier based on local policy.  The cached data MAY also be removed on the EAP-TLS server or EAP-TLS peer if any certificate in the certificate chain has been revoked or has expired. In all such cases, an attempt at resumption results in a full TLS handshake instead. </ins> Information from the EAP-TLS exchange (e.g., the identity provided in EAP-Response/Identity) as well as non-EAP information (e.g., IP


7.2. <del> A subdomain can also be used for all internal DNS names (e.g., the zone internal.example.com exists only on the internal DNS server). For successful validation described in this document the the internal DNS server will need a certificate signed by a CA trusted by the client. </del> <ins> In many split-horizon deployments, all non-public domain names are placed in a separate child zone (e.g., ).  In this configuration, the message flow is similar to internal- only, except that queries for hosts not within the subdomain (e.g., </ins> <del> For such a name internal.example.com the message flow is similar to internal-only the difference is that queries for hosts not within the subdomain (www.example.com) are sent to the public resolver rather than resolver for internal.example.com. </del> <ins> ) are sent to the external resolver rather than resolver for internal.example.com. As in internal-only, the internal DNS server will need a certificate signed by a CA trusted by the client. </ins> 8.


This approach, as described in RFC2198, allows for redundant data to be piggybacked on an existing primary encoding, all in a single packet.  This redundant data may be an exact copy of a previous <del> packet, or for codecs that support variable-bitrate encodings, </del> <ins> payload, or for codecs that support variable-bitrate encodings, </ins> possibly a smaller, lower-quality representation.  In certain cases, <del> the redundant data could include multiple prior packets. </del> <ins> the redundant data could include encodings of multiple prior audio frames. </ins> Since there is only a single set of packet headers, this approach allows for a very efficient representation of primary + redundant


22. <del> Following is the list of changes from RFC 5245 </del> <ins> The purpose of this updated ICE specification is to: </ins> <del> The specification was generalized to be more usable with any protocol and the parts that are specific to SIP and SDP were moved to a SIP/SDP usage document I-D.ietf-mmusic-ice-sip-sdp. </del> <ins> Clarify procedures in RFC 5245. </ins> <del> Default candidates, multiple components, ICE mismatch detection, subsequent offer/answer, and role conflict resolution were made optional since they are not needed with every protocol using ICE. </del> <ins> Make technical changes, due to discovered flows in RFC 5245 and based on feedback from the community that has implemented and deployed ICE applications based on RFC 5245. </ins> <del> With IPv6, the precedence rules of RFC 6724 are used instead of the obsoleted RFC 3483 and using address preferences provided by the host operating system is recommended. </del> <ins> Make the procedures signaling protocol independent, by removing the SIP and SDP procedures.  Procedures specific to a signaling protocol will be defined in separate usage documents.  I-D.ietf- mmusic-ice-sip-sdp defines the ICE usage with SIP and SDP. </ins> <del> Candidate gathering rules regarding loopback addresses and IPv6 addresses were clarified. </del> <ins> The following technical changes have been done: Aggressive nomination removed. The procedures for calculating candidate pair states and scheduling connectivity checks modified. Procedures for calculation of Ta and RTO modified. Active check list and frozen check list definitions removed. 'ice2' ice option added. IPv6 considerations modified. Usage with no-op for keepalives, and keepalives with non-ICE peers, removed. </ins>


7. <del> This section provides a summary on the content in previous sections. The fig:summary sums up some recommendations.  It is worth pointing out that the "coding without congestion" considers that coded packets are sent along with original data packets, in opposition with the solution where coded packets are transmitted only when there is no more original packets to transmit.  Moreover, the values indicated in this Figure consider a channel that does not exhibit a high loss pattern. </del> <ins> [MICHAEL: I'm sorry to say that I find this table to be in the same style, of wrongly mixing things together, and would like to see it removed altogether.]  This section provides a summary on the content in previous sections.  The fig:summary sums up some recommendations. It is worth pointing out that the "coding without congestion" considers that coded packets are sent along with original data packets, in opposition with the solution where coded packets are transmitted only when there is no more original packets to transmit. Moreover, the values indicated in this Figure consider a channel that does not exhibit a high loss pattern. </ins> 8.


the delegation, even though they are not themselves authoritative data. <ins> "A lame delegations exists when a nameserver is delegated responsibility for providing nameservice for a zone (via NS records) but is not performing nameservice for that zone (usually because it is not set up as a primary or secondary for the zone)." (Definition from RFC1912, Section 2.8) </ins> "[Resource records] which are not part of the authoritative data [of the zone], and are address resource records for the [name servers in subzones].  These RRs are only necessary if the name


octet of the Connection ID are reserved to express the length of the following connection ID, not including the first octet. <del> A server not using this functionality SHOULD make the six bits appear to be random. </del> <ins> A server not using this functionality SHOULD choose the six bits so as to have no observable relationship to previous connection IDs issued for that connection. </ins> 2.4.


To avoid excessively small idle timeout periods, endpoints MUST increase the idle timeout period to be at least three times the current Probe Timeout (PTO).  This allows for multiple PTOs to <del> expire, and therefore multiple probes to be sent in the event of loss, prior to idle timeout. </del> <ins> expire, and therefore multiple probes to be sent and lost, prior to idle timeout. </ins> 10.1.1.


the RS again. The RS validates the access token and determines that the access <del> token is expired The RS responds to the client instance with an </del> <ins> token is expired.  The RS responds to the client instance with an </ins> error. The client instance calls the token management URI returned in (2)


Today, on the Internet it publishes two NS records, "ns1.example.com" and "ns2.example.com". <del> The host and network first need mutual support one of the mechanisms described in learning.  Shown in fig-learn is learning using DNR and PvD. </del> <ins> First, the host and network both need to support one of the discovery mechanisms described in learning. fig-learn shows discovery using DNR and PvD. </ins> <del> Validation is then perfomed using either example-verify-public or </del> <ins> Validation is then perfomed using either example-verify-external or </ins> example-verify-dnssec. 7.1.1. The figure below shows the steps performed to verify the local claims <del> of DNS authority using a public resolver. </del> <ins> of DNS authority using an external resolver. </ins> 7.1.2.


would be too large to fit in a packet, however receivers MAY also limit ACK frame size further to preserve space for other frames. <del> When discarding unacknowledged ACK Ranges, a receiver MUST retain the largest received packet number.  A receiver SHOULD retain ACK Ranges containing newly received packets or higher-numbered packets. </del> <ins> A receiver MUST retain an ACK Range unless it can ensure that it will not subsequently accept packets with numbers in that range. Maintaining a minimum packet number that increases as ranges are discarded is one way to achieve this with minimal state. Receivers can discard all ACK Ranges, but they MUST retain the largest packet number that has been successfully processed as that is used to recover packet numbers from subsequent packets; see packet- encoding. A receiver SHOULD include an ACK Range containing the largest received packet number in every ACK frame.  The Largest Acknowledged field is used in ECN validation at a sender and including a lower value than what was included in a previous ACK frame could cause ECN to be unnecessarily disabled; see ecn-validation. </ins> A receiver that sends only non-ack-eliciting packets, such as ACK frames, might not receive an acknowledgement for a long period of


The initiator uses information from the peer's certificate to verify the delegated credential and that the peer is asserting an expected identity, determining an authentication result for the <del> peer.. </del> <ins> peer. </ins> Peers accepting the delegated credential use it as the certificate key for the (D)TLS handshake.


Application messages <del> The sender information used to look up the key for the content encryption is encrypted under AEAD using a random nonce and the "sender_data_key" which is derived from the "sender_data_secret" as follows: </del> <ins> The sender information used to look up the key for content encryption is encrypted with an AEAD where the key and nonce are derived from both "sender_data_secret" and a sample of the encrypted message content. </ins> For handshake and application messages, a sequence of keys is derived via a "sender ratchet".  Each sender has their own sender ratchet,


consider congestion control aspects when proposing coding solutions. The proposed recommendations apply for coding at the transport or <del> application layer and coding for tunnels is out-of-the scope of the </del> <ins> application layer.  Coding for tunnels is out of scope for the </ins> document. 2. fig:sep-channel presents the notations that will be used in this document and introduce the Congestion Control (CC) and Forward <del> Erasure Correction (FEC) channels.  Congestion Control channel carries data packets (from the server to the client) and a potential </del> <ins> Erasure Correction (FEC) channels.  The Congestion Control channel carries data packets (from a server to a client) and a potential </ins> information signaling the packets that have been received (from the <del> client to the server).  Forward Erasure Correction channel carries coded packets (from the server to the client) and a potiential information signaling the packets that have been repaired (from the client to the server).  It is worth pointing out that there are cases where these channels are not separated. </del> <ins> client to the server).  The Forward Erasure Correction channel carries coded packets (from the server to the client) and a potiential information signaling the packets that have been repaired (from the client to the server).  It is worth pointing out that there are cases where these channels are not separated. Inside a host, the CC and FEC entities can be regarded as conceptually separate: As this diagram shows, the inputs to FEC (data to work upon, and signaling from the receiver about losses and/or repaired blocks) are distinct from the inputs to CC.  The latter calculates a sending rate or window from network measurements, and it takes the data to send as input, sometimes along with application requirements such as upper/ lower rate bounds, periods of quiescence, or a priority. It is not clear that the ACK signals feeding into a congestion control algorithm are useful to FEC in their raw form, and vice versa - information about repaired blocks may be quite irrelevant to a CC algorithm.  However, there can be meaningful other interactions (indicated by the horizontal double arrow) between the two entities, usually as a result of their operation rather than by relaying their own raw inputs.  For example, the network measurements carried out by CC can yield a longer-term statistical measure such as a loss ratio which is useful input for a FEC coding scheme.  Similarly, unequal error protection using fountain codes can be used to assign different priorities to blocks of data, and these priorities can be honored by a CC mechanism. </ins> 3.


length is a uint defined by the application <del> PRK_exporter is derived from PRK_out: where hash_length denotes the output size in bytes of the EDHOC hash algorithm of the selected cipher suite. </del> The (exporter_label, context) pair used in EDHOC_Exporter must be unique, i.e., an (exporter_label, context) MUST NOT be used for two different purposes.  However an application can re-derive the same


timestamp of the event, Client visible information (including the IP address), and the Origin name. <del> The challenge controls the type of token that the Origin will accept for the given resource.  As described in AUTHSCHEME, there are a number of ways in which the token may vary, including: </del> <ins> The challenge provides the client with the information necessary to obtain tokens that the server might subsequently accept (in this context).  As described in AUTHSCHEME, there are a number of ways in which the token may vary, including: </ins> Issuance protocol.  The token identifies the type of issuance protocol required for producing the token.  Different issuance


In some circumstances, the information needed at a given stage is communicated out of band or is preconfigured between the components <del> or entities performing the roles.  For example, one entity can fulfil multiple roles, and so explicit communication between the roles is not necessary within the protocol flow.  Additionally some components may not be involved in all use cases.  For example, a client instance could be calling the AS just to get direct user information and have no need to get an access token to call an RS. </del> <ins> or entities performing the roles.  For example, one entity can fulfill multiple roles, and so explicit communication between the roles is not necessary within the protocol flow.  Additionally some components may not be involved in all use cases.  For example, a client instance could be calling the AS just to get direct user information and have no need to get an access token to call an RS. </ins> 1.5.1.


methods: If interaction finishing is supported for this client instance and <del> request, the AS response-interact-finish used by the client instance to validate the callback.  Requests to the callback URI MUST be processed as described in interaction-finish, and the AS MUST require presentation of an interaction callback reference as described in continue-after-interaction. </del> <ins> request, the AS will response-interact-finish used by the client instance to validate the callback.  All interaction finish methods MUST use this nonce to allow the client to verify the connection between the pending interaction request and the callback.  GNAP does this through the use of the interaction hash, defined in interaction- hash.  All requests to the callback URI MUST be processed as described in interaction-finish. All interaction finish methods MUST require presentation of an interaction reference for continuing this grant request.  This means that the the interaction reference MUST be returned by the AS and MUST be presented by the client as described in continue-after- interaction.  The means by which the interaction reference is returned to the client instance is specific to the interaction finish method. </ins> 2.5.2.1.


5.2. <del> min_rtt is the minimum RTT observed for a given network path. min_rtt is set to the latest_rtt on the first RTT sample, and to the lesser of min_rtt and latest_rtt on subsequent samples.  In this document, min_rtt is used by loss detection to reject implausibly small rtt samples. </del> <ins> min_rtt is the sender's estimate of the minimum RTT observed for a given network path.  In this document, min_rtt is used by loss detection to reject implausibly small rtt samples. min_rtt MUST be set to the latest_rtt on the first RTT sample. min_rtt MUST be set to the lesser of min_rtt and latest_rtt (latest- rtt) on all other samples. </ins> An endpoint uses only locally observed times in computing the min_rtt and does not adjust for acknowledgment delays reported by the peer.


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


(TLS) and Datagram Transport Layer Security (DTLS) recommends use of SHA-256 as a minimum requirement.  This update moves the minimum recommendation to use stronger language deprecating use of both SHA-1 <del> and MD5.  The prior text did not explicitly include MD5 and this text adds it to ensure it is understood as having been deprecated. </del> <ins> and MD5.  The prior text did not explicitly include MD5 or SHA-1; and this text adds guidance to ensure that these algorithms have been deprecated.. </ins> Section 4.3:


Full Coverage This property specifies the minimum number of bytes in a received <del> message that need to be covered by a checksum.  A special value of 0 means that a received packet does not need to have a non-zero checksum field.  A receiving endpoint will not forward messages that have less coverage to the application.  The application is responsible for handling any corruption within the non-protected part of the message RFC8085. </del> <ins> message that need to be covered by a checksum.  A receiving endpoint will not forward messages that have less coverage to the application. The application is responsible for handling any corruption within the non-protected part of the message RFC8085.  A special value of 0 means that a received packet may also have a zero checksum field. </ins> 8.1.2.


authoritative IdPs, thus allowing the user to instantly grasp that the call is being authenticated by Facebook, Google, etc. <ins> 6.4.4.1. Because a broad range of characters are permitted in identity strings, it may be possible for attackers to craft identities which are confusable with other identities (see RFC6943 for more on this topic).  This is a problem with any identifier space of this type (e.g., e-mail addresses).  Those minting identifers should avoid mixed scripts and similar confusable characters.  Those presenting these identifiers to a user should consider highlighting cases of mixed script usage (see RFC5890, section 4.4).  Other best practices are still in development. </ins> 6.4.5. A number of optional Web security features have the potential to


3.1.3. <del> QUIC ends a loss epoch when a packet sent after loss is declared is acknowledged.  TCP waits for the gap in the sequence number space to be filled, and so if a segment is lost multiple times in a row, the loss epoch may not end for several round trips.  Because both should reduce their congestion windows only once per epoch, QUIC will do it correctly once for every round trip that experiences loss, while TCP may only do it once across multiple round trips. </del> <ins> QUIC starts a loss epoch when a packet is lost and ends one when any packet sent after the epoch starts is acknowledged.  TCP waits for the gap in the sequence number space to be filled, and so if a segment is lost multiple times in a row, the loss epoch may not end for several round trips.  Because both should reduce their congestion windows only once per epoch, QUIC will do it correctly once for every round trip that experiences loss, while TCP may only do it once across multiple round trips. </ins> 3.1.4.


to receiving packets that only contain DATAGRAM frames, since the timing of these acknowledgements is not used for loss recovery. <ins> As with any ack-eliciting frame, when a sender suspects that a packet containing only DATAGRAM frames has been lost, it MAY send probe packets to elicit a faster acknowledgement as described in Section 6.2.4 of RFC9002. </ins> If a sender detects that a packet containing a specific DATAGRAM frame might have been lost, the implementation MAY notify the application that it believes the datagram was lost.


server.  This attack is bound by the number of valid TCP connections an attacker can open. <del> 7.2.4. </del> <ins> 7.3.4. </ins> As more clients enable ESNI support, e.g., as normal part of Web browser functionality, with keys supplied by shared hosting


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


9. Running DNS over HTTPS relies on the security of the underlying HTTP <del> connection.  By requiring at least RFC7540 levels of support for TLS, this protocol expects to use current best practices for secure transport. </del> <ins> transport.  Implementations utilizing HTTP/2 benefit from the TLS profile defined in RFC7540 Section 9.2. </ins> Session level encryption has well known weaknesses with respect to traffic analysis which might be particularly acute when dealing with


external_aad = << TH_2, CRED_R, ? EAD_2 >> <del> CRED_R - bstr containing the credential of the Responder, see </del> <ins> CRED_R - CBOR item containing the credential of the Responder, see </ins> EAD_2 = unprotected external authorization data, see


is persistently offline may still be holding old keying material and thus be a threat to both FS and PCS if it is later compromised. <del> MLS partially defend against this problem by active member including freshness, however not much can be done on the inactive side especially in the case where the client has not processed messages. </del> <ins> MLS partially defends against this problem by active members including freshness, however not much can be done on the inactive side especially in the case where the client has not processed messages. </ins> <del> *RECOMMENDATION:* Mandate a key updates from clients that are not </del> <ins> *RECOMMENDATION:* Mandate key updates from clients that are not </ins> otherwise sending messages and evict clients which are idle for too long.


Architecture RFC7556 provides some discussion on authenticating an operator. <del> Given that a user chooses to visit a Captive Portal URI, the URI location SHOULD be securely provided to the user's device.  E.g., the DHCPv6 AUTH option can sign this information. </del> <ins> The user makes an informed choice to visit and trust the Captive Portal URI.  Since the network provides Captive Portal URI to the user equipment, the network SHOULD do so securely so that the user's trust in the network can extend to their trust of the Captive Portal URI.  E.g., the DHCPv6 AUTH option can sign this information. </ins> If a user decides to incorrectly trust an attacking network, they might be convinced to visit an attacking web page and unwittingly


report share as invalid with the error "hpke-unknown-config-id". Otherwise, it decrypts the payload with the following procedure: <del> where "sk" is the HPKE secret key, "task_id" is the task ID, "nonce" and "extensions" are the nonce and extensions of the report share respectively, and "server_role" is 0x02 if the aggregator is the leader and 0x03 otherwise.  If decryption fails, the aggregator marks the report share as invalid with the error "hpke-decrypt-error". Otherwise, it outputs the resulting "input_share". </del> <ins> where "sk" is the HPKE secret key, and "server_role" is the role of the aggregator ("0x02" for the leader and "0x03" for the helper).  If decryption fails, the aggregator marks the report share as invalid with the error "hpke-decrypt-error".  Otherwise, it outputs the resulting "input_share". </ins> 4.3.1.4.


Passive open is the Action of waiting for Connections from remote endpoints, commonly used by servers in client-server interactions. <del> Passive open is supported by this interface through the Listen Action: </del> <ins> Passive open is supported by this interface through the Listen Action and returns a Listener object: </ins> Before calling Listen, the caller must have initialized the Preconnection during the pre-establishment phase with a Local Endpoint specifier, as well as all properties necessary for Protocol Stack selection.  A Remote Endpoint may optionally be specified, to <del> constrain what Connections are accepted.  The Listen() Action consumes the Preconnection.  Once Listen() has been called, no further properties may be added to the Preconnection, and no subsequent establishment call may be made on the Preconnection. </del> <ins> constrain what Connections are accepted.  The Listen() Action returns a Listener object.  Once Listen() has been called, properties added to the Preconnection have no effect on the Listener and the Preconnection can be disposed of or reused. </ins> Listening continues until the global context shuts down, or until the <del> Stop action is performed on the same Preconnection: </del> <ins> Stop action is performed on the Listener object: </ins> <del> After Stop() is called, the preconnection can be disposed of. </del> <ins> After Stop() is called, the Listener can be disposed of. </ins> The ConnectionReceived Event occurs when a Remote Endpoint has <del> established a transport-layer connection to this Preconnection (for </del> <ins> established a transport-layer connection to this Listener (for </ins> Connection-oriented transport protocols), or when the first Message has been received from the Remote Endpoint (for Connectionless protocols), causing a new Connection to be created.  The resulting


address validation by sending a Retry packet (packet-retry) containing a token.  This token MUST be repeated by the client in all Initial packets it sends for that connection after it receives the <del> Retry packet.  In response to processing an Initial containing a token, a server can either abort the connection or permit it to proceed. </del> <ins> Retry packet. In response to processing an Initial containing a token that was provided in a Retry packet, a server cannot send another Retry packet; it can only refuse the connection or permit it to proceed. </ins> As long as it is not possible for an attacker to generate a valid token for its own address (see token-integrity) and the client is


6.4. <del> Groups of Connections can be created using the Clone Action: </del> <ins> Entangled Connections can be created using the Clone Action: </ins> Calling Clone on a Connection yields a group of two Connections: the parent Connection on which Clone was called, and the resulting cloned


4.1.4. Session description objects (RTCSessionDescription) may be of type <del> "offer", "pranswer", and "answer".  These types provide information as to how the description parameter should be parsed, and how the media state should be changed. </del> <ins> "offer", "pranswer", or "answer".  These types provide information as to how the description parameter should be parsed, and how the media state should be changed. </ins> "offer" indicates that a description should be parsed as an offer; said description may include many possible media configurations.  A


"authority" as defined in Section 3.2 of RFC3986. The Alternative-Address Option is a repeatable option as defined in <del> Section 5.4.5 of RFC7252. </del> <ins> Section 5.4.5 of RFC7252.  When multiple occurrences of the option are included, the peer can choose any of the alternative transport addresses. </ins> The elective Hold-Off Option indicates that the server is requesting that the peer not reconnect to it for the number of seconds given in


contains the unmodified payload of a UDP packet (referred to as "data octets" in UDP). <del> Clients MAY optimistically start sending UDP packets in HTTP Datagrams before receiving the response to its UDP proxying request. However, implementors should note that such proxied packets may not be processed by the UDP proxy if it responds to the request with a failure, or if the proxied packets are received by the UDP proxy before the request. </del> By virtue of the definition of the UDP header UDP, it is not possible to encode UDP payloads longer than 65527 bytes.  Therefore, endpoints MUST NOT send HTTP Datagrams with a Payload field longer than 65527


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


RDAO: Clarify that it is an option for RAs and not other ND messages. <ins> Examples: Use example URIs rather than unclear reg names (unless it's RFC6690 examples, which were kept for continuity) </ins> changes from -24 to -25 Large rework of section 7 (Security policies)


client ever sees the values for individual clients. In order to address this problem, the aggregators engage in a secure, <del> multi-party computation specified by the chosen VDAF I-D.draft-cfrg- patton-vdaf in order to prepare a report for aggregation.  At the beginning of this computation, each aggregator is in possession of an input share uploaded by the client.  At the end of the computation, each aggregator is in posession of either an "output share" that is ready to be aggregated or an indication that a valid output share could not be computed. </del> <ins> multi-party computation specified by the chosen VDAF VDAF in order to prepare a report for aggregation.  At the beginning of this computation, each aggregator is in possession of an input share uploaded by the client.  At the end of the computation, each aggregator is in posession of either an "output share" that is ready to be aggregated or an indication that a valid output share could not be computed. </ins> To facilitiate this computation, the input shares generated by the client include information used by the aggregators during aggregation


PMTU probes are ack-eliciting packets. Endpoints could limit the content of PMTU probes to PING and PADDING <del> frames as packets that are larger than the current maximum packet size are more likely to be dropped by the network.  Loss of a QUIC packet that is carried in a PMTU probe is therefore not a reliable indication of congestion and SHOULD NOT trigger a congestion control reaction; see Section 3, Bullet 7 of DPLPMTUD.  However, PMTU probes consume congestion window, which could delay subsequent transmission by an application. </del> <ins> frames, since packets that are larger than the current maximum datagram size are more likely to be dropped by the network.  Loss of a QUIC packet that is carried in a PMTU probe is therefore not a reliable indication of congestion and SHOULD NOT trigger a congestion control reaction; see Section 3, Bullet 7 of DPLPMTUD.  However, PMTU probes consume congestion window, which could delay subsequent transmission by an application. </ins> 14.4.1.


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and <del> "OPTIONAL" in this document are to be interpreted as described in RFC2119.  The term "byte" is used in its now customary sense as a synonym for "octet". </del> <ins> "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. The term "byte" is used in its now customary sense as a synonym for "octet". </ins> This specification requires readers to be familiar with all the terms and concepts that are discussed in RFC3986, RFC8288 and RFC6690.


needs to initialize a GroupContext object that can be updated to the current state using the Add message.  This information is encrypted for the new member using HPKE.  The recipient key pair for the HPKE <del> encryption is the one included in the indicated UserInitKey, </del> <ins> encryption is the one included in the indicated ClientInitKey, </ins> corresponding to the indicated ciphersuite. In the description of the tree as a list of nodes, the "credential"