Hi Nancy, thank you for this review. Hi Jim, thank you for incorporating the feedback in -09
I entered a No Objection ballot. Regards, Roman > -----Original Message----- > From: Nancy Cam-Winget (ncamwing) <[email protected]> > Sent: Friday, May 29, 2020 1:49 PM > To: Jim Schaad <[email protected]>; [email protected] > Cc: [email protected]; [email protected]; draft-ietf-cose-rfc8152bis- > [email protected] > Subject: Re: Secdir last call review of draft-ietf-cose-rfc8152bis-algs-08 > > Hi Jim, > Thanks for addressing the comments! Answers below: > > On 5/29/20, 10:22 AM, "Jim Schaad" <[email protected]> wrote: > > Hi Nancy, > > Comments inline. > > Jim > > > -----Original Message----- > From: Nancy Cam-Winget via Datatracker <[email protected]> > Sent: Tuesday, May 26, 2020 2:23 PM > To: [email protected] > Cc: [email protected]; [email protected]; draft-ietf-cose-rfc8152bis- > [email protected] > Subject: Secdir last call review of draft-ietf-cose-rfc8152bis-algs-08 > > Reviewer: Nancy Cam-Winget > Review result: Has Nits > > IOTDIR review of draft-ietf-cose-rfc8152bis-algs-08 > > Reviewer: Nancy Cam-Winget > > I have reviewed this document as part of the security directorate'sÊ > ongoing > effort to review all IETF documents being processed by theÊ IESG.ÊÊThese > comments were written primarily for the benefit of theÊ security area > directors.ÊÊDocument editors and WG chairs should treatÊ these comments > just like any other last call comments. > > This document describes an initial set of cryptographic algorithms used to > protect CBOR, I believe this document is almost ready, barring some editorial > nits (I only made a few below). In general, the description of the "initial" > set of algorithms used in COSE make sense and it is good to see each > section > carry their own security section for better mapping of the considerations > based > on the security algorithm applied. As a reader (like myself) who is not fully > versant to the nuances of CBOR it was a little hard to follow as the > structures > and taxonomy is described in the companion draft (draft-ietf-cose-rfc8152bis- > struct). As a whole, I think the document is close to ready, I only noted a > few > technical and editorial nits for the earlier sections below: > > Section 2.1: > - What field does the ECDSA algorithm value map to? I presume it is the > 'alg' > field (if present)? But should be made explicit. - It seems that the > "should" > in the 4th paragraph is normative (e.g. SHOULD) as it is needed for > interoperability, and perhaps even a MUST as I'm not seeing negotiation or > selection of curve choice. So, if it is to be implicit, then a MUST would be > more > appropriate. > [JLS] I have added text to section 1.3 (terminology) to describe the > contents > of the tables to make what the value is clearer. > [NCW] Thanks, that will help. > > [JLS] There is no need to negotiate the curve as this is implicit from > the size > of the signature. That is P-256 is going to end up with two 256-bit values as > the signature. One implication is that only a single curve of any given > length > can be assigned to ECDSA, thus the effort to use the Ed25519 curve with ECDSA > requires a different identifier so that there is no confusion on what curve is > being used. This means that the length of the hash algorithm is not part of > this > selection process. It is therefore possible to use SHA-256 with P-521 and > SHA- > 512 with P-256 (the hash value is truncated in this case). The only issue is > that > if a piece of hardware supports the P-256 curve then it might only support > SHA- > 256 and thus would not be able to validate a signature that uses SHA-512. > There is no special security issue here, this is just a recommendation for > making > things more likely to succeed. This is the reason that it is not a 'SHOULD' or > 'MUST' but is an 'suggested'. Does this both make things clearer and reduce > the feeling on you part that a stronger statement is needed? > [NCW] Agree that there is no security issue, it was more of breaking > interoperability. I don't feel strongly either way, it was by the way it > reads....if > you want to ensure interoperability the it seems that stronger language would > be needed (but that’s my personal bias). > > Section 2.2: > - The rationaleThere may be some corner case in which there may be a very > large > (2K?) structure to be protected. It would be better to quantify > "extremely > large" or perhaps another/additional rationale for the need to ONLY do Pure > edDSA is the intent for constrained devices not have enough memory to > compute the block updates. > > [JLS] I don't know that I would consider a 2K message to be very large, I > would expect a firmware update to be at least that large. The issue is that > EdDSA needs to do two passes over the message, this means that the entire > message needs to be held in memory. That would be limitation on what I > would consider to be "extremely large". The presumption is that one is not > going to try and create and stream the object out as this would also require a > streaming processing on the recipient. If streaming is removed from the > equation then there is no benefit not to use Pure EdDSA. This means that > ones > idea of large is going to be very device specific. I will not be surprised > if some > firmware packages do indirect signing, but the manifest description is still > going > to need to fit in memory. > [NCW] 2Kbytes can seem very large to some IoT devices __. But your point is > well taken...sorry if I was too nit-picky....as for guidance I personally > prefer to > have quantification (ranges). > > Section 4.1.1: > - GCM's limitation for one encryption string is 2^39-256 e.g. not "a > single > key"....so sufficiently large for COSE! However, it does mean that the nonce > MUST be unique for every encrypted message (e.g. the bullet before this one is > correct). I think the limit for one key using GCM is based on the size of the > nonce as it must be unique. > [JLS] You are going to make me look this up again. However I think that > this > limit may end up being smaller with more modern analysis so going back and > re--checking this is going to be worthwhile. It just will take a few days. > [NCW] No worries, as an early adopter of GCM, I do recall that number being > for a packet.... > > Section 4.2: > - 'k' is the key size in bits (I presume), would be good to describe that > before > the table. > [JLS] I changed the title of the column to 'Key Length' > [NCW] Thanks. > > Editorial nits: > Section 1.5 > - The second sentence is hard to parse. Is it that the intermediate > values > used for debugging are represented in both a hex as well as a CBOR diagnostic > notation format"? - Third sentence, is it that some examples were designed to > fail (e.g. they are "failure test bases")? > [JLS] I have updated this section. I think that this should solve your > issues. > <t> > A GitHub project has been created at > <https://github.com/cose- > wg/Examples> that contains a set of testing examples as well. > Each example is found in a JSON file that contains the inputs > used to > create the example, some of the intermediate values that can be used for > debugging, and the output of the example. > The results are encoded using both hexadecimal and CBOR > diagnostic > notation format. > </t> > <t> > Some of the examples are designed to test failure case; these > are > clearly marked as such in the JSON file. > If errors in the examples in this document are found, the > examples on > GitHub will be updated, and a note to that effect will be placed in the JSON > file. > </t> > [NCW] Thank you, I can parse this better. > > Section 2.2: > - The rationale for why Pure EdDSA is used only (vs. HashEdDSA) may leave > more room for questions; as there may be some corner case in which there may > be a very large (2K?) structure to be protected. For those that are in the > healthcare sector (of IoT), I could see potential for large blocks and may > wonder > what qualifies as "extremely large". RFC 8032 speaks to HashEdDSA as > providing better collision resilience...so am inclined to suggest to either > remove > this rationale or be more complete in justification. > [JLS] See above. > [NCW] OK > > Section 3.1 > - 3rd paragraph: "Some recipient algorithms carry the key while others > derive > a key from secret data"....I think you mean "Some algorithms are used to > transmit a key, e.g. key wrapping." "Carry the key", in this sentence leads > me > to imply it's the same key being used in the HMAC. > [JLS] This is the same key that is being used in the HMAC algorithm. I > have > changed "carry" to "transport" because I think that is going to be clearer. > [NCW] Yes, indeed, that makes it better. > > > > _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
