[TLS] Re: Discussion about the Deployment Decision
Sophie Schmieg <[email protected]> Fri, 31 Jul 2026 10:42:43 -0700
| Newsgroups | gmane.ietf.tls |
|---|---|
| Message-ID | <CAEEbLAb4bExRixbxUy=ewLh9yKXc-v9uddtkS6i_D2c16v+Uzw@mail.gmail.com> |
--===============2152953438815229177== Content-Type: multipart/alternative; boundary="000000000000eeb8040657ebb7da" --000000000000eeb8040657ebb7da Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=E2=80=AFAM Paul Romer <romerp=3D40bc.edu@dmar= c.ietf.org> 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=E2=80=AFPM Paul Romer <[email protected]> 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) =3D 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 -- [email protected] > To unsubscribe send an email to [email protected] > --=20 Sophie Schmieg | Information Security Engineer | ISE Crypto | [email protected] --000000000000eeb8040657ebb7da Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">I think it's overall probably prudent to not assume im= plementers have a degree or even interest in economy. A recommendation flag= should do nicely to convey expected utility.</div><br><div class=3D"gmail_= quote gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, = Jul 31, 2026 at 10:24=E2=80=AFAM Paul Romer <romerp=3D<a href=3D"mailto:= [email protected]">[email protected]</a>> wrote:<br></div><b= lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le= ft:1px solid rgb(204,204,204);padding-left:1ex">log( ) is concave. I should= have written "concave utility function"<br> instead of "convex utility function." I tripped over the change o= f<br> sign associated with the use of a utility function instead of a loss<br> function.<br> <br> On Fri, Jul 31, 2026 at 12:53=E2=80=AFPM Paul Romer <<a href=3D"mailto:r= [email protected]" target=3D"_blank">[email protected]</a>> wrote:<br> ><br> > The response to my message with the subject "Improving the Qualit= y<br> > ..." has split into two different discussions:<br> ><br> > 1. One addresses the decision to deploy MLKEM768 instead of X25519MLKE= M768.<br> ><br> > 2. The second is concerned with the tally of support for publishing th= e RFC<br> ><br> > I'm starting a new thread here that can focus on discussion 1 to<b= r> > highlight some positive contributions to that discussion.<br> ><br> ><br> > - Mark pointed out that I made a mistake by referring to a "Feynm= an<br> > estimate". I should have said a "Fermi estimate." He is= right and his<br> > message shows why a focused response about a specific issue can be so<= br> > useful in discussions like this. I made a mistake. If no one had<br> > corrected it, it could have encouraged others to repeat that mistake.<= br> > Mark corrected the mistake. We now have a consensus about how to refer= <br> > to this type of estimation. It is easier to build consensus with a<br> > series of small steps like this one that focus on narrow specifics.<br= > ><br> > <a href=3D"https://mailarchive.ietf.org/arch/msg/tls/qAPFBiBwPPXj0nST6= 2FfJ3PsDCU/" rel=3D"noreferrer" target=3D"_blank">https://mailarchive.ietf.= org/arch/msg/tls/qAPFBiBwPPXj0nST62FfJ3PsDCU/</a><br> ><br> ><br> > - Dennis said that I repeated arguments from my original post and that= <br> > it is important to avoid repetition. On reflection, he is correct on<b= r> > both counts and I will try not to make this mistake again.<br> ><br> > <a href=3D"https://mailarchive.ietf.org/arch/msg/tls/vw685VPl4aXLWmqgO= fdEzyWyADw/" rel=3D"noreferrer" target=3D"_blank">https://mailarchive.ietf.= org/arch/msg/tls/vw685VPl4aXLWmqgOfdEzyWyADw/</a><br> ><br> ><br> > - Dennis also pointed to an alternative way to estimate the benefit of= <br> > deploying MLKEM768. What would be helpful would be some rough<br> > calculations that show how the extension he has in mind affects the<br= > > comparison of costs and benefits.<br> ><br> ><br> > - Dennis objected to the admittedly ad hoc method that I used to come<= br> > up with an estimate of the cost of the reduction in security provided<= br> > by MLKEM768 instead of X25519MLKEM768. In light of the news about the<= br> > Anthropic attack on HAWK, an interesting way to examine the costs of<b= r> > changes in security would be to allow for a convex utility function<br= > > that captures the idea of risk aversion. Instead of using the implicit= <br> > decision rule "make the change if B > C", a better rule w= ould be make<br> > the change if<br> ><br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 E(U(B-C)) > 0,<br> ><br> > where E is the expectations operator and U is the utility function. A<= br> > natural initial choice is logarithmic utility U(y) =3D ln(y).<br> ><br> > For this type of estimation, you have to have a stomach for extreme<br= > > simplification. One might start by continuing to treat B as<br> > deterministic and allowing for just two states of the world with<br> > different costs C_1 and C_2. With probability p there is no successful= <br> > attack on MLKEM768 and the ex post cost of deploying it is C_1. With<b= r> > probability (1-p) there is a successful attack and the ex post cost is= <br> > C_2 > C_1.<br> ><br> > This does not address an issue that Donald Bernstein has emphasized,<b= r> > that there is also a risk of implementation errors in software that<br= > > supports MLKEM768. That could be added into a subsequent analysis.<br> > Given the news about the attack on Hawk, it seems reasonable to focus<= br> > first on an analysis of the effects of a change in the probability of<= br> > a successful attack on the protocol.<br> ><br> > In the simple framework that I suggest, one can do a sensitivity<br> > analysis that varies the estimates of C_1 and C_2, but the more<br> > interesting analysis would fix those values and explore small changes<= br> > in p.<br> ><br> > I think it might not be helpful for me to contribute an analysis along= <br> > these lines. It is obvious that I think it would be a mistake to<br> > deploy MLKEM768. Allowing for risk aversion will make a decision to<br= > > deploy MLKEM768 look worse. A neutral observer might worry that any<br= > > analysis I do is biased by motivated reasoning. It might be helpful<br= > > for someone else to give this a try.<br> <br> _______________________________________________<br> TLS mailing list -- <a href=3D"mailto:[email protected]" target=3D"_blank">tls@i= etf.org</a><br> To unsubscribe send an email to <a href=3D"mailto:[email protected]" targe= t=3D"_blank">[email protected]</a><br> </blockquote></div><div><br clear=3D"all"></div><div><br></div><span class= =3D"gmail_signature_prefix">-- </span><br><div dir=3D"ltr" class=3D"gmail_s= ignature"><div dir=3D"ltr"><div><div dir=3D"ltr"><div><div dir=3D"ltr"><div= ><div dir=3D"ltr"><div><div dir=3D"ltr"><div style=3D"line-height:1.5em;pad= ding-top:10px;margin-top:10px;color:rgb(85,85,85);font-family:sans-serif;fo= nt-size:small"><span style=3D"border-width:2px 0px 0px;border-style:solid;b= order-color:rgb(213,15,37);padding-top:2px;margin-top:2px"><br>Sophie Schmi= eg=C2=A0|</span><span style=3D"border-width:2px 0px 0px;border-style:solid;= border-color:rgb(51,105,232);padding-top:2px;margin-top:2px">=C2=A0Informat= ion Security Engineer=C2=A0|</span><span style=3D"border-width:2px 0px 0px;= border-style:solid;border-color:rgb(0,153,57);padding-top:2px;margin-top:2p= x">=C2=A0ISE Crypto=C2=A0|</span><span style=3D"border-width:2px 0px 0px;bo= rder-style:solid;border-color:rgb(238,178,17);padding-top:2px;margin-top:2p= x">=C2=A0<a href=3D"mailto:[email protected]" target=3D"_blank">sschmieg@= google.com</a></span></div><div><span style=3D"border-width:2px 0px 0px;bor= der-style:solid;border-color:rgb(238,178,17);padding-top:2px;margin-top:2px= "><br></span></div><span style=3D"color:rgb(0,0,0);font-family:"Times = New Roman";font-size:medium"></span></div></div></div></div></div></di= v></div></div></div></div> --000000000000eeb8040657ebb7da-- --===============2152953438815229177== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KVExTIG1haWxp bmcgbGlzdCAtLSB0bHNAaWV0Zi5vcmcKVG8gdW5zdWJzY3JpYmUgc2VuZCBhbiBlbWFpbCB0byB0 bHMtbGVhdmVAaWV0Zi5vcmcK --===============2152953438815229177==--