2. <del> Flows are bidirectional exchanges of datagrams within a single QUIC connection.  These are conceptually similar to streams in the sense that they allow multiplexing of application data.  Flows are identified within a connection by a numeric value, referred to as the flow ID.  A flow ID is a 62-bit integer (0 to 2^62-1). </del> <ins> In order to allow multiple exchanges of datagrams to coexist on a given QUIC connection, HTTP datagrams contain two layers of multiplexing.  First, the QUIC DATAGRAM frame payload starts with an encoded stream identifier that associates the datagram with a given QUIC stream.  Second, datagrams carry a context identifier (see datagram-contexts) that allows multiplexing multiple datagram contexts related to a given HTTP request.  Conceptually, the first layer of multiplexing is per-hop, while the second is end-to-end. </ins> <del> Flows lack any of the ordering or reliability guarantees of streams. Beyond this, a sender SHOULD ensure that DATAGRAM frames within a single flow are transmitted in order relative to one another. </del> <ins> 2.1. </ins> <del> 3. </del> <ins> Within the scope of a given HTTP request, contexts provide an additional demultiplexing layer.  Contexts determine the encoding of datagrams, and can be used to implicitly convey metadata.  For example, contexts can be used for compression to elide some parts of the datagram: the context identifier then maps to a compression context that the receiver can use to reconstruct the elided data. Contexts are identified within the scope of a given request by a numeric value, referred to as the context ID.  A context ID is a 62-bit integer (0 to 2^62-1). While stream IDs are a per-hop concept, context IDs are an end-to-end concept.  In other words, if a datagram travels through one or more intermediaries on its way from client to server, the stream ID will most likely change from hop to hop, but the context ID will remain the same.  Context IDs are opaque to intermediaries. 2.2. </ins> Implementations of HTTP/3 that support the DATAGRAM extension MUST <del> provide a flow ID allocation service.  That service will allow applications co-located with HTTP/3 to request a unique flow ID that they can subsequently use for their own purposes.  The HTTP/3 implementation will then parse the flow ID of incoming DATAGRAM </del> <ins> provide a context ID allocation service.  That service will allow applications co-located with HTTP/3 to request a unique context ID that they can subsequently use for their own purposes.  The HTTP/3 implementation will then parse the context ID of incoming DATAGRAM </ins> frames and use it to deliver the frame to the appropriate application context. <del> Even-numbered flow IDs are client-initiated, while odd-numbered flow IDs are server-initiated.  This means that an HTTP/3 client implementation of the flow ID allocation service MUST only provide </del> <ins> Even-numbered context IDs are client-initiated, while odd-numbered context IDs are server-initiated.  This means that an HTTP/3 client implementation of the context ID allocation service MUST only provide </ins> even-numbered IDs, while a server implementation MUST only provide <del> odd-numbered IDs.  Note that, once allocated, any flow ID can be used by both client and server - only allocation carries separate namespaces to avoid requiring synchronization. </del> <ins> odd-numbered IDs.  Note that, once allocated, any context ID can be used by both client and server - only allocation carries separate namespaces to avoid requiring synchronization.  Additionally, note that the context ID namespace is tied to a given HTTP request: it is possible for the same numeral context ID to be used simultaneously in distinct requests. </ins> <del> 4. </del> <ins> 3. </ins> When used with HTTP/3, the Datagram Data field of QUIC DATAGRAM frames uses the following format (using the notation from the "Notational Conventions" section of QUIC): <del> A variable-length integer indicating the Flow ID of the datagram (see datagram-flows). </del> <ins> A variable-length integer that contains the value of the client- initiated bidirectional stream that this datagram is associated with, divided by four.  (The division by four stems from the fact that HTTP requests are sent on client-initiated bidirectional streams, and those have stream IDs that are divisible by four.) A variable-length integer indicating the context ID of the datagram (see datagram-contexts). The payload of the datagram, whose semantics are defined by individual applications.  Note that this field can be empty. Intermediaries parse the Quarter Stream ID field in order to associate the QUIC DATAGRAM frame with a stream.  If an intermediary receives a QUIC DATAGRAM frame whose payload is too short to allow parsing the Quarter Stream ID field, the intermediary MUST treat it as an HTTP/3 connection error of type H3_GENERAL_PROTOCOL_ERROR. Intermediaries MUST ignore any HTTP/3 Datagram fields after the Quarter Stream ID. Endpoints parse both the Quarter Stream ID field and the Context ID field in order to associate the QUIC DATAGRAM frame with a stream and context within that stream.  If an endpoint receives a QUIC DATAGRAM frame whose payload is too short to allow parsing the Quarter Stream ID field, the endpoint MUST treat it as an HTTP/3 connection error of type H3_GENERAL_PROTOCOL_ERROR.  If an endpoint receives a QUIC DATAGRAM frame whose payload is long enough to allow parsing the Quarter Stream ID field but too short to allow parsing the Context ID field, the endpoint MUST abruptly terminate the corresponding stream with a stream error of type H3_GENERAL_PROTOCOL_ERROR. If a DATAGRAM frame is received and its Quarter Stream ID maps to a stream that has already been closed, the receiver MUST silently drop that frame.  If a DATAGRAM frame is received and its Quarter Stream ID maps to a stream that has not yet been created, the receiver SHALL either drop that frame silently or buffer it temporarily while awaiting the creation of the corresponding stream. 4. CAPSULE allows reliably sending request-related information end-to- end, even in the presence of HTTP intermediaries. CAPSULE is an HTTP/3 Frame (as opposed to a QUIC frame) which SHALL only be sent in client-initiated bidirectional streams. Intermediaries MUST forward all received CAPSULE frames in their unmodified entirety on the same stream where it would forward DATA frames.  Intermediaries MUST NOT send any CAPSULE frames other than the ones it is forwarding. This specification of CAPSULE currently uses HTTP/3 frame type 0xffcab5.  If this document is approved, a lower number will be requested from IANA. The Type and Length fields follows the definition of HTTP/3 frames from H3.  The payload consists of: The type of this capsule. Data whose semantics depends on the Capsule Type. Endpoints which receive a Capsule with an unknown Capsule Type MUST silently drop that Capsule.  Intermediaries MUST forward Capsules, even if they do not know the Capsule Type or cannot parse the Capsule Data. 4.1. The REGISTER_DATAGRAM_CONTEXT capsule (type=0x00) allows an endpoint to inform its peer of the encoding and semantics of datagrams associated with a given context ID.  Its Capsule Data field consists of: The context ID to register. A string of comma-separated key-value pairs to enable extensibility.  Keys are registered with IANA, see iana-keys. The ABNF for the Extension String field is as follows (using syntax from Section 3.2.6 of RFC7230): Note that these registrations are unilateral and bidirectional: the sender of the frame unilaterally defines the semantics it will apply to the datagrams it sends and receives using this context ID.  Once a context ID is registered, it can be used in both directions. Endpoints MUST NOT send DATAGRAM frames using a Context ID until they have either sent or received a REGISTER_DATAGRAM_CONTEXT Capsule with the same Context ID.  However, due to reordering, an endpoint that receives a DATAGRAM frame with an unknown Context ID MUST NOT treat it as an error, it SHALL instead drop the DATAGRAM frame silently, or buffer it temporarily while awaiting the corresponding REGISTER_DATAGRAM_CONTEXT Capsule. Endpoints MUST NOT register the same Context ID twice on the same stream.  This also applies to Context IDs that have been closed using a CLOSE_DATAGRAM_CONTEXT capsule.  Clients MUST NOT register server- initiated Context IDs and servers MUST NOT register client-initiated Context IDs.  If an endpoint receives a REGISTER_DATAGRAM_CONTEXT capsule that violates one or more of these requirements, the endpoint MUST abruptly terminate the corresponding stream with a stream error of type H3_GENERAL_PROTOCOL_ERROR. 4.2. The CLOSE_DATAGRAM_CONTEXT capsule (type=0x01) allows an endpoint to inform its peer that it will no longer send or parse received datagrams associated with a given context ID.  Its Capsule Data field consists of: The context ID to close. A string of comma-separated key-value pairs to enable extensibility, see the definition of the same field in register- capsule for details. Note that this close is unilateral and bidirectional: the sender of the frame unilaterally informs its peer of the closure.  Endpoints can use CLOSE_DATAGRAM_CONTEXT capsules to close a context that was initially registered by either themselves, or by their peer. Endpoints MAY use the CLOSE_DATAGRAM_CONTEXT capsule to immediately reject a context that was just registered using a REGISTER_DATAGRAM_CONTEXT capsule if they find its Extension String to be unacceptable. After an endpoint has either sent or received a CLOSE_DATAGRAM_CONTEXT frame, it MUST NOT send any DATAGRAM frames with that Context ID.  However, due to reordering, an endpoint that receives a DATAGRAM frame with a closed Context ID MUST NOT treat it as an error, it SHALL instead drop the DATAGRAM frame silently. Endpoints MUST NOT close a Context ID that was not previously registered.  Endpoints MUST NOT close a Context ID that has already been closed.  If an endpoint receives a CLOSE_DATAGRAM_CONTEXT capsule that violates one or more of these requirements, the endpoint MUST abruptly terminate the corresponding stream with a stream error of type H3_GENERAL_PROTOCOL_ERROR. 4.3. The DATAGRAM capsule (type=0x02) allows an endpoint to send a datagram frame over an HTTP stream.  This is particularly useful when using a version of HTTP that does not support QUIC DATAGRAM frames. Its Capsule Data field consists of: A variable-length integer indicating the context ID of the datagram (see datagram-contexts). </ins> The payload of the datagram, whose semantics are defined by individual applications.  Note that this field can be empty. <del> Endpoints MUST treat receipt of a DATAGRAM frame whose payload is too short to parse the flow ID as an HTTP/3 connection error of type H3_GENERAL_PROTOCOL_ERROR. </del> <ins> Datagrams sent using the DATAGRAM Capsule have the exact same semantics as datagrams sent in QUIC DATAGRAM frames. </ins> 5.


A TCP connection error is signaled with QUIC RESET_STREAM frame.  A proxy treats any error in the TCP connection, which includes receiving a TCP segment with the RST bit set, as a stream error of <del> type HTTP_CONNECT_ERROR (http-error-codes).  Correspondingly, a proxy MUST send a TCP segment with the RST bit set if it detects an error with the stream or the QUIC connection. </del> <ins> type HTTP_CONNECT_ERROR (http-error-codes).  Correspondingly, if a proxy detects an error with the stream or the QUIC connection, it MUST close the TCP connection.  If the underlying TCP implementation permits it, the proxy SHOULD send a TCP segment with the RST bit set. </ins> 4.3.


9. <del> 9.1. </del> <ins> M00TODO: Put in generalities about sigature algorithms and parameters. </ins> <del> 9.2. </del> <ins> 9.1. </ins> ECDSA DSS defines a signature algorithm using ECC.


The "path" field of a Commit message MUST be populated if the Commit covers at least one Update or Remove proposal, i.e., if the length of <del> the "updates" or "removes vectors is greater than zero.  The "path"field MUST also be populated if the Commit covers no proposals at all (i.e., if all three proposal vectors are empty).  The "path"field MAY be omitted if the Commit covers only Add proposals. In pseudocode, the logic for whether the "path` field is required is as follows: </del> <ins> the "updates" or "removes" vectors is greater than zero.  The "path" field MUST also be populated if the Commit covers no proposals at all (i.e., if all three proposal vectors are empty).  The "path" field MAY be omitted if the Commit covers only Add proposals.  In pseudocode, the logic for whether the "path" field is required is as follows: </ins> To summarize, a Commit can have three different configurations, with different uses:


12.3.21. <del> Protocol Property (Generic) Integer Connection This Property is a non-negative integer representing the relative inverse priority of this Connection relative to other Connections in the same Connection Group.  It has no effect on Connections not part of a Connection Group.  As noted in groups, this property is not entangled when Connections are cloned. </del> <ins> Integer Connection Property - see </ins> 12.3.22. [TODO: Discuss: should we remove this?  Whether we need this or the other depends on how we want to implement multi-streaming.  We don't <del> need both, so we should make a decision.] </del> <ins> need both, so we should make a decision. @mwelzl - These are really two different things @philsbln] </ins> Integer Message Property - see msg-niceness.


5.6. <del> In addition to measurements media players use to guide their segment- by-segment adaptive streaming requests, streaming media providers may also rely on measurements collected from media players to provide analytics that can be used for decisions such as whether the adaptive encoding bitrates in use are the best ones to provide to media players, or whether current media content caching is providing the best experience for viewers.  To that effect, the Consumer Technology Association (CTA) who owns the Web Application Video Ecosystem (WAVE) project has published two important specifications. 5.6.1. </del> <ins> Media players use measurements to guide their segment-by-segment adaptive streaming requests, but may also provide measurements to streaming media providers. In turn, providers may base analytics on these measurements, to guide decisions such as whether adaptive encoding bitrates in use are the best ones to provide to media players, or whether current media content caching is providing the best experience for viewers. To that effect, the Consumer Technology Association (CTA) who owns the Web Application Video Ecosystem (WAVE) project has published two important specifications. CTA-2066: Streaming Quality of Experience Events, Properties and Metrics </ins> CTA-2066 specifies a set of media player events, properties, quality of experience (QoE) metrics and associated terminology for


Prior to receiving an ACK_FREQUENCY frame, endpoints send acknowledgements as specified in Section 13.2.1 of QUIC-TRANSPORT. <del> On receiving an ACK_FREQUENCY frame and updating its recorded "max_ack_delay" and "Ack-Eliciting Threshold" values (ack-frequency- frame), the endpoint MUST send an acknowledgement when one of the following conditions are met: </del> <ins> On receiving an ACK_FREQUENCY frame and updating its "max_ack_delay" and "Ack-Eliciting Threshold" values (ack-frequency-frame), the endpoint sends an acknowledgement when one of the following conditions are met: </ins> Since the last acknowledgement was sent, the number of received <del> ack-eliciting packets is greater than or equal to the recorded "Ack-Eliciting Threshold". </del> <ins> ack-eliciting packets is greater than the "Ack-Eliciting Threshold". </ins> Since the last acknowledgement was sent, "max_ack_delay" amount of time has passed.


This document provides usage guidance for external Pre-Shared Keys (PSKs) in Transport Layer Security (TLS) 1.3 as defined in RFC 8446. <del> This document lists TLS security properties provided by PSKs under certain assumptions, and then demonstrates how violations of these assumptions lead to attacks.  This document discusses PSK use cases and provisioning processes.  This document provides advice for applications to help meet these assumptions.  This document also lists the privacy and security properties that are not provided by TLS 1.3 when external PSKs are used. </del> <ins> It lists TLS security properties provided by PSKs under certain assumptions, and then demonstrates how violations of these assumptions lead to attacks.  Advice for applications to help meet these assumptions is provided.  It also discusses PSK use cases and provisioning processes.  Finally, it lists the privacy and security properties that are not provided by TLS 1.3 when external PSKs are used. </ins> 1.


4.2. TCP conflates transmission order at the sender with delivery order at <del> the receiver, which results in retransmissions of the same data carrying the same sequence number, and consequently leads to "retransmission ambiguity".  QUIC separates the two.  QUIC uses a packet number to indicate transmission order.  Application data is sent in one or more streams and delivery order is determined by stream offsets encoded within STREAM frames. </del> <ins> the receiver, resulting in the retransmission ambiguity problem (RETRANSMISSION).  QUIC separates transmission order from delivery order: packet numbers indicate transmission order, and delivery order is determined by the stream offsets in STREAM frames. </ins> QUIC's packet number is strictly increasing within a packet number space, and directly encodes transmission order.  A higher packet


2. The design goal is to be able to send simple sensor measurements in <del> small packets on mesh networks from large numbers of constrained devices.  Keeping the total size of payload under 80 bytes makes this easy to use on a wireless mesh network.  It is always difficult to define what small code is, but there is a desire to be able to implement this in roughly 1 KB of flash on a 8 bit microprocessor. Experience with power meters and other large scale deployments has indicated that the solution needs to support allowing multiple measurements to be batched into a single HTTP or CoAP request.  This "batch" upload capability allows the server side to efficiently support a large number of devices.  It also conveniently supports batch transfers from proxies and storage devices, even in situations where the sensor itself sends just a single data item at a time.  The multiple measurements could be from multiple related sensors or from the same sensor but at different times. </del> <ins> small packets from large numbers of constrained devices.  Keeping the total size of payload small makes it easy to use SenML also in constrained networks, e.g., in a 6LoWPAN RFC4944.  It is always difficult to define what small code is, but there is a desire to be able to implement this in roughly 1 KB of flash on a 8 bit microprocessor.  Experience with power meters and other large scale deployments has indicated that the solution needs to support allowing multiple measurements to be batched into a single HTTP or CoAP request.  This "batch" upload capability allows the server side to efficiently support a large number of devices.  It also conveniently supports batch transfers from proxies and storage devices, even in situations where the sensor itself sends just a single data item at a time.  The multiple measurements could be from multiple related sensors or from the same sensor but at different times. </ins> The basic design is an array with a series of measurements.  The following example shows two measurements made at different times.


If the nodelist is empty, the conversion result is "LogicalFalse". <del> Extraction of a value from a nodelist can be performed in several ways, so an implicit conversion from "NodesType" to "ValueType" may be surprising and has therefore not been defined.  A function expression with a declared type of "NodesType" can indirectly be used as an argument for a parameter of declared type "ValueType" by wrapping the expression in a call to a function extension such as "value" (see value). </del> <ins> Notes: Extraction of a value from a nodelist can be performed in several ways, so an implicit conversion from "NodesType" to "ValueType" may be surprising and has therefore not been defined. A function expression with a declared type of "NodesType" can indirectly be used as an argument for a parameter of declared type "ValueType" by wrapping the expression in a call to a function extension, such as "value()" (see value), that takes a parameter of type "NodesType" and returns a result of type "ValueType". </ins> The well-typedness of function expressions can now be defined in terms of this type system.


Section 8.2 of I-D.ietf-add-svcb-dns describes a second downgrade attack where an attacker can block connections to the encrypted DNS <del> server, and recommends that clients prevent it by switching to SVCB- reliant behavior once SVCB resolution does succeed.  For DDR, this means that once a client discovers a compatible Designated Resolver, it SHOULD NOT use unencrypted DNS until the SVCB record expires, unless verification of the resolver fails. </del> <ins> server.  For DDR, clients need to validate a Designated Resolver using a connection to the server before trusting it, so attackers that can block these connections can prevent clients from switching to use encrypted DNS. </ins> DoH resolvers that allow discovery using DNS SVCB answers over unencrypted DNS MUST NOT provide differentiated behavior based on the


param_value_definition : If for any one of the endpoints the parameter is absent or set to 0, <del> or if the two endpoints select incompatible values, one proposing 0x1 and the other proposing 0x2, the endpoints MUST fallback to QUIC- TRANSPORT with single path and MUST NOT use any frame or mechanism defined in this document. If an endpoint proposes the value 0x3, the value proposed by the other is accepted.  If both endpoints propose the value 0x3, the value 0x2 is negotiated. </del> <ins> the endpoints MUST fallback to QUIC-TRANSPORT with single active path and MUST NOT use any frame or mechanism defined in this document. </ins> If endpoint receives unexpected value for the transport parameter "enable_multipath", it MUST treat this as a connection error of type


The helper handles well-formed requests as follows.  (As usual, malformed requests are handled as described in pa-error-common- aborts.)  It first looks for the PDA parameters "PDAParam" for which <del> "PDAAggregateReq.task_id" is equal to the task id derived from </del> <ins> "PDAAggregateReq.task_id" is equal to the task ID derived from </ins> "PDAParam". The response consists of the helper's updated state and a sequence of


handshake even though the Retry itself was sent using the original version. <del> 6.2. </del> <ins> 7.2. </ins> QUIC version 1 uses TLS 1.3, which supports session resumption by sending session tickets in one connection that can be used in a later


for other control processes, and a short header that may be used for data transmission in an established connection.  While the long header always exposes some information (such as the version and <del> Connection IDs), the short header only optionally exposes a single Connection ID. Given that exposing this information may make it possible to associate multiple addresses with a single client during rebinding, which has privacy implications, an application may indicate to not support exposure of certain information after the handshake. Specifically, an application that has additional information that the client is not behind a NAT and the server is not behind a load balancer, and therefore it is unlikely that the addresses will be re- bound, may indicate to the transport that is wishes to not expose a </del> <ins> Connection IDs), the short header exposes at most only a single </ins> Connection ID. 6.1. QUIC supports a server-generated Connection ID, transmitted to the client during connection establishment (see Section 6.1 of QUIC). <del> Servers behind load balancers should propose a Connection ID during the handshake, encoding the identity of the server or information about its load balancing pool, in order to support stateless load balancing.  Once the server generates a Connection ID that encodes its identity, every CDN load balancer would be able to forward the packets to that server without needing information about every specific flow it is forwarding. Server-generated Connection IDs must not encode any information other that that needed to route packets to the appropriate backend server(s): typically the identity of the backend server or pool of servers, if the data-center's load balancing system keeps "local" state of all flows itself.  Care must be exercised to ensure that the information encoded in the Connection ID is not sufficient to identify unique end users.  Note that by encoding routing information in the Connection ID, load balancers open up a new attack vector that allows bad actors to direct traffic at a specific backend server or pool.  It is therefore recommended that Server-Generated Connection ID includes a cryptographic MAC that the load balancer pool server is able to identify and discard packets featuring an invalid MAC. </del> <ins> Servers behind load balancers may need to propose a Connection ID during the handshake, encoding the identity of the server or information about its load balancing pool, in order to support stateless load balancing.  Once the server generates a Connection ID that encodes its identity, every CDN load balancer would be able to forward the packets to that server without retaining connection state. Server-generated connection IDs should seek to obscure any encoding, of routing identities or any other information.  Exposing the server mapping would allow linkage of multiple IP addresses to the same host if the server also supports migration.  Furthermore, this opens an attack vector on specific servers or pools. The best way to obscure an encoding is to appear random to observers, which is most rigorously achieved with encryption. </ins> 6.2. <ins> While sufficiently robust connection ID generation schemes will mitigate linkability issues, they do not provide full protection. Analysis of the lifetimes of six-tuples (source and destination addresses as well as the migrated CID) may expose these links anyway. In the limit where connection migration in a server pool is rare, it is trivial for an observer to associate two connection IDs. Conversely, in the opposite limit where every server handles multiple simultaneous migrations, even an exposed server mapping may be insufficient information. The most efficient mitigation for these attacks is operational, either by using a load balancing architecture that loads more flows onto a single server-side address, by coordinating the timing of migrations to attempt to increase the number of simultaneous migrations at a given time, or through other means. 6.3. </ins> QUIC provides a Server Retry packet that can be sent by a server in response to the Client Initial packet.  The server may choose a new Connection ID in that packet and the client will retry by sending


Compute a COSE_Encrypt0 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_4, the <del> initialization vector IV_4, the plaintext P, and the following parameters as input (see COSE): </del> <ins> initialization vector IV_4, the plaintext PLAINTEXT_4, and the following parameters as input (see COSE): </ins> protected = h''


To avoid excessively small idle timeout periods, endpoints MUST increase the idle timeout period to be at least three times the <del> current Probe Timeout (PTO). </del> <ins> current Probe Timeout (PTO).  This allows for multiple PTOs to expire prior to idle timeout, ensuring the idle timeout does not expire as a result of a single packet loss. </ins> 10.1.1.


4.2.2. <del> The ADDRESS_REQUEST capsule allows an endpoint to request assignment of an IP address from its peer.  This capsule is not required for simple client/proxy communication where the client only expects to receive one address from the proxy.  The capsule allows the endpoint to optionally indicate a preference for which address it would get assigned.  This capsule uses a Capsule Type of 0xfff101.  Its value uses the following format: </del> <ins> The ADDRESS_REQUEST capsule (see iana-types for the value of the capsule type) allows an endpoint to request assignment of an IP address from its peer.  This capsule is not required for simple client/proxy communication where the client only expects to receive one address from the proxy.  The capsule allows the endpoint to optionally indicate a preference for which address it would get assigned. </ins> IP Version of this address request.  MUST be either 4 or 6.


must instead match what was supplied in the offer, as described above. <del> Unless codec preferences have been set for the associated transceiver, the media formats on the m= line MUST be generated in the same order as in the current local description. </del> Each "a=ice-ufrag" and "a=ice-pwd" line MUST stay the same, unless the m= section is restarting, in which case new ICE credentials must be created as specified in RFC5245, Section 9.2.1.1.  If the


following restriction: The fields of the "o=" line MUST stay the same except for the <del> <session-version> field, which MUST increment if the session description changes in any way, including the addition of ICE candidates. </del> <ins> <session-version> field, which MUST increment by one on each call to createOffer if the offer might differ from the output of the previous call to createOffer; implementations MAY opt to increment <session-version> on every call.  The value of the generated <session-version> is independent of the <session-version> of the current local description; in particular, in the case where the current version is N, an offer is created with version N+1, and then that offer is rolled back so that the current version is again N, the next generated offer will still have version N+2. Note that if the application creates an offer by reading currentLocalDescription instead of calling createOffer, the returned SDP may be different than when setLocalDescription was originally called, due to the addition of gathered ICE candidates, but the <session-version> will not have changed.  There are no known scenarios in which this causes problems, but if this is a concern, the solution is simply to use createOffer to ensure a unique <session-version>. </ins> If the initial offer was applied using setLocalDescription, but an answer from the remote side has not yet been applied, meaning the


provide a signature on a signature allowing for a proof that a signature existed at a given time (i.e., a timestamp). <ins> A CoSWID SHOULD be signed, using the above mechanism, to protect the integrity of the CoSWID tag.  See the security considerations (in sec-sec) for more information on why a signed CoSWID is valuable in most cases. </ins> 8. This specification allows for tagged and untagged CBOR data items


Before the client can upload its report to the leader, it must know the public key of each of the aggregators.  These are retrieved from <del> each aggregator by sending a request to "[aggregator]/hpke_config", where "[aggregator]" is the aggregator's endpoint URL, obtained from the task parameters.  The aggregator responds to well-formed requests with status 200 and an "HpkeConfig" value: </del> <ins> each aggregator by sending a request to "[aggregator]/hpke_config?task_id=[task-id]", where "[aggregator]" is the aggregator's endpoint URL, obtained from the task parameters, and "[task-id]" is the task ID obtained from the task parameters, encoded in Base 64 with URL and filename safe alphabet with no padding, as specified in sections 5 and 3.2 of RFC4648.  If the aggregator does not recognize the task ID, then it responds with HTTP error status 404 Not Found and an error of type "unrecognizedTask".  The aggregator responds to well-formed requests with status 200 and an "HpkeConfig" value: [TODO: Allow aggregators to return HTTP 403 Forbidden in deployments that use authentication to avoid leaking information about which tasks exist.] </ins> [OPEN ISSUE: Decide whether to expand the width of the id, or support multiple cipher suites (a la OHTTP/ECH).]


Time-Sensitive Network. <del> 2.3. 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> 3. The basic approach defined in I-D.ietf-detnet-mpls supports the


match a value provided in the corresponding "ECHConfig.cipher_suites" list. <del> A cryptographic hash of the "ECHConfig" structure from which the ECH key was obtained, i.e., from the first byte of "version" to the end of the structure.  This hash is computed using the hash function associated with "cipher_suite", i.e., the corresponding HPKE KDF algorithm hash. </del> <ins> Equal to "Expand(Extract("", config), "ech_config_digest", Nh)", where "config" is the "ECHConfig" structure and "Extract", "Expand", and "Nh" are as specified by the cipher suite KDF. (Passing the literal """" as the salt is interpreted by "Extract" as no salt being provided.) </ins> The HPKE encapsulated key, used by servers to decrypt the corresponding "encrypted_ch" field.


CertificateEntry. If the corresponding certificate type extension <del> ("server_certificate_type" or "client_certificate_type") was not used or the X.509 certificate type was negotiated, then each CertificateEntry contains an X.509 certificate.  The sender's certificate MUST come in the first CertificateEntry in the list. Each following certificate SHOULD directly certify one preceding it. Because certificate validation requires that trust anchors be distributed independently, a certificate that specifies a trust anchor MAY be omitted from the chain, provided that supported peers are known to possess any omitted certificates. </del> <ins> ("server_certificate_type" or "client_certificate_type") was not negotiated in Encrypted Extensions, or the X.509 certificate type was negotiated, then each CertificateEntry contains an X.509 certificate. The sender's certificate MUST come in the first CertificateEntry in the list.  Each following certificate SHOULD directly certify one preceding it.  Because certificate validation requires that trust anchors be distributed independently, a certificate that specifies a trust anchor MAY be omitted from the chain, provided that supported peers are known to possess any omitted certificates. </ins> Note: Prior to TLS 1.3, "certificate_list" ordering required each certificate to certify the one immediately preceding it; however,


That the client controls the identifier in question. <del> This process may be repeated to associate multiple identifiers to a key pair (e.g., to request certificates with multiple identifiers) or to associate multiple accounts with an identifier (e.g., to allow </del> <ins> This process may be repeated to associate multiple identifiers with an account (e.g., to request certificates with multiple identifiers) or to associate multiple accounts with an identifier (e.g., to allow </ins> multiple entities to manage certificates). Authorization resources are created by the server in response to <del> certificate orders or authorization requests submitted by an account key holder; their URLs are provided to the client in the responses to </del> <ins> newOrder or newAuthorization requests submitted by an account key holder; their URLs are provided to the client in the responses to </ins> these requests.  The authorization object is implicitly tied to the account key used to sign the request. <del> When a client receives an order from the server in reply to a new order request, it downloads the authorization resources by sending </del> <ins> When a client receives an order from the server in reply to a newOrder request, it downloads the authorization resources by sending </ins> POST-as-GET requests to the indicated URLs.  If the client initiates authorization using a request to the newAuthz resource, it will have already received the pending authorization object in the response to


involves sending a cookie exchange to avoid DoS attacks. Protocols: QUIC + TLS, DTLS, WireGuard <ins> 5.3. Connection Termination The security protocol may be instructed to tear down its connection and session information.  This is needed by some protocols to prevent application data truncation attacks. Protocols: TLS, DTLS, QUIC + TLS, MinimalT, tcpcrypt, IKEv2 </ins> Key Update The handshake protocol may be instructed to update its keying material, either by the application directly or by the record protocol sending a key expiration event. Protocols: TLS, DTLS, QUIC + TLS, MinimalT, tcpcrypt, IKEv2 <del> Pre-Shared Key Export The handshake protocol will generate one or more keys to be used for record encryption/decryption and authentication.  These may be explicitly exportable to the application, traditionally limited to direct export to the record protocol, or inherently non-exportable because the keys must be used directly in conjunction with the record protocol. </del> <ins> Pre-Shared Key Export The handshake protocol will generate one or more keys to be used for record encryption/decryption and authentication.  These may be explicitly exportable to the application, traditionally limited to direct export to the record protocol, or inherently non-exportable because the keys must be used directly in conjunction with the record protocol. </ins> Explict export: TLS (for QUIC), tcpcrypt, IKEv2, DTLS (for SRTP)


Steps: <del> Run "(cfg, update) = PP_Server_Setup(id)". </del> <ins> Run "(cfg, update) = ServerSetup(id)". </ins> Construct a "config_update" message.


Priority handling of retransmissions can be implemented by the sender in the transport layer.  QUIC recommends retransmitting lost data before new data, unless indicated differently by the application. <del> Currently, QUIC only provides fully reliable stream transmission, which means that prioritization of retransmissions will be beneficial in most cases, by filling in gaps and freeing up the flow control window.  For partially reliable or unreliable streams, priority scheduling of retransmissions over data of higher-priority streams might not be desirable.  For such streams, QUIC could either provide an explicit interface to control prioritization, or derive the prioritization decision from the reliability level of the stream. </del> <ins> When a QUIC endpoint uses fully reliable streams for transmission, prioritization of retransmissions will be beneficial in most cases, filling in gaps and freeing up the flow control window.  For partially reliable or unreliable streams, priority scheduling of retransmissions over data of higher-priority streams might not be desirable.  For such streams, QUIC could either provide an explicit interface to control prioritization, or derive the prioritization decision from the reliability level of the stream. </ins> 4.3.


ClientHello message in their first Initial packet. The TLS implementation does not need to ensure that the ClientHello <del> is sufficiently large.  QUIC PADDING frames are added to increase the size of the packet as necessary. </del> <ins> is large enough to meet the requirements for QUIC packets.  QUIC PADDING frames are added to increase the size of the packet as necessary; see Section 14.1 of QUIC-TRANSPORT. </ins> 4.4.


Clients using Opportunistic Discovery (opportunistic) MUST be limited to cases where the Unencrypted DNS Resolver and Designated Resolver <del> have the same IP address.  Clients which do not follow Opportunistic Discovery (opportunistic) and instead try to connect without first checking for a designation run the possible risk of being intercepted by an attacker hosting an Encrypted DNS Resolver on an IP address of an Unencrypted DNS Resolver where the attacker has failed to gain </del> <ins> have the same IP address, which SHOULD be a private or local IP address.  Clients which do not follow Opportunistic Discovery (opportunistic) and instead try to connect without first checking for a designation run the possible risk of being intercepted by an attacker hosting an Encrypted DNS Resolver on an IP address of an Unencrypted DNS Resolver where the attacker has failed to gain </ins> control of the Unencrypted DNS Resolver. The constraints on the use of Designated Resolvers specified here


batch IDs.  Thus the Aggregator needs to check that the query is associated with a known batch ID: <del> For a CollectReq containing a query of type "by_batch_id", the </del> <ins> For a CollectionReq containing a query of type "by_batch_id", the </ins> Leader checks that the provided batch ID corresponds to a batch ID <del> it returned in a previous CollectResp for the task. </del> <ins> it returned in a previous Collection for the task. </ins> For an AggregateShareReq, the Helper checks that the batch ID provided by the Leader corresponds to a batch ID used in a


For example, an If-Match Outer option is discarded, Uri-Host Outer option is not discarded, Observe is not discarded. <ins> Replace step 3 in ver-req with: B.  If Observe is present in the received message, and has value 0, check if the Token, Kid and Partial IV are identical to a previously received Observe registration.  In this case, replay verification is postponed until step C.  Otherwise verify the 'Partial IV' parameter using the Replay Window, as described in replay-protection. </ins> Insert the following steps between step 6 and 7 of ver-req: <del> B.  If Observe was present in the received message (in step 1): </del> <ins> C.  If Observe was present in the received message (in step 1): </ins> If the value of Observe in the Outer message is 0: If Observe is present and has value 0 in the decrypted options, <del> discard the Outer Observe; </del> <ins> discard the Outer Observe.  If the Token, Kid and Partial IV are identical to a previously received Observe registration, respond with a notification as described in observe-replay- processing; </ins> Otherwise, discard both the Outer and Inner (if present) <del> Observe options. </del> <ins> Observe options and verify the 'Partial IV' parameter using the Replay Window, as described in replay-protection. </ins> <del> If the value of Observe in the Outer message is not 0, discard </del> <ins> If the value of Observe in the Outer message is not 0, discard the </ins> decrypted Observe option if present. <del> Insert the following steps between step 6 and 7 of ver-req: C.  If the message is an Observe registration, store it in memory for later comparison with re-registrations (see replay-protection). D.  If the message is an Observe cancellation, delete from memory the previously stored registration related to that observation (see replay-protection). </del> 8.3. If a CoAP response is generated in response to an OSCORE request, the


8.5. <del> A new address is considered valid when a PATH_RESPONSE frame is received that contains the data that was sent in a previous PATH_CHALLENGE frame.  Receipt of an acknowledgment for a packet containing a PATH_CHALLENGE frame is not adequate validation, since the acknowledgment can be spoofed by a malicious peer. </del> <ins> Path validation succeeds when a PATH_RESPONSE frame is received that contains the data that was sent in a previous PATH_CHALLENGE frame. This validates the path on which the PATH_CHALLENGE was sent. Receipt of an acknowledgment for a packet containing a PATH_CHALLENGE frame is not adequate validation, since the acknowledgment can be spoofed by a malicious peer. </ins> 8.6.


This specification does not assume that the implementation will have access to ICMP or raw IP. <ins> The following protocols may be used, but can be implemented by a WebRTC endpoint, and are therefore not defined as "system-provided interfaces": TURN - Traversal Using Relays Around NAT, STUN - Session Traversal Utilities for NAT, ICE - Interactive Connectivity Establishment, RFC5245 TLS - Trasnsport Layer Security, DTLS - Datagram Transport Layer Security, RFC6347. </ins> 3.2. Web applications running in a WebRTC browser MUST be able to utilize


An "a=rtcp-mux" line, as specified in RFC5761, Section 5.1.3. <ins> If the RTP/RTCP multiplexing policy is "require", an "a=rtcp-mux- only" line, as specified in I-D.ietf-mmusic-mux-exclusive, Section 4. </ins> An "a=rtcp-rsize" line, as specified in RFC5506, Section 5. Lastly, if a data channel has been created, a m= section MUST be


9.2. In addition to the SenML Fragment Identifiers described above, with <del> the XML and EXI SenML formats also the syntax defined in </del> <ins> the XML and EXI SenML formats also the syntax defined in the XPointer element() Scheme XPointerElement of the XPointer Framework </ins> XPointerFramework can be used.  (This is required by RFC7303 for media types using the "+xml" structured syntax suffix.  SenML allows this for the EXI formats as well for consistency.)


replay protection data.  The operation of validating the Partial IV and updating the replay protection data MUST be atomic. <ins> 7.4.1.2. In order to allow intermediaries to re-register their interest in a resource (see 3.3.1 of RFC7641), a server receiving an Observe registration with Token, Kid and Partial IV identical to a previously received registration, and which decrypts without error SHALL not treat it as a replay and SHALL respond with a notification.  The notification may be a cached copy of the latest sent notification (with the same Token, Kid and Partial IV) or it may be a newly generated notification with a fresh Partial IV. </ins> 7.5. To prevent reuse of an AEAD nonce with the same key, or from


the client has accomplished the challenge. Once the validation process is complete and the server is satisfied <del> that the client has met its requirements, the server can either proactively issue the requested certificate or wait for the client to request that the application be "finalized", at which point the certificate will be issued and provided to the client. </del> <ins> that the client has met its requirements, the server will issue the requested certificate and make it available to the client. </ins> To revoke a certificate, the client simply sends a revocation request indicating the certificate to be revoked, signed with an authorized


The hash function used for HKDF RFC5869 is that which is associated with the EPSK.  It is not the hash function associated with ImportedIdentity.target_kdf.  If no hash function is specified, <del> SHA-256 SHA2 MUST be used.  Diversifying EPSK by </del> <ins> SHA-256 SHA2 SHOULD be used.  Diversifying EPSK by </ins> ImportedIdentity.target_kdf ensures that an IPSK is only used as input keying material to at most one KDF, thus satisfying the requirements in RFC8446.  See security-considerations for more


12. Each Commit message is premised on a given starting state, indicated <del> in its "prior_epoch" field.  If the changes implied by a Commit messages are made starting from a different state, the results will be incorrect. </del> <ins> by the "epoch" field of the enclosing MLSPlaintext message.  If the changes implied by a Commit messages are made starting from a different state, the results will be incorrect. </ins> This need for sequencing is not a problem as long as each time a group member sends a Commit message, it is based on the most current


Minor editorial fixes in response to Gen-ART review. <ins> Random EP names: Point that multiple collisions are possible but unlikely. (For background, in the first round of attempts there's a good chance that one of the random IDs will collide due to the birthday paradox; the likelyhood for a second (or even third) collision in a row is way below that because only the colliding node(s) will retry). </ins> changes from -24 to -25 Large rework of section 7 (Security policies)


as well as providing a public key that others can use for key agreement.  The client's signature key can be updated throughout the lifetime of the group by sending a new KeyPackage with a new <del> signature key; the new signature key MUST be validated by the </del> <ins> Credential.  However, the identity MUST be the same in both Credentials and the new Credential MUST be validated by the </ins> authentication service. When used as InitKeys, KeyPackages are intended to be used only once


a Preconnection allows applications to override this for more detailed control. <del> Transport Properties MUST always be specified while security parameters are OPTIONAL. </del> If Message Framers are used (see framing), they MUST be added to the Preconnection during pre-establishment.


4.2.3. <del> The Transport Services architecture defines a mechanism that allows applications to easily make use of various network paths and Protocol Stacks without requiring major changes in application logic.  In some cases, changing which Protocol Stacks or network paths are used will require updating the preferences expressed by the application that uses the Transport Services system.  For example, an application can enable the use of a multipath or multistreaming transport protocol by modifying the properties in its Pre-Connection configuration.  In some cases, however, the Transport Services system will be able to automatically change Protocol Stacks without an update to the application, either by selecting a new stack entirely, or by racing multiple candidate Protocol Stacks during connection establishment. This functionality in the API can be a powerful driver of new protocol adoption, but needs to be constrained carefully to avoid unexpected behavior that can lead to functional or security problems. If two different Protocol Stacks can be safely swapped, or raced in parallel (see racing), then they are considered to be "equivalent". Equivalent Protocol Stacks need to meet the following criteria: Both stacks MUST offer the interface requested by the application for connection establishment and data transmission.  For example, if an application requires preservation of message boundaries, a Protocol Stack that runs UDP as the top-level interface to the application is not equivalent to a Protocol Stack that runs TCP as the top-level interface.  A UDP stack would allow an application to read out message boundaries based on datagrams sent from the remote system, whereas TCP does not preserve message boundaries on its own, but needs a framing protocol on top to determine message boundaries. Both stacks MUST offer the transport services that are requested by the application.  For example, if an application specifies that it requires reliable transmission of data, then a Protocol Stack using UDP without any reliability layer on top would not be allowed to replace a Protocol Stack using TCP.  However, if the application does not require reliability, then a Protocol Stack that adds reliability could be regarded as an equivalent Protocol Stack as long as providing this would not conflict with any other application-requested properties. Both stacks MUST offer security protocols and parameters as requested by the application I-D.ietf-taps-transport-security. Security features and properties, such as cryptographic algorithms, peer authentication, and identity privacy vary across security protocols, and across versions of security protocols. Protocol equivalence ought not to be assumed for different protocols or protocol versions, even if they offer similar application configuration options.  To ensure that security protocols are not incorrectly swapped, Transport Services systems SHOULD only automatically generate equivalent Protocol Stacks when the transport security protocols within the stacks are identical. Specifically, a Transport Services system would consider protocols identical only if they are of the same type and version.  For example, the same version of TLS running over two different transport Protocol Stacks are considered equivalent, whereas TLS 1.2 and TLS 1.3 RFC8446 are not considered equivalent.  However, Transport Services systems MAY allow applications to indicate that they consider two different transport protocols equivalent, e.g., to allow fallback to TLS 1.2 if TLS 1.3 is not available. 4.2.4. </del> By default, stored properties of the implementation, such as cached protocol state, cached path state, and heuristics, may be shared (e.g. across multiple connections in an application).  This provides


Partial IV MUST always be compared with the Notification Number, which thus MUST NOT be forgotten after 128 seconds.  Further details of replay protection of notifications are specified in replay- <del> protection.  The client MAY ignore the Observe option value. </del> <ins> protection. </ins> Clients can re-register observations to ensure that the observation is still active and establish freshness again (RFC7641 <del> Section 3.3.1).  When an OSCORE observation is refreshed, not only the ETags, but also the partial IV (and thus the payload and OSCORE option) change.  The server uses the new request's Partial IV as the 'request_piv' of new responses. </del> <ins> Section 3.3.1).  When an OSCORE protected observation is refreshed, not only the ETags, but also the partial IV (and thus the payload and OSCORE option) change.  The server uses the new request's Partial IV as the 'request_piv' of new responses. </ins> 4.1.3.5.


its adoption in the broadcasting/streaming industry is lagging behind. <del> Currently, there is no standard protocol designed for ingesting media into a streaming service using WebRTC and so content providers still rely heavily on protocols like RTMP for doing so. These protocols are much older than WebRTC and by default lack some important security and resilience features provided by WebRTC with minimal overhead and additional latency. The media codecs used for ingestion in older protocols tend to be limited and not negotiated.  WebRTC includes support for negotiation of codecs, potentially alleviating transcoding on the ingest node (which can introduce delay and degrade media quality).  Server side transcoding that has traditionally been done to present multiple renditions in Adaptive Bit Rate Streaming (ABR) implementations can be replaced with Simulcast RFC8853 and SVC codecs that are well supported by WebRTC clients.  In addition, WebRTC clients can adjust client-side encoding parameters based on RTCP feedback to maximize encoding quality. Encryption is mandatory in WebRTC, therefore secure transport of media is implicit. </del> The IETF RTCWEB working group standardized JSEP (RFC8829), a mechanism used to control the setup, management, and teardown of a multimedia session.  It also describes how to negotiate media flows


This information is aggregated in a "PublicGroupState" object as follows: <del> "struct { CipherSuite cipher_suite; opaque group_id<0..255>; uint64 epoch; opaque tree_hash<0..255>; opaque interim_transcript_hash<0..255>; Extension extensions<0..2^32-1>; HPKEPublicKey external_pub; } PublicGroupState; " </del> Note that the "tree_hash" field is used the same way as in the Welcome message.  The full tree can be included via the "ratchet_tree" extension ratchet-tree-extension. <del> The information above are not deemed public data in general, but applications can choose to make them available to new members in order to allow External Commits. </del> <ins> The signature MUST verify using the public key taken from the credential in the leaf node at position "signer_index".  The signature covers the following structure, comprising all the fields in the PublicGroupState above "signer_index": This signature authenticates the HPKE public key, so that the joiner knows that the public key was provided by a member of the group.  The fields that are not signed are included in the key schedule via the GroupContext object.  If the joiner is provided an inaccurate data for these fields, then its external Commit will have an incorrect "confirmation_tag" and thus be rejected. The information in a PublicGroupState is not deemed public in general, but applications can choose to make it available to new members in order to allow External Commits. </ins> External Commits work like regular Commits, with a few differences:


the server is not overly constrained by the amplification restriction. <del> Packet loss, in particular loss of a Handshake packet from the server, can cause a situation in which the server cannot send when the client has no data to send and the anti-amplification limit is reached.  In order to avoid this causing a handshake deadlock, clients MUST send a packet upon a probe timeout, as described in QUIC-RECOVERY.  If the client has no data to retransmit and does not have Handshake keys, it MUST send an Initial packet in a UDP datagram of at least 1200 bytes.  If the client has Handshake keys, it SHOULD send a Handshake packet. </del> <ins> Loss of an Initial or Handshake packet from the server can cause a deadlock if the client does not send additional Initial or Handshake packets.  A deadlock could occur when the server reaches its anti- amplification limit and the client has received acknowledgements for all the data it has sent.  In this case, when the client has no reason to send additional packets, the server will be unable to send more data because it has not validated the client's address.  To prevent this deadlock, clients MUST send a packet on a probe timeout (PTO, see Section 5.3 of QUIC-RECOVERY).  Specifically, the client MUST send an Initial packet in a UDP datagram of at least 1200 bytes if it does not have Handshake keys, and otherwise send a Handshake packet. </ins> A server might wish to validate the client address before starting the cryptographic handshake.  QUIC uses a token in the Initial packet


then the server SHOULD change the status of the order to "invalid" and MAY delete the order resource. <del> The server MUST issue the requested certificate and update the order resource with a URL for the certificate shortly after the client has fulfilled the server's requirements.  If the client has already satisfied the server's requirements at the time of this request (e.g., by obtaining authorization for all of the identifiers in the certificate in previous transactions), then the server MUST proactively issue the requested certificate and provide a URL for it in the "certificate" field of the order.  The server MUST, however, still list the completed authorizations in the "authorizations" array. </del> <ins> The server MUST begin the issuance process for the requested certificate and update the order resource with a URL for the certificate once the client has fulfilled the server's requirements. If the client has already satisfied the server's requirements at the time of this request (e.g., by obtaining authorization for all of the identifiers in the certificate in previous transactions), then the server MUST proactively issue the requested certificate and provide a URL for it in the "certificate" field of the order.  The server MUST, however, still list the completed authorizations in the "authorizations" array. </ins> Once the client believes it has fulfilled the server's requirements, it should send a GET request to the order resource to obtain its


2.4.7. <del> The "search" function extension provides a way to check whether a </del> <ins> The "search()" function extension provides a way to check whether a </ins> given string contains a substring that matches a given regular expression, which is in I-D.draft-ietf-jsonpath-iregexp form.


AggregateShare collect-flow: "application/dap-aggregate-share" <del> CollectReq collect-flow: "application/dap-collect-req" </del> <ins> CollectionReq collect-flow: "application/dap-collect-req" </ins> Collection collect-flow: "application/dap-collection"


for key exchange, AES-128-GCM for HPKE, HKDF over SHA2-256, and Ed25519 for signatures. <del> Values with the first byte 255 (decimal) are reserved for Private Use. </del> New ciphersuite values are assigned by IANA as described in iana- considerations.


PSK into the devices, or using a Trust On First Use (TOFU) approach with a device completely unprotected before the first login did take place.  Many devices have very limited UI.  For <del> example, they may only have a numeric keypad or even less number of buttons.  When the TOFU approach is not suitable, entering the key would require typing it on a constrained UI. </del> <ins> example, they may only have a numeric keypad or even fewer buttons.  When the TOFU approach is not suitable, entering the key would require typing it on a constrained UI. </ins> Some devices provision PSKs via an out-of-band, cloud-based syncing protocol. <del> Some secrets may be baked into or hardware or software device </del> <ins> Some secrets may be baked into hardware or software device </ins> components.  Moreover, when this is done at manufacturing time, secrets may be printed on labels or included in a Bill of Materials for ease of scanning or import.


that the load balancer will redirect the next Client Initial packet to a different server in that pool. <del> 7. </del> <ins> 8. </ins> Versioning in QUIC may change the protocol's behavior completely, except for the meaning of a few header fields that have been declared


Internet Transport Protocols" describes the impact of increased encryption of transport headers in general terms. <ins> It is also worth noting that considerations for heavily-encrypted transport protocols also come into play when streaming media is carried over IP-level VPNs and tunnels, with the additional consideration that an intermediary that does not possess credentials allowing decryption will not have visibility to the source and destination IP addresses of the packets being carried inside the tunnel. </ins> 7.2. Although the IETF has put considerable emphasis on end-to-end


is not present or does not validate, the server MUST abort the handshake.  Servers SHOULD NOT attempt to validate multiple binders; rather they SHOULD select a single PSK and validate solely the binder <del> that corresponds to that PSK.  See [client-hello-recording] for the security rationale for this requirement.  In order to accept PSK key establishment, the server sends a "pre_shared_key" extension indicating the selected identity. </del> <ins> that corresponds to that PSK.  See [client-hello-recording] and [psk- identity-exposure] for the security rationale for this requirement. In order to accept PSK key establishment, the server sends a "pre_shared_key" extension indicating the selected identity. </ins> Clients MUST verify that the server's selected_identity is within the range supplied by the client, that the server selected a cipher suite


recognition of the handshake, as illustrated in handshake.  It can also be inferred during the flow's lifetime, if the endpoints use the spin bit facility described below and in Section 17.3.1 of QUIC- <del> TRANSPORT. </del> <ins> TRANSPORT.  RTT measurement is available to unidirectional observers when the spin bit is enabled. </ins> 3.8.1.


Delimiter-separated formats, such as HTTP/1.1. Common Message Framers can be provided by the Transport Services <del> implementation, but an implemention ought to allow custom Message </del> <ins> implementation, but an implementation ought to allow custom Message </ins> Framers to be defined by the application or some other piece of software.  This section describes one possible interface for defining Message Framers as an example.


Each POST request to an aggregator contains a "PDATaskID".  If the aggregator does not recognize the task, i.e., it can't find a <del> "PDAParam" for which the derived task id matches the "PDATaskID", </del> <ins> "PDAParam" for which the derived task ID matches the "PDATaskID", </ins> then it aborts and alerts the peer with "unrecognized task". 4.


exchange-summary shows the multiple packets that form a single "flight" of messages being processed individually, to show what <del> incoming messages trigger different actions.  New handshake messages are requested after incoming packets have been processed.  This process varies based on the structure of endpoint implementations and the order in which packets arrive; this is intended to illustrate the steps involved in a single handshake exchange. </del> <ins> incoming messages trigger different actions.  This shows multiple "Get Handshake" invocations to retrieve handshake messages at different encryption levels.  New handshake messages are requested after incoming packets have been processed. exchange-summary shows one possible structure for a simple handshake exchange.  The exact process varies based on the structure of endpoint implementations and the order in which packets arrive. Implementations could use a different number of operations or execute them in other orders. </ins> 4.2.


used to fine-tune the eventually established connection.  These Connection Properties can also be used to monitor and fine-tune established connections.  The behavior of the selected protocol <del> stack(s) when sending Messages is controlled by Message Context Properties message-props. Collectively, Selection, Connection, and Message Context Properties can be referred to as Transport Properties.  All Transport Properties, regardless of the phase in which they are used, are organized within a single namespace.  This enables setting them as defaults in earlier stages and querying them in later stages: - Connection Properties can be set on Preconnections - Message Properties can be set on Preconnections and Connections - The effect of Selection Properties can be queried on Connections and Messages </del> <ins> stack(s) when sending Messages is controlled by Message Properties message-props. Collectively, Selection, Connection, and Message Properties can be referred to as Transport Properties.  All Transport Properties, regardless of the phase in which they are used, are organized within a single namespace.  This enables setting them as defaults in earlier stages and querying them in later stages: - Connection Properties can be set on Preconnections - Message Properties can be set on Preconnections and Connections - The effect of Selection Properties can be queried on Connections and Messages </ins> Transport Properties can have one of a set of data types:


performing subflows or subflows that regularly fail during use, in order to temporarily choose not to use these paths. <ins> 3.11. TCP Fast Open, described in RFC7413, has been introduced with the objective of gaining one RTT before transmitting data.  This is considered a valuable gain as very short connections are very common, especially for HTTP request/response schemes.  It achieves this by sending the SYN-segment together with data and allowing the server to reply immediately with data after the SYN/ACK.  RFC7413 secures this mechanism, by using a new TCP option that includes a cookie which is negotiated in a preceding connection. When using TCP Fast Open in conjunction with MPTCP, there are two key points to take into account, detailed hereafter. 3.11.1. When a TFO client first connects to a server, it cannot immediately include data in the SYN for security reasons RFC7413.  Instead, it requests a cookie that will be used in subsequent connections.  This is done with the TCP cookie request/response options, of resp. 2 bytes and 6-18 bytes (depending on the chosen cookie length). TFO and MPTCP can be combined provided that the total length of their options does not exceed the maximum 40 bytes possible in TCP: In the SYN: MPTCP uses a 4-bytes long MP_CAPABLE option.  The MPTCP and TFO options sum up to 6 bytes.  With typical TCP-options using up to 19 bytes in the SYN (24 bytes if options are padded at a word boundary), there is enough space to combine the MP_CAPABLE with the TFO Cookie Request. In the SYN+ACK: MPTCP uses a 12-bytes long MP_CAPABLE option, but now TFO can be as long as 18 bytes.  Since the maximum option length may be exceeded, it is up to the server to solve this by using a shorter cookie.  As an example, if we consider that 19 bytes are used for classical TCP options, the maximum possible cookie length would be of 7 bytes.  Note that the same limitation applies to subsequent connections, for the SYN packet (because the client then echoes back the cookie to the server).  Finally, if the security impact of reducing the cookie size is not deemed acceptable, the server can reduce the amount of other TCP-options by omitting the TCP timestamps (as outlined in app_options). 3.11.2. MPTCP uses, in the TCP establishment phase, a key exchange that is used to generate the Initial Data Sequence Numbers (IDSNs).  In particular, the SYN with MP_CAPABLE occupies the first octet of the data sequence space.  With TFO, one way to handle the data sent together with the SYN would be to consider an implicit DSS mapping that covers that SYN segment (since there is not enough space in the SYN to include a DSS option).  The problem with that approach is that if a middlebox modifies the TFO data, this will not be noticed by MPTCP because of the absence of a DSS-checksum.  For example, a TCP (but not MPTCP)-aware middlebox could insert bytes at the beginning of the stream and adapt the TCP checksum and sequence numbers accordingly.  With an implicit mapping, this would give to client and server a different view on the DSS-mapping, with no way to detect this inconsistency as the DSS checksum is not present. To solve this, the TFO data should not be considered part of the Data Sequence Number space: the SYN with MP_CAPABLE still occupies the first octet of data sequence space, but then the first non-TFO data byte occupies the second octet.  This guarantees that, if the use of DSS-checksum is negotiated, all data in the data sequence number space is checksummed.  We also note that this does not entail a loss of functionality, because TFO-data is always sent when only one path is active. 3.11.3. The following shows a few examples of possible TFO+MPTCP establishment scenarios. Before a client can send data together with the SYN, it must request a cookie to the server, as shown in Figure fig_tfocookie.  This is done by simply combining the TFO and MPTCP options. Once this is done, the received cookie can be used for TFO, as shown in Figure fig_tfodata.  In this example, the client first sends 20 bytes in the SYN.  The server immediately replies with 100 bytes following the SYN-ACK upon which the client replies with 20 more bytes.  Note that the last segment in the figure has a TCP sequence number of 21, while the DSS subflow sequence number is 1 (because the TFO data is not part of the data sequence number space, as explained in Section tfodata. In Figure fig_tfofallback, the server does not support TFO.  The client detects that no state is created in the server (as no data is acked), and now sends the MP_CAPABLE in the third ack, in order for the server to build its MPTCP context at then end of the establishment.  Now, the tfo data, retransmitted, becomes part of the data sequence mapping because it is effectively sent (in fact re- sent) after the establishment. It is also possible that the server acknowledges only part of the TFO data, as illustrated in Figure fig_tfopartial.  The client will simply retransmit the missing data together with a DSS-mapping. </ins> 4. In order to support multipath operation, the semantics of some TCP


server, can cause a situation in which the server cannot send when the client has no data to send and the anti-amplification limit is reached.  In order to avoid this causing a handshake deadlock, <del> clients SHOULD send a packet upon a probe timeout, as described in </del> <ins> clients MUST send a packet upon a probe timeout, as described in </ins> QUIC-RECOVERY.  If the client has no data to retransmit and does not <del> have Handshake keys, it SHOULD send an Initial packet in a UDP datagram of at least 1200 bytes.  If the client has Handshake keys, it SHOULD send a Handshake packet. </del> <ins> have Handshake keys, it MUST send an Initial packet in a UDP datagram of at least 1200 bytes.  If the client has Handshake keys, it SHOULD send a Handshake packet. </ins> A server might wish to validate the client address before starting the cryptographic handshake.  QUIC uses a token in the Initial packet


ACK-Eliciting Threshold, an endpoint can expect that the peer will not need to wait for its "max_ack_delay" period before sending an acknowledgement.  In such cases, the endpoint MAY therefore exclude <del> the peer's 'max_ack_delay' from its PTO calculation.  Note that this optimization requires some care in implementation, since it can cause premature PTOs under packet loss when "ignore_order" is enabled. </del> <ins> the peer's 'max_ack_delay' from its PTO calculation.  When Ignore Order is enabled and loss causes the peer to not receive enough packets to trigger an immediate acknowledgement, the receiver will wait 'max_ack_delay', increasing the chances of a premature PTO. Therefore, if Ignore Order is enabled, the PTO MUST be larger than the peer's 'max_ack_delay'. </ins> 9.


There are two primary use cases for this protocol. <del> The primary one is to prevent on-path network devices from </del> <ins> The primary use case is to prevent on-path network devices from </ins> interfering with native DNS operations.  This interference includes, but is not limited to, spoofing DNS responses, blocking DNS requests, and tracking.  HTTP authentication and proxy friendliness are


ClientEncryptedCH.encrypted_ch.  This matching procedure should be done using one of the following two checks: <del> Compare ClientEncryptedCH.config_digest against cryptographic hashes of known ECHConfig and choose the one that matches. </del> <ins> Compare ClientEncryptedCH.config_digest against digests of known ECHConfig and choose the one that matches. </ins> Use trial decryption of ClientEncryptedCH.encrypted_ch with known ECHConfig and choose the one that succeeds.


(OK) status code and the current contents of the account object. Once an account is deactivated, the server MUST NOT accept further <del> requests authorized by that account's key.  A server may take a variety of actions in response to an account deactivation, e.g., deleting data related to that account or sending mail to the account's contacts.  Servers SHOULD NOT revoke certificates issued by the deactivated account, since this could cause operational disruption for servers using these certificates.  ACME does not provide a way to reactivate a deactivated account. </del> <ins> requests authorized by that account's key.  The server SHOULD cancel any pending operations authorized by the account's key, such as certificate orders.  A server may take a variety of actions in response to an account deactivation, e.g., deleting data related to that account or sending mail to the account's contacts.  Servers SHOULD NOT revoke certificates issued by the deactivated account, since this could cause operational disruption for servers using these certificates.  ACME does not provide a way to reactivate a deactivated account. </ins> 7.4.


explanation for the overall connection rate drop is that hairpinning failed in some cases. <del> One potential mitigation, as discussed in privacy, is to not conceal candidates created from RFC4941 IPv6 addresses.  This permits connectivity even in large internal networks or where mDNS is disabled.  Future versions of this document will include experimental data regarding this option. </del> 5.2. As noted in description, ICE agents using the mDNS technique are


could send more data to an unwilling target than a CONNECT proxy. However, in practice denial of service attacks target open TCP ports so the TCP SYN-ACK does not offer much protection in real scenarios. <ins> While a proxy could potentially limit the number of UDP packets it is willing to forward until it has observed a response from the target, that is unlikely to provide any protection against denial of service attacks because such attacks target open UDP ports where the protocol running over UDP would respond, and that would be interpreted as willingness to accept UDP by the proxy. UDP sockets for UDP proxying have a different lifetime than TCP sockets for CONNECT, therefore implementors would be well served to follow the advice in handling if they base their UDP proxying implementation on a preexisting implementation of CONNECT. </ins> The security considerations described in HTTP-DGRAM also apply here.


encrypted-nonce) Pass 2: The load balancer decrypts the nonce octets using 128-bit <del> AES Electronic Codebook (ECB) mode, much like QUIC header protection, using the server-id intermediate as "nonce" for this </del> <ins> AES ECB mode, using the server-id intermediate as "nonce" for this </ins> pass.  The server-id intermediate octets are zero-padded to 16 octets.  AES-ECB encrypts this padded server-id intermediate using its key to generate a mask which it applies to the encrypted


Secret is called with four distinct transcripts; in a 1-RTT-only exchange with three distinct transcripts. <del> The complete transcript passed to Derive-Secret is always taken from the following sequence of handshake messages, starting at the first ClientHello and including only those messages that were sent: ClientHello, HelloRetryRequest, ClientHello, ServerHello, EncryptedExtensions, Server CertificateRequest, Server Certificate, Server CertificateVerify, Server Finished, EndOfEarlyData, Client Certificate, Client CertificateVerify, Client Finished. </del> If a given secret is not available, then the 0-value consisting of a string of Hash.length zero bytes is used.  Note that this does not mean skipping rounds, so if PSK is not in use Early Secret will still


then accepts B as trustworthy, it can choose to accept B as a Verifier for other Attesters. <ins> As another example, the Relying Party can establish trust in the Verifier by out of band establishment of key material, combined with a protocol like TLS to communicate.  There is an assumption that between the establishment of the trusted key material and the creation of the Evidence, that the Verifier has not been compromised. </ins> Similarly, the Relying Party also needs to trust the Relying Party Owner for providing its Appraisal Policy for Attestation Results, and in some scenarios the Relying Party might even require that the


5. <del> This section defines how to use the COSE format I-D.ietf-cose-msg to wrap and protect data in the unprotected CoAP message.  OSCOAP uses the COSE_Encrypt0 structure with an Authenticated Encryption with Additional Data (AEAD) algorithm. </del> <ins> This section defines how to use COSE I-D.ietf-cose-msg to wrap and protect data in the unprotected CoAP message.  OSCOAP uses the untagged COSE_Encrypt0 structure with an Authenticated Encryption with Additional Data (AEAD) algorithm.  The key lengths, IV lengths, and maximum sequence number are algorithm dependent.  The maximum sequence number SHALL be 2^(nonce length in bits - 1) - 1. </ins> The AEAD algorithm AES-CCM-64-64-128 defined in Section 10.2 of I- D.ietf-cose-msg is mandatory to implement.  For AES-CCM-64-64-128 the <del> length of Sender Key and Recipient Key SHALL be 128 bits, the length of nonce, Sender IV, and Recipient IV SHALL be 7 bytes, and the maximum Sequence Number SHALL be 2^56-1.  The nonce is constructed as described in Section 3.1 of I-D.ietf-cose-msg, i.e. by padding the Partial IV (Sequence Number in network byte order) with zeroes and XORing it with the context IV (Sender IV or Recipient IV). Since OSCOAP only makes use of a single COSE structure, there is no need to explicitly specify the structure, and OSCOAP uses the untagged version of the COSE_Encrypt0 structure (Section 2. of I- D.ietf-cose-msg).  If the COSE object has a different structure, the recipient MUST reject the message, treating it as malformed. </del> <ins> length of Sender Key and Recipient Key is 128 bits, the length of nonce, Sender IV, and Recipient IV is 7 bytes, and the maximum Sequence Number is 2^55 - 1. The nonce is constructed as described in Section 3.1 of I-D.ietf- cose-msg, i.e. by padding the partial IV (Sequence Number in network byte order) with zeroes and XORing it with the context IV (Sender IV or Recipient IV).  The first bit in the Sender IV or Recipient IV SHALL be flipped in responses. </ins> We denote by Plaintext the data that is encrypted and integrity protected, and by Additional Authenticated Data (AAD) the data that <del> is integrity protected only, in the COSE object. The fields of COSE_Encrypt0 structure are defined as follows (see example in sem-auth-enc). </del> <ins> is integrity protected only. </ins> <del> The "Headers" field is formed by: </del> <ins> The COSE Object SHALL be a COSE_Encrypt0 object with fields defined as follows </ins> <del> The "protected" field, which SHALL include: </del> <ins> The "protected" field includes: </ins> <del> The "Partial IV" parameter.  The value is set to the Sender Sequence Number.  The Partial IV is a byte string (type: bstr), and SHOULD be of minimum length needed to encode the sequence number. </del> <ins> The "Partial IV" parameter.  The value is set to the Sender Sequence Number.  The Partial IV SHALL be of minimum length needed to encode the sequence number.  This parameter SHALL be present in requests, and MAY be present in responses. </ins> <del> The "kid" parameter.  The value is set to the Sender ID (see sec-context-section). </del> <ins> The "kid" parameter.  The value is set to the Sender ID (see sec-context-section).  This parameter SHALL be present in requests. </ins> <del> The "unprotected" field, which SHALL be empty. </del> <ins> The "unprotected" field is empty. </ins> The "ciphertext" field is computed from the Plaintext (see plaintext) and the Additional Authenticated Data (AAD) (see AAD) <del> and encoded as a byte string (type: bstr), following Section 5.2 of I-D.ietf-cose-msg. </del> <ins> following Section 5.2 of I-D.ietf-cose-msg. The encryption process is described in Section 5.3 of I-D.ietf-cose- msg. </ins> 5.1. The Plaintext is formatted as a CoAP message without Header (see plaintext-figure) consisting of: <del> all CoAP Options present in the unprotected message which are encrypted (see coap-headers-and-options), in the order as given by the Option number (each Option with Option Header including delta to previous included encrypted option); and </del> <ins> all CoAP Options present in the unprotected message that are encrypted (see coap-headers-and-options).  The options are encoded as described in Section 3.1 of RFC7252, where the delta is the difference to the previously included encrypted option); and </ins> <del> the CoAP Payload, if present, and in that case prefixed by the one-byte Payload Marker (0xFF). </del> <ins> the Payload of unprotected CoAP message, if present, and in that case prefixed by the one-byte Payload Marker (0xFF). </ins> 5.2. <del> The Additional Authenticated Data ("Enc_structure") as described is Section 5.3 of I-D.ietf-cose-msg includes: the "context" parameter, which has value "Encrypted" </del> <ins> The external_aad SHALL be a CBOR array as defined below: </ins> <del> the "protected" parameter, which includes the "protected" part of the "Headers" field; the "external_aad" is a serialized CBOR array aad where the exact content is different in requests (external_aad_req) and responses (external_aad_resp).  It contains: ver: uint, contains the CoAP version number, as defined in Section 3 of code: uint, contains is the CoAP Code of the unprotected CoAP message, as defined in Section 3 of RFC7252. </del> <ins> where: </ins> <del> alg: int, contains the Algorithm from the security context used for the exchange (see sec-context-def-section); </del> <ins> ver: uint, contains the CoAP version number, as defined in Section 3 of RFC7252. </ins> <del> id : bstr, is the identifier for the endpoint sending the request and verifying the response; which means that for the endpoint sending the response, the id has value Recipient ID, while for the endpoint receiving the response, id has the value Sender ID. </del> <ins> code: uint, contains is the CoAP Code of the unprotected CoAP message, as defined in Section 3 of RFC7252. </ins> <del> seq : bstr, is the value of the "Partial IV" in the COSE object of the request (see Section 5). </del> <ins> alg: int, contains the Algorithm from the security context used for the exchange (see sec-context-def-section). </ins> <del> tag-previous-block: bstr, contains the AEAD Tag of the message containing the previous block in the sequence, as enumerated by Block1 in the case of a request and Block2 in the case of a response, if the message is fragmented using a block option RFC7959. </del> <ins> request_id : bstr, contains the identifier for the endpoint sending the request and verifying the response; which means that for the endpoint sending the response, the id has value Recipient ID, while for the endpoint receiving the response, id has the value Sender ID. </ins> <del> The encryption process is described in Section 5.3 of I-D.ietf-cose- msg. </del> <ins> request_seq : bstr, contains the value of the "Partial IV" in the COSE object of the request (see Section 5). </ins> 6.


key exchange, signatures, and ciphersuites. Protocols: TLS, DTLS, QUIC + TLS, MinimalT, tcpcrypt, IKEv2, SRTP <del> Session Cache The application provides the ability to save and retrieve session state (such as tickets, keying material, and server parameters) that may be used to resume the security session. </del> <ins> Session Cache Management The application provides the ability to save and retrieve session state (such as tickets, keying material, and server parameters) that may be used to resume the security session. </ins> Protocols: TLS, DTLS, QUIC + TLS, MinimalT Authentication Delegation


track documents need to be marked as recommended. If an item is marked as not recommended it does not necessarily mean <del> that it is flawed, rather, it indicates that either the item has not </del> <ins> that it is flawed; rather, it indicates that either the item has not </ins> been through the IETF consensus process, has limited applicability, or is intended only for specific use cases.


The final size is the amount of flow control credit that is consumed by a stream.  Assuming that every contiguous byte on the stream was sent once, the final size is the number of bytes sent.  More <del> generally, this is one higher than the largest byte offset sent on the stream. </del> <ins> generally, this is one higher than the offset of the byte with the largest offset sent on the stream, or zero if no bytes were sent. </ins> For a stream that is reset, the final size is carried explicitly in a RESET_STREAM frame.  Otherwise, the final size is the offset plus the


Note that, as a PSK may have a different lifetime than an update, it does not necessarily provide the same Forward Secrecy (FS) or Post- <del> Compromise Security (PCS) guarantees than a Commit message. </del> <ins> Compromise Security (PCS) guarantees as a Commit message. </ins> 7.10.


The server MUST ignore any updates to the "key", or "order" fields or any other fields it does not recognize.  The server MUST verify that the request is signed with the private key corresponding to the "key" <del> field of the request before updating the registration. </del> <ins> field of the request before updating the account object. </ins> For example, to update the contact information in the above account, the client could send the following request:


meet these requirements, it MUST abort the IP proxying request stream. <ins> Since setting the IP protocol to zero indicates all protocols are allowed, the requirements above make it possible for two routes to overlap when one has IP protocol set to zero and the other set to non-zero.  Endpoints MUST not send a ROUTE_ADVERTISEMENT capsule with routes that overlap in such a way.  Validating this requirement is OPTIONAL, but if an endpoint detects the violation, it MUST abort the IP proxying request stream. </ins> 5. The mechanism for proxying IP in HTTP defined in this document allows


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


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


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


With multi-homing, an adversary is able to correlate the communication interaction over the two paths, which adds further <del> privacy concerns. </del> <ins> privacy concerns.  The lack of a CID update mechanism makes this extension unsuitable for mobility scenarios where correlation must be considered. </ins> Importantly, the sequence number makes it possible for a passive attacker to correlate packets across CID changes.  Thus, even if a


The CA verifies that the client controls the requested domain name(s) by having the ACME client perform some action(s) that can only be done with control of the domain name(s).  For example, the <del> CA might require a client requesting example.com to provision DNS record under example.com or an HTTP resource under </del> <ins> CA might require a client requesting example.com to provision a DNS record under example.com or an HTTP resource under </ins> http://example.com. Once the CA is satisfied, it issues the certificate and the ACME


7.4. <del> The Initiator and the Responder must make sure that unprotected data and metadata do not reveal any sensitive information.  In particular, this applies to AT_KDF, AT_KDF_FS, AT_PUB_ECDHE, and AT_KDF_INPUT. AT_KDF, AT_KDF_FS, and AT_PUB_ECDHE reveals the used cryptographic </del> <ins> Unprotected data and metadata can reveal sensitive information and need to be selected with care.  In particular, this applies to AT_KDF, AT_KDF_FS, AT_PUB_ECDHE, and AT_KDF_INPUT.  AT_KDF, AT_KDF_FS, and AT_PUB_ECDHE reveals the used cryptographic </ins> algorithms, if these depend on the peer identity they leak <del> information about the peer.  AT_KDF_INPUT reveals the network name. An attacker observing network traffic may use such information for traffic flow analysis or to track an endpoint. </del> <ins> information about the peer.  AT_KDF_INPUT reveals the network name, although that is done on purpose to bind the authentication to a particular context. An attacker observing network traffic may use the above types of information for traffic flow analysis or to track an endpoint. </ins> 7.5.


A client that is unable to retry requests loses all requests that are in flight when the server closes the connection.  An endpoint MAY <del> send multiple GOAWAY frames indicating different identifiers, but MUST NOT increase the identifier value they send, since clients might already have retried unprocessed requests on another connection. Receiving a GOAWAY containing a larger identifier than previously received MUST be treated as a connection error of type H3_ID_ERROR. </del> <ins> send multiple GOAWAY frames indicating different identifiers, but the identifier in each frame MUST NOT be greater than the identifier in any previous frame, since clients might already have retried unprocessed requests on another connection.  Receiving a GOAWAY containing a larger identifier than previously received MUST be treated as a connection error of type H3_ID_ERROR. </ins> An endpoint that is attempting to gracefully shut down a connection can send a GOAWAY frame with a value set to the maximum possible


identity on a site they do trust (such as a social network.) Recently, a number of Web-based identity technologies (OAuth, <del> BrowserID, Facebook Connect), etc. have been developed.  While the </del> <ins> BrowserID, Facebook Connect etc.) have been developed.  While the </ins> details vary, what these technologies share is that they have a Web- based (i.e., HTTP/HTTPS) identity provider which attests to your identity.  For instance, if I have an account at example.org, I could


upper layer protocol MUST NOT write any record that exceeds the maximum record size of 2^14 bytes. <ins> The DTLS record layer SHOULD also allow the upper layer protocol to discover the amount of record expansion expected by the DTLS processing; alternately it MAY report PMTU estimates minus the estimated expansion from the transport layer and DTLS record framing. </ins> Note that DTLS does not defend against spoofed ICMP messages; implementations SHOULD ignore any such messages that indicate PMTUs below the IPv4 and IPv6 minimums of 576 and 1280 bytes respectively <del> The DTLS record layer SHOULD allow the upper layer protocol to discover the amount of record expansion expected by the DTLS processing. If there is a transport protocol indication (either via ICMP or via a refusal to send the datagram as in Section 14 of RFC4340), then the DTLS record layer MUST inform the upper layer protocol of the error. </del> <ins> If there is a transport protocol indication that the PMTU was exceeded (either via ICMP or via a refusal to send the datagram as in Section 14 of RFC4340), then the DTLS record layer MUST inform the upper layer protocol of the error. </ins> The DTLS record layer SHOULD NOT interfere with upper layer protocols performing PMTU discovery, whether via RFC1191 or RFC4821 mechanisms.


extension.  It MUST NOT save the "retry_config" value in EncryptedExtensions. <del> [[OPEN ISSUE: Depending on what we do for issue#450, it may be appropriate to change the client behavior if the HRR extension is present.]] </del> Offering a GREASE extension is not considered offering an encrypted ClientHello for purposes of requirements in real-ech.  In particular, the client MAY offer to resume sessions established without ECH.


clients that they are behind a captive-portal enforcement device and how to contact an API for more information. <ins> This document replaces RFC 7710 RFC7710. </ins> 1.1. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",


renders 5-tuple based filtering insufficient and requires more state to be maintained by DDoS defense systems.  For the common case of NAT rebinding, DDoS defense systems can detect a change in the client's <del> endpoint address by linking flows based on the first 8 bytes of the server's connection IDs, provided the server is using at least 8- bytes-long connection IDs.  QUIC's linkability resistance ensures that a deliberate connection migration is accompanied by a change in the connection ID and necessitates that connection ID-aware DDoS defense system must have the same information about connection IDs as the load balancer I-D.ietf-quic-load-balancers.  This may be complicated where mitigation and load balancing environments are logically separate. </del> <ins> endpoint address by linking flows based on the server's connection IDs.  QUIC's linkability resistance ensures that a deliberate connection migration is accompanied by a change in the connection ID. </ins> It is questionable whether connection migrations must be supported during a DDoS attack.  If the connection migration is not visible to


is represented as an encoded UncompressedPointRepresentation struct, as defined in RFC8446. <ins> 5.1.2. The signature algorithm specified in the ciphersuite is the mandatory algorithm to be used for signatures in FramedContentAuthData and the tree signatures.  It MUST be the same as the signature algorithm specified in the credentials in the leaves of the tree (including the leaf node information in KeyPackages used to add new members). </ins> The signatures used in this document are encoded as specified in RFC8446.  In particular, ECDSA signatures are DER-encoded and EdDSA signatures are defined as the concatenation of "r" and "s" as


implementation should store the properties in storage common to all protocols, and notify all protocol instances in the Protocol Stack whenever the properties have been modified by the application.  For <del> protocol-specfic properties, such as the User Timeout that applies to TCP, the Transport Services implementation only needs to update the relevant protocol instance. </del> <ins> Protocol-specific Properties, such as the User Timeout that applies to TCP, the Transport Services implementation only needs to update the relevant protocol instance. </ins> If an error is encountered in setting a property (for example, if the application tries to set a TCP-specific property on a Connection that


Endpoints MUST NOT send this extension in a TLS connection that does not use QUIC (such as the use of TLS with TCP defined in TLS13).  A <del> fatal unsupported_extension alert MUST be sent if this extension is received when the transport is not QUIC. </del> <ins> fatal unsupported_extension alert MUST be sent by an implementation that supports this extension if the extension is received when the transport is not QUIC. </ins> 8.3.


Signature = I2OSP(R, n) | I2OSP(S, n) where n = ceiling(key_length / 8) <del> 9.2.1. </del> <ins> 9.1.1. </ins> On of the issues that needs to be discussed is substitution attacks. There are two different things that can potentially be substituted in