From nobody Mon Sep 6 10:07:32 2021 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14B3C3A169D for ; Mon, 6 Sep 2021 10:07:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GSkIuXXWSRee for ; Mon, 6 Sep 2021 10:07:24 -0700 (PDT) Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67B143A169B for ; Mon, 6 Sep 2021 10:07:24 -0700 (PDT) Received: by mail-qk1-x72c.google.com with SMTP id a10so7444620qka.12 for ; Mon, 06 Sep 2021 10:07:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0E3aNoNebj0iommSXRx/4YEmUfvNWZyC821obb1/9TQ=; b=Xn3htjDagz7EwyrwkeZc7VWPuC7phDecvUUqpl/4FsHtZowJWDJijGfYpkjCBibUQc vWfNAj1VnkOhW1Bqc1oGlQGjwH8YnBfPxi5SV7YRhmhu2FJircuFNilDYOHTcS3r2qly 6ycPJmkGvBL1aMuMxXygwdWSbp9MfXstqJsN0D/ZNVAFoInUSS+qVO/gOJWYbXozuWAZ fRwjHs998IpbLm9RK2wEn6Pyp1rdHXAvf+VHbmQF1uD0s6JEu1ScIAdQyTY73rw51DOo 1UopUl8JqJvte88HXgYcp/7F4fTToBDJrIZNNuVrhFngxVjDSOvoXoTU7to+c6rxaTL8 AfnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0E3aNoNebj0iommSXRx/4YEmUfvNWZyC821obb1/9TQ=; b=Aie+C6oLYTrH3ZQbvxVhpqKPC64C8C1UcGtxWv+FusfYfnbRjRKHuciUwkTeoQPvYM pKbFoUrWGRe2386kbncN1yO0Y/OlPFCZ39eSJPHFpWQnplSSiLzaq7JyJrnCP0bYKN9R THm2PAytRPIq76jw7eOxAyxlXvpM9U9GDVIrTjLVqbKwR1yd+Iglf3DD9tOVnhIxe+22 FnTV+Mto3/eLTQxot1EiHdRj/xjIe13+w6CTcp5PdhgwBLKkotwyhSjcJf3Vnj7sq4UN ahRu16Q4i5nAjGa2ny6bGSBv3movzrkTjo2oydhqadv9d6hBWiTkKHOqUgOiAGo3wyUK dkeA== X-Gm-Message-State: AOAM530OXdn9eqNaWag1zbPmZpLCU7Gq4wZ7aGJtMgEiqGp4yjOqNKLr BPiURXtOE4/AK+6qrLSiCXGDQFGrcHmBi+dKzkU= X-Google-Smtp-Source: ABdhPJygdBRbNMo4C/clKY+b3kr9+qwejQV8rxUUj78fPcD+COXMxpe9zRw3kO0HeLEgMSPFWA/RNbpPFOJWaRD0uh0= X-Received: by 2002:a05:620a:11a6:: with SMTP id c6mr11394728qkk.458.1630948042210; Mon, 06 Sep 2021 10:07:22 -0700 (PDT) MIME-Version: 1.0 References: <27861041-A7D9-401F-8790-4BD76ED3CB9D@ll.mit.edu> <6AB0509D-EBD2-479E-B2D9-E61023A2019A@ll.mit.edu> In-Reply-To: <6AB0509D-EBD2-479E-B2D9-E61023A2019A@ll.mit.edu> From: Nimrod Aviram Date: Mon, 6 Sep 2021 20:07:10 +0300 Message-ID: To: "Blumenthal, Uri - 0553 - MITLL" Cc: "" Content-Type: multipart/alternative; boundary="000000000000b4004405cb56ae07" Archived-At: Subject: Re: [TLS] Combining Secrets in Hybrid Key Exchange in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Sep 2021 17:07:30 -0000 --000000000000b4004405cb56ae07 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'd like to understand your position better. > Since (if memory serves me) KDF is HMAC-based, rather than merely SHA-based =E2=80=93 it won=E2=80=99t matter from the security point of view= whether SHA256 will or will not show collisions. So, if I understand correctly, you argue that the text David Benjamin quoted from Appendix E.1 is wrong? The second paragraph in Appendix E.1.1: https://datatracker.ietf.org/doc/html/rfc8446#appendix-E.1.1 "This requires the underlying hash function to be collision resistant..." Moreover, if it won=E2=80=99t matter from the security point of view whethe= r SHA256 will or will not show collisions, then this implies that (hypothetically) switching from SHA256 to e.g. MD5 will not degrade security. Is this your position? If so, could you please provide references that support this position, e.g. prove security under a non-CR hash function? > I don=E2=80=99t think so. If I understand correctly, you wrote this in response to me saying "an attacker that can establish multiple PSKs of their choice with another party can cause two sessions with two different PSKs to share the same early_secret... This likely violates the security proof for TLS 1.3, in and of itself." Is this what you're referring to? And I understand that you claim that an attacker achieving this would not violate any proven security property of TLS 1.3? best, Nimrod On Thu, 2 Sept 2021 at 23:32, Blumenthal, Uri - 0553 - MITLL wrote: > The APOP attack demonstrates that concatenating secrets may be dangerous, > as a general cryptographic practice. > > > > I disagree with the word =E2=80=9Cgeneral=E2=80=9D here. > > > > As to the TLS KDF, if future SHA256 cryptanalysis results in collisions, > > > > Since (if memory serves me) KDF is HMAC-based, rather than merely > SHA-based =E2=80=93 it won=E2=80=99t matter from the security point of vi= ew whether SHA256 > will or will not show collisions. > > > > This likely violates the security proof for TLS 1.3, in and of itself. > > > > I don=E2=80=99t think so. > > > > A similar violation of the security guarantee seems to arise when using > hybrid key exchange with a PQ KEM. > > > > I absolutely don=E2=80=99t think so. > > > > Or if that's what you're asking: As we write, we are unaware of a way to > apply the APOP attack to the TLS KDF. > > > > Excellent, thanks! I concur here. > > > > We view this as an opportunity to defend-in-depth against such issues, > while the document is not yet finalized. > > > > I think we=E2=80=99re OK as-is. > > > > > > On Wed, 1 Sept 2021 at 23:34, Blumenthal, Uri - 0553 - MITLL < > uri@ll.mit.edu> wrote: > > How does the described AOAP attack apply to TLS KDF? > > > > -- > > Regards, > > Uri > > > > *There are two ways to design a system. One is to make is so simple there > are obviously no deficiencies.* > > *The other is to make it so complex there are no obvious deficiencies.* > > * > = - > C. A. R. Hoare* > > > > > > *From: *TLS on behalf of Nimrod Aviram < > nimrod.aviram@gmail.com> > *Date: *Wednesday, September 1, 2021 at 15:58 > *To: *"" > *Cc: *Eylon Yogev , Ilan Komargodski < > ilankom10@gmail.com>, Benjamin Dowling , Eyal > Ronen > *Subject: *[TLS] Combining Secrets in Hybrid Key Exchange in TLS 1.3 > > > > (This note is also available on Github > for ease of reading.) > > > > This note identifies a possible security problem in the "Hybrid key > exchange in > TLS 1.3" document, stemming from how cryptographic secrets are combined. = In > short: constructions that concatenate secrets are vulnerable when the > underlying > hash function is not collision-resistant. We are unaware of a full attack > that leverages the underlying problem. However, we view this as an > opportunity > to defend-in-depth against such issues, while the document is not yet > finalized. > We propose a new construction that seems robust to this potential issue, > and we > are in the process of writing a technical report that includes a full > security > proof. > > # Concatenating Secrets May Be Dangerous > > The APOP attack (see appendix for a brief description) demonstrates that > concatenating secrets to potentially attacker-controlled input might be > dangerous. Currently, the "Hybrid key exchange in TLS 1.3" document uses > secret > concatenation as the preferred way to combine secrets. (This was an > understandable design choice given how little this issue has been studied= .) > > We recommend a defense-in-depth approach against this potential issue. We > should > not concede to an attacker even the ability to cause a collision in an > internal > state of the key schedule. Moreover, this part of TLS is likely > particularly > amenable to ossification: Whatever we standardize will likely persist for > 5-10 > years. (We do note that TLS mixes in the client and server nonces, so > additional > offensive techniques would be required to exploit this for a full attack.= ) > > We note that concatenation is also used in the "TLS 1.3 Extended Key > Schedule" > document. > > # Our proposed construction > > We have identified an alternative construction that we believe could > provide > defense-in-depth against this issue. We are in the process of writing a > technical report that includes a full security proof. > The required assumptions on the hash function appear to be much milder th= an > collision resistance; instead, we likely only need > multi-preimage-resistance: > Essentially, requiring only that computing preimages for multiple images = is > hard. > > The construction is: > combined_key =3D H(HMAC(key=3DH1(k1), data=3D2||F(k2)) xor HMAC(key=3DH2(= k2), > data=3D1||F(k1))) > where || denotes concatenation, H denotes the underlying hash function, > and: > H1(k) =3D H('derive1' || k) > H2(k) =3D H('derive2' || k) > F is defined as follows: > Let m denote the input to F. We split m into blocks, according to the > block size > of H: > m =3D m1||m2||...||mn > Let j~=3D3 denote an =E2=80=9Cexpanding factor=E2=80=9D (the value chosen= for j in practice > depends on how strong an assumption we want to rely on; we expect 3 to be > enough). > Then > F(m) =3D > H(0||m1)||H(1||m1)||...||H(j-1||m1)||H(0||m2)||H(1||m2)||...||H(j-1||m2)|= |H(0||mn)||H(1||mn)||...||H(j-1||mn) > > This construction is cheap to calculate and would be used only in the key > schedule, which is not a bottleneck for TLS performance. > > # Adding another layer to the TLS key schedule may also be problematic > > Another strategy for mixing secrets is to add the second secret to anothe= r > layer > of the TLS key schedule. This strategy is already used to mix a PSK and a= n > ECDHE > secret in TLS 1.3, as well as in AuthKEM, and it was also considered for > the > Hybrid key exchange document. This strategy is vulnerable as well to > collisions > in the underlying hash function, and we propose using one secure > construction > for mixing secrets. > > Consider a standard PSK+ECDHE TLS 1.3 handshake. Then > handshake_secret =3D HKDF_Extract(IKM=3DECDHE_secret, > salt=3DDerive_Secret(early_secret)) > early_secret =3D HKDF_Extract(IKM=3DPSK, salt=3D000) > HKDF_Extract(IKM, salt) =3D HMAC(k=3Dsalt, data=3DIKM) > > Therefore, early_secret =3D HMAC(k=3D000, data=3DPSK). > Assume a non-collision-resistant hash function. Then an attacker that can > establish multiple PSKs of their choice with another party can cause two > sessions with two different PSKs to share the same early_secret. If the > other > party reuses ECDH(E) values, the attacker can also cause the > handshake_secret to > be identical. > > Furthermore, > Client_Handshake_Traffic_Secret =3D > HMAC(k=3DHandshake_Secret, data=3DLabel||H(ClientHello...ServerHello)) > If the attacker is the server, and the hash function allows for > chosen-prefix > collisions, the attacker can choose two ServerHello messages such that fo= r > two > different ClientHello messages, H(ClientHello...ServerHello) is identical= . > This leads to identical values for an actual key output of the key > schedule, > Client-Handshake-Traffic-Secret (if the client reuses an ECDH(E) value, o= r > in a > hypothetical PQ TLS, which uses a KEM and the server chooses the > encapsulated > key). > > We note that the full version of the HKDF paper explicitly disclaims > security in > the presence of attacker-controlled entropy. Also, note that by > definition, a > KEM allows one party to control the secret. > > # Appendix: The APOP Attack > > APOP is an old challenge-response protocol used in email, relevant here > because > it demonstrates the attack well. Broadly, in APOP the challenger sends a > challenge, and the responder needs to respond with: > MD5(challenge || password) > where || denotes concatenation. > > The attacker wants to e.g. test whether the password starts with 'a'. The= y > pick an MD5 collision x, y such that MD5(x) =3D MD5(y) and both x and y e= nd > with > 'a'. They wait for the client to connect in two different sessions, and > send > x[:-1] and y[:-1] as the challenges, where [:-1] denotes removing the las= t > byte > from a string. If the password starts with 'a', and the MD5 blocks align, > then > the response will be the same for both challenges. The attacker can > therefore > test a single guess for the starting byte with two sessions, and learn > that byte > after at most 512 sessions. See [1], [2]. > > best wishes, > Nimrod Aviram, Benjamin Dowling, Ilan Komargodski, Kenny Paterson, Eyal > Ronen, Eylon Yogev > > References: > [1] Practical key-recovery attack against APOP, an MD5-based > challenge-response authentication. Leurent, Gaetan. > > [2] Practical Password Recovery on an MD5 Challenge and Response. > Sasaki, Yu and Yamamoto, Go and Aoki, Kazumaro. > > > > --000000000000b4004405cb56ae07 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I&#= 39;d like to understand your position better.

> Since (if memory = serves me) KDF is HMAC-based, rather than merely SHA-based =E2=80=93 it won= =E2=80=99t matter from the security point of view whether SHA256 will or wi= ll not show collisions.
So, if I understand correctly, you argue that th= e text David Benjamin quoted from Appendix E.1 is wrong?
The second para= graph in Appendix E.1.1:
https://datatracker.ietf.org/doc/html/rfc8446#app= endix-E.1.1
"This requires the underlying hash function to be c= ollision resistant..."

Moreover, if it won=E2=80=99t matter fro= m the security point of view whether SHA256 will or will not show collision= s, then this implies that (hypothetically) switching from SHA256 to e.g. MD= 5 will not degrade security.
Is this your position? If so, could you ple= ase provide references that support this position, e.g. prove security unde= r a non-CR hash function?

> I don=E2=80=99t think so.
If I und= erstand correctly, you wrote this in response to me saying "an attacke= r that can establish multiple PSKs of their choice with another party can c= ause two sessions with two different PSKs to share the same early_secret...= This likely violates the security proof for TLS 1.3, in and of itself.&quo= t;
Is this what you're referring to? And I understand that you claim= that an attacker achieving this would not violate any proven security prop= erty of TLS 1.3?

best,
Nimrod


On Thu, 2 Sept 2021 at 23:32, Blumenthal= , Uri - 0553 - MITLL <uri@ll.mit.edu> wrote:

The APOP attack demon= strates that concatenating secrets may be dangerous, as a general cryptogra= phic practice.

=C2=A0

<= span style=3D"font-size:12pt;color:rgb(0,112,192)">I disagree with the word= =E2=80=9Cgeneral=E2=80=9D here.

<= u>=C2=A0

As to the TLS KDF, if futur= e SHA256 cryptanalysis results in collisions,

=C2=A0

Since (if memory serves me) KDF is HMAC-based, rather than merely SHA-= based =E2=80=93 it won=E2=80=99t matter from the security point of view whe= ther SHA256 will or will not show collisions.

=C2=A0

This likely violates the security proof for TLS 1.3,= in and of itself.

=C2=A0

I don=E2=80=99t think = so.

=C2=A0

A similar violation of the security guarantee seems to arise when using h= ybrid key exchange with a PQ KEM.

=C2=A0

I absol= utely don=E2=80=99t think so.<= u>

=C2=A0

Or if that's what you're asking: As we write, we are unawa= re of a way to apply the APOP attack to the TLS KDF.

=C2=A0

Excellent, thanks! I concur here.

=C2=A0=

We view this as an opportunity to defend-in-depth ag= ainst such issues, while the document is not yet finalized.

=C2= =A0

I think we=E2=80=99re OK as-is.

=C2=A0

=C2=A0

How does the described AOAP attack apply to TLS KDF?<= u>

=C2=A0

--<= /u>

Regards,

Uri=

=C2=A0

There are two ways to design a system. One is to make i= s so simple there are obviously no deficiencies.

The other is to make it so complex there are no obvious deficienci= es.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0-=C2=A0 C. A. R. Hoare

= =C2=A0

=C2=A0

From: TLS <tls-bounces@ietf.org> on behalf = of Nimrod Aviram <nimrod.aviram@gmail.com>
Date: Wednesday, September= 1, 2021 at 15:58
To: "<tls@ietf.org>" <tls@ietf.org>
Cc: Eylon Yogev <<= a href=3D"mailto:eylony@gmail.com" target=3D"_blank">eylony@gmail.com&g= t;, Ilan Komargodski <ilankom10@gmail.com>, Benjamin Dowling <b.dowling@sheffield.ac.uk&= gt;, Eyal Ronen <er@e= yalro.net>
Subject: [TLS] Combining Secrets in Hybrid Key = Exchange in TLS 1.3

=C2=A0

(= This note is also available on Github for ease of reading.)=

=C2=A0

T= his note identifies a possible security problem in the "Hybrid key exc= hange in
TLS 1.3" document, stemming from how cryptographic secrets= are combined. In
short: constructions that concatenate secrets are vuln= erable when the underlying
hash function is not collision-resistant. We = are unaware of a full attack
that leverages the underlying problem. Howe= ver, we view this as an opportunity
to defend-in-depth against such issu= es, while the document is not yet finalized.
We propose a new constructi= on that seems robust to this potential issue, and we
are in the process = of writing a technical report that includes a full security
proof.
# Concatenating Secrets May Be Dangerous

The APOP attack (see appe= ndix for a brief description) demonstrates that
concatenating secrets to= potentially attacker-controlled input might be
dangerous. Currently, th= e "Hybrid key exchange in TLS 1.3" document uses secret
concat= enation as the preferred way to combine secrets. (This was an
understand= able design choice given how little this issue has been studied.)

We= recommend a defense-in-depth approach against this potential issue. We sho= uld
not concede to an attacker even the ability to cause a collision in = an internal
state of the key schedule. Moreover, this part of TLS is lik= ely particularly
amenable to ossification: Whatever we standardize will = likely persist for 5-10
years. (We do note that TLS mixes in the client = and server nonces, so additional
offensive techniques would be required = to exploit this for a full attack.)

We note that concatenation is al= so used in the "TLS 1.3 Extended Key Schedule"
document.
# Our proposed construction

We have identified an alternative cons= truction that we believe could provide
defense-in-depth against this iss= ue. We are in the process of writing a
technical report that includes a = full security proof.
The required assumptions on the hash function appea= r to be much milder than
collision resistance; instead, we likely only n= eed multi-preimage-resistance:
Essentially, requiring only that computin= g preimages for multiple images is
hard.

The construction is: combined_key =3D H(HMAC(key=3DH1(k1), data=3D2||F(k2)) xor HMAC(key=3DH2(k= 2), data=3D1||F(k1)))
where || denotes concatenation, H denotes the und= erlying hash function, and:
H1(k) =3D H('derive1' || k)
H2(= k) =3D H('derive2' || k)
F is defined as follows:
Let m deno= te the input to F. We split m into blocks, according to the block size
o= f H:
m =3D m1||m2||...||mn
Let j~=3D3 denote an =E2=80=9Cexpanding = factor=E2=80=9D (the value chosen for j in practice
depends on how stron= g an assumption we want to rely on; we expect 3 to be enough).
Then
= F(m) =3D H(0||m1)||H(1||m1)||...||H(j-1||m1)||H(0||m2)||H(1||m2)||...||H(j-= 1||m2)||H(0||mn)||H(1||mn)||...||H(j-1||mn)

This construction is che= ap to calculate and would be used only in the key
schedule, which is not= a bottleneck for TLS performance.

# Adding another layer to the TLS= key schedule may also be problematic

Another strategy for mixing se= crets is to add the second secret to another layer
of the TLS key schedu= le. This strategy is already used to mix a PSK and an ECDHE
secret in TL= S 1.3, as well as in AuthKEM, and it was also considered for the
Hybrid = key exchange document. This strategy is vulnerable as well to collisionsin the underlying hash function, and we propose using one secure construct= ion
for mixing secrets.

Consider a standard PSK+ECDHE TLS 1.3 han= dshake. Then
handshake_secret =3D HKDF_Extract(IKM=3DECDHE_secret, salt= =3DDerive_Secret(early_secret))
early_secret =3D HKDF_Extract(IKM=3DPSK= , salt=3D000)
HKDF_Extract(IKM, salt) =3D HMAC(k=3Dsalt, data=3DIKM)
Therefore, early_secret =3D HMAC(k=3D000, data=3DPSK).
Assume a no= n-collision-resistant hash function. Then an attacker that can
establish= multiple PSKs of their choice with another party can cause two
sessions= with two different PSKs to share the same early_secret. If the other
pa= rty reuses ECDH(E) values, the attacker can also cause the handshake_secret= to
be identical.

Furthermore,
Client_Handshake_Traffic_Secre= t =3D
=C2=A0 HMAC(k=3DHandshake_Secret, data=3DLabel||H(ClientHello...S= erverHello))
If the attacker is the server, and the hash function allow= s for chosen-prefix
collisions, the attacker can choose two ServerHello = messages such that for two
different ClientHello messages, H(ClientHello= ...ServerHello) is identical.
This leads to identical values for an actu= al key output of the key schedule,
Client-Handshake-Traffic-Secret (if t= he client reuses an ECDH(E) value, or in a
hypothetical PQ TLS, which us= es a KEM and the server chooses the encapsulated
key).

We note th= at the full version of the HKDF paper explicitly disclaims security in
t= he presence of attacker-controlled entropy. Also, note that by definition, = a
KEM allows one party to control the secret.

# Appendix: The APO= P Attack

APOP is an old challenge-response protocol used in email, r= elevant here because
it demonstrates the attack well. Broadly, in APOP t= he challenger sends a
challenge, and the responder needs to respond with= :
MD5(challenge || password)
where || denotes concatenation.

T= he attacker wants to e.g. test whether the password starts with 'a'= . They
pick an MD5 collision x, y such that MD5(x) =3D MD5(y) and both x= and y end with
'a'. They wait for the client to connect in two = different sessions, and send
x[:-1] and y[:-1] as the challenges, where = [:-1] denotes removing the last byte
from a string. If the password star= ts with 'a', and the MD5 blocks align, then
the response will be= the same for both challenges. The attacker can therefore
test a single = guess for the starting byte with two sessions, and learn that byte
after= at most 512 sessions. See [1], [2].

best wishes,
Nimrod Aviram, = Benjamin Dowling, Ilan Komargodski, Kenny Paterson, Eyal Ronen, Eylon Yogev=

References:
[1] Practical key-recovery attack against APOP, an = MD5-based challenge-response authentication. Leurent, Gaetan.

[2] Pr= actical Password Recovery on an MD5 Challenge and Response.
Sasaki, Yu a= nd Yamamoto, Go and Aoki, Kazumaro.

=C2=A0

= --000000000000b4004405cb56ae07--