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 35EAFBD604F0 for ; Tue, 24 Feb 2026 11:39:04 -0800 (PST) X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -2.693 X-Spam-Level: X-Spam-Status: No, score=-2.693 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, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, 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=verizon.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 YUBczTP_9eNn for ; Tue, 24 Feb 2026 11:39:03 -0800 (PST) Received: from mx0a-0024a201.pphosted.com (mx0a-0024a201.pphosted.com [148.163.149.93]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 59B5EBD604DB for ; Tue, 24 Feb 2026 11:39:03 -0800 (PST) Received: from pps.filterd (m0488737.ppops.net [127.0.0.1]) by mx0a-0024a201.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 61OHvtHo1606684 for ; Tue, 24 Feb 2026 14:38:55 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.com; h= cc:content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to; s=prodmail; bh=OIbFo8mMValbzQXPckZ1PbyK7 IFIgkK1FtaJOrgHaYY=; b=vPG+QohSWMdRxQbUpE9HLUrfI+52M0eV8Z2TWUSPq xpdaRp+gxkHNIpwJPBh6v0xQDWtdjp5pX8rhgvYscC34TlaLXXNZIwUbEAFNc6oo K8egHoyEY6HYsToIVENRoP856EqS6ULcM5P8yk1K9Y1/+UOZuLpEm/ZS7gAwXNAj U5zlhspmGDBDoLamz0tElot874DxME2Er04iqZbtz8usmSKNj0S+20aaTasfIV1w Rzsgu/jrDtUgEAABSOpsr+8cqHQAhLKVWeJgpvSuw9gCJa1qQEjiloOlmZNvL7Ja J+8l4rY2YapGQ176TdAVs/c5WQYVtQ6s530omxLAsVLOw== Received: from mail-pj1-f72.google.com (mail-pj1-f72.google.com [209.85.216.72]) by mx0a-0024a201.pphosted.com (PPS) with ESMTPS id 4cha6vrh95-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Tue, 24 Feb 2026 14:38:55 -0500 (EST) Received: by mail-pj1-f72.google.com with SMTP id 98e67ed59e1d1-35301003062so41899380a91.2 for ; Tue, 24 Feb 2026 11:38:55 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1771961935; cv=none; d=google.com; s=arc-20240605; b=ZeLDMlQAV2mJbUFR/DPvjtJ5wP96M5v7rRBocvEs0VETi9kkmHl4kFLiSvybm3feAD YaAimVFYNOK6hOPy/mKIH+1x7LaGts8eXv180+hsycyNLPPpOdYN3dI6+2Y4IFinPx4p zermTo/0bLgMcaPLibbgkwyGXFqHC+CCyYJkhlCG7kOSX2mo1B829MyUiXEXC2IaETpw mujWtOykVnZx4WJhw82UlPuN7B2zhRWawVAMa90bxK43+HVVQ3bOiOyFvTxx6/jEUYzO q3RNZmItQnqxljV2qlcUBt9IZgIMyiqs1nUjWqPvkE9GOif9tqs5imw/ZdWTVKBUBMLh LLGw== 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; bh=OIbFo8mMValbzQXPckZ1PbyK7IFIgkK1FtaJOrgHaYY=; fh=2mc/0AxfHhbyOgk/94X4TyKtQNm2eGEai6PFU9Nalao=; b=Ja+gOu0wrWjPIjjCl4PyYJMG0aacAeX5lKNEKL9vYhbFcMFAzjnWvkTqKyrxqjF+j/ CySq6zs3kcwMs8zjoZZP4xSjtTVUF+F2Sw+zTi5IWTBDSlfQSfdn5W/0biLv+1c6LCac i41lEZGpbmHBBvvdCwAl6+APgDm5+SJ0ifLdJeZ3vQJFn4JcWfVroZ1cJ4AYAk+RAzHq 4HOhM0qUko/RjjYePO7wGA8V9R6F8+nSiNmbsuJapwbbQoTkNq02ZDWi3MY7PxNjWozB CCrNm5tqKo09BM0DluuMp2dQj0pEoti6F8VRgW/bFZiackfJxQkqLOY97WB+qffP3CCg 22fQ==; darn=ietf.org ARC-Authentication-Results: i=1; mx.google.com; arc=none X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771961935; x=1772566735; 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=OIbFo8mMValbzQXPckZ1PbyK7IFIgkK1FtaJOrgHaYY=; b=k8V91K7cXZnhTl1s4p2kQ6MbiqNbWlZvQcSRa2gLSYETkYBiAFtBw+9hAFVCpy7v/1 Liff2PuifniM0ZSniA2uBsGKqPEztfvZ548mZix7T9rPdnpcHDFYosNybSZMFIfWfKte JAsnT13xa1/+BHr1mSJSjrVVb0k6M1wKexORR/CPDcYr4h/PcFZRUho6VPCwsTUukTFi Zoq6FeI2Wn8YejT9twsPHwRXaEHwlHbuxXQDQLmJJVhADHyII0Zw0i8+USvLBwFl4VLa w0zRPjwfsyT9UHj9EDa9Gi6ngtLZTR4w5e8AkPxMurQtpikzC6lY035DUsfz4AtuRnpP /maQ== X-Forwarded-Encrypted: i=1; AJvYcCXIO1d+OlDMS09mwpJgM4I7L7/jQ65j+ACDW1mj8RcmE7kvVTgwt2xa3fe7nbXXRI51xPU=@ietf.org X-Gm-Message-State: AOJu0YwKjmeGBr5lN330i+pZkGvDatbRI6v746kE4mvhMRL9xFAXK5As LR1R1AzRzflld+Olxc7qDJ+/u2m8gjanb1MTPuldqLW2DgcUp/uylVcz58mTiEf4CI7bxHCFLeu 1aGB4cS+hRoqVBh0n44chAQXmfl9/Lt/MYDCveThUDw9wO6HWh5duHmQJ9w5UPxwVFvuRh2pah9 uIHsLCZXkqMjVjWMeQvOg= X-Gm-Gg: ATEYQzxV0dnoDjZK+Bej5u2eNF0ON6Kjlt6XZ9X6yXc/A70r4tKexG5vs+nP1IcZCGI 4DA6JCdY80CRMudejI/LPvXEK2Ui2LKpt+gP93odldj3qKrH75sGoJOPgc0ct5dK3FUbqEqlYj9 wDRdfQTmAAJBQOz8yw/C4FG5LfpOxhx7XaImGzE7O75zplA50oP36TQoVccfnWg18utKQUk8V71 xseS0k= X-Received: by 2002:a17:90b:37c7:b0:341:8ac7:39b7 with SMTP id 98e67ed59e1d1-358ae8c2d42mr9485017a91.25.1771961935248; Tue, 24 Feb 2026 11:38:55 -0800 (PST) X-Received: by 2002:a17:90b:37c7:b0:341:8ac7:39b7 with SMTP id 98e67ed59e1d1-358ae8c2d42mr9485000a91.25.1771961934731; Tue, 24 Feb 2026 11:38:54 -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: "Choyi, Vinod Kumar" Date: Tue, 24 Feb 2026 11:38:42 -0800 X-Gm-Features: AaiRm53GelCwmsFcZugpX7c49CtFUnm4N5KPsan8i8IDeefaX6031ZGHHhiUePQ Message-ID: To: Richard Barnes Content-Type: multipart/alternative; boundary="000000000000acf230064b970911" X-mailroute: internal Message-ID-Hash: RXWGV63QLX2DUTJEPUFCH2OBBTBKFL2E X-Message-ID-Hash: RXWGV63QLX2DUTJEPUFCH2OBBTBKFL2E X-MailFrom: prvs=35153b2aef=vinod.choyi@verizon.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: John Mattsson , "" , "Charles Eckel (eckelcu)" X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5BTLS=5D_Re=3A_=5BE=5D_Re=3A_New_Version_Notification_for_draft-b?= =?utf-8?q?arnes-tls-this-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: --000000000000acf230064b970911 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Richard, I can say with a high degree of certainty, and I agree with John that almost all of our vendors and SDOs (3GPP, GSMA) rely on IETF RFCs especially those pertaining to TLS, IKE/IPSEC, EAP.... Regards, Vinod On Tue, Feb 24, 2026 at 8:57=E2=80=AFAM Richard Barnes wrote: > 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 the= m > 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 t= he > draft already accommodates. Clearly WG action is required for that. > > --Richard > > On Tue, Feb 24, 2026 at 12:46=E2=80=AFAM John Mattsson 40ericsson.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 >> understand the needs of external SDOs using TLS and made sure that we ca= n >> improve (and sustain) the applicability and suitability of the TLS famil= y >> 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 TL= S >> 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 >> cannot be adopted? Adding 1-2 sentences to the charter paragraph startin= g >> with "The third goal..." could have the same effect as this document, bu= t >> be one 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. >> It occurred to me that the TLS WG has been doing a lot of unnecessary wo= rk >> on drafts that just register crypto algorithms. This draft proposes tha= t >> 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 >> successfully >> 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 i= s >> 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-a= n-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-b= een-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 >> > _______________________________________________ > TLS mailing list -- tls@ietf.org > To unsubscribe send an email to tls-leave@ietf.org > --000000000000acf230064b970911 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Richard,

I can say with a high degree of certa= inty, and I agree with John that almost all of our vendors and SDOs (3GPP, = GSMA) rely on IETF RFCs especially those pertaining to TLS, IKE/IPSEC, EAP.= ...

Regards,
Vinod=C2=A0

<= /div>

=
On Tue, Feb 24, 2026 at 8:57=E2=80=AF= AM Richard Barnes <rlb@ipv.sx> wrot= e:
Hi John,

I'm confused.=C2=A0 Are you = saying that external SDOs aren't able to use a TLS ciphersuite unless t= he TLS WG publishes an RFC on it, even if there's a registered IANA cod= e point?=C2=A0 Even if that's the case, it seems like a them problem an= d not an us problem.=C2=A0 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.=C2=A0 Clearly=C2=A0WG action = is required for that.

--Richard

On Tue, Feb 2= 4, 2026 at 12:46=E2=80=AFAM John Mattsson <john.mattsson=3D40ericsson.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=A0https://datatracker.ietf.org/doc/draft-barnes-tls-this-c= ould-have-been-an-email/
HTML:=C2=A0 =C2=A0 =C2=A0https://www.ietf.org/archive/id/draft-barnes-t= ls-this-could-have-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
_______________________________________________
TLS mailing list -- tls@i= etf.org
To unsubscribe send an email to tls-leave@ietf.org
--000000000000acf230064b970911--