Re: [secdir] Secdir last call review of draft-ietf-cose-rfc8152bis-algs-08

[Benjamin Kaduk <[e-mail]>]

Seconded, thanks Nancy and Jim for getting the right updates in place for
the document.
I entered a Discuss ballot only because I tried to follow the [MAC]
reference and got something unexpected -- I want to make sure we've got the
right thing there.

Thanks,

Ben

On Tue, Jun 09, 2020 at 05:36:51PM +0000, Roman Danyliw wrote:
> 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) <[e-mail]>
> > Sent: Friday, May 29, 2020 1:49 PM
> > To: Jim Schaad <[e-mail]>; [e-mail]
> > Cc: [e-mail]; [e-mail]; draft-ietf-cose-rfc8152bis-
> > [e-mail]
> > 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" <[e-mail]> wrote:
> > 
> >     Hi Nancy,
> > 
> >     Comments inline.
> > 
> >     Jim
> > 
> > 
> >     -----Original Message-----
> >     From: Nancy Cam-Winget via Datatracker <[e-mail]>
> >     Sent: Tuesday, May 26, 2020 2:23 PM
> >     To: [e-mail]
> >     Cc: [e-mail]; [e-mail]; draft-ietf-cose-rfc8152bis-
> > [e-mail]
> >     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 &lt;https://github.com/cose-
> > wg/Examples&gt; 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.
> > 
> > 
> > 
> > 
>