Re: [Iotops] Group OSCORE message sizes in -iotops-security-protocol-comparison

[Marco Tiloca <[e-mail]>]

Hi John,

On 2023-04-07 17:05, John Mattsson wrote:
> Marco wrote: >Then you would have a overhead triple (11, 11, 11), i.e. 
> the Sender ID size does not play a role in theresponse overhead.
>
> Thanks Marco, fixed in -01
>

==>MT
Thanks!
<==

>
> Are the following values for I-D.ietf-core-oscore-edhoc correct?
> “EDHOC is typically sent over CoAP which would add 4 bytes to flight 
> #1 and #2 and 5 or 20 bytes to flight #3 depending on if OSCORE is 
> used [I-D.ietf-core-oscore-edhoc].”
>

==>MT
I think this can be expanded as follows.

You are assuming that:
- The CoAP token has a length of 0 bytes
- The CoAP Content-Format is not specified in the EDHOC messages
- EDHOC is run with the forward message flow

We should also assume that:
- The used connection identifiers (at least C_R) is one of the 49 
identifiers whose encoding on the wire is 1 byte in size
- The URI Path of the EDHOC resource at the CoAP server is, e.g., 
"edhoc". This admittedly deviates from the most expected 
".well-known/edhoc" but it still gives an (adjustable) fair idea.

That said, the following should be the additional overhead due to CoAP 
used as transport.

* For EDHOC message_1

--- CoAP header: 4 bytes
--- CoAP token: 0 bytes
--- URI-Path option with value "edhoc": 6 bytes
--- Payload marker 0xff: 1 byte
--- Dummy connection identifier "true": 1 byte

Total: 12 bytes


* For EDHOC message_2

--- CoAP header: 4 bytes
--- CoAP token: 0 bytes
--- Payload marker 0xff: 1 byte

Total: 5 bytes


* For EDHOC message_3 without the combined request

--- CoAP header: 4 bytes
--- CoAP token: 0 bytes
--- URI-Path option with value "edhoc": 6 bytes
--- Payload marker 0xff: 1 byte
--- Connection identifier C_R (wire encoding): 1 byte

Total: 12 bytes


* For EDHOC message_3 without the EDHOC + OSCORE combined request

All the overhead contributions from the previous case is gone. That is:

--- There is no message transporting only EDHOC message_3 anymore. You 
just take advantage of what the EDHOC + OSCORE combined request does. 
This removes the CoAP header, CoAP token, URI-Path option and payload 
marker counted above when EDHOC message_3 is sent as a separate message.
--- You also lose the connection identifier C_R, since this is anyway 
already specified in the 'kid' of the OSCORE option of the combined request.

However, you do have the 1-byte overhead due to the EDHOC option in the 
EDHOC + OSCORE combined request.

Hence, the total overhead due to CoAP transporting EDHOC message_3 when 
using the EDHOC + OSCORE combined request is 1 byte.
<==


==>MT
Also, please replace the reference to draft-tiloca-lpwan-8824-update 
with a reference to draft-tiloca-schc-8824-update, as recently resubmitted.

Best,
/Marco
<==

>
> Cheers,
>
> John
>
>

-- 
Marco Tiloca
Ph.D., Senior Researcher

Phone: [phone]

RISE Research Institutes of Sweden AB
Box 1263
164 29 Kista (Sweden)

Division: Digital Systems
Department: Computer Science
Unit: Cybersecurity

https://www.ri.se