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