Re: [Cbor] Benjamin Kaduk's Yes on draft-ietf-cbor-sequence-01: (with COMMENT)

Benjamin Kaduk <kaduk@mit.edu> Thu, 19 September 2019 02:40 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: cbor@ietfa.amsl.com
Delivered-To: cbor@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B1791200D6; Wed, 18 Sep 2019 19:40:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 rY5NO_PYZBEn; Wed, 18 Sep 2019 19:40:23 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 928EA12008A; Wed, 18 Sep 2019 19:40:23 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x8J2eFwv024645 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 18 Sep 2019 22:40:17 -0400
Date: Wed, 18 Sep 2019 21:40:14 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: Jim Schaad <ietf@augustcellars.com>
Cc: "'The IESG'" <iesg@ietf.org>, cbor@ietf.org, draft-ietf-cbor-sequence@ietf.org, cbor-chairs@ietf.org
Message-ID: <20190919024014.GC14253@kduck.mit.edu>
References: <156885006199.4487.4211790094945761661.idtracker@ietfa.amsl.com> <008401d56e91$caf513f0$60df3bd0$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <008401d56e91$caf513f0$60df3bd0$@augustcellars.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/Irhd4k32ZxqneRsQUyASTbQkICI>
Subject: Re: [Cbor] Benjamin Kaduk's Yes on draft-ietf-cbor-sequence-01: (with COMMENT)
X-BeenThere: cbor@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Concise Binary Object Representation \(CBOR\)" <cbor.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cbor>, <mailto:cbor-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cbor/>
List-Post: <mailto:cbor@ietf.org>
List-Help: <mailto:cbor-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cbor>, <mailto:cbor-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Sep 2019 02:40:26 -0000

On Wed, Sep 18, 2019 at 07:27:29PM -0700, Jim Schaad wrote:
> One response down below.
> 
> -----Original Message-----
> From: Benjamin Kaduk via Datatracker <noreply@ietf.org> 
> Sent: Wednesday, September 18, 2019 4:41 PM
> To: The IESG <iesg@ietf.org>
> Cc: draft-ietf-cbor-sequence@ietf.org; Jim Schaad <ietf@augustcellars.com>om>; cbor-chairs@ietf.org; ietf@augustcellars.com; cbor@ietf.org
> Subject: Benjamin Kaduk's Yes on draft-ietf-cbor-sequence-01: (with COMMENT)
> 
>> Section 5
> 
>> I might note that when COSE is applied to the elements of a sequence, the cryptographic protection is on a per-element basis, and thus there is no guarantee of relationship between level of protection, source authentication, time of generation, etc., across members of the sequence.
> 
> [JLS] I don't believe that there is any requirement that there be only a single element of a sequence inside of a COSE wrapper.  If three elements are generated at the same time then all three could be placed into a single encryption.  Thus I am not sure how to say that the protection is on a per-element basis.  

Perhaps (presumably?) this is just a question of semantics, but from where
I sit, the output of a COSE operation is a CBOR array (that has at least
three elements and maybe more depending on context, but that's not really
relevant for the point I want to make).  If I'm using COSE to protect
(some) elements of a CBOR sequence, then what goes into the sequence is the
CBOR array resulting from the COSE operation.  Undoing that COSE operation
may or may not produce more than one CBOR object, but those objects are not
elements of the CBOR sequence in question; they are contained within an
element of the CBOR sequence in question.  So, to me, the elements of the
sequence are necessarily a single COSE output, even if the consuming
application may assign different semantics to them.

> While it is true there is not necessarily a relationship between each COSE object, each COSE object does have the ability to provide that information for each element of the sequence.  You have more than what you started with, where you had none of that, and now you have it for each element.  You just need to do key validation on each decryption.  That might be a better way to say things in that a stream could have multiple sources and thus multiple keys.

Sure, making positive statements about what can be done is preferrable to
just making statements about what is not guaranteed (though perhaps both
would be needed; I haven't thought about what the text would look like very
much).

-Ben