Re: [Lake] Zaheduzzaman Sarker's No Objection on draft-ietf-lake-edhoc-20: (with COMMENT)

[Göran Selander <[e-mail]>]

Hi Zahed,

Thanks for your review. It is tracked as github issue #420<https://github.com/lake-wg/edhoc/issues/420>. I tried to compile all updates related to comments on section 3.4, including yours, in one PR #429<https://github.com/lake-wg/edhoc/pull/429>.

Please find responses to your comments inline below.

Göran


From: Zaheduzzaman Sarker via Datatracker <[e-mail]>
Date: Tuesday, 22 August 2023 at 16:46
To: The IESG <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: Zaheduzzaman Sarker's No Objection on draft-ietf-lake-edhoc-20: (with COMMENT)
Zaheduzzaman Sarker has entered the following ballot position for
draft-ietf-lake-edhoc-20: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lake-edhoc/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for working on this specification. Thanks to Michael Scharf his valuable
TSVART review and nice to those addressed.

I would like to have responses on the following points as I believe clarity
would help this specification -

   - It appeared to me that reliable transport is preferred while EDHOC
   messages are transmitted, however, this is not clearly mentioned. I think if
   this is the case then it should be clear in this specification.
[GS] The preferences for transport depend on the application, but the default transport of EDHOC is CoAP in reliable mode.  See clarifications in #429<https://github.com/lake-wg/edhoc/pull/429>.

   - I also like section 3.4, however, it is not clear to me if the list
   provided, is a "must to meet" criteria for any transport or fulfilling any
   subset of features is good enough. If the later then this specification
   should describe how the missing criteria should be fulfilled or ignore or
   describe the impact.
[GS] The security protocol does not depend on any of the transport criteria listed in section 3.4. The consequence of the transport producing something else than the next message according to protocol state is that the session will be aborted. The application decides on transport to use and which criteria in the list to fulfil, and thereby what risks it is prepared to take for potential termination of the protocol due to shortcomings of the transport. Attempted clarifications to 3.4 has been added in #429<https://github.com/lake-wg/edhoc/pull/429>.


For the similar reason, I am also supporting Lars's discuss on clarification
required for DoS protection by the transport.

[GS] Please check PR #425<https://github.com/lake-wg/edhoc/pull/425> and the response to Lars:
https://mailarchive.ietf.org/arch/msg/lake/ZNDy-K2lz-YY4utze6vwJMdPucg/