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

From: "Fries, Steffen" <[email-masked]>
Date: Fri, 5 Mar 2021 14:01:52 +0000

Hello all

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. 

The background is that for the securing TCP based communication in power system automation we defined the application of TLS in IEC 62351-3. The document specifies how to use TLS v1.2 in this environment. As some of the connections are rather long lasting connections, the document defines the usage of TLS session renegotiation at least every 24 hours to update the session key material on one hand and to enforce the certificate verification from both sides (TLS is always used with mutual authentication) including the revocation check. The 24 hours were motivated by an expected CRL update once a day. 

As TLS 1.3 is available the consequent next step is the consideration also for power system automation. In TLS 1.3 session renegotiation is not available anymore. The session key update can easily be addressed by the post-handshake messages. For performing a certificate based authentication during the session I understood one could use the post-handshake authentication approach. But this seems to be available only for a client side authentication. Is there any option in TLS to also enforce a server side authentication during an ongoing session?  Again, the reason for a certificate based authentication is to have a trigger for the revocation check of the certificates used in the initial handshake. If post-handshake certificate based authentication is not supported in TLS 1.3, it would require to have a separate mechanism/process that checks the revocation state of the certificates utilized in the initial handshake. 

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

Best regards
Steffen

--
Steffen Fries
Siemens AG

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 5 Mar 2021 13:13:57 -0500

On Fri, Mar 05, 2021 at 02:01:52PM +0000, 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. 
> 
> The background is that for the securing TCP based communication in
> power system automation we defined the application of TLS in IEC
> 62351-3. The document specifies how to use TLS v1.2 in this
> environment. As some of the connections are rather long lasting
> connections, the document defines the usage of TLS session
> renegotiation at least every 24 hours to update the session key
> material on one hand and to enforce the certificate verification from
> both sides (TLS is always used with mutual authentication) including
> the revocation check. The 24 hours were motivated by an expected CRL
> update once a day. 

This harks back to another recent thread where it was noted that one
needs to make a distinction between authentication and authorisation.

The integrity of a TLS 1.3 session (which always performs ephemeral key
agreement that offers forward-secrecy) is not compromised if later the
signing keys of one of the parties is compromised.  So there is no need
to check CRLs or renegotiate to just to maintain a secure connection.

On the server side, if the client's identity is used as a key into an
authorisation table, one just needs to periodically (or even at each
logical request) to revalidate the client's authorisation, there is
generally no need to "re-authenticate" the client.

If the client is presenting bearer-tokens for entitlement, the client
may periodically need to obtain fresh tokens.

If there is a concern that a server may somehow mid-session cease to be
a legitimate application endpoint for clients that are still connected
to it, and an expectation that timely CRLs and periodic revalidation
of the server certificate would help to avoid that, then perhaps
something should be done.

This feels to me like rather a very distant risk.  When a server is
taken out of rotation, the operator should typically terminate all
client connections at that time.  How often would one expect to
lose operational control of a running server, such that the only
way to protect active clients is via certificate revocation, with
clients finding out soon enough for this to be useful?

If loss of operational control of servers is a real concern, then I
guess clients should avoid long-lived sessions, and open new connections
frequently, limiting connection reuse and TLS session resumption to just
minutes (just to amortise the cost of the initial handshake over a short
sequence of back-to-back requests).

Once there's a new TLS session every ~5 minutes, there's no need for
CRLs, renegotiation, ... but a quick sequence of requests is still
handled efficiently.

So, in summary, avoid CRLs, OCSP, ... they're obsolete crutches.  Use
short-lived certificates (possibly just days or hours), reconnect often
if that's appropriate.  Demand fresh authorisation tokens from clients
if authorisation is encoded in the tokens, rather than checked out
of band by the server on a request-by-request basis.

-- 
    Viktor.

---

From: Nico Williams <[email-masked]>
Date: Sat, 6 Mar 2021 00:07:01 -0600

> generally no need to "re-authenticate" the client.

Yes, authorization is probably getting conflated here.  Suppose the
authorization is local and slow to be updated.  E.g., when an employee
separates from their employer, local authorization may not get updated
with much celerity, so if the subject's certificate expires sooner than
local authz could get updated, then re-authenticating the subject would
help.  (This assumes credentials do expire with celerity, but that is
good practice.)

That might seem weird, but consider a stateful file server, something
like NFSv4, say, and suppose that a client connects, authenticates,
successfully opens some file to which they were authorized and... maybe
now they can use that open file reference forever, much as one expects
in POSIX.  Except NFSv4 will require reauthentication though, so the
client cannot in fact use that open file reference forever.  But the
NFSv4 server (I think) will not re-evaluate ACLs for existing open file
handles as the ACLs change (per POSIX).  Re-authenticating the client
does serve something of an authorization purpose in the file server
example.  (Of course, a file server doesn't need to hew to POSIX on
this, and could re-evaluate ACLs for open file references, and/or it
could have a revocation feature like BSD's revoke(2) that lets users
forcibly close open file references.)

> [...]

+1