[TLS] Re: [EXTERNAL] Re: Dual certificates in TLS proposal

Watson Ladd <watsonbladd@gmail.com> Wed, 18 June 2025 22:40 UTC

Return-Path: <watsonbladd@gmail.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 F2E5636A9312 for <tls@mail2.ietf.org>; Wed, 18 Jun 2025 15:40:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 nq-vLYAY-LOo for <tls@mail2.ietf.org>; Wed, 18 Jun 2025 15:40:18 -0700 (PDT)
Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) (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 7A7E936A9308 for <tls@ietf.org>; Wed, 18 Jun 2025 15:40:18 -0700 (PDT)
Received: by mail-wm1-x332.google.com with SMTP id 5b1f17b1804b1-453426170b6so7899505e9.1 for <tls@ietf.org>; Wed, 18 Jun 2025 15:40:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1750286417; x=1750891217; darn=ietf.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=oEI0owEM1q0QLABPR0Ms4q3weILfaUSxqmWeDD+5/DA=; b=d4l7kf0PNw92fnB2SOvSsByJeGVUHjMgZnWJfSTZ0s2I/HEj4zIr+/1MgT0S+EGJ+c ZN5N+SVtY5sATghqIakJLVGGH9eoOg+/IAj5KRqpYgZb5mKvjIPw8PJPSD57Jw8OJwL9 0AqUHs/FgaUd5JNJntk0TNdrl0b8/7sAqq2C9L8HryUWhLCws6vyfRDUbrlI/IYLK4Ky veV0lvC20543pmX0eCJJhGC4bsn///gXkyElsymHaDmgWnqLYya//MMbVz22En46tGRc PtubxnIGruhHo4sV2KyjtTs6z5VTyf6yl1YritlUo+mPE7xXZEpFL0Xm4lFom4qrUnEq J4iQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1750286417; x=1750891217; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=oEI0owEM1q0QLABPR0Ms4q3weILfaUSxqmWeDD+5/DA=; b=uvUSDx6khbOuhup0hpppYHYN0gm/gs459aQETbbe2Rum0eRzL0kvbmKJXCz6xFTiyM ma1XdiXdR48UcjlZDwa7eZeD9jvMa0bXOP7YAsDhZjjHAepiewKKJeB3XuQJpRxpuA6F LsegIqxZJXs/rHiaB3Fd5pEEQ28MM6kOd1Ll0nv1wRCqu5mt7TQQi+O+cl1WtlOb671h kFbb2ZhWcA+xLk7BIV1sEZ8vFcFgcirwx++erE/yy94fkhlZB0WH/m/R5MkAT4KadXXA 1mA0D16hCwFIR9P0zOYYuNCEJeN4wQM3fCn/jnZDi30QHA37rOzcWDOd4za/z9Zjytv4 WdWw==
X-Forwarded-Encrypted: i=1; AJvYcCVAZoRleZ+KYzEKalXfobPYQC0pxAY0u5psJS8/r/PHT3482jQFCONoi/fHA1YZ2p/gaz4=@ietf.org
X-Gm-Message-State: AOJu0YyMp9XBSn8+XIql4cAgcMQgZbD3clilvJ5Y8hZYZLYYzX3oyzue HBRziZq49upIWB2up4HDJ9WrkSgox0MCbi67M4uWxWv0UL9vzMRIzCihOaDCYSHZEMTMFNOqQYj AgERpJq8cACVqNJ/89oDYfbOBfSgn813Ggw==
X-Gm-Gg: ASbGncuci2tBvdK5SAR+wLk/eUFtIhr0I+OntBenFliZeQAmv8B5VwOeGpnQ9q0qK8B Vlv1BXbvNzy5L79M0lp4AGae3UqWhgQN24QXcMuY9PImti1MmSAqlTBqKD/rzyH6NWFaG9qgpfB jZjpwiVJBMfs9oNy0fxz/vN8UhThn3huwPKyc4zb+brLW4ljI6O9i+Lked5Ao/NCQ4lhKFqjYRN Iw9
X-Google-Smtp-Source: AGHT+IFIXnO54DSSLMUbBSvGDRACAV9t2lfCHg56UFn+tFftYPG8CyutdGraZaNl+9fdgfxP2hZlLMlPK7PcJ7pp3iI=
X-Received: by 2002:a05:6000:2dc7:b0:3a5:8601:613b with SMTP id ffacd0b85a97d-3a6c96cbd5bmr1019579f8f.20.1750286417361; Wed, 18 Jun 2025 15:40:17 -0700 (PDT)
MIME-Version: 1.0
References: <CAMtubr1CHuJoiyG+t-kOfV4kcmV4XV7QmAYfLhK1saVL=f9MTQ@mail.gmail.com> <CACsn0cnS_Lwevju1o1rzYsujYqGJZZm6YMKU1rPk73QaKzbC5w@mail.gmail.com> <CH0PR11MB573987A69F61A0176BB417689F72A@CH0PR11MB5739.namprd11.prod.outlook.com>
In-Reply-To: <CH0PR11MB573987A69F61A0176BB417689F72A@CH0PR11MB5739.namprd11.prod.outlook.com>
From: Watson Ladd <watsonbladd@gmail.com>
Date: Wed, 18 Jun 2025 15:40:05 -0700
X-Gm-Features: Ac12FXxnJiXR59ByDjpOY8IIx-jqD5uBoHbzb65P0Sk21qFLHFgoA20PbBIlHTM
Message-ID: <CACsn0cn1dWPCebzuWiSA1TQyissqc2+Y7m383a18+R_fXdPJMQ@mail.gmail.com>
To: Mike Ounsworth <Mike.Ounsworth@entrust.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Message-ID-Hash: XJ5WVIY2OBCOH7CZ4CZRUTVZ5M4JFY3Q
X-Message-ID-Hash: XJ5WVIY2OBCOH7CZ4CZRUTVZ5M4JFY3Q
X-MailFrom: watsonbladd@gmail.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
CC: Yaroslav Rosomakho <yrosomakho=40zscaler.com@dmarc.ietf.org>, "<tls@ietf.org>" <tls@ietf.org>, Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [TLS] Re: [EXTERNAL] Re: Dual certificates in TLS proposal
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/YNwuebC8tvDE4pDOaNVT-UXgb1I>
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 Wed, Jun 18, 2025 at 3:33 PM Mike Ounsworth
<Mike.Ounsworth@entrust.com> wrote:
>
> Watson,
>
>
>
> There is currently no way to request that a server produce a CertificateVerify containing two signatures. This draft is adding a mechanism for 2 certificates -> 1 CertificateVerify.
>
>
>
> Basically, since draft-reddy-tls-composite-mldsa is on the table, we also wanted to write down the other obvious way of doing hybrid signatures so that we can have a complete discussion on the topic. Whether or not this is “needed” is exactly the discussion to have at 123 😊

It's much easier to make complex arguments over email than in a few
minutes of time at the mic line.

More specifically, it's not clear to me why these are desirable
mechanisms. Unlike confidentiality mechanisms, authentication
mechanisms cannot be broken retrospectively. We already have a
mechanism for negotiation that has functioned to enable transition
from RSA to ECDSA, largely seamlessly. The scope in the document and
justification of a smooth transition is already demonstrably met with
no real change to libraries to implement this.  I don't see anything
in the introduction of the draft that makes the case here, unlike the
one you cite as an alternative.

Sincerely,
Watson
>
>
>
> ---
>
> Mike Ounsworth
>
>
>
> From: Watson Ladd <watsonbladd@gmail.com>
> Sent: Wednesday, June 18, 2025 5:29 PM
> To: Yaroslav Rosomakho <yrosomakho=40zscaler.com@dmarc.ietf.org>
> Cc: <tls@ietf.org> <tls@ietf.org>; Hannes Tschofenig <Hannes.Tschofenig@gmx.net>; Mike Ounsworth <Mike.Ounsworth@entrust.com>
> Subject: [EXTERNAL] Re: [TLS] Dual certificates in TLS proposal
>
>
>
> On Wed, Jun 18, 2025, 3: 19 PM Yaroslav Rosomakho <yrosomakho=40zscaler. com@ dmarc. ietf. org> wrote: Dear TLS WG, We have just submitted a new proposal, draft-yusef-tls-dual-certs-00, that extends TLS 1. 3 to support authentication using two
>
>
>
>
>
> On Wed, Jun 18, 2025, 3:19 PM Yaroslav Rosomakho <yrosomakho=40zscaler.com@dmarc.ietf.org> wrote:
>
> Dear TLS WG,
>
> We have just submitted a new proposal, draft-yusef-tls-dual-certs-00, that extends TLS 1.3 to support authentication using two certificate chains: one using traditional algorithms and one using post-quantum (PQ) algorithms. This approach, aimed at closed environments and staged post-quantum migration, enables stronger session authentication by requiring both signatures to validate.
>
> The proposal builds on existing TLS 1.3 mechanisms with minimal protocol changes. It introduces a dual signature algorithm extension and defines how dual certificate chains and signatures are structured, while preserving compatibility with Exported Authenticators.
>
> This mechanism complements existing proposals such as composite certificates (e.g., draft-reddy-tls-composite-mldsa), offering greater deployment flexibility, especially for systems that require support for independently validated classical and PQ credentials. It also helps with phased migration strategies where TLS endpoints have to deal with a mix of opinionated peers while limiting the need to create a zoo of PKI hierarchies to satisfy classic, pure PQ as well as all possible compositions of algorithms.
>
> We welcome your feedback and discussion on the proposal and the design specifics.
>
>
>
> Why is this needed given the existing signalling of client support for certificate signature algorithms?
>
>
>
>
> Best Regards,
> Hannes, Mike, Rifaat, Tiru, Yaron and Yaroslav
>
>
>
>
>
> ---------- Forwarded message ---------
>
> A new version of Internet-Draft draft-yusef-tls-pqt-dual-certs-00.txt has been
> successfully submitted by Yaroslav Rosomakho and posted to the
> IETF repository.
>
> Name:     draft-yusef-tls-pqt-dual-certs
> Revision: 00
> Title:    Post-Quantum Traditional (PQ/T) Hybrid Authentication with Dual Certificates in TLS 1.3
> Date:     2025-06-18
> Group:    Individual Submission
> Pages:    27
> URL:      https://www.ietf.org/archive/id/draft-yusef-tls-pqt-dual-certs-00.txt
> Status:   https://datatracker.ietf.org/doc/draft-yusef-tls-pqt-dual-certs/
> HTML:     https://www.ietf.org/archive/id/draft-yusef-tls-pqt-dual-certs-00.html
> HTMLized: https://datatracker.ietf.org/doc/html/draft-yusef-tls-pqt-dual-certs
>
>
> Abstract:
>
>    This document extends the TLS 1.3 authentication mechanism to allow
>    the negotiation and use of two signature algorithms to enable dual-
>    algorithm hybrid authentication, ensuring that an attacker would need
>    to break both algorithms to compromise the session.  The two
>    signature algorithms come from two independent certificates that
>    together produce a single Certificate and CertificateVerify message.
>
>
>
> 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 mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-leave@ietf.org
>
> Any email and files/attachments transmitted with it are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system.
>


-- 
Astra mortemque praestare gradatim