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

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

Hi Zahed, and all,

We made a small PR on top of -21 clarifying the preference for reliable transport:
https://github.com/lake-wg/edhoc/pull/434/files

Please let us know if this change is preferred and if there is anything missing.

Thanks,
Göran



From: Göran Selander <[e-mail]>
Date: Thursday, 24 August 2023 at 13:08
To: Zaheduzzaman Sarker <[e-mail]>
Cc: The IESG <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: Re: Zaheduzzaman Sarker's No Objection on draft-ietf-lake-edhoc-20: (with COMMENT)
Hi Zahed, and all,

Thanks for quick response. Inline.

From: Zaheduzzaman Sarker <[e-mail]>
Date: Thursday, 24 August 2023 at 10:59

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

[GS] I’m open for guidance here (from IESG, LAKE WG/chairs,  or others).

Section 3.4 in #429 is intended to explain (may be improved!) that

·         if you just run UDP then your EDHOC session may be aborted, because the message received is not always the expected next message according to protocol state.

·         If you add CoAP in reliable mode it should work just fine.

·         If you don’t use CoAP then you need to use something else that handles the listed transport properties or risk the session unnecessarily being aborted.

In A.2 we recommend using CoAP in reliable mode. We could make that recommendation more general. Not sure how to best do that in the context of the existing list.

Is your view of the problem with the current text that people may get wrong expectations, or that we allow settings where the EDHOC session sometimes doesn’t complete due to limitations in the transport?

Thanks,
Göran