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
<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
To unsubscribe send an email to tls-le...@ietf.org
