> -----Original Message----- > From: TLS <tls-boun...@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 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
