Re: [core] 🔔 WGLC on draft-ietf-core-object-security

[Esko Dijk <[e-mail]>]

Dear CoRE WG,

Below my review comments for this draft, split in two parts: 1) comments for the authors and WG to resolve prior to RFC editing;  and 2) minor comments that could be resolved also later e.g. during RFC editing.
Overall, OSCORE seems a very comprehensive security solution that is well integrated with all relevant existing CoRE/CoAP/COSE specifications.

1) Comments for authors/WG

General
·         Term "hop-by-hop" could be introduced. It seems not yet defined in one of the documents listed in Section 1.1, and also not in this draft.

Section 1
 and the RESTful method -> …
  For HTTP [RFC7230] it should be called 'request method'.
  For CoAP [RFC7252] it should be called 'Code'.  (see Fig 7 in [RFC7252] - which is either Method Code or Response Code. The protection applies to the Code field.)

-> section could explain already why the Token does not need to be protected. (Since it is defined for the Request/Response layer, Sect 2.2 [RFC7252], this question may come up with readers at this point.)

The solution transforms a message into an "OSCORE message"
-> Could we clarify this like "The solution transforms a CoAP or HTTP message into an "OSCORE message"  " ?

and the request/response method (CoAP Code) are protected in a COSE object
-> official terms [RFC7252] are Request Method / Response Code, so perhaps better is
  "and the Request Method/Response Code (CoAP Code) are protected in a COSE object"

2
   Since the payload and most options are encrypted Section 4, and the
   corresponding plain text message fields of the original are not
   included in the OSCORE message, the processing of these fields does
   not expand the total message size.
-> unclear paragraph; what type of "processing" of these fields is meant? Does it mean the encryption operation? Also this paragraph appears to be out of context here; it is not really about the Object-Security Option but rather a general property of the protocol.

3.2.1
The 'alg' array element is undefined in the list below the 'info = ' CBOR array.

3.2.2
replay protection and replay window length is application specific and depends on the lower layers
-> the “lower layers” could be clarified more. Is this e.g. UDP, TCP or other transports that carry CoAP? And how would these impact the replay window length. Or does it also include medium speed/bitrate such that a larger window size is needed for a faster medium.

3.3
The maximum length of Sender ID is length of nonce subtracted by 6 bytes.
-> The maximum length of the Sender ID in bytes equals the length of the nonce minus 6.
(attempt to make this more clear!)

Sender IDs MUST be long uniformly random distributed byte strings
-> how long is long?  (good to be specific for a normative requirement)

4.2
Add Option 258 No-Response to the table perhaps. (Just saw this is in the registry and not listed yet in the table; there may be reasons not to include it here.)

4.2.3.1
Non-error OSCORE responses do not need to include a Max-Age option
   since the responses are non-cacheable by construction
->
Non-error OSCORE responses do not need to include an Outer Max-Age option
   since the responses are non-cacheable by construction
(attempt to clarify)

4.2.3.5
detects an OSCORE option ->  detects an Object-Security option

5.4
A version number is introduced.
-> What should the behaviour of a receiver be when receiving OSCORE messages with version >  1 , or version < 1?
Perhaps we also would like to indicate that the array length may increase for future versions (version > 1) of this spec. So that when a v2 protocol comes along that wants to extend the array length, the v1 receivers will not choke these longer arrays.  It is fine to verify array length strictly for version==1 , but preferably not too strict for version>1 messages.
If we do not define some extra future-compatibility rules now, there is a big risk that any new version (v2) format additions will be handled in different ways by different v1 endpoint implementations.

-> Going a bit more extreme; it would be easier and more efficient to define the version number at the end of the array, leaving it out when version == 1 and including it otherwise. (The array length thus may grow in a future version of this spec.)  But the “moving version field to the end” may be a too big change at this point in time. The nice thing here is that your array length value doubles as a for-free version number indicator :)  in the sense that if the array is longer, the version is known to be > 1.

7.2
Step 4: if the verification of Partial IV fails, can the server respond with an error message? Or should it simply discard the request?

Step 5. Compose the Additional Authenticated Data, as described in Section 5
-> could this reference be more specific, e.g. to 5.4 ?
-> why is the data composed - I would expect parsing would take place in the server.

7.3
Given a CoAP response, the server SHALL perform the following steps to create an OSCORE response
-> "If a CoAP response is generated in response to an OSCORE request, the server SHALL perform the following steps to create an OSCORE response"
(more specific - since the server may answer non-OSCORE requests with plain CoAP responses also)

7.4
Step 5. Compose the Additional Authenticated Data, as described in Section 5
-> same question as above for Section 7.2 Step 5.

10.1
The targeted proxy operations are specified in Section 2.2.1 of [I-D.hartke-core-e2e-security-reqs].
-> it looks as if the Section 10, which describes normative requirements for OSCORE-aware proxies, here defers part of the solution to an informative document.  Is it possible to clarify the sentence to better communicate e.g. that the requirements of [I-D.hartke-core-e2e-security-reqs] are all addressed/met by the text in the present section 10.1 ?  Now it looks like the section refers to [I-D.hartke-core-e2e-security-reqs] for normative implementation details.

10.2
Example
-> Could explicitly add a statement that in the HTTP message the Content-Type header, or more generally the representation metadata (Content-* headers) must be elided.  (That would cause a receiver to automatically assume "application/octet-stream" type.)   Or, in case such headers are allowed, the selected / preferred media type for these headers should be specified.

-> example should be extended by having the CoAP server respond with a Content-Format option, which is then found/decrypted by the OSCORE component that is situated on the HTTP client.  Since responding with a Content-Format option together with payload is quite common for CoAP servers.

-> considering above, it seems worthwhile to point out again that the "HTTP Client" contains the OSCORE function which already must contain a HTTP-to-CoAP mapping function, in order to convert the CoAP response code and CoAP response options to the equivalents in HTTP, e.g. doing so per [RFC8075].

10.3
Example
-> perhaps worthwhile to point out that the OSCORE function in the "HTTP Server" contains a HTTP-to-CoAP mapping function inside, in order to convert the HTTP response and content-type/encoding to the equivalent CoAP response code and Options.
(Since this "mapping function" processing is not separately identified in the steps but rather included in one OSCORE step; people may overlook this aspect - and may wonder how a HTTP Server knows about CoAP syntax and semantics.)

11
OSCORE protects end-to-end the payload, and all information in the options and header,
-> probably here "CoAP" was removed at some point, making the reference to options and header unclear. Options are CoAP-specific. Can we also say "CoAP header" here? And for HTTP we should say "header fields" probably, not "header"?

Appendix A
Has a "TODO" label only



2) Minor comments

·         Some references to sections seem to be missing the brackets e.g. "Section X" instead of "(Section X)".
e.g. "most options are encrypted Section 4, and the"
·         Some section references are written lowercase "section X" instead of "Section X"

Section 1
secure the binding -> secure binding          (for improved sentence flow)

2
detailed format is specified in Section 8). -> detailed format is specified in Section 8.
options are encrypted Section 4, -> options are encrypted (Section 4),

4.2.3.5
inegrity  -> integrity

6.4
The server MAY set an Outer Max-Age option with value zero.
-> could clarify that the server may do this if the verification fails. E.g. say
"Also, the server MAY in this case set an Outer Max-Age option with value zero."

6.5
'node' (used several times)
-> should this be replaced by 'endpoint' ?  Most other section seem to use the 'endpoint' term for these. Just a thought - maybe the term 'node' is indeed better when talking about e.g. reboots since endpoints don't reboot, but nodes do. On the other hand 6.5.2 talks about a rebooting (CoAP) server.

Notififcation Numbers -> Notification Numbers

to achieve this is described below -> to achieve this are described below

6.5.3
and re-register -> and re-registers

8.1
and n = 7 is reserved -> and n = 7 are reserved

8.3.1
Some leading tabs or vertical spacing could be used to better separate the examples.

11
The inner block options -> The Inner Block options

since the encrypted options  -> since the encrypted Block options   ?

13.1
paramter  -> parameter

14
My browser displays:
Malisa Vu&#269;ini&#263

Best regards,
Esko Dijk


From: core [mailto:[e-mail]] On Behalf Of Jaime Jiménez
Sent: Monday, November 20, 2017 16:09
To: [e-mail] WG ([e-mail]) <[e-mail]>
Cc: [e-mail]
Subject: [core] 🔔 WGLC on draft-ietf-core-object-security

Dear CoRE WG,

As we discussed during this IETF, the OSCORE draft is in good shape for WGLC.
The authors have submitted a reviewed version dealing with the minor comments from IEF100.

https://tools.ietf.org/html/draft-ietf-core-object-security-07

The WGLC will end by 11th of December.

Best Regards,
- - Jaime Jiménez


________________________________
The information contained in this email may be confidential and/or legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this email is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original email.