crypto/tls: cap lifetime of authentication in TLS 1.3

[FiloSottile]

In TLS 1.3, session resumptions rotate the key material, so we have been willing to let chains of resumptions go on unlimitedly.

@rbqvq pointed out in private, in #77217, and in CL 738761 that it might still be desirable to force the peer to periodically prove control over the certificate's private key.

As @rbqvq reports BoringSSL has such a cap, and nginx applies it also when using OpenSSL (which instead has the same behavior as we do openssl/openssl#19341).

It'd probably make sense to match BoringSSL here.

[rbqvq]

Acked.

Let's update with CL tomorrow.

[rbqvq]

In addition, there is a point to be discussed.

Personally, I think the default seven-day window is too long.

For connections with client authentication, perhaps we can consider a shorter time window (e.g. 1 day or 2 day)

[gabyhelp]

Related Issues

• crypto/tls: certificate chains aren't re-checked on resumption #77217

Related Code Changes

• crypto/tls: add identity freshness on server resumption
• crypto/tls: lightweight verified chain checking during resumption

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[gopherbot]

Change https://go.dev/cl/738761 mentions this issue: crypto/tls: add identity freshness on server resumption