(*) indicates changes to the wire protocol.  draft-04 Add support for client certificates. The signature algorithm of the credential key pair, where the type SignatureScheme is as defined in RFC8446.  This is expected to be <del> the same as CertificateVerify.algorithm sent by the server. </del>  The credential's public key, a DER-encoded X690 SubjectPublicKeyInfo as defined in RFC5280. DelegatedCredential.cred.valid_time. Verify that expected_cert_verify_algorithm matches the scheme <del> indicated in the peer's CertificateVerify message. </del>  Verify that the end-entity certificate satisfies the conditions in certificate-requirements.

Forbid PKC15 in DCs. Should fix URL Recording the consensus here: URL
TLS 1.3 prohibits the use of PKCSv1.5 signatures, but this doesn't really say anything about the situation. A question came up about it. It might help to be explicit.
We had some questions about what to do with , which I think all roll up into a different question: what to do about an RSA SPKI. I suspect that RSA isn't going to be part of common configurations, but implementations could still implement this. If someone offers and a PKCSv1.5 SPKI, is it OK? It seems like it should be by the terms of the spec, but if we require PSS support, why not simply mandate the use of and a PSS SPKI instead? This has the effect of carrying the constraints on scheme in the SPKI directly, which actually makes the signature scheme redundant (I think), which is nice. The downside is that generating a PSS SPKI is less simple; I had to write custom code for that case. Narrowing the SPKI to PSS would be nice if people were willing to accept the constraints (a small increase in size for the SPKI; code complexity).
By PKCSv1.5 SPKI do you mean an rsaEncryption OID in the certificate?
If I'm reading URL correctly, any rsaEncryption oids for the AlgorithmIdentifier do not restrict the signing algorithm for the RSA key. So I believe it is okay. Currently most people's rsa certs are signed with rsaEncryptionWithSha256, so people mostly end up using rsapssrsaesha256. I don't think CA's support generation of pure PSS oids yet fully, so it might be a deployment issue if we enforce a constraint of using rsapsspsssha256.
I'm not talking about the certificate. As you say, most certificates issued by CAs will use an rsaEncryption OID. I'm talking specifically about the SPKI we put in the delegated credential. is the code in NSS that creates the SPKI, which I imagine other stacks will have similar constructs for. My guess is that anyone who just calls the "public key to SPKI" function will not get a PSS SPKI (as defined in ) that has the id-RSASSA-PSS OID and associated RSASSA-PSS-params.
Oh I see. Ya That’s a very interesting question. I have a feeling that treating the constraints differently between Certs and dcs might add more unknown complexities. For example if a clients pki library can only deal with rsae for Certs but its ssl library can deal with rsae (for some reason) the cert sig Algs would have to offer only rsae, and the Ssl library cannot use dcs. Often the pki and ssl libraries are different ( like in the case of fizz or s2n, not sure about mozpkix) Are you thinking about this in terms of cleaning up cruft or in terms of adding security?
The most important thing is to be very crisp about what is required. But then yeah, I don't want cruft, especially when that means more code to carry. I really don't want to have to support two types of SPKI when there is only one sort of signature we are permitting.
Ya at the core of this issue is that there is no separate list for sigalgs for dcs vs certs. You have to have rsae for certs, but if you have them you implicitly allow them for dcs as well. We could have the one off "allowed vs disallowed" list since the problem seems like it's very RSA specific. The alternative, i.e. the status quo, is to commit to supporting an algorithm you advertise for certs in dcs as well. Maybe taking it to the list. NAME what do you think?
I think this should be taken to the list. It's a subtle point I don't quite get. Martin, are you suggesting these two options? We remove SignatureScheme from the Credential in favor of simply relying on the SPKI to determine the signature scheme We explicitly forbid RSA DCs from having PKCSv1.5 as SubjectPublicKeyInfo? I'm in favor of explicitly forbidding PKCSv1.5 SKIs and not having to deal with a client that sends rsapssrsae_sha256 as the signature scheme and deciding to use a signature algorithm that is mismatched with the SKI. Of these options, 2) seems more similar to what is done in TLS. However, 1) seems like it fixes a protocol redundancy at the cost of some code complexity. I'd lean towards 2), myself.
I think the simplest thing to do might be to require the signature_algorithms extension contain the DC's algorithm, and use rsaEncryption OID in the SPKI as RFC 8446 does for certificates. This way the same code should work for verifying CertificateVerify messages regardless of the presence or absence of the delegated credential and delegated credentials will only be internal to the TLS library, not requiring much to do with PKIX. This may or may not be what NAME meant by not supporting two SPKIs, I'm not sure I entirely followed that remark. This may need to go to the list, I'm not sure what happens with RSA DCs in the current implementation: some experimentation may need to happen to figure it out!
Talking to NAME offline, I'm also in favor of requiring pss oids for DCs. I don't think it should cause a huge issue.
I also feel like I don't have a firm grasp of the problem. That said, here's my $0.02: Like NAME says, the intention of the DC spec is that the DC signature algorithm should be the same as the signature algorithm chosen by the server for signing the handshake. My understanding is that TLS 1.3 explicitly forbids using PKCSv1.5 for the handshake signature, so the DC spec would, too. Thus, at a high-level, I'd opt for whatever option makes preserving this semantics easier. Is the core of the problem is the manner in which the algorithm is selected? For example, the client might (a) choose the algorithm based on the code point in the handshake message (, if memory serves) or (b) based on the SPKI in the DC. I think option (a) is better in terms of cryptographic agility, but I suppose there are times when (b) is more convenient. Am I missing something? Is the issue that the code point in the handshake message doesn't fully specify an algorithm?
Considering the subsequent comments, I think I have a cleaner set of options: Allow RSA Credentials with the rsaEncryption OID in the SPKI to be used with the rsapssrsae signature schemes, but disallow rsapkcs1 signature schemes Forbid RSA Credentials with the rsaEncryption OID and require RSA PSS OIDs for rsapsspss signature schemes My sense is that the rsapssrsae_ suites are a hack created for backwards-compatibility with rsaEncryption OID certs. We don't have this legacy here, so I'm inclined to prefer 2). The only reason I see to go for 1) is because the RSA PSS OIDs are hard to get right in code, but considering that RSA DCs are unlikely to be widely used, I think this is a fine requirement. I'll take it to the list.
Looks good to me. Martin Thomson wrote: applies to the cert chain, which is fine. It's slightly annoying that supporting new SPKIs in DCs makes implementations have to support the new SPKI in certificates, but it doesn't seem like too big of a deal. I'd be interested in hearing from other client implementations on this issue (cc: David Benjamin).

(*) indicates changes to the wire protocol. <ins> draft-05 * Removed support for PKCS 1.5 RSA signature algorithms.  * Additional security considerations. </ins> draft-04 Add support for client certificates. The signature algorithm of the credential key pair, where the type SignatureScheme is as defined in RFC8446.  This is expected to be  <ins> the same as CertificateVerify.algorithm sent by the server.  Only signature algorithms allowed for use in CertificateVerify messages are allowed.  When using RSA, the public key MUST NOT use the rsaEncryption OID, as a result, the following algorithms are not allowed for use with delegated credentials: rsa_pss_rsae_sha256, rsa_pss_rsae_sha384, rsa_pss_rsae_sha512. </ins> The credential's public key, a DER-encoded X690 SubjectPublicKeyInfo as defined in RFC5280. DelegatedCredential.cred.valid_time. Verify that expected_cert_verify_algorithm matches the scheme  <ins> indicated in the peer's CertificateVerify message and that the algorithm is allowed for use with delegated credentials. </ins> Verify that the end-entity certificate satisfies the conditions in certificate-requirements.


(*) indicates changes to the wire protocol. <del> draft-05 * Removed support for PKCS 1.5 RSA signature algorithms.  * Additional security considerations. </del>  draft-04

Fix formatting issue in changes.
This is trivial and straightforward change so I'm just going to merge this directly.

(*) indicates changes to the wire protocol.  <ins> draft-05 Removed support for PKCS 1.5 RSA signature algorithms. Additional security considerations. </ins> draft-04


3.1.1. <del> A client which supports this specification SHALL send an empty "delegated_credential" extension in its ClientHello.  If the client receives a delegated credential without indicating support, then the client MUST abort with an "unexpected_message" alert. </del>  If the extension is present, the server MAY send a delegated credential; if the extension is not present, the server MUST NOT send certificate. The algorithm and expected_cert_verify_algorithm fields MUST be of a <del> type advertised by the client in the "signature_algorithms" extension and are considered invalid otherwise.  Clients that receive invalid delegated credentials MUST terminate the connection with an "illegal_parameter" alert. </del>  3.1.2.

Hearing no objections on the list, merging this in. NAME can you please spin a new version for WGLC?
Allow the client to send a list of signature schemes that are supported in a delegated credential handshake.
Fixed by .

3.1.1.  <ins> A client which supports this specification SHALL send a "delegated_credential" extension in its ClientHello.  The body of the extension consists of a SignatureSchemeList: If the client receives a delegated credential without indicating support, then the client MUST abort with an "unexpected_message" alert. </ins> If the extension is present, the server MAY send a delegated credential; if the extension is not present, the server MUST NOT send certificate. The algorithm and expected_cert_verify_algorithm fields MUST be of a  <ins> type advertised by the client in the SignatureSchemeList and are considered invalid otherwise.  Clients that receive invalid delegated credentials MUST terminate the connection with an "illegal_parameter" alert. </ins> 3.1.2.


This document registers the "delegated_credentials" extension in the "TLS ExtensionType Values" registry.  The "delegated_credentials" <del> extension has been assigned a code point of TBD.  The IANA registry </del>  lists this extension as "Recommended" (i.e., "Y") and indicates that it may appear in the ClientHello (CH), CertificateRequest (CR), or Certificate (CT) messages in TLS 1.3 RFC8446.

Currently the codepoint is TBD
NAME does one know what we need to get a code point.
NAME if we want one early, we can kick that process off. If not we wait for it to be assigned later in the process.
I think we need an early one. It's not possible yet to implement this to evaluate in various scenarios. We plan to use delegated credentials in our internal infrastructure and then probably would push the implementation back to open source projects like OpenSSL.
i think a resolution to URL is the only thing that is probably holding back the code point.
NAME can you please start the code point allocation process now that is resolved?

This document registers the "delegated_credentials" extension in the "TLS ExtensionType Values" registry.  The "delegated_credentials"  <ins> extension has been assigned a code point of 34.  The IANA registry </ins> lists this extension as "Recommended" (i.e., "Y") and indicates that it may appear in the ClientHello (CH), CertificateRequest (CR), or Certificate (CT) messages in TLS 1.3 RFC8446.


This document defines the following extension code point. A client which supports this document SHALL send an empty <del> "delegated_credential" extension in its ClientHello. If the extension is present, the server MAY send a DelegatedCredential extension.  If the extension is not present, the server MUST NOT send a credential.  A credential MUST NOT be provided unless a Certificate message is also sent. When negotiating TLS 1.3, and using Delegated credentials, the server MUST send the DelegatedCredential as an extension in the CertificateEntry of its end-entity certificate.  When negotiating TLS 1.2, the DelegatedCredential MUST be sent as an extension in the ServerHello. The DelegatedCredential contains a signature from the public key in </del>  the end-entity certificate using a signature algorithm advertised by the client in the "signature_algorithms" extension.  Additionally, the credential's public key MUST be of a type that enables at least than 7 days. Verify that the certificate has the DelegationUsage extension, <del> which permits the use of Delegated credentials. </del>  Use the public key in the server's end-entity certificate to verify the signature on the credential. deemed invalid.  Clients that receive invalid delegated credentials MUST terminate the connection with an "illegal_parameter" alert.  If successful, the client uses the public key in the credential to <del> verify a signature provided in the handshake: in particular, the </del>  CertificateVerify message in TLS 1.3 and the ServerKeyExchange in 1.2.

These came up when I implemented the extension in Go (URL) and I think would be useful to add to the standard.
looks good to me

This document defines the following extension code point. A client which supports this document SHALL send an empty  <ins> "delegated_credential" extension in its ClientHello.  If the client receives a delegated credential without indicating support, then the client SHOULD abort with an "unexpected_message" alert. If the extension is present, the server MAY send a delegated credential extension.  If the extension is not present, the server MUST NOT send a credential.  A credential MUST NOT be provided unless a Certificate message is also sent.  The server MUST ignore the extension unless TLS 1.2 or later is negotiated. When negotiating TLS 1.3, and using delegated credentials, the server MUST send the delegated credential as an extension in the CertificateEntry of its end-entity certificate; the client SHOULD ignore delegated credentials sent as extensions with any other certificate.  When negotiating TLS 1.2, the delegated credential MUST be sent as an extension in the ServerHello. The delegated credential contains a signature from the public key in </ins> the end-entity certificate using a signature algorithm advertised by the client in the "signature_algorithms" extension.  Additionally, the credential's public key MUST be of a type that enables at least than 7 days. Verify that the certificate has the DelegationUsage extension,  <ins> which permits the use of delegated credentials. </ins> Use the public key in the server's end-entity certificate to verify the signature on the credential. deemed invalid.  Clients that receive invalid delegated credentials MUST terminate the connection with an "illegal_parameter" alert.  If successful, the client uses the public key in the credential to  <ins> verify the signature provided in the handshake: in particular, the </ins> CertificateVerify message in TLS 1.3 and the ServerKeyExchange in 1.2.


These dependencies cause problems in practice.  Server operators often want to create short-lived certificates for servers in low- <del> trust zones such as Content Delivery Network (CDNs) or remote data </del>  centers.  This allows server operators to limit the exposure of keys <del> in cases that they do not realize a compromise has occurred.  The risk inherent in cross-organizational transactions makes it operationally infeasible to rely on an external CA for such short- lived credentials.  In Online Certificate Status Protocol (OCSP) stapling (i.e., using the Certificate Status extension type ocsp RFC8446, if an operator chooses to talk frequently to the CA to obtain stapled responses, then failure to fetch an OCSP stapled response results only in degraded performance.  On the other hand, failure to fetch a potentially large number of short lived certificates would result in the service not being available, which creates greater operational risk. </del>  To remove these dependencies, this document proposes a limited delegation mechanism that allows a TLS peer to issue its own

Also fixed a few smaller grammatical/punctuation errors. Rationale from the mailing list: I think OCSP is being brought up here as an example of a way that dependence on a CA can go wrong, but that isn't really made explicit.I'm not sure what "only" means in "only in degraded performance." Is it "the worst that can happen is just degraded performance" or "it can result only in degraded performance, as opposed to better performance"? At first I thought it was the latter, but after reading the subsequent sentence, I realized it was probably the former.The use of "On the other hand" sounds like the rest of the sentence is going to describe a way that failure to receive something from a CA resulted in better performance, which obviously would be silly.

These dependencies cause problems in practice.  Server operators often want to create short-lived certificates for servers in low-  <ins> trust zones such as Content Delivery Networks (CDNs) or remote data </ins> centers.  This allows server operators to limit the exposure of keys  <ins> in cases where they do not realize a compromise has occurred. However, the risk inherent in cross-organizational transactions makes it operationally infeasible to rely on an external CA for such short- lived credentials.  For instance, in the case of Online Certificate Status Protocol (OCSP) stapling (i.e., using the Certificate Status extension type ocsp RFC8446), a CA may fail to deliver OCSP stapled response.  While this will result in degraded performance, the ramifications of failing to deliver short-lived certificates are even worse: the service that depends on those certificates would go down entirely.  Thus, ensuring independence from CAs for short-lived certificates is critical to the uptime of a service. </ins> To remove these dependencies, this document proposes a limited delegation mechanism that allows a TLS peer to issue its own


4.1. <del> We define a new X.509 extension, DelegationUsage to be used in the </del>  certificate when the certificate permits the usage of delegated credentials. certificates. The client MUST NOT accept a delegated credential unless the server's <del> end-entity certificate has the DelegationUsage extension. </del>  5.

Based on One of the design criteria for this standard is to isolate the TLS with the DC extension from other protocols. In this PR, I propose explicitly restricting the X.509 KeyUsage of the end-entity certificate. This change is made in the last commit: URL The two commits that proceed it don't actually change the semantics of the standard, but clean up the language a bit. If the KeyUsage change isn't adopted, we might consider merging the other two commits.
if it's not too painful, could you move this particular diff above all the others, I think I want to have some more discussion on this one. If its painful, we can just resolve this one first
Done, NAME
looks like i merged this as a result of merging a dependent PR accidentally. This is fine, we can just discuss this before I put up the next draft versions

4.1.  <ins> We define a new X.509 extension, DelegationUsage, to be used in the </ins> certificate when the certificate permits the usage of delegated credentials. certificates. The client MUST NOT accept a delegated credential unless the server's  <ins> end-entity certificate satisfies the following criteria: It has the DelegationUsage extension. It has the digitalSignature key usage enabled (see the Keyusage type in RFC5280), but has the keyEncipherment and dataEncipherment usages are disabled. </ins> 5.


Address case nits  Add text around using an oracle to forge DCs in the future and past Verify that the current time is within the validity interval of the credential.  This is done by asserting that the current time is no more than the delegation certificate's notBefore value plus <del> DelegatedCredential.cred.valid_time.  2 Verify that the credential's remaining validity time is no more than the maximum validity period.  This is done by asserting that the current time is no more than the delegation certificate's notBefore value plus DelegatedCredential.cred.valid_time plus the maximum validity period. </del>  Verify that expected_cert_verify_algorithm matches the scheme indicated in the peer's CertificateVerify message and that the 5.  This document registers the "delegated_credentials" extension in the "TLS ExtensionType Values" registry.  The "delegated_credentials" extension has been assigned a code point of 34.  The IANA registry extension is not needed as it is already assigned to the extension from Cloudflare's IANA Private Enterprise Number (PEN) arc. <del> 6. </del>  <del> 6.1. </del>  Delegated credentials limit the exposure of the private key used in a TLS connection by limiting its validity period.  An attacker who mechanisms SHOULD be used to protect it, including file system controls, physical security, or hardware security modules. <del> 6.2. </del>  It is not possible to use the same delegated credential for both client and server authentication because issuing parties compute the corresponding signature using a context string unique to the intended role (client or server). <del> 6.3. </del>  Delegated credentials do not provide any additional form of early revocation.  Since it is short lived, the expiry of the delegated private key that signs the delegated credential also implicitly revokes the delegated credential. <del> 6.4. </del>  If a client decides to cache the certificate chain and re-validate it when resuming a connection, the client SHOULD also cache the associated delegated credential and re-validate it. <del> 6.5. </del>  Delegated credentials can be valid for 7 days and it is much easier for a service to create delegated credential than a certificate want to advertise support for delegated credentials or limit the number of probes that a server can perform. <del> 6.6. </del>  When TLS 1.2 servers support RSA key exchange, they may be vulnerable to attacks that allow forging an RSA signature over an arbitrary

From Martin: I wonder how much more needs to be said about expiration dates and allowance for clock skew. We haven't had any trouble with the mechanism proposed here (to my knowledge), but we've had plenty of trouble with ESNI deployment. Maybe the design here is sufficiently superior that it is less susceptible to problems, but it's not clear that this is indeed the case. Our implementation follows the spec when it comes to the validity period, but we can't really prevent skew from causing credentials to be rejected. What this does is that it creates a fixed notBefore equivalent for the DC that is relative to the notAfter. This effectively means that servers need to set valid_time values that aren't too far in the future based on their tolerance for client clock skew. For a 7-day credential, you might get 5 good days of use. A little bit of a nod in this direction might go a long way to avoiding deployment problems.
Fixed in

Address case nits <ins> Fix section bullets in 4.1.3. Add operational considerations section for clock skew </ins> Add text around using an oracle to forge DCs in the future and past Verify that the current time is within the validity interval of the credential.  This is done by asserting that the current time is no more than the delegation certificate's notBefore value plus  <ins> DelegatedCredential.cred.valid_time. Verify that the credential's remaining validity time is no more than the maximum validity period.  This is done by asserting that the current time is no more than the delegation certificate's notBefore value plus DelegatedCredential.cred.valid_time plus the maximum validity period. </ins> Verify that expected_cert_verify_algorithm matches the scheme indicated in the peer's CertificateVerify message and that the 5. <ins> 5.1. One of the risks of deploying a short-lived credential system based on absolute time is client clock skew.  If a client's clock is sufficiently ahead or behind of the server's clock, then clients will reject credentials that are valid from the server's perspective. Clock skew also affects the validity of the original certificates. The lifetime of the delegated credential should be set taking clock skew into account.  Clock skew may affect a delegated credential at the beginning and end of its validity periods, which should also be taken into account. 6. </ins> This document registers the "delegated_credentials" extension in the "TLS ExtensionType Values" registry.  The "delegated_credentials" extension has been assigned a code point of 34.  The IANA registry extension is not needed as it is already assigned to the extension from Cloudflare's IANA Private Enterprise Number (PEN) arc.  <ins> 7. </ins>  <ins> 7.1. </ins> Delegated credentials limit the exposure of the private key used in a TLS connection by limiting its validity period.  An attacker who mechanisms SHOULD be used to protect it, including file system controls, physical security, or hardware security modules.  <ins> 7.2. </ins> It is not possible to use the same delegated credential for both client and server authentication because issuing parties compute the corresponding signature using a context string unique to the intended role (client or server).  <ins> 7.3. </ins> Delegated credentials do not provide any additional form of early revocation.  Since it is short lived, the expiry of the delegated private key that signs the delegated credential also implicitly revokes the delegated credential.  <ins> 7.4. </ins> If a client decides to cache the certificate chain and re-validate it when resuming a connection, the client SHOULD also cache the associated delegated credential and re-validate it.  <ins> 7.5. </ins> Delegated credentials can be valid for 7 days and it is much easier for a service to create delegated credential than a certificate want to advertise support for delegated credentials or limit the number of probes that a server can perform.  <ins> 7.6. </ins> When TLS 1.2 servers support RSA key exchange, they may be vulnerable to attacks that allow forging an RSA signature over an arbitrary


Address case nits  Add text about certificate extension vs EKU draft-08 elliptic curve certificates for DC-enabled traffic, while using RSA certificates without the DelegationUsage certificate extension for non-DC traffic; this completely prevents such attacks.

NAME please go ahead and merge after resolving conflicts!
From Martin: The security considerations don't cover the potential for misissuance creating a credential that is as long-lived as the certificate, but they probably should.
NAME I'm not sure what you mean here. Are you talking about explicitly calling out the possibility that the credential may expire after the certificate and that this should be forbidden?
If you are able to access the signing key of the certificate, or are otherwise able to construct a DC, you can create multiple DCs that cover the time from now until the certificate expires. It's not a big deal, but I thought it might be worth noting.
Gotcha. I'll note this.
Closed in

Address case nits <ins> Add text around using an oracle to forge DCs in the future and past </ins> Add text about certificate extension vs EKU draft-08 elliptic curve certificates for DC-enabled traffic, while using RSA certificates without the DelegationUsage certificate extension for non-DC traffic; this completely prevents such attacks. <ins> Note that if a signature can be forged over an arbitrary credential, the attacker can choose any value for the valid_time field.  Repeated signature forgeries therefore allow the attacker to create multiple delegated credentials that can cover the entire validity period of the certificate.  Temporary exposure of the key or a signing oracle may allow the attacker to impersonate a server for the lifetime of the certificate. </ins>


semantic fields: a validity interval and a public key (along with its associated signature algorithm).  The signature on the credential indicates a delegation from the certificate that is issued to the <del> peer.  The secret key used to sign a credential corresponds to the </del>  public key of the peer's X.509 end-entity certificate RFC5280. A TLS handshake that uses delegated credentials differs from a

In section 3, the document says: The secret key used to sign ... Please change "secret" to "private". Later in the sentence, [RFC5280] is referenced, and it talks about "private key" in this context.
Addressed in

semantic fields: a validity interval and a public key (along with its associated signature algorithm).  The signature on the credential indicates a delegation from the certificate that is issued to the  <ins> peer.  The private key used to sign a credential corresponds to the </ins> public key of the peer's X.509 end-entity certificate RFC5280. A TLS handshake that uses delegated credentials differs from a


Address case nits  draft-08 Include details about the impact of signature forgery attacks It has the digitalSignature KeyUsage (see the KeyUsage extension defined in RFC5280).  5. This document registers the "delegated_credentials" extension in the

From Russ: I guess I ask the authors to add a paragraph to the rationale section that says something about why this extension was used instead of an extended key usage. From Watson: One of the hard requirements for our deployment was that the same certificate be useable with DCs and without. A different EKU would be more problematic then an extension for this purpose, and while it might be more or less irritating for implementors depending on how their stack works (sorry Rich - https://boringssl-URL might serve as inspiration, but the client side got dropped for similar issues). We know the extension doesn't bust things, I don't know an EKU would, and the root program issues make me hesitate.
Addressed in

Address case nits <ins> Add text about certificate extension vs EKU </ins> draft-08 Include details about the impact of signature forgery attacks It has the digitalSignature KeyUsage (see the KeyUsage extension defined in RFC5280). <ins> A new extension was chosen instead of adding a new Extended Key Usage (EKU) to be compatible with deployed TLS and PKI software stacks without requiring CAs to issue new intermediate certificates. </ins> 5. This document registers the "delegated_credentials" extension in the


make such delegations as long as they only enable the recipient of the delegation to speak for names that the CA has authorized.  For clarity, we will refer to the certificate issued by the CA as a <del> "certificate", or "deleagation certificate", and the one issued by the operator as a "delegated credential". </del>  2. issue other signed objects as long as the certificate contains the digitalSignature key usage (RFC5280 section 4.2.1.3).  We define a new signed object format that would encode only the semantics that <del> are needed for this application. </del>  <del> Relative time in seconds from the beginning of the certificate's notBefore value after which the delegated credential is no longer valid. </del>  The delegated credential's public key, which is an encoded SubjectPublicKeyInfo RFC5280.  The signature algorithm used to sign the delegated credential, where SignatureScheme is as defined in the TLS 1.3 standard. The DER-encoded X.509 end-entity certificate used to sign the DelegatedCredential. <del> The ProtocolVersion in which the delegated credential is to be used, where ProtocolVersion is as defined in the TLS 1.3 standard. The SignatureScheme of Credential.public_key, the signature scheme used by the server to sign the handshake. </del>  DelegatedCredential.scheme. <del> DelegatedCredential.cred. </del> The signature effectively binds the credential to the parameters of the handshake in which it is used.  In particular, it ensures that credentials are only used with the certificate, protocol, and

Based on There is currently no binding of the credential to the signature scheme used to sign the handshake. The field of the encodes the DC public key type; but there's not a one-to-one correspondence between X.509's and TLS . Hence, the TLS terminator could use a signature scheme to sign the handshake other than the scheme intended by the delegator. To prevent this, this PR adds the SignatureScheme that the TLS terminator selects in the "signature_algorithms" extension to scope of the delegation signature. In addition, it makes this and the protocol version explicit parameters of the Credential structure. This is intended to make debugging easier.

make such delegations as long as they only enable the recipient of the delegation to speak for names that the CA has authorized.  For clarity, we will refer to the certificate issued by the CA as a  <ins> "certificate", or "delegation certificate", and the one issued by the operator as a "delegated credential". </ins> 2. issue other signed objects as long as the certificate contains the digitalSignature key usage (RFC5280 section 4.2.1.3).  We define a new signed object format that would encode only the semantics that  <ins> are needed for this application.  The credential has the following structure: </ins>  <ins> Relative time in seconds from the beginning of the delegation certificate's notBefore value after which the delegated credential is no longer valid. The signature algorithm of the credential key pair, where the type SignatureScheme is as defined in the TLS 1.3 standard. The version of TLS in which the credential will be used, where the type ProtocolVersion is as defined in TLS 1.3. </ins> The delegated credential's public key, which is an encoded SubjectPublicKeyInfo RFC5280. <ins> The delegated credential has the following structure: </ins> The signature algorithm used to sign the delegated credential, where SignatureScheme is as defined in the TLS 1.3 standard. The DER-encoded X.509 end-entity certificate used to sign the DelegatedCredential.  <ins> DelegatedCredential.cred. </ins> DelegatedCredential.scheme.  The signature effectively binds the credential to the parameters of the handshake in which it is used.  In particular, it ensures that credentials are only used with the certificate, protocol, and


Time in seconds relative to the beginning of the delegation certificate's notBefore value after which the delegated credential <del> is no longer valid.  Endpoints will reject delegate credentials with valid_times exceeding 7 days (as described in client-and- server-behavior). </del>  The signature algorithm of the Credential key pair, where the type SignatureScheme is as defined in RFC8446.  This is expected to be On receiving a delegated credential and a certificate chain, the peer validates the certificate chain and matches the end-entity <del> certificate to the peer's expected identity.  It also takes the following steps: Validate that DelegatedCredential.cred.valid_time is no more than 7 days. </del>  Verify that the current time is within the validity interval of the credential.  This is done by asserting that the current time <del> is no more than the delegation certificate's notBefore value plus DelegatedCredential.cred.valid_time. Verify that the delegated credential's remaining validity time is no more than the maximum validity period.  This is done by asserting that the current time is no more than the delegation certificate's notBefore value plus DelegatedCredential.cred.valid_time plus the maximum validity period. </del>  Verify that expected_cert_verify_algorithm matches the scheme indicated in the peer's CertificateVerify message and that the

Update the condition for validating a DC to the following: now() <= notBefore + valid_time <= now() + 7d
LGTM % nit

Time in seconds relative to the beginning of the delegation certificate's notBefore value after which the delegated credential  <ins> is no longer valid.  Endpoints will reject delegated credentials that expire more than 7 days from the current time (as described in client-and-server-behavior). </ins> The signature algorithm of the Credential key pair, where the type SignatureScheme is as defined in RFC8446.  This is expected to be On receiving a delegated credential and a certificate chain, the peer validates the certificate chain and matches the end-entity  <ins> certificate to the peer's expected identity.  It then performs the following checks with expiry time set to the delegation certificate's notBefore value plus DelegatedCredential.cred.valid_time: </ins> Verify that the current time is within the validity interval of the credential.  This is done by asserting that the current time  <ins> does not exceed the expiry time. Verify that the delegated credential's remaining validity period is no more than the maximum validity period.  This is done by asserting that the expiry time does not exceed the current time plus the maximum validity period (7 days). </ins> Verify that expected_cert_verify_algorithm matches the scheme indicated in the peer's CertificateVerify message and that the


If the extension is present, the server MAY send a delegated credential; if the extension is not present, the server MUST NOT send a delegated credential.  The server MUST ignore the extension unless <del> TLS 1.3 or a later version is negotiated. </del>  The server MUST send the delegated credential as an extension in the CertificateEntry of its end-entity certificate; the client SHOULD

Addresses .
Tweak some of the text in s4.1.1 to be explain downgrade protections. from . Hi Sean, Thanks for the follow-up. I refreshed my memory as much as I could. Please see my responses in line. Yours, Daniel Sean Turner wrote: I think I would rather take the structure: 1 - Use case 2 - Problem description 3 - Solution I am fine with whatever fits best to you. Server operators often deploy TLS termination services in locations such as remote data centers or Content Delivery Networks (CDNs) where it may be difficult to detect key compromises. Short-lived certificates may be used to limit the exposure of keys in these cases. However, short-lived certificates need to be renewed more frequently than long-lived certificates. If an external CA is unable to issue a certificate in time to replace a deployed certificate, the server would no longer be able to present a valid certificate to clients. With short-lived certificates, there is a smaller window of time to renew a certificates and therefore a higher risk that an outage at a CA will negatively affect the uptime of the service. Typically, a TLS server uses a certificate provided by some entity other than the operator of the server (a "Certification Authority" or CA) [RFC8446 ] [RFC5280 ]. This organizational separation makes the TLS server operator dependent on the CA for some aspects of its operations, for example: Whenever the server operator wants to deploy a new certificate, it has to interact with the CA. The server operator can only use TLS signature schemes for which the CA will issue credentials. To reduce the dependency on external CAs, this document proposes a limited delegation mechanism that allows a TLS peer to issue its own credentials within the scope of a certificate issued by an external CA. These credentials only enable the recipient of the delegation to speak for names that the CA has authorized. Furthermore, this mechanism allows the server to use modern signature algorithms such as Ed25519 [RFC8032 ] even if their CA does not support them. We will refer to the certificate issued by the CA as a "certificate", or "delegation certificate", and the one issued by the operator as a "delegated credential" or "DC". I think my concern has been clarified by Ilari. It was resolved by your b). I am fine with both text. works for me. The text does not address my concern and will recap my perspective of the discussion. My initial comment was that the reference [KEYLESS] points to a solution that does not work with TLS 1.3 and currently the only effort compatible with TLS 1.3 is draft-mglt-lurk-tls13. I expect this reference to be mentioned and I do not see it in the text proposed text. If the intention with [KEYLESS] is to mention TLS Handshake Proxying techniques, then I argued that other mechanisms be mentioned and among others draft-mglt-lurk-tls12 and draft-mglt-lurk-tls13 that address different versions of TLS. This was my second concern and I do not see any of these references being mentioned. The way I understand your response is that the paper pointed out by [KEYLESS] is not Cloudflare's commercial product but instead a generic TLS Handshake proxying and that you propose to add a reference to an academic paper that discusses the LURK extension for TLS 1.2. I appreciate that other solutions - and in this case LURK, are being considered. I am wondering however why draft-mglt-lurk-tls12 is being replaced by an academic reference [REF2] and why draft-mglt-lurk-tls13 has been omitted. It seems that we are trying to avoid any reference of the work that is happening at the IETF. Is there anything I am missing ? My suggestion for the text OLD: (e.g., a PKCS interface or a remote signing mechanism [KEYLESS]) NEW: (e.g., a PKCS interface or a remote signing mechanism such as [draft-mglt-lurk-tls13] or [draft-mglt-lurk-tls12] ([LURK-TLS12]) or [KEYLESS]) with [KEYLESS] Sullivan, N. and D. Stebila, "An Analysis of TLS Handshake Proxying", IEEE TrustCom/BigDataSE/ISPA 2015, 2015. [LURK-TLS12] Boureanu, I., Migault, D., Preda, S., Alamedine, H.A., Mishra, S. Fieau, F., and M. Mannan, "LURK: Server-Controlled TLS Delegation”, IEEE TrustCom 2020, URL, 2020. [draft-mglt-lurk-tls12] IETF draft [draft-mglt-lurk-tls13] IETF draft It is unclear to me what is generic about the paper pointed by [KEYLESS] or [REF1]. In any case, for clarification, the paper clearly refers to Cloudflare commercial products as opposed to a generic mechanism, and this will remain whatever label will be used as a reference. Typically, Cloudflare co-authors the paper appears 12 times in the 8 page paper. The contribution section mentions: """ Our work focuses specifically on the TLS handshake proxying system implemented by CloudFlare in their Keyless SSL product [6], [7] """ The methodology mentions says: """ We tested TLS key proxying using CloudFlare’s implementation, which was implemented with the following three parts: """ """ The different scenarios were set up through CloudFlare’s control panel. In the direct handshake handshake scenario, the site is set up with no reverse proxy. In the scenario where the key is held by the edge server, the same certificate that was used on the origin is uploaded to CloudFlare and the reverse proxy is enabled for the site. """ Cloudflare appears in at least references URL CloudFlare Inc., “CloudFlare Keyless SSL,” Sep. 2014, URL N. Sullivan, “Keyless SSL: The nitty gritty technical details,” Sep. 2014, URL works for me. works for me seems clearer. I suspect earlier clarifications addressed this. thanks that it way clearer. Daniel Migault Ericsson

If the extension is present, the server MAY send a delegated credential; if the extension is not present, the server MUST NOT send a delegated credential.  The server MUST ignore the extension unless  <ins> TLS 1.3 or a later version is negotiated.  An example of when a server could choose not to send a delegated credential is when the SignatureSchemes listed only contain signature schemes for which a corresponding delegated credential does not exist or are otherwise unsuitable for the connection. </ins> The server MUST send the delegated credential as an extension in the CertificateEntry of its end-entity certificate; the client SHOULD


The signature algorithm of the Credential key pair, where the type SignatureScheme is as defined in RFC8446.  This is expected to be <del> the same as the sender's CertificateVerify.algorithm.  Only signature algorithms allowed for use in CertificateVerify messages are allowed.  When using RSA, the public key MUST NOT use the rsaEncryption OID.  As a result, the following algorithms are not allowed for use with delegated credentials: rsa_pss_rsae_sha256, rsa_pss_rsae_sha384, rsa_pss_rsae_sha512. </del>  The Credential's public key, a DER-encoded X.690 SubjectPublicKeyInfo as defined in RFC5280.

Addresses a comment from from . Hi Sean, Thanks for the follow-up. I refreshed my memory as much as I could. Please see my responses in line. Yours, Daniel Sean Turner wrote: I think I would rather take the structure: 1 - Use case 2 - Problem description 3 - Solution I am fine with whatever fits best to you. Server operators often deploy TLS termination services in locations such as remote data centers or Content Delivery Networks (CDNs) where it may be difficult to detect key compromises. Short-lived certificates may be used to limit the exposure of keys in these cases. However, short-lived certificates need to be renewed more frequently than long-lived certificates. If an external CA is unable to issue a certificate in time to replace a deployed certificate, the server would no longer be able to present a valid certificate to clients. With short-lived certificates, there is a smaller window of time to renew a certificates and therefore a higher risk that an outage at a CA will negatively affect the uptime of the service. Typically, a TLS server uses a certificate provided by some entity other than the operator of the server (a "Certification Authority" or CA) [RFC8446 ] [RFC5280 ]. This organizational separation makes the TLS server operator dependent on the CA for some aspects of its operations, for example: Whenever the server operator wants to deploy a new certificate, it has to interact with the CA. The server operator can only use TLS signature schemes for which the CA will issue credentials. To reduce the dependency on external CAs, this document proposes a limited delegation mechanism that allows a TLS peer to issue its own credentials within the scope of a certificate issued by an external CA. These credentials only enable the recipient of the delegation to speak for names that the CA has authorized. Furthermore, this mechanism allows the server to use modern signature algorithms such as Ed25519 [RFC8032 ] even if their CA does not support them. We will refer to the certificate issued by the CA as a "certificate", or "delegation certificate", and the one issued by the operator as a "delegated credential" or "DC". I think my concern has been clarified by Ilari. It was resolved by your b). I am fine with both text. works for me. The text does not address my concern and will recap my perspective of the discussion. My initial comment was that the reference [KEYLESS] points to a solution that does not work with TLS 1.3 and currently the only effort compatible with TLS 1.3 is draft-mglt-lurk-tls13. I expect this reference to be mentioned and I do not see it in the text proposed text. If the intention with [KEYLESS] is to mention TLS Handshake Proxying techniques, then I argued that other mechanisms be mentioned and among others draft-mglt-lurk-tls12 and draft-mglt-lurk-tls13 that address different versions of TLS. This was my second concern and I do not see any of these references being mentioned. The way I understand your response is that the paper pointed out by [KEYLESS] is not Cloudflare's commercial product but instead a generic TLS Handshake proxying and that you propose to add a reference to an academic paper that discusses the LURK extension for TLS 1.2. I appreciate that other solutions - and in this case LURK, are being considered. I am wondering however why draft-mglt-lurk-tls12 is being replaced by an academic reference [REF2] and why draft-mglt-lurk-tls13 has been omitted. It seems that we are trying to avoid any reference of the work that is happening at the IETF. Is there anything I am missing ? My suggestion for the text OLD: (e.g., a PKCS interface or a remote signing mechanism [KEYLESS]) NEW: (e.g., a PKCS interface or a remote signing mechanism such as [draft-mglt-lurk-tls13] or [draft-mglt-lurk-tls12] ([LURK-TLS12]) or [KEYLESS]) with [KEYLESS] Sullivan, N. and D. Stebila, "An Analysis of TLS Handshake Proxying", IEEE TrustCom/BigDataSE/ISPA 2015, 2015. [LURK-TLS12] Boureanu, I., Migault, D., Preda, S., Alamedine, H.A., Mishra, S. Fieau, F., and M. Mannan, "LURK: Server-Controlled TLS Delegation”, IEEE TrustCom 2020, URL, 2020. [draft-mglt-lurk-tls12] IETF draft [draft-mglt-lurk-tls13] IETF draft It is unclear to me what is generic about the paper pointed by [KEYLESS] or [REF1]. In any case, for clarification, the paper clearly refers to Cloudflare commercial products as opposed to a generic mechanism, and this will remain whatever label will be used as a reference. Typically, Cloudflare co-authors the paper appears 12 times in the 8 page paper. The contribution section mentions: """ Our work focuses specifically on the TLS handshake proxying system implemented by CloudFlare in their Keyless SSL product [6], [7] """ The methodology mentions says: """ We tested TLS key proxying using CloudFlare’s implementation, which was implemented with the following three parts: """ """ The different scenarios were set up through CloudFlare’s control panel. In the direct handshake handshake scenario, the site is set up with no reverse proxy. In the scenario where the key is held by the edge server, the same certificate that was used on the origin is uploaded to CloudFlare and the reverse proxy is enabled for the site. """ Cloudflare appears in at least references URL CloudFlare Inc., “CloudFlare Keyless SSL,” Sep. 2014, URL N. Sullivan, “Keyless SSL: The nitty gritty technical details,” Sep. 2014, URL works for me. works for me seems clearer. I suspect earlier clarifications addressed this. thanks that it way clearer. Daniel Migault Ericsson

The signature algorithm of the Credential key pair, where the type SignatureScheme is as defined in RFC8446.  This is expected to be  <ins> the same as the sender's CertificateVerify.algorithm (as described in validating-a-delegated-credential).  Only signature algorithms allowed for use in CertificateVerify messages are allowed.  When using RSA, the public key MUST NOT use the rsaEncryption OID.  As a result, the following algorithms are not allowed for use with delegated credentials: rsa_pss_rsae_sha256, rsa_pss_rsae_sha384, rsa_pss_rsae_sha512. </ins> The Credential's public key, a DER-encoded X.690 SubjectPublicKeyInfo as defined in RFC5280.


7.6.  When TLS 1.2 servers support RSA key exchange, they may be vulnerable to attacks that allow forging an RSA signature over an arbitrary message BLEI.  TLS 1.2 RFC5246 (Section 7.4.7.1.) describes a

Addresses .
The text in s7.6, needs an intro to explain why it talks about TLS 1.2 when this extension is only applicable to TLS 1.3. From .
I don't think this is really necessary, but Hi Sean, Thanks for the follow-up. I refreshed my memory as much as I could. Please see my responses in line. Yours, Daniel Sean Turner wrote: I think I would rather take the structure: 1 - Use case 2 - Problem description 3 - Solution I am fine with whatever fits best to you. Server operators often deploy TLS termination services in locations such as remote data centers or Content Delivery Networks (CDNs) where it may be difficult to detect key compromises. Short-lived certificates may be used to limit the exposure of keys in these cases. However, short-lived certificates need to be renewed more frequently than long-lived certificates. If an external CA is unable to issue a certificate in time to replace a deployed certificate, the server would no longer be able to present a valid certificate to clients. With short-lived certificates, there is a smaller window of time to renew a certificates and therefore a higher risk that an outage at a CA will negatively affect the uptime of the service. Typically, a TLS server uses a certificate provided by some entity other than the operator of the server (a "Certification Authority" or CA) [RFC8446 ] [RFC5280 ]. This organizational separation makes the TLS server operator dependent on the CA for some aspects of its operations, for example: Whenever the server operator wants to deploy a new certificate, it has to interact with the CA. The server operator can only use TLS signature schemes for which the CA will issue credentials. To reduce the dependency on external CAs, this document proposes a limited delegation mechanism that allows a TLS peer to issue its own credentials within the scope of a certificate issued by an external CA. These credentials only enable the recipient of the delegation to speak for names that the CA has authorized. Furthermore, this mechanism allows the server to use modern signature algorithms such as Ed25519 [RFC8032 ] even if their CA does not support them. We will refer to the certificate issued by the CA as a "certificate", or "delegation certificate", and the one issued by the operator as a "delegated credential" or "DC". I think my concern has been clarified by Ilari. It was resolved by your b). I am fine with both text. works for me. The text does not address my concern and will recap my perspective of the discussion. My initial comment was that the reference [KEYLESS] points to a solution that does not work with TLS 1.3 and currently the only effort compatible with TLS 1.3 is draft-mglt-lurk-tls13. I expect this reference to be mentioned and I do not see it in the text proposed text. If the intention with [KEYLESS] is to mention TLS Handshake Proxying techniques, then I argued that other mechanisms be mentioned and among others draft-mglt-lurk-tls12 and draft-mglt-lurk-tls13 that address different versions of TLS. This was my second concern and I do not see any of these references being mentioned. The way I understand your response is that the paper pointed out by [KEYLESS] is not Cloudflare's commercial product but instead a generic TLS Handshake proxying and that you propose to add a reference to an academic paper that discusses the LURK extension for TLS 1.2. I appreciate that other solutions - and in this case LURK, are being considered. I am wondering however why draft-mglt-lurk-tls12 is being replaced by an academic reference [REF2] and why draft-mglt-lurk-tls13 has been omitted. It seems that we are trying to avoid any reference of the work that is happening at the IETF. Is there anything I am missing ? My suggestion for the text OLD: (e.g., a PKCS interface or a remote signing mechanism [KEYLESS]) NEW: (e.g., a PKCS interface or a remote signing mechanism such as [draft-mglt-lurk-tls13] or [draft-mglt-lurk-tls12] ([LURK-TLS12]) or [KEYLESS]) with [KEYLESS] Sullivan, N. and D. Stebila, "An Analysis of TLS Handshake Proxying", IEEE TrustCom/BigDataSE/ISPA 2015, 2015. [LURK-TLS12] Boureanu, I., Migault, D., Preda, S., Alamedine, H.A., Mishra, S. Fieau, F., and M. Mannan, "LURK: Server-Controlled TLS Delegation”, IEEE TrustCom 2020, URL, 2020. [draft-mglt-lurk-tls12] IETF draft [draft-mglt-lurk-tls13] IETF draft It is unclear to me what is generic about the paper pointed by [KEYLESS] or [REF1]. In any case, for clarification, the paper clearly refers to Cloudflare commercial products as opposed to a generic mechanism, and this will remain whatever label will be used as a reference. Typically, Cloudflare co-authors the paper appears 12 times in the 8 page paper. The contribution section mentions: """ Our work focuses specifically on the TLS handshake proxying system implemented by CloudFlare in their Keyless SSL product [6], [7] """ The methodology mentions says: """ We tested TLS key proxying using CloudFlare’s implementation, which was implemented with the following three parts: """ """ The different scenarios were set up through CloudFlare’s control panel. In the direct handshake handshake scenario, the site is set up with no reverse proxy. In the scenario where the key is held by the edge server, the same certificate that was used on the origin is uploaded to CloudFlare and the reverse proxy is enabled for the site. """ Cloudflare appears in at least references URL CloudFlare Inc., “CloudFlare Keyless SSL,” Sep. 2014, URL N. Sullivan, “Keyless SSL: The nitty gritty technical details,” Sep. 2014, URL works for me. works for me seems clearer. I suspect earlier clarifications addressed this. thanks that it way clearer. Daniel Migault Ericsson

7.6. <ins> Delegated credentials are only used in TLS 1.3 connections.  However, the certificate that signs a delegated credential may be used in other contexts such as TLS 1.2.  Using a certificate in multiple contexts opens up a potential cross-protocol attack against delegated credentials in TLS 1.3. </ins> When TLS 1.2 servers support RSA key exchange, they may be vulnerable to attacks that allow forging an RSA signature over an arbitrary message BLEI.  TLS 1.2 RFC5246 (Section 7.4.7.1.) describes a


endpoint and the certification authority can create limitations.  For example, the lifetime of certificates, how they may be used, and the algorithms they support are ultimately determined by the <del> certification authority.  This document describes a mechanism by which operators may delegate their own credentials for use in (D)TLS, without breaking compatibility with peers that do not support this specification. </del>  1. Typically, a (D)TLS server uses a certificate provided by some entity other than the operator of the server (a "Certification Authority" or <del> CA) RFC8446 ID.ietf-tls-dtls13 RFC5280.  This organizational separation makes the (D)TLS server operator dependent on the CA for some aspects of its operations, for example: </del>  Whenever the server operator wants to deploy a new certificate, it has to interact with the CA. (*) indicates changes to the wire protocol.  draft-10 Address superficial comments It was noted in XPROT that certificates in use by servers that support outdated protocols such as SSLv2 can be used to forge signatures for certificates that contain the keyEncipherment KeyUsage <del> (RFC5280 section 4.2.1.3).  In order to prevent this type of cross- protocol attack, we define a new DelegationUsage extension to X.509 that permits use of delegated credentials.  (See certificate- requirements.) </del>  3.1. X.509 semantics are very rich.  This can cause unintended consequences if a service owner creates a proxy certificate where <del> the properties differ from the leaf certificate.  For this reason, delegated credentials have very restricted semantics that should not conflict with X.509 semantics. </del>  Proxy certificates rely on the certificate path building process to establish a binding between the proxy certificate and the end- interact with a back-end server that holds a private key.  The mechanism proposed in this document allows the delegation to be done off-line, with no per-transaction latency.  The figure below compares <del> the message flows for these two mechanisms with (D)TLS 1.3 RFC8446 ID.ietf-tls-dtls13. </del>  These two mechanisms can be complementary.  A server could use delegated credentials for clients that support them, while using a server-side mechanism to support legacy clients.  Both mechanisms require a trusted relationship between the Front-End and Back-End - the delegated credential can be used in place of a certificate <del> private key, and the remote key signing case is effectively a signing oracle for TLS connections using that certificate. </del>  Use of short-lived certificates with automated certificate issuance, e.g., with Automated Certificate Management Environment (ACME) 6. <del> This document registers the "delegated_credentials" extension in the "TLS ExtensionType Values" registry.  The "delegated_credentials" </del>  extension has been assigned a code point of 34.  The IANA registry lists this extension as "Recommended" (i.e., "Y") and indicates that it may appear in the ClientHello (CH), CertificateRequest (CR), or <del> Certificate (CT) messages in (D)TLS 1.3 RFC8446 ID.ietf-tls-dtls13. </del>  Additionally, the "DTLS-Only" column is assigned the value "N". This document also defines an ASN.1 module for the DelegationUsage Delegated credentials limit the exposure of the private key used in a (D)TLS connection by limiting its validity period.  An attacker who <del> compromises the private key of a delegated credential can act as a man-in-the-middle until the delegated credential expires.  However, they cannot create new delegated credentials.  Thus, delegated credentials should not be used to send a delegation to an untrusted party, but are meant to be used between parties that have some trust relationship with each other.  The secrecy of the delegated credential's private key is thus important and access control mechanisms SHOULD be used to protect it, including file system controls, physical security, or hardware security modules. </del>  7.2. 7.4. <del> If a client decides to cache the certificate chain and re-validate it when resuming a connection, the client SHOULD also cache the associated delegated credential and re-validate it. </del>  7.5.

Editorial changes from AD review.
Modulo adding the hyphen in between the I and the D (my bad) to make sure we get a normative reference to DTLS 1.3. This is good to go.

endpoint and the certification authority can create limitations.  For example, the lifetime of certificates, how they may be used, and the algorithms they support are ultimately determined by the  <ins> certification authority.  This document describes a mechanism to to overcome some of these limitations by enabling operators to delegate their own credentials for use in (D)TLS without breaking compatibility with peers that do not support this specification. </ins> 1. Typically, a (D)TLS server uses a certificate provided by some entity other than the operator of the server (a "Certification Authority" or  <ins> CA) RFC8446 RFC5280.  This organizational separation makes the (D)TLS server operator dependent on the CA for some aspects of its operations, for example: </ins> Whenever the server operator wants to deploy a new certificate, it has to interact with the CA. (*) indicates changes to the wire protocol. <ins> draft-11 Editorial changes based on AD comments Add support for DTLS Address address ambiguity in cert expiry </ins> draft-10 Address superficial comments It was noted in XPROT that certificates in use by servers that support outdated protocols such as SSLv2 can be used to forge signatures for certificates that contain the keyEncipherment KeyUsage  <ins> (RFC5280 section 4.2.1.3).  In order to reduce the risk of cross- protocol attacks on certificates that are not intended to be used with DC-capable TLS stacks, we define a new DelegationUsage extension to X.509 that permits use of delegated credentials.  (See certificate-requirements.) </ins> 3.1. X.509 semantics are very rich.  This can cause unintended consequences if a service owner creates a proxy certificate where  <ins> the properties differ from the leaf certificate.  Proxy certificates can be useful in controlled environments, but remain a risk in scenarios where the additional flexibility they provide are not necessary.  For this reason, delegated credentials have very restricted semantics that should not conflict with X.509 semantics. </ins> Proxy certificates rely on the certificate path building process to establish a binding between the proxy certificate and the end- interact with a back-end server that holds a private key.  The mechanism proposed in this document allows the delegation to be done off-line, with no per-transaction latency.  The figure below compares  <ins> the message flows for these two mechanisms with (D)TLS 1.3 RFC8446 I- D.ietf-tls-dtls13. </ins> These two mechanisms can be complementary.  A server could use delegated credentials for clients that support them, while using a server-side mechanism to support legacy clients.  Both mechanisms require a trusted relationship between the Front-End and Back-End - the delegated credential can be used in place of a certificate  <ins> private key. </ins> Use of short-lived certificates with automated certificate issuance, e.g., with Automated Certificate Management Environment (ACME) 6.  <ins> This document registers the "delegated_credential" extension in the "TLS ExtensionType Values" registry.  The "delegated_credential" </ins> extension has been assigned a code point of 34.  The IANA registry lists this extension as "Recommended" (i.e., "Y") and indicates that it may appear in the ClientHello (CH), CertificateRequest (CR), or  <ins> Certificate (CT) messages in (D)TLS 1.3 RFC8446 I-D.ietf-tls-dtls13. </ins> Additionally, the "DTLS-Only" column is assigned the value "N". This document also defines an ASN.1 module for the DelegationUsage Delegated credentials limit the exposure of the private key used in a (D)TLS connection by limiting its validity period.  An attacker who  <ins> compromises the private key of a delegated credential can impersonate the compromised party in new TLS connections until the delegated credential expires. However, they cannot create new delegated credentials.  Thus, delegated credentials should not be used to send a delegation to an untrusted party, but are meant to be used between parties that have some trust relationship with each other.  The secrecy of the delegated credential's private key is thus important and access control mechanisms SHOULD be used to protect it, including file system controls, physical security, or hardware security modules. </ins> 7.2. 7.4.  <ins> If a peer decides to cache the certificate chain and re-validate it when resuming a connection, they SHOULD also cache the associated delegated credential and re-validate it.  Failing to do so may result in resuming connections for which the DC has expired. </ins> 7.5.


(EC)DHE key establishment, thus providing forward secrecy. When PSKs are provisioned out of band, the PSK identity and the KDF <del> to be used with the PSK MUST also be provisioned.  Note: When using an out-of-band provisioned pre-shared secret, a critical consideration is using sufficient entropy during the key generation, as discussed in RFC4086.  Deriving a shared secret from a password or other low-entropy sources is not secure.  A low-entropy secret, or password, is subject to dictionary attacks based on the PSK binder. The specified PSK authentication is not a strong password-based authenticated key exchange even when used with Diffie-Hellman key establishment. </del>  2.3. the identities in the client's list. Each PSK is associated with a single Hash algorithm.  For PSKs <del> established via the ticket mechanism (NSTMessage), this is the Hash used for the KDF on the connection where the ticket was established. </del>  For externally established PSKs, the Hash algorithm MUST be set when the PSK is established, or default to SHA-256 if no such algorithm is defined.  The server must ensure that it selects a compatible PSK (if used first. Any ticket MUST only be resumed with a cipher suite that has the same <del> KDF hash as that used to establish the original connection, and only if the client provides the same SNI value as in the original </del>  connection, as described in Section 3 of RFC6066. Note: Although the resumption master secret depends on the client's Expand functions as defined for HKDF RFC5869, as well as the functions defined below: <del> The Hash function and the HKDF hash are the cipher suite hash algorithm.  Hash.length is its output length in bytes.  Messages are the concatenation of the indicated handshake messages, including the handshake message type and length fields, but not including record layer headers.  Note that in some cases a zero-length HashValue (indicated by "") is passed to HKDF-Expand-Label. </del>  Note: with common hash functions, any label longer than 12 characters requires an additional iteration of the hash function to compute.

HKDF-Expand-Label has changed between draft -19 and -20, clarify that "HDF Hash" refers to the hash algorithm and not a version-specific instance of HKDF-Expand-Label which is populated with a hash algorithm.

(EC)DHE key establishment, thus providing forward secrecy. When PSKs are provisioned out of band, the PSK identity and the KDF  <ins> hash algorithm to be used with the PSK MUST also be provisioned. Note: When using an out-of-band provisioned pre-shared secret, a critical consideration is using sufficient entropy during the key generation, as discussed in RFC4086.  Deriving a shared secret from a password or other low-entropy sources is not secure.  A low-entropy secret, or password, is subject to dictionary attacks based on the PSK binder.  The specified PSK authentication is not a strong password-based authenticated key exchange even when used with Diffie- Hellman key establishment. </ins> 2.3. the identities in the client's list. Each PSK is associated with a single Hash algorithm.  For PSKs  <ins> established via the ticket mechanism (NSTMessage), this is the KDF Hash algorithm on the connection where the ticket was established. </ins> For externally established PSKs, the Hash algorithm MUST be set when the PSK is established, or default to SHA-256 if no such algorithm is defined.  The server must ensure that it selects a compatible PSK (if used first. Any ticket MUST only be resumed with a cipher suite that has the same  <ins> KDF hash algorithm as that used to establish the original connection, and only if the client provides the same SNI value as in the original </ins> connection, as described in Section 3 of RFC6066. Note: Although the resumption master secret depends on the client's Expand functions as defined for HKDF RFC5869, as well as the functions defined below:  <ins> The Hash function used by Transcript-Hash and HKDF are the cipher suite hash algorithm.  Hash.length is its output length in bytes. Messages are the concatenation of the indicated handshake messages, including the handshake message type and length fields, but not including record layer headers.  Note that in some cases a zero- length HashValue (indicated by "") is passed to HKDF-Expand-Label. </ins> Note: with common hash functions, any label longer than 12 characters requires an additional iteration of the hash function to compute.


Sent by servers when a client "application_layer_protocol_negotiation" extension advertises <del> protocols that the server does not support. </del>  New Alert values are assigned by IANA as described in iana- considerations.

Follow up to PR . Add a link for the ALPN RFC to the relevant alert's description. (same as with other extension alerts above)
URL & No feature in the TLS 1.3 spec, optional or required, needs ALPN to work. We merely cite places where it needs to be taken into consideration if it is in use. It could be argued that it is an "optional feature" of TLS (as a whole), but not of this document, thus I don't think it meets the qualifications to be normative. I think staying as informative is correct.
There's a bunch of text that specifically mentions ALPN, some of it with normative statements. If those normative statements can't be understood, optional feature or not, then it's normative.

Sent by servers when a client "application_layer_protocol_negotiation" extension advertises  <ins> protocols that the server does not support (see RFC7301). </ins> New Alert values are assigned by IANA as described in iana- considerations.


%%% Updating Keys If the server sent an "early_data" extension, the client MUST send an <del> EndOfEarlyData after receiving the server Finished.  This indicates that all 0-RTT application_data messages, if any, have been transmitted and that the following records are protected under handshake traffic keys.  Servers MUST NOT send this message and clients receiving it MUST terminate the connection with an "unexpected_message" alert.  This message is encrypted under keys derived from the client_early_traffic_secret. </del>  4.6.

This follows naturally from the inclusion of EndOfEarlyData in the handshake transcript, but it doesn't hurt to mention it explicitly. See also, uh, 7511e2a259.
NAME I mention it explicitly because it tripped me up in implementation :)

%%% Updating Keys If the server sent an "early_data" extension, the client MUST send an  <ins> EndOfEarlyData message after receiving the server Finished.  If the server does not send an "early_data" extension, then the client MUST NOT send an EndOfEarlyData message.  This message indicates that all 0-RTT application_data messages, if any, have been transmitted and that the following records are protected under handshake traffic keys.  Servers MUST NOT send this message and clients receiving it MUST terminate the connection with an "unexpected_message" alert. This message is encrypted under keys derived from the client_early_traffic_secret. </ins> 4.6.


algorithm only if the "signature_algorithms" extension provided by the client permits it.  If the client cannot construct an acceptable chain using the provided certificates and decides to abort the <del> handshake, then it MUST abort the handshake with an "unsupported_certificate" alert. </del>  If the server has multiple certificates, it chooses one of them based on the above-mentioned criteria (in addition to other criteria, such

There are a number of different alerts that may be suitable for sending to indicate a non-acceptable cert chain, e.g. certificaterevoked, certificateexpired, unknown_ca, etc. We should not restrict the client to only sending one specific alert.
I have updated this PR with the wording as suggested by NAME

algorithm only if the "signature_algorithms" extension provided by the client permits it.  If the client cannot construct an acceptable chain using the provided certificates and decides to abort the  <ins> handshake, then it MUST abort the handshake with an appropriate certificate-related alert (by default, "unsupported_certificate"; see error-alerts for more). </ins> If the server has multiple certificates, it chooses one of them based on the above-mentioned criteria (in addition to other criteria, such


32 bytes generated by a secure random number generator.  See implementation-notes for additional information.  The last eight bytes MUST be overwritten as described below if negotiating TLS <del> 1.2 or TLS 1.1.  This structure is generated by the server and MUST be generated independently of the ClientHello.random. </del>  The single cipher suite selected by the server from the list in ClientHello.cipher_suites.  A client which receives a cipher suite one for each potential PSK; if no PSK is selected, it will then need to compute the early secret corresponding to the zero PSK.  7.2. Once the handshake is complete, it is possible for either side to

by Hugo Krawczyk.
Other than davegarrett's editorial notes, this looks good.

32 bytes generated by a secure random number generator.  See implementation-notes for additional information.  The last eight bytes MUST be overwritten as described below if negotiating TLS  <ins> 1.2 or TLS 1.1, but the remaining bytes MUST be random.  This structure is generated by the server and MUST be generated independently of the ClientHello.random. </ins> The single cipher suite selected by the server from the list in ClientHello.cipher_suites.  A client which receives a cipher suite one for each potential PSK; if no PSK is selected, it will then need to compute the early secret corresponding to the zero PSK. <ins> Once all the values which are to be derived from a given secret have been computed, that secret SHOULD be erased. </ins> 7.2. Once the handshake is complete, it is possible for either side to


Removed support for non-AEAD ciphers <del> 1.3. This document is a revision of the TLS 1.1 RFC4346 protocol which contains improved flexibility, particularly for negotiation of cryptographic algorithms.  The major changes are: The MD5/SHA-1 combination in the pseudorandom function (PRF) has been replaced with cipher-suite-specified PRFs.  All cipher suites in this document use P_SHA256. The MD5/SHA-1 combination in the digitally-signed element has been replaced with a single hash.  Signed elements now include a field that explicitly specifies the hash algorithm used. Substantial cleanup to the client's and server's ability to specify which hash and signature algorithms they will accept. Note that this also relaxes some of the constraints on signature and hash algorithms from previous versions of TLS. Addition of support for authenticated encryption with additional data modes. TLS Extensions definition and AES Cipher Suites were merged in from external TLSEXT and RFC3268. Tighter checking of EncryptedPreMasterSecret version numbers. Tightened up a number of requirements. Verify_data length now depends on the cipher suite (default is still 12). Cleaned up description of Bleichenbacher/Klima attack defenses. Alerts MUST now be sent in many cases. After a certificate_request, if no certificates are available, clients now MUST send an empty certificate list. TLS_RSA_WITH_AES_128_CBC_SHA is now the mandatory to implement cipher suite. Added HMAC-SHA256 cipher suites. Removed IDEA and DES cipher suites.  They are now deprecated and will be documented in a separate document. Support for the SSLv2 backward-compatible hello is now a MAY, not a SHOULD, with sending it a SHOULD NOT.  Support will probably become a SHOULD NOT in the future. Added limited "fall-through" to the presentation language to allow multiple case arms to have the same encoding. Added an Implementation Pitfalls sections The usual clarifications and editorial work. </del> 2. The goals of the TLS protocol, in order of priority, are as follows:

TLS 1.1 [RFC 4346] & TLS 1.2 [RFC 5246] each only have a list of changes from the immediately previous version. This current draft has both the current changelog since TLS 1.2 and the old list of changes from TLS 1.1 to 1.2. The contents of this old section are no longer relevant, in particular it mentions TLSRSAWITHAES128CBCSHA as MTI which is no longer permitted at all. Suggesting just removing this now.
Thanks. Merged.

Removed support for non-AEAD ciphers  2. The goals of the TLS protocol, in order of priority, are as follows:


alert" and "abort the handshake with a X alert" mean that the implementation MUST send alert X if it sends any alert.  All alerts defined in this section below, as well as all unknown alerts, are <del> universally considered fatal as of TLS 1.3 (see alert-protocol). The following error alerts are defined: </del>  An inappropriate message (e.g., the wrong handshake message, premature application data, etc.) was received.  This alert should

I disagree with this. Equally valid advice is to do as little as possible except abort the connection when receiving an alert. Some implementations will not send alerts at all.
NAME can you please raise this on the list in response to Kathleen's comments? Thanks
Per Kathleen's AD review

alert" and "abort the handshake with a X alert" mean that the implementation MUST send alert X if it sends any alert.  All alerts defined in this section below, as well as all unknown alerts, are  <ins> universally considered fatal as of TLS 1.3 (see alert-protocol).  The implementation SHOULD provide a way to facilitate logging the sending and receiving of alerts. </ins> An inappropriate message (e.g., the wrong handshake message, premature application data, etc.) was received.  This alert should


may appear in ClientHello messages from clients which are offering prior versions of TLS).  4.2.5. The "post_handshake_auth" extension is used to indicate that a client authentication) provided that the client has sent the "post_handshake_auth" extension (see post_handshake_auth). <del> 4.3.2.1. The "oid_filters" extension allows servers to provide a set of OID/ value pairs which it would like the client's certificate to match. This extension MUST only be sent in the CertificateRequest message. %%% Server Parameters Messages A list of certificate extension OIDs RFC5280 with their allowed values, represented in DER-encoded X690 format.  Some certificate extension OIDs allow multiple values (e.g., Extended Key Usage). If the server has included a non-empty certificate_extensions list, the client certificate included in the response MUST contain all of the specified extension OIDs that the client recognizes. For each extension OID recognized by the client, all of the specified values MUST be present in the client certificate (but the certificate MAY have other values as well).  However, the client MUST ignore and skip any unrecognized certificate extension OIDs.  If the client ignored some of the required certificate extension OIDs and supplied a certificate that does not satisfy the request, the server MAY at its discretion either continue the connection without client authentication, or abort the handshake with an "unsupported_certificate" alert.  PKIX RFCs define a variety of certificate extension OIDs and their corresponding value types.  Depending on the type, matching certificate extension values are not necessarily bitwise-equal.  It is expected that TLS implementations will rely on their PKI libraries to perform certificate selection using certificate extension OIDs. This document defines matching rules for two standard certificate extensions defined in RFC5280: The Key Usage extension in a certificate matches the request when all key usage bits asserted in the request are also asserted in the Key Usage certificate extension. The Extended Key Usage extension in a certificate matches the request when all key purpose OIDs present in the request are also found in the Extended Key Usage certificate extension. The special anyExtendedKeyUsage OID MUST NOT be used in the request. Separate specifications may define matching rules for other certificate extensions. </del> 4.4. As discussed in protocol-overview, TLS generally uses a common set of If the certificate_extensions list in the CertificateRequest message was non-empty, the end-entity certificate MUST match the <del> extension OIDs recognized by the client, as described in certificate-request. </del>  Note that, as with the server certificate, there are certificates that use algorithm combinations that cannot be currently used with

This was the one extension that wasn't in the extensions section, which made it hard to find. Note I've also removed the indent on the trailing paragraphs to avoid the walloftext problem with the existing text.
Does the part that says need to be updated to point to this new location instead of {{certificate-request}}?
Good catch. Fixed.
lgtm
merge this when ready

may appear in ClientHello messages from clients which are offering prior versions of TLS). <ins> 4.2.4.1. The "oid_filters" extension allows servers to provide a set of OID/ value pairs which it would like the client's certificate to match. This extension MUST only be sent in the CertificateRequest message. %%% Server Parameters Messages A list of certificate extension OIDs RFC5280 with their allowed values, represented in DER-encoded X690 format.  Some certificate extension OIDs allow multiple values (e.g., Extended Key Usage). If the server has included a non-empty certificate_extensions list, the client certificate included in the response MUST contain all of the specified extension OIDs that the client recognizes. For each extension OID recognized by the client, all of the specified values MUST be present in the client certificate (but the certificate MAY have other values as well).  However, the client MUST ignore and skip any unrecognized certificate extension OIDs.  If the client ignored some of the required certificate extension OIDs and supplied a certificate that does not satisfy the request, the server MAY at its discretion either continue the connection without client authentication, or abort the handshake with an "unsupported_certificate" alert. PKIX RFCs define a variety of certificate extension OIDs and their corresponding value types.  Depending on the type, matching certificate extension values are not necessarily bitwise-equal.  It is expected that TLS implementations will rely on their PKI libraries to perform certificate selection using certificate extension OIDs. This document defines matching rules for two standard certificate extensions defined in RFC5280: The Key Usage extension in a certificate matches the request when all key usage bits asserted in the request are also asserted in the Key Usage certificate extension. The Extended Key Usage extension in a certificate matches the request when all key purpose OIDs present in the request are also found in the Extended Key Usage certificate extension.  The special anyExtendedKeyUsage OID MUST NOT be used in the request. Separate specifications may define matching rules for other certificate extensions. </ins> 4.2.5. The "post_handshake_auth" extension is used to indicate that a client authentication) provided that the client has sent the "post_handshake_auth" extension (see post_handshake_auth).  4.4. As discussed in protocol-overview, TLS generally uses a common set of If the certificate_extensions list in the CertificateRequest message was non-empty, the end-entity certificate MUST match the  <ins> extension OIDs recognized by the client, as described in oid- filters. </ins> Note that, as with the server certificate, there are certificates that use algorithm combinations that cannot be currently used with


The cipher suite for use with this PSK <del> The Application-Layer Protocol Negotiation (ALPN) protocol, if any is to be used </del>  The Server Name Indication (SNI), if any is to be used

The reference to [RFC7301] is after the third mention of ALPN. It should instead be at the first reference to ALPN.

The cipher suite for use with this PSK  <ins> The Application-Layer Protocol Negotiation (ALPN) protocol RFC7301, if any is to be used </ins> The Server Name Indication (SNI), if any is to be used


Add a per-ticket nonce so that each ticket is associated with a different PSK (*).  Add discussion of 0-RTT and replay.  Recommend that implementations implement some anti-replay mechanism. Servers MAY send data after sending their first flight, but because the handshake is not yet complete, they have no assurance <del> of either the peer's identity or of it's liveness (i.e., the </del>  ClientHello might have been replayed). The key used to compute the finished message is computed from the

NAME NAME I would appreciate a sanity check here.
Maybe remove the "arguably" statement and the *

Add a per-ticket nonce so that each ticket is associated with a different PSK (*). <ins> Clarify that clients should change to sending with handshake keys immediately upon reading ServerHello.  Arguably a wire format change. (*). Update state machine to show rekeying events </ins> Add discussion of 0-RTT and replay.  Recommend that implementations implement some anti-replay mechanism. Servers MAY send data after sending their first flight, but because the handshake is not yet complete, they have no assurance  <ins> of either the peer's identity or of its liveness (i.e., the </ins> ClientHello might have been replayed). The key used to compute the finished message is computed from the


1.1. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <del> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 RFC2119. </del>  1.2.  draft-04 Remove renegotiation.

A straightforward cleanup of part of the backwards compatibility section. (handles an easy part of issue ) SSL 2.0 backwards compatibility was previously deprecated in TLS 1.2 (2008) and was warned to be "phased out with all due haste". RFC 6176 (2011) prohibits it entirely. It's a section of obsolete complexity still in the draft. Remove it and replace it with a simple "MUST NOT" send or accept. Edit to correct attribution of the "phased out with all due haste" language. Whilst in the TLS 1.2 (2008) spec, it was first introduced in SSL 3 (1996). It has been around for 19 years, not 5.
Dave, can you please post about this to the list?
I have to ask, why not SSL 3 as well?
This is about SSLv2 compatibility needing a different ClientHello format.
I completely agree that similar language should be added for SSL3 as well, however its prohibition RFC is not done yet. SSL2 was just an obvious start. I'll write another PR with the SSL3 prohibition draft language added in. URL
One possible idea if SSL 2.0 ClientHello compatibility is still needed is to max it at TLS 1.2.
There is discussion on list, but just let me say for the record here that I am astonished that this wasn't considered a non-controversial cleanup. The SSL2 hello has been deprecated for 20 years...
Per Brian's suggestion, this PR is now just for the changes with large agreement. Prohibiting all SSL v2 CLIENT-HELLO entirely is now moved to issue .
Per Brian's suggestion, splitting this off of PR . SSL v2 CLIENT-HELLO support requires additional implementation complexity that is an unnecessary risk to maintain support with a 20 year old deprecated negotiation format. Implementations have had notable bugs in handling this in the past. The current status quo expects them to be acceptable for negotiating TLS 1.0-1.2, even though ALL TLS clients are capable of using the SSL v3 version ClientHello if properly configured. Support for this has been optional and deprecated for many years, with the SSL 3 spec noting in 1996 that "The ability to send version 2.0 client hello messages will be phased out with all due haste. Implementers should make every effort to move forward as quickly as possible." Some implementers would be quite happy to have this prohibited entirely so that their code can finally be scrubbed clean of obsolete SSL 2 junk. Others want to perpetuate backwards compatibility support for EOL clients forever. I argue the former. A decision needs to be made on which path to chose. It will be depressing if it is to be the latter. :/
It is now no longer possible to use SSLv2 hellos with TLS 1.3 (because some extensions are mandatory) so we shouldn't need anythign here.

1.1. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",  <ins> "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 RFC2119. </ins> 1.2. <ins> draft-05 Prohibit SSL negotiation for backwards compatibility. </ins> draft-04 Remove renegotiation.


Messages are the concatenation of the indicated handshake messages, including the handshake message type and length fields, but not including record layer headers.  Note that in some cases a zero- <del> length HashValue (indicated by "") is passed to HKDF-Expand-Label. </del>  Note: with common hash functions, any label longer than 12 characters requires an additional iteration of the hash function to compute.

This is no longer a hash value throughout, using a different name might reduce confusion a little.
Seems like an improvement.+1

Messages are the concatenation of the indicated handshake messages, including the handshake message type and length fields, but not including record layer headers.  Note that in some cases a zero-  <ins> length Context (indicated by "") is passed to HKDF-Expand-Label. </ins> Note: with common hash functions, any label longer than 12 characters requires an additional iteration of the hash function to compute.


See NSTMessage for the use of the max_early_data_size field. The parameters for the 0-RTT data (symmetric cipher suite, ALPN <del> protocol, etc.) are the same as those which were negotiated in the connection which established the PSK.  The PSK used to encrypt the early data MUST be the first PSK listed in the client's "pre_shared_key" extension. </del>  For PSKs provisioned via NewSessionTicket, a server MUST validate that the ticket age for the selected PSK identity (computed by In order to accept early data, the server MUST have accepted a PSK cipher suite and selected the first key offered in the client's "pre_shared_key" extension.  In addition, it MUST verify that the <del> following values are consistent with those negotiated in the connection during which the ticket was established. </del>  <del> The TLS version number and cipher suite. </del>  <del> The selected ALPN RFC7301 protocol, if any. </del>  Future extensions MUST define their interaction with 0-RTT. Hash algorithm on the connection where the ticket was established. For externally established PSKs, the Hash algorithm MUST be set when the PSK is established, or default to SHA-256 if no such algorithm is <del> defined.  The server must ensure that it selects a compatible PSK (if </del>  any) and cipher suite.  Implementor's note: the most straightforward way to implement the PSK/cipher suite matching requirements is to negotiate the cipher suite first and then exclude any incompatible PSKs.  Any unknown PSKs use each ticket no more than once, with more recent tickets being used first. <del> Any ticket MUST only be resumed with a cipher suite that has the same KDF hash algorithm as that used to establish the original connection, and only if the client provides the same SNI value as in the original connection, as described in Section 3 of RFC6066. </del>  Note: Although the resumption master secret depends on the client's second flight, servers which do not request client authentication MAY

Both for 0-RTT and 1-RTT. Give NST- and externally-provisioned PSKs more uniform treatment.
NAME ping? It would be good to get some resolution in this space, as it's somewhat relevant to URL
I guess we could perhaps recommend that external PSKs not be provisioned with a SNI value, since the PSK value itself ought to serve as enough of a lookup key for what the intended communication semantics are.
NAME is there a path forward for this (e.g., does it need to go to the list)?
NAME I think this is generally good except for the SNI stuff which conflicts with PR , which we also need to resolve one way or another. What say we land this without those pieces and then when we we will know what to do
SGTM. Do you need me to adjust the patch?
Nah, I'll do it.
These actually just seem to make the SNI requirements clearer but no sharper, so merging.
The Early Data Indication section contains this sentence: The parameters for the 0-RTT data (symmetric cipher suite, ALPN protocol, etc.) are the same as those which were negotiated in the connection which established the PSK. This implies to me that you can only do 0-RTT where the PSK was established via an earlier connection. In external PSK this is not the case. I don't think this interpretation was the intention.
This is stale text from before we allowed 0-RTT with external PSK, IIRC.
Zero-RTT Data says: But 4.6.1. New Session Ticket Message says: For consistency, I would like to have the latter in Section 2.2 with the same style. Moreover, I would like to know where this differences of requirements come from.
I think 4.2.10 may be more appropriate than 2.2, as it is closer to where the server is doing the relevant processing.
Now 4.2.10 has clear requirements. So, why don't we remove the same requirement from 2.3? additional information MUST be provisioned to both parties:

See NSTMessage for the use of the max_early_data_size field. The parameters for the 0-RTT data (symmetric cipher suite, ALPN  <ins> protocol, etc.) are those associated with the PSK in use.  For externally established PSKs, the associated values are those provisioned along with the key.  For PSKs established via a NewSessionTicket message, the associated values are those which were negotiated in the connection which established the PSK.  The PSK used to encrypt the early data MUST be the first PSK listed in the client's "pre_shared_key" extension. </ins> For PSKs provisioned via NewSessionTicket, a server MUST validate that the ticket age for the selected PSK identity (computed by In order to accept early data, the server MUST have accepted a PSK cipher suite and selected the first key offered in the client's "pre_shared_key" extension.  In addition, it MUST verify that the  <ins> following values are consistent with those associated with the selected PSK: </ins>  <ins> The TLS version number </ins>  <ins> The selected cipher suite The selected ALPN RFC7301 protocol, if any The selected SNI (Section 3 of RFC6066) value, if any These requirements are a superset of those needed to perform a 1-RTT handshake using the PSK in question.  For externally established PSKs, the associated values are those provisioned along with the key. For PSKs established via a NewSessionTicket message, the associated values are those negotiated in the connection during which the ticket was established. </ins> Future extensions MUST define their interaction with 0-RTT. Hash algorithm on the connection where the ticket was established. For externally established PSKs, the Hash algorithm MUST be set when the PSK is established, or default to SHA-256 if no such algorithm is  <ins> defined.  The server MUST ensure that it selects a compatible PSK (if </ins> any) and cipher suite. <ins> Each PSK is also associated with at most one Server Name Identification (SNI) value (Section 3 of RFC6066).  For PSKs established via the ticket mechanism (NSTMessage), this is the SNI value (if any) on the connection where the ticket was established. For externally established PSKs, the associated SNI value (or lack of value) is set when the PSK is established.  The server MUST ensure that it selects a compatible PSK (if any) and SNI value (if any). SNI MUST NOT be negotiated when using a PSK not associated with an SNI value. </ins> Implementor's note: the most straightforward way to implement the PSK/cipher suite matching requirements is to negotiate the cipher suite first and then exclude any incompatible PSKs.  Any unknown PSKs use each ticket no more than once, with more recent tickets being used first.  <ins> Any ticket MUST only be resumed on connections where the following values match the values negotiated in the connection during which the ticket was established: The KDF hash algorithm associated with the cipher suite The SNI value (if any), as described in Section 3 of </ins> Note: Although the resumption master secret depends on the client's second flight, servers which do not request client authentication MAY