[TLS] Re: Discussion about the Deployment Decision

[Sophie Schmieg <[e-mail]>]

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]