I think this discussion should be moved to a separate mailing list. The current discussion is not technical and has very little to do with the TLS WG.
Procedural: I think the chairs and ADs are handling this well. Technically: I think reuse of "ephemeral" keys is a vulnerability waiting to happen. John Sent from Commodore VIC-20 ________________________________ From: D. J. Bernstein <[email protected]> Sent: Saturday, June 14, 2025 3:15:38 AM To: [email protected] <[email protected]> Subject: [TLS] Re: Complaint regarding a declaration of consensus to adopt a non-hybrid draft Paul Wouters writes: > Before we can get to the content of the complaint (aka appeal), I need > to clarify some process issues with your message. Happy to discuss. However, the "need" statement is incorrect (see below), so please go ahead with answering the contents. > 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, RFC 2026 says "any of the parties involved may bring it to the attention of the Area Director(s) for the area in which the Working Group is chartered. The Area Director(s) shall attempt to resolve the dispute". There is a dispute about the mid-April declaration that there was TLS WG consensus to adopt this non-hybrid Kyber draft. I explicitly brought this dispute to the attention of both ADs. Ergo, both ADs "shall attempt to resolve the dispute". RFC 2026 has a precondition involving discussion with the WG chairs. In the case at hand, that discussion led to the WG chairs (1) sticking to their claim of consensus and (2) explicitly authorizing an appeal. Structurally, the message that I'm replying to doesn't appear to be arguing that the situation at hand is somehow outside RFC 2026's "shall attempt to resolve the dispute" requirement. It's raising various side issues---which, again, I'm happy to discuss, but this discussion doesn't remove this RFC 2026 requirement. > I will be > the only Area Director handling your message at this point, To clarify, you're saying that the other AD won't attempt to resolve this dispute? Surely you wouldn't be able to make such a statement without discussion with the other AD; can you please point to the records of that discussion? (Dates, minutes, email records, etc.) > which is presumably aimed to be a message under BCP 9 (RFC 2026) > Section 6.5.1. The document explicitly says it's invoking Section 6.5.1 of RFC 2026, and pinpoints the specific paragraph it's invoking. Consequently, the word "presumably" is inaccurate. > Second, I am unable to respond privately You can send private email to [email protected], but you shouldn't: that would be a transparency violation. This is a complaint about an action by TLS WG chairs regarding TLS WG activity, so I requested that all discussion of this complant be cc'ed to the TLS mailing list. Anyway, "The Area Director(s) shall attempt to resolve the dispute" does not make an exception for ADs who ask for non-transparency. > The TLS WG list should not be used as a backup for not being able to > receive direct emails. This statement has nothing to do with my complaint. My complaint cited various transparency requirements, and on that basis asked for the discussion of this TLS WG consensus call to take place on the relevant mailing list, the TLS list. > 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: No. A quote saying that a WG chair "may" do something doesn't say that other people can't. > That is to say, WG Chairs may decide a complaint is or isn’t suitable for > further discussion on the WG list. RFC 2026 doesn't say that. Furthermore, transparency requires IETF to be public in how it handles complaints about IETF standardization activity. > By continuing your participation using Contributions, you are > agreeing to operate under this Note Well. As my complaint already noted, IETF cannot ask people to give up other rights in exchange for appeals. > 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. https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fweb.archive.org%2Fweb%2F20250613195523%2Fhttps%3A%2F%2Fcr.yp.to%2F2025%2F20250605-non-hybrid.pdf&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7Ca15c63c1aff84a5d373808ddaae105b7%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638854610406250496%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C80000%7C%7C%7C&sdata=0QpZVTsjYYunh6hn3qokqUy%2BjOgSSajaDxfdSXjbvRY%3D&reserved=0<https://web.archive.org/web/20250613195523/https://cr.yp.to/2025/20250605-non-hybrid.pdf> has a copy, so the archiving concern seems misplaced. More to the point, "The Area Director(s) shall attempt to resolve the dispute" is not limited to disputes that were brought to AD attention via permanently archived documents. > The PDF format also discourages participation Such a broad general statement is certainly not true. For example, other formats are more likely than PDFs to be displayed in mangled form; when that happens, those formats are discouraging participation. I'm not saying PDF is always better than other formats. The evaluation depends on many factors, such as the type of material being presented. I often post PDFs, but I often post information in other formats. PDF is also one of the formats that IETF habitually uses, although certainly not the only one. Anyway, "The Area Director(s) shall attempt to resolve the dispute" does not make an exception for disputes documented as PDFs. > as the content cannot be easily replied to preserving context via > email threads on the TLS WG mailing list. The message I'm now replying to is, in turn, replying to an earlier message of mine---but for some reason _doesn't_ use the standard threading header fields to show this. So I'm puzzled to see the message also recognizing that threading is a positive feature. A reply can and should be posted under the original subject line, in the same thread, for easy tracking, even if the reply is simply a link to another document. I understand that your mail software doesn't make it as easy for you to quote a PDF as to quote something else, but typing time is a very small part of normal procedures for dispute resolution. > 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". It provides the requisite transparency. It provides other people an opportunity to comment if they would like to. > This is not a valid use of the TLS WG mailing list. My complaint is on topic for the TLS WG mailing list. See above. The message I'm replying to is unnecessarily "meta": in particular, it explicitly avoids the actual content of the complaint. However, it's portrayed as a step towards addressing the content. > Furthermore, previous efforts of converting your remotely hosted PDFs > to a local location within the IETF archives for the community by the > IESG I guess you're talking specifically about one particular earlier PDF, namely https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcr.yp.to%2F2025%2F20250501-bcp-79.pdf&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7Ca15c63c1aff84a5d373808ddaae105b7%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638854610406275249%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C80000%7C%7C%7C&sdata=AYdp2of2R6ibbuZn%2FvD4h%2BvVzHRY01XjXTV9Mcff8qo%3D&reserved=0<https://cr.yp.to/2025/20250501-bcp-79.pdf>. IESG did _not_ simply repost a copy of that PDF. In particular, that document has a central diagram with two main items and various subitems; IESG posted a modified version of the document that destroyed this structure, instead showing a dozen main items in the diagram. Eventually I noticed this and complained, and it was fixed---but what other changes did IESG make? The bigger problem, before and after the fix, is that IESG placed a burden on the reader to (1) realize that something changed and (2) figure out what changed. The issue here isn't permanence. The issue is IESG turning a simple situation of a single document into an unnecessarily complicated situation of (1) an original document and (2) an unauthorized IESG-modified version of the document. There still has been no statement of why IESG modified the document in the first place. > have resulted in claims on your end of "gross misrepresentation" It's true that the words "gross misrepresentation" appear in the email that's linked at the end of this paragraph in your message. However, that email wasn't from me. Please note that one basic part of proper dispute resolution is simply tracking who said what. One of my reasons to ask for multiple people to handle this complaint is that this reduces the risk of error. > merely for containing formatting changes: Claiming that the changes were just "formatting changes" ignores the fact that IESG changed the meaning of the document. > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fadmin-discuss%2Fy6eNBaogfeCZ2oEVyVmdrEPrjJg%2F&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7Ca15c63c1aff84a5d373808ddaae105b7%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638854610406289672%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C80000%7C%7C%7C&sdata=7TtgRoKhA8BV36x%2BBY7kfxNzwFlzIVIgMuRH7H0%2BAe8%3D&reserved=0<https://mailarchive.ietf.org/arch/msg/admin-discuss/y6eNBaogfeCZ2oEVyVmdrEPrjJg/> Thank you for the link. > Your remotely hosted PDF furthermore contains text disallowing the > content to be reformatted and thus quoted. No. The document contains a reminder of various rights, such as copyrights and the right to appeal, but those rights exist whether or not they're pointed out. More to the point, "The Area Director(s) shall attempt to resolve the dispute" does not make an exception for ADs complaining about copyright on documents that describe the dispute. > This prevents me and others from discussing the content. No, it does not. For example, copyright has a "fair use" exception, which I'm comfortably relying upon here in giving many quotes and commenting individually on each quote, allowing readers to easily track which comment is in reply to which quote. > 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. "The Area Director(s) shall attempt to resolve the dispute" makes no reference to the question of what constitutes a "Contribution". > If it is not a Contribution, it cannot be a complaint (appeal) under RFC > 2026 Section 6.5.1. That section says no such thing. > If it is a Contribution, it cannot come with its own stipulated > restrictions. See above. > The text, which you did not consent me to quote, does not > comply with your agreed participation under the Note Well. "The Area Director(s) shall attempt to resolve the dispute" does not make an exception for ADs issuing complaints about alleged violations of other procedures. > 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 My complaint is not confidential. Creating derived works, as IESG did with a previous PDF, is modification, not dissemination. > This text states that due to your dissemination modifier, your PDF file > cannot be considered a Contribution in any part of the Standards Process. No, the text certainly doesn't state this, nor does it imply it, nor do any of these references to confidentiality provisions create exceptions to "The Area Director(s) shall attempt to resolve the dispute". I'll stop commenting on the "Contribution"-related claims after this. > This is, however, further updated by RFC3978 Section 3.2 which states: > 3.2. Confidentiality Obligations Again, this is not a confidential document. Are your discussions with other IETF LLC agents regarding this matter confidential? Where are the records of those discussions? > 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. Again, RFC 2026 says "any of the parties involved may bring it to the attention of the Area Director(s) for the area in which the Working Group is chartered. The Area Director(s) shall attempt to resolve the dispute". This doesn't allow ADs to put limitations on the mechanism of bringing the dispute to their attention. > Either way, this prevents me from processing your complaint under the > Internet Standards Process. No, it doesn't. See above. > Fourth, your email to the TLS WG list (thus per definition a Contribution) > contains additional instructions that you are attempting to force "IETF participants have impersonal discussions." > 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 ([email protected]), including, > but not limited to, any discussions of this matter among IESG members, > IAB members, agents of IETF Administration LLC, etc. IETF LLC says that IETF operates with "extreme transparency". RFC 2026 says that "Each of the organizations involved in the development and approval of Internet Standards shall publicly announce, and shall maintain a publicly accessible record of, every activity in which it engages, to the extent that the activity represents the prosecution of any part of the Internet Standards Process". > You have been notified that this is inappropriate before, by the IETF > Executive Director: > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fadmin-discuss%2Fy6eNBaogfeCZ2oEVyVmdrEPrjJg%2F&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7Ca15c63c1aff84a5d373808ddaae105b7%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638854610406306298%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C80000%7C%7C%7C&sdata=u1OOVRXWVw33ZAQuTWaCTS7636RJitFcgSIPqUg2vDs%3D&reserved=0<https://mailarchive.ietf.org/arch/msg/admin-discuss/y6eNBaogfeCZ2oEVyVmdrEPrjJg/> I didn't see that message before---looks like it was diverted to some obscure mailing list, which is certainly contrary to the point of transparency rules. Anyway, the contents of the message don't say what you claim they're saying, and in any event they're not relevant to "The Area Director(s) shall attempt to resolve the dispute". > 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). See above. > 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. I have no idea how putting "Thanks in advance" after "Please ..." is conveying a "false aura of authority". > This is not appropriate use of the TLS WG mailing list. I've complained about an erroneous declaration of TLS WG consensus. The discussion of the complaint belongs on 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. Again: RFC 2026 says "any of the parties involved may bring it to the attention of the Area Director(s) for the area in which the Working Group is chartered. The Area Director(s) shall attempt to resolve the dispute". > Your unique personal process "IETF participants have impersonal discussions." > 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. Hyperlinks appear all the time on IETF mailing lists. > They may further feel prohibited from discussing your email > content - in email threads or otherwise - by your disclaimers and > stipulations on how to behave. Vague comments about "stipulations on how to behave" aren't addressing what actually happened here. As noted above, I posted a complaint with a central diagram having two main items and various subitems; IESG posted a modified version of the document that destroyed this structure, instead showing a dozen main items. I complained about this. Someone then fixed that particular problem, but there wasn't even an apology, let alone assurance that such incidents won't recur. > They might also be discouraged from engagement for safety reasons "Safety reasons"? What are you talking about? > and/or because following a discussion via attached PDF files is too > cumbersome. Regarding the oversimplified view of PDF as a bad thing, see above. Regarding "too cumbersome", it's up to individual participants to decide what they want to follow. Of course, IETF LLC agents in particular are under more stringent obligations, such as "The Area Director(s) shall attempt to resolve the dispute". > This in turn, might lead to a false sense of consensus in the WG. This unsubstantiated speculation about conceivable future events is not relevant to the complaint at hand, which is about an erroneous consensus call from mid-April 2025. Can you (and the other AD) please attempt to resolve the dispute, as required by RFC 2026? > You are requested by me as Area Director to stop engaging in this > behaviour. I understand that you're asking me to stop linking to PDFs. To clarify, am I correctly understanding that "request ... as Area Director" means "demand", with a threat that you will use your position as AD to impose punishment for non-compliance? What exactly do you believe gives ADs authority to ban links to PDFs? Note that draft-connolly-tls-mlkem-key-agreement normatively cites NIST's ML-KEM standard---which is a PDF. Is that also banned now? ---D. J. Bernstein
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
