[Secdispatch] FW: EDHOC and Transports

[Jim Schaad <[e-mail]>]

Send it to the right mailing list.

-----Original Message-----
From: Jim Schaad <[e-mail]> 
Sent: Thursday, January 24, 2019 9:08 PM
To: '[e-mail]' <[e-mail]>
Subject: EDHOC and Transports

Someplace over the set of messages which I recently scanned one of the
questions was what were the constrained restrictions that we were looking at
as part of the evaluation process.

There are three that I will highlight even though I am only able to provide
any type of quantification for two of them:

1.  Low-power devices that either are battery based or scavenge power, these
devices pay a power penalty for every byte of data sent and thus have a
desire for the smallest messages possible.

2. CoAP over SMS:  SMS has a 140 byte packet size.  There are two approaches
for dealing with packets of larger than 140 bytes:  1) There is a method of
appending multiple packets together to form a single larger packet.  2) You
can use CoAP blockwise transfer.  Using CoAP blockwise would result in 128
byte packets for the underlying transfer assuming that only 12 bytes are
needed for the CoAP header itself.

3. 6LoPan over IEEE 802.15.4:  This has a packet size of 127 bytes.  The
maximum frame overhead size is 25 bytes allowing for 102 bytes of message
space.   If one assumes 20 bytes of overhead for CoAP then this means a
protocol packet size of 82 bytes.  If one needs to break the message across
multiple packets then the maximum data size is going to be 64 bytes using
CoAP blockwise options.

There are of course two additional transports which are to be considered
IPV4 UDP and IPV6 UDP.  Both of these transports have a packet size which is
sufficiently large to hold a any given message using TLS or EDHOC.

Jim