[TLS] Re: WG Last Call: draft-ietf-tls-mlkem-08 (Ends 20 26-07-08)

Please let's not correct each other's english. Especially those are 
aren't native english speakers. Next time I suggest you just ignore it 
instead of posting to the list.

On 7/4/26 16:46, Sandip Dholakia wrote:
> Some verbs stay “put” - unless, of course, you are a golfer 
> and “putted” on the course! 🤣😎
>
> Sandip
> Sent using my 1970s Typewriter!
> (248)962-3143
> LinkedIn
> GoogleScholar
> Modern Cryptography
>
>
> On Fri, Jul 3, 2026 at 4:59 PM Sofia Celi <[email protected]> wrote:
>
>     I idiotically just realised I putted ML-DSA ;) Meant, ML-KEM ahaha
>
>     Thank you,
>
>     On 03/07/2026 21:38, Sofia Celi wrote:
>     > Hi, all!
>     >
>     > I was thinking on weighing on this very dramatic discussion for
>     a while,
>     > and thought it might be worthwhile. For context, as people are now
>     > checking the credentials of people posting in this mailing list:
>     I’m
>     > Sofia Celi, not long a go I was the chair of the PQUIP WG, HRPC
>     RC and a
>     > member of the Ombusteam. I resigned to those positions some
>     months ago.
>     > I’m also a cryptographer and I have won numerous awards on
>     research by
>     > the IEEE S&P and NDSS. I have also published extensively on
>     cryptography
>     > and systems since 2022 at top-tier peer-reviewed publication venues.
>     >
>     > I neither support publication nor not publication of this
>     document on
>     > the reason that I don’t understand why we need such a document
>     (yes,
>     > organisations and liaison statements have asked for this, but,
>     as far as
>     > I know, that's a request, not an argument. The IETF publishes on
>     rough
>     > consensus and technical merit, not on demand. Liaison statements
>     are
>     > inputs to said judgement, not instructions; and per RFC 7282,
>     consensus
>     > was never a headcount of who wants something in the first
>     place), but
>     > also I don’t see much harm on publishing it (to the dismay of
>     some, ML-
>     > DSA is already a NIST standard. This means it can be freely be
>     used by
>     > the Internet either in a hybrid manner or solo. Having an IETF
>     > informational document on this does not hurt in my opinion: in
>     fact, the
>     > vast majority of people deploying cryptography nowadays i. Don’t
>     even
>     > know what the IETF is ii. Choose to push any type of cryptography
>     > regardless of, iii Do not want to bother with the IETF process).
>     > However, in general I’m fully on board with https://www.ietf.org/
>     >
>     archive/id/draft-barnes-tls-this-could-have-been-an-email-00.txt: the
>     > TLS WG is not the best place to discuss cryptography algorithms
>     or their
>     > political implications: "The typical TLS WG participant is not a
>     > cryptographer, and the cryptographic choices of TLS users are
>     typically
>     > dictated by other factors than the opinion of the TLS WG". As
>     noted many
>     > times on this discussion, ML-DSA already has an IANA code point.
>     >
>     > On the basis of RFC 7282, the IETF publishes on rough consensus and
>     > technical merit. It doesn’t seem to me that the draft has in
>     itself much
>     > technical merit as it just notes the usage of ML-DSA solo in
>     TLS, as ML-
>     > DSA is already standardised by another body. This is not to
>     shame the
>     > authors (who I appreciate a lot for bearing this painful process
>     > regardless of the decision), but I don't think the purpose of that
>     > document is to standardise ML-DSA at the IETF and the draft
>     clearly does
>     > not do that nor the TLS WG is the place to standardise
>     cryptography. I
>     > guess the consensus question here is to decide that we agree on
>     > “Recommended:  N”: all the other text on that document is already
>     > standardised. ML-DSA is a standard, a code point exists, the
>     Internet is
>     > freely able to use only ML-DSA in TLS 1.3. The only “new” thing
>     this
>     > draft proposes is “Recommended:  N”. I don’t see publishing this
>     as an
>     > informational document at the IETF as a “stamp of approval” of
>     the IETF:
>     > what does that even mean? But, via the same argument, why does
>     this even
>     > need to be an IETF document?
>     >
>     > However, what does worry me is how horrid this process has been.
>     I don’t
>     > think it is fair to single out a single person for the toxicity
>     of this
>     > process. From all sides of this discussion I have seen said
>     toxicity.
>     > There are multiple Signal, Slack, Discord, Twitter (or X nowadays),
>     > blogs, HN discussions on this topic. Said discussions have
>     reached the
>     > level of attacking people based on who they are, based on the
>     geographic
>     > location they come from, publicly mocking people, digging
>     people's work
>     > and websites and mocking them, publicly accusing them of not
>     independent
>     > thinking (but rather that someone sent them), attributing bad
>     faith to
>     > anyone that disagrees with your position. This is shameful. Many of
>     > those channels and this IETF mailing list have participants that
>     are new
>     > to the field and it is a shame that they see how other people
>     publicly
>     > mock others to the degree that people now have to explain their
>     > credentials. Just for the record: Orr Dunkelman is a very great
>     > cryptographer that has multiple peer-reviewed publications, has
>     won an
>     > amazing set of awards and has an enviable career. You can
>     disagree with
>     > people but that does not give you carte blanche to attack them.
>     That one
>     > participant is using inflammatory language or publishing
>     blogposts does
>     > not give you carte blanche to do the same or worse.
>     >
>     > I implore this community to follow the chairs guideline: Let’s
>     stick to
>     > the consensus call, "I support" or do "I do not support" as was
>     > requested in the email that began this thread. Statement as the
>     > following  are not constructive and are quite toxic:
>     >
>     > - Labelling parts of a community credible and others as not
>     > - Asking who sent someone to weigh on the discussion
>     > - Publicly stating that people leaving the IETF is a good thing
>     (there
>     > are many on the community that have left due to feeling
>     discriminated
>     > against, and seeing this does not do any good job at making it
>     better
>     > for underrepresent people). Once you're telling interlocutors
>     you'd be
>     > glad to see them leave, you've stopped trying to persuade anyone
>     and
>     > started performing contempt for an audience.
>     > - Assigning people positions based on the organisations they
>     work or
>     > have worked for
>     > - Demanding that participants recite their credentials before their
>     > views are treated as legitimate
>     > - Mocking people's professional work, CVs, personal websites or
>     > publications
>     > - Characterising a draft, or its authors, as secretly acting on
>     behalf
>     > of a government agency
>     > - Treating someone's nationality or where they are based as
>     relevant to
>     > the merits of their argument
>     > - Using another participant's incivility or blogposts as a
>     licence for
>     > your own
>     > - Framing technical disagreement as proof of incompetence or bad
>     faith
>     >
>     > None of the above bears on rough consensus or technical merit,
>     which,
>     > per RFC 7282, is the only question in front of us. If you need
>     to resort
>     > to the points above to make your point, then you are not really
>     making a
>     > point. I also implore the chairs and ADs to moderate more firmly
>     this
>     > discussion.
>     >
>     > I fully expect this to end with people mocking my work or me
>     across the
>     > various channels, or sending me messages directly. I won't be
>     debating
>     > it with anyone, and I'd gently point out that proving my point
>     for me
>     > isn't the flex some may think it is.
>     >
>     > Thank you,
>
>     -- 
>     Sofía Celi
>     @claucece
>     Cryptographic research and implementation at Brave and University of
>     Bristol. 🏳️‍🌈
>     Reach me out at: [email protected]
>     Website: https://sofiaceli.com/
>
>     _______________________________________________
>     TLS mailing list -- [email protected]
>     To unsubscribe send an email to [email protected]
>
>
> _______________________________________________
> TLS mailing list [email protected]
> To unsubscribe send an email [email protected]

_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]