6.1. <ins> 6.1.1. </ins> This ciphersuite uses the following primitives: Hash function: SHA-256


QUIC-LB requires common configuration to synchronize understanding of encodings and guarantee explicit consent of the server. <del> The load balancer and server MUST agree on a routing algorithm, server ID allocation method, and the relevant parameters for that algorithm. </del> <ins> The load balancer and server MUST agree on a routing algorithm and the relevant parameters for that algorithm. </ins> All algorithm configurations can have a server ID length, nonce length, and key.  However, for Plaintext CID, there is no key. <del> If server IDs are statically allocated, the load balancer MUST receive the full table of mappings, and each server must receive its assigned SID(s), from the configuration agent. </del> <ins> The load balancer MUST receive the full table of mappings, and each server must receive its assigned SID(s), from the configuration agent. </ins> Note that server IDs are opaque bytes, not integers, so there is no notion of network order or host order.


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


The payload of this packet contains CRYPTO frames and could contain PING, PADDING, or ACK frames.  Handshake packets MAY contain <del> CONNECTION_CLOSE frames.  Endpoints MUST treat receipt of Handshake packets with other frames as a connection error. </del> <ins> CONNECTION_CLOSE frames of type 0x1c.  Endpoints MUST treat receipt of Handshake packets with other frames as a connection error. </ins> Like Initial packets (see discard-initial), data in CRYPTO frames for Handshake packets is discarded - and no longer retransmitted - when


The default value is unlimited.  See header-formatting for usage. <del> Setting identifiers of the format "0x1f * N + 0x21" for integer values of N are reserved to exercise the requirement that unknown identifiers be ignored.  Such settings have no defined meaning. Endpoints SHOULD include at least one such setting in their SETTINGS frame.  Endpoints MUST NOT consider such settings to have any meaning upon receipt. </del> <ins> Setting identifiers of the format "0x1f * N + 0x21" for non-negative integer values of N are reserved to exercise the requirement that unknown identifiers be ignored.  Such settings have no defined meaning.  Endpoints SHOULD include at least one such setting in their SETTINGS frame.  Endpoints MUST NOT consider such settings to have any meaning upon receipt. </ins> Because the setting has no defined meaning, the value of the setting can be any value the implementation selects.


As a system bus-connected entity, a Verifier consumes Evidence from other devices connected to the system bus that implement Attester roles.  As a wide-area network connected entity, it may implement an <del> Attester role.  The entity, as a system bus Verifier, may choose to fully isolate its role as a wide-area network Attester. </del> <ins> Attester role. </ins> In essence, an entity that combines more than one role creates and consumes the corresponding conceptual messages as defined in this


1. Bootstrapping Remote Secure Key Infrastructures BRSKI specifies <del> automated bootstrapping of an Autonomic Control Plane.  BRSKI Section 2.7 describes how a pledge "MAY contact a well-known URI of a cloud registrar if a local registrar cannot be discovered or if the pledge's target use cases do not include a local registrar". </del> <ins> automated network onboarding of devices, referred to as pledges, within an Autonomic Control Plane or other managed network infrastructure.  BRSKI Section 2.7 describes how a pledge "MAY contact a well-known URI of a cloud registrar if a local registrar cannot be discovered or if the pledge's target use cases do not include a local registrar". </ins> This document further specifies use of a BRSKI cloud registrar and clarifies operations that are not sufficiently specified in BRSKI.


with an array of supported "alg" values.  See errors for more details on the structure of error responses. <ins> If the server supports the signature algorithm "alg" but either does not support or chooses to reject the public key "jwk", then the server MUST return an error with status code 400 (Bad Request) and type "urn:ietf:params:acme:error:badPublicKey".  The problem document detail SHOULD describe the reason for rejecting the public key; some example reasons are: "alg" is "RS256" but the modulus "n" is too small (e.g., 512-bit) "alg" is "ES256" but "jwk" does not contain a valid P-256 public key "alg" is "EdDSA" and "crv" is "Ed448", but the server only supports "EdDSA" with "Ed25519" the corresponding private key is known to have been compromised </ins> Because client requests in ACME carry JWS objects in the Flattened JSON Serialization, they must have the Content-Type header field set to "application/jose+json".  If a request does not meet this


4.2.1. The ADDRESS_ASSIGN capsule (see iana-types for the value of the <del> capsule type) allows an endpoint to inform its peer that it has assigned an IP address or prefix to it.  The ADDRESS_ASSIGN capsule allows assigning a prefix which can contain multiple addresses.  Any </del> <ins> capsule type) allows an endpoint to inform its peer of the list of IP addresses or prefixes it has assigned to it.  Every capsule contains the full list of IP prefixes currently assigned to the receiver.  Any </ins> of these addresses can be used as the source address on IP packets originated by the receiver of this capsule. <del> If an endpoint receives multiple ADDRESS_ASSIGN capsules, all of the assigned addresses or prefixes can be used.  For example, multiple ADDRESS_ASSIGN capsules are necessary to assign both IPv4 and IPv6 addresses. </del> <ins> The ADDRESS_ASSIGN capsule contains a sequence of zero or more Assigned Addresses. Note that an ADDRESS_ASSIGN capsule can also indicate that a previously assigned address is no longer assigned.  An ADDRESS_ASSIGN capsule can also be empty. </ins> In some deployments of CONNECT-IP, an endpoint needs to be assigned an address by its peer before it knows what source address to set on its own packets.  For example, in the Remote Access case (example- remote) the client cannot send IP packets until it knows what address <del> to use.  In these deployments, endpoints need to send ADDRESS_ASSIGN capsules to allow their peers to send traffic. </del> <ins> to use.  In these deployments, the endpoint that is expecting an address assignment MUST send an ADDRESS_REQUEST capsule.  This isn't required if the endpoint does not need any address assignment, for example when it is configured out-of-band with static addresses. While ADDRESS_ASSIGN capsules are commonly sent in response to ADDRESS_REQUEST capsules, endpoints MAY send ADDRESS_ASSIGN capsules unprompted. </ins> 4.2.2. The ADDRESS_REQUEST capsule (see iana-types for the value of the <del> capsule type) allows an endpoint to request assignment of an IP address from its peer.  This capsule is not required for simple client/proxy communication where the client only expects to receive one address from the proxy.  The capsule allows the endpoint to </del> <ins> capsule type) allows an endpoint to request assignment of IP addresses from its peer.  The capsule allows the endpoint to </ins> optionally indicate a preference for which address it would get assigned. <ins> The ADDRESS_REQUEST capsule contains a sequence of Requested Addresses. If the IP Address is all-zero (0.0.0.0 or ::), this indicates that the sender is requesting an address of that address family but does not have a preference for a specific address.  In that scenario, the prefix length still indicates the sender's preference for the prefix length it is requesting. </ins> Upon receiving the ADDRESS_REQUEST capsule, an endpoint SHOULD assign an IP address to its peer, and then respond with an ADDRESS_ASSIGN <del> capsule to inform the peer of the assignment. </del> <ins> capsule to inform the peer of the assignment.  Note that the receiver of the ADDRESS_REQUEST capsule is not required to assign the requested address, and that it can also assign some requested addresses but not others. </ins> 4.2.3.


Sent by servers when a retrieved object does not have the correct hash provided by the client via the "client_certificate_url" <del> extension RFC6066.  This alert is always fatal. </del> <ins> extension RFC6066. </ins> Sent by servers when a PSK cipher suite is selected but no acceptable PSK identity is provided by the client.  Sending this


processing of vulnerability description data is expected to trigger the vulnerability assessment. <del> See "Data Attribute Tables and Definitions" for information-specific details. </del> <ins> See data-attribute-table for information-specific details. </ins> 5.


The following rules extend the ABNF syntax defined in RFC3339 in order to allow the inclusion of an optional suffix. <del> The extended date/time format is described by the rule "date-time- ext". </del> <ins> The Internet Extended Date/Time Format (IXDTF) is described by the rule "date-time-ext". </ins> "date-time" and "time-numoffset" are imported from RFC3339, "ALPHA" and "DIGIT" from RFC5234.


Including transport parameters in the TLS handshake provides integrity protection for these values. <del> The "extension_data" field of the quic_transport_parameters extension </del> <ins> The extension_data field of the quic_transport_parameters extension </ins> contains a value that is defined by the version of QUIC that is in use.


Media Distributors use DTLS-SRTP RFC5764 directly with a peer Media Distributor to establish HBH keys for transmitting RTP and RTCP <del> packets that peer Media Distributor.  The Key Distributor does not </del> <ins> packets to that peer Media Distributor.  The Key Distributor does not </ins> facilitate establishing HBH keys for use between Media Distributors. 4.5.1. The procedures defined in DTLS Tunnel for PERC I-D.jones-perc-dtls- <del> tunnel establish one or more DTLS tunnels between the Media </del> <ins> tunnel establish one or more TLS tunnels between the Media </ins> Distributor and Key Distributor, making it is possible for the Media Distributor to facilitate the establishment of a secure DTLS association between each endpoint and the Key Distributor as shown


an analysis of these limits under the assumption that the underlying primitive (AES or ChaCha20) has no weaknesses.  Implementations SHOULD do a key update as described in key-update prior to reaching <del> these limits. </del> <ins> these limits.  Note that it is not possible to perform a KeyUpdate for early data and therefore implementations SHOULD not exceed the limits when sending early data. </ins> For AES-GCM, up to 2^24.5 full-size records (about 24 million) may be encrypted on a given connection while keeping a safety margin of


that datagram silently or buffer it temporarily while awaiting the creation of the corresponding stream. <ins> HTTP/3 datagrams MUST only be sent with an association to a stream that supports semantics for HTTP Datagrams.  For example, existing HTTP methods GET and POST do not define semantics for associated HTTP Datagrams; therefore, HTTP/3 datagrams cannot be sent associated with GET or POST request streams.  If an endpoint receives an HTTP/3 datagram associated with a method that has no known semantics for HTTP Datagrams, it MUST abort the corresponding stream with H3_GENERAL_PROTOCOL_ERROR.  Future extensions MAY remove these requirements if they define semantics for such HTTP Datagrams and negotiate mutual support. </ins> 4. This specification introduces the Capsule Protocol.  The Capsule Protocol is a sequence of type-length-value tuples that new HTTP <del> Methods or new HTTP Upgrade Tokens can choose to use.  It allows endpoints to reliably communicate request-related information end-to- end on HTTP request streams, even in the presence of HTTP intermediaries.  The Capsule Protocol can be used to exchange HTTP Datagrams when HTTP is running over a transport that does not support the QUIC DATAGRAM frame. </del> <ins> Upgrade Tokens can choose to use.  It allows endpoints to reliably communicate request-related information end-to-end on HTTP request streams, even in the presence of HTTP intermediaries.  The Capsule Protocol can be used to exchange HTTP Datagrams when HTTP is running over a transport that does not support the QUIC DATAGRAM frame. </ins> This specification defines the "data stream" of an HTTP request as the bidirectional stream of bytes that follow the headers in both


IANA will create a registry of SenML unit symbols.  The primary purpose of this registry is to make sure that symbols uniquely map to give type of measurement.  Definitions for many of these units can be <del> found in location such as NIST811 and BIPM. </del> <ins> found in location such as NIST811 and BIPM.  Units marked with an asterisk are NOT RECOMMENDED to be produced by new implementations, but are in active use and SHOULD be implemented by consumers that can use the related base units. </ins> Note 1: A value of 0.0 indicates the switch is off while 1.0 <del> indicates on and 0.5 would be half on. </del> <ins> indicates on and 0.5 would be half on.  The preferred name of this unit is "/".  For historical reasons, the name "%" is also provided for the same unit - but note that while that name strongly suggests a percentage (0..100) -- it is however NOT a percentage, but the absolute ratio! </ins> Note 2: Assumed to be in WGS84 unless another reference frame is known for the sensor.


<del> CAPPORT Architecture </del> <ins> Captive Portal Architecture </ins> draft-ietf-capport-architecture-08 Abstract <del> This document describes a CAPPORT architecture.  DHCP or Router Advertisements, an optional signaling protocol, and an HTTP API are used to provide the solution.  The role of Provisioning Domains (PvDs) is described. </del> <ins> This document describes a captive portal architecture.  DHCP or Router Advertisements, an optional signaling protocol, and an HTTP API are used to provide the solution.  The role of Provisioning Domains (PvDs) is described. </ins> 1.


handshake but reject 0-RTT, and SHOULD NOT take any other action that assumes that this ClientHello is fresh. <del> The parameters for the 0-RTT data (symmetric cipher suite, ALPN, etc.) are the same as those which were negotiated in the connection which established the PSK.  The PSK used to encrypt the early data MUST be the first PSK listed in the client's "pre_shared_key" extension. </del> <ins> The parameters for the 0-RTT data (symmetric cipher suite, ALPN protocol, etc.) are the same as those which were negotiated in the connection which established the PSK.  The PSK used to encrypt the early data MUST be the first PSK listed in the client's "pre_shared_key" extension. </ins> 0-RTT messages sent in the first flight have the same content types as their corresponding messages sent in other flights (handshake,


push messages to the user agent.  Flow control SHOULD be used to limit the state commitment for delivery of large messages. <ins> 5.1. A push service can improve the reliability of push message delivery considerably by storing push messages for a period.  User agents are often only intermittendly connected, and so benefit from having short term message storage at the push service. Delaying delivery might also be used to batch communication with the user agent, thereby conserving radio resources. Some push messages are not useful once a certain period of time elapses.  Delivery of messages after they have ceased to be relevant is wasteful.  For example, if the push message contains a call notification, receiving a message after the caller has abandoned the call is of no value; the application at the user agent is forced to suppress the message so that it does not generate a useless alert. An application server can use the TTL header field to limit the time that a push message is retained by a push service.  The TTL header field contains a value in seconds that describes how long a push message is retained by the push service. Once the TTL period elapses, the push service MUST remove the push message and cease any attempt to deliver it to the user agent.  A push service might retain values for a short duration after the TTL period to account for time accounting errors in processing.  For instance, distributing a push message within a server cluster might accrue errors due to clock variation, or processing and transit delays. A push service is not obligated to account for time spent by the application server in sending a push message to the push service, or delays incurred while sending a push message to the user agent.  An application server needs to account for transit delays in selecting a TTL header field value. Absence of the TTL header field is interpreted as equivalent to a zero value.  Push messages with a zero TTL indicate that storage is not needed and that the message can be dropped if the user agent isn't immediately available to receive the message.  Push messages with a zero TTL can be delivered very efficiently. A push service MAY choose to retain a push message for a shorter duration than that requested.  It indicates this by including a TTL header field in the response that includes the actual TTL.  This TTL value MUST be less than or equal to the value provided by the application server. </ins> 6. A user agent requests the delivery of new push messages by making a


The PSK associated with the ticket depends on the client Finished and cannot be pre-computed in handshakes with client authentication.  The NewSessionTicket message MUST NOT include an "early_data" extension. <del> A mechanism by which clients can specify the desired number of tickets needed for future connections is defined in I-D.ietf-tls- ticketrequests. </del> <ins> Servers should take into account that fewer newSessionTickets will likely be needed in EAP-TLS than in the usual HTTPS connection scenario.  In most cases a single newSessionTicket will be sufficient.  A mechanism by which clients can specify the desired number of tickets needed for future connections is defined in I- D.ietf-tls-ticketrequests. </ins> figbase2 shows an example message flow for a succesfull EAP-TLS full handshake with mutual authentication and ticket establishment of a


Servers MUST NOT send a REGISTER_DATAGRAM_CONTEXT capsule on a stream before they have received at least one REGISTER_DATAGRAM_CONTEXT <del> capsule from the client on that stream.  This ensures that clients control whether datagrams are allowed for a given request.  If a </del> <ins> capsule or one REGISTER_DATAGRAM_NO_CONTEXT capsule from the client on that stream.  This ensures that clients control whether datagrams are allowed for a given request.  If a client receives a REGISTER_DATAGRAM_CONTEXT capsule on a stream where the client has not yet sent a REGISTER_DATAGRAM_CONTEXT capsule, the client MUST abruptly terminate the corresponding stream with a stream error of type H3_GENERAL_PROTOCOL_ERROR. Servers MUST NOT send a REGISTER_DATAGRAM_CONTEXT capsule on a stream where it has received a REGISTER_DATAGRAM_NO_CONTEXT capsule.  If a </ins> client receives a REGISTER_DATAGRAM_CONTEXT capsule on a stream where <del> the client has not yet sent a REGISTER_DATAGRAM_CONTEXT capsule, the </del> <ins> the client has sent a REGISTER_DATAGRAM_NO_CONTEXT capsule, the </ins> client MUST abruptly terminate the corresponding stream with a stream error of type H3_GENERAL_PROTOCOL_ERROR. 4.2. <ins> The REGISTER_DATAGRAM_NO_CONTEXT capsule (type=0x03) allows a client to inform the server that datagram contexts will not be used with this stream.  It also informs the server of the encoding and semantics of datagrams associated with this stream.  Its Capsule Data field consists of: A string of comma-separated key-value pairs to enable extensibility, see the definition of the same field in register- capsule for details. Note that this registration is unilateral and bidirectional: the client unilaterally defines the semantics it will apply to the datagrams it sends and receives with this stream. Endpoints MUST NOT send DATAGRAM frames without a Context ID until they have either sent or received a REGISTER_DATAGRAM_NO_CONTEXT Capsule.  However, due to reordering, an endpoint that receives a DATAGRAM frame before receiving either a REGISTER_DATAGRAM_CONTEXT capsule or a REGISTER_DATAGRAM_NO_CONTEXT capsule MUST NOT treat it as an error, it SHALL instead drop the DATAGRAM frame silently, or buffer it temporarily while awaiting a REGISTER_DATAGRAM_NO_CONTEXT capsule or the corresponding REGISTER_DATAGRAM_CONTEXT capsule. Servers MUST NOT send the REGISTER_DATAGRAM_NO_CONTEXT capsule.  If a client receives a REGISTER_DATAGRAM_NO_CONTEXT capsule, the client MUST abruptly terminate the corresponding stream with a stream error of type H3_GENERAL_PROTOCOL_ERROR. Clients MUST NOT send more than one REGISTER_DATAGRAM_NO_CONTEXT capsule on a stream.  If a server receives a second REGISTER_DATAGRAM_NO_CONTEXT capsule on the same stream, the server MUST abruptly terminate the corresponding stream with a stream error of type H3_GENERAL_PROTOCOL_ERROR. Clients MUST NOT send a REGISTER_DATAGRAM_NO_CONTEXT capsule on a stream before they have sent at least one HEADERS frame on that stream.  This removes the need to buffer REGISTER_DATAGRAM_CONTEXT capsules when the server needs information from headers to determine how to react to the capsule.  If a server receives a REGISTER_DATAGRAM_NO_CONTEXT capsule on a stream that hasn't yet received a HEADERS frame, the server MUST abruptly terminate the corresponding stream with a stream error of type H3_GENERAL_PROTOCOL_ERROR. Clients MUST NOT send both REGISTER_DATAGRAM_CONTEXT capsules and REGISTER_DATAGRAM_NO_CONTEXT capsules on the same stream.  If a server receives both a REGISTER_DATAGRAM_CONTEXT capsule and a REGISTER_DATAGRAM_NO_CONTEXT capsule on the same stream, the server MUST abruptly terminate the corresponding stream with a stream error of type H3_GENERAL_PROTOCOL_ERROR. 4.3. </ins> The CLOSE_DATAGRAM_CONTEXT capsule (type=0x01) allows an endpoint to inform its peer that it will no longer send or parse received datagrams associated with a given context ID.  Its Capsule Data field


at the CoAP layer then it may be inclined to use the endpoint name for looking up what information to provision to the malicious device. <del> Endpoint authentication needs to be checked independently of whether there are configured requirements on the credentials for a given endpoint name (secure-ep) or whether arbitrary names are accepted (arbitrary-ep). </del> <ins> Endpoint authorization needs to be checked on registration and registration resource operations independently of whether there are configured requirements on the credentials for a given endpoint name (secure-ep) or whether arbitrary names are accepted (arbitrary-ep). </ins> Simple registration could be used to circumvent address-based access control: An attacker would send a simple registration request with


A function argument is a "filter-path" or a "comparable". <del> According to filter-selector, a "function-expression" is valid as a </del> <ins> According to filter-selector, a "function-expr" is valid as a </ins> "filter-path" or a "comparable". Any function expressions in a query must be well-formed (by


these are used to define "!=", "<=", ">", and ">=". When either side of a comparison results in an empty nodelist or <del> "Nothing": </del> <ins> "Nothing" (see typesys): </ins> a comparison using the operator "==" yields true if and only the other side also results in an empty nodelist or "Nothing".


the following additional information MUST be provisioned to both parties: <ins> The TLS version number for use with this PSK </ins> The cipher suite for use with this PSK The Application-Layer Protocol Negotiation (ALPN) protocol, if any


11.3. The following registrations are done following the procedure <del> specified in RFC6838 and RFC7303. </del> <ins> specified in RFC6838 and RFC7303.  Clipboard formats are defined for the JSON and XML form of lists but do not make sense for streams or other formats. </ins> Note to RFC Editor - please remove this paragraph.  Note that a request for media type review for senml+json was sent to the media-


increased cost (depending on whether the application chooses to use TURN). <del> The exact impact of this technique is being researched experimentally and will be provided before publication of this document. </del> <ins> One potential mitigation, as discussed in {#privacy}, is to not conceal candidates created from RFC4941 IPv6 addresses.  This permits connectivity even in large internal networks or where mDNS is disabled. The exact impact of the mDNS technique is being researched experimentally and will be provided before publication of this document. </ins> 4.2.


The ACK_MP frame, as specified in ack-mp-frame, is used to acknowledge 1-RTT packets.  Compared to the QUIC version 1 ACK frame, <del> the ACK_MP frames additionally contains a Packet Number Space Identifier (PN Space ID).  The PN Space ID used to distinguish packet number spaces for different paths and is simply derived from the sequence number of Destination Connection ID.  Therefore, the packet number space for 1-RTT packets can be identified based on the Destination Connection ID in each packet. </del> <ins> the ACK_MP frame additionally contains a Path ID.  The Path ID is used to distinguish packet number spaces for different paths and is simply derived from the sequence number of Destination Connection ID. Therefore, the Path ID for 1-RTT packets can be identified based on the Destination Connection ID in each packet. </ins> Acknowledgements of Initial and Handshake packets MUST be carried using ACK frames, as specified in QUIC-TRANSPORT.  The ACK frames, as


MTUs can vary.  TODO: Describe how the path MTU can be computed, specifically propagation across HTTP proxies. <del> 4.5. </del> <ins> 4.4. </ins> In WebTransport over HTTP/3, the client MAY send its SETTINGS frame, as well as multiple WebTransport CONNECT requests, WebTransport data


The Stream Cipher CID algorithm provides cryptographic protection at the cost of additional per-packet processing at the load balancer to <del> decrypt every incoming connection ID.  The CID format is depicted below. </del> <ins> decrypt every incoming connection ID. </ins> 5.2.1.


is the only one that can choose the new account key that receives the capabilities held by the account being recovered. <del> MAC-based recovery can be performed if the attacker knows the account key and registration URI for the account being recovered.  Both of these are difficult to obtain for a network attacker, because ACME uses HTTPS, though if the recovery key and registration URI are sufficiently predictable, the attacker might be able to guess them. An ACME MitM can see the registration URI, but still has to guess the recovery key, since neither the ECDH in the provisioning phase nor HMAC in the recovery phase will reveal it to him. ACME clients can thus mitigate problems with MAC-based recovery by using long recovery keys.  ACME servers should enforce a minimum recovery key length, and impose rate limits on recovery to limit an attacker's ability to test different guesses about the recovery key. Contact-based recovery uses both the ACME channel and the contact channel.  The provisioning process is only visible to an ACME MitM, and even then, the MitM can only observe the contact information provided.  If the ACME attacker does not also have access to the contact channel, there is no risk. The security of the contact-based recovery process is entirely dependent on the security of the contact channel.  The details of this will depend on the specific out-of-band technique used by the server.  For example: </del> <ins> Account recovery uses both the ACME channel and the contact channel. The provisioning process is only visible to an ACME MitM, and even then, the MitM can only observe the contact information provided.  If the ACME attacker does not also have access to the contact channel, there is no risk. The security of the recovery process is entirely dependent on the security of the contact channel.  The details of this will depend on the specific out-of-band technique used by the server.  For example: </ins> If the server requires a user to click a link in a message sent to a contact address, then the contact channel will need to ensure


4.5.2. <del> An indexed header field representation identifies an entry in either the static table or the dynamic table and causes that header field to be added to the decoded header list. If the entry is in the static table, or in the dynamic table with an absolute index less than the Base, this representation starts with the '1' 1-bit pattern, followed by the 'T' bit indicating whether the reference is into the static or dynamic table.  The 6-bit prefix integer (see prefixed-integers) that follows is used to locate the table entry for the header field.  When T=1, the number represents the static table index; when T=0, the number is the relative index of the entry in the dynamic table. </del> <ins> An indexed header field representation identifies an entry in the static table, or an entry in the dynamic table with an absolute index less than the Base. This representation starts with the '1' 1-bit pattern, followed by the 'T' bit indicating whether the reference is into the static or dynamic table.  The 6-bit prefix integer (see prefixed-integers) that follows is used to locate the table entry for the header field.  When T=1, the number represents the static table index; when T=0, the number is the relative index of the entry in the dynamic table. </ins> 4.5.3. <del> If the entry is in the dynamic table with an absolute index greater 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 (see prefixed-integers). </del> <ins> An indexed header field with post-base index representation identifies an entry in the dynamic table with an absolute index greater than or equal to the Base. </ins> <del> 4.5.4. </del> <ins> This representation starts with the '0001' 4-bit pattern.  This is followed by the post-base index (see post-base) of the matching header field, represented as an integer with a 4-bit prefix (see prefixed-integers). </ins> <del> A literal header field with name reference represents a header field where the header field name matches the header field name of an entry stored in the static table or the dynamic table. If the entry is in the static table, or in the dynamic table with an absolute index less than the Base, this representation starts with the '01' two-bit pattern. </del> <ins> 4.5.4. </ins> <del> The following 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 security-considerations for more details). </del> <ins> A literal header field with name reference representation encodes a header field where the header field name matches the header field name of an entry in the static table, or the header field name of an entry in the dynamic table with an absolute index less than the Base. This representation starts with the '01' two-bit pattern.  The following 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 security-considerations for more details). </ins> The fourth ('T') bit indicates whether the reference is to the static or dynamic table.  The 4-bit prefix integer (see prefixed-integers)


A rollback may be performed if the PeerConnection is in any state except for "stable".  This means that both offers and provisional answers can be rolled back.  Rollback can only be used to cancel <del> proposed changes; there is no support for rolling back from a stable state to a previous stable state.  If a rollback is attempted in the "stable" state, processing MUST stop and an error MUST be returned. Note that this implies that once the answerer has performed setLocalDescription with its answer, this cannot be rolled back. </del> <ins> proposed changes; there is no support for rolling back from a "stable" state to a previous "stable" state.  If a rollback is attempted in the "stable" state, processing MUST stop and an error MUST be returned.  Note that this implies that once the answerer has performed setLocalDescription with its answer, this cannot be rolled back. </ins> The effect of rollback MUST be the same regardless of whether setLocalDescription or setRemoteDescription is called.


using the KDF provided by TLS.  In TLS 1.3, the HKDF-Expand-Label function described in Section 7.1 of TLS13 is used, using the hash function from the negotiated cipher suite.  Other versions of TLS <del> MUST provide a similar function in order to be used QUIC. </del> <ins> MUST provide a similar function in order to be used with QUIC. </ins> The current encryption level secret and the label "quic key" are input to the KDF to produce the AEAD key; the label "quic iv" is used


The User Equipment accesses the external network. <del> 4. </del> <ins> 5. </ins> This memo includes no request to IANA. <del> 5. </del> <ins> 6. </ins> <del> 5.1. </del> <ins> 6.1. </ins> When joining a network, some trust is placed in the network operator. This is usually considered to be a decision by a user on the basis of


Clients are configured to use IP proxying over HTTP via an URI Template TEMPLATE.  The URI template MAY contain two variables: <del> "target" and "ipproto" (scope).  The optionality of the variables </del> <ins> "target" and "ipproto"; see scope.  The optionality of the variables </ins> needs to be considered when defining the template so that either the variable is self-identifying or it is possible to exclude it in the syntax.


For cases where the device is not specifically configured with a way to find an RD, the network may want to provide a suitable default. <del> If the address configuration of the network is performed via SLAAC, this is provided by the RDAO option rdao. </del> <ins> The IPv6 Neighbor Discovery option RDAO rdao can do that. </ins> <del> If the address configuration of the network is performed via DHCP, this could be provided via a DHCP option (no such option is defined at the time of writing). </del> <ins> When DHCP is in use, this could be provided via a DHCP option (no such option is defined at the time of writing). </ins> Finally, if neither the device nor the network offers any specific configuration, the device may want to employ heuristics to find a


10. <del> The first example shows a deprecation header field without date information: The second example shows a deprecation header with date information </del> <ins> The first example shows a deprecation header with date information </ins> and a link to the successor version: <del> The third example shows a deprecation header field with links for the successor version and for the API's deprecation policy.  In addition, it shows the sunset date for the deprecated resource: </del> <ins> The second example shows a deprecation header field with links for the successor version and for the API's deprecation policy.  In addition, it shows the sunset date for the deprecated resource: </ins>


servers set up their HPKE context and decrypt ClientECH as follows: ClientHelloOuterAAD is computed from the second ClientHelloOuter as <del> described in authenticating-outer. </del> <ins> described in authenticating-outer.  The "info" parameter to SetupPSKR is computed as above. </ins> If the client offered ECH in the first ClientHello, then it MUST offer ECH in the second.  Likewise, if the client did not offer ECH


prevents passive observers from correlating sessions unless tickets are reused.  Note: because ticket lifetimes are restricted to a week, 32 bits is enough to represent any plausible age, even <del> in milliseconds.  External tickets SHOULD use an obfuscated_ticket_age of 0; servers MUST ignore this value for external tickets. </del> <ins> in milliseconds.  For identities established externally an obfuscated_ticket_age of 0 SHOULD be used, and servers MUST ignore the value. </ins> A list of the identities that the client is willing to negotiate with the server.  If sent alongside the "early_data" extension


on.  Connections in a Connection Group share all Protocol Properties that are not applicable to a Message. <ins> In addition, incoming entangled Connections can be received by creating a Listener on an existing connection: </ins> Changing one of these Protocol Properties on one Connection in the group changes it for all others.  Per-Message Protocol Properties, however, are not entangled.  For example, changing "Timeout for


depending on their current availability and capabilities as well as application requirements, thus avoiding silo like solutions.  One of the crucial enablers of such design is the ability to discover <del> resources (machines -- endpoints) capable of providing required information at a given time or acting on instructions from the end users. </del> <ins> resources (and thus the endpoints they are hosted on) capable of providing required information at a given time or acting on instructions from the end users. </ins> Imagine a scenario where endpoints installed on vehicles enable tracking of the position of these vehicles for fleet management


over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. <ins> This document updates RFCs 4492, 5705, and 6066 and it obsoletes RFCs 5077, 5246, and 6961. </ins> 1. RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH The source for this


transport mode, it would only be possible to send packets originated by the ACP node itself. <del> IKEv2 authentication MUST use authentication method=1 ("RSA Digital Signature") for ACP certificates with RSA key and methods 9,10,11 for ACP certificates with ECC key according to the keys size/curve. A certificate payload with the ACP certificate MUST be included during IKEv2 authentication to support the ACP domain membership as described in certcheck, because it is using additional elements of the ACP certificates.  ACP peers are expected to have the same set of Trust Anchors (TA), so a certificate path MUST only be included in the signaled payload when the path contains intermediate certificates not in the TA set, such as sub-CAs (see acp-registrars). IPsec MUST support ESP with ENCR_AES_GCM_16 (RFC4106) due to its higher performance over ENCR_AES_CBC.  ACP MUST NOT use any NULL encryption option due to the confidentiality of ACP payload that may not be encrypted by itself (when carrying legacy management protocol traffics as well as hop-by-hop GRASP).  These requirements are based on RFC8221 but limited to the minimum necessary options because there is no need for interoperability with legacy equipment for ACP channels, instead any such backward compatibility would reduce the minimum security or performance required for ACP channels or increase the implementation complexity of the ACP. </del> <ins> ACP IPsec implementations MUST support ESP with ENCR_AES_GCM_16 (RFC4106) due to its higher performance over ENCR_AES_CBC.  ACP MUST NOT use any NULL encryption option due to the confidentiality of ACP payload that may not be encrypted by itself (when carrying legacy management protocol traffics as well as hop-by-hop GRASP).  When using AES encryption, 256-bit keys MUST be used.  AES-GCM is an AEAD cipher mode, so no ESP authentication algorithm requirement is needed. </ins> Once there are updates to RFC8221, these should accordingly be reflected in updates to these ACP requirements, for example if


A packet that does not increase the largest received packet number for its packet number space (packet-numbers) by exactly one.  A <del> packet can arrive out of order if it is delayed or if earlier packets are lost or delayed. </del> <ins> packet can arrive out of order if it is delayed, if earlier packets are lost or delayed, or if the sender intentionally skips a packet number. </ins> An entity that can participate in a QUIC connection by generating, receiving, and processing QUIC packets.  There are only two types


discovered.  Such elements may include classes of data, major roles, and role interactions.  This scenario also informs protocol and data model development in support of vulnerability assessment, as part of <del> overall posture assessment.  Vulnerability discovery, disclosure, and publication is out of scope. </del> <ins> overall posture assessment (see implementation-examples for examples of solutions that support this scenario). Vulnerability discovery, disclosure, publication, and prioritization is out of scope.  However, given the importance of prioritization in an enterprise's vulnerability assessment process, it is discussed in priority. Information on how the scenario aligns with SACM and other existing work is discussed in sacm-usage-scenarios through alignment-with- other-existing-works. </ins> 2.


21.13. Deployments should limit the ability of an attacker to target a new <del> connection to a particular server instance.  This means that client- controlled fields, such as the initial Destination Connection ID used on Initial and 0-RTT packets SHOULD NOT be used by themselves to make routing decisions.  Ideally, routing decisions are made independently of client-selected values; a Source Connection ID can be selected to route later packets to the same server. </del> <ins> connection to a particular server instance.  Ideally, routing decisions are made independently of client-selected values, including addresses.  Once an instance is selected, a connection ID can be selected so that later packets are routed to the same instance. </ins> 21.14.


3. <del> The Transport Services API is the basic common abstract application programming interface to the Transport Services Architecture defined in the TAPS Architecture I-D.ietf-taps-arch. </del> An application primarily interacts with this API through two Objects: Preconnections and Connections.  A Preconnection object (pre- establishment) represents a set of properties and constraints on the


The requested operation cannot be served over HTTP/3.  The peer should retry over HTTP/1.1. <del> Error codes of the format "0x1f * N + 0x21" for integer values of N are reserved to exercise the requirement that unknown error codes be treated as equivalent to H3_NO_ERROR (extensions).  Implementations SHOULD select an error code from this space with some probability when they would have sent H3_NO_ERROR. </del> <ins> Error codes of the format "0x1f * N + 0x21" for non-negative integer values of N are reserved to exercise the requirement that unknown error codes be treated as equivalent to H3_NO_ERROR (extensions). Implementations SHOULD select an error code from this space with some probability when they would have sent H3_NO_ERROR. </ins> 9.


In some cases, a CA running an ACME server might have a completely external, non-ACME process for authorizing a client to issue for an <del> identifier.  In these case, the CA should provision its ACME server </del> <ins> identifier.  In these cases, the CA should provision its ACME server </ins> with authorization objects corresponding to these authorizations and reflect them as already valid in any orders submitted by the client.


6. One of the content types supported by the TLS record layer is the <del> alert type.  Alert messages convey the severity of the message (warning or fatal) and a description of the alert.  Alert messages with a level of fatal result in the immediate termination of the connection.  Like other messages, alert messages are encrypted as </del> <ins> alert type.  Like other messages, alert messages are encrypted as </ins> specified by the current connection state. <ins> Alert messages convey the severity of the message (warning or fatal) and a description of the alert.  Warning-level messages are used to indicate orderly closure of the connection (see closure-alerts). Upon receiving a warning-level alert, the TLS implementation SHOULD indicate end-of-data to the application and, if appropriate for the alert type, send a closure alert in response. Fatal-level messages are used to indicate abortive closure of the connection (See error-alerts).  Upon receiving a fatal-level alert, the TLS implementation SHOULD indicate an error to the application and MUST NOT allow any further data to be sent or received on the connection.  Servers and clients MUST forget keys and secrets associated with a failed connection.  Stateful implementations of session tickets (as in many clients) SHOULD discard tickets associated with failed connections. All the alerts listed in error-alerts MUST be sent as fatal and MUST be treated as fatal regardless of the AlertLevel in the message. Unknown alert types MUST be treated as fatal. </ins> %%% Alert Messages 6.1.


appropriate).  Note that when considering a MediaStreamTrack that is producing rotated video, the unrotated resolution MUST be used.  This is required regardless of whether the receiver supports performing <del> receive-side rotation (e.g., through CVO), as it significantly simplifies the matching logic. </del> <ins> receive-side rotation (e.g., through CVO TS26.114), as it significantly simplifies the matching logic. </ins> For the purposes of resolution negotiation, only size limits are considered.  Any other values, e.g. picture or sample aspect ratio,


absolute index less than the Base, this representation starts with the '01' two-bit pattern. <del> Only the header field name stored in the static or dynamic table is used.  Any header field value MUST be ignored. </del> The following 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


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


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


In order to facilitate asynchronous addition of clients to a group, it is possible to pre-publish initialization keys that provide some <del> public information about a user.  UserInitKey messages provide </del> <ins> public information about a user.  ClientInitKey messages provide </ins> information about a client that any existing member can use to add this client to the group asynchronously. <del> A UserInitKey object specifies what ciphersuites a client supports, </del> <ins> A ClientInitKey object specifies what ciphersuites a client supports, </ins> as well as providing public keys that the client can use for key derivation and signing.  The client's identity key is intended to be stable throughout the lifetime of the group; there is no mechanism to change it.  Init keys are intended to be used a very limited number <del> of times, potentially once. (see init-key-reuse).  UserInitKeys also contain an identifier chosen by the client, which the client MUST assure uniquely identifies a given UserInitKey object among the set of UserInitKeys created by this client. </del> <ins> of times, potentially once. (see init-key-reuse).  ClientInitKeys also contain an identifier chosen by the client, which the client MUST assure uniquely identifies a given ClientInitKey object among the set of ClientInitKeys created by this client. </ins> The init_keys array MUST have the same length as the cipher_suites array, and each entry in the init_keys array MUST be a public key for


SSRF is somewhat more difficult to manage at runtime, and systems should generally refuse to fetch a URI if unsure. <ins> 12.33. Keys presented by value are allowed to be in only a single format, as discussed in key-format.  Presenting the same key in multiple formats is not allowed and is considered an error in the request.  If multiple keys formats were allowed, receivers of these key definitions need to be able to make sure that it's the same key represented in each field and not simply use one of the key formats without checking for equivalence.  If equivalence were not carefully checked, it is possible for an attacker to insert their own key into one of the formats without needing to have control over the other formats.  This could potentially lead to a situation where one key is used by part of the system (such as identifying the client instance) and a different key in a different format in the same message is used for other things, like calculating signature validity. To combat this, all keys presented by value have to be in exactly one supported format known by the receiver.  Normally, a client instance is going to be configured with its keys in a single format, and it will simply present that format as-is to the AS in its request.  A client instance capable of multiple formats can use discovery to determine which formats are supported, if desired.  An AS should be generous in supporting many different key formats to allow different types of client software and client instance deployments. </ins> 13. The privacy considerations in this section are modeled after the list


minimizing the set of supported attestation procedures helps minimize the amount of information leaked through a token. <del> Each attestation procedure also has an impact on the overall system privacy.  Requiring a conjunction of attestation types could decrease the overall anonymity set size.  For example, the number of Clients that have solved a CAPTCHA in the past day, that have a valid account, and that are running on a trusted device is less than the number of Clients that have solved a CAPTCHA in the past day. Attesters SHOULD not admit attestation types that result in small anonymity sets. </del> <ins> The role of the Attester in the issuance protocol and its impact on privacy depends on the type of attestation procedure, issuance protocol, deployment model.  For instance, requiring a conjunction of attestation procedures could decrease the overall anonymity set size. As an example, the number of Clients that have solved a CAPTCHA in the past day, that have a valid account, and that are running on a trusted device is less than the number of Clients that have solved a CAPTCHA in the past day.  Attesters SHOULD NOT be based on attestation procedures that result in small anonymity sets. Depending on the issuance protocol, the Issuer might learn information about the Origin.  To ensure Issuer-Client unlinkability, the Issuer should be unable to link that information to a specific Client.  For such issuance protocols where the Attester has access to Client-specific information, such as is the case for attestation procedures that involve Client-specific information (such as application-layer account information) or for deployment models where the Attester learns Client-specific information (such as Client IP addresses), Clients trust the Attester to not share any Client- specific information with the Issuer.  In deployments where the Attester does not learn Client-specific information, the Client does not need to explicitly trust the Attester in this regard. </ins> Issuers trust Attesters to correctly and reliably perform attestation.  However, certain types of attestation can vary in value


7.6. For application-layer protocols where the Connection initiator also <del> sends the first message, the InitiateWithIdempotentSend() action combines Connection initiation with a first Message sent, provided that message is idempotent. </del> <ins> sends the first message, the InitiateWithSend() action combines Connection initiation with a first Message sent. </ins> Without a message context (as in send-basic): With a message context (as in message-props): <del> The message passed to InitiateWithIdempotentSend() is, as suggested by the name, considered to be idempotent (see msg-idempotent) regardless of declared message properties or defaults.  If protocol stacks supporting 0-RTT establishment with idempotent data are available on the Preconnection, then 0-RTT establishment may be used with the given message when establishing candidate connections.  For a non-idemponent initial message, or when the selected stack(s) do not support 0-RTT establishment, InitiateWithIdempotentSend is identical to Initiate() followed by Send(). </del> <ins> Whenever possible, a messageContext should be provided to declare the message passed to InitiateWithSend as idempotent.  This allows the transport system to make use of 0-RTT establishment in case this is supported by the available protocol stacks.  When the selected stack(s) do not support transmitting data upon connection establishment, InitiateWithSend is identical to Initiate() followed by Send(). </ins> Neither partial sends nor send batching are supported by <del> InitiateWithIdempotentSend(). </del> <ins> InitiateWithSend(). </ins> <del> The Events that may be sent after InitiateWithIdempotentSend() are equivalent to those that would be sent by an invocation of Initate() followed immediately by an invocation of Send(), with the caveat that a send failure that occurs because the Connection could not be established will not result in a SendError separate from the InitiateError signaling the failure of Connection establishment. </del> <ins> The Events that may be sent after InitiateWithSend() are equivalent to those that would be sent by an invocation of Initate() followed immediately by an invocation of Send(), with the caveat that a send failure that occurs because the Connection could not be established will not result in a SendError separate from the InitiateError signaling the failure of Connection establishment. </ins> 7.7.


8. <del> TBD. </del> <ins> There are tradeoffs inherent in a sender sending an ACK_FREQUENCY frame to the receiver.  As such it is recommended that implementers experiment with different strategies and find those which best suit their applications and congestion controllers.  There are, however, noteworthy considerations when devising strategies for sending ACK_FREQUENCY frames. 8.1. A sender relies on receipt of acknowledgements to determine the amount of data in flight and to detect losses, e.g. when packets experience reordering, see QUIC-RECOVERY.  Consequently, how often a receiver sends acknowledgments determines how long it takes for losses to be detected at the sender. 8.2. Many congestion control algorithms have a startup mechanism during the beginning phases of a connection.  It is typical that in this period the congestion controller will quickly increase the amount of data in the network until it is signalled to stop.  While the mechanism used to achieve this increase varies, acknowledgments by the peer are generally critical during this phase to drive the congestion controller's machinery.  A sender can send ACK_FREQUENCY frames while its congestion controller is in this state, ensuring that the receiver will send acknowledgments at a rate which is optimal for the the sender's congestion controller. 8.3. Congestion controllers that are purely window-based and strictly adherent to packet conservation, such as the one defined in QUIC- RECOVERY, rely on receipt of acknowledgments to move the congestion window forward and send additional data into the network.  Such controllers will suffer degraded performance if acknowledgments are delayed excessively.  Similarly, if these controllers rely on the timing of peer acknowledgments (an "ACK clock"), delaying acknowledgments will cause undesirable bursts of data into the network. </ins> 9. TBD. <ins> 10. TBD. </ins>


8. <del> This document does not have additional security considerations beyond those defined in QUIC and DGRAM. </del> <ins> Since this feature requires sending an HTTP/3 Settings parameter, it "sticks out".  In other words, probing clients can learn whether a server supports this feature.  Implementations that support this feature SHOULD always send this Settings parameter to avoid leaking the fact that there are applications using HTTP/3 datagrams enabled on this endpoint. </ins> 9.


%%% Key Exchange Messages This field contains the version of TLS negotiated for this <del> session.  Servers MUST select the lower of the highest supported server version and the version offered by the client in the ClientHello.  In particular, servers MUST accept ClientHello messages with versions higher than those supported and negotiate the highest mutually supported version.  For this version of the specification, the version is 0x0304.  (See backward-compatibility for details about backward compatibility.) </del> <ins> session.  Servers MUST select a version from the list in ClientHello.supported_versions extension.  A client which receives a version that was not offered MUST abort the handshake.  For this version of the specification, the version is 0x0304.  (See backward-compatibility for details about backward compatibility.) </ins> This structure is generated by the server and MUST be generated independently of the ClientHello.random.


4. Servers MUST NOT include MD5 and SHA-1 in ServerKeyExchange messages. <del> If a client receives a MD5 or SHA-1 signature in a ServerKeyExchange message it MUST abort the connection with the illegal_parameter alert. </del> <ins> If no other signature algorithms are available (for example, if the client does not send a signature_algorithms extension), the server MUST abort the handshake with a handshake_failure alert or select a different cipher suite. </ins> 5.


shifting necessary in the event that there are an odd number of octets. <del> The expand_left() function outputs 16 octets, with its first argument in the most significant bits, its second argument in the least significant byte, its third argument in the second least significant byte, and zeros in all other positions.  Thus, </del> <ins> When configured with both a key, and a nonce length and server ID length that sum to any number other than 16, the server MUST follow the algorith below to encrypt the connection ID. </ins> <del> expand_right() is similar, except that the second argument is in the most significant byte, the third is in the second most significant byte, and the first argument is in the least significant bits. Therefore, </del> <ins> 4.3.2.1. </ins> <del> Similarly, truncate_left() and truncate_right() take the most significant and least significant bits, respectively, from a ciphertext.  For example, to take 28 bits of a ciphertext: </del> <ins> The 4-pass algorithm is a four-round Feistel Network with the round function being AES-ECB.  Most modern applications of Feistel Networks have more than four rounds.  The implications of this choice, which is meant to limit the per-packet compute overhead at load balancers, are discussed in distinguishing-attacks. The server concatenates the server ID and nonce into a single field, which is then split into equal halves.  In successive passes, one of these halves is expanded into a 16B plaintext, encrypted with AES- ECB, and the result XORed with the other half.  The diagram below shows the conceptual processing of a plaintext server ID and nonce into a connection ID.  'FO' stands for 'First Octet'. 4.3.2.2. Two functions are useful to define: The expand(length, pass, input_bytes) function concatenates three arguments and outputs 16 zero-padded octets. The first argument 'length' is an 8-bit integer that reports the sum of the configured nonce length and server id length in octets, and forms the most significant octet of the output.  The 'length' argument MUST NOT exceed 28. The second argument is an 8-bit integer that is the 'pass' of the algorithm, and forms the second-most significant octet of the output. The third argument is a variable-length stream of octets, which is copied into the third-most significant octet of the output and beyond.  The length of this octet stream is half the 'length', rounded up.  All remaining octets of the output are zero. For example, Similarly, truncate(input, n) returns the first n octets of 'input'. Let 'half_len' be equal to 'plaintext_len' / 2, rounded up. 4.3.2.3. </ins> The example at the end of this section helps to clarify the steps described below. The server concatenates the server ID and nonce to create <del> plaintext_CID. </del> <ins> plaintext_CID.  The length of the result in octets is plaintext_len. </ins> The server splits plaintext_CID into components left_0 and right_0 <del> of equal length, splitting an odd octet in half if necessary.  For example, 0x7040b81b55ccf3 would split into a left_0 of 0x7040b81 and right_0 of 0xb55ccf3. </del> <ins> of equal length half_len.  If plaintext_len is odd, right_0 clears its first four bits, and left_0 clears its last four bits.  For example, 0x7040b81b55ccf3 would split into a left_0 of 0x7040b810 and right_0 of 0x0b55ccf3. </ins> <del> Encrypt the result of expand_left(left_0, index)) to obtain a ciphertext, where 'index' is one octet: the two most significant bits of which are 0b00, and the six least significant bits are the length of the resulting connection ID in bytes, cid_len. </del> <ins> Encrypt the result of expand(plaintext_len, 1, left_0) using an AES-ECB-128 cipher to obtain a ciphertext. </ins> <del> XOR the least significant bits of the ciphertext with right_0 to form right_1. </del> <ins> XOR the first half_len octets of the ciphertext with right_0 to form right_1.  Steps 3 and 4 can be summarized as </ins> <del> Thus steps 3 and 4 can be expressed as "right_1 = right_0 ^ truncate_right( AES_ECB(key, expand_left(left_0, cid_len, 1)), len(right_0)) " </del> <ins> If the plaintext_len is odd, clear the first four bits of right_1. </ins> Repeat steps 3 and 4, but use them to compute left_1 by expanding <del> and encrypting right_1 with the most significant octet as the concatenation of 0b01 and cid_len, and XOR the results with </del> <ins> and encrypting right_1 with pass = 2, and XOR the results with </ins> left_0. <del> "left_1 = left_0 ^ truncate_left( AES_ECB(key, expand_right(right_1, cid_len, 2)), len(left_0)) " </del> <ins> If the plaintext_len is odd, clear the last four bits of left_1. </ins> Repeat steps 3 and 4, but use them to compute right_2 by expanding <del> and encrypting left_1 with the least significant octet as the concatenation of 0b10 and cid_len, and XOR the results with </del> <ins> and encrypting left_1 with pass = 3, and XOR the results with </ins> right_1. <del> "right_2 = right_1 ^ truncate_right( AES_ECB(key, expand_left(left_1, cid_len, 3), len(right_1)) " </del> <ins> If the plaintext_len is odd, clear the first four bits of right_2. </ins> Repeat steps 3 and 4, but use them to compute left_2 by expanding <del> and encrypting right_2 with the most significant octet as the concatenation of 0b11 ands cid_len, and XOR the results with </del> <ins> and encrypting right_2 with pass = 4, and XOR the results with </ins> left_1. <del> "left_2 = left_1 ^ truncate_left( AES_ECB(key, expand_right(right_2, cid_len, 4), len(left_1)) " </del> <ins> If the plaintext_len is odd, clear the last four bits of left_2. </ins> The server concatenates left_2 with right_2 to form the ciphertext <del> CID, which it appends to the first octet. </del> <ins> CID, which it appends to the first octet.  If plaintext_len is odd, the four least significant bits of left_2 and four most significant bits of right_2, which are all zero, are stripped off before concatenation to make the resulting ciphertext the same length as the original plaintext. 4.3.2.4. </ins> The following example executes the steps for the provided inputs. Note that the plaintext is of odd octet length, so the middle octet


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


included in this candidate collection.  However, disclosure of these addresses has privacy implications.  This document describes a way to share local IP addresses with other clients while preserving client <del> privacy.  This is achieved by obfuscating IP addresses with </del> <ins> privacy.  This is achieved by concealing IP addresses with </ins> dynamically generated Multicast DNS (mDNS) names. 1.


instead continues to use the peer's "Ack-Eliciting Threshold" and "max_ack_delay" thresholds for sending acknowledgements. <del> 6.2. </del> <ins> 7.2. </ins> As specified in Section 13.2.1 of QUIC-TRANSPORT, an endpoint SHOULD immediately acknowledge packets marked with the ECN Congestion Experienced (CE) codepoint in the IP header.  Doing so reduces the peer's response time to congestion events. <del> 6.3. </del> <ins> 7.3. </ins> For performance reasons, an endpoint can receive incoming packets from the underlying platform in a batch of multiple packets.  This


The RTT for a network path may change over time.  If a path's actual RTT decreases, the min_rtt will adapt immediately on the first low <del> sample.  If the path's actual RTT increases, the min_rtt will not adapt to it, allowing future RTT samples that are smaller than the new RTT to be included in smoothed_rtt. </del> <ins> sample.  If the path's actual RTT increases however, the min_rtt will not adapt to it, allowing future RTT samples that are smaller than the new RTT to be included in smoothed_rtt. Endpoints SHOULD set the min_rtt to the newest RTT sample after persistent congestion is established.  This is to allow a connection to reset its estimate of min_rtt and smoothed_rtt (smoothed-rtt) after a disruptive network event, and because it is possible that an increase in path delay resulted in persistent congestion being incorrectly declared. Endpoints MAY re-establish the min_rtt at other times in the connection, such as when traffic volume is low and an acknowledgement is received with a low acknowledgement delay.  Implementations SHOULD NOT refresh the min_rtt value too often, since the actual minimum RTT of the path is not frequently observable. </ins> 5.3.


after setRemoteDescription, decides it does not want to accept the new parameters and sends a reject message back to the offerer.  Now, the offerer, and possibly the answerer as well, needs to return to a <del> stable state and the previous local/remote description.  To support </del> <ins> "stable" state and the previous local/remote description.  To support </ins> this, we introduce the concept of "rollback", which discards any proposed changes to the session, returning the state machine to the <del> stable state.  A rollback is performed by supplying a session </del> <ins> "stable" state.  A rollback is performed by supplying a session </ins> description of type "rollback" with empty contents to either setLocalDescription or setRemoteDescription.


have to keep pace with the changes to SDP, at least until the time that this new encoding eclipsed SDP in popularity. <del> However, to simplify Javascript processing, and provide for future flexibility, the SDP syntax is encapsulated within a SessionDescription object, which can be constructed from SDP, and be serialized out to SDP.  If future specifications agree on a JSON format for session descriptions, we could easily enable this object to generate and consume that JSON. Other methods may be added to SessionDescription in the future to simplify handling of SessionDescriptions from Javascript.  In the meantime, Javascript libraries can be used to perform these manipulations. Note that most applications should be able to treat the </del> <ins> However, to provide for future flexibility, the SDP syntax is encapsulated within a SessionDescription object, which can be constructed from SDP, and be serialized out to SDP.  If future specifications agree on a JSON format for session descriptions, we could easily enable this object to generate and consume that JSON. As detailed below, most applications should be able to treat the </ins> SessionDescriptions produced and consumed by these various API calls as opaque blobs; that is, the application will not need to read or change them.


The "service-limit" is expressed in "quota-units" and has the following syntax: <del> where "quota-units" is a non-negative sf-integer. </del> <ins> where "quota-units" is a non-negative Integer. </ins> The "service-limit" SHOULD match the maximum number of acceptable requests.


scheme.  This provides confidentiality and integrity protection for subscriptions and push messages from external parties. <ins> Applications using this protocol MUST use mechanisms that provide confidentiality, integrity and data origin authentication.  The application server sending the push message and the application on the user agent that receives it are frequently just different instances of the same application, so no standardized protocol is needed to establish a proper security context.  The distribution of subscription information from the user agent to its application server also offers a convenient medium for key agreement. </ins> 8.1. The protection afforded by TLS does not protect content from the push <del> service.  Without additional safeguards, a push service is able to see and modify the content of the messages. Applications are able to provide additional confidentiality, integrity or authentication mechanisms within the push message itself.  The application server sending the push message and the application on the user agent that receives it are frequently just different instances of the same application, so no standardized protocol is needed to establish a proper security context.  The process of providing the application server with subscription information provides a convenient medium for key agreement. The Web Push API codifies this practice by requiring that each push subscription created by the browser be bound to a browser generated encryption key.  Pushed messages are authenticated and decrypted by the browser before delivery to applications.  This scheme ensures that the push service is unable to examine the contents of push messages. The public key for a subscription ensures that applications using that subscription can identify messages from unknown sources and discard them.  This depends on the public key only being disclosed to entities that are authorized to send messages on the channel.  The push service does not require access to this public key. </del> <ins> service.  Without additional safeguards, a push service can inspect and modify the message content. For its requirements, the API has adopted I-D.ietf-webpush-encryption to secure the content of messages from the push service.  Other scenarios can be addressed by similar policies. </ins> The Topic header field exposes information that allows more granular correlation of push messages on the same subject.  This might be used


Boolean <del> If true, it specifies that a Message should be delivered to the other side after the previous Message which was passed to the same Connection via the Send Action.  If false, the Message may be delivered out of order.  This property is used for protocols that support preservation of data ordering, see prop-ordering, but allow out-of-order delivery for certain messages. </del> <ins> If true, it specifies that the receiver-side transport protocol stack only deliver the Message to the receiving application after the previous ordered Message which was passed to the same Connection via the Send Action, when such a Message exists.  If false, the Message may be delivered to the receiving application out of order.  This property is used for protocols that support preservation of data ordering, see prop-ordering, but allow out-of-order delivery for certain messages. </ins> 7.3.4.


in read-only memory, (B) a bootloader, and (C) an operating system kernel. <del> The first Attesting Environment, the read-only BIOS in this example, has to ensure the integrity of the bootloader (the first Target </del> <ins> The first Attesting Environment, the ROM in this example, has to ensure the integrity of the bootloader (the first Target </ins> Environment).  There are potentially multiple kernels to boot, and the decision is up to the bootloader.  Only a bootloader with intact integrity will make an appropriate decision.  Therefore, the Claims


unsigned CNAME records that may have been synthesized in the response from a DNS resolver. <del> The subsequent RRsets MUST contain the full sequence of DNS records needed to authenticate the TLSA record set from the server's trust anchor.  Typically this means a sequence of DNSKEY and DS RRsets that cover all zones from the target zone containing the TLSA record set to the trust anchor zone. </del> <ins> The subsequent RRsets MUST contain the full set of DNS records needed to authenticate the TLSA record set from the server's trust anchor. Typically this means a set of DNSKEY and DS RRsets that cover all zones from the target zone containing the TLSA record set to the trust anchor zone.  The TLS client should be prepared to receive this set of RRsets in any order. </ins> Names that are aliased via CNAME and/or DNAME records may involve multiple branches of the DNS tree.  In this case, the authentication


by sending different Resource Records containing ESNIRecord and ESNIKeys values with different keys using a short TTL. <del> 7.2.3. </del> <ins> 7.3.3. </ins> This design requires servers to decrypt ClientHello messages with ClientEncryptedSNI extensions carrying valid digests.  Thus, it is


constrained UI.  Moreover, PSK production lacks guidance unlike user passwords. <del> Some devices are provisioned PSKs via an out-of-band, cloud-based </del> <ins> Some devices provision PSKs via an out-of-band, cloud-based </ins> syncing protocol. Some secrets may be baked into or hardware or software device


the datagram: the context identifier then maps to a compression context that the receiver can use to reconstruct the elided data. <del> Contexts are identified within the scope of a given request by a numeric value, referred to as the context ID.  A context ID is a 62-bit integer (0 to 2^62-1). </del> <ins> Contexts are optional, their use is negotiated on each request stream using registration capsules, see register-capsule and register-no- context-capsule.  When contexts are used, they are identified within the scope of a given request by a numeric value, referred to as the context ID.  A context ID is a 62-bit integer (0 to 2^62-1). </ins> While stream IDs are a per-hop concept, context IDs are an end-to-end concept.  In other words, if a datagram travels through one or more


[TODO: handling of CN, telephone-event, "red"] <del> If the media section if of type audio: </del> <ins> If the media section is of type audio: </ins> For any specified "ptime" value, configure the available <del> payload types to use the specified packet size.  If the specified size is not supported for a payload type, use the </del> <ins> media formats to use the specified packet size.  If the specified size is not supported for a media format, use the </ins> next closest value instead. Finally, if this description is of type "pranswer" or "answer",


Client anonymity.  Such techniques are closely linked to the type of key schedule that is used by the Issuer.  When an Issuer rotates their key, any Client that invokes the issuance protocol in this key <del> cycle will be part of a group of possible clients owning valid tokens </del> <ins> cycle will be part of a group of possible Clients owning valid tokens </ins> for this key.  To mechanize this attack strategy, an Issuer could introduce a key rotation policy that forces Clients into small key cycles, reducing the size of the anonymity set for these Clients.


role.  The entity, as a system bus Verifier, may choose to fully isolate its role as a wide-area network Attester. <del> In essence, an entity that combines more than one role also creates and consumes the corresponding conceptual messages as defined in this </del> <ins> In essence, an entity that combines more than one role creates and consumes the corresponding conceptual messages as defined in this </ins> document. 7.


If a zero-length connection ID is selected, the corresponding transport parameter is included with a zero-length value. <del> fig-auth-cid shows the connection IDs that are used in a complete </del> <ins> fig-auth-cid shows the connection IDs (with DCID=Destination Connection ID, SCID=Source Connection ID) that are used in a complete </ins> handshake.  The exchange of Initial packets is shown, plus the later exchange of 1-RTT packets that includes the connection ID established during the handshake.


The basic operations that the applications can have the media engine do are: <del> Start exchanging media to a given remote peer, but keep all the </del> <ins> Start exchanging media with a given remote peer, but keep all the </ins> resources reserved in the offer. Start exchanging media with a given remote peer, and free any


notifies its peer that if the receiver of the ROUTE_ADVERTISEMENT capsule sends IP packets for this prefix in HTTP Datagrams, the sender of the capsule will forward them along its preexisting route. <del> This capsule uses a Capsule Type of 0xfff102.  Its value uses the following format: </del> <ins> Any of these addresses can be used as the destination address on IP packets originated by the receiver of this capsule.  This capsule uses a Capsule Type of 0xfff102.  Its value uses the following format: </ins> IP Version of this route advertisement.  MUST be either 4 or 6.


7.3. <del> IANA is requested to add srtp_ekt_key_transport as a new extension name to the "ExtensionType Values" table of the "Transport Layer Security (TLS) Extensions" registry with a reference to this specification and allocate a value of TBD to for this.  Note to RFC Editor: TBD will be allocated by IANA. </del> <ins> IANA is requested to add as a new extension name to the "ExtensionType Values" table of the "Transport Layer Security (TLS) Extensions" registry with a reference to this specification and allocate a value of TBD to for this. [[ Note to RFC Editor: TBD will be allocated by IANA. ]] </ins> Considerations for this type of extension are described in Section 5 of RFC4366 and requires "IETF Consensus". 7.4. <del> IANA is requested to add srtp_ekt_message as an new descriptions name to the "TLS ContentType Registry" table of the "Transport Layer Security (TLS) Extensions" registry with a reference to this specification, a DTLS-OK value of "Y", and allocate a value of TBD to for this content type.  Note to RFC Editor: TBD will be allocated by IANA. </del> <ins> IANA is requested to add as a new entry in the "TLS HandshakeType Registry" table of the "Transport Layer Security (TLS) Parameters" registry with a reference to this specification, a DTLS-OK value of "Y", and allocate a value of TBD to for this content type. [[ Note to RFC Editor: TBD will be allocated by IANA. ]] </ins> This registry was defined in Section 12 of RFC5246 and requires "Standards Action".


Load balancers SHOULD drop short header packets with unroutable DCIDs. <del> The routing of long headers with unroutable DCIDs depends on the server ID allocation strategy, described in sid-allocation.  However, the load balancer MUST NOT drop these packets, with one exception. </del> <ins> When forwarding a packet with a long header and unroutable DCID, load balancers MUST use a fallback algorithm as specified in fallback- algorithm. </ins> Load balancers MAY drop packets with long headers and unroutable DCIDs if and only if it knows that the encoded QUIC version does not


depend on the ServerHello and therefore has weaker guarantees. This is especially relevant if the data is authenticated either with TLS client authentication or inside the application protocol. <del> The same warnings apply to any use of the early_exporter_main_secret. </del> <ins> The same warnings apply to any use of the early_exporter_secret. </ins> 0-RTT data cannot be duplicated within a connection (i.e., the server will not process the same data twice for the same connection), and an


the only possible choice for hosting.  There are other services that host revision control repositories and provide similar additional features to GitHub.  For instance, BitBucket [4], or GitLab [5] <del> provide a similar feature set.  In additional to a hosted service, </del> <ins> provide a similar feature set.  In addition to a hosted service, </ins> software for custom installations exists. This document concentrates primarily on GitHub as it has a large and


The Welcome message contains the information that the new member needs to initialize a GroupState object that can be updated to the current state using the Add message.  This information is encrypted <del> for the new member using ECIES.  The recipient key pair for the ECIES </del> <ins> for the new member using HPKE.  The recipient key pair for the HPKE </ins> encryption is the one included in the indicated UserInitKey, corresponding to the indicated ciphersuite.


security application.  The application can now derive application keys using the EDHOC-Exporter interface. <del> If any verification step fails, the Responder MUST send an EDHOC error message back, formatted as defined in error, and the protocol MUST be discontinued. </del> <ins> If any processing step fails, the Responder SHOULD send an EDHOC error message back, formatted as defined in error.  Sending error messages is essential for debugging but MAY e.g.be skipped if a session cannot be found or due to denial of service reasons, see security.  If an error message is sent, the session MUST be discontinued. </ins> After verifying message_3, the Responder is assured that the Initiator has calculated the key PRK_4x3m (explicit key confirmation)


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


12.1. All QUIC packets except Version Negotiation packets use authenticated <del> encryption with additional data (AEAD) RFC5116 to provide </del> <ins> encryption with associated data (AEAD) RFC5116 to provide </ins> confidentiality and integrity protection.  Retry packets use AEAD to provide integrity protection.  Details of packet protection are found in QUIC-TLS; this section includes an overview of the process.


limit its use of tokens to only the information needed to validate client addresses. <ins> Clients MAY use tokens obtained on one connection for any connection attempt using the same version.  When selecting a token to use, clients do not need to consider other properties of the connection that is being attempted, including the choice of possible application protocols, session tickets, or other connection properties. </ins> Attackers could replay tokens to use servers as amplifiers in DDoS attacks.  To protect against such attacks, servers SHOULD ensure that tokens sent in Retry packets are only accepted for a short time.


JSEP's handling of session descriptions is simple and straightforward.  Whenever an offer/answer exchange is needed, the <del> initiating side creates an offer by calling a createOffer() API.  The </del> <ins> initiating side creates an offer by calling a createOffer API.  The </ins> application then uses that offer to set up its local config via the <del> setLocalDescription() API.  The offer is finally sent off to the remote side over its preferred signaling mechanism (e.g., WebSockets); upon receipt of that offer, the remote party installs it using the setRemoteDescription() API. </del> <ins> setLocalDescription API.  The offer is finally sent off to the remote side over its preferred signaling mechanism (e.g., WebSockets); upon receipt of that offer, the remote party installs it using the setRemoteDescription API. </ins> To complete the offer/answer exchange, the remote party uses the <del> createAnswer() API to generate an appropriate answer, applies it using the setLocalDescription() API, and sends the answer back to the </del> <ins> createAnswer API to generate an appropriate answer, applies it using the setLocalDescription API, and sends the answer back to the </ins> initiator over the signaling channel.  When the initiator gets that <del> answer, it installs it using the setRemoteDescription() API, and </del> <ins> answer, it installs it using the setRemoteDescription API, and </ins> initial setup is complete.  This process can be repeated for additional offer/answer exchanges.


in hexadecimal notation.  Future versions of QUIC SHOULD generate a new salt value, thus ensuring that the keys are different for each version of QUIC.  This prevents a middlebox that only recognizes one <del> version of QUIC from seeing or modifying the contents of handshake packets from future versions. </del> <ins> version of QUIC from seeing or modifying the contents of packets from future versions. </ins> The HKDF-Expand-Label function defined in TLS 1.3 MUST be used for Initial packets even where the TLS versions offered do not include


external_aad = << TH_3, CRED_I, ? EAD_3 >> <del> CRED_I - bstr containing the credential of the Initiator, see id_cred. </del> <ins> CRED_I - CBOR item containing the credential of the Initiator, see id_cred. </ins> EAD_3 = protected external authorization data, see


frames as specified in Sections 5 and 6 of RFC6455. The message format shown in ws-message-format is the same as the CoAP <del> over TCP message format (see tcp-message-format) with one restriction.  The Length (Len) field MUST be set to zero because the WebSockets frame contains the length. </del> <ins> over TCP message format (see tcp-message-format) with one change. The Length (Len) field MUST be set to zero because the WebSockets frame contains the length. </ins> <del> The CoAP over TCP message format eliminates the Version field defined in CoAP over UDP.  If CoAP version negotiation is required in the future, CoAP over WebSockets can address the requirement by the definition of a new subprotocol identifier that is negotiated during the opening handshake. </del> <ins> As with CoAP over TCP, the message format for CoAP over Websockets eliminates the Version field defined in CoAP over UDP.  If CoAP version negotiation is required in the future, CoAP over WebSockets can address the requirement by the definition of a new subprotocol identifier that is negotiated during the opening handshake. </ins> Requests and response messages can be fragmented as specified in Section 5.4 of RFC6455, though typically they are sent unfragmented


on compliant devices, then the corresponding attestation format should be untrusted until the exploit is patched.  Addressing changes in attestation quality is therefore a deployment-specific task.  In <del> Split Attester and Issuer deployments, Issuers can choose to remove compromised Attesters from their trusted set until the compromise is patched, without needing to modify Origin allow-lists. </del> <ins> Split Attester and Issuer deployments (see deploy-split), Issuers can choose to remove compromised Attesters from their trusted set until the compromise is patched, without needing to modify Origin allow- lists. </ins> 3.2.2.


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


5.3. Before using DOH response data for DNS resolution, the client MUST <del> 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 </del> <ins> establish that the HTTP request URI is authorized for the DOH query. For HTTP requests initiated by the DNS API client this authorization </ins> 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 <del> client as trusted DNS API servers. </del> <ins> client as authorized DNS API servers. </ins> 5.4.


This document <del> 8.2. This document will request IANA to register IP_PACKET in the "HTTP Datagram Format Types" registry established by HTTP-DGRAM. 8.3. </del> <ins> 9.2. </ins> This document will request IANA to add the following values to the "HTTP Capsule Types" registry created by HTTP-DGRAM:


among parallel groups.  For example, suppose a common member M of two groups A and B has performed a key update in group A but not in group B.  The key update provides PCS with regard to M in group A.  If a <del> PSK exported from group A and injected into group B, then some of </del> <ins> PSK is exported from group A and injected into group B, then some of </ins> these PCS properties carry over to group B, since the PSK and secrets derived from it are only known to the new, updated version of M, not to the old, possibly compromised version of M.


violated, then the security properties of TLS are severely weakened. As discussed in use-cases, there are use cases where it is desirable <del> for multiple clients or multiple servers share a PSK.  If this is </del> <ins> for multiple clients or multiple servers to share a PSK.  If this is </ins> done naively by having all members share a common key, then TLS only authenticates the entire group, and the security of the overall system is inherently rather brittle.  There are a number of obvious


5.1. Configuration interfaces are used to configure the security protocols <del> before a handshake begins or the keys are negotiated. </del> <ins> before a handshake begins or keys are negotiated. </ins> Identities and Private Keys (IPK): The application can provide its identity, credentials (e.g., certificates), and private keys, or


the first transport encryption supported in some classes of constrained devices. <ins> An ACP node announces its ability to support DTLS as the ACP secure channel protocol in GRASP as the "DTLS" method for the "AN_ACP" objective. </ins> To run ACP via UDP and DTLS v1.2 RFC6347 a locally assigned UDP port is used that is announced as a parameter in the GRASP AN_ACP objective to candidate neighbors.


format payload to register. The registrant-ep includes the same registration parameters in the <del> POST request as it would per registration.  The registration base URI of the registration is taken from the registrant-ep's network address (as is default with regular registrations). </del> <ins> POST request as it would with a regular registration per registration.  The registration base URI of the registration is taken from the registrant-ep's network address (as is default with regular registrations). </ins> Example request from registrant-EP to RD (unanswered until the next step):


If present, a single "a=dtls-id" line is parsed as specified in I- D.ietf-mmusic-dtls-sdp Section 5, and the dtls-id value is stored. <ins> Any "a=identity" lines are parsed and the identity values stored for subsequent verification, as specified I-D.ietf-rtcweb- security-arch, Section 5. </ins> Any "a=extmap" lines are parsed as specified in RFC5285, Section 5, and their values are stored.