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

> -----Original Message-----
> From: TLS <tls-bounces@ietf.org> On Behalf Of Viktor Dukhovni, Sent: Montag, 8. März 2021 19:05
> > 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.
Yes, that would be one scenario. 

> 
> 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.
True, which requires either a timer to do the checks periodically (either using CRL or OCSP) or a trigger when a new CRL is locally available.
So I already gathered, that this may be the solution.

> 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.
Agree. This would be the case, in which the receiver may have no access to an OCSP responder.


> 
> 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, ...
While this may be a solution in general, it may not fit for power systems (like a substation). 
The application of DNSSEC or DANE is not very common and may not be used. Also due to 
Existing deployments, which do not feature these services (yet). 

Regards
Steffen
> 
> --
>     Viktor.
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls