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

[Mališa Vučinić <[e-mail]>]

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