[core] AD review of draft-ietf-core-object-security-08

[Alexey Melnikov]

Hi,
In order to speed up publication process I initiated IETF LC before
fully completing my AD review. The completed review is below:

In general I found the document to be well written and quite detailed
(which I like). Some smaller issues and a few questions below:

Minor:

1) I found Section 6 to be confusing. There is nothing about payload
compression there. There is also description of the Object-Security
option format. Maybe rename the section, as it is not purely about
compression?

In particular, In Section 6.1: I suggest you explain that
Object-Security option is a more compact encoding of the Headers in the
COSE_Encrypt0 structure. If that is not the case, then I think this
section needs even more work.

2) In Section 8.3, point 3:

If Observe is not used, either the nonce from the
request is used or a new Partial IV is used.

How can the responder decide which of the choices to use? (If this is
covered elsewhere in the document, I would appreciate a reference).

3) In Section 9: Does "osc" target attribute need to be registered with
IANA?

4) In Section 10.1: the reference to [I-D.ietf-core-echo-request-tag]
looks Normative to me, not Informative.

5) In Section 10.2: which media type is used for the OSCORE-encrypted
payload transported in HTTP?


Nits:

In Section 3.3:
To enable retrieval of the right Recipient Context, the Recipient ID
SHOULD be unique in the sets of all Recipient Contexts used by an

Does this SHOULD need a bit more explaining (i.e. why it is not a MUST)?

endpoint. The Client MAY provide a 'kid context' parameter (Section
5.1) to help the Server find the right context.


[I-D.ietf-core-coap-tcp-tls] - this is RFC 8323 now.

First mention of AEAD needs a reference to RFC 5116. The document
references it later on in the document, so maybe just move the reference
earlier.


Best Regards,
Alexey

[Göran Selander]

Hi Alexey,

Thanks for the review, comments/questions inline below.

I updated the draft on the CoRE WG Github based on the review, the commit
is here:
https://github.com/core-wg/oscoap/commit/7656662

The resulting document is here (including also some editorial fixes and
the new Appendix D proposed by the Shepherd):
https://core-wg.github.io/oscoap/draft-ietf-core-object-security.html

Post by Alexey Melnikov
Hi,
In order to speed up publication process I initiated IETF LC before
In general I found the document to be well written and quite detailed
1) I found Section 6 to be confusing. There is nothing about payload
compression there. There is also description of the Object-Security
option format. Maybe rename the section, as it is not purely about
compression?

[GS] Peter van der Stok also commented on this in his review and we made
an update, but maybe this needs to be clarified further. I have changed
the title of the section “OSCORE Header Compression” emphasizing that it

Post by Alexey Melnikov
In particular, In Section 6.1: I suggest you explain that
Object-Security option is a more compact encoding of the Headers in the
COSE_Encrypt0 structure.

[GS] I added the explanation immediately before Section 6.1.

Post by Alexey Melnikov
If Observe is not used, either the nonce from the
request is used or a new Partial IV is used.
How can the responder decide which of the choices to use? (If this is
covered elsewhere in the document, I would appreciate a reference).

[GS] This is discussed in the beginning of section 5, I added the a
reference. (The answer is that the former is recommended, to save message
overhead, but there are non-Observe examples where the Partial IV is
included in a response, see section 7.5.2.)

Post by Alexey Melnikov
3) In Section 9: Does "osc" target attribute need to be registered with
IANA?

[GS] I don’t think so. We mimicked the specification of the “obs” target
attribute from RFC 7641:
https://tools.ietf.org/html/rfc7641#section-6

Post by Alexey Melnikov
4) In Section 10.1: the reference to [I-D.ietf-core-echo-request-tag]
looks Normative to me, not Informative.

[GS] Correct, good catch. However, [I-D.ietf-core-echo-request-tag] (if
approved) updates RFC 7959 (i.e. Blockwise) which is already normatively
referenced, so we don’t have to mention [I-D.ietf-core-echo-request-tag]
at all in this context. I removed the reference.

Post by Alexey Melnikov
5) In Section 10.2: which media type is used for the OSCORE-encrypted
payload transported in HTTP?

[GS] Good question, there are a few things to note here. First, the CoAP
option Content-Format is Inner so the CoAP payload media type is
encrypted. Second, the Outer Content-Format option is not present in
OSCORE protected CoAP messages (in the interest of saving message
overhead). Third, when CoAP-mappable HTTP is protected with OSCORE, the
message is first mapped to CoAP and then processed with OSCORE, so the
media type of the OSCORE encrypted payload is carried in the encrypted
Content-Format option also in the case of HTTP. However, we may still want
to have a Content-Type header field in the HTTP message transporting the
OSCORE message. Was this what you were referring to?

According to RFC 7231
(https://tools.ietf.org/html/rfc7231#section-3.1.1.5):

'A sender that generates a message containing a payload body SHOULD
generate a Content-Type header field in that message unless the
intended media type of the enclosed representation is unknown to the
sender. If a Content-Type header field is not present, the recipient
MAY either assume a media type of "application/octet-stream”
([RFC2046]) or examine the data to determine its type.'


While Content-Type is recommend, noting that in the case of OSCORE we want
to encrypt the Content-Type for the other CoAP endpoint, so whatever media
type we would potentially include in the “Outer” message would only be a
dummy. Furthermore, the destination endpoint would anyway first have to
process the OSCORE message to recreate the HTTP message before handing
over for HTTP processing.

As I read the text above it is possible to leave Content-Type out, but
would that be an issue in existing networks? Who would be able to give
some advice her?

If we decide to include a Content-Type header field, the main options are:

- reuse of "application/cose” defined in RFC 8152 (if appropriate)
- new media type e.g. “application/oscore” to be defined in this draft.


I added a placeholder (TBD) in the draft.

Post by Alexey Melnikov
To enable retrieval of the right Recipient Context, the Recipient ID
SHOULD be unique in the sets of all Recipient Contexts used by an
Does this SHOULD need a bit more explaining (i.e. why it is not a MUST)?

If the Recipient ID is the same for different security contexts (i.e. when
different Master Secrets) this is not a security issue, but the recipient
may have to try multiple security contexts before finding the right (if
any). Therefore it is not mandatory but recommended. I added more
explanation on this.

Post by Alexey Melnikov
endpoint. The Client MAY provide a 'kid context' parameter (Section
5.1) to help the Server find the right context.

Were there any comment on this particular text, or is this snippet it just
a remnant from the quote in the previous comment?

Post by Alexey Melnikov
[I-D.ietf-core-coap-tcp-tls] - this is RFC 8323 now.

OK, done.

Post by Alexey Melnikov
First mention of AEAD needs a reference to RFC 5116. The document
references it later on in the document, so maybe just move the reference
earlier.

OK, I added the reference to the first mentioning of AEAD.


Thanks
Göran

[Alexey Melnikov]

Hi Göran,

Thank you for the updates. I deleted the ones where I am in agreement
and have nothing else to say.

Post by Göran Selander
Hi Alexey,
Thanks for the review, comments/questions inline below.
I updated the draft on the CoRE WG Github based on the review, the commit
https://github.com/core-wg/oscoap/commit/7656662
The resulting document is here (including also some editorial fixes and
https://core-wg.github.io/oscoap/draft-ietf-core-object-security.html

Post by Alexey Melnikov
Hi,
In order to speed up publication process I initiated IETF LC before
In general I found the document to be well written and quite detailed
1) I found Section 6 to be confusing. There is nothing about payload
compression there. There is also description of the Object-Security
option format. Maybe rename the section, as it is not purely about
compression?

[GS] Peter van der Stok also commented on this in his review and we made
an update, but maybe this needs to be clarified further. I have changed
the title of the section “OSCORE Header Compression” emphasizing that it

Post by Alexey Melnikov
In particular, In Section 6.1: I suggest you explain that
Object-Security option is a more compact encoding of the Headers in the
COSE_Encrypt0 structure.

[GS] I added the explanation immediately before Section 6.1.

Your new text is better, thank you.

 (snip)

Post by Göran Selander

Post by Alexey Melnikov
3) In Section 9: Does "osc" target attribute need to be registered with
IANA?

[GS] I don’t think so. We mimicked the specification of the “obs” target
https://tools.ietf.org/html/rfc7641#section-6

Ok. I think it would be good to have an IANA registry for these, but no
need to make your document do that.

Post by Göran Selander

Post by Alexey Melnikov
4) In Section 10.1: the reference to [I-D.ietf-core-echo-request-tag]
looks Normative to me, not Informative.

[GS] Correct, good catch. However, [I-D.ietf-core-echo-request-tag] (if
approved) updates RFC 7959 (i.e. Blockwise) which is already normatively
referenced, so we don’t have to mention [I-D.ietf-core-echo-request-tag]
at all in this context. I removed the reference.

I don't think this works with references. Does implementing RFC 7959
without any knowledge of [I-D.ietf-core-echo-request-tag] be
satisfactory with OSCORE?

Post by Göran Selander

Post by Alexey Melnikov
5) In Section 10.2: which media type is used for the OSCORE-encrypted
payload transported in HTTP?

[GS] Good question, there are a few things to note here. First, the CoAP
option Content-Format is Inner so the CoAP payload media type is
encrypted. Second, the Outer Content-Format option is not present in
OSCORE protected CoAP messages (in the interest of saving message
overhead). Third, when CoAP-mappable HTTP is protected with OSCORE, the
message is first mapped to CoAP and then processed with OSCORE, so the
media type of the OSCORE encrypted payload is carried in the encrypted
Content-Format option also in the case of HTTP. However, we may still want
to have a Content-Type header field in the HTTP message transporting the
OSCORE message. Was this what you were referring to?

Yes. Applications or plugin frequently get invoked based on media types.
So if you want to allow for decoding of OSCORE payloads in a plugin, you
should define a media type.

Post by Göran Selander
According to RFC 7231
'A sender that generates a message containing a payload body SHOULD
generate a Content-Type header field in that message unless the
intended media type of the enclosed representation is unknown to the
sender. If a Content-Type header field is not present, the recipient
MAY either assume a media type of "application/octet-stream”
([RFC2046]) or examine the data to determine its type.'
While Content-Type is recommend, noting that in the case of OSCORE we want
to encrypt the Content-Type for the other CoAP endpoint, so whatever media
type we would potentially include in the “Outer” message would only be a
dummy.

Yes, but it signals to applications that "this payload is OSCORE-encrypted".

Post by Göran Selander
Furthermore, the destination endpoint would anyway first have to
process the OSCORE message to recreate the HTTP message before handing
over for HTTP processing.
As I read the text above it is possible to leave Content-Type out, but
would that be an issue in existing networks?

I think unlabelled content is a bad form :-).

Post by Göran Selander
Who would be able to give
some advice her?
- reuse of "application/cose” defined in RFC 8152 (if appropriate)
- new media type e.g. “application/oscore” to be defined in this draft.

Either of these work for me.

Post by Göran Selander
I added a placeholder (TBD) in the draft.

Post by Alexey Melnikov
To enable retrieval of the right Recipient Context, the Recipient ID
SHOULD be unique in the sets of all Recipient Contexts used by an
Does this SHOULD need a bit more explaining (i.e. why it is not a MUST)?

If the Recipient ID is the same for different security contexts (i.e. when
different Master Secrets) this is not a security issue, but the recipient
may have to try multiple security contexts before finding the right (if
any). Therefore it is not mandatory but recommended. I added more
explanation on this.

Post by Alexey Melnikov
endpoint. The Client MAY provide a 'kid context' parameter (Section
5.1) to help the Server find the right context.

Were there any comment on this particular text, or is this snippet it just
a remnant from the quote in the previous comment?

Just continuation of the previously quoted text.

[Göran Selander]

Hi Alexey,

Thanks for quick response, more replies below.

Post by Alexey Melnikov

Post by Göran Selander

Post by Alexey Melnikov
4) In Section 10.1: the reference to [I-D.ietf-core-echo-request-tag]
looks Normative to me, not Informative.

[GS] Correct, good catch. However, [I-D.ietf-core-echo-request-tag] (if
approved) updates RFC 7959 (i.e. Blockwise) which is already normatively
referenced, so we don’t have to mention [I-D.ietf-core-echo-request-tag]
at all in this context. I removed the reference.

I don't think this works with references. Does implementing RFC 7959
without any knowledge of [I-D.ietf-core-echo-request-tag] be
satisfactory with OSCORE?

[GS] The reference to [I-D.ietf-core-echo-request-tag] in this text
addressed the use of the Request-Tag option together with Blockwise.
Request-Tag is primarily addressing the "Request Fragment Rearrangement
Attack” described in
https://tools.ietf.org/html/draft-mattsson-core-coap-actuators-03#section-2
.5
OSCORE, as well as DTLS, are vulnerable to this attack, so in general
neither are “satisfactory” without it for these use cases.

Hence the reference to [I-D.ietf-core-echo-request-tag] in this section
was as a security update to RFC 7959 (compare section 4.2.3.2 where this
is described in the context of Inner as well as Outer options) but
specification-wise the dependence is between this draft and RFC7959,
including any potential updates of that draft.


Does that make more sense?

Post by Alexey Melnikov

Post by Göran Selander

Post by Alexey Melnikov
5) In Section 10.2: which media type is used for the OSCORE-encrypted
payload transported in HTTP?

[GS] Good question, there are a few things to note here. First, the CoAP
option Content-Format is Inner so the CoAP payload media type is
encrypted. Second, the Outer Content-Format option is not present in
OSCORE protected CoAP messages (in the interest of saving message
overhead). Third, when CoAP-mappable HTTP is protected with OSCORE, the
message is first mapped to CoAP and then processed with OSCORE, so the
media type of the OSCORE encrypted payload is carried in the encrypted
Content-Format option also in the case of HTTP. However, we may still want
to have a Content-Type header field in the HTTP message transporting the
OSCORE message. Was this what you were referring to?

Yes. Applications or plugin frequently get invoked based on media types.
So if you want to allow for decoding of OSCORE payloads in a plugin, you
should define a media type.

Post by Göran Selander
According to RFC 7231
'A sender that generates a message containing a payload body SHOULD
generate a Content-Type header field in that message unless the
intended media type of the enclosed representation is unknown to the
sender. If a Content-Type header field is not present, the recipient
MAY either assume a media type of "application/octet-stream”
([RFC2046]) or examine the data to determine its type.'
While Content-Type is recommend, noting that in the case of OSCORE we want
to encrypt the Content-Type for the other CoAP endpoint, so whatever media
type we would potentially include in the “Outer” message would only be a
dummy.

Yes, but it signals to applications that "this payload is
OSCORE-encrypted".

Post by Göran Selander
Furthermore, the destination endpoint would anyway first have to
process the OSCORE message to recreate the HTTP message before handing
over for HTTP processing.
As I read the text above it is possible to leave Content-Type out, but
would that be an issue in existing networks?

I think unlabelled content is a bad form :-).

Post by Göran Selander
Who would be able to give
some advice her?
- reuse of "application/cose” defined in RFC 8152 (if appropriate)
- new media type e.g. “application/oscore” to be defined in this draft.

Either of these work for me.

[GS] OK, I’ll make a separate thread on that.

Thanks
Göran

[Carsten Bormann]

Post by Alexey Melnikov
3) In Section 9: Does "osc" target attribute need to be registered with
IANA?

Some more details about this one:

RFC 5988 decided not to create a registry for link target attributes, and its replacement, RFC 8288, sustained this decision.

RFC 6690 went ahead and defined two sub-registries for *values* of the link target attributes “rt” and “if”. Still, the target attribute names themselves are registered nowhere.

A 6690bis effort may very well want to create a registry here, now that RFC 8288 says about Target Attributes (Section 2.2):

They can be defined both by individual link relation types and by
link serialisations.

This specification does not attempt to coordinate the name of target
attributes, their cardinality, or use. Those creating and
maintaining serialisations SHOULD coordinate their target attributes
to avoid conflicts in semantics or syntax and MAY define their own
registries of target attributes.

So, in addition to individual link relation types, RFC6690 or a successor specification, as a serialization of Web Links, is the place where such a registry could be defined.

Until that happens, OSCORE is exactly right in proceeding in the same way RFC 7641 (Observe) did for “obs”.

Grüße, Carsten