[TLS] Re: Discussion about the Deployment Decision

[Bas Westerbaan <[e-mail]>]

On Mon, Aug 3, 2026 at 1:02 PM Paul Romer <romerp=[e-mail]>
wrote:

> Sophie, you wrote:
> > A recommendation flag should do nicely to convey expected utility.
>
> You also wrote:
> > Well, technically my opinion is that X25519MLKEM768 should be
> recommended,
> > but I also think that neither this flag nor the MTI flag have any meaning
> > in the first place
>
> https://mailarchive.ietf.org/arch/msg/tls/anqTfO9uoZXfHTOeiV1wZOm1GVo/
>
> Are you trolling me?
>
> I don't see how this group will be able to establish a consensus about
> anything if everyone just looks at their shoes when you claim that
>
> - A is true because P => A
>
> and
>
> - B is true because ¬P => B
>
> where
>
> P  = "The recommended flag conveys information"
> ¬P = "The recommended flag has no meaning"
>
>
> Look, anyone can make a mistake. It's no big deal as long as the rest
> of the group does it's job:
>
> - flag any logical inconsistencies and any misleading or incorrect
> statements of fact;
>
> - push for logical coherence and alignment with the evidence.
>
> The deep problem is the missing messages. People seem to be afraid to
> speak up about the mistakes.
>

Calling out a Nobel laureate indeed requires some nerve. I think it's
pretty obvious that two seemingly contradictory statements can make total
sense when considered in context.



>
> On Fri, Jul 31, 2026 at 1:42 PM Sophie Schmieg
> <sschmieg=[e-mail]> wrote:
> >
> > I think it's overall probably prudent to not assume implementers have a
> degree or even interest in economy. A recommendation flag should do nicely
> to convey expected utility.
> >
> > On Fri, Jul 31, 2026 at 10:24 AM Paul Romer <romerp=
> [e-mail]> wrote:
> >>
> >> log( ) is concave. I should have written "concave utility function"
> >> instead of "convex utility function." I tripped over the change of
> >> sign associated with the use of a utility function instead of a loss
> >> function.
> >>
> >> On Fri, Jul 31, 2026 at 12:53 PM Paul Romer <[e-mail]> wrote:
> >> >
> >> > The response to my message with the subject "Improving the Quality
> >> > ..." has split into two different discussions:
> >> >
> >> > 1. One addresses the decision to deploy MLKEM768 instead of
> X25519MLKEM768.
> >> >
> >> > 2. The second is concerned with the tally of support for publishing
> the RFC
> >> >
> >> > I'm starting a new thread here that can focus on discussion 1 to
> >> > highlight some positive contributions to that discussion.
> >> >
> >> >
> >> > - Mark pointed out that I made a mistake by referring to a "Feynman
> >> > estimate". I should have said a "Fermi estimate." He is right and his
> >> > message shows why a focused response about a specific issue can be so
> >> > useful in discussions like this. I made a mistake. If no one had
> >> > corrected it, it could have encouraged others to repeat that mistake.
> >> > Mark corrected the mistake. We now have a consensus about how to refer
> >> > to this type of estimation. It is easier to build consensus with a
> >> > series of small steps like this one that focus on narrow specifics.
> >> >
> >> >
> https://mailarchive.ietf.org/arch/msg/tls/qAPFBiBwPPXj0nST62FfJ3PsDCU/
> >> >
> >> >
> >> > - Dennis said that I repeated arguments from my original post and that
> >> > it is important to avoid repetition. On reflection, he is correct on
> >> > both counts and I will try not to make this mistake again.
> >> >
> >> >
> https://mailarchive.ietf.org/arch/msg/tls/vw685VPl4aXLWmqgOfdEzyWyADw/
> >> >
> >> >
> >> > - Dennis also pointed to an alternative way to estimate the benefit of
> >> > deploying MLKEM768. What would be helpful would be some rough
> >> > calculations that show how the extension he has in mind affects the
> >> > comparison of costs and benefits.
> >> >
> >> >
> >> > - Dennis objected to the admittedly ad hoc method that I used to come
> >> > up with an estimate of the cost of the reduction in security provided
> >> > by MLKEM768 instead of X25519MLKEM768. In light of the news about the
> >> > Anthropic attack on HAWK, an interesting way to examine the costs of
> >> > changes in security would be to allow for a convex utility function
> >> > that captures the idea of risk aversion. Instead of using the implicit
> >> > decision rule "make the change if B > C", a better rule would be make
> >> > the change if
> >> >
> >> >          E(U(B-C)) > 0,
> >> >
> >> > where E is the expectations operator and U is the utility function. A
> >> > natural initial choice is logarithmic utility U(y) = ln(y).
> >> >
> >> > For this type of estimation, you have to have a stomach for extreme
> >> > simplification. One might start by continuing to treat B as
> >> > deterministic and allowing for just two states of the world with
> >> > different costs C_1 and C_2. With probability p there is no successful
> >> > attack on MLKEM768 and the ex post cost of deploying it is C_1. With
> >> > probability (1-p) there is a successful attack and the ex post cost is
> >> > C_2 > C_1.
> >> >
> >> > This does not address an issue that Donald Bernstein has emphasized,
> >> > that there is also a risk of implementation errors in software that
> >> > supports MLKEM768. That could be added into a subsequent analysis.
> >> > Given the news about the attack on Hawk, it seems reasonable to focus
> >> > first on an analysis of the effects of a change in the probability of
> >> > a successful attack on the protocol.
> >> >
> >> > In the simple framework that I suggest, one can do a sensitivity
> >> > analysis that varies the estimates of C_1 and C_2, but the more
> >> > interesting analysis would fix those values and explore small changes
> >> > in p.
> >> >
> >> > I think it might not be helpful for me to contribute an analysis along
> >> > these lines. It is obvious that I think it would be a mistake to
> >> > deploy MLKEM768. Allowing for risk aversion will make a decision to
> >> > deploy MLKEM768 look worse. A neutral observer might worry that any
> >> > analysis I do is biased by motivated reasoning. It might be helpful
> >> > for someone else to give this a try.
> >>
> >> _______________________________________________
> >> TLS mailing list -- [e-mail]
> >> To unsubscribe send an email to [e-mail]
> >
> >
> >
> > --
> >
> > Sophie Schmieg | Information Security Engineer | ISE Crypto |
> [e-mail]
> >
>
> _______________________________________________
> TLS mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>