[core] Opsdir telechat review of draft-ietf-core-object-security-08
Éric Vyncke <evyncke@cisco.com> Thu, 22 February 2018 14:32 UTC
Return-Path: <evyncke@cisco.com>
X-Original-To: core@ietf.org
Delivered-To: core@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C350212EADA; Thu, 22 Feb 2018 06:32:07 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Éric Vyncke <evyncke@cisco.com>
To: ops-dir@ietf.org
Cc: draft-ietf-core-object-security.all@ietf.org, ietf@ietf.org, core@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.72.2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151930992776.8232.15713995276934864913@ietfa.amsl.com>
Date: Thu, 22 Feb 2018 06:32:07 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/VWQephoRNbBzP7MaUWi-iiTZE7M>
Subject: [core] Opsdir telechat review of draft-ietf-core-object-security-08
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.22
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Feb 2018 14:32:08 -0000
Reviewer: Éric Vyncke Review result: Has Issues 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
- [core] Opsdir telechat review of draft-ietf-core-… Éric Vyncke
- Re: [core] Opsdir telechat review of draft-ietf-c… Göran Selander