Draft: draft-ietf-lake-edhoc

Commentary: Not sure this change is practically needed , but it is a simple change does not hurt . Actually simplifies the specification as the discussion on HKDF and empty string can be deleted . 
 No disagreement recorded - merging now . 
 The nonce used for the computation of PRK2e 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 PRK2e 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 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 . 
 This would increase the reduction bounds for PRK2e , but would it make a change if we consider the actual keystream ? ( and latter keys ) As the transcript is included inside the derivation , the keystream2 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 vs ? ( I have no clue about the answer , but I would guess that if we rely on the PRF assumption , it is mostly the same ? ) 
 Making the following change would be relatively easy : But as charlie - j points out , TH2 is already included in all the Expand ( ) derivations , so I am not sure that adding TH2 improves the practical security . 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 . 
 For comparison , below is how the TLS 1.3 key schedule looks like without PSK 
 This is not really true for the current : But would be true for 
 If we interpret in this quote as covering the PRKs , it is not true for any of them apart from PRKout , as similarly TH3 and TH4 are included only in K3 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 
 The keys ( and actually random material ) that do follow this specification are the one form the key derivation figure : So an option would be to simply point at the figure ? 
 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 ) . 
 PR is included in -16
Paragraph (version A):
The salt SHALL be a zero-length byte string.  Note that RFC5869
specifies that if the salt is not provided, it is set to a string
of zeros (see Section 2.2 of RFC5869).  For implementation
purposes, not providing the salt is the same as setting the salt
to the zero-length byte string (0x).
Paragraph (version B):
The salt SHALL be TH_2.
Paragraph (version A):
where salt = 0x (zero-length byte string).