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

[Eric Rescorla <[e-mail]>]

On Fri, Mar 5, 2021 at 11:38 AM Watson Ladd <[e-mail]> wrote:

> On Fri, Mar 5, 2021, 10:43 AM John Mattsson
> <john.mattsson=[e-mail]> 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.
>
> The application traffic secret N+1 and the security of the
> authentication is unaffected by compromise of key N AFAIK. I'm not
> sure what property you want here that is stronger.
>

It seems to me that there are potentially two distinct properties here:

1. Post-Compromise Security in the case where the traffic keys were leaked
2. Re-authentication of the server.

Id like to understand the second use case better.

Assume that Alice connects to Bob and Bob authenticates with certificate X
which is valid at the time. As long as Bob's certificate remains valid, I'm
not sure that any new TLS behavior is required. I.e., Alice is free to
re-validate the certificate (i.e., check for revocation) but it's not clear
to me that as long as it is valid, it is necessary for Bob to re-prove
possession of the key. The primary threat that the defends against is an
un-detected temporary misuse of Bob's key at a prior time, which seems
distinct from future compromise. So, it seems like you can just re-validate
the key and then abort the connection if that fails, as Rich Salz suggests.

This leaves us with the case where Bob's certificate is no longer valid but
Bob has a new certificate [0]. In this case, just re-validating does not
help. Does that happen so often that we need protocol machinery other than
just tearing down the connection and starting over?

-Ekr

[0] Potentially, with a different key, though just assuming that because
the key is the same you can transplant the new identity on seems dangerous,
as we usually want to sign over the identities.