[TLS] Re: Improving the quality of the discussion on the TLS email list

Ken Kubota <ietf@kenkubota.de> Sat, 01 August 2026 00:24 UTC

Return-Path: <ietf@kenkubota.de>
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 A8DAF121EB2D3 for <tls@mail2.ietf.org>; Fri, 31 Jul 2026 17:24:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1785543873; bh=MBUMlq/6Bhx1OoGt1Z7RZHBTZl3PR4hmV3uezuFNy9M=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=ecR2YyDB59vfBbc6LFznVhEUnzzfTn1P1Yu2DpADOGFdly1+U9s914Llz8r+NFnNF R7q0RjFsnC5e8DuRP7mBezEXNqIkZBmojlUvDAaUHjnEwz/Mbg87UM9bAI3fSJK8ti cjnb0GQGm3Ce1ljwuPapctOx+Vv4QW+VcnsrWO6E=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.797
X-Spam-Level:
X-Spam-Status: No, score=-2.797 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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=kenkubota.de
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 kmrU1rrd887o for <tls@mail2.ietf.org>; Fri, 31 Jul 2026 17:24:30 -0700 (PDT)
Received: from plasma4.jpberlin.de (plasma4.jpberlin.de [80.241.57.33]) (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 7C5CC121EB2CA for <tls@ietf.org>; Fri, 31 Jul 2026 17:24:29 -0700 (PDT)
Received: from spamfilter02.heinlein-hosting.de (spamfilter02.heinlein-hosting.de [80.241.56.116]) by plasma.jpberlin.de (Postfix) with ESMTP id 260B8AC008; Sat, 1 Aug 2026 02:24:20 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kenkubota.de; s=MBO0001; t=1785543860; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=5Lb/Jd172x18ZM+xd/WsRNRckOqCtLWqTFS6LZnNhV4=; b=YgNFIoE+3QDTOdQE2f2dUGduKZxLDxTGlckzE6anLJcUXPWwoyo/U10ePW6L5Hk/jqA41B slKPvl4ptxqPleZB23gsa7y5JPdiWDxXV//wE3VACG1SQIRNVZ6FDiYcunFQYoLSsbi4Cl NxVuC1HviU3YiJPkwcGuL4t/YzWM49Gs3VOmwBGcKDAfW7KX8yVe5xdpxYWL/2GTSTCsvo FsIWwMQeug7VoaNibAQlqY1CtWroBgl8uwLvtYcUWTEfrFypRKPUUnI4bl9lmrM1MK9FvK Lp/40yDaYKuISzLBWKaVGwqb9ndUe9uW80dXPkYfhBpDSYejzmnf+3VYD/PxJA==
Received: from plasma.jpberlin.de ([80.241.56.68]) by spamfilter02.heinlein-hosting.de (spamfilter02.heinlein-hosting.de [80.241.56.116]) (amavisd-new, port 10030) with ESMTP id tJEJ_DEbk9ur; Sat, 1 Aug 2026 02:24:15 +0200 (CEST)
Received: from smtpclient.apple (unknown [37.19.200.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: ietf@kenkubota.de) by plasma.jpberlin.de (Postfix) with ESMTPSA id B4344ABC31; Sat, 1 Aug 2026 02:24:12 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0
From: Ken Kubota <ietf@kenkubota.de>
In-Reply-To: <MN2PR17MB40315611A5F4FD712F362BA9CDC82@MN2PR17MB4031.namprd17.prod.outlook.com>
Date: Sat, 01 Aug 2026 02:23:59 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <8A9729C8-6F3A-4CC5-8313-27B415146C74@kenkubota.de>
References: <CAEzBKQ4fymnSeo8tgqMLOfKopvMGk4xnDq=SQJKf-RBL4-uh6g@mail.gmail.com> <CAEEbLAbhZUpempA9Rvjhm1qrLfBWXa_2ntdfpO20cqDu0h5fbQ@mail.gmail.com> <CAEzBKQ6NOzQc66T+SEdSvLa2gxjtO77DYUUWuTfr99zV_a-Ofg@mail.gmail.com> <c8a74833-35cd-44a0-8992-e5463a82aa8f@dennis-jackson.uk> <F95592F7-6E60-4835-B21C-B5B1954084F7@kenkubota.de> <b3321e23-5f9b-4f8a-8bd9-d2cca2800d67@lear.ch> <amypaHNTh0Ya7XF+@ein.win.tue.nl> <538b6162-6cbb-4051-9810-601b29f880fe@app.fastmail.com> <CAA+_yBYWP_3MOcTM8FH8wjiif_L_WLOPVHKnp8nVmGJzFiCCpQ@mail.gmail.com> <f5cb425b-6fd4-48f2-aec0-5272e9ff30fe@app.fastmail.com> <0F869FB6-FAF9-4DBB-A046-3ABEA0A14C44@joseon.com> <MN2PR17MB40315611A5F4FD712F362BA9CDC82@MN2PR17MB4031.namprd17.prod.outlook.com>
To: "Salz, Rich" <rsalz=40akamai.com@dmarc.ietf.org>
Message-ID-Hash: 43IGISF2IZIXM4ZT2RVTGO2XHFA7EY3C
X-Message-ID-Hash: 43IGISF2IZIXM4ZT2RVTGO2XHFA7EY3C
X-MailFrom: ietf@kenkubota.de
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tls.ietf.org-0; header-match-tls.ietf.org-1; header-match-tls.ietf.org-2; header-match-tls.ietf.org-3; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: Andrew Lee <andrew@joseon.com>, Orr Dunkelman <orrd=40cs.haifa.ac.il@dmarc.ietf.org>, "tls@ietf.org" <tls@ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [TLS] Re: Improving the quality of the discussion on the TLS email list
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/mDCqeSlfJq0qBM_EDwc93ImSC24>
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>

The relationship between RFC 2418 and RFC 2026 was already detailed in [1].

They state that conflict resolution should first be attempted within the working group, with the working group chair(s).
(Note regarding Orr [2]: The Area Director(s) [ADs] are the second step on the escalation ladder; see [1]. The first step is always the Working Group [WG] and Working Group's chair(s) [WG chairs].)

These two RFCs also clearly emphasize openness and transparency. Consequently, actions such as excluding participants or claiming 70% support without supplying evidence -- which prevents participants from verifying the claim -- violate these RFCs exactly.

In other words, the RFCs you referred to support Andrew's position [3], not Filippo's [4]; therefore, the discussion should take place here within the working group with the working group chairs first, asking them to comply with IETF standards of openness and transparency.

Simply dismissing legitimate criticism with impolite phrasing ("Go read [...]" [5]) or other direct or indirect attempts to justify the working group chairs' lack of transparency ("can give it a useful try" [6]) will not pull this working group out of the hole it crashed into.

Kind regards,

Ken Kubota

____________________________________________________

Ken Kubota
https://doi.org/10.4444/100



[1] https://mailarchive.ietf.org/arch/msg/tls/ByLJ7Kf1EbP2fESF5R4KRhkKPsE/

[2] https://mailarchive.ietf.org/arch/msg/tls/3pMbxvdca-lpwpEoJMHBdfE_uG8/

[3] https://mailarchive.ietf.org/arch/msg/tls/xLZ6nZF8aAVgXEU3ht87YbJ44zQ/

[4] https://mailarchive.ietf.org/arch/msg/tls/6Y4oDbqc8oKaU4muPy4aobCWBEA/

[5] https://mailarchive.ietf.org/arch/msg/tls/bm6aH__5ZIOZWaQo-MGnXXbt6Pc/

[6] https://mailarchive.ietf.org/arch/msg/tls/6Y4oDbqc8oKaU4muPy4aobCWBEA/



> Am 31.07.2026 um 21:14 schrieb Salz, Rich <rsalz=40akamai.com@dmarc.ietf.org>:
> 
>     • Nobody should have to guess at blackbox processes when it comes to the security of the billions of people on the internet. Further, an appeal cannot be conducted when the process which produced the outcome is unclear.
> 
> Go read RFC 2418 which describes how IETF working groups work.  And then read RFC 2026 which describes how decisions are appealed. Fillipo was terse, but he was neither wrong, nor unserious.
> 
> 
> _______________________________________________
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-leave@ietf.org