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


9. <del> Thanks to Mark Nottingham, Glenn Deen, Dave Oran, Aaron Falk, Kyle Rose, Leslie Daigle, Lucas Pardue, Matt Stock, Alexandre Gouaillard, and Mike English for their very helpful reviews and comments. </del> <ins> Thanks to Alexandre Gouaillard, Aaron Falk, Dave Oran, Glenn Deen, Kyle Rose, Leslie Daigle, Lucas Pardue, Mark Nottingham, Matt Stock, Mike English, Roni Even, and Will Law for very helpful suggestions, reviews and comments. (If we missed your name, please let us know!) </ins> 10.  References


errors.  The "instance" value MUST be the endpoint to which the request was targeted.  The problem document MUST also include a "taskid" member which contains the associated PPM task ID, encoded <del> with base64 RFC4648 (this value is always known, see task- configuration). </del> <ins> with base64 using the standard alphabet RFC4648 (this value is always known, see task-configuration). </ins> In the remainder of this document, we use the tokens in the table above to refer to error types, rather than the full URNs.  For


This protocol is extensible and allows for the addition of new cryptographic schemes that implement the VDAF interface specified in <del> I-D.draft-cfrg-patton-vdaf.  Candidates include: </del> <ins> VDAF.  Candidates include: </ins> "prio3", which allows for aggregate statistics such as sum, mean, histograms, etc.  This class of VDAFs is based on Prio CGB17 and


client ever sees the values for individual clients. In order to address this problem, the aggregators engage in a secure, <del> multi-party computation specified by the chosen VDAF I-D.draft-cfrg- patton-vdaf in order to prepare a report for aggregation.  At the beginning of this computation, each aggregator is in possession of an input share uploaded by the client.  At the end of the computation, each aggregator is in posession of either an "output share" that is ready to be aggregated or an indication that a valid output share could not be computed. </del> <ins> multi-party computation specified by the chosen VDAF VDAF in order to prepare a report for aggregation.  At the beginning of this computation, each aggregator is in possession of an input share uploaded by the client.  At the end of the computation, each aggregator is in posession of either an "output share" that is ready to be aggregated or an indication that a valid output share could not be computed. </ins> To facilitiate this computation, the input shares generated by the client include information used by the aggregators during aggregation


"vdaf_verify_param": The aggregator's VDAF verification parameter output by the setup algorithm computed jointly by the aggregators <del> before the start of the PPM protocol I-D.draft-cfrg-patton-vdaf). [OPEN ISSUE: This is yet to be specified.  See issue#161.] </del> <ins> before the start of the PPM protocol VDAF).  [OPEN ISSUE: This is yet to be specified.  See issue#161.] </ins> Finally, the collector is configured with the HPKE secret key corresponding to "collector_hpke_config".


The following terms are used: <del> This document uses the presentation language of RFC8446. </del> <ins> This document uses the presentation language of RFC8446 to define messages in the PPM protocol.  Encoding and decoding of these messages as byte strings also follows RFC8446. </ins> 2.


6. <del> Prio assumes a powerful adversary with the ability to compromise an unbounded number of clients.  In doing so, the adversary can provide malicious (yet truthful) inputs to the aggregation function.  Prio also assumes that all but one server operates honestly, where a dishonest server does not execute the protocol faithfully as specified.  The system also assumes that servers communicate over secure and mutually authenticated channels.  In practice, this can be done by TLS or some other form of application-layer authentication. In the presence of this adversary, Prio provides two important properties for computing an aggregation function F: Privacy.  The aggregators and collector learn only the output of F computed over all client inputs, and nothing else. Robustness.  As long as the aggregators execute the input- validation protocol correctly, a malicious client can skew the output of F only by reporting false (untruthful) input.  The output cannot be influenced in any other way. There are several additional constraints that a Prio deployment must satisfy in order to achieve these goals: Minimum batch size.  The aggregation batch size has an obvious impact on privacy.  (A batch size of one hides nothing of the input.) Aggregation function choice.  Some aggregation functions leak slightly more than the function output itself. [TODO: discuss these in more detail.] </del> <ins> PPM assumes an active attacker that controls the network and has the ability to statically corrupt any number of clients, aggregators, and collectors.  That is, the attacker can learn the secret state of any party prior to the start of its attack.  For example, it may coerce a client into providing malicious input shares for aggregation or coerce an aggregator into diverting from the protocol specified (e.g., by divulging its input shares to the attacker). In the presence of this adversary, PPM aims to achieve the following high-level secure aggregation goals: Privacy.  Clients trust that some aggregator is honest.  That is, as long as at least one aggregator executes the protocol faithfully, the parties learn nothing beyond the aggregate result (i.e., the output of the aggregation function computed over the honest measurements). Correctness.  The collector trusts that the aggregators execute the protocol correctly.  That is, as long as the aggregators execute the protocol faithfully, a malicious client can skew the aggregate result only by reporting a false (untruthful) measurement.  The result cannot be influenced in any other way. Currently, the specification does not achieve these goals.  In particular, there are several open issues that need to be addressed before these goals are met.  Details for each issue are below. When crafted maliciously, collect requests may leak more information about the measurements than the system intends.  For example, the spec currently allows sequences of collect requests to reveal an aggregate result for a batch smaller than the minimum batch size.  [OPEN ISSUE: See issue#195.  This also has implications for how we solve issue#183.] Even benign collect requests may leak information beyond what one might expect intuitively.  For example, the Poplar1 VDAF VDAF can be used to compute the set of heavy hitters among a set of arbitrary bit strings uploaded by clients.  This requires multiple evaluations of the VDAF, the results of which reveal information to the aggregators and collector beyond what follows from the heavy hitters themselves.  Note that this leakage can be mitigated using differential privacy.  [OPEN ISSUE: We have yet not specified how to add DP.] The core PPM spec does not defend against Sybil attacks.  In this type of attack, the adversary adds to a batch a number of reports that skew the aggregate result in its favor.  For example: The result may reveal additional information about the honest measurements, leading to a privacy violation; or the result may have some property that is desirable to the adversary ("stats poisoning").  The upload sub-protocol includes an extensions mechanism that can be used to prevent -- or at least mitigate -- these types of attacks.  See upload-extensions.  [OPEN ISSUE: No such extension has been implemented, so we're not yet sure if the current mechanism is sufficient.] Attacks may also come from the network.  Thus, it is required that the aggregators and collector communicate with one another over mutually authenticated and confidential channels.  The core PPM spec does not specify such a mechanism beyond requiring server authentication for HTTPS sessions.  Note that clients are not required to authenticate themselves.  [OPEN ISSUE: It might be better to be prescriptive about leader authentication in leader- helper channels and collector authenticaiton in collector-leader channels.  For the latter we have issue#155.] </ins> 6.1. <ins> [OPEN ISSUE: This subsection is a bit out-of-date.] </ins> In this section, we enumerate the actors participating in the Prio system and enumerate their assets (secrets that are either inherently valuable or which confer some capability that enables further attack


To generate the report, the client begins by sharding its measurement into a sequence of input shares as specified by the VDAF in use.  To <del> encrypt an input share, the client first generates an HPKE RFC9180 context for the aggregator by running </del> <ins> encrypt an input share, the client generates an HPKE RFC9180 ciphertext and encapsulated key for the aggregator by running </ins> <del> where "pk" is the aggregator's public key and "server_role" is the Role of the intended recipient ("0x02" for the leader and "0x03" for the helper).  In general, the info string for computing the HPKE context is suffixed by two bytes, the first of which identifies the role of the sender and the second of which identifies the role of the intended recipient. "enc" is the HPKE encapsulated key and "context" is the HPKE context used by the client for encryption.  The payload is encrypted as where "input_share" is the aggregator's input share and "nonce" and "extensions" are the corresponding fields of "Report".  Clients MUST NOT use the same "enc" for multiple reports. </del> <ins> where "pk" is the aggregator's public key; "server_role" is the Role of the intended recipient ("0x02" for the leader and "0x03" for the helper); "task_id", "nonce", and "extensions" are the corresponding fields of "Report"; and "input_share" is the aggregator's input share. </ins> The leader responds to well-formed requests to "[leader]/upload" with HTTP status code 200 OK and an empty body.  Malformed requests are


report share as invalid with the error "hpke-unknown-config-id". Otherwise, it decrypts the payload with the following procedure: <del> where "sk" is the HPKE secret key, "task_id" is the task ID, "nonce" and "extensions" are the nonce and extensions of the report share respectively, and "server_role" is 0x02 if the aggregator is the leader and 0x03 otherwise.  If decryption fails, the aggregator marks the report share as invalid with the error "hpke-decrypt-error". Otherwise, it outputs the resulting "input_share". </del> <ins> where "sk" is the HPKE secret key, and "server_role" is the role of the aggregator ("0x02" for the leader and "0x03" for the helper).  If decryption fails, the aggregator marks the report share as invalid with the error "hpke-decrypt-error".  Otherwise, it outputs the resulting "input_share". </ins> 4.3.1.4.


"AggregateShareReq" is done as follows: where "pk" is the HPKE public key encoded by the collector's HPKE <del> key, and server_role is is "0x02" for the leader and "0x03" for a helper. </del> <ins> key, "server_role" is "0x02" for the leader and "0x03" for a helper. </ins> The collector decrypts these aggregate shares using the opposite process.  Specifically, given an encrypted input share, denoted "enc_share", for a given batch interval, denoted "batch_interval", decryption works as follows: <del> where "sk" is the HPKE secret key, "task_id" is the task ID for a given collect request, and "server_role" is the role of the server that sent the aggregate share ("0x02" for the leader and "0x03" for the helper). </del> <ins> where "sk" is the HPKE secret key, "task_id" is the task ID for the collect request, and "server_role" is the role of the server that sent the aggregate share ("0x02" for the leader and "0x03" for the helper). </ins> 4.4.5.


"batch_interval" is the batch interval of the request. <ins> "agg_param", an aggregation parameter for the VDAF being executed. </ins> "report_count" is the number of reports included in the aggregation. "checksum" is the checksum computed over the set of client reports. <del> "job_id" is the ID of the aggregation job. </del> This request MUST be authenticated as described in https-sender-auth. To handle the leader's request, the helper first ensures that the request meets the requirements for batch parameters following the


where "[leader]" is the first entry in the task's aggregator endpoints.  The payload is structured as follows: <del> This message is called the Client's report.  It consists of a "header" and the encrypted input share of each of the Aggregators. The header consists of the task ID and report "metadata".  The metadata consists of the following fields: </del> <ins> This message is called the Client's report.  It consists of the report metaata, the "public share" output by the VDAF's input- distribution algorithm, and the encrypted input share of each of the Aggregators.  The header consists of the task ID and report "metadata".  The metadata consists of the following fields: </ins> A timestamp representing the time at which the report was generated.  Specifically, the "time" field is set to the number of


4.4.1.3. Each report share has a corresponding task ID, report metadata <del> (timestamp, nonce, and extensions), and encrypted input share.  Let "task_id", "metadata", and "encrypted_input_share" denote these values, respectively.  Given these values, an aggregator decrypts the input share as follows.  First, the aggregator looks up the HPKE config and corresponding secret key indicated by </del> <ins> (timestamp, nonce, and extensions), the public share sent to each Aggregator, and the recipient's encrypted input share.  Let "task_id", "metadata", "public_share", and "encrypted_input_share" denote these values, respectively.  Given these values, an aggregator decrypts the input share as follows.  First, the aggregator looks up the HPKE config and corresponding secret key indicated by </ins> "encrypted_input_share.config_id".  If not found, then it marks the report share as invalid with the error "hpke-unknown-config-id". Otherwise, it decrypts the payload with the following procedure:


"vdaf_verify_key" is the VDAF verification key shared by the aggregators; "agg_id" is the aggregator ID ("0x00" for the Leader and <del> "0x01" for the helper); and "agg_param" is the opaque aggregation parameter distributed to the aggregtors by the collector. </del> <ins> "0x01" for the helper); "agg_param" is the opaque aggregation parameter distributed to the aggregtors by the collector; "public_share" is the public share generated by the client and distributed to each aggregator; and "input_share" is the aggregator's input share. </ins> If either step fails, the aggregator marks the report as invalid with error "vdaf-prep-error".  Otherwise, the value "out" is interpreted


aggregate shares into an aggregate result using the VDAF's "agg_shares_to_result" algorithm.  In particular, let "agg_shares" denote the ordered sequence of aggregator shares, ordered by <del> aggregator index, and let "agg_param" be the opaque aggregation parameter.  The final aggregate result is computed as follows: </del> <ins> aggregator index, let "report_count" denote the report count sent by the Leader, and let "agg_param" be the opaque aggregation parameter. The final aggregate result is computed as follows: </ins> 4.5.4.


participating clients or permit some attacks on robustness.  This auxiliary information could be removed by having clients submit reports to an anonymizing proxy server which would then use Oblivious <del> HTTP I-D.thomson-http-oblivious to forward inputs to the DAP leader, without requiring any server participating in DAP to be aware of whatever client authentication or attestation scheme is in use. </del> <ins> HTTP I-D.draft-ietf-ohai-ohttp-07 to forward inputs to the DAP leader, without requiring any server participating in DAP to be aware of whatever client authentication or attestation scheme is in use. </ins> 7.4.


*Collect:* The collector makes one or more requests to the leader in order to obtain the final output of the protocol.  Before the output can be computed, the aggregators (i.e, the leader and <del> helpers) need to have verified and aggregated a sufficient number </del> <ins> helper) need to have verified and aggregated a sufficient number </ins> of inputs.  Depending on the PA protocol, it may be possible for the aggregators to do so immediately when reports are uploaded. (See prio.)  However, in general it is necessary for them to wait until (a) enough reports have been uploaded and (b) the collector has made a request.  (See hits.) <del> [TODO: Say that the protocol involves multiple helpers.  The downside of using secret sharing is that the protocol requires at least two servers to be online during the entire data aggregation process.  To ameliorate this problem, we run the protocol in parallel with multiple helpers.] </del> 3. This section specifies a protocol for executing generic PA tasks.


"task": The PA task. <del> "helper_urls": The helpers' endpoint URLs. </del> <ins> "helper_url": The helpers endpoint URL. </ins> "collector_config": The HPKE configuration of the collector (described in hpke-config).  [OPEN ISSUE: Maybe the collector's


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;


the key config specifies a KEM, KDF, or AEAD algorithm the client doesn't recognize. <del> If the set of supported helpers is empty, then the client aborts and alerts the leader with "no supported helpers".  Otherwise, for each supported helper the client issues a POST request to "[leader]/upload_finish" with a payload constructed as described below. </del> [OPEN ISSUE: Should the request URL encode the PA task?  This would be necessary if we make "upload_start" an idempotent GET per issue#48.]


that about a client?  I'm not sure, so I'd be inclined to remove this unless we have a concrete use case.] <del> The client begins by setting up an HPKE I-D.irtf-cfrg-hpke context for the helper by running </del> <ins> Next, the client issues a POST request to "[leader]/upload_finish". It begins by setting up an HPKE I-D.irtf-cfrg-hpke context for the helper by running </ins> where "pk" is the KEM public key encoded by "HpkeConfig.public_key". The outputs are the helper's encapsulated context "enc" and the


SetupBaseS() will be, as well as the aad for context.Seal().  The aad might be the entire "transcript" between the client and helper.] <del> [OPEN ISSUE: Is it safe to generate the proof once, then secret-share between each (leader, helper) pair?  Probably not in general, but maybe for Prio?] </del> [OPEN ISSUE: allow server to send joint randomness in UploadStartResp, and then enforce uniqueness via double-spend state or something else (see issue#48).]


We sometimes refer to this message as the _report_. The message contains the "task" fields of the previous request.  In addition, it includes the time (in seconds since the beginning of UNIX time) at <del> which the report was generated, the helper's HPKE config id, endpoint URL, and the helper and leader shares.  The helper share has the following structure: </del> <ins> which the report was generated, the helper's HPKE config id, and the helper and leader shares.  The helper share has the following structure: </ins> Field "enc" encodes the helper's encapsulated HPKE context.  The remainder of the structure contains the share itself, the structure


3.4.2.1. The process begins with a PACollectReq.  The leader collects a <del> sequence of reports that are all associated with the same PA task, helper URL, and helper HPKE config id.  Let "[helper]" denote "PACollectReq.helper_url".  The leader sends a POST request to "[helper]/aggregate" with the following message: </del> <ins> sequence of reports that are all associated with the same PA task. Let "[helper]" denote "PAParam.helper_url", where "PAParam" is the PA parameters structure associated "PAAggregateReq.task.id".  The leader sends a POST request to "[helper]/aggregate" with the following message: </ins> The structure contains the PA task, the helper's HPKE config id, an opaque _helper state_ string, and a sequence of _sub-requests_, each


The term "Remote Attestation" is a common expression and often associated or connoted with certain properties.  The term "Remote" in this context does not necessarily refer to a remote entity in the <del> scope of network topologies or the Internet.  It rather refers to a decoupled system or entities that exchange the payload of the </del> <ins> scope of network topologies or the Internet.  It rather refers to decoupled systems or entities that exchange the payload of the </ins> Conceptual Message type called Evidence I-D.ietf-rats-architecture. This conveyance can also be "Local", if the Verifier role is part of the same entity as the Attester role, e.g., separate system <del> components of the same Composite Device (a single RATS entity). Examples of these types of co-located environments include: a Trusted Execution Environment (TEE), Baseboard Management Controllers (BMCs), as well as other physical or logical protected/isolated/shielded Computing Environments (e.g. embedded Secure Elements (eSE) or Trusted Platform Modules (TPM)).  Readers of this document should be familiar with the concept of Layered Attestation as described in Section 4.3 Two Types of Environments of an Attester in I-D.ietf- rats-architecture and the definition of Attestation as described in I-D.ietf-rats-tpm-based-network-device-attest. </del> <ins> components of the same Composite Device (a single RATS entity).  Even if an entity takes on two or more different roles, the functions they provide typically reside in isolated environments that are components of the same entity.  Examples of such isolated environments include: a Trusted Execution Environment (TEE), Baseboard Management Controllers (BMCs), as well as other physical or logical protected/isolated/shielded Computing Environments (e.g. embedded Secure Elements (eSE) or Trusted Platform Modules (TPM)).  Readers of this document should be familiar with the concept of Layered Attestation as described in Section 4.3 Two Types of Environments of an Attester in I-D.ietf-rats-architecture and the definition of Attestation as described in I-D.ietf-rats-tpm-based-network-device- attest. </ins> 3.


_mandatory_ <del> Reference Claims are components of Reference Values as defined in I-D.ietf-rats-architecture.  [Editor's Note: Definition might become obsolete, if replaced by Reference Values.  Is there a difference between Claims and Values here?  Analogously, why is not named Reference Claims in the RATS arch?] Reference Claims are used to appraise the Claims received from an Attester.  For example, Reference Claims MAY be Reference </del> <ins> Reference Values as defined in I-D.ietf-rats-architecture.  This specific type of Claims is used to appraise Claims incorporated in Evidence.  For example, Reference Values MAY be Reference </ins> Integrity Measurements (RIM) or assertions that are implicitly trusted because they are signed by a trusted authority (see <del> Endorsements in I-D.ietf-rats-architecture).  Reference Claims </del> <ins> Endorsements in I-D.ietf-rats-architecture).  Reference Values </ins> typically represent (trusted) Claim sets about an Attester's intended platform operational state.


signature, the Attester Identity, and the Handle, and then appraises the Claims.  Appraisal procedures are application-specific and can be conducted via comparison of the Claims with corresponding Reference <del> Claims, such as Reference Integrity Measurements.  The final output </del> <ins> Values, such as Reference Integrity Measurements.  The final output </ins> of the Verifier are Attestation Results.  Attestation Results constitute new Claim Sets about the properties and characteristics of an Attester, which enables Relying Parties, for example, to assess an


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


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


The 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:


For the format defined here, suffix tags are always : They can be added or left out as desired by the generator of the <del> string in Internet Date/Time Format.  (An application might require the presence of specific suffix tags, though.) </del> <ins> string in Internet Extended Date/Time Format (IXDTF).  (An application might require the presence of specific suffix tags, though.) </ins> Without further indication, they are also <del> : Even if included in the Internet Date/Time Format string, the recipient is free to ignore the suffix tag.  Reasons might include that the recipient does not implement (or know about) the specific suffix key, or that it does recognize the key but cannot act on the value provided. </del> <ins> : Even if included in the IXDTF string, the recipient is free to ignore the suffix tag.  Reasons might include that the recipient does not implement (or know about) the specific suffix key, or that it does recognize the key but cannot act on the value provided. </ins> A suffix tag may also indicate that it is <del> : The recipient is advised that it MUST not act on the Internet Date/ Time Format string unless it can process the suffix tag as specified. A critical suffix tag is indicated by following its opening bracket with an exclamation mark (see "critical-flag" in abnf). </del> <ins> : The recipient is advised that it MUST not act on the Internet Extended Date/Time Format (IXDTF) string unless it can process the suffix tag as specified.  A critical suffix tag is indicated by following its opening bracket with an exclamation mark (see "critical-flag" in abnf). </ins> <del> Internet Date/Time Format strings such as: </del> <ins> IXDTF strings such as: </ins> are internally inconsistent, as Europe/Paris does not use a time zone offset of 0 (which is indicated in the "Z", an abbreviation for


However, all have an internal inconsistency or an unrecognized suffix key/ <del> value, so a recipient MUST treat the Internet Date/Time Format string as erroneous. </del> <ins> value, so a recipient MUST treat the IXDTF string as erroneous. </ins> Note that this does not mean that an application is disallowed to perform additional processing on elective suffix tags, e.g., asking


The following rules extend the ABNF syntax defined in RFC3339 in order to allow the inclusion of an optional suffix. <del> The extended date/time format is described by the rule "date-time- ext". </del> <ins> The Internet Extended Date/Time Format (IXDTF) is described by the rule "date-time-ext". </ins> "date-time" and "time-numoffset" are imported from RFC3339, "ALPHA" and "DIGIT" from RFC5234.


3.2. <del> Here are some examples of Internet extended date/time format. </del> <ins> Here are some examples of Internet Extended Date/Time Format (IXDTF). </ins> rfc3339-datetime represents 39 minutes and 57 seconds after the 16th hour of December 19th, 1996 with an offset of -08:00 from UTC.  Note


5.1. Configuration interfaces are used to configure the security protocols <del> before a handshake begins or the keys are negotiated. </del> <ins> before a handshake begins or keys are negotiated. </ins> Identities and Private Keys (IPK): The application can provide its identity, credentials (e.g., certificates), and private keys, or


Identity Validation (IV): During a handshake, the security protocol will conduct identity validation of the peer.  This can <del> call into the application to offload validation. </del> <ins> offload validation or occur transparently to the application. </ins> TLS


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


5.2. <del> Cryptographic algorithm negotiation: Transport security protocols should permit applications to configure supported or enabled cryptographic algorithms. </del> <ins> Cryptographic algorithm negotiation (AN): Transport security protocols should permit applications to configure supported or enabled cryptographic algorithms. </ins> Transport dependency: None. Application dependency: Application awareness of supported or desired algorithms. <del> Application authentication delegation: Some protocols may </del> <ins> Application authentication delegation (AD): Some protocols may </ins> completely defer endpoint authentication to applications, e.g., to reduce online protocol complexity.


Application dependency: Application opt-in and policy for endpoint authentication <del> Mutual authentication: Transport security protocols should allow each endpoint to authenticate the other if required by the </del> <ins> Mutual authentication (MA): Transport security protocols should allow each endpoint to authenticate the other if required by the </ins> application. Transport dependency: None.


Application dependency: Mutual authentication required for application support. <del> DoS mitigation: Transport security protocols may need to support volumetric DoS prevention via, e.g., cookies or initiator-side puzzles. </del> <ins> DoS mitigation (DM): Transport security protocols may need to support volumetric DoS prevention via, e.g., cookies or initiator- side puzzles. </ins> Transport dependency: None. Application dependency: None. <del> Connection mobility: Sessions should not be bound to a network connection (or 5-tuple).  This allows cryptographic key material and other state information to be reused in the event of a connection change.  Examples of this include a NAT rebinding that occurs without a client's knowledge. </del> <ins> Connection mobility (CM): Sessions should not be bound to a network connection (or 5-tuple).  This allows cryptographic key material and other state information to be reused in the event of a connection change.  Examples of this include a NAT rebinding that occurs without a client's knowledge. </ins> Transport dependency: Connections are unreliable or can change due to unpredictable network events, e.g., NAT re-bindings. Application dependency: None. <del> Source validation: Source validation must be provided to mitigate server-targeted DoS attacks.  This can be done with puzzles or cookies. </del> <ins> Source validation (SV): Source validation must be provided to mitigate server-targeted DoS attacks.  This can be done with puzzles or cookies. </ins> Transport dependency: Packets may arrive as datagrams instead of streams from unauthenticated sources. Application dependency: None. <del> Application-layer feature negotiation: The type of application using a transport security protocol often requires features configured at the connection establishment layer, e.g., ALPN RFC7301.  Moreover, application-layer features may often be used to offload the session to another server which can better handle the request.  (The TLS SNI is one example of such a feature.)  As such, transport security protocols should provide a generic mechanism to allow for such application-specific features and options to be configured or otherwise negotiated. </del> <ins> Application-layer feature negotiation (AFN): The type of application using a transport security protocol often requires features configured at the connection establishment layer, e.g., ALPN RFC7301.  Moreover, application-layer features may often be used to offload the session to another server which can better handle the request.  (The TLS SNI is one example of such a feature.)  As such, transport security protocols should provide a generic mechanism to allow for such application-specific features and options to be configured or otherwise negotiated. </ins> Transport dependency: None. Application dependency: Specification of application-layer features or functionality. <del> Configuration extensions: The protocol negotiation should be </del> <ins> Configuration extensions (CX): The protocol negotiation should be </ins> extensible with addition of new configuration options. Transport dependency: None.


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


4.2.2. <del> [[TODO]] </del> <ins> [[OPEN ISSUE: Limiting this to one value would potentially save some bytes here, at the cost of generality.]] </ins> 4.3.


7.2. <ins> ESNI requires encrypted DNS to be an effective privacy protection mechanism.  However, verifying the server's identity from the Certificate message, particularly when using the X509 CertificateType, may result in additional network traffic that may reveal the server identity.  Examples of this traffic may include requests for revocation information, such as OCSP or CRL traffic, or requests for repository information, such as authorityInformationAccess.  It may also include implementation- specific traffic for additional information sources as part of verification. Implementations SHOULD avoid leaking information that may identify the server.  Even when sent over an encrypted transport, such requests may result in indirect exposure of the server's identity, such as indicating a specific CA or service being used.  To mitigate this risk, servers SHOULD deliver such information in-band when possible, such as through the use of OCSP stapling, and clients SHOULD take steps to minimize or protect such requests during certificate validation. 7.3. </ins> I-D.ietf-tls-sni-encryption lists several requirements for SNI encryption.  In this section, we re-iterate these requirements and assess the ESNI design against them. <del> 7.2.1. </del> <ins> 7.3.1. </ins> Since the SNI encryption key is derived from a (EC)DH operation between the client's ephemeral and server's semi-static ESNI key, the


Hello, with a different ephemeral key share, as the terminating server will fail to decrypt and verify the ESNI value. <del> 7.2.2. </del> <ins> 7.3.2. </ins> This design depends upon DNS as a vehicle for semi-static public key distribution.  Server operators may partition their private keys


by sending different Resource Records containing ESNIRecord and ESNIKeys values with different keys using a short TTL. <del> 7.2.3. </del> <ins> 7.3.3. </ins> This design requires servers to decrypt ClientHello messages with ClientEncryptedSNI extensions carrying valid digests.  Thus, it is


server.  This attack is bound by the number of valid TCP connections an attacker can open. <del> 7.2.4. </del> <ins> 7.3.4. </ins> As more clients enable ESNI support, e.g., as normal part of Web browser functionality, with keys supplied by shared hosting


ESNI extensions (see grease-extensions), which helps ensure the ecosystem handles the values correctly. <del> 7.2.5. </del> <ins> 7.3.5. </ins> This design is not forward secret because the server's ESNI key is static.  However, the window of exposure is bound by the key lifetime.  It is RECOMMENDED that servers rotate keys frequently. <del> 7.2.6. </del> <ins> 7.3.6. </ins> This design permits servers operating in Split Mode to forward connections directly to backend origin servers, thereby avoiding unnecessary MiTM attacks. <del> 7.2.7. </del> <ins> 7.3.7. </ins> Assuming ESNI records retrieved from DNS are validated, e.g., via DNSSEC or fetched from a trusted Recursive Resolver, spoofing a


client validates the server certificate against the public name before retrying. <del> 7.2.8. </del> <ins> 7.3.8. </ins> This design has no impact on application layer protocol negotiation. It may affect connection routing, server certificate selection, and client certificate verification.  Thus, it is compatible with multiple protocols. <del> 7.3. </del> <ins> 7.4. </ins> Note that the backend server has no way of knowing what the SNI was, but that does not lead to additional privacy exposure because the


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


receipt of a second ClientHello message with a ClientECH value, servers set up their HPKE context and decrypt ClientECH as follows: <del> It is an error for the client to offer ECH before the HelloRetryRequest but not after.  Likewise, it is an error for the client to offer ECH after the HelloRetryRequest but not before.  If the client-facing server accepts ECH for the first ClientHello but not the second, or it accepts ECH for the second ClientHello but not the first, then the client MUST abort the handshake with an "illegal_parameter" alert. </del> <ins> If the client offered ECH in the first ClientHello, then it MUST offer ECH in the second.  Likewise, if the client did not offer ECH in the first ClientHello, then it MUST NOT not offer ECH in the second. </ins> [[OPEN ISSUE: Should we be using the PSK input or the info input?  On the one hand, the requirements on info seem weaker, but maybe


negotiating ECH, including servers which do not implement this specification. <ins> 7.1.1. It is an error for the client to offer ECH before the HelloRetryRequest but not after.  Likewise, it is an error for the client to offer ECH after the HelloRetryRequest but not before.  If either of these conditions occurs, then the client-facing server MUST abort the handshake with an "illegal_parameter" alert. </ins> 7.2. When the client-facing server accepts ECH, it forwards the


If the server sends an "encrypted_client_hello" extension, the client MUST check the extension syntactically and abort the connection with <del> a "decode_error" alert if it is invalid. </del> <ins> a "decode_error" alert if it is invalid.  It otherwise ignores the extension and MUST NOT use the retry keys. </ins> Offering a GREASE extension is not considered offering an encrypted ClientHello for purposes of requirements in client-behavior.  In


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


"encrypted_client_hello" extension and proceeds with the handshake as usual, per RFC8446, Section 4.1.2. <del> If it supports ECH but does not recognize the configuration specified by the client, then it ignores the extension and </del> <ins> If it supports ECH but cannot decrypt the extension, then it </ins> terminates the handshake using the ClientHelloOuter.  This is referred to as "ECH rejection".  When ECH is rejected, the server sends an acceptable ECH configuration in its EncryptedExtensions message. <del> If it supports ECH and recognizes the configuration, then it attempts to decrypt the ClientHelloInner.  It aborts the handshake if decryption fails; otherwise it forwards the ClientHelloInner to the backend, who terminates the connection.  This is referred to as "ECH acceptance". </del> <ins> If it supports ECH and decrypts the extension, it forwards the ClientHelloInner to the backend, who terminates the connection. This is referred to as "ECH acceptance". </ins> Upon receiving the server's response, the client determines whether or not ECH was accepted and proceeds with the handshake accordingly.


"ECHConfig.cipher_suites" list. The configuration identifier, equal to "Expand(Extract("", <del> config), "tls13 ech config id", Nh)", where "config" is the </del> <ins> config), "tls ech config id", Nh)", where "config" is the </ins> "ECHConfig" structure and "Extract", "Expand", and "Nh" are as specified by the cipher suite KDF.  (Passing the literal """" as the salt is interpreted by "Extract" as no salt being provided.)


Note that the HPKE functions Deserialize and SetupBaseS are those which match "ECHConfig.kem_id" and the AEAD/KDF used with "context" are those which match the client's chosen preference from <del> "ECHConfig.cipher_suites". </del> <ins> "ECHConfig.cipher_suites".  The "info" parameter to SetupBaseS is the concatenation of "tls ech", a zero byte, and the serialized ECHConfig. </ins> The value of the "encrypted_client_hello" extension in the ClientHelloOuter is a "ClientECH" with the following values:


"payload", as computed above. <ins> If optional configuration identifiers (see optional-configs)) are used, the "config_id" field MAY be empty or randomly generated. Unless specified by the application using (D)TLS or externally configured on both sides, implementations MUST compute the field as specified in encrypted-client-hello. </ins> 6.2. This section describes a deterministic padding mechanism based on the


of the first ClientHelloInner via the derived ech_hrr_key by modifying HPKE setup as follows: <del> Clients then encrypt the second ClientHelloInner using this new HPKE context.  In doing so, the encrypted value is also authenticated by ech_hrr_key.  The rationale for this is described in flow-hrr-hijack. </del> <ins> The "info" parameter to SetupPSKS is the concatenation of "tls ech", a zero byte, and the serialized ECHConfig.  Clients then encrypt the second ClientHelloInner using this new HPKE context.  In doing so, the encrypted value is also authenticated by ech_hrr_key.  The rationale for this is described in flow-hrr-hijack. </ins> Client-facing servers perform the corresponding process when decrypting second ClientHelloInner messages.  In particular, upon


servers set up their HPKE context and decrypt ClientECH as follows: ClientHelloOuterAAD is computed from the second ClientHelloOuter as <del> described in authenticating-outer. </del> <ins> described in authenticating-outer.  The "info" parameter to SetupPSKR is computed as above. </ins> If the client offered ECH in the first ClientHello, then it MUST offer ECH in the second.  Likewise, if the client did not offer ECH


extension will result in a new ClientHello to process, so even the client's TLS version preferences may have changed. <del> The ClientECH value is said to match a known ECHConfig if there exists an ECHConfig that can be used to successfully decrypt ClientECH.payload.  This matching procedure should be done using one of the following two checks: </del> <ins> First, the server collects a set of candidate ECHConfigs.  This set is determined by one of the two following methods: </ins> <del> Compare ClientECH.config_id against identifiers of known ECHConfig and choose the one that matches. </del> <ins> Compare ClientECH.config_id against identifiers of known ECHConfigs and select the one that matches, if any, as a candidate. </ins> <del> Use trial decryption of ClientECH.payload with known ECHConfig and choose the one that succeeds. </del> <ins> Collect all known ECHConfigs as candidates, with trial decryption below determining the final selection. </ins> Some uses of ECH, such as local discovery mode, may omit the ClientECH.config_id since it can be used as a tracking vector.  In <del> such cases, trial decryption should be used for matching ClientECH to known ECHConfig.  Unless specified by the application using (D)TLS or externally configured on both sides, implementations MUST use the first method. If the ClientECH value does not match any known ECHConfig structure, it MUST ignore the extension and proceed with the connection, with the following added behavior: It MUST include the "encrypted_client_hello" extension in its EncryptedExtensions with the "retry_configs" field set to one or more ECHConfig structures with up-to-date keys.  Servers MAY supply multiple ECHConfig values of different versions.  This allows a server to support multiple versions at once. If offered, the server MUST ignore the "pre_shared_key" extension in the ClientHello. Note that an unrecognized ClientECH.config_id value may be a GREASE ECH extension (see grease-extensions), so it is necessary for servers to proceed with the connection and rely on the client to abort if ECH was required.  In particular, the unrecognized value alone does not indicate a misconfigured ECH advertisement (misconfiguration). Instead, servers can measure occurrences of the "ech_required" alert to detect this case. </del> <ins> such cases, the second method should be used for matching ClientECH to known ECHConfig.  See optional-configs.  Unless specified by the application using (D)TLS or externally configured on both sides, implementations MUST use the first method. The server then iterates over all candidate ECHConfigs, attempting to decrypt the "encrypted_client_hello" extension: </ins> <del> Once a suitable ECHConfig is found, the server verifies that the ECHConfig supports the cipher suite indicated by ClientECH.cipher_suite and that the version of ECH indicated by the client matches the ECHConfig.version.  If not, then the server MUST abort with an "illegal_parameter" alert.  Otherwise, the server decrypts ClientECH.payload, using the private key skR corresponding to ECHConfig, as follows: </del> <ins> The server verifies that the ECHConfig supports the cipher suite indicated by the ClientECH.cipher_suite and that the version of ECH indicated by the client matches the ECHConfig.version.  If not, the server continues to the next candidate ECHConfig. Next, the server decrypts ClientECH.payload, using the private key skR corresponding to ECHConfig, as follows: </ins> ClientHelloOuterAAD is computed from ClientHelloOuter as described in <del> authenticating-outer.  If decryption fails, the server MUST abort the connection with a "decrypt_error" alert.  Otherwise, the server reconstructs ClientHelloInner from EncodedClientHelloInner, as described in encoding-inner. </del> <ins> authenticating-outer.  The "info" parameter to SetupBaseS is the concatenation "tls ech", a zero byte, and the serialized ECHConfig. If decryption fails, the server continues to the next candidate ECHConfig.  Otherwise, the server reconstructs ClientHelloInner from EncodedClientHelloInner, as described in encoding-inner.  It then stops consider candidate ECHConfigs. </ins> Upon determining the ClientHelloInner, the client-facing server then forwards the ClientHelloInner to the appropriate backend server,


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


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


The non-empty name of the client-facing server, i.e., the entity trusted to update the ECH configuration.  This is used to correct misconfigured clients, as described in handle-server-response. <ins> This value MUST NOT begin or end with an ASCII dot and MUST be parsable as a dot-separated sequence of LDH labels, as defined in RFC5890, Section 2.3.1.  Clients MUST ignore any "ECHConfig" structure whose "public_name" does not meet these criteria.  Note that these criteria are incomplete; they incidentally rule out textual representations of IPv6 addresses (see RFC3986, Section 3.2.2), but do not exclude IPv4 addresses in standard dotted-decimal or other non-standard notations such as octal and hexadecimal (see RFC3986, Section 7.4).  If "public_name" contains a literal IPv4 or IPv6 address, the client SHOULD ignore the "ECHConfig" to avoid sending a non-compliant "server_name" extension on the ClientHelloOuter (see RFC6066, Section 3). </ins> A list of extensions that the client must take into consideration when generating a ClientHello message.  These are described below


"psk_key_exchange_modes" from the ClientHelloInner into the ClientHelloOuter. <ins> When the client offers the "early_data" extension in ClientHelloInner, it MUST also include the "early_data" extension in ClientHelloOuter.  This allows servers that reject ECH and use ClientHelloOuter to safely ignore any early data sent by the client per RFC8446, Section 4.2.10. </ins> [[OPEN ISSUE: We currently require HRR-sensitive parameters to match in ClientHelloInner and ClientHelloOuter in order to simplify client- side logic in the event of HRR.  See https://github.com/tlswg/draft-


ClientHelloInner. The list of HPKE KDF and AEAD identifier pairs clients can use for <del> encrypting ClientHelloInner. </del> <ins> encrypting ClientHelloInner.  See real-ech for how clients choose from this list. </ins> The client-facing server advertises a sequence of ECH configurations to clients, serialized as follows.


Deprecating MD5 and SHA-1 signature hashes in TLS 1.2 <del> draft-ietf-tls-md5-sha1-deprecate-04 </del> <ins> draft-ietf-tls-md5-sha1-deprecate-05 </ins> Abstract <del> The MD5 and SHA-1 hashing algorithms are steadily weakening in strength and their deprecation process should begin for their use in TLS 1.2 digital signatures.  However, this document does not deprecate SHA-1 in HMAC for record protection.  This document updates RFC 5246 and RFC 7525. </del> <ins> The MD5 and SHA-1 hashing algorithms are increasingly vulnerable to attack and this document deprecates their use in TLS 1.2 digital signatures.  However, this document does not deprecate SHA-1 in HMAC for record protection.  This document updates RFC 5246 and RFC 7525. </ins> 1.


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:


recommended) as defined by RFC8447.  The following entries are to be updated: <del> Other entries of the resgistry remain the same. </del> <ins> Other entries of the registry remain the same. </ins> 9. Concerns with TLS 1.2 implementations falling back to SHA-1 is an <del> issue.  This draft updates the TLS 1.2 specification to deprecate </del> <ins> issue.  This document updates the TLS 1.2 specification to deprecate </ins> support for MD5 and SHA-1 for digital signatures.  However, this document does not deprecate SHA-1 in HMAC for record protection.


2. <del> Clients MUST NOT include MD5 and SHA-1 in the signature_algorithms extension.  If a client does not send a signature_algorithms extension, then the server MUST abort the handshake and send a handshake_failure alert, except when digital signatures are not used (for example, when using PSK ciphers). </del> <ins> Clients MUST include the signature_algorithms extension.  Clients MUST NOT include MD5 and SHA-1 in this extension. </ins> 3.


4. Servers MUST NOT include MD5 and SHA-1 in ServerKeyExchange messages. <del> If a client receives a MD5 or SHA-1 signature in a ServerKeyExchange message it MUST abort the connection with the illegal_parameter alert. </del> <ins> If no other signature algorithms are available (for example, if the client does not send a signature_algorithms extension), the server MUST abort the handshake with a handshake_failure alert or select a different cipher suite. </ins> 5.


6. <del> RFC5246, The Transport Layer Security (TLS) Protocol Version 1.2, suggests that implementations can assume support for MD5 and SHA-1 by their peer.  This update changes the suggestion to assume support for SHA-256 instead, due to MD5 and SHA-1 being deprecated. In Section 7.4.1.4.1: the text should be revised from: OLD: "Note: this is a change from TLS 1.1 where there are no explicit rules, but as a practical matter one can assume that the peer supports MD5 and SHA- 1." NEW: "Note: This is a change from TLS 1.1 where there are no explicit rules, but as a practical matter one can assume that the peer supports SHA-256." 7. </del> The document updates the "TLS SignatureScheme" registry to change the recommended status of SHA-1 based signature schemes to N (not recommended) as defined by RFC8447.  The following entries are to be


[RFC5246][RFC8447][RFC-to-be] <del> 8. </del> <ins> 7. </ins> Concerns with TLS 1.2 implementations falling back to SHA-1 is an issue.  This document updates the TLS 1.2 specification to deprecate support for MD5 and SHA-1 for digital signatures.  However, this document does not deprecate SHA-1 in HMAC for record protection. <del> 9. </del> <ins> 8. </ins> The authors would like to thank Hubert Kario for his help in writing the initial draft.  We are also grateful to Daniel Migault, Martin


The MD5 and SHA-1 hashing algorithms are steadily weakening in strength and their deprecation process should begin for their use in TLS 1.2 digital signatures.  However, this document does not <del> deprecate SHA-1 in HMAC for record protection. </del> <ins> deprecate SHA-1 in HMAC for record protection.  This document updates RFC 5246 and RFC 7525. </ins> 1. The usage of MD5 and SHA-1 for signature hashing in TLS 1.2 is specified in RFC5246.  MD5 and SHA-1 have been proven to be insecure, <del> subject to collision attacks.  RFC6151 details the security considerations, including collision attacks for MD5, published in 2011.  NIST formally deprecated use of SHA-1 in 2011 NISTSP800-131A-R2 and disallowed its use for digital signatures at the end of 2013, based on both the Wang, et. al, attack and the potential for brute-force attack.  In 2016, researchers from INRIA identified a new class of transcript collision attacks on TLS (and other protocols) that rely on efficient collision-finding algorithms on the underlying hash constructions Transcript-Collision.  Further, in 2017, researchers from Google and CWI Amsterdam SHA-1-Collision proved SHA-1 collision attacks were practical.  This document updates RFC5246 and RFC7525 in such a way that MD5 and SHA-1 MUST NOT be used for digital signatures.  However, this document does not deprecate SHA-1 in HMAC for record protection. </del> <ins> subject to collision attacks Wang.  In 2011, RFC6151 detailed the security considerations, including collision attacks for MD5.  NIST formally deprecated use of SHA-1 in 2011 NISTSP800-131A-R2 and disallowed its use for digital signatures at the end of 2013, based on both the Wang, et. al, attack and the potential for brute-force attack.  In 2016, researchers from INRIA identified a new class of transcript collision attacks on TLS (and other protocols) that rely on efficient collision-finding algorithms on the underlying hash constructions Transcript-Collision.  Further, in 2017, researchers from Google and CWI Amsterdam SHA-1-Collision proved SHA-1 collision attacks were practical.  This document updates RFC5246 and RFC7525 in such a way that MD5 and SHA-1 MUST NOT be used for digital signatures.  However, this document does not deprecate SHA-1 in HMAC for record protection. </ins> 1.1. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <del> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119. </del> <ins> "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </ins> 2.


their peer.  This update changes the suggestion to assume support for SHA-256 instead, due to MD5 and SHA-1 being deprecated. <ins> In Section 7.4.1.4.1: the text should be revised from: </ins> OLD: <del> In Section 7.4.1.4.1: the text should be revised from " Note: this is a change from TLS 1.1 where there are no explicit rules, but as a practical matter one can assume that the peer supports MD5 and SHA- 1." </del> <ins> "Note: this is a change from TLS 1.1 where there are no explicit rules, but as a practical matter one can assume that the peer supports MD5 and SHA- 1." </ins> NEW:


(TLS) and Datagram Transport Layer Security (DTLS) recommends use of SHA-256 as a minimum requirement.  This update moves the minimum recommendation to use stronger language deprecating use of both SHA-1 <del> and MD5.  The prior text did not explicitly include MD5 and this text adds it to ensure it is understood as having been deprecated. </del> <ins> 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 deprecated.. </ins> Section 4.3:


Servers SHOULD authenticate using certificates with at least a 2048-bit modulus for the public key. <del> In addition, the use of the SHA-256 hash algorithm is RECOMMENDED, SHA-1 or MD5 MUST NOT be used (see CAB-Baseline for more details). Clients MUST indicate to servers that they request SHA-256, by using the "Signature Algorithms" extension defined in TLS 1.2. </del> <ins> In addition, the use of the SHA-256 hash algorithm is RECOMMENDED; and SHA-1 or MD5 MUST NOT be used (see CAB-Baseline for more details).  Clients MUST indicate to servers that they request SHA- 256, by using the "Signature Algorithms" extension defined in TLS 1.2. </ins> 8.


will typically be the minimum of the server's self-imposed limit and TicketRequestContents.count. <del> Servers that support ticket requests MUST NOT echo "ticket_request" in the EncryptedExtensions message.  A client MUST abort the connection with an "illegal_parameter" alert if the "ticket_request" extension is present in the EncryptedExtensions message. </del> <ins> A server that supports ticket requests MAY echo the "ticket_request" extension in the EncryptedExtensions message.  If present, it contains a TicketRequestContents structure, where TicketRequestContents.count indicates the number of tickets the server expects to send to the client. Servers MUST NOT send the "ticket_request" extension in ServerHello or HelloRetryRequest messages.  A client MUST abort the connection with an "illegal_parameter" alert if the "ticket_request" extension is present in either of these messages. </ins> If a client receives a HelloRetryRequest, the presence (or absence) of the "ticket_request" extension MUST be maintained in the second


IANA is requested to Create an entry, ticket_request(TBD), in the existing registry for ExtensionType (defined in RFC8446), with "TLS <del> 1.3" column values being set to "CH", and "Recommended" column being set to "Yes". </del> <ins> 1.3" column values being set to "CH, EE", and "Recommended" column being set to "Yes". </ins> 5.


4.2. <del> WebTransport clients can initiate bidirectional streams by opening an HTTP/3 bidirectional stream and sending an HTTP/3 frame with type </del> <ins> WebTransport endpoints can initiate bidirectional streams by opening an HTTP/3 bidirectional stream and sending an HTTP/3 frame with type </ins> "WEBTRANSPORT_STREAM" (type=0x41).  The format of the frame SHALL be the frame type, followed by the session ID, encoded as a variable- length integer, followed by the user-specified stream data (fig-bidi- client).  The frame SHALL last until the end of the stream. <del> 4.3. </del> <ins> HTTP/3 does not by itself define any semantics for server-initiated bidirectional streams.  If WebTransport setting is negotiated by both endpoints, the syntax of the server-initiated bidirectional streams SHALL be the same as the syntax of client-initated bidirectional streams, that is, a sequence of HTTP/3 frames.  The only frame defined by this document for use within server-initiated bidirectional streams is WEBTRANSPORT_STREAM. </ins> <del> WebTransport servers can initiate bidirectional streams by opening a bidirectional stream within the HTTP/3 connection.  Note that since HTTP/3 does not define any semantics for server-initiated bidirectional streams, this document is a normative reference for the semantics of such streams for all HTTP/3 connections in which the SETTINGS_ENABLE_WEBTRANSPORT option is negotiated.  The format of those streams SHALL be the session ID, encoded as a variable-length integer, followed by the user-specified stream data (fig-bidi- server). </del> <ins> TODO: move the paragraph above into a separate draft; define what happens with already existing HTTP/3 frames on server-initiated bidirectional streams. </ins> <del> 4.4. </del> <ins> 4.3. </ins> Datagrams can be sent using the DATAGRAM frame as defined in QUIC- DATAGRAM and HTTP3-DATAGRAM.  For all HTTP/3 connections in which the


MTUs can vary.  TODO: Describe how the path MTU can be computed, specifically propagation across HTTP proxies. <del> 4.5. </del> <ins> 4.4. </ins> In WebTransport over HTTP/3, the client MAY send its SETTINGS frame, as well as multiple WebTransport CONNECT requests, WebTransport data


Coding is a reliability mechanism that is distinct and separated from the loss detection of congestion controls.  Using coding can be a useful way to better deal with tail losses or with networks with non- <del> congestion losses.  However, coding mechanisms could hide congestion signals to the server.  This memo proposes a discussion on how coding and congestion signals could interact and proposes best current practice. </del> <ins> congestion losses.  However, coding mechanisms should not hide congestion signals.  This memo offers a discussion of how coding and congestion control interact. </ins> 1.


it is not an IETF product and is not a standard. There are cases where deploying coding improves the quality of the <del> transmission.  As example, the server may hardly detect tail losses that impact may impact the application layer.  Another example may be the networks where non-congestion losses are persistent and prevent the server from exploiting the link capacity.  RFC5681 defines TCP as a loss-based congestion control and coding mechanisms can hide congestion signals to the server. </del> <ins> transmission.  As an example, the server may hardly detect tail losses that impact may impact the application layer [MICHAEL: I don't understand this.  Why would it not detect them?  And why is detecting them the problem?].  Another example are networks where non- congestion losses are persistent and prevent a sender from exploiting the link capacity.  RFC5681 defines TCP as a loss-based congestion control; because coding repairs such losses, blindly applying it may easily lead to an implementation that also hides a congestion signal to the sender.  It is important to ensure that such information hiding does not occur. </ins> Coding is a reliability mechanism that is distinct and separated from the loss detection of congestion controls.  This memo discusses


consider congestion control aspects when proposing coding solutions. The proposed recommendations apply for coding at the transport or <del> application layer and coding for tunnels is out-of-the scope of the </del> <ins> application layer.  Coding for tunnels is out of scope for the </ins> document. 2. fig:sep-channel presents the notations that will be used in this document and introduce the Congestion Control (CC) and Forward <del> Erasure Correction (FEC) channels.  Congestion Control channel carries data packets (from the server to the client) and a potential </del> <ins> Erasure Correction (FEC) channels.  The Congestion Control channel carries data packets (from a server to a client) and a potential </ins> information signaling the packets that have been received (from the <del> client to the server).  Forward Erasure Correction channel carries coded packets (from the server to the client) and a potiential information signaling the packets that have been repaired (from the client to the server).  It is worth pointing out that there are cases where these channels are not separated. </del> <ins> client to the server).  The Forward Erasure Correction channel carries coded packets (from the server to the client) and a potiential information signaling the packets that have been repaired (from the client to the server).  It is worth pointing out that there are cases where these channels are not separated. Inside a host, the CC and FEC entities can be regarded as conceptually separate: As this diagram shows, the inputs to FEC (data to work upon, and signaling from the receiver about losses and/or repaired blocks) are distinct from the inputs to CC.  The latter calculates a sending rate or window from network measurements, and it takes the data to send as input, sometimes along with application requirements such as upper/ lower rate bounds, periods of quiescence, or a priority. It is not clear that the ACK signals feeding into a congestion control algorithm are useful to FEC in their raw form, and vice versa - information about repaired blocks may be quite irrelevant to a CC algorithm.  However, there can be meaningful other interactions (indicated by the horizontal double arrow) between the two entities, usually as a result of their operation rather than by relaying their own raw inputs.  For example, the network measurements carried out by CC can yield a longer-term statistical measure such as a loss ratio which is useful input for a FEC coding scheme.  Similarly, unequal error protection using fountain codes can be used to assign different priorities to blocks of data, and these priorities can be honored by a CC mechanism. </ins> 3.


3.2. <del> The document focuses on end-to-end coding, i.e. in cases where coding is added at the server and client end points.  The discussions should </del> <ins> The document focuses on end-to-end coding, i.e. cases where coding is added at the server and client end points.  The discussions should </ins> then consider fairness with non-coding solutions. 4. <del> The solution can be described as follows: </del> <ins> The solution can be described as follows: [MICHAEL: So far, it hasn't been clear that we're going to describe a "solution".  A solution to which problem?  I thought we're only discussing how FEC and CC relate.] </ins> <del> The client MUST indicate to the server that one or multiple packets have been repaired using a coding scheme.  The "repaired packet" signal does not guarantee that the packet actually needed to be repaired, since it could have been delayed but not lost. </del> <ins> The client indicates to the server that one or multiple packets have been repaired using a coding scheme.  The "repaired packet" signal does not guarantee that the packet actually needed to be repaired, since it could have been delayed but not lost. </ins> <del> The server MUST be able to detect the "repaired packet" signal. </del> <ins> The server must be able to detect the "repaired packet" signal. </ins> The base solution does not describe how the congestion control reacts to such signal. The rationale behind this solution is the following: the server has more information on the congestion status and the application <del> characteristics.  Moreover, congestion control should not be splitted between multiple entities otherwise non-optimized decisions may be taken. </del> <ins> characteristics.  Moreover, congestion control should not be split between multiple entities, as otherwise non-optimized decisions may be taken. </ins> The proposed solution applies for coding in the transport and <del> application layers.  The proposed approach is inline with the one in </del> <ins> application layers.  The proposed approach is in-line with the one in </ins> I-D.swett-nwcrg-coding-for-quic.  The proposed solution does not <del> applies for the interaction between coding under the transport layer </del> <ins> apply for the interaction between coding under the transport layer </ins> (i.e. not end-to-end), such as coding for tunnels. 5.


In this solution, the coded packets are sent on top of what is allowed by a congestion window.  Examples of the solution could be <del> adding a given pourcentage of the congestion window as supplementary </del> <ins> adding a given percentage of the congestion window as supplementary </ins> packets or sending a given amount of coded packets at a given rate. The redundancy flow can be decorrelated from the congestion control <del> that manages source packets : a secondary congestion control can be </del> <ins> that manages source packets: a secondary congestion control can be </ins> introduced, such as in coupled congestion control for RTP media I- D.ietf-rmcat-coupled-cc.  An example would be to exploit a lower than best-effort congestion control RFC6297. <del> The advantage of such solution is that coding would help in challenges cases where transmission losses are persistent. </del> <ins> The advantage of such a solution is that coding would help in challenging cases where transmission losses are persistent. </ins> <del> The drawback of such solution is that it may result in coding </del> <ins> The drawback of such a solution is that it may result in coding </ins> solutions being unfair towards non-coding solutions.  This solutions may result in adding congestion in congested networks.


or preferably send coded packets instead of the following packets in the send buffer. <del> The advantage of this solution is that it does not contribute in adding more congestion than the congestion window allows.  Indeed, all traffic (source and redundancy) is controlled by one congestion control only and TCP metrics for fairness can be indifferently applied in this case. </del> <ins> The advantage of this solution is that it does not add more traffic than the congestion window allows.  Indeed, all traffic (source and redundancy) is controlled by one congestion control only and TCP metrics for fairness can be indifferently applied in this case. </ins> The main drawback is the decrease of goodput if coded packets are sent but are not used at the client side. 6. <del> Delay-based congestion controls ignore packets that have been repaired with coding.  There is no need to define best current </del> <ins> [MICHAEL: I would remove this section entirely: it only adds to confusion.  If the inputs are seen as distinct, and we say that the raw inputs shouldn't be shared, then why would one even think about what delay-based CC does with this input?  It's just not the right input.]  Delay-based congestion controls ignore packets that have been repaired with coding.  There is no need to define best current </ins> pratices in this case.  However, more discussions are required for congestion controls that use loss as congestion signals (potentially among other congestion detection mechanism). 6.1. <del> In this solution, the server reacts to repaired packet signals as to congestion-implied packet losses.  That being said, this does not necessarily means that the packets have actually been lost.  The server may have other means to identify that the packet was just out- of-ordered and ignore the repaired packet signals. </del> <ins> [MICHAEL: As above, lets remove all of this please.  This text gets in the way of a clean separation.]  In this solution, the server reacts to repaired packet signals as to congestion-implied packet losses.  That being said, this does not necessarily mean that the packets have actually been lost.  The server may have other means to identify that the packet was just out-of-order and ignore the repaired packet signals. </ins> The advantages of the solution are (1) that coding mechanisms do not hide congestion signals, such as packets voluntary dropped by a AQM <del> RFC7567 and (2) packets may be repaired faster than with traditionnal retransmission mechanisms. </del> <ins> RFC7567 and (2) packets may be repaired faster than with a traditional retransmission mechanisms. </ins> The drawback of this solution is that, if there is a high non- congestion loss rate, the congestion control throughput may decrease


6.2. <del> In this solution, the server does not reduce the congestion window with the same amount when the "repaired packet" signal is received, i.e. when a packet has been lost but repaired.  Example of this solution could be based on RFC8511 or considering that recovering an isolated packet is not an actual sign of congestion. </del> <ins> [MICHAEL: this is even just a terrible idea.  There's no good rationale to back off less when a packet is repaired.]  In this solution, the server does not reduce the congestion window with the same amount when the "repaired packet" signal is received, i.e. when a packet has been lost but repaired.  Example of this solution could be based on RFC8511 or considering that recovering an isolated packet is not an actual sign of congestion. </ins> The advantage of the solution is that in cases where there is no actual congestion, coding could help in improving the transmission


6.3. <del> This is the case for delay-based congestion controls.  The interaction between delay-based congestion controls and the delay induced by a coding mechanisms is an open research activity.  That being said, a potential approach would be that loss-based congestion control ignores the "repaired packet" signal. </del> <ins> [MICHAEL: as above, also here, the signals are discussed as going into both blocks, leading to a strange unification of things that shouldn't be together.  Let's remove this.  Also, the idea of ignoring packet loss for CC is appalling anyway.]  This is the case for delay-based congestion controls.  The interaction between delay- based congestion controls and the delay induced by a coding mechanisms is an open research activity.  That being said, a potential approach would be that loss-based congestion control ignores the "repaired packet" signal. </ins> The advantage of this solution is that coding would provided substantial benefits in cases where there are transmission losses.


7. <del> This section provides a summary on the content in previous sections. The fig:summary sums up some recommendations.  It is worth pointing out that the "coding without congestion" considers that coded packets are sent along with original data packets, in opposition with the solution where coded packets are transmitted only when there is no more original packets to transmit.  Moreover, the values indicated in this Figure consider a channel that does not exhibit a high loss pattern. </del> <ins> [MICHAEL: I'm sorry to say that I find this table to be in the same style, of wrongly mixing things together, and would like to see it removed altogether.]  This section provides a summary on the content in previous sections.  The fig:summary sums up some recommendations. It is worth pointing out that the "coding without congestion" considers that coded packets are sent along with original data packets, in opposition with the solution where coded packets are transmitted only when there is no more original packets to transmit. Moreover, the values indicated in this Figure consider a channel that does not exhibit a high loss pattern. </ins> 8.


5.4. <del> frames implicitly create a stream and carry stream data.  The Type field in the frame takes the form 0b00001XXX (or the set of values from 0x08 to 0x0f) to maximize compatibility with QUIC.  However, unlike QUIC, there are only one bit used to determine the fields that are present in the frame: The FIN bit (0x01) indicates that the frame marks the end of the stream.  The final size of the stream is the sum of the length, in bytes, of all data previously sent on this stream and the length of this frame without the length of the Stream ID. </del> <ins> frames implicitly create a stream and carry stream data. The Type field in the frame is either 0x0a or 0x0b.  This uses the same frame types as a QUIC STREAM frame with the OFF bit clear and the LEN bit set.  The FIN bit (0x01) in the frame type indicates that the frame marks the end of the stream in one direction.  Stream data consists of any number of 0x0a frames followed by a terminal 0x0b frame. frames contain the following fields: The stream ID for the stream. Zero or more bytes of data for the stream.  Empty frames MUST NOT be used unless they open or close a stream; an endpoint MAY treat an empty frame that neither starts nor ends a stream as a session error. </ins> 5.5.


ClientHello, MUST contain the ConnectionId structure.  This structure contains the CID value the client wishes the server to use when sending messages to the client.  A zero-length CID value indicates <del> that the client is prepared to send with a CID but does not wish the </del> <ins> that the client is prepared to send using a CID but does not wish the </ins> server to use one when sending. A server willing to use CIDs will respond with a "connection_id" extension in the ServerHello, containing the CID it wishes the client to use when sending messages towards it.  A zero-length value <del> indicates that the server will send with the client's CID but does not wish the client to include a CID. </del> <ins> indicates that the server will send using the client's CID but does not wish the client to include a CID when sending. </ins> Because each party sends the value in the "connection_id" extension it wants to receive as a CID in encrypted records, it is possible for


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.


publication, the early allocation will be deprecated in favor of this assignment. <ins> A new column "DTLS-Only" is added to the registry.  The valid entries are "Y" if the extension is only applicable to DTLS, "N" otherwise. All the pre-existing entries are given the value "N". </ins> Note: The value "N" in the Recommended column is set because this extension is intended only for specific use cases.  This document describes the behavior of this extension for DTLS 1.2 only; it is not


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


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


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


active path, implementations SHOULD use T = 3xRTT. If an implementation has no way to obtain information regarding the <del> RTT of the active path, a value of 1s SHOULD be used. </del> <ins> RTT of the active path, T SHOULD be set to 1s. </ins> Profiles for specific deployment environments - for example, constrained networks I-D.ietf-uta-tls13-iot-profile - MAY specify a


Handshake messages are potentially larger than any given datagram, thus creating the problem of IP fragmentation. <del> Datagram transport protocols, like UDP, are more vulnerable to denial of service attacks and require a return-routability check with the help of cookies to be integrated into the handshake.  A detailed discussion of countermeasures can be found in dos. </del> <ins> Datagram transport protocols, like UDP, are susceptible to abusive behavior effecting denial of service attacks against nonparticipants, and require a return-routability check with the help of cookies to be integrated into the handshake.  A detailed discussion of countermeasures can be found in dos. </ins> 3.1.


error.  Note that if DTLS is run over UDP, then any implementation which does this will be extremely susceptible to denial-of-service (DoS) attacks because UDP forgery is so easy.  Thus, this practice is <del> NOT RECOMMENDED for such transports. </del> <ins> NOT RECOMMENDED for such transports, both to increase the reliability of DTLS service and to avoid the risk of spoofing attacks sending traffic to unrelated third parties. </ins> If DTLS is being carried over a transport that is resistant to forgery (e.g., SCTP with SCTP-AUTH), then it is safer to send alerts


datagram.  Omitting the length field MUST only be used for the last record in a datagram. <del> Implementations which send multiple records in the same datagram SHOULD omit the connection id from all but the first record; receiving implementations MUST assume that any subsequent records without connection IDs belong to the same association.  Sending implementations MUST NOT mix records from multiple DTLS associations in the same datagram.  If the second or later record has a connection ID which does not correspond to the same association used for previous records, the rest of the datagram MUST be discarded. </del> <ins> If a connection ID is negotiated, then it MUST be contained in all datagrams.  Sending implementations MUST NOT mix records from multiple DTLS associations in the same datagram.  If the second or later record has a connection ID which does not correspond to the same association used for previous records, the rest of the datagram MUST be discarded. </ins> When expanded, the epoch and sequence number can be combined into an unpacked RecordNumber structure, as shown below:


5.7.3. <ins> DTLS does not have any built-in congestion control or rate control; in general this is not an issue because messages tend to be small. However, in principle, some messages - especially Certificate - can be quite large.  If all the messages in a large flight are sent at once, this can result in network congestion.  A better strategy is to send out only part of the flight, sending more when messages are acknowledged.  DTLS offers a number of mechanisms for minimizing the size of the certificate message, including the cached information extension RFC7924 and certificate compression RFC8879. 5.7.4. </ins> DTLS 1.3 makes use of the following categories of post-handshake messages:


The basic design philosophy of DTLS is to construct "TLS over datagram transport".  Datagram transport does not require nor provide reliable or in-order delivery of data.  The DTLS protocol preserves <del> this property for application data.  Applications such as media </del> <ins> this property for application data.  Applications, such as media </ins> streaming, Internet telephony, and online gaming use datagram transport for communication due to the delay-sensitive nature of transported data.  The behavior of such applications is unchanged when the DTLS protocol is used to secure communication, since the DTLS protocol does not compensate for lost or reordered data traffic. <ins> Note that while low-latency streaming and gaming use DTLS to protect data (e.g. for protection of a WebRTC data channel), telephony utilizes DTLS for key establishment, and Secure Real-time Transport Protocol (SRTP) for protection of data RFC5763. </ins> TLS cannot be used directly in datagram environments for the following five reasons:


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


DTLS record MUST fit within a single datagram.  In order to avoid IP fragmentation, clients of the DTLS record layer SHOULD attempt to size records so that they fit within any PMTU estimates obtained from <del> the record layer. </del> <ins> the record layer.  For more information about PMTU issues see pmtu- issues. </ins> Multiple DTLS records MAY be placed in a single datagram.  Records are encoded consecutively.  The length field from DTLS records


probes the implementation to see how it responds to various types of error.  Note that if DTLS is run over UDP, then any implementation which does this will be extremely susceptible to denial-of-service <del> (DoS) attacks because UDP forgery is so easy.  Thus, this practice is NOT RECOMMENDED for such transports, both to increase the reliability of DTLS service and to avoid the risk of spoofing attacks sending traffic to unrelated third parties. </del> <ins> (DoS) attacks because UDP forgery is so easy.  Thus, the practice of generating fatal alerts is NOT RECOMMENDED for such transports, both to increase the reliability of DTLS service and to avoid the risk of spoofing attacks sending traffic to unrelated third parties. </ins> If DTLS is being carried over a transport that is resistant to forgery (e.g., SCTP with SCTP-AUTH), then it is safer to send alerts


5.8.2. <del> Though timer values are the choice of the implementation, mishandling of the timer can lead to serious congestion problems, for example if many instances of a DTLS time out early and retransmit too quickly on a congested link.  Implementations SHOULD use an initial timer value of 100 msec (the minimum defined in RFC 6298 RFC6298) and double the value at each retransmission, up to no less than 60 seconds (the RFC 6298 maximum).  Application specific profiles, such as those used for the Internet of Things environment, may recommend longer timer values.  Note that a 100 msec timer is recommended rather than the 3-second RFC 6298 default in order to improve latency for time- sensitive applications.  Because DTLS only uses retransmission for handshake and not dataflow, the effect on congestion should be minimal. </del> <ins> The configuration of timer settings varies with implementations and certain deployment environments require timer value adjustments. Mishandling of the timer can lead to serious congestion problems, for example if many instances of a DTLS time out early and retransmit too quickly on a congested link.  Implementations SHOULD use an initial timer value of 100 msec (the minimum defined in RFC 6298 RFC6298) and double the value at each retransmission, up to no less than 60 seconds (the RFC 6298 maximum).  Application specific profiles, such as those used for the Internet of Things environment, may recommend longer timer values.  Note that a 100 msec timer is recommended rather than the 3-second RFC 6298 default in order to improve latency for time-sensitive applications.  Because DTLS only uses retransmission for handshake and not dataflow, the effect on congestion should be minimal. </ins> Implementations SHOULD retain the current timer value until a message is transmitted and acknowledged without having to be retransmitted,


be quite large.  If all the messages in a large flight are sent at once, this can result in network congestion.  A better strategy is to send out only part of the flight, sending more when messages are <del> acknowledged.  DTLS offers a number of mechanisms for minimizing the size of the certificate message, including the cached information extension RFC7924 and certificate compression RFC8879. </del> <ins> acknowledged.  Several extensions have been standardized to reduce the size of the certificate message, for example the cached information extension RFC7924, certificate compression RFC8879 and RFC6066, which defines the "client_certificate_url" extension allowing DTLS clients to send a sequence of Uniform Resource Locators (URLs) instead of the client certificate. </ins> 5.8.4.


first.  Likewise, a server MAY send multiple CertificateRequest messages at once without having completed earlier client authentication requests before.  In contrast, implementations MUST <del> NOT have send KeyUpdate, NewConnectionId or RequestConnectionId </del> <ins> NOT have sent KeyUpdate, NewConnectionId or RequestConnectionId </ins> message if an earlier message of the same type has not yet been acknowledged.