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 to [email protected]
