IETF Logo Mail Archive

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 03:40 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 8C1773A235A for <tls@ietfa.amsl.com>; Sun, 7 Mar 2021 19:40:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 fejVAfBTenJO for <tls@ietfa.amsl.com>; Sun, 7 Mar 2021 19:40:39 -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 0CEB73A236B for <tls@ietf.org>; Sun, 7 Mar 2021 19:40:35 -0800 (PST)
Received: by straasha.imrryr.org (Postfix, from userid 1001) id ED5E9C8CF0; Sun, 7 Mar 2021 22:40:33 -0500 (EST)
Date: Sun, 07 Mar 2021 22:40:33 -0500
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: tls@ietf.org
Message-ID: <YEWcsX5b9g1dZQ5k@straasha.imrryr.org>
Reply-To: tls@ietf.org
References: <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> <YEVqToCtAMgT3Swu@straasha.imrryr.org> <1615173682710.74632@cs.auckland.ac.nz> <20210308033123.GC25665@akamai.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20210308033123.GC25665@akamai.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/2u42F_8ehK-eWDOQu__UAAYvEgU>
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 03:40:41 -0000

On Sun, Mar 07, 2021 at 07:31:24PM -0800, Benjamin Kaduk wrote:

> Just to confirm: the scenario you're using to contrast to the one described
> by Viktor (and Nico) is a scenarios in which the certificates expire at "never"
> (99991231235959Z)?
> 
> I think that at least some people are contrasting against something other
> than that...

Correct, I'm contrasting with N-year certs for N <= 30 (longer if
expected lifetime of device is larger, e.g. switches in the NYC subway
system, though their actual deployed lifetime has well exceeded anything
"planned").  In other words, with certs that will actually need to be
replaced now and then.

Peter's "never" scenario has its place, it's the cases that fall between
"never" and short-lived that I find suboptimal.  Do it well, or don't
do it at all.

-- 
    Viktor.

v2.23.0 | Report a Bug | By Email