IETF Logo Mail Archive

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

Peter Gutmann <pgut001@cs.auckland.ac.nz> Mon, 08 March 2021 03:21 UTC

Return-Path: <pgut001@cs.auckland.ac.nz>
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 E642B3A230F for <tls@ietfa.amsl.com>; Sun, 7 Mar 2021 19:21:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.917
X-Spam-Level:
X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=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 ZdzOFR8GLD-P for <tls@ietfa.amsl.com>; Sun, 7 Mar 2021 19:21:37 -0800 (PST)
Received: from au-smtp-delivery-117.mimecast.com (au-smtp-delivery-117.mimecast.com [180.189.28.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E19A83A2308 for <tls@ietf.org>; Sun, 7 Mar 2021 19:21:36 -0800 (PST)
Received: from AUS01-ME3-obe.outbound.protection.outlook.com (mail-me3aus01lp2239.outbound.protection.outlook.com [104.47.71.239]) (Using TLS) by relay.mimecast.com with ESMTP id au-mta-33-40-3OZ-zPvy5TDgdbx21Qg-1; Mon, 08 Mar 2021 14:21:32 +1100
X-MC-Unique: 40-3OZ-zPvy5TDgdbx21Qg-1
Received: from SL2P216CA0075.KORP216.PROD.OUTLOOK.COM (2603:1096:101:2::8) by SYXPR01MB1264.ausprd01.prod.outlook.com (2603:10c6:0:31::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3912.26; Mon, 8 Mar 2021 03:21:27 +0000
Received: from PU1APC01FT034.eop-APC01.prod.protection.outlook.com (2603:1096:101:2:cafe::d4) by SL2P216CA0075.outlook.office365.com (2603:1096:101:2::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3912.17 via Frontend Transport; Mon, 8 Mar 2021 03:21:26 +0000
X-MS-Exchange-Authentication-Results: spf=none (sender IP is 130.216.95.208) smtp.mailfrom=cs.auckland.ac.nz; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cs.auckland.ac.nz
Received: from uxcn13-tdc-b.UoA.auckland.ac.nz (130.216.95.208) by PU1APC01FT034.mail.protection.outlook.com (10.152.252.218) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.3912.19 via Frontend Transport; Mon, 8 Mar 2021 03:21:24 +0000
Received: from uxcn13-tdc-d.UoA.auckland.ac.nz (10.6.3.5) by uxcn13-tdc-b.UoA.auckland.ac.nz (10.6.3.3) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 8 Mar 2021 16:21:22 +1300
Received: from uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::207a:c7e4:28d9:e2fe]) by uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::207a:c7e4:28d9:e2fe%14]) with mapi id 15.00.1497.012; Mon, 8 Mar 2021 16:21:22 +1300
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: "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+KwrPix1Q1lap0ziCAgAAS0wCAAA9lAIAAVjGAgABa2YCAAOWiuIAAFZqAgAGvzff///pFgIAADFyAgAAMyACAAQ9hHA==
Date: Mon, 08 Mar 2021 03:21:22 +0000
Message-ID: <1615173682710.74632@cs.auckland.ac.nz>
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>, <YEVqToCtAMgT3Swu@straasha.imrryr.org>
In-Reply-To: <YEVqToCtAMgT3Swu@straasha.imrryr.org>
Accept-Language: en-NZ, en-GB, en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [130.216.158.4]
MIME-Version: 1.0
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 891b5a67-aa14-4dd4-a6da-08d8e1e14128
X-MS-TrafficTypeDiagnostic: SYXPR01MB1264:
X-Microsoft-Antispam-PRVS: <SYXPR01MB1264209D36E0AA539470FC2BEE939@SYXPR01MB1264.ausprd01.prod.outlook.com>
X-MS-Oob-TLC-OOBClassifiers: OLM:6430
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam: BCL:0
X-Microsoft-Antispam-Message-Info: GwFkC8NgtS509Yr8OovJSry1fj6RpLFyc0i+MFlWKv4LgDFFil/R6TtJ09X8HwV2KTobJVoSs9ifQLsmoTPaRcGbSevuRzmsRx8pUxUPS7O5LHCtebAsfg377bUluNCbyOQtklUdy/wVbR2g5alj2gY3dvK5gXPXT4B6gfiRrTHAqj59HTJ0F2ViSgeSktNAFwG4YLjg7hVUGCJkgjb0yPdVjvJRzMUuyhfRiNPkwZ3Qtyu1YxkCkt5SjHMfySs6BCsmFfZJOLIAPXVVRVcIeBqPAIzskE93irGsK9XldLQMceeBs9Z+2CBd/Ah1pmeE4pfycEosD0x1ilI0dMbLZaT7jpH6CHZQEK/Nb+wn4GZrbxFJbUaIkNRldbOK9jnQqRSbEOl0x3mIXQCftUAHf/a6Y/h9xR6OjIA7k7Q8OR6Og8i2jvt6tiDyzEGTVBad4lY60qVq71ug98KBroAxNFCKPp7uuQ8CjkukOCuzM3bbHZbmzcCpme9Kq2iU/XN/9fdOjCX5TlTVpFIXVDquhwVp40c0KOzRRfJAvUeveL0wMC5hSWLeeAU2JIyeV8UQLRNlPq4H3I5xlix4++U3RC5bW9J8nbfAf19lGh2+kuKLPOipLK3Vn0+H3WZnIpKHd7P6ZU7MC7EyeP7kwHZNnKTF681ifPFqVEysMzJ+ZjmcK9mzBmDSr/Wu+vrxNTJ6
X-Forefront-Antispam-Report: CIP:130.216.95.208; CTRY:NZ; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:uxcn13-tdc-b.UoA.auckland.ac.nz; PTR:natgate1-1.auckland.ac.nz; CAT:NONE; SFS:(4636009)(39860400002)(376002)(136003)(346002)(396003)(36840700001)(46966006)(82310400003)(70586007)(2906002)(7636003)(83380400001)(47076005)(36860700001)(36906005)(4744005)(70206006)(5660300002)(786003)(316002)(478600001)(186003)(82740400003)(8936002)(86362001)(8676002)(2616005)(356005)(26005)(336012)(6916009)(219973002); DIR:OUT; SFP:1101
X-OriginatorOrg: cs.auckland.ac.nz
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Mar 2021 03:21:24.6031 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 891b5a67-aa14-4dd4-a6da-08d8e1e14128
X-MS-Exchange-CrossTenant-Id: d1b36e95-0d50-42e9-958f-b63fa906beaa
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=d1b36e95-0d50-42e9-958f-b63fa906beaa; Ip=[130.216.95.208]; Helo=[uxcn13-tdc-b.UoA.auckland.ac.nz]
X-MS-Exchange-CrossTenant-AuthSource: PU1APC01FT034.eop-APC01.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SYXPR01MB1264
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: cs.auckland.ac.nz
Content-Language: en-NZ
Content-Type: text/plain; charset="WINDOWS-1252"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/21t_y-jRHDxjwzoSrVBdoqewMzE>
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:21:39 -0000

Viktor Dukhovni <ietf-dane@dukhovni.org> writes:

>But if the signal is not ignored, and proper automation is applied,
>reliability actually improves.

No, it drops.  You're going from a situation where you've eliminated any
chances of outages due to expired certs to one where you get to play Russian
roulette every single day: Will the cert renewal work, or will it fail for
some reason?  Let's spin the cylinder and see if this is the day our grid goes
down.

Even if you somehow create a 100% successful magical process for replacing
certs that never ever fails, you're now introduced another possible failure
situation, with certs changing constantly there's a chance that something that
relies on them can't handle a new cert, for example because an issuing CA has
renewed as well or something similar.

It's just building in more and more opportunities for failure from a mechanism
that's supposed to be making your infrastructure more robust, not less.

Peter.

v2.23.0 | Report a Bug | By Email