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

[Zaheduzzaman Sarker <[e-mail]>]

On Wed, Aug 23, 2023 at 11:14 PM Göran Selander <[e-mail]>
wrote:

> 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.
>
OK.


> 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.
>
This is however, still not clear in the text in 3.4. Lets say, for some
reasons the application just opens up an UDP socket to send the EDHOC
messages, in that case the transport protocol would not be able to provide
those listed as expect in the specification - "In order to avoid
unnecessary message processing or protocol termination, the transport is
responsible to handle", so either the application take cares of all the
transport responsibilities or does not select UDP, but there is nothing in
the specification that prohibits the application to pick UDP in the socket.
This is to me is not a good situation and need clarification. (As I wrote
in the my previous comment, the specification seems to prefer reliable
transport and may be that should be default ask).

//Zahed

>