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

Jim Schaad <ietf@augustcellars.com> Wed, 21 September 2016 23:52 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 B153812B7FC for <secdir@ietfa.amsl.com>; Wed, 21 Sep 2016 16:52:55 -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=unavailable 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 vxaUxUhI_KbJ for <secdir@ietfa.amsl.com>; Wed, 21 Sep 2016 16:52:53 -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 7B13012B56A for <secdir@ietf.org>; Wed, 21 Sep 2016 16:42:58 -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 16:56:12 -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 16:42:48 -0700
Message-ID: <080101d21461$de39f850$9aade8f0$@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+ErX890UkhHKZArMVoO8r82N055YgYfQ
Content-Language: en-us
X-Originating-IP: [192.168.1.152]
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/RwxGw3U56PWiLcBgBMZiRf7USCA>
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: Wed, 21 Sep 2016 23:52:55 -0000

Hi Steve,

Good to hear from you again.  I will be doing a second message on the nits so that I can make them at the same time that I do the response.

It is always good to have a comprehensive and useful review and one with action items. Thanks for that

Comments in line

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
 
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 with the intent of improving security requirements and considerations in IETF drafts.  Comments not addressed in last call may be included in AD reviews during the IESG review.  Document editors and WG chairs should treat these comments just like any other last call comments.
 
This document defines formats for signing and/or encryption of data encoded using CBOR (RFC7049). The signing/encryption approach adopted here is based on the standards developed in JOSE (RFCs 7515-18), since CBOR is based on JSON. 
 
This is a large document: about 90 pages plus almost 30 pages of appendices (providing useful examples).  Close to half of the (non-appendix portion) document is devoted to specifications for a set of algorithms for encryption, signatures, message authentication, and key distribution. Only when the reader reaches page 73 is it made clear that the algorithm descriptions are not MTI; they define a set from which application developers must (?) choose when creating a profile for COSE use in a specific application context. Given the long-standing IETF policy to trying to facilitate algorithm agility,  
I think it preferable to extract these descriptions and publish them as separate RFCs, a practice often employed in documenting many other security protocols (including JOSE, from which this work is based). 

[JLS] This was the approach that I had originally intended to take, breaking the document in two pieces towards the end when things were settled.  My memory is that this was discussed in the working group, and it was determined that one document was preferable to having two different documents.  I believe that this practice started with CMS and it was done there to deal with the question of how to advance to standards track for the format document and still allow the algorithm document to be updated.  This has not seemed to be how things have worked in practice, or has been necessary as protocol documents such as S/MIME is where the implementation requirements on algorithms are specified rather than in the format draft (CMS).  I therefore have less problems with the fact that this is one draft from that standpoint.  It would have been nicer just from a length prospective, but people thought that being able to reference back and forth in a single HTML page to be better than flipping between different pages.

 
Since there is no standard grammar for CBOR, the author adopted the primitive types defined in an I-D (draft-ietf- greevenbosch-appsawg-cbor-cddl) to allow for a concise specification of COSE formats. I recommend that this document be held for publication until that I-D is approved. I also note that the cited I-D is Informational, but this document is Standards Track. the cited I-D is listed as informative, but the syntax it defines is used extensively throughout this document, thus I believe it really is normative.

[JLS]  There was a long discussion about what to do with the CDDL grammar portions of the document.  Like me, it would appear that you are a strong advocate of doing formal languages and making them normative rather than making descriptive text normative.  Given the state of CDDL making it a normative reference would be difficult since it is still being transformed.  I have argued with the authors to try and get what is there published but have not been successful.

During the discussion there were several versions where presented as alternatives.
* The current mixing of CDDL and text
* Moving the CDDL to the end of the section that it relates to 
* Moving the CDDL to an appendix
* Removing the CDDL entirely.

I argued against the last option as I find formal language to be useful.  As I placed the CDDL in line to start with as it makes it easier to validate the language and the text as being the same that became somewhat of the baseline, however at least one version of the document moved all of the CDDL to the end of the section so people did have a change to see what that would look like.  After much discussion, the group decided that it wanted to keep the current format as they did not like having it at the end of the section.  

The draft is cited as informative because the document states that the text description is to be normative and there is a full duplication of the CDDL in the text.  One can remove the CDDL and a complete description of how to encode things is still I the document.

 
 
Section 2 defines the basic COSE data structure. The description seems clear and logical, but the list of message types is a bit puzzling (absent information that is provided later, in Sections 4 and 5). For example, there is a Single Signer data Object, and a Signed Data Object. If the latter accommodates multiple signers, why not make that part of the name? The same nomenclature confusion arises for encrypted objects directed to a single recipient vs. multiple recipients.

[JLS] I thought about making this change in the past but had an issue with the fact that this might make people think that the Signed Data object version could only be used if there were two or more signers.  It allows for one or more signers so it is a bit of a misnomer to say that it is a multiple signer version.  The structures are build in such a way that one cannot switch between the versions so you cannot just go from the Single Signer to the Multiple Signer when a second signature is added.

I can understand the issue you are raising, but the solution has similar issues.  The term "One or More Signer Data Object" seems to be a bit unwieldy.  Other suggestions would be welcome.


 
Section 4 describes the objects used to convey one or more signatures for objects. The description here is a bit confusing when it discusses one vs. multiple signatures. The format that allows carriage of multiple signatures does not necessarily imply that there are multiple signers, e.g., the multiple signatures may be present to accommodate different algorithm capabilities for different recipients. The introduction to 4.2 says: 
	“The COSE_Sign1 signature structure is used when only one signer is going to be placed on a message.”
Perhaps it would be clearer to say that this structure is used when only one signature is to be placed in a message.

[JLS] Makes sense - done.

 
 
Section 5 describes the COSE encryption objects. I disagree with one choice of terminology adopted here: “recipient algorithm classes” which is described in 5.1.1. This is really a discussion of classes of key distribution/management algorithms, focusing on how each recipient of an encrypted message acquires the CEK used to decrypt the message. I’d prefer a less obscure name for this sub-section. Otherwise this section is well written and provide lots of useful details about how to encrypt and decrypt messages for two classes of encryption algorithms.

[JLS] I agree that the term is not optimal.  There was a long discussion about this in the WG on the mailing list.  The original term used was "key management classes" (if memory serves) and there were issues raised because this is not key management in the world of how does a client get a symmetric or public key.  The fact that the term was ambiguous as to the problem being solved was thought to be an issue.  After a long discussion the term "recipient algorithm classes" was adopted.
 
 
Section 6 describes the MAC objects. Here too there are two types of structures, depending on whether a recipient implicitly knows what key to use to verify the MAC, or whether an ID for one or more MAC keys must be communicated. The text here closely parallels that of Section 5 and is very good.
 
  
Section 8 defines two classes of signature algorithms that can be used with COSE, specifies an algorithm of each type, and provides security guidance for each algorithm. I think it would be preferable to remove the detailed algorithm descriptions (Sections 8.1 and 8.2) and associated security considerations (which are well written) from this document. The comments below apply to sections 9, 10, 11 and 12. 
 
I have several concerns about including the algorithm (vs. algorithm class) descriptions here. For many security protocols (and security-focused data formats), we usually (though not always) specify mandatory and optional to implement algorithms in separate documents, to facilitate algorithm agility. I think we should follow that model for COSE. Also, the text here does not mandate support for these algorithms; it merely provides details for a set of algorithms that a sender and/or receive may choose to implement. One has to read the final sentence of the opening paragraph of Section 15 to learn that this is the intent, i.e., that selection of specific algorithms is deferred to the each application that makes use of COSE. Given that later statement, it appears that the algorithms specified in Sections 8-12 ate intended to define the set from which application developer MUST choose, but that too is not clearly stated. I think this makes it even more appropriate to remove the detailed algorithm discussions from this document.  

[JLS] There is discussion on making things a separate document up above.

Section 15 was placed to be near the other "Considerations" sections and so that it would not need to do any clarification language about the issues.  This section could just as easily be placed immediately following Section 1 (Introduction) which would allow people to understand that not only are the algorithms presented as not MTI but the same thing is true on the structures.   Would that alleviate some of your concerns?

 
Section 12 describes the “recipient algorithm classes” aka key distribution/management methods. Most of this section is analogous to the preceding sections (9-11) where specific algorithms are described for use with COSE, and thus my comments about undue bundling of algorithms with a protocol specs apply here too. I do not object to describing key transport, key wrapping and key agreement methods in general, but the detailed specs in 12.2.1, 12.4.1 and 12.5.1 seem inappropriate here, for the reasons noted above.
 
  
Section 15 provides guidance for application developers making use of COSE. This is where a reader finally discovers that  the algorithms described in Sections 8-12 are not MTI, and that each application is expected to specify which algorithms are MTI in that context, to facilitate interoperability.

[JLS] See above question