[TLS] Re: New Version Notification for draft-sullivan-tls-xo f-ciphers-00.txt
John Mattsson <[email protected]> Sun, 26 Jul 2026 20:55:18 +0000
| Newsgroups | gmane.ietf.tls |
|---|---|
| Message-ID | <AS4PR07MB8825774B95A2135226B3325F89CD2@AS4PR07MB8825.eurprd07.prod.outlook.com> |
--===============4014014360788331123== Content-Language: en-GB Content-Type: multipart/alternative; boundary="_000_AS4PR07MB8825774B95A2135226B3325F89CD2AS4PR07MB8825eurp_" --_000_AS4PR07MB8825774B95A2135226B3325F89CD2AS4PR07MB8825eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >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*, Certificat= eVerify*) >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*, Certificat= eVerify*) >verify_data =3D Derive(BaseKey, Finished, transcript, finished_len) Removing the MAC algorithm and using the PRF directly seems like an optimiz= ation worth doing. Cheers, John Preu=DF Mattsson From: Ilari Liusvaara <[email protected]> Date: Sunday, 26 July 2026 at 17:48 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 12:03:45PM +0200, Nadim Kobeissi wrote: > > This draft looks interesting, so I would like to volunteer to maintain > some ProVerif models that track its development and run formal > analysis that tracks security properties across implementations that > use your XOF draft and those that are using current TLS 1.3, running > in parallel. > > I've pushed an initial ProVerif model for the draft [2]. This model > layers the deck schedule over our existing RFC 8446bis models as a > separate library, so the published models stay byte-identical and > sessions of both schedules run side by side under one attacker, > across all three key-exchange modes (classical (EC)DHE, standalone > ML-KEM, and the hybrid). 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*, Certificate= Verify*) 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*, Certificate= Verify*) verify_data =3D Derive(BaseKey, Finished, transcript, finished_len) ? (The PSK binder construction is similar.) > The modeling follows the draft's own abstractions closely: section > 7.1.2's one-shot equivalence, since every derived value becomes a > single deck-function application over its injectively framed path. > The governing cipher suite is bound at each leaf, hybrid component > secrets are absorbed as separate "dh" items in group order rather > than concatenated, the MAC is a distinct keyed function, and the > transcript hash comes from the same XOF as the schedule. One thing to be careful of is that cryptographic sponge assumption is very powerful (easily enough to prove the above transform). What happens if it breaks down (partially, so everything does not sink)? -Ilari _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected] --_000_AS4PR07MB8825774B95A2135226B3325F89CD2AS4PR07MB8825eurp_ 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: 11pt; color: rgb(0, 0, 0);"> >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.</div> <div style=3D"direction: ltr; font-family: Aptos, Arial, Helvetica, sans-se= rif; font-size: 11pt; color: rgb(0, 0, 0);"> ></div> <div style=3D"direction: ltr; font-family: Aptos, Arial, Helvetica, sans-se= rif; font-size: 11pt; color: rgb(0, 0, 0);"> >That is, TLS 1.3 uses the following construct for Finished:<br> ><br> >transcript =3D Transcript-Hash(Handshake Context, Certificate*, Certifi= cateVerify*)<br> >finished_key =3D Derive(BaseKey, "finished", "", Ha= sh.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*, Certifi= cateVerify*)<br> >verify_data =3D Derive(BaseKey, Finished, transcript, finished_len)<br> </div> <div style=3D"direction: ltr; font-family: Aptos, Arial, Helvetica, sans-se= rif; font-size: 11pt; color: rgb(0, 0, 0);"> <br> </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;">Removing the MAC algorithm and using = the PRF directly seems like an optimization worth </span>doing<span style=3D"text-transform: none;">.</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;"><br> </span></div> <div style=3D"direction: ltr; font-family: Aptos, Arial, Helvetica, sans-se= rif; font-size: 11pt; color: rgb(0, 0, 0);"> Cheers,</div> <div style=3D"direction: ltr; font-family: Aptos, Arial, Helvetica, sans-se= rif; font-size: 11pt; color: rgb(0, 0, 0);"> John Preu=DF Mattsson</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>Sunday, 26 July 2026 at 17:48<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= 12:03:45PM +0200, Nadim Kobeissi wrote:<br> ><br> > This draft looks interesting, so I would like to volunteer to maintain= <br> > some ProVerif models that track its development and run formal<br> > analysis that tracks security properties across implementations that<b= r> > use your XOF draft and those that are using current TLS 1.3, running<b= r> > in parallel.<br> ><br> > I've pushed an initial ProVerif model for the draft [2]. This model<br= > > layers the deck schedule over our existing RFC 8446bis models as a<br> > separate library, so the published models stay byte-identical and<br> > sessions of both schedules run side by side under one attacker,<br> > across all three key-exchange modes (classical (EC)DHE, standalone<br> > ML-KEM, and the hybrid).<br> <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*, Certificate= Verify*)<br> finished_key =3D Derive(BaseKey, "finished", "", Hash.l= ength)<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*, Certificate= Verify*)<br> verify_data =3D Derive(BaseKey, Finished, transcript, finished_len)<br> <br> ?<br> <br> (The PSK binder construction is similar.)<br> <br> <br> > The modeling follows the draft's own abstractions closely: section<br> > 7.1.2's one-shot equivalence, since every derived value becomes a<br> > single deck-function application over its injectively framed path.<br> > The governing cipher suite is bound at each leaf, hybrid component<br> > secrets are absorbed as separate "dh" items in group order r= ather<br> > than concatenated, the MAC is a distinct keyed function, and the<br> > transcript hash comes from the same XOF as the schedule.<br> <br> One thing to be careful of is that cryptographic sponge assumption is<br> very powerful (easily enough to prove the above transform). What<br> happens if it breaks down (partially, so everything does not sink)?<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_AS4PR07MB8825774B95A2135226B3325F89CD2AS4PR07MB8825eurp_-- --===============4014014360788331123== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KVExTIG1haWxp bmcgbGlzdCAtLSB0bHNAaWV0Zi5vcmcKVG8gdW5zdWJzY3JpYmUgc2VuZCBhbiBlbWFpbCB0byB0 bHMtbGVhdmVAaWV0Zi5vcmcK --===============4014014360788331123==--