Using sid as nonce in Extract for better security reduction

[cottierb]

The nonce used for the computation of PRK_2e in the key schedule is set to be an empty. By replacing this empty string by the sid of the session, this makes the key PRK_2e linked to the session connection identifiers and divides the chances for an attacker to correctly compute the key PRK_2e by the number of running sessions.

More precisely, considering $n$ running sessions, computing Extract("",Z) with a random Z, the attacker may have a match with any of the sessions. While considering using a sid, computing Extract(sid, Z), the attacker may have a match only with the session using this sid.

[charlie-j]

This would increase the reduction bounds for PRK_2e, but would it make a change if we consider the actual keystream? (and latter keys) KEYSTREAM_2 = EDHOC-KDF( PRK_2e, 0, TH_2, plaintext_length )

As the transcript is included inside the derivation, the keystream_2 does depend on all the information exchanged that could be used to build an sid.

At a high level, the question is kind of the following I guess: is it better to do Expand( Extract(0,Z), TH_2, length) vs Expand( Extract(TH_2,Z), 0, length)? (I have no clue about the answer, but I would guess that if we rely on the PRF assumption, it is mostly the same?)

[emanjon]

Making the following change would be relatively easy:

OLD: PRK_2e = Extract( 0x, G_XY )
NEW: PRK_2e = Extract( TH_2, G_XY )

But as charlie-j points out, TH_2 is already included in all the Expand() derivations, so I am not sure that adding TH_2 improves the practical security.

computing Extract("",Z) with a random Z, the attacker may have a match with any of the sessions. While considering using a sid, computing Extract(sid, Z), the attacker may have a match only with the session using this sid.

For the inclusion of SID to make this "attack" harder the size of the curve would have to be smaller than the size of the hash function output. For the X25519-SHA-256 combination that is true but the size of X25519 is still 2^252. Brute forcing that would be much harder than brute forcing the typically 128 bit OSCORE key or breaking X25519 with Pollard's rho.

[emanjon]

For comparison, below is how the TLS 1.3 key schedule looks like without PSK

             0
             |
             v
000... ->  HKDF-Extract
             |
             v
       Derive-Secret(., "derived", "")
             |
             v
   (EC)DHE -> HKDF-Extract = Handshake Secret
             |
             +-----> Derive-Secret(., "c hs traffic",
             |                     ClientHello...ServerHello)
             |                     = client_handshake_traffic_secret
             |
             +-----> Derive-Secret(., "s hs traffic",
             |                     ClientHello...ServerHello)
             |                     = server_handshake_traffic_secret

[emanjon]

draft-ietf-lake-edhoc-14: "and all symmetric keys are derived using as much previous information as possible"

This is not really true for the current: PRK_2e = Extract( 0x, G_XY )

But would be true for PRK_2e = Extract( TH_2, G_XY )

[charlie-j]

If we interpret symmetric keys in this quote as covering the PRKs, it is not true for any of them apart from PRK_out, as similarly TH_3 and TH_4 are included only in K_3 and K_4.

[emanjon]

If we interpret symmetric keys in this quote as covering the PRKs, it is not true for any of them apart from PRK_out, as similarly TH_3 and TH_4 are included only in K_3 and K_4.

Good point. Let's see if we should reformulate "and all symmetric keys are derived using as much previous information as possible" is some way

[charlie-j]

The keys (and actually random material) that do follow this specification are the one form the key derivation figure:

{: #fig-edhoc-kdf title="Key derivations using EDHOC-KDF."} {: artwork-align="center"}

So an option would be to simply point at the figure?

[emanjon]

Making a PR for this I noticed that this change has the benefit of allowing the text talking about HKDF and using the empty string as salt. Irrespectively of if the extra security factor is needed or not I therefore think this change should be done. There does not seem to be any negative affects of the change (except that it affects the test vectors).

[gselander]

PR #323 is included in -16