[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.