Draft: draft-ietf-lake-edhoc

Commentary: Targeting 
 The structure of sections 2 , 3 and 4.1 - 4.2 is reflecting old versions of the protocol : New methods have been and the symmetric key authentication variant has been removed . Some examples of why this is needed : Section 4 is described as containing the asymmetric key authentication variant although the current protocol only supports asymmetric key authentication . There are two sections labelled as " overview " ( 3 and 4.1 ) with overlap in content and unclear division of content . Section 2 already contains an overview . Figure 3 in section 3 is not very helpful to explain the protocol components , replace with figure 4 from section 4 . A restructure is needed , some initial ideas : Keep section 2 largely as is but change title to " EDHOC outline " and mention other methods  section 3 " Protocol components " and move corresponding content here  section 4 " Messages formatting and processing " and focus on that 
 Great improvement in my opinion ( I am thinking from the point of view of implementers / new readers ) ! Thanks ! I have n't reviewed all the reference ( those that have not been modified in the message formatting sections ) to make sure they all point to the right thing . The changes I suggest can be done in the next update , I 'm ok with merging first .
Paragraph (version A):
EDHOC specifies different authentication methods of the Diffie-
Hellman key exchange: digital signatures and static Diffie-Hellman
keys.  This section outlines the digital signature based method.
Paragraph (version B):
EDHOC specifies different authentication methods of the Diffie-
Hellman key exchange: digital signatures and static Diffie-Hellman
keys.  This section outlines the digital signature based method.
Further details of protocol elements and other authentication methods
are provided in the remainder of this document.
Paragraph (version A):
To simplify for implementors, the use of CBOR in EDHOC is summarized
in CBORandCOSE and test vectors including CBOR diagnostic notation
are given in vectors.
Paragraph (version A):
EDHOC consists of three messages (message_1, message_2, message_3)
that maps directly to the three messages in SIGMA-I, plus an EDHOC
error message.  EDHOC messages are CBOR Sequences RFC8742, where the
first data item (METHOD_CORR) of message_1 is an int specifying the
method and the correlation properties of the transport used, see
transport.  The method specifies the authentication methods used
(signature, static DH), see method-types.  An implementation may
support only Initiator or Responder.  An implementation may support
only a single method.  The Initiator and the Responder need to have
agreed on a single method to be used for EDHOC.
Paragraph (version A):
While EDHOC uses the COSE_Key, COSE_Sign1, and COSE_Encrypt0
structures, only a subset of the parameters is included in the EDHOC
messages.  The unprotected COSE header in COSE_Sign1, and
COSE_Encrypt0 (not included in the EDHOC message) MAY contain
parameters (e.g. 'alg').  After creating EDHOC message_3, the
Initiator can derive symmetric application keys, and application
protected data can therefore be sent in parallel with EDHOC
message_3.  The application may protect data using the algorithms
(AEAD, hash, etc.) in the selected cipher suite and the connection
identifiers (C_I, C_R).  EDHOC may be used with the media type
application/edhoc defined in iana.
Paragraph (version A):
Cryptographically, EDHOC does not put requirements on the lower
layers.  EDHOC is not bound to a particular transport layer, and can
be used in environments without IP.  The transport is responsible to
handle message loss, reordering, message duplication, fragmentation,
and denial of service protection, where necessary.  The Initiator and
the Responder need to have agreed on a transport to be used for
EDHOC.  It is recommended to transport EDHOC in CoAP payloads, see
transfer.
Paragraph (version A):
EDHOC includes connection identifiers (C_I, C_R) to correlate
messages.  The connection identifiers C_I and C_R do not have any
cryptographic purpose in EDHOC.  They contain information
facilitating retrieval of the protocol state and may therefore be
very short.  The connection identifier MAY be used with an
application protocol (e.g.  OSCORE) for which EDHOC establishes keys,
in which case the connection identifiers SHALL adhere to the
requirements for that protocol.  Each party choses a connection
identifier it desires the other party to use in outgoing messages.
(For OSCORE this results in the endpoint selecting its Recipient ID,
see Section 3.1 of RFC8613).
Paragraph (version B):
To simplify for implementors, the use of CBOR and COSE in EDHOC is
summarized in CBORandCOSE and test vectors including CBOR diagnostic
notation are given in vectors.
Paragraph (version B):
EDHOC consists of three messages (message_1, message_2, message_3)
between Initiator and Responder, plus an EDHOC error message.  EDHOC
messages are CBOR Sequences RFC8742, see fig-flow.  The protocol
elements in the figure are introduced in the following sections.
Message formatting and processing is specified in asym and error.  An
implementation may support only Initiator or only Responder.
Paragraph (version B):
Application data is protected using the agreed application algorithms
(AEAD, hash) in the selected cipher suite (see cs) and the
application can make use of the established connection identifiers
C_I and C_R (see corr).  EDHOC may be used with the media type
application/edhoc defined in iana.
Paragraph (version B):
The Initiator can derive symmetric application keys after creating
EDHOC message_3, see exporter.  Application protected data can
therefore be sent in parallel with EDHOC message_3, optionally in the
same CoAP message I-D.palombini-core-oscore-edhoc.
Paragraph (version B):
The first data item of message_1, METHOD_CORR (see asym-msg1-form),
is an integer specifying the method and the correlation properties of
the transport, which are described in this section.
Paragraph (version B):
An implementation may support only a single method.  The Initiator
and the Responder need to have agreed on a single method to be used
for EDHOC, see applicability.
Paragraph (version B):
EDHOC includes connection identifiers (C_I, C_R) to correlate
messages.  The connection identifiers C_I and C_R do not have any
cryptographic purpose in EDHOC.  They contain information
facilitating retrieval of the protocol state and may therefore be
very short.  One byte connection identifiers are realistic in many
scenarios as most constrained devices only have a few connections.
In cases where a node only has one connection, the identifiers may
even be the empty byte string.
Paragraph (version B):
The connection identifier MAY be used with an application protocol
(e.g.  OSCORE) for which EDHOC establishes keys, in which case the
connection identifiers SHALL adhere to the requirements for that
protocol.  Each party choses a connection identifier it desires the
other party to use in outgoing messages.  (For OSCORE this results in
the endpoint selecting its Recipient ID, see Section 3.1 of RFC8613).
Paragraph (version B):
Cryptographically, EDHOC does not put requirements on the lower
layers.  EDHOC is not bound to a particular transport layer, and can
be used in environments without IP.  The transport is responsible to
handle message loss, reordering, message duplication, fragmentation,
and denial of service protection, where necessary.
Paragraph (version B):
The Initiator and the Responder need to have agreed on a transport to
be used for EDHOC, see applicability.  It is recommended to transport
EDHOC in CoAP payloads, see transfer.
Paragraph (version A):
The EDHOC message exchange may be authenticated using raw public keys
(RPK) or public key certificates.  The certificates and RPKs can
contain signature keys or static Diffie-Hellman keys.  In X.509
certificates, signature keys typically have key usage
"digitalSignature" and Diffie-Hellman keys typically have key usage
"keyAgreement".
Paragraph (version B):
Only the Responder SHALL have access to the Responder's private
authentication key.
Paragraph (version B):
Only the Initiator SHALL have access to the Initiator's private
authentication key.
Paragraph (version A):
authentication key and the subject name, see fig-sigma.  Before
running EDHOC, each endpoint needs a specific public
authentication key/unique associated subject name, or a set of
public authentication keys/unique associated subject names, which
it is allowed to communicate with.  EDHOC provides proof that the
other party possesses the private authentication key corresponding
to the public authentication key.
Paragraph (version B):
authentication key and the subject name, see auth-cred.  Before
running EDHOC, each endpoint needs a specific public
authentication key/unique associated subject name, or a set of
public authentication keys/unique associated subject names, which
it is allowed to communicate with.  EDHOC provides proof that the
other party possesses the private authentication key corresponding
to the public authentication key.
Paragraph (version A):
One byte connection and credential identifiers are realistic in many
scenarios as most constrained devices only have a few keys and
connections.  In cases where a node only has one connection or key,
the identifiers may even be the empty byte string.
Paragraph (version B):
The authentication credentials, CRED_I and CRED_R, contain the public
authentication key of the Initiator and the Responder, respectively.
The Initiator and the Responder MAY use different types of
credentials, e.g. one uses an RPK and the other uses a public key
certificate.
Paragraph (version B):
The credentials CRED_I and CRED_R are signed or MAC:ed (depending on
method) by the Initiator and the Responder, respectively, see m3 and
m2.
Paragraph (version B):
For COSE_Keys of type OKP the CBOR map SHALL only include the
parameters 1 (kty), -1 (crv), and -2 (x-coordinate).
Paragraph (version B):
For COSE_Keys of type EC2 the CBOR map SHALL only include the
parameters 1 (kty), -1 (crv), -2 (x-coordinate), and -3
(y-coordinate).
Paragraph (version B):
ID_CRED_I and ID_CRED_R are identifiers of the public authentication
keys of the Initiator and the Responder, respectively.  ID_CRED_I and
ID_CRED_R do not have any cryptographic purpose in EDHOC.
Paragraph (version B):
ID_CRED_R is intended to facilitate for the Initiator to retrieve
the Responder's public authentication key.
Paragraph (version B):
ID_CRED_I is intended to facilitate for the Responder to retrieve
the Initiator's public authentication key.
Paragraph (version B):
The identifiers ID_CRED_I and ID_CRED_R are COSE header_maps, i.e.
CBOR maps containing COSE Common Header Parameters, see Section 3.1
of RFC8152).  In the following we give some examples of COSE
header_maps.
Paragraph (version B):
ID_CRED_x MAY contain the actual credential used for authentication,
CRED_x.  It is RECOMMENDED that they uniquely identify the public
authentication key as the recipient may otherwise have to try several
keys.  ID_CRED_I and ID_CRED_R are transported in the ciphertext, see
m3 and m2.
Paragraph (version B):
When ID_CRED_x does not contain the actual credential it may be very
short.  One byte credential identifiers are realistic in many
scenarios as most constrained devices only have a few keys.  In cases
where a node only has one key, the identifier may even be the empty
byte string.
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.
Paragraph (version A):
The Initiator decides on the correlation parameter corr (see
transport).  This is typically given by the transport which the
Initiator and the Responder have agreed on beforehand.  The
Responder either accepts or rejects.
Paragraph (version A):
The Initiator decides on the method parameter, see method-types.
The Responder either accepts or rejects.
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 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
negotation.
Paragraph (version B):
The ECDH ephemeral public keys are formatted as a COSE_Key of type
EC2 or OKP according to Sections 13.1 and 13.2 of RFC8152, but only
the 'x' parameter is included G_X and G_Y.  For Elliptic Curve Keys
of type EC2, compact representation as per RFC6090 MAY be used also
in the COSE_Key.  If the COSE implementation requires an 'y'
parameter, any of the possible values of the y-coordinate can be
used, see Appendix C of RFC6090.  COSE RFC8152 always use compact
output for Elliptic Curve Keys of type EC2.
Paragraph (version A):
The ECDH ephemeral public keys are formatted as a COSE_Key of type
EC2 or OKP according to Sections 13.1 and 13.2 of RFC8152, but only
the 'x' parameter is included in the EDHOC messages.  For Elliptic
Curve Keys of type EC2, compact representation as per RFC6090 MAY be
used also in the COSE_Key.  If the COSE implementation requires an
'y' parameter, any of the possible values of the y-coordinate can be
used, see Appendix C of RFC6090.  COSE RFC8152 always use compact
output for Elliptic Curve Keys of type EC2.
Paragraph (version B):
The Initiator decides on the correlation parameter corr (see
corr).  This is typically given by the transport which the
Initiator and the Responder have agreed on beforehand.  The
Responder either accepts or rejects.
Paragraph (version B):
The Initiator decides on the method parameter, see fig-method-
types.  The Responder either accepts or rejects.
Paragraph (version B):
Editor's note: This section needs to be aligned with applicability.
Paragraph (version A):
Only the Responder SHALL have access to the Responder's private
authentication key,
Paragraph (version A):
Only the Initiator SHALL have access to the Initiator's private
authentication key,
Paragraph (version A):
The Initiator is able to retrieve the Responder's public
authentication key using ID_CRED_R,
Paragraph (version A):
The Responder is able to retrieve the Initiator's public
authentication key using ID_CRED_I,
Paragraph (version A):
where ID_CRED_I and ID_CRED_R are the identifiers of the public
authentication keys.  Their encoding is specified in id_cred.
Paragraph (version A):
The identifiers ID_CRED_I and ID_CRED_R are COSE header_maps, i.e.
CBOR maps containing COSE Common Header Parameters, see Section 3.1
of RFC8152).  ID_CRED_I and ID_CRED_R need to contain parameters that
can identify a public authentication key.  In the following paragraph
we give some examples of possible COSE header parameters used.
Paragraph (version A):
The purpose of ID_CRED_I and ID_CRED_R is to facilitate retrieval of
a public authentication key and when they do not contain the actual
credential, they may be very short.  ID_CRED_I and ID_CRED_R MAY
contain the actual credential used for authentication.  It is
RECOMMENDED that they uniquely identify the public authentication key
as the recipient may otherwise have to try several keys.  ID_CRED_I
and ID_CRED_R are transported in the ciphertext, see asym-msg2-proc
and asym-msg3-proc.
Paragraph (version B):
This section specifies formatting of the messages and processing
steps.  Error messages are specified in error.
Paragraph (version B):
An EDHOC message is encoded as a sequence of CBOR data (CBOR
Sequence, RFC8742).  Additional optimizations are made to reduce
message overhead.
Paragraph (version B):
While EDHOC uses the COSE_Key, COSE_Sign1, and COSE_Encrypt0
structures, only a subset of the parameters is included in the EDHOC
messages.  The unprotected COSE header in COSE_Sign1, and
COSE_Encrypt0 (not included in the EDHOC message) MAY contain
parameters (e.g. 'alg').
Paragraph (version A):
METHOD_CORR = 4 * method + corr, where method = 0, 1, 2, or 3 (see
method-types) and the correlation parameter corr is chosen based
on the transport and determines which connection identifiers that
are omitted (see transport).
Paragraph (version B):
METHOD_CORR = 4 * method + corr, where method = 0, 1, 2, or 3 (see
fig-method-types) and the correlation parameter corr is chosen
based on the transport and determines which connection identifiers
that are omitted (see corr).
Paragraph (version B):
IANA has created a new registry titled "EDHOC Method Type" under the
new heading "EDHOC".  The registration procedure is "Expert Review".
The columns of the registry are Value, Description, and Reference,
where Value is an integer and the other columns are text strings.
The initial contents of the registry is shown in fig-method-types.