Re: [TLS] I-D Action: draft-housley-tls-tls13-cert-with-extern-psk-02.txt

[Russ Housley <[e-mail]>]

David:

Thanks for reading the draft.

> The resumption flow in this draft looks odd to me. While the handshake flow is the same, the use cases differ between which identity should be in play and when to use it. Separate extensions and documents may be better. (I suppose saying the semantics change completely between resumption and external PSK is also an option, but that seems weird?)

This was my initial approach, offering just the certificate with an external PSK in the document, but Nick and Martin asked for the resumption PSK to be added.  I wish you had spoken back then ...

> First, identities:
> 
> In the external PSK use case, my read is you intend for the certificate to still be the server identity? It seems external PSK is just meant as extra input to the key schedule and not authentication since it may be shared amongst a group. (I'll note that, if your concern is we've lost all our asymmetric crypto, trusting the CertificateVerify for authentication is a little fuzzy. Is the scenario that the group is trusted not to attack each other?)

No, that is not the concern.  I want to mix a PSK into the key schedule today, then in the future when a large-scale quantum computer comes into existence, the communications that were recorded are still unable to be decrypted, even though the attacker can learn the (EC)DHE shared secret.

Thus, I can trust the CertificateVerify today for authentication, but I am also relying on the external PSK for the long-term protection of the session content.

> The use case for resumption is very different. The one I'm familiar with is to avoid a resumption/0-RTT cliff when the client considers the CertificateVerify expired. As before, It needs to be clearly defined which identity is in use. This is particularly complicated with 0-RTT, where only the PSK is available for early data, and swapping identities is problematic. (HTTP/2 cross-name pooling gets especially messy.)
> 
> This conflicts with the external PSK case which wants the certificate identity. The document addresses this in 3.3, by requiring the two to be identical, but this breaks much of the use case. It's rather common for servers to rotate certificates without dropping their session cache, to avoid a resumption cliff. (This assumes the protocol, e.g., HTTPS, does not care exactly which certificate is used, just that they are valid for a name.) This proposal leaves a gap in that scenario and means such servers must add extra state to sessions and conditionally disable 0-RTT in some cases.
> 
> Such servers could fall back to 1-RTT resumption, which could use the certificate and ignore the PSK, but this mechanism is not very useful without 0-RTT. The benefit of 1-RTT resumption is bandwidth and CPU from not sending the certificate. But 1-RTT resumption/certs sends the certificate anyway. You may as well just do a full handshake.

Dealing with the use cases that were advocated by Nick and Martin, I cam up with this approach:

       IF client includes early_data
       /* prove server still has access to private key */
       THEN
               send_client_hello(early_data, resumption_psk)
               get_server_hello(msg)
               IF msg.cert ^= context.previous_cert
               THEN
                       send_error_alert(certificate_unknown)
                       abort_connection

       /* allow server to change certificate and private key */
       ELSE
               send_client_hello(NULL, resumption_psk)
               get_server_hello(msg)
               IF msg.cert ^= context.previous_cert
               THEN
                       context.previous_cert = msg.cert

This avoids any change of identity when early_data is present.


> Second, when to use it:
> 
> In the external PSK case, I gather the goal is to use the external PSK all the time? It carries no auth, so expiry is fuzzy. If you support it, you enable it.
> 
> The resumption use case involves the client expiring the CertificateVerify signature. This is purely client policy which the server doesn't know a priori. Long before the signature is expired, the server shouldn't use tls_cert_with_psk because it's a bandwidth+CPU waste. After the signature has expired is too late. The client wouldn't be willing to encrypt early data at that point. (The client would also need to account for servers that don't support this draft.) tls_cert_with_psk should be used before but near expiry.
> 
> The advertisement then wants extra meaning: I offered you a PSK identity (with some early data if you accept it) that I will accept instead of your certificate, but it is nearing expiry. Renewals will be rejected soon. So, in addition to using the PSK, consider re-asserting ownership of your certificate, to keep renewals useful.
> 
> 
> These two together suggest a slightly different design for in the resumption case.
> 1. If the client's session is, say, 75% of the way through the CertificateVerify life adds the extension. Otherwise, it omits it.
> 2. The server can acknowledge this extension to do PSK+Certs. Probably with 0-RTT as it's largely pointless otherwise.
> 3. The connection is authenticated with the PSK as before.
> 4. But any tickets issued off the connection authenticated with the certificate, which may be different.

Martin spoke for a positive confirmation that the server still has access to the private key.  I do not see that with step 3.

> Finally, on a more minor note:
> 
>    TLS 1.3 does not permit the server to send a CertificateRequest
>    message when a PSK is being used.  This restriction is removed when
>    the "tls_cert_with_psk" extension is negotiated, allowing the
>    certificate-based authentication for both the client and the server.
>    If certificate-based client authentication is desired, this is
>    accomplished by the client sending the Certificate and
>    CertificateVerify messages as described in Sections 4.4.2 and 4.4.3
>    of [RFC8446].
> 
> This restriction should be retained with 0-RTT, otherwise things become really strange with the connection's client identity changing partway through.

Martin spoke for the use of early_data when the server is using the same certificate.  If you look at the previous version of may draft, you will see it is aligned with your approach.

Russ