Deirdre, I’m not familiar with the PQ3 protocol, but I think PRF-ODH can fail in practice due to the way that ECDH is usually instantiated.
For NIST P-256, the input to the KDF is usually the x-coordinate of the ECDH shared secret rather than the full point. Given a challenge (C, label), setting C’ = -C and querying the oracle with (C’, label) should give the same KDF output. For X25519, the private keys are clamped and there are usually no checks on the public keys. Given a challenge (C, label), setting C’ = C + P for a point P of small order and querying the oracle with (C’, label) should give the same KDF output. Note that in both cases we are deviating from the idealised PRF-ODH setting so this does not contradict the proof that StDH implies PRF-ODH (https://ia.cr/2017/517). Peter From: Deirdre Connolly <durumcrustu...@gmail.com> Sent: Wednesday, July 24, 2024 3:34 PM To: Peter C <pete...@ncsc.gov.uk> Cc: Douglas Stebila <dsteb...@uwaterloo.ca>; TLS List <tls@ietf.org> Subject: Re: [TLS]Re: I-D Action: draft-ietf-tls-hybrid-design-10.txt Not a direct reference for TLS 1.3, but recent related work from the document author, Douglas's analysis of PQ3 iMessage¹, has a hybrid encrypted session setup with commonalities with the TLS 1.3 key schedule, especially the layers of calls to HKDF.Expand and HKDF.extract, albeit in a different order than TLS. These proofs rely on PRF-ODH for the curves and that HKDF.Expand/Extract are PRFs in their first argument and more PRF assumptions of the ~equivalent of the large key schedule that it is also a PRF in two arguments (any chaining key material and the public session information, including the ephemeral public keys) to achieve session key indistinguishability. ¹https://security.apple.com/assets/files/Security_analysis_of_the_iMessage_PQ3_protocol_Stebila.pdf Maybe Douglas will be able to answer directly on TLS 1.3 but hopefully this is also useful ✨ On Wed, Jul 24, 2024, 6:41 AM Peter C <Peter.C=40ncsc.gov...@dmarc.ietf.org<mailto:40ncsc.gov...@dmarc.ietf.org>> wrote: Douglas, The agenda for the TLS session is looking packed, and this is a very in-the-weeds comment, so I hope you don't mind me posting it to the list. Happy to take any discussion off-list, if you'd prefer. The draft-ietf-tls-hybrid-design security considerations currently say: The shared secrets computed in the hybrid key exchange should be computed in a way that achieves the "hybrid" property: the resulting secret is secure as long as at least one of the component key exchange algorithms is unbroken. See [GIACON] and [BINDEL] for an investigation of these issues. If you assume the PQ KEM is IND-CCA2 secure, then I agree that [GIACON] and [BINDEL] imply that the derived traffic secrets will be indistinguishable from random and from each other. The same is true if the KEM is only OW-CCA2 secure by Petcher-Campagna (https://ia.cr/2023/972). If you assume the PQ KEM is broken, however, then [GIACON] and [BINDEL] do not apply since ECDH-as-a-KEM is not IND-CCA2 secure. Similarly, Petcher-Campagna does not apply because ECDH is not OW-CCA2 secure. Nor do I think it's possible to fall back on [DOWLING] since X25519 and NIST P-256 (as they are used in RFC 8446) do not satisfy the dual-snPRF-ODH assumption for any choice of KDF. In this case, I don't believe the derived traffic secrets are guaranteed to be indistinguishable from random. Flo raised similar points a couple of years ago which I don't think were fully addressed at the time. I suspect this is just a security proof issue - the inclusion of the ciphertexts in the transcript hash should still protect against any actual attacks - and it's entirely possible that I've missed more recent results covering all of this. If not, one easy solution might be to adopt the X-Wing approach and use concatenated_ss = pqkem_ss || ecdh_ss || ecdh_ct || ecdh_pk, although this currently only works with ML-KEM. Best, Peter > -----Original Message----- > From: TLS <tls-boun...@ietf.org<mailto:tls-boun...@ietf.org>> On Behalf Of > internet-dra...@ietf.org<mailto:internet-dra...@ietf.org> > Sent: Friday, April 5, 2024 9:24 PM > To: i-d-annou...@ietf.org<mailto:i-d-annou...@ietf.org> > Cc: tls@ietf.org<mailto:tls@ietf.org> > Subject: [TLS] I-D Action: draft-ietf-tls-hybrid-design-10.txt > > Internet-Draft draft-ietf-tls-hybrid-design-10.txt is now available. It is a > work item of the Transport Layer Security (TLS) WG of the IETF. > > Title: Hybrid key exchange in TLS 1.3 > Authors: Douglas Stebila > Scott Fluhrer > Shay Gueron > Name: draft-ietf-tls-hybrid-design-10.txt > Pages: 24 > Dates: 2024-04-05 > > Abstract: > > Hybrid key exchange refers to using multiple key exchange algorithms > simultaneously and combining the result with the goal of providing > security even if all but one of the component algorithms is broken. > It is motivated by transition to post-quantum cryptography. This > document provides a construction for hybrid key exchange in the > Transport Layer Security (TLS) protocol version 1.3. > > Discussion of this work is encouraged to happen on the TLS IETF > mailing list tls@ietf.org<mailto:tls@ietf.org> or on the GitHub repository > which contains > the draft: > https://github/. > com%2Fdstebila%2Fdraft-ietf-tls-hybrid- > design&data=05%7C02%7CPeter.C%40ncsc.gov.uk<http://40ncsc.gov.uk/>%7Cec161933c97947c8a7e0 > 08dc55ae8cd7%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C6384 > 79455373796379%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiL > CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata > =qNBE50aYk4woYCLUj6Rq1wMeFur63hP1MnHXDGihg80%3D&reserved=0. > > The IETF datatracker status page for this Internet-Draft is: > https://datatra/ > cker.ietf.org<http://cker.ietf.org/>%2Fdoc%2Fdraft-ietf-tls-hybrid- > design%2F&data=05%7C02%7CPeter.C%40ncsc.gov.uk<http://40ncsc.gov.uk/>%7Cec161933c97947c8 > a7e008dc55ae8cd7%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C > 638479455373796379%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM > DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&s > data=kVBR6kDc19NDTnC1fRgVqJmTnZOQggzmWk7wHHcVKbI%3D&reserved= > 0 > > There is also an HTML version available at: > https://www.ie/ > tf.org<http://tf.org/>%2Farchive%2Fid%2Fdraft-ietf-tls-hybrid-design- > 10.html&data=05%7C02%7CPeter.C%40ncsc.gov.uk<http://40ncsc.gov.uk/>%7Cec161933c97947c8a7e > 008dc55ae8cd7%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C638 > 479455373796379%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAi > LCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdat > a=dcjY38cicBXU6ab7hnMalN1WTWqtQdhblMYu7xdzVT8%3D&reserved=0 > > A diff from the previous version is available at: > https://author/ > -tools.ietf.org<http://tools.ietf.org/>%2Fiddiff%3Furl2%3Ddraft-ietf-tls-hybrid-design- > 10&data=05%7C02%7CPeter.C%40ncsc.gov.uk<http://40ncsc.gov.uk/>%7Cec161933c97947c8a7e008d > c55ae8cd7%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C6384794 > 55373952646%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQ > IjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=3ll > ZNYcqaixqUpU%2BhzzNOigFmuDlrA6CxCrIvyiG5HI%3D&reserved=0 > > Internet-Drafts are also available by rsync at: > rsync.ietf.org::internet-drafts > > > _______________________________________________ > TLS mailing list > TLS@ietf.org<mailto:TLS@ietf.org> > https://www.ie/ > tf.org<http://tf.org/>%2Fmailman%2Flistinfo%2Ftls&data=05%7C02%7CPeter.C%40ncsc.gov.u > k%7Cec161933c97947c8a7e008dc55ae8cd7%7C14aa5744ece1474ea2d734f46 > dda64a1%7C0%7C0%7C638479455373952646%7CUnknown%7CTWFpbGZsb3 > d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0% > 3D%7C0%7C%7C%7C&sdata=rFzF%2BExBIX03adggpWV4uxzcgfHR6Z0zCLamc > GZIX9o%3D&reserved=0 _______________________________________________ TLS mailing list -- tls@ietf.org<mailto:tls@ietf.org> To unsubscribe send an email to tls-le...@ietf.org<mailto:tls-le...@ietf.org>
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
