Telechat Review of draft-ietf-core-object-security-08
review-ietf-core-object-security-08-opsdir-telechat-vyncke-2018-02-22-00

Hello,

I am the assigned OPS-DIR reviewer for this draft. The OPS DIrectorate reviews
a great part of the IETF documents being processed by the IESG for the OPS ADs.
Please treat with these comments as with all other IETF LC comments. Please
wait for direction from your document shepherd or AD before posting a new
version of the draft.

This document defines a method for application-layer protection of CoAP called
OSCORE, re-using CORE (RFC8152) for protection and designed for constrained
nodes. It is specifically designed to avoid clear-text access by TLS proxies.

_Please note that I am not following the CORE WG so some candid comments may be
uneducated._

As a side note, I wonder why the AEAD algorithm is in the common security
context as it prevents using different crypto algorithm for the two directions
of the traffic.

Section 3.2 states that the master secret shall be pre-established but *does
not give any hint on how to provision this master secret*.

Section 4.2 defines the behavior when new CoAP fields/options will be
specified. Which is good of course for the future operations.

The draft specifies a mandatory AEAD algorithm to be implemented => I am afraid
when this algorithm will become less secure, a revised version of this I-D will
be published but let's hope that the devices will be able to be upgraded...
(this issue is obviously out of scope for this document)

The OSCORE message contains a version which is good for future versions.

Section 8 does not discuss the situations when the receiving endpoints does not
support the proposed method... This section should mention how to
provision/discover whether the receiving side (and possibly all the on-path
proxies) support OSCORE. Section 9 very briefly mention a 'osc' attribut in a
web link.

The establishement of security context is very succinctly described in section
11.2 which refers to section 3.2 which does not specify how to provision this
master secret. It would be useful to refer to I-D.ietf-ace-oauth-authz and
I-D.ietf-ace-oscore-profile in section 3.2

In short my concerns are:
- no description of the master secret provisioning (or is a reference to
draft-ietf-ace-oauth-authz enough?) - no YANG model for provisioning (or is
there an I-D for this in writing?) - no description how crypto algorithms can
be negociated

Hope this helps

-éric