IETF Logo Mail Archive

Re: [TLS] Question to TLS 1.3 and certificate revocation checks in long lasting connections

"Salz, Rich" <rsalz@akamai.com> Fri, 05 March 2021 17:06 UTC

Return-Path: <rsalz@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 56B033A2859; Fri, 5 Mar 2021 09:06:48 -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=ham 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 e3aTL5wVbucw; Fri, 5 Mar 2021 09:06:46 -0800 (PST)
Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::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 9EC4A3A2860; Fri, 5 Mar 2021 09:06:46 -0800 (PST)
Received: from pps.filterd (m0122332.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 125H0DqM020661; Fri, 5 Mar 2021 17:06:45 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=sN/m1kLLZYX2oTAtr+FUkdt+6/YC2La/8mdm2tvwAOE=; b=HtehSbzk2H4wbMiOVoviq3VRLyAJ3BpVg2i0iW3malcD0KAbtjPDtIfFyX9iT3g2cszt Q2H66zoAyANjD8EDqJ6DZIpeavYOAvnicKvBADjuTmfME1C3EaWoILUVstIM/qTDjec3 YSEUVwkoE4zI5OzfRLADcIErU2zeO5Cfgx8tdS9fyr7gg4mtdyhYhf1TtkIzsj7R+fX/ eKdIl4EUx02vRoEiYnzUCLMHtWS7BG9T2cKmmNVvzxCG4hhCp8J/aNiJFLhaU3aExfFX 2Q3w+0RfBl4z7P5HovyDLadQaFn8VO2gjKDV7j9BYfL7mjyCUn1TN3zpr+14RnXPqwGA mg==
Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19] (may be forged)) by mx0a-00190b01.pphosted.com with ESMTP id 3732f27bxp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 05 Mar 2021 17:06:45 +0000
Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.43/8.16.0.43) with SMTP id 125H3sW0027217; Fri, 5 Mar 2021 12:06:43 -0500
Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint2.akamai.com with ESMTP id 36yja4xvcu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 05 Mar 2021 12:06:43 -0500
Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 5 Mar 2021 12:06:22 -0500
Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1497.012; Fri, 5 Mar 2021 12:06:22 -0500
From: "Salz, Rich" <rsalz@akamai.com>
To: John Mattsson <john.mattsson=40ericsson.com@dmarc.ietf.org>, "Fries, Steffen" <steffen.fries@siemens.com>, "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] Question to TLS 1.3 and certificate revocation checks in long lasting connections
Thread-Index: AQHXEeEgKe23eiCLoE+KwrPix1Q1lap1n/cA
Date: Fri, 05 Mar 2021 17:06:21 +0000
Message-ID: <27F18D0E-FDC0-4E75-B9E7-0DBFB639B438@akamai.com>
References: <DE27E5E0-4AB9-4B53-92F6-1057015A8F6C@ericsson.com>
In-Reply-To: <DE27E5E0-4AB9-4B53-92F6-1057015A8F6C@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.46.21021202
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.27.164.43]
Content-Type: text/plain; charset="utf-8"
Content-ID: <8D4EA3AD763F4542B8EB5A0B16A39765@akamai.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.369, 18.0.761 definitions=2021-03-05_10:2021-03-03, 2021-03-05 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 mlxscore=0 mlxlogscore=818 bulkscore=0 malwarescore=0 adultscore=0 phishscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2103050086
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.369, 18.0.761 definitions=2021-03-05_10:2021-03-03, 2021-03-05 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 lowpriorityscore=0 adultscore=0 mlxscore=0 spamscore=0 impostorscore=0 phishscore=0 bulkscore=0 priorityscore=1501 malwarescore=0 mlxlogscore=743 clxscore=1011 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2103050086
X-Agari-Authentication-Results: mx.akamai.com; spf=${SPFResult} (sender IP is 184.51.33.19) smtp.mailfrom=rsalz@akamai.com smtp.helo=prod-mail-ppoint2
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/P_NOws8UYdV-0e8c0V46hA09ZhU>
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 17:06:48 -0000

The TLS WG has not addressed long-lived connections. Probably because most of the people who developed the spec are in the Web space. That's not intended as a criticism, just pointing out where there seems to be this blind spot.

AFAIK, nothing stops either side from periodically going off on its own to verify the peer identity and then sending an alert to shut things down.  That might not scale well, and some kind of extension that allows both sides to send updated status information might be useful and I would support that. (Peter Gutman, you still around? :)

v2.23.0 | Report a Bug | By Email