>Hi Martin, > > >Thanks for good comments. Version -12 submitted. Replies inline labelled >[GS]. > > >On 2018-03-08 03:14, "ietf on behalf of Martin Thomson" ><ietf-bounces@xxxxxxxx on behalf of martin.thomson@xxxxxxxxx> wrote: > > >I have a number of concerns. Primarily: > > >* This is only a partial solution. > > >* This is yet another solution for an existing problem with existing >solutions. > > >* This doesn't appear to have any supporting security analysis. > > >* This is another protocol that abuses of HTTP by tunneling over it. > > >I also have a bunch of minor concerns and questions. > > > > ># Incomplete Solution > > >This is an incomplete solution, neglecting to address important and >difficult parts of the problem like key exchange. If the working >group (or groups) intends to work on those more difficult problems, it >should do that and present a coherent solution. I appreciate that big >problems are more tractable when broken down, but it's not clear how >this fits into a bigger picture. The most mature seems to be the ACE >profile in >draft-ietf-ace-oscore-profile-00, but the draft references two other >individual drafts as well. Each presents a different interaction >model. If the intent is to allow for many options, that makes >analysis harder. > > >[GS] Pre-shared keys will be used in IoT deployments for performance >reasons for time to come. We have included a recommendation for forward >secrecy, but repeated key exchanges are not possible for all IoT >scenarios. A key exchange protocol for OSCORE is a separate activity. >Each option needs to show its feasibility to adequately address the use >cases as well as its use with OSCORE. > > > > ># Security Analysis > > >I'm not going to go into the details of the various security claims or >mechanisms here, except to note that there is no reference to a >security analysis of this work, which makes me extremely nervous. >Even with the level of analysis that TLS 1.3 got, there were still a >few occasions when new tools or perspectives revealed new issues. If >there is some analysis, citations are necessary. > > >[GS] There is a new appendix D giving an overview of the security >properties. >This appendix is not addressing a future key exchange protocol but the use >of COSE_Encrypt0 with an AEAD as specified in the draft. > > >If this depends on EDHOC or something else, then any analysis should >cover that as well or be very clear about stating assumptions. Too >many times we've received an analysis that made assumptions that >didn't line up with the properties of the overall system, and that >leaves holes. > > >[GS] There is no dependency on EDHOC. > > ># High Level Concerns > > >This document continues the trend of building specialized solutions >for constrained endpoints rather than find ways to improve existing >solutions or provide generic capabilities. This time, the problem is >end-to-end security. > > >This is a partial implementation of TLS - the record layer essentially >- with the hard parts deferred to another document and tight >integration with COAP. Presumably that makes messages smaller, but >given the non-existent overlap between outer and inner messages, I >suspect that this isn't true. DTLS has a 3+auth-tag octet overhead, >and the best examples here are less efficient than that. > > >The ATLAS proto-group is taking yet another approach. Maybe we should >be having a discussion about XKCD 927 here (it would only be the >second in 24 hours for me). > > >One potential reason for a new design is the involvement of >intermediaries in the protocol and the need to route messages via >those intermediaries. But this design actively works against any such >involvement. > > >[GS] The new appendix D is hopefully doing a better job in explaining the >end-to-end security setting and the assumed role of the intermediaries. > > > > ># HTTP Use > > >This turns COAP from something that sort-of translates into HTTP to >something that abuses it by treating it as a simple tunnel. I guess >that it turns COAP into something that abuses COAP as well if it comes >to that. > > >[GS] OSCORE is using CoAP in two ways: the inner/end-to-end encrypted >message which is using CoAP and essentially all its features and >extensions, and the outer/transport message which is only using a limited >set of the CoAP functionality but which complies with most of its >features and extensions. > > >The use of HTTP was introduced on request to address certain end-to-end >REST settings e.g. HTTP client to CoAP server, where the HTTP client is >assumed to know how to map a (CoAP-mappable) HTTP request into CoAP (RFC >8075) as well as OSCORE. In this setting at the core of the inner message >is a translated HTTP message. So, while not taking advantage of all HTTP >features this construction is doing more than a simple tunnelling. > > > > > I would encourage folks to read > >http://httpwg.org/http-extensions/draft-ietf-httpbis-bcp56bis.html#getting > -value-from-http for context. Why is a simpler substrate not possible? > > >[GS] I don’t know what that simpler substrate would be given the use case >above. > > > > >The introductory parts of Section 10.2 are very hard to read. > > > > >[GS] Admittedly, there were several details on HTTP missing and we are >grateful >for this review. The HTTP related sections are now restructured and >more details are provided. > > > > >For >instance, I can't parse this: > > > All field semantics is given within the CoAP-Object-Security header >field. > > >That applies to the bulk of the introductory material. The actual >process is quite clear, thanks. > > >[GS] The introductory parts are rephrased. > > > > >This is not true: > > > Intermediaries are not allowed to insert, delete, or modify the > field's value. The header field is not preserved across redirects. > > >The point here is that the message that is sent is integrity >protected, so the intermediary can't modify the message without >detection. > > >[GS] This was not intended as a statement of integrity, but as a >statement of what an intermediate is expected to do according to >instructions about >required documentation related to the new HTTP header field. We have >tried to clarify that. > > > > >What if the request is redirected by a server that doesn't understand >OSCORE? > > >[GS] Please see the updated description. > > >Requiring the use of the empty string as the value of an HTTP header >field is a good way to lose header fields. Many intermediaries - and >stacks in general - silently discard such a header field. If the >intent is to literally include two double quotes, say that very >clearly; the presentation makes it hard to know exactly what bits are >expected. The examples don't help by adding " (empty string)", which >might be interpreted as being part of the value. > > > > >[GS] Yes, thanks, this is changed to AA. > > > > >The new header field needs [A]BNF. > > >[GS] Agreed, included. > > > > >A new media type is defined, but I don't see any mention of a >codepoint for use with COAP and none of the examples show that media >type in use. > > >[GS] This has been discussed on the CORE WG mailing list and in the f2f >meeting. We don’t have a show-stopping use case for this codepoint at the >moment, but have anyway included it in -12 for potential future use cases. > > > > >Is the expectation that a COAP-HTTP gateway understands the >significance of the new header field and insert the media type when >translating? That seems like a stretch. > > > > >[GS] Since the CoAP-HTTP gateway must understand OSCORE to make the >correct translation, it would know when to insert the media type. So, >indeed, this is assumed. > > > > ># Linking > > >Section 9 would benefit from an example. Greatly. It took me a while >to understand the intent of this mechanism. > > >[GS] A simple example is added. > > >RFC 8288 doesn't define a registry for target attributes. That seems >like a major problem here if the intent is to avoid accidental >bustage. "osc" is very low entropy and therefore prone to collisions, >and the net effect of making links unusable isn't an outcome that will >be expected. > > >[GS] This is a copy of a corresponding text in RFC 7641. We think that >this is not for OSCORE to solve. Please see: > https://mailarchive.ietf.org/arch/msg/core/yLGC6quPw7SmOmmkjz3L1pIDNJ4 > > > > >If the user of a link is expected to acquire a security context from >somewhere without the link relation providing any help, I question the >value of this annotation. If the intent is to mark resources >off-limits for clients that don't have keys, then that's one thing, >but the document doesn't establish what the expectations are regarding >OSCORE requirements on a resource. Is it is supported *in addition >to* unprotected access or does "osc" mean that OSCORE is necessary for >accessing that resource. The draft says the link "is to be accessed >using OSCORE", which hints that it is the latter, but it needs to be >very crisp. > > >[GS] Ok, thanks for the comment. We did try to improve the text so that, >as you guessed, the mean is the latter. Now the text reads: >The "osc" attribute is a hint indicating that the destination of that >link is only accessible using OSCORE, and unprotected access to it is >not supported. > > > > >I also don't see the path from here to using EDHOC/other for a >resource thus marked, if that is indeed an expected part of the bigger >picture. I have questions of scope of applicability of EDHOC and the >ACE profile that would result from that sort of key agreement, but >that can wait. > > >[GS] OK, let’s get back on that in the context of those protocols. > > > > ># Examples > > >The examples in Section 6.3 are incomprehensible to me. What is the >message you are sending? Is it already protected? > > > > >[GS] The examples are intended to how the COSE_Encrypt0 object is >compressed and divided into OSCORE option and payload. >In -11 some of the examples missed the "Before compression” part which is >now included. Hope that makes more sense. > > > > >Similarly, I can't see how you can fit the request you claim to be >making into the examples in Section 10.3. You don't describe the AEAD >that is in use, or what keys. > > >[GS] This is now section 11.5 and 11.6. These are not test vectors, the >examples are intended to illustrate the translation of message fields. We >have tried to clarify that. > > >The appendices are much better. > > > >Again, thanks for good comments! > > >Göran >
