Re: [TLS] Question to TLS 1.3 and certificate revocation checks in long lasting connections
Viktor Dukhovni <ietf-dane@dukhovni.org> Mon, 08 March 2021 00:05 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 E9D063A1F78 for <tls@ietfa.amsl.com>; Sun, 7 Mar 2021 16:05:36 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 E97g90DC2RvZ for <tls@ietfa.amsl.com>; Sun, 7 Mar 2021 16:05:35 -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 973073A1F77 for <tls@ietf.org>; Sun, 7 Mar 2021 16:05:35 -0800 (PST)
Received: by straasha.imrryr.org (Postfix, from userid 1001) id 897D8C8E02; Sun, 7 Mar 2021 19:05:34 -0500 (EST)
Date: Sun, 07 Mar 2021 19:05:34 -0500
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: tls@ietf.org
Message-ID: <YEVqToCtAMgT3Swu@straasha.imrryr.org>
Reply-To: tls@ietf.org
References: <20210305173516.GV30153@localhost> <701E874C-EA40-47FD-A4E4-C4C595E96337@ericsson.com> <CACsn0cmmKdR0-82DjrYZD5_CaF2bqwHnj07dM+Bnd-2aupU5QQ@mail.gmail.com> <CABcZeBP8wdmbO8DQPZ8e5CDZ76ioe3vzaJ+7YtQ74XZzcuxHmg@mail.gmail.com> <20210306061124.GY30153@localhost> <1615013752661.15146@cs.auckland.ac.nz> <20210306211036.GZ30153@localhost> <1615111060736.9067@cs.auckland.ac.nz> <20210307223534.GB30153@localhost> <12CE99EA-C55C-4327-A4DF-80734E6F1459@ll.mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <12CE99EA-C55C-4327-A4DF-80734E6F1459@ll.mit.edu>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/EXJrpztJLxj2CrAb_p09VBINZYw>
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: Mon, 08 Mar 2021 00:05:37 -0000
On Sun, Mar 07, 2021 at 11:19:49PM +0000, Blumenthal, Uri - 0553 - MITLL wrote: > > > So instead of getting one chance a year for your control system to break > > > itself if the renewal fails, you get hundreds of them? > > > > Yes. Exactly. It's a human factors problem. And this solution works. > > With all due respect, *absolutely not*. Well, it works when fragile manual processes (likely to be entirely forgotten until things break) that are almost good enough to get by on every year or two, become plainly unreasonable when exercised every month or every week. In other words, short-lived certs force: - Active monitoring - Automation of preëmptive renewals (with sufficient time to retry more than once on failure). The tools to make this possible need to be available before we ask people to invent this for themselves, but the effect on operational discipline is real. If either monitoring or automation are skipped, then sure, you have a recipe for failure. But if the signal is not ignored, and proper automation is applied, reliability actually improves. I see this effect in the stability of DANE deployments at domains that are using Let's Encrypt with "mailinabox.email" which automates the lifecycle including TLSA record updates, ..., v.s. DYI MTAs with certs are only renewed every year or two (often wildcard shared by all MTAs for the domain). The mailinabox systems do a far better job of keeping their certs valid. Despite the fact that they make up 1/3 of the deployed MXs, they make up a much smaller fraction of the domains I ping when the DANE survey finds poorly managed cert chains that fail authentication. Does this mean that a nuclear reactor's cooling system should shut down when a cert expires? Probably not, ... but if one is going to manage certificates that do expire, my bet is that the short-lived ones are better managed, and will exhibit fewer total hours of downtime, despite the more frequent expirations. -- 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