Draft: draft-ietf-lake-edhoc

Commentary: Addresses 
 Q1 : The document talks about the Initiator and Responder roles , what messages they send etc . But I ca n't find a definition of what the roles . I assume the Initiator initiates something , but unless I have missed it it would be good to have a few word of role definitions . 
 Yes , we will add that 
 Closing this as PR is merged .
Mailing list commentary: Reviewer : Review result : Almost Ready I am the assigned Gen - ART reviewer for this draft . The General Area Review Team ( Gen - ART ) reviews all IETF documents being processed by the IESG for the IETF Chair . Please treat these comments just like any other last call comments . For more information , please see the FAQ at . Document : draft - ietf - lake - edhoc-18 Reviewer : Review Date : 2022 - 12 - 20 IETF LC End Date : None IESG Telechat date : Not scheduled for a telechat Summary : The document is well written , and easy to read . I do have one minor issue that I would like the authors to address . Major issues : N / A Minor issues : Q1 : The document talks about the Initiator and Responder roles , what messages they send etc . But I ca n't find a definition of what the roles . I assume the Initiator initiates something , but unless I have missed it it would be good to have a few word of role definitions . Nits / editorial comments : N / A
Paragraph (version A):
SIGMA (SIGn-and-MAc) is a family of theoretical protocols with a
large number of variants SIGMA.  Like in IKEv2 RFC7296 and (D)TLS 1.3
RFC9147, EDHOC authenticated with signature keys is built on a
variant of the SIGMA protocol which provides identity protection of
the Initiator (SIGMA-I) against active attackers, and like IKEv2,
EDHOC implements the MAC-then-Sign variant of the SIGMA-I protocol
shown in fig-sigma.
Paragraph (version A):
The parties exchanging messages in an EDHOC session are called
Initiator (I) and Responder (R).  They exchange ephemeral public
keys, compute a shared secret session key PRK_out, and derive
symmetric application keys used to protect application data.
Paragraph (version B):
SIGMA (SIGn-and-MAc) is a family of theoretical protocols with a
large number of variants SIGMA.  Like in IKEv2 RFC7296 and (D)TLS 1.3
RFC9147, EDHOC authenticated with signature keys is built on a
variant of the SIGMA protocol, SIGMA-I, which provides identity
protection against active attacks on the party initiating the
protocol.  Also like IKEv2, EDHOC implements the MAC-then-Sign
variant of the SIGMA-I protocol shown in fig-sigma.
Paragraph (version B):
The parties exchanging messages in an EDHOC session are called
Initiator (I) and Responder (R), where the Initiator sends message_1
(see overview).  They exchange ephemeral public keys, compute a
shared secret session key PRK_out, and derive symmetric application
keys used to protect application data.
Paragraph (version A):
The EDHOC protocol consists of three mandatory messages (message_1,
message_2, message_3) between an Initiator and a Responder, an
optional fourth message (message_4), and an error message.  The roles
have slightly different security properties which should be
considered when the roles are assigned, see sec-prop.  All EDHOC
messages are CBOR Sequences RFC8742, and are deterministically
encoded. fig-flow illustrates an EDHOC message flow with the optional
fourth message as well as the content of each message.  The protocol
elements in the figure are introduced in overview and asym.  Message
formatting and processing are specified in asym and error.
Paragraph (version B):
The EDHOC protocol consists of three mandatory messages (message_1,
message_2, message_3), an optional fourth message (message_4), and an
error message, between an Initiator (I) and a Responder (R).  The odd
messages are sent by I, the even by R.  Both I and R can send error
messages.  The roles have slightly different security properties
which should be considered when the roles are assigned, see sec-prop.
All EDHOC messages are CBOR Sequences RFC8742, and are
deterministically encoded. fig-flow illustrates an EDHOC message flow
with the optional fourth message as well as the content of each
message.  The protocol elements in the figure are introduced in
overview and asym.  Message formatting and processing are specified
in asym and error.