Yet another reason I would love full group elements included in these protocols but alas
On Wed, Jul 24, 2024, 9:22 AM Peter C <pete...@ncsc.gov.uk> wrote: > 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> 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> On Behalf Of internet-dra...@ietf.org > > Sent: Friday, April 5, 2024 9:24 PM > > To: i-d-annou...@ietf.org > > Cc: 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 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%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%2Fdoc%2Fdraft-ietf-tls-hybrid- > > design%2F&data=05%7C02%7CPeter.C%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%2Farchive%2Fid%2Fdraft-ietf-tls-hybrid-design- > > 10.html&data=05%7C02%7CPeter.C%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%2Fiddiff%3Furl2%3Ddraft-ietf-tls-hybrid-design- > > 10&data=05%7C02%7CPeter.C%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 > > https://www.ie/ > > 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 > To unsubscribe send an email to tls-le...@ietf.org > >
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
