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

Stephen Kent <> Fri, 23 September 2016 17:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3EA7912B747 for <>; Fri, 23 Sep 2016 10:54:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.921
X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id M4kQpNPBJDNg for <>; Fri, 23 Sep 2016 10:54:51 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C402E12B883 for <>; Fri, 23 Sep 2016 10:54:50 -0700 (PDT)
Received: from ( []) by (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id u8NHsSnV002843 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 23 Sep 2016 17:54:28 GMT
Received: from ([]) by ( with ESMTPS id u8NHsQQa030868 (version=TLSv1 cipher=AES256-SHA bits=256 verify=NOT); Fri, 23 Sep 2016 17:54:27 GMT
Received: from ([]:50999 helo=COMSEC.fios-router.home) by with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <>) id 1bnUg6-0009f5-6i; Fri, 23 Sep 2016 13:54:26 -0400
From: Stephen Kent <>
To: Jim Schaad <>, 'secdir' <>, 'Justin Richer' <>, 'Kepeng Li' <>, 'Kathleen Moriarty' <>
References: <> <081e01d21474$a3db8440$eb928cc0$>
Message-ID: <>
Date: Fri, 23 Sep 2016 13:54:25 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <081e01d21474$a3db8440$eb928cc0$>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-09-23_07:, , signatures=0
Archived-At: <>
Subject: Re: [secdir] secdir review of cose-msg-18
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 23 Sep 2016 17:54:53 -0000


Thanks for making the changes you describe as done. Comments below on 
the few remaining items.

> 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  Not sure that this makes sense.
When you refer to IANA registries defined in the doc you cite the 
relevant section of the doc. Since this registry already exists I think 
it would be appropriate to include a pointer to it:
> 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.
How about:

The IV can be placed in the unprotected header as modifying the IV will cause the decryption to yield plaintext that is readily detectable as garbled.

The decryption process will not, itself, detect any error, so it will 
not "fail" per se.