Draft: draft-ietf-lake-traces

Commentary: First results , needs to be confirmed 
 HTML is here : https://lake- .txt is here : https://lake- 
 Figure of key schedule in -14 
 No other issues reported besides , so merge this for submission of traces-01 . 
 The input for TH_3 given in the traces doc [ 1 ] : produces the hash value : and not [ 1 ] : https://lake- 
 Thanks for spotting this . The bug is actually in the " input " value compiled in the traces ( i.e. , not in the following values and steps ) . This applies to both traces and to the input for computing both  and TH4 . The resulting TH3 and TH4 are as already reported in the corresponding traces . I will update the traces in What we should correctly have is as follows . Trace 1 Input to calculate TH3 ( CBOR Sequence ) ( 114 bytes ) Input to calculate TH4 ( CBOR Sequence ) ( 114 bytes ) Trace 2 Input to calculate TH3 ( CBOR Sequence ) ( 44 bytes ) Input to calculate TH4 ( CBOR Sequence ) ( 44 bytes ) 
 Thanks for the fast response  ! Can you share the complete raw traces ? 
 Except for the fixes above ( to be ) , the raw traces are both available at : as part of PR 
 EDIT : The fixes above are now to PR , see the commit 
 have you looked at the ones generated by me ?
Paragraph (version A):
The traces in this draft are valid for versions -11 and -12 of I-
D.ietf-lake-edhoc, with the additional modification in
https://github.com/lake-wg/edhoc/pull/205.
Paragraph (version B):
The traces in this draft are valid for version -14 and -15 of I-
D.ietf-lake-edhoc.
Paragraph (version A):
PRK_4x3m is specified in Section 4.1.3 of I-D.ietf-lake-edhoc.
Paragraph (version A):
Since R authenticates with signatures PRK_4x3m = PRK_3e2m.
Paragraph (version B):
Since I authenticates with signatures PRK_4e3m = PRK_3e2m.
Paragraph (version A):
The mapping from EDHOC connection identifiers to OSCORE Sender/
Recipient IDs is defined in Appendix A.1 of I-D.ietf-lake-edhoc.
Paragraph (version A):
C_R is mapped to the Recipient ID of the server, i.e., the Sender ID
of the client.  Since C_R is a numeric, it is converted to a byte
string equal to its CBOR encoded form.
Paragraph (version A):
Key update is defined in Section 4.4 of I-D.ietf-lake-edhoc.
Paragraph (version B):
C_R is mapped to the Recipient ID of the server, i.e., the Sender ID
of the client.  The byte string 0x18, which as C_R is encoded as the
CBOR byte string 0x4118, is converted to the server Recipient ID
0x18.
Paragraph (version B):
C_I is mapped to the Recipient ID of the client, i.e., the Sender ID
of the server.  The byte string 0x2d, which as C_I is encoded as the
CBOR integer 0x2d is converted to the client Recipient ID 0x2d.
Paragraph (version B):
Key update is defined in Section 4.2.2 of I-D.ietf-lake-edhoc.
Paragraph (version B):
where info and hash_length as unchanged as in out-and-exporter1.
Paragraph (version A):
The public keys are represented as raw public keys (RPK), encoded in
an CWT Claims Set (CCS) and identified by the COSE header parameter
'kid'.
Paragraph (version B):
The public keys are represented as raw public keys (RPK), encoded in
a CWT Claims Set (CCS) and identified by the COSE header parameter
'kid'.
Paragraph (version A):
Since METHOD = 3, R authenticates using static DH.
Paragraph (version B):
Since METHOD = 3, R authenticates using static DH.  The EDHOC key
exchange algorithm is based on the same curve as for the ephemeral
keys, which is P-256, since the selected cipher suite is 2.
Paragraph (version B):
Since R authenticates with static DH (METHOD = 3), PRK_3e2m is
derived from SALT_3e2m and G_RX.
Paragraph (version B):
The input needed to calculate SALT_3e2m is defined in Section 4.1.2
of I-D.ietf-lake-edhoc, using Expand() with the EDHOC hash
algorithm:.
Paragraph (version A):
Since ID_CRED_R contains a single 'kid' parameter, only the int -19
is included in the plaintext.
Paragraph (version B):
Since ID_CRED_R contains a single 'kid' parameter, only the byte
string value is included in the plaintext, represented as described
in Section 3.3.2 of I-D.ietf-lake-edhoc.  The CBOR map { 4 : h'32' }
is thus replaced, not by the CBOR byte string 0x4132, but by the CBOR
int 0x32, since that is a one byte encoding of a CBOR integer (-19).
Paragraph (version A):
Since METHOD = 3, I authenticates using static DH.
Paragraph (version B):
Since METHOD = 3, I authenticates using static DH.  The EDHOC key
exchange algorithm is based on the same curve as for the ephemeral
keys, which is P-256, since the selected cipher suite is 2.
Paragraph (version B):
Since I authenticates with static DH (METHOD = 3), PRK_4e3m is
derived from SALT_4e3m and G_IY.
Paragraph (version B):
The input needed to calculate SALT_4e3m is defined in Section 4.1.2
of I-D.ietf-lake-edhoc, using Expand() with the EDHOC hash
algorithm:.
Paragraph (version A):
Since ID_CRED_I contains a single 'kid' parameter, only the int -12
is included in the plaintext.
Paragraph (version B):
Since ID_CRED_I contains a single 'kid' parameter, only the byte
string value is included in the plaintext, represented as described
in Section 3.3.2 of I-D.ietf-lake-edhoc.  The CBOR map { 4 : h'2b' }
is thus replaced, not by the CBOR byte string 0x412b, but by the CBOR
int 0x2b, since that is a one byte encoding of a CBOR integer (-12).
Paragraph (version A):
The mapping from EDHOC connection identifiers to OSCORE Sender/
Recipient IDs is defined in Section A.1of I-D.ietf-lake-edhoc.
Paragraph (version A):
C_R is mapped to the Recipient ID of the server, i.e., the Sender ID
of the client.  Since C_R is byte valued it the OSCORE Sender/
Recipient ID equals the byte string (in this case the empty byte
string).
Paragraph (version B):
C_R is mapped to the Recipient ID of the server, i.e., the Sender ID
of the client.  The byte string 0x27, which as C_R is encoded as the
CBOR integer 0x27, is converted to the server Recipient ID 0x27.
Paragraph (version B):
C_I is mapped to the Recipient ID of the client, i.e., the Sender ID
of the server.  The byte string 0x37, which as C_I is encoded as the
CBOR integer 0x0e is converted to the client Recipient ID 0x37.
Paragraph (version B):
ey update is defined in Section 4.2.2 of I-D.ietf-lake-edhoc.
Paragraph (version B):
where info and hash_length as unchanged as in out-and-exporter2.