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

[Roman Danyliw <[e-mail]>]

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.
> 
> 
> 
>