Skip to main content

Last Call Review of draft-ietf-core-oscore-edhoc-09

Request Review of draft-ietf-core-oscore-edhoc
Requested revision No specific revision (document currently at 11)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2023-11-13
Requested 2023-10-23
Authors Francesca Palombini , Marco Tiloca , Rikard Höglund , Stefan Hristozov , Göran Selander
I-D last updated 2023-11-13
Completed reviews Opsdir Telechat review of -10 by Jürgen Schönwälder (diff)
Secdir Telechat review of -10 by Wes Hardaker (diff)
Artart Telechat review of -10 by Shuping Peng (diff)
Iotdir Telechat review of -10 by Emmanuel Baccelli (diff)
Artart Last Call review of -09 by Shuping Peng (diff)
Opsdir Last Call review of -09 by Jürgen Schönwälder (diff)
Secdir Last Call review of -09 by Wes Hardaker (diff)
Genart Last Call review of -09 by Joel M. Halpern (diff)
Assignment Reviewer Jürgen Schönwälder
State Completed
Request Last Call review on draft-ietf-core-oscore-edhoc by Ops Directorate Assigned
Posted at
Reviewed revision 09 (document currently at 11)
Result Has issues
Completed 2023-11-13
I have reviewed draft-ietf-core-oscore-edhoc-09 and while I have a
general understanding about CoAP, I am not familiar with EDHOC or the
details of OSCORE. Perhaps some of my questions have simple obvious
answers for those familiar with the technologies.

- The document title consists of six token, three of them are
  acronyms. This is crisp and short but unless you know the acronyms,
  it is hard to tell what this document is about. Sure, expanding all
  acronyms in the title makes it long but it might make the abstract,
  which uses the acronyms as well, more accessible as well...

    Using Ephemeral Diffie-Hellman Over COSE (EDHOC) with the
    Constrained Application Protocol (CoAP) and Object Security for
    Constrained RESTful Environments (OSCORE)

- It is difficult to judge whether there are any possible side effects
  of the proposed optimization, which essentially piggybacks the first
  OSCORE exchange on the last EDHOC exchange. Optimizations of this
  kind sometimes cause subtle side-effects. A security review should
  be done to ensure that there is no impact on the security of EDHOC
  and OSCORE. I	am not able to judge this in a time efficient manner.

- It is not clear to me how this works in mixed deployments where some
  responders implement this specification but others do not. How does
  the initiator figure out whether sending a combined message makes
  sense? It seems question is handled by the application profile. But
  then section 5. starts with "can include the information below"
  followed by some SHOULD text. So what does this combination of "can
  include ... SHOULD ..." mean?

- What does it mean for the client to 'bear [something] in mind'?
  Should the text not spell out clearly what the client is expected to
  do in this case (SHOULDS not send a combined EDHOC + OSCORE

- Is section 4 telling me that the OSCORE ID and EDHOC ID can be the
  same (but they do not have to be the same) while with the proposed
  optimization they must be the same? Or is there always an identity
  mapping between the OSCORE ID and EDHOC ID? If so, why is section 4
  even necessary?

I have ticked 'has issues' because there is no reviewer 'has
questions' option. It is most likely that my questions have very
simple answers - so take a look at my questions and it is absolutely
fine to move ahead if my questions have	obvious	answers	or are just a
lack of understanding of the context.