[TLS] Re: New Version Notification for draft-sullivan-tls-xo f-ciphers-00.txt
John Mattsson <[email protected]> Tue, 28 Jul 2026 17:01:58 +0000
| Newsgroups | gmane.ietf.tls |
|---|---|
| Message-ID | <AS4PR07MB8825873DF87F9ECCFF7A817A89CB2@AS4PR07MB8825.eurprd07.prod.outlook.com> |
--===============8692956439040342750== Content-Language: en-GB Content-Type: multipart/alternative; boundary="_000_AS4PR07MB8825873DF87F9ECCFF7A817A89CB2AS4PR07MB8825eurp_" --_000_AS4PR07MB8825873DF87F9ECCFF7A817A89CB2AS4PR07MB8825eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I think an Extendable-Output Function (XOF) should be defined as a function= that is indifferentiable from a variable-output random oracle. At the very= least, I think the IETF should only consider XOFs with this property. Unde= r this definition, SHA-2 with an output index counter would not qualify as = a XOF. Cheers, John Preu=DF Mattsson From: Ilari Liusvaara <[email protected]> Date: Tuesday, 28 July 2026 at 17:44 To: [email protected] <[email protected]> Subject: [TLS] Re: New Version Notification for draft-sullivan-tls-xof-ciph= ers-00.txt On Sun, Jul 26, 2026 at 08:55:18PM +0000, John Mattsson wrote: > >One thing I think is important is working out if it is possible to > >eliminate the MACs, as those are extra complexity, and are not > >insignificant load compared to the rest. > > > >That is, TLS 1.3 uses the following construct for Finished: > > > >transcript =3D Transcript-Hash(Handshake Context, Certificate*, Certific= ateVerify*) > >finished_key =3D Derive(BaseKey, "finished", "", Hash.length) > >verify_data =3D MAC(finished_key, transcript) > > > >Is it possible to change that to: > > > >transcript =3D Transcript-Hash(Handshake Context, Certificate*, Certific= ateVerify*) > >verify_data =3D Derive(BaseKey, Finished, transcript, finished_len) > > Removing the MAC algorithm and using the PRF directly seems like an optim= ization worth doing. Thinking about this some more, if this works or not depends on if Derive() is MAC or not. Now, since KMAC is MAC, any reasonable Derive() built from (Turbo)Shake256 is a MAC. However, it is possible to build a XOF that satisfies all the other requirements (input collision resistance and output pseudorandomness), but fails to be a MAC (e.g., SHA-2 with output index counter). And funkily enough, TLS 1.3 Derive-Secret() is a MAC (expand the definition), so this optimization would have worked in base TLS 1.3. OTOH, due to input constraints, any reasonable Derive(), even if not a MAC, is unlikely to admit any practical attack even if directly used as binder. -Ilari _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected] --_000_AS4PR07MB8825873DF87F9ECCFF7A817A89CB2AS4PR07MB8825eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-= 1"> </head> <body> <div style=3D"direction: ltr; font-family: Aptos, Arial, Helvetica, sans-se= rif; font-size: 12pt; color: rgb(0, 0, 0);"> I think an Extendable-Output Function (XOF) should be defined as a function= that is indifferentiable from a variable-output random oracle. At the very= least, I think the IETF should only consider XOFs with this property. Unde= r this definition, SHA-2 with an output index counter would not qualify as a XOF.</div> <div style=3D"direction: ltr; font-family: Aptos, Arial, Helvetica, sans-se= rif; font-size: 12pt; color: rgb(0, 0, 0);"> <span style=3D"text-transform: none;"><br> </span></div> <div style=3D"direction: ltr; font-family: Aptos, Arial, Helvetica, sans-se= rif; font-size: 12pt; color: rgb(0, 0, 0);"> <span style=3D"text-transform: none;">Cheers,</span></div> <div style=3D"direction: ltr; font-family: Aptos, Arial, Helvetica, sans-se= rif; font-size: 12pt; color: rgb(0, 0, 0);"> <span style=3D"text-transform: none;">John Preu=DF Mattsson</span></div> <div style=3D"direction: ltr; font-family: Aptos, Arial, Helvetica, sans-se= rif; font-size: 12pt; color: rgb(0, 0, 0);"> <br> </div> <div id=3D"mail-editor-reference-message-container"> <div class=3D"ms-outlook-mobile-reference-message skipProofing"> <meta name=3D"Generator" content=3D"Microsoft Exchange Server"> </div> <div style=3D"padding: 3pt 0in 0in; border-width: 1pt medium medium; border= -style: solid none none; border-color: rgb(181, 196, 223) currentcolor curr= entcolor;"> <div class=3D"ms-outlook-mobile-reference-message skipProofing" style=3D"te= xt-align: left; font-family: Aptos; font-size: 12pt; color: black;"> <b>From: </b>Ilari Liusvaara <[email protected]><br> <b>Date: </b>Tuesday, 28 July 2026 at 17:44<br> <b>To: </b>[email protected] <[email protected]><br> <b>Subject: </b>[TLS] Re: New Version Notification for draft-sullivan-tls-x= of-ciphers-00.txt<br> <br> </div> </div> <div class=3D"PlainText" style=3D"font-size: 11pt;">On Sun, Jul 26, 2026 at= 08:55:18PM +0000, John Mattsson wrote:<br> > >One thing I think is important is working out if it is possible to= <br> > >eliminate the MACs, as those are extra complexity, and are not<br> > >insignificant load compared to the rest.<br> > ><br> > >That is, TLS 1.3 uses the following construct for Finished:<br> > ><br> > >transcript =3D Transcript-Hash(Handshake Context, Certificate*, Ce= rtificateVerify*)<br> > >finished_key =3D Derive(BaseKey, "finished", ""= ;, Hash.length)<br> > >verify_data =3D MAC(finished_key, transcript)<br> > ><br> > >Is it possible to change that to:<br> > ><br> > >transcript =3D Transcript-Hash(Handshake Context, Certificate*, Ce= rtificateVerify*)<br> > >verify_data =3D Derive(BaseKey, Finished, transcript, finished_len= )<br> ><br> > Removing the MAC algorithm and using the PRF directly seems like an op= timization worth doing.<br> <br> Thinking about this some more, if this works or not depends on if<br> Derive() is MAC or not. Now, since KMAC is MAC, any reasonable Derive()<br> built from (Turbo)Shake256 is a MAC.<br> <br> However, it is possible to build a XOF that satisfies all the other<br> requirements (input collision resistance and output pseudorandomness),<br> but fails to be a MAC (e.g., SHA-2 with output index counter).<br> <br> And funkily enough, TLS 1.3 Derive-Secret() is a MAC (expand the<br> definition), so this optimization would have worked in base TLS 1.3.<br> <br> OTOH, due to input constraints, any reasonable Derive(), even if not a<br> MAC, is unlikely to admit any practical attack even if directly used as<br> binder.<br> <br> <br> <br> <br> -Ilari<br> <br> _______________________________________________<br> TLS mailing list -- [email protected]<br> To unsubscribe send an email to [email protected]<br> </div> </div> </body> </html> --_000_AS4PR07MB8825873DF87F9ECCFF7A817A89CB2AS4PR07MB8825eurp_-- --===============8692956439040342750== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KVExTIG1haWxp bmcgbGlzdCAtLSB0bHNAaWV0Zi5vcmcKVG8gdW5zdWJzY3JpYmUgc2VuZCBhbiBlbWFpbCB0byB0 bHMtbGVhdmVAaWV0Zi5vcmcK --===============8692956439040342750==--