[TLS] Certificate Update in TLS
Yaroslav Rosomakho <yrosomakho@zscaler.com> Fri, 20 June 2025 21:45 UTC
Return-Path: <yrosomakho@zscaler.com>
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 9C360378F4BC for <tls@mail2.ietf.org>; Fri, 20 Jun 2025 14:45:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (1024-bit key) header.d=zscaler.com
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 qICjPNm_5vSp for <tls@mail2.ietf.org>; Fri, 20 Jun 2025 14:45:57 -0700 (PDT)
Received: from mail-lf1-x144.google.com (mail-lf1-x144.google.com [IPv6:2a00:1450:4864:20::144]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 17E8E378F4B5 for <tls@ietf.org>; Fri, 20 Jun 2025 14:45:57 -0700 (PDT)
Received: by mail-lf1-x144.google.com with SMTP id 2adb3069b0e04-551efd86048so2325916e87.3 for <tls@ietf.org>; Fri, 20 Jun 2025 14:45:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zscaler.com; s=google; t=1750455955; x=1751060755; darn=ietf.org; h=cc:to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=64AU43lP4KWx3S15n0Zkt1wsMK3I9kq7Env1BQJehBs=; b=DK7IB7OaoqQrFwWNeJaTEkS+e0Dne4dZ2YSb/bZeANIFsAXyH82HOFOVRifleHGpgN NMKBnBDpUceGLO4O2ftV1bYQ21jy89f0waQbvvuF/BjelOBhqAqTgnLts6sqt/7mwbYp 37lMYCIs8rdFajuqL5oUGFhf1SYVYK4ndhm+Q=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1750455955; x=1751060755; h=cc:to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=64AU43lP4KWx3S15n0Zkt1wsMK3I9kq7Env1BQJehBs=; b=srba0BNCSwA2L50TjkqxXOAPjvXPeAr/rpeqdFDmprSoU4RbkcznPGJeEUwUMf5mV6 RpHaNc5qflkDfmp5NyflIeYyWTwOSoJ5DuN1nMMnozkSTnb0k8T3PxcQ/oy9S9R7bCHI CBnL7IzWCcHgb4obHEruL1PVvHGxYNlKbyJtM5FH9rV4xOsu4FSZN2DAFzEFMPTc5N4k fqPx5eb9Qm96GjPdXIDdixiyh+433Nj5pG36cd6pVhQwVXQpA0qrnpXi8GLun9X3fpoz rMZW+o8W2rA4pbq4SZn7i7vweCYxUlFCHfO3jAB9gKvxvr20XlZAgcUkU4nb9eInYpsd Z0FA==
X-Gm-Message-State: AOJu0Yy2mKBktPvd9AAKnpQkFwZqHElaI+AdHxndjwnn5SzATTHIP/gK v+7oD0X3gtnFn9llpNEtvgTsZHQkpSnS+PwUeQUKX/UY3szueFZwrfHUm5GgNr6dO73ozj9wKGK 56yyk/EdBsWj6Gttj3EkuCG/9a50DKO3gT4DV8nOk0SqlYv6x63hW7d+d6sTU8q4Zt9iQqf+5pP rSEZNQg7iYgtmfbOpqzsNYbwt0+WWJ9A==
X-Gm-Gg: ASbGnctpLgTtdxx9H+pdstVpPyqP9ICuvL9Tw019/zMiij5fVgVqVaXcd6H0RILZNeD vV+LMDzAdLioUBgZwIKBPQwkdAj4PKgJ0bBkUUp4eZHEGikCljzMJdu32qgl2wU6yhbDFywNEON LKlD0crT9BG+LaTbAzhWQL7kJ4MfHOmUpKZNUPwmVtOZpdnLicXZ6m3Ak2RTnrhivqHqMmYddMa tq1Dg==
X-Google-Smtp-Source: AGHT+IFur+CdM0aSpaVGqPvd2PzOnQrXl6UMzMN/qnlAtw1hwtGCO+Fqwq/vaXK3ojyIPNczaEV9QZOfbmXG3rA+Nok=
X-Received: by 2002:a05:6512:3f27:b0:553:cf38:5ea2 with SMTP id 2adb3069b0e04-553e3ba785bmr1709881e87.3.1750455954445; Fri, 20 Jun 2025 14:45:54 -0700 (PDT)
MIME-Version: 1.0
From: Yaroslav Rosomakho <yrosomakho@zscaler.com>
Date: Fri, 20 Jun 2025 22:45:43 +0100
X-Gm-Features: Ac12FXyBCX9p_9pm2aCQ-WoiolMppWosbERtrpkrBrp3UGEmvGpghbJKSt9MI-o
Message-ID: <CAMtubr3CGwYZ49KQQ93Y5+g8a_t_+pZtXFP0eqYYOJdEedLDPw@mail.gmail.com>
To: "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000005c3215063807c9b5"
Message-ID-Hash: A2EOGRCMRQ32PW2P2ME2IOWCGUZ2IJ4J
X-Message-ID-Hash: A2EOGRCMRQ32PW2P2ME2IOWCGUZ2IJ4J
X-MailFrom: yrosomakho@zscaler.com
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
Subject: [TLS] 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/4rRq5RugH87DgJM5wMuoR52xEGg>
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>
Dear TLS Working Group, We would like to share a new individual draft, "Certificate Update in TLS 1.3" (draft-rosomakho-tls-cert-update). This document specifies a lightweight extension and two post-handshake messages that allow TLS peers to provide renewed certificates on an active TLS 1.3, DTLS 1.3 or QUIC connection without requiring session termination and re-estabilshment. We see this proposal as highly complementary to the Extended Key Update draft There is a growing set of use cases that rely on long-lived TLS or QUIC sessions, including IoT communications, VPN tunnels such as MASQUE CONNECT-IP, and carrier signaling. In these settings, tearing down a connection to share an updated certificate can be costly and disruptive. At the same time, there is a strong trend towards shorter certificate lifetimes, which creates a tension between security and operational continuity. This mechanism enables both peers to provide updated certificates mid-session using Exported Authenticators. The specification defines tight constraints on updated certificates to ensure that such updates do not alter the logical identity of the peer or result in unintended authentication or authorization changes at the application layer. We believe this solution addresses limitation of alternative approaches: - Relying solely on initial authentication becomes increasingly problematic as sessions grow longer. - Using application logic to detect certificate expiration and terminate sessions is fragile and cumbersome. - Updating higher-layer protocols to handle signaling certificate updates uniformly is infeasible and potentially disruptive. We do not expect this mechanism to be useful for short-lived session such as typical web browsing when TLS sessions are significantly shorter than typical certificate lifetime. It would be great to hear feedback on the proposal in general as well as design specifics. Best Regards, Yaroslav and Tiru ---------- Forwarded message --------- A new version of Internet-Draft draft-rosomakho-tls-cert-update-00.txt has been successfully submitted by Yaroslav Rosomakho and posted to the IETF repository. Name: draft-rosomakho-tls-cert-update Revision: 00 Title: Certificate Update in TLS 1.3 Date: 2025-06-20 Group: Individual Submission Pages: 14 URL: https://www.ietf.org/archive/id/draft-rosomakho-tls-cert-update-00.txt Status: https://datatracker.ietf.org/doc/draft-rosomakho-tls-cert-update/ HTML: https://www.ietf.org/archive/id/draft-rosomakho-tls-cert-update-00.html HTMLized: https://datatracker.ietf.org/doc/html/draft-rosomakho-tls-cert-update Abstract: This document defines a mechanism that enables TLS 1.3 endpoints to update their certificates during the lifetime of a connection using Exported Authenticators. A new extension is introduced to negotiate support for certificate update at handshake time. When negotiated, either endpoint can provide a post-handshake authenticator containing an updated certificate, delivered via a new handshake message. This mechanism allows long-lived TLS connections to remain valid across certificate rotations without requiring session termination. The IETF Secretariat -- This communication (including any attachments) is intended for the sole use of the intended recipient and may contain confidential, non-public, and/or privileged material. Use, distribution, or reproduction of this communication by unintended recipients is not authorized. If you received this communication in error, please immediately notify the sender and then delete all copies of this communication from your system.
- [TLS] Certificate Update in TLS Yaroslav Rosomakho
- [TLS] Re: Certificate Update in TLS Watson Ladd
- [TLS] Re: [External⚠️] Re: Certificate Update in … Yaroslav Rosomakho
- [TLS] Re: [External⚠️] Re: Certificate Update in … Watson Ladd
- [TLS] Re: [External⚠️] Re: Certificate Update in … Yaroslav Rosomakho
- [TLS] Re: [External⚠️] Re: Certificate Update in … Rifaat Shekh-Yusef
- [TLS] Re: [External⚠️] Re: Certificate Update in … Eric Rescorla
- [TLS] Re: [External⚠️] Re: Certificate Update in … Rifaat Shekh-Yusef
- [TLS] Re: [External⚠️] Re: Certificate Update in … tirumal reddy
- [TLS] Re: [External⚠️] Re: Certificate Update in … Eric Rescorla
- [TLS] Re: [External⚠️] Re: Certificate Update in … Yaroslav Rosomakho
- [TLS] Re: [External⚠️] Re: Certificate Update in … Watson Ladd
- [TLS] Re: [External⚠️] Re: Certificate Update in … Yaroslav Rosomakho
- [TLS] Re: [External⚠️] Re: Certificate Update in … Viktor Dukhovni
- [TLS] Re: [External⚠️] Re: Certificate Update in … Yaroslav Rosomakho
- [TLS] Re: [External⚠️] Re: Certificate Update in … Viktor Dukhovni
- [TLS] Re: [External⚠️] Re: Certificate Update in … Michael Tuexen
- [TLS] Re: [External⚠️] Re: Certificate Update in … Yaroslav Rosomakho
- [TLS] Re: [External⚠️] Re: Certificate Update in … Viktor Dukhovni
- [TLS] Re: [External⚠️] Re: Certificate Update in … Yaroslav Rosomakho
- [TLS] Re: [External⚠] Re: Certificate Update in T… Christian Huitema
- [TLS] Re: [External⚠️] Re: Re: [External⚠] Re: Ce… Yaroslav Rosomakho
- [TLS] Re: Certificate Update in TLS Martin Thomson
- [TLS] Re: Certificate Update in TLS John Mattsson
- [TLS] Re: Certificate Update in TLS Martin Thomson
- [TLS] Re: Certificate Update in TLS Michael Tuexen
- [TLS] Re: Certificate Update in TLS Michael Tuexen