Re: [TLS] Question to TLS 1.3 and certificate revocation checks in long lasting connections
Viktor Dukhovni <ietf-dane@dukhovni.org> Fri, 05 March 2021 18:14 UTC
Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD2033A295E for <tls@ietfa.amsl.com>; Fri, 5 Mar 2021 10:14:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id adEK-IdIA63M for <tls@ietfa.amsl.com>; Fri, 5 Mar 2021 10:13:59 -0800 (PST)
Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55C883A295D for <tls@ietf.org>; Fri, 5 Mar 2021 10:13:59 -0800 (PST)
Received: by straasha.imrryr.org (Postfix, from userid 1001) id 2711BC7556; Fri, 5 Mar 2021 13:13:57 -0500 (EST)
Date: Fri, 05 Mar 2021 13:13:57 -0500
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: tls@ietf.org
Message-ID: <YEJ05QPD7pwP8yFE@straasha.imrryr.org>
Reply-To: tls@ietf.org
References: <f3afdea307594d4f8cf1a81f09c57aa9@siemens.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <f3afdea307594d4f8cf1a81f09c57aa9@siemens.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/HMRy3PAC_pURJTAV9dIeN4vHbnc>
Subject: Re: [TLS] Question to TLS 1.3 and certificate revocation checks in long lasting connections
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Mar 2021 18:14:01 -0000
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.
- [TLS] Question to TLS 1.3 and certificate revocat… Fries, Steffen
- Re: [TLS] Question to TLS 1.3 and certificate rev… John Mattsson
- Re: [TLS] Question to TLS 1.3 and certificate rev… Salz, Rich
- Re: [TLS] Question to TLS 1.3 and certificate rev… Nico Williams
- Re: [TLS] Question to TLS 1.3 and certificate rev… Viktor Dukhovni
- Re: [TLS] Question to TLS 1.3 and certificate rev… John Mattsson
- Re: [TLS] Question to TLS 1.3 and certificate rev… Nico Williams
- Re: [TLS] Question to TLS 1.3 and certificate rev… Watson Ladd
- Re: [TLS] Question to TLS 1.3 and certificate rev… Eric Rescorla
- Re: [TLS] Question to TLS 1.3 and certificate rev… Nico Williams
- Re: [TLS] Question to TLS 1.3 and certificate rev… Nico Williams
- Re: [TLS] Question to TLS 1.3 and certificate rev… Viktor Dukhovni
- Re: [TLS] Question to TLS 1.3 and certificate rev… Peter Gutmann
- Re: [TLS] Question to TLS 1.3 and certificate rev… Nico Williams
- Re: [TLS] Question to TLS 1.3 and certificate rev… Nico Williams
- Re: [TLS] Question to TLS 1.3 and certificate rev… Hannes Tschofenig
- Re: [TLS] Question to TLS 1.3 and certificate rev… Peter Gutmann
- Re: [TLS] Question to TLS 1.3 and certificate rev… Graham Bartlett
- Re: [TLS] Question to TLS 1.3 and certificate rev… Deb Cooley
- Re: [TLS] Question to TLS 1.3 and certificate rev… Graham Bartlett
- Re: [TLS] Question to TLS 1.3 and certificate rev… Hannes Tschofenig
- Re: [TLS] Question to TLS 1.3 and certificate rev… Hannes Tschofenig
- Re: [TLS] Question to TLS 1.3 and certificate rev… Benjamin Kaduk
- Re: [TLS] Question to TLS 1.3 and certificate rev… Graham Bartlett
- Re: [TLS] Question to TLS 1.3 and certificate rev… Nico Williams
- Re: [TLS] Question to TLS 1.3 and certificate rev… Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] Question to TLS 1.3 and certificate rev… Nico Williams
- Re: [TLS] Question to TLS 1.3 and certificate rev… Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] Question to TLS 1.3 and certificate rev… Nico Williams
- Re: [TLS] Question to TLS 1.3 and certificate rev… Viktor Dukhovni
- Re: [TLS] Question to TLS 1.3 and certificate rev… Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] Question to TLS 1.3 and certificate rev… Peter Gutmann
- Re: [TLS] Question to TLS 1.3 and certificate rev… Benjamin Kaduk
- Re: [TLS] Question to TLS 1.3 and certificate rev… Viktor Dukhovni
- Re: [TLS] Question to TLS 1.3 and certificate rev… Peter Gutmann
- Re: [TLS] Question to TLS 1.3 and certificate rev… Viktor Dukhovni
- Re: [TLS] Question to TLS 1.3 and certificate rev… Olle E. Johansson
- Re: [TLS] Question to TLS 1.3 and certificate rev… Fries, Steffen
- Re: [TLS] Question to TLS 1.3 and certificate rev… Salz, Rich
- Re: [TLS] Question to TLS 1.3 and certificate rev… Viktor Dukhovni
- Re: [TLS] Question to TLS 1.3 and certificate rev… Fries, Steffen
- Re: [TLS] Question to TLS 1.3 and certificate rev… Viktor Dukhovni
- Re: [TLS] Question to TLS 1.3 and certificate rev… Jonathan Hoyland
- Re: [TLS] Question to TLS 1.3 and certificate rev… Fries, Steffen
- Re: [TLS] Question to TLS 1.3 and certificate rev… Fries, Steffen
- Re: [TLS] Question to TLS 1.3 and certificate rev… Jonathan Hoyland