Merged into the github again. Jim -----Original Message----- From: Theresa Enghardt <ietf@xxxxxxxxxxxxx> Sent: Thursday, May 28, 2020 9:24 PM To: Jim Schaad <ietf@xxxxxxxxxxxxxxxxx>; gen-art@xxxxxxxx Cc: draft-ietf-cose-rfc8152bis-struct.all@xxxxxxxx; last-call@xxxxxxxx; cose@xxxxxxxx Subject: Re: [Last-Call] Genart last call review of draft-ietf-cose-rfc8152bis-struct-09 Hi Jim, Thank you for the responses and text changes. Please find replies to some of your points inline, prefixed with "[TE]". Best, Theresa On 27.05.20 19:19, Jim Schaad wrote: > Major issues: > > The intended RFC status is Internet Standard, while RFC 8152 is a Proposed Standard. While this document points to three different implementations, how widespread is their deployment? Were there other lessons learned from implementation and deployment experience? Has complexity been reduced by removing unused features, as RFC 6410 suggests? > > [JLS] This document lists the three most complete implementations of the document that I know about. I am aware of at least nine different implementations of the specification. The rest of them implement a subset of the structures in the document and are not as complete. I am aware of at least two different places where one of my implementations has been adapted to work in a different location. I have had several different jolts where I have learned that COSE is either being used or is planned to be used in different locations. So yes, I believe that there are a number of implementations and the usage of parts of COSE are wide spread. > > [JLS] The only complexity reduction in the document that has been made is to remove the algorithm descriptions from the document and thus shortening the structure document from 120 pages to around 80 pages. The problem with removing any additional items is that some security feature will no longer be available for applications to use. For that reason no features have been removed. [TE] I see. I'm excited to hear about IoT security techniques getting deployed! > Minor issues: > > In the introduction, it would be great to add some more context on how > COSE is intended to be used. Is this solely for adding security to objects within CoAP, e.g., by signing and encrypting messages exchanged as CoAP payload? Or can it be used with other protocols or in other contexts? In RFC 7165, which describes JOSE use cases, Section 5.8.2 mentions Object Security for CoAP. Is COSE addressing this use case? If so, please add a link to Section 5.8.2 of RFC 7165. Section 9.5.4 mentions that COSE "is designed for a store and forward environment rather than an online environment". Perhaps it's worth mentioning such design goals and context in the introduction already. When adding one or two paragraphs on how COSE is intended to be used to the introduction, it's also worth stating explicitly that each application is expected to select the COSE objects and processes that it needs, and that Section 11 provides more guidance on how to do this. This will make it easier for application de velopers to understand how to use COSE. > > [JLS] I have added such a paragraph which you can view in the github version of the document. I did not reference 7165 as you suggested but went directly to the CoRE solutions using COSE instead. [TE] Thank you for adding this paragraph! I find it very helpful to better understand the context and use cases of COSE. Found one typo: "[…] although one can use COSE in and online protocol […]" -> "in an online protocol". [JLS] FIxed > When introducing the CDDL syntaxes: > Is "* label => values" missing here? It appears to be used in some examples below. > > [JLS] I do not believe that this needs to be introduced in the text. The section discusses only a part of CDDL that is used in the document and points to CDDL so that some additional things can be found. The syntax "label=>value" is equivalent to "label: value" but either in a yet to be defined sense or for something which is not a string or number as the label. Given that the text is normative it does not worry me that a complete description of CDDL is not presented here. [TE] Right, I was just wondering if "* label" is similar to "+ label" used in other places. As "[+ FOO]" is introduced in Section 1.4, I was wondering if [* FOO] has to be introduced as well to be consistent. But maybe I'm misunderstanding and these are substantially different? [JLS] Your intuition on this is probably right, '+' is one or more '*' is zero or more. Adding something for '*' does make sense. > In Section 2: > "[...] The wrapping allows for the encoding of the > protected map to be transported with a greater chance that it will > not be altered in transit. (Badly behaved intermediates could > decode and re-encode, but this will result in a failure to verify > unless the re-encoded byte string is identical to the decoded byte > string.) This avoids the problem of all parties needing to be > able to do a common canonical encoding." > I'm not sure I understand this scenario. Does this statement just apply to zero-length maps or to all kinds of protected buckets? What does "to be transported with a greater chance" mean here? That intermediates are less likely to block traffic containing such a COSE object? That intermediates are less likely to accidentally (or deliberately) modify it in such a way that it gets accepted by the receiver? Is this an effect of some cryptographic protection, is it related to different encoding techniques being used in different implementations, or both? Why is it a problem if all parties need to be able to do a common canonical encoding? In fact, what kind of encoding does this refer to: Binary encoding vs. base64 encoding? Or specific ways of encoding certain information as binary data? > > [JLS] I think that you mean section 3 if that is not right please let > me know. The wrapping applies to all encoding of protected buckets. For a zero length bucket this is less of an issue as there is only one way to encode it per the rules in section 10. The issue is that an intermediate entity could decode the message, including the map, and encode it using a slightly different encoding. This normally has to do with the order of items in the map but could be any number of things as the rules for deterministic encoding would need to be expanded to cover all possible CBOR objects rather than just the few that are given in section 10. If one decodes all the way to the data model of CBOR then things such as dates become difficult to encode canonically as it could be encoded either as a floating point number or an integer number. By doing the wrapping all parties doe NOT need to be able to do a common canonical encoding. Experience with ASN.1 and the XML signature security have sh own that the number of times that at least one party is going to get things wrong is much higher than one would like to see for a security protocol that wants to be simple and small. Would starting a new paragraph at this point make it easier to understand that it is nothing to deal with zero-length maps? [TE] You're right, I meant Section 3. And yes, I think starting a new paragraph here would make it easier to understand that this is no longer about the zero-length map. Also, maybe substituting "The wrapping" with something more general helps, because otherwise I'm wondering which part of the previous sentence the "The" refers to. Further, I'm wondering if it's worth adding "accidentally" (or similar wording) to the sentence saying that content is transported "with a greater chance that it will not be altered in transit". As the draft is about security, when reading this I was thinking about an attacker altering a message deliberately, but according to your explanation, this part appears to be more about accidentally altering a message. [JLS] - Ok I will change that. Making it not be deliberate makes sense and I have changed the "The" to be explicit about what it is talking about. [JLS] If an attacker changes the message deliberately then you are dead no matter what. A part of this is left over from the world of S/MIME where transport agents would do things like change the content transfer encoding from 8-bit to 7-bit and thus the message was now different. Not from an attacker, but simply from pulling apart the message looking at it and putting it back together. There are times when I just feel too old because of all of the ancient problems that I still remember as being problems which may longer be ones. Jim -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
