[TLS] Re: PQ Cipher Suite I-Ds: adopt or not?

S Moonesamy <sm+ietf@elandsys.com> Sat, 21 December 2024 10:44 UTC

Return-Path: <sm@elandsys.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83567C14F5EA for <tls@ietfa.amsl.com>; Sat, 21 Dec 2024 02:44:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.708
X-Spam-Level:
X-Spam-Status: No, score=-1.708 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h37qUrf2IMjN for <tls@ietfa.amsl.com>; Sat, 21 Dec 2024 02:44:20 -0800 (PST)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ACCCC14F5F7 for <tls@ietf.org>; Sat, 21 Dec 2024 02:44:20 -0800 (PST)
Received: from DESKTOP-K6V9C2L.elandsys.com ([102.117.91.135]) (authenticated bits=0) by mx.elandsys.com (8.15.2/8.14.5) with ESMTPSA id 4BLAh7lh018318 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 21 Dec 2024 02:43:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=elandsys.com; s=mail; t=1734777799; x=1734864199; i=@elandsys.com; bh=R1570dnuUhxG44Oeef4Z9DhCGx0Vvak7hsNWU52+jbo=; h=Date:To:From:Subject:In-Reply-To:References; b=c3b21kVddcMbaf1nCHQ3guRtNg2l81a82zNaI22CeppFqQDsCO2eV+IpNLTXtr/8w gI2vN0BxHHSEGFAOhxcsuJBFXsYxmtxfY8aXcFhq6r55Hmc99LyBR0izFgnitEyQIE WhMJkPfX2E4PTMRmcnQGIZL1W+e39W4HqepyaP/s=
Message-Id: <6.2.5.6.2.20241221010056.13289fe0@elandnews.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Sat, 21 Dec 2024 02:40:17 -0800
To: "D. J. Bernstein" <djb@cr.yp.to>, tls@ietf.org
From: S Moonesamy <sm+ietf@elandsys.com>
In-Reply-To: <20241221081913.278129.qmail@cr.yp.to>
References: <AE56D7F9-68EE-4566-96AF-134B25CF6EF2@akamai.com> <20241221081913.278129.qmail@cr.yp.to>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Message-ID-Hash: T65FRMQIG5ET5LUEV6GRPYIEI5K6VSHY
X-Message-ID-Hash: T65FRMQIG5ET5LUEV6GRPYIEI5K6VSHY
X-MailFrom: sm@elandsys.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: [TLS] Re: PQ Cipher Suite I-Ds: adopt or not?
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/44NckzMi74ozQecAtxq1R6QY8uI>
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>

Hello,
At 12:19 AM 21-12-2024, D. J. Bernstein wrote:
>Salz, Rich writes:
> > No, the IETF does not require controversies to be resolved. It
> > requires "rough consensus."
>
>I don't know what dividing line you're drawing here.
>
>Whatever terminology is used, WG action requires general agreement. This
>doesn't necessarily mean unanimity, but the WG is obliged to fairly
>consider each objection and to try to resolve each objection. If
>resolution fails and an objection ends up being overridden then there
>has to be documentation explaining why that objection was overridden.
>
>My source for these statements is authoritative and binding upon IETF,
>but naming the source here would be risky given threats by the WG chairs
>(currently under appeal), so I'm not naming the source in this message.
>I will, however, point to a non-authoritative source that's well worth
>reading on these topics, namely RFC 7282. For example, that RFC says the
>following: "What can't happen is that the chair bases their decision
>solely on hearing a large number of voices simply saying, 'The objection
>isn't valid.' That would simply be to take a vote. A valid justification
>needs to me made. ... Simply having a large majority of people agreeing
>to dismiss an objection is not enough to claim there is rough consensus;
>the group must have honestly considered the objection and evaluated that
>other issues weighed sufficiently against it."

Eric Rescorla pointed out yesterday that the procedures under which a 
working group operates is described in RFC 2418.  Those procedures 
have been in use since 1998.  From what I understand of the 
discussions, the working group was asked whether there were any 
documents it wishes to work on.  The person taking the decision (it's 
generally a working group Chair) would have to figure out whether the 
persons within the working group are sufficiently motivated to 
complete the work on one or more documents.  The person may have 
other considerations as there might be some planning to be done.  The 
person taking the decision is generally allowed some leeway.

It may happen that there are different opinions on 
procedural/technical outcome(s).  A course of action [1] would be to 
seek general agreement.  RFC 7282 tried to outline how decisions are 
taken in general.  That document also mentioned some pitfalls for the 
reader to think about.

Regards,
S. Moonesamy

1. It may happen that it is not an a viable alternative.