Hi Hugo,
Following the related sources [1-4], it appears to be - as Eric called
it - a theoretical and futuristic concern. In my understanding, the main
concern was that with the key hierarchy of draft 18:
* the Handshake Secret could collide with binder_key if the attacker
is somehow able to match (EC)DHE secret with the label to the
corresponding Derive-Secret.
* the Handshake Secret could collide with client_early_traffic_secret
if the attacker is somehow able to match (EC)DHE secret with the
label to the corresponding Derive-Secret.
The reasoning for 2nd Derive-Secret is even more far-fetched. If in the
future the IKM input to HKDF-Extract (zero) changes, then similar
collision may happen between Master Secret and
client_handshake_traffic_secret or server_handshake_traffic_secret. So
my question more precisely is:
* Is there any /practical/ security implication for missing the
additional Derive-Secrets? Has this ever been /practically/
exploited? Has anyone else explored this?
Now about the Inria paper that you have mentioned, I am not much
knowledgeable about computational analysis. I understand that it helped
them remove the assumption (that DH group elements do not match the
corresponding labels) in their proof in CryptoVerif but the
corresponding formal analysis in ProVerif in the same paper does not
support this view, i.e., all properties remain the same regardless of
the additional Derive-Secret.
Moreover, the implementation of key hierarchy in draft 20 in ProVerif by
the authors is incorrect [5-6]. For instance, due to a strange reason
and beyond our understanding, the draft 20 implementation does not use
the Derive-Secret for Master Secret [5]. Do you have any
thoughts/opinion on this? The same implementation is being used by other
extensions as a baseline, including Lurk [7].
Usama
[1] https://github.com/tlswg/tls13-spec/pull/875
[2] https://mailarchive.ietf.org/arch/msg/tls/cS4vdMvENOGdpall7uos9iwZ5OA/
[3] https://datatracker.ietf.org/meeting/98/materials/slides-98-tls-tls13-00
[4]
https://www.youtube.com/watch?v=oSwXkhVd2ts&list=PLC86T-6ZTP5jo6kIuqdyeYYhsKv9sUwG1&ab_channel=IETF-InternetEngineeringTaskForce
[5] https://github.com/Inria-Prosecco/reftls/issues/6
[6] https://github.com/Inria-Prosecco/reftls/issues/7
[7] https://github.com/lurk-t/proverif
On 17.12.23 21:05, Hugo Krawczyk wrote:
See full thread here
https://mailarchive.ietf.org/arch/msg/tls/cS4vdMvENOGdpall7uos9iwZ5OA/
See also how this helped analysis here (search for reference [73]
https://inria.hal.science/hal-01528752v3/file/RR-9040.pdf
On Sat, Dec 16, 2023 at 1:16 PM Muhammad Usama Sardar
<muhammad_usama.sar...@tu-dresden.de> wrote:
Hi all,
In the key schedule (section 7.1) of RFC8446(bis), what is the
rationale for using /*Derive-Secret(., "derived", "")*/in the
derivations of Handshake and Master Secrets? Since this change was
made in draft 19, I expect there should be some reasoning of why
this was added. Specifically, what are the security implications
if this step is missed, i.e.,
* if Early Secret is directly used as the Salt argument for
HKDF-Extract of Handshake Secret;
* and similarly if Handshake Secret is directly used as the Salt
argument for HKDF-Extract of Master Secret.
Regards,
Usama
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
