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

[John Mattsson <[e-mail]>]

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

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 DTLS/SCTP with DTLS 1.3:

       {KeyShareEntry}         -------->
                                              {KeyShareEntry}
                                          {CertificateVerify}  
                               <--------           {Finished}  
       {CertificateVerify}
       {Finished}              -------->


               Derive-Secret( ... ) = exporter_secret_N

Cheers,
John

-----Original Message-----
From: Nico Williams <[e-mail]>
Date: Friday, 5 March 2021 at 18:35
To: John Mattsson <[e-mail]>
Cc: "Fries, Steffen" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: [TLS] Question to TLS 1.3 and certificate revocation checks in long lasting connections

On Fri, Mar 05, 2021 at 05:01:04PM +0000, John Mattsson wrote:
> On Friday, 5 March 2021 at 15:02, Fries, Steffen wrote:
> > I've got a question regarding application of TLS 1.3 to protect long
> > lasting  connections. Specifically on the trigger to perform a
> > revocation check for the utilized certificates in the handshake. 

You can perform OCSP or CRL checks on the RPs at any time.  You don't
need a protocol trigger for it.  You can use a timer.

The issue is that the EE certificate (or intermediates in the chain
perhaps) could expire or be replaced before the connection ends, and
then you might want the EE to present a new certificate and, if for a
new key, then also a proof of possession.  One could use session
renegotiation back when it existed, but it does not now.

> > Hence the question if there is a feature in TLS 1.3, which would
> > provide the functionality to invoke a mutual certificate based
> > authentication.

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.

Authenticating the client to the server and vice-versa would be
independent, at least when using certificates, though not so much when
using PSK.  Each relying party would send a CertificateRequest message
on a timer based on local configuration of certificate freshness policy
and/or the peer's certificate's expiration time, or whatever you like.

Nico
--