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

From: Esko Dijk <[email-masked]>
Date: Wed, 13 Dec 2017 11:33:57 +0000

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:[email-masked]] On Behalf Of Jaime Jiménez
Sent: Monday, November 20, 2017 16:09
To: [email-masked] WG ([email-masked]) <[email-masked]>
Cc: [email-masked]
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.

---

From: Mališa Vučinić <[email-masked]>
Date: Thu, 14 Dec 2017 14:18:03 +0100

Göran, all,

It was really a pleasure to witness how this spec advanced from draft-selander-ace-object-security-00 and evolved to its current form. Thank you for accommodating the requests coming from 6TiSCH and making this solution so efficient.

I am just starting to work on a Wireshark dissector and this made me go through the text on HTTP-to-CoAP and CoAP-to-HTTP proxying as one may have HTTP carrying OSCORE. I would like to understand better the added value of this part of the spec. Take as an example HTTP client generating request that is proxied/translated into a CoAP request. For the HTTP client to generate external_aad and ciphertext, it needs to implement portions of CoAP machinery. For example, to generate plaintext, the HTTP client needs to know in advance what CoAP Code will the proxied request have, how HTTP headers will translate to CoAP options and how to encode them in CoAP format. My question is whether it makes sense for an HTTP client to implement this, but not the rest of CoAP.

Second comment is related to normative language on error handling in -07. Background: Some error responses can be spoofed as they are not protected due to the lack of common keying material, so this opens up a DoS vector on the client. Current text in -07 states that the server MAY send this kind of response. Could you elaborate the reasoning behind this? What is the expected behavior of a client? Could you discuss somewhere security tradeoff being made when one opts for one approach or the other? Why do you not differentiate based on message type (NON/CON), as used in previous versions?

Mališa

> On 20 Nov 2017, at 16:09, Jaime Jiménez <[email-masked]> wrote:
> 
> Dear CoRE WG,
> 
> https://tools.ietf.org/html/draft-ietf-core-object-security-07 <https://tools.ietf.org/html/draft-ietf-core-object-security-07> 
> 
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 14 Dec 2017 14:29:05 +0100

On Dec 14, 2017, at 14:18, Mališa Vučinić <[email-masked]> wrote:
> 
> My question is whether it makes sense for an HTTP client to implement this, but not the rest of CoAP.

Hi Mališa,

unfortunately, this is not just a question of implementation, but also about whether the client will have reachability.  
HTTP is "the protocol that goes through firewalls”...

Grüße, Carsten

---

From: Mališa Vučinić <[email-masked]>
Date: Thu, 14 Dec 2017 15:59:05 +0100

Hi Carsten,

Thanks, I wasn’t aware of those use cases. I take then as useful that OSCORE has a stand-alone dissector instead of being part of CoAP.

Mališa

> On 14 Dec 2017, at 14:29, Carsten Bormann <[email-masked]> wrote:
> 
> Hi Mališa,
>

---

From: Göran Selander <[email-masked]>
Date: Tue, 19 Dec 2017 09:35:38 +0000

Hi Mališa,

Great to hear you are progressing with Wireshark for OSCORE!

Answers/comments inline:

From: Mališa Vučinić <[email-masked]<mailto:[email-masked]>>
Date: Thursday 14 December 2017 at 14:18
To: "[email-masked]<mailto:[email-masked]> WG ([email-masked]<mailto:[email-masked]>)" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [core] 🔔 WGLC on draft-ietf-core-object-security
Resent-From: <[email-masked]<mailto:[email-masked]>>
Resent-To: Göran Selander <[email-masked]<mailto:[email-masked]>>, John Mattsson <[email-masked]<mailto:[email-masked]>>, Francesca Palombini <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>
Resent-Date: Thursday 14 December 2017 at 14:18

Göran, all,

[GS] Carsten already commented about using HTTP for traversing firewalls. This thus enables end-to-end REST in practice, including deployments with mixed HTTP/CoAP legs. The feature was requested by e.g. OCF.

Second comment is related to normative language on error handling in -07. Background: Some error responses can be spoofed as they are not protected due to the lack of common keying material, so this opens up a DoS vector on the client. Current text in -07 states that the server MAY send this kind of response. Could you elaborate the reasoning behind this?

[GS] There was a request from one of the implementors to avoid unnecessary retransmissions and to be able to send info about what error it is. Typically error messages are protected, but if the error is related to OSCORE itself, e.g. that the server cannot find the security context, then the error message to the client cannot be protected. The DoS aspect related to a client receiving an unprotected error message depends on how the client acts on this message. The ability to send unprotected messages existed even without this.

What is the expected behavior of a client?

[GS] The application decides how to act. If an error message arrives, either the application specifies how to deal with it (e.g. based on the payload if any) or drops it without further processing.

Could you discuss somewhere security tradeoff being made when one opts for one approach or the other?

[GS] Yes, we should add a security consideration on this note.

Why do you not differentiate based on message type (NON/CON), as used in previous versions?

[GS] Because the error is sent independently of the underlying messaging layer, and there may not even be a messaging layer as in CoAP over TCP. The dependence on NON/CON was a mistake in the previous version that came up during the last interop, thanks to the implementers.

I hope this addresses your comments.

Göran

Mališa

On 20 Nov 2017, at 16:09, Jaime Jiménez <[email-masked]<mailto:[email-masked]>> wrote:

Dear CoRE WG,

Best Regards,
- - Jaime Jiménez

_______________________________________________
core mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/core

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 19 Dec 2017 11:02:13 +0100

> Thanks, I wasn’t aware of those use cases. I take then as useful that OSCORE has a stand-alone dissector instead of being part of CoAP.

Actually, CoAP now comes in three encoding variants:

— in a CoAP/UDP (or CoAP/DTLS) message
— in a CoAP/TCP (TLS, WebSockets) stream
— within an OSCORE Object-Security option, in CoAP, or in the HTTP header field of the same name

These are all mostly the same (most of the work is in the option encoding), but the way the message code is transported differs between these three cases.  (There are also some new options for CoAP/TCP the meaning of which depends on the message code.)

Grüße, Carsten