[TLS] Re: MLKEM Consensus Call (was WG Last Call: draft- ietf-tls-mlkem-08 (Ends 2026-07-08))

Nathanael Ritz <[email protected]> Sun, 19 Jul 2026 17:57:59 -0600
Newsgroups gmane.ietf.tls
Message-ID <CAHxYnaOLxx_1PTVM9oMC27SbNM1ao1sFuuU6KDySaJpHjYU8TQ@mail.gmail.com>
Hello,

On Sun, Jul 19, 2026 at 4:56 PM Erwin Hoffmann <[email protected]> wrote:
>
> Dear Fabiana,
>
> Am Sonntag, dem 19.07.2026 um 13:55 +0000 schrieb DA PIEVE Fabiana:
> > Can I kindly ask if there is evidence that can be provided for your
> > statements about the numbers, and more info on the weights / method
> > you apply to weigh answers, from both sides ?
> >
> > I imagine you have a table/a scheme/something, with participants, an
> > established method for the weights, weights associated to each person
> > on both sides, other elements you may have considered relevant ....
>
> I hope, this list (if existing) keeps disclosed. Even if Joe (having my
> deepest respect for moderating this list and advancing the discussion
> to an end) provides such a list, it probably will fail to correctly
> attribute the different oppinions to put into the forseen jars.
> For instance, my analysis can be found here [1], check item 6; but in
> particular this does not tell, that I am an opponent of the original
> draft.
>
> At the bottom line: It is irrelevant.

I don’t have much novel to offer here of my own. However, I wanted to share
a presentation I recently watched about how rough consensus works where
Pete Resnick (who published RFC7282) says at one point (and I paraphrase),
that “the IETF counts issues, not noses.” [0].

I think the entire RFC is worth reading, but Section 6 and Section 7 offer
an interesting juxtaposition:

    “6. One hundred people for and five people against might not be rough
consensus” [1]
    [...]
    "7.  Five people for and one hundred people against might still be
rough consensus" [2]

Cheers,
Nathanael

[0] (around the 26 minute mark)
https://icann.zoom.us/rec/play/0r5AsvGWq6qAZ04TVZhUi_fNK3uLSfDxfYoQqX0IyVCXzfK2Z6wiWklDZW7nWSu94N3MoWJXBEbjkUwJ.Srtsf5NDGkGDO41i?eagerLoadZvaPages=sidemenu.billing.plan_management&accessLevel=meeting&canPlayFromShare=true&from=share_recording_detail&startTime=1773054013000&componentName=rec-play&originRequestUrl=https%3A%2F%2Ficann.zoom.us%2Frec%2Fshare%2F89927reyILuByB7Qto6LKE4LNIvRL1fGaV8qsWE1HQnKMtoXQFMsF6sDpmdfp0cG.FtubGwXJ0h5DOetq%3FstartTime%3D1773054013000

[1] https://www.rfc-editor.org/info/rfc7282/#section-6

[2] https://www.rfc-editor.org/info/rfc7282/#section-7

On Sun, 19 Jul 2026 at 16:56, Erwin Hoffmann <[email protected]> wrote:

> Dear Fabiana,
>
> Am Sonntag, dem 19.07.2026 um 13:55 +0000 schrieb DA PIEVE Fabiana:
> > Can I kindly ask if there is evidence that can be provided for your
> > statements about the numbers, and more info on the weights / method
> > you apply to weigh answers, from both sides ?
> >
> > I imagine you have a table/a scheme/something, with participants, an
> > established method for the weights, weights associated to each person
> > on both sides, other elements you may have considered relevant ....
>
> I hope, this list (if existing) keeps disclosed. Even if Joe (having my
> deepest respect for moderating this list and advancing the discussion
> to an end) provides such a list, it probably will fail to correctly
> attribute the different oppinions to put into the forseen jars.
> For instance, my analysis can be found here [1], check item 6; but in
> particular this does not tell, that I am an opponent of the original
> draft.
>
> At the bottom line: It is irrelevant.
>
> While working with TLS (for my users, including public organizations
> and federal states here in Germany which depended on my SW) over the
> last > 25 years, for me it is important to provide the highest
> achievable level of security/confidentiality for those.
>
> Given the proposed solution with the addendum of Joe, I like to comment
> the following:
>
> * The risk mitigation taken (given the PRNG) relies on paper-work only.
> * The risk mitigation does not necessarily require an implementation
> (though possible, cheap, and easy).
>
> Since I'm known for my bad analogies (limping), I would like to add
> another one [2]. A lot of people here have my age and are veterans of
> the Internet (Eric, Rich, and many other from whom I profited quite a
> lot in my SW - thanks to those; and including Deb - for her I apologize
> any unqualified assertations) and will share those memories. This was
> the trigger of my following mail [3] because the NASA left no choices
> for the astronaut crew; though possible with low chances. The result is
> known.
>
> Engineers will not only talk about problems, but rather solve those for
> critical missions. And this has nothing to do in what camp you are.
>
> Regards.
> --eh.
>
> PS: I can live with the draft version of Joe, but this is the second-
> best solution.
>
> PPS: I will shut my mouth now and go back to work (Joe).
>
>
> [1]
> https://mailarchive.ietf.org/arch/msg/tls/Q-ZAH0cyd6vM1iG0QreHDtan0dg/
> [2]
>
> https://nicholastoole.wordpress.ncsu.edu/disaster-archive-case-study/columbia-space-shuttle-disaster-and-powerpoint/
> [3]
> https://mailarchive.ietf.org/arch/msg/tls/w3QCc4vdUV8E1BUNum5hm1EBc8w/
>
> --
> Dr. Erwin Hoffmann | www.fehcom.de
> PGP key-id: 36553F7F9C58D1CC
> PGP key-fingerprint:  950B 5555 0B08 5A2A 1C00 9594 3655 3F7F 9C58 D1CC
> _______________________________________________
> 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]