[Secdispatch] draft-selander-lake-reqs-01

[Hannes Tschofenig <[e-mail]>]

Hi Goeran,

your draft makes the assumption we need OSCORE and hence a key management protocol for it.

It says that it is


   OSCORE [I-D.ietf-core-object-security<https://tools.ietf.org/html/draft-selander-lake-reqs-01#ref-I-D.ietf-core-object-security>] is a lightweight communication

   security protocol providing end-to-end security for constrained IoT

   settings (cf.  [RFC7228<https://tools.ietf.org/html/rfc7228>]).

Should the draft say something about the weaker privacy properties compared to the DTLS 1.3 record layer? You seem to have forgotten to mention those.

Maybe it would also be good to state somewhere that OSCORE is heavier than the DTLS 1.3 record layer (based on the analysis from your co-workers). If we care about the bits over the wire so much we should probably be using the DTLS 1.3 record layer instead.


Should it also state somewhere that these "end-to-end security" properties only work under certain conditions? The name "Object Security for ..." may give the uninformed reader the impression that it provides security at the object level but instead it provides "provides end-to-end protection between endpoints communicating using CoAP or CoAP-mappable HTTP" - a kind of message level security. Particularly the CoAP-mappable HTTP part is interesting here because it requires the API on the CoAP side and the API on the HTTP to be semantically equivalent. This does not appear to be the case in many IoT deployments (for good reasons). Just look at the APIs vendors have published. (FWIW I am still waiting to see the API description of the Ericsson IoT device management server. Ours is public and can be found here: https://www.pelion.com/docs/device-management/current/service-api-references/index.html)



It might also be a good idea to explore the CoAP proxy functionality again because this is an often claimed area where OSCORE is needed. For those who have not followed the CoAP work it is interesting to know that the design of CoAP and HTTP differs also in the way proxies are used. A TLS connection can traverse an HTTP proxy while in CoAP it terminates there. Maybe it is time to integrate the properties of the HTTP proxy into CoAP?

Ciao
Hannes
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.