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. # 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. 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. # 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. # 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. 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? The introductory parts of Section 10.2 are very hard to read. 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. 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. What if the request is redirected by a server that doesn't understand OSCORE? 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. The new header field needs [A]BNF. 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. 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. # Linking Section 9 would benefit from an example. Greatly. It took me a while to understand the intent of this mechanism. 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. 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. 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. # Examples The examples in Section 6.3 are incomprehensible to me. What is the message you are sending? Is it already protected? 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. The appendices are much better.
