Subject: [Last-Call] Secdir last call review of draft-ietf-cose-rfc8152bis-algs-08

From: Nancy Cam-Winget via Datatracker <[email-masked]>
Date: Tue, 26 May 2020 14:23:09 -0700

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.

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.

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.

Section 4.2:
- 'k' is the key size in bits (I presume), would be good to describe that
before the table.

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")?

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.

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.

---

From: Jim Schaad <[email-masked]>
Date: Tue, 26 May 2020 19:57:31 -0700

Nancy - one clarification please

jim

-----Original Message-----
From: Nancy Cam-Winget via Datatracker <[email-masked]> 
Sent: Tuesday, May 26, 2020 2:23 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Secdir last call review of draft-ietf-cose-rfc8152bis-algs-08

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 don't think I know which "should" you are talking about.  The word does not exist in that paragraph so I don't know for sure that I have the same number.

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.

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.

Section 4.2:
- 'k' is the key size in bits (I presume), would be good to describe that before the table.

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")?

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.

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.

---

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Thu, 28 May 2020 01:02:38 +0000

Hi Jim,
Apologies for not being more clear, see more context below:

On 5/26/20, 7:57 PM, "Jim Schaad" <[email-masked]> wrote:

    jim
    
    -----Original Message-----
    From: Nancy Cam-Winget via Datatracker <[email-masked]> 
    Sent: Tuesday, May 26, 2020 2:23 PM
    To: [email-masked]
    Cc: [email-masked]; [email-masked]; [email-masked]
    Subject: Secdir last call review of draft-ietf-cose-rfc8152bis-algs-08

    

    
    Section 2.1:
[NCW] The sentence doesn't have a SHOULD though I think the word "suggested" should be stronger; e.g. "In order to promote interoperability, SHA-256 SHOULD be used with curve P-256...."
    
    Section 2.2:
    
    Section 4.1.1:
    
    Section 4.2:
    
    Editorial nits:
    Section 1.5
    
    Section 2.2:
    
    Section 3.1

---

From: Jim Schaad <[email-masked]>
Date: Fri, 29 May 2020 10:22:02 -0700

Hi Nancy,

Comments inline.

Jim

-----Original Message-----
From: Nancy Cam-Winget via Datatracker <[email-masked]> 
Sent: Tuesday, May 26, 2020 2:23 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Secdir last call review of draft-ietf-cose-rfc8152bis-algs-08

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.

[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?

Section 2.2:

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

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.

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'

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>

Section 2.2:
[JLS] See above.

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.

---

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Fri, 29 May 2020 17:48:41 +0000

Hi Jim,
Thanks for addressing the comments!  Answers below:

On 5/29/20, 10:22 AM, "Jim Schaad" <[email-masked]> wrote:

    Hi Nancy,
    
    Comments inline.
    
    Jim

    -----Original Message-----
    From: Nancy Cam-Winget via Datatracker <[email-masked]> 
    Sent: Tuesday, May 26, 2020 2:23 PM
    To: [email-masked]
    Cc: [email-masked]; [email-masked]; [email-masked]
    Subject: Secdir last call review of draft-ietf-cose-rfc8152bis-algs-08

    

    
    Section 2.1:
[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:
    
    [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:
[NCW] Thanks.
    
    Editorial nits:
    Section 1.5
    [NCW] Thank you, I can parse this better.

    Section 2.2:
[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.