Hi Göran, A few select comments: You mention that OSCORE isn't useful to list in Vary. Instead, you should observe that messages that include OSCORE are generally not useful when served from cache (i.e., they will generally be marked Cache-Control: no-cache) and so interaction with Vary isn't relevant. "The HTTP OSCORE header field is not useful in trailers " isn't quite what you need; the point is that because it is critical for message processing, moving it from headers to trailers renders the message unusable in case trailers are ignored. When redirecting, you say: although the condition for this being successful is that the server to which the OSCORE message is redirected needs to be a clone of the server for which the OSCORE message was intended I think that you mean that the target of the redirect has to have the necessary keys. What you have here is too specific. This implies that a proxy is the one the follows the redirect. That's highly irregular in the HTTP world, dangerous even. 3xx responses need to reach the client or you get problems with misattribution. RFC 8075 doesn't mention HTTP redirects at all, so I would have to assume that this is a problem beyond the scope of this draft to fix. Assuming that there is a solution to this problem, you should also observe that some redirects will result in message bodies being removed and that 307 and 308 are recommended over 302/301. On Fri, Mar 30, 2018 at 9:49 PM, Göran Selander <goran.selander@xxxxxxxxxxxx> wrote: >>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 >> >
