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

From: Mališa Vučinić <[email-masked]>
Date: Sun, 15 Jul 2018 23:43:59 +0200

Hi Ludwig, all,

I am in the process of implementing draft-ietf-ace-oscore-profile-02 for
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

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.

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

-  To save bytes, could we not define a specific structure to carry OSCORE
context params instead of COSE_Key?  For example:

[
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

---

From: Jim Schaad <[email-masked]>
Date: Mon, 16 Jul 2018 12:30:36 -0400

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

- 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.

- Sending single byte for PIV in COSE Encrypt0 of CWT, the actual AEAD nonce is PIV prepended with zeros

[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.

A2                                      # map(2)

   A1                                   # map(1)          # cnf   

      A4                                # map(4)           # COSE_Key

            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"

   58 2F                              # bytes(47)     

                                        # ""

A1                                      # map(1)

   A1                                   # map(1)  # cnf

      A4                                # map(4) # COSE_Key

            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.

- 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

? ( 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