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

[Nico Williams <[e-mail]>]

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
--