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

From: Alexey Melnikov <[email-masked]>
Date: Sat, 17 Feb 2018 15:27:49 +0000

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

---

From: Göran Selander <[email-masked]>
Date: Mon, 19 Feb 2018 13:31:12 +0000

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

>option format. Maybe rename the section, as it is not purely about

[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
is about encoding headers, which is also aligned with your other comment:

>COSE_Encrypt0 structure.

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

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

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

[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

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

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

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

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

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

OK, done.

>references it later on in the document, so maybe just move the reference

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

Thanks
Göran

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 19 Feb 2018 14:00:20 +0000

Hi Göran,

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

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

Your new text is better, thank you.

  (snip)

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

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

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

> dummy.

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

>   Furthermore, the destination endpoint would anyway first have to
> would that be an issue in existing networks?
I think unlabelled content is a bad form :-).
>   Who would be able to give
> some advice her?
>
Either of these work for me.

> a remnant from the quote in the previous comment?
Just continuation of the previously quoted text.

---

From: Göran Selander <[email-masked]>
Date: Mon, 19 Feb 2018 17:15:38 +0000

Hi Alexey,

Thanks for quick response, more replies below.

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

>Either of these work for me.

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

Thanks
Göran

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 25 Feb 2018 18:46:56 +0100

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

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