Re: [TLS] Question to TLS 1.3 and certificate revocation checks in long lasting connections

[Viktor Dukhovni <[e-mail]>]

On Mon, Mar 08, 2021 at 08:51:31AM +0000, Fries, Steffen wrote:

> The problem that was addressed so far with the session renegotiation in TLS 1.2 was motivated by different points. 
>
> - Recommendation in RFC 5246 regarding the use of the SessionID  lifetime
> - Regular session key update for the ongoing TLS Session
> - Trigger to verify the certificates used by both sides on a regular
>   base, ideally in relation to the update of locally available
>   revocation information
> 
> For the latter, the assumption was that some of the processes, when a
> long term key is compromised, may not be perfectly synchronized,
> meaning that the entity with a potentially compromised
> certificate/private key (long term key) is not immediately taken from
> the network.

So it sounds like the concern is that the key may have already been
compromised at the time the session was established, but was not yet
published on a CRL?  And so you want to keep checking the CRL
periodically, in case the client is talking to an MiTM attacker,
and it isn't too late to undo the damage.

Now of course the client can just check its CRL any time it wants,
without redoing the handshake.  It typically has (or can arrange to
retain) the server's certificate chain from the initial handshake.

So the only case that comes to mind where a new handshake is needed to
refresh the certificate validity is with stapled OCSP, where the server
is the source of the certificate freshness data.

My take is such measures are much too complicated.  Just keep the
connection lifetime short, and make a new one from time to time.  Also
keep certificate lifetimes short.  Where DNSSEC is an option on both
ends, you can also use DANE TLSA records instead of CRLs, just publish a
"1 1 1" (PKIX + DANE) or "3 1 1" (DANE only) record that validates the
server's public key, and give it a short-enough TTL that it can be
replaced quickly.  Presto-magic, no need for OCSP, CRLs, ...

-- 
    Viktor.