Welcome message MUST be the same as the corresponding fields in the ReInit proposal. <del> The "epoch" in the Welcome message MUST be 1 </del> The Welcome MUST specify a PreSharedKey of type "resumption" with usage "reinit".  The "group_id" must match the old group, and the "epoch" must indicate the epoch after the Commit covering the ReInit. <del> The "psk_nonce" included in the "PreSharedKeyID" of the resumption PSK MUST be a randomly sampled nonce of length "KDF.Nh", for the KDF defined by the new group's ciphersuite. </del> Note that these three steps may be done by the same group member or different members.  For example, if a group member sends a commit with an inline ReInit proposal (steps 1 and 2), but then goes


as specified in I-D.ietf-mmusic-sctp-sdp, Section 6, and the value stored.  Otherwise, use the specified default. <ins> As required by RFC4566, Section 5.13, unknown attribute lines MUST be ignored. </ins> 5.7.3. Assuming parsing completes successfully, the parsed description is


first.  Likewise, a server MAY send multiple CertificateRequest messages at once without having completed earlier client authentication requests before.  In contrast, implementations MUST <del> NOT have send KeyUpdate, NewConnectionId or RequestConnectionId </del> <ins> NOT have sent KeyUpdate, NewConnectionId or RequestConnectionId </ins> message if an earlier message of the same type has not yet been acknowledged.


We sometimes refer to this message as the _report_. The message contains the "task" fields of the previous request.  In addition, it includes the time (in seconds since the beginning of UNIX time) at <del> which the report was generated, the helper's HPKE config id, endpoint URL, and the helper and leader shares.  The helper share has the following structure: </del> <ins> which the report was generated, the helper's HPKE config id, and the helper and leader shares.  The helper share has the following structure: </ins> Field "enc" encodes the helper's encapsulated HPKE context.  The remainder of the structure contains the share itself, the structure


At any time after the server has received the client Finished message, it MAY send a NewSessionTicket message.  This message creates a unique association between the ticket value and a secret <del> PSK derived from the resumption main secret (see cryptographic- </del> <ins> PSK derived from the resumption secret (see cryptographic- </ins> computations). The client MAY use this PSK for future handshakes by including the


IANA is requested to Create an entry, ticket_request(TBD), in the existing registry for ExtensionType (defined in RFC8446), with "TLS <del> 1.3" column values being set to "CH", and "Recommended" column being set to "Yes". </del> <ins> 1.3" column values being set to "CH, EE", and "Recommended" column being set to "Yes". </ins> 5.


Clients SHOULD send a CANCEL_PUSH frame upon receipt of a PUSH_PROMISE frame carrying a request that is not cacheable, is not known to be safe, that indicates the presence of a request body, or <del> for which it does not consider the server authoritative. </del> <ins> for which it does not consider the server authoritative.  Any corresponding responses MUST NOT be used or cached. </ins> Each pushed response is associated with one or more client requests. The push is associated with the request stream on which the


The use of source control improves traceability and visibility of changes.  Issue tracking can be used to manage open issues and provide a record of their resolution.  Pull requests allow for better <del> engagement on technical and edditorial changes, and encourage </del> <ins> engagement on technical and editorial changes, and encourage </ins> contributions from a larger set of contributors.  Using GitHub can also broaden the community of contributors for a specification.


with a HelloRetryRequest.  A client MUST NOT include the "early_data" extension in its followup ClientHello. <del> In order to accept early data, the server server MUST have accepted a PSK cipher suite and selected the the first key offered in the client's "pre_shared_key" extension.  In addition, it MUST verify that the following values are consistent with those negotiated in the </del> <ins> In order to accept early data, the server MUST have accepted a PSK cipher suite and selected the first key offered in the client's "pre_shared_key" extension.  In addition, it MUST verify that the following values are consistent with those negotiated in the </ins> connection during which the ticket was established. The TLS version number, AEAD algorithm, and the hash for HKDF. <del> The selected ALPN RFC7443 value, if any. </del> <ins> The selected ALPN RFC7301 protocol, if any. </ins> Future extensions MUST define their interaction with 0-RTT.


The "version" and "ciphersuite" values in the Welcome MUST be the same as those used by the old group. <ins> The "epoch" in the Welcome message MUST be 1. </ins> Each LeafNode in a new subgroup MUST match some LeafNode in the original group.  In this context, a pair of LeafNodes is said to "match" if the identifiers presented by their respective credentials are considered equivalent by the application. <del> In addition, to avoid key re-use, the "psk_nonce" included in the "PreSharedKeyID" object MUST be a randomly sampled nonce of length "KDF.Nh". </del> Resumption PSKs with usage "branch" MUST NOT be used in other contexts.  A PreSharedKey proposal with type "resumption" and usage "branch" MUST be considered invalid.


the unprotected requests and responses, plus protections for traffic analysis; see ta. <ins> Nonsecure requests - such those with the "http" scheme as opposed to the "https" scheme - SHOULD NOT be used if the Oblivious Gateway and Target Resources are operated by different entities as that would expose both requests and response to modification or inspection by a network attacker. 7.4. </ins> An Oblivious Gateway Resource needs to have a plan for replacing keys.  This might include regular replacement of keys, which can be assigned new key identifiers.  If an Oblivious Gateway Resource


4.2. <del> WebTransport clients can initiate bidirectional streams by opening an HTTP/3 bidirectional stream and sending an HTTP/3 frame with type </del> <ins> WebTransport endpoints can initiate bidirectional streams by opening an HTTP/3 bidirectional stream and sending an HTTP/3 frame with type </ins> "WEBTRANSPORT_STREAM" (type=0x41).  The format of the frame SHALL be the frame type, followed by the session ID, encoded as a variable- length integer, followed by the user-specified stream data (fig-bidi- client).  The frame SHALL last until the end of the stream. <del> 4.3. </del> <ins> HTTP/3 does not by itself define any semantics for server-initiated bidirectional streams.  If WebTransport setting is negotiated by both endpoints, the syntax of the server-initiated bidirectional streams SHALL be the same as the syntax of client-initated bidirectional streams, that is, a sequence of HTTP/3 frames.  The only frame defined by this document for use within server-initiated bidirectional streams is WEBTRANSPORT_STREAM. </ins> <del> WebTransport servers can initiate bidirectional streams by opening a bidirectional stream within the HTTP/3 connection.  Note that since HTTP/3 does not define any semantics for server-initiated bidirectional streams, this document is a normative reference for the semantics of such streams for all HTTP/3 connections in which the SETTINGS_ENABLE_WEBTRANSPORT option is negotiated.  The format of those streams SHALL be the session ID, encoded as a variable-length integer, followed by the user-specified stream data (fig-bidi- server). </del> <ins> TODO: move the paragraph above into a separate draft; define what happens with already existing HTTP/3 frames on server-initiated bidirectional streams. </ins> <del> 4.4. </del> <ins> 4.3. </ins> Datagrams can be sent using the DATAGRAM frame as defined in QUIC- DATAGRAM and HTTP3-DATAGRAM.  For all HTTP/3 connections in which the


6.7.1. <del> An ACP node announces its ability to support IKEv2 as the ACP secure channel protocol in GRASP as "IKEv2". </del> <ins> An ACP node announces its ability to support IPsec, negotiated via IKEv2, as the ACP secure channel protocol in GRASP as the "IKEv2" method for the "AN_ACP" objective. </ins> 6.7.1.1. To run ACP via IPsec natively, no further IANA assignments/ definitions are required. <del> An ACP node that is supporting native IPsec MUST use IPsec security setup via IKEv2 for tunnel mode and IPsec/IKE signaling accordingly for IPv6 payload (e.g.: ESP next header of 41).  It MUST use local and peer link-local IPv6 addresses for encapsulation. Authentication MUST use the ACP domain certificates.  Certificate Encoding MUST support "PKCS #7 wrapped X.509 certificate" (0) (see IKEV2IANA for this and other IANA IKEv2 parameter names used in this text).  If certificate chains are used, all intermediate certificates up to, but not including the locally provisioned trust anchor certificate must be signaled. </del> <ins> The ACP usage of IPsec and IKEv2 mandates a narrow profile of the current standards-track usage guidance for IPsec RFC8221 and IKEv2 RFC8247.  This profile provides for stringent security properties and can exclude deprecated/legacy algorithms because there is no need for interoperability with legacy equipment for ACP channels.  Any such backward compatibility would lead only to increased attack surface and implementation complexity, for no benefit. An ACP node that is supporting native IPsec MUST use IPsec in tunnel mode, negotiated via IKEv2, and with IPv6 payload (e.g., ESP Next Header of 41).  It MUST use local and peer link-local IPv6 addresses for encapsulation.  Manual keying MUST NOT be used (independent of the security weaknesses of manual keying, it is incompatible with an autonomic platform). </ins> IPsec tunnel mode is required because the ACP will route/forward packets received from any other ACP node across the ACP secure


2. <del> Clients MUST NOT include MD5 and SHA-1 in the signature_algorithms extension.  If a client does not send a signature_algorithms extension, then the server MUST abort the handshake and send a handshake_failure alert, except when digital signatures are not used (for example, when using PSK ciphers). </del> <ins> Clients MUST include the signature_algorithms extension.  Clients MUST NOT include MD5 and SHA-1 in this extension. </ins> 3.


7.2. <del> Push services typically store messages for some time to allow for limited recovery from transient faults.  If a push message is stored, but not delivered, the push service can indicate the probable duration of storage by including expiration information in the response to the push request. </del> <ins> Storage of push messages based on the TTL header field comprises a potentially significant amount of storage for a push service.  A push service is not obligated to store messages indefinitely.  A push service is able to indicate how long it intends to retain a message to an application server using the TTL header field (see ttl). </ins> <del> A push service is not obligated to store messages indefinitely.  If a user agent is not actively monitoring for push messages, those messages can be lost or overridden by newer messages on the same subscription. </del> <ins> A user agent that does not actively monitor for push messages will not receive messages that expire during that interval. </ins> <del> Push messages that were stored and not delivered to a user agent are </del> <ins> Push messages that are stored and not delivered to a user agent are </ins> delivered when the user agent recommences monitoring.  Stored push messages SHOULD include a Last-Modified header field (see Section 2.2 of RFC7232) indicating when delivery was requested by an application


anchors.  Clients can fetch these alternates and use their own heuristics to decide which is optimal. <del> An ACME client MAY attempt to fetch the certificate with a GET request.  If the server does not allow GET requests for certificate resources, then it will return an error as described in post-as-get. On receiving such an error, the client SHOULD fall back to a POST-as- GET request. </del> A certificate resource represents a single, immutable certificate. If the client wishes to obtain a renewed certificate, the client initiates a new order process to request one.


Enumeration: can take one value of a finite set of values, dependent on the property itself.  The representation is <del> implementation dependent; however, implementations MUST provide a method for the application to determine the entire set of possible values for each property. </del> <ins> implementation dependent. </ins> Preference: can take one of five values (Prohibit, Avoid, Ignore, Prefer, Require) for the level of preference of a given property


server configuration on the responses to OPTIONS request sent to the WHIP endpoint URL before the POST request is sent. <ins> NOTE: Depending on the ICE Agent implementation, the WHIP client may need to call the setConfiguration method before calling the setLocalDespcription method with the local SDP offer in order to avoid having to perform an ICE restart for applying the updated STUN/ TURN server configuration on the next ICE gathering phase. </ins> The generation of the TURN server credentials may require performing a request to an external provider, which can both add latency to the OPTION request processing and increase the processing required to


UDP.  The client can send and recieve UDP IP packets to the either of the server addresses to enable Happy Eyeballs through the proxy. <del> 7. </del> <ins> 8. </ins> There are significant risks in allowing arbitrary clients to establish a tunnel to arbitrary servers, as that could allow bad


The JWK representation of the new key <del> Both of these thumbprints MUST be computed as specified in RFC7638, using the SHA-256 digest.  The values in the "oldKey" and "newKey" fields MUST be the base64url encodings of the thumbprints. </del> The client then encapsulates the key-change object in a JWS, signed with the client's current account key (i.e., the key matching the "oldKey" value).


12. <ins> 12.1. Implementers need to pay close attention to the isolation and protection of the Attester and the factory processes for provisioning the Attestation Key Material.  When either of these are compromised, the remote attestation becomes worthless because the attacker can forge Evidence. Remote attestation applies to use cases with a range of security requirements, so the protections discussed here range from low to high security where low security may be only application or process isolation by the device's operating system and high security involves specialized hardware to defend against physical attacks on a chip. 12.1.1. It is assumed that the Attester is located in an isolated environment of a device like a process, a dedicated chip a TEE or such that collects the Claims, formats them and signs them with an Attestation Key. The Attester must be protected from unauthorized modification to ensure it behaves correctly.  There must also be confidentiality so that the signing key is not captured and used elsewhere to forge evidence. In many cases the user or owner of the device must not be able to modify or exfiltrate keys from the Attesting Environment of the Attester.  For example the owner or user of a mobile phone or FIDO authenticator is not trusted.  The point of remote attestation is for the Relying Party to be able to trust the Attester even though they don't trust the user or owner. Some of the measures for low level security include process or application isolation by a high-level operating system, and perhaps restricting access to root or system privilege.  For extremely simple single-use devices that don't use a protected mode operating system, like a Bluetooth speaker, the isolation might only be the plastic housing for the device. At medium level security, a special restricted operating environment like a Trusted Execution Environment (TEE) might be used.  In this case, only security-oriented software has access to the Attester and key material. For high level security, specialized hardware will likely be used providing protection against chip decapping attacks, power supply and clock glitching, faulting injection and RF and power side channel attacks. 12.1.2. Attestation key provisioning is the process that occurs in the factory or elsewhere that establishes the signing key material on the device and the verification key material off the device.  Sometimes this is referred to as "personalization". One way to provision a key is to first generate it external to the device and then copy the key onto the device.  In this case, confidentiality of the generator, as well as the path over which the key is provisioned, is necessary.  This can be achieved in a number of ways. Confidentiality can be achieved entirely with physical provisioning facility security involving no encryption at all.  For low-security use cases, this might be simply locking doors and limiting personnel that can enter the facility.  For high-security use cases, this might involve a special area of the facility accessible only to select security-trained personnel. Cryptography can also be used to support confidentiality, but keys that are used to then provision attestation keys must somehow have been provisioned securely beforehand (a recursive problem). In many cases both some physical security and some cryptography will be necessary and useful to establish confidentiality. Another way to provision the key material is to generate it on the device and export the verification key.  If public key cryptography is being used, then only integrity is necessary.  Confidentiality is not necessary. In all cases, the Attestation Key provisioning process must ensure that only attestation key material that is generated by a valid Endorser is established in Attesters and then configured correctly. For many use cases, this will involve physical security at the facility, to prevent unauthorized devices from being manufactured that may be counterfeit or incorrectly configured. 12.2. </ins> Any solution that conveys information used for security purposes, whether such information is in the form of Evidence, Attestation Results, Endorsements, or Appraisal Policy must support end-to-end


server implementation declines all PSK identities with different SNI values, these two values are always the same. <del> Note: Although the resumption main secret depends on the client's second flight, a server which does not request certificate-based client authentication MAY compute the remainder of the transcript </del> <ins> Note: Although the resumption ecret depends on the client's second flight, a server which does not request certificate-based client authentication MAY compute the remainder of the transcript </ins> independently and then send a NewSessionTicket immediately upon sending its Finished rather than waiting for the client Finished. This might be appropriate in cases where the client is expected to


Provider (SP) as described in I-D.ietf-mls-architecture.  In particular, we assume the SP provides the following services: <del> A long-term identity key provider which allows clients to </del> <ins> A long-term signature key provider which allows clients to </ins> authenticate protocol messages in a group. A broadcast channel, for each group, which will relay a message to


2. <ins> 2.1. </ins> MLS provides a way for _clients_ to form _groups_ within which they can communicate securely.  For example, a set of users might use clients on their phones or laptops to join a group and communicate with each other.  A group may be as small as two clients (e.g., for simple person to person messaging) or as large as tens of thousands. <del> A client that is part of a group is a _member_ of that group. </del> <ins> A client that is part of a group is a _member_ of that group.  As groups change membership and group or member properties, they advance from one _epoch_ to another and the cryptographic state of the group evolves. The group is represented using a _ratchet tree_, which represents the members as the leaves of a tree.  It is used to efficiently encrypt to subsets of the members.  Each member has a _LeafNode_ object in the tree holding the client's identity, credentials, and capabilities. Various messages are used in the evolution from epoch to epoch.  A _Proposal_ message proposes a change to be made in the next epoch, such as adding or removing a member.  A _Commit_ message initiates a new epoch by instructing members of the group to implement a collection of proposals.  Proposals and Commits are collectively called _Handshake messages_.  A _KeyPackage_ provides keys that can be used to add the client to a group, including its LeafNode, and _Signature Key_.  A _Welcome_ message provides a new member to the group with the information to initialize their state for the epoch in which they were added. Of course most (but not all) applications use MLS to send encrypted group messages.  An _application message_ is an MLS message with an arbitrary application payload. Finally, a _PublicMessage_ contains an integrity-protected MLS Handshake message, while a _PrivateMessage_ contains a confidential, integrity-protected Handshake or Application message. For a more detailed explanation of these terms, please consult the MLS protocol specification. 2.2. </ins> In order to communicate securely, users initially interact with services at their disposal to establish the necessary values and


1.2. <del> draft-14 - Allow cookies to be longer. </del> <ins> draft-14 Allow cookies to be longer. </ins> draft-13


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


datagram.  Omitting the length field MUST only be used for the last record in a datagram. <del> Implementations which send multiple records in the same datagram SHOULD omit the connection id from all but the first record; receiving implementations MUST assume that any subsequent records without connection IDs belong to the same association.  Sending implementations MUST NOT mix records from multiple DTLS associations in the same datagram.  If the second or later record has a connection ID which does not correspond to the same association used for previous records, the rest of the datagram MUST be discarded. </del> <ins> If a connection ID is negotiated, then it MUST be contained in all datagrams.  Sending implementations MUST NOT mix records from multiple DTLS associations in the same datagram.  If the second or later record has a connection ID which does not correspond to the same association used for previous records, the rest of the datagram MUST be discarded. </ins> When expanded, the epoch and sequence number can be combined into an unpacked RecordNumber structure, as shown below:


5.2.10. <ins> This property specifies whether an application considers it useful to transfer data across multiple paths between the same end hosts. Generally, in most cases, this will improve performance (e.g., achieve greater throughput).  One possible side-effect is increased jitter, which may be problematic for delay-sensitive applications. The recommended default is to have this option. 5.2.11. </ins> This property specifies whether an application wants to use the connection for sending and/or receiving data.  Possible values are:


If present, the IP prefix length in "target" SHALL be preceded by a percent-encoded slash ("/"): "%2F".  The IP prefix length MUST <del> represent an integer between 0 and the length of the IP address in bits, inclusive. </del> <ins> represent a decimal integer between 0 and the length of the IP address in bits, inclusive. </ins> <del> "ipproto" MUST represent an integer between 0 and 255 inclusive, or the wildcard value "*". </del> <ins> "ipproto" MUST represent a decimal integer between 0 and 255 inclusive, or the wildcard value "*". </ins> IP proxies MAY perform access control using the scoping information provided by the client: if the client is not authorized to access any of the destinations included in the scope, then the IP proxy can immediately fail the request. <del> 4.6. </del> <ins> 4.7. </ins> This document defines multiple new capsule types that allow endpoints to exchange IP configuration information.  Both endpoints MAY send any number of these new capsules. <del> 4.6.1. </del> <ins> 4.7.1. </ins> The ADDRESS_ASSIGN capsule (see iana-types for the value of the capsule type) allows an endpoint to inform its peer of the list of IP


tunnel due to a period of inactivity, but they MUST close the request stream when doing so. <ins> A successful response (as defined in Sections resp1 and resp23) indicates that the IP proxy has established an IP tunnel and is willing to proxy IP payloads.  Any response other than a successful response indicates that the request has failed; thus, the client MUST abort the request. </ins> Along with a successful response, the IP proxy can send capsules to assign addresses and advertise routes to the client (capsules).  The client can also assign addresses and advertise routes to the IP proxy for network-to-network routing. <del> By virtue of the definition of the Capsule Protocol (see HTTP-DGRAM), IP proxying requests do not carry any message content.  Similarly, successful IP proxying responses also do not carry any message content. 4.1. </del> <ins> 4.2. </ins> When using HTTP/1.1 H1, an IP proxying request will meet the following requirements:


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


6.2. <del> In this solution, the server does not reduce the congestion window with the same amount when the "repaired packet" signal is received, i.e. when a packet has been lost but repaired.  Example of this solution could be based on RFC8511 or considering that recovering an isolated packet is not an actual sign of congestion. </del> <ins> [MICHAEL: this is even just a terrible idea.  There's no good rationale to back off less when a packet is repaired.]  In this solution, the server does not reduce the congestion window with the same amount when the "repaired packet" signal is received, i.e. when a packet has been lost but repaired.  Example of this solution could be based on RFC8511 or considering that recovering an isolated packet is not an actual sign of congestion. </ins> The advantage of the solution is that in cases where there is no actual congestion, coding could help in improving the transmission


Integer <del> Default: :the TCP default </del> <ins> the TCP default </ins> This time value is advertised via the TCP User Timeout Option (UTO) RFC5482 at the remote endpoint to adapt its own "Timeout for aborting


protect against passive attacker as active attackers can always get the Responder's identity by sending their own message_1.  EDHOC uses the Expand function (typically HKDF-Expand) as a binary additive <del> stream cipher.  HKDF-Expand is not often used as it is slow on long messages, and most applications require both IND-CCA confidentiality as well as integrity protection.  For the encryption of message_2, any speed difference is negligible, IND-CCA does not increase security, and integrity is provided by the inner MAC (and signature depending on method). </del> <ins> stream cipher which is proven secure as long as the expand function is a PRF.  HKDF-Expand is not often used as a stream cipher as it is slow on long messages, and most applications require both IND-CCA confidentiality as well as integrity protection.  For the encryption of message_2, any speed difference is negligible, IND-CCA does not increase security, and integrity is provided by the inner MAC (and signature depending on method). </ins> Requirements for how to securely generate, validate, and process the ephemeral public keys depend on the elliptic curve.  For X25519 and


(method equals 1 or 3), then mac_length_2 is the EDHOC MAC length of the selected cipher suite.  If the Responder authenticates with a signature key (method equals 0 or 2), then <del> mac_length_2 is equal to the output size of the EDHOC hash algorithm of the selected cipher suite. </del> <ins> mac_length_2 is equal to hash_length. </ins> ID_CRED_R - identifier to facilitate the retrieval of CRED_R, see


draft-04 <ins> Renumber the new handshake messages to be somewhat more consistent with existing convention and to remove a duplicate registration. </ins> Remove renegotiation. draft-03


The key exchange and authentication modes this PSK is allowed to be used with <del> The Application-Layer Protocol Negotiation (ALPN) label(s) </del> <ins> The Application-Layer Protocol Negotiation (ALPN) protocol, if any is to be used </ins> The Server Name Indication (SNI), if any is to be used


9. <ins> Extensions to CONNECT-IP can define behavior changes to this mechanism.  Such extensions SHOULD define new capsule types to exchange configuration information if needed.  It is RECOMMENDED for extensions that modify addressing to specify that their extension capsules be sent before the ADDRESS_ASSIGN capsule and that they do not take effect until the ADDRESS_ASSIGN capsule is parsed.  This allows modifications to address assignement to operate atomically. Similarly, extensions that modify routing SHOULD behave similarly with regards to the ROUTE_ADVERTISEMENT capsule. 10. </ins> There are significant risks in allowing arbitrary clients to establish a tunnel to arbitrary servers, as that could allow bad actors to send traffic and have it attributed to the proxy.  Proxies


In order to limit the attacks described in sec-ice-hammer, an ICE agent MUST limit the total number of connectivity checks the agent <del> performs across all check lists to a specific value, and this value MUST be configurable.  A default of 100 is RECOMMENDED.  This limit is enforced by discarding the lower-priority candidate pairs until there are less than 100.  It is RECOMMENDED that a lower value be utilized when possible, set to the maximum number of plausible checks that might be seen in an actual deployment configuration.  The requirement for configuration is meant to provide a tool for fixing this value in the field if, once deployed, it is found to be problematic. </del> <ins> performs across all check lists in the check list set.  This is done by limiting the total number of candidate pairs in the check list set.  The default limit of candidate pairs for the check list set is 100, but the value MUST be configurable.  The limit is enforced by, within in each check list, discarding lower-priority candidate pairs until the total number of candidate pairs in the check list set is smaller than the limit value.  The discarding SHOULD be done evenly so that the number of candidate pairs in each check list is reduced the same amount. It is RECOMMENDED that a lower limit value than the default is picked when possible, and that the value is set to the maximum number of plausible candidate pairs that might be created in an actual deployment configuration.  The requirement for configuration is meant to provide a tool for fixing this value in the field if, once deployed, it is found to be problematic. </ins> 6.1.2.6.


is a CDDL defined type, and Description is a text string.  The initial contents of the registry is shown in fig-error-codes. <del> 9.4. </del> <ins> 9.5. </ins> IANA has added the well-known URI 'edhoc' to the Well-Known URIs registry.


This limit does act as an additional constraint on datagram size in the same way as the path MTU, but it is a property of the <del> endpoint and not the path; see packet-size.  It is expected that </del> <ins> endpoint and not the path; see datagram-size.  It is expected that </ins> this is the space an endpoint dedicates to holding incoming packets.


21.12.1. The QUIC handshake incorporates the TLS 1.3 handshake and enjoys the <del> cryptographic properties described in Appendix E.1 of TLS13. </del> <ins> cryptographic properties described in Appendix E.1 of TLS13.  Many of the security properties of QUIC depend on the TLS handshake providing these properties.  Any attack on the TLS handshake could affect QUIC. </ins> <del> In addition to those properties, the handshake is intended to provide some defense against DoS attacks on the handshake, as described below. </del> <ins> Any attack on the TLS handshake that compromises the secrecy or uniqueness of session keys affects other security guarantees provided by QUIC that depends on these keys.  For instance, migration (migration) depends on the efficacy of confidentiality protections, both for the negotiation of keys using the TLS handshake and for QUIC packet protection, to avoid linkability across network paths. An attack on the integrity of the TLS handshake might allow an attacker to affect the selection of application protocol or QUIC version. In addition to the properties provided by TLS, the QUIC handshake provides some defense against DoS attacks on the handshake. </ins> 21.12.1.1.


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


Selection properties are represented as preferences, which can have one of five preference levels: <ins> In addition, the pseudo-level "Default" can be used to reset the property to the default level used by the implementation.  This level will never show up when queuing the value of a preference - the effective preference must be returned instead. </ins> Internally, the transport system will first exclude all protocols and paths that match a Prohibit, then exclude all protocols and paths that do not match a Require, then sort candidates according to


response to receiving a Retry. A client MUST NOT reset the packet number for any packet number space <del> after processing a Retry packet; packet-0rtt contains more information on this. </del> <ins> after processing a Retry packet.  In particular, 0-RTT packets contain confidential information that will most likely be retransmitted on receiving a Retry packet.  The keys used to protect these new 0-RTT packets will not change as a result of responding to a Retry packet.  However, the data sent in these packets could be different than what was sent earlier.  Sending these new packets with the same packet number is likely to compromise the packet protection for those packets because the same key and nonce could be used to protect different content. </ins> A server acknowledges the use of a Retry packet for a connection using the retry_source_connection_id transport parameter; see


notification provider have to be trusted to avoid making correlation on which devices are recipients of the same message. <del> For secure messaging systems, push notification are often sent real- </del> <ins> For secure messaging systems, push notifications are often sent real- </ins> time as it is not acceptable to create artificial delays for message retrieval.


encrypt or (successfully) decrypt a message or <del> if a key, nonce or secret derived from S has been consumed.  (This goes both for values derived via Derive-Secret and HKDF-Expand- Label). </del> <ins> if a key, nonce or secret derived from S has been consumed. (This goes both for values derived via Derive-Secret and HKDF-Expand- Label.) </ins> Here, S may be the init_secret, update_secret, epoch_secret, application_secret as well as any secret in the AS Tree or one of the


publication, the early allocation will be deprecated in favor of this assignment. <ins> A new column "DTLS-Only" is added to the registry.  The valid entries are "Y" if the extension is only applicable to DTLS, "N" otherwise. All the pre-existing entries are given the value "N". </ins> Note: The value "N" in the Recommended column is set because this extension is intended only for specific use cases.  This document describes the behavior of this extension for DTLS 1.2 only; it is not


Authorization Data" under the new group name "Ephemeral Diffie- Hellman Over COSE (EDHOC)".  The registration procedure is "Specification Required".  The columns of the registry are Label, <del> Message, Description, and Reference, where Label is an integer and the other columns are text strings. </del> <ins> Description, and Reference, where Label is a positive integer and the other columns are text strings. </ins> 9.6.


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


case, the advertised route is restricted to 192.0.2.0/24, rather than 0.0.0.0/0. <del> 6.2. </del> <ins> 7.2. </ins> The following example shows an IP flow forwarding setup, where a client requests to establish a forwarding tunnel to


absolute index less than the Base, this representation starts with the '1' 1-bit pattern, followed by the "S" bit indicating whether the reference is into the static or dynamic table.  The 6-bit prefix <del> integer (see Section 5.1 of RFC7541) that follows is used to locate the table entry for the header name.  When S=1, the number represents </del> <ins> integer (see prefixed-integers) that follows is used to locate the table entry for the header field.  When S=1, the number represents </ins> the static table index; when S=0, the number is the relative index of the entry in the dynamic table.


Reference: [[this document]] <del> 9.7. </del> <ins> 9.8. </ins> The IANA Registries established in this document is defined as "Expert Review".  This section gives some general guidelines for what


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


relatively short period of time, clients have an indication that the credential might have been created without the user's knowledge.  Due to the asynchronous nature of MLS, however, there may be transient <del> inconsistencies in a user's device set, so correlating users' clients </del> <ins> inconsistencies in a user's client set, so correlating users' clients </ins> across groups is more of a detection mechanism than a prevention mechanism.


header field with the 'N' bit set, it MUST use a literal representation to forward this header field.  This bit is intended for protecting header field values that are not to be put at risk by <del> compressing them (see Section 7.1 of RFC7541 for more details). </del> <ins> compressing them (see security-considerations for more details). </ins> The fourth ("S") bit indicates whether the reference is to the static <del> or dynamic table.  The 4-bit prefix integer (see Section 5.1 of RFC7541) that follows is used to locate the table entry for the header name.  When S=1, the number represents the static table index; when S=0, the number is the relative index of the entry in the dynamic table. </del> <ins> or dynamic table.  The 4-bit prefix integer (see prefixed-integers) that follows is used to locate the table entry for the header name. When S=1, the number represents the static table index; when S=0, the number is the relative index of the entry in the dynamic table. Only the header field name is taken from the dynamic table entry; the header field value is encoded as an 8-bit prefix string literal (see string-literals). </ins> 4.5.5. <del> If the name entry is in the dynamic table with an absolute index greater than or equal to the Base, the representation starts with the '0000' four-bit pattern.  The fifth bit is the 'N' bit as described in literal-name-reference.  Finally, the header field name is represented using the post-base index of that entry (see post-base) encoded as an integer with a 3-bit prefix. </del> <ins> A literal header field with post-base name reference represents a header field where the name matches the header field name of a dynamic table entry with an absolute index greater than or equal to the Base. This representation starts with the '0000' four-bit pattern.  The fifth bit is the 'N' bit as described in literal-name-reference. This is followed by a post-base index of the dynamic table entry (see post-base) encoded as an integer with a 3-bit prefix (see prefixed- integers). Only the header field name is taken from the dynamic table entry; the header field value is encoded as an 8-bit prefix string literal (see string-literals). </ins> 4.5.6. <del> An addition to the header table where both the header field name and the header field value are represented as string literals (see primitives) starts with the '001' three-bit pattern. The fourth bit, 'N', indicates whether an intermediary is permitted to add this header to the dynamic header table on subsequent hops. When the 'N' bit is set, the encoded header MUST always be encoded with a literal representation.  In particular, when a peer sends a header field that it received represented as a literal header field with the 'N' bit set, it MUST use a literal representation to forward this header field.  This bit is intended for protecting header field values that are not to be put at risk by compressing them (see Section 7.1 of RFC7541 for more details). The name is represented as a 4-bit prefix string literal, while the value is represented as an 8-bit prefix string literal. </del> <ins> The literal header field without name reference representation encodes a header field name and header field value as string literals. This representation begins with the '001' three-bit pattern.  The fourth bit is the 'N' bit as described in literal-name-reference. The name follows, represented as a 4-bit prefix string literal, then the value, represented as an 8-bit prefix string literal (see string- literals). </ins> 5.


ServerConfiguration format. The semantics of this message are to establish a shared state between <del> the client and server for use with the "known_configuration" extension with the key specified in key and with the handshake </del> <ins> the client and server for use with the "early_data" extension with the key specified in "static_key_share" and with the handshake </ins> parameters negotiated by this handshake. When the ServerConfiguration message is sent, the server MUST also send a Certificate message and a CertificateVerify message, even if <del> the "known_configuration" extension was used for this handshake, thus </del> <ins> the "early_data" extension was used for this handshake, thus </ins> requiring a signature over the configuration before it can be used by the client.  Clients MUST NOT rely on the ServerConfiguration message until successfully receiving and processing the server's Certificate,


If the answer contains valid bundle groups, discard any ICE components for the "m=" sections that will be bundled onto the primary ICE components in each bundle, and begin muxing these "m=" <del> sections accordingly, as described in RFC8843. </del> <ins> sections accordingly, as described in I-D.ietf-mmusic-rfc8843-bis. </ins> If the description is of type "answer" and there are still remaining candidates in the ICE candidate pool, discard them.


of the first ClientHelloInner via the derived ech_hrr_key by modifying HPKE setup as follows: <del> Clients then encrypt the second ClientHelloInner using this new HPKE context.  In doing so, the encrypted value is also authenticated by ech_hrr_key.  The rationale for this is described in flow-hrr-hijack. </del> <ins> The "info" parameter to SetupPSKS is the concatenation of "tls ech", a zero byte, and the serialized ECHConfig.  Clients then encrypt the second ClientHelloInner using this new HPKE context.  In doing so, the encrypted value is also authenticated by ech_hrr_key.  The rationale for this is described in flow-hrr-hijack. </ins> Client-facing servers perform the corresponding process when decrypting second ClientHelloInner messages.  In particular, upon


This property specifies that a message should be sent in such a way that the transport protocol ensures all data is received on the other side without corruption.  Changing the 'Reliable Data Transfer' <del> property on Messages is only possible if the transport protocol supports partial reliability (see prop-partially-reliable). Therefore, for protocols that always transfer data reliably, this property is always true and for protocols that always transfer data unreliably, this property is always false.  Changing it may generate an error. </del> <ins> property on Messages is only possible if the Connection supports reliability.  When this is not the case, changing it will generate an error. </ins> 7.3.8.


Specific processing MUST also be applied for the following attribute lines: <del> If present, a single "a=ice-lite" line is parsed as specified in RFC5245, Section 15.3, and a value indicating the presence of ice- lite is stored. </del> If present, a single "a=ice-ufrag" line is parsed as specified in RFC5245, Section 15.4, and the ufrag value is stored.


process can be represented and performed by Internet protocols with no out-of-band human intervention. <del> When an operator deploys a current HTTPS server, it generally prompts him to generate a self-signed certificate.  When an operator deploys an ACME-compatible web server, the experience would be something like this: </del> <ins> When deploying a current HTTPS server, an operator generally gets a prompt to generate a self-signed certificate.  When an operator deploys an ACME-compatible web server, the experience would be something like this: </ins> The ACME client prompts the operator for the intended domain name(s) that the web server is to stand for.


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


entity that receives an Initial packet from a client can recover the keys that will allow them to both read the contents of the packet and generate Initial packets that will be successfully authenticated at <del> either endpoint. </del> <ins> either endpoint.  The AEAD also protects Initial packets against accidental modification. </ins> All other packets are protected with keys derived from the cryptographic handshake.  The cryptographic handshake ensures that


transceiver direction is intersected with the offered direction, as explained in the sec.generating-an-answer section below. <ins> Note that while setDirection sets the direction attribute of the transceiver immediately (sec.transceiver-direction), this attribute does not immediately affect whether the transceiver's RtpSender will send or its RtpReceiver will receive.  The direction in effect is represented by the currentDirection attribute, which is only updated when an answer is applied. </ins> 4.2.4. The direction method returns the last value passed into setDirection.


blind RSA documents also apply in the Privacy Pass use-case. Considerations related to broader privacy and security concerns in a multi-Client and multi-Issuer setting are deferred to the <del> Architecture document I-D.ietf-privacypass-architecture. </del> <ins> Architecture document ARCHITECTURE. </ins> Beyond these considerations, it is worth highlighting the fact that Client TokenRequest messages contain truncated token key IDs.  This


If the m= section proto value indicates use of RTP: <del> If there is no RtpTransceiver associated with this m= section (which will only happen when applying an offer), find one and associate it with this m= section according to the following steps: </del> <ins> If there is no RtpTransceiver associated with this m= section, find one and associate it with this m= section according to the following steps.  Note that this situation will only occur when applying an offer. </ins> Find the RtpTransceiver that corresponds to this m= section, using the mapping between transceivers and m= section


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


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


The primary function of a connection ID is to ensure that changes in addressing at lower protocol layers (UDP, IP, and below) don't cause <del> packets for a QUIC connection to be delivered to the wrong endpoint. The connection ID is used by endpoints and the intermediaries that support them to ensure that each QUIC packet can be delivered to the correct instance of an endpoint.  At the endpoint, the connection ID is used to identify which QUIC connection the packet is intended for. </del> <ins> packets for a QUIC connection to be delivered to the wrong QUIC endpoint.  The connection ID is used by endpoints and the intermediaries that support them to ensure that each QUIC packet can be delivered to the correct instance of an endpoint.  At the endpoint, the connection ID is used to identify which QUIC connection the packet is intended for. </ins> The connection ID is chosen by each endpoint using version-specific methods.  Packets for the same QUIC connection might use different


protocols are not incorrectly swapped, Transport Services systems SHOULD only automatically generate equivalent Protocol Stacks when the transport security protocols within the stacks are identical. <del> Specifically, a Transport System would consider protocols </del> <ins> Specifically, a Transport Services system would consider protocols </ins> identical only if they are of the same type and version.  For example, the same version of TLS running over two different transport Protocol Stacks are considered equivalent, whereas TLS


This protocol MUST be used with https scheme URI RFC7230. <del> This protocol MUST use HTTP/2 RFC7540 or its successors in order to satisfy the security requirements of DNS over HTTPS.  Further, the messages in classic UDP based DNS RFC1035 are inherently unordered and have low overhead.  A competitive HTTP transport needs to support reordering, priority, parallelism, and header compression, all of which are supported by HTTP/2 RFC7540 or its successors. </del> <ins> 7.1. The minimum version of HTTP used by DOH SHOULD be HTTP/2 RFC7540. The messages in classic UDP based DNS RFC1035 are inherently unordered and have low overhead.  A competitive HTTP transport needs to support reordering, parallelism, priority, and header compression to acheive similar performance.  Those features were introduced to HTTP in HTTP/2 RFC7540.  Earlier versions of HTTP are capable of conveying the semantic requirements of DOH but would result in very poor performance for many uses cases. </ins> 8.


2. <del> To start a request, the client instance sends RFC8259 document with </del> <ins> To start a request, the client instance sends a RFC8259 document with </ins> an object as its root.  Each member of the request object represents a different aspect of the client instance's request.  Each field is described in detail in a section below. Additional members of this request object can be defined by <del> extensions to this protocol as described in </del> <ins> extensions to this protocol as described in request-extending. </ins> A non-normative example of a grant request is below:


12.34. <ins> GNAP allows the RO to be contacted by the AS asynchronously, outside the regular flow of the protocol.  This allows for some advanced use cases, such as cross-user authentication or information release, but such advanced use cases have some distinct issues that implementors need to be fully aware of before using these features. First, in many applications, the return of a subject information to the client instance could indicate to the client instance that the end-user is the party represented by that information, functionally allowing the end-user to authenticate to the client application. While the details of a fully functional authentication protocol are outside the scope of GNAP, it is a common exercise for a client instance to be requesting information about the end user.  This is facilitated by the several interaction-start defined in GNAP that allow the end user to begin interaction directly with the AS. However, when the subject of the information is intentionally not the end-user, the client application will need some way to differentiate between requests for authentication of the end user and requests for information about a different user.  Confusing these states could lead to an attacker having their account associated with a privileged user.  Client instances can mitigate this by having distinct code paths for primary end user authentication and requesting subject information about secondary users, such as in a call center.  In such use cases, the client software used by the resource owner (the caller) and the end-user (the agent) are generally distinct, allowing the AS to differentiate between the agent's corporate device making the request and the caller's personal device approving the request. Second, RO's interacting asynchronously do not usually have the same context as an end user in an application attempting to perform the task needing authorization.  As such, the asynchronous requests for authorization coming to the RO from the AS might have very little to do with what the RO is doing at the time.  This situation can consequently lead to authorization fatigue on the part of the RO, where any incoming authorization request is quickly approved and dispatched without the RO making a proper verification of the request.  An attacker can exploit this fatigue and get the RO to authorize the attacker's system for access.  To mitigate this, AS systems deploying asynchronous authorization should only prompt the RO when the RO is expecting such a request, and significant user experience engineering efforts need to be employed to ensure the RO can clearly make the appropriate security decision.  Furthermore, audit capability, and the ability to undo access decisions that may be ongoing, is particularly important in the asynchronous case. </ins> An attacker may aim to gain access to confidential or sensitive resources.  The measures for hardening and monitoring resource server systems (beyond protection with access tokens) is out of the scope of


Store the mDNS hostname and its related IP address in the ICE agent for future reuse. <del> Replace the IP address of the ICE host candidate with its mDNS </del> <ins> Replace the IP address of the ICE candidate with its mDNS </ins> hostname, and expose the candidate as usual. An ICE agent can implement this procedure in any way so long as it


shown below. The derivation process is as follows, where L denotes the length of <del> the underlying hash function for HKDF RFC5869. </del> <ins> the underlying hash function for HKDF RFC5869.  SS and ES denote the sources from the table above.  Whilst SS and ES may be the same in some cases, the extracted xSS and xES will not. </ins> The traffic keys are computed from xSS, xES, and the master_secret as described in traffic-key-calculation below.


default of 53).  DNS URIs normally omit the authority, or specify an IP address, but a hostname and non-default port number are allowed. <del> When a non-default port number is part of a service identifier, Port- </del> <ins> When the binding authority specifies a non-default port number, Port- </ins> Prefix Naming places the port number in an additional a prefix on the <del> name.  For example, SVCB records for a DNS service identified as ""dns1.example.com:9953"" would be located at </del> <ins> name.  For example, if the binding authority is ""dns1.example.com:9953"", the client would query for SVCB records at </ins> ""_9953._dns.dns1.example.com"".  If two DNS services operating on different port numbers provide different behaviors, this arrangement allows them to preserve the distinction when specifying alternative


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


ability given to a subject to perform a given operation on a resource under the control of an RS. <del> person, organization or device. </del> <ins> person, organization or device.  It decides whether and under which conditions its attributes can be disclosed to other parties. </ins> statement asserted by an AS about a subject.


_mandatory_ <del> Reference Claims are components of Reference Values as defined in I-D.ietf-rats-architecture.  [Editor's Note: Definition might become obsolete, if replaced by Reference Values.  Is there a difference between Claims and Values here?  Analogously, why is not named Reference Claims in the RATS arch?] Reference Claims are used to appraise the Claims received from an Attester.  For example, Reference Claims MAY be Reference </del> <ins> Reference Values as defined in I-D.ietf-rats-architecture.  This specific type of Claims is used to appraise Claims incorporated in Evidence.  For example, Reference Values MAY be Reference </ins> Integrity Measurements (RIM) or assertions that are implicitly trusted because they are signed by a trusted authority (see <del> Endorsements in I-D.ietf-rats-architecture).  Reference Claims </del> <ins> Endorsements in I-D.ietf-rats-architecture).  Reference Values </ins> typically represent (trusted) Claim sets about an Attester's intended platform operational state.


Using a value for "N" that is small, but at least 1 (for example, 1.25) ensures that variations in round-trip time do not result in <del> under-utilization of the congestion window.  Values of 'N' larger than 1 ultimately result in sending packets as acknowledgments are received rather than when timers fire, provided the congestion window is fully utilized and acknowledgments arrive at regular intervals. </del> <ins> under-utilization of the congestion window. </ins> Practical considerations, such as packetization, scheduling delays, and computational efficiency, can cause a sender to deviate from this


The path component of the URI Template MUST start with a slash "/". <del> All template variables MUST be within the path component of the URI. </del> <ins> All template variables MUST be within the path or query components of the URI. </ins> The URI template MUST contain the two variables "target_host" and "target_port" and MAY contain other variables.


14. <del> TODO: Registries for protocol parameters, e.g., ciphersuites </del> <ins> This document requests the creation of the following new IANA registries: MLS Ciphersuites All of these registries should be under a heading of "Message Layer Security", and administered under a Specification Required policy RFC8126. 14.1. The "MLS Ciphersuites" registry lists identifiers for suites of cryptographic algorithms defined for use with MLS.  These are two- byte values, so the maximum possible value is 0xFFFF = 65535.  Values in the range 0xF000 - 0xFFFF are reserved for vendor-internal usage. Template: Value: The two-byte identifier for the ciphersuite Name: The name of the ciphersuite Reference: Where this algorithm is defined The initial contents for this registry are as follows: [[ Note to RFC Editor: Please replace "XXXX" above with the number assigned to this RFC. ]] </ins>


any web server that is accessible to the ACME server, even if it is not accessible to the ACME client. <del> The risk of SSRF through this channel is limited by the fact that the attacker can only control the domain of the URL, not the path. Nonetheless, in order to further limit the SSRF risk, ACME server operators should ensure that validation queries can only be sent to servers on the public Internet, and not, say, web services within the server operator's internal network.  Since the attacker could make requests to these public servers himself, he can't gain anything extra through an SSRF attack on ACME aside from a layer of anonymization. </del> <ins> It might seem that the risk of SSRF through this channel is limited by the fact that the attacker can only control the domain of the URL, not the path.  However, if the attacker first sets the domain to one they control, then they can send the server an HTTP redirect (e.g., a 302 response) which will cause the server to query an arbitrary URI. In order to further limit the SSRF risk, ACME server operators should ensure that validation queries can only be sent to servers on the public Internet, and not, say, web services within the server operator's internal network.  Since the attacker could make requests to these public servers himself, he can't gain anything extra through an SSRF attack on ACME aside from a layer of anonymization. </ins> 9.5.


2.2.1. A standard for providing a portal URI using DHCP or Router <del> Advertisements is described in RFC7710bis.  The CAPPORT architecture expects this URI to indicate the API described in section_api. </del> <ins> Advertisements is described in RFC7710bis.  The captive portal architecture expects this URI to indicate the API described in section_api. </ins> 2.2.2.


The MD5 and SHA-1 hashing algorithms are steadily weakening in strength and their deprecation process should begin for their use in TLS 1.2 digital signatures.  However, this document does not <del> deprecate SHA-1 in HMAC for record protection. </del> <ins> deprecate SHA-1 in HMAC for record protection.  This document updates RFC 5246 and RFC 7525. </ins> 1. The usage of MD5 and SHA-1 for signature hashing in TLS 1.2 is specified in RFC5246.  MD5 and SHA-1 have been proven to be insecure, <del> subject to collision attacks.  RFC6151 details the security considerations, including collision attacks for MD5, published in 2011.  NIST formally deprecated use of SHA-1 in 2011 NISTSP800-131A-R2 and disallowed its use for digital signatures at the end of 2013, based on both the Wang, et. al, attack and the potential for brute-force attack.  In 2016, researchers from INRIA identified a new class of transcript collision attacks on TLS (and other protocols) that rely on efficient collision-finding algorithms on the underlying hash constructions Transcript-Collision.  Further, in 2017, researchers from Google and CWI Amsterdam SHA-1-Collision proved SHA-1 collision attacks were practical.  This document updates RFC5246 and RFC7525 in such a way that MD5 and SHA-1 MUST NOT be used for digital signatures.  However, this document does not deprecate SHA-1 in HMAC for record protection. </del> <ins> subject to collision attacks Wang.  In 2011, RFC6151 detailed the security considerations, including collision attacks for MD5.  NIST formally deprecated use of SHA-1 in 2011 NISTSP800-131A-R2 and disallowed its use for digital signatures at the end of 2013, based on both the Wang, et. al, attack and the potential for brute-force attack.  In 2016, researchers from INRIA identified a new class of transcript collision attacks on TLS (and other protocols) that rely on efficient collision-finding algorithms on the underlying hash constructions Transcript-Collision.  Further, in 2017, researchers from Google and CWI Amsterdam SHA-1-Collision proved SHA-1 collision attacks were practical.  This document updates RFC5246 and RFC7525 in such a way that MD5 and SHA-1 MUST NOT be used for digital signatures.  However, this document does not deprecate SHA-1 in HMAC for record protection. </ins> 1.1. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <del> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119. </del> <ins> "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "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. </ins> 2.


Change Controller: IESG <del> 9.9. </del> <ins> 9.8.2. Type name: application Subtype name: cid-edhoc+cbor-seq </ins> <del> IANA has added the media type "application/edhoc" to the "CoAP Content-Formats" registry under the group name "Constrained RESTful Environments (CoRE) Parameters". </del> <ins> Required parameters: N/A </ins> <del> Media Type: application/edhoc </del> <ins> Optional parameters: N/A </ins> <del> Encoding: </del> <ins> Encoding considerations: binary </ins> <del> ID: TBD42 </del> <ins> Security considerations: See Section 7 of this document. </ins> <del> Reference: [[this document]] </del> <ins> Interoperability considerations: N/A Published specification: [[this document]] (this document) Applications that use this media type: To be identified Fragment identifier considerations: N/A Additional information: Magic number(s): N/A File extension(s): N/A Macintosh file type code(s): N/A Person & email address to contact for further information: See "Authors' Addresses" section. Intended usage: COMMON Restrictions on usage: N/A Author: See "Authors' Addresses" section. Change Controller: IESG 9.9. IANA has added the media types "application/edhoc+cbor-seq" and "application/cid-edhoc+cbor-seq" to the "CoAP Content-Formats" registry under the group name "Constrained RESTful Environments (CoRE) Parameters". </ins> 9.10.


1. Censorship is where an entity in a position of power - such as a <del> government, organization, or individual - supresses communication </del> <ins> government, organization, or individual - suppresses communication </ins> that it considers objectionable, harmful, sensitive, politically incorrect or inconvenient.  (While censors that engage in censorship or establish censorship regimes must do so through legal, military,


Hello, with a different ephemeral key share, as the terminating server will fail to decrypt and verify the ESNI value. <del> 7.2.2. </del> <ins> 7.3.2. </ins> This design depends upon DNS as a vehicle for semi-static public key distribution.  Server operators may partition their private keys


5.4. <del> frames implicitly create a stream and carry stream data.  The Type field in the frame takes the form 0b00001XXX (or the set of values from 0x08 to 0x0f) to maximize compatibility with QUIC.  However, unlike QUIC, there are only one bit used to determine the fields that are present in the frame: The FIN bit (0x01) indicates that the frame marks the end of the stream.  The final size of the stream is the sum of the length, in bytes, of all data previously sent on this stream and the length of this frame without the length of the Stream ID. </del> <ins> frames implicitly create a stream and carry stream data. The Type field in the frame is either 0x0a or 0x0b.  This uses the same frame types as a QUIC STREAM frame with the OFF bit clear and the LEN bit set.  The FIN bit (0x01) in the frame type indicates that the frame marks the end of the stream in one direction.  Stream data consists of any number of 0x0a frames followed by a terminal 0x0b frame. frames contain the following fields: The stream ID for the stream. Zero or more bytes of data for the stream.  Empty frames MUST NOT be used unless they open or close a stream; an endpoint MAY treat an empty frame that neither starts nor ends a stream as a session error. </ins> 5.5.


This property represents the maximum Message size that an application can send. <del> 7.1.10.4. </del> <ins> 7.1.11.4. </ins> recvMsgMaxLen


errors.  The "instance" value MUST be the endpoint to which the request was targeted.  The problem document MUST also include a "taskid" member which contains the associated PPM task ID, encoded <del> with base64 RFC4648 (this value is always known, see task- configuration). </del> <ins> with base64 using the standard alphabet RFC4648 (this value is always known, see task-configuration). </ins> In the remainder of this document, we use the tokens in the table above to refer to error types, rather than the full URNs.  For


A QUIC packet with a short header includes a Destination Connection ID immediately following the first byte.  The short header does not include the Connection ID Lengths, Source Connection ID, or Version <del> fields.  The length of the Destination Connection ID is not specified </del> <ins> fields.  The length of the Destination Connection ID is not encoded </ins> in packets with a short header and is not constrained by this specification.


6. An entity in the RATS architecture includes at least one of the roles <del> defined in this document.  As a result, the entity can participate as a constituent of the RATS architecture.  Additionally, an entity can aggregate more than one role into itself.  These collapsed roles combine the duties of multiple roles.  In these cases, interaction between these roles do not necessarily use the Internet Protocol. They can be using a loopback device or other IP-based communication between separate environments, but they do not have to.  Alternative channels to convey conceptual messages include function calls, sockets, GPIO interfaces, local busses, or hypervisor calls.  This type of conveyance is typically found in Composite Devices.  Most importantly, these conveyance methods are out-of-scope of RATS, but they are presumed to exist in order to convey conceptual messages appropriately between roles. </del> <ins> defined in this document.  An entity can aggregate more than one role into itself.  These collapsed roles combine the duties of multiple roles. In these cases, interaction between these roles do not necessarily use the Internet Protocol.  They can be using a loopback device or other IP-based communication between separate environments, but they do not have to.  Alternative channels to convey conceptual messages include function calls, sockets, GPIO interfaces, local busses, or hypervisor calls.  This type of conveyance is typically found in Composite Devices.  Most importantly, these conveyance methods are out-of-scope of RATS, but they are presumed to exist in order to convey conceptual messages appropriately between roles. </ins> For example, an entity that both connects to a wide-area network and to a system bus is taking on both the Attester and Verifier roles.


each key/nonce pair MUST NOT be used to encrypt more than one message. <del> Keys, nonces and secrets of ratchets are derived using </del> <ins> Keys, nonces, and the secrets in ratchets are derived using </ins> DeriveAppSecret.  The context in a given call consists of the index of the sender's leaf in the ratchet tree and the current position in the ratchet.  In particular, the index of the sender's leaf in the


4.5.6. The literal header field without name reference representation <del> encodes a header field name and header field value as string </del> <ins> encodes a header field name and a header field value as string </ins> literals. This representation begins with the '001' three-bit pattern.  The


.  A string is a well-formed JSONPath query if it conforms to the ABNF syntax in this document.  A well-formed JSONPath query is valid <del> if it also fulfills all semantic requirements posed by this document. </del> <ins> if it also fulfills all semantic requirements posed by this document, which are: </ins> <del> To be valid, integer numbers in the JSONPath query that are relevant to the JSONPath processing (e.g., index values and steps) MUST be within the range of exact values defined in I-JSON RFC7493, namely within the interval [-(2 </del> <ins> Integer numbers in the JSONPath query that are relevant to the JSONPath processing (e.g., index values and steps) MUST be within the range of exact values defined in I-JSON RFC7493, namely within the interval [-(2 </ins> <del> )+1, (2 </del> <ins> )+1, (2 </ins> <del> )-1]). </del> <ins> )-1]. </ins> <del> To be valid, strings on the right-hand side of the "=~" regex matching operator need to conform to I-D.draft-ietf-jsonpath-iregexp. </del> <ins> Strings on the right-hand side of the "=~" regex matching operator MUST conform to I-D.draft-ietf-jsonpath-iregexp. </ins> The well-formedness and the validity of JSONPath queries are independent of the JSON value the query is applied to; no further


The client instance request.  The client instance does not send any interaction modes to the server. <del> The AS determines that the request is been authorized, the AS grants access to the information in the form of response-token to the client instance.  Note that response-subject is not generally </del> <ins> The AS determines that the request has been authorized, the AS grants access to the resource in the form of response-token to the client instance.  Note that response-subject is not generally </ins> applicable in this use case, as there is no user involved. The client instance use-access-token to call the RS.


other aspects of EKT processing.  EKT ciphers are free to use this field in any way, but they SHOULD NOT use other EKT or SRTP fields as an input.  The values of the parameters L, and T MUST be defined by <del> each EKTCipher. </del> <ins> each EKTCipher.  The cipher MUST provide integrity protection. </ins> 2.5.


conveying the semantic requirements of DOH but may result in very poor performance for many uses cases. <ins> 7.3. Before using DOH response data for DNS resolution, the client MUST establish that the HTTP request URI is a trusted service for the DOH query.  For HTTP requests initiated by the DNS API client this trust is implicit in the selection of URI.  For HTTP server push (RFC7540 Section 8.2) extra care must be taken to ensure that the pushed URI is one that the client would have directed the same query to if the client had initiated the request.  This specification does not extend DNS resolution privileges to URIs that are not recognized by the client as trusted DNS API servers. </ins> 8. 8.1.


1. As detailed in IPHandling, exposing client private IP addresses by <del> default maximizes the probability of successfully creating direct peer-to-peer connection between two clients, but creates a significant surface for user fingerprinting.  IPHandling recognizes </del> <ins> default to web applications maximizes the probability of successfully creating direct peer-to-peer connections between clients, but creates a significant surface for user fingerprinting.  IPHandling recognizes </ins> this issue, but also admits that there is no current solution to this problem; implementations that choose to use Mode 3 to address the privacy concerns often suffer from failing or suboptimal connections


than or equal to the Base, the representation starts with the '0001' 4-bit pattern, followed by the post-base index (see post-base) of the matching header field, represented as an integer with a 4-bit prefix <del> (see Section 5.1 of RFC7541). </del> <ins> (see prefixed-integers). </ins> 4.5.4.


".local" name may happen through Unicast DNS as noted in RFC6762, Section 3. <del> An ICE agent that supports mDNS candidates MUST support the situation where the hostname resolution results in more than one IP address. In this case, the ICE agent MUST take exactly one of the resolved IP addresses and ignore the others.  The ICE agent SHOULD use the first IPv6 address resolved, if one exists, or the first IPv4 address, if not. </del> <ins> An ICE agent SHOULD ignore candidates where the hostname resolution returns more than one IP address. </ins> An ICE agent MAY add additional restrictions regarding the ICE candidates it will resolve using mDNS, as this mechanism allows


9. <ins> draft-ietf-core-dynlink-10 Binding methods now support both POST and PUT operations for server push. </ins> draft-ietf-core-dynlink-09 Corrections in Table 1, Table 2, Figure 2.


If the client instance can open a URL associated with an application on the end-user's device, the client instance indicates this by <del> sending the "app" field with boolean value "true".  The means by </del> <ins> including "app" in the array under the "start" key.  The means by </ins> which the client instance determines the application to open with this URL are out of scope of this specification.


packets being encrypted with per-version keys and the Handshake and later packets being encrypted with keys derived from the TLS key exchange.  Further, parameter negotiation is folded into the TLS <del> transcript and thus provides the same security guarantees as ordinary TLS negotiation.  Thus, an attacker can observe the client's transport parameters (as long as it knows the version-specific salt) </del> <ins> transcript and thus provides the same integrity guarantees as ordinary TLS negotiation.  An attacker can observe the client's transport parameters (as long as it knows the version-specific keys) </ins> but cannot observe the server's transport parameters and cannot influence parameter negotiation.


active path, implementations SHOULD use T = 3xRTT. If an implementation has no way to obtain information regarding the <del> RTT of the active path, a value of 1s SHOULD be used. </del> <ins> RTT of the active path, T SHOULD be set to 1s. </ins> Profiles for specific deployment environments - for example, constrained networks I-D.ietf-uta-tls13-iot-profile - MAY specify a


any interaction modes to the server, indicating that it does not expect to interact with the RO.  The client instance can also signal which RO it requires authorization from, if known, by using <del> the request-user. </del> <ins> the request-user.  It's also possible for the AS to determine which RO needs to be contacted by the nature of what access is being requested. </ins> The AS determines that interaction is needed, but the client instance cannot interact with the RO.  The AS response with the


aggregate shares into an aggregate result using the VDAF's "agg_shares_to_result" algorithm.  In particular, let "agg_shares" denote the ordered sequence of aggregator shares, ordered by <del> aggregator index, and let "agg_param" be the opaque aggregation parameter.  The final aggregate result is computed as follows: </del> <ins> aggregator index, let "report_count" denote the report count sent by the Leader, and let "agg_param" be the opaque aggregation parameter. The final aggregate result is computed as follows: </ins> 4.5.4.


4.5.5. <del> A literal header field with post-base name reference represents a header field where the name matches the header field name of a dynamic table entry with an absolute index greater than or equal to the Base. </del> <ins> A literal header field with post-base name reference representation encodes a header field where the header field name matches the header field name of a dynamic table entry with an absolute index greater than or equal to the Base. </ins> This representation starts with the '0000' four-bit pattern.  The fifth bit is the 'N' bit as described in literal-name-reference.


If the client's credentials indicate any subject name that is certified by any authority which the RD recognizes (which may be <del> the system's trust anchor store), all those subject names are </del> <ins> the system's trust anchor store), all such subject names are </ins> stored.  With CWT or JWT based credentials (as common with ACE), the Subject (sub) claim is stored as a single name, if it exists. With X.509 certificates, the Common Name (CN) and the complete


RFC5705 defines keying material exporters for TLS in terms of the TLS PRF.  This document replaces the PRF with HKDF, thus requiring a new <del> construction.  The exporter interface remains the same, however the value is computed as: </del> <ins> construction.  The exporter interface remains the same.  If context is provided, the value is computed as: If no context is provided, the value is computed as: Note that providing no context computes the same value as providing an empty context.  As of this document's publication, no allocated exporter label is used with both modes.  Future specifications MUST NOT provide an empty context and no context with the same label and SHOULD provide a context, possibly empty, in all exporter computations. </ins> 8.


In practice, many contact channels that can be used to reach many clients do not provide strong assurances of the types noted above. <del> In designing and deploying contact-based recovery schemes, ACME servers operators will need to find an appropriate balance between using contact channels that can reach many clients and using contact- based recovery schemes that achieve an appropriate level of risk using those contact channels. </del> <ins> In designing and deploying recovery schemes, ACME servers operators will need to find an appropriate balance between using contact channels that can reach many clients and using contact-based recovery schemes that achieve an appropriate level of risk using those contact channels. </ins> 9.4.


8.3.1. <del> The server does not expose "RateLimit-Remaining" values, but resets the limit counter every second. </del> <ins> The server does not expose "RateLimit-Remaining" values (for example, because the underlying counters are not available).  Instead, it resets the limit counter every second. </ins> It communicates to the client the limit of 10 quota-units per second always returning the couple "RateLimit-Limit" and "RateLimit-Reset".


Environment, then this sub-entity generates Evidence about its trustworthiness.  Therefore each sub-entity can be called an Attester.  Among these Attesters, there may be only some, which can <del> be called Lead Attesters, that have the communication functionality with the Verifier.  Other Attesters don't have this ability, but they are connected to the Lead Attesters via internal links or network </del> <ins> be called Lead Attesters, that have the ability to communicate with the Verifier.  Other Attesters don't have this ability, but they are connected to the Lead Attesters via internal links or network </ins> connections, and they are evaluated via the Lead Attester's help. For example, a carrier-grade router is a composite device consisting of a chassis and multiple slots.  The trustworthiness of the router depends on all its slots' trustworthiness.  Each slot has an Attesting Environment such as a TPM or TEE collecting the claims of <del> its boot process, then it generates Evidence from the claims to prove its trustworthiness.  Among these slots, only a main slot can communicate with the Verifier while other slots cannot.  But other slots can communicate with the main slot by the links between them inside the router.  So the main slot collects the Evidence of other slots, produces the final Evidence of the whole router and conveys the final Evidence to the Verifier.  Therefore the router is a Composite Attester, each slot is an Attester and the main slot is the Lead Attester. Another example is a multi-chassis router which is composed of multiple single carrier-grade routers.  The multi-chassis router provides higher throughput by interconnecting multiple routers and simpler management by being logically treated as one router.  Among these routers, there is only one main router that connects to the Verifier.  Other routers are only connected to the main router by the network cables, and therefore they are managed and verified via this main router.  So, in this case, the multi-chassis router is the Composite Attester, each router is an Attester and the main router is the Lead Attester. composite depicts the data that flows between the Composite Attester and Verifier for the remote attestation. </del> <ins> its boot process, after which it generates Evidence from the claims. Among these slots, only a main slot can communicate with the Verifier while other slots cannot.  But other slots can communicate with the main slot by the links between them inside the router.  So the main slot collects the Evidence of other slots, produces the final Evidence of the whole router and conveys the final Evidence to the Verifier.  Therefore the router is a Composite Attester, each slot is an Attester, and the main slot is the Lead Attester. Another example is a multi-chassis router composed of multiple single carrier-grade routers.  The multi-chassis router provides higher throughput by interconnecting multiple routers and simpler management by being logically treated as one router.  Among these routers, there is only one main router that connects to the Verifier.  Other routers are only connected to the main router by the network cables, and therefore they are managed and verified via this main router.  So, in this case, the multi-chassis router is the Composite Attester, each router is an Attester and the main router is the Lead Attester. composite depicts the conceptual data flow for a Composite Attester. </ins> In the Composite Attester, each Attester generates its own Evidence <del> by its Attesting Environments collecting the claims from its Target Environments.  The Lead Attester collects the Evidence of all other </del> <ins> by its Attesting Environment(s) collecting the claims from its Target Environment(s).  The Lead Attester collects the Evidence of all other </ins> Attesters and then generates the Evidence of the whole Composite Attester. <del> Inside the Lead Attester, there may be an optional Verifying Environment.  The Verifying Environment can verify the collected Evidence of other Attesters to evaluate their trustworthiness. Therefore, there are two situations when the Lead Attester generates the final Evidence. One situation is that the Lead Attester has no Verifying Environment. In this situation, the Lead Attester just collects the Evidence of other Attesters but doesn't verify them.  It may just string all these Evidence into a whole one, or it may reorganize these Evidence with a new structure and sign this final Evidence.  Then it conveys the final Evidence to the Verifier and the Verifier evaluates the Composite Attester's, including the Lead Attester's and other Attesters', trustworthiness. The other situation is that the Lead Attester has a Verifying Environment.  After collecting the Evidence of other Attesters, the Lead Attester verifies these Evidence by using the Endorsements and Appraisal Policies, which are got from the Verifier or some reliable parties, for evaluating these Attesters' trustworthiness.  Then the Lead Attester makes the verification results as claims which are the input to the final Evidence of the whole Composite Attester.  Then the Lead Attester conveys the final Attestation Evidence to the Verifier on behalf of the Composite Attester.  Before receiving the Endorsements and Appraisal Policies for other Attesters, to increase the security, the Lead Attester may first generate Evidence about its trustworthiness and convey this Evidence to the Verifier for evaluating. </del> <ins> The Lead Attester's Claims Collector may or may not include its own Verifier.  One situation is that the Claims Collector has no internal Verifier.  In this situation, the Claims Collecctor simply combines the various Evidences into the final Evidence that is sent off to the remote Verifier, which evaluates the Composite Attester's, including the Lead Attester's and other Attesters', trustworthiness. The other situation is that the Lead Attester's Claims Collector has an internal Verifier.  After collecting the Evidence of other Attesters, the Claims Collector verifies them using Endorsements and Appraisal Policies (obtained the same way as any other Verifier), for evaluating these Attesters' trustworthiness.  Then the Claims Collector combines the Attestation Results into the final Evidence of the whole Composite Attester which is sent off to the remote Verifier, which might treat the claims obtained from the local Attestation Results as if they were Evidence. </ins> 5.


If the media section proto value indicates use of RTP: <del> [TODO: header extensions] </del> If the m= section is being recycled (see sec.subsequent- offers), dissociate the currently associated RtpTransceiver by setting its mid attribute to null.


12. <ins> changes from -27 to -28 Security policies / link confidentiality: Point out the RD's obligations that follow from such a policy. Simple registration: clarify term "regular registration" by introducing it along with the reference to Wording fix in first-come-first-remembered Wording fixes in RD definition </ins> changes from -26 to -27 In general, this addresses the points that were pointed out in


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


MUST be the exact string provided in the Location header field in response to the new-registration request that created the account. <del> The JWK representation of the original key (i.e., the client's current account key) </del> The JWK representation of the new key The client then encapsulates the key-change object in a JWS, signed


A syntactically valid segment MUST NOT produce errors when executing the query.  This means that some operations that might be considered <del> erroneous, such as indexing beyond the end of an array, simply result in fewer nodes being selected. </del> <ins> erroneous, such as using an index lying outside the range of an array, simply result in fewer nodes being selected. </ins> Consider this example.  With the argument "{"a":[{"b":0},{"b":1},{"c":2}]}", the query "$.a[*].b" selects the


leveraging the security and congestion-control properties of QUIC. However, QUIC DATAGRAM frames do not provide a means to demultiplex application contexts.  This document describes how to use QUIC <del> DATAGRAM frames when the application protocol running over QUIC is HTTP/3 H3.  It associates datagrams with client-initiated bidirectional streams.  Additionally, this document defines the Capsule Protocol that can convey datagrams over prior versions of HTTP. </del> <ins> DATAGRAM frames with HTTP/3 H3 by association with HTTP requests. Additionally, this document defines the Capsule Protocol that can convey datagrams over prior versions of HTTP. </ins> This document is structured as follows: