Re: [Ace] Message overhead of the OSCORE profile and ACE specs

[Jim Schaad <[e-mail]>]

 

 

From: Ace <[e-mail]> On Behalf Of Mališa Vucinic
Sent: Sunday, July 15, 2018 5:44 PM
To: [e-mail]
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