[ Responding as AD, omitting disfunctional direct email address ]
On Tue, 15 Apr 2025, D. J. Bernstein wrote:
Date: Tue, 15 Apr 2025 15:53:51
From: D. J. Bernstein <d...@cr.yp.to>
To: tls@ietf.org
Subject: [TLS] Re: WG Adoption Call for ML-KEM Post-Quantum Key Agreement for
TLS 1.3
Sean Turner writes:
Hi! It looks like we have consensus to adopt this draft as a working
group item.
Um, what? There were several people (including me) raising objections on
list to basic flaws in this draft
The term "basic flaws" here is mis-used. There are no known "basic flaws"
in pure ML-KEM. If you know of a flaw, please present evidence in the
form of a proper reference to the flaw. Your preference for hybrid over
pure is not a "basic flaw", and those preferring hybrids can choose to
only use hybrids.
, such as (1) the failure to provide an
ECC backup to limit the damage from further security problems in the PQ
layer
Not being a hybrid KEM is not a "basic flaw". The additional security
from hybrids comes at a complexity cost that people have different
opinions about. There will also obviously be differences of opinion on
when hybrids will have outlived their security premise in the future,
and so supporting both now and letting implementers make their own
choices on which defaults to use now and when to migrate in the future
is up to them. The TLS WG, along with CFRG backed by the larger
cryptography community will continue to play an advisory role here
over the next years.
(2) the failure to provide an engineering justification for this option
This is your own made up condition. People who do not wish to rely on
pure PQ can already use a hybrid PQ. There are those who wish to use
pure PQs, and your reasons for not letting them are not widely supported
within the IETF or the TLS WG, as can be seen by other protocols also
implementing pure PQ algorithms.
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.
Your message doesn't explain how you came to the conclusion that there's
consensus. Surely you aren't relying on some tally of positive votes to
ram this document through while ignoring objections; voting isn't how
IETF is supposed to work. So how _did_ you come to this conclusion?
I have reviewed the responses to this WGLC. There is clearly consensus
based on the 67 responses to the adoption call. I support the TLS WG Chairs
decision on calling consensus. If you wish to appeal the TLS WG Chairs
decision based on RFC 2026, Section 6.5.1 you may do so by contacting me
using a working email address. If you present no new information to your
appeal to the chairs, I would deny your appeal. My decision could then
be appealed with the IESG.
The vast majority was in favour of adoption, and this included several
vendors who stated they have implementations. There were further no
raised technical issues. There were a few dissenting opinions that
preferred pure PQ should not be done at all. Note that this document
does not set a mandatory to implement or RECOMMENDED Y option, allowing
those who wish to avoid pure PQ to keep avoiding these in the future.
Your arguments on whether hybrid is more secure than pure would be
valid arguments in a discussion about MTI or RECOMMENDED status.
However, this is not that discussion.
As a procedural matter, this lack of explanation is in violation of
"IETF activities are conducted with extreme transparency, in public
forums". Please rectify this violation immediately. Also, please state
the procedures for appealing your action. Thanks in advance.
There is no such violation, and you cherry-picking when to call
consensus evaluation "voting" depending on whether misnaming this
is in your advantage (eg recently on the ssh list) is dishonestly
manipulative and has no place on this list or anywhere else at the IETF.
Your insinuation that this WGLC was not conducted with "extreme
transparency" is in itself a violation of our code of conduct through
insinuations and a continuation of behaviour you have been warned
about recently by the TLS WG chairs, confirmed via me as the TLS AD,
and the IESG[1]. I recommend you voluntarily stop this kind of behaviour
to avoid triggering measures under the terms of RFC3934 which is part
of BCP25.
You are free to voice your dissent. You are not free to make up
accusations against process or individuals.
Paul Wouters, speaking as TLS Area Director
[1] https://datatracker.ietf.org/group/iesg/appeals/artifact/126
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
