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