Re: [TLS] Key Hierarchy TLS 1.3 RFC8446(bis)

[Muhammad Usama Sardar <[e-mail]>]

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 
> <[e-mail]> 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
>     [e-mail]
>     https://www.ietf.org/mailman/listinfo/tls
>