[TLS] Re: Discussion about the Deployment Decision

[Paul Romer <[e-mail]>]

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.