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


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


MUST be in the same order.  The leader's endpoint MUST be the first in the list.  The order of the "encrypted_input_shares" in a "Report" (see uploading-reports) MUST be the same as the order in <del> which aggregators appear in this list. </del> <ins> which aggregators appear in this list.  Aggregators MAY use the same endpoint for multiple tasks. </ins> "max_batch_lifetime": The maximum number of times a batch of reports may be used in collect requests.


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


Initialize VDAF preparation and initial outputs as described in input-share-prep. <del> [[OPEN ISSUE: consider moving the helper nonce check into #early- </del> <ins> [[OPEN ISSUE: consider moving the helper nonce check into early- </ins> input-share-validation]] Once the helper has processed each valid report share in


The last input comprises the randomness consumed by the sharding algorithm.  The sharding randomness is a random byte string of length specified by the VDAF.  The Client MUST generate this using a <del> cryptographicallly secure random number generator. </del> <ins> cryptographically secure random number generator. </ins> The Client then wraps each input share in the following structure:


Each report share has a corresponding task ID, report metadata (report ID and, timestamp), the public share sent to each Aggregator, and the recipient's encrypted input share.  Let "task_id", <del> "metadata", "public_share", and "encrypted_input_share" denote these values, respectively.  Given these values, an aggregator decrypts the input share as follows.  First, it constructs an "InputShareAad" message from "task_id", "metadata", and "public_share".  Let this be denoted by "input_share_aad".  Then, the aggregator looks up the HPKE config and corresponding secret key indicated by "encrypted_input_share.config_id" and attempts decryption of the payload with the following procedure: </del> <ins> "report_metadata", "public_share", and "encrypted_input_share" denote these values, respectively.  Given these values, an aggregator decrypts the input share as follows.  First, it constructs an "InputShareAad" message from "task_id", "report_metadata", and "public_share".  Let this be denoted by "input_share_aad".  Then, the aggregator looks up the HPKE config and corresponding secret key indicated by "encrypted_input_share.config_id" and attempts decryption of the payload with the following procedure: </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).


Implementation note: The Leader considers a batch to be collected once it has completed a collection job for a <del> CollectReq message from the Collector; the Helper considers a batch to be collected once it has responded to an </del> <ins> CollectionReq message from the Collector; the Helper considers a batch to be collected once it has responded to an </ins> AggregateShareReq message from the Leader.  A batches is determined by query (query) conveyed in these messages. Queries must satisfy the criteria covered in batch-validation.


the hash values with a bitwise-XOR operation. Then, for each Aggregator endpoint "{aggregator}" in the parameters <del> associated with "CollectReq.task_id" (see collect-flow) except its </del> <ins> associated with "CollectionReq.task_id" (see collect-flow) except its </ins> own, the Leader sends a POST request to "{aggregator}/tasks/{task- id}/aggregate_shares" with the following message:


4.5.6. <del> Before an Aggregator responds to a CollectReq or AggregateShareReq, it must first check that the request does not violate the parameters associated with the DAP task.  It does so as described here. </del> <ins> Before an Aggregator responds to a CollectionReq or AggregateShareReq, it must first check that the request does not violate the parameters associated with the DAP task.  It does so as described here. </ins> First the Aggregator checks that the batch respects any "boundaries" determined by the query type.  These are described in the subsections


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


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


malformed requests are handled as described in pa-error-common- aborts.)  It first looks for the PA parameters "PAParam" for which "PAAggregateReq.task_id" is equal to the task id derived from <del> "PAParam".  Next, it looks up the HPKE config and corresponding secret key associated with "PAAggregateReq.helper_hpke_config_id". If not found, then it aborts and alerts the leader with "unrecognized key config".  [NOTE: In this situation, the leader has no choice but to abort.  This falls into the class of error scenarios that are addressable by running with multiple helpers.] [TODO: Don't require all sub-requests to pertain to the same HPKE config.] </del> <ins> "PAParam". </ins> The response consists of the helper's updated state and a sequence of _sub-responses_, where the i-th sub-response corresponds to the sub-


to the PA protocol: The helper handles each sub-request "PAAggregateSubReq" as follows. <del> It first checks that checks that "PAAggregateSubReq.proto == PAParam.proto".  If not, it aborts and alerts the leader with "incorrect protocol for sub-request".  Otherwise, it computes the HPKE context as where "sk" is its HPKE key and computes the body of the "PAAggregateSubResp".  It then updates its state according to the PA protocol.  After processing all of the sub-requests, the helper encrypts its updated state and constructs its response to the aggregate request. </del> <ins> It first looks up the HPKE config and corresponding secret key associated with "helper_share.config_id".  If not found, then the sub-response consists of an "unrecognized config" alert.  [TODO: We'll want to be more precise about what this means.  See issue#57.] Next, it attempts to decrypt the payload with the following procedure: where "sk" is the HPKE secret key.  If decryption fails, then the sub-response consists of a "decryption error" alert.  [See issue#57.] Otherwise, the helper handles the request for its plaintext input share "input_share" and updates its state as specified by the PA protocol. After processing all of the sub-requests, the helper encrypts its updated state and constructs its response to the aggregate request. </ins> 3.4.2.1.1.


structure, which specify the protocol used to verify and aggregate the clients' measurements: <ins> "nonce": A unique sequence of bytes used to ensure that two otherwise identical "PDAParam" instances will have distinct "PDATaskID"s.  It is RECOMMENDED that this be set to a random 16-byte string derived from a cryptographically secure pseurandom number generator. </ins> "leader_url": The leader's endpoint URL. "helper_url": The helper's endpoint URL.


"proto": The PDA protocol, e.g., Prio or Hits.  The rest of the structure contains the protocol specific parameters. <del> Each task has a unique _task id_ derived from the PDA parameters: </del> <ins> Each task has a unique _task ID_ derived from the PDA parameters: The task ID of a "PDAParam" `is derived using the following procedure: </ins> <del> The task id is derived using the following procedure.  [TODO: Specify derivation of the task ID.] </del> <ins> Where "SHA-256" is as specified in FIPS180-4. </ins> 3.1.2.


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


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


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


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


without accompanying evidence about its validity - used as proof of identity. <del> The Attester is issued with a credential by the Endorser that is randomised and then used to anonymously confirm the validity of their evidence.  The evidence is verified using the Endorser's public key. </del> _mandatory_ A statement representing an identifier list that MUST be


Claims are assertions that represent characteristics of an Attester's Target Environment. <del> Claims are part Conceptual Message and are, for example, used to appraise the integrity of Attesters via a Verifiers.  The other </del> <ins> Claims are part of a Conceptual Message and are, for example, used to appraise the integrity of Attesters via Verifiers.  The other </ins> information elements in this section can be expressed as Claims in any type of Conceptional Messages. <ins> _optional_ Event Logs accompany Claims by providing event trails of security- critical events in a system.  The primary purpose of Event Logs is to support Claim reproducibility by providing information on how Claims originated. </ins> _mandatory_ Reference Values as defined in I-D.ietf-rats-architecture.  This


_mandatory_ <ins> Collected Claims represent a (sub-)set of Claims created by an Attester. Collected Claims are gathered based on the Claims selected in the Claim Selection.  If a Verifier does not provide a Claim Selection, then all available Claims on the Attester are part of the Collected Claims. _mandatory_ </ins> A set of Claims that consists of a list of Authentication Secret IDs that each identifies an Authentication Secret in a single Attesting Environment, the Attester Identity, Claims, and a


The Attester boots up and thereby produces claims about its boot state and its operational state.  Event Logs accompany the produced <del> claims by providing an event trail of security-critical events of a </del> <ins> claims by providing an event trail of security-critical events in a </ins> system.  Claims are produced by all attesting Environments of an Attester system.


interaction models in general, the following set of prerequisites MUST be in place to support the implementation of interaction models: <del> A statement about a distinguishable Attester made by an Endorser without accompanying evidence about its validity, used as proof of identity. </del> <ins> An Authentication Secret MUST be available exclusively to an Attesting Environment of an Attester. The Attester MUST protect Claims with that Authentication Secret, thereby proving the authenticity of the Claims included in Evidence.  The Authentication Secret MUST be established before RATS can take place. A statement about a distinguishable Attester made by an Endorser. </ins> The provenance of Evidence with respect to a distinguishable Attesting Environment MUST be correct and unambiguous. <del> An Attester Identity MAY be a unique identity, MAY be included in a zero-knowledge proof (ZKP), MAY be part of a group signature, or it MAY be a randomized DAA credential DAA. </del> <ins> An Attester Identity MAY be an Authentication Secret which is available exclusively to one of the Attesting Environments of an Attester.  It MAY be a unique identity, MAY be included in a zero- knowledge proof (ZKP), MAY be part of a group signature, or it MAY be a randomized DAA credential DAA. </ins> Attestation Evidence MUST be authentic. In order to provide proofs of authenticity, Attestation Evidence SHOULD be cryptographically associated with an identity document <del> (e.g. an PKIX certificate or trusted key material, or a randomized DAA credential DAA), or SHOULD include a correct and unambiguous and stable reference to an accessible identity document. An Authentication Secret MUST be available exclusively to an Attester's Attesting Environment. The Attester MUST protect Claims with that Authentication Secret, thereby proving the authenticity of the Claims included in Evidence.  The Authentication Secret MUST be established before RATS can take place. </del> <ins> (e.g., a PKIX certificate or trusted key material, or a randomized DAA credential DAA), or SHOULD include a correct, unambiguous and stable reference to an accessible identity document. </ins> Evidence MUST include an indicator about its freshness that can be understood by a Verifier.  Analogously, interaction models MUST


_mandatory_ <del> A statement about a distinguishable Attester made by an Endorser without accompanying evidence about its validity - used as proof of identity. _mandatory_ </del> A statement representing an identifier list that MUST be associated with corresponding Authentication Secrets used to protect Claims included in Evidence.


Evidence as well as all accompanying Event Logs back to the Verifier. While it is crucial that Claims, the Handle, and the Attester <del> Identity information MUST be cryptographically bound to the signature of Evidence, they MAY be presented obfuscated, encrypted, or cryptographically blinded.  For further reference see section security-and-privacy-considerations. </del> <ins> Identity information (i.e., the Authentication Secret) MUST be cryptographically bound to the signature of Evidence, they MAY be presented obfuscated, encrypted, or cryptographically blinded.  For further reference see section security-and-privacy-considerations. </ins> <del> As soon as the Verifier receives the signed Evidence and Event Logs, it appraises the Evidence.  For this purpose, it validates the </del> <ins> As soon as the Verifier receives the Evidence and the Event Logs, it appraises the Evidence.  For this purpose, it validates the </ins> 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


stored or transported, as compared to the less efficient text-based form of the original vocabulary. <ins> Through use of CDDL-based integer labels, CoSWID allows for future expansion in subsequent revisions of this specification and through extensions (see model-extension).  New constructs can be associated with a new integer index.  A deprecated construct can be replaced by a new construct with a new integer index.  An implementation can use these integer indexes to identify the construct to parse.  The CoSWID Items registry, defined in iana-coswid-items, is used to ensure that new constructs are assigned a unique index value on a first-come, first-served basis.  This approach avoids the need to have an explicit CoSWID version. </ins> The root of the CDDL specification provided by this document is the rule "coswid" (as defined in tagged):


integrity measurements for files.  The ISO-19770-2:2015 XML schema uses XML DSIG to support cryptographic signatures. <del> Signing CoSWID tags follows the procedues defined in CBOR Object Signing and Encryption RFC8152.  A CoSWID tg MUST be wrapped in a </del> <ins> Signing CoSWID tags follows the procedures defined in CBOR Object Signing and Encryption RFC8152.  A CoSWID tag MUST be wrapped in a </ins> COSE Single Signer Data Object (COSE_Sign1) that contains a single signature and MUST be signed by the tag creator.  The following CDDL specification defines a restrictive subset of COSE header parameters


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


A tag is considered "authoritative" if the CoSWID tag was created by the software provider.  An authoritative CoSWID tag contains <del> information about a software component provided by the maintainer of </del> <ins> information about a software component provided by the supplier of </ins> the software component, who is expected to be an expert in their own <del> software.  Thus, authoritative CoSWID tags can be trusted to represent authoritative information about the software component. </del> <ins> software.  Thus, authoritative CoSWID tags can represent authoritative information about the software component.  The degree to which this information can be trusted depends on the tag's chain of custody and the ability to verify a signature provided by the supplier if present in the CoSWID tag.  The provisioning and validation of CoSWID tags are handled by local policy and is outside the scope of this document. </ins> A signed CoSWID tag (see coswid-cose) whose signature has been validated can be relied upon to be unchanged since it was signed.  By <del> contrast, the data contained in unsigned tags cannot be trusted to be unmodified. When an authoritative tag is signed, the software provider can be authenticated as the originator of the signature.  A trustworthy association between the signature and the originator of the signature can be established via trust anchors.  A certification path between a trust anchor and a certificate including a pub-key enabling the validation of a tag signature can realize the assessment of trustworthiness of an authoritative tag.  Having a signed authoritative CoSWID tag can be useful when the information in the tag needs to be trusted, such as when the tag is being used to convey reference integrity measurements for software components. </del> <ins> contrast, the data contained in unsigned tags can be altered by any user or process with write-access to the tag.  To support signature validation, there is the need associate the right key with the software provider or party originating the signature.  This operation is application specific and needs to be addressed by the application or a user of the application; a specific approach for which is out- of-scope for this document. When an authoritative tag is signed, the originator of the signature can be verified.  A trustworthy association between the signature and the originator of the signature can be established via trust anchors. A certification path between a trust anchor and a certificate including a public key enabling the validation of a tag signature can realize the assessment of trustworthiness of an authoritative tag. Verifying that the software provider is the signer is a different matter.  This requires an association between the signature and the tag's entity item associated corresponding to the software provider. No mechanism is defined in this draft to make this association; therefore, this association will need to be handled by local policy. </ins> CoSWID tags are intended to contain public information about software components and, as such, the contents of a CoSWID tag does not need


do this, CoSWID tags can be created by any party and the CoSWID tags collected from an endpoint could contain a mixture of vendor and non- vendor created tags.  For this reason, a CoSWID tag might contain <del> potentially malicious content.  Input sanitization and loop detection are two ways that implementations can address this concern. </del> <ins> potentially malicious content.  Input sanitization, loop detection, and signature verification are ways that implementations can address this concern. </ins> 10.


Aligned excerpt examples in I-D text with full CDDL <del> Fixed titels where title was referring to group instead of map </del> <ins> Fixed titles where title was referring to group instead of map </ins> <del> Added missig date in SEMVER </del> <ins> Added missing date in SEMVER </ins> Fixed root cardinality for file and directory, etc.


This interaction is often limited to signaling between the record layer and the handshake layer. <del> ESP </del> <ins> IPsec </ins> Mobility Events (ME): The record protocol can be signaled that it is being migrated to another transport or interface due to


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


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


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. </ins> Configuration extensions: The protocol negotiation should be extensible with addition of new configuration options. <ins> Transport dependency: None. Application dependency: Specification of application-specific extensions. </ins> Session caching and management: Sessions should be cacheable to enable reuse and amortize the cost of performing session establishment handshakes. <del> 4.2.2. </del> <ins> Transport dependency: None. </ins> <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> Application dependency: None. </ins> 5. This section describes the interface surface exposed by the security <del> protocols described above, with each interface.  Note that not all protocols support each interface. </del> <ins> protocols described above.  Note that not all protocols support each interface.  We partition these interfaces into pre-connection (configuration), connection, and post-connection interfaces. </ins> 5.1.


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


provide authentication, using EAP for example. Protocols: IKEv2, SRTP <del> 5.2. </del> <ins> Pre-Shared Key Import Either the handshake protocol or the application directly can supply pre-shared keys for the record protocol use for encryption/ decryption and authentication.  If the application can supply keys directly, this is considered explicit import; if the handshake protocol traditionally provides the keys directly, it is considered direct import; if the keys can only be shared by the handshake, they are considered non-importable. </ins> <del> Handshake interfaces are the points of interaction between a handshake protocol and the application, record protocol, and transport once the handshake is active. </del> <ins> Explict import: QUIC, ESP Direct import: TLS, DTLS, MinimalT, tcpcrypt, WireGuard </ins> <del> Send Handshake Messages The handshake protocol needs to be able to send messages over a transport to the remote peer to establish trust and to negotiate keys. Protocols: All (TLS, DTLS, QUIC + TLS, MinimalT, CurveCP, IKEv2, WireGuard, SRTP (DTLS)) </del> <ins> Non-importable: CurveCP </ins> <del> Receive Handshake Messages The handshake protocol needs to be able to receive messages from the remote peer over a transport to establish trust and to negotiate keys. Protocols: All (TLS, DTLS, QUIC + TLS, MinimalT, CurveCP, IKEv2, WireGuard, SRTP (DTLS)) </del> <ins> 5.2. </ins> Identity Validation During a handshake, the security protocol will conduct identity


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


Non-exportable: CurveCP <del> 5.3. Record interfaces are the points of interaction between a record protocol and the application, handshake protocol, and transport once in use. Pre-Shared Key Import Either the handshake protocol or the application directly can supply pre-shared keys for the record protocol use for encryption/ decryption and authentication.  If the application can supply keys directly, this is considered explicit import; if the handshake protocol traditionally provides the keys directly, it is considered direct import; if the keys can only be shared by the handshake, they are considered non-importable. Explict import: QUIC, ESP Direct import: TLS, DTLS, MinimalT, tcpcrypt, WireGuard Non-importable: CurveCP Encrypt application data The application can send data to the record protocol to encrypt it into a format that can be sent on the underlying transport.  The encryption step may require that the application data is treated as a stream or as datagrams, and that the transport to send the encrypted records present a stream or datagram interface. Stream-to-Stream Protocols: TLS, tcpcrypt Datagram-to-Datagram Protocols: DTLS, ESP, SRTP, WireGuard Stream-to-Datagram Protocols: QUIC ((Editor's Note: This depends on the interface QUIC exposes to applications.)) Decrypt application data The application can receive data from its transport to be decrypted using record protocol.  The decryption step may require that the incoming transport data is presented as a stream or as datagrams, and that the resulting application data is a stream or datagrams. Stream-to-Stream Protocols: TLS, tcpcrypt Datagram-to-Datagram Protocols: DTLS, ESP, SRTP, WireGuard Datagram-to-Stream Protocols: QUIC ((Editor's Note: This depends on the interface QUIC exposes to applications.)) </del> Key Expiration The record protocol can signal that its keys are expiring due to reaching a time-based deadline, or a use-based deadline (number of


more on this, as well as https://mailarchive.ietf.org/arch/msg/tls/ TugB5ddJu3nYg7chcyeIyUqWSbA.]] <ins> contains keys that are not required to be understood by the client.  Server operators MUST NOT place a key in this section unless the server is able to determine whether the key is in use based on the client data it receives.  A key MUST NOT appear in both the main template and the optional section. </ins> 2.1.1. To be compatible with the specializations described in this section,


6. <ins> 6.1. </ins> This document requests that a code point be allocated from the "TLS ContentType registry.  This value must be in the range 0-31 (inclusive).  The row to be added in the registry has the following


[[OPEN ISSUE: Should we require standards action for all profile IDs that would fit in 2 octets.]] <ins> 6.2. This document requests that IANA open a new registry entitled "cTLS Template Keys", on the Transport Layer Security (TLS) Parameters page, with a "Specification Required" registration policy and the following initial contents: </ins>


https://mailarchive.ietf.org/arch/msg/tls/ TugB5ddJu3nYg7chcyeIyUqWSbA. <ins> If true, handshake messages MUST be conveyed inside a "Handshake" (RFC8446, Section 4) struct on stream transports, or a "DTLSHandshake" (RFC9147, Section 5.2) struct on datagram transports, and MAY be broken into multiple records as in TLS and DTLS.  Otherwise, each handshake message is conveyed in a "CTLSHandshake" or "CTLSDatagramHandshake" struct (ctlshandshake), which MUST be the payload of a single record. </ins> contains keys that are not required to be understood by the client.  Server operators MUST NOT place a key in this section unless the server is able to determine whether the key is in use


value to distinguish cTLS plaintext records from encrypted records, TLS/DTLS records, and other protocols using the same 5-tuple. <ins> The "profile_id" field MUST identify the profile that is in use.  A zero-length ID corresponds to the cTLS default protocol.  The server's reply does not include the "profile_id", because the server must be using the same profile indicated by the client. </ins> Encrypted records use DTLS 1.3 RFC9147 record framing, comprising a configuration octet followed by optional connection ID, sequence number, and length fields.  The encryption process and additional


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


6.3. <ins> This document requests that IANA change the name of entry 6 in the TLS HandshakeType Registry from "hello_retry_request_RESERVED" to "hello_retry_request", and set its Reference field to this document. 6.4. </ins> This document requests that IANA open a new registry entitled "Well- known cTLS Profile IDs", on the Transport Layer Security (TLS) Parameters page, with the following columns:


Omitting the fields and handshake messages required for preserving backwards-compatibility with earlier TLS versions. <del> More compact encodings, for example point compression. </del> <ins> More compact encodings. </ins> A template-based specialization mechanism that allows pre- populating information at both endpoints without the need for negotiation. <del> Alternative cryptographic techniques, such as semi-static Diffie- Hellman. OPEN ISSUE: Semi-static and point compression are never mentioned again. </del> <ins> Alternative cryptographic techniques, such as nonce truncation. </ins> For the common (EC)DHE handshake with pre-established certificates, Stream cTLS achieves an overhead of 53 bytes over the minimum


"encrypted_server_name" extension.  If the client does not retry in either scenario, it MUST report an error to the calling application. <ins> If the server sends a HelloRetryRequest in response to the ClientHello and the client can send a second updated ClientHello per the rules in RFC8446, the "encrypted_server_name" extension values which do not depend on the (possibly updated) ClientHello.KeyShareClientHello, i.e,, ClientEncryptedSNI.suite, ClientEncryptedSNI.key_share, and ClientEncryptedSNI.record_digest, MUST NOT change across ClientHello messages.  Moreover, ClientESNIInner.nonce and ClientESNIInner.realSNI MUST not change across ClientHello messages.  Informally, the values of all unencrypted extension information, as well as the inner extension plaintext, must be consistent between the first and second ClientHello messages. </ins> 5.1.3. When the server cannot decrypt or does not process the


existing registry for Alerts (defined in RFC8446), with the "DTLS-OK" column being set to "Y". <del> 8.3. IANA is requested to create an entry, ESNI(0xff9f), in the existing registry for Resource Record (RR) TYPEs (defined in RFC6895) with "Meaning" column value being set to "Encrypted SNI". </del> <ins> 9. When operating in Split Mode, backend servers will not have access to PaddedServerNameList.sni or ClientESNIInner.nonce without access to the ESNI keys or a way to decrypt ClientEncryptedSNI.encrypted_sni. One way to address this for a single connection, at the cost of having communication not be unmodified TLS 1.3, is as follows. Assume there is a shared (symmetric) key between the client-facing server and the backend server and use it to AEAD-encrypt Z and send the encrypted blob at the beginning of the connection before the ClientHello.  The backend server can then decrypt ESNI to recover the true SNI and nonce. 10. Alternative approaches to encrypted SNI may be implemented at the TLS or application layer.  In this section we describe several alternatives and discuss drawbacks in comparison to the design in this document. 10.1. 10.1.1. In this variant, TLS Client Hellos are tunneled within early data payloads belonging to outer TLS connections established with the client-facing server.  This requires clients to have established a previous session --- and obtained PSKs --- with the server.  The client-facing server decrypts early data payloads to uncover Client Hellos destined for the backend server, and forwards them onwards as necessary.  Afterwards, all records to and from backend servers are forwarded by the client-facing server - unmodified.  This avoids double encryption of TLS records. Problems with this approach are: (1) servers may not always be able to distinguish inner Client Hellos from legitimate application data, (2) nested 0-RTT data may not function correctly, (3) 0-RTT data may not be supported - especially under DoS - leading to availability concerns, and (4) clients must bootstrap tunnels (sessions), costing an additional round trip and potentially revealing the SNI during the initial connection.  In contrast, encrypted SNI protects the SNI in a distinct Client Hello extension and neither abuses early data nor requires a bootstrapping connection. 10.1.2. In this variant, client-facing and backend servers coordinate to produce "combined tickets" that are consumable by both.  Clients offer combined tickets to client-facing servers.  The latter parse them to determine the correct backend server to which the Client Hello should be forwarded.  This approach is problematic due to non- trivial coordination between client-facing and backend servers for ticket construction and consumption.  Moreover, it requires a bootstrapping step similar to that of the previous variant.  In contrast, encrypted SNI requires no such coordination. 10.2. 10.2.1. In this variant, clients request secondary certificates with CERTIFICATE_REQUEST HTTP/2 frames after TLS connection completion. In response, servers supply certificates via TLS exported authenticators I-D.ietf-tls-exported-authenticator in CERTIFICATE frames.  Clients use a generic SNI for the underlying client-facing server TLS connection.  Problems with this approach include: (1) one additional round trip before peer authentication, (2) non-trivial application-layer dependencies and interaction, and (3) obtaining the generic SNI to bootstrap the connection.  In contrast, encrypted SNI induces no additional round trip and operates below the application layer. 11. The design described here only provides encryption for the SNI, but not for other extensions, such as ALPN.  Another potential design would be to encrypt all of the extensions using the same basic structure as we use here for ESNI.  That design has the following advantages: It protects all the extensions from ordinary eavesdroppers If the encrypted block has its own KeyShare, it does not necessarily require the client to use a single KeyShare, because the client's share is bound to the SNI by the AEAD (analysis needed). It also has the following disadvantages: The client-facing server can still see the other extensions.  By contrast we could introduce another EncryptedExtensions block that was encrypted to the backend server and not the client-facing server. It requires a mechanism for the client-facing server to provide the extension-encryption key to the backend server (as in communicating-sni and thus cannot be used with an unmodified backend server. A conformant middlebox will strip every extension, which might result in a ClientHello which is just unacceptable to the server (more analysis needed). </ins>


encrypt the ClientHello.  See hpke-map for information on how a cipher suite maps to corresponding HPKE algorithm identifiers. <del> the largest name the server expects to support.  If the server supports arbitrary wildcard names, it SHOULD set this value to 256.  Clients SHOULD reject ESNIConfig as invalid if maximum_name_length is greater than 256. </del> <ins> The largest name the server expects to support, if known.  If this value is not known it can be set to zero, in which case clients SHOULD use the inner ClientHello padding scheme described below. That could happen if wildcard names are in use, or if names can be added or removed from the anonymity set during the lifetime of a particular resource record value. </ins> A list of extensions that the client can take into consideration when generating a Client Hello message.  The purpose of the field


an "echo_nonce" extension <del> TLS padding Padding SHOULD be P = L - D bytes, where L = ECHOConfig.maximum_name_length, rounded up to the nearest multiple of 16 D = len(dns_name), where dns_name is the DNS name in the ClientHelloInner "server_name" extension </del> <ins> TLS padding RFC7685 (see section padding) </ins> When offering an encrypted ClientHello, the client MUST NOT offer to resume any non-ECHO PSKs.  It additionally MUST NOT offer to resume


7.2. <ins> Future extensions could reveal sensitive information through their length.  Consequently, padding should be flexible and support arbitrary extension changes. For each field in the inner ClientHello, clients need to determine how much to pad given the semantics of that field.  For example, if a client can propose various ALPN values, it could add padding to round up to the longest of those. The target padding length of most ClientHello extensions can be determined without server help.  However, the "server_name" extension could benefit from server input (ECHOConfig.maximum_name_length). Clients SHOULD compute the padding for this extension as follows: If ECHOConfig.maximum_name_length is longer than the actual server_name then clients SHOULD add padding to make up that difference. Otherwise, if ECHOConfig.maximum_name_length is zero or less than the length of the actual server_name then round the server_name up to a multiple of 32 octets and randomly add another 32 octets 50% of the time and then include that amount of additional padding. The amount of padding applied to the ClientHello is then computed as the sum of all per-extension padding values, rounded up to the nearest multiple of 32.  (This additional rounding step aims to hide variance across different client implementations.) In addition to padding ClientHelloInner, clients and servers will also need to pad all other handshake messages that have sensitive- length fields.  For example, if a client proposes ALPN values in ClientHelloInner, the server-selected value will be returned in an EncryptedExtension, so that handshake message also needs to be padded using TLS record layer padding. 7.3. </ins> As described in server-behavior, the server MAY either accept ECHO and use ClientHelloInner or reject it and use ClientHelloOuter. However, there is no indication in ServerHello of which one the server has done and the client must therefore use trial decryption in order to determine this. <del> 7.2.1. </del> <ins> 7.3.1. </ins> If the server used ClientHelloInner, the client proceeds with the connection as usual, authenticating the connection for the origin server. <del> 7.2.2. </del> <ins> 7.3.2. </ins> If the server used ClientHelloOuter, the client proceeds with the handshake, authenticating for ECHOConfig.public_name as described in


"encrypted_server_name" extension.  If the client does not retry in either scenario, it MUST report an error to the calling application. <del> 7.2.2.1. </del> <ins> 7.3.2.1. </ins> When the server cannot decrypt or does not process the "encrypted_server_name" extension, it continues with the handshake


implemented, for instance, by reporting a failed connection with a dedicated error code. <del> 7.2.3. </del> <ins> 7.3.3. </ins> If the server sends a HelloRetryRequest in response to the ClientHello, the client sends a second updated ClientHello per the


and this is easy to probe for, can we just instead have an extension to indicate what has happened.]] <del> 7.3. </del> <ins> 7.4. </ins> If the client attempts to connect to a server and does not have an ECHOConfig structure available for the server, it SHOULD send a


11.1. <del> In comparison to I-D.kazuho-protected-sni, wherein DNS Resource Records are signed via a server private key, ECHO records have no authenticity or provenance information.  This means that any attacker which can inject DNS responses or poison DNS caches, which is a common scenario in client access networks, can supply clients with fake ECHO records (so that the client encrypts data to them) or strip the ECHO record from the response.  However, in the face of an attacker that controls DNS, no encryption scheme can work because the attacker can replace the IP address, thus blocking client connections, or substituting a unique IP address which is 1:1 with the DNS name that was looked up (modulo DNS wildcards).  Thus, allowing the ECHO records in the clear does not make the situation significantly worse. Clearly, DNSSEC (if the client validates and hard fails) is a defense against this form of attack, but DoH/DPRIVE are also defenses against DNS attacks by attackers on the local network, which is a common case where ClientHello and SNI encryption are desired.  Moreover, as noted in the introduction, SNI encryption is less useful without encryption of DNS queries in transit via DoH or DPRIVE mechanisms. 11.2. Supporting optional record digests and trial decryption opens oneself up to DoS attacks.  Specifically, an adversary may send malicious ClientHello messages, i.e., those which will not decrypt with any known ECHO key, in order to force decryption.  Servers that support this feature should, for example, implement some form of rate limiting mechanism to limit the damage caused by such attacks. 11.3. ECHO 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. 11.4. I-D.ietf-tls-sni-encryption lists several requirements for SNI encryption.  In this section, we re-iterate these requirements and assess the ECHO design against them. 11.4.1. Since servers process either ClientHelloInner or ClientHelloOuter, and ClientHelloInner contains an HPKE-derived nonce, it is not possible for an attacker to "cut and paste" the ECHO value in a different Client Hello and learn information from ClientHelloInner. This is because the attacker lacks access to the HPKE-derived nonce used to derive the handshake secrets. 11.4.2. This design depends upon DNS as a vehicle for semi-static public key distribution.  Server operators may partition their private keys however they see fit provided each server behind an IP address has the corresponding private key to decrypt a key.  Thus, when one ECHO key is provided, sharing is optimally bound by the number of hosts that share an IP address.  Server operators may further limit sharing by publishing different DNS records containing ECHOConfig values with different keys using a short TTL. 11.4.3. This design requires servers to decrypt ClientHello messages with ClientEncryptedCH extensions carrying valid digests.  Thus, it is possible for an attacker to force decryption operations on the server.  This attack is bound by the number of valid TCP connections an attacker can open. 11.4.4. As more clients enable ECHO support, e.g., as normal part of Web browser functionality, with keys supplied by shared hosting providers, the presence of ECHO extensions becomes less suspicious and part of common or predictable client behavior.  In other words, if all Web browsers start using ECHO, the presence of this value does not signal suspicious behavior to passive eavesdroppers. Additionally, this specification allows for clients to send GREASE ECHO extensions (see grease-extensions), which helps ensure the ecosystem handles the values correctly. 11.4.5. This design is not forward secret because the server's ECHO key is static.  However, the window of exposure is bound by the key lifetime.  It is RECOMMENDED that servers rotate keys frequently. 11.4.6. This design permits servers operating in Split Mode to forward connections directly to backend origin servers, thereby avoiding unnecessary MiTM attacks. 11.4.7. Assuming ECHO 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 cleartext-dns for more details regarding cleartext DNS. Authenticating the ECHOConfigs structure naturally authenticates the included public name.  This also authenticates any retry signals from the server because the client validates the server certificate against the public name before retrying. 11.4.8. 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. 11.5. 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 backend server also only has one identity.  This does, however, change the situation slightly in that the backend server might previously have checked SNI and now cannot (and an attacker can route a connection with an encrypted SNI to any backend server and the TLS connection will still complete).  However, the client is still responsible for verifying the server's identity in its certificate. [[TODO: Some more analysis needed in this case, as it is a little odd, and probably some precise rules about handling ECHO and no SNI uniformly?]] 12. 12.1. </del> IANA is requested to create an entry, encrypted_server_name(0xffce), in the existing registry for ExtensionType (defined in RFC8446), with "TLS 1.3" column values being set to "CH, EE", and "Recommended" column being set to "Yes". <del> 12.2. </del> <ins> 11.2. </ins> IANA is requested to create an entry, echo_required(121) in the existing registry for Alerts (defined in RFC8446), with the "DTLS-OK"


has been unable to develop a completely generic solution.  I-D.ietf- tls-sni-encryption provides a description of the problem space and some of the proposed techniques.  One of the more difficult problems <del> is "Do not stick out" (I-D.ietf-tls-sni-encryption; Section 3.4): if </del> <ins> is "Do not stick out" (I-D.ietf-tls-sni-encryption, Section 3.4): if </ins> only sensitive/private services use SNI encryption, then SNI encryption is a signal that a client is going to such a service.  For this reason, much recent work has focused on concealing the fact that


"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, <del> as shown here.  All TLS notation comes from RFC8446; Section 3. </del> <ins> as shown here.  All TLS notation comes from RFC8446, Section 3. </ins> 3.


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


9.2. A more serious problem is MITM proxies which do not support this <del> extension.  RFC8446; Section 9.3 requires that such proxies remove </del> <ins> extension.  RFC8446, Section 9.3 requires that such proxies remove </ins> any extensions they do not understand.  The handshake will then present a certificate based on the public name, without echoing the "encrypted_client_hello" extension to the client.


IANA is requested to create an entry, echo_required(121) in the existing registry for Alerts (defined in RFC8446), with the "DTLS-OK" column being set to "Y". <ins> 12. Any future information or hints that influence the outer ClientHello SHOULD be specified as ECHOConfig extensions, or in an entirely new version of ECHOConfig.  This is primarily because the outer ClientHello exists only in support of ECHO.  Namely, it is both an envelope for the encrypted inner ClientHello and enabler for authenticated key mismatch signals (see server-behavior).  In contrast, the inner ClientHello is the true ClientHello used upon ECHO negotiation. </ins>


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


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


server in the same session. Set the "config_digest" field to a randomly-generated string of <del> hash_length bytes, where hash_length is the length of the hash function associated with the chosen HpkeCipherSuite. </del> <ins> "Nh" bytes, where "Nh" is the output length of the "Extract" function of the KDF associated with the chosen cipher suite.  (The KDF API is specified in I-D.irtf-cfrg-hpke.) </ins> Set the "enc" field to a randomly-generated valid encapsulated public key output by the HPKE KEM.


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


When a client wants to establish a TLS session with the backend server, it constructs its ClientHello as usual (we will refer to this as the ClientHelloInner message) and then encrypts this message using <del> the ECH public key.  It then constructs a new ClientHello (ClientHelloOuter) with innocuous values for sensitive extensions, e.g., SNI, ALPN, etc., and with the encrypted ClientHelloInner in an </del> <ins> the public key of the ECH configuration.  It then constructs a new ClientHello (ClientHelloOuter) with innocuous values for sensitive extensions, e.g., SNI, ALPN, etc., and with an </ins> "encrypted_client_hello" extension, which this document defines <del> (encrypted-client-hello).  Finally, it sends ClientHelloOuter to the server. </del> <ins> (encrypted-client-hello).  The extension's payload carries the encrypted ClientHelloInner and specifies the ECH configuration used for encryption.  Finally, it sends ClientHelloOuter to the server. </ins> Upon receiving the ClientHelloOuter, the client-facing server takes one of the following actions:


"encrypted_client_hello" extension and proceeds with the handshake as usual, per RFC8446, Section 4.1.2. <del> If it supports ECH but cannot decrypt it, then it ignores the extension and proceeds with the handshake as usual.  This is </del> <ins> If it supports ECH but does not recognize the configuration specified by the client, then it ignores the extension and terminates the handshake using the ClientHelloOuter.  This is </ins> 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 can decrypt it, then 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 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". </ins> Upon receiving the server's response, the client determines whether ECH was accepted or rejected and proceeds with the handshake


7.3.2.1. <del> When the server cannot decrypt or does not process the </del> <ins> When the server rejects ECH or otherwise ignores </ins> "encrypted_client_hello" extension, it continues with the handshake using the plaintext "server_name" extension instead (see server- behavior).  Clients that offer ECH then authenticate the connection


suite it will use for encryption.  It MUST NOT choose a cipher suite not advertised by the configuration. <del> Next, the client constructs the ClientHelloOuter message just as it </del> <ins> Next, the client constructs the ClientHelloInner message just as it </ins> does a standard ClientHello, with the exception of the following rules: <del> It MUST offer to negotiate TLS 1.3 or above. It MUST include an "encrypted_client_hello" extension with a payload constructed as described below. </del> <ins> It MUST NOT offer to negotiate TLS 1.2 or below.  Note this is necessary to ensure the backend server does not negotiate a TLS version that is incompatible with ECH. </ins> <del> The value of "ECHConfig.public_name" MUST be placed in the "server_name" extension. </del> <ins> It MUST NOT offer to resume any session for TLS 1.2 and below. </ins> <del> It MUST NOT include the "pre_shared_key" extension.  (See flow- clienthello-malleability.) </del> <ins> It SHOULD contain TLS padding RFC7685 as described in padding. </ins> <del> The client then constructs the ClientHelloInner message just as it </del> <ins> The client then constructs the ClientHelloOuter message just as it </ins> does a standard ClientHello, with the exception of the following rules: <del> It MUST NOT offer to negotiate TLS 1.2 or below.  Note this is necessary to ensure the backend server does not negotiate a TLS version that is incompatible with ECH. It MUST NOT offer to resume any session for TLS 1.2 and below. </del> <ins> It MUST offer to negotiate TLS 1.3 or above. </ins> <del> It MAY offer any other extension in the ClientHelloOuter except those that have been incorporated into the ClientHelloInner as described in outer-extensions. </del> <ins> Any extensions compressed as described in outer-extensions must match the ClientHelloInner.  [[OPEN ISSUE: When #331 and compression ordering is resolved, be a bit more precise here.]] </ins> <del> It MAY copy any other field from the ClientHelloOuter except ClientHelloOuter.random.  Instead, It MUST generate a fresh ClientHelloInner.random using a secure random number generator. </del> <ins> It MAY copy any other field from the ClientHelloInner except ClientHelloInner.random.  Instead, It MUST generate a fresh ClientHelloOuter.random using a secure random number generator. </ins> (See flow-client-reaction.) <del> It SHOULD contain TLS padding RFC7685 as described in padding. </del> If implementing TLS 1.3's compatibility mode (see Appendix D.4 of RFC8446), it MUST copy the legacy_session_id field from <del> ClientHelloOuter.  This allows the server to echo the correct </del> <ins> ClientHelloInner.  This allows the server to echo the correct </ins> session ID when ECH is negotiated. <ins> It MUST include an "encrypted_client_hello" extension with a payload constructed as described below. The value of "ECHConfig.public_name" MUST be placed in the "server_name" extension. It MUST NOT include the "pre_shared_key" extension.  (See flow- clienthello-malleability.) </ins> The client might duplicate non-sensitive extensions in both messages. However, implementations need to take care to ensure that sensitive extensions are not offered in the ClientHelloOuter.  [[OPEN ISSUE: We


If sending a second ClientHello in response to a HelloRetryRequest, the client copies the entire "encrypted_client_hello" extension from <del> the first ClientHello. </del> <ins> the first ClientHello.  The identical value will reveal to an observer that the value of "encrypted_client_hello" was fake, but this only occurs if there is a HelloRetryRequest. </ins> If the server sends an "encrypted_client_hello" extension in either HelloRetryRequest or EncryptedExtensions, the client MUST check the


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


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


3.2. <del> ECH allows the client to encrypt sensitive ClientHello extensions, e.g., SNI, ALPN, etc., under the public key of the client-facing server.  This requires the client-facing server to publish the public key and metadata it uses for ECH for all the domains for which it serves directly or indirectly (via Split Mode).  This document defines the format of the ECH encryption public key and metadata, referred to as an ECH configuration, and delegates DNS publication details to HTTPS-RR, though other delivery mechanisms are possible. In particular, if some of the clients of a private server are applications rather than Web browsers, those applications might have the public key and metadata preconfigured. When a client wants to establish a TLS session with the backend server, it constructs its ClientHello as indicated in real-ech.  We will refer to this as the ClientHelloInner message.  The client encrypts this message using the public key of the ECH configuration. It then constructs a new ClientHello, the ClientHelloOuter, with innocuous values for sensitive extensions, e.g., SNI, ALPN, etc., and with an "encrypted_client_hello" extension, which this document defines (encrypted-client-hello).  The extension's payload carries the encrypted ClientHelloInner and specifies the ECH configuration used for encryption.  Finally, it sends ClientHelloOuter to the server. Upon receiving the ClientHelloOuter, a TLS server takes one of the following actions: If it does not support ECH, it ignores the "encrypted_client_hello" extension and proceeds with the handshake as usual, per RFC8446, Section 4.1.2. If it is a client-facing server for the ECH protocol, but cannot decrypt the extension, then it terminates the handshake using the ClientHelloOuter.  This is referred to as "ECH rejection".  When ECH is rejected, the client-facing server sends an acceptable ECH configuration in its EncryptedExtensions message. If it supports ECH and decrypts the extension, it forwards the ClientHelloInner to the backend server, who terminates the connection.  This is referred to as "ECH acceptance". </del> <ins> A client-facing server enables ECH by publishing an ECH configuration, which is an encryption public key and associated metadata.  The server must publish this for all the domains it serves via Shared or Split Mode.  This document defines the ECH configuration's format, but delegates DNS publication details to HTTPS-RR.  Other delivery mechanisms are also possible.  For example, the client may have the ECH configuration preconfigured. When a client wants to establish a TLS session with some backend server, it constructs a private ClientHello, referred to as the ClientHelloInner.  The client then constructs a public ClientHello, referred to as the ClientHelloOuter.  The ClientHelloOuter contains innocuous values for sensitive extensions and an "encrypted_client_hello" extension (encrypted-client-hello), which carries the encrypted ClientHelloInner.  Finally, the client sends ClientHelloOuter to the server. The server takes one of the following actions: If it does not support ECH or cannot decrypt the extension, it completes the handshake with ClientHelloOuter.  This is referred to as rejecting ECH. If it successfully decrypts the extension, it forwards the ClientHelloInner to the backend server, which completes the handshake.  This is referred to as accepting ECH. </ins> Upon receiving the server's response, the client determines whether <del> or not ECH was accepted and proceeds with the handshake accordingly. (See client-behavior for details.) </del> <ins> or not ECH was accepted (handle-server-response) and proceeds with the handshake accordingly.  When ECH is rejected, the resulting connection is not usable by the client for application data. Instead, ECH rejection allows the client to retry with up-to-date configuration (rejected-ech). </ins> The primary goal of ECH is to ensure that connections to servers in the same anonymity set are indistinguishable from one another.


extension and MUST NOT use the retry keys. Offering a GREASE extension is not considered offering an encrypted <del> ClientHello for purposes of requirements in client-behavior.  In particular, the client MAY offer to resume sessions established without ECH. </del> <ins> ClientHello for purposes of requirements in real-ech.  In particular, the client MAY offer to resume sessions established without ECH. </ins> 7.


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


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


expansion) the server MAY abort the connection with an "illegal_parameter" alert without attempting to decrypt. <del> Assuming that these checks succeed, the server then computes K_sni and decrypts the ServerName value.  If decryption fails, the server MUST abort the connection with a "decrypt_error" alert. </del> <ins> Assuming these checks succeed, the server then computes K_sni and decrypts the ServerName value.  If decryption fails, the server MUST abort the connection with a "decrypt_error" alert. </ins> If the decrypted value's length is different from the advertised padding_length or the padding consists of any value other than 0,


5.3. <ins> A server operating in Shared Mode uses PaddedServerNameList.sni as if it were the "server_name" extension to finish the handshake.  It SHOULD pad the Certificate message, via padding at the record layer, such that its length equals the size of the largest possible Certificate (message) covered by the same ESNI key. 5.4. </ins> The Hidden Server ignores both the "encrypted_server_name" and the "server_name" (if any) and completes the handshake as usual.  If in Shared Mode, the server will still know the true SNI, and can use it for certificate selection.  In Split Mode, it may not know the true <del> SNI and so will generally be configured to use a single certificate </del> <ins> SNI and so will generally be configured to use a single certificate. </ins> communicating-sni describes a mechanism for communicating the true <del> SNI to the hidden server.  [[OPEN ISSUE: Do we want "encrypted_server_name" in EE?  It's clearer communication, but gets in the way of stock servers.]] </del> <ins> SNI to the hidden server. Similar to the Shared Mode behavior, the hidden server in Split Mode SHOULD pad the Certificate message, via padding at the record layer such that its length equals the size of the largest possible Certificate (message) covered by the same ESNI key. [[OPEN ISSUE: Do we want "encrypted_server_name" in EE?  It's clearer communication, but gets in the way of stock servers.]] </ins> 6.


Records are signed via a server private key, ESNIKeys have no authenticity or provenance information.  This means that any attacker which can inject DNS responses or poison DNS caches, which is a <del> common scenario in client access netowrks, can supply clients with </del> <ins> common scenario in client access networks, can supply clients with </ins> fake ESNIKeys (so that the client encrypts SNI to them) or strip the ESNIKeys from the response.  However, in the face of an attacker that controls DNS, no SNI encryption scheme can work because the attacker


for the "encrypted_client_hello" extension.  Clients MUST ignore any "ECHConfig" structure with a version they do not support. <del> The length, in bytes, of the next field. </del> <ins> The length, in bytes, of the next field.  This length field allows implementations to skip over the elements in such a list where they cannot parse the specific version of ECHConfig. </ins> An opaque byte string whose contents depend on the version.  For this specification, the contents are an "ECHConfigContents"


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


Abstract <del> This document describes an interface for importing external PSK (Pre- Shared Key) into TLS 1.3. </del> <ins> This document describes an interface for importing external Pre- Shared Keys (PSKs) into TLS 1.3. </ins> 1. <del> TLS 1.3 RFC8446 supports pre-shared key (PSK) authentication, wherein </del> <ins> TLS 1.3 RFC8446 supports Pre-Shared Key (PSK) authentication, wherein </ins> PSKs can be established via session tickets from prior connections or externally via some out-of-band mechanism.  The protocol mandates that each PSK only be used with a single hash function.  This was


key derivation.  Moreover, it requires external PSKs to be provisioned for specific hash functions. <del> To mitigate these problems, external PSKs can be bound to a specific KDF and hash function when used in TLS 1.3, even if they are associated with a different hash function when provisioned.  This document specifies an interface by which external PSKs may be imported for use in a TLS 1.3 connection to achieve this goal.  In particular, it describes how KDF-bound PSKs can be differentiated by the target (D)TLS protocol version and KDF for which the PSK will be used.  This produces a set of candidate PSKs, each of which are bound to a specific target protocol and KDF.  This expands what would normally have been a single PSK identity into a set of PSK identities. </del> <ins> To mitigate these problems, this document specifies a PSK Importer interface by which external PSKs may be imported and subsequently bound to a specific KDF and hash function for use in TLS 1.3.  In particular, it describes a mechanism for differentiating external PSKs by the target KDF, (D)TLS protocol version, and an optional context string.  This process yields a set of candidate PSKs, each of which are bound to a target KDF and protocol.  This expands what would normally have been a single PSK and identity into a set of PSKs and identities. </ins> 2.


3. <del> Key importers mirror the concept of key exporters in TLS in that they diversify a key based on some contextual information before use in a connection.  In contrast to key exporters, wherein differentiation is done via an explicit label and context string, the key importer defined herein diversifies external one PSK into one or more PSKs for use via a target protocol, KDF identifier, and optional context string.  Additionally, the resulting PSK binder key is modified with a new derivation label to prevent confusion with non-imported PSKs. Imported keys do not require negotiation for use, as a client and server will not agree upon identities if not imported correctly. Endpoints may incrementally deploy PSK importer support by offering </del> <ins> The PSK Importer interface mirrors that of the TLS Exporters interface in that it diversifies a key based on some contextual information.  In contrast to the Exporters interface, wherein differentiation is done via an explicit label and context string, the PSK Importer interface defined herein takes an external PSK and identity and "imports" it into TLS, creating a set of "derived" PSKs and identities.  Each of these derived PSKs are bound a target protocol, KDF identifier, and optional context string.  Additionally, the resulting PSK binder keys are modified with a new derivation label to prevent confusion with non-imported PSKs. Imported keys do not require negotiation for use since a client and server will not agree upon identities if imported incorrectly. Endpoints may incrementally deploy PSK Importer support by offering </ins> non-imported keys for TLS versions prior to TLS 1.3.  Non-imported and imported PSKs are distinct since their identities are different on the wire.  See rollout for more details. <del> Clients which import external keys TLS MUST NOT use these keys for any other purpose.  Moreover, each external PSK MUST be associated with at most one hash function. </del> <ins> Clients which import external keys MUST NOT use either the external keys or the derived keys for any other purpose.  Moreover, each external PSK MUST be associated with at most one hash function, as per the rules in Section 4.2.11 from RFC8446.  See security- considerations for more discussion. </ins> 3.1.


Target KDF: The KDF for which a PSK is imported for use. <del> Imported PSK (IPSK): A PSK derived from an EPSK, external identity, optional context string, and target protocol and KDF. </del> <ins> Imported PSK (IPSK): A PSK derived from an EPSK, External Identity, optional context string, and target protocol and KDF. </ins> Imported Identity: A sequence of bytes used to identify an IPSK. 4. <del> A key importer diversifies an input EPSK into one or more PSKs advertised on the wire via a target protocol, KDF identifier, and optional context string.  Additionally, the resulting PSK binder key is modified with a new derivation label to prevent confusion with non-imported PSKs.  This section describes the diversification mechanism and binder key computation change. </del> <ins> This section describes the PSK Importer interface and its underlying diversification mechanism and binder key computation modification. </ins> 4.1. <del> A key importer takes as input an EPSK with external identity "external_identity" and base key "epsk", as defined in terminology, along with an optional context, and transforms it into a set of PSKs and imported identities for use in a connection based on supported (target) protocols and KDFs.  In particular, for each supported target protocol "target_protocol" and KDF "target_kdf", the importer </del> <ins> The PSK Importer interface takes as input an EPSK with External Identity "external_identity" and base key "epsk", as defined in terminology, along with an optional context, and transforms it into a set of PSKs and imported identities for use in a connection based on target protocols and KDFs.  In particular, for each supported target protocol "target_protocol" and KDF "target_kdf", the importer </ins> constructs an ImportedIdentity structure as follows: The list of "target_kdf" values is maintained by IANA as described in


and QUICv1 QUIC use 0x0304.  Note that this means future versions of TLS will increase the number of PSKs derived from an external PSK. <del> An Imported PSK derived from an EPSK with base key 'epsk' bound to this identity is then computed as follows: </del> <ins> Given an ImportedIdentity and corresponding EPSK with base key "epsk", an Imported PSK IPSK with base key "ipskx" is computed as follows: </ins> <del> L is corresponds to the KDF output length of ImportedIdentity.target_kdf as defined in IANA.  For hash-based KDFs, such as HKDF_SHA256(0x0001), this is the length of the hash function output, i.e., 32 octets.  This is required for the IPSK to be of length suitable for supported ciphersuites. </del> <ins> L corresponds to the KDF output length of ImportedIdentity.target_kdf as defined in IANA.  For hash-based KDFs, such as HKDF_SHA256(0x0001), this is the length of the hash function output, i.e., 32 octets.  This is required for the IPSK to be of length suitable for supported ciphersuites. </ins> <del> The identity of 'ipskx' as sent on the wire is ImportedIdentity, </del> <ins> The identity of "ipskx" as sent on the wire is ImportedIdentity, </ins> i.e., the serialized content of ImportedIdentity is used as the <del> content of PskIdentity.identity in the PSK extension. </del> <ins> content of PskIdentity.identity in the PSK extension.  The corresponding TLS 1.3 binder key is "ipskx". </ins> The hash function used for HKDF RFC5869 is that which is associated with the EPSK.  It is not the hash function associated with


SHA-256 MUST be used.  Diversifying EPSK by ImportedIdentity.target_kdf ensures that an IPSK is only used as input keying material to at most one KDF, thus satisfying the <del> requirements in RFC8446. Endpoints generate a compatible ipskx for each target ciphersuite they offer.  For example, importing a key for TLS_AES_128_GCM_SHA256 and TLS_AES_256_GCM_SHA384 would yield two PSKs, one for HKDF-SHA256 and another for HKDF-SHA384.  In contrast, if TLS_AES_128_GCM_SHA256 and TLS_CHACHA20_POLY1305_SHA256 are supported, only one derived key is necessary. The resulting IPSK base key 'ipskx' is then used as the binder key in TLS 1.3 with identity ImportedIdentity.  With knowledge of the supported KDFs, one may import PSKs before the start of a connection. EPSKs may be imported for early data use if they are bound to protocol settings and configurations that would otherwise be required for early data with normal (ticket-based PSK) resumption.  Minimally, that means ALPN, QUIC transport settings, etc., must be provisioned alongside these EPSKs. </del> <ins> requirements in RFC8446.  See security-considerations for more details. Endpoints SHOULD generate a compatible "ipskx" for each target ciphersuite they offer.  For example, importing a key for TLS_AES_128_GCM_SHA256 and TLS_AES_256_GCM_SHA384 would yield two PSKs, one for HKDF-SHA256 and another for HKDF-SHA384.  In contrast, if TLS_AES_128_GCM_SHA256 and TLS_CHACHA20_POLY1305_SHA256 are supported, only one derived key is necessary. EPSKs may be imported before the start of a connection if the target KDFs, protocols, and context string(s) are known a priori.  EPSKs may also be imported for early data use if they are bound to protocol settings and configurations that would otherwise be required for early data with normal (ticket-based PSK) resumption.  Minimally, that means ALPN, QUIC transport parameters (if used for QUIC), etc., must be provisioned alongside these EPSKs. </ins> 4.2. <del> To prevent PSK Importers from being confused with standard out-of- band PSKs, imported PSKs change the PSK binder key derivation label. In particular, the standard TLS 1.3 PSK binder key computation is defined as follows: </del> <ins> To prevent confusion between imported and non-imported PSKs, imported PSKs change the PSK binder key derivation label.  In particular, the standard TLS 1.3 PSK binder key computation is defined as follows: </ins> Imported PSKs replace the string "ext binder" with "imp binder" when <del> deriving "binder_key".  This means the binder key is now computed as </del> <ins> deriving "binder_key".  This means the binder key is computed as </ins> follows: <del> This new label differentiates non-imported and imported external PSKs.  Specifically, a client and server will negotiate use of an </del> <ins> This new label ensures a client and server will negotiate use of an </ins> external PSK if and only if (a) both endpoints import the PSK or (b) neither endpoint imports the PSK.  As "binder_key" is a leaf key, changing its computation does not affect any other key.


algorithm and PSK.  Thus, an EPSK may be used with the same KDF (and underlying HMAC hash algorithm) as TLS 1.3 with importers.  However, critically, the derived PSK will not be the same since the importer <del> differentiates the PSK via the identity, target protocol, and target KDF.  Thus, PSKs imported for TLS 1.3 are distinct from those used in TLS 1.2, and thereby avoid cross-protocol collisions.  Note that this </del> <ins> differentiates the PSK via the identity and target KDF and protocol. Thus, PSKs imported for TLS 1.3 are distinct from those used in TLS 1.2, and thereby avoid cross-protocol collisions.  Note that this </ins> does not preclude endpoints from using non-imported PSKs for TLS 1.2. Indeed, this is necessary for incremental deployment. 7. <del> The Key Importer security goals can be roughly stated as follows: </del> <ins> The PSK Importer security goals can be roughly stated as follows: </ins> avoid PSK re-use across KDFs while properly authenticating endpoints. When modeled as computational extractors, KDFs assume that input keying material (IKM) is sampled from some "source" probability