Draft: draft-ietf-lake-edhoc

Commentary: Looks good . 
 The current draft has the following text in several places : " If any verification step fails , the Responder  send an EDHOC error message back , formatted as defined in { { error } } , and the protocol MUST be discontinued . " I am not sure this is a good idea . This means that the availability of EDHOC will be low . An attacker can e.g. send a single byte as message_4 and it would make EDHOC shut down imidiatly . I think we need to soften this and give the implementation some more choice here . Are there constrained radio protocols where noice could be mistaken for an actual message and forwarded to EDHOC or do all constrained radio have strong enough CRC to make sure that that more or less never happens ? 
 I just changed the following text OLD : If the Initiator previously received from the Responder an error message with error code 1 ( see Section 6.3 ) indicating cipher suites supported by the Responder which also are supported by the Initiator , then the Initiator SHALL select the most preferred cipher suite of those . NEW : If the Initiator previously received from the Responder an error message with error code 1 ( see Section 6.3 ) 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 ) . Made me think about that I do n't think the group has discussed if some error messages should be authenticated . Some error messages to message2 could include a MAC to prove that the error was sent by the same party that sent message3 . error messages to message3 and  could be authenticated . I am uncertain if this is worth specifying . At least not as long as there are easier ways to an attacker to end the protocol . I think what needs to be done is to specify that a processing error does not need to discontinue the protocol , the received message can have been an attack . receiveing an error does not need to discontinue the protocol , the received error can have been an attack . 
 from interim : CB perhaps wisely said : " Use cases exist for multiplexing over same port / URI , so applications should normally sort / demultiplex traffic before start interpreting as EDHOC , which implies treating invalid messages that get to EDHOC code as an error or attack " 
 Yes , my understanding is that we only need to be concerned about attacks where an attacker sends a packet crafted so that it will be processed by EDHOC ( which is not hard ) . 
 I made a pull request addressing this issue Added text on demultiplexing . Changed procession so implementation are not mandated to shut down the session if an attacker sends a few bytes to the EDHOC resource / port .. Added more security consideration on Denial of service . 
 Writing this PR made me think about whether we want to mandate that error messages are always fatal as well as downgrade protection . The " " Wrong selected cipher suite " error is fatal because it is sent in repsponse to message1 . You could consider similar types of error sent in response to message2 and message3 . E.g. IDCRED format not supported or CRED format not supported or X.509 public key algorithm not supported . [ BBFGKZ16 ] defines the following theoretical downgrade protection for a session : The cryptographic parameters should be the same on both sides and should be the same as if the peers had been communicating in the absence of an attack . But this definition has very little to do with practical security . In practice it does not matter if an attacker can influence the chosen parameter in the current session or a following session . I am still confused regarding the purpose of the applicability statement . Is it a informal section describing things the parties need to both support to make the protocol work or is a normative security section relevant for policy and downgrade . If we want downgrade protection over multiple sessions , the parties need to agree or securely negotiate everything . Downgrade protection for a session does not make much sense to me if an attacker can force the parties to set up a second session with lower security . 
 Do we need to align the terminology , we use both " session " and " instance " in the draft ? 
 Yes , I just changed " protocol " to " session " not remembering that the draft use instance in other places . 
 We can resolve this later , I opened . Unless there are other comments we will soon merge this . 
 The PR has been discussed and merged . Closing 
 Current specification mandates sending error messages upon certain failures . But in cases when message processing fails when no state has been allocated or when no connection identifier has been found or then a more appropriate action would be to just silently drop the message . 
 I think the MUST ( if possible ) is good . Debugging without any error messages is not nice . We now other protocols that it is good to mandate error messages . It is kind of obvious that can not send an error if you do n't now where / how to send it . Do n't know if that has to be pointed out .... 
 Migth be good to not sent error if you are under a DoS attack . 
 This issue is addressed by pull request that also address availability 
 The PR has been discussed and merged . Closing
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.
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 application using EDHOC is
responsible to handle message loss, reordering, message duplication,
fragmentation, demultiplex EDHOC messages from other types of
messages, and denial of service protection, where necessary.
Paragraph (version B):
If any processing step fails, the Responder SHOULD send an EDHOC
error message back, formatted as defined in error, and the session
MUST be discontinued.  Sending error messages is essential for
debugging but MAY e.g. be skipped due to denial of service reasons,
see security.
Paragraph (version A):
If any verification step fails, the Initiator MUST send an EDHOC
error message back, formatted as defined in error, and the protocol
MUST be discontinued.
Paragraph (version B):
If any processing step fails, the Initiator SHOULD send an EDHOC
error message back, formatted as defined in error.  Sending error
messages is essential for debugging but MAY e.g.be skipped if a
session cannot be found or due to denial of service reasons, see
security.  If an error message is sent, the session MUST be
discontinued.
Paragraph (version B):
If any processing step fails, the Responder SHOULD send an EDHOC
error message back, formatted as defined in error.  Sending error
messages is essential for debugging but MAY e.g.be skipped if a
session cannot be found or due to denial of service reasons, see
security.  If an error message is sent, the session MUST be
discontinued.
Paragraph (version A):
All error messages in EDHOC are fatal.  After sending an error
message, the sender MUST discontinue the protocol.  The receiver
SHOULD treat an error message as an indication that the other party
likely has discontinued the protocol.  But as the error message is
not authenticated, a received error messages might also have been
sent by an attacker and the receiver MAY therefore try to continue
the protocol.
Paragraph (version B):
Errors in EDHOC are fatal.  After sending an error message, the
sender MUST discontinue the protocol.  The receiver SHOULD treat an
error message as an indication that the other party likely has
discontinued the protocol.  But as the error message is not
authenticated, a received error message might also have been sent by
an attacker and the receiver MAY therefore try to continue the
protocol.
Paragraph (version A):
If any verification step fails the Initiator MUST send an EDHOC error
message back, formatted as defined in error, and the protocol MUST be
discontinued.
Paragraph (version B):
If any verification step fails the Initiator MUST send an EDHOC error
message back, formatted as defined in error, and the session MUST be
discontinued.
Paragraph (version B):
An attacker can also send faked message_2, message_3, message_4, or
error in an attempt to trick the receiving party to send an error
message and discontinue the session.  EDHOC implementations MAY
evaluate if a received message is likely to have be forged by and
attacker and ignore it without sending an error message or
discontinuing the session.