At the time this is published, the response types are works in progress.  The only response type defined in this document is <del> "message/dns", but it is possible that other response formats will be defined in the future. </del> <ins> "application/dns-message", but it is possible that other response formats will be defined in the future. </ins> <del> The DNS response for "message/dns" in dnswire MAY have one or more EDNS options, depending on the extension definition of the extensions given in the DNS request. </del> <ins> The DNS response for "application/dns-message" in dnswire MAY have one or more EDNS options, depending on the extension definition of the extensions given in the DNS request. </ins> Each DNS request-response pair is matched to one HTTP exchange.  The responses may be processed and transported in any order using HTTP's


7. <del> Two examples are shown below.  The first example showing an company with an internal-only DNS server resolving the entire zone for that company (e.g., *.example.com) the second example resolving only a subdomain of the company's zone (e.g., *.internal.example.com). </del> <ins> Two examples are shown below.  The first example shows a company with an internal-only DNS server that claims the entire zone for that company (e.g., ).  In the second example, the internal servers resolves only a subdomain of the company's zone (e.g., ). </ins> 7.1.


comandeered those user agents to send DDoS traffic to various sites Marczak-2015. <del> 4.5. </del> <ins> 4.6. </ins> While it is perhaps the crudest of all censorship techniques, there is no more effective way of making sure undesirable information isn't


Properties when sending.) Abort: The action the application takes on a Connection to <del> indicate a Close and also indicate that the Transport System SHOULD NOT attempt to deliver any outstanding data.  This is intended for immediate termination of a connection, without </del> <ins> indicate a Close and also indicate that the Transport Services system SHOULD NOT attempt to deliver any outstanding data.  This is intended for immediate termination of a connection, without </ins> cleaning up state. 4.2.


RFC EDITOR PLEASE DELETE THIS SECTION. <ins> draft-04 ECIES is now renamed in favor of HPKE (*) </ins> draft-03 Added ciphersuites and signature schemes (*)


When there is no user consent, the following filtering should be done to prevent private IP address leakage: <del> host ICE candidates with an IP address are not exposed as ICE candidate events. </del> <ins> ICE candidates with an IP address are not exposed as ICE candidate events. </ins> Server reflexive ICE candidate raddr field is set to 0.0.0.0 and rport to 0. <del> SDP does not expose any a=candidate line corresponding to a host ICE candidate which contains an IP address. </del> <ins> SDP does not expose any a=candidate line corresponding to an ICE candidate which contains an IP address. </ins> Statistics related to ICE candidates MUST NOT contain the resolved IP address of a remote mDNS candidate or the IP address of a peer-


Key updates MUST be initiated before usage limits on packet protection keys are exceeded.  For the cipher suites mentioned in <del> this document, the limits in Section 5.5 of TLS13 apply.  Other cipher suites MUST define usage limits in order to be used with QUIC. </del> <ins> this document, the limits in Section 5.5 of TLS13 apply.  TLS13 does not specify a limit for AEAD_AES_128_CCM, but the analysis in ccm- bounds shows that a limit of 2^23 packets can be used to obtain the same confidentiality protection as the limits specified in TLS. The usage limits defined in TLS 1.3 exist for protection against attacks on confidentiality and apply to successful applications of AEAD protection.  The integrity protections in authenticated encryption also depend on limiting the number of attempts to forge packets.  TLS achieves this by closing connections after any record fails an authentication check.  In comparison, QUIC ignores any packet that cannot be authenticated, allowing multiple forgery attempts. Endpoints MUST count the number of received packets that fail authentication for each set of keys.  If the number of packets that fail authentication with the same key exceeds a limit that is specific to the AEAD in use, the endpoint MUST stop using those keys. Endpoints MUST initiate a key update before reaching this limit.  If a key update is not possible, the endpoint MUST immediately close the connection.  Applying a limit reduces the probability that an attacker is able to successfully forge a packet; see AEBounds and ROBUST. Due to the way that header protection protects the Key Phase, packets that are discarded are likely to have an even distribution of both Key Phase values.  This means that packets that fail authentication will often use the packet protection keys from the next key phase.  It is therefore necessary to also track the number of packets that fail authentication with the next set of packet protection keys.  To avoid exhaustion of both sets of keys, it might be necessary to initiate two key updates in succession. For AEAD_AES_128_GCM, AEAD_AES_256_GCM, and AEAD_CHACHA20_POLY1305, the limit on the number of packets that fail authentication is 2^36. Note that the analysis in AEBounds supports a higher limit for the AEAD_AES_128_GCM and AEAD_AES_256_GCM, but this specification recommends a lower limit.  For AEAD_AES_128_CCM, the limit on the number of packets that fail authentication is 2^23.5; see ccm-bounds. These limits were originally calculated using assumptions about the limits on TLS record size.  The maximum size of a TLS record is 2^14 bytes.  In comparison, QUIC packets can be up to 2^16 bytes.  However, it is expected that QUIC packets will generally be smaller than TLS records.  Where packets might be larger than 2^14 bytes in length, smaller limits might be needed. Any TLS cipher suite that is specified for use with QUIC MUST define limits on the use of the associated AEAD function that preserves margins for confidentiality and integrity.  That is, limits MUST be specified for the number of packets that can be authenticated and for the number packets that can fail authentication.  Providing a reference to any analysis upon which values are based - and any assumptions used in that analysis - allows limits to be adapted to varying usage conditions. </ins> 6.7.


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


IP packet forwarding, or a specific proxied flow; see scope. An IP proxying request that does not conform to these restrictions is <del> malformed (see H2 and H3). </del> <ins> malformed; see H2 and H3. </ins> For example, if the client is configured with URI Template "https://example.org/.well-known/masque/ip/{target}/{ipproto}/" and wishes to open an IP forwarding tunnel with no target or protocol limitations, it could send the following request: <del> 4.4. </del> <ins> 4.5. </ins> The IP proxy indicates a successful response by replying with the following requirements:


it can request-interact-usercode. The AS determines that interaction is needed and response with a <del> response-interact-usercode.  This could optionally include a URI to direct the user to, but this URI should be static and so could be configured in the client instance's documentation.  The AS also includes information the client instance will need to response- continue in (8) and (10).  The AS associates this continuation information with an ongoing request that will be referenced in (4), (6), (8), and (10). </del> <ins> response-interact-usercode.  The AS also includes information the client instance will need to response-continue in (8) and (10). The AS associates this continuation information with an ongoing request that will be referenced in (4), (6), (8), and (10). </ins> The client instance stores the continuation information from (2) for use in (8) and (10).  The client instance then interaction-


section 5.1.1, the candidate is processed as follows: Check whether the ICE agent has a usable registered mDNS hostname <del> resolving to the ICE host candidate's IP address.  If one exists, skip ahead to Step 6. </del> <ins> resolving to the ICE candidate's IP address.  If one exists, skip ahead to Step 6. </ins> Generate a unique mDNS hostname.  The unique name MUST consist of a version 4 UUID as defined in RFC4122, followed by ".local".


as slice bounds and must first be normalized.  Normalization for this purpose is defined as: <del> The result of the array indexing expression "i" applied to an array of length "len" is defined to be the result of the array slicing </del> <ins> The result of the array index expression "i" applied to an array of length "len" is defined to be the result of the array slicing </ins> expression "Normalize(i, len):Normalize(i, len)+1:1". Slice expression parameters "start" and "end" are used to derive


packet protection keys for Initial packets. The client populates the Source Connection ID field with a value of <del> its choosing and sets the SCID Length field to indicate the length. </del> <ins> its choosing and sets the Source Connection ID Length field to indicate the length. </ins> The first flight of 0-RTT packets use the same Destination Connection ID and Source Connection ID values as the client's first Initial


respectively, and the public authentication keys are denoted G_I and G_R, respectively. <del> For X.509 certificates the authentication key is represented with a </del> <ins> For X.509 certificates the authentication key is represented by a </ins> SubjectPublicKeyInfo field.  For CWT and CCS (see auth-cred)) the <del> authentication key is represented with a 'cnf' claim RFC8747 containing a COSE_Key RFC9052. </del> <ins> authentication key is represented by a 'cnf' claim RFC8747 containing a COSE_Key RFC9052.  In EDHOC, a raw public key (RPK) is an authentication key encoded as a COSE_Key wrapped in a CCS. </ins> 3.5.2. The authentication credentials, CRED_I and CRED_R, contain the public authentication key of the Initiator and the Responder, respectively. <ins> The authentication credential typically also contains other parameters that needs to be verified by the application, see auth- validation, and in particular information about the identity ("subject") of the endpoint to prevent misbinding attacks, see identities. </ins> EDHOC relies on COSE for identification of credentials (see id_cred), for example X.509 certificates RFC5280, C509 certificates I-D.ietf- cose-cbor-encoded-cert, CWTs RFC8392 and CWT Claims Sets (CCS) RFC8392.  When the identified credential is a chain or a bag, the authentication credential CRED_x is just the end entity X.509 or C509 <del> certificate / CWT. </del> <ins> certificate / CWT.  The Initiator and the Responder MAY use different types of authentication credentials, e.g., one uses an RPK and the other uses a public key certificate. </ins> Since CRED_R is used in the integrity verification, see asym- msg2-proc, it needs to be specified such that it is identical when


11.4. <del> During each epoch senders MUST NOT encrypt more messages than permitted by the security bounds of the AEAD scheme used. </del> <ins> During each epoch senders MUST NOT encrypt more data than permitted by the security bounds of the AEAD scheme used. </ins> Note that each change to the Group through a Handshake message will also set a new application_secret.  Hence this change MUST be applied


Both of these approaches allow clients to confirm that a discovered Encrypted Resolver is designated by the originally provisioned <del> resolver.  "Equivalence" in this context means that the resolvers are operated by the same entity; for example, the resolvers are accessible on the same IP address, or there is a certificate that claims ownership over both resolvers. </del> <ins> resolver.  "Designated" in this context means that the resolvers are operated by the same entity or cooperating entities; for example, the resolvers are accessible on the same IP address, or there is a certificate that claims ownership over both resolvers. </ins> 1.1.


If a contributor makes a comment that raises what you believe to be a new issue, create an issue for them.  If the issue has an obvious solution, consider creating a pull request.  It doesn't matter what <del> venue the issue was raised in, email, issue discussion, a pull request review, capturing issues quickly ensures that problems become visible and can be tracked. </del> <ins> venue the issue was raised in (e.g., email, issue discussion, a pull request review); capturing issues quickly ensures that problems become visible and can be tracked. </ins> This takes a little more effort, but these simple steps can help encourage contributions, which will ultimately improve the quality of


10.2. <del> These properties specifies configurations for the User Timeout Option </del> <ins> These properties specify configurations for the User Timeout Option </ins> (UTO), in case TCP becomes the chosen transport protocol. Implementation is optional and of course only sensible if TCP is implemented in the transport system. <del> All of the below parameters are optional (e.g., it is possible to </del> <ins> These TCP-specific properties are included here because the feature "Suggest timeout to the peer" is part of the minimal set of transport services I-D.ietf-taps-minset, where this feature was categorized as "functional".  This means that when an implementation offers this feature, it has to expose an interface to it to the application. Otherwise, the implementation might violate assumptions by the application, which could cause the application to fail. All of the below properties are optional (e.g., it is possible to </ins> specify "User Timeout Enabled" as true, but not specify an Advertised User Timeout value; in this case, the TCP default will be used).


identifiers or IP address information, to the Issuer.  Tokens produced by an Issuer that admits issuance for any type of attestation cannot be relied on for any specific property.  See <del> attester-role for more details. </del> <ins> attester for more details. </ins> 3.2.1.


otherwise gathered metrics) to better estimate the "RateLimit-Reset" moment intended by the server. <del> The "quota-policy" values and comments provided in "RateLimit-Limit" are informative and MAY be ignored. </del> <ins> The details provided in "RateLimit-Policy" are informative and MAY be ignored. </ins> If a response contains both the "RateLimit-Reset" and "Retry-After" fields, "Retry-After" MUST take precedence and "RateLimit-Reset" MAY


protocol execution (specifically, cipher suite, see cs) but other parameters are only communicated and may not be negotiated (e.g., which authentication method is used, see method).  Yet other <del> parameters need to be known out-of-band. </del> <ins> parameters need to be known out-of-band.  The application decides which endpoint is Initiator and which is Responder. </ins> The purpose of an application profile is to describe the intended use of EDHOC to allow for the relevant processing and verifications to be


not be supported. This document proposes an overall solution to this problem by <del> registering ephemeral mDNS RFC6762 names for each local private IP address, and then providing those names, rather than the IP addresses, to the web application when it gathers ICE candidates. WebRTC implementations resolve these names to IP addresses and perform ICE processing as usual, but the actual IP addresses are not exposed to the web application. </del> <ins> providing a mechanism for WebRTC implementations to register ephemeral mDNS RFC6762 names for local private IP addresses, and then provide those names, rather than the IP addresses, in their ICE candidates.  While this technique is intended to benefit WebRTC implementations in web browsers, by preventing collection of private IP addresses by arbitrary web pages, it can also be used by any endpoint that wants to avoid disclosing information about its local network to remote peers on other networks. WebRTC and WebRTC-compatible endpoints Overview that receive ICE candidates with mDNS names will resolve these names to IP addresses and perform ICE processing as usual.  In the case where the endpoint is a web application, the WebRTC implementation will manage this resolution internally and will not disclose the actual IP addresses to the application. </ins> 2.


3.3.2. <del> For each URL "[helper]" in "PAUploadStartResp.helper_urls", the client sends a GET request to "[helper]/key_config".  The helper responds with status 200 and an "HpkeConfig" message.  Next, the client collects the set of helpers it will upload shares to.  It ignores a helper if: </del> <ins> Let "[helper]" denote the helper URL encoded by "PAUploadStartResp.param.helper_url".  When a client sends a GET request to "[helper]/key_config", the helper responds with status 200 and an "HpkeConfig" message.  The client aborts if any of the following happen: </ins> the client and helper failed to establish a secure, helper- authenticated channel;


RFC EDITOR PLEASE DELETE THIS SECTION. <ins> draft-07 Initial version of the Tree based Application Key Schedule (*) Initial definition of the Init message for group creation (*) Fix issue with the transcript used for newcomers (*) Clarifications on message framing and HPKE contexts (*) </ins> draft-06 Reorder blanking and update in the Remove operation (*)


Wording fixes in RD definition <ins> Capitalization: Consistently using "registration resource" </ins> changes from -26 to -27 In general, this addresses the points that were pointed out in


The format provides a generalized way to attach any additional information to the timestamp. <ins> We refer to this format as the Internet Extended Date/Time Format (IXDTF). </ins> This document does not address extensions to the format where the semantic result is no longer a fixed timestamp that is referenced to a (past or future) UTC time.  For instance, it does not address:


header field names proliferates. <del> Client applications interfacing with different servers may thus need to process different headers, or the very same application interface </del> <ins> User Agents interfacing with different servers may thus need to process different headers, or the very same application interface </ins> that sits behind different reverse proxies may reply with different throttling headers.


By virtue of the definition of the data stream, the Capsule Protocol is not in use on responses unless the response includes a 2xx <del> (Successful) status code.  The Capsule Protocol MUST NOT be used with messages that contain Content-Length or Transfer-Encoding header fields. </del> <ins> (Successful) status code. The Capsule Protocol MUST NOT be used with messages that contain Content-Length, Content-Type, or Transfer-Encoding header fields. Additionally, HTTP status codes 204 (No Content), 205 (Reset Content), and 206 (Partial Content) MUST NOT be sent on responses that use the Capsule Protocol. </ins> 4.2. <del> Definitions of new HTTP Methods or of new HTTP Upgrade Tokens that use the Capsule Protocol MAY use the Capsule-Protocol header field to simplify intermediary processing. </del> <ins> Definitions of new HTTP Upgrade Tokens that use the Capsule Protocol MAY use the Capsule-Protocol header field to simplify intermediary processing. </ins> "Capsule-Protocol" is an Item Structured Header RFC8941.  Its value MUST be a Boolean.  Its ABNF is:


All HTTP/3 requests MUST include exactly one value for the ":method", ":scheme", and ":path" pseudo-header fields, unless it is a CONNECT <del> request (connect).  An HTTP request that omits mandatory pseudo- header fields or contains invalid values for those fields is malformed (malformed). </del> <ins> request (connect). If the ":scheme" pseudo-header field identifies a scheme which has a mandatory authority component (including "http" and "https"), the request MUST contain either an ":authority" pseudo-header field or a "Host" header field.  If these fields are present, they MUST NOT be empty.  If both fields are present, they MUST contain the same value. If the scheme does not have a mandatory authority component and none is provided in the request target, the request MUST NOT contain the ":authority" pseudo-header and "Host" header fields. An HTTP request that omits mandatory pseudo-header fields or contains invalid values for those fields is malformed (malformed). </ins> HTTP/3 does not define a way to carry the version identifier that is included in the HTTP/1.1 request line.


(method equals 2 or 3), then mac_length_3 is the EDHOC MAC length of the selected cipher suite.  If the Initiator authenticates with a signature key (method equals 0 or 1), then <del> mac_length_3 is equal to the output size of the EDHOC hash algorithm of the selected cipher suite. </del> <ins> mac_length_3 is equal to hash_length. </ins> ID_CRED_I - identifier to facilitate the retrieval of CRED_I, see


constants-of-interest) for a new path, but the delay SHOULD NOT be considered an RTT sample. <del> Prior to handshake completion, when few to none RTT samples have been generated, it is possible that the probe timer expiration is due to an incorrect RTT estimate at the client.  To allow the client to improve its RTT estimate, the new packet that it sends MUST be ack- eliciting. </del> Initial packets and Handshake packets could be never acknowledged, but they are removed from bytes in flight when the Initial and Handshake keys are discarded, as described below in discarding-


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


the "extensions" field of a LeafNode object with the "application_id" extension. <del> However, applications SHOULD NOT rely on the data in an </del> <ins> However, applications MUST NOT rely on the data in an </ins> "application_id" extension as if it were authenticated by the Authentication Service, and SHOULD gracefully handle cases where the identifier presented is not unique.


ready to use as soon as it is passed to the application via the event. <del> A ListenError occurs either when the Preconnection cannot be fulfilled for listening, when the Local Endpoint (or Remote Endpoint, if specified) cannot be resolved, or when the application is prohibited from listening by policy. </del> <ins> A ListenError occurs either when the Properties of the Preconnection cannot be fulfilled for listening, when the Local Endpoint (or Remote Endpoint, if specified) cannot be resolved, or when the application is prohibited from listening by policy. </ins> <del> A Stopped event occurs after the Preconnection has stopped listening. </del> <ins> A Stopped event occurs after the Listener has stopped listening. </ins> 6.3.


The API must ensure the integrity of this information, as well as its confidentiality. <del> 5.4. </del> <ins> 6.4. </ins> It is possible for any user on the Internet to send ICMP packets in an attempt to cause the receiving equipment to go to the captive


is Any-source Multicast, and the path selection is based on the outbound route to the group supplied in the Local Endpoint. <ins> There are cases where it is required to open multiple connections for the same address(es).  For example, one Connection might be opened for a multicast group to for a multicast control bus, and another application later opens a separate Connection to the same group to send signals to and/or receive signals from the common bus.  In such cases, the interface needs to explicitly enable re-use of the same set of addresses (equivalent to setting SO_REUSEADDR in the socket API). </ins> UDP Multicast Receive Listeners will deliver new connections once they have received traffic from a new Remote Endpoint.


make use of the data that arrived; the ability to manage dependencies between messages, when the <del> Transport System could decide to not deliver a message, either following packet loss or because it has missed a deadline.  In particular, this can avoid (re-)sending data that relies on a </del> <ins> Transport Services system could decide to not deliver a message, either following packet loss or because it has missed a deadline. In particular, this can avoid (re-)sending data that relies on a </ins> previous transmission that was never received. the ability to automatically assign messages and connections to


A Retry packet causes a client to send another Initial packet, effectively restarting the connection process.  A Retry packet indicates that the Initial was received, but not processed.  A Retry <del> packet MUST NOT be treated as an acknowledgment. </del> <ins> packet cannot be treated as an acknowledgment, because it does not indicate that a packet was processed or specify the packet number. </ins> Clients that receive a Retry packet reset congestion control and loss recovery state, including resetting any pending timers.  Other


extension but CH1 does not, then the server MUST abort the handshake with an "illegal_parameter" alert. <del> Suppose the "encrypted_client_hello" extension is sent in both CH1 and CH2, If the configuration identifier (see ech-configuration) differs between CH1 and CH2, then the server MUST abort with an "illegal_parameter" alert. </del> <ins> If the "encrypted_client_hello" extension is sent in CH2, the server follows the procedure in client-facing-server to decrypt the extension, but it uses the previously-selected ECHConfig as the set of candidate ECHConfigs.  If decryption fails, the server aborts the connection with a "decrypt_error" alert rather than continuing the handshake with the second ClientHelloOuter. </ins> [[OPEN ISSUE: If the client-facing server implements stateless HRR, it has no way to send a cookie, short of as-yet-unspecified


URIs and relative references, and not limit the set of discovered URIs to those hosted at the address used for URI discovery. <ins> With security policies where the client requires the RD to be authorized to act as an RD, that authorization may be limited to resources on which the authorized RD advertises the adequate resource types.  Clients that have obtained links they can not rely on yet can repeat the URI discovery step at the /.well-known/core resource of the indicated host to obtain the resource type information from an authorized source. </ins> The URI Discovery operation can yield multiple URIs of a given resource type.  The client of the RD can use any of the discovered addresses initially.


4.1.4. Direct Key Agreement derives the CEK from the shared secret computed <del> by the key agreement operation.  For Direct Key Agreement, no recipient structure is built.  All of the information about the key and key agreement process is placed in either the 'protected' or 'unprotected' fields at the content level. </del> <ins> by the key agreement operation. </ins> When direct key agreement mode is used, it SHOULD be the only mode used on the message.  This method creates the CEK directly and that


The Privacy Pass protocol provides a privacy-preserving authorization mechanism.  In essence, the protocol allows clients to provide cryptographic tokens that prove nothing other than that they have <del> been created by a given server in the past I-D.ietf-privacypass- architecture. </del> <ins> been created by a given server in the past ARCHITECTURE. </ins> This document describes the issuance protocol for Privacy Pass.  It specifies two variants: one that is privately verifiable based on the oblivious pseudorandom function from OPRF, and one that is publicly verifiable based on the blind RSA signature scheme BLINDRSA. <del> This document DOES NOT cover the architectural framework required for running and maintaining the Privacy Pass protocol in the Internet setting.  In addition, it DOES NOT cover the choices that are necessary for ensuring that client privacy leaks do not occur.  Both of these considerations are covered in I-D.ietf-privacypass- architecture. </del> <ins> This document does not cover the Privacy Pass architecture, including choices that are necessary for ensuring that client privacy leaks. This information is covered in ARCHITECTURE. </ins> 2.


respective fields. If there is no key in the configuration, the server MUST fill the <del> Nonce field with bytes that appear to be random.  If there is a key, the server fills the nonce field with a nonce of its choosing.  See cid-entropy for details. </del> <ins> Nonce field with bytes that have no observable relationship to the field in previously issued connection IDs.  If there is a key, the server fills the nonce field with a nonce of its choosing.  See cid- entropy for details. </ins> The server MAY append additional bytes to the connection ID, up to the limit specified in that version of QUIC, for its own use.  These


applies) "NodesType". If it occurs directly as a "comparable" in a comparison, the <del> function is declared to have a result type of "ValueType", or (conversion applies) "NodesType". </del> <ins> function is declared to have a result type of "ValueType". </ins> Otherwise, it occurs as an argument in another function expression, and the following rules for function arguments apply


transport parameter; see termination.  However, state in middleboxes might time out earlier than that.  Though REQ-5 in RFC4787 recommends a 2 minute timeout interval, experience shows that sending packets <del> every 15 to 30 seconds is necessary to prevent the majority of middleboxes from losing state for UDP flows. </del> <ins> every 30 seconds is necessary to prevent the majority of middleboxes from losing state for UDP flows GATEWAY. </ins> 10.3.


6. <ins> The IMMEDIATE_ACK Frame is a frame which causes the peer to send a packet containing an ACK frame immediately, similar to the receipt of Initial and Handshake packets during the QUIC handshake. Receivers of the IMMEDIATE_ACK frame MAY choose to delay sending the ACK if the vast majority of received packets contain an IMMEDIATE_ACK or the receiver is under heavy load.  Senders MAY include multiple IMMEDIATE_ACK frames in a single QUIC packet, but the behavior is identical to a single IMMEDIATE_ACK frame. 7. </ins> Prior to receiving an ACK_FREQUENCY frame, endpoints send acknowledgements as specified in Section 13.2.1 of QUIC-TRANSPORT.


The bandwidth is per L2VPN service. <del> 'svc-inbound-bandwidth' indicates the inbound bandwidth of the </del> <ins> 'svc-pe-to-ce-bandwidth' indicates the inbound bandwidth of the </ins> connection (i.e., download bandwidth from the service provider to the site). <del> 'svc-outbound-bandwidth' indicates the outbound bandwidth of the </del> <ins> 'svc-ce-to-pe-bandwidth' indicates the outbound bandwidth of the </ins> connection (i.e., upload bandwidth from the site to the service provider).


its prior membership with a PSK. There are a few practical challenges to this approach.  For example, <del> the application will need to ensure that the new members have the </del> <ins> the application will need to ensure that all members have the </ins> required PSK, including any new members that have joined the group since the epoch in which the PSK was issued.


nonce re-use since the client's ESNI key share, and thus the value of Zx, does not change across ClientHello retries.) <ins> Note that ESNIContents will not be directly transmitted to the server in the ClientHello.  The server will instead reconstruct the same object by obtaining its values from ClientEncryptedSNI and ClientHello. </ins> [[TODO: label swapping fixes a bug in the spec, though this may not be the best way to deal with HRR.  See https://github.com/tlswg/ draft-ietf-tls-esni/issues/121 and https://github.com/tlswg/draft- ietf-tls-esni/pull/170 for more details.]] <ins> Same value as ClientEncryptedSNI.record_digest. Same value as ClientEncryptedSNI.key_share. Same nonce as ClientHello.random. </ins> The client then creates a ClientESNIInner structure: A random 16-octet value to be echoed by the server in the


The next bit (0x40) of byte 0 is set to 1.  Packets containing a zero value for this bit are not valid packets in this version and <del> MUST be discarded. </del> <ins> MUST be discarded.  A value of 1 for this bit allows QUIC to coexist with other protocols; see RFC7983. </ins> The third most significant bit (0x20) of byte 0 is the latency spin bit, set as described in spin-bit.


5.2. The following MAC algorithm applies to block ciphers that use the <del> with Encrypt-then-MAC processing described in RFC7366. </del> <ins> Encrypt-then-MAC processing described in RFC7366. </ins> 5.3.


7. Security considerations for DetNet are described in detail in I- <del> D.ietf-detnet-security.  This section considers exclusively security considerations which are specific to the DetNet data plane. </del> <ins> D.ietf-detnet-security.  General security considerations are described in I-D.ietf-detnet-architecture.  This section considers exclusively security considerations which are specific to the DetNet IP data plane. </ins> Security aspects which are unique to DetNet are those whose aim is to provide the specific quality of service aspects of DetNet, which are


DTLS RFC6347 or DTLS-SRTP RFC5763, MUST be used, as appropriate for the media type, as specified in <del> 5.1.3. </del> <ins> The SDES SRTP keying mechanism from RFC4568 MUST NOT be used, as discussed in I-D.ietf-rtcweb-security-arch. 5.1.2. </ins> <del> For media m= sections, JSEP implementations MUST support both the "UDP/TLS/ RTP/SAVPF" and "TCP/DTLS/RTP/SAVPF" profiles and MUST indicate one of these two profiles for each media m= line they produce in an offer.  For data m= sections, implementations MUST support both the "UDP/DTLS/SCTP" and "TCP/DTLS/SCTP" profiles and MUST indicate one of these two profiles for each data m= line they </del> <ins> For media m= sections, JSEP implementations MUST support the "UDP/TLS/RTP/SAVPF" profile specified in RFC7850, and MUST indicate this profile for each media m= line they produce in an offer.  For data m= sections, implementations MUST support the "UDP/DTLS/SCTP" profile and MUST indicate this profile for each data m= line they </ins> produce in an offer.  Because ICE can select either TCP or UDP <del> transport depending on network conditions, both advertisements are </del> <ins> transport depending on network conditions, this advertisement is </ins> consistent with ICE eventually selecting either either UDP or TCP. Unfortunately, in an attempt at compatibility, some endpoints


In addition, the client MAY advise the server at which IP the challenge is provisioned: <del> An IPv4 or IPv6 address which, if given, MUST be included in the set of IP addresses to which the domain name resolves.  If given, the server will connect to that specific IP address instead of arbitrarily choosing an IP from the set of A and AAAA records to which the domain name resolves.  If the field is given but equal to ""peer"", the server MUST treat the field as if it contained the IP address from which the response was received. </del> <ins> An IPv4 or IPv6 address which, in dotted decimal form or RFC4291 form, respectively.  If given, this address MUST be included in the set of IP addresses to which the domain name resolves.  If given, the server SHOULD connect to that specific IP address instead of arbitrarily choosing an IP from the set of A and AAAA records to which the domain name resolves. </ins> On receiving a response, the server MUST verify that the key authorization in the response matches the "token" value in the


12.3. A new group can be formed from a subset of an existing group's <del> members, using the same parameters as the old group.  The creator of the group indicates this situation by including a PreSharedKey of type "resumption" with usage "branch" in the Welcome message that creates the branched subgroup. </del> <ins> members, using the same parameters as the old group. A member can create a sub-group by performing the following steps: Determine a subset of existing members that should be a part of the sub-group. Create a new tree for the sub-group by fetching a new KeyPackage for each existing member that should be included in the sub-group. Create a Welcome message that includes a PreSharedKey of type "resumption" with usage "branch". </ins> A client receiving a Welcome including a PreSharedKey of type "resumption" with usage "branch" MUST verify that the new group


The COSE_encrypt structure for the recipient is organized as follows: <del> The 'protected', 'aad', and 'recipients' fields MUST be null. </del> <ins> The 'protected', 'aad', and 'recipients' fields MUST be nil. </ins> The plain text to be encrypted is the key from next layer down (usually the content layer).


9. <ins> This protocol defines new HTTP header fields in iana.header.fields. New link relation types are identified using the URNs defined in iana.urns. 9.1. HTTP header fields are registered within the "Message Headers" registry maintained at <https://www.iana.org/assignments/message- headers/>. This document defines the following HTTP header fields, so their associated registry entries shall be added according to the permanent registrations below (see RFC3864): The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force". 9.2. </ins> This document registers three URNs for use in identifying link relation types.  These are added to a new "Web Push Identifiers" registry according to the procedures in Section 4 of RFC3553; the


establishing UDP relay candidates using TURN over TCP to connect to their respective relay servers. <del> Third, using TCP only between the endpoint and its relay may result in less issues with TCP in regards to real-time constraints, e.g. due to head of line blocking. </del> <ins> Third, using TCP between the client's TURN server and the peer may result in more performance problems than using UDP, e.g. due to head of line blocking. </ins> ICE-TCP candidates RFC6544 MUST be supported; this may allow applications to communicate to peers with public IP addresses across


QUIC begins every connection in slow start with the congestion window set to an initial value.  Endpoints SHOULD use an initial congestion window of 10 times the maximum datagram size (max_datagram_size), <del> limited to the larger of 14720 bytes or twice the maximum datagram size.  This follows the analysis and recommendations in RFC6928, increasing the byte limit to account for the smaller 8-byte overhead of UDP compared to the 20-byte overhead for TCP. </del> <ins> while limiting the window to the larger of 14720 bytes or twice the maximum datagram size.  This follows the analysis and recommendations in RFC6928, increasing the byte limit to account for the smaller 8-byte overhead of UDP compared to the 20-byte overhead for TCP. </ins> If the maximum datagram size changes during the connection, the initial congestion window SHOULD be recalculated with the new size.


1.1. <del> The terminology from RFC7252 and STD94 applies.  Readers are also expected to be familiar with the terminology from RFC7807. </del> <ins> The terminology from RFC7252, STD94, and RFC8610 applies; in particular CBOR diagnostic notation is defined in STD94 and RFC8610. Readers are also expected to be familiar with the terminology from RFC7807. </ins> In this document, the structure of data is specified in CDDL RFC8610 RFC9165.


contained within the RendezvousDone<> Event, and is ready to use as soon as it is passed to the application via the Event. <del> An RendezvousError occurs either when the Preconnection cannot be fulfilled for listening, when the Local Endpoint or Remote Endpoint cannot be resolved, when no transport-layer connection can be established to the Remote Endpoint, or when the application is prohibited from rendezvous by policy. </del> <ins> An RendezvousError occurs either when the Properties and Security Parameters of the Preconnection cannot be fulfilled for rendezvous or cannot be reconciled with the Local and/or Remote Endpoints, when the Local Endpoint or Remote Endpoint cannot be resolved, when no transport-layer connection can be established to the Remote Endpoint, or when the application is prohibited from rendezvous by policy. </ins> When using some NAT traversal protocols, e.g., Interactive Connectivity Establishment (ICE) RFC5245, it is expected that the


for a human user to navigate to.  If the user chooses to complete this challenge (by visiting the website and completing its instructions), the client indicates this by sending a simple <del> acknowledgement response to the server. The string "oob-01" </del> <ins> acknowledgement response to the server.  The payload of this response is an empty JSON object ("{}", or "e30" base64url-encoded). </ins> On receiving a response, the server MUST verify that the value of the "type" field is "oob-01".  Otherwise, the steps the server takes to


<del> DNS Queries over HTTPS </del> <ins> DNS Queries over HTTPS (DOH) </ins> draft-ietf-doh-dns-over-https Abstract <del> This document describes how to run DNS service over HTTP (DOH) using https:// URIs. </del> <ins> This document describes how to make DNS queries over HTTPS. </ins> 1. This document defines a specific protocol for sending DNS RFC1035 <del> queries and getting DNS responses over HTTP RFC7540 using https:// </del> <ins> queries and getting DNS responses over HTTP RFC7540 using https URIs </ins> (and therefore TLS RFC5246 security for integrity and confidentiality).  Each DNS query-response pair is mapped into a HTTP exchange.


applications written to a single API to make use of transport protocols in terms of the features they provide. <del> A unified interface to datagram and connection-oriented transports, allowing use of a common API for connection- establishment and closing. </del> <ins> A unified interface to datagram and stream-oriented transports, allowing use of a common API for connection establishment and closing. </ins> Message-orientation, as opposed to stream-orientation, using application-assisted framing and deframing where the underlying


Replace the IP address of the ICE candidate with its mDNS hostname and provide the candidate to the web application. <del> An ICE agent can implement this procedure in any way so long as it produces equivalent results to this procedure. </del> <ins> ICE agents can implement this procedure in any way as long as it produces equivalent results.  An implementation may for instance pre- register mDNS hostnames by executing steps 3 to 6 and prepopulate an ICE agent accordingly.  By doing so, only step 7 of the above procedure will be executed at the time of gathering candidates. </ins> <del> An implementation may for instance pre-register mDNS hostnames by executing steps 3 to 5 and prepopulate an ICE agent accordingly.  By doing so, only step 6 of the above procedure will be executed at the time of gathering candidates. </del> <ins> ICE agents may also decide that certain local IP addresses are safe to expose.  This may be because the ICE agent has a priori knowledge that the address is in fact public, or because the agent has made a policy decision to not conceal certain types of IP addresses (e.g., those with built-in privacy protections) as a calculated choice to improve connectivity.  This topic is discussed further in {#privacy} below. </ins> An implementation may also detect that mDNS is not supported by the <del> available network interfaces.  The ICE agent may skip steps 2 and 3 </del> <ins> available network interfaces.  The ICE agent may skip steps 3 and 4 </ins> and directly decide to not expose the host candidate. This procedure ensures that an mDNS name is used to replace only one


Context associated to endpoint X.  The Recipient Key is used as salt in the HKDF, when deriving the Pairwise Recipient Key. <del> The Shared Secret is computed as a static-static Diffie-Hellman shared secret NIST-800-56A, where the endpoint uses its private key and the public key of the other endpoint X.  The Shared Secret is used as Input Keying Material (IKM) in the HKDF. </del> <ins> IKM-Sender - the Input Keying Material (IKM) used in HKDF for the derivation of the Pairwise Sender Key - is the concatenation of the endpoint's own signature public key, endpoint X's signature public key from the Recipient Context, and the Shared Secret IKM-Recipient - the Input Keying Material (IKM) used in HKDF for the derivation of the Recipient Sender Key - is the concatenation of endpoint X's signature public key from the Recipient Context, the endpoint's own signature public key, and the Shared Secret. The Shared Secret is computed as a cofactor Diffie-Hellman shared secret, see Section 5.7.1.2 of NIST-800-56A, where the endpoint uses its private key and the public key of the other endpoint X. Note the requirement of validation of public keys in ssec-crypto- considerations.  For X25519 and X448, the procedure is described in Section 5 of RFC7748 using public keys mapped to Montgomery coordinates, see montgomery. </ins> info and L are as defined in Section 3.2.1 of RFC8613. If EdDSA asymmetric keys are used, the Edward coordinates are mapped to Montgomery coordinates using the maps defined in Sections 4.1 and 4.2 of RFC7748, before using the X25519 and X448 functions defined in <del> Section 5 of RFC7748. </del> <ins> Section 5 of RFC7748.  For further details, see montgomery. </ins> After establishing a partially or completely new Security Context (see ssec-sec-context-persistence and sec-group-key-management), the


write data, understanding when stream flow control credit (data- flow-control) has successfully been reserved to send the written <del> data </del> <ins> data; </ins> end the stream (clean termination), resulting in a STREAM frame (frame-stream) with the FIN bit set; and reset the stream (abrupt termination), resulting in a RESET_STREAM <del> frame (frame-reset-stream), even if the stream was already ended. </del> <ins> frame (frame-reset-stream), if the stream was not already in a terminal state. </ins> On the receiving part of a stream, application protocols need to be able to: <del> read data </del> <ins> read data; and </ins> abort reading of the stream and request closure, possibly <del> resulting in a STOP_SENDING frame (frame-stop-sending) </del> <ins> resulting in a STOP_SENDING frame (frame-stop-sending). </ins> Applications also need to be informed of state changes on streams, including when the peer has opened or reset a stream, when a peer


The semantics of the other CoAP header fields are left unchanged. <del> 2.4. </del> <ins> 2.5. </ins> CoAP requests and responses are exchanged asynchronously over the TCP/TLS connection.  A CoAP client can send multiple requests without


Capability and Settings messages are used for two purposes: <del> Capability options advertise the capabilities of the sender to the recipient. </del> <ins> Each capability option advertises one capability of the sender to the recipient. </ins> Setting options indicate a setting that will be applied by the sender.


send a Certificate message and a CertificateVerify message, even if the "known_configuration" extension was used for this handshake, thus requiring a signature over the configuration before it can be used by <del> the client. </del> <ins> the client.  Clients MUST not rely on the ServerConfiguration message until successfully receiving and processing the server's Certificate, CertificateVerify, and Finished.  If there is a failure in processing those messages, the client MUST discard the ServerConfiguration. </ins> 6.3.8.


Remote Endpoint and the Local Endpoint, such as IP addresses resolved from a DNS hostname. <ins> 4.2.3. While some transports expose a byte stream abstraction, most higher level protocols impose some structure onto that byte stream.  That is, the higher level protocol operates in terms of messages, protocol data units (PDUs), rather than using unstructured sequences of bytes, with each message being processed in turn.  Protocols are specified in terms of state machines acting on semantic messages, with parsing the byte stream into messages being a necessary annoyance, rather than a semantic concern.  Accordingly, the Transport Services architecture exposes messages as the primary abstraction.  Protocols that deal only in byte streams, such as TCP, represent their data in each direction as a single, long message.  When framing protocols are placed on top of byte streams, the messages used in the API represent the framed messages within the stream. Providing a message-based abstraction also provides: the ability to associate deadlines with messages, for transports that care about timing; the ability to provide control of reliability, choosing what messages to retransmit in the event of packet loss, and how best to make use of the data that arrived; the ability to manage dependencies between messages, when some messages may not be delivered due to either packet loss or missing a deadline, in particular the ability to avoid (re-)sending data that relies on a previous transmission that was never received. All require explicit message boundaries, and application-level framing of messages, to be effective.  Once a message is passed to the transport, it can not be cancelled or paused, but prioritization as well as lifetime and retransmission management will provide the protocol stack with all needed information to send the messages as quickly as possible without blocking transmission unnecessarily.  The transport services architecture facilitates this by handling messages, with known identity (sequence numbers, in the simple case), lifetimes, niceness, and antecedents. Transport protocols such as SCTP provide a message-oriented API that has similar features to those we describe.  Other transports, such as TCP, do not.  To support a message oriented API, while still being compatible with stream-based transport protocols, implementations of the transport services architecture should provide APIs for framing and de-framing messages.  That is, we push message framing down into the transport services API, allowing applications to send and receive complete messages.  This is backwards compatible with existing protocols and APIs, since the wire format of messages does not change, but gives the protocol stack additional information to allow it to make better use of modern transport services. </ins> 5. RFC-EDITOR: Please remove this section before publication.


14. <del> The QUIC packet size includes the QUIC header and protected payload, but not the UDP or IP headers. </del> <ins> A UDP datagram can include one or more QUIC packets.  The datagram size refers to the total UDP payload size of a single UDP datagram carrying QUIC packets.  The datagram size includes one or more QUIC packet headers and protected payloads, but not the UDP or IP headers. The maximum datagram size is defined as the largest size of UDP payload that can be sent across a network path using a single UDP datagram. </ins> QUIC depends upon a minimum IP packet size of at least 1280 bytes. This is the IPv6 minimum size (IPv6) and is also supported by most <del> modern IPv4 networks.  Assuming the minimum IP header size, this results in a QUIC maximum packet size of 1232 bytes for IPv6 and 1252 bytes for IPv4. </del> <ins> modern IPv4 networks.  Assuming the minimum IP header size of 40 bytes for IPv6 and 20 bytes for IPv4 and a UDP header size of 8 bytes, this results in a maximum datagram size of 1232 bytes for IPv6 and 1252 bytes for IPv4. The maximum datagram size MUST be at least 1200 bytes. </ins> <del> The QUIC maximum packet size is the largest size of QUIC packet that can be sent across a network path using a single packet.  Any maximum packet size larger than 1200 bytes can be discovered using Path Maximum Transmission Unit Discovery (PMTUD; see pmtud) or Datagram Packetization Layer PMTU Discovery (DPLPMTUD; see dplpmtud). </del> <ins> Any maximum datagram size larger than 1200 bytes can be discovered using Path Maximum Transmission Unit Discovery (PMTUD; see pmtud) or Datagram Packetization Layer PMTU Discovery (DPLPMTUD; see dplpmtud). </ins> Enforcement of the max_udp_payload_size transport parameter (transport-parameter-definitions) might act as an additional limit on <del> the maximum packet size.  A sender can avoid exceeding this limit, </del> <ins> the maximum datagram size.  A sender can avoid exceeding this limit, </ins> once the value is known.  However, prior to learning the value of the transport parameter, endpoints risk datagrams being lost if they send <del> packets larger than the smallest allowed maximum packet size of 1200 bytes. </del> <ins> datagrams larger than the smallest allowed maximum datagram size of 1200 bytes. </ins> UDP datagrams MUST NOT be fragmented at the IP layer.  In IPv4 (IPv4), the DF bit MUST be set if possible, to prevent fragmentation


for a certificate using a Link relation header field with relation "ct-sct". <del> A certificate resource always represents the most recent certificate issued for the name/key binding expressed in the CSR.  If the CA allows a certificate to be renewed, then it publishes renewed versions of the certificate through the same certificate URI. Clients retrieve renewed versions of the certificate using a GET query to the certificate URI, which the server should then return in a 200 (OK) response.  The server SHOULD provide a stable URI for each specific certificate in the Content-Location header field, as shown above.  Requests to stable certificate URIs MUST always result in the same certificate. To avoid unnecessary renewals, the CA may choose not to issue a renewed certificate until it receives such a request (if it even allows renewal at all).  In such cases, if the CA requires some time to generate the new certificate, the CA MUST return a 202 (Accepted) response, with a Retry-After header field that indicates when the new certificate will be available.  The CA MAY include the current (non- renewed) certificate as the body of the response. Likewise, in order to prevent unnecessary renewal due to queries by parties other than the account key holder, certificate URIs should be structured as capability URLs W3C.WD-capability-urls-20140218. From the client's perspective, there is no difference between a certificate URI that allows renewal and one that does not.  If the client wishes to obtain a renewed certificate, and a GET request to the certificate URI does not yield one, then the client may initiate a new-certificate transaction to request one. </del> <ins> A certificate resource represents a single, immutable certificate. If the client wishes to obtain a renewed certificate, the client initiates a new-certificate transaction to request one. Because certificate resources are immutable once issuance is complete, the server MAY enable the caching of the resource by adding Expires and Cache-Control headers specifying a point in time in the distant future.  These headers have no relation to the certificate's period of validity. </ins> 6.6.


receiving a TLS ClientHello.  The server MAY retain these packets for later decryption in anticipation of receiving a ClientHello. <ins> A client generally receives 1-RTT keys at the same time as the handshake completes.  Even if it has 1-RTT secrets, a client MUST NOT process incoming 1-RTT protected packets before the TLS handshake is complete. </ins> 5.8. Retry packets (see the Retry Packet section of QUIC-TRANSPORT) carry


The DNS API client SHOULD include an HTTP "Accept" request header to indicate what type of content can be understood in response. Irrespective of the value of the Accept request header, the client <del> MUST be prepared to process "message/dns" (as described in dnswire) responses but MAY also process any other type it receives. </del> <ins> MUST be prepared to process "application/dns-message" (as described in dnswire) responses but MAY also process any other type it receives. </ins> In order to maximize cache friendliness, DNS API clients using media <del> formats that include DNS ID, such as message/dns, SHOULD use a DNS ID of 0 in every DNS request.  HTTP correlates the request and response, thus eliminating the need for the ID in a media type such as message/ dns.  The use of a varying DNS ID can cause semantically equivalent DNS queries to be cached separately. </del> <ins> formats that include DNS ID, such as application/dns-message, SHOULD use a DNS ID of 0 in every DNS request.  HTTP correlates the request and response, thus eliminating the need for the ID in a media type such as application/dns-message.  The use of a varying DNS ID can cause semantically equivalent DNS queries to be cached separately. </ins> DNS API clients can use HTTP/2 padding and compression in the same way that other HTTP/2 clients use (or don't use) them.


datagrams, it's best for all implementations that support this feature to always send this Settings parameter, see setting. <ins> Since use of the Capsule Protocol is restricted to new HTTP Upgrade Tokens, it is not accessible from Web Platform APIs (such as those commonly accessed via JavaScript in web browsers). </ins> 8. 8.1.


over the streams can be represented similarly to the TCP stream (one Message per direction, see tcp). <ins> Connectedness: Multiplexing Connected Data Unit: Stream Connection objects represent a single HTTP/2 stream on a HTTP/2 connection. 9.8. To support sender-side stream schedulers (which are implemented on the sender side), a receiver-side Transport System should always support message interleaving RFC8260. SCTP messages can be very large.  To allow the reception of large messages in pieces, a "partial flag" can be used to inform a (native SCTP) receiving application that a message is incomplete.  After receiving the "partial flag", this application would know that the next receive calls will only deliver remaining parts of the same message (i.e., no messages or partial messages will arrive on other streams until the message is complete) (see Section 8.1.20 in RFC6458).  The "partial flag" can therefore facilitate the implementation of the receiver buffer in the receiving application, at the cost of limiting multiplexing and temporarily creating head- of-line blocking delay at the receiver. When a Transport System transfers a Message, it seems natural to map the Message object to SCTP messages in order to support properties such as "Ordered" or "Lifetime" (which maps onto partially reliable delivery with a SCTP_PR_SCTP_TTL policy RFC6458).  However, since multiplexing of Connections onto SCTP streams may happen, and would be hidden from the application, the Transport System requires a per- stream receiver buffer anyway, so this potential benefit is lost and the "partial flag" becomes unnecessary for the system. The problem of long messages either requiring large receiver-side buffers or getting in the way of multiplexing is addressed by message interleaving RFC8260, which is yet another reason why a receivers- side transport system supporting SCTP should implement this mechanism. </ins> 10. RFC-EDITOR: Please remove this section before publication.


they do not limit what a server may respond under atypical circumstances. <del> REST clients (registrant-EPs / CTs, lookup clients, RD servers during simple registrations) MUST be prepared to receive any unsuccessful code and act upon it according to its definition, options and/or payload to the best of their capabilities, falling back to failing the operation if recovery is not possible.  In particular, they should retry the request upon 5.03 (Service Unavailable; 503 in HTTP) according to the Max-Age (Retry-After in HTTP) option, and fall back to link-format when receiving 4.15 (Unsupported Content-Format; 415 in HTTP). </del> <ins> REST clients (registrant-EPs and CTs during registration and maintenance, lookup clients, RD servers during simple registrations) MUST be prepared to receive any unsuccessful code and act upon it according to its definition, options and/or payload to the best of their capabilities, falling back to failing the operation if recovery is not possible.  In particular, they should retry the request upon 5.03 (Service Unavailable; 503 in HTTP) according to the Max-Age (Retry-After in HTTP) option, and fall back to link-format when receiving 4.15 (Unsupported Content-Format; 415 in HTTP). </ins> A resource directory MAY make the information submitted to it available to further directories, if it can ensure that a loop does


When a stream is reset or reading is abandoned, the decoder emits a Stream Cancellation instruction.  The instruction begins with the <del> '01' two-bit pattern.  The instruction includes the stream ID of the affected stream encoded as a 6-bit prefix integer.  See state- synchronization. </del> <ins> '01' two-bit pattern, which is followed by the stream ID of the affected stream encoded as a 6-bit prefix integer. This instruction is used as described in state-synchronization. </ins> 4.4.3. The Insert Count Increment instruction begins with the '00' two-bit <del> pattern.  The instruction specifies the total number of dynamic table inserts and duplications since the last Insert Count Increment or Header Acknowledgement that increased the Known Received Count for the dynamic table (see known-received-count).  The Increment field is encoded as a 6-bit prefix integer.  The encoder uses this value to determine which table entries might cause a stream to become blocked, as described in state-synchronization. </del> <ins> pattern, followed by the Increment encoded as a 6-bit prefix integer. The value of the Increment is the total number of dynamic table insertions and duplications processed by the decoder since the last time it sent a Header Acknowledgement instruction that increased the Known Received Count (see known-received-count) or an Insert Count Increment instruction.  The encoder uses this value to update the Known Received Count, as described in state-synchronization. </ins> An encoder that receives an Increment field equal to zero or one that increases the Known Received Count beyond what the encoder has sent


certificate was issued, and one with relation "author" to indicate the registration under which this certificate was issued. <del> The server MAY include an Expires header as a hint to the client about when to renew the certificate.  (Of course, the real expiration of the certificate is controlled by the notAfter time in the certificate itself.) </del> If the CA participates in Certificate Transparency (CT) RFC6962, then they may want to provide the client with a Signed Certificate Timestamp (SCT) that can be used to prove that a certificate was


a ciphertext value C with a length of N bytes. <del> The decryption function returns a plaintext value P that is at least M bytes long, or returns an indication that the decryption operation failed because the ciphertext was invalid (i.e. it was not generated by the encryption of plaintext with the key K). These functions have the property that D(K, E(K, P)) = ( P concatenated with optional padding) for all values of K and P.  Each cipher also has a limit T on the number of times that it can be used with any fixed key value.  The EKTKey MUST NOT be used for encryption more that T times.  Note that if the same EKT packet is retransmitted 3 times, that only counts as 1 encryption. </del> <ins> The decryption function returns a plaintext value P that is M bytes long, or returns an indication that the decryption operation failed because the ciphertext was invalid (i.e. it was not generated by the encryption of plaintext with the key K). These functions have the property that D(K, E(K, P)) = P for all values of K and P.  Each cipher also has a limit T on the number of times that it can be used with any fixed key value.  The EKTKey MUST NOT be used for encryption more that T times.  Note that if the same EKT packet is retransmitted 3 times, that only counts as 1 encryption. </ins> Security requirements for EKT ciphers are discussed in sec.


application. In general, any protocol or path used for a connection must conform <del> to all three sources of constraints.  A violation of any of the layers should cause a protocol or path to be considered ineligible for use.  For an example of application preferences leading to constraints, an application may prohibit the use of metered network interfaces for a given Connection to avoid user cost.  Similarly, the system policy at a given time may prohibit the use of such a metered network interface from the application's process.  Lastly, the implementation itself may default to disallowing certain network interfaces unless explicitly requested by the application and allowed by the system. </del> <ins> to all three sources of constraints.  A violation that occurs at any of the policy layers should cause a protocol or path to be considered ineligible for use.  For an example of application preferences leading to constraints, an application may prohibit the use of metered network interfaces for a given Connection to avoid user cost. Similarly, the system policy at a given time may prohibit the use of such a metered network interface from the application's process. Lastly, the implementation itself may default to disallowing certain network interfaces unless explicitly requested by the application and allowed by the system. </ins> It is expected that the database of system policies and the method of looking up these policies will vary across various platforms.  An


The RS signs the request with its own key and sends the access token as the body of the request. <ins> REQUIRED.  The access token value presented to the RS by the client instance. RECOMMENDED.  The proofing method used by the client instance to bind the token to the RS request. REQUIRED.  The identification used to authenticate the resource server making this call, either by value or by reference as described in authentication. OPTIONAL.  The minimum access rights required to fulfill the request.  This MUST be in the format described in the Resource Access Rights section of I-D.ietf-gnap-core-protocol. The AS MUST validate the access token value and determine if the token is active.  An active access token is defined as a token that was issued by the processing AS, has not been revoked, has not expired, and is appropriate for presentation at the identified RS. </ins> The AS responds with a data structure describing the token's current state and any information the RS would need to validate the token's presentation, such as its intended proofing mechanism and key <del> material.  The response MAY include any fields defined in an access token response. </del> <ins> material. REQUIRED.  If "true", the access token presented is active, as defined above.  If any of the criteria for an active token are not true, or if the AS is unable to make a determination (such as the token is not found), the value is set to "false" and other fields are omitted. If the access token is active, additional fields from the single access token response structure defined in I-D.ietf-gnap-core- protocol are included.  In particular, these include the following: REQUIRED.  The access rights associated with this access token. This MUST be in the format described in the Resource Access Rights section of I-D.ietf-gnap-core-protocol.  This array MAY be filtered or otherwise limited for consumption by the identified RS, including being an empty array. REQUIRED if the token is bound.  The key bound to the access token, to allow the RS to validate the signature of the request from the client instance.  If the access token is a bearer token, this MUST NOT be included. OPTIONAL.  The set of flags associated with the access token. The response MAY include any additional fields defined in an access token response and MUST NOT include the access token "value" itself. </ins> 3.4.


documents they edit but preserves the need for contributors to understand their obligations with respect to IETF processes. <ins> Work done in GitHub has no special status.  The output of any activity using GitHub needs to be taken to the Working Group and is subject to approval, rejection, or modification by the Working Group as with any other input. </ins> 3.2. New repositories can be created within the Working Group organization


6. <del> Encoding notifications for the HTTPS notifications is the same as the encoding notifications as defined in RFC8040 Section 6.4, with the following changes.  Instead of saying that for JSON-encoding purposes, the module name for "notification" element will be "ietf- restconf, it will say that for JSON-encoding purposes, the module name for "notification" element will be "ietf-https-notif". With those changes, the SSE event notification encoded JSON example that would be sent over the HTTPS notif transport would appear as follows: </del> <ins> Notifications are encoded as defined in RFC8040 Section 6.4.  The examples in that section apply for sending notifications over the "https-notif" based transport. An example of YANG-Push in JSON would look something like this: An example of YANG-Push in XML would look something like this: </ins> 7.


Application dependency: Specification of application-specific extensions. <del> Session caching (and management): Sessions should be cacheable to enable reuse and amortize the cost of performing session </del> <ins> Session caching and management (SC): Sessions should be cacheable to enable reuse and amortize the cost of performing session </ins> establishment handshakes. Transport dependency: None. Application dependency: None. <del> Length-hiding padding: Applications may wish to defer traffic padding to the security protocol to deter traffic analysis </del> <ins> Length-hiding padding (LHP): Applications may wish to defer traffic padding to the security protocol to deter traffic analysis </ins> attacks. Transport dependency: None. Application dependency: Knowledge of desired padding policies. <ins> 5.3. The following table lists the availability of the above-listed optional features in each of the analyzed protocols.  "Mandatory" indicates that the feature is intrinsic to the protocol and cannot be disabled.  "Supported" indicates that the feature is optionally provided natively or through a (standardized, where applicable) extension. M=Mandatory S=Supported but not required U=Unsupported *=On TCP; MPTCP would provide this ability **=TCP provides SYN cookies natively, but these are not cryptographically strong +=For transport packets only </ins> 6. This section describes the interface surface exposed by the security


peer.  For example, a client might be willing to consume a very large response header, while servers are more cautious about request size. <del> Parameters MUST NOT occur more than once in the SETTINGS frame.  A receiver MAY treat the presence of the same parameter more than once as a connection error of type HTTP_SETTINGS_ERROR. </del> <ins> The same setting identifier MUST NOT occur more than once in the SETTINGS frame.  A receiver MAY treat the presence of duplicate setting identifiers as a connection error of type HTTP_SETTINGS_ERROR. </ins> The payload of a SETTINGS frame consists of zero or more parameters. Each parameter consists of a setting identifier and a value, both


3. <del> The protocol in this document allows the domain owner to create a split-horizon DNS.  Other entities which do not own the domain are detected by the client.  Thus, DNS filtering is not enabled by this </del> <ins> The protocol in this document is designed to support the ability of a domain owner to create or authorize a split-horizon view of their domain.  The protocol does not support split-horizon views created by any other entity.  Thus, DNS filtering is not enabled by this </ins> protocol. 4.


The RECOMMENDED initial value for the packet reordering threshold (kPacketThreshold) is 3, based on best practices for TCP loss <del> detection RFC5681 RFC6675. </del> <ins> detection RFC5681 RFC6675.  Implementations SHOULD NOT use a packet threshold less than 3, to keep in line with TCP RFC5681. </ins> Some networks may exhibit higher degrees of reordering, causing a sender to detect spurious losses.  Implementers MAY use algorithms


An endpoint detected an error with protocol compliance that was not covered by more specific error codes. <ins> A server received a Retry Token in a client Initial that is invalid. </ins> An endpoint has received more data in CRYPTO frames than it can buffer.


curves, they SHOULD perform the additional checks specified in Section 7 of <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.5.2. This ciphersuite uses the following primitives:


The semantics of the other CoAP header fields are left unchanged. <del> 2.4. </del> <ins> 2.3. Once a connection is established, both the client and the server MUST send a Capabilities 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. To avoid unnecessary latency, a client MAY send additional messages without waiting to receive the server CSM; however, it is important to note that the server CSM might advertise capabilities that impact how a client is expected to communicate with the server.  For example, the server CSM could advertise a Max-Message-Size option (see max-message-size) that is smaller than the base value (1152). Clients and servers MUST treat a missing or invalid CSM as a connection error and abort the connection (see sec-abort). </ins> CoAP requests and responses are exchanged asynchronously over the TCP/TLS connection.  A CoAP client can send multiple requests without


multiple data channels between them. An implementation of the Interactive Connectivity Establishment <del> (ICE) I-D.ietf-ice-rfc5245bis protocol.  An ICE Agent may also be an SDP Agent, but there exist ICE Agents that do not use SDP (for instance those that use Jingle XEP-0166). </del> <ins> (ICE) RFC5245 protocol.  An ICE Agent may also be an SDP Agent, but there exist ICE Agents that do not use SDP (for instance those that use Jingle XEP-0166). </ins> Communication between multiple parties, where the expectation is that an action from one party can cause a reaction by another


5.1. <ins> When using HTTP/3 with the QUIC Datagram extension DGRAM, UDP payloads are transmitted in QUIC DATAGRAM frames.  Since those cannot be fragmented, they can only carry payloads up to a given length determined by the QUIC connection configuration and the path MTU.  If a proxy is using QUIC DATAGRAM frames and it receives a UDP payload from the target that will not fit inside a QUIC DATAGRAM frame, the proxy SHOULD NOT send the UDP payload in a DATAGRAM capsule, as that defeats the end-to-end unreliability characteristic that methods such as Datagram Packetization Layer Path MTU Discovery (DPLPMTUD) depend on RFC8899.  In this scenario, the proxy SHOULD drop the UDP payload and send an ICMP "Packet Too Big" message to the target RFC4443. 5.2. </ins> UDP proxying does not create an IP-in-IP tunnel, so the guidance in RFC6040 about transferring ECN marks between inner and outer IP headers does not apply.  There is no inner IP header in UDP proxying


resources allocated by the caller can be released, now that the exact session configuration is known.  These "resources" can include things like extra ICE components, TURN candidates, or video decoders. <del> Provisional answers, on the other hand, do no such deallocation results; as a result, multiple dissimilar provisional answers can be received and applied during call setup. </del> <ins> Provisional answers, on the other hand, do no such deallocation; as a result, multiple dissimilar provisional answers can be received and applied during call setup. </ins> In RFC3264, the constraint at the signaling level is that only one offer can be outstanding for a given session, but at the media stack


registration, to allow a client to retrieve the "new-authorization" and "terms-of-service" URI <del> 6.3.1. If the client wishes to establish a secret key with the server that it can use to recover this account later (a "recovery key"), then it must perform a simple key agreement protocol as part of the new- registration transaction.  The client and server perform an ECDH exchange through the new-registration transaction (using the technique in key-agreement), and the result is the recovery key. To request a recovery key, the client includes a "recoveryKey" field in its new-registration request.  The value of this field is a JSON object. The client's ECDH public key The length of the derived secret, in octets. In the client's request, this object contains a JWK for a random ECDH public key generated by the client and the client-selected length value.  Clients need to choose length values that balance security and usability.  On the one hand, a longer secret makes it more difficult for an attacker to recover the secret when it is used for recovery (see mac-based-recovery).  On the other hand, clients may wish to make the recovery key short enough for a user to easily write it down. The server MUST validate that the elliptic curve ("crv") and length value chosen by the client are acceptable, and that it is otherwise willing to create a recovery key.  If not, then it MUST reject the new-registration request. If the server agrees to create a recovery key, then it generates its own random ECDH key pair and combines it with the client's public key as described in key-agreement above, using the label "recovery".  The derived secret value is the recovery key.  The server then returns to the client the ECDH key that it generated.  The server MUST generate a fresh key pair for every transaction. The server's ECDH public key On receiving the server's response, the client can compute the recovery key by combining the server's public key together with the private key corresponding to the public key that it sent to the server. Clients may refresh the recovery key associated with a registration by sending a POST request with a new recoveryKey object.  If the server agrees to refresh the recovery key, then it responds in the same way as to a new registration request that asks for a recovery key. </del> 6.4. Once a client has created an account with an ACME server, it is


Further configurations are possible, including those where a WebSocket connection is established through an HTTP proxy. <del> CoAP over WebSockets is intentionally very similar to CoAP over UDP. Therefore, instead of presenting CoAP over WebSockets as a new protocol, this document specifies it as a series of deltas from RFC7252. </del> 3.1. Before CoAP requests and responses are exchanged, a WebSocket


ordered delivery of cryptographic handshake data start from zero in each packet number space. <ins> fig-hs shows a simplied handshake and the exchange of packets and frames that are used to advance the handshake.  Exchange of application data during the handshake is enabled where possible, shown with a '*'.  Once completed, endpoints are able to exchange application data. </ins> Endpoints MUST explicitly negotiate an application protocol.  This avoids situations where there is a disagreement about the protocol that is in use.


3. <del> A Working Group Chairs are responsible for determining how to best </del> <ins> Working Group Chairs are responsible for determining how to best </ins> accomplish the Charter in an open and transparent fashion.  The Working Group Chairs are responsible for determining if there is interest in using GitHub and making a consensus call to determine if <del> a the proposed policy and use is acceptable. </del> <ins> the proposed policy and use is acceptable. </ins> <del> Chairs MUST involve Area Directors any decision to use GitHub for anything more than managing of drafts. </del> <ins> Chairs MUST involve Area Directors in any decision to use GitHub for anything more than managing drafts. </ins> While a document editor can still use GitHub independently for documents that they edit, even if the working group does not


the "challenges" dictionary. The client sends these updates back to the server in the form of a <del> JSON object with the response fields required by the challenge type, carried in a POST request to the challenge URL (not authorization URL) once it is ready for the server to attempt validation. </del> <ins> JSON object with contents as specified by the challenge type, carried in a POST request to the challenge URL (not authorization URL) once it is ready for the server to attempt validation. </ins> For example, if the client were to respond to the "http-01" challenge in the above authorization, it would send the following request: The server updates the authorization document by updating its <del> representation of the challenge with the response fields provided by </del> <ins> representation of the challenge with the response object provided by </ins> the client.  The server MUST ignore any fields in the response object that are not specified as response fields for this type of challenge. The server provides a 200 (OK) response with the updated challenge


Abstract <del> This document defines a YANG RPC and a minimal datastore tree required to retrieve attestation evidence about integrity measurements from a composite device with one or more roots of trust for reporting.  Complementary measurement logs are also provided by the YANG RPC originating from one or more roots of trust of measurement.  The module defined requires at least one TPM 1.2 or TPM 2.0 and corresponding Trusted Software Stack included in the device components of the composite device the YANG server is running on. </del> <ins> This document defines a YANG RPC and a minimal datastore required to retrieve attestation evidence about integrity measurements from a device following the operational context defined in I-D.ietf-rats- tpm-based-network-device-attest.  Complementary measurement logs are also provided by the YANG RPC originating from one or more roots of trust of measurement.  The module defined requires at least one TPM 1.2 or TPM 2.0 and corresponding Trusted Software Stack included in the device components of the composite device the YANG server is running on. </ins> 1. This document is based on the terminology defined in the I-D.ietf- <del> rats-architecture and uses the interaction model and information elements defined in the I-D.birkholz-rats-reference-interaction-model document.  The currently supported hardware security modules (HWM) - sometimes also referred to as an embedded secure element (eSE) - is the Trusted Platform Module (TPM) version 1.2 and 2.0 specified by the Trusted Computing Group (TCG).  One ore more TPMs embedded in the components of a composite device - sometimes also referred to as an aggregate device - are required in order to use the YANG module defined in this document.  A TPM is used as a root of trust for reporting (RTR) in order to retrieve attestation evidence from a composite device (quote primitive operation).  Additionally, it is used as a root of trust for storage (RTS) in order to retain shielded secrets and store system measurements using a folding hash function (extend primitive operation). </del> <ins> rats-architecture and uses the operational context defined in I- D.ietf-rats-tpm-based-network-device-attest as well as the interaction model and information elements defined in I-D.birkholz- rats-reference-interaction-model.  The currently supported hardware security modules (HWM) are the Trusted Platform Module (TPM) TPM1.2 and TPM2.0 specified by the Trusted Computing Group (TCG).  One ore more TPMs embedded in the components of a composite device - sometimes also referred to as an aggregate device - are required in order to use the YANG module defined in this document.  A TPM is used as a root of trust for reporting (RTR) in order to retrieve attestation evidence from a composite device (quote primitive operation).  Additionally, it is used as a root of trust for storage (RTS) in order to retain shielded secrets and store system measurements using a folding hash function (extend primitive operation). </ins> 1.1.


the method SHALL be "GET". <del> the request-target SHALL use absolute-form (see H1). </del> the request SHALL include a single Host header field containing the origin of the UDP proxy.


higher value.  By default, this value is Infinite.  The caller is also able to reset the value to Infinite at any point. <del> A ListenError occurs either when the Properties of the Preconnection cannot be fulfilled for listening, when the Local Endpoint (or Remote Endpoint, if specified) cannot be resolved, or when the application is prohibited from listening by policy. </del> <ins> A ListenError occurs either when the Properties and Security Parameters of the Preconnection cannot be fulfilled for listening or cannot be reconciled with the Local Endpoint (and/or Remote Endpoint, if specified), when the Local Endpoint (or Remote Endpoint, if specified) cannot be resolved, or when the application is prohibited from listening by policy. </ins> A Stopped Event occurs after the Listener has stopped listening.


For example, assuming the IV value is "6b26114b9cba2b63a9e8dd4f", the connection ID sequence number is "3", and the packet number is <del> "aead", the nonce will be set to "6b2611489cba2b63a9a873e2". </del> <ins> "aead", the nonce will be set to "6b2611489cba2b63a9e873e2". </ins> 6.3.2.


suites to the registry.  The "Value" and "Description" columns are taken from the table.  The "DTLS-OK" and "Recommended" columns are both marked as "Yes" for each new cipher suite.  [[This assumes I- <del> D.sandj-tls-iana-registry-updates has been applied.]] </del> <ins> D.ietf-tls-iana-registry-updates has been applied.]] </ins> TLS ContentType Registry: Future values are allocated via Standards Action RFC5226.


calculation of the counter signature can be computed.  Details on computing counter signatures are found in counter_signature. <del> This parameter provides the time the content was created.  For signatures and recipient structures, this would be the time that the signature or recipient key object was created.  For content structures, this would be the time that the content was created. The unsigned integer value is the number of seconds, excluding leap seconds; after midnight UTC, January 1, 1970. </del> <ins> This parameter provides the time the content cryptographic operation is performed.  For signatures and recipient structures, this would be the time that the signature or recipient key object was created.  For content structures, this would be the time that the content structure was created.  The unsigned integer value is the number of seconds, excluding leap seconds; after midnight UTC, January 1, 1970.  The field is primarily intended to be to be used for countersignatures, however it can additionally be used for replay detection as well. </ins> The CDDL fragment that represents the set of headers defined in this section is given below.  Each of the headers is tagged as optional


guarantee that applications do so.  The JSEP implementation MUST be prepared for the JS to pass in bogus data instead. <del> Conversely, the application programmer MUST recognize that the JS </del> <ins> Conversely, the application programmer needs to be aware that the JS </ins> does not have complete control of endpoint behavior.  One case that bears particular mention is that editing ICE candidates out of the SDP or suppressing trickled candidates does not have the expected


The header value is <del> The delta-seconds format is used because: </del> <ins> The delay-seconds format is used because: </ins> it does not rely on clock synchronization and is resilient to clock adjustment and clock skew between client and server (see <del> SEMANTICS Section 4.1.1.1); </del> <ins> Section 5.6.7 of SEMANTICS); </ins> it mitigates the risk related to thundering herd when too many clients are serviced with the same timestamp.


5.2. <del> This document defines a new TLS negotiated extension called "srtp_ekt_key_transport" and a new TLS content type called EKTMessage. Using the syntax described in DTLS RFC6347, the following structures are used: If a DTLS client includes srtp_ekt_key_transport in its ClientHello, then a DTLS server that supports this extensions will includes srtp_ekt_key_transport in its ServerHello message.  If a DTLS client includes srtp_ekt_key_transport in its ClientHello, but does not receive srtp_ekt_key_transport in the ServerHello, the DTLS client MUST NOT send DTLS EKTMessage messages.  Also, the srtp_ekt_key_transport in the ServerHello MUST select one and only one EKTCipherType from the list provided by the client in the srtp_ekt_key_transport in the ClientHello. When a DTLS client sends the srtp_ekt_key_transport in its ClientHello message, it MUST include the SupportedEKTCiphers as the extension_data for the extension, listing the EKTCipherTypes the client is willing to use in preference order, with the most preferred version first.  When the server responds in the srtp_ekt_key_transport in its ServerHello message, it MUST include a SupportedEKTCiphers list that selects a single EKTCipherType to use (selected from the list provided by the client) or it returns an empty list to indicate there is no matching EKTCipherType in the clients list that the server is also willing to use.  The value to be used in the EKTCipherType for future extensions that define new ciphers is the value from the "EKT Ciphers Type" IANA registry defined in iana-ciphers. The figure above defines the contents for a new TLS content type called EKTMessage which is registered in iana-tls-content.  The EKTMessage above is used as the opaque fragment in the TLSPlaintext structure defined in Section 6.2.1 of RFC5246 and the srtp_ekt_message as the content type.  The srtp_ekt_message content type is defined and registered in iana-tls-ext. When the Server wishes to provide a new EKT Key, it can send EKTMessage containing an EKTKey with the new key information.  The client MUST respond with an EKTMessage of type ekt_key_act, if the EKTKey was successfully processed and stored or respond with the the ekt_key_error EKTMessage otherwise. The diagram below shows a message flow of DTLS client and DTLS server using the DTLS-SRTP Key Transport extension. Note that when used in PERC I-D.ietf-perc-private-media-framework, the Server is actually split between the Media Distrbutor and Key Distributor.  The messages in the above figure that are "SRTP packets" will not got to the Key Distributor but the other packets will be relayed by the Media Distributor to the Key Distributor. </del> <ins> This document defines a new TLS negotiated extension and a new TLS handshake message type .  The extension negotiates the cipher to be used in encrypting and decrypting EKTCiphertext values, and the handshake message carries the corresponding key. The diagram below shows a message flow of DTLS 1.3 client and server using EKT configured using the DTLS extensions described in this section.  (The initial cookie exchange and other normal DTLS messages are omitted.) In the context of a multi-party SRTP session in which each endpoint performs a DTLS handshake as a client with a central DTLS server, the extensions defined in this session allow the DTLS server to set a common EKT key among all participants.  Each endpoint can then use EKT tags encrypted with that common key to inform other endpoint of the keys it is using to protect SRTP packet.  This avoids the need for many individual DTLS handshakes among the endpoints, at the cost of preventing endpoints from directly authenticating one another. 5.2.1. To indicate its support for EKT, a DTLS-SRTP client includes in its ClientHello an extension of type listing the EKT ciphers the client supports in preference order, with the most preferred version first.  If the server agrees to use EKT, then it includes a extension in its ServerHello containing a cipher selected from among those advertised by the client. The field of this extension contains an "EKTCipher" value, encoded using the syntax defined in RFC5246: 5.2.2. Once a client and server have concluded a handshake that negotiated an EKT cipher, the server MUST provide to the client a key to be used when encrypting and decrypting EKTCiphertext values.  EKT keys are sent in encrypted handshake records, using handshake type .  The body of the handshake message contains an structure: [[ NOTE: RFC Editor, please replace "TBD" above with the code point assigend by IANA ]] The contents of the fields in this message are as follows: If the server did not provide a extension in its ServerHello, then EKTKey messages MUST NOT be sent by either the client or the server. When an EKTKey is received and processed successfully, the recipient MUST respond with an Ack handshake message as described in Section 7 of I-D.ietf-tls-dtls13.  The EKTKey message and Ack must be retransmitted following the rules in Secton 4.2.4 of RFC6347. Note: To be clear, EKT can be used with versions of DTLS prior to 1.3.  The only difference is that in a pre-1.3 TLS stacks will not have built-in support for generating and processing Ack messages. If an EKTKey message is received that cannot be processed, then the recipient MUST respond with an appropriate DTLS alert. </ins> 5.3.


Distributor, this framework utilizes a DTLS-SRTP RFC5764 association between an endpoint and the Key Distributor.  To establish this association, an endpoint will send DTLS-SRTP messages to the Media <del> Distributor which will then forward them to the Media Distributor as </del> <ins> Distributor which will then forward them to the Key Distributor as </ins> defined in I-D.jones-perc-dtls-tunnel.  The Key Encryption Key (KEK) (i.e., EKT Key) is also conveyed by the Key Distributor over the DTLS association to endpoints via procedures defined in PERC EKT [I-


session configuration is known.  These "resources" can include things like extra ICE components, TURN candidates, or video decoders. Provisional answers, on the other hand, do no such deallocation; as a <del> result, multiple dissimilar provisional answers can be received and applied during call setup. </del> <ins> result, multiple dissimilar provisional answers, with their own codec choices, transport parameters, etc., can be received and applied during call setup.  Note that the final answer itself may be different than any received provisional answers. </ins> In RFC3264, the constraint at the signaling level is that only one offer can be outstanding for a given session, but at the media stack


Changes to this behavior are currently under discussion: see https://github.com/quicwg/base-drafts/issues/631. <del> 3.6. </del> <ins> 3.7. </ins> All QUIC packets carry packet numbers in cleartext, and while the protocol allows packet numbers to be skipped, skipping is not


authorities). Servers which are authenticating with a PSK MUST NOT send the <del> CertificateRequest message. </del> <ins> CertificateRequest message in the main handshake, though they MAY send it in post-handshake authentication (see post-handshake- authentication) provided that the client has sent the "post_handshake_auth" extension (see post_handshake_auth). </ins> 4.3.2.1.


8.1. <del> An Endpoint (name, sector) pair is unique within the et of endpoints </del> <ins> An Endpoint (name, sector) pair is unique within the set of endpoints </ins> registered by the RD.  An Endpoint MUST NOT be identified by its protocol, port or IP address as these may change over the lifetime of an Endpoint.


12.1. <del> Implementers need to pay close attention to the isolation and protection of the Attester and the factory processes for provisioning the Attestation key material.  If either of these are compromised, the remote attestation becomes worthless because the attacker can forge Evidence. </del> <ins> Implementers need to pay close attention to the protection of the Attester and the factory processes for provisioning the Attestation key material.  If either of these are compromised, the remote attestation becomes worthless because an attacker can forge Evidence or manipulate the Attesting Environment.  For example, a Target Environment should not be able to tamper with the Attesting Environment that measures it, by isolating the two environments from each other in some way. </ins> Remote attestation applies to use cases with a range of security requirements, so the protections discussed here range from low to


group.  Initialization keys are published for each client (ClientInitKey). <del> A secret that represent a member's contribution to the group </del> <ins> A secret that represents a member's contribution to the group </ins> secret (so called because the members' leaf keys are the leaves in the group's ratchet tree).


recommendation to use stronger language deprecating use of both SHA-1 and MD5.  The prior text did not explicitly include MD5 or SHA-1; and this text adds guidance to ensure that these algorithms have been <del> deprecated.. </del> <ins> deprecated. </ins> Section 4.3: