Lifetime, expiry, and validity of certificates and PSKs

[emanjon]

3GPP has a lot of use cases with (D)TLS and they keep increasing. Most of them use X509 but there are a few uses of external PSKs. The external PSKs in 3GPP have a lifetime and after that they expire, exactly like a certificate. This is common also in other uses of TLS with external PSKs. When working on this we noted that RFC8446 does not say anything about what to do when the external PSK expire. There is also no way to signal the expiry with an alert similar to certificate_expired.

When working on DTLS/SCRP for 3GPP we noted that TLS 1.3 does not have post-handshake server authentication. Mutually authenticated TLS is not used much on the Web but is very commonly used in a lot of other industries. Best practice for certificate lifetimes keeps changing towards shorter and shorter lifetimes. When working on this we noted that RFC8446 does not give any normative statement on what to do when a certificate expires. (Note that the currently suggestion in RFC6083bis is to set up new connections frequently instead so this is not a problem there).

How should the expiry of an external PSK be signaled with an alert? Would it be a new alert

external_psk_expired: The external PSK has expired or is not currently valid.

Or should certificate_expired be redefined?

certificate_expired: A credential used for authentication has expired or is not

I think TLS 1.3 also need to say something on what to do when the authentication credential expire. As far as I can see, the connection would have to be terminated unless there has been some post-handshake authentication. I would suggest something like this:

If the certificate or external PSK last used by a party has expired, the other party MUST terminate the connection with a "certificate_expired" alert.

[tomato42]

This area is definitely underspecified, I'd be for double duty of the certificate_expired alert as both the cause and the expected course of action is fundamentally the same.

But for X.509 there is another expiry date for the used credential: freshness of the revocation information (be it CRL or OCSP). I wonder if we couldn't add a new message to transmit up to date OCSP response for the certificate? Then reuse it for proof of possession of the updated PSK?

[emanjon]

There were some good comments from Ilari Liusvaara and Viktor Dukhovni on the UTA list regarding responsibilities between TLS and the application as well as resumption PSKs. They point out that Certificate and PSK lifetimes is mostly the application's responsibility. Ilari points out that tickets also have lifetimes. TLS should probably have an alert indicating that the connection was closed because the ticket lifetime expired.

Ticket expiry should maybe be a new alert. A resumption connection could be closed because the ticket expire or the external PSK/certificate expire.

Certificate and PSK lifetimes are the responsibility of the application using TLS so the normative text suggested above is likely to strong. Ticket lifetimes are strictly the responsibility of TLS. MUST terminate the connection might be too brutal, the application might want to show some warning to the user (but should have done so before the expiry).

Maybe something like this would be reasonable:

If the ticket lifetime has expired, the server SHOULD terminate the connection with a "ticket_expired" alert. If the certificate or external PSK last used by a party has expired or is not currently valid, the application of the other party can terminate the connection with a "certificate_expired" alert. Continuing a connection when the key used for authentication has expired or is not valid is NOT RECOMMENDED. To avoid this, the parties should perform post-handshake authentication or set up a new connection before this happens.

Regarding updated OCSP, that is currently possible for the client, but only combined with reauthentication. I think TLS needs more work for long term connections. The only current solution is to set up new connections, but that may be complicated in some use cases.

Some years ago TLS 1.2 had a 24 h recommended lifetime for session IDs and certificates often had lifetimes of many years. Today certificates are getting shorter and shorted lifetimes and more and more applications do revocation checking. Having short certificate lifetimes does not make much sense if the connections can last forever.

[emanjon]

Viktor Dukhovni made a good point in UTA that this is an authorization problem. An alternative to terminating the connection is to consider the other party unauthenticated. That might be a better solution. An application that does not accept unauthorized parties would not send any application data, ask for post-handshake authentication, or close the connection.

I agree with @tomato42 that this is an underspecified area. TLS can put some but not all responsibilities to the application. Considerations are needed and some mechanisms are missing.

[richsalz]

TLS should probably have an alert indicating that the connection was closed because the ticket lifetime expired.

I would prefer we keep moving away from specific alerts.

[emanjon]

Based on the comments from Hubert and Rich, I made a PR suggesting expanding the the duty of certificate_revoked, certificate_expired, certificate_unknown to PSKs (external and resumption).

#1251

[ekr]

It turns out we already have "unknown_psk_identity"

unknown_psk_identity:
: Sent by servers when PSK key establishment is desired but no
acceptable PSK identity is provided by the client. Sending this alert
is OPTIONAL; servers MAY instead choose to send a "decrypt_error"
alert to merely indicate an invalid PSK identity.

This seems to fit the bill.

[ekr]

Aargh. I should have read my own comments. This is no change needed.