[TLS] Re: Discussion about the Deployment Decision
Bas Westerbaan <[email protected]> Mon, 3 Aug 2026 16:44:57 +0200
| Newsgroups | gmane.ietf.tls |
|---|---|
| Message-ID | <CAMjbhoUeGzikXOKZoD_=F0XSLkJdpEHL8UK=e99GY5FKUuNLiA@mail.gmail.com> |
--===============7906285613629020341== Content-Type: multipart/alternative; boundary="000000000000afc3590658259534" --000000000000afc3590658259534 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Aug 3, 2026 at 1:02=E2=80=AFPM Paul Romer <romerp=3D40bc.edu@dmarc.= ietf.org> wrote: > 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 meani= ng > > 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 =3D> A > > and > > - B is true because =C2=ACP =3D> B > > where > > P =3D "The recommended flag conveys information" > =C2=ACP =3D "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. > Calling out a Nobel laureate indeed requires some nerve. I think it's pretty obvious that two seemingly contradictory statements can make total sense when considered in context. > > On Fri, Jul 31, 2026 at 1:42=E2=80=AFPM Sophie Schmieg > <[email protected]> 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 nicel= y > to convey expected utility. > > > > On Fri, Jul 31, 2026 at 10:24=E2=80=AFAM Paul Romer <romerp=3D > [email protected]> 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]> wr= ote: > >> > > >> > 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 hi= s > >> > message shows why a focused response about a specific issue can be s= o > >> > 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 ref= er > >> > 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 th= at > >> > 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 com= e > >> > up with an estimate of the cost of the reduction in security provide= d > >> > by MLKEM768 instead of X25519MLKEM768. In light of the news about th= e > >> > 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 implic= it > >> > decision rule "make the change if B > C", a better rule would be mak= e > >> > 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 successf= ul > >> > 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 focu= s > >> > first on an analysis of the effects of a change in the probability o= f > >> > 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 change= s > >> > in p. > >> > > >> > I think it might not be helpful for me to contribute an analysis alo= ng > >> > 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] > > > > > > > > -- > > > > Sophie Schmieg | Information Security Engineer | ISE Crypto | > [email protected] > > > > _______________________________________________ > TLS mailing list -- [email protected] > To unsubscribe send an email to [email protected] > --000000000000afc3590658259534 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote g= mail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, Aug 3, = 2026 at 1:02=E2=80=AFPM Paul Romer <romerp=3D<a href=3D"mailto:40bc.edu@= dmarc.ietf.org">[email protected]</a>> wrote:<br></div><blockquote= class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px so= lid rgb(204,204,204);padding-left:1ex">Sophie, you wrote:<br> > A recommendation flag should do nicely to convey expected utility.<br> <br> You also wrote:<br> > Well, technically my opinion is that X25519MLKEM768 should be recommen= ded,<br> > but I also think that neither this flag nor the MTI flag have any mean= ing<br> > in the first place<br> <br> <a href=3D"https://mailarchive.ietf.org/arch/msg/tls/anqTfO9uoZXfHTOeiV1wZO= m1GVo/" rel=3D"noreferrer" target=3D"_blank">https://mailarchive.ietf.org/a= rch/msg/tls/anqTfO9uoZXfHTOeiV1wZOm1GVo/</a><br> <br> Are you trolling me?<br> <br> I don't see how this group will be able to establish a consensus about<= br> anything if everyone just looks at their shoes when you claim that<br> <br> - A is true because P =3D> A<br> <br> and<br> <br> - B is true because =C2=ACP =3D> B<br> <br> where<br> <br> P=C2=A0 =3D "The recommended flag conveys information"<br> =C2=ACP =3D "The recommended flag has no meaning"<br> <br> <br> Look, anyone can make a mistake. It's no big deal as long as the rest<b= r> of the group does it's job:<br> <br> - flag any logical inconsistencies and any misleading or incorrect<br> statements of fact;<br> <br> - push for logical coherence and alignment with the evidence.<br> <br> The deep problem is the missing messages. People seem to be afraid to<br> speak up about the mistakes.<br></blockquote><div><br></div><div>Calling ou= t a Nobel laureate indeed requires some nerve. I think it's pretty obvi= ous that two seemingly contradictory statements can make total sense when c= onsidered in context.</div><div><br></div><div>=C2=A0</div><blockquote clas= s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid r= gb(204,204,204);padding-left:1ex"> <br> On Fri, Jul 31, 2026 at 1:42=E2=80=AFPM Sophie Schmieg<br> <sschmieg=3D<a href=3D"mailto:[email protected]" target=3D"_bl= ank">[email protected]</a>> wrote:<br> ><br> > I think it's overall probably prudent to not assume implementers h= ave a degree or even interest in economy. A recommendation flag should do n= icely to convey expected utility.<br> ><br> > On Fri, Jul 31, 2026 at 10:24=E2=80=AFAM Paul Romer <romerp=3D<a hr= ef=3D"mailto:[email protected]" target=3D"_blank">[email protected]= .org</a>> wrote:<br> >><br> >> log( ) is concave. I should have written "concave utility fun= ction"<br> >> instead of "convex utility function." I tripped over the= change of<br> >> sign associated with the use of a utility function instead of a lo= ss<br> >> function.<br> >><br> >> On Fri, Jul 31, 2026 at 12:53=E2=80=AFPM Paul Romer <<a href=3D= "mailto:[email protected]" target=3D"_blank">[email protected]</a>> wrote:<br> >> ><br> >> > The response to my message with the subject "Improving t= he Quality<br> >> > ..." has split into two different discussions:<br> >> ><br> >> > 1. One addresses the decision to deploy MLKEM768 instead of X= 25519MLKEM768.<br> >> ><br> >> > 2. The second is concerned with the tally of support for publ= ishing the RFC<br> >> ><br> >> > I'm starting a new thread here that can focus on discussi= on 1 to<br> >> > highlight some positive contributions to that discussion.<br> >> ><br> >> ><br> >> > - Mark pointed out that I made a mistake by referring to a &q= uot;Feynman<br> >> > estimate". I should have said a "Fermi estimate.&qu= ot; He is right and his<br> >> > message shows why a focused response about a specific issue c= an 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 w= ith a<br> >> > series of small steps like this one that focus on narrow spec= ifics.<br> >> ><br> >> > <a href=3D"https://mailarchive.ietf.org/arch/msg/tls/qAPFBiBw= PPXj0nST62FfJ3PsDCU/" rel=3D"noreferrer" target=3D"_blank">https://mailarch= ive.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 cor= rect on<br> >> > both counts and I will try not to make this mistake again.<br= > >> ><br> >> > <a href=3D"https://mailarchive.ietf.org/arch/msg/tls/vw685VPl= 4aXLWmqgOfdEzyWyADw/" rel=3D"noreferrer" target=3D"_blank">https://mailarch= ive.ietf.org/arch/msg/tls/vw685VPl4aXLWmqgOfdEzyWyADw/</a><br> >> ><br> >> ><br> >> > - Dennis also pointed to an alternative way to estimate the b= enefit of<br> >> > deploying MLKEM768. What would be helpful would be some rough= <br> >> > calculations that show how the extension he has in mind affec= ts 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 a= bout the<br> >> > Anthropic attack on HAWK, an interesting way to examine the c= osts of<br> >> > changes in security would be to allow for a convex utility fu= nction<br> >> > that captures the idea of risk aversion. Instead of using the= implicit<br> >> > decision rule "make the change if B > C", a bett= er rule would 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 fun= ction. 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 e= xtreme<br> >> > simplification. One might start by continuing to treat B as<b= r> >> > deterministic and allowing for just two states of the world w= ith<br> >> > different costs C_1 and C_2. With probability p there is no s= uccessful<br> >> > attack on MLKEM768 and the ex post cost of deploying it is C_= 1. With<br> >> > probability (1-p) there is a successful attack and the ex pos= t cost is<br> >> > C_2 > C_1.<br> >> ><br> >> > This does not address an issue that Donald Bernstein has emph= asized,<br> >> > that there is also a risk of implementation errors in softwar= e that<br> >> > supports MLKEM768. That could be added into a subsequent anal= ysis.<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 probab= ility of<br> >> > a successful attack on the protocol.<br> >> ><br> >> > In the simple framework that I suggest, one can do a sensitiv= ity<br> >> > analysis that varies the estimates of C_1 and C_2, but the mo= re<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 analy= sis 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 decis= ion to<br> >> > deploy MLKEM768 look worse. A neutral observer might worry th= at any<br> >> > analysis I do is biased by motivated reasoning. It might be h= elpful<br> >> > for someone else to give this a try.<br> >><br> >> _______________________________________________<br> >> TLS mailing list -- <a href=3D"mailto:[email protected]" target=3D"_bla= nk">[email protected]</a><br> >> To unsubscribe send an email to <a href=3D"mailto:[email protected]= rg" target=3D"_blank">[email protected]</a><br> ><br> ><br> ><br> > --<br> ><br> > Sophie Schmieg | Information Security Engineer | ISE Crypto | <a href= =3D"mailto:[email protected]" target=3D"_blank">[email protected]</a><b= r> ><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> --000000000000afc3590658259534-- --===============7906285613629020341== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KVExTIG1haWxp bmcgbGlzdCAtLSB0bHNAaWV0Zi5vcmcKVG8gdW5zdWJzY3JpYmUgc2VuZCBhbiBlbWFpbCB0byB0 bHMtbGVhdmVAaWV0Zi5vcmcK --===============7906285613629020341==--