> On 28 Jun 2026, at 14:01, D. J. Bernstein <[email protected] > <mailto:[email protected]>> wrote: > >> no In-Reply-To header (which is slightly annoying to produce when one >> was not a participant in the list previously). > > Did you complain about the lack of an In-Reply-To header field in > multiple messages that have already shown up _supporting_ the document, > such as the message from NSA's Mike Jenkins? > […] > But there's also a much more basic point here about fairness. How can it > be okay for new TLS participants to support the spec, and not okay for > new TLS participants to oppose the spec?
I assume you mean my email, given that (from a quick skim, admittedly) I’m the only other new TLS participant in support. And I agree with Filippo: frankly, my opinion should probably be less weighted on this matter! I certainly believe myself to have sufficient context to comment on this, or I would not, as I have not in the past. But of course there is no reason for you to believe that. My only direct contribution to the IETF is draft-sfluhrer-cfrg-ml-kem-security-considerations with the CFRG (and I would absolutely appreciate and welcome further contributions to that document from anyone here, by the way!). But, I have avoided participating in the mailing list, for reasons I suspect many here would be familiar with, and it seems eminently reasonable for that to be taken into consideration when I voice my support for the draft. Cheers, Kevin > On 28 Jun 2026, at 14:01, D. J. Bernstein <[email protected]> wrote: > > Filippo Valsorda writes: >> I want the WG and the chairs to be aware that Bernstein is now >> coordinating a campaign to get dissenting opinions emailed to the >> list. > > Your quote ("You can have your voice heard too" etc.) omits important > context from <https://nsa.2026.action.cr.yp.to>, namely the paragraph > immediately before the quote. Here's that paragraph: > >>> NSA lost the most recent mlkem vote in the IETF TLS working group. >>> However, they've now called another vote and are trying to pack the >>> room. For example, a positive vote has now appeared from NSA's Mike >>> Jenkins, who has _never_ shown up on the working-group mailing list >>> before. This is _allowed_ under IETF rules, which say that "There is >>> no membership in the IETF" and that "Anyone can participate by >>> signing up to a working group mailing list". > > When NSA's Mike Jenkins showed up on the TLS list to post the three > words "I support publication" without having ever posted anything to the > list before, did you complain about that? Did you complain about the > people from NSA asking him, even paying him, to do this? > > We seem to agree that IETF rules allow such actions. Why exactly are you > (1) complaining about such actions in the first place, (2) targeting > those complaints solely at _opponents_ of the document, and (3) omitting > the explicit context of _proponents_ already taking such actions? > >> no In-Reply-To header (which is slightly annoying to produce when one >> was not a participant in the list previously). > > Did you complain about the lack of an In-Reply-To header field in > multiple messages that have already shown up _supporting_ the document, > such as the message from NSA's Mike Jenkins? > >> the interpretation that consensus is a voting process is incorrect and >> in bad faith > > Did you ask the chairs to withdraw their claim that, for solo ML-DSA, > "There is consensus to move this document forward - a ratio of 4:1"? > That claim is using the purported ratio of supporters and opponents as > its sole basis for claiming consensus. > > (I'm saying "purported" because, in fact, the situation at the end of > WGLC for that document was 14 people having stated opposition on list, > 37 people having stated support on list. This is a ratio of 2.64, not > the "4:1" fiction from the chairs. But that's a separate issue.) > >> the degree to which individuals have participated in the WG in the >> past should be part of how their opinion is weighted into calling the >> consensus of the WG. > > Did you use this rationale to ask the chairs to discount the message > from NSA's Mike Jenkins supporting the document, the only message that > he has ever sent to the TLS mailing list? > > How about the messages from NSA's Nicholas Gajcowski supporting the two > solo PQ documents? Those are the only two messages that he ever sent to > the TLS mailing list. (To be clear, this is according to not just IETF's > limited archives of the list but also to my own list archives going back > to when I joined last century.) > > As a reminder: "IETF procedural rules, which include robust appeal > options, are well-documented in public materials, and rigorously > followed." If you'd like to have some people count as, let's say, only > 3/5 of other people, then you'll have to find where this is documented > in IETF's procedural rules, and you'll have to rigorously follow it. > > What IETF actually says is that it's not a "pay-to-play organization", > that "51% of the working group does not qualify as 'rough consensus' ", > that WG-issued RFCs have "consensus of the IETF community", etc. There > are also legal requirements for standards-development organizations to > address all "objections by interested parties", among other rules. So > there are a bunch of obstacles to any attempts to disenfranchise people. > > But there's also a much more basic point here about fairness. How can it > be okay for new TLS participants to support the spec, and not okay for > new TLS participants to oppose the spec? How can it be okay for NSA to > overtly wave around huge amounts of money for its "vendors" to push the > controversial idea of weakening ECC+PQ to solo PQ, and not okay when the > opposition posts a message asking for volunteers to speak up in favor of > the public interest? > > ---D. J. Bernstein > > > ===== NOTICES ===== > > IETF BCP 78, "Rights Contributors Provide to the IETF Trust", Section 5 > (normative), "Rights in Contributions", provides a modification right > "unless explicitly disallowed in the notices contained in a Contribution > (in the form specified by the Legend Instructions)". > > The official language from IETF's "Legend Instructions" for the > situation that "the Contributor does not wish to allow modifications nor > to allow publication as an RFC" is as follows: "This document may not be > modified, and derivative works of it may not be created, and it may not > be published except as an Internet-Draft." > <https://trustee.ietf.org/wp-content/uploads/Corrected-TLP-5.0-legal-provsions.pdf> > > The same language is used in, e.g., RFC 5831. The same language hereby > applies to this document. This is not disclaiming or limiting the > applicability of IETF policies; it is strictly following IETF policies. > > IESG claims that the "explicitly disallowed" provision in BCP 78 is > limited to the examples in Section 3 in BCP 78. That is incorrect. BCP > 78 states that Section 5, "Rights in Contributions", is normative, while > Section 3, "Exposition of Why These Procedures Are the Way They Are", is > informative. The opt-out provision in the normative text is clear, and > cannot be limited by an informative section. BCP 78 does not give IESG > any authority to issue changes or purported clarifications of the rules. > > Rationale for exercising the BCP 78 opt-out provision: I'm fine with > redistribution of copies of this document. The issue is instead with > modification, such as (1) IESG's May 2025 posting of an IESG-mangled > version of an appeal that I had filed and (2) IETF management selling > IETF mailing-list text to AI companies. This goes far beyond what > copyright law allows as fair use (such as giving quotes for purposes of > commentary). When I complained about the mangled document, the IETF > Executive Director responded not by apologizing but instead by asserting > that IETF management had the power to do whatever it wanted. >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
