Paul Wouters writes: > Responding as AD Hmmm. I thought that a "person who disagrees with a Working Group recommendation shall always first discuss the matter with the Working Group's chair(s)", whereas AD involvement is only if "the disagreement cannot be resolved in this way". This provides multiple levels of opportunities to resolve disagreements.
So I posed a question to the chairs: specifically, asking how they came to the conclusion that there was consensus here. I also explained why I was asking. (Procedurally, I also shouldn't have to ask.) Does the new AD interruption mean that the chairs are no longer obliged to engage in discussion of their action? In other words, has the AD single-handedly destroyed a mandated opportunity for resolution? If so, what's the authorization for this under IETF procedures? The situation was already a bit messy before this (for example, were the chairs deterring input when they issued a consensus declaration before the end of the call period?), but at this point it's very difficult to figure out how the situation relates to how the IETF standardization process is supposed to work. I'm also not sure how this can be brought back to the proper procedures. Withdrawing the AD message isn't going to magically restore independent evaluation by the chairs. > There is clearly consensus > based on the 67 responses to the adoption call. [ ... ] > The vast majority was in favour of adoption [ ... ] > a few dissenting opinions I have an easy question and a harder question. The easy question, just to make completely sure that I'm not missing something: You're saying that the numbers here, such as "67" and "a few", were considered as part of your forming a conclusion that there's consensus here? (I assume the answer is simply "yes"---why else would the numbers have been brought up?---but I'd just like to make sure.) The harder question: For transparency, please explain how many different people you're referring to in saying "67 responses" and "vast majority" and "a few", and please provide details so that the rest of us can check your tallies. My impression from watching the list is that the actual ratio between the numbers of objectors and supporters is vastly larger than the ratio between "a few" and "67", for any reasonable understanding of "a few". > > There were several people (including me) raising objections on > > list to basic flaws in this draft [ ... ] > Not being a hybrid KEM is not a "basic flaw". The only reason that CECPQ2 didn't expose user data to pre-quantum attackers is that it had the common sense to include an ECC layer. > > (2) the failure to provide an engineering justification for this option > This is your own made up condition. No, it isn't: "Rather than bringing a fully-formed solution and looking for a use, begin by articulating _what issue or gap needs to be addressed_. ... In other words, _donât put the cart before the horse_: first convince the group that there's an important problem to solve." These quotes aren't from something binding on the TLS WG---they're quotes from a CFRG process document---but they're still doing a nice job of pinpointing one of the basic flaws in the ML-KEM draft. > > and (3) the lack of any principles that would justify saying no > > to options selected by other governments if this option is allowed. > This document does not set policy for other documents or governments, > so this "reason" is out of scope for the IETF. Non sequitur. Supporting endless options is a systemic security problem, so the WG shouldn't take every option that's proposed---but then there should be principles for the dividing line. This is entirely about what the WG is endorsing, not about the level of WG power over anyone else. > no raised technical issues Can you please clarify what exactly you mean by "technical" here, why this criterion factors into the question of whether there's consensus, and why the issues raised (e.g., the security risks of non-hybrids) don't qualify as "technical"? Thanks in advance. ---D. J. Bernstein
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
