[Last-Call] Opsdir last call review of draft-ietf-core-oscore-edhoc-09

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Reviewer: Jürgen Schönwälder
Review result: Has Issues

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
  request)?

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


-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux