Hi Eric, Thanks for your review. Comments inline. On 2018-02-22 15:32, "Éric Vyncke" <evyncke@xxxxxxxxx> wrote: >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. This has been discussed but no compelling use case were presented so for simplicity this was left out. > >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*. I-D.ietf-ace-oauth-authz is referenced in Section 3.2, but - as you remark below - we should also add the specific reference to I-D.ietf-ace-oscore-profile. There are also other options. Some constrained device deployments provision pre-shared keys which may be used as master secret. There are also two candidate key exchange protocols (draft-selander-ace-cose-ecdhe and draft-mattsson-ace-tls-oscore) but progress has been stalled by a discussion in ACE which protocol is right. >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 The IETF mandates specification of MTI algorithms. >=> 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 use of I-D.ietf-ace-oscore-profile, for example, allows in addition to master secret also the specification of AEAD algorithm and KDF algorithm and other default parameters used to derive the security context. If the device supports more than one AEAD algorithm, a switch can be made with this protocol. As you remark, the real issue is that the device may not support multiple algorithms. > >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... It wasn’t clear to me what the "proposed method” referred to. Are you thinking of receiving endpoints not supporting OSCORE? CoAP (RFC7252 section 5.4.1) specifies the behaviour of a receiving endpoint which does not support the Object-Security option: "Unrecognized options of class "critical" that occur in a Confirmable request MUST cause the return of a 4.02 (Bad Option) response. This response SHOULD include a diagnostic payload describing the unrecognized option(s) (see Section 5.5.2).” The application decides the conditions for which OSCORE is required, and if it invokes OSCORE also needs to handle the case that OSCORE is not supported by the server (which SHOULD become known to the client by the mechanism described above). Do we need to specify something in this respect? >This section should mention how to provision/discover whether the >receiving side (and possibly all the on-path proxies) support OSCORE. As mentioned above, the provisioning of the receiving side is described e.g. in I-D.ietf-ace-oscore-profile. OSCORE is designed to work with proxies which understand or don’t understand OSCORE, providing different functionality. But the protection of messages between endpoints and proxies is not in scope. It can be added by defining a class I option. Or, if endpoints and proxies can be consider to part of a security group, the extension to group communications can be applied (draft-ietf-core-oscore-groupcomm), where the key provisioning is specified in another ACE draft (draft-tiloca-ace-oscoap-joining). Please provide some more details as to what kind of provisioning/discovery mechanisms you are still missing and for what purpose. >Section 9 very briefly mention a 'osc' attribut in a >web link. Yes, that is one way to indicate support for OSCORE. Did you miss anything in this section? > >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 Agreed, as mentioned above. > >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 I hope I have answered these items above, except YANG model: The planned deployments I know of are not using YANG, but if that is required or people are interested we can specify that in a separate draft. Let us know. > >Hope this helps Thanks, Göran
