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

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

Just a quick update/reminder on this:

The authors acknowledged that their implementation of key schedule in 
ProVerif was incorrect [5-6]. So this part of the mystery was resolved.

However, it is still unclear whether there are any /practical/ attacks 
if Derive-Secret is skipped in generating handshake and master secrets.

Again, I am not much into computational analysis. I may be missing 
something but I would very much like to know what I am missing. Is there 
any intuitive explanation for understanding why Derive-Secret is required?

Usama

On 22.12.23 11:11, Muhammad Usama Sardar wrote:
>
> 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
>>