On Fri, Mar 5, 2021 at 11:38 AM Watson Ladd <watsonbl...@gmail.com> wrote:
> On Fri, Mar 5, 2021, 10:43 AM John Mattsson > <john.mattsson=40ericsson....@dmarc.ietf.org> 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.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
