Return-Path: 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 3088ADCE65AB for ; Wed, 15 Apr 2026 09:13:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1776269592; bh=tBXj4gp2aAoWN9gRv0T+mtxf2uHc/5hrFC+F9XkIFAA=; h=From:Subject:Date:References:To:In-Reply-To; b=Xaf1ukcQ1jVW+9UZr6ee37lV7j8A0D9qpxDEo3PlVHRDld+X37NMXbBSjV38+cNrw Fo8/FIQ1p/gIbz7hvJEme/vKIoLO9pAay2/ZmDe5OgEH3zF12u8bkRZHdaYXmpEoNc HdNIPXj6BgKfUnbyaK474+AMc+0iiGb3zCwKQihg= X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 8uTCJpMNAb-Z for ; Wed, 15 Apr 2026 09:13:11 -0700 (PDT) Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (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 B9BA1DCE4BCA for ; Wed, 15 Apr 2026 09:08:50 -0700 (PDT) Received: by mail-qk1-x72d.google.com with SMTP id af79cd13be357-8dfd34c9ac0so296975485a.0 for ; Wed, 15 Apr 2026 09:08:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; t=1776269330; x=1776874130; darn=ietf.org; h=message-id:in-reply-to:to:references:date:subject:mime-version:from :from:to:cc:subject:date:message-id:reply-to; bh=OiFU8A8IbXmQHPga4Y4K1PB4PA8p2YhD3pYQ0bWENu4=; b=Kj2hJMGtraYbjsTGx/UMfzaLROmTalPgmcLb/tt3ezjqPPHJa30h4/vSOUZZxyX7lI gbMGmAuJAeRv0bqn/WeilFN0kQW9bkBlyufMeTXdmL6zb+ivWZELViS9zZ5iqw1ye4Y0 Qg2S35a8SuDhykN6q63caXU0cJxQjIyLfALNs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776269330; x=1776874130; h=message-id:in-reply-to:to:references:date:subject:mime-version:from :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=OiFU8A8IbXmQHPga4Y4K1PB4PA8p2YhD3pYQ0bWENu4=; b=oAjiTpRbqG3zWcWWCjS8jynk6XgKn0xN6ZwrlMMzdk4v/T1cEfSPza1iO8jKjvLpE2 wHesutIm57C9z8gxEYXqMpc0Tku9bHbSuSN8NdnJhsMG3vaLerxq0Q1xJDG+H2oexfev MRCvjAaEourOGrAkHrY8rbKv3OsV7Hz83BC0Bnw7ZDxiYvyyUrSGF6ssLEeKIFrp/AmC Ip+LsNdxbHUkbdr1XQAuU50SrMhE4hPvOxt8lRgvgjADQkO2xMETOuFGkRXyWdVBjjIR qMHdKhKUuFp/oUJrwpUS+eQhfiwB36O3IHcUjfQHv/ZL7Osc5nQasaqAxRaRiwzbEofa Yr0A== X-Gm-Message-State: AOJu0Ywp40lYWHJY2F0VXdfRh/BmEno/z+HCazneh0J3kXGoOmd1yHPX lR5/E8ENoptI15gs1UgegEwCdyqufHGr7sDw/XGlB7mxklZHSsapWoIo/K0ygByAxyl+RiVs1zB bCF0bDOc= X-Gm-Gg: AeBDiesoiFdS9qNakl9+jROF8Waq58JimTOvZimdGufQg8tNxf/H3PDl98zrKXokHjP jBnZT6MlfuAWQy2fzLWlAOnZigTqlFFh9pPifdp1O4w46uPKDTObtv/gNvhNYK0NxtjHedYES32 EWjCRY92FZ3U4BLSvH6GyvluQZ8KRiIU0txH+/ObalwL5j58ikX+SuTtAa+KHAvEkpqSzFBqD2R swoAoJ8IdJj3YauWpLdmfLOFV48gvFCiGmlkAB9MHt9eR1BFy8weaGsXtcWHxWDVEIhNdH2A3/r Dax/2idMPThrAlPGM/+KyfKupu79fxU6GFGhmzjQzINWu03R/b5U64fh69qjZTA8QL/pf/NAyAo oy0dqIVndnpvxVjnQ3fkMcTJF4eW7Q8luvN3osoOKFdV68zUtYa8R6AZoqu+AZrp4/K/WFYKBX9 vH27VEHTgqfjrceR8QO7IkUs7fCCsNZ8jf8eums837q9M2jNEL X-Received: by 2002:a05:620a:1725:b0:8cf:dc6a:18bf with SMTP id af79cd13be357-8ddcfea03e7mr3108233385a.50.1776269330120; Wed, 15 Apr 2026 09:08:50 -0700 (PDT) Received: from smtpclient.apple ([2600:4040:2555:6800:3ca6:affb:5154:42a0]) by smtp.gmail.com with ESMTPSA id af79cd13be357-8e4ef33b477sm151450285a.20.2026.04.15.09.08.49 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Apr 2026 09:08:49 -0700 (PDT) From: Sean Turner Content-Type: multipart/alternative; boundary="Apple-Mail=_EB7E99CA-246F-4FBD-BA58-4796C7666272" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.500.181\)) Date: Wed, 15 Apr 2026 12:08:29 -0400 References: <16CF0FDA-7263-461A-9F2B-D37DBEAF5DD9@sn3rd.com> <25c8d414-e4c8-455b-bd64-28132615ba75@cs.tcd.ie> <68f49a81-dd2c-4bea-896a-87da3e6aff68@tu-dresden.de> <2971d01a-89e3-43d3-a01d-b9c17b178763@amongbytes.com> <692bb582-ab7e-4d6b-aa75-ac5d93228bb2@tu-dresden.de> <3a16c7c4-345e-48ce-af70-a3bf503c8caf@app.fastmail.com> To: TLS List In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3864.500.181) Message-ID-Hash: DVMCIHDFGMFREGWUZSHNZTJBCQAKHTRF X-Message-ID-Hash: DVMCIHDFGMFREGWUZSHNZTJBCQAKHTRF X-MailFrom: sean@sn3rd.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: =?utf-8?q?=5BTLS=5D_Re=3A_Composite_ML-DSA?= List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --Apple-Mail=_EB7E99CA-246F-4FBD-BA58-4796C7666272 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Top posting here because the subject has changed and mailer (and maybe = yours) seems to show this part of the ML-DSA WGLC thread. Note that we are *NOT* currently running a WG adoption call for = composite ML-DSA. spt > On Apr 15, 2026, at 01:43, tirumal reddy wrote: >=20 > Hi Yaroslav, >=20 > Thanks for the feedback. This draft significantly reduces the number = of code points compared to what is defined in = ietf-lamps-pq-composite-sigs, registering only the subset of composite = ML-DSA algorithms that are compatible with the traditional signature = algorithms already recommended in TLS 1.3, rather than the full set = defined in the LAMPS draft.=20 >=20 > Beyond code point allocation, simply registering code points without a = TLS specification would lead to interoperability failures. For example, = ietf-lamps-pq-composite-sigs defines a context string parameter for = signing and verification, without explicitly requiring an empty context = string for TLS use, implementations could make different choices, = causing signature verification failures between peers. There are several = other such TLS-specific decisions discussed in the draft that cannot be = addressed through code point registration alone.=20 >=20 > We believe these issues justify adoption of the specification in the = TLS working group rather than a standalone code point registration. >=20 > Cheers, > -Tiru >=20 > On Tue, 14 Apr 2026 at 05:22, Yaroslav Rosomakho = > wrote: >> I think allocating codepoints to the zoo of ML-DSA composites would = be good, but I don't see a good reason to adopt the composites = specification in the TLS working group. >>=20 >> -yaroslav >>=20 >> On Tue, Apr 14, 2026 at 12:02=E2=80=AFAM David Adrian = > wrote: >>> I am perfectly fine defining composite certificates however, I will = go further than other David and say that Chrome cannot, should not, must = not, and will not implement composite certificates in TLS.=20 >>>=20 >>> On Mon, Apr 13, 2026 at 3:51=E2=80=AFPM Filippo Valsorda = > wrote: >>>> We have no plans to implement composite certificates either. >>>>=20 >>>> 2026-04-14 00:20 GMT+02:00 Watson Ladd >: >>>>> I do not think composite certs make sense for TLS. >>>>>=20 >>>>> On Mon, Apr 13, 2026 at 12:33=E2=80=AFPM David Benjamin = > wrote: >>>>> > >>>>> > On Mon, Apr 13, 2026 at 10:51=E2=80=AFAM Viktor Dukhovni = > wrote: >>>>> >> >>>>> >> On Mon, Apr 13, 2026 at 04:30:34PM +0000, Andrei Popov wrote: >>>>> >> >>>>> >> > Just to weigh in on this: I would support adoption of >>>>> >> > draft-reddy-tls-composite-mldsa. There is customer demand for >>>>> >> > composite certs, and I would like to get these implemented in = the >>>>> >> > Windows TLS stack. >>>>> >> >>>>> >> I don't know what sort of interoperability you are expecting = with these, >>>>> >> I am strongly inclined to NOT implement any of the composite = signature >>>>> >> algorithms, at least not in TLS. It may be harder to fend off = their >>>>> >> adoption in CMS, but ideally sit that out as well, until we = either have >>>>> >> CRQCs and hybrids are pointless, or we don't have CRQCs and = know why >>>>> >> we're never going to have them. >>>>> > >>>>> > >>>>> > We're also not planning to implement composite ML-DSA in TLS. >>>>> > >>>>> > David >>>>> > _______________________________________________ >>>>> > TLS mailing list -- tls@ietf.org >>>>> > To unsubscribe send an email to tls-leave@ietf.org = >>>>>=20 >>>>>=20 >>>>>=20 >>>>> --=20 >>>>> Astra mortemque praestare gradatim >>>>>=20 >>>>> _______________________________________________ >>>>> TLS mailing list -- tls@ietf.org >>>>> To unsubscribe send an email to tls-leave@ietf.org = >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> TLS mailing list -- tls@ietf.org >>>> To unsubscribe send an email to tls-leave@ietf.org = >>> _______________________________________________ >>> TLS mailing list -- tls@ietf.org >>> To unsubscribe send an email to tls-leave@ietf.org = >>=20 >>=20 >> 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 = > _______________________________________________ > TLS mailing list -- tls@ietf.org > To unsubscribe send an email to tls-leave@ietf.org --Apple-Mail=_EB7E99CA-246F-4FBD-BA58-4796C7666272 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Top posting here because the subject has = changed and mailer (and maybe yours) seems to show this part of the = ML-DSA WGLC thread.

Note that we are *NOT* currently = running a WG adoption call for composite = ML-DSA.

spt

On Apr 15, 2026, at 01:43, tirumal reddy = <kondtir@gmail.com> wrote:

Hi = Yaroslav,

Thanks for the feedback. This draft significantly = reduces the number of code points compared to what is defined in = ietf-lamps-pq-composite-sigs, registering only the subset of composite = ML-DSA algorithms that are compatible with the traditional signature = algorithms already recommended in TLS 1.3, rather than the full set = defined in the LAMPS draft. 

Beyond code = point allocation, simply registering code points without a TLS = specification would lead to interoperability failures. For example, = ietf-lamps-pq-composite-sigs defines a context string parameter for = signing and verification, without explicitly requiring an empty context = string for TLS use, implementations could make different choices, = causing signature verification failures between peers. There are several = other such TLS-specific decisions discussed in the draft that cannot be = addressed through code point registration = alone. 

We believe these issues justify = adoption of the specification in the TLS working group rather than a = standalone code point = registration.

Cheers,
-Tiru

On Tue, 14 = Apr 2026 at 05:22, Yaroslav Rosomakho <yrosomakho=3D40zscaler.com@dmarc.ietf.org<= /a>> wrote:

On Tue, Apr = 14, 2026 at 12:02=E2=80=AFAM David Adrian <davadria@umich.edu> wrote:
I am = perfectly fine defining composite certificates however, I will go = further than other David and say that Chrome cannot, should not, must = not, and will not implement composite certificates in = TLS. 

On Mon, Apr 13, 2026 at 3:51=E2=80=AFPM = Filippo Valsorda <filippo@ml.filippo.io> = wrote:
We have no plans to = implement composite certificates = either.

2026-04-14 00:20 GMT+02:00 = Watson Ladd <watsonbladd@gmail.com>:
I do not think composite certs make sense = for TLS.

On Mon, Apr 13, 2026 at 12:33=E2=80=AFPM= David Benjamin <davidben@chromium.org> = wrote:
>
> On Mon, Apr 13, 2026 at 10:51=E2=80=AF= AM Viktor Dukhovni <ietf-dane@dukhovni.org> = wrote:
>>
>> On Mon, Apr 13, 2026 at = 04:30:34PM +0000, Andrei Popov = wrote:
>>
>> > Just to weigh in on = this: I would support adoption of
>> > = draft-reddy-tls-composite-mldsa. There is customer demand = for
>> > composite certs, and I would like to get = these implemented in the
>> > Windows TLS = stack.
>>
>> I don't know what sort of = interoperability you are expecting with these,
>> I am = strongly inclined to NOT implement any of the composite = signature
>> algorithms, at least not in TLS.  It = may be harder to fend off their
>> adoption in CMS, but = ideally sit that out as well, until we either have
>> = CRQCs and hybrids are pointless, or we don't have CRQCs and know = why
>> we're never going to have = them.
>
>
> We're also not = planning to implement composite ML-DSA in = TLS.
>
> David
> = _______________________________________________
> TLS = mailing list -- tls@ietf.org
> To unsubscribe send an = email to tls-leave@ietf.org



-- 
Astra mortemque praestare = gradatim

________________________________________= _______
TLS mailing list -- tls@ietf.org
To unsubscribe send an = email to tls-leave@ietf.org

=

_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-leave@ietf.org
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-leave@ietf.org


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
_______________________________________________
TLS mailing list -- = tls@ietf.org
To unsubscribe send an email to = tls-leave@ietf.org

= --Apple-Mail=_EB7E99CA-246F-4FBD-BA58-4796C7666272--