[TLS] Re: [External⚠️] Re: Certificate Update in TLS

Viktor Dukhovni <ietf-dane@dukhovni.org> Sun, 22 June 2025 15:11 UTC

Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: tls@mail2.ietf.org
Delivered-To: tls@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 7BEAD37FB2BF for <tls@mail2.ietf.org>; Sun, 22 Jun 2025 08:11:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -4.398
X-Spam-Level:
X-Spam-Status: No, score=-4.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (1024-bit key) header.d=dukhovni.org
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VCjKlJLEL_7F for <tls@mail2.ietf.org>; Sun, 22 Jun 2025 08:11:54 -0700 (PDT)
Received: from chardros.imrryr.org (chardros.imrryr.org [144.6.86.210]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 9EEED37FB2BA for <tls@ietf.org>; Sun, 22 Jun 2025 08:11:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dukhovni.org; i=@dukhovni.org; q=dns/txt; s=f8320d6e; t=1750605111; h=date : from : to : subject : message-id : reply-to : references : mime-version : content-type : in-reply-to : from; bh=ccQ0CSgycE435o0G4OEeLbgqapKa6A+qOXdretzS9Fc=; b=DWUYKZfkVhdjIMufGc9EqbGS5T2D6n9p4KBUFnlEL9VnmpQC5VFnKtFzhFWriyJfo9+43 g7IVFnMN5E5YmbZAc4PCHf9OyieSIeQPaS98rWX4BBcy82iLAbCIqFVWIVKePmoqQQd5RVj FuWqZbKqpT1TqveNeGdXZLANs5hat5g=
Received: by chardros.imrryr.org (Postfix, from userid 1000) id 84446868D31; Mon, 23 Jun 2025 01:11:51 +1000 (AEST)
Date: Mon, 23 Jun 2025 01:11:51 +1000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: tls@ietf.org
Message-ID: <aFgdN-JEkWmKKMsS@chardros.imrryr.org>
References: <CAMtubr17Sv3HmokvF6DmqjqQDMO+xiZEbyhzn9_RMmgEXPiNfQ@mail.gmail.com> <CACsn0c=9w=_EmqTx0WkNSna_zCyfUsriKjXn2ixb1J+=SBQHMw@mail.gmail.com> <CAMtubr2YPJBkfbuOLVde4rxzVbFamSN4QGhrzgh9_Ae8CGh7rw@mail.gmail.com> <CADNypP8WFChpb7yW8qJaJAzv156z+mdm1NtRXS2c-oehngcjEA@mail.gmail.com> <CABcZeBPxUnO4ijfeZi-xD+07K3aSwqG4cd4t_jT2v3E=51EVSQ@mail.gmail.com> <CAFpG3gctxH-n-ygmNFRktrwxPo4MdR3VMoqM04-mV8HbJOpVvQ@mail.gmail.com> <CABcZeBMSwUPTWMcuq1GEU7zBh4_fmxg1nCRAPqRHUJqWp53hig@mail.gmail.com> <CAMtubr2ASZv1=ZOW5-riGXkwXZwb4TM+HU6_ANQTqFGKbMmomA@mail.gmail.com> <CACsn0cnf5P7C33c8KoqvRLKe99nFnRsUZdwXUO7g_Sr3p0TqMw@mail.gmail.com> <CAMtubr1o_Raqn=c1CJeuEmsUEi17LSOmx667r+mmGMLDH1o3qQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAMtubr1o_Raqn=c1CJeuEmsUEi17LSOmx667r+mmGMLDH1o3qQ@mail.gmail.com>
Mail-Followup-To: <tls@ietf.org>
Message-ID-Hash: BDVKBAYX5YAF2K53KFSVLLMXDPVP46FX
X-Message-ID-Hash: BDVKBAYX5YAF2K53KFSVLLMXDPVP46FX
X-MailFrom: ietf-dane@dukhovni.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tls.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc6
Precedence: list
Reply-To: tls@ietf.org
Subject: [TLS] Re: [External⚠️] Re: Certificate Update in TLS
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/VglvFAeb77a1WaKoas8JS1sZAdU>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Owner: <mailto:tls-owner@ietf.org>
List-Post: <mailto:tls@ietf.org>
List-Subscribe: <mailto:tls-join@ietf.org>
List-Unsubscribe: <mailto:tls-leave@ietf.org>

On Sun, Jun 22, 2025 at 03:53:15PM +0100, Yaroslav Rosomakho wrote:

> Overall, correct implementation of creating a new TLS session, carefully
> moving traffic and not introducing new stability or security risks is
> extremely complex in large scale distributed systems. Extended Key Update
> and Certificate Update enable long-lasting TLS 1.3 connections in a much
> simpler and more secure way.

This appears to be the case at first blush, but I wonder which is more
likely:

    - The key was already compomised when the connection was first
      established, and a later failure to perform certificate update
      helps to limit the duration of a compromise of which the node
      operator might not otherwise have been able to learn in a
      similarly timely manner.

    - The key was fine when the connection was established, but a
      problem with a subsequent certificate rollover resulted in
      a failure of certificate update that tears down a working
      session.

My money is on the second, and also that in environments where such
long-lived connetions are highly desirable, either both nodes are
under the control of a single operator, or the operators know each
other and key compromise can be communicated effectively out of
band, perhaps faster than revocation happening via CAs.

So I am concerned that the proposed mechanism is likely to reduce
rather than increase the availability of these long-term sessions.

-- 
    Viktor.