Re: Form of Appeals (Re: Complaint to IAB regarding non-transparency)

Nick Hilliard <nick@foobar.org> Thu, 09 October 2025 08:52 UTC

Return-Path: <nick@foobar.org>
X-Original-To: ietf@mail2.ietf.org
Delivered-To: ietf@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id F12306FE7C1E for <ietf@mail2.ietf.org>; Thu, 9 Oct 2025 01:52:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -6.381
X-Spam-Level:
X-Spam-Status: No, score=-6.381 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-2.182, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 YNwB7D2VMdIX for <ietf@mail2.ietf.org>; Thu, 9 Oct 2025 01:52:21 -0700 (PDT)
Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (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 218366FE7C17 for <ietf@ietf.org>; Thu, 9 Oct 2025 01:52:20 -0700 (PDT)
Received: from crumpet.local (vpn.ibn.ie [46.182.8.8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.netability.ie (Postfix) with ESMTPSA id C598D9CD4A; Thu, 09 Oct 2025 09:52:17 +0100 (IST)
Subject: Re: Form of Appeals (Re: Complaint to IAB regarding non-transparency)
To: Rob Sayre <sayrer@gmail.com>
References: <CAChr6Sy9t4nEXJTH=pX4c1TNMW41pXHm8H7++R7Y9YU2+3N65A@mail.gmail.com>
From: Nick Hilliard <nick@foobar.org>
Message-ID: <22019b18-ebbb-8f3a-4c51-814c08622b69@foobar.org>
Date: Thu, 09 Oct 2025 09:52:16 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 26.0; rv:52.0) Gecko/20100101 PostboxApp/7.0.65
MIME-Version: 1.0
In-Reply-To: <CAChr6Sy9t4nEXJTH=pX4c1TNMW41pXHm8H7++R7Y9YU2+3N65A@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------32AB1CE7103AD7997D062353"
Content-Language: en-US
Message-ID-Hash: AEKF4EUUUZW3MJPH4SJVFF2HHFAERHSW
X-Message-ID-Hash: AEKF4EUUUZW3MJPH4SJVFF2HHFAERHSW
X-MailFrom: nick@foobar.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-ietf.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: IETF discussion list <ietf@ietf.org>, "D. J. Bernstein" <djb@cr.yp.to>
X-Mailman-Version: 3.3.9rc6
Precedence: list
List-Id: "IETF-Discussion. This is the most general IETF mailing list, intended for discussion of technical, procedural, operational, and other topics for which no dedicated mailing lists exist." <ietf.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/Xei2iDOk6zorD4oFnLoJ5mAdkdQ>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Owner: <mailto:ietf-owner@ietf.org>
List-Post: <mailto:ietf@ietf.org>
List-Subscribe: <mailto:ietf-join@ietf.org>
List-Unsubscribe: <mailto:ietf-leave@ietf.org>

Rob Sayre wrote on 09/10/2025 01:17:
> Nick Hilliard <nick@foobar.org <mailto:nick@foobar.org>> wrote:
> > Or write a standards track / bcp ID which requires ECC+PQ as a baseline
> > for all new crypto protocols
>
> That's the thing. We have that one.
>
> https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/
>
> So, why are we doing a PQ-only document? I agree with DJB here, as I 
> don't understand the motivation.

Even better then. Submit two text updates: one in the body that 
standalone PQ conflicts with the recommendations in [hybrid-design], and 
a second for the security consideration sections stating that for 
reasons outlined in [hybrid-design], PQ-only [is considered to be 
materially weaker than ECC+PQ | is potentially vulnerable to 
harvest-now-decrypt-later | should not be implemented as a standalone 
key exchange mechanism, but only as part of a ECC+PQ] etc. It these 
updates are not inserted, then raise this politely as an outstanding 
objection and run with that. Or raise that the document should not be 
published at all, because of the recommendations in tls-hybrid-design.

It's a bit odd to see that tls-wg is aiming to publish one draft saying 
that standalone PQ is a poor idea and a second draft documenting a 
standalone PQ mechanism. At the very least, there ought to be a 
technically convincing explanation in the tls-mlkem draft for why it's 
ignoring the recommendations in tls-hybrid-design.


> I do not agree with the procedural acts, like PDFs and license 
> agreements. But maybe that is just an act of protest, and a peaceful 
> one at that.

Which battle does he want to win though? All that's come out of the 
procedural stuff is a new set of IETF guidelines about appeal 
submissions processes, which is great because wallpapering everything in 
process is what we all need in our lives. The rest is coming across as 
sound and fury, signifying not very much, and for sure drowning out the 
only thing actually worth discussing, namely the key exchange issue.

Nick