[TLS] Re: Improving the quality of the discussion on the TLS email list
Sophie Schmieg <[email protected]> Thu, 30 Jul 2026 18:59:33 -0700
| Newsgroups | gmane.ietf.tls |
|---|---|
| Message-ID | <CAEEbLAZqYLE3qvSP1ONSVhy4zYYfL679sH7Guz934ORe7H6ygA@mail.gmail.com> |
--===============8220068286337660625== Content-Type: multipart/alternative; boundary="000000000000e029960657de8a52" --000000000000e029960657de8a52 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable It seems that Paul is responding publicly to an email I wrote to him directly, mostly as it tries to explain the situation in terms an economist is more familiar with and does not really fit on this list. Here it is, in full, for the public record, in case any other economists stumble on the TLS mailing list. There is no downgrade attack. That is the whole freaking point of the TLS handshake. To put it in economy terms, we have two parties, the client and the server playing the following sequential game with the client going first and the server going second, with the cryptography having made sure that this is the actual game that they are playing. Basically all the hard part went into making sure that this is the game that is played, but that fact reduces to the security of the hash function and the signature scheme, so it is not in question here and is well established in the literature [1] (I recommend you familiarize yourself with this book if you plan on contributing on the mailing list, this is a discussion between experts that will use shorthands that you'll otherwise be unfamiliar with). Let's use h for hybrid, p for pure and x for connection failed client/server | choose h | choose p | refuse connection advertise h | h | x | x advertise p | x | p | x advertise both | h | p | x refuse conn | x | x | x as you can surely see, there is an obvious strategy for both the client and the server if they value h over x over p to ensure that they will never end up with p, and will end up with h if both assign a value greater than x to it. For most people, we have v(h) > v(x) > v(p) at this point in time (something that everybody violently agrees on), and so the default selected in pretty much all stacks reflects exactly that: Clients advertise h and servers pick h or refuses the connection. The literally *only* thing this standard does is to allow clients and servers that mutually value p over h (which exist, they are the clients and servers owned by the NSA among others) to have the option to choose p, without incurring any externalities to anybody else. The only case where any party sees less utility in this negotiation compared to the scenario where p does not exist is a client that values h over p over x, and a server that values p over h over x, as the outcome here would be p, even though the client would have preferred h. However, when it comes to security concerns, x will always be more valuable than any scheme that a party does not trust to be secure, so this is not really much of a difference. Moreover, remember that the client technically offers a preference list, so it can communicate to the server that it values h over p, and, if the server is mainly indifferent between the two (which the server usually is), the server will be able to honor that preference. As you can see, the individual value assigned to h, p, or x is mostly irrelevant, hence my insistence that any arguing over the exact computational, bandwidth or even security cost of h or p is besides the point. The protocol ensures that each party never has a utility below v(x). Cryptographers usually assume that the honest parties in a protocol share the same goals anyhow, and with that assumption added we see that this protocol maximize utility (Indeed, from a game theoretic standpoint, it is an extremely boring game). The extreme frustration that you can see build up on the mailing list is due to djb attempting to force the conversation to be about the value of h over p, when, in fact, this value does not matter. This is, as far as I can tell, simply a bad faith argument from him, as he has deployed many before to slow down the adoption of ML-KEM. [1] See Dan Boneh, A Graduate Course in Applied Cryptography https://toc.cryptobook.us/book.pdf 21.10 On Thu, Jul 30, 2026 at 6:35=E2=80=AFPM Dennis Jackson <ietf=3D [email protected]> wrote: > Hi Paul, > > In the context of improving the quality of discussion on the TLS mailing > list, I *strongly* encourage you to write more concise emails and > refrain, as much as is possible, from repeating arguments you have alread= y > made in the thread. > > It is enough to say 'I don't understand why my argument given earlier is > wrong', there is no need to repeat the argument nearly verbatim. > > Further responses are inline. > On 30/07/2026 16:30, Paul Romer wrote: > > # Costs and Benefits > > [49 lines snipped] > > What I did claim was that if the discussion in this group focused on > specifics such as these, consensus would emerge naturally, just as it > does in science. > > I would encourage you to familiarize yourself with 'wicked problems' [1] > which are ubiquitous in social planning and policy and do not admit such > easy answers. > > But now we have a puzzle. Why is this suggestion about doing a > cost-benefit analysis perceived as such a threat? > > Whilst I trust your cost-benefit analysis was offered in good faith, it i= s > sorely lacking. In order to support the conclusions you're drawing, you > would need to estimate the value which accrues to the server from > terminating the TLS connection and establish if the additional cost is > negligible with respect to that figure. Instead, you've pulled a number o= ut > of the air to assign a benefit to the client. > > I don't think your line of argument can be seriously engaged with. > > # Why You Keep Referring to Downgrade Attacks > > [16 lines snipped] > > Here we hit the puzzle again. Why is the suggestion that the group > provide information about B and C perceived as a threat? > > Your choice of framing suggests you're received a hostile response to you= r > suggestion, rather than a rather helpful response offered by an expert in > the field you've decided to contribute your perspective to to. > > I would strongly consider familiarizing yourself with the basics of this > field. [2] may be a useful starting point. > > # The TLS Working Group Is in a Hole > > I think I understand why the message I submitted made people who > supported publication of the RFC feel defensive and threatened. I > think everyone understands why. > > Hostility toward something as innocuous as a cost-benefit analysis is > a sign of the damage that was done by the strategy of misdirection and > deception that was used to get the RFC published. > > This kind of hostile framing very much undermines your claim to want to > improve the quality of discussion on this mailing list. It is completely > unwarranted as a response to Sophie's message and the blatant hypocrisy > reflects rather poorly on you. > > Best, > Dennis > > [1] https://en.wikipedia.org/wiki/Wicked_problem > > [2] > https://web.archive.org/web/20170716034728id_/https://eprint.iacr.org/201= 6/072.pdf > _______________________________________________ > TLS mailing list -- [email protected] > To unsubscribe send an email to [email protected] > --=20 Sophie Schmieg | Information Security Engineer | ISE Crypto | [email protected] --000000000000e029960657de8a52 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div>It seems that Paul is responding publicly to an email= I wrote to him directly, mostly as it tries to explain the situation in te= rms an economist is more familiar with and does not really fit on this list= . Here it is, in full, for the public record, in case any other economists = stumble on the TLS mailing list.</div><div><br></div>There is no downgrade = attack. That is the whole freaking point of the TLS handshake. To put it in= economy terms, we have two parties, the client and the server playing the = following sequential game with the client going first and the server going = second, with the cryptography having made sure that this is the actual game= that they are playing. Basically all the hard part went into making sure t= hat this is the game that is played, but that fact reduces to the security = of the hash function and the signature scheme, so it is not in question her= e and is well established in the literature [1] (I recommend you familiariz= e yourself with this book if you plan on contributing on the mailing list, = this is a discussion between experts that will use shorthands that you'= ll otherwise be unfamiliar with).<div><br></div><div>Let's use h for hy= brid, p for pure and x for connection failed</div><div><br></div><div><font= face=3D"monospace">client/server=C2=A0 | choose h | choose p | refuse conn= ection</font></div><div><font face=3D"monospace">advertise h=C2=A0 =C2=A0 |= =C2=A0 =C2=A0 =C2=A0 =C2=A0 h |=C2=A0 =C2=A0 =C2=A0 =C2=A0 x |=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0x</font></div><div><font f= ace=3D"monospace">advertise p=C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 x |= =C2=A0 =C2=A0 =C2=A0 =C2=A0 p |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0x</font></div><div><font face=3D"monospace">advertise b= oth |=C2=A0 =C2=A0 =C2=A0 =C2=A0 h |=C2=A0 =C2=A0 =C2=A0 =C2=A0 p |=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0x</font></div><div><= font face=3D"monospace">refuse conn=C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2= =A0 x |=C2=A0 =C2=A0 =C2=A0 =C2=A0 x |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0x</font></div><div><font face=3D"arial, sans-ser= if"><br></font></div><div><font face=3D"arial, sans-serif">as you can surel= y see, there is an obvious strategy for both the client and the server if t= hey value h over x over p to ensure that they will never end up with p, and= will end up with h if both assign a value greater than x to it. For most p= eople, we have v(h) > v(x) > v(p) at this point in time (something th= at everybody violently agrees on), and so the default selected in pretty mu= ch all stacks reflects exactly that: Clients advertise h and servers pick h= or refuses the connection. The literally=C2=A0<i>only</i>=C2=A0thing this = standard does is to allow clients and servers that mutually=C2=A0value p ov= er h (which exist, they are the clients and servers owned by the NSA among = others) to have the option to choose p, without incurring any externalities= to anybody else.</font></div><div><font face=3D"arial, sans-serif">The onl= y case where any party sees less utility in this negotiation compared to th= e scenario where p does not exist is a client that values h over p over x, = and a server that values p over h over x, as the outcome here would be p, e= ven though the client would have preferred h. However, when it comes to sec= urity concerns, x will always be more valuable than any scheme that a party= does not trust to be secure, so this is not really much of a difference. M= oreover, remember that the client technically offers a preference list, so = it can communicate to the server that it values h over p, and, if the serve= r is mainly indifferent between the two (which the server usually is), the = server will be able to honor that preference.</font></div><div><font face= =3D"arial, sans-serif"><br></font></div><div><font face=3D"arial, sans-seri= f">As you can see, the individual value assigned to h, p, or x is mostly ir= relevant, hence my insistence that any arguing over the exact computational= , bandwidth or even security cost of h or p is besides the point. The proto= col ensures that each party never has a utility below v(x).</font></div><di= v><font face=3D"arial, sans-serif"><br></font></div><div><font face=3D"aria= l, sans-serif">Cryptographers usually assume that the honest parties in a p= rotocol share the same goals anyhow, and with that assumption added we see = that this protocol maximize utility (Indeed, from a game theoretic standpoi= nt, it is an extremely boring game). The extreme frustration that you can s= ee build up on the mailing list is due to djb attempting to force the conve= rsation to be about the value of h over p, when, in fact, this value does n= ot matter. This is, as far as I can tell, simply a bad faith argument from = him, as he has deployed many before to slow down the adoption of ML-KEM.</f= ont></div><div><br></div><div><font face=3D"arial, sans-serif">[1] See Dan = Bon</font>eh, A Graduate Course in Applied Cryptography=C2=A0<a href=3D"htt= ps://toc.cryptobook.us/book.pdf" target=3D"_blank">https://toc.cryptobook.u= s/book.pdf</a>=C2=A0<span style=3D"background-color:transparent">21.10</spa= n></div></div><br><div class=3D"gmail_quote gmail_quote_container"><div dir= =3D"ltr" class=3D"gmail_attr">On Thu, Jul 30, 2026 at 6:35=E2=80=AFPM Denni= s Jackson <ietf=3D<a href=3D"mailto:[email protected]">= [email protected]</a>> wrote:<br></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"><u></u> =20 =20 =20 <div> <p>Hi Paul,=C2=A0</p> <p>In the context of improving the quality of discussion on the TLS mailing list, I=C2=A0<b>strongly</b> encourage you to write more concise emails and refrain, as much as is possible, from repeating arguments you have already made in the thread.=C2=A0</p> <p>It is enough to say 'I don't understand why my argument give= n earlier is wrong', there is no need to repeat the argument nearly verbatim.=C2=A0</p> <p>Further responses are inline.=C2=A0</p> <div>On 30/07/2026 16:30, Paul Romer wrote:<br> </div> <blockquote type=3D"cite"> <pre># Costs and Benefits [49 lines snipped]=20 What I did claim was that if the discussion in this group focused on specifics such as these, consensus would emerge naturally, just as it does in science.</pre> </blockquote> <p>I would encourage you to familiarize yourself with 'wicked problems' [1] which are ubiquitous in social planning and policy and do not admit such easy answers.=C2=A0</p> <blockquote type=3D"cite"> <pre>But now we have a puzzle. Why is this suggestion about doing a cost-benefit analysis perceived as such a threat? </pre> </blockquote> <p>Whilst I trust your cost-benefit analysis was offered in good faith, it is sorely lacking. In order to support the conclusions you're drawing, you would need to estimate the value which accrue= s to the server from terminating the TLS connection and establish if the additional cost is negligible with respect to that figure. Instead, you've pulled a number out of the air to assign a benefi= t to the client.</p> <p>I don't think your line of argument can be seriously engaged with.=C2=A0</p> <blockquote type=3D"cite"> <pre># Why You Keep Referring to Downgrade Attacks [16 lines snipped]=20 Here we hit the puzzle again. Why is the suggestion that the group provide information about B and C perceived as a threat?</pre> </blockquote> <p>Your choice of framing suggests you're received a hostile response to your suggestion, rather than a rather helpful response offered by an expert in the field you've decided to contribute your perspective to to.=C2=A0</p> <p>I would strongly consider familiarizing yourself with the basics of this field. [2] may be a useful starting point.=C2=A0</p> <blockquote type=3D"cite"> <pre># The TLS Working Group Is in a Hole I think I understand why the message I submitted made people who supported publication of the RFC feel defensive and threatened. I think everyone understands why. Hostility toward something as innocuous as a cost-benefit analysis is a sign of the damage that was done by the strategy of misdirection and deception that was used to get the RFC published. </pre> </blockquote> <p>This kind of hostile framing very much undermines your claim to want to improve the quality of discussion on this mailing list. It is completely unwarranted as a response to Sophie's message and the blatant hypocrisy reflects rather poorly on you.=C2=A0</p> <p>Best,<br> Dennis</p> <p>[1] <a href=3D"https://en.wikipedia.org/wiki/Wicked_problem" target= =3D"_blank">https://en.wikipedia.org/wiki/Wicked_problem</a></p> <p>[2] <a href=3D"https://web.archive.org/web/20170716034728id_/https://eprint.iac= r.org/2016/072.pdf" target=3D"_blank">https://web.archive.org/web/201707160= 34728id_/https://eprint.iacr.org/2016/072.pdf</a></p> </div> _______________________________________________<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> --000000000000e029960657de8a52-- --===============8220068286337660625== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KVExTIG1haWxp bmcgbGlzdCAtLSB0bHNAaWV0Zi5vcmcKVG8gdW5zdWJzY3JpYmUgc2VuZCBhbiBlbWFpbCB0byB0 bHMtbGVhdmVAaWV0Zi5vcmcK --===============8220068286337660625==--