Re: [secdir] secdir review of cose-msg-18

Jim Schaad <ietf@augustcellars.com> Thu, 22 September 2016 01:57 UTC

Return-Path: <ietf@augustcellars.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB14312C0C3 for <secdir@ietfa.amsl.com>; Wed, 21 Sep 2016 18:57:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.217
X-Spam-Level:
X-Spam-Status: No, score=-4.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0r-J0gEbe-TX for <secdir@ietfa.amsl.com>; Wed, 21 Sep 2016 18:57:20 -0700 (PDT)
Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B70212BC7B for <secdir@ietf.org>; Wed, 21 Sep 2016 18:57:20 -0700 (PDT)
Received: from hebrews (192.168.1.152) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 21 Sep 2016 19:10:35 -0700
From: Jim Schaad <ietf@augustcellars.com>
To: 'Stephen Kent' <kent@bbn.com>, 'secdir' <secdir@ietf.org>, 'Justin Richer' <jricher@mit.edu>, 'Kepeng Li' <kepeng.lkp@alibaba-inc.com>, 'Kathleen Moriarty' <Kathleen.Moriarty.ietf@gmail.com>
References: <33a10112-ee91-75df-a390-1c7c2a23a729@bbn.com>
In-Reply-To: <33a10112-ee91-75df-a390-1c7c2a23a729@bbn.com>
Date: Wed, 21 Sep 2016 18:57:10 -0700
Message-ID: <081e01d21474$a3db8440$eb928cc0$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQLn+ErX890UkhHKZArMVoO8r82N055Y1HMw
Content-Language: en-us
X-Originating-IP: [192.168.1.152]
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/YqudvVQDQMVBsAE6g0fwH2bskIY>
Subject: Re: [secdir] secdir review of cose-msg-18
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Sep 2016 01:57:23 -0000

Changes marked 'done' have been integrated on github.

Jim


From: Stephen Kent [mailto:kent@bbn.com] 
Sent: Wednesday, September 21, 2016 7:27 AM
To: secdir <secdir@ietf.org>; Jim Schaad <ietf@augustcellars.com>; Justin Richer <jricher@mit.edu>; Kepeng Li <kepeng.lkp@alibaba-inc.com>; Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com>
Subject: secdir review of cose-msg-18

SECDIR review of draft-ietf-cose-msg-18
 

Typos and suggested rewording.
 
Section 2: 
 
The COSE object structure is designed so that there can be a large amount of common code when parsing and processing the different
security messages.
 -> The COSE object structure is designed so that there can be a large amount of common code when parsing and processing the different types of security messages.

done
 
COSE messages are also built using the concept of using layers to … 
-> COSE messages are built using the concept of layers to …

done
 
Section 3:
 
The integer and string values for labels has been divided …
 -> The integer and string values for labels have been divided …

done
 
Applications SHOULD perform the same checks that the same label …
-> Applications SHOULD verify that the same label …

done
 
Applications should have a statement if the label can be omitted.
-> Applications SHOULD (?) have a statement if the label can be omitted.

[JLS] I believe that lower case is correct here.  This would not be a requirement on the COSE protocol, but on the application that is using COSE.  It does not make sense to me to have 2119 language for this type of statement.  (Partly from an initial brow beating from Russ.)
 
Integers are from the "CoAP Content-Formats" IANA registry table. (no reference)

[JLS] What do you think should be referenced here?  Are you looking for a URL to iana.org?  Not sure that this makes sense.
 
As the IV is authenticated by the encryption process, it can be placed in the unprotected header bucket. (in general, an encryption process will not “authenticate” an IV, but use of a modified IV will yield mangled plaintext, which can be detected by an integrity check or a signature. the same comment applies to the similar statement in the “partial IV” description.)
 
[JLS] Does this work?

The IV can be placed in the unprotected header as modifying the IV will cause the decryption of the plaintext to fail.

 
Section 4:
 
Edwards Digital Signature Algorithm (EdDSA) signature algorithm and with the Elliptic Curve Digital Signature Algorithm (ECDSA) signature algorithm.
-> Edwards Digital Signature Algorithm (EdDSA) (cite) and with the Elliptic Curve Digital Signature Algorithm (ECDSA) (cite).

[JLS] I think it is excessive, but done.

 
One of the features supplied in the COSE document is the ability…
-> One of the features offered by the COSE format is the ability …

done
 
This algorithm takes in the body information …
-> The signing and verification processes take in the body information …

done
 
Counter signatures provide a method of having a different signature occur on some piece of content.
-> Counter signatures provide a method of associating different signatures generated by different signers with some piece of content.

done
 
 
Section 5
 
Other:  The key is randomly generated.
-> Other:  The key is randomly or pseudo-randomly generated.
 
done
 
Section 6
 
(This knowledge of sender assumes that there are only two parties involved and you did not send the message yourself.)
-> (This knowledge of sender assumes that there are only two parties involved and you did not send the message to yourself.)
 
done
 
Section 15:
 
It is intended that a profile of this document be created that
defines the interopability
-> It is intended that a profile of this document be created that
   defines the interoperability

done