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

From: Göran Selander <[email-masked]>
Date: Mon, 15 Jan 2018 16:27:57 +0000

Hi Esko,

Thanks very much for your review. We addressed most of your comments on the Github before the holidays, but a few things needed more time to resolve. We will soon submit a new version of the draft, the current Github version is here:

https://core-wg.github.io/oscoap/draft-ietf-core-object-security.html

Comments inline.

From: Esko Dijk <[email-masked]<mailto:[email-masked]>>
Date: Wednesday 13 December 2017 at 12:33
To: Jaime Jiménez <[email-masked]<mailto:[email-masked]>>, "[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: Wednesday 13 December 2017 at 12:50

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.

[GS] We rephrased the introduction and defined it in the terminology.

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

[GS] The general REST term seems to be “method” so I believe that term can be both HTTP and CoAP,  but added the clarification that it is called Code in RFC7252. I don’t think we need to mention that the response code is also protected – this is just the introduction.

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

[GS] Done.

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"  " ?

[GS] Done.

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"

[GS] Done.

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.

[GS] Rewritten.

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

[GS] Done.

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.

[GS] Rewritten and with reference to 7.4 where more information is given.

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!)

[GS] Done.

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

[GS] Rephrased, but no numbers are provided since it it application specific: "If Sender ID uniqueness cannot be guaranteed by construction, Sender IDs MUST be long uniformly random distributed byte strings such that the probability of collisions is negligible."

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

[GS] Special option added to table. Specification of processing in progress.

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)

[GS] Done.

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

[GS] Done (now 4.2.3.6)

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.

This seems to be a misunderstanding here, let’s see if we can find out where:

A. The version number is the OSCORE version. We tried to clarify that point by renaming it “oscore_version”.  This specification assumes oscore_version = 1.
B. oscore_version is only present in the external_aad, i.e. it is never sent. This enables a version 1 implementation to verify that the sending party also intended that. But since there may be several reasons why the message doesn’t verify, it is not possible from this specification to conclude that the version is wrong.  If there is a need for a new version of OSCORE , that version will have to define how this parameter is used for other values of oscore_version.

Does that make more sense? Is this still an issue?

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?

[GS] Now 8.2. Included a reference to current section 7.4, which also describes error messaging.

Step 5. Compose the Additional Authenticated Data, as described in Section 5
-> could this reference be more specific, e.g. to 5.4 ?

[GS] Done.

-> why is the data composed - I would expect parsing would take place in the server.

[GS] Similar comment as above; since this is additional authenticated data of the AEAD, it is composed in the server rather than received and used in the verification.

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)

[GS] Done.

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

[GS] Same answer as above.

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.

[GS] I made an attempt to clarify specifying which additional requirements are also addressed.

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.

[GS] Now 10.3. There may be a misunderstanding how Content-Type/Content-Format is processed so we added that to the example. Does this make more sense?

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

[GS] Included in 10.2.

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

[GS]

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

[GS]  Now includes some test vectors.

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]<mailto:[email-masked]> WG ([email-masked]<mailto:[email-masked]>) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[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: Göran Selander <[email-masked]>
Date: Mon, 15 Jan 2018 16:37:50 +0000

Hi again Esko,

I was a bit quick on the  “Send” button. Some additional comments at the end of this mail.

From: Göran Selander <[email-masked]<mailto:[email-masked]>>
Date: Monday 15 January 2018 at 17:27
To: Esko Dijk <[email-masked]<mailto:[email-masked]>>, Jaime Jiménez <[email-masked]<mailto:[email-masked]>>, "[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

Hi Esko,

Comments inline.

Dear CoRE WG,

General

Section 1

[GS] Done.

[GS] Done.

[GS] Done.

2

[GS] Rewritten.

3.2.1

[GS] Done.

3.2.2

3.3

[GS] Done.

4.2

4.2.3.1

[GS] Done.

4.2.3.5

[GS] Done (now 4.2.3.6)

5.4

7.2

[GS] Done.

7.3

[GS] Done.

7.4

10.1

10.2
Example

[GS] Included in 10.2.

10.3
Example

[GS] Included in 10.2

11

[GS] Rephrased.

Appendix A
Has a "TODO" label only

2) Minor comments

Section 1

2

4.2.3.5
inegrity  -> integrity

6.4

6.5

6.5.3

8.1

8.3.1

11

13.1
paramter  -> parameter

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

All minor comments included in the updated draft.

Again thanks very much for detailed review. Please let us know if you have further comments.

Best regards,
Göran

---

From: Esko Dijk <[email-masked]>
Date: Wed, 17 Jan 2018 11:12:45 +0000

Hello Göran,

Thanks for the improvements made in the document.

> B. oscore_version is only present in the external_aad, i.e. it is never sent. This enables a version 1 implementation to verify that the sending party also intended that.
> But since there may be several reasons why the message doesn’t verify, it is not possible from this specification to conclude that the version is wrong.  If there is a
> need for a new version of OSCORE , that version will have to define how this parameter is used for other values of oscore_version.

Ok this makes it clear to me; when reviewing this part I thought the data was carried somewhere in the message. After reading Section 8 it’s more clear that that’s not the case. The new text could be clarified a little bit more; as it does not say what external_aad is used for. E.g. insert as first sentence of 5.4:   “The external_aad byte array defined below is used as the Additional Authenticated Data input as described in [RFC8152] Section 4.3.”  ?

Two comments on the Section 10.4 example:

   GET http://server.url/orders
-> should there be “HTTP/1.1” added after the URL?

  [CoAP response -- CoAP Server to Proxy]
-> shouldn’t this be “[CoAP response – Proxy to CoAP client]” ?  (of course the Proxy includes internally a CoAP Server – so we may call that also the “Proxy’s CoAP Server” or so.)
Best regards,
Esko

From: Göran Selander [mailto:[email-masked]]
Sent: Monday, January 15, 2018 17:38
To: Esko Dijk <[email-masked]>; Jaime Jiménez <[email-masked]>; [email-masked] WG ([email-masked]) <[email-masked]>
Cc: [email-masked]
Subject: Re: [core] 🔔 WGLC on draft-ietf-core-object-security

Hi again Esko,

Hi Esko,

Comments inline.

Dear CoRE WG,

General

Section 1

[GS] Done.

[GS] Done.

[GS] Done.

2

[GS] Rewritten.

3.2.1

[GS] Done.

3.2.2

3.3

[GS] Done.

4.2

4.2.3.1

[GS] Done.

4.2.3.5

[GS] Done (now 4.2.3.6)

5.4

7.2

[GS] Done.

7.3

[GS] Done.

7.4

10.1

10.2
Example

[GS] Included in 10.2.

10.3
Example

[GS] Included in 10.2

11

[GS] Rephrased.

Appendix A
Has a "TODO" label only

2) Minor comments

Section 1

2

4.2.3.5
inegrity  -> integrity

6.4

6.5

6.5.3

8.1

8.3.1

11

13.1
paramter  -> parameter

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

Best regards,
Göran

---

From: Göran Selander <[email-masked]>
Date: Mon, 22 Jan 2018 21:45:21 +0000

Hi Esko,

Thanks, your proposals are included in the new version.

Best regards
Göran

From: Esko Dijk <[email-masked]<mailto:[email-masked]>>
Date: Wednesday 17 January 2018 at 12:12
To: Göran Selander <[email-masked]<mailto:[email-masked]>>, Jaime Jiménez <[email-masked]<mailto:[email-masked]>>, "[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

Hello Göran,

To: Esko Dijk <[email-masked]<mailto:[email-masked]>>; Jaime Jiménez <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> WG ([email-masked]<mailto:[email-masked]>) <[email-masked]<mailto:[email-masked]>>

Hi again Esko,

Hi Esko,

Comments inline.

Dear CoRE WG,

General

Section 1

[GS] Done.

[GS] Done.

[GS] Done.

2

[GS] Rewritten.

3.2.1

[GS] Done.

3.2.2

3.3

[GS] Done.

4.2

4.2.3.1

[GS] Done.

4.2.3.5

[GS] Done (now 4.2.3.6)

5.4

7.2

[GS] Done.

7.3

[GS] Done.

7.4

10.1

10.2
Example

[GS] Included in 10.2.

10.3
Example

[GS] Included in 10.2

11

[GS] Rephrased.

Appendix A
Has a "TODO" label only

2) Minor comments

Section 1

2

4.2.3.5
inegrity  -> integrity

6.4

6.5

6.5.3

8.1

8.3.1

11

13.1
paramter  -> parameter

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

Best regards,
Göran