Hi Jim,
Apologies for not being more clear, see more context below:
On 5/26/20, 7:57 PM, "Jim Schaad" <[email protected]> wrote:
Nancy - one clarification please
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];
[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 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.
[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:
- 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.
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
