All comparisons of text strings are performed byte-by-byte (and therefore necessarily case-sensitive). <ins> Where arithmetic is used, this specification uses the notation familiar from the programming language C, except that the operator "**" stands for exponentiation. </ins> 4. Each SenML Pack carries a single array that represents a set of


However, QUIC DATAGRAM frames do not provide a means to demultiplex application contexts.  This document describes how to use QUIC DATAGRAM frames when the application protocol running over QUIC is <del> HTTP/3 H3.  It defines logical flows identified by a non-negative integer that are present at the start of the DATAGRAM frame payload. Flows are associated with HTTP messages using the Datagram-Flow-Id header field, allowing endpoints to match unreliable DATAGRAMS frames to the HTTP messages that they are related to. This design mimics the use of Stream Types in HTTP/3, which provide a demultiplexing identifier at the start of each unidirectional stream. </del> <ins> HTTP/3 H3.  It associates datagrams with client-initiated bidirectional streams and defines an optional additional demultiplexing layer. </ins> Discussion of this work is encouraged to happen on the MASQUE IETF mailing list (masque@ietf.org [2]) or on the GitHub repository which


multiple layers of derivation or resolution, such as DNS service resolution and DNS hostname resolution. <ins> For example, if the application has indicated both a preference for WiFi over LTE and for a feature only available in SCTP, branches will be first sorted accord to path selection, with WiFi at the top. Then, branches with SCTP will be sorted to the top within their subtree according to the properties influencing protocol selection. However, if the implementation has cached the information that SCTP is not available on the path over WiFi, there is no SCTP node in the WiFi subtree.  Here, the path over WiFi will be tried first, and, if connection establishment succeeds, TCP will be used.  So the Selection Property of preferring WiFi takes precedence over the Property that led to a preference for SCTP. </ins> 4.3. Implementations should sort the branches of the tree of connection


First four (4) octets of the SHA-256 message digest RFC6234 of the ESNIKeys structure starting from the first octet of "keys" to the <del> end of the stucture. </del> <ins> end of the structure. </ins> The list of keys which can be used by the client to encrypt the SNI.  Every key being listed MUST belong to a different group. The length to pad the ServerNameList value to prior to encryption. This value SHOULD be set to the largest ServerNameList the server <del> expects to support rounded up the nearest multiple of 16. [[OPEN ISSUE: An alternative to padding is to instead send a hash of the server name.  This would be fixed-length, but have the disadvantage that the server has to retain a table of all the server names it supports, and will not work if the mapping between the client-facing server and hidden server uses wildcards.]] </del> <ins> expects to support rounded up the nearest multiple of 16.  If the server supports wildcard names, it SHOULD set this value to 256. </ins> The moment when the keys become valid for use.  The value is represented as seconds from 00:00:00 UTC on Jan 1 1970, not


Tree hash: The root hash of the above ratchet tree <del> Confirmed transcript hash: the zero-length octet string </del> <ins> Confirmed transcript hash: The zero-length octet string </ins> <del> Interim transcript hash: the zero-length octet string </del> <ins> Interim transcript hash: The zero-length octet string </ins> <del> Init secret: a fresh random value of size "KDF.Nh" </del> <ins> Init secret: A fresh random value of size "KDF.Nh" Extensions: Any values of the creator's choosing </ins> For each member, construct an Add proposal from the KeyPackage for that member (see add)


The following example shows a case where "example.com" has a server running on port 443, with an alternate port of 8443 for QUIC. <del> 6.1.3. </del> <ins> 6.1.4. </ins> The following examples of Endpoints show common usage patterns.


secure delegation.  The zone signing and secure delegation may be performed either by the Homenet Naming Authority or by the Outsourcing Infrastructure. sec-dnssec-deplyment discusses these two <del> alternatives. sec-views discusses the consequences of publishing multiple representations of the same zone also commonly designated as views.  This section provides guidance to limit the risks associated with multiple views.  sec-reverse discusses management of the reverse zone. sec-renumbering discusses how renumbering should be handled. </del> <ins> alternatives. sec-reverse discusses management of the reverse zone. sec-renumbering discusses how renumbering should be handled. </ins> Finally, sec-privacy and sec-security respectively discuss privacy and security considerations when outsourcing the Homenet Zone. <ins> The Homenet Zone is expected to host public information only.  It is not the scope of this DNS service to define local home network boundaries.  Instead, local scope information is expected to be provided to the home network using local scope naming services. mDNS RFC6762 DNS-SD RFC6763 are two examples of these services.  Currently mDNS is limited to a single link network.  However, future protocols are expected to leverage this constraint as pointed out in RFC7558. </ins> 3. Customer Premises Equipment: (CPE) is a router providing


also send-idempotent.  This is a strict requirement.  The default is to not have this option. <del> 5.2.5. </del> <ins> 5.2.6. </ins> Type: Preference


Every time a client issues a new Observe request, a new Partial IV MUST be used (see cose-object), and so the payload and OSCORE option are changed.  The server uses the Partial IV of the new request as <del> the 'request_piv' of all associated notifications (see AAD).  The Partial IV of the registration is also used as 'request_piv' of associated cancellations (see AAD). </del> <ins> the 'request_piv' of all associated notifications (see AAD). </ins> Intermediaries are not assumed to have access to the OSCORE security context used by the endpoints, and thus cannot make requests or


isolating a single location within a document. Path is a query syntax that can also be used to pull multiple locations. <ins> [no-dot-length] We probably want to use an expression that does not use </ins>


of their element or member values then.  Applied to other value types, it will select nothing. <del> : The zero number/empty string exceptions are no longer true. Booleans work the same everywhere. Negation operator "neg-op" allows to test of values. Applying negation operator twice "!!" gives us </del> <ins> DELETE-ME: (( We currently don't need this.  But we commit a version in case we do need it later.  The negation operator "neg-op" can be applied to any JSON value and returns "true" only when applied to "false" or "null": </ins> <del> of values. </del> <ins> Consequently, applying the negation operator twice "!!" returns "true" for all values except "false" or "null".  )) </ins> Some examples:


which is in milliseconds.  Sending a value smaller than the "min_ack_delay" advertised by the peer is invalid.  Receipt of an invalid value MUST be treated as a connection error of type <del> PROTOCOL_VIOLATION. </del> <ins> PROTOCOL_VIOLATION.  On receiving a valid value in this field, the endpoint MUST update its "max_ack_delay" to the value provided by the peer. </ins> A variable-length integer that indicates how many out of order packets can arrive before eliciting an immediate ACK.  If no


7.3.2. <del> This method is indicated by "mtls" in the "proof" field.  The signer presents its TLS client certificate during TLS negotiation with the verifier. </del> <ins> This method is indicated by the method value "mtls".  This method defines no additional parameters.  The signer presents its TLS client certificate during TLS negotiation with the verifier. </ins> In this example, the certificate is communicated to the application through the "Client-Cert" header from a TLS reverse proxy, leading to


Changed the lookup interface to accept endpoint and Domain as query string parameters to control the scope of a lookup. <ins> Editorial Comments [_1] cabo: What is _sub here? </ins>


to an entity body that is 4096 bytes or less in size. To limit the number of stored push messages, the push service MAY <del> either expire messages prior to their advertised Time-To-Live or reduce their advertised Time-To-Live. </del> <ins> respond with a shorter Time-To-Live than proposed by the application server in its request for push message delivery (ttl).  Once a message has been accepted, the push service MAY later expire the message prior to its advertised Time-To-Live.  If the application server requested a delivery receipt, the push service MUST return a failure response (acknowledge_message). </ins> 7.3.


prioritization. Note that this property is not a per-message override of the <del> connection Priority - see conn-priority.  Both Priority properties may interact, but can be used independently and be realized by different mechanisms. </del> <ins> connection Priority - see conn-priority.  The Priority properties may interact, but can be used independently and be realized by different mechanisms; see priority-in-taps. </ins> 8.1.3.3.


transport layer, in line with developments in modern platforms and programming languages; <del> Selection between alternate network paths that can be informed by additional information that is available about the networks over </del> <ins> Selection between alternate network paths that can be informed when additional information is available about the networks over </ins> which an endpoint can operate (e.g.  Provisioning Domain (PvD) information RFC7556);


The ciphersuites are defined in section mls-ciphersuites. <del> Depending on the Diffie-Hellman group of the ciphersuite, different rules apply to private key derivation and public key verification. For all ciphersuites defined in this document, the Derive-Key-Pair function begins by deriving a "key pair secret" of appropriate length, then converting it to a private key in the required group. The ciphersuite specifies the required length and the conversion. 6.1.1. For X25519, the key pair secret is 32 octets long.  No conversion is required, since any 32-octet string is a valid X25519 private key. The corresponding public key is X25519(SHA-256(X), 9). For X448, the key pair secret is 56 octets long.  No conversion is required, since any 56-octet string is a valid X448 private key.  The corresponding public key is X448(SHA-256(X), 5). Implementations MUST use the approach specified in RFC7748 to calculate the Diffie-Hellman shared secret.  Implementations MUST check whether the computed Diffie-Hellman shared secret is the all- zero value and abort if so, as described in Section 6 of RFC7748.  If implementers use an alternative implementation of these elliptic curves, they MUST perform the additional checks specified in Section 7 of 6.1.2. For P-256, the key pair secret is 32 octets long.  For P-521, the key pair secret is 66 octets long.  In either case, the private key derived from a key pair secret is computed by interpreting the key pair secret as a big-endian integer. ECDH calculations for these curves (including parameter and key generation as well as the shared secret calculation) are performed according to IEEE1363 using the ECKAS-DH1 scheme with the identity map as key derivation function (KDF), so that the shared secret is the x-coordinate of the ECDH shared secret elliptic curve point represented as an octet string.  Note that this octet string (Z in IEEE 1363 terminology) as output by FE2OSP, the Field Element to Octet String Conversion Primitive, has constant length for any given field; leading zeros found in this octet string MUST NOT be truncated. (Note that this use of the identity KDF is a technicality.  The complete picture is that ECDH is employed with a non-trivial KDF because MLS does not directly use this secret for anything other than for computing other secrets.) Clients MUST validate remote public values by ensuring that the point is a valid point on the elliptic curve.  The appropriate validation procedures are defined in Section 4.3.7 of X962 and alternatively in Section 5.6.2.3 of keyagreement.  This process consists of three steps: (1) verify that the value is not the point at infinity (O), (2) verify that for Y = (x, y) both integers are in the correct interval, (3) ensure that (x, y) is a correct solution to the elliptic curve equation.  For these curves, implementers do not need to verify membership in the correct subgroup. </del> 6.2. A member of a group authenticates the identities of other


As depicted in fig-naming-arch and fig-auth-servers, the Public Homenet Zone is hosted on the Public Authoritative Server(s), whereas <del> the Homenet Zone is hosted on the HNA.  Motivations for keeping these two zones identical are detailed in sec-views, and this section considers that the HNA builds the zone that will be effectively published on the Public Authoritative Server(s).  In other words "Homenet to Public Zone transformation" is the identity also commonly designated as "no operation" (NOP). </del> <ins> the Homenet Zone is hosted on the HNA.  This section considers that the HNA builds the zone that will be effectively published on the Public Authoritative Server(s).  In other words "Homenet to Public Zone transformation" is the identity also commonly designated as "no operation" (NOP). </ins> In that case, the Homenet Zone should configure its Name Server RRset (NS) and Start of Authority (SOA) with the values associated with the


specified via Provisioning Domain attributes (see prop-pvd) or another specific property. <ins> Note that this property is not used to specify an interface scope for a particular endpoint. ifspec provides details about how to qualify endpoint candidates on a per-interface basis. </ins> 6.2.12. pvd


ppm-urn-space).  Clients SHOULD display the "detail" field of all errors.  The "instance" value MUST be the endpoint to which the request was targeted.  The problem document MUST also include a <del> "taskid" member which contains the associated PPM task ID, encoded with base64 using the standard alphabet RFC4648 (this value is always known, see task-configuration). </del> <ins> "taskid" member which contains the associated PPM task ID, encoded in Base 64 using the URL and filename safe alphabet with no padding as defined in sections 5 and 3.2 of RFC4648 (this value is always known, see task-configuration). </ins> In the remainder of this document, we use the tokens in the table above to refer to error types, rather than the full URNs.  For


It was noted in XPROT that certificates in use by servers that support outdated protocols such as SSLv2 can be used to forge signatures for certificates that contain the keyEncipherment KeyUsage <del> (RFC5280 section 4.2.1.3) In order to prevent this type of cross- </del> <ins> (RFC5280 section 4.2.1.3).  In order to prevent this type of cross- </ins> protocol attack, we define a new DelegationUsage extension to X.509 that permits use of delegated credentials.  (See certificate- requirements.)


in the system policy.  The valid values for the access network interface kinds are implementation specific. <del> 5.2.10. </del> <ins> 5.2.11. </ins> Type: Enumeration


A serialized authorized key object, base64-encoded.  The "key" field in this object MUST match the client's account key. <del> In response to the challenge, the client MUST parse the authorized key object and verify that its "key" field contains the client's account key.  The client then computes the SHA-256 digest Z of the JSON-encoded authorized key object (without base64-encoding), and encodes Z in hexadecimal form. The client will generate a self-signed certificate with the subjectAlternativeName extension containing the dNSName "<Z[0:32]>.<Z[32:64]>.acme.invalid".  The client will then configure the TLS server at the domain such that when a handshake is initiated with the Server Name Indication extension set to "<Z[0:32]>.<Z[32:64]>.acme.invalid", the generated test certificate is presented. </del> <ins> Number of DVSNI iterations In response to the challenge, the client MUST decode and parse the authorized keys object and verify that it contains exactly one entry, whose "token" and "key" attributes match the token for this challenge and the client's account key.  The client then computes the SHA-256 digest Z0 of the JSON-encoded authorized key object (without base64-encoding), and encodes Z0 in UTF-8 lower-case hexadecimal form.  The client then generates iterated hash values Z1...Z(n-1) as follows: The client generates a self-signed certificate for each iteration of Zi with a single subjectAlternativeName extension dNSName that is "<Zi[0:32]>.<Zi[32:64]>.acme.invalid", where "Zi[0:32]" and "Zi[32:64]" represent the first 32 and last 32 characters of the hex- encoded value, respectively (following the notation used in Python). The client then configures the TLS server at the domain such that when a handshake is initiated with the Server Name Indication extension set to "<Zi[0:32]>.<Zi[32:64]>.acme.invalid", the corresponding generated certificate is presented. </ins> The response to the DVSNI challenge simply acknowledges that the client is ready to fulfill this challenge.


client's control of the domain by verifying that the TLS server was configured appropriately. <del> Compute the Z-value from the authorized key object in the same way as the client. </del> <ins> Choose a subset of the N DVSNI iterations to check, according to local policy. For each iteration, compute the Zi-value from the authorized keys object in the same way as the client. </ins> <del> Open a TLS connection to the domain name being validated on port 443, presenting the value "<Z[0:32]>.<Z[32:64]>.acme.invalid" in the SNI field (where the comparison is case-insensitive). </del> <ins> Open a TLS connection to the domain name being validated on the requested port, presenting the value "<Zi[0:32]>.<Zi[32:64]>.acme.invalid" in the SNI field (where the comparison is case-insensitive). </ins> Verify that the certificate contains a subjectAltName extension <del> with the dNSName of "<Z[0:32]>.<Z[32:64]>.acme.invalid". </del> <ins> with the dNSName of "<Z[0:32]>.<Z[32:64]>.acme.invalid", and that no other dNSName entries of the form "*.acme.invalid" are present in the subjectAltName extension. It is RECOMMENDED that the ACME server verify a random subset of the N iterations with an appropriate sized to ensure that an attacker who can provision certs for a default virtual host, but not for arbitrary simultaneous virtual hosts, cannot pass the challenge.  For instance, testing a subset of 5 of N=25 domains ensures that such an attacker has only a one in 25/5 chance of success if they post certs Zn in random succession.  (This probability is enforced by the requirement that each certificate have only one Zi value.) </ins> It is RECOMMENDED that the ACME server validation TLS connections from multiple vantage points to reduce the risk of DNS hijacking


Change controller: n/a <del> 3.2. </del> <ins> 2.2. The OpenAPI Specification Media Types convey OpenAPI document (OAS) files as defined in oas for version 3.0.0 and above. Those files can be serialized in JSON or yaml.  Since there are multiple OpenAPI Specification versions, those media-types support the "version" parameter. The following examples conveys the desire of a client to receive an OpenAPI Specification resource preferably in the following order: openapi 3.1 in yaml openapi 3.0 in yaml any openapi version in json 2.2.1. The following information serves as the registration form for the "application/openapi+json" media type. </ins> Type name: application


Various HTTP versions have been used for media delivery.  HTTP/1.0, HTTP/1.1 and HTTP/2 are carried over TCP, and TCP's transport <del> behavior is described in tcp-behavior.  HTTP/3 is carried over QUIC, and QUIC's transport behavior is described in quic-behavior. </del> <ins> behavior is described in reliable-behavior.  HTTP/3 is carried over QUIC, and QUIC's transport behavior is described in quic-behavior. </ins> Unreliable media delivery using RTP and other UDP-based protocols is <del> also discussed in ultralow, udp-behavior, and hop-by-hop-encrypt, but it is difficult to give general guidance for these applications.  For instance, when packet loss occurs, the most appropriate response may depend on the type of codec being used. </del> <ins> also discussed in ultralow, unreliable-behavior, and hop-by-hop- encrypt, but it is difficult to give general guidance for these applications.  For instance, when packet loss occurs, the most appropriate response may depend on the type of codec being used. </ins> 3.


identified by "aead_id". The then constructs an , "enc_request", from a binary encoded HTTP <del> request, "request", as follows: </del> <ins> request BINARY, "request", as follows: </ins> Construct a message header, "hdr", by concatenating the values of "key_id", "kem_id", "kdf_id", and "aead_id", as one 8-bit integer


Served DNS Zones" registry for 'resolver.arpa.' with the description "DNS Resolver Special-Use Domain", listing this document as the reference. <ins> 8.2. In accordance with Section 5 of RFC6761, the answers to the following questions are provided relative to this document: Are human users expected to recognize these names as special and use them differently?  In what way? No.  This name is used automatically by DNS stub resolvers running on client devices on behalf of users, and users will never see this name directly. Are writers of application software expected to make their software recognize these names as special and treat them differently?  In what way? No.  There is no use case where a non-DNS application (covered by the next question) would need to use this name. Are writers of name resolution APIs and libraries expected to make their software recognize these names as special and treat them differently?  If so, how? Yes. DNS client implementors are expected to use this name when querying for a resolver's properties instead of records for the name itself.  DNS servers are expected to respond to queries for this name with their own properties instead of checking the matching zone as it would for normal domain names. Are developers of caching domain name servers expected to make their implementations recognize these names as special and treat them differently?  If so, how? Yes. Caching domain name servers should not forward queries for this name to avoid causing validation failures due to IP address mismatch. Are developers of authoritative domain name servers expected to make their implementations recognize these names as special and treat them differently?  If so, how? No.  DDR is designed for use by recursive resolvers.  Theoretically, an authoritative server could choose to support this name if it wants to advertise support for encrypted DNS protocols over plain-text DNS, but that scenario is covered by other work in the IETF DNSOP working group. Does this reserved Special-Use Domain Name have any potential impact on DNS server operators?  If they try to configure their authoritative DNS server as authoritative for this reserved name, will compliant name server software reject it as invalid?  Do DNS server operators need to know about that and understand why?  Even if the name server software doesn't prevent them from using this reserved name, are there other ways that it may not work as expected, of which the DNS server operator should be aware? This name is locally served, and any resolver which supports this name should never forward the query.  DNS server operators should be aware that records for this name will be used by clients to modify the way they connect to their resolvers. How should DNS Registries/Registrars treat requests to register this reserved domain name?  Should such requests be denied? Should such requests be allowed, but only to a specially- designated entity? IANA should hold the registration for this name.  Non-IANA requests to register this name should always be denied by DNS Registries/ Registrars. </ins>


assigned by IANA and MUST NOT appear in the listing of assigned values. <del> 10.5. </del> <ins> 9.4. </ins> This document establishes a registry for HTTP context extension type codes.  The "HTTP Context Close Codes" registry governs a 62-bit


during the lifetime of an ongoing DTLS session then the receiver will be unable to locate the correct security context. <ins> The new ciphertext record format with CID also provides content type encryption and record-layer padding. </ins> 1. The Datagram Transport Layer Security (DTLS) RFC6347 protocol was


9. Please update the "Media Types" registry at <del> https://iana.org/assignments/media-types [1] for the media types </del> <ins> https://iana.org/assignments/media-types [3] for the media types </ins> "application/ohttp-keys" (iana-keys), "message/ohttp-req" (iana-req), and "message/ohttp-res" (iana-res). Please update the "HTTP Problem Types" registry at <del> https://iana.org/assignments/http-problem-types [2] for the types </del> <ins> https://iana.org/assignments/http-problem-types [4] for the types </ins> "date" (iana-problem-date) and "ohttp-key" (iana-problem-ohttp-key). 9.1.


QUIC, and applications ought not to use private keys intended for server authentication as keys for client authentication. <del> Moreover, Transport Services systems MUST NOT automatically fall back </del> <ins> Moreover, Transport Services systems must not automatically fall back </ins> from secure protocols to insecure protocols, or to weaker versions of <del> secure protocols.  For example, if an application requests a specific version of TLS, but the desired version of TLS is not available, its connection will fail.  Applications are thus responsible for implementing security protocol fallback or version fallback by creating multiple Transport Services Connections, if so desired. Alternatively, a Transport Services system MAY allow applications to specify that fallback to a specific other version of a protocol is allowed. </del> <ins> secure protocols (see equivalence).  For example, if an application requests a specific version of TLS, but the desired version of TLS is not available, its connection will fail.  Applications are thus responsible for implementing security protocol fallback or version fallback by creating multiple Transport Services Connections, if so desired.  Alternatively, a Transport Services system MAY allow applications to specify that fallback to a specific other version of a protocol is allowed. </ins>


it wishes to share with the user (e.g., store info, maps, flight status, or entertainment). <ins> "can-extend-session" (optional, boolean): indicates that the URL specified as "user-portal-url" allows the user to extend a session once the client is no longer in a state of captivity.  This provides a hint that a client system can suggest accessing the portal URL to the user when the session is near its limit in terms of time or bytes. </ins> "seconds-remaining" (optional, integer): indicates the number of seconds remaining, after which the client will be placed into a captive state.  The API server SHOULD include this value if the


IP address (IPv4 or IPv6 address): <del> Interface name (string): </del> <ins> Interface name (string), e.g., to qualify link-local or multicast addresses (see ifspec for details): </ins> Note that an IPv6 address specified with a scope (e.g. "2001:db8:4920:e29d:a420:7461:7073:0a%en0") is equivalent to


The best way to obscure an encoding is to appear random to observers, which is most rigorously achieved with encryption. <del> 6.2. </del> <ins> 7.2. </ins> While sufficiently robust connection ID generation schemes will mitigate linkability issues, they do not provide full protection.


4. Servers MUST NOT include MD5 and SHA-1 in ServerKeyExchange messages. <del> 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. </del> <ins> If the client receives a ServerKeyExchange message indicating MD5 or SHA-1, then it MUST abort the connection with an illegal_parameter alert. </ins> 5. Clients MUST NOT include MD5 and SHA-1 in CertificateVerify messages. If a server receives a CertificateVerify message with MD5 or SHA-1 it <del> MUST abort the connection with handshake_failure or insufficient_security alert. </del> <ins> MUST abort the connection with an illegal_parameter alert. </ins> 6.


"connect-udp". For example, if the client is configured with URI template <del> "https://proxy.example.org/{target_host}/{target_port}/" and wishes to open a UDP proxying tunnel to target 192.0.2.42:443, it could send the following request: </del> <ins> "https://proxy.example.org/.well-known/masque/ udp/{target_host}/{target_port}/" and wishes to open a UDP proxying tunnel to target 192.0.2.42:443, it could send the following request: </ins> 3.3.


queries being dropped either maliciously or unintentionally, clients can re-send their SVCB queries periodically. <ins> DoH resolvers that allow discovery using DNS SVCB answers over unencrypted DNS MUST NOT provide differentiated behavior based on the HTTP path alone, since an attacker could modify the "dohpath" parameter. </ins> While the IP address of the Unencrypted Resolver is often provisioned over insecure mechanisms, it can also be provisioned securely, such as via manual configuration, a VPN, or on a network with protections


4.5. <del> In order to be usable for 0-RTT, TLS MUST provide a NewSessionTicket message that contains the "early_data" extension with a max_early_data_size of 0xffffffff; the amount of data which the client can send in 0-RTT is controlled by the "initial_max_data" transport parameter supplied by the server.  A client MUST treat receipt of a NewSessionTicket that contains an "early_data" extension with any other value as a connection error of type PROTOCOL_VIOLATION. </del> <ins> To communicate their willingness to process 0-RTT data, servers send a NewSessionTicket message that contains the "early_data" extension with a max_early_data_size of 0xffffffff; the amount of data which the client can send in 0-RTT is controlled by the "initial_max_data" transport parameter supplied by the server.  Servers MUST NOT send the "early_data" extension with a max_early_data_size set to any value other than 0xffffffff.  A client MUST treat receipt of a NewSessionTicket that contains an "early_data" extension with any other value as a connection error of type PROTOCOL_VIOLATION. </ins> A client that wishes to send 0-RTT packets uses the "early_data" extension in the ClientHello message of a subsequent handshake (see


interaction models in general, the following set of prerequisites MUST be in place to support the implementation of interaction models: <ins> A statement about a distinguishable Attester made by an Endorser without accompanying evidence about its validity, used as proof of identity. </ins> The provenance of Evidence with respect to a distinguishable Attesting Environment MUST be correct and unambiguous. <del> An Attester Identity MAY be a unique identity, it MAY be included in a zero-knowledge proof (ZKP), or it MAY be part of a group signature, or it MAY be a randomised DAA credential DAA. </del> <ins> An Attester Identity MAY be a unique identity, MAY be included in a zero-knowledge proof (ZKP), MAY be part of a group signature, or it MAY be a randomized DAA credential DAA. </ins> Attestation Evidence MUST be authentic. In order to provide proofs of authenticity, Attestation Evidence SHOULD be cryptographically associated with an identity document <del> (e.g. an PKIX certificate or trusted key material, or a randomised </del> <ins> (e.g. an PKIX certificate or trusted key material, or a randomized </ins> DAA credential DAA), or SHOULD include a correct and unambiguous and stable reference to an accessible identity document.


encounter "tripped circuit breakers", with resulting user-visible impacts. <del> 6.2. </del> <ins> 6.3. </ins> For most of the history of the Internet, we have trusted TCP to limit the impact of applications that sent a significant number of packets,


will not result in a SendError separate from the InitiateError signaling the failure of Connection establishment. <ins> 8.2.7. The Transport Services interface provides two properties to allow a sender to signal the relative priority of data transmission: the Priority Message Property msg-priority, and the Connection Priority Connection Property conn-priority.  These properties are designed to allow the expression and implementation of a wide variety of approaches to transmission priority in the transport and application layer, including those which do not appear on the wire (affecting only sender-side transmission scheduling) as well as those that do (e.g.  I-D.ietf-httpbis-priority. A Transport Services system gives no guarantees about how its expression of relative priorities will be realized; for example, if a transport stack that only provides a single in-order reliable stream is selected, prioritization information can only be ignored. However, the Transport Services system will seek to ensure that performance of relatively-prioritized connections and messages is not worse with respect to those connections and messages than an equivalent configuration in which all prioritization properties are left at their defaults. The Transport Services interface does order Connection Priority over the Priority Message Property.  In the absense of other externalities (e.g., transport-layer flow control), a priority 1 Message on a priority 0 Connection will be sent before a priority 0 Message on a priority 1 Connection in the same group. </ins> 8.3. Once a Connection is established, it can be used for receiving data


4. There exists a common set of features shared across the transport <del> protocols surveyed in this document.  The mandatory features should be provided by any transport security protocol, while the optional features are extensions that a subset of the protocols provide.  For clarity, we also distinguish between handshake and record features. </del> <ins> protocols surveyed in this document.  Mandatory features constitute a baseline of functionality that an application may assume for any TAPS implementation.  Optional features by contrast may vary from implementation to implementation, and so an application cannot simply assume they are available.  Applications learn of and use optional features by querying for their presence and support.  Optional features may not be implemented, or may be disabled if their presence impacts transport services or if a necessary transport service is unavailable. </ins> 4.1. <del> 4.1.1. </del> <ins> Segment encryption and authentication: Transit data must be protected with an authenticated encryption algorithm. </ins> <del> Forward-secure segment encryption and authentication: Transit data must be protected with an authenticated encryption algorithm. </del> <ins> Forward-secure key establishment: Negotiated keying material must come from an authenticated, forward-secure key exchange protocol. </ins> Private key interface or injection: Authentication based on public key signatures is commonplace for many transport security


or split-tunnel. In this case, the client does not specify any scope in its request. <del> The server assigns the client an IPv6 address prefix to the client (2001:db8::/64) and a full-tunnel route of all IPv6 addresses (::/0). The client can then send to any IPv6 host using a source address in its assigned prefix. </del> <ins> The server assigns the client an IPv4 address to the client (192.0.2.11) and a full-tunnel route of all IPv4 addresses (0.0.0.0/0).  The client can then send to any IPv4 host using a source address in its assigned prefix. </ins> A setup for a split-tunnel VPN (the case where the client can only access a specific set of private subnets) is quite similar.  In this <del> case, the advertised route is restricted to 2001:db8::/32, rather than ::/0. </del> <ins> case, the advertised route is restricted to 192.0.2.0/24, rather than 0.0.0.0/0. </ins> 6.2.


To properly indicate use of DTLS, the <proto> field MUST be set to "UDP/TLS/RTP/SAVPF", as specified in RFC5764, Section 8, if the default candidate uses UDP transport, or "TCP/DTLS/RTP/SAVPF", as <del> specified in I-D.nandakumar-mmusic-proto-iana-registration if the default candidate uses TCP transport. </del> <ins> specified in RFC7850 if the default candidate uses TCP transport. </ins> If codec preferences have been set for the associated transceiver, media formats MUST be generated in the corresponding order, and


The backend server begins by generating a message ServerHelloECHConf, which is identical in content to a ServerHello message with the exception that ServerHelloECHConf.random is equal to 24 random bytes <del> followed by 8 zero bytes.  It then computes a string where Derive-Secret and Handshake Secret are as specified in RFC8446, Section 7.1, and ClientHelloInner...ServerHelloECHConf refers to the sequence of handshake messages beginning with the first ClientHello and ending with ServerHelloECHConf.  Finally, the backend server constructs its ServerHello message so that it is equal to </del> <ins> followed by 8 zero bytes.  It then computes an 8-byte string where HKDF-Expand-Label and Transcript-Hash are as defined in RFC8446, Section 7.1, "0" indicates a string of Hash.length bytes set to zero, and ClientHelloInner...ServerHelloECHConf refers to the sequence of handshake messages beginning with the first ClientHelloInner and ending with ServerHelloECHConf.  (Note that ClientHelloInner and ServerHelloECHConf messages replace the ClientHello and ServerHello messages in the transcript hash sequence as specified in Section 4.1.1 of RFC8446.  Finally, the backend server constructs its ServerHello message so that it is equal to </ins> ServerHelloECHConf but with the last 8 bytes of ServerHello.random <del> set to the first 8 bytes of accept_confirmation. </del> <ins> set to "accept_confirmation". </ins> The backend server MUST NOT perform this operation if it negotiated TLS 1.2 or below.  Note that doing so would overwrite the downgrade


Because the DNS-SD registration protocol is automatic, and not managed by humans, some additional bookkeeping is required.  When an update is constructed by the SRP requestor, it MUST include an <del> EDNS(0) Update Lease Option I-D.sekar-dns-ul.  The Update Lease Option contains two lease times: the Lease Time and the Key Lease Time. </del> <ins> EDNS(0) Update Lease Option I-D.ietf-dnssd-update-lease.  The Update Lease Option contains two lease times: the Lease Time and the Key Lease Time. </ins> These leases are promises, similar to RFC2131, from the SRP requestor that it will send a new update for the service registration before


the "tree" array divided by two. Construct a new group state using the information in the GroupInfo <del> object.  The new member's position in the tree is "index", as defined above. </del> <ins> object and verify the integrity of the tree using the "tree_hash". The new member's position in the tree is "index", as defined above. </ins> Identify the lowest node at which the direct paths from "index" and "signer_index" overlap.  Set private keys for that node and


Terminology specific to tree computations is described in ratchet- tree-terminology. <ins> 2.1. </ins> We use the TLS presentation language RFC8446 to describe the <del> structure of protocol messages. </del> <ins> structure of protocol messages.  In addition to the base syntax, we add two additional features, the ability for fields to be optional and the ability for vectors to have variable-size length headers. 2.1.1. An optional value is encoded with a presence-signaling octet, followed by the value itself if present.  When decoding, a presence octet with a value other than 0 or 1 MUST be rejected as malformed. 2.1.2. In the TLS presentation language, vectors are encoded as a sequence of encoded elements prefixed with a length.  The length field has a fixed size set by specifying the minimum and maximum lengths of the encoded sequence of elements. In MLS, there are several vectors whose sizes vary over significant ranges.  So instead of using a fixed-size length field, we use a variable-size length using a variable-length integer encoding based on the one in Section 16 of RFC9000.  (They differ only in that the one here requires a minimum-size encoding.)  Instead of presenting min and max values, the vector description simply includes a "V". For example: Such a vector can represent values with length from 0 bytes to 2^62 bytes.  The variable-length integer encoding reserves the two most significant bits of the first byte to encode the base 2 logarithm of the integer encoding length in bytes.  The integer value is encoded on the remaining bits, in network byte order.  The encoded value MUST use the smallest number of bits required to represent the value. When decoding, values using more bits than necessary MUST be treated as malformed. This means that integers are encoded on 1, 2, 4, or 8 bytes and can encode 6-, 14-, 30-, or 62-bit values respectively. For example, the eight-byte sequence c2 19 7c 5e ff 14 e8 8c (in hexadecimal) decodes to the decimal value 151288809941952652; the four byte sequence 9d 7f 3e 7d decodes to 494878333; the two byte sequence 7b bd decodes to 15293; and the single byte 25 decodes to 37 (as does the two byte sequence 40 25). The following figure adapts the pseudocode provided in RFC9000 to add a check for minimum-length encoding: The use of variable-size integers for vector lengths allows vectors to grow very large, up to 2^62 bytes.  Implementations should take care not to allow vectors to overflow available storage.  To facilitate debugging of potential interoperatbility problems, implementations should provide a clear error when such an overflow condition occurs. </ins> 3.


maximum_name_length is greater than 256. A list of extensions that the client can take into consideration <del> when generating a Client Hello message.  The purpose of the field is to provide room for additional features in the future.  The format is defined in RFC8446; Section 4.2.  The same interpretation rules apply: extensions MAY appear in any order, but there MUST NOT be more than one extension of the same type in the extensions block.  An extension may be tagged as mandatory by using an extension type codepoint with the high order bit set to 1.  A client which receives a mandatory extension they do not understand must reject the ECHOConfig content. </del> <ins> when generating a ClientHello message.  The purpose of the field is to provide room for additional functionality in the future. See config-extensions for guidance on what type of extensions are appropriate for this structure. The format is defined in RFC8446, Section 4.2.  The same interpretation rules apply: extensions MAY appear in any order, but there MUST NOT be more than one extension of the same type in the extensions block.  An extension can be tagged as mandatory by using an extension type codepoint with the high order bit set to 1.  A client which receives a mandatory extension they do not understand MUST reject the ECHOConfig content. </ins> Clients MUST parse the extension list and check for unsupported mandatory extensions.  If an unsupported mandatory extension is


3.2.3. <del> The sending client maps the outgoing streams and give them unique indices: 0, 1,.. etc.  As mentioned above SFrame supports up to 16 outgoing stream.  After encoding the frame and before packetizing it, the necessary media metadata will be moved out of the encoded frame buffer, to be used later in the RTP header extension.  The encoded frame, the metadata buffer and the stream index are passed to SFrame encryptor which internally keeps track of the number of frames encrypted so far for that stream.  The encryptor constructs SFrame header using the stream index and frame counter and derive the encryption IV.  The frame is encrypted using the encryption key and the header, encrypted frame and the media metadata are authenticated using the authentication key.  The authentication tag is then truncated (If supported by the cipher suite) and prepended at the end of the ciphertext. </del> <ins> After encoding the frame and before packetizing it, the necessary media metadata will be moved out of the encoded frame buffer, to be used later in the RTP header extension.  The encoded frame and the metadata buffer are passed to SFrame encryptor which internally keeps track of the number of frames encrypted so far.  The encryptor constructs SFrame header using frame counter and key id and derive the encryption IV.  The frame is encrypted using the encryption key and the header, encrypted frame and the media metadata are authenticated using the authentication key.  The authentication tag is then truncated (If supported by the cipher suite) and prepended at the end of the ciphertext. </ins> The encrypted payload is then passed to a generic RTP packetized to construct the RTP packets and encrypts it using SRTP keys for the


the ratchet tree the provisional GroupContext, to update the ratchet tree and generate the "commit_secret": <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, and store "key_package" at the Committer's leaf.


obtained via some other mechanism such as being configured in the Verifier by an administrator. <ins> For example, for some claims the Verifier might check the values of claims in the Evidence against constraints specified in the Appraisal Policy for Evidence.  Such constraints might involve a comparison for equality against reference values, or a check for being in a range bounded by reference values, or membership in a set of reference values, or a check against values in other claims, or any other test. Such reference values might be specified as part of the Appraisal Policy for Evidence itself, or might be obtained from a separate source, such as an Endorsement, and then used by the Appraisal Policy for Evidence.  The actual data format and semantics of a known-good value are specific to claims and implementations.  There is no general purpose format for them or general means for comparison defined in this architecture document.  Similarly, for some claims the Verifier might check the values of claims in the Evidence for membership in a set, or against a range of values, or against known- bad values such as an expiration time.  These reference values may be conveyed to the Verifier as part of an Endorsement or as part of Appraisal Policy or both as these are the two input paths to the Verifier. </ins> The Relying Party uses Attestation Results by applying its own Appraisal Policy to make application-specific decisions such as authorization decisions.  The Attestation Result Appraisal Policy


Applications may need to annotate the Messages they send with extra information to control how data is scheduled and processed by the <del> transport protocols in the Connection.  A messageContext object contains parameters for sending Messages, and can be passed to the </del> <ins> transport protocols in the Connection.  A MessageContext object contains properties for sending Messages, and can be passed to the </ins> Send Action.  Note that these properties are per-Message, not per- Send if partial Messages are sent (send-partial).  All data blocks associated with a single Message share properties.  For example, it


changes under discussion, via issues and pull requests in GitHub current as of the time of writing. <del> 1.1. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </del> 2. In this section, we discusses those aspects of the QUIC transport


9. <ins> RFC7626 discusses DNS Privacy Considerations in both "On the wire" (Section 2.4), and "In the server" (Section 2.5) contexts.  This is also a useful framing for DoH's privacy considerations. 9.1. DoH encrypts DNS traffic and requires authentication of the server. This mitigates both passive surveillance RFC7258 and active attacks that attempt to divert DNS traffic to rogue servers (RFC7626 Section 2.5.1).  DNS over TLS RFC7858 provides similar protections, while direct UDP and TCP based transports are vulnerable to this class of attack. Additionally, the use of the HTTPS default port 443 and the ability to mix DoH traffic with other HTTPS traffic on the same connection can deter unprivileged on-path devices from interfering with DNS operations and make DNS traffic analysis more difficult. 9.2. A DoH implementation is built on IP, TCP, TLS, and HTTP.  Each layer contains one or more common features that can be used to correlate queries to the same identity.  DNS transports will generally carry the same privacy properties of the layers used to implement them. For example, the properties of IP, TCP, and TLS apply to DNS over TLS implementations. The privacy considerations of using the HTTPS layer in DoH are incremental to those of DNS over TLS.  DoH is not known to introduce new concerns beyond those associated with HTTPS. At the IP level, the client address provides obvious correlation information.  This can be mitigated by use of a NAT, proxy, VPN, or simple address rotation over time.  It may be aggravated by use of a DNS server that can correlate real-time addressing information with other personal identifiers, such as when a DNS server and DHCP server are operated by the same entity. TCP-based solutions may seek performance through the use of TCP Fast Open RFC7413.  The cookies used in TCP Fast Open allow servers to correlate TCP sessions together. TLS based implementations often achieve better handshake performance through the use of some form of session resumption mechanism such as session tickets RFC5077.  Session resumption creates trivial mechanisms for a server to correlate TLS connections together. HTTP's feature set can also be used for identification and tracking in a number of different ways.  For example, authentication request header fields explicitly identify profiles in use, and HTTP Cookies are designed as an explicit state tracking mechanism between the client and serving site and often are used as an authentication mechanism. Additionally, the User-Agent and Accept-Language request header fields often convey specific information about the client version or locale.  This facilitates content negotiation and operational work- arounds for implementation bugs.  Request header fields that control caching can expose state information about a subset of the client's history.  Mixing DoH requests with other HTTP requests on the same connection also provides an opportunity for richer data correlation. The DoH protocol design allows applications to fully leverage all the features of the HTTP ecosystem, including features not enumerated here.  Implementations of DoH clients and servers need to consider the benefit and privacy impact of these features, and their deployment context, when deciding whether or not to enable them. Implementations are advised to expose the minimal set of data needed to achieve the desired feature set. Determining whether or not a DoH implementation requires HTTP cookie RFC6265 support is particularly important because HTTP cookies are the primary state tracking mechanism in HTTP.  HTTP Cookies SHOULD NOT be accepted by DOH clients unless they are explicitly required by a use case. 10. </ins> Running DNS over HTTPS relies on the security of the underlying HTTP transport.  This mitigates classic amplification attacks for UDP- based DNS.  Implementations utilizing HTTP/2 benefit from the TLS


direct path of the new node Set the leaf node in the tree at position "index" to a new node <del> containing the public key from the ClientInitKey in the Add corresponding to the ciphersuite in use, as well as the credential under which the ClientInitKey was signed </del> <ins> containing the public key from the ClientInitKey in the Add, as well as the credential under which the ClientInitKey was signed </ins> The "update_secret" resulting from this change is an all-zero octet string of length Hash.length.


ack-eliciting packets, to avoid an expensive consecutive PTO expiration due to a single lost datagram. <del> It is possible that the sender has no new or previously-sent data to send.  As an example, consider the following sequence of events: new </del> <ins> When the PTO timer expires, and there is new or previously sent unacknowledged data, it MUST be sent.  Data that was previously sent with Initial encryption MUST be sent before Handshake data and data previously sent at Handshake encryption MUST be sent before any ApplicationData data. It is possible the sender has no new or previously-sent data to send. As an example, consider the following sequence of events: new </ins> application data is sent in a STREAM frame, deemed lost, then retransmitted in a new packet, and then the original transmission is <del> acknowledged.  In the absence of any new application data, a PTO timer expiration now would find the sender with no new or previously- sent data to send. When there is no data to send, the sender SHOULD send a PING or other ack-eliciting frame in a single packet, re-arming the PTO timer. </del> <ins> acknowledged.  When there is no data to send, the sender SHOULD send a PING or other ack-eliciting frame in a single packet, re-arming the PTO timer. </ins> Alternatively, instead of sending an ack-eliciting packet, the sender MAY mark any packets still in flight as lost.  Doing so avoids


When, and under what circumstances, a reinitialization proposal is allowed. <del> When proposals from external senders are allowed. </del> <ins> When proposals from external senders are allowed and how to authorize those proposals. When external joiners are allowed and how to authorize those external commits. Which other proposal types are allowed. A policy of when members should commit pending proposals in a group. </ins> <del> When external joiners are allowed. </del> <ins> A policy of how to protect and share the GroupInfo objects needed for external joins. </ins> A policy for when two credentials represent the same client.  Note that many credentials may be issued authenticating the same


MLS Signature Labels (mls-signature-labels) <ins> MLS Public Key Encryption Labels (mls-public-key-encryption- labels) </ins> MLS Exporter Labels (mls-exporter-labels) All of these registries should be under a heading of "Messaging Layer


to RTCP.  If more accurate control of bandwidth is needed, "TIAS" should be used instead of "AS". <ins> For any "RR" or "RS" bandwidth values, handle as specified in RFC3556, Section 2. </ins> Any specified "CT" bandwidth value MUST be ignored, as the meaning of this construct at the media level is not well defined. <del> For any "RR" or "RS" bandwidth values, handle as specified in RFC3556, Section 2. </del> [TODO: handling of CN, telephone-event, "red"] If the media section if of type audio:


Internet X.509 Public Key Infrastructure: <del> HTTP security: Section 9 of RFC7230, Section 9 of RFC7231, etc. </del> <ins> HTTP security: Section 11 of RFC9112, Section 17 of RFC9110, etc. </ins> CoAP security:


applications using QUIC, as well. Application developers should note that any fallback they use when <del> QUIC cannot be used due to network blocking of UDP SHOULD guarantee </del> <ins> QUIC cannot be used due to network blocking of UDP should guarantee </ins> the same security properties as QUIC; if this is not possible, the <del> connection SHOULD fail to allow the application to explicitly handle </del> <ins> connection should fail to allow the application to explicitly handle </ins> fallback to a less-secure alternative.  See fallback. 14.


max_datagram_frame_size <del> Indicates that the connection should enable support for unreliable DATAGRAM frames.  An endpoint that advertises this transport parameter can receive datagrams frames from the other endpoint, up to and including the length in bytes provided in the transport parameter. </del> <ins> A non-zero value indicates that the endpoint supports receiving unreliable DATAGRAM frames.  An endpoint that advertises this transport parameter can receive DATAGRAM frames from the other endpoint, up to and including the length in bytes provided in the transport parameter.  The default value is 0. </ins> This document also registers a new value in the QUIC Frame Type registry:


The "return_routability_check" message MUST be authenticated and encrypted using the currently active security context. <del> The receiver that observes the peer's address and or port update MUST </del> <ins> 5. The receiver that observes the peer's address or port update MUST </ins> stop sending any buffered application data (or limit the data sent to <del> a TBD threshold) and initiate the return routability check that proceeds as follows: </del> <ins> the unvalidated address to the anti-amplification limit) and initiate the return routability check that proceeds as follows: </ins> <del> A cookie is placed in a "return_routability_check" message of type path_challenge; </del> <ins> An unpredictable cookie is placed in a "return_routability_check" message of type path_challenge; </ins> <del> The message is sent to the observed new address and a timeout T is started; </del> <ins> The message is sent to the observed new address and a timer T (see timer-choice) is started; </ins> The peer endpoint, after successfully verifying the received <del> "return_routability_check" message echoes the cookie value in a "return_routability_check" message of type path_response; </del> <ins> "return_routability_check" message responds by echoing the cookie value in a "return_routability_check" message of type path_response; </ins> When the initiator receives and verifies the "return_routability_check" message contains the sent cookie, it


This document registers one new ND option type under the sub-registry "IPv6 Neighbor Discovery Option Formats": <del> Resource Directory address Option (38) </del> <ins> Resource Directory Address Option (38) </ins> 9.3.


ECHClientHello.config_id since it can be used as a tracking vector. In such cases, the second method should be used for matching the ECHClientHello to a known ECHConfig.  See optional-configs.  Unless <del> specified by the application using (D)TLS or externally configured, implementations MUST use the first method. </del> <ins> specified by the application profile or otherwise externally configured, implementations MUST use the first method. </ins> The server then iterates over the candidate ECHConfig values, attempting to decrypt the "encrypted_client_hello" extension:


MTUs can vary.  TODO: Describe how the path MTU can be computed, specifically propagation across HTTP proxies. <ins> 4.5. In WebTransport over HTTP/3, the client MAY send its SETTINGS frame, as well as multiple WebTransport CONNECT requests, WebTransport data streams and WebTransport datagrams, all within a single flight.  As those can arrive out of order, a WebTransport server could be put into a situation where it receives a stream or a datagram without a corresponding session.  Similarly, a client may receive a server- initiated stream or a datagram before receiving the CONNECT response headers from the server. To handle this case, WebTransport endpoints SHOULD buffer streams and datagrams until those can be associated with an established session. To avoid resource exhaustion, the endpoints MUST limit the number of buffered streams and datagrams.  When the number of buffered streams is exceeded, a stream SHALL be closed by sending a RESET_STREAM and/ or STOP_SENDING with the "H3_WEBTRANSPORT_BUFFERED_STREAM_REJECTED" error code.  When the number of buffered datagrams is exceeded, a datagram SHALL be dropped.  It is up to an implementation to choose what stream or datagram to discard. </ins> 5. An WebTransport session over HTTP/3 is terminated when either


Compute a COSE_Encrypt0 object as defined in Sections 5.2 and 5.3 of I-D.ietf-cose-rfc8152bis-struct, with the EDHOC AEAD algorithm of the selected cipher suite, using the encryption key K_3, the <del> initialization vector IV_3, the plaintext P, and the following parameters as input (see COSE): </del> <ins> initialization vector IV_3, the plaintext PLAINTEXT_3, and the following parameters as input (see COSE): </ins> protected = h''


A hash function <del> A Diffie-Hellman finite-field group or elliptic curve group </del> <ins> A key encapsulation mechanism (KEM) </ins> An AEAD encryption algorithm A signature algorithm <del> The ciphersuite's Diffie-Hellman group is used to instantiate an HPKE I-D.irtf-cfrg-hpke instance for the purpose of public-key encryption. The ciphersuite must specify an algorithm "Derive-Key-Pair" that maps octet strings with length Hash.length to HPKE key pairs. </del> <ins> The ciphersuite's KEM used to instantiate an HPKE I-D.irtf-cfrg-hpke instance for the purpose of public-key encryption.  Each ciphersuite has a "Derive-Key-Pair" function that maps octet strings of length "Nsk" (a KEM-specific constant defined by HPKE) to HPKE key pairs. This function is defined to be HPKE's "DeriveKeyPair" function. </ins> Ciphersuites are represented with the CipherSuite type.  HPKE public <del> keys are opaque values in a format defined by the underlying Diffie- Hellman protocol (see the Ciphersuites section of the HPKE specification for more information). </del> <ins> keys are opaque values in a format defined by the underlying protocol (see the Cryptographic Dependencies section of the HPKE specification for more information). </ins> The signature algorithm specified in the ciphersuite is the mandatory algorithm to be used for signatures in MLSPlaintext and the tree


Endpoint and group lookups result in links to the selected registration resource and group resources.  Endpoint registration resources are annotated with their endpoint names (ep), domains (d, <del> if present), context (con), endpoint type (et, if present) and lifetime (lt, if present).  Additional endpoint attributes are added as link attributes to their endpoint link unless their specification says otherwise.  Group resources are annotated with their group names (gp), domain (d, if present) and multicast address (con, if present). </del> <ins> if present), context (con) and lifetime (lt, if present).  Additional endpoint attributes are added as link attributes to their endpoint link unless their specification says otherwise.  Group resources are annotated with their group names (gp), domain (d, if present) and multicast address (con, if present). </ins> While Endpoint Lookup does expose the registration resources, the RD does not need to make them accessible to clients.  Clients SHOULD NOT


2.3. <del> The cTLS handshake framing is same as the TLS 1.3 handshake framing, except for two changes: The length field is omitted. The HelloRetryRequest message is a true handshake message instead of a specialization of ServerHello. </del> <ins> When "template.handshakeFraming" is not "true", cTLS uses a custom handshake framing that saves space by relying on the record layer for message lengths.  (This saves 3 bytes per message compared to TLS, or 9 bytes compared to DTLS.)  This compact framing is defined by the "CTLSHandshake" and "CTLSDatagramHandshake" structs. Any handshake type registered in the IANA TLS HandshakeType Registry can be conveyed in a "CTLS[Datagram]Handshake", but not all messages are actually allowed on a given connection.  This definition shows the messages types supported in "CTLSHandshake" as of TLS 1.3 and DTLS 1.3, but any future message types are also permitted. Each "CTLSHandshake" or "CTLSDatagramHandshake" MUST be conveyed as a single "CTLSClientPlaintext.fragment", "CTLSServerPlaintext.fragment", or "CTLSCiphertext.encrypted_record", and is therefore limited to a maximum length of "2^16-1" or less. When operating over UDP, large "CTLSDatagramHandshake" messages will also require the use of IP fragmentation, which is sometimes undesirable.  Operators can avoid these concerns by setting "template.handshakeFraming = true". </ins> 3. <del> In general, we retain the basic structure of each individual TLS handshake message.  However, the following handshake messages have been modified for space reduction and cleaned up to remove pre-TLS 1.3 baggage. </del> <ins> In general, we retain the basic structure of each individual TLS or DTLS handshake message.  However, the following handshake messages have been modified for space reduction and cleaned up to remove pre- TLS 1.3 baggage. </ins> 3.1. The cTLS ClientHello is defined as follows. <del> The "profile_id" field MUST identify the profile that is in use.  A zero-length ID corresponds to the cTLS default protocol. </del> 3.2. We redefine ServerHello in the following way. 3.3. <del> The HelloRetryRequest has the following format. </del> <ins> In cTLS, the HelloRetryRequest message is a true handshake message instead of a specialization of ServerHello.  The HelloRetryRequest has the following format. </ins> The HelloRetryRequest is the same as the ServerHello above but without the unnecessary sentinel Random value.


connection must be authenticated before any data is sent to said party. <del> Source validation: Source validation must be provided to mitigate server-targeted DoS attacks.  This can be done with puzzles or cookies. 4.1.2. Pre-shared key support: A record protocol must be able to use a pre-shared key established out-of-band to encrypt individual messages, packets, or datagrams. </del> <ins> Pre-shared key support: A security protocol must be able to use a pre-shared key established out-of-band or from a prior session to encrypt individual messages, packets, or datagrams. </ins> 4.2. <del> 4.2.1. </del> Mutual authentication: Transport security protocols must allow each endpoint to authenticate the other if required by the application. <ins> Transport dependency: None. Application dependency: Mutual authentication required for application support. Connection mobility: Sessions should not be bound to a network connection (or 5-tuple).  This allows cryptographic key material and other state information to be reused in the event of a connection change.  Examples of this include a NAT rebinding that occurs without a client's knowledge. Transport dependency: Connections are unreliable or can change due to unpredictable network events, e.g., NAT re-bindings. Application dependency: None. Source validation: Source validation must be provided to mitigate server-targeted DoS attacks.  This can be done with puzzles or cookies. Transport dependency: Packets may arrive as datagrams instead of streams from unauthenticated sources. Application dependency: None. </ins> Application-layer feature negotiation: The type of application using a transport security protocol often requires features configured at the connection establishment layer, e.g., ALPN


<del> Privacy Pass: The Protocol draft-davidson-pp-protocol-latest </del> <ins> Privacy Pass Protocol Specification draft-ietf-privacypass-protocol-latest </ins> Abstract


that supports this extension if the extension is received when the transport is not QUIC. <ins> Negotiating the quic_transport_parameters extension causes the EndOfEarlyData to be removed; see remove-eoed. </ins> 8.3. The TLS EndOfEarlyData message is not used with QUIC.  QUIC does not


5.2. <del> Upon receiving an "encrypted_server_name" extension, the server MUST first perform the following checks: </del> <ins> Upon receiving an "encrypted_server_name" extension, the client- facing server MUST first perform the following checks: </ins> If it is unable to negotiate TLS 1.3 or greater, it MUST abort the connection with a "handshake_failure" alert.


used later as described in private-finalize.  The Client then generates an HTTP POST request to send to the Issuer, with the TokenRequest as the body.  The media type for this request is <del> "message/token-request".  An example request is shown below. </del> <ins> "application/private-token-request".  An example request is shown below. </ins> Upon receipt of the request, the Issuer validates the following conditions:


No supported codec is present in the offer. <del> The bundle policy is "max-bundle", the m= section is not in a bundle group, and this is not the first m= section. </del> <ins> The bundle policy is "max-bundle", and this is not the first m= section or in the same bundle group as the first m= section. </ins> <del> The bundle policy is "balanced", the m= section is not in a bundle group, and this is not the first m= section for this media type. </del> <ins> The bundle policy is "balanced", and this is not the first m= section for this media type or in the same bundle group as the first m= section for this media type. </ins> The RTP/RTCP multiplexing policy is "require" and the m= section doesn't contain an "a=rtcp-mux" attribute.


4.2.2. To provide forward secrecy in an even more efficient way than re- <del> running EDHOC, EDHOC provides the function EDHOC-KeyUpdate.  When EDHOC-KeyUpdate is called, the old PRK_out is deleted and the new PRK_out is calculated as a "hash" of the old key using the Expand function as illustrated by the following pseudocode: </del> <ins> running EDHOC, EDHOC provides the optional function EDHOC-KeyUpdate. When EDHOC-KeyUpdate is called, a new PRK_out is calculated as a "hash" of the old PRK_out using the Expand function as illustrated by the following pseudocode.  The change of PRK_out causes a change to PRK_exporter and derived keys using EDHOC-Exporter. </ins> where hash_length denotes the output size in bytes of the EDHOC hash algorithm of the selected cipher suite.


The key and nonce provided to the AEAD are computed as the KDF of the first "KDF.Nh" bytes of the ciphertext generated in the previous section.  If the length of the ciphertext is less than "KDF.Nh", the <del> whole ciphertext is used without padding.  In pseudocode, the key and nonce are derived as: </del> <ins> whole ciphertext is used.  In pseudocode, the key and nonce are derived as: </ins> The Additional Authenticated Data (AAD) for the SenderData ciphertext is the first three fields of MLSCiphertext:


Upon receiving the ROUTE_ADVERTISEMENT capsule, an endpoint MAY start routing IP packets in that prefix to its peer. <ins> If an endpoint receives multiple ROUTE_ADVERTISEMENT capsules, all of the advertised routes can be used.  For example, multiple ROUTE_ADVERTISEMENT capsules are necessary to provide routing to both IPv4 and IPv6 hosts.  Routes are removed using ROUTE_WITHDRAWAL capsules. </ins> 4.2.4. The ROUTE_WITHDRAWAL capsule allows an endpoint to communicate to its


section 4.3.  For simplicity, if both RTX and FEC are supported, the FEC SSRC MUST be the same as the RTX SSRC. <del> [OPEN ISSUE: Handling of a=imageattr] </del> If a data channel m= section has been offered, a m= section MUST also be generated for data.  The <media> field MUST be set to "application" and the <proto> field MUST be set to exactly match the


A secondary use case is web applications that want to access DNS information.  Standardizing an HTTPS mechanism allows this to be done <del> in a way consistent with the cross-origin resource sharing CORS security model of the web and also integrate the caching mechanisms of DNS with those of HTTP.  These applications may be interested in </del> <ins> in a way consistent with the cross-origin resource sharing security model of the web CORS and also integrate the caching mechanisms of DNS with those of HTTP.  These applications may be interested in </ins> using a different media type than traditional clients. <del> [ This paragraph is to be removed when this document is published as an RFC ] Note that these use cases are different than those in a </del> <ins> [[ This paragraph is to be removed when this document is published as an RFC ]] Note that these use cases are different than those in a </ins> similar protocol described at I-D.ietf-dnsop-dns-wireformat-http. The use case for that protocol is proxying DNS queries over HTTP instead of over DNS itself.  The use cases in this document all


indicate that the client configuration used to construct the request is incorrect or out of date. <ins> 5.3. The problem type PROBLEM of "https://iana.org/assignments/http- problem-types#ohttp-key" is defined.  An MAY use this problem type in a response to indicate that an used an outdated or incorrect . fig-key-problem shows an example response in HTTP/1.1 format. As this response cannot be encrypted, it might not reach the .  A cannot rely on the using this problem type.  A might also be configured to disregard responses that are not encapsulated on the basis that they might be subject to observation or modification by an .  A might manage the risk of an outdated using a heuristic approach whereby it periodically refreshes its if it receives a response with an error status code that has not been encapsulated. </ins> 6. In this design, a wishes to make a request of a server that is


3- Authentication key to authenticate the encrypted frame and the media metadata <del> The IV is 128 bits long and calculated from the SRC and CTR field of the Frame header: </del> <ins> The IV is 128 bits long and calculated from the CTR field of the Frame header: </ins> 3.2.2.


assumed to be implicitly reset. After sending a CONNECTION_CLOSE frame, an endpoint immediately <del> enters the closing state. </del> <ins> enters the closing state; see closing.  After receiving a CONNECTION_CLOSE frame, endpoints enter the draining state; see draining. </ins> <del> During the closing period, an endpoint that sends a CONNECTION_CLOSE frame SHOULD respond to any incoming packet that can be decrypted with another packet containing a CONNECTION_CLOSE frame.  Such an endpoint SHOULD limit the number of packets it generates containing a CONNECTION_CLOSE frame.  For instance, an endpoint could wait for a </del> <ins> An immediate close can be used after an application protocol has arranged to close a connection.  This might be after the application protocol negotiates a graceful shutdown.  The application protocol can exchange messages that are needed for both application endpoints to agree that the connection can be closed, after which the application requests that QUIC close the connection.  When QUIC consequently closes the connection, a CONNECTION_CLOSE frame with an application-supplied error code will be used to signal closure to the peer. The closing and draining connection states exist to ensure that connections close cleanly and that delayed or reordered packets are properly discarded.  These states SHOULD persist for at least three times the current Probe Timeout (PTO) interval as defined in QUIC- RECOVERY. Disposing of connection state prior to exiting the closing or draining state could cause could result in an endpoint generating a stateless reset unnecessarily when it receives a late-arriving packet.  Endpoints that have some alternative means to ensure that late-arriving packets do not induce a response, such as those that are able to close the UDP socket, MAY end these states earlier to allow for faster resource recovery.  Servers that retain an open socket for accepting new connections SHOULD NOT end the closing or draining states early. Once its closing or draining state ends, an endpoint SHOULD discard all connection state.  The endpoint MAY send a stateless reset in response to any further incoming packets belonging to this connection. 10.2.1. An endpoint enters the closing state after initiating an immediate close. In the closing state, an endpoint retains only enough information to generate a packet containing a CONNECTION_CLOSE frame and to identify packets as belonging to the connection.  An endpoint in the closing state sends a packet containing a CONNECTION_CLOSE frame in response to any incoming packet that it attributes to the connection. An endpoint SHOULD limit the rate at which it generates packets in the closing state.  For instance, an endpoint could wait for a </ins> progressively increasing number of received packets or amount of time <del> before responding to a received packet. An endpoint is allowed to drop the packet protection keys when entering the closing period (draining) and send a packet containing a CONNECTION_CLOSE in response to any UDP datagram that is received. However, an endpoint without the packet protection keys cannot identify and discard invalid packets.  To avoid creating an unwitting amplification attack, such endpoints MUST limit the cumulative size of packets containing a CONNECTION_CLOSE frame to 3 times the cumulative size of the packets that cause those packets to be sent. To minimize the state that an endpoint maintains for a closing connection, endpoints MAY send the exact same packet. </del> <ins> before responding to received packets. An endpoint's selected connection ID and the QUIC version are sufficient information to identify packets for a closing connection; the endpoint MAY discard all other connection state.  An endpoint that is closing is not required to process any received frame.  An endpoint MAY retain packet protection keys for incoming packets to allow it to read and process a CONNECTION_CLOSE frame. An endpoint MAY drop packet protection keys when entering the closing state and send a packet containing a CONNECTION_CLOSE frame in response to any UDP datagram that is received.  However, an endpoint that discards packet protection keys cannot identify and discard invalid packets.  To avoid being used for an amplication attack, such endpoints MUST limit the cumulative size of packets it sends to three times the cumulative size of the packets that are received and attributed to the connection.  To minimize the state that an endpoint maintains for a closing connection, endpoints MAY send the exact same packet in response to any received packet. </ins> Allowing retransmission of a closing packet is an exception to the requirement that a new packet number be used for each packet in


meaning that the server is not willing to receive any WebTransport sessions. <ins> Because WebTransport over HTTP/3 requires support for HTTP/3 datagrams and the Capsule Protocol, both the client and the server MUST indicate support for HTTP/3 datagrams by sending a SETTINGS_H3_DATAGRAM value set to 1 in their SETTINGS frame (see Section 2.1.1 of HTTP-DATAGRAM). WebTransport over HTTP/3 also requires support for QUIC datagrams. To indicate support, both the client and the server MUST send a max_datagram_frame_size transport parameter with a value greater than 0 (see Section 3 of QUIC-DATAGRAM). </ins> 3.2. RFC8441 defines an extended CONNECT method in Section 4, enabled by


packets in response to Initial packets that don't include a valid token. <del> Both server and service must have access to Universal time, though tight synchronization is unnecessary. </del> <ins> Both server and service must have time synchronized with respect to one another to prevent tokens being incorrectly marked as expired, though tight synchronization is unnecessary. </ins> The tokens are protected using AES128-GCM AEAD, as explained in token-protection-with-aead.  All tokens, generated by either the


information that does not reveal information about the encapsulated response. <del> An Oblivious Gateway Resource acts as a gateway for requests to the Target Resource (see HTTP).  The one exception is that any information it might forward in a response MUST be encapsulated, unless it is responding to errors it detects before removing encapsulation of the request; see errors. </del> In order to achieve the privacy and security goals of the protocol an Oblivious Gateway Resource also needs to observe the guidance in server-responsibilities.


13.2. Endpoints acknowledge all packets they receive and process.  However, <del> only ack-eliciting packets (see QUIC-RECOVERY) trigger the sending of an ACK frame.  Packets that are not ack-eliciting are only </del> <ins> only ack-eliciting packets cause an ACK frame to be sent within the maximum ack delay.  Packets that are not ack-eliciting are only </ins> acknowledged when an ACK frame is sent for other reasons. When sending a packet for any reason, an endpoint should attempt to


endpoint that receives packets for routes it has rejected MUST NOT treat that as an error. <ins> ROUTE_ADVERTISEMENT and ROUTE_WITHDRAWAL capsules are applied in order of receipt: if a prefix is covered by multiple received ROUTE_ADVERTISEMENT and/or ROUTE_WITHDRAWAL capsules, only the last received capsule applies as it supersedes prior ROUTE_ADVERTISEMENT and ROUTE_WITHDRAWAL capsules for this prefix. </ins> 5. IP packets are sent using HTTP Datagrams I-D.ietf-masque-h3-datagram.


successful connection to the Alternative-Address inherits all the security properties of the current connection. <del> SNI vs. Default-Uri-Host: Any security negotiated in the TLS handshake is for the SNI name exchanged in the TLS handshake and checked against the certificate provided by the server.  The Default-Uri-Host Option cannot be used to extend these security properties to the additional server name. </del> 9. 9.1.


The application server requests the delivery of receipts from the push server by making a HTTP GET request to the receipt subscription resource.  The push service does not respond to this request, it <del> instead uses I-D.ietf-httpbis-http2 to send push receipts when messages are acknowledged (acknowledge_message) by the user agent. </del> <ins> instead uses RFC7540 to send push receipts when messages are acknowledged (acknowledge_message) by the user agent. </ins> Each receipt is pushed in response to a synthesized GET request.  The GET request is made to the same push message resource that was


2. This document uses the following set of terms, roles, and concepts as <del> defined in I-D.ietf-rats-architecture: Attester, Verifier, Relying Party, Conceptual Message, Evidence, Endorsement, Attestation Result, Appraisal Policy, Attesting Environment, Target Environment </del> <ins> defined in I-D.ietf-rats-architecture: Attester, Verifier, Relying Party, Conceptual Message, Evidence, Endorsement, Attestation Result, Appraisal Policy, Attesting Environment, Target Environment </ins> A PKIX Certificate is an X.509v3 format certificate as specified by RFC5280.


The security model takes the following form: <del> A server is created that runs "PP_Server_Setup" and broadcasts the </del> <ins> A server is created that runs "ServerSetup" and broadcasts the </ins> "ServerUpdate" message "s_update". <del> The adversary runs "PP_Client_Setup" on "s_update". </del> <ins> The adversary runs "ClientSetup" on "s_update". </ins> The adversary specifies a number "Q" of issuance phases to initiate with the server, where each phase "i in 1..Q" consists of


Retransmission and deduplication of messages is provided by the TCP/ TLS protocol. <del> Since the TCP protocol provides ordered delivery of messages, the mechanism for reordering detection when RFC7641 is not needed.  The value of the Observe Option in notifications MAY be empty on transmission and MUST be ignored on reception. </del> 3. CoAP over WebSockets can be used in a number of configurations.  The


Characters in the String Value are encoded using a definite length text string (type 3).  Octets in the Data Value are encoded using <del> a definite length byte string (type 2) . </del> <ins> a definite length byte string (type 2). </ins> <del> For compactness, the CBOR representation uses integers for the map keys defined in tbl-cbor-labels.  This table is conclusive, i.e., there is no intention to define any additional integer map keys; any extensions will use string map keys.  This allows translators converting between CBOR and JSON representations to convert also all future labels without needing to update implementations. </del> <ins> For compactness, the CBOR representation uses integers for the labels, as defined in tbl-cbor-labels.  This table is conclusive, i.e., there is no intention to define any additional integer map keys; any extensions will use string map keys.  This allows translators converting between CBOR and JSON representations to convert also all future labels without needing to update implementations. </ins> For streaming SensML in CBOR representation, the array containing <del> the records SHOULD be an CBOR indefinite length array while for non streaming SenML, a definite length array MUST be used. </del> <ins> the records SHOULD be a CBOR indefinite length array while for non-streaming SenML, a definite length array MUST be used. </ins> The following example shows a dump of the CBOR example for the same sensor measurement as in co-ex.


QUIC QUIC has numerous extension points, including the version number that occupies the second through fifth bytes of every long header <del> (see RFC8999).  If experimental versions are rare, and QUIC version 1 constitutes the vast majority of QUIC traffic, there is the potential for middleboxes to ossify on the version bytes always being </del> <ins> (see QUIC-INVARIANTS).  If experimental versions are rare, and QUIC version 1 constitutes the vast majority of QUIC traffic, there is the potential for middleboxes to ossify on the version bytes always being </ins> 0x00000001. <del> Furthermore, version 1 Initial packets are encrypted with keys derived from a universally known salt, which allow observers to inspect the contents of these packets, which include the TLS Client Hello and Server Hello messages.  Again, middleboxes may ossify on </del> <ins> In QUIC version 1, Initial packets are encrypted with the version- specific salt as described in Section 5.2 of QUIC-TLS.  Protecting Initial packets in this way allows observers to inspect their contents, which includes the TLS Client Hello or Server Hello messages.  Again, there is the potential for middleboxes to ossify on </ins> the version 1 key derivation and packet formats. Finally QUIC-VN provides two mechanisms for endpoints to negotiate


This contains a pointer to the public specification for the field if one exists <del> This registry will be initially populated by the values in COSE_KEY_PARAM_KEYS.  The specification column for all of these entries will be this document. </del> <ins> This registry will be initially populated by the values in --Multiple Tables--.  The specification column for all of these entries will be this document. </ins> 15.8.


not specify how protocols add security with TLS; how to initiate TLS handshaking and how to interpret the authentication certificates exchanged are left to the judgment of the designers and implementors <del> of protocols that run on top of TLS. </del> <ins> of protocols that run on top of TLS.  Application protocols using TLS MUST specify how TLS works with their application protocol, including how and when handshaking occurs, and how to do identity verification. I-D.ietf-uta-rfc6125bis provides useful guidance on integrating TLS with applicaiton protocols. </ins> This document defines TLS version 1.3.  While TLS 1.3 is not directly compatible with previous versions, all versions of TLS incorporate a


"index-wild-selector", "filter-selector", or "list-selector" acting on objects or arrays, or a "slice-selector" acting on arrays. <del> Note that there is no "bald" descendant selector "..". </del> <ins> Note that there is no "bald" descendant selector (".." on its own). </ins> 3.5.7.2. <del> The "descendant-selector" selects certain descendants of a node: </del> <ins> A "descendant-selector" selects certain descendants of a node: </ins> the "..<name>" form (and the "..[<index>]" form where "<index>" is a "quoted-member-name") selects those descendants that are member


enc-request. request describes the process for constructing and processing an Encapsulated Request. <ins> The Nenc parameter corresponding to the HpkeKdfId can be found in HPKE. </ins> Responses are bound to responses and so consist only of AEAD- protected content.  response describes the process for constructing and processing an Encapsulated Response.


"HTTP fields"; see Sections RFC9110 and RFC9110 of RFC9110.  For a listing of registered HTTP fields, see the "Hypertext Transfer Protocol (HTTP) Field Name Registry" maintained at <del> <https://www.iana.org/assignments/http-fields/>. </del> <ins> <https://www.iana.org/assignments/http-fields/>.  Like HTTP/2, HTTP/3 has additional considerations related to the use of characters in field names, the Connection header field, and pseudo-header fields. </ins> Field names are strings containing a subset of ASCII characters. Properties of HTTP field names and values are discussed in more <del> detail in RFC9110.  As in HTTP/2, characters in field names MUST be converted to lowercase prior to their encoding.  A request or response containing uppercase characters in field names MUST be treated as . </del> <ins> detail in RFC9110.  Characters in field names MUST be converted to lowercase prior to their encoding.  A request or response containing uppercase characters in field names MUST be treated as . </ins> <del> Like HTTP/2, HTTP/3 does not use the Connection header field to indicate connection-specific fields; in this protocol, connection- specific metadata is conveyed by other means.  An endpoint MUST NOT generate an HTTP/3 field section containing connection-specific fields; any message containing connection-specific fields MUST be treated as . </del> <ins> HTTP/3 does not use the Connection header field to indicate connection-specific fields; in this protocol, connection-specific metadata is conveyed by other means.  An endpoint MUST NOT generate an HTTP/3 field section containing connection-specific fields; any message containing connection-specific fields MUST be treated as . </ins> The only exception to this is the TE header field, which MAY be present in an HTTP/3 request header; when it is, it MUST NOT contain


Exporters Labels marked as "Yes" are those allocated via Standards Track RFCs.  Exporter Labels marked as "No" are not. <ins> If an item is not marked as recommended it does not necessarily mean that it is flawed; rather, it indicates that either the item has not been through the IETF consensus process, has limited applicability, or is intended only for specific use cases. </ins> IANA [SHALL update/has updated] the reference for this registry to also refer to this document.


mechanism for DNS clients to use DNS records to discover a resolver's encrypted DNS configuration.  This mechanism can be used to move from unencrypted DNS to encrypted DNS when only the IP address of a <del> resolver is known.  It can also be used to discover support for encrypted DNS protocols when the name of an encrypted resolver is known.  This mechanism is designed to be limited to cases where unencrypted resolvers and their designated resolvers are operated by the same entity or cooperating entities. </del> <ins> resolver is known.  This mechanism is designed to be limited to cases where unencrypted resolvers and their designated resolvers are operated by the same entity or cooperating entities.  It can also be used to discover support for encrypted DNS protocols when the name of an encrypted resolver is known. </ins> 1.


1. <del> RFC5280 specifies several extended key purpose identifiers for X.509 certificates.  In addition, several extended key purpose identifiers were addedRFC7299 as public OIDs under the IANA PKIX Extended key purpose identifiers arc.  While usage of the any extended key usage value is bad practice for publicly trusted certificates, there is no public and general extended key purpose identifier explicitly assigned for Document Signing certificates.  The current practice is to use id-kp-emailProtection, id-kp-codeSigning or vendor defined Object IDs for general document signing purposes. </del> <ins> RFC5280 specifies several extended key usages for X.509 certificates. In addition, several extended key usage had been addedRFC7299 as public OID under the IANA repository.  While usage of any extended key usage is bad practice for publicly trusted certificates, there are no public and general extended key usage explicitly assigned for Document Signing certificates.  The current practice is to use id-kp- emailProtection, id-kp-codeSigning or vendor defined Object ID for general document signing purposes. </ins> In circumstances where code signing and S/MIME certificates are also widely used for document signing, the technical or policy changes


After this point, any pending send operation is resumed to the bound peer address. <del> 5. </del> <ins> path-challenge-reqs and path-response-reqs contain the requirements for the initiator and responder roles, broken down per protocol phase. 5.1. The initiator MAY send multiple "return_routability_check" messages of type path_challenge to cater for packet loss on the probed path. Each path_challenge SHOULD go into different transport packets. (Note that the DTLS implementation may not have control over the packetization done by the transport layer.) The transmission of subsequent path_challenge messages SHOULD be paced to decrease the chance of loss. Each path_challenge message MUST contain random data. The initiator MAY use padding using the record padding mechanism available in DTLS 1.3 (and in DTLS 1.2, when CID is enabled on the sending direction) up to the anti-amplification limit to probe if the path MTU (PMTU) for the new path is still acceptable. 5.2. The responder MUST NOT delay sending an elicited path_response message. The responder MUST send exactly one path_response messages for each received path_request. The responder MUST send the path_response on the network path where the corresponding path_challenge has been received, so that validation succeeds only if the path is functional in both directions. The initiator MUST NOT enforce this behaviour The initiator MUST silently discard any invalid path_response it receives. Note that RRC does not cater for PMTU discovery on the reverse path. If the responder wants to do PMTU discovery using RRC, it should initiate a new path validation procedure. 5.3. When setting T, implementations are cautioned that the new path could have a longer round-trip time (RTT) than the original. In settings where there is external information about the RTT of the active path, implementations SHOULD use T = 3xRTT. If an implementation has no way to obtain information regarding the RTT of the active path, a value of 1s SHOULD be used. Profiles for specific deployment environments - for example, constrained networks I-D.ietf-uta-tls13-iot-profile - MAY specify a different, more suitable value. 6. </ins> The example TLS 1.3 handshake shown in fig-handshake shows a client and a server negotiating the support for CID and for the RRC


When sending ClientHello, the client first computes ClientHelloInner, including any PSK binders, and then MAY substitute extensions which it knows will be duplicated in ClientHelloOuter.  To do so, the <del> client computes a hash of the entire ClientHelloInner message with the same hash as for the KDF used to encrypt ClientHelloInner.  Then, the client removes and replaces extensions from ClientHelloInner with a single "outer_extensions" extension.  The list of "outer_extensions" include those which were removed from </del> <ins> client computes a hash of the entire ClientHelloInner message as: where "inner" is the ClientHelloInner structure and "Extract", "Expand", and "Nh" are as defined by the KDF API in I-D.irtf-cfrg- hpke.  Then, the client removes and replaces extensions from ClientHelloInner with a single "outer_extensions" extension.  The list of "outer_extensions" include those which were removed from </ins> ClientHelloInner, in the order in which they were removed.  The hash contains the full ClientHelloInner hash computed above.


if they define semantics for such HTTP Datagrams and negotiate mutual support. <ins> 3.1. Implementations of HTTP/3 that support HTTP Datagrams can indicate that to their peer by sending the H3_DATAGRAM SETTINGS parameter with a value of 1.  The value of the H3_DATAGRAM SETTINGS parameter MUST be either 0 or 1.  A value of 0 indicates that HTTP Datagrams are not supported.  An endpoint that receives the H3_DATAGRAM SETTINGS parameter with a value that is neither 0 or 1 MUST terminate the connection with error H3_SETTINGS_ERROR. Endpoints MUST NOT send QUIC DATAGRAM frames until they have both sent and received the H3_DATAGRAM SETTINGS parameter with a value of 1. When clients use 0-RTT, they MAY store the value of the server's H3_DATAGRAM SETTINGS parameter.  Doing so allows the client to send QUIC DATAGRAM frames in 0-RTT packets.  When servers decide to accept 0-RTT data, they MUST send a H3_DATAGRAM SETTINGS parameter greater than or equal to the value they sent to the client in the connection where they sent them the NewSessionTicket message.  If a client stores the value of the H3_DATAGRAM SETTINGS parameter with their 0-RTT state, they MUST validate that the new value of the H3_DATAGRAM SETTINGS parameter sent by the server in the handshake is greater than or equal to the stored value; if not, the client MUST terminate the connection with error H3_SETTINGS_ERROR.  In all cases, the maximum permitted value of the H3_DATAGRAM SETTINGS parameter is 1. It is RECOMMENDED that implementations that support receiving HTTP Datagrams using QUIC always send the H3_DATAGRAM SETTINGS parameter with a value of 1, even if the application does not intend to use HTTP Datagrams.  This helps to avoid "sticking out"; see security. 3.1.1. [[RFC editor: please remove this section before publication.]] Some revisions of this draft specification use a different value (the Identifier field of a Setting in the HTTP/3 SETTINGS frame) for the H3_DATAGRAM Settings Parameter.  This allows new draft revisions to make incompatible changes.  Multiple draft versions MAY be supported by either endpoint in a connection.  Such endpoints MUST send multiple values for H3_DATAGRAM.  Once an endpoint has sent and received SETTINGS, it MUST compute the intersection of the values it has sent and received, and then it MUST select and use the most recent draft version from the intersection set.  This ensures that both endpoints negotiate the same draft version. </ins> 4. This specification introduces the Capsule Protocol.  The Capsule