Telechat Review of draft-ietf-core-object-security-08

Request Review of draft-ietf-core-object-security
Requested rev. no specific revision (document currently at 16)
Type Telechat Review
Team Ops Directorate (opsdir)
Deadline 2018-03-06
Requested 2018-02-15
Authors Göran Selander, John Preuß Mattsson, Francesca Palombini, Ludwig Seitz
Draft last updated 2018-02-22
Completed reviews Opsdir Telechat review of -08 by Éric Vyncke (diff)
Genart Last Call review of -08 by Joel Halpern (diff)
Secdir Last Call review of -14 by Daniel Migault (diff)
Genart Last Call review of -13 by Joel Halpern (diff)
Genart Last Call review of -14 by Joel Halpern (diff)
Assignment Reviewer Éric Vyncke 
State Completed
Review review-ietf-core-object-security-08-opsdir-telechat-vyncke-2018-02-22
Reviewed rev. 08 (document currently at 16)
Review result Has Issues
Review completed: 2018-02-22



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