[TLS] Re: Discussion about the Deployment Decision

[Paul Romer <[e-mail]>]

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.

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]
>