Draft: draft-ietf-lake-edhoc

Commentary: Addressing 
 Please check if your comments are addressed . 
 Yes , especially in [ 1 ] . Thanks ! [ 1 ] 
 -08 contained a definition of CREDx including an example when kid is used . -09 removed that example and replaces it with a RPK by value example . Now it seems like the most important use case is not well specified . This is the use case that leads to message2 being 45 bytes . 
 In addition the TOFU use case should likely also have a kid . Otherwise the UCCS has to be sent by value every time . 
 This is solved by just adding a ' kid ' in the COSE_Key map 
 The document should say someting more about COSEKey . If IDCREDx = { 4 : keyidx } identifies a raw COSEKey , is that an error or is CREDx then the COSEKey wrapped in a UCCS without any parameters like sub ? 
 SUITES_R is a name . The type needs to be defined and the table changed . This can be done in PR 
 The current definition of SUITESI is that the Initiator can chose any truncation of the list of supported cipher suites as long as the selected cipher suite is included . This works and allows the Initiator to give the Responder information about the full list . This is however a bit complex and has led to misunderstandings of the test vectors where several people thought the test vectors were wrong . i.e. the following are all valid I think we should simplify  by mandating that the last suite in the list is the selected . This makes SUITESI much easier to understand and lowers message size when an array is used . Giving the Responder info is not so important . CDDL 
 Maybe a recommendation that SUITES_R SHOULD contain all cipher suites that R supports . 
 Currently SUITESR : [ supported : 2 suite ] / suite We may keep that , or remove " supported " SUITESR : [ 2 suite ] / suite Alternatively , we may define SUITES_I : [ supported : 2 * suite ] / suite Any preference ? 
 They should be the same : or And then 
 This needs to be defined as a CDDL type . suites = [ 2 * suite ] / suite See
Paragraph (version B):
The Initiator lists supported cipher suites in order of
preference, ending with the selected cipher suite for the
session.
Paragraph (version A):
The Initiator needs to have a list of cipher suites it supports in
order of preference.  The Responder needs to have a list of cipher
suites it supports.  SUITES_I is a CBOR array containing cipher
suites that the Initiator supports.  SUITES_I is formatted and
processed as detailed in asym-msg1-form to secure the cipher suite
negotiation.  Examples of cipher suite negotiation are given in ex-
neg.
Paragraph (version B):
The Initiator needs to have a list of cipher suites it supports in
order of preference.  The Responder needs to have a list of cipher
suites it supports.  SUITES_I contains cipher suites supported by the
Initiator, formatted and processed as detailed in asym-msg1-form to
secure the cipher suite negotiation.  Examples of cipher suite
negotiation are given in ex-neg.
Paragraph (version A):
The applicability statement may also contain information about
supported cipher suites.  The procedure for selecting and verifying
cipher suite is still performed as specified by the protocol, but it
may become simplified by this knowledge.
Paragraph (version B):
The applicability statement may also contain information about
supported cipher suites.  The procedure for selecting and verifying
cipher suite is still performed as described in asym-msg1-form and
wrong-selected, but it may become simplified by this knowledge.
Paragraph (version A):
SUITES_I - cipher suites which the Initiator supports in order of
(decreasing) preference.  The list of supported cipher suites can
be truncated at the end, as is detailed in the processing steps
below and wrong-selected.  One of the supported cipher suites is
selected.  The selected suite is the first suite in the SUITES_I
CBOR array.  If a single supported cipher suite is conveyed, then
that cipher suite is selected and SUITES_I is encoded as an int
instead of an array.
Paragraph (version B):
SUITES_I - array of cipher suites which the Initiator supports in
order of preference, starting with the most preferred and ending
with the cipher suite selected for this session.  If the most
preferred cipher suite is selected then SUITES_I is encoded as
that cipher suite, i.e. as an int.  The processing steps are
detailed below and in wrong-selected.
Paragraph (version A):
The supported cipher suites and the order of preference MUST NOT
be changed based on previous error messages.  However, the list
SUITES_I sent to the Responder MAY be truncated such that cipher
suites which are the least preferred are omitted.  The amount of
truncation MAY be changed between sessions, e.g., based on
previous error messages (see next bullet), but all cipher suites
which are more preferred than the least preferred cipher suite in
the list MUST be included in the list.
Paragraph (version A):
The Initiator MUST select its most preferred cipher suite,
conditioned on what it can assume to be supported by the
Responder.  If the Initiator previously received from the
Responder an error message with error code 2 (see wrong-selected)
indicating cipher suites supported by the Responder which also are
supported by the Initiator, then the Initiator SHOULD select the
most preferred cipher suite of those (note that error messages are
not authenticated and may be forged).
Paragraph (version B):
The supported cipher suites and the order of preference MUST NOT
be changed based on previous error messages.  SUITES_I contains
the ordered list of supported cipher suites, truncated after the
cipher suite selected for this session.  The selected cipher suite
MAY be changed between sessions, e.g., based on previous error
messages (see next bullet), but all cipher suites which are more
preferred than the selected cipher suite in the list MUST be
included in SUITES_I.
Paragraph (version B):
The Initiator MUST select its most preferred cipher suite,
conditioned on what it can assume to be supported by the
Responder.  If the Initiator previously received from the
Responder an error message with error code 2 (see wrong-selected)
indicating cipher suites supported by the Responder, then the
Initiator SHOULD select the most preferred supported cipher suite
among those (note that error messages are not authenticated and
may be forged).
Paragraph (version A):
If the Responder does not support the selected cipher suite, then
SUITES_R MUST include one or more supported cipher suites.  If the
Responder does not support the selected cipher suite, but supports
another cipher suite in SUITES_I, then SUITES_R MUST include the
first supported cipher suite in SUITES_I.
Paragraph (version A):
After receiving SUITES_R, the Initiator can determine which cipher
suite to select for the next EDHOC session with the Responder.
Paragraph (version A):
If the Initiator intends to contact the Responder in the future, the
Initiator SHOULD remember which selected cipher suite to use until
the next message_1 has been sent, otherwise the Initiator and
Responder will likely run into an infinite loop.  After a successful
run of EDHOC, the Initiator MAY remember the selected cipher suite to
use in future EDHOC sessions.  Note that if the Initiator or
Responder is updated with new cipher suite policies, any cached
information may be outdated.
Paragraph (version A):
Assume that the Initiator supports the five cipher suites 5, 6, 7, 8,
and 9 in decreasing order of preference.  Figures fig-error1 and fig-
error2 show examples of how the Initiator can truncate SUITES_I and
how SUITES_R is used by Responders to give the Initiator information
about the cipher suites that the Responder supports.
Paragraph (version B):
Error code 2 MUST only be used in a response to message_1 in case the
cipher suite selected by the Initiator is not supported by the
Responder, or if the Responder supports a cipher suite more preferred
by the Initiator than the selected cipher suite, see resp-proc-msg1.
ERR_INFO is in this case denoted SUITES_R and is of type suites, see
asym-msg1-form).  If the Responder does not support the selected
cipher suite, then SUITES_R MUST include one or more supported cipher
suites.  If the Responder supports a cipher suite in SUITES_I other
than the selected cipher suite (independently of if the selected
cipher suite is supported or not) then SUITES_R MUST include the
supported cipher suite in SUITES_I which is most preferred by the
Initiator.  SUITES_R MAY include a single cipher suite, i.e. be
encoded as an int.  If the Responder does not support any cipher
suite in SUITES_I, then it SHOULD include all its supported cipher
suites in SUITES_R in any order.
Paragraph (version B):
After receiving SUITES_R, the Initiator can determine which cipher
suite to select (if any) for the next EDHOC run with the Responder.
Paragraph (version B):
If the Initiator intends to contact the Responder in the future, the
Initiator SHOULD remember which selected cipher suite to use until
the next message_1 has been sent, otherwise the Initiator and
Responder will likely run into an infinite loop where the Initiator
selects its most preferred and the Responder sends an error with
supported cipher suites.  After a successful run of EDHOC, the
Initiator MAY remember the selected cipher suite to use in future
EDHOC sessions.  Note that if the Initiator or Responder is updated
with new cipher suite policies, any cached information may be
outdated.
Paragraph (version B):
Assume that the Initiator supports the five cipher suites 5, 6, 7, 8,
and 9 in decreasing order of preference.  Figures fig-error1 and fig-
error2 show examples of how the Initiator can format SUITES_I and how
SUITES_R is used by Responders to give the Initiator information
about the cipher suites that the Responder supports.