Re: [TLS] Question to TLS 1.3 and certificate revocation checks in long lasting connections
Benjamin Kaduk <bkaduk@akamai.com> Sun, 07 March 2021 16:25 UTC
Return-Path: <bkaduk@akamai.com>
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 382E33A18B6 for <tls@ietfa.amsl.com>; Sun, 7 Mar 2021 08:25:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.347
X-Spam-Level:
X-Spam-Status: No, score=-2.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.248, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com
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 6Ng_pTnJbRmR for <tls@ietfa.amsl.com>; Sun, 7 Mar 2021 08:25:52 -0800 (PST)
Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 14CB73A18B7 for <tls@ietf.org>; Sun, 7 Mar 2021 08:25:51 -0800 (PST)
Received: from pps.filterd (m0122331.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 127GJCKl027004; Sun, 7 Mar 2021 16:25:49 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to; s=jan2016.eng; bh=R7t4wXy1Eu6wigNcSfrMi4dXTZlmNJ3u9xR8bgaH3Wc=; b=ReS2dSXm1EJ5sKyjBT2a4HaG7BPj8rxoKxT8aHmm7xgR3KlUmAQm6IeTw2+ejBGt53xd zuJBfZroshphF9i5x9w3E3wa+BF/6wURSotrr1ltIKX7Ih0osIzs1SMLh5lNp3M3560s SvDOhBdnIMtvJPwenuDCqzf34kxyS3Yx9Mj8ZsC78DAeoQRuODf0qsW6gdTVdbk+b9KB 67aLLrzIhoQFAf9uas09T1SbDInsd7ggpxLnVG8OSdkmay7hOgkIJ7sIjdJzeIIlceOg v5kHmFlqHajPvk2LrD5QXhtMZMDwWEQr8oPBICHmOjXrMFHltH2D+l+ymVfau0QzR+CU gA==
Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 373yg2yb4f-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 07 Mar 2021 16:25:48 +0000
Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.43/8.16.0.43) with SMTP id 127GJPu5031625; Sun, 7 Mar 2021 11:25:48 -0500
Received: from prod-mail-relay10.akamai.com ([172.27.118.251]) by prod-mail-ppoint1.akamai.com with ESMTP id 3745y42nwk-1; Sun, 07 Mar 2021 11:25:48 -0500
Received: from akamai.com (sea-lp9yo.kendall.corp.akamai.com [172.19.16.134]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 8CB39421DA; Sun, 7 Mar 2021 16:25:47 +0000 (GMT)
Date: Sun, 07 Mar 2021 08:25:01 -0800
From: Benjamin Kaduk <bkaduk@akamai.com>
To: Graham Bartlett <graham.ietf@gmail.com>
Cc: Deb Cooley <debcooley1@gmail.com>, "Cooley, Dorothy E" <decoole@nsa.gov>, John Mattsson <john.mattsson=40ericsson.com@dmarc.ietf.org>, TLS List <tls@ietf.org>
Message-ID: <20210307162500.GA25665@akamai.com>
References: <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> <CAO4D2DN=kbUtSs=7GqDPibpDeJjL4GO7OWa22wbBHvNJeQU66A@mail.gmail.com> <CAGgd1Od3EfNAt0ZOpe-N+2t34U7bG5Za4j_abcy_4OX2si0gSw@mail.gmail.com> <CAO4D2DOQVJzQxn87mFQk=oFvY_JG4rcKB5RSFqW2vZRE2jYGzA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAO4D2DOQVJzQxn87mFQk=oFvY_JG4rcKB5RSFqW2vZRE2jYGzA@mail.gmail.com>
User-Agent: Mutt/1.9.4 (2018-02-28)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.369, 18.0.761 definitions=2021-03-07_10:2021-03-03, 2021-03-07 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 mlxscore=0 bulkscore=0 adultscore=0 spamscore=0 mlxlogscore=999 phishscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2103070089
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.369, 18.0.761 definitions=2021-03-07_10:2021-03-03, 2021-03-07 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 priorityscore=1501 bulkscore=0 spamscore=0 lowpriorityscore=0 adultscore=0 mlxlogscore=999 malwarescore=0 suspectscore=0 phishscore=0 clxscore=1011 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2103070089
X-Agari-Authentication-Results: mx.akamai.com; spf=${SPFResult} (sender IP is 184.51.33.18) smtp.mailfrom=bkaduk@akamai.com smtp.helo=prod-mail-ppoint1
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/pz3fO4bP_HRnZFtQfh_-hIL3RLc>
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: Sun, 07 Mar 2021 16:25:53 -0000
On Sun, Mar 07, 2021 at 12:15:24PM +0000, Graham Bartlett wrote: > > I would imagine that the implementation would pull the session down once > the certificate expires, so the session only lasts for the lifetime of the > certificate. Many people expect this, but I don't think there's universal agreement that it's the right behavior. The divide between authentication and authorization that (IIRC) Viktor called out is relevant here -- the initial key exchange and, to large extent, authentication, do not suddenly become invalid upon credential expiry, but any authorization derived from the credential might. So it seems that whether the session should terminate at the certificate expiry time is rather dependent on what the session is being used for. -Ben
- [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