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 <del> identities.  However, importantly, it requires no change to the TLS 1.3 key schedule. </del>  2. 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 <del> defined herein uses an optional context string along with a target protocol and KDF identifier to differentiate an external PSK into one or more PSKs for use. </del>  Imported keys do not require negotiation for use, as a client and server will not agree upon identities if not imported correctly. <del> Thus, importers induce no protocol changes with the exception of expanding the set of PSK identities sent on the wire.  Endpoints may incrementally deploy PSK importer support by offering 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 4. <del> To prevent PSK Importers from being confused with standard OOB PSKs we change the label used in the computation of the PSK binder key. In TLS 1.3 the PSK binder key computation is defined as follows: </del>  <del> We replace the string "ext binder" with "imp binder".  This means the binder key is now computed as follows: This new label differentiates non-imported and imported external PSKs.  Specifically, a client and server will negotiate use of an external PSK if and only if (a) both endpoints import the PSK or (b) neither endpoint imports the PSK.  The "binder_key" is a leaf key. Therefore, changing its computation doesn't affect any other key. 5. </del>  A key importer takes as input an EPSK with external identity "external_identity" and base key "epsk", as defined in terminology, constructs an ImportedIdentity structure as follows: The list of "target_kdf" values is maintained by IANA as described in <del> IANA.  External PSKs MUST NOT be imported for versions of (D)TLS 1.2 or prior versions.  See rollout for discussion on how imported PSKs for TLS 1.3 and non-imported PSKs for earlier versions co-exist for </del>  incremental deployment. ImportedIdentity.context MUST include the context used to derive the output, i.e., 32 octets.  This is required for the IPSK to be of length suitable for supported ciphersuites. <del> The identity of 'ipskx' as sent on the wire is ImportedIdentity. </del>  The hash function used for HKDF RFC5869 is that which is associated with the EPSK.  It is not the hash function associated with that means ALPN, QUIC transport settings, etc., must be provisioned alongside these EPSKs. <del> 6. </del>  If a client or server wish to deprecate a hash function and no longer use it for TLS 1.3, they remove the corresponding KDF from the set of target KDFs used for importing keys.  This does not affect the KDF operation used to derive Imported PSKs. <del> 7. </del>  Recall that TLS 1.2 permits computing the TLS PRF with any hash algorithm and PSK.  Thus, an EPSK may be used with the same KDF (and does not preclude endpoints from using non-imported PSKs for TLS 1.2. Indeed, this is necessary for incremental deployment. <del> 8. </del>  The Key Importer security goals can be roughly stated as follows: avoid PSK re-use across KDFs while properly authenticating endpoints. [[ TODO: point to stable reference which describes the analysis of these goals ]] <del> 9. </del>  External PSK identities are typically static by design so that endpoints may use them to lookup keying material.  However, for some systems and use cases, this identity may become a persistent tracking identifier. <del> 10. </del>  This specification introduces a new registry for TLS KDF identifiers and defines the following target KDF values: <del> +-------------+-----+ | Description | Value | +-------------+-----+ | Reserved | 0x0000 | | | | | HKDF_SHA256 | 0x0001 | | | | | HKDF_SHA384 | 0x0002 | +-------------+-----+ </del> New target KDF values are allocated according to the following process:

Addresses . cc NAME
The document says: Aside from this statement needing update in light of the changes to the binder label, the core statement here isn't expanded upon. The document needs to very clearly say that the PSK ID that is sent in the psk extension is literally the serialized content of .
Fixed in .

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  <ins> identities. </ins> 2. 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  <ins> 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. </ins> Imported keys do not require negotiation for use, as a client and server will not agree upon identities if not imported correctly.  <ins> Endpoints may incrementally deploy PSK importer support by offering 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. </ins> Clients which import external keys TLS MUST NOT use these keys for any other purpose.  Moreover, each external PSK MUST be associated 4.  <ins> 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. </ins>  <ins> 4.1. </ins> A key importer takes as input an EPSK with external identity "external_identity" and base key "epsk", as defined in terminology, constructs an ImportedIdentity structure as follows: The list of "target_kdf" values is maintained by IANA as described in  <ins> IANA.  External PSKs MUST NOT be imported for (D)TLS 1.2 or prior versions.  See rollout for discussion on how imported PSKs for TLS 1.3 and non-imported PSKs for earlier versions co-exist for </ins> incremental deployment. ImportedIdentity.context MUST include the context used to derive the output, i.e., 32 octets.  This is required for the IPSK to be of length suitable for supported ciphersuites.  <ins> The identity of 'ipskx' as sent on the wire is ImportedIdentity, i.e., the serialized content of ImportedIdentity is used as the content of PskIdentity.identity in the PSK extension. </ins> The hash function used for HKDF RFC5869 is that which is associated with the EPSK.  It is not the hash function associated with that means ALPN, QUIC transport settings, etc., must be provisioned alongside these EPSKs.  <ins> 4.2. 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: Imported PSKs replace the string "ext binder" with "imp binder" when deriving "binder_key".  This means the binder key is now computed as follows: This new label differentiates non-imported and imported external PSKs.  Specifically, a client and server will negotiate use of an 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. 5. </ins> If a client or server wish to deprecate a hash function and no longer use it for TLS 1.3, they remove the corresponding KDF from the set of target KDFs used for importing keys.  This does not affect the KDF operation used to derive Imported PSKs.  <ins> 6. </ins> Recall that TLS 1.2 permits computing the TLS PRF with any hash algorithm and PSK.  Thus, an EPSK may be used with the same KDF (and does not preclude endpoints from using non-imported PSKs for TLS 1.2. Indeed, this is necessary for incremental deployment.  <ins> 7. </ins> The Key Importer security goals can be roughly stated as follows: avoid PSK re-use across KDFs while properly authenticating endpoints. [[ TODO: point to stable reference which describes the analysis of these goals ]]  <ins> 8. </ins> External PSK identities are typically static by design so that endpoints may use them to lookup keying material.  However, for some systems and use cases, this identity may become a persistent tracking identifier.  <ins> 9. </ins> This specification introduces a new registry for TLS KDF identifiers and defines the following target KDF values:  New target KDF values are allocated according to the following process:


Base Key: The secret value of an EPSK. <del> External Identity: The identity of an EPSK. </del>  Target protocol: The protocol for which a PSK is imported for use. Imported PSK (IPSK): A PSK derived from an EPSK, external identity, optional context string, and target protocol and KDF. <del> Imported Identity: The identity of an Imported PSK as sent on the wire. </del>  4.

This isn't perfect either, but it concentrates on the functional side, namely that we use a sequence of bytes to identify PSKs.

Base Key: The secret value of an EPSK.  <ins> External Identity: A sequence of bytes used to identify an EPSK. </ins> Target protocol: The protocol for which a PSK is imported for use. 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. </ins> 4.


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 <del> label to prevent confusion with non-imported PSKs. </del>  Imported keys do not require negotiation for use since a client and server will not agree upon identities if imported incorrectly. and imported PSKs are distinct since their identities are different on the wire.  See rollout for more details. <del> Clients which import external keys MUST NOT use either the external </del>  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- ImportedIdentity.context MUST include the context used to derive the EPSK, if any exists.  For example, ImportedIdentity.context may include information about peer roles or identities to mitigate <del> Selfie-style reflection attacks.  See mitigate-selfie for more </del>  details.  If the EPSK is a key derived from some other protocol or sequence of protocols, ImportedIdentity.context MUST include a channel binding for the deriving protocols RFC5056.

Addresses , , , and .
idnits caught this. Oops.
It's currently later in the document.
From URL
From URL Related to this, where Section 3 states, "Clients which import external keys MUST NOT use either the external keys or the derived keys for any other purpose," should "Clients" be "Clients and servers" or simply "Endpoints"? Here are a few comments gathered from Verisign Labs on draft-ietf-tls-external-psk-importer-04. Overview of draft goals and techniques. We've summarized our understanding of the draft here. Our subsequent comments are based on this understanding. a. Goal: The draft's goal is to define a mechanism by which a TLS client and server can derive multiple, cryptographically separate imported PSKs (IPSKs) from a single, shared external PSK (EPSK), such that each IPSK is associated with a different combination of protocol parameters (e.g., the target KDF for the TLS key schedule). The IPSK then takes the place of the PSK input. This goal is beneficial as it avoids the need for a client and server to establish different EPSKs for these different combinations. The draft doesn't specify how to establish the EPSK initially (this is left out of scope, as it is in TLS itself). b. Mechanism: The IPSK is derived from the EPSK and other parameters via a key derivation function associated with the EPSK. The other parameters include a general-purpose context string, the identifier of the target protocol, and the identifier of the target KDF. The IPSK is thereby bound to these parameters. The binding to the target KDF helps ensure that the input key material for different KDFs are cryptographically separate. c. Syntax: In support of this mechanism, the draft also specifies a new syntax for the opaque PskIdentity.identity field in the TLS PSK extension. The new syntax includes the identity of the underlying EPSK (which remains an opaque string, as usual) and the associated protocol parameters. When a server recognizes that the PSKIdentity.identity field has this syntax, if the server accepts the underlying EPSK and the associated parameters, the server then derives the PSK input to the TLS key schedule from the underlying EPSK and the other parameters. A client may offer multiple IPSK identities, each with a different combination of underlying EPSK identities and associated parameters. Technical comments. a. Distinct identities? Sec. 3 states "Non-imported and imported PSKs are distinct since their identities are different on the wire." We have two concerns about this statement. First, the statement appears to suggest that if two EPSKs have different identities, then they must have different secret values. But couldn't two EPSKs have the same secret value yet employ different identities for convenience? For example, an endpoint might identify the same EPSK with a domain name in some cases and with an IP address in others. Second, and more fundamentally, the statement assumes that a non-imported EPSK, by definition, cannot be misinterpreted as an imported PSK. But isn't the identifier of a non-imported EPSK just an opaque string? A non-imported EPSK identity could therefore have the same "bits on the wire" as an IPSK identity, if the client and server employ an identifier system that whose encoding happens to coincide with the ImportedIdentity structure defined in the draft. (Moreover, the identifier of a resumption PSK is just an opaque string -- so couldn't this also collide with ImportedIdentity values? Perhaps we are missing something even more fundamental in our reading.) ([draft-dt-tls-external-psk-guidance-01] covers similar issues in its Sec. 6.1.2, "PSK Identity Collisions.") b. Attack impact. If it's possible for an opaque identifier for a non-imported EPSK identity to have the same encoding as an ImportedIdentity value, then how does the server recognize unambiguously that the opaque identifier is intended to be an imported identity? The server could take an optimistic approach and assume that an identifier that meets the ImportedIdentity syntax is probably an imported identity, and run the code path for imported identities first. If that path fails, however -- either because the server doesn't accept the EPSK or associated parameters, or because the binder value is incorrect -- then the server may need to run the code path for non-imported identities as a fallback, checking next to see if the opaque string is recognized as an ordinary EPSK identity. But this practice just puts more burden on a server against an attacker who replays (or makes up) the PSKIdentity.identity value: two code paths are exercised for the price of one attempted handshake. c. Mitigations. One way to reduce the burden is to impose a new requirement that the opaque string can only have the ImportedIdentity syntax if the client (or server in the case of hints) indeed intends to use the import mechanism. An ordinary EPSK could have any other value, just not this kind. But this may not be compatible with the installed base, especially with implementations that allow clients and servers to specify arbitrary EPSK identities. (Consider the case where an application adopts the imported identity syntax for the use intended in this draft, and then decides to reuse the syntax for other purposes, including ordinary EPSK identities.) Another way to ensure distinctness is to add a flag that indicates that the PSK identity is an imported identity. But it's not clear where this flag would go, given that the PskIdentity syntax isn't extensible. Perhaps there could be an overall flag indicating that _all PSK identities are imported identities? Or a new extension for imported PSKs? d. Key separation. Note that the foregoing discussion about EPSK identifiers potentially colliding is separate from the question about what happens if an IPSK happens to collide with a non-imported EPSK. The draft handles this effectively with different inputs to the binder derivation ("ext binder" vs. "imp binder"). But this happens after the implementation has already decided whether to interpret the identifier as external or imported. e. Incremental deployment. Section 6 states that " the derived PSK will not be the same [as the underlying EPSK] since the importer differentiates the PSK via the identity, target protocol and target key KDF." However, the next statement does not follow directly: "Thus, PSKs imported for TLS 1.3 are distinct from those used in TLS 1.2, and thereby avoid cross-protocol collisions." Rather, the statement also depends on the requirement in Section 3 that clients (and servers) don't deliberately use EPSKs or IPSKs for other purposes, and the security properties of the KDF that produces the IPSK (which ensures that collisions don't occur accidentally). But there also seems to be an implication in Section 6 that the use of the KDF in the TLS 1.3 importer doesn't conflict with the cryptographic functions used for obtaining the TLS 1.2 pre-master secret. If so, this distinction should be spelled out. Related to this, where Section 3 states, "Clients which import external keys MUST NOT use either the external keys or the derived keys for any other purpose," should "Clients" be "Clients and servers" or simply "Endpoints"? Scott

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  <ins> label to prevent confusion with non-imported PSKs.  Through this interface, importing external PSKs with different identities yields distinct PSK binder keys. </ins> Imported keys do not require negotiation for use since a client and server will not agree upon identities if imported incorrectly. and imported PSKs are distinct since their identities are different on the wire.  See rollout for more details.  <ins> Endpoints which import external keys MUST NOT use either the external </ins> 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- ImportedIdentity.context MUST include the context used to derive the EPSK, if any exists.  For example, ImportedIdentity.context may include information about peer roles or identities to mitigate  <ins> Selfie-style reflection attacks Selfie.  See mitigate-selfie for more </ins> details.  If the EPSK is a key derived from some other protocol or sequence of protocols, ImportedIdentity.context MUST include a channel binding for the deriving protocols RFC5056.


that each PSK only be used with a single hash function.  This was done to simplify protocol analysis.  TLS 1.2 RFC5246, in contrast, has no such requirement, as a PSK may be used with any hash algorithm <del> and the TLS 1.2 PRF.  This means that external PSKs could possibly be re-used in two different contexts with the same hash functions during key derivation.  Moreover, it requires external PSKs to be provisioned for specific hash functions. 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. </del>  2. Imported PSKs are not used as IKM for two different KDFs. <del> Imported PSKs do not collide with existing PSKs used for TLS 1.2 and below. </del> Imported PSKs do not collide with future protocol versions and KDFs.  The PSK Importer does not prevent applications from constructing non- importer PSK identities that collide with imported PSK identities.

The gist of the feedback, as I understood it, was that we made claims that were quite strong. This relaxes the language a bit and draws on RFC8446 for some example text. cc NAME NAME NAME
Hard to pick up the differences here, but I think that I got them.

that each PSK only be used with a single hash function.  This was done to simplify protocol analysis.  TLS 1.2 RFC5246, in contrast, has no such requirement, as a PSK may be used with any hash algorithm  <ins> and the TLS 1.2 PRF.  While there is no known way in which the same external PSK might produce related output in TLS 1.3 and prior versions, only limited analysis has been done.  Applications SHOULD provision separate PSKs for TLS 1.3 and prior versions when possible. To mitigate against any interference, 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 (D)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, that are separate from those used in (D)TLS 1.2 and prior versions.  This expands what would normally have been a single PSK and identity into a set of PSKs and identities. </ins> 2. Imported PSKs are not used as IKM for two different KDFs.  Imported PSKs do not collide with future protocol versions and KDFs. <ins> There is no known interference between the process for computing Imported PSKs from an external PSK and the processing of existing external PSKs used in (D)TLS 1.2 and below.  However, only limited analysis has been done, which is an additional reason why applications SHOULD provision separate PSKs for (D)TLS 1.3 and prior versions when possible, even when the importer interface is used in (D)TLS 1.3. </ins> The PSK Importer does not prevent applications from constructing non- importer PSK identities that collide with imported PSK identities.


that each PSK only be used with a single hash function.  This was done to simplify protocol analysis.  TLS 1.2 RFC5246, in contrast, has no such requirement, as a PSK may be used with any hash algorithm <del> and the TLS 1.2 PRF.  While there is no known way in which the same external PSK might produce related output in TLS 1.3 and prior versions, only limited analysis has been done.  Applications SHOULD provision separate PSKs for TLS 1.3 and prior versions when possible. </del>  To mitigate against any interference, this document specifies a PSK Importer interface by which external PSKs may be imported and <del> subsequently bound to a specific KDF and hash function for use in (D)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, that are separate from those used in (D)TLS 1.2 and prior versions.  This expands what would normally have been a single PSK and identity into a set of PSKs and identities. </del>  2. Target KDF: The KDF for which a PSK is imported for use. Imported PSK (IPSK): A PSK derived from an EPSK, External <del> Identity, optional context string, and target protocol and KDF. </del>  Imported Identity: A sequence of bytes used to identify an IPSK. protocol "target_protocol" and KDF "target_kdf", the importer constructs an ImportedIdentity structure as follows: <del> The list of "target_kdf" values is maintained by IANA as described in IANA.  External PSKs MUST NOT be imported for (D)TLS 1.2 or prior versions.  See rollout for discussion on how imported PSKs for TLS 1.3 and non-imported PSKs for earlier versions co-exist for incremental deployment. </del>  ImportedIdentity.context MUST include the context used to derive the EPSK, if any exists.  For example, ImportedIdentity.context may Selfie-style reflection attacks Selfie.  See mitigate-selfie for more details.  If the EPSK is a key derived from some other protocol or sequence of protocols, ImportedIdentity.context MUST include a <del> channel binding for the deriving protocols RFC5056. </del>  ImportedIdentity.target_protocol MUST be the (D)TLS protocol version for which the PSK is being imported.  For example, TLS 1.3 RFC8446 <del> 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>  Given an ImportedIdentity and corresponding EPSK with base key "epsk", an Imported PSK IPSK with base key "ipskx" is computed as The hash function used for HKDF RFC5869 is that which is associated with the EPSK.  It is not the hash function associated with ImportedIdentity.target_kdf.  If no hash function is specified, <del> SHA-256 MUST be used.  Diversifying EPSK by </del>  ImportedIdentity.target_kdf ensures that an IPSK is only used as input keying material to at most one KDF, thus satisfying the requirements in RFC8446.  See security-considerations for more if TLS_AES_128_GCM_SHA256 and TLS_CHACHA20_POLY1305_SHA256 are supported, only one derived key is necessary. <del> 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 </del>  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, <del> that means ALPN, QUIC transport parameters (if used for QUIC), etc., must be provisioned alongside these EPSKs. </del>  4.2. 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 does not preclude endpoints from using non-imported PSKs for TLS 1.2. <del> Indeed, this is necessary for incremental deployment. </del>  7. external PSKs used in (D)TLS 1.2 and below.  However, only limited analysis has been done, which is an additional reason why applications SHOULD provision separate PSKs for (D)TLS 1.3 and prior <del> versions when possible, even when the importer interface is used in (D)TLS 1.3. </del>  The PSK Importer does not prevent applications from constructing non- importer PSK identities that collide with imported PSK identities.

, and . cc NAME
Reviewer: Al Morton Review result: Has Nits OPS-DIR Review of: Importing External PSKs for TLS draft-ietf-tls-external-psk-importer-05 Note that Brian Carpenter provided a useful review for GEN-ART, far beyond general questions. Brian's comments on Section 6, Incremental Deployment, are relevant to operational considerations, which are the focus of this review. The draft provides a useful capability and considers possible issues stemming from interaction with (D)TLS 1.2. There are some implementations and other parties are interested. Nits: Intro:not expanded on first use PRF KDF Terminology: one-too-many "and" in: ... Imported PSK (IPSK): A PSK derived from an EPSK, External Identity, optional context string, and target protocol and KDF.
Nits in the introduction are also listed in Roman's review. section 3.1 should be updated.
Document: draft-ietf-tls-external-psk-importer-05 Reviewer: Brian Carpenter Review Date: 2020-10-07 IETF LC End Date: 2020-10-15 IESG Telechat date: Summary: Ready with issues Issues: >1. Introduction I think that "when possible" could easily be used as a loophole by a lazy implementer. ("Impossible, because I'd have to refactor my code.") Since presumably this rule is to avoid all risk of a "related output" cryptanalytic vulnerability, why weaken the RFC2119 definition of SHOULD? The formal definition of SHOULD is stronger, with "the full implications must be understood and carefully weighed before choosing a different course." So I suggest simply deleting "when possible". >6. Incremental Deployment I read this three times and I have to ask whether "TLS 1.2" is really what you want in the penultimate line. Nits: >4.1. External PSK Diversification ... As far as I can tell, [QUIC] doesn't specify this, but draft-ietf-quic-tls does specify that QUICv1 uses TLS1.3. So the phrasing is a bit misleading. Maybe: For example, TLS 1.3 [RFC8446] uses 0x0304, which will therefore also be used by QUICv1 [QUIC-TLS]. Are all the RFC2119 terms capitalised when required? For example, there are lower case 'may' and 'must' in the last paragraph of section 4.1 (External PSK Diversification). I couldn't determine whether they were intended to be normative.
Section 1. Editorial. Expand acronym on first use: -- s/TLS 1.2 PRF/TLS 1.2 Pseudorandom Function (PRF)/ -- s/KDF/Key Derivation Function (KDF)/ Section 1. Editorial. Since the text says "... this document specifies a PSK Importer interface ... for use in D(TLS 1.3)" perhaps the this scoping should also be upfront in the first sentence too: s/TLS 1.3 [RFC8446] supports/(D)TLS 1.3 [RFC8446][ID-DTLS]/ Section 4.1. Editorial. Per "The list of 'targetkdf' ...", other parts of this text refer to elements of struct ImportIdentity with the notation "ImportedIdentity.". Consider s/The list of "targetkdf" values/The list of ImportedIdentity.targetkdf values/ Section 4.1. If the EPSK is a key derived from some other protocol or sequence of protocols, ImportedIdentity.context MUST include a channel binding for the deriving protocols [RFC5056]. To the end of this normative guidance, I'd recommend adding something to the effect of: "The details of this binding will be protocol specific and out of scope in this document". Section 4.1. Per "If no hash function is specified, SHA-256 MUST be used" -- Please provide a reference for SHA-256 (per "... If no hash function is specified, SHA-256 MUST be used"). -- It is likely worth saying that this is the equivalent of HKDFSHA256 (i.e., 0x0001) Section 4.1. Per "EPSKs may be imported before the started of the connection ..." and "EPSKs may also be imported for early data use ..." should be these be a normative MAYs? Section 4.1. Per "Minimally, that means ALPN, QUIC ... must be provisioned alongside these EPSK" -- Please expand ALPN -- should this be a normative MUST? Section 9. Per the columns in the registry: -- Is there a reason why there isn't a Reference column in the registry to capture which specification describes the particular KDF? I think it needs one to eliminate guesswork from the label in "KDF Description" to an algorithm. -- Was a Recommended column (and the associated processed for populating it like a few of the other TLS registries) discussed/considered? Section 9. While it is implied by the label, the text doesn't explicitly say what HKDFSHA256 and SHA384 are (per previous comment about needing a reference).

that each PSK only be used with a single hash function.  This was done to simplify protocol analysis.  TLS 1.2 RFC5246, in contrast, has no such requirement, as a PSK may be used with any hash algorithm  <ins> and the TLS 1.2 pseudorandom function (PRF).  While there is no known way in which the same external PSK might produce related output in TLS 1.3 and prior versions, only limited analysis has been done. Applications SHOULD provision separate PSKs for TLS 1.3 and prior versions. </ins> To mitigate against any interference, this document specifies a PSK Importer interface by which external PSKs may be imported and  <ins> subsequently bound to a specific key derivation function (KDF) and hash function for use in TLS 1.3 RFC8446 and DTLS 1.3 DTLS13.  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, that are separate from those used in (D)TLS 1.2 and prior versions.  This expands what would normally have been a single PSK and identity into a set of PSKs and identities. </ins> 2. Target KDF: The KDF for which a PSK is imported for use. Imported PSK (IPSK): A PSK derived from an EPSK, External  <ins> Identity, optional context string, target protocol, and target KDF. </ins> Imported Identity: A sequence of bytes used to identify an IPSK. protocol "target_protocol" and KDF "target_kdf", the importer constructs an ImportedIdentity structure as follows:  <ins> The list of ImportedIdentity.target_kdf values is maintained by IANA as described in IANA.  External PSKs MUST NOT be imported for (D)TLS 1.2 or prior versions.  See rollout for discussion on how imported PSKs for TLS 1.3 and non-imported PSKs for earlier versions co-exist for incremental deployment. </ins> ImportedIdentity.context MUST include the context used to derive the EPSK, if any exists.  For example, ImportedIdentity.context may Selfie-style reflection attacks Selfie.  See mitigate-selfie for more details.  If the EPSK is a key derived from some other protocol or sequence of protocols, ImportedIdentity.context MUST include a  <ins> channel binding for the deriving protocols RFC5056.  The details of this binding are protocol specific and out of scope for this document. </ins> ImportedIdentity.target_protocol MUST be the (D)TLS protocol version for which the PSK is being imported.  For example, TLS 1.3 RFC8446  <ins> uses 0x0304, which will therefore also be used by QUICv1 QUIC.  Note that this means future versions of TLS will increase the number of PSKs derived from an external PSK. </ins> Given an ImportedIdentity and corresponding EPSK with base key "epsk", an Imported PSK IPSK with base key "ipskx" is computed as The hash function used for HKDF RFC5869 is that which is associated with the EPSK.  It is not the hash function associated with ImportedIdentity.target_kdf.  If no hash function is specified,  <ins> SHA-256 SHA2 MUST be used.  Diversifying EPSK by </ins> ImportedIdentity.target_kdf ensures that an IPSK is only used as input keying material to at most one KDF, thus satisfying the requirements in RFC8446.  See security-considerations for more if TLS_AES_128_GCM_SHA256 and TLS_CHACHA20_POLY1305_SHA256 are supported, only one derived key is necessary.  <ins> 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 </ins> 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,  <ins> that means Application-Layer Protocol Negotiation RFC7301, QUIC transport parameters (if used for QUIC), and any other relevant parameters that are negotiated for early data MUST be provisioned alongside these EPSKs. </ins> 4.2. 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 does not preclude endpoints from using non-imported PSKs for TLS 1.2.  <ins> Indeed, this is necessary for incremental deployment.  Specifically, existing applications using TLS 1.2 with non-imported PSKs can safely enable TLS 1.3 with imported PSKs in clients and servers without interoperability risk. </ins> 7. external PSKs used in (D)TLS 1.2 and below.  However, only limited analysis has been done, which is an additional reason why applications SHOULD provision separate PSKs for (D)TLS 1.3 and prior  <ins> versions, even when the importer interface is used in (D)TLS 1.3. </ins> The PSK Importer does not prevent applications from constructing non- importer PSK identities that collide with imported PSK identities.


PSKs change the PSK binder key derivation label.  In particular, the standard TLS 1.3 PSK binder key computation is defined as follows: <del> Imported PSKs replace the string "ext binder" with "imp binder" when deriving "binder_key".  This means the binder key is computed as follows: </del>  This new label ensures a client and server will negotiate use of an external PSK if and only if (a) both endpoints import the PSK or (b)

It's a bit confusing to use the term "replace" when discussing the string used for derivation. The text only references one of the strings used for derivation where the diagram references two.

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 use the string "imp binder" rather than "ext binder" or "res binder" when deriving "binder_key".  This means the binder key is computed as follows: </ins> This new label ensures a client and server will negotiate use of an external PSK if and only if (a) both endpoints import the PSK or (b)


1. <del> TLS 1.3 RFC8446 supports pre-shared key (PSK) resumption, wherein </del>  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 <del> done to simplify protocol analysis.  TLS 1.2, in contrast, has no such requirement, as a PSK may be used with any hash algorithm and the TLS 1.2 PRF.  This means that external PSKs could possibly be re- used in two different contexts with the same hash functions during </del>  key derivation.  Moreover, it requires external PSKs to be provisioned for specific hash functions. Imported keys do not require negotiation for use, as a client and server will not agree upon identities if not imported correctly. Thus, importers induce no protocol changes with the exception of <del> expanding the set of PSK identities sent on the wire. </del>  3.1. 5.  If a client or server wish to deprecate a hash function and no longer use it for TLS 1.3, they may remove this hash function from the set of hashes used during while importing keys.  This does not affect the KDF operation used to derive concrete PSKs. <del> 6. </del>  Recall that TLS 1.2 permits computing the TLS PRF with any hash algorithm and PSK.  Thus, an external PSK may be used with the same However, critically, the derived PSK will not be the same since the importer differentiates the PSK via the identity and hash function. Thus, PSKs imported for TLS 1.3 are distinct from those used in TLS <del> 1.2, and thereby avoid cross-protocol collisions. </del>  <del> 7. </del>  This is a WIP draft and has not yet seen significant security analysis. <del> 8. </del>  DISCLAIMER: This section contains a sketch of a design for protecting external PSK identities.  It is not meant to be implementable as precompute these obfuscated identities to ease the burden of trial decryption. <del> 9. </del>  This document makes no IANA requests.

Importantly, add details regarding incremental deployment, and clarify label values for non TCP-based variants of TLS.
Fixed in .
Fixed in .
Both endpoints must adopt importers for interoperability's sake.
Fixed in .
"TLS 1.3 supports pre-shared key s/resumption/authentication"
Fixed in .

1.  <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  <ins> done to simplify protocol analysis.  TLS 1.2 RFC5246, in contrast, has no such requirement, as a PSK may be used with any hash algorithm and the TLS 1.2 PRF.  This means that external PSKs could possibly be re-used in two different contexts with the same hash functions during </ins> key derivation.  Moreover, it requires external PSKs to be provisioned for specific hash functions. Imported keys do not require negotiation for use, as a client and server will not agree upon identities if not imported correctly. Thus, importers induce no protocol changes with the exception of  <ins> expanding the set of PSK identities sent on the wire.  Endpoints may incrementally deploy PSK importer support by offering non-imported keys for TLS versions prior to TLS 1.3.  (Negotiation and use of imported PSKs requires both endpoints support the importer API described herein.) </ins> 3.1. 5. <ins> For clarity, the following table specifies PSK importer labels for varying instances of the TLS handshake. 6. </ins> If a client or server wish to deprecate a hash function and no longer use it for TLS 1.3, they may remove this hash function from the set of hashes used during while importing keys.  This does not affect the KDF operation used to derive concrete PSKs.  <ins> 7. </ins> Recall that TLS 1.2 permits computing the TLS PRF with any hash algorithm and PSK.  Thus, an external PSK may be used with the same However, critically, the derived PSK will not be the same since the importer differentiates the PSK via the identity and hash function. Thus, PSKs imported for TLS 1.3 are distinct from those used in TLS  <ins> 1.2, and thereby avoid cross-protocol collisions.  Note that this does not preclude endpoints from using non-imported PSKs for TLS 1.2. Indeed, this is necessary for incremental deployment. </ins>  <ins> 8. </ins> This is a WIP draft and has not yet seen significant security analysis.  <ins> 9. </ins> DISCLAIMER: This section contains a sketch of a design for protecting external PSK identities.  It is not meant to be implementable as precompute these obfuscated identities to ease the burden of trial decryption.  <ins> 10. </ins> This document makes no IANA requests.


1. <del> The TLS protocol RFC8466 includes several points of extensibility, </del>  including the list of cipher suites and the list of extensions.  The values in these lists identify implementation capabilities.  TLS follows a model where one side, usually the client, advertises consistent pattern while avoiding collisions with any existing applicable registries in TLS. <del> The following values are reserved as GREASE values for cipher suites: </del>  {TBD} {0x0A,0x0A} {TBD} {0x1A,0x1A} {TBD} 0xC5 {TBD} 0xE4 <del> Finally, this document reserves all ALPN identifiers RFC7301 beginning with the prefix "ignore/".  This corresponds to the seven- octet prefix: 0x69, 0x67, 0x6e, 0x6f, 0x72, 0x65, 0x2f. </del> 3. Most extension points in TLS are offered by the client and selected cipher suite interoperability testing and it's suggested that IANA use these values for assignment. <del> [[TODO: How do I write IANA instructions to reserve all ALPN identifiers that begin with "ignore/"?  Perhaps it would be better to reserve a concrete handful of identifiers instead.]] </del>  7.

Also fix the build. Some references were a little off.
A possible privacy consideration for Grease Implementations that do not select grease values at random my open up the opportunity for the fingerprinting of implementations and may impact the privacy of users.
Ah yes, good point. That should be pointed out explicitly. Will put together a PR after Thanksgiving (and after is merged since it contains a build fix and I'm not sure how PRs depending on pieces of other PRs works :-) ).
NAME NAME NAME unless there are any objections once we get this issue squared away I'll go ahead and issue a WGLC. It's been marinating long enough.
Should be fixed by .
THere's a TODO for reserving "ignore/" ALPN.
NAME are you thinking: Protocol: ignore/1 Identification: 0x69 0x67 0x6e 0x6f 0x72 0x65 0x31 Reference: (This document) ... Protocol: ignore/10 Identification: 0x69 0x67 0x6e 0x6f 0x72 0x65 0x31 0x30 Reference: (This document)
I didn't have a particularly clear picture in my mind, TBH. We're not sending fake ALPN values or anything right now. ignore/[numbers] seems fine. Or maybe it would be better to drop the "ignore/" thing and just use the same two-byte pattern. "ignore/" makes it look like you should do a prefix check, which isn't really what we want...
NAME NAME NAME NAME NAME NAME PTAL because I think this is really the last "technical" point remaining.
NAME not sure what you mean by two-byte pattern. You mean things like "qz" "db" "r$" etc? If so, I agree that that is better.
Yeah. For the sake of consistency, I figure it could just be the same old 0x?a, 0x?a pattern that everything else does. (Though they then wouldn't be ASCII. Could pick some pattern that's ASCII if that's preferred.)
i think two random bytes is good (testing for non-ascii seems greasy as well)
I also prefer the two-byte pattern, since ignore/ might indicate to people that this is somehow meant to be special-cased.
Two bytes it is! URL

1.  <ins> The TLS protocol RFC8446 includes several points of extensibility, </ins> including the list of cipher suites and the list of extensions.  The values in these lists identify implementation capabilities.  TLS follows a model where one side, usually the client, advertises consistent pattern while avoiding collisions with any existing applicable registries in TLS.  <ins> The following values are reserved as GREASE values for cipher suites and ALPN identifiers: </ins> {TBD} {0x0A,0x0A} {TBD} {0x1A,0x1A} {TBD} 0xC5 {TBD} 0xE4  3. Most extension points in TLS are offered by the client and selected cipher suite interoperability testing and it's suggested that IANA use these values for assignment.  <ins> This document updates the TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs registry, available from <https://www.iana.org/assignments/tls-extensiontype-values/tls- extensiontype-values>: </ins> 7.


Adding security considerations for fingerprinting.
This change is to address
NAME if you fix this nit up then NAME can merge and we can WGLC this draft.
A possible privacy consideration for Grease Implementations that do not select grease values at random my open up the opportunity for the fingerprinting of implementations and may impact the privacy of users.
Ah yes, good point. That should be pointed out explicitly. Will put together a PR after Thanksgiving (and after is merged since it contains a build fix and I'm not sure how PRs depending on pieces of other PRs works :-) ).
NAME NAME NAME unless there are any objections once we get this issue squared away I'll go ahead and issue a WGLC. It's been marinating long enough.
Should be fixed by .

silently disable the new feature.  By preventing a class of such interoperability problems, GREASE reduces the need for this kind of fallback. <ins> If an implementation does not select GREASE values at random it is possible it will allow for fingerprinting of the implementation or perhaps even of individual users.  This can result in a negative impact to a user's privacy. </ins>


applicable registries in TLS. The following values are reserved as GREASE values for cipher suites <del> and ALPN identifiers: </del>  {TBD} {0x0A,0x0A} {TBD} {0x1A,0x1A}

The date is wrong and ALPN is missing a citation: Error: Cannot handle a with year different than this year, and no month. Using today's date. Warning: no in targets
(Editorial, I hope. Going ahead and merging this for -02.)

applicable registries in TLS. The following values are reserved as GREASE values for cipher suites  <ins> and ALPN RFC7301 identifiers: </ins> {TBD} {0x0A,0x0A} {TBD} {0x1A,0x1A}


In this document, we use the term "(D)TLS" to refer to registries that apply to both TLS and DTLS. <del> Add "TLS" to registries' names for consistency with other TLS- related registries. </del>  Change the IANA registry policy RFC5226 for the TLS ExtensionType Values, TLS Cipher Suite, and TLS ClientCertificateType Identifiers registries.  These changes register a small part of these code spaces for experimentation and private use. <del> Add the designated expert intructions as a note to the TLS ExtensionType Values, TLS Cipher Suite, and TLS ClientCertificateType Identifiers registries to inform users of the registry. </del>  Add notes to indicate whether an extension, certain values of an extension, or an entire registry is only applicable pre-(D)TLS Add missing entry to the TLS Alert Registry for the no_application_protocol alert defined in  This document proposes no changes to the registration policies for TLS Alert I-D.ietf-tls-tls13, TLS ContentType I-D.ietf-tls-tls13, TLS HandshakeType, I-D.ietf-tls-tls13 and TLS Certificate Status Types

Need to update summary to, at a minimum, reflect that the following is now in the draft: Added "Recommended" column to TLS ExtensionType Values, TLS Cipher Suite, and TLS Exporters registries to clearly indicate which values are specified in IETF Standards Track documents.

In this document, we use the term "(D)TLS" to refer to registries that apply to both TLS and DTLS.  <ins> Add "TLS" to registries' names for consistency amongst TLS-related registries. </ins> Change the IANA registry policy RFC5226 for the TLS ExtensionType Values, TLS Cipher Suite, and TLS ClientCertificateType Identifiers registries.  These changes register a small part of these code spaces for experimentation and private use.  <ins> Add designated expert intructions as notes in the TLS ExtensionType Values, TLS Cipher Suite, TLS ClientCertificateType Identifiers, and TLS Exporter Label registries to inform users about what to expect from the designated expert. </ins> Add notes to indicate whether an extension, certain values of an extension, or an entire registry is only applicable pre-(D)TLS Add missing entry to the TLS Alert Registry for the no_application_protocol alert defined in <ins> Added "Recommended" column to TLS ExtensionType Values, TLS Cipher Suite, and TLS Exporters Label registries.  Initial values marked "Yes" are specified in IETF Standards Track documents; all others are marked "No".  This new column is intened to alter the incorrect perception that getting a code point somehow legitimizes the extesion, cipher suite/algorithm, or exporter. </ins> This document proposes no changes to the registration policies for TLS Alert I-D.ietf-tls-tls13, TLS ContentType I-D.ietf-tls-tls13, TLS HandshakeType, I-D.ietf-tls-tls13 and TLS Certificate Status Types


Identifiers registries.  These changes register a small part of these code spaces for experimentation and private use. <del> Add designated expert intructions as notes in the TLS </del>  ExtensionType Values, TLS Cipher Suite, TLS ClientCertificateType Identifiers, and TLS Exporter Label registries to inform users about what to expect from the designated expert. Added "Recommended" column to TLS ExtensionType Values, TLS Cipher Suite, and TLS Exporters Label registries.  Initial values marked "Yes" are specified in IETF Standards Track documents; all others <del> are marked "No".  This new column is intened to alter the </del>  incorrect perception that getting a code point somehow legitimizes <del> the extesion, cipher suite/algorithm, or exporter. </del>  This document proposes no changes to the registration policies for TLS Alert I-D.ietf-tls-tls13, TLS ContentType I-D.ietf-tls-tls13, TLS cryptographic standpoint. Note(3): The designated expert RFC5226 only ensures that the <del> specification is publically available. </del>  7. Add the following: Note: The designated expert RFC5226 only ensures that the <del> specification is publically available. </del>  8. document RFC5226 is required to register an extension with the value "Yes".  11. IANA is to add the following entry to the TLS Alert Registry (the

Added the guidelines from RFC 5705
Need to add designated expert instructions for exporters like we did for ExtensionType, Cipher Suite, and ClientCertificateType Identifiers registries.
Also addressed by .

Identifiers registries.  These changes register a small part of these code spaces for experimentation and private use.  <ins> Add designated expert instructions as notes in the TLS </ins> ExtensionType Values, TLS Cipher Suite, TLS ClientCertificateType Identifiers, and TLS Exporter Label registries to inform users about what to expect from the designated expert. Added "Recommended" column to TLS ExtensionType Values, TLS Cipher Suite, and TLS Exporters Label registries.  Initial values marked "Yes" are specified in IETF Standards Track documents; all others  <ins> are marked "No".  This new column is intended to alter the </ins> incorrect perception that getting a code point somehow legitimizes  <ins> the extension, cipher suite/algorithm, or exporter. </ins> This document proposes no changes to the registration policies for TLS Alert I-D.ietf-tls-tls13, TLS ContentType I-D.ietf-tls-tls13, TLS cryptographic standpoint. Note(3): The designated expert RFC5226 only ensures that the  <ins> specification is publicly available. </ins> 7. Add the following: Note: The designated expert RFC5226 only ensures that the  <ins> specification is publicly available. </ins> 8. document RFC5226 is required to register an extension with the value "Yes". <ins> IANA is also to add the following note: </ins> 11. IANA is to add the following entry to the TLS Alert Registry (the


promotes those 4 cipher suites to standards track (see TO-DO insert reference).  The cipher suites that follow are standards track ephemeral pre- shared key cipher suites which are available in TLS 1.2.  RFC6655 is inconsistent with respect to the ordering of components within PSK

Adding instructions for the RFC editor to delete the sentence that notes the algorithms defined in RFC 5289 as these algorithms will be standards track at or before the time this draft gets to the RFC editor.

promotes those 4 cipher suites to standards track (see TO-DO insert reference). <ins> RFC EDITOR: Please delete the sentence beginning with "The notable exception ..." after RFC 5289 has been promoted to Proposed Standard. </ins> The cipher suites that follow are standards track ephemeral pre- shared key cipher suites which are available in TLS 1.2.  RFC6655 is inconsistent with respect to the ordering of components within PSK


Add a "Recommended" column to the cipher suite registry.  The cipher suites that follow in the two tables are marked as "Yes". <del> All other cipher suites are marked as "No". </del>  The cipher suites that follow are standards track server- authenticated (and optionally client-authenticated) cipher suites

Addresses .
Also addresses .
LGTM
We need to update the registry's reference to point to this document if we require new CS definitions to indicate whether the Recommended column is Yes or No (see ).
The cipher suite "recommended" column needs to include something along the line of the following: Future cipher suites MUST define the value of the Recommended column. A Standards Track document [RFC5226] is required to register a cipher suite with the value “Yes”.

Add a "Recommended" column to the cipher suite registry.  The cipher suites that follow in the two tables are marked as "Yes".  <ins> All other cipher suites are marked as "No".  Future cipher suites MUST define the value of the Recommended column.  A Standards Track document RFC5226 is required to register a cipher suite with the value "Yes". Update the reference for this registry to also point to this document. </ins> The cipher suites that follow are standards track server- authenticated (and optionally client-authenticated) cipher suites


no_application_protocol alert defined in RFC7301. Added "Recommended" column to TLS ExtensionType Values, TLS Cipher <del> Suite, and TLS Exporters Label registries.  Initial values marked "Yes" are specified in IETF Standards Track documents; all others are marked "No".  This new column is intended to alter the incorrect perception that getting a code point somehow legitimizes the extension, cipher suite/algorithm, or exporter. </del>  Establish Designated Expert pool rules for Specification Required registries. IETF Review for the last), are appropriate for these one-byte code points because of their scarcity. <del> This document proposes no changes to the EC Curve Type, EC Point Format, and Supported Groups Registries (see I-D.ietf-tls- rfc4492bis). </del> 3. IANA is to update the names of the following registries to add "TLS" 7.  IANA is to update the TLS ClientCertificateType Identifiers registry as follows: Note: The designated expert RFC5226 only ensures that the specification is publicly available. <del> 8. </del>  To align with TLS implementations and to align the naming nomenclature for other Handshake message types, IANA is to rename this document in the Reference column for entry 4 in the TLS HandshakeType registry. <del> 9. </del>  The nomenclature for the registry entries in the TLS ExtensionType Values registry correspond to the presentation language field name consistently identified in the registry, IANA is to rename entry 35 to "session_ticket (renamed from "SessionTicket TLS")". <del> 10. </del>  IANA is to add the following note to the TLS Exporter Label Registry: IANA is also to add the following note: <del> 11. </del>  IANA is to add the following entry to the TLS Alert Registry (the entry was omitted from the IANA instructions in RFC7301): <del> 12. </del>  To make it clear that (D)TLS 1.3 has orphaned certain extensions (i.e., they are only applicable to version of (D)TLS prior to 1.3), IANA is to add the following to the TLS ExtensionType Values registry: <del> 13. </del>  To make it clear that (D)TLS 1.3 has orphaned certain registries (i.e., they are only applicable to version of (D)TLS protocol TLS Hash Algorithm RFC5246 and TLS SignatureAlgorithm registries to also refer to this document. <del> 14. </del>  Specification Required RFC5226 registry requests are registered after a three-week review period on the (tbd but maybe tls-reg- Expert, that Expert SHOULD defer to the judgment of the other Experts. <del> 15. </del>  The authors are fairly certain that there are no security considerations for this document. <del> 16. </del>  This document is entirely about changes to TLS-related IANA registries.

"Supported Groups" also needed a "Recommended" column.
NAME We've also got FF DHE groups in this registry. Got a feeling for which should be "Yes"?
Much like the ciphers we need to add a "recommended" column for curves/groups. Adding this column was suggested during review of 4492bis.

no_application_protocol alert defined in RFC7301. Added "Recommended" column to TLS ExtensionType Values, TLS Cipher  <ins> Suite, TLS Supported Groups, and TLS Exporters Label registries. Initial values marked "Yes" are specified in IETF Standards Track documents; all others are marked "No".  This new column is intended to alter the incorrect perception that getting a code point somehow legitimizes the extension, cipher suite/algorithm, or exporter. </ins> Establish Designated Expert pool rules for Specification Required registries. IETF Review for the last), are appropriate for these one-byte code points because of their scarcity.  3. IANA is to update the names of the following registries to add "TLS" 7. <ins> Add a "Recommended" column with a "Yes" for secp256r1, secp384r1, x25519, and x448 while all others are "No".  These "Yes" groups are taken from Standards Track RFCs.  Not all groups from I-D.ietf-tls- rfc4492bis, which is standards track, are not marked as "Yes"; these groups apply to TLS 1.3 I-D.ietf-tls-tls13 and previous versions of TLS I-D.ietf-tls-tls13.  A Standards Track document RFC5226 is required to register an entry with the value "Yes". 8. </ins> IANA is to update the TLS ClientCertificateType Identifiers registry as follows: Note: The designated expert RFC5226 only ensures that the specification is publicly available.  <ins> 9. </ins> To align with TLS implementations and to align the naming nomenclature for other Handshake message types, IANA is to rename this document in the Reference column for entry 4 in the TLS HandshakeType registry.  <ins> 10. </ins> The nomenclature for the registry entries in the TLS ExtensionType Values registry correspond to the presentation language field name consistently identified in the registry, IANA is to rename entry 35 to "session_ticket (renamed from "SessionTicket TLS")".  <ins> 11. </ins> IANA is to add the following note to the TLS Exporter Label Registry: IANA is also to add the following note:  <ins> 12. </ins> IANA is to add the following entry to the TLS Alert Registry (the entry was omitted from the IANA instructions in RFC7301):  <ins> 13. </ins> To make it clear that (D)TLS 1.3 has orphaned certain extensions (i.e., they are only applicable to version of (D)TLS prior to 1.3), IANA is to add the following to the TLS ExtensionType Values registry:  <ins> 14. </ins> To make it clear that (D)TLS 1.3 has orphaned certain registries (i.e., they are only applicable to version of (D)TLS protocol TLS Hash Algorithm RFC5246 and TLS SignatureAlgorithm registries to also refer to this document.  <ins> 15. </ins> Specification Required RFC5226 registry requests are registered after a three-week review period on the (tbd but maybe tls-reg- Expert, that Expert SHOULD defer to the judgment of the other Experts.  <ins> 16. </ins> The authors are fairly certain that there are no security considerations for this document.  <ins> 17. </ins> This document is entirely about changes to TLS-related IANA registries.


TLS HashAlgorithm RFC5246 and TLS SignatureAlgorithm registries to also refer to this document.  16. Specification Required RFC5226 registry requests are registered after

This text is taken from TLS1.3. The point is to reserve the remaining values as a really big hint to "not look here, go look over there".

TLS HashAlgorithm RFC5246 and TLS SignatureAlgorithm registries to also refer to this document. <ins> IANA [SHALL update/has updated] the TLS HashAlgorithm Registry to list values 7-223 as "Reserved" and the TLS SignatureAlgorithm registry to list values 4-223 as "Reserved". </ins> 16. Specification Required RFC5226 registry requests are registered after


Add the following: <del> Note: The designated expert RFC5226 only ensures that the specification is publicly available. </del>  10. IANA is to add the following note to the TLS Exporter Label Registry:  IANA is to also to add a "Recommended" column to the TLS Exporter Label registry.  The table that follows has been generated by marking Standards Track RFCs as "Yes" and all others as "No".  Future IANA is also to add the following note:  12. IANA is to add the following entry to the TLS Alert Registry (the IANA is to add the following to the TLS ExtensionType Values registry:  15. To make it clear that (D)TLS 1.3 has orphaned certain registries Add the following to the TLS Compression Method Identifiers registry RFC3749: <del> Note: Value 0 (NULL) is the only value in this registry applicable to (D)TLS protocol version 1.3 or later. </del>  Add the following to the TLS HashAlgorithm RFC5246 and TLS SignatureAlgorithm registries RFC5246: <del> Note: The values in this registry are only applicable to (D)TLS protocol versions prior to 1.3. </del>  Update the "References" in the TLS Compression Method Identifiers, TLS HashAlgorithm RFC5246 and TLS SignatureAlgorithm registries to

I'm fairly sure that I sent these in already. Was there a regression? The current build has lines that are insanely long. This corrects that (and removes a warning caused by an open bracket).
I thought I fixed it, but I guess I'd missed it. I've got a fairly long rewrite that I hope to land early next that I think also addresses these.
Hoping that this is fixed via , which is pretty big set of editorial changes.

Add the following:  <ins> The designated expert RFC5226 only ensures that the specification is publicly available. </ins> 10. IANA is to add the following note to the TLS Exporter Label Registry: <ins> RFC5705 defines keying material exporters for TLS in terms of the TLS PRF.  I-D.ietf-tls-tls13 replaced the PRF with HKDF, thus requiring a new construction.  The exporter interface remains the same, however the value is computed different. </ins> IANA is to also to add a "Recommended" column to the TLS Exporter Label registry.  The table that follows has been generated by marking Standards Track RFCs as "Yes" and all others as "No".  Future IANA is also to add the following note: <ins> The designated expert RFC5226 ensures that the specification is publicly available.  The expert also verifies that the label is a string consisting of printable ASCII characters beginning with "EXPORTER".  IANA MUST also verify that one label is not a prefix of any other label.  For example, labels "key" or "master secretary" are forbidden. </ins> 12. IANA is to add the following entry to the TLS Alert Registry (the IANA is to add the following to the TLS ExtensionType Values registry: <ins> The following extensions are only applicable to (D)TLS protocol vesions prior to 1.3: trusted_ca_keys, truncated_hmac, ec_point_formats, srp, status_request_v2, encrypt_then_mac, extended_master_secret, session_ticket, and renegotiation_info. These are not applicable to DTLS 1.3. </ins> 15. To make it clear that (D)TLS 1.3 has orphaned certain registries Add the following to the TLS Compression Method Identifiers registry RFC3749:  <ins> Value 0 (NULL) is the only value in this registry applicable to (D)TLS protocol version 1.3 or later. </ins> Add the following to the TLS HashAlgorithm RFC5246 and TLS SignatureAlgorithm registries RFC5246:  <ins> The values in this registry are only applicable to (D)TLS protocol versions prior to 1.3. </ins> Update the "References" in the TLS Compression Method Identifiers, TLS HashAlgorithm RFC5246 and TLS SignatureAlgorithm registries to


Abstract <del> This document changes the IANA registry policy for a number of registries related to DTLS and TLS, renames some of the registries for consistency, and adds notes to many of the registries.  As a result, this document updates many RFCs (see updates header). </del>  1. 2. <del> This document requests that IANA make changes to a number of DTLS- and TLS-related IANA registries. </del>  <del> In this document, we use the term "(D)TLS" to refer to registries that apply to both TLS and DTLS. Add "TLS" to registries' names for consistency amongst TLS-related registries. Change the IANA registry policy RFC5226 for the TLS ExtensionType Values, TLS Cipher Suite, and TLS ClientCertificateType Identifiers registries.  These changes register a small part of these code spaces for experimentation and private use. Add designated expert instructions as notes in the TLS ExtensionType Values, TLS Cipher Suite, TLS ClientCertificateType Identifiers, and TLS Exporter Label registries to inform users about what to expect from the designated expert. Add notes to indicate whether an extension, certain values of an extension, or an entire registry is only applicable pre-(D)TLS 1.3. Rename the NewSessionTicket TLS HandshakeType message registry entry RFC5077 to new_session_ticket to match the naming nomenclature for the other Handshake type names and to match with existing implementations. Rename the SessionTicket TLS extension to session_ticket to match the nomenclature for the other extensions' names. Add missing entry to the TLS Alert Registry for the no_application_protocol alert defined in RFC7301. Added "Recommended" column to TLS ExtensionType Values, TLS Cipher Suite, TLS Certificate Types, TLS Supported Groups, and TLS Exporters Label registries.  Initial values marked "Yes" are specified in IETF Standards Track documents; all others are marked "No".  This new column is intended to alter the incorrect perception that getting a code point somehow legitimizes the extension, cipher suite/algorithm, or exporter. Establish Designated Expert pool rules for Specification Required registries. </del>  This document proposes no changes to the registration policies for TLS Alert I-D.ietf-tls-tls13, TLS ContentType I-D.ietf-tls-tls13, TLS <del> HandshakeType, I-D.ietf-tls-tls13 and TLS Certificate Status Types RFC6961; the existing policies (Standards Action for the first three; IETF Review for the last), are appropriate for these one-byte code points because of their scarcity. </del>  3. <del> IANA is to update the names of the following registries to add "TLS" to for consistency with the other TLS-related extensions: </del>  <del> Application-Layer Protocol Negotiation (ALPN) Protocol IDs, </del>  ExtensionType Values, <del> Heartbeat Message Types, </del>  <del> Heartbeat Modes, and </del>  <del> Supported Groups. IANA is also to add a reference to this document for the registry whose names have been updated as a result of the above change.  The remainder of this document will use the registry names with the "TLS" prefix. </del>  4. <del> Many of the TLS-related IANA registries were defined prior to RFC5226 where "IETF Consensus" was used instead of the RFC5226-defined "IETF Review".  To align with the new terminology, IANA is to update to use "IETF Review" in place of "IETF Consensus" in the following registries: </del>  <del> TLS Authorization Data Formats </del>  TLS Supplemental Data Formats (SupplementalDataType) with "IETF Consensus" are undergoing other changes either as a result of this document or I-D.ietf-tls-rfc4492bis.  5. The nomenclature for the registry entries in the TLS ExtensionType Values registry correspond to the presentation language field name except for entry 35.  To ensure that the values in the registry are <del> consistently identified in the registry, IANA is to rename entry 35 to "session_ticket (renamed from "SessionTicket TLS")". </del>  6. <del> IANA is to update the TLS ExtensionType Values registry as follows: </del>  Change the registry policy to: Values with the first byte in the range 0-254 (decimal) are <del> assigned via Specification Required RFC5226.  Values with the first byte 255 (decimal) are reserved for Private Use RFC5226. </del>  <del> Update the "References" to also refer to this document. </del>  Add the following note: <del> Note: Experts are to verify that there is in fact a publicly available standard. </del>  Add a "Recommended" column with the contents as listed below. This table has been generated by marking Standards Track RFCs as "Yes" and all others as "No".  Future extensions MUST define the <del> value of this column.  A Standards Track document RFC5226 is required to register an extension with the value "Yes". </del>  7. <del> IANA is to update the TLS Cipher Suite registry as follows: </del>  <del> Change the registry policy to: </del>  <del> Values with the first byte in the range 0-254 (decimal) are assigned via Specification Required RFC5226.  Values with the first byte 255 (decimal) are reserved for Private Use RFC2434. </del>  <del> Add a "Recommended" column to the cipher suite registry.  The </del>  cipher suites that follow in the two tables are marked as "Yes". All other cipher suites are marked as "No".  Future cipher suites MUST define the value of the Recommended column.  A Standards <del> Track document RFC5226 is required to register a cipher suite with </del>  the value "Yes". <del> Update the reference for this registry to also point to this document. </del>  <del> The cipher suites that follow are standards track server- authenticated (and optionally client-authenticated) cipher suites which are currently available in TLS 1.2.  The notable exception are the ECDHE AES GCM cipher suites which are not yet standards track prior to the publication of this specification, but this document promotes those 4 cipher suites to standards track (see TO-DO insert reference). RFC EDITOR: Please delete the sentence beginning with "The notable exception ..." after RFC 5289 has been promoted to Proposed Standard. </del>  The cipher suites that follow are standards track ephemeral pre- shared key cipher suites which are available in TLS 1.2.  RFC6655 is AES CCM cipher suite names; those names are used here without modification. <del> Add the following: </del>  <del> WARNING: Cryptographic algorithms will be broken or weakened over time.  Blindly implementing cipher suites listed here is not </del>  advised.  Implementers and users need to check that the cryptographic algorithms listed continue to provide the expected level of security. <del> Note(1): Although TLS 1.3 uses the same cipher suite space as previous versions of TLS, TLS 1.3 cipher suites are defined differently, only specifying the symmetric ciphers, and cannot be used for TLS 1.2.  Similarly, TLS 1.2 and lower cipher suites cannot be used with TLS 1.3. </del>  <del> Note(2): Cipher suites marked as "Yes" are those allocated via Standards Track RFCs.  Cipher suites marked as "No" are not; cipher suites marked "No" range from "good" to "bad" from a cryptographic standpoint. </del>  <del> Note(3): The designated expert RFC5226 only ensures that the specification is publicly available. </del>  8. <del> Add a "Recommended" column with a "Yes" for secp256r1, secp384r1, x25519, and x448 while all others are "No".  These "Yes" groups are taken from Standards Track RFCs.  Not all groups from I-D.ietf-tls- rfc4492bis, which is standards track, are not marked as "Yes"; these groups apply to TLS 1.3 I-D.ietf-tls-tls13 and previous versions of TLS I-D.ietf-tls-tls13.  A Standards Track document RFC5226 is </del>  required to register an entry with the value "Yes".  The value 0 (0x0000) is to be marked as reserved. 9. <del> IANA is to update the TLS ClientCertificateType Identifiers registry as follows: Change the registry policy to: </del>  <del> Values in the range 0-223 are assigned via Specification Required RFC5226.  Values 224-255 are reserved for Private Use. </del>  <del> Add the following: </del>  <del> The designated expert RFC5226 only ensures that the specification </del>  is publicly available.  10. To align with TLS implementations and to align the naming <del> nomenclature for other Handshake message types, IANA is to rename entry 4 in the TLS HandshakeType registry to "new_session_ticket (renamed from NewSessionTicket)".  IANA is to also add a reference to this document in the Reference column for entry 4 in the TLS HandshakeType registry. </del>  11. <del> IANA is to add the following note to the TLS Exporter Label Registry: </del>  RFC5705 defines keying material exporters for TLS in terms of the TLS PRF.  I-D.ietf-tls-tls13 replaced the PRF with HKDF, thus requiring a new construction.  The exporter interface remains the same, however the value is computed different. <del> IANA is to also to add a "Recommended" column to the TLS Exporter Label registry.  The table that follows has been generated by marking Standards Track RFCs as "Yes" and all others as "No".  Future exporters MUST define the value of this column.  A Standards Track document RFC5226 is required to register an extension with the value "Yes". </del>  <del> IANA is also to add the following note: </del>  <del> The designated expert RFC5226 ensures that the specification is </del>  publicly available.  The expert also verifies that the label is a string consisting of printable ASCII characters beginning with "EXPORTER".  IANA MUST also verify that one label is not a prefix of any other label.  For example, labels "key" or "master secretary" are forbidden.  12. <del> IANA is to add the following entry to the TLS Alert Registry (the entry was omitted from the IANA instructions in RFC7301): </del>  13. <del> Add a "Recommended" column to the registry.  X.509 and Raw Public Key are "Yes".  All others are "No".  A Standards Track document RFC5226 is required to register a certificate type with the value "Yes". </del>  14. To make it clear that (D)TLS 1.3 has orphaned certain extensions <del> (i.e., they are only applicable to version of (D)TLS prior to 1.3), IANA is to add the following to the TLS ExtensionType Values registry: </del>  The following extensions are only applicable to (D)TLS protocol vesions prior to 1.3: trusted_ca_keys, truncated_hmac, ec_point_formats, srp, status_request_v2, encrypt_then_mac, extended_master_secret, session_ticket, and renegotiation_info. <del> These are not applicable to DTLS 1.3. </del>  15. To make it clear that (D)TLS 1.3 has orphaned certain registries (i.e., they are only applicable to version of (D)TLS protocol <del> versions prior to 1.3), IANA is to: </del>  <del> Add the following to the TLS Compression Method Identifiers registry RFC3749: </del>  Value 0 (NULL) is the only value in this registry applicable to (D)TLS protocol version 1.3 or later. <del> Add the following to the TLS HashAlgorithm RFC5246 and TLS SignatureAlgorithm registries RFC5246: </del>  The values in this registry are only applicable to (D)TLS protocol versions prior to 1.3. <del> Update the "References" in the TLS Compression Method Identifiers, TLS HashAlgorithm RFC5246 and TLS SignatureAlgorithm registries to also refer to this document. </del>  <del> IANA [SHALL update/has updated] the TLS HashAlgorithm Registry to list values 7-223 as "Reserved" and the TLS SignatureAlgorithm registry to list values 4-223 as "Reserved". </del>  16. <del> Specification Required RFC5226 registry requests are registered after </del>  a three-week review period on the (tbd but maybe tls-reg- review@ietf.org) mailing list, on the advice of one or more Designated Experts.  However, to allow for the allocation of values

A pretty major rewrite to incorporate the rationale for changes into individual sections as opposed to having it at the beginning. Also fixing some formatting.

Abstract  <ins> This document describes a number of changes to D/TLS IANA registries that range from adding notes to the registry all the way to changing the registration policy.  These changes were mostly motivated by WG review of the (D)TLS-related registries undertaken as part of the TLS1.3 development process.  This document updates many (D)TLS RFCs (see updates header). </ins> 1. 2.  <ins> This document instructs IANA to make changes to a number of (D)TLS- related IANA registries.  These changes were almost entirely motiviated by the development of TLS1.3 I-D.ietf-tls-tls13. </ins>  <ins> The changes introduced by this document range from simple, e.g., adding notes, to commplex, e.g., changing a registry's registration policy.  Intsead of listing the changes and their rationale in this, the introducotry, section each section provides rationale for the proposed change(s). </ins> This document proposes no changes to the registration policies for TLS Alert I-D.ietf-tls-tls13, TLS ContentType I-D.ietf-tls-tls13, TLS  <ins> HandshakeType I-D.ietf-tls-tls13, and TLS Certificate Status Types RFC6961 registries; the existing policies (Standards Action for the first three; IETF Review for the last), are appropriate for these one-byte code points because of their scarcity. </ins> 3.  <ins> For consistency amongst TLS reqgistries, IANA [SHALL prepend/has prepended] "TLS" to the following registries: </ins>  <ins> Application-Layer Protocol Negotiation (ALPN) Protocol IDs RFC7301, </ins> ExtensionType Values,  <ins> Heartbeat Message Types RFC6520, and </ins>  <ins> Heartbeat Modes RFC6520. </ins>  <ins> IANA [SHALL update/has updated] the reference for these four registires to also refer to this document.  The remainder of this document will use the registry names with the "TLS" prefix. </ins> 4.  <ins> Many of the TLS-related IANA registries were defined prior to RFC8126 where "IETF Consensus" was used instead of the RFC8126-defined "IETF Review".  To align with the new terminology, IANA [SHALL update/has updated] the following registries to use "IETF Review" in place of "IETF Consensus": </ins>  <ins> TLS Authorization Data Formats RFC4680} </ins> TLS Supplemental Data Formats (SupplementalDataType) with "IETF Consensus" are undergoing other changes either as a result of this document or I-D.ietf-tls-rfc4492bis. <ins> IANA [SHALL update/has updated] the reference for these two registries to also refer to this document. </ins> 5. The nomenclature for the registry entries in the TLS ExtensionType Values registry correspond to the presentation language field name except for entry 35.  To ensure that the values in the registry are  <ins> consistently identified in the registry, IANA: [SHALL rename/has renamed] entry 35 to "session_ticket (renamed from "SessionTicket TLS")" RFC5077. [SHALL add/has added] a reference to this document in the Reference column for entry 35. </ins> 6.  <ins> Experience has shown that the IETF Review registry policy for TLS Extensions was too strict.  Based on WG consensus, the decision was taken to change the registration policy to Specification Required RFC8126 while reserving a small part of the code space for experimental and prviate use.  Therefore, IANA [SHALL update/has updated] the TLS ExtensionType Values registry to: </ins> Change the registry policy to: Values with the first byte in the range 0-254 (decimal) are  <ins> assigned via Specification Required RFC8126.  Values with the first byte 255 (decimal) are reserved for Private Use RFC8126. </ins>  <ins> Update the "Reference" to also refer to this document. </ins> Add the following note:  <ins> Experts are to verify that there is in fact a publicly available standard. See expert-pool for additional information about the designated expert pool. Despite wanting to "loosen" the registration policies for TLS Extensions, it is still useful to indicate in the IANA registry which extensions the WG recommends be supported.  Therefore, IANA [SHALL update/has updated] the TLS ExtensionType Values registry to: </ins> Add a "Recommended" column with the contents as listed below. This table has been generated by marking Standards Track RFCs as "Yes" and all others as "No".  Future extensions MUST define the  <ins> value of the Recommended column.  A Standards Track document RFC8126 is required to register an extension with the value "Yes". </ins> 7.  <ins> Experience has shown that the IETF Consensus registry policy for TLS Cipher Suites was too strict.  Based on WG consensus, the decision was taken to change the TLS Cipher Suite registry's registration policy to Specification Required RFC8126 while reserving a small part of the code space for experimental and prviate use.  Therefore, IANA [SHALL update/has updated] the TLS Cipher Suite registry's policy as follows: </ins>  <ins> See expert-pool for additional information about the designated expert pool. </ins>  <ins> The cipher suite registry has grown significantly and will continue to do so.  To better guide those not intimately involved in TLS, IANA [shall update/has updated] the TLS Cipher Suite registry as follows: </ins>  <ins> Add a "Recommended" column to the TLS Cipher Suite registry.  The </ins> cipher suites that follow in the two tables are marked as "Yes". All other cipher suites are marked as "No".  Future cipher suites MUST define the value of the Recommended column.  A Standards  <ins> Track document RFC8126 is required to register a cipher suite with </ins> the value "Yes".  <ins> The cipher suites that follow are standards track server- authenticated (and optionally client-authenticated) cipher suites which are currently available in TLS 1.2. </ins>  <ins> RFC EDITOR: The previous paragraph is for document reviewers and is not meant for the registry. </ins> The cipher suites that follow are standards track ephemeral pre- shared key cipher suites which are available in TLS 1.2.  RFC6655 is AES CCM cipher suite names; those names are used here without modification.  <ins> RFC EDITOR: The previous paragraph is for document reviewers and is not meant for the registry. Despite the following behavior being crazy, experience has shown that some customers use the IANA registry as checklist against which to measure an implemention's completeness and some implementers blindly implement cipher suites.  Therefore, IANA [SHALL add/has added] the following warning to the registry: </ins>  <ins> Cryptographic algorithms and parameters will be broken or weakened over time.  Blindly implementing cipher suites listed here is not </ins> advised.  Implementers and users need to check that the cryptographic algorithms listed continue to provide the expected level of security.  <ins> IANA [SHALL add/has added] the following note to ensure that those that focus on IANA registries are aware that TLS 1.3 I-D.ietf-tls- tls13 uses the same registry but defines ciphers differently: Although TLS 1.3 uses the same cipher suite space as previous versions of TLS, TLS 1.3 cipher suites are defined differently, only specifying the symmetric ciphers, and cannot be used for TLS 1.2.  Similarly, TLS 1.2 and lower cipher suite values cannot be used with TLS 1.3. </ins>  <ins> IANA [SHALL add/has added] the following notes to document the rules for populating the Recommended column: </ins>  <ins> Cipher suites marked as "Yes" are those allocated via Standards Track RFCs.  Cipher suites marked as "No" are not; cipher suites marked "No" range from "good" to "bad" from a cryptographic standpoint. The designated expert RFC8126 only ensures that the specification is publicly available. IANA [SHALL uppdate/has updated] the reference for this registry to also refer to this document. </ins> 8.  <ins> Similar to cipher suites, supported groups have proliferated over time and some use the registry to measure implementations. Therefore, IANA [SHALL add/has added] a "Recommended" column with a "Yes" for secp256r1, secp384r1, x25519, and x448 while all others are "No".  These "Yes" groups are taken from Standards Track RFCs.  Not all groups from I-D.ietf-tls-rfc4492bis, which is standards track, are marked as "Yes"; these groups apply to TLS 1.3 I-D.ietf-tls-tls13 and previous versions of TLS.  Future supported groups MUST define the value of this column.  A Standards Track document RFC8126 is </ins> required to register an entry with the value "Yes". <ins> IANA [SHALL add/has added] the following note: Supported Groups marked as "Yes" are those allocated via Standards Track RFCs.  Supported Groups marked as "No" are not; supported groups marked "No" range from "good" to "bad" from a cryptographic standpoint. Despite the following behavior being crazy, experience has shown that some customers use the IANA registry as checklist against which to measure an implemention's completeness and some implementers blindly implement cipher supported.  Therefore, IANA [SHALL add/has added] the following warning to the registry: Cryptographic algorithms and parameters will be broken or weakened over time.  Blindly implementing cipher suites listed here is not advised.  Implementers and users need to check that the cryptographic algorithms listed continue to provide the expected level of security. IANA [SHALL update/has updated] the reference for this registry to also refer to this document. </ins> The value 0 (0x0000) is to be marked as reserved. 9.  <ins> Experience has shown that the IETF Consensus registry policy for TLS ClientCertificateType Identifers is too strict.  Based on WG consensus, the decision was taken to change registration policy to Specification Required RFC8126 while reserving a small part of the code space for experimental and prviate use.  Therefore, IANA [SHALL update/has updated] the TLS Cipher Suite registry's policy as follows: </ins>  <ins> See expert-pool for additional information about the designated expert pool. </ins>  <ins> IANA [SHALL add/has added] the following notes: </ins>  <ins> The designated expert RFC8126 only ensures that the specification </ins> is publicly available. <ins> ClientCertificateType Identifers marked as "Yes" are those allocated via Standards Track RFCs.  ClientCertificateTypes marked as "No" are not. </ins> 10. To align with TLS implementations and to align the naming  <ins> nomenclature with other Handshake message types, IANA: [SHALL rename/has renamed] entry 4 in the TLS HandshakeType registry to "new_session_ticket (renamed from NewSessionTicket)" RFC5077. [SHALL add/has added] a reference to this document in the Reference column for entry 4 in the TLS HandshakeType registry. </ins> 11.  <ins> To aid those reviewers who start with the IANA registry, IANA [SHALL add/has added]: The following note to the TLS Exporter Label Registry: </ins> RFC5705 defines keying material exporters for TLS in terms of the TLS PRF.  I-D.ietf-tls-tls13 replaced the PRF with HKDF, thus requiring a new construction.  The exporter interface remains the same, however the value is computed different.  <ins> A "Recommended" column to the TLS Exporter Label registry.  The table that follows has been generated by marking Standards Track RFCs as "Yes" and all others as "No".  Future exporters MUST define the value of this column.  A Standards Track document RFC8126 is required to register an extension with the value "Yes". </ins>  <ins> To provide additional information for the designated experts, IANA [SHALL add/has added] the following note: </ins>  <ins> The designated expert RFC8126 ensures that the specification is </ins> publicly available.  The expert also verifies that the label is a string consisting of printable ASCII characters beginning with "EXPORTER".  IANA MUST also verify that one label is not a prefix of any other label.  For example, labels "key" or "master secretary" are forbidden. <ins> Exporters Labels marked as "Yes" are those allocated via Standards Track RFCs.  Exporter Labels marked as "No" are not. IANA [SHALL update/has updated] the reference for this registry to also refer to this document. </ins> 12.  <ins> IANA [SHALL add/has added] the following entry to the TLS Alert Registry; the entry was omitted from the IANA instructions in RFC7301): </ins> 13.  <ins> Experience has shown that the IETF Consensus registry policy for TLS Certificate Types is too strict.  Based on WG consensus, the decision was taken to change registration policy to Specification Required RFC8126 while reserving a small part of the code space for experimental and prviate use.  Therefore, IANA [SHALL add/has added] a "Recommended" column to the registry.  X.509 and Raw Public Key are "Yes".  All others are "No".  A Standards Track document RFC8126 is required to register a certificate type with the value "Yes".  Future Certificate Types MUST define the value of this column.  A Standards Track document RFC8126 is required to register an entry with the value "Yes". See expert-pool for additional information about the designated expert pool. IANA [SHALL add/has added] the following note: Certificate Types marked as "Yes" are those allocated via Standards Track RFCs.  Certificate Types marked as "No" are not. IANA [SHALL update/has updated] the reference for this registry to also refer this document. </ins> 14. To make it clear that (D)TLS 1.3 has orphaned certain extensions  <ins> (i.e., some extensions are only applicable to version of (D)TLS prior to 1.3), IANA [SHALL add/has added] the following note to the TLS ExtensionType Values registry: </ins> The following extensions are only applicable to (D)TLS protocol vesions prior to 1.3: trusted_ca_keys, truncated_hmac, ec_point_formats, srp, status_request_v2, encrypt_then_mac, extended_master_secret, session_ticket, and renegotiation_info.  <ins> These extensions are not applicable to (D)TLS 1.3. </ins> 15. To make it clear that (D)TLS 1.3 has orphaned certain registries (i.e., they are only applicable to version of (D)TLS protocol  <ins> versions prior to 1.3), IANA: </ins>  <ins> [SHALL add/has added] the following to the TLS Compression Method Identifiers registry RFC3749: </ins> Value 0 (NULL) is the only value in this registry applicable to (D)TLS protocol version 1.3 or later.  <ins> [SHALL add/has added] the following to the TLS HashAlgorithm RFC5246 and TLS SignatureAlgorithm registries RFC5246: </ins> The values in this registry are only applicable to (D)TLS protocol versions prior to 1.3.  <ins> [SHALL update/has updated] the "Reference" field in the TLS Compression Method Identifiers, TLS HashAlgorithm and TLS SignatureAlgorithm registries to also refer to this document. </ins>  <ins> [SHALL update/has updated] the TLS HashAlgorithm Registry to list values 7-223 as "Reserved" and the TLS SignatureAlgorithm registry to list values 4-223 as "Reserved". </ins> 16.  <ins> Specification Required RFC8126 registry requests are registered after </ins> a three-week review period on the (tbd but maybe tls-reg- review@ietf.org) mailing list, on the advice of one or more Designated Experts.  However, to allow for the allocation of values


groups marked "No" range from "good" to "bad" from a cryptographic standpoint.  Despite the following behavior being crazy, experience has shown that some customers use the IANA registry as checklist against which to measure an implemention's completeness and some implementers blindly

This adds the designated expert note to supported groups to address issue 32
NAME Just setting this up to auto address .
I believe specification required still involves a designated expert review.
Yes expert review is implied by specification required, but you're right we should also include the same note about the experts just making sure it's publicly available.

groups marked "No" range from "good" to "bad" from a cryptographic standpoint. <ins> The designated expert RFC8126 only ensures that the specification is publicly available. </ins> Despite the following behavior being crazy, experience has shown that some customers use the IANA registry as checklist against which to measure an implemention's completeness and some implementers blindly


<del> D/TLS IANA Registry Updates </del>  draft-ietf-tls-iana-registry-updates-latest Abstract <del> This document describes a number of changes to D/TLS IANA registries </del>  that range from adding notes to the registry all the way to changing the registration policy.  These changes were mostly motivated by WG review of the (D)TLS-related registries undertaken as part of the

This changes the title to remove the D/TLS.
It seems that we use D/TLS and (D)TLS interchangeably throughout the document. It should use one of these and the title should probably be something like "IANA Registry Updates for TLS and DTLS"

<ins> IANA Registry Updates for TLS and DTLS </ins> draft-ietf-tls-iana-registry-updates-latest Abstract  <ins> This document describes a number of changes to (D)TLS IANA registries </ins> that range from adding notes to the registry all the way to changing the registration policy.  These changes were mostly motivated by WG review of the (D)TLS-related registries undertaken as part of the


values 7-223 as "Reserved" and the TLS SignatureAlgorithm registry to list values 4-223 as "Reserved".  16. Specification Required RFC8126 registry requests are registered after

Addresses .
MT suggested that we add the same warnings we have for cipher suites and named groups to all crypto-related registries. The two remaining crypt-related registries are HashAlgorithm and SignatureAlgorithm and both are being orphaned. Despite the fact they are being orphaned we should still add similar text. NAME Are there any others that should include the warning?
merged

values 7-223 as "Reserved" and the TLS SignatureAlgorithm registry to list values 4-223 as "Reserved". <ins> Despite the fact that the HashAlgorithm and SignarureAlgorithm registries are orphaned, it is still import to warn implementers of pre-TLS1.3 implmentations about the dangers of blinding implementing cryptographic algorithms.  Therefore, IANA [SHALL add/has added] the following warning to the HashAlgorithm and SignatureAlgorithm: WARNING: Cryptographic algorithms and parameters will be broken or weakened over time.  Blindly implementing cipher suites listed here is not advised.  Implementers and users need to check that the cryptographic algorithms listed continue to provide the expected level of security. </ins> 16. Specification Required RFC8126 registry requests are registered after


17. <del> The authors are fairly certain that there are no security considerations for this document. </del>  18.

Possibly addresses .
We probably need to say something more in the security considerations. What springs to mind first is the implications of relaxing to specification required for cipher suites and named groups. There must be others.

17.  <ins> The change to Specification Required from IETF Review lowers the amount of review provided by the WG for cipher suites and supported groups.  This change reflects reality in that the WG essentially provided no cryptographic review of the cipher suites or supported groups.  This was espcecially true of national cipher suites. </ins> 18.


amount of review provided by the WG for cipher suites and supported groups.  This change reflects reality in that the WG essentially provided no cryptographic review of the cipher suites or supported <del> groups.  This was espcecially true of national cipher suites. </del>  18.

This fixes a typo in the security considerations section and adds some additional text.
We probably need to say something more in the security considerations. What springs to mind first is the implications of relaxing to specification required for cipher suites and named groups. There must be others.

amount of review provided by the WG for cipher suites and supported groups.  This change reflects reality in that the WG essentially provided no cryptographic review of the cipher suites or supported  <ins> groups.  This was especially true of national cipher suites. Recommended algorithms regarded as secure for general use at the time of registration, however, cryptographic algorithms and parameters will be broken or weakened over time.  It is possible that the recommended status in the registry lags behind the most recent advances in cryptanalysis.  Implementers and users need to check that the cryptographic algorithms listed continue to provide the expected level of security. </ins> 18.