From: Ace <[email protected]> On Behalf Of Mališa Vucinic Sent: Sunday, July 15, 2018 5:44 PM To: [email protected] Subject: [Ace] Message overhead of the OSCORE profile and ACE specs Hi Ludwig, all, I am in the process of implementing draft-ietf-ace-oscore-profile-02 for openwsn.org <http://openwsn.org/> . For now, I have a first implementation of AS available, and will be going to the firmware part in the next weeks.. I have to say that I was quite frustrated with the number of drafts that I had to go through in order to understand what should be implemented. Maybe this is implied knowledge for people actively working on ACE, but I believe a guide somewhere pointing to different specs one needs to follow in order to instantiate a profile would be quite beneficial. Here, I'd like to share my comments about the message overhead found when implementing the OSCORE profile and give some optimization proposals. I am mostly concerned with the response from AS to C, where C is in a constrained network. Please bear with me that my understanding of the specs is correct and that my implementation generated correct outputs. Assumptions used in the implementation: - OSCORE channel between AS and C, AS and RS. - AS and RS share an additional key, derived from the OSCORE Master Secret using HKDF label 'ACE' and RS's unique identifier. Explicit monotonically increasing counter kept to generate nonce, incremented for each Encrypt0 object generated towards a given RS. - Profile is implicitly known by all the parties - Scope is implicitly known by all the parties - Audience is implicitly known by all the parties - Default values of OSCORE KDF, salt, id_context To save bytes, I use the following optimizations: - Sending single byte for PIV in COSE Encrypt0 of CWT, the actual AEAD nonce is PIV prepended with zeros - Using single byte for OSCORE IDs in the security context generated by AS [JLS] Both of these optimizations are ones that I would expect to be used. With this, I got the CoAP payload from AC to C down to 82 bytes. This overflows 802.15.4 + 6LoWPAN + UDP packet by 29 bytes, assuming the latest OpenWSN implementation implementing most of the cross layer optimizations available and not supporting fragmentation. [JLS] From the computations that I thought existed, I was under the impression that 82 bytes of COAP payload should fit. This is slightly disappointing. I copy here output of the payload that I generated: A2 # map(2) 18 19 # unsigned(25) # cnf label A1 # map(1) # cnf 01 # unsigned(1) # COSE_Key label A4 # map(4) # COSE_Key 01 # unsigned(1) # type label 04 # unsigned(4) # symmetric 20 # negative(0) # key value label 50 # bytes(16) # key value 6F92418A5CAA7C639255A1AF0C7B832C # "o\x92A\x8A\\\xAA|c\x92U\xA1\xAF\f{\x83," 06 # unsigned(6) # OSCORE sender id label 41 # bytes(1) # OSCORE sender id value 00 # "\x00" 07 # unsigned(7) # OSCORE recipient id label 41 # bytes(1) # OSCORE recipient id value 01 # "\x01" 13 # unsigned(19) # access_token 58 2F # bytes(47) 8340A106015828E72233134093261AB93634B3413BB46D1273AB98DBE95C4E7E332C754B348FBC70EC9C921133E8AE where the access token decodes to: 83 # array(3) # COSE_Encrypt0 40 # bytes(0) # protected bucket # "" A1 # map(1) # unprotected bucket 06 # unsigned(6) # PIV label 01 # unsigned(1) # PIV value 58 28 # bytes(40) # ciphertext E72233134093261AB93634B3413BB46D1273AB98DBE95C4E7E332C754B348FBC70EC9C921133E8AE where the corresponding plaintext is: A1 # map(1) 18 19 # unsigned(25) # cnf label A1 # map(1) # cnf 01 # unsigned(1) # COSE_Key label A4 # map(4) # COSE_Key 01 # unsigned(1) # type label 04 # unsigned(4) # symmetric 20 # negative(0) # key value label 50 # bytes(16) # key value 6F92418A5CAA7C639255A1AF0C7B832C # "o\x92A\x8A\\\xAA|c\x92U\xA1\xAF\f{\x83," 06 # unsigned(6) # OSCORE sender id label 41 # bytes(1) # OSCORE sender id value 00 # "\x00" 07 # unsigned(7) # OSCORE recipient id label 41 # bytes(1) # OSCORE recipient id value 01 # "\x01" To this, there is an additional tag of 8 bytes for AES-CCM-16-64-128 that was used. Some points where we could save bytes: - Does cnf label really need to fall into the 2-byte integers space? having the label encoded as a single integer would result in 2 bytes savings, since cnf is present twice [JLS] That seems to me to be a reasonable request – this is going to be a high frequency field. - To save bytes, could we not define a specific structure to carry OSCORE context params instead of COSE_Key? For example: [JLS] I was thinking that this would be a reasonable thing to do in terms of defining a new Confirmation method to carry this. It is not really a COSE_Key so putting it there seems to be an odd choice. Defining a new confirmation structure for this sounds like a good idea. Jim [ sender_id : bstr recipient_id : bstr master_secret : bstr ? ( master_salt : bstr / nil, id_context : bstr / nil), ? ( hkdf : uint, alg : uint ) ] In the use case from above with sender_id : h'00', recipient_id : h'01' and master_secret a random 16-byte string, this encodes to 22 bytes. COSE_Key carrying the same thing encodes to 27 bytes, resulting in 5 bytes savings per COSE_Key object, or total of 10 bytes saved in the payload from AS to C. - Can we not define some sort of a compressed structure using arrays in the OSCORE profile for the cnf claim? Or something like OSCORE's compression flag byte omitting some of these labels? With the current numbers, having a constrained client in OpenWSN simply does not work... Mališa
_______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
