[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
- [TLS] AD response to message on WG chair consensu… Paul Wouters