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 12BFABD4380D for ; Tue, 24 Feb 2026 08:57:18 -0800 (PST) X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20230601.gappssmtp.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 rScJl5bf7P4u for ; Tue, 24 Feb 2026 08:57:17 -0800 (PST) Received: from mail-oo1-xc36.google.com (mail-oo1-xc36.google.com [IPv6:2607:f8b0:4864:20::c36]) (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 7180CBD437FD for ; Tue, 24 Feb 2026 08:57:17 -0800 (PST) Received: by mail-oo1-xc36.google.com with SMTP id 006d021491bc7-6786b13984fso3875084eaf.2 for ; Tue, 24 Feb 2026 08:57:17 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1771952231; cv=none; d=google.com; s=arc-20240605; b=lnearBmNVPvI/+xy/BEWzexlXDOqORXYBAYkgytfvVR8Dvf+L8e1+Pd3lYQHOJY5sT rA/5C2rGHJdDNURsmXATcok/UTNjVZitqu7sVbUFUyavOlN4SPUvjF3moKA4g5EVf604 Pac8dAWbpJodfKwPlhdo81GxGJLGqAaVJi1jwp+NgADsP5jOhGK00iVm8uKycl7YBoje wzaUS0FKFs0/T4CExz2DPf09LgPmypX6kw8V45yeCSCAKQXqWY9p0RzAamS1YDfk8YPK j7ZMZ4kVZvvcGf3fN8ztF9RpaWCYMVjQxRUQtGTHTfQ9G8xXS7+P1zQIq0sLZ88syGX8 CA7g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=5R++UiUksrs5KFIMytg8XSZ7sI4dseYYsWJQuZyVdDk=; fh=xPWwfoCirAaOErNbu/vj692RU2e6bxPIiHDbizLJcio=; b=D8XsZPVu5Vh4TMc4AqGflcKXVPBU54Hzj0NpQCf3h/GAwd+vQ1ZL943Q8tV5p/ZHVq IEXJzGLe+lVZnJn5Uug9sqyIQdOhSzAAyrThjuNAhwr4ZDhUHHd452QO/E4nq/aRJm0n 3FyaxOTXj0q70jd3LDdwTY1tpfxRl8kUDnM4KJ8y1kIWLC5ez5K2v3onA35IEqhZdLZ4 OIODHGpuvBy3W3I2qPOsU6WOn6J94OLtMOmzAKV4NSXXGcQzQW53cvoIK0ZkKLQW4ELG qWi+T/6GX5TRN3QUrxIRuF9uQNSNIhqTPFLVPGeAcNA9JnQk1qIzJt4P8ANw81R6g7Uz C92w==; darn=ietf.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20230601.gappssmtp.com; s=20230601; t=1771952231; x=1772557031; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=5R++UiUksrs5KFIMytg8XSZ7sI4dseYYsWJQuZyVdDk=; b=ZhaGjurjID728tz4i1DNBlP9DJ21DI5kPfdSivNH++jEl3Ouh8dfI3Ltw6t569+eXz +H7M0J8XejnJ2jt/TCEmdxH1UJ4q0AuOg4lm8+cMNkLQaW+p+4s1ivN4NF7W1FQFLxDq 3XUvuRYXXW8E+bbq0iiX0uC1JpqTFRGWF8V+FrsWmie7319JcOxsI2QvFnaIj65Nbncx aMTClWZ9vnlNl2QLANiE/5QPZvTgzBA6288G7J4IaH+zzGLfBSwMsV/vNJkEmio+KSfZ DvHvERBJOvwsxF7CDugAQaCVQ94h8/s2Tsr+lrL4H+9MGE9QuWCrubEL7hFqdgcdFa/h RQeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771952231; x=1772557031; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=5R++UiUksrs5KFIMytg8XSZ7sI4dseYYsWJQuZyVdDk=; b=GKcrxkdPdtUZawd2b+i0XxeBKrtL9cuNgzkVUsdvwXBY3GvYTrg1rVARKjAShmiOxF UcC3zSQoVQ29TIOsg6yhQh2aakGkKV6id4WgQJ2QlF+k4K1oWM6IqMkVP8SgaJtVFxvM SUV1d/UgIwkU5x9rbfJlyCfp9Yd8DfPA5izbbtRV/gYkBq7oknU/7bidKQWG86hm9o2S j8QuhpjrFey3PJnpLNMfGnqyl67B9/0mq5f0Yfm1np8L4iPsinQwAC0lEFJUe13yGlYk aRABZ2SudACclX2W8yQ929mxenxxKvo73hlGWqVk0R+d87k6KzbVRKnJx9TpRroUo0LH yb9A== X-Gm-Message-State: AOJu0Yx/MFdY1t31xRRpQITfbk99FR8JyFHCcEqoLQdy7OpxsLqNFoWO ngHN0y3iEceSAihYzLMuqUW69jeLjhgs4RsOTsYCrbwU556SHaaq3PG56EwiH4fxjErkc8xYNlg /YAuBWacROUZyRzh0ImKCrdG5AY5poB3gaIai6KdhWy+MRzEC0/OmVIg= X-Gm-Gg: AZuq6aLHVPP+HAcv8nm3zKULufbm5WZCZ1Mk5Pt4OnaXNe9Nd/u3lwYyfDy57N/Xlmf EQu54/XhZzyIlpwIUSGUqDsDCvo2uFMaemh0a4IGGWjbjI8z4MPj0kHozDpDLJRELiVQ0LQvedY 0a2GxUS+8yjRUio9ff+MMn7uZvVGZzwRbJTIldqdZljSR6n4ZcoVRy3vn0nL091TJRr/HrDV9Eg 0pqSF9ZS294UAGfh0iyaXREwTxNyv4hWfv8LFXqjzli4N+1CTI2/4LyX7enQcmGjYOLvlI0mR4X m7YWpb0= X-Received: by 2002:a05:6820:1997:b0:667:7e1a:203a with SMTP id 006d021491bc7-679c46e948amr6829627eaf.58.1771952231114; Tue, 24 Feb 2026 08:57:11 -0800 (PST) MIME-Version: 1.0 References: <177189438640.2182161.16660142956175423236@dt-datatracker-6ff7c68975-7k42g> <7CDDF045-4A74-441F-9BAC-2E119075DB38@symbolic.software> In-Reply-To: From: Richard Barnes Date: Tue, 24 Feb 2026 06:57:00 -1000 X-Gm-Features: AaiRm51BEI3gL081SQGvIaMrL5u__Ul1K2zEnXZg783EXSlf0wvNAaMIhcSsaWU Message-ID: To: John Mattsson Content-Type: multipart/alternative; boundary="0000000000004b7784064b94c7fb" Message-ID-Hash: 3SI4KJNQ4XYDIXMEM7RZUFSMTR4Z2BM3 X-Message-ID-Hash: 3SI4KJNQ4XYDIXMEM7RZUFSMTR4Z2BM3 X-MailFrom: rlb@ipv.sx 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: "" , "Charles Eckel (eckelcu)" X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5BTLS=5D_Re=3A_New_Version_Notification_for_draft-barnes-tls-this?= =?utf-8?q?-could-have-been-an-email-00=2Etxt?= 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: --0000000000004b7784064b94c7fb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi John, I'm confused. Are you saying that external SDOs aren't able to use a TLS ciphersuite unless the TLS WG publishes an RFC on it, even if there's a registered IANA code point? Even if that's the case, it seems like a them problem and not an us problem. Like, get out of your own way, man. If they need Recommended=3DY, that's a different question, and one that the draft already accommodates. Clearly WG action is required for that. --Richard On Tue, Feb 24, 2026 at 12:46=E2=80=AFAM John Mattsson wrote: > Completely agree that this type of policy should be in the charter and no= t > in a draft. > > I am against any changes in this direction until TLS WG has tried to > understand the needs of external SDOs using TLS and made sure that we can > improve (and sustain) the applicability and suitability of the TLS family > of protocols for use in emerging protocols and use cases. > > At IETF 125, I would like to discuss sending an LS to SDOs relying on TLS > asking them if this kind of major change would work for them and if not > explain why. > > John > > *From: *Nadim Kobeissi > *Date: *Tuesday, 24 February 2026 at 11:11 > *To: *Felix Linker > *Cc: * > > *Subject: *[TLS] Re: New Version Notification for > draft-barnes-tls-this-could-have-been-an-email-00.txt > > Yes, true! > > Nadim Kobeissi > Symbolic Software =E2=80=A2 https://symbolic.software > > On 24 Feb 2026, at 10:25=E2=80=AFAM, Felix Linker = wrote: > > Hi everyone, > > Sorry to be pedantic, but shouldn't the charter define what can and canno= t > be adopted? Adding 1-2 sentences to the charter paragraph starting with > "The third goal..." could have the same effect as this document, but be o= ne > document less. > > Best, > Felix > > Am Di., 24. Feb. 2026 um 01:56 Uhr schrieb Richard Barnes : > > Hi TLS folks, > > Those who have worked with me know that I hate doing unnecessary work. I= t > occurred to me that the TLS WG has been doing a lot of unnecessary work o= n > drafts that just register crypto algorithms. This draft proposes that we > shouldn't do that. > > Submitted for your consideration, > --Richard > > ---------- Forwarded message --------- > From: > Date: Mon, Feb 23, 2026 at 2:53=E2=80=AFPM > Subject: New Version Notification for > draft-barnes-tls-this-could-have-been-an-email-00.txt > To: Richard Barnes > > > A new version of Internet-Draft > draft-barnes-tls-this-could-have-been-an-email-00.txt has been successful= ly > submitted by Richard Barnes and posted to the > IETF repository. > > Name: draft-barnes-tls-this-could-have-been-an-email > Revision: 00 > Title: Stop Doing Cryptographic Algorithm Drafts when Email to IANA is > All You Need > Date: 2026-02-24 > Group: Individual Submission > Pages: 5 > URL: > https://www.ietf.org/archive/id/draft-barnes-tls-this-could-have-been-an-= email-00.txt > Status: > https://datatracker.ietf.org/doc/draft-barnes-tls-this-could-have-been-an= -email/ > HTML: > https://www.ietf.org/archive/id/draft-barnes-tls-this-could-have-been-an-= email-00.html > HTMLized: > https://datatracker.ietf.org/doc/html/draft-barnes-tls-this-could-have-be= en-an-email > > > Abstract: > > People keep pitching drafts to the TLS Working Group where the only > thing the draft does is register a code point for a cryptographic > algorithm. Stop doing that. It's unnecessary. Write an email to > IANA instead. > > > > The IETF Secretariat > > > _______________________________________________ > 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 > --0000000000004b7784064b94c7fb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi John,

I'm confused.= =C2=A0 Are you saying that external SDOs aren't able to use a TLS ciphe= rsuite unless the TLS WG publishes an RFC on it, even if there's a regi= stered IANA code point?=C2=A0 Even if that's the case, it seems like a = them problem and not an us problem.=C2=A0 Like, get out of your own way, ma= n.

If they need Recommended=3DY, that's a diff= erent question, and one that the draft already accommodates.=C2=A0 Clearly= =C2=A0WG action is required for that.

--Richard

On Tue, Feb 24, 2026 at 12:46=E2=80=AFAM John Matt= sson <john.mattsson=3D4= 0ericsson.com@dmarc.ietf.org> wrote:
Completely agree that this type of policy should be in the charter and not = in a draft.

I am against any changes in this direction until TLS WG has tried to unders= tand the needs of external SDOs using TLS and made sure that we can improve= (and sustain) the applicability and suitability of the TLS family of proto= cols for use in emerging protocols and use cases.

At IETF 125, I would like to discuss sending an LS to SDOs relying on TLS a= sking them if this kind of major change would work for them and if not expl= ain why.

John

From: Nadim Kobeissi <nadim@symbolic.software>
Date: Tuesday, 24 February 2026 at 11:11
To: Felix Linker <linkerfelix@gmail.com>
Cc:
<tls@ietf.org><= br> Subject: [TLS] Re: New Version Notification for draft-barnes-tls-thi= s-could-have-been-an-email-00.txt

Yes, true!

Nadim Kobeissi
Symbolic Software =E2=80=A2=C2=A0https://symbolic.software

On 24 Feb 2026, at 10:25=E2=80=AFAM, Felix Linker <linkerfelix@gmail.com> wr= ote:

Hi everyone,

Sorry to be pedantic, but shouldn't the charter define what can and can= not be adopted? Adding 1-2 sentences to the charter paragraph starting with= "The third goal..." could have the same effect=C2=A0as this docu= ment, but be one document less.

Best,
Felix

Am Di., 24. Feb. 2026 um = 01:56=C2=A0Uhr schrieb Richard Barnes <rlb@ipv.sx>:
Hi TLS folks,

Those who have worked wi= th me know that I hate doing unnecessary work.=C2=A0 It occurred to me that= the TLS WG has been doing a lot of unnecessary work on drafts that just re= gister crypto algorithms.=C2=A0 This draft proposes that we shouldn't do that.

Submitted for your consi= deration,
--Richard

---------- Forwarded mess= age ---------
From: <int= ernet-drafts@ietf.org>
Date: Mon, Feb 23, 2026 at 2:53=E2=80=AFPM
Subject: New Version Notification for draft-barnes-tls-this-could-have-been= -an-email-00.txt
To: Richard Barnes <rlb@= ipv.sx>


A new version of Internet-Draft
draft-barnes-tls-this-could-have-been-an-email-00.txt has been successfully=
submitted by Richard Barnes and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0draft-barnes-tls-this-could-have-been-an-email
Revision: 00
Title:=C2=A0 =C2=A0 Stop Doing Cryptographic Algorithm Drafts when Email to= IANA is All You Need
Date:=C2=A0 =C2=A0 =C2=A02026-02-24
Group:=C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 5
URL:=C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/archive/id/draft-barnes-tls-this-could-have-been-an-em= ail-00.txt
Status:=C2=A0 =C2=A0= https://datatracker.ietf.org/doc/draft-barnes-tls-this-could-have-been-an-e= mail/
HTML:=C2=A0 =C2=A0 =C2=A0https://www.ietf.org/archive/id/draft-barnes-tls-this-could-hav= e-been-an-email-00.html
HTMLized: https://datatracker.ietf.org/doc/html/draft-barnes-tls-this-could-have-been= -an-email


Abstract:

=C2=A0 =C2=A0People keep pitching drafts to the TLS Working Group where the= only
=C2=A0 =C2=A0thing the draft does is register a code point for a cryptograp= hic
=C2=A0 =C2=A0algorithm.=C2=A0 Stop doing that.=C2=A0 It's unnecessary.= =C2=A0 Write an email to
=C2=A0 =C2=A0IANA instead.



The IETF Secretariat


_______________________________________________<= br> TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-leave@ietf.org
_______________________________________________
TLS mailing list -- tls@i= etf.org
To unsubscribe send an email to tls-leave@ietf.org

_______________________________________________
TLS mailing list -- tls@i= etf.org
To unsubscribe send an email to tls-leave@ietf.org
--0000000000004b7784064b94c7fb--