[TLS] AD response to message on WG chair consensus call draft-connolly-tls- mlkem-key-agreement by D. J. Bernstein of 2025-06-05

Paul Wouters <paul.wouters@aiven.io> Thu, 12 June 2025 19:58 UTC

Return-Path: <paul.wouters@aiven.io>
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 E45E934538EE for <tls@mail2.ietf.org>; Thu, 12 Jun 2025 12:58:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: 1.71
X-Spam-Level: *
X-Spam-Status: No, score=1.71 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, THIS_AD=1.099, T_KAM_HTML_FONT_INVALID=0.01] autolearn=no autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (1024-bit key) header.d=aiven.io
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 c87bnykxze2m for <tls@mail2.ietf.org>; Thu, 12 Jun 2025 12:58:57 -0700 (PDT)
Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [IPv6:2a00:1450:4864:20::629]) (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 C283234538C5 for <tls@ietf.org>; Thu, 12 Jun 2025 12:58:57 -0700 (PDT)
Received: by mail-ej1-x629.google.com with SMTP id a640c23a62f3a-ad8a6c202ffso254255266b.3 for <tls@ietf.org>; Thu, 12 Jun 2025 12:58:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aiven.io; s=google; t=1749758337; x=1750363137; 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=Ta1Q4Srdxn9lVW1Teri1Zx/p3sDhYS9r2pPTfHpk9vQ=; b=ZY1s+ClQ8WYy68qfMXOChBRVmXQ/YelOJ+gBemOfZA0LmBGRp1iHFmgODpFiHiNv+D ZPFwzMoFuuoxC5a1t68bdbwvpKLr6wLr1xyj2gJ+tngl8xlY95GSlOanK4y45qoHZjse RDfI/EOXnTFJ1GOpKk8SgcDdH2umCweSpZj7c=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1749758337; x=1750363137; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Ta1Q4Srdxn9lVW1Teri1Zx/p3sDhYS9r2pPTfHpk9vQ=; b=E75sHv2jqE9Wa4bBbmrCIz53HHP5lLPWwZCgIPSV2QwKSqaBU0enusd0a5NRhvzV+c +FKLK7jFuKlkjTPbcAhuIc7wHESjhulDNJKPp1jonXpqXOxdvKAqOJHJleonvHF1B+Hq l1jW6sCiYSG2WcQPpzB102VS1yosn6AzO9VIq4HPIE6enUCwsYrNZroY5m9bB9f+ciKU oyiAQdXmmgekRb65yR3eCEy4EHl8MJg/Nq8Hagcp2+joHSTvd0B1lNmEdtP2Ud+0OUXI KTg8aXzFmtNqSvFOnvoFV810bVulvL9KFOn9SX1eLPoAk+vO8y1aapoy+xNZSwWsJreU a3lw==
X-Gm-Message-State: AOJu0Yyy2qHA+Z4A9yz9A9UJL3AQ7U1O6oW7nbJ47wBuO2s7/y9SjH1H Beokn+Kue7zomk21gsJch/pTpyaBwLeUX1dOnkdehFr8jmRFQTnTGYHl7m5MbH2lvVpXUeqq89D Q4TdrZhqq+gaUWTb4AOqBp2eq+a9AI2BOkkeIMJCl6H+gCA0CvaylfFo=
X-Gm-Gg: ASbGncvf3QVQ2YTLMV7ti4Y2GDVcXEk8yEuUA/95c1qITj5G1lsgtYE2JEbQ/2HSWw3 v6W/8wicbg/G5L3TV8dWO6XqGA5CKqA2il/dHVMK3mY89BUppm5VlsYMUmG3YtZv85wBG0oBY7w R9v0FpaGNtD8w4BBB9Cx7uaJLSNGjmjAsuBWy7mpKABNwHrA==
X-Google-Smtp-Source: AGHT+IHSAWzaBgt4d5yii52kWU9WA4e1hIortPzAxZsu1sVMFb8K3m7MFKTRTfZfx16KiwowLKUVXSf9jdHx7eXxFXM=
X-Received: by 2002:a17:907:9344:b0:ad8:9c97:c2eb with SMTP id a640c23a62f3a-adec553baefmr54572566b.19.1749758336502; Thu, 12 Jun 2025 12:58:56 -0700 (PDT)
MIME-Version: 1.0
References: <CAGL5yWaMixv5sEEMbRvTef8q4OzdjRYre7wA28VosTvQfGfq7Q@mail.gmail.com>
In-Reply-To: <CAGL5yWaMixv5sEEMbRvTef8q4OzdjRYre7wA28VosTvQfGfq7Q@mail.gmail.com>
From: Paul Wouters <paul.wouters@aiven.io>
Date: Thu, 12 Jun 2025 15:58:44 -0400
X-Gm-Features: AX0GCFvJGckjbBtPOwWJxXNN9ch_9uR3SCbkdm5Cb4LBMjHdOrr2hknNYmUjjTI
Message-ID: <CAGL5yWZoSGxi0i3npwvpHHm0_oBm2DisXucGt0mQtvSTVKPKtw@mail.gmail.com>
To: "D. J. Bernstein" <djb@cr.yp.to>
Content-Type: multipart/alternative; boundary="00000000000017708e0637655cd2"
Message-ID-Hash: KBZWMX36AYJAQQXRWGCI3SQFS72GDJU7
X-Message-ID-Hash: KBZWMX36AYJAQQXRWGCI3SQFS72GDJU7
X-MailFrom: paul.wouters@aiven.io
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: "<tls@ietf.org>" <tls@ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [TLS] AD response to message on WG chair consensus call draft-connolly-tls- mlkem-key-agreement by D. J. Bernstein of 2025-06-05
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/eSW2K3Ql1jzMcN-Aj1EYCGOLu9o>
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>

> To the Security ADs, cc'ing tls@ietf.org:

> I am writing to file https://cr.yp.to/2025/20250605-non-hybrid.pdf with

> both of you.  For transparency, please carry out all discussion of this

> matter on the relevant public mailing list (tls@ietf.org) including,

> but not limited to, any discussions of this matter among IESG members,

> IAB members, agents of IETF Administration LLC, etc. Thanks in advance.

>

> ---D. J. Bernstein

Hi Dan,

Before we can get to the content of the complaint (aka appeal), I need to
clarify some process issues with your message.
Process clarifications by the responsible Area Director of TLS, Paul Wouters

First, the Security Area Directors have divided their work based on Working
Groups, with me being the responsible AD for the TLS WG so as per the
Security Area workflow decided by the Security Area Directors, I will be
the only Area Director handling your message at this point, which is
presumably aimed to be a message under BCP 9 (RFC 2026) Section 6.5.1.

Second, I am unable to respond privately to your email address <djb@cr.yp.to>
from my official IETF email address <paul.wouters@aiven.io> as per my
datatracker profile due to an auto-responder attempting to impose
additional restrictions before receiving email.  This prevents me from
fully executing my role of Area Director in the Internet Standards Process
via use of email, such as for BCP 9 RFC 2026 Section 6.5.1 actions related
to "may bring [matters] to the attention of the Area Director(s) for the
area". The TLS WG list should not be used as a backup for not being able to
receive direct emails. Please use a fully functional email address.

Note that as per Section 6.5.1, it is the Working Group Chairs who may
decide whether or not to involve the WG as a whole:

   A person who disagrees with a Working Group recommendation shall

   always first discuss the matter with the Working Group's chair(s),

   who may involve other members of the Working Group (or the Working

   Group as a whole) in the discussion.

That is to say, WG Chairs may decide a complaint is or isn’t suitable for
further discussion on the WG list. Further conditions apply, see below.


Third, by participating on the IETF mailing lists, you have agreed to
participate under the terms of the Note Well (www.ietf.org/about/note-well/)
which lists several BCPs related to IETF participation including BCP 9 and
BCP 25. By continuing your participation using Contributions, you are
agreeing to operate under this Note Well.  However, this complaint has been
filed in the form of, in essence, an indirect remotely hosted link to the
complaint itself.  This raises concerns since there is no guarantee of the
permanence of the material behind that link, and the content will not be
part of the IETF public mail archive. The PDF format also discourages
participation as the content cannot be easily replied to preserving context
via email threads on the TLS WG mailing list. Thus, an email to the TLS WG
mailing list consisting of a (link to) PDF does not "involve the Working
Group as a whole in the discussion". This is not a valid use of the TLS WG
mailing list.

Furthermore, previous efforts of converting your remotely hosted PDFs to a
local location within the IETF archives for the community by the IESG have
resulted in claims on your end of "gross misrepresentation" merely for
containing formatting changes:

https://mailarchive.ietf.org/arch/msg/admin-discuss/y6eNBaogfeCZ2oEVyVmdrEPrjJg/

Your remotely hosted PDF furthermore contains text disallowing the content
to be reformatted and thus quoted. This prevents me and others from
discussing the content. Additionally, as you did not mail the PDF to any
IETF mailing list, there is now a question as to whether this link to a
remotely hosted PDF is considered a Contribution under the IETF Note Well.

If it is not a Contribution, it cannot be a complaint (appeal) under RFC
2026 Section 6.5.1.

If it is a Contribution, it cannot come with its own stipulated
restrictions. The text, which you did not consent me to quote, does not
comply with your agreed participation under the Note Well. BCP 9 (RFC 2026)
Section 10.2 states:

   10.2  Confidentiality Obligations

   No contribution that is subject to any requirement of confidentiality

   or any restriction on its dissemination may be considered in any part

   of the Internet Standards Process

This text states that due to your dissemination modifier, your PDF file
cannot be considered a Contribution in any part of the Standards Process.
This is, however, further updated by RFC3978 Section 3.2 which states:

3.2.  Confidentiality Obligations

   No information or document that is subject to any requirement of

   confidentiality or any restriction on its dissemination may be

   submitted as a Contribution or otherwise considered in any part of

   the IETF Standards Process, and there must be no assumption of any

   confidentiality obligation with respect to any Contribution.  Each

   Contributor agrees that any statement in a Contribution, whether

   generated automatically or otherwise, that states or implies that the

   Contribution is confidential or subject to any privilege, can be

   disregarded for all purposes, and will be of no force or effect.

This statement confirms you may also not submit the remotely hosted PDF -
in its form as it appeared when I downloaded it - to an IETF mailing list
(or as a private email to an AD) and that if you do, it "[may not be]
considered in any part of the IETF Standards Process".

However, it is also possible to argue that remotely linked content has not
in fact been submitted under the IETF Note Well and are thus not
Contributions as per RFC3978. In that case, you have not actually submitted
a complaint under RFC 2026 Section 6.5.1 either.

Either way, this prevents me from processing your complaint under the
Internet Standards Process.

Fourth, your email to the TLS WG list (thus per definition a Contribution)
contains additional instructions that you are attempting to force onto the
Internet Standards Process that are not codified in any RFCs:

        For transparency, please carry out all discussion of this

        matter on the relevant public mailing list (tls@ietf.org)
including,

        but not limited to, any discussions of this matter among IESG
members,

        IAB members, agents of IETF Administration LLC, etc.

You have been notified that this is inappropriate before, by the IETF
Executive Director:

https://mailarchive.ietf.org/arch/msg/admin-discuss/y6eNBaogfeCZ2oEVyVmdrEPrjJg/

By insisting on including this language, you are misleading participants
about their responsibilities and obligations under the Internet Standards
Process as set forth by the IETF (again via the Note Well that you
voluntarily comply to by sending messages to IETF mailing lists). You are
purposefully amplifying this misleading text with a "Thanks in advance"
modifier, that further exacerbates the misleading message by giving it a
false aura of authority. This is not appropriate use of the TLS WG mailing
list.
Summary

Your message to the TLS WG list on June 5 2025 does not constitute a valid
submitted Contribution or complaint under RFC 2026 Section 6.5.1, but you
can rectify this by sending a compliant email to the Area Director and/or
TLS WG mailing list.
Addendum

Your unique personal process negatively affects the IETF Standards Process
by confusing participants in what they can and cannot do with the content
of your emails, including hyperlinks to off-site material that you sent to
the list. They may further feel prohibited from discussing your email
content - in email threads or otherwise - by your disclaimers and
stipulations on how to behave. They might also be discouraged from
engagement for safety reasons and/or because following a discussion via
attached PDF files is too cumbersome. This in turn, might lead to a false
sense of consensus in the WG.

You are requested by me as Area Director to stop engaging in this
behaviour. You may continue emailing the TLS WG list, like any other
participant, by sending text or html based emails with inline content of
IETF discussions, limiting external references to non-IETF resources to be
informative information. That is, the main discussion of any work under the
Internet Standards Process (which may include complaints/appeals) are to
happen inline on the respective mailing list allowing for proper public
archiving and/or through direct emails to the WG Chairs and/or Area
Director. You (like everyone else) must not add additional restrictions or
suggest additional processing procedures in your Contributions, compliant
to BCP 9 and BCP 25.  See the IETF Note Well for full details on the
mandatory requirements for participating with the IETF.
Possible courses of action

The following possible actions that comply to the IETF Note Well are
available to you:
Email the AD directly without community email lists

Appeals under RFC 2026 Section 6.5.1 are not required to be posted to an
IETF Mailing List and can be sent via email directory to the Area Director.
You can email your appeal in a format you think the Area Director can read.
The email should, as indicated above, contain all normative text related to
the appeal within the body of the email. It may of course include normative
references to IETF resources, and informative references to non-IETF
resources. The email will be treated as an IETF Contribution, meaning that
any language contrary to the Internet Standards Process will have no force
or effect. You may use a PDF format, but my response will be inline regular
email, so I recommend against using the PDF format if you wish for me to
quote text from your message in my response.

You should use my official IETF datatracker email account of
paul.wouters@aiven.io and you should send it from an address that can
receive a reply without adding further constraints or conditions on
receiving a responding email (e.g. "QRsecretary").

If you wish to not engage in private-only emails, you may CC: the
iesg@ietf.org on such emails for transparency.
Email the AD, along with the TLS WG

You may email your appeal in regular text or html email to the TLS WG list.
This will have the additional benefit over the above listed method that it
involves the TLS WG community that can further give technical feedback on
the technical parts of your complaint (appeal) that are in scope for the
TLS WG, as meant under RFC 2026 Section 6.5.1, second paragraph.

Note that the TLS WG is not a place to discuss the Internet Standards
Process itself, so if a discussion is no longer related to technical
matters within the TLS WG charter, you may be asked by the WG Chairs or AD
to continue the discussion elsewhere, for example at ietf@ietf.org or the
mailing list of the PROCON WG (if/when formed).

Emails should not include language that violates BCP 9 RFC 2026 Section
10.2 or BCP 25 RFC3978 Section 3.2 and should not include processing
instructions that are not backed by our Internet Standards Process.
Abandon the complaint

You are free to abandon your attempt to file a complaint that is in
compliance with the Internet Standards Process. In that case, no further
action is required on your part.
Appeal this AD process clarification

I hope the explanation of the Internet Standards Process above is clear
enough that you are able to address the issues in your complaint allowing
you to file an updated compliant version of your message to me for
processing, before escalation to the IESG. But as with any AD decision, you
may appeal this decision with the IESG under BCP 9 RFC 2026 Section 6.5.2.

Paul Wouters
Security Area Director