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

[Jaime Jiménez]

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

[Esko Dijk]

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:core-***@ietf.org] On Behalf Of Jaime Jiménez
Sent: Monday, November 20, 2017 16:09
To: ***@ietf.org WG (***@ietf.org) <***@ietf.org>
Cc: draft-ietf-core-object-***@ietf.org
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.

[Göran Selander]

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 <***@philips.com<mailto:***@philips.com>>
Date: Wednesday 13 December 2017 at 12:33
To: Jaime Jiménez <***@ericsson.com<mailto:***@ericsson.com>>, "***@ietf.org<mailto:***@ietf.org> WG (***@ietf.org<mailto:***@ietf.org>)" <***@ietf.org<mailto:***@ietf.org>>
Cc: "draft-ietf-core-object-***@ietf.org<mailto:draft-ietf-core-object-***@ietf.org>" <draft-ietf-core-object-***@ietf.org<mailto:draft-ietf-core-object-***@ietf.org>>
Subject: RE: [core] 🔔 WGLC on draft-ietf-core-object-security
Resent-From: <alias-***@ietf.org<mailto:alias-***@ietf.org>>
Resent-To: Göran Selander <***@ericsson.com<mailto:***@ericsson.com>>, John Mattsson <***@ericsson.com<mailto:***@ericsson.com>>, Francesca Palombini <***@ericsson.com<mailto:***@ericsson.com>>, <***@ri.se<mailto:***@ri.se>>
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:core-***@ietf.org] On Behalf Of Jaime Jiménez
Sent: Monday, November 20, 2017 16:09
To: ***@ietf.org<mailto:***@ietf.org> WG (***@ietf.org<mailto:***@ietf.org>) <***@ietf.org<mailto:***@ietf.org>>
Cc: draft-ietf-core-object-***@ietf.org<mailto:draft-ietf-core-object-***@ietf.org>
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.

[Göran Selander]

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 <***@ericsson.com<mailto:***@ericsson.com>>
Date: Monday 15 January 2018 at 17:27
To: Esko Dijk <***@philips.com<mailto:***@philips.com>>, Jaime Jiménez <***@ericsson.com<mailto:***@ericsson.com>>, "***@ietf.org<mailto:***@ietf.org> WG (***@ietf.org<mailto:***@ietf.org>)" <***@ietf.org<mailto:***@ietf.org>>
Cc: "draft-ietf-core-object-***@ietf.org<mailto:draft-ietf-core-object-***@ietf.org>" <draft-ietf-core-object-***@ietf.org<mailto:draft-ietf-core-object-***@ietf.org>>
Subject: Re: [core] 🔔 WGLC on draft-ietf-core-object-security

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 <***@philips.com<mailto:***@philips.com>>
Date: Wednesday 13 December 2017 at 12:33
To: Jaime Jiménez <***@ericsson.com<mailto:***@ericsson.com>>, "***@ietf.org<mailto:***@ietf.org> WG (***@ietf.org<mailto:***@ietf.org>)" <***@ietf.org<mailto:***@ietf.org>>
Cc: "draft-ietf-core-object-***@ietf.org<mailto:draft-ietf-core-object-***@ietf.org>" <draft-ietf-core-object-***@ietf.org<mailto:draft-ietf-core-object-***@ietf.org>>
Subject: RE: [core] 🔔 WGLC on draft-ietf-core-object-security
Resent-From: <alias-***@ietf.org<mailto:alias-***@ietf.org>>
Resent-To: Göran Selander <***@ericsson.com<mailto:***@ericsson.com>>, John Mattsson <***@ericsson.com<mailto:***@ericsson.com>>, Francesca Palombini <***@ericsson.com<mailto:***@ericsson.com>>, <***@ri.se<mailto:***@ri.se>>
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] Included in 10.2



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

[GS] Rephrased.


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

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

[Esko Dijk]

Hello Göran,

Thanks for the improvements made in the document.

Post by Göran Selander
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.

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:***@ericsson.com]
Sent: Monday, January 15, 2018 17:38
To: Esko Dijk <***@philips.com>; Jaime Jiménez <***@ericsson.com>; ***@ietf.org WG (***@ietf.org) <***@ietf.org>
Cc: draft-ietf-core-object-***@ietf.org
Subject: Re: [core] 🔔 WGLC on draft-ietf-core-object-security

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 <***@ericsson.com<mailto:***@ericsson.com>>
Date: Monday 15 January 2018 at 17:27
To: Esko Dijk <***@philips.com<mailto:***@philips.com>>, Jaime Jiménez <***@ericsson.com<mailto:***@ericsson.com>>, "***@ietf.org<mailto:***@ietf.org> WG (***@ietf.org<mailto:***@ietf.org>)" <***@ietf.org<mailto:***@ietf.org>>
Cc: "draft-ietf-core-object-***@ietf.org<mailto:draft-ietf-core-object-***@ietf.org>" <draft-ietf-core-object-***@ietf.org<mailto:draft-ietf-core-object-***@ietf.org>>
Subject: Re: [core] 🔔 WGLC on draft-ietf-core-object-security

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 <***@philips.com<mailto:***@philips.com>>
Date: Wednesday 13 December 2017 at 12:33
To: Jaime Jiménez <***@ericsson.com<mailto:***@ericsson.com>>, "***@ietf.org<mailto:***@ietf.org> WG (***@ietf.org<mailto:***@ietf.org>)" <***@ietf.org<mailto:***@ietf.org>>
Cc: "draft-ietf-core-object-***@ietf.org<mailto:draft-ietf-core-object-***@ietf.org>" <draft-ietf-core-object-***@ietf.org<mailto:draft-ietf-core-object-***@ietf.org>>
Subject: RE: [core] 🔔 WGLC on draft-ietf-core-object-security
Resent-From: <alias-***@ietf.org<mailto:alias-***@ietf.org>>
Resent-To: Göran Selander <***@ericsson.com<mailto:***@ericsson.com>>, John Mattsson <***@ericsson.com<mailto:***@ericsson.com>>, Francesca Palombini <***@ericsson.com<mailto:***@ericsson.com>>, <***@ri.se<mailto:***@ri.se>>
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] Included in 10.2



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

[GS] Rephrased.


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

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


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

[Göran Selander]

Hi Esko,

Thanks, your proposals are included in the new version.

Best regards
Göran


From: Esko Dijk <***@philips.com<mailto:***@philips.com>>
Date: Wednesday 17 January 2018 at 12:12
To: Göran Selander <***@ericsson.com<mailto:***@ericsson.com>>, Jaime Jiménez <***@ericsson.com<mailto:***@ericsson.com>>, "***@ietf.org<mailto:***@ietf.org> WG (***@ietf.org<mailto:***@ietf.org>)" <***@ietf.org<mailto:***@ietf.org>>
Cc: "draft-ietf-core-object-***@ietf.org<mailto:draft-ietf-core-object-***@ietf.org>" <draft-ietf-core-object-***@ietf.org<mailto:draft-ietf-core-object-***@ietf.org>>
Subject: RE: [core] 🔔 WGLC on draft-ietf-core-object-security

Hello Göran,

Thanks for the improvements made in the document.

Post by Göran Selander
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.

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:***@ericsson.com]
Sent: Monday, January 15, 2018 17:38
To: Esko Dijk <***@philips.com<mailto:***@philips.com>>; Jaime Jiménez <***@ericsson.com<mailto:***@ericsson.com>>; ***@ietf.org<mailto:***@ietf.org> WG (***@ietf.org<mailto:***@ietf.org>) <***@ietf.org<mailto:***@ietf.org>>
Cc: draft-ietf-core-object-***@ietf.org<mailto:draft-ietf-core-object-***@ietf.org>
Subject: Re: [core] 🔔 WGLC on draft-ietf-core-object-security

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 <***@ericsson.com<mailto:***@ericsson.com>>
Date: Monday 15 January 2018 at 17:27
To: Esko Dijk <***@philips.com<mailto:***@philips.com>>, Jaime Jiménez <***@ericsson.com<mailto:***@ericsson.com>>, "***@ietf.org<mailto:***@ietf.org> WG (***@ietf.org<mailto:***@ietf.org>)" <***@ietf.org<mailto:***@ietf.org>>
Cc: "draft-ietf-core-object-***@ietf.org<mailto:draft-ietf-core-object-***@ietf.org>" <draft-ietf-core-object-***@ietf.org<mailto:draft-ietf-core-object-***@ietf.org>>
Subject: Re: [core] 🔔 WGLC on draft-ietf-core-object-security

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 <***@philips.com<mailto:***@philips.com>>
Date: Wednesday 13 December 2017 at 12:33
To: Jaime Jiménez <***@ericsson.com<mailto:***@ericsson.com>>, "***@ietf.org<mailto:***@ietf.org> WG (***@ietf.org<mailto:***@ietf.org>)" <***@ietf.org<mailto:***@ietf.org>>
Cc: "draft-ietf-core-object-***@ietf.org<mailto:draft-ietf-core-object-***@ietf.org>" <draft-ietf-core-object-***@ietf.org<mailto:draft-ietf-core-object-***@ietf.org>>
Subject: RE: [core] 🔔 WGLC on draft-ietf-core-object-security
Resent-From: <alias-***@ietf.org<mailto:alias-***@ietf.org>>
Resent-To: Göran Selander <***@ericsson.com<mailto:***@ericsson.com>>, John Mattsson <***@ericsson.com<mailto:***@ericsson.com>>, Francesca Palombini <***@ericsson.com<mailto:***@ericsson.com>>, <***@ri.se<mailto:***@ri.se>>
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] Included in 10.2



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

[GS] Rephrased.


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

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


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

[Mališa Vučinić]

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

Post by Jaime Jiménez
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 <https://tools.ietf.org/html/draft-ietf-core-object-security-07>
The WGLC will end by 11th of December.
Best Regards,
- - Jaime Jiménez
_______________________________________________
core mailing list
https://www.ietf.org/mailman/listinfo/core

[Carsten Bormann]

Post by Mališa Vučinić
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

[Mališa Vučinić]

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

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

[Carsten Bormann]

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

_______________________________________________
core mailing list

[Göran Selander]

Hi Mališa,

Great to hear you are progressing with Wireshark for OSCORE!

Answers/comments inline:

From: Mališa Vučinić <***@inria.fr<mailto:***@inria.fr>>
Date: Thursday 14 December 2017 at 14:18
To: "***@ietf.org<mailto:***@ietf.org> WG (***@ietf.org<mailto:***@ietf.org>)" <***@ietf.org<mailto:***@ietf.org>>
Cc: "draft-ietf-core-object-***@ietf.org<mailto:draft-ietf-core-object-***@ietf.org>" <draft-ietf-core-object-***@ietf.org<mailto:draft-ietf-core-object-***@ietf.org>>
Subject: Re: [core] 🔔 WGLC on draft-ietf-core-object-security
Resent-From: <alias-***@ietf.org<mailto:alias-***@ietf.org>>
Resent-To: Göran Selander <***@ericsson.com<mailto:***@ericsson.com>>, John Mattsson <***@ericsson.com<mailto:***@ericsson.com>>, Francesca Palombini <***@ericsson.com<mailto:***@ericsson.com>>, <***@ri.se<mailto:***@ri.se>>
Resent-Date: Thursday 14 December 2017 at 14:18

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.

[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 <***@ericsson.com<mailto:***@ericsson.com>> wrote:

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

_______________________________________________
core mailing list
***@ietf.org<mailto:***@ietf.org>
https://www.ietf.org/mailman/listinfo/core