Draft: draft-ietf-lake-edhoc

Commentary: Addressing 
 Opening a PR with one commit as placeholder , more updates to follow . 
 I tried to clarify normative text in Appendix A , which led to a refactoring of section A.2 . Please comment on if this is going in the right direction . 
  's note : Remains to write about flow control . 
 Are you happy with the latest changes ? ( Plan to merge soon ) 
 Looks good to me , thanks ! 
 provided some comments based on PR . The specification was already before quite open for various means to provide correlation . This may lead to interoperability problems even in the case of using EDHOC over CoAP ( it did in one of the recent interop tests , where one party was not using prepended identifiers ) . If we are now reworking this text we should try to fix this . Correlation may be provided without the use of transport ( which was the reason why prepended identifiers was not used ) . This should be mentioned . So on the one hand , the specification is limiting the description to the case when transport provides correlation , on the other hand is it a bit loose on how to achieve correlation even over CoAP , leading to interoperability problems . It is proposed to use a formulation like " Unless correlation is provided by other means " then SHOULD use < a well - defined way of getting correlation . The only candidate for well - defined way is prepended identifiers . Formulations like this : “ Prepended identifiers MAY be omitted in case the transport provides such correlation . ” should be omitted since it could be a problem in case of proxying between TCP and UDP . Text referring to “ the integer representation ” should be rephrased , since it is a representation of identifiers which sometimes may be represented as integers . A sanity check of the processing steps in the new forward / reverse message flow sections showed one missing case when error message can be sent . When working with the changes I realized some other quirks : Throughout the draft , references about correlation are made to appendix A.2 ( EDHOC over CoAP ) instead of section 3.4.1 which contains the general description . I think it is better to reference the section in the body ( which includes a reference to the appendix ) Section 3.4.1 is not only about connection identifiers so the title is misleading . Change from " Use of Connection Identifiers for EDHOC Message Correlation " to " EDHOC Message Correlation " After making these updates , the text in Appendix H becomes essentially redundant and can be removed and the remnants distributed over 3.4.1 and A.2 . 
 A proposal included in PR : 
 Closing this as is merged . 
 Nits in Section 3.4 : The wording " In addition to the transport of messages including errors " does not explain whether ( bit ) errors in messages need to be handled in the underlying transport . If the protocol assumes error - free transport of messages , a better wording would be " In addition to reliable transport of messages without errors " , or the like . " Flow control " is not listed as requirement in Section 3.4 . That could be a bug or a feature . Yet , as the protocol targets devices with low memory that may run out of buffer space , it may make sense to be explicit whether flow control is needed to deal with scarce memory . If not , it would make sense to explain how an implementation running out of send / receive buffer space would deal with that . While the document stresses in various places that the message sizes are small , and example values are also included , neither a required minimum nor a worst - case maximum is mentioned . As the underlying transport has to support fragmentation , a definition may not be required . Yet , if min /  numbers can be derived , it could be useful to better explain them in Section 3.4 in order to illustrate the requirements on the underlying transport . If min /  numbers can not be derived , a corresponding heads - up could be instead to emphasize that the transport protocol needs to support arbitrarily large messages . Nits in Appendix A : It is not fully clear whether the content of Appendix A , or subsets thereof , are normative requirements for an implementation . This in particular applies to the RFC2119 / RFC8174 language . The relationship between Appendix A and draft - ietf - core - oscore - edhoc is quite hard to understand . 
 error - free . EDHOC does not require error free . EDHOC will detect errors but it might be detected later in the message flow . We will add some considerations . We will think about what to write about flow controlA min number can be derived . We will add min numbers and some considerations on large messages . We agree with the Nits . We will improve this .
Mailing list commentary: Reviewer : Review result : Ready with Nits This document has been reviewed as part of the transport area review team 's ongoing effort to review key IETF documents . These comments were written primarily for the transport area directors , but are copied to the document 's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information . When done at the time of IETF Last Call , the authors should consider this review as part of the last - call comments they receive . Please always CC tsv- if you reply to or forward this review . This document basically specifies an application protocol that is by - and - large independent of an underlying reliable transport protocol . As such , there are no apparent transport issues in the protocol design itself . Transport protocol issues are in particular discussed in Section 3.4 and In both there are some small nits . Nits in Section 3.4 : The wording " In addition to the transport of messages including errors " does not explain whether ( bit ) errors in messages need to be handled in the underlying transport . If the protocol assumes error - free transport of messages , a better wording would be " In addition to reliable transport of messages without errors " , or the like . " Flow control " is not listed as requirement in Section 3.4 . That could be a bug or a feature . Yet , as the protocol targets devices with low memory that may run out of buffer space , it may make sense to be explicit whether flow control is needed to deal with scarce memory . If not , it would make sense to explain how an implementation running out of send / receive buffer space would deal with that . While the document stresses in various places that the message sizes are small , and example values are also included , neither a required minimum nor a worst - case maximum is mentioned . As the underlying transport has to support fragmentation , a definition may not be required . Yet , if min / numbers can be derived , it could be useful to better explain them in Section 3.4 in order to illustrate the requirements on the underlying transport . If min / numbers can not be derived , a corresponding heads - up could be instead to emphasize that the transport protocol needs to support arbitrarily large messages . Nits in Appendix A : It is not fully clear whether the content of Appendix A , or subsets thereof , are normative requirements for an implementation . This in particular applies to the RFC2119 / RFC8174 language . The relationship between Appendix A and draft - ietf - core - oscore - edhoc is quite hard to understand .
Paragraph (version A):
message correlation.
Paragraph (version A):
The use of transport is specified in the application profile
applicability.
Paragraph (version A):
The transport needs to support the correlation between EDHOC messages
and facilitate the retrieval of protocol state and security context
during an EDHOC session, including an indication of a message being
message_1.  The correlation may reuse existing mechanisms in the
transport protocol.  For example, the CoAP Token may be used to
correlate EDHOC messages in a CoAP response and an associated CoAP
request.
Paragraph (version A):
Connection identifiers may be used to correlate EDHOC messages and
facilitate the retrieval of protocol state/security context during an
EDHOC session.  Transports that do not inherently provide correlation
across all messages of an EDHOC session can send connection
identifiers along with EDHOC messages to gain that required
capability, e.g., by prepending the appropriate connection identifier
(when available from the EDHOC protocol) to the EDHOC message.
Transport of EDHOC in CoAP payloads is described in coap, which also
shows how to use connection identifiers and message_1 indication with
CoAP.
Paragraph (version B):
flow control,
Paragraph (version B):
message correlation, see ci-edhoc.
Paragraph (version B):
EDHOC does not require error free transport since a change in message
content is detected through the transcript hashes in a subsequent
integrity verification, see asym.
Paragraph (version B):
EDHOC is designed to enable an authenticated key exchange with small
messages, where the minimum message sizes are of the order
illustrated in the first column of fig-sizes.  There is no maximum
message size specified by the protocol; this is for example dependent
on the size of authentication credentials (if they are transported,
see auth-key-id).
Paragraph (version B):
The use of transport is specified in the application profile, which
in particular may specify limitations in message sizes, see
applicability.
Paragraph (version B):
Correlation between EDHOC messages is needed to facilitate the
retrieval of protocol state and security context during an EDHOC
session.  It is also helpful for the Responder to get an indication
that a received EDHOC message is the beginning of a new session, such
that no existing protocol state or security context needs to be
retrieved.
Paragraph (version B):
Correlation may be based on existing mechanisms in the transport
protocol, for example, the CoAP Token may be used to correlate EDHOC
messages in a CoAP response and in an associated CoAP request.  The
connection identifiers may also be used to correlate EDHOC messages.
Paragraph (version B):
If correlation between consecutive messages is not provided by other
means then the transport binding SHOULD mandate prepending of an
appropriate connection identifier (when available from the EDHOC
protocol) to the EDHOC message.  If message_1 indication is not
provided by other means, then the transport binding SHOULD mandate
prepending of message_1 with the CBOR simple value "true" (0xf5), as
a unique dummy identifier.
Paragraph (version B):
Transport of EDHOC in CoAP payloads is described in coap, including
how to use connection identifiers and message_1 indication with CoAP.
A similar construction is possible for other client-server protocols.
Protocols that do not provide any correlation at all can prescribe
prepending of the peer's connection identifier to all messages.
Paragraph (version B):
Note that correlation between EDHOC messages may be obtained without
transport support or connection identifiers, for example if the
endpoints only accept a single instance of the protocol at a time,
and execute conditionally on a correct sequence of messages.
Paragraph (version A):
Retrieve the protocol state according to the message correlation
provided by the transport, see transport.  If there is no protocol
state, in the case of message_1, a new protocol state is created.
The Responder endpoint needs to make use of available Denial-of-
Service mitigation (dos).
Paragraph (version B):
Retrieve the protocol state according to the message correlation,
see ci-edhoc.  If there is no protocol state, in the case of
message_1, a new protocol state is created.  The Responder
endpoint needs to make use of available Denial-of-Service
mitigation (dos).
Paragraph (version A):
Retrieve the protocol state using the message correlation provided
by the transport (e.g., the CoAP Token, the 5-tuple, or the
prepended C_R, see coap).
Paragraph (version B):
Retrieve the protocol state using available message correlation
(e.g., the CoAP Token, the 5-tuple, or the prepended C_R, see ci-
edhoc).