Draft: draft-ietf-lake-edhoc

Commentary: Updates and consequential changes following comments by Loïc .
Paragraph (version A):
Connection identifiers in EDHOC are CBOR byte strings.  Since most
constrained devices only have a few connections, short identifiers
are desirable in many cases.  However, except for the empty byte
string h'', which encodes as one byte (0x40), all byte strings are
CBOR encoded as two or more bytes.  Therefore EDHOC specifies certain
byte strings to be represented as CBOR ints on the wire, see bstr-
repr.
Paragraph (version B):
Connection identifiers in EDHOC are intrinsically byte strings.  Most
constrained devices only have a few connections for which short
identifiers may be sufficient.  In some cases minimum length
identifiers are necessary to comply with overhead requirements.
However, CBOR byte strings - with the exception of the empty byte
string h'' which encodes as one byte (0x40) - are encoded as two or
more bytes.  To enable one-byte encoding of certain byte strings
while maintaining CBOR encoding, EDHOC represents certain byte string
identifiers as CBOR ints on the wire, see bstr-repr.
Paragraph (version A):
For example, a C_I equal to 0xFF is converted to a (typically client)
Responder ID equal to 0xFF; a C_R equal to 0x21 is converted to a
(typically server) Responder ID equal to 0x21.  Note that the
representation of connection identifiers as CBOR byte strings or CBOR
ints in EDHOC messages as described in bstr-repr has no impact on
this mapping.
Paragraph (version B):
Examples: * A connection identifier 0xFF (represented in the EDHOC
message as the CBOR byte string 0x41FF, see bstr-repr) is converted
to the OSCORE Recipient ID 0xFF * A connection identifier 0x21
(represented in the EDHOC message as the CBOR int 0x21, see bstr-
repr) is converted to the OSCORE Recipient ID 0x21.
Paragraph (version A):
fig-edhoc-kdf lists derivations made with EDHOC-KDF during message
processing.  How the output keying material is used is specified in
asym.
Paragraph (version B):
Further details of the key derivation and how the output keying
material is used is specified in asym.
Paragraph (version A):
If the Responder authenticates with a static Diffie-Hellman key
(method equals 1 or 3), then mac_length_2 is the EDHOC MAC
length given by the selected cipher suite.  If the Responder
authenticates with a signature key (method equals 0 or 2), then
mac_length_2 is equal to the output size of the EDHOC hash
algorithm given by the selected cipher suite.
Paragraph (version B):
If the Responder authenticates with a static Diffie-Hellman key
(method equals 1 or 3), then mac_length_2 is the EDHOC MAC
length of the selected cipher suite.  If the Responder
authenticates with a signature key (method equals 0 or 2), then
mac_length_2 is equal to the output size of the EDHOC hash
algorithm of the selected cipher suite.
Paragraph (version A):
If the Initiator authenticates with a static Diffie-Hellman key
(method equals 2 or 3), then mac_length_3 is the EDHOC MAC
length given by the selected cipher suite.  If the Initiator
authenticates with a signature key (method equals 0 or 1), then
mac_length_3 is equal to the output size of the EDHOC hash
algorithm given by the selected cipher suite.
Paragraph (version B):
If the Initiator authenticates with a static Diffie-Hellman key
(method equals 2 or 3), then mac_length_3 is the EDHOC MAC
length of the selected cipher suite.  If the Initiator
authenticates with a signature key (method equals 0 or 1), then
mac_length_3 is equal to the output size of the EDHOC hash
algorithm of the selected cipher suite.
Paragraph (version A):
PAD = 1*true is padding that may be used to hide the length
of the unpadded plaintext.
Paragraph (version B):
PAD = 1* "true" (see CBOR) is padding that may be used to
hide the length of the unpadded plaintext.
Paragraph (version A):
Note that HKDF-Expand has a relatively small maximum output length of
255 * hash_length.  This means that when SHA-256 is used as hash
algorithm, message_2 cannot be longer than 8160 bytes.
Paragraph (version B):
Note that HKDF-Expand has a relatively small maximum output length of
255 * hash_length, where hash_length is the output size in bytes of
the EDHOC hash algorithm of the selected cipher suite.  This means
that when when SHA-256 is used as hash algorithm, message_2 cannot be
longer than 8160 bytes.