configuration.  This does not guarantee protection against invalid data but reduces the risk. <del> A client can use DNS over HTTPS as one of multiple mechanisms to obtain DNS data.  If a client of this protocol encounters an HTTP error after sending a DNS query, and then falls back to a different DNS retrieval mechanism, doing so can weaken the privacy and authenticity expected by the user of the client. </del> 10. Local policy considerations and similar factors mean different DNS


its own name as one of the names in the list. When used in an authentication challenge, the "PrivateToken" scheme <del> uses the following attributes: </del> <ins> uses the following parameters: </ins> "challenge", which contains a base64url-encoded RFC4648 TokenChallenge value.  Since the length of the challenge is not


authenticating to, and interacting with the captive portal is out of scope of this document. <del> RFC7710 used DHCP code point 160.  Due to a conflict, this document specifies TBD. </del> <ins> This document replaces RFC 7710.  RFC 7710 used DHCP code point 160. Due to a conflict, this document specifies TBD. </ins> [ This document is being collaborated on in Github at: https://github.com/capport-wg/7710bis.  The most recent version of


it also requires connection IDs of at least 17 octets, increasing overhead of client-to-server packets. <del> 4.4.1. </del> <ins> 4.3.1. </ins> The configuration agent assigns a server ID to every server in its pool, and determines a server ID length (in octets) sufficiently


implementation level only -- they do not influence the result of the evaluation.) <del> Any function expressions in a query must be well-formed (by conforming to the above ABNF) and well-typed, otherwise the JSONPath </del> <ins> Any function expressions in a query must be well formed (by conforming to the above ABNF) and well typed, otherwise the JSONPath </ins> implementation MUST raise an error (see synsem-overview).  To define <del> which function expressions are well-typed, a type system is first </del> <ins> which function expressions are well typed, a type system is first </ins> introduced. 2.6.1.


For any specified "TIAS" bandwidth value, set this value as a constraint on the maximum RTP bitrate to be used when sending <del> media as specified in RFC3890.  If a "TIAS" value is not </del> <ins> media, as specified in RFC3890.  If a "TIAS" value is not </ins> present, but an "AS" value is specified, generate a "TIAS" value using this formula:


confidence to the receiving peer that the sending peer is reachable at the indicated address and port. <ins> Note however that, irrespective of CID, if RRC has been successfully negotiated by the peers, path validation can be used at any time by either endpoint.  For instance, an endpoint might use RRC to check that a peer is still in possession of its address after a period of quiescence. </ins> 2. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",


servers that support UDP proxying ought to restrict its use to authenticated users. <ins> There exist software and network deployments that perform access control checks based on the source IP address of incoming requests. For example, some software allows unauthenticated configuration changes if they originated from 127.0.0.1.  Such software could be running on the same host as the UDP proxy, or in the same broadcast domain.  Proxied UDP traffic would then be received with a source IP address belonging to the UDP proxy.  If this source address is used for access control, UDP proxying clients could use the UDP proxy to escalate their access privileges beyond those they might otherwise have.  This could lead to unauthorized access by UDP proxying clients unless the UDP proxy disallows UDP proxying requests to vulnerable targets, such as localhost names and addresses, link-local addresses, the UDP proxy's own addresses, multicast and broadcast addresses. UDP proxies can use the destination_ip_prohibited Proxy Error Type from PROXY-STATUS when rejecting such requests. </ins> UDP proxies share many similarities to TCP CONNECT proxies when considering them as infrastructure for abuse to enable denial of service attacks.  Both can obfuscate the attacker's source address


algorithm and PSK.  Thus, an EPSK may be used with the same KDF (and underlying HMAC hash algorithm) as TLS 1.3 with importers.  However, critically, the derived PSK will not be the same since the importer <del> differentiates the PSK via the identity, target protocol, and target KDF.  Thus, PSKs imported for TLS 1.3 are distinct from those used in TLS 1.2, and thereby avoid cross-protocol collisions.  Note that this </del> <ins> differentiates the PSK via the identity and target KDF and protocol. Thus, PSKs imported for TLS 1.3 are distinct from those used in TLS 1.2, and thereby avoid cross-protocol collisions.  Note that this </ins> does not preclude endpoints from using non-imported PSKs for TLS 1.2. Indeed, this is necessary for incremental deployment. 7. <del> The Key Importer security goals can be roughly stated as follows: </del> <ins> The PSK Importer security goals can be roughly stated as follows: </ins> avoid PSK re-use across KDFs while properly authenticating endpoints. When modeled as computational extractors, KDFs assume that input keying material (IKM) is sampled from some "source" probability


handshake packets sent before the cryptographic context was established are validated later during the cryptographic handshake. Therefore, devices on path cannot alter any information or bits in <del> QUIC packet headers, since alteration of header information will lead to a failed integrity check at the receiver, and can even lead to connection termination. </del> <ins> QUIC packet headers, except specific parts of Initial packets, since alteration of header information will lead to a failed integrity check at the receiver, and can even lead to connection termination. </ins> 2.6.


Revise list of currently available AEAD cipher suites. <ins> Reduce maximum permitted record expansion for AEAD from 2048 to 256 octets. </ins> draft-07 Integration of semi-ephemeral DH proposal.


If sending a second ClientHello in response to a HelloRetryRequest, the client copies the entire "encrypted_client_hello" extension from <del> the first ClientHello. </del> <ins> the first ClientHello.  The identical value will reveal to an observer that the value of "encrypted_client_hello" was fake, but this only occurs if there is a HelloRetryRequest. </ins> If the server sends an "encrypted_client_hello" extension in either HelloRetryRequest or EncryptedExtensions, the client MUST check the


Server functionality: <del> "PP_Server_Setup": Generates server configuration and keys </del> <ins> "ServerSetup": Generates server configuration and keys </ins> <del> "PP_Issue": Run on the contents of the client message in the </del> <ins> "Issue": Run on the contents of the client message in the </ins> issuance phase. <del> "PP_Verify": Run on the contents of the client message in the </del> <ins> "Verify": Run on the contents of the client message in the </ins> redemption phase. Client functionality: <del> "PP_Client_Setup": Generates the client configuration based on the configuration used by a given server. </del> <ins> "ClientSetup": Generates the client configuration based on the configuration used by a given server. </ins> <del> "PP_Generate": Generates public and private data associated with the contents of the client message in the issuance phase. </del> <ins> "Generate": Generates public and private data associated with the contents of the client message in the issuance phase. </ins> <del> "PP_Process": Processes the contents of the server response in the issuance phase. </del> <ins> "Process": Processes the contents of the server response in the issuance phase. </ins> <del> "PP_Redeem": Generates the data that forms the client message in the redemption phase. </del> <ins> "Redeem": Generates the data that forms the client message in the redemption phase. </ins> We will use each of the functions internally in the description of the interfaces that follows.


to predict usage and provision bandwidth, caching, and other mechanisms to meet the needs of users.  In some cases (sec-predict), this is relatively routine, but in other cases, it is more difficult <del> (sec-unpredict, sec-extreme). </del> <ins> (sec-unpredict). </ins> And as with other parts of the ecosystem, new technology brings new challenges.  For example, with the emergence of ultra-low-latency


endpoint is allowed to send packets from any source address that falls within the prefix. <ins> If an endpoint receives multiple ADDRESS_ASSIGN capsules, all of the assigned addresses or prefixes can be used.  For example, multiple ADDRESS_ASSIGN capsules are necessary to assign both IPv4 and IPv6 addresses. </ins> 4.2.2. The ADDRESS_REQUEST capsule allows an endpoint to request assignment


client or network. If the IP address of a Designated Resolver differs from that of an Unencrypted DNS Resolver, clients applying Verified Discovery (verified) MUST validate that the IP address of the Unencrypted DNS Resolver is covered by the SubjectAlternativeName of the Designated


associate an SNI value with the ticket.  Clients, however, SHOULD store the SNI with the PSK to fulfill the requirements of NSTMessage. <del> Implementor's note: the most straightforward way to implement the PSK/cipher suite matching requirements is to negotiate the cipher suite first and then exclude any incompatible PSKs.  Any unknown PSKs (e.g., they are not in the PSK database or are encrypted with an unknown key) SHOULD simply be ignored.  If no acceptable PSKs are found, the server SHOULD perform a non-PSK handshake if possible. </del> <ins> Implementor's note: when session resumption is the primary use case of PSKs the most straightforward way to implement the PSK/cipher suite matching requirements is to negotiate the cipher suite first and then exclude any incompatible PSKs.  Any unknown PSKs (e.g., they are not in the PSK database or are encrypted with an unknown key) SHOULD simply be ignored.  If no acceptable PSKs are found, the server SHOULD perform a non-PSK handshake if possible.  If backwards compatibility is important, client provided, externally established PSKs SHOULD influence cipher suite selection. </ins> Prior to accepting PSK key establishment, the server MUST validate the corresponding binder value (see psk-binder below).  If this value


appropriate rules. If the client supports only the default hash and signature algorithms <del> (listed in this section), it MAY omit the signature_algorithms </del> <ins> (listed in this section), it MAY omit the "signature_algorithms" </ins> extension.  If the client does not support the default algorithms, or supports other hash and signature algorithms (and it is willing to use them for verifying messages sent by the server, i.e., server certificates and server key share), it MUST send the <del> signature_algorithms extension, listing the algorithms it is willing to accept. </del> <ins> "signature_algorithms" extension, listing the algorithms it is willing to accept. </ins> <del> If the client does not send the signature_algorithms extension, the </del> <ins> If the client does not send the "signature_algorithms" extension, the </ins> server MUST do the following: If the negotiated key exchange algorithm is one of (DHE_RSA,


Including a "Date" header field in the response allows the to correct clock errors by retrying the same request using the value of the "Date" field provided by the .  The value of the "Date" field can be <del> copied if the request is fresh, with an adjustment based on the "Age" field otherwise.  When retrying a request, the MUST create a fresh encryption of the modified request, using a new HPKE context. </del> <ins> copied if the response is fresh, with an adjustment based on the "Age" field otherwise; see HTTP-CACHING.  When retrying a request, the MUST create a fresh encryption of the modified request, using a new HPKE context. Retrying immediately allows the to measure the round trip time to the . The observed delay might reveal something about the location of the .  could delay retries to add some uncertainty to any observed delay. </ins> Intermediaries can sometimes rewrite the "Date" field when forwarding responses.  This might cause problems if the and intermediary clocks


3. During pre-establishment the application specifies the Endpoints to <del> be used for communication as well as its preferences regarding Protocol and Path Selection.  The implementation stores these objects and properties as part of the Preconnection object for use during connection establishment.  For Protocol and Path Selection Properties that are not provided by the application, the implementation must use the default values specified in the Transport Services API (I-D.ietf- taps-interface). </del> <ins> be used for communication as well as its preferences via Selection Properties and, if desired, also Connection Properties.  Generally, Connection Properties should be configured as early as possible, as they may serve as input to decisions that are made by the implementation (the Capacity Profile may guide usage of a protocol offering scavenger-type congestion control, for example).  In the remainder of this document, we only refer to Selection Properties because they are the more typical case and have to be handled by all implementations. The implementation stores these objects and properties as part of the Preconnection object for use during connection establishment.  For Selection Properties that are not provided by the application, the implementation must use the default values specified in the Transport Services API (I-D.ietf-taps-interface). </ins> 3.1.


delay SHOULD NOT be considered an RTT sample. Until the server has validated the client's address on the path, the <del> amount of data it can send is limited, as specified in Section 8.1 of QUIC-TRANSPORT.  Data at Initial encryption MUST be retransmitted before Handshake data and data at Handshake encryption MUST be retransmitted before any ApplicationData data.  If no data can be sent, then the PTO alarm MUST NOT be armed until data has been received from the client. </del> <ins> amount of data it can send is limited to three times the amount of data received, as specified in Section 8.1 of QUIC-TRANSPORT.  If no data can be sent, then the PTO alarm MUST NOT be armed. </ins> Since the server could be blocked until more packets are received from the client, it is the client's responsibility to send packets to


implementation to communicate control data to the Remote Endpoint that can be used to parse Messages. <ins> Once the framer implementation has completed its setup or handshake, it can indicate to the application that it is ready to handling data with this call. </ins> Similarly, when a Message Framer generates a "Stop" event, the framer implementation has the opportunity to write some final data or clear up its local state before the "Closed" event is delivered to the Application.  The framer implementation can indicate that it has <del> finished with this. </del> <ins> finished with this call. </ins> At any time if the implementation encounters a fatal error, it can also cause the Connection to fail and provide an error.


associated signature algorithm).  The signature on the credential indicates a delegation from the certificate that is issued to the TLS server operator.  The secret key used to sign a credential <del> corresponds to the public key of the X.509 end-entity certificate. </del> <ins> corresponds to the public key of the TLS server's X.509 end-entity certificate. </ins> A TLS handshake that uses delegated credentials differs from a normal handshake in a few important ways:


A credential (only for leaf nodes) <ins> A signature over the content of the node </ins> The conditions under which each of these values must or must not be present are laid out in views.


3.5. <del> Section 4.3 of RFC7231 defines the set of methods in HTTP; </del> <ins> Section 9.3 of RFC9110 defines the set of methods in HTTP; </ins> Section 5.8 of RFC7252 defines the set of methods in CoAP.  As part of the Uniform Interface constraint, each method can have certain properties that give guarantees to clients.


iv_length - length of the initialization vector of the EDHOC AEAD algorithm <del> P = ( ? PAD, ID_CRED_I / bstr / -24..23, Signature_or_MAC_3, ? EAD_3 ) </del> <ins> PLAINTEXT_3 = ( ? PAD, ID_CRED_I / bstr / -24..23, Signature_or_MAC_3, ? EAD_3 ) </ins> If ID_CRED_I contains a single 'kid' parameter, i.e., ID_CRED_I = { 4 : kid_I }, then only the byte string kid_I


Records are signed via a server private key, ESNIKeys have no authenticity or provenance information.  This means that any attacker which can inject DNS responses or poison DNS caches, which is a <del> common scenario in client access netowrks, can supply clients with </del> <ins> common scenario in client access networks, can supply clients with </ins> fake ESNIKeys (so that the client encrypts SNI to them) or strip the ESNIKeys from the response.  However, in the face of an attacker that controls DNS, no SNI encryption scheme can work because the attacker


3. QUIC version 2 endpoints MUST implement the QUIC version 1 <del> specification as described in RFC9000, RFC9001, and RFC9002, with the </del> <ins> specification as described in QUIC, QUIC-TLS, and RFC9002, with the </ins> following changes: The version field of long headers is TBD.  Note: Unless this


5.6. In a number of cases, it is desirable for the endpoint (i.e., the <del> browser) to be able to directly identity the endpoint on the other side without trusting only the signaling service to which they are </del> <ins> browser) to be able to directly identify the endpoint on the other side without trusting the signaling service to which they are </ins> connected.  For instance, users may be making a call via a federated system where they wish to get direct authentication of the other side.  Alternately, they may be making a call on a site which they


DTLS implementations SHOULD follow the following rules: If the DTLS record layer informs the DTLS handshake layer that a <del> message is too big, it SHOULD immediately attempt to fragment it, using any existing information about the PMTU. </del> <ins> message is too big, the handshake layer SHOULD immediately attempt to fragment the message, using any existing information about the PMTU. </ins> If repeated retransmissions do not result in a response, and the PMTU is unknown, subsequent retransmissions SHOULD back off to a


the same properties for operations on the registration resource. Registrants that are prepared to pick a different identifier when <del> their initial attempt at registration is unauthorized should pick an </del> <ins> their initial attempt (or attempts, in the unlikely case of two subsequent collisions) at registration is unauthorized should pick an </ins> identifier at least twice as long as the expected number of registrants; registrants without such a recovery options should pick significantly longer endpoint names (e.g. using UUID URNs RFC4122).


authentication protocols, wherein at least one is uncompromised, jointly authenticates all protocols.  Authenticating with an externally provisioned PSK, therefore, should ideally authenticate <del> both the TLS connection and the external provision process. </del> <ins> both the TLS connection and the external provisioning process. </ins> Typically, the external provision process produces a PSK and corresponding context from which the PSK was derived and in which it <del> should be used.  We refer to an external PSK without such context as "context free". </del> <ins> should be used.  If available, this is used as the ImportedIdentity.context value.  We refer to an external PSK without such context as "context-free". </ins> Thus, in considering the source-independence and compound <del> authentication requirements, the Key Import API described in this document aims to achieve the following goals: </del> <ins> authentication requirements, the PSK Import interface described in this document aims to achieve the following goals: </ins> <del> Externally provisioned PSKs imported into TLS achieve compound authentication of the provision step(s) and connection. </del> <ins> Externally provisioned PSKs imported into a TLS connection achieve compound authentication of the provisioning process and connection. </ins> Context-free PSKs only achieve authentication within the context of a single connection. <del> Imported PSKs are used as IKM for two different KDFs. </del> <ins> Imported PSKs are not used as IKM for two different KDFs. </ins> Imported PSKs do not collide with existing PSKs used for TLS 1.2 and below.


impacted by QUIC. QUIC is an end-to-end transport protocol.  No information in the <del> protocol header, even that which can be inspected, is meant to be mutable by the network.  This is achieved through integrity protection of the wire image WIRE-IMAGE.  Encryption of most control signaling means that less information is visible to the network than is the case with TCP. </del> <ins> protocol header, even that which can be inspected, is mutable by the network.  This is achieved through integrity protection of the wire image WIRE-IMAGE.  Encryption of most control signaling means that less information is visible to the network than is the case with TCP. </ins> Integrity protection can also simplify troubleshooting, because none of the nodes on the network path can modify transport layer <del> information.  However, it does imply that in-network operations that depend on modification of data are not possible without the cooperation of a QUIC endpoint.  This might be possible with the introduction of a proxy which authenticates as an endpoint.  Proxy operations are not in scope for this document. </del> <ins> information.  However, it means in-network operations that depend on modification of data are not possible without the cooperation of an QUIC endpoint.  This might be possible with the introduction of a proxy which authenticates as an endpoint.  Proxy operations are not in scope for this document. </ins> Network management is not a one-size-fits-all endeavour: practices considered necessary or even mandatory within enterprise networks


5. <del> This document discuses some opportunities to introduce these </del> <ins> This document discuses some opportunities to introduce coding </ins> techniques at a wider scale in satellite telecommunications systems. Even though this document focuses on satellite systems, it is worth


limited UI.  For example, they may only have a numeric keypad or even less number of buttons.  When the TOFU approach is not suitable, entering the key would require typing it on a <del> constrained UI.  Moreover, PSK production lacks guidance unlike user passwords. </del> <ins> constrained UI. </ins> Some devices provision PSKs via an out-of-band, cloud-based syncing protocol.


preference to use the User Timeout Option, communication would not fail when a protocol such as QUIC is selected. <del> Other specialized features, however, could be strictly required by an </del> <ins> Other specialized features, however, can be strictly required by an </ins> application and thus constrain the set of protocols that can be used. For example, if an application requires support for automatic handover or failover for a connection, only protocol stacks that


POST <del> {+rd}{?ep,d,et,lt,con,extra-attrs*} </del> <ins> {+rd}{?ep,d,lt,con,extra-attrs*} </ins>


the link-format payload to register. The endpoint MUST include the endpoint name and MAY include the <del> registration parameters d, lt, et and extra-attrs, in the POST request as per registration.  The context of the registration is taken from the requesting server's URI. </del> <ins> registration parameters d, lt and extra-attrs, in the POST request as per registration.  The context of the registration is taken from the requesting server's URI. </ins> The endpoints MUST be deleted after the expiration of their lifetime. Additional operations cannot be executed because no registration


of contexts, and they MAY do so in a way which is opaque to intermediaries. <del> 4.3. </del> <ins> 4.4.3. </ins> The CLOSE_DATAGRAM_CONTEXT capsule (see iana-types for the value of the capsule type) allows an endpoint to inform its peer that it will


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


length connection ID is also strongly recommended when migration is supported. <del> Currently QUIC only supports the use of a single network path at a time, which enables failover use cases.  Path validation is required so that endpoints validate paths before use to avoid address spoofing attacks.  Path validation takes at least one RTT and congestion control will also be reset after path migration.  Therefore migration usually has a performance impact. </del> <ins> The base specification of QUIC version 1 only supports the use of a single network path at a time, which enables failover use cases. Path validation is required so that endpoints validate paths before use to avoid address spoofing attacks.  Path validation takes at least one RTT and congestion control will also be reset after path migration.  Therefore migration usually has a performance impact. </ins> QUIC probing packets, which can be sent on multiple paths at once, are used to perform address validation as well as measure path


Before a new entry is added to the dynamic table, entries are evicted from the end of the dynamic table until the size of the dynamic table is less than or equal to (table capacity - size of new entry) or <del> until the table is empty.  The encoder MUST NOT evict a dynamic table entry unless it has first been acknowledged by the decoder. </del> <ins> until the table is empty.  The encoder MUST NOT evict a blocking dynamic table entry (see blocked-insertion). </ins> If the size of the new entry is less than or equal to the dynamic table capacity, then that entry is added to the table.  It is an


constructing and processing an . The Nn and Nk values correspond to parameters of the AEAD used in <del> HPKE, which is defined in HPKE.  Nn and Nk refer to the size of the AEAD nonce and key respectively, in bytes.  The nonce length is set to the larger of these two lengths, i.e., max(Nn, Nk). </del> <ins> HPKE, which is defined in HPKE or the HPKE AEAD IANA registry [2]. Nn and Nk refer to the size of the AEAD nonce and key respectively, in bytes.  The nonce length is set to the larger of these two lengths, i.e., max(Nn, Nk). </ins> 4.3.


This interaction is often limited to signaling between the record layer and the handshake layer. <del> ESP </del> <ins> IPsec </ins> Mobility Events (ME): The record protocol can be signaled that it is being migrated to another transport or interface due to


above), then it MUST be populated.  Otherwise, the sender MAY omit the "path" field at its discretion. <del> If populating the "path" field: Create a DirectPath using the new </del> <ins> If populating the "path" field: Create a UpdatePath using the new </ins> tree (which includes any new members).  The GroupContext for this operation uses the "group_id", "epoch", "tree_hash", and "confirmed_transcript_hash" values in the initial GroupContext object. <del> Assign this DirectPath to the "path" field in the Commit. </del> <ins> Assign this UpdatePath to the "path" field in the Commit. </ins> <del> Apply the DirectPath to the tree, as described in </del> <ins> Apply the UpdatePath to the tree, as described in </ins> synchronizing-views-of-the-tree.  Define "commit_secret" as the value "path_secret[n+1]" derived from the "path_secret[n]" value assigned to the root node.


network elements such as firewalls that use the port number for application identification. <ins> Applications could define an alternate endpoint discovery mechanism to allow the usage of ports other than the default.  For example, HTTP/3 (Sections 3.2 and 3.3 of QUIC-HTTP) specifies the use of HTTP Alternative Services RFC7838 for an HTTP origin to advertise the availability of an equivalent HTTP/3 endpoint on a certain UDP port by using the "h3" Application-Layer Protocol Negotiation (ALPN) RFC7301 token. ALPN permits the client and server to negotiate which of several protocols will be used on a given connection.  Therefore, multiple applications might be supported on a single UDP port based on the ALPN token offered.  Applications using QUIC are required to register an ALPN token for use in the TLS handshake. As QUIC version 1 deferred defining a complete version negotiation mechanism, HTTP/3 requires QUIC version 1 and defines the ALPN token ("h3") to only apply to that version.  So far no single approach has been selected for managing the use of different QUIC versions, neither in HTTP/3 nor in general.  Application protocols that use QUIC need to consider how the protocol will manage different QUIC versions.  Decisions for those protocols might be informed by choices made by other protocols, like HTTP/3. </ins> 9. QUIC supports connection migration by the client.  If an IP address


The last input comprises the randomness consumed by the sharding algorithm.  The sharding randomness is a random byte string of length specified by the VDAF.  The Client MUST generate this using a <del> cryptographicallly secure random number generator. </del> <ins> cryptographically secure random number generator. </ins> The Client then wraps each input share in the following structure:


When a client wants to establish a TLS session with the backend server, it constructs its ClientHello as usual (we will refer to this as the ClientHelloInner message) and then encrypts this message using <del> the ECH public key.  It then constructs a new ClientHello (ClientHelloOuter) with innocuous values for sensitive extensions, e.g., SNI, ALPN, etc., and with the encrypted ClientHelloInner in an </del> <ins> the public key of the ECH configuration.  It then constructs a new ClientHello (ClientHelloOuter) with innocuous values for sensitive extensions, e.g., SNI, ALPN, etc., and with an </ins> "encrypted_client_hello" extension, which this document defines <del> (encrypted-client-hello).  Finally, it sends ClientHelloOuter to the server. </del> <ins> (encrypted-client-hello).  The extension's payload carries the encrypted ClientHelloInner and specifies the ECH configuration used for encryption.  Finally, it sends ClientHelloOuter to the server. </ins> Upon receiving the ClientHelloOuter, the client-facing server takes one of the following actions:


4.5.6. <del> Before an Aggregator responds to a CollectReq or AggregateShareReq, it must first check that the request does not violate the parameters associated with the DAP task.  It does so as described here. </del> <ins> Before an Aggregator responds to a CollectionReq or AggregateShareReq, it must first check that the request does not violate the parameters associated with the DAP task.  It does so as described here. </ins> First the Aggregator checks that the batch respects any "boundaries" determined by the query type.  These are described in the subsections


value to distinguish cTLS plaintext records from encrypted records, TLS/DTLS records, and other protocols using the same 5-tuple. <ins> The "profile_id" field MUST identify the profile that is in use.  A zero-length ID corresponds to the cTLS default protocol.  The server's reply does not include the "profile_id", because the server must be using the same profile indicated by the client. </ins> Encrypted records use DTLS 1.3 RFC9147 record framing, comprising a configuration octet followed by optional connection ID, sequence number, and length fields.  The encryption process and additional


2.5.5.2.1. <del> A path by itself in a Logical context is an existence test which yields true if the path selects at least one node and yields false if the path does not select any nodes. </del> <ins> A query by itself in a Logical context is an existence test which yields true if the query selects at least one node and yields false if the query does not select any nodes. </ins> Existence tests differ from comparisons in that: <del> they work with arbitrary relative or absolute paths (not just Singular Paths). </del> <ins> they work with arbitrary relative or absolute queries (not just Singular Queries). </ins> <del> they work with paths that select structured values. </del> <ins> they work with queries that select structured values. </ins> <del> To examine the value of a node selected by a path, an explicit </del> <ins> To examine the value of a node selected by a query, an explicit </ins> comparison is necessary.  For example, to test whether the node <del> selected by the path "@.foo" has the value "null", use "@.foo == </del> <ins> selected by the query "@.foo" has the value "null", use "@.foo == </ins> null" (see null-semantics) rather than the negated existence test "!@.foo" (which yields false if "@.foo" selects a node, regardless of the node's value).


the main Connection implementation that delivers events to the custom framer implementation whenever data is ready to be parsed or framed. <ins> The Transport Services implementation needs to ensure that all of the events and actions taken on a Message Framer are synchronized to ensure consistent behavior.  For example, some of the actions defined below (such as PrependFramer and StartPassthrough) modify how data flows in a protocol stack, and require synchronization with sending and parsing data in the Message Framer. </ins> When a Connection establishment attempt begins, an event can be delivered to notify the framer implementation that a new Connection is being created.  Similarly, a stop event can be delivered when a


JSEP's handling of session descriptions is simple and straightforward.  Whenever an offer/answer exchange is needed, the initiating side creates an offer by calling a createOffer() API.  The <del> application optionally modifies that offer, and then uses it to set up its local config via the setLocalDescription() API.  The offer is then 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> application then uses that offer to set up its local config via the 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 createAnswer() API to generate an appropriate answer, applies it