[TLS]Re: I-D Action: draft-ietf-tls-hybrid-design-10.txt

[Deirdre Connolly <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]>
> *Sent:* Wednesday, July 24, 2024 3:34 PM
> *To:* Peter C <[e-mail]>
> *Cc:* Douglas Stebila <[e-mail]>; TLS List <[e-mail]>
> *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=
> [e-mail]> 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 <[e-mail]> On Behalf Of [e-mail]
> > Sent: Friday, April 5, 2024 9:24 PM
> > To: [e-mail]
> > Cc: [e-mail]
> > 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 [e-mail] 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
> > [e-mail]
> > 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 -- [e-mail]
> To unsubscribe send an email to [e-mail]
>
>