the threat model of RFC3552 applies.  In particular, JavaScript can call the API in any order and with any inputs, including malicious ones.  This is particularly relevant when we consider the SDP that is <del> passed to setLocalDescription().  While correct API usage requires that the application pass in SDP that was derived from createOffer() or createAnswer(), there is no guarantee that applications do so. The JSEP implementation MUST be prepared for the JavaScript to pass in bogus data instead. </del> <ins> passed to setLocalDescription.  While correct API usage requires that the application pass in SDP that was derived from createOffer or createAnswer, there is no guarantee that applications do so.  The JSEP implementation MUST be prepared for the JavaScript to pass in bogus data instead. </ins> Conversely, the application programmer needs to be aware that the JavaScript does not have complete control of endpoint behavior.  One


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 <del> 14 BCP14 when, and only when, they appear in all capitals, as shown here. </del> <ins> 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </ins> Definitions of terms that are used in this document:


If the RS needs to, it can post a set of resources as described in the Resource Access Rights section of I-D.ietf-gnap-core-protocol to <del> the AS's resource registration endpoint. </del> <ins> the AS's resource registration endpoint along with information about what the RS will need to validate the request. REQUIRED.  The list of access rights associated with the request in the format described in the "Resource Access Rights" section of I-D.ietf-gnap-core-protocol. REQUIRED.  The identification used to authenticate the resource server making this call, either by value or by reference as described in authentication. OPTIONAL.  The token format required to access the identified resource.  If the field is omitted, the token format is at the discretion of the AS.  If the AS does not support the requested token format, the AS MUST return an error to the RS. OPTIONAL.  If present and set to "true", the RS expects to make a token introspection request as described in introspection.  If absent or set to "false", the RS does not anticipate needing to make an introspection request for tokens relating to this resource set. </ins> The RS MUST identify itself with its own key and sign the request. <del> The AS responds with a handle appropriate to represent the resources list that the RS presented. </del> <ins> The AS responds with a reference appropriate to represent the resources list that the RS presented in its request as well as any additional information the RS might need in future requests. REQUIRED.  A single string representing the list of resources registered in the request.  The RS MAY make this handle available to a client instance as part of a discovery response as described in I-D.ietf-gnap-core-protocol or as documentation to client software developers. </ins> <del> The RS MAY make this handle available as part of a discovery response as described in I-D.ietf-gnap-core-protocol or as documentation to developers. </del> <ins> OPTIONAL.  An instance identifier that the RS can use to refer to itself in future calls to the AS, in lieu of sending its key by value. </ins> <del> [[ See issue #117 [2] ]] </del> <ins> OPTIONAL.  The introspection endpoint of this AS, used to allow the RS to perform token introspection. </ins> 4.


6. dtls-example2 shows an example exchange where a connection id is used <del> uni-directionally from the client to the server. </del> <ins> uni-directionally from the client to the server.  To indicate that a connection_id has zero length we use the term 'connection_id=empty'. Note: In the example exchange the CID is included in the record layer once encryption is enabled.  In DTLS 1.2 only one handshake message is encrypted, namely the Finished message.  Since the example shows how to use the CID for payloads sent from the client to the server only the record layer payload containing the Finished messagen contains a CID.  Application data payloads sent from the client to the server contain a CID in this example as well. </ins> 7.


those datagrams are cryptographically authenticated).  On-path adversaries can, in general, pose a harm to connectivity. <ins> When using DTLS 1.3, peers SHOULD avoid using the same CID on multiple network paths, in particular when initiating connection migration or when probing a new network path, as described in path- validation, as an adversary can otherwise correlate the communication interaction across those different paths.  DTLS 1.3 provides mechanisms to ensure that a new CID can always be used.  In general, an endpoint should proactively send a RequestConnectionId message to ask for new CIDs as soon as the pool of spare CIDs is depleted (or goes below a threshold).  Also, in case a peer might have exhausted available CIDs, a migrating endpoint could include NewConnectionId in packets sent on the new path to make sure that the subsequent path validation can use fresh CIDs. Note that DTLS 1.2 does not offer the ability to request new CIDs during the session lifetime since CIDs have the same life-span of the connection.  Therefore, deployments that use DTLS in multihoming environments SHOULD refuse to use CIDs with DTLS 1.2 and switch to DTLS 1.3 if the correlation privacy threat is a concern. </ins> 10. [[to-be-removed: RFC Editor: please replace RFCthis with this RFC


The 50 is based on 50 packets per second, the 40 is based on an estimate of total header size, the 1000 changes the unit from kbps to bps (as required by TIAS), and the 0.95 is to allocate <del> 5% to RTCP.  If more accurate control of bandwidth is needed, "TIAS" should be used instead of "AS". </del> <ins> 5% to RTCP.  "TIAS" is used in preference to "AS" because it provides more accurate control of bandwidth. </ins> For any "RR" or "RS" bandwidth values, handle as specified in RFC3556, Section 2.


entities that are authorized to send messages on the channel.  The push service does not require access to this public key. <ins> The Topic header field exposes information that allows more granular correlation of push messages on the same subject.  This might be used to aid traffic analysis of push messages by the push service. </ins> 9.2. Push message confidentiality does not ensure that the identity of who


cause a sender to increase their send rate.  This increase could result in congestion and loss. <del> A sender MAY attempt to detect suppression of reports by marking occasional packets that they send with ECN-CE.  If a packet sent with ECN-CE is not reported as having been CE marked when the packet is acknowledged, then the sender SHOULD disable ECN for that path. </del> <ins> A sender can detect suppression of reports by marking occasional packets that it sends with an ECN-CE marking.  If a packet sent with an ECN-CE marking is not reported as having been CE marked when the packet is acknowledged, then the sender can disable ECN for that path by not setting ECT codepoints in subsequent packets sent on that path RFC3168. </ins> Reporting additional ECN-CE markings will cause a sender to reduce their sending rate, which is similar in effect to advertising reduced


Each distinct instant in time can be represented in a descriptive text format using a timestamp, and ISO8601 standardizes a widely- <del> adopted timestamp format, which forms the basis of RFC3339.  However, this format only allows timestamps to contain very little additional relevant information, which means that, beyond that, any contextual information related to a given timestamp needs to be either handled separately or attached to it in a non-standard manner. </del> <ins> adopted timestamp format, which forms the basis of the Internet Date/ Time Format RFC3339.  However, this format only allows timestamps to contain very little additional relevant information, which means that, beyond that, any contextual information related to a given timestamp needs to be either handled separately or attached to it in a non-standard manner. </ins> This is already a pressing issue for applications that handle each instant with an associated time zone name, to take into account


the secrets themselves are protected by HPKE encryption. Note that under that compromise scenario, authentication is not <del> affected in neither of these cases.  As every member of the group can </del> <ins> affected in either of these cases.  As every member of the group can </ins> compute the AEAD keys for all the chains (they have access to the Group Secrets) in order to send and receive messages, the authentication provided by the AEAD encryption layer of the common


tuple, as shown in transport-parameter-encoding-fig: The Transport Parameter Length field contains the length of the <del> Transport Parameter Value field. </del> <ins> Transport Parameter Value field in bytes. </ins> QUIC encodes transport parameters into a sequence of bytes, which is then included in the cryptographic handshake.


Different challenges allow the server to obtain proof of different aspects of control over an identifier.  In some challenges, like HTTP and TLS SNI, the client directly proves its ability to do certain <del> things related to the identifier.  In the Proof of Possession challenge, the client proves historical control of the identifier, by reference to a prior authorization transaction or certificate. The choice of which challenges to offer to a client under which circumstances is a matter of server policy.  A CA may choose different sets of challenges depending on whether it has interacted with a domain before, and how.  For example: New domain with no known certificates: Domain Validation (HTTP or TLS SNI) Domain for which known certs exist from other CAs: DV + Proof of Possession of previous CA-signed key Domain with a cert from this CA, lost account key: DV + PoP of ACME-certified Subject key Domain with a cert from this CA, all keys and recovery mechanisms lost: Out of band proof of authority for the domain </del> <ins> things related to the identifier.  The choice of which challenges to offer to a client under which circumstances is a matter of server policy. </ins> The identifier validation challenges described in this section all relate to validation of domain names.  If ACME is extended in the


Upon transmission or receipt of a fatal alert message, both parties immediately close the connection.  Whenever an implementation encounters a condition which is defined as a fatal alert, it MUST <del> send the appropriate alert prior to closing the connection. </del> <ins> send the appropriate alert prior to closing the connection.  All alerts defined in this section below, as well as all unknown alerts are universally considered fatal as of TLS 1.3 (see alert-protocol). </ins> The following error alerts are defined: <del> An inappropriate message was received.  This alert is always fatal and should never be observed in communication between proper implementations. </del> <ins> An inappropriate message was received.  This alert should never be observed in communication between proper implementations. </ins> This alert is returned if a record is received which cannot be deprotected.  Because AEAD algorithms combine decryption and verification, this alert is used for all deprotection failures. <del> This alert is always fatal and should never be observed in communication between proper implementations (except when messages were corrupted in the network). </del> <ins> This alert should never be observed in communication between proper implementations, except when messages were corrupted in the network. </ins> A TLSCiphertext record was received that had a length more than 2^14 + 256 bytes, or a record decrypted to a TLSPlaintext record <del> with more than 2^14 bytes.  This alert is always fatal and should never be observed in communication between proper implementations (except when messages were corrupted in the network). </del> <ins> with more than 2^14 bytes.  This alert should never be observed in communication between proper implementations, except when messages were corrupted in the network. </ins> Reception of a "handshake_failure" alert message indicates that the sender was unable to negotiate an acceptable set of security <del> parameters given the options available.  This alert is always fatal. </del> <ins> parameters given the options available. </ins> A certificate was corrupt, contained signatures that did not verify correctly, etc.


but is not limited to, spoofing DNS responses, blocking DNS requests, and tracking.  HTTP authentication and proxy friendliness are expected to make this protocol function in some environments where <del> DNS directly on TLS (RFC7858) would not. </del> <ins> unsecured DNS (DNS) or DNS directly on TLS (RFC7858) would not. </ins> A secondary use case is web applications that want to access DNS information.  Standardizing an HTTPS mechanism allows this to be done


9.1.6. <del> Integer This property specifies how long to wait before aborting a Connection during establishment, or before deciding that a Connection has failed after establishment.  It is given in seconds. </del> <ins> This property specifies how long to wait before deciding that a Connection has failed after establishment. </ins> 9.1.7.


3.8. <del> In order to reduce round trips and the number of messages or to </del> <ins> In order to reduce round trips and the number of messages, or to </ins> simplify processing, external security applications may be integrated into EDHOC by transporting authorization related data in the messages. <del> EDHOC allows opaque external authorization data (EAD) to be sent in each of the four EDHOC messages (EAD_1, EAD_2, EAD_3, EAD_4). </del> <ins> EDHOC allows processing of external authorization data (EAD) to be defined in a separate specification, and sent in dedicated fields of the four EDHOC messages (EAD_1, EAD_2, EAD_3, EAD_4).  EAD is opaque data to EDHOC. </ins> <del> External authorization data is a CBOR sequence (see CBOR) consisting of one or more (ead_label, ead_value) pairs as defined below: </del> <ins> Each EAD field is a CBOR sequence (see CBOR) consisting of one or more EAD items (ead_label, ead_value) as defined below: </ins> A security application using external authorization data need to <del> register an ead_label, specify the ead_value format for each message (see iana-ead), and describe processing and security considerations. </del> <ins> register a positive ead_label and the associated ead_value format for each EAD item it uses (see iana-ead), and describe processing and security considerations.  Each application registers their own EAD items and defines associated operations.  The application may define multiple uses of certain EAD items, e.g., the same EAD item may be used in different EDHOC messages with the same application. An EAD item can be either critical or non-critical, determined by the sign of the ead_label in the transported EAD item included in the EDHOC message.  Using the registered positive value indicates that the EAD item is non-critical.  The corresponding negative value indicates that the EAD item is critical. ead_label = 0 MUST NOT be used. If an endpoint receives a critical EAD item it does not recognize or a critical EAD item that contains information that it cannot process, the EDHOC protocol MUST be discontinued.  A non-critical EAD item can be ignored. The specification registring a new EAD label needs to describe under what conditions the EAD item is critical or non-critical. </ins> The EAD fields of EDHOC must not be used for generic application <del> data.  Examples of the use of EAD is provided in ead-appendix. </del> <ins> data.  Examples of the use of EAD are provided in ead-appendix. </ins> 3.9.


Abstract This document provides an overview of operational networking issues <del> that pertain to quality of experience in delivery of video and other </del> <ins> that pertain to quality of experience in streaming of video and other </ins> high-bitrate media over the internet. 1.


the inclusion of uppercase field names, or <del> the inclusion of invalid characters in field names or values </del> <ins> the inclusion of invalid characters in field names or values. </ins> A request or response that includes a payload body can include a Content-Length header field.  A request or response is also malformed


Various academic works have analyzed MLS and the different security guarantees it aims to provide.  The security of large parts of the <del> protocol has been analyzed by [BBN19] (draft 7), [ACDT21] (draft 11) and [AJM20] (draft 12). </del> <ins> protocol has been analyzed by BBN19 (draft 7), ACDT21 (draft 11) and AJM20 (draft 12). </ins> Individual components of various drafts of the MLS protocol have been analyzed in isolation and with differing adversarial models, for <del> example, [BBR18], [ACDT19], [ACCKKMPPWY19], [AJM20] and [ACJM20] </del> <ins> example, BBR18, ACDT19, ACCKKMPPWY19, AJM20, ACJM20, and AHKM21 </ins> analyze the ratcheting tree as the sub-protocol of MLS that <del> facilitates key agreement, while [BCK21] analyzes the key derivation paths in the ratchet tree and key schedule.  Finally, [CHK21] analyzes the authentication and cross-group healing guarantees provided by MLS. </del> <ins> facilitates key agreement, while BCK21 analyzes the key derivation paths in the ratchet tree and key schedule.  Finally, CHK21 analyzes the authentication and cross-group healing guarantees provided by MLS. </ins> 8. <del> ACCKKMPPWY19: https://eprint.iacr.org/2019/1489 ACDT19: https://eprint.iacr.org/2019/1189 ACDT21: https://eprint.iacr.org/2021/1083 ACJM20: https://eprint.iacr.org/2020/752 AHKM21: https://eprint.iacr.org/2021/1456 AJM20: https://eprint.iacr.org/2020/1327 BBN19: https://hal.laas.fr/INRIA/hal-02425229 BBR18: https://hal.inria.fr/hal-02425247 BCK21: https://eprint.iacr.org/2021/137 CHK21: https://www.usenix.org/system/files/sec21-cremers.pdf 9. </del> This document makes no requests of IANA.


A PATH_RESPONSE frame received on any network path validates the path on which the PATH_CHALLENGE was sent. <del> If the PATH_CHALLENGE frame that resulted in successful path validation was sent in a datagram that was not expanded to at least 1200 bytes, the endpoint can regard the address as valid.  The endpoint is then able to send more than three times the amount of </del> <ins> If an endpoint sends a PATH_CHALLENGE frame in a datagram that is not expanded to at least 1200 bytes, and if the response to it validates the peer address, the path is validated but not the path MTU.  As a result, the endpoint can now send more than three times the amount of </ins> data that has been received.  However, the endpoint MUST initiate another path validation with an expanded datagram to verify that the <del> path supports required MTU. </del> <ins> path supports the required MTU. </ins> Receipt of an acknowledgment for a packet containing a PATH_CHALLENGE frame is not adequate validation, since the acknowledgment can be


(e.g.  I-D.ietf-httpbis-priority. A Transport Services system gives no guarantees about how its <del> expression of relative priorities will be realized; for example, if a transport stack that only provides a single in-order reliable stream is selected, prioritization information can only be ignored. However, the Transport Services system will seek to ensure that performance of relatively-prioritized connections and messages is not worse with respect to those connections and messages than an equivalent configuration in which all prioritization properties are left at their defaults. </del> <ins> expression of relative priorities will be realized.  However, the Transport Services system will seek to ensure that performance of relatively-prioritized connections and messages is not worse with respect to those connections and messages than an equivalent configuration in which all prioritization properties are left at their defaults. </ins> The Transport Services interface does order Connection Priority over the Priority Message Property.  In the absense of other externalities


increased in either slow start or congestion avoidance.  This can happen due to insufficient application data or flow control limits. <del> A sender MAY use the pipeACK method described in Section 4.3 of </del> <ins> A sender can use the pipeACK method described in Section 4.3 of </ins> RFC7661 to determine if the congestion window is sufficiently utilized.


output of AEAD_AES_128_GCM AEAD used with the following inputs: The secret key, K, is 128 bits equal to <del> 0x4d32ecdb2a2133c841e4043df27d4430. </del> <ins> 0xccce187ed09a09d05728155a6cb96be1. </ins> <del> The nonce, N, is 96 bits equal to 0x4d1611d05513a552c587d575. </del> <ins> The nonce, N, is 96 bits equal to 0xe54930f97f2136f0530a8c1c. </ins> The plaintext, P, is empty.


If TLS experiences an error, it generates an appropriate alert as defined in Section 6 of TLS13. <del> A TLS alert is turned into a QUIC connection error by converting the one-byte alert description into a QUIC error code.  The alert </del> <ins> A TLS alert is converted into a QUIC connection error.  The alert </ins> description is added to 0x100 to produce a QUIC error code from the range reserved for CRYPTO_ERROR.  The resulting value is sent in a QUIC CONNECTION_CLOSE frame of type 0x1c.


The exporter value is computed as: <del> Where Secret is either the early_exporter_main_secret or the exporter_main_secret.  Implementations MUST use the exporter_main_secret unless explicitly specified by the application. The early_exporter_main_secret is defined for use in settings where an exporter is needed for 0-RTT data.  A separate interface for the early exporter is RECOMMENDED; this avoids the exporter user accidentally using an early exporter when a regular one is desired or vice versa. </del> <ins> Where Secret is either the early_exporter_secret or the exporter_secret.  Implementations MUST use the exporter_secret unless explicitly specified by the application.  The early_exporter_secret is defined for use in settings where an exporter is needed for 0-RTT data.  A separate interface for the early exporter is RECOMMENDED; this avoids the exporter user accidentally using an early exporter when a regular one is desired or vice versa. </ins> If no context is provided, the context_value is zero length. Consequently, providing no context computes the same value as


4.1.1. In direct encryption mode, a shared secret between the sender and the <del> recipient is used as the CEK.  For direct encryption mode, no recipient structure is built.  All of the information about the key is placed in either the protected or unprotected fields at the content level.  When direct encryption mode is used, it MUST be the only mode used on the message.  It is a massive security leak to have both direct encryption and a different key management mode on the same message. </del> <ins> recipient is used as the CEK.  When direct encryption mode is used, it MUST be the only mode used on the message.  It is a massive security leak to have both direct encryption and a different key management mode on the same message. </ins> For JOSE, direct encryption key management is the only key management method allowed for doing MAC-ed messages.  In COSE, all of the key


to specify options for simple integrity protection via checksums.  A value of 0 means that no checksum is required, and -1 means that the entire Message is protected by a checksum.  Only full coverage is <del> guaranteed, any other requests are advisory. </del> <ins> guaranteed, any other requests are advisory, meaning that full coverage is applied anyway. </ins> 7.4.7.


(this document) <del> Martin Thomson (martin.thomson@gmail) or the Web Push WG (webpush@ietf.org) </del> <ins> The Web Push WG (webpush@ietf.org) </ins>


5.3. <del> A QUIC connection is a stateful interaction between a client and server, the primary purpose of which is to support the exchange of data by an application protocol.  Streams (streams) are the primary means by which an application protocol exchanges information. Each connection starts with a handshake phase, during which client and server establish a shared secret using the cryptographic handshake protocol QUIC-TLS and negotiate the application protocol. The handshake (handshake) confirms that both endpoints are willing to communicate (validate-handshake) and establishes parameters for the connection (transport-parameters). An application protocol can also operate in a limited fashion during the handshake phase.  0-RTT allows application data to be sent by a client before receiving any response from the server.  However, 0-RTT lacks certain key security guarantees.  In particular, there is no protection against replay attacks in 0-RTT; see QUIC-TLS. Separately, a server can also send application data to a client before it receives the final cryptographic handshake messages that allow it to confirm the identity and liveness of the client.  These capabilities allow an application protocol to offer the option to trade some security guarantees for reduced latency. The use of connection IDs (connection-id) allows connections to migrate to a new network path, both as a direct choice of an endpoint and when forced by a change in a middlebox.  migration describes mitigations for the security and privacy issues associated with migration. For connections that are no longer needed or desired, there are several ways for a client and server to terminate a connection (termination). 5.4. </del> There are certain operations that an application MUST be able to perform when interacting with the QUIC transport.  This document does not specify an API, but any implementation of this version of QUIC


initially issued. At a high level, the Privacy Pass architecture consists of two <del> protocols: issuance and redemption.  The issuance protocol runs between an endpoint referred to as a Client and two functions in the Privacy Pass architecture: Attestation and Issuance.  These two network functions can be implemented by the same protocol participant, but can also be implemented separately.  The entity that implements Issuance, referred to as the Issuer, is responsible for issuing tokens in response to requests from Clients.  The entity that implements Attestation, referred to as the Attester, is responsible for attesting to properties about the Client for which tokens are issued.  The Issuer needs to be trusted by the server that later redeems the token.  Attestation can be performed by the Issuer or by an Attester that is trusted by the Issuer.  Clients might prefer to select different Attesters, separate from the Issuer, to be able to use preferred authentication methods or to improve privacy by not directly communicating with an Issuer.  Depending on the attestation, Attesters can store state about a Client, such as the number of overall tokens issued thus far.  As an example of an issuance protocol, in the original Privacy Pass protocol PPEXT, tokens were only issued to Clients that solved CAPTCHAs.  In this context, the Attester attested that some client solved a CAPTCHA and the resulting token produced by the Issuer was proof of this fact. The redemption protocol runs between Client and Origin (server).  It allows Origins to challenge Clients to present one or more tokens for </del> <ins> protocols: issuance and redemption.  The redemption protocol AUTHSCHEME runs between Client and Origin (server).  It allows Origins to challenge Clients to present one or more tokens for </ins> authorization.  Depending on the type of token, e.g., whether or not it can be cached, the Client either presents a previously obtained <del> token or invokes the issuance protocol to acquire one for authorization. The issuance and redemption protocols operate in concert as shown in the figure below. </del> <ins> token or invokes an issuance protocol, such as ISSUANCE, to acquire a token to present as authorization. </ins> This document describes requirements for both issuance and redemption <del> protocols.  It also provides recommendations on how the architecture should be deployed to ensure the privacy of clients and the security of all participating entities. The privacypass working group is working on AUTHSCHEME as an instantiation of a redemption protocol and ISSUANCE as an instantiation of the issuance protocol. </del> <ins> protocols and how they interact.  It also provides recommendations on how the architecture should be deployed to ensure the privacy of clients and the security of all participating entities. </ins> 2.


MUST abruptly terminate the corresponding stream with a stream error of type H3_GENERAL_PROTOCOL_ERROR. <del> 4.3. </del> <ins> 4.4. </ins> The DATAGRAM capsule (type=0x02) allows an endpoint to send a datagram frame over an HTTP stream.  This is particularly useful when


authentication mechanisms, ciphersuites, and infrastructure functionalities. <del> 5.10. </del> <ins> 5.9. </ins> It is important that multiple versions of MLS be able to coexist in the future.  Thus, MLS offers a version negotiation mechanism; this


a digital signature), multiple recipients, encryption of manifests (in comparison to firmware images).]] <ins> The following manifests examplify how to deliver the encrypted firmware and its encryption info to the Devices. The examples are signed using the following ECDSA secp256r1 key: The corresponding public key can be used to verify these examples: Each example uses SHA256 as the digest function. 9.1. Diagnostic notation of the SUIT Manifest: In hex: </ins> 10. The algorithms described in this document assume that the party


If the Client already has a token available that satisfies the token challenge, e.g., because the Client has a cache of previously issued tokens, it can skip to step-redemption and <del> redeem its token. </del> <ins> redeem its token; see hoarding for security considerations of cached tokens. </ins> If the Client does not have a token available and decides it wants to obtain one (or more) bound to the token challenge, it then


13.27. Several parts of the GNAP process make use of unguessable randomized <del> values, such as nonces, tokens, and randomized URIs.  Since these values are intended to be unique, a sufficiently powerful attacker could make a large number of requests to trigger generation of randomized values in an attempt to exhaust the random number </del> <ins> values, such as nonces, tokens, user codes, and randomized URIs. Since these values are intended to be unique, a sufficiently powerful attacker could make a large number of requests to trigger generation of randomized values in an attempt to exhaust the random number </ins> generation space.  While this attack is particularly applicable to the AS, client software could likewise be targeted by an attacker triggering new grant requests against an AS.


Source Address Validation (SAV): The handshake protocol may interact with the transport protocol or application to validate the address of the remote peer that has sent data.  This involves <del> sending a cookie exchange to avoid DoS attacks. </del> <ins> sending a cookie exchange to avoid DoS attacks.  (This list omits protocols which depend on TCP and therefore implicitly perform SAV.) </ins> DTLS


of efficiency.  This is not a strict requirement.  The default is to not have this option. <del> Notification of special errors (excessive retransmissions, ICMP error message arrival): This boolean property specifies whether an application considers it useful to be informed in case sent data was retransmitted more often than a certain threshold, or when an ICMP error message arrives.  This property applies to Connections and Connection Groups.  This is not a strict requirement.  The default is to have this option. </del> <ins> Notification of excessive retransmissions: This boolean property specifies whether an application considers it useful to be informed in case sent data was retransmitted more often than a certain threshold.  This property applies to Connections and Connection Groups.  This is not a strict requirement.  The default is to have this option. Notification of ICMP error message arrival: This boolean property specifies whether an application considers it useful to be informed when an ICMP error message arrives.  This property applies to Connections and Connection Groups.  This is not a strict requirement.  The default is to have this option. </ins> Control checksum coverage on sending or receiving: This boolean property specifies whether the application considers it useful to


Each "a=mid" line MUST stay the same. <del> Each "a=ice-ufrag" and "a=ice-pwd" line MUST stay the same. </del> <ins> Each "a=ice-ufrag" and "a=ice-pwd" line MUST stay the same unless the "IceRestart" option (sec.options-handling was specified.  Note that it's not clear why you would actually want to do this, since at this point ICE has not yet started and is thus unlikely to need a restart. </ins> For MediaStreamTracks that are still present, the "a=msid", "a=ssrc", and "a=ssrc-group" lines MUST stay the same.


transported depends on lower layers, which need to enable error messages to be sent and processed as intended. <del> All error messages in EDHOC are fatal.  After sending an error message, the sender MUST discontinue the protocol.  The receiver SHOULD treat an error message as an indication that the other party likely has discontinued the protocol.  But as the error message is not authenticated, a received error messages might also have been sent by an attacker and the receiver MAY therefore try to continue the protocol. </del> <ins> Errors in EDHOC are fatal.  After sending an error message, the sender MUST discontinue the protocol.  The receiver SHOULD treat an error message as an indication that the other party likely has discontinued the protocol.  But as the error message is not authenticated, a received error message might also have been sent by an attacker and the receiver MAY therefore try to continue the protocol. </ins> error SHALL be a CBOR Sequence (see CBOR) as defined below


order to allow the inclusion of an optional suffix. The extended date/time format is described by the rule "date-time- <del> ext".  "date-time" is imported from RFC3339, "ALPHA" and "DIGIT" from RFC5234. </del> <ins> ext".  "date-time" and "time-numoffset" are imported from RFC3339, "ALPHA" and "DIGIT" from RFC5234. </ins> Note that a "time-zone" is syntactically similar to a "suffix-tag", but does not include an equals sign.  This special case is only


7.3.4. <del> This method is indicated by "dpop" in the "proof" field.  The signer creates a Demonstration of Proof-of-Possession signature header as described in I-D.ietf-oauth-dpop section 2.  In addition, this specification defines the following fields to be added to the DPoP payload: Digest of the request body as the value of the Digest header defined in RFC3230.  When a request contains a message body, such as a POST or PUT request, this field is REQUIRED. In this example, the request body is the following JSON object: ~~~ { "access_token": { "access": [ "dolphin-metadata" ] }, "interact": { "start": ["redirect"], "finish": { "method": "redirect", "uri": "https://client.foo/callback", "nonce": "VJLO6A4CAYLBXHTR0KRO" } }, "client": { "proof": "dpop", "key": { "jwk": { "kid": "gnap-rsa", "kty": "RSA", "e": "AQAB", "alg": "RS256", "n": "hYOJ- XOKISdMMShn_G4W9m20mT0VWtQBsmBBkI2cmRt4Ai8Bf YdHsFzAtYKOjpBR1RpKpJmVKxIGNy0g6Z3ad2XYsh8KowlyVy8IkZ8NMwSrcUIBZG YXjHpwjzvfGvXH_5KJlnR3_uRUp4Z4Ujk2bCaKegDn11V2vxE41hqaPUnhRZxe0jR ETddzsE3mu1SK8dTCROjwUl14mUNo8iTrTm4n0qDadz8BkPo-uv4BC0bunS0K3bA_ 3UgVp7zBlQFoFnLTO2uWp_muLEWGl67gBq9MO3brKXfGhi3kOzywzwPTuq-cVQDyE N7aL0SxCb3Hc4IdqDaMg8qHUyObpPitDQ" } } "display": { "name": "My Client Display Name", "uri": "https://client.foo/" }, } } ~~~ The JOSE header contains the following parameters, including the public key: The JWS Payload contains the following JWT claims, including a hash of the body: This results in the following full HTTP message request: The verifier MUST parse and validate the DPoP proof header as defined in I-D.ietf-oauth-dpop.  If the HTTP message request includes a message body, the verifier MUST calculate the digest of the body and compare it to the "htd" value.  The verifier MUST ensure the key presented in the DPoP proof header is the same as the expected key of the signer. 7.3.5. </del> This method is indicated by "httpsig" in the "proof" field.  The sender creates an HTTP Message Signature as described in I-D.ietf- httpbis-message-signatures.


seconds, between two consecutive notifications (whether or not the resource value has changed).  In the absence of this parameter, the maximum period is up to the server.  The maximum period MUST be <del> greater than zero and MUST be greater than the minimum period parameter (if present) otherwise the receiver MUST return a CoAP error code 4.00 "Bad Request" (or equivalent). </del> <ins> greater than zero and MUST be greater than, or equal to, the minimum period parameter (if present) otherwise the receiver MUST return a CoAP error code 4.00 "Bad Request" (or equivalent). </ins> 3.1.3.


that attest to this information. The most basic Privacy Pass protocol provides a set of cross-origin <del> authorization tokens that protect the client's anonymity during </del> <ins> authorization tokens that protect the Clients' anonymity during </ins> interactions with a server.  This allows clients to communicate an attestation of a previously authenticated server action without having to reauthenticate manually.  The tokens retain anonymity in


In response to a client instance's request, the AS responds with a JSON object as the HTTP entity body.  Each possible field is detailed <del> in the sections below </del> <ins> in the sections below. </ins> In this example, the AS is returning an response-interact-redirect, a response-interact-finish, and a response-continue.


The derivation of pairwise keys defined in key-derivation-pairwise is compatible with ECDSA and EdDSA asymmetric keys, but is not <del> compatible with RSA asymmetric keys.  The security of using the same key pair for Diffie-Hellman and for signing is demonstrated in Degabriele. </del> <ins> compatible with RSA asymmetric keys. For the public key translation from Ed25519 (Ed448) to X25519 (X448) specified in key-derivation-pairwise, variable time methods can be used since the translation operates on public information.  Any byte string of appropriate length is accepted as a public key for X25519 (X448) in RFC7748, it is therefore not necessary for security to validate the translated public key (assuming the translation was successful). The security of using the same key pair for Diffie-Hellman and for signing (by considering the ECDH procedure in sec-derivation-pairwise as a Key Encapsulation Mechanism (KEM)) is demonstrated in Degabriele and Thormarker. Applications using ECDH (except X25519 and X448) based KEM in sec- derivation-pairwise are assumed to verify that a peer endpoint's public key is on the expected curve and that the shared secret is not the point at infinity.  The KEM in Degabriele checks that the shared secret is different from the point at infinity, as does the procedure in Section 5.7.1.2 of NIST-800-56A which is referenced in sec- derivation-pairwise. Extending Theorem 2 of Degabriele, Thormarker shows that the same key pair can be used with X25519 and Ed25519 (X448 and Ed448) for the KEM specified in sec-derivation-pairwise.  By symmetry in the KEM used in this document, both endpoints can consider themselves to have the recipient role in the KEM -- as discussed in Section 7 of Thormarker - and rely on the mentioned proofs for the security of their key pairs. Theorem 3 in Degabriele shows that the same key pair can be used for an ECDH based KEM and ECDSA.  The KEM uses a different KDF than in sec-derivation-pairwise, but the proof only depends on that the KDF has certain required properties, which are the typical assumptions about HKDF, e.g., that output keys are pseudorandom.  In order to comply with the assumptions of Theorem 3, received public keys MUST be successfully validated, see Section 5.6.2.3.4 of NIST-800-56A. The validation MAY be performed by a trusted Group Manager.  For Degabriele to apply as it is written, public keys need to be in the expected subgroup.  For this we rely on cofactor DH, Section 5.7.1.2 of NIST-800-56A which is referenced in sec-derivation-pairwise. HashEdDSA variants of Ed25519 and Ed448 are not used by COSE, see Section 2.2 of I-D.ietf-cose-rfc8152bis-algs, and are not covered by the analysis in Thormarker, and hence MUST NOT be used with the public keys used with pairwise keys as specified in this document. </ins> 10.14.


Packet Size (MPS) as described in Datagram PLPMTUD I-D.ietf-tsvwg- datagram-plpmtud. <del> 7.1.10.3. </del> <ins> 7.1.11.3. </ins> sendMsgMaxLen


left and right children, respectively.  When computing the hash of a leaf node, the hash of a "LeafNodeHashInput" object is used: <ins> Note that the "node_index" field contains the index of the leaf among the nodes in the tree, not its index among the leaves; "node_index = 2 * leaf_index". </ins> 7.6. Each member of the group maintains a GroupContext object that


with an algorithm such as HMAC or an AEAD algorithm. The PublicMessage and PrivateMessage formats are defined in message- <del> framing; they represent integrity-protected and confidentiality- protected messages, respectively.  Security notions such as forward secrecy and post-compromise security are defined in security- considerations. </del> <ins> framing.  Security notions such as forward secrecy and post- compromise security are defined in security-considerations. </ins> 2.1.


intermediary not acting as a tunnel) MUST NOT forward a malformed request or response.  Malformed requests or responses that are detected MUST be treated as a stream error (errors) of type <del> H3_GENERAL_PROTOCOL_ERROR. </del> <ins> H3_MESSAGE_ERROR. </ins> For malformed requests, a server MAY send an HTTP response indicating the error prior to closing or resetting the stream.  Clients MUST NOT


though 1-RTT keys are available to a server after receiving the first handshake messages from a client, the server cannot consider the client to be authenticated until it receives and validates the <del> client's Finished message. </del> <ins> client's Finished message.  A server MUST NOT process 1-RTT packets until the handshake is complete.  A server MAY buffer or discard 1-RTT packets that it cannot read. </ins> The requirement for the server to wait for the client Finished message creates a dependency on that message being delivered.  A


as an asynchronous interface, they generally use a try-and-fail model.  If the application wants to read, but data has not yet been received from the peer, the call to read will fail.  The application <del> then waits for a notification to indicate when it can try again. </del> <ins> then waits and can try again later. </ins> All interaction with a Transport Services system is expected to be asynchronous, and use an event-driven model unlike sockets events.


Since the last acknowledgement was sent, "max_ack_delay" amount of time has passed. <del> reordering, congestion, and batch describe exceptions to this </del> <ins> out-of-order, congestion, and batch describe exceptions to this </ins> strategy. An endpoint is expected to bundle acknowledgements when possible.


Removing a member. <del> Before the initialization of a group, clients publish UserInitKey </del> <ins> Before the initialization of a group, clients publish ClientInitKey </ins> objects to a directory provided to the Messaging Service. When a client A wants to establish a group with B and C, it first <del> downloads UserInitKeys for B and C.  It then initializes a group state containing only itself and uses the UserInitKeys to compute </del> <ins> downloads ClientInitKeys for B and C.  It then initializes a group state containing only itself and uses the ClientInitKeys to compute </ins> Welcome and Add messages to add B and C, in a sequence chosen by A. The Welcome messages are sent directly to the new members (there is no need to send them to the group).  The Add messages are broadcasted


choose stricter modes if desired, e.g., if a user indicates they want all WebRTC traffic to follow the default route. <del> Future versions of this document may define additional modes and/or update the recommended default modes. </del> <ins> Future documents may define additional modes and/or update the recommended default modes. </ins> Note that the suggested defaults can still be used even for organizations that want all external WebRTC traffic to traverse a


The client instance stores the continuation information from (2) for use in (8) and (10).  The client instance then interaction- <del> redirect given by the AS in (2). </del> <ins> usercode given by the AS in (2). </ins> <del> The user's directs their browser to the user code URI.  This URI is stable and can be communicated via the client software's </del> <ins> The users directs their browser to the user code URI.  This URI is stable and can be communicated via the client software's </ins> documentation, the AS documentation, or the client software itself.  Since it is assumed that the RO will interact with the AS through a secondary device, the client instance does not provide a


10. <ins> [[to-be-removed: RFC Editor: please replace RFCthis with this RFC number and remove this note.]] 10.1. </ins> IANA is requested to allocate an entry to the TLS "ContentType" registry, for the "return_routability_check(TBD2)" message defined in this document.  The "return_routability_check" content type is only applicable to DTLS 1.2 and 1.3. <ins> 10.2. </ins> IANA is requested to allocate the extension code point (TBD1) for the "rrc" extension to the "TLS ExtensionType Values" registry as described in tbl-ext. <ins> 10.3. IANA is requested to create a new sub-registry for RRC Message Types in the TLS Parameters registry IANA.tls-parameters, with the policy "expert review" RFC8126. Each entry in the registry must include: The initial state of this sub-registry is as follows: </ins> 11. Issues against this document are tracked at https://github.com/tlswg/


11. TBD. <del> 12.  References 12.1.  URIs [1] https://mailarchive.ietf.org/arch/search/?email_list=quic [2] https://github.com/quicwg/ack-frequency [3] https://github.com/quicwg </del>


other certificate management functions, such as certificate revocation. <del> DISCLAIMER: This is a work in progress draft of ACME and has not yet had a thorough security analysis. </del> RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH: The source for this draft is maintained in GitHub.  Suggested changes should be submitted as pull requests at https://github.com/ietf-wg-acme/acme


two connection IDs to the same connection, client, or server.  In particular, all servers using a configuration MUST consistently add the same length to each connection ID, to preserve the linkability <del> objectives of QUIC-LB.  Any additional bytes SHOULD appear random unless individual servers are not distinguishable (e.g. any server using that configuration appends identical bytes to every connection ID). </del> <ins> objectives of QUIC-LB.  Any additional bytes SHOULD NOT provide any observable correlation to previous connection IDs for that connection (e.g., the bytes can be chosen at random). </ins> If there is no key in the configuration, the Connection ID is complete.  Otherwise, there are further steps, as described in the


Data Unit: Datagram The Transport Services API mappings for UDP-Lite are identical to <del> UDP.  Properties that require checksum coverage are not supported by UDP-Lite, such as "msgChecksumLen", "fullChecksumSend", "recvChecksumLen", and "fullChecksumRecv". </del> <ins> UDP.  In addition, UDP-Lite supports the "msgChecksumLen" and "recvChecksumLen" Properties that allow an application to specify the minimum number of bytes in a message that need to be covered by a checksum. </ins> 10.5.


the current window; "RateLimit-Reset": containing the time remaining in the current <del> window, specified in seconds. </del> <ins> window, specified in seconds; "RateLimit-Policy": containing the quota policy information. </ins> The behavior of "RateLimit-Reset" is compatible with the "delay- seconds" notation of "Retry-After".


by allowing receipt of arbitrarily small resolutions, perhaps via fallback to a software decoder. <del> In the special case of a maximum resolution of [0, 0], as described above, the sender MUST NOT transmit the encoding. </del> 3.7. JSEP supports simulcast transmission of a MediaStreamTrack, where


fields only when a given quota is going to expire. Implementers concerned with response fields' size, might take into <del> account their ratio with respect to the payload data, or use header- compression http features such as HPACK. </del> <ins> account their ratio with respect to the content length, or use header-compression HTTP features such as HPACK. </ins> 4.


successful ACK processing updates the keys of the KeyUpdate message sender, which is reflected in the change of epoch values. <ins> With a 128-bit key as in AES-256, rekeying 2^64 times has a high probability of key reuse within a given connection.  Note that even if the key repeats, the IV is also independently generated.  In order to provide an extra margin of security, sending implementations MUST NOT allow the epoch to exceed 2^48-1.  In order to allow this value to be changed later, receiving implementations MUST NOT enforce this rule.  If a sending implementation receives a KeyUpdate with request_update set to "update_requested", it MUST NOT send its own KeyUpdate if that would cause it to exceed these limits. </ins> 9. If the client and server have negotiated the "connection_id"


entities that handle the data, but do not modify it (such as TURN relays). <del> It includes necessary functions for congestion control: When not to send data. </del> <ins> It includes necessary functions for congestion control, retransmission, and in-order delivery. </ins> WebRTC endpoints MUST implement the transport protocols described in I-D.ietf-rtcweb-transports.


"key_share" and using the "psk_dhe_ke" pre-shared key exchange mode is also important in order to limit the impact of a key compromise. When using "psk_dhe_ke", TLS 1.3 provides forward secrecy meaning <del> that key leakage does not compromise any earlier connections.  It is RECOMMMENDED to use "psk_dhe_ke" for resumption. </del> <ins> that key leakage does not compromise any earlier connections.  The "psk_dh_ke" mechanism MUST be used for resumption unless the deployment has a local requirement to allow configuration of other mechanisms. </ins> 2.1.4.


?1.  A Capsule-Protocol header field with a value of ?0 has the same semantics as when the header is not present.  Intermediaries MAY use this header field to allow processing of HTTP Datagrams for unknown <del> HTTP methods or unknown HTTP Upgrade Tokens. </del> <ins> HTTP Upgrade Tokens; note that this is only possible for HTTP Upgrade or Extended CONNECT. </ins> The Capsule-Protocol header field MUST NOT be sent multiple times on a message.  The Capsule-Protocol header field MUST NOT be used on


4.1. There are several DHCP options that convey local domain hints of <del> different kinds.  The most directly relevant is "RDNSS Selection" RFC6731, which provides "a list of domains ... about which the RDNSS has special knowledge", along with a "High", "Medium", or "Low" preference for each name.  The specification notes the difficulty of relying on these hints without validation: Other local domain hints in DHCP include the "Domain Name" RFC2132, "Access Network Domain Name" RFC5986, "Client FQDN" RFC4704, and "Name Service Search" RFC2937 options.  This specification may help clients to interpret these hints.  For example, a rogue DHCP server could use the "Client FQDN" option to assign a client the name </del> <ins> different kinds.  The most directly relevant is RFC6731, which provides "a list of domains ... about which the RDNSS has special knowledge", along with a "High", "Medium", or "Low" preference for each name.  The specification notes the difficulty of relying on these hints without validation: Other local domain hints in DHCP include the RFC2132, RFC5986, "Client FQDN" RFC4704, and RFC2937 options.  This specification may help clients to interpret these hints.  For example, a rogue DHCP server could use the "Client FQDN" option to assign a client the name </ins> "www.example.com" in order to prevent the client from reaching the true "www.example.com".  A client could use this specification to check the network's authority over this name, and adjust its behavior


of SP-800-56A.  For secp256r1, secp384r1, and secp521r1, at least partial public-key validation MUST be done. <del> A static Diffie-Hellman key for authentication in method 1, 2 or 3 MUST NOT not be used as a digital signature key for authentication in method 0, unless proven secure by a dedicated cryptographic analysis. </del> <ins> As noted in Section 12 of I-D.ietf-cose-rfc8152bis-struct the use of a single key for multiple algorithms is strongly disencouraged unless proven secure by a dedicated cryptographic analysis.  In particular this recommendation applies to using the same private key for static Diffie-Hellman authentication and digital signature authentication. </ins> A preliminary conjecture is that a minor change to EDHOC may be sufficient to fit the analysis of secure shared signature and ECDH key usage in Degabriele11 and Thormarker21.


different forms.  For example, any Client can only remain private relative to the entire space of other Clients using the protocol. Moreover, by owning tokens for a given set of keys, the Client's <del> anonymity set shrinks to the total number of clients controlling </del> <ins> anonymity set shrinks to the total number of Clients controlling </ins> tokens for the same keys. In the following, we consider the possible ways that Issuers can


ClientHelloInner.  The client-facing server forwards all other TLS messages between the client and backend server unmodified. <ins> Otherwise, if all candidate ECHConfigs fail to decrypt the extension, the client-facing server MUST ignore the extension and proceed with the connection using ClientHelloOuter.  This connection proceeds as usual, except the server MUST include the "encrypted_client_hello" extension in its EncryptedExtensions with the "retry_configs" field set to one or more ECHConfig structures with up-to-date keys. Servers MAY supply multiple ECHConfig values of different versions. This allows a server to support multiple versions at once. Note that decryption failure could indicate a GREASE ECH extension (see grease-extensions), so it is necessary for servers to proceed with the connection and rely on the client to abort if ECH was required.  In particular, the unrecognized value alone does not indicate a misconfigured ECH advertisement (misconfiguration). Instead, servers can measure occurrences of the "ech_required" alert to detect this case. </ins> 7.1.1. In case a HelloRetryRequest (HRR) is sent, the client-facing server


Indicates that x is repeated zero or more times (and that each instance is length E) <ins> This document uses network byte order (that is, big endian) values. Fields are placed starting from the high-order bits of each byte. </ins> fig-ex-format shows an example structure: 5.


3.1. Adaptive BitRate (ABR) is a sort of application-level response <del> strategy in which the receiving media player attempts to detect the available bandwidth of the network path by experiment or by observing the successful application-layer download speed, then chooses a video bitrate (among the limited number of available options) that fits within that bandwidth, typically adjusting as changes in available bandwidth occur in the network or changes in capabilities occur in the player (such as available memory, CPU, display size, etc.). </del> <ins> strategy in which the streaming client attempts to detect the available bandwidth of the network path by observing the successful application-layer download speed, then chooses a bitrate for each of the video, audio, subtitles and metadata (among the limited number of available options) that fits within that bandwidth, typically adjusting as changes in available bandwidth occur in the network or changes in capabilities occur during the playback (such as available memory, CPU, display size, etc.). </ins> The choice of bitrate occurs within the context of optimizing for <del> some metric monitored by the video player, such as highest achievable video quality, or lowest rate of expected rebuffering events. </del> <ins> some metric monitored by the client, such as highest achievable video quality or lowest chances for a rebuffering (playback stall). </ins> 3.2. <del> ABR playback is commonly implemented by video players using HLS </del> <ins> ABR playback is commonly implemented by streaming clients using HLS </ins> RFC8216 or DASH DASH to perform a reliable segmented delivery of <del> video data over HTTP.  Different player implementations and receiving devices use different strategies, often proprietary algorithms (called rate adaptation or bitrate selection algorithms), to perform available bandwidth estimation/prediction and the bitrate selection. Most players only use passive observations, i.e., they do not generate probe traffic to measure the available bandwidth. </del> <ins> media over HTTP.  Different implementations use different strategies ABRSurvey, often proprietary algorithms (called rate adaptation or bitrate selection algorithms) to perform available bandwidth estimation/prediction and the bitrate selection.  Most clients only use passive observations, i.e., they do not generate probe traffic to measure the available bandwidth. </ins> This kind of bandwidth-measurement systems can experience trouble in several ways that can be affected by networking design choices.


storage provider, and give the encryption key to the user as a recovery value. <del> 6.4.1. With MAC-based recovery, the client proves to the server that it holds a secret value established in the initial registration transaction.  The client requests MAC-based recovery by sending a MAC over the new account key, using the recovery key from the initial registration. The string "mac" The URI for the registration to be recovered. A JSON-formatted JWS object using an HMAC algorithm, whose payload is the JWK representation of the public key of the new account key pair. On receiving such a request the server MUST verify that: The base registration has a recovery key associated with it The "alg" value in the "mac" JWS represents a MAC algorithm The "mac" JWS is valid according to the validation rules in RFC7515, using the recovery key as the MAC key The JWK in the payload represents the new account key (i.e. the key used to verify the ACME message) If those conditions are met, and the recovery request is otherwise acceptable to the server, then the recovery process has succeeded. The server creates a new registration resource based on the base registration and the new account key, and returns it on a 201 (Created) response, together with a Location header indicating a URI for the new registration.  If the recovery request is unsuccessful, the server returns an error response, such as 403 (Forbidden). 6.4.2. In the contact-based recovery process, the client requests that the server send a message to one of the contact URIs registered for the account.  That message indicates some action that the server requires the client's user to perform, e.g., clicking a link in an email.  If the user successfully completes the server's required actions, then the server will bind the account to the new account key. </del> <ins> The client requests recovery by asking that the server send a message to one of the contact URIs registered for the account.  That message indicates some action that the server requires the client's user to perform, e.g., clicking a link in an email.  If the user successfully completes the server's required actions, then the server will bind the account to the new account key. </ins> (Note that this process is almost entirely out of band with respect to ACME.  ACME only allows the client to initiate the process, and the server to indicate the result.) <del> To initiate contact-based recovery, the client sends a POST request to the server's recover-registration URI, with a body specifying which registration is to be recovered.  The body of the request MUST be signed by the client's new account key pair. </del> <ins> To initiate recovery, the client sends a POST request to the server's recover-registration URI, with a body specifying which registration is to be recovered.  The body of the request MUST be signed by the client's new account key pair. </ins> The string "contact" The URI for the registration to be recovered. <del> If the server agrees to attempt contact-based recovery, then it creates a new registration resource containing a stub registration object.  The stub registration has the client's new account key and contacts, but no authorizations or certificates associated.  The server returns the stub contact in a 201 (Created) response, along with a Location header field indicating the URI for the new registration resource (which will be the registration URI if the recovery succeeds). </del> <ins> If the server agrees to attempt recovery, then it creates a new registration resource containing a stub registration object.  The stub registration has the client's new account key and contacts, but no authorizations or certificates associated.  The server returns the stub contact in a 201 (Created) response, along with a Location header field indicating the URI for the new registration resource (which will be the registration URI if the recovery succeeds). </ins> After recovery has been initiated, the server follows its chosen recovery process, out-of-band to ACME.  While the recovery process is


data, unless priorities specified by the application indicate otherwise (see stream-prioritization). <ins> Even though a sender is encouraged to assemble frames containing up- to-date information every time it sends a packet, it is not forbidden to retransmit frames of lost packets as they are.  A receiver MUST accept packets containing an outdated frame, such as a MAX_DATA frame carrying a smaller maximum data than one found in an older packet. </ins> Upon detecting losses, a sender MUST take appropriate congestion control action.  The details of loss detection and congestion control are described in QUIC-RECOVERY.


watch for increasing numbers of end users uploading significant amounts of content. <ins> 2.6. The causes of unpredictable usage described in sec-unpredictable were more or less the result of human choices, but we were reminded during a post-IETF 107 meeting that humans are not always in control, and forces of nature can cause enormous fluctuations in traffic patterns. In his talk, Sanjay Mishra Mishra reported that after the CoViD-19 pandemic broke out in early 2020, Comcast's streaming and web video consumption rose by 38%, with their reported peak traffic up 32% overall between March 1 to March 30 Comcast, AT&T reported a 28% jump in core network traffic (single day in April, as compared to pre stay-at-home daily average traffic), with video accounting for nearly half of all mobile network traffic, while social networking and web browsing remained the highest percentage (almost a quarter each) of overall mobility traffic ATT, and Verizon reported similar trends with video traffic up 36% over an average day (pre COVID-19) Verizon. We note that other operators saw similar spikes during this time period.  Craig Labowitz Labovitz reported Weekday peak traffic increases over 45%-50% from pre-lockdown levels, A 30% increase in upstream traffic over their pre-pandemic levels, and A steady increase in the overall volume of DDoS traffic, with amounts exceeding the pre-pandemic levels by 40%. (He attributed this increase to the significant rise in gaming-related DDoS attacks (LabovitzDDoS), as gaming usage also increased.) </ins> 3. 3.1.


See iana-error-codes for details of registering new error codes. <ins> In defining these error codes, several principles are applied.  Error conditions that might require specific action on the part of a recipient are given unique codes.  Errors that represent common conditions are given specific codes.  Absent either of these conditions, error codes are used to identify a general function of the stack, like flow control or transport parameter handling. Finally, generic errors are provided for conditions where implementations are unable or unwilling to use more specific codes. </ins> 20.1. Application protocol error codes are 62-bit unsigned integers, but


Context (optional).  This parameter sets the Default Base URI under which the request's links are to be interpreted.  The <del> specified URI MUST NOT have a path component of its own, but MUST be suitable as a base URI to resolve any relative </del> <ins> specified URI typically does not have a path component of its own, and MUST be suitable as a base URI to resolve any relative </ins> references given in the registration.  The parameter is <del> therefore of the shape "scheme://authority" for HTTP and CoAP URIs.  In the absence of this parameter the scheme of the protocol, source address and source port of the registration request are assumed.  This parameter is mandatory when the directory is filled by a third party such as an commissioning tool.  If the endpoint uses an ephemeral port to register with, it MUST include the con parameter in the registration to provide a valid network path.  If the endpoint which is located behind a NAT gateway is registering with a Resource Directory which is on the network service side of the NAT gateway, the endpoint MUST use a persistent port for the outgoing registration in order to provide the NAT gateway with a valid network address for replies and incoming requests. </del> <ins> therefore usually of the shape "scheme://authority" for HTTP and CoAP URIs.  In the absence of this parameter the scheme of the protocol, source address and source port of the registration request are assumed.  This parameter is mandatory when the directory is filled by a third party such as an commissioning tool.  If the endpoint uses an ephemeral port to register with, it MUST include the con parameter in the registration to provide a valid network path.  If the endpoint which is located behind a NAT gateway is registering with a Resource Directory which is on the network service side of the NAT gateway, the endpoint MUST use a persistent port for the outgoing registration in order to provide the NAT gateway with a valid network address for replies and incoming requests. Endpoints that register with a con that contains a path component need to carefully consider the rules of relative URI resolution.  Typically, links submitted by such an endpoint are of the "path-noscheme" form. </ins> Additional registration attributes (optional).  The endpoint can pass any parameter registered at iana-registry to the


in RFC5888.  addTrack attempts to minimize the number of transceivers as follows: if the PeerConnection is in the "have-remote-offer" state, the track will be attached to the first compatible transceiver <del> that was created by the most recent call to setRemoteDescription() and does not have a local track.  Otherwise, a new transceiver will be created, as described in sec.addTransceiver. </del> <ins> that was created by the most recent call to setRemoteDescription and does not have a local track.  Otherwise, a new transceiver will be created, as described in sec.addTransceiver. </ins> 4.1.3.


operations, and "core.rd-group" is used to discover the URI path for RD Group operations.  Upon success, the response will contain a payload with a link format entry for each RD function discovered, <del> indicating the URI path of the RD function returned and the corresponding Resource Type.  When performing multicast discovery, the multicast IP address used will depend on the scope required and the multicast capabilities of the network. </del> <ins> indicating the URI of the RD function returned and the corresponding Resource Type.  When performing multicast discovery, the multicast IP address used will depend on the scope required and the multicast capabilities of the network. </ins> A Resource Directory MAY provide hints about the content-formats it supports in the links it exposes or registers, using the "ct" link


Universal Time, or might be defined relative to some other timestamp or timeticks counter. <del> We now walk through a number of hypothetical examples of how a solution might be built.  This list is not intended to be complete, but is just representative enough to highlight various timing considerations. </del> <ins> Using the table above, a number of hypothetical examples of how a solution might be built are illustrated below.  a solution might be built.  This list is not intended to be complete, but is just representative enough to highlight various timing considerations. </ins> 15.1.


Finally QUIC-VN provides two mechanisms for endpoints to negotiate the QUIC version to use.  The "incompatible" version negotiation <del> method can support switching from any initial QUIC version to any other version with full generality, at the cost of an additional round-trip at the start of the connection.  "Compatible" version negotiation eliminates the round-trip penalty but levies some restrictions on how much the two versions can differ semantically. </del> <ins> method can support switching from any QUIC version to any other version with full generality, at the cost of an additional round-trip at the start of the connection.  "Compatible" version negotiation eliminates the round-trip penalty but levies some restrictions on how much the two versions can differ semantically. </ins> QUIC version 2 is meant to mitigate ossification concerns and exercise the version negotiation mechanisms.  The only change is a


10.8.6. This design permits servers operating in Split Mode to forward <del> connections directly to backend origin servers, thereby avoiding unnecessary MiTM attacks. </del> <ins> connections directly to backend origin servers.  The client authenticates the identity of the backend origin server, thereby avoiding unnecessary MiTM attacks. </ins> <del> 10.8.7. Assuming ECH records retrieved from DNS are authenticated, e.g., via DNSSEC or fetched from a trusted Recursive Resolver, spoofing a server operating in Split Mode is not possible.  See plaintext-dns for more details regarding plaintext DNS. </del> <ins> Conversely, assuming ECH records retrieved from DNS are authenticated, e.g., via DNSSEC or fetched from a trusted Recursive Resolver, spoofing a client-facing server operating in Split Mode is not possible.  See plaintext-dns for more details regarding plaintext DNS. </ins> Authenticating the ECHConfigs structure naturally authenticates the included public name.  This also authenticates any retry signals from <del> the server because the client validates the server certificate against the public name before retrying. </del> <ins> the client-facing server because the client validates the server certificate against the public name before retrying. </ins> <del> 10.8.8. </del> <ins> 10.8.7. </ins> This design has no impact on application layer protocol negotiation. It may affect connection routing, server certificate selection, and client certificate verification.  Thus, it is compatible with <del> multiple protocols. </del> <ins> multiple application and transport protocols.  By encrypting the entire ClientHello, this design additionally supports encrypting the ALPN extension. </ins> 10.9.


Group will rely upon.  features contains a more thorough discussion on the different features that can be used. <del> Once a document is published in a repository on GitHub, many features like pull requests, issue tracking or the wiki can be individually disabled.  If specific features are not used by the Working Group in the development of the document, disabling those features avoids creating confusion in the wider community about what can be used. </del> 3.2. Working Group Chairs that decide to use GitHub MUST inform their


elliptic curve equation.  For these curves, implementers do not need to verify membership in the correct subgroup. <del> Encryption keys are derived from shared secrets by taking the first 16 bytes of H(Z), where Z is the shared secret and H is SHA-256. </del> 5.6. A member of a group authenticates the identities of other


2.3. <ins> Both the client and the server MUST send a Capability and Settings message (CSM see csm) as its first message on the connection.  This message establishes the initial settings and capabilities for the endpoint such as maximum message size or support for block-wise transfers.  The absence of options in the CSM indicates that base values are assumed. Clients and servers MUST treat a missing or invalid CSM as a connection error and abort the connection (see sec-abort). 2.4. </ins> The CoAP message format defined in RFC7252, as shown in CoAP-Header, relies on the datagram transport (UDP, or DTLS over UDP) for keeping the individual messages separate and for providing length


Clients SHOULD NOT respond to challenges until they believe that the server's queries will succeed.  If a server's initial validation <del> query fails, the server SHOULD retry the query after some time. While the server is still trying, the status of the challenge remains "pending"; it is only marked "invalid" once the server has given up. </del> <ins> query fails, the server SHOULD retry the query after some time, in order to account for delay in setting up responses such as DNS records or HTTP resources.  The precise retry schedule is up to the server, but server operators should keep in mind the operational scenarios that the schedule is trying to accommodate.  Given that retries are intended to address things like propagation delays in HTTP or DNS provisioning, there should not usually be any reason to retry more often than every 5 or 10 seconds.  While the server is still trying, the status of the challenge remains "pending"; it is only marked "invalid" once the server has given up. </ins> The server MUST provide information about its retry state to the client via the "errors" field in the challenge and the Retry-After


Any received 0-RTT data that the server responds to might be due to a replay attack. <del> Therefore, the server's use of 1-RTT keys MUST be limited to sending data before the handshake is complete.  A server MUST NOT process </del> <ins> Therefore, the server's use of 1-RTT keys before the handshake is complete is limited to sending data.  A server MUST NOT process </ins> incoming 1-RTT protected packets before the TLS handshake is complete.  Because sending acknowledgments indicates that all frames in a packet have been processed, a server cannot send acknowledgments


"offer" indicates that a description should be parsed as an offer; said description may include many possible media configurations.  A description used as an "offer" may be applied any time the <del> PeerConnection is in a stable state or applied as an update to a </del> <ins> PeerConnection is in a "stable" state or applied as an update to a </ins> previously supplied but unanswered "offer". "pranswer" indicates that a description should be parsed as an


10. The security considerations of HTTP/3 should be comparable to those <del> of HTTP/2 with TLS.  Note that where HTTP/2 employs PADDING frames and Padding fields in other frames to make a connection more resistant to traffic analysis, HTTP/3 can either rely on transport- layer padding or employ the reserved frame and stream types discussed in frame-grease and stream-grease. </del> <ins> of HTTP/2 with TLS; the considerations from Section 10 of HTTP2 apply in addition to those listed here. </ins> When HTTP Alternative Services is used for discovery for HTTP/3 endpoints, the security considerations of ALTSVC also apply. <ins> 10.1. Where HTTP/2 employs PADDING frames and Padding fields in other frames to make a connection more resistant to traffic analysis, HTTP/3 can either rely on transport-layer padding or employ the reserved frame and stream types discussed in frame-grease and stream- grease.  These methods of padding produce different results in terms of the granularity of padding, the effect of packet loss and recovery, and how an implementation might control padding. 10.2. </ins> Several protocol elements contain nested length elements, typically in the form of frames with an explicit length containing variable- length integers.  This could pose a security risk to an incautious implementer.  An implementation MUST ensure that the length of a frame exactly matches the length of the fields it contains. <ins> 10.3. </ins> The use of 0-RTT with HTTP/3 creates an exposure to replay attack. The anti-replay mitigations in HTTP-REPLAY MUST be applied when using HTTP/3 with 0-RTT. <ins> 10.4. </ins> Certain HTTP implementations use the client address for logging or access-control purposes.  Since a QUIC client's address might change during a connection (and future versions might support simultaneous


This document describes an architecture for implementing captive portals while addressing most of the problems arising for current captive portal mechanisms.  The architecture is guided by these <del> principles: </del> <ins> requirements: </ins> A side-benefit of the architecture described in this document is that devices without user interfaces are able to identify parameters of


Payload field is longer than that limit without buffering the capsule contents. <ins> If a UDP proxy receives an HTTP Datagram before it has received the corresponding request, it SHALL either drop that HTTP Datagram silently or buffer it temporarily (on the order of a round trip) while awaiting the corresponding request. Note that buffering datagrams (either because the request was not yet received, or because the Context ID is not yet known) consumes resources.  Receivers that buffer datagrams SHOULD apply buffering limits in order to reduce the risk of resource exhaustion occuring. For example, receivers can limit the total number of buffered datagrams, or the cumulative size of buffered datagrams, on a per- stream, per-context, or per-connection basis. A client MAY optimistically start sending UDP packets in HTTP Datagrams before receiving the response to its UDP proxying request. However, implementors should note that such proxied packets may not be processed by the UDP proxy if it responds to the request with a failure, or if the proxied packets are received by the UDP proxy before the request and the UDP proxy chooses to not buffer them. </ins> 6. UDP proxies SHOULD strive to avoid increasing burstiness of UDP


clients and media servers, WHIP imposes the following restrictions regarding WebRTC usage: <del> Bothe the WHIP client and the media server SHALL use SDP bundle RFC8843.  The SDP offer created by the WHIP client must include the bundle-only attribute in all m-lines as per RFC8843.  Also, RTCP muxing SHALL be supported by both the WHIP client and the media server. </del> <ins> Both the the WHIP client and the WHIP endpoint SHALL use SDP bundle RFC8843.  Each "m=" section MUST be part of a single BUNDLE group. Hence, when a WHIP client sends an SDP offer, it MUST include a "bundle-only" attribute in each bundled "m=" section.  The WHIP client and the Media Server MUST support multiplexed media associated with the BUNDLE group as per RFC8843 section 9.  In addition, per RFC8843 the WHIP client and Media Server will use RTP/RTCP multiplexing for all bundled media.  The WHIP client and media server SHOULD include the "rtcp-mux-only" attribute in each bundled "m=" sections. </ins> When a WHIP client sends an SDP offer, it SHOULD insert an SDP "setup" attribute with an "actpass" attribute value, as defined in


value MUST be less than or equal to the value provided by the application server. <ins> 6.3. A push message that has been stored by the push service can be replaced with new content.  If the user agent is offline during the time that the push messages are sent, updating a push message avoids the situation where obsolete or redundant messages are sent to the user agent. Only push messages that have been assigned a topic can be updated.  A push message with a topic replaces any outstanding push message with an identical topic. A push message topic is a string.  A topic is carried in a Topic header field.  A topic is used to correlate push messages sent to the same subscription, it does not convey any other semantics. The grammar for the Topic header field uses the "token" and "quoted- string" rules defined in RFC7230. Any double quotes from the "quoted-string" form are removed before comparing topics for equality. For use with this protocol, the Topic header field MUST be restricted to no more than 32 characters from the URL- and filename-safe base64 set [RFC4648].  A push service that receives a request with a Token header field that does not meet these constraints SHOULD return an HTTP 400 (Bad Request) status code to an application server. A push message request creates a new push message resource, but simultaneously deletes any existing message resource that has a matching topic.  In effect, the information that is stored for the push message is updated, but a new resource is created to avoid problems with in flight acknowledgments for the old message.  The push service MAY suppress acknowledgement receipts for the replaced message. This mechanism doesn't allow for stored push messages to be deleted. An application server can remove a push message using a DELETE request to the push message URL. A push message with a topic that has a zero or absent time-to-live will cause a stored message with the same topic to be removed as well as not being stored itself, but the push service will attempt to forward the updated message to the user agent. A push message with a topic that is not shared by an outstanding message to the same subscription is stored or delivered as normal. The value of the Topic header field MUST NOT be forwarded to user agents.  Its value is not encrypted or authenticated. </ins> 7. A user agent requests the delivery of new push messages by making a


File extension(s): senml and sensml <ins> Windows Clipboard Name: "JSON Sensor Measurement List" for senml </ins> Macintosh file type code(s): none <ins> Macintosh Universal Type Identifier code: org.ietf.senml-json conforms to public.text for senml </ins> Person & email address to contact for further information: Cullen Jennings <fluffy@iii.ca>


Message representing the body, and the Headers being provided in Message metadata. <ins> Connectedness: Multiplexing Connected Data Unit: Message Connection objects represent a flow of HTTP messages between a client and a server, which may be an HTTP/1.1 connection over TCP, or a single stream in an HTTP/2 connection. Calling "Initiate" on an HTTP connection intiates a TCP or TLS connection as a client. Calling "Clone" on an HTTP Connection opens a new stream on an existing HTTP/2 connection when possible.  If the underlying version does not support multiplexed streams, calling "Clone" simply creates a new parallel connection. When an application sends an HTTP Message, it is expected to provide HTTP header values as a MessageContext in a canonical form, along with any associated HTTP message body as the Message data.  The HTTP header values are encoded in the specific version format upon sending. HTTP Connections deliver Messages in which HTTP header values attached to MessageContexts, and HTTP bodies in Message data. Calling "Close" on an HTTP Connection will only close the underlying TLS or TCP connection if the HTTP version does not support multiplexing.  For HTTP/2, for example, closing the connection only closes a specific stream. </ins> 9.6. QUIC provides a multi-streaming interface to an encrypted transport.


thus avoiding concerns about interleaving multiple HelloRetryRequests. <ins> For more detail on timeouts and retransmission, see timeout- retransmissions. </ins> 3.2. In DTLS, each handshake message is assigned a specific sequence


long as they do not result in a reduction of security over the above MTI requirements.  For example, ESP compression MAY be used. <del> IKEv2 MUST follow RFC8247 as necessary to support the above listed IPsec requirements. </del> <ins> As for ESP (above), for IKEv2, the ENCR_AES_GCM_16 encryption algorithm (with 256-bit keys) MUST be supported.  The IKEv2 PRF_HMAC_SHA2_512 pseudorandom function MUST be supported. IKEv2 Diffie-Hellman key exchange group 19 (256-bit random ECP) MUST be supported (in addition to 2048-bit MODP).  ECC provides a similar security level to finite-field (MODP) key exchange with a shorter key length, so is generally preferred absent other considerations. IKEv2 authentication MUST use the ACP domain certificates.  The Certificate Encoding "PKCS #7 wrapped X.509 certificate" (1) MUST be supported (see IKEV2IANA for this and other IANA IKEv2 parameter names used in this text).  If certificate chains are used, all intermediate certificates up to, but not including the locally provisioned trust anchor certificate must be signaled. A certificate payload with the ACP certificate MUST be included during IKEv2 authentication to support the ACP domain membership check as described in certcheck, because it is using additional elements of the ACP certificates.  ACP peers are expected to have the same set of Trust Anchors (TA), so a certificate path MUST only be included in the signaled payload when the path contains intermediate certificates not in the TA set, such as sub-CAs (see acp-registrars). ACP nodes are identified by their ACP address, so the ID_IPv6_ADDR IKEv2 identification payload MUST be used and MUST convey the ACP address.  If the peer's ACP domain certificate includes an ACP address in the domain information, the address in the identification payload must match the address in the certificate (allowing for the presence of virtualization bits in the ACP addressing scheme used). IKEv2 authentication MUST use authentication method 14 ("Digital Signature") for ACP certificates; this authentication method can be used with both RSA and ECDSA certificates, as indicated by a PKIX- style OID. The Digital Signature hash SHA2-512 MUST be supported (in addition to SHA2-256). Once there are updates to RFC8247, these should accordingly be reflected in updates to these ACP requirements, for example if ENCR_AES_GCM_16 was to be superceeded in the future or the key- exchange group recommendations are changed. Additional requirements from RFC8247 MAY be used for ACP channels as long as they do not result in a reduction of security over the above MTI requirements. </ins> 6.7.1.2.


addition or removal of group members without informing all other members. <del> Membership of an MLS group is the managed at the level of individual </del> <ins> Membership of an MLS group is managed at the level of individual </ins> clients.  In most cases, a client corresponds to a specific device used by a user.  If a user has multiple devices, the user will be represented in a group by multiple clients.  If an application wishes


Name: The name of the ciphersuite <del> Recommended: Whether support for this extension is recommended by the IETF MLS WG.  Valid values are "Y" and "N".  The "Recommended" column is assigned a value of "N" unless explicitly requested, and adding a value with a "Recommended" value of "Y" requires Standards Action RFC8126.  IESG Approval is REQUIRED for a Y->N transition. </del> <ins> Recommended: Whether support for this ciphersuite is recommended by the IETF MLS WG.  Valid values are "Y" and "N".  The "Recommended" column is assigned a value of "N" unless explicitly requested, and adding a value with a "Recommended" value of "Y" requires Standards Action RFC8126.  IESG Approval is REQUIRED for a Y->N transition. </ins> Reference: The document where this ciphersuite is defined


whether a threshold has been met and an acknowledgement is to be sent in response. <del> 7. </del> <ins> 8. </ins> On sending an update to the peer's "max_ack_delay", an endpoint can use this new value in later computations of its Probe Timeout (PTO)


response-token-single, the proof of that key MUST be used when presenting the access token. <del> A key presented by value MUST be a public key in at least one supported format.  If a key is sent in multiple formats, all the key format values MUST be equivalent.  Note that while most formats present the full value of the public key, some formats present a value cryptographically derived from the public key.  See additional discussion of public keys in security-symmetric. A key presented by value MUST be a public key in at least one supported format.  If a key is sent in multiple formats, all the key format values MUST be equivalent.  Note that while most formats present the full value of the public key, some formats present a value cryptographically derived from the public key. </del> <ins> A key presented by value MUST be a public key and MUST be presented in one and only one supported format, as discussed in security- multiple-key-formats.  Note that while most formats present the full value of the public key, some formats present a value cryptographically derived from the public key.  See additional discussion of the presentation of public keys in security-symmetric. </ins> Additional key formats are defined in the IANA-key-formats. <del> This non-normative example shows a single key presented in multiple formats.  This example key is intended to be used with the httpsig- binding proofing mechanism, as indicated by the "httpsig" value of the "proof" field. </del> <ins> This non-normative example shows a single key presented in two different formats.  This example key is intended to be used with the httpsig-binding proofing mechanism, as indicated by the "httpsig" value of the "proof" field. As a JSON Web Key: As a certificate in PEM format: </ins> 7.1.1.


which the lookup client relies on the RD.  To avoid the limitations, RD applications should consider prescribing that lookup clients only use the discovered information as hints, and describe which pieces of <del> information need to be verified with the server because they impact the application's security. </del> <ins> information need to be verified because they impact the application's security.  A straightforward way to verify such information is to request it again from an authorized server, typically the one that hosts the target resource.  That similar to what happens in discovery when the URI discovery step is repeated. </ins> 7.3.


otherwise, a TLS-compliant application MUST implement the TLS_AES_128_GCM_SHA256 cipher suite and SHOULD implement the TLS_AES_256_GCM_SHA384 and TLS_CHACHA20_POLY1305_SHA256 cipher <del> suites. </del> <ins> suites. (see cipher-suites) </ins> A TLS-compliant application MUST support digital signatures with rsa_pkcs1_sha256 (for certificates), rsa_pss_sha256 (for


GroupContext for the current epoch, so that signatures are specific to a given group and epoch. <del> The ciphertext field of the MLSCiphertext object is produced by </del> <ins> 8.2. The "ciphertext" field of the MLSCiphertext object is produced by </ins> supplying the inputs described below to the AEAD function specified by the ciphersuite in use.  The plaintext input contains content and signature of the MLSPlaintext, plus optional padding.  These values


before or during Connection establishment, see also msg- safelyreplayable.  It is given in Bytes. <del> 7.1.10.2. </del> <ins> 7.1.11.2. </ins> singularTransmissionMsgMaxLen


Pass AD_2 to the security application. <del> If any verification step fails, the Initiator MUST send an EDHOC error message back, formatted as defined in error, and the protocol MUST be discontinued. </del> <ins> If any processing step fails, the Initiator SHOULD send an EDHOC error message back, formatted as defined in error.  Sending error messages is essential for debugging but MAY e.g.be skipped if a session cannot be found or due to denial of service reasons, see security.  If an error message is sent, the session MUST be discontinued. </ins> 5.5.


The client's stream terminated without containing a fully-formed request. <ins> An HTTP message was malformed and cannot be processed. </ins> The TCP connection established in response to a CONNECT request was reset or abnormally closed.


described in Section 2.1 of RFC5116.  The key is either the client_write_key or the server_write_key. The type field is identical to TLSPlaintext.type. The version field is identical to TLSPlaintext.version. The length (in bytes) of the following TLSCiphertext.fragment. The length MUST NOT exceed 2^14 + 2048. The AEAD encrypted form of TLSPlaintext.fragment. Each AEAD cipher suite MUST specify how the nonce supplied to the AEAD operation is constructed, and what is the length of the <del> GenericAEADCipher.nonce_explicit part.  In many cases, it is appropriate to use the partially implicit nonce technique described in Section 3.2.1 of RFC5116; with record_iv_length being the length of the explicit part.  In this case, the implicit part SHOULD be derived from key_block as client_write_iv and server_write_iv (as described in key-calculation), and the explicit part is included in </del> <ins> TLSCiphertext.nonce_explicit part.  In many cases, it is appropriate to use the partially implicit nonce technique described in Section 3.2.1 of RFC5116; with record_iv_length being the length of the explicit part.  In this case, the implicit part SHOULD be derived from key_block as client_write_iv and server_write_iv (as described in key-calculation), and the explicit part is included in </ins> GenericAEAEDCipher.nonce_explicit. The plaintext is the TLSPlaintext.fragment.


Otherwise, resolve the candidate using mDNS. <del> If it resolves to an IP address, replace the value of the ICE host candidate by the resolved IP address and continue processing of the candidate. </del> <ins> If it resolves to an IP address, replace the mDNS hostname of the ICE candidate with the resolved IP address and continue processing of the candidate. </ins> Otherwise, ignore the candidate.


DNS: The MAC covers the account key, and the MAC key is derived from an ECDH public key signed with the account private key. <del> Proof of possession of a prior key: The signature by the prior key covers the account public key. </del> The association of challenges to identifiers is typically done by requiring the client to perform some action that only someone who effectively controls the identifier can perform.  For the challenges


"Connection Priority" on one Connection does not change it on the other Connections in the same Connection Group. <ins> The optional "connectionProperties" parameter allows passing Transport Properties that control the behavior of the underlying stream or connection to be created, e.g., protocol-specific properties to request specific stream IDs for SCTP or QUIC. </ins> Message Properties set on a Connection also apply only to that Connection.


Before a TLS ciphersuite can be used with QUIC, a header protection algorithm MUST be specified for the AEAD used with that ciphersuite. This document defines algorithms for AEAD_AES_128_GCM, <del> AEAD_AES_128_CCM, AEAD_AES_256_GCM, AEAD_AES_256_CCM (all AES AEADs are defined in AEAD), and AEAD_CHACHA20_POLY1305 CHACHA.  Prior to TLS selecting a ciphersuite, AES header protection is used (hp-aes), matching the AEAD_AES_128_GCM packet protection. </del> <ins> AEAD_AES_128_CCM, AEAD_AES_256_GCM (all AES AEADs are defined in AEAD), and AEAD_CHACHA20_POLY1305 CHACHA.  Prior to TLS selecting a ciphersuite, AES header protection is used (hp-aes), matching the AEAD_AES_128_GCM packet protection. </ins> 5.4.2.


Connection Properties: The Connection Properties are used to configure protocol-specific options and control per-connection <del> behavior of the Transport System; for example, a protocol-specific Connection Property can express that if UDP is used, the implementation ought to use checksums.  Note that the presence of such a property does not require that a specific protocol will be used.  In general, these properties do not explicitly determine the selection of paths or protocols, but can be used in this way by an implementation during connection establishment.  Connection Properties are specified on a Preconnection prior to Connection establishment, and can be modified on the Connection later. Changes made to Connection Properties after Connection establishment take effect on a best-effort basis. </del> <ins> behavior of the Transport Services system; for example, a protocol-specific Connection Property can express that if UDP is used, the implementation ought to use checksums.  Note that the presence of such a property does not require that a specific protocol will be used.  In general, these properties do not explicitly determine the selection of paths or protocols, but can be used in this way by an implementation during connection establishment.  Connection Properties are specified on a Preconnection prior to Connection establishment, and can be modified on the Connection later.  Changes made to Connection Properties after Connection establishment take effect on a best- effort basis. </ins> 4.1.3.


Rename the GroupState structure to GroupContext (*) <ins> Rename UserInitKey to ClientInitKey </ins> draft-05 Common framing for handshake and application messages (*)


5.2.3.1. <del> If the "IceRestart" option is specified, with a value of "true", the </del> <ins> If the IceRestart option is specified, with a value of "true", the </ins> offer MUST indicate an ICE restart by generating new ICE ufrag and pwd attributes, as specified in RFC8839.  If this option is specified on an initial offer, it has no effect (since a new ICE ufrag and pwd


The mandatory-to-implement ciphersuite for MLS 1.0 is "MLS10_128_HPKE25519_AES128GCM_SHA256_Ed25519" which uses <del> Curve25519, HKDF over SHA2-256 and AES-128-GCM for HPKE, and AES- 128-GCM with Ed25519 for symmetric encryption and signatures. </del> <ins> Curve25519 for key exchange, AES-128-GCM for HPKE, HKDF over SHA2-256, AES for metadata masking, and Ed25519 for signatures. </ins> Values with the first byte 255 (decimal) are reserved for Private Use.