Hi, First of all thanks for all the discussion on that question, which is great input also to the discussion in IEC.
> From: TLS <tls-boun...@ietf.org> On Behalf Of Hannes Tschofenig > I think it is useful to start with the problem description. 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. If the certificate is put onto a CRL , the RP would realize this during the next complete handshake and tear down the connection. An alternative of this could indeed be to utilize an external trigger like whenever the CRL is refreshed (which should happen every 24 hours), the certificates of ongoing connections are validated regarding their status. As this is independent of TLS, it would work also with TLS 1.3. By comparing, what has been used in TLS 1.2 we simply stumbled about the fact that the trigger to perform the revocation check is no longer available for both sides, client and server. As said, the client could be authenticated using post authentication but not the server. This would mean to solve the problem of identifying a revoked certificate in an ongoing session could be done externally of TLS but the result would be fed back to TLS, if a connection needs to be closed due to a revoked certificate. Regards Steffen > > It seems that you are concerned that there is a possibility for leakage or > compromise of keying material during the lifetime of the session. > What could happen? > > * Long-term keys*, > * Some keys used in the key hierarchy, > * keys used for protecting the application traffic > > Additionally, you could also consider the case that the trust anchor store > gets > compromised. > > In any case, you seem to be concerned about the leakage of long-term keys (at > least that's what I get from the email thread). > > If your long-term keys got compromised then you have a serious problem. Re- > running even the full handshake will not indicate problem. It will just work > fine. > > You will somehow have to find out that these long-term keys have been leaked, > which will not be easy. Then, you need to isolate the endpoints using those > compromised keys and reprovision new keys to them. You might want to > terminate ongoing connections as well. Since you will often not know what > exactly has been compromised (at least not quickly enough), you might need to > take a range of steps to re-set it to a known good state (such as doing a > firmware update, in case of an IoT device). > > Many of these aspects are, however, outside the scope of TLS itself. > > Could you elaborate on the threats you are trying to address? > > Ciao > Hannes > > *: Often a device has more than one long-term key pair (used for different > purposes). Without further complicating things, the impact depend a bit on > which keys have been leaked. > > -----Original Message----- > From: TLS <tls-boun...@ietf.org> On Behalf Of Nico Williams > Sent: Friday, March 5, 2021 8:35 PM > To: John Mattsson <john.matts...@ericsson.com> > Cc: tls@ietf.org > Subject: Re: [TLS] Question to TLS 1.3 and certificate revocation checks in > long > lasting connections > > On Fri, Mar 05, 2021 at 06:42:40PM +0000, John Mattsson wrote: > > >While renegotiation will never be re-added, there is post-handshake > > >authentication (RFC 8446, section 4.6.2), and while that is currently > > >about authenticating the _client_ to the server, it should be trivial > > >to extend the protocol to support re-authenticating the server to the > > >client as well. > > > > I think the current Post-Handshake authentication is not really > > suitable for long-term connections. It assures that the other party is > > still alive but it does not shut out any other third parties with > > access to application_traffic_secret_N. Such parties may have gotten > > the key with or without collaboration with one of the nodes. > > We assume local security, so the only way the TLS keys could have leaked to > third parties is if either a) the local security assumption fails, in which > case you > have bigger problems, or b) the cryptographic security of TLS itself failed, > in > which case you have bigger problems, or c) you're exceeding usage limits on a > symmetric cipher. > > Changing session keys wouldn't help you in cases (a) or (b). > > I think the only interesting case is (c). If you're using a 128-bit block > cipher, > you're not in case (c) as you'd have to transfer something like 2PB before you > exceed AES key usage limits. > > At some point you have to be prepared to reconnect. Application protocols > that > work like BGP (destroy the world on RST) simply need to be fixed to not do > that. > > > Agree that the negotiation part of renegotiation should not come back. > > Below is a sketch of what I think would be needed Post-Handshake for > > That's essentially renego-lite. Note that there's protocol timing trickiness > in > getting this right. SSHv2, which does have proper re-keying, has experience > with > that. > > > DTLS/SCTP with DTLS 1.3: > > What's special about DTLS vs. TLS? Why should one get this but not the other? > > Nico > -- > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, > please notify the sender immediately and do not disclose the contents to any > other person, use it for any purpose, or store or copy the information in any > medium. Thank you. > > _______________________________________________ > 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
