[TLS] Discussion about the Deployment Decision

[Paul Romer <[e-mail]>]

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.