Re: [COSE] Benjamin Kaduk's Discuss on draft-ietf-cose-hash-sig-07: (with DISCUSS and COMMENT)

Russ Housley <housley@vigilsec.com> Fri, 06 December 2019 17:27 UTC

Return-Path: <housley@vigilsec.com>
X-Original-To: cose@ietfa.amsl.com
Delivered-To: cose@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D09CB120110 for <cose@ietfa.amsl.com>; Fri, 6 Dec 2019 09:27:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 i6JAp6Dyt5mB for <cose@ietfa.amsl.com>; Fri, 6 Dec 2019 09:27:01 -0800 (PST)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C3501200FE for <cose@ietf.org>; Fri, 6 Dec 2019 09:27:01 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 84FB8300B06 for <cose@ietf.org>; Fri, 6 Dec 2019 12:26:59 -0500 (EST)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id IU5vuCpqVzRX for <cose@ietf.org>; Fri, 6 Dec 2019 12:26:57 -0500 (EST)
Received: from a860b60074bd.fios-router.home (pool-108-51-198-163.washdc.fios.verizon.net [108.51.198.163]) by mail.smeinc.net (Postfix) with ESMTPSA id BBFCC300AA0; Fri, 6 Dec 2019 12:26:57 -0500 (EST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <20191205221806.GH13890@kduck.mit.edu>
Date: Fri, 6 Dec 2019 12:26:58 -0500
Cc: IESG <iesg@ietf.org>, Jim Schaad <jimsch@augustcellars.com>, cose <cose@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <4A8E2FA1-C98D-45C3-B0F1-FF2B9FF056A0@vigilsec.com>
References: <157539486101.24700.12161503456212968239.idtracker@ietfa.amsl.com> <619FB9BA-BDEB-4E31-BC04-DF265F27E51D@vigilsec.com> <559B8753-15F1-4C18-A604-686FD0A96215@vigilsec.com> <20191205221806.GH13890@kduck.mit.edu>
To: Ben Kaduk <kaduk@MIT.EDU>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cose/lTJR0IEnMV9YrXQ8h29bW2hIOw4>
Subject: Re: [COSE] Benjamin Kaduk's Discuss on draft-ietf-cose-hash-sig-07: (with DISCUSS and COMMENT)
X-BeenThere: cose@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: CBOR Object Signing and Encryption <cose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cose>, <mailto:cose-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cose/>
List-Post: <mailto:cose@ietf.org>
List-Help: <mailto:cose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cose>, <mailto:cose-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Dec 2019 17:27:03 -0000

Ben:

Trimming to the one unresolved comment...

>>> ----------------------------------------------------------------------
>>> COMMENT:
>>> ----------------------------------------------------------------------
>>> 
>>> Related to the above Discuss, should we have an explicit statement that we do
>>> not define a way to convey an HSS/LMS private key in a COSE_Key object?
>>> (I think it is correct to not define such a thing, since conveying a
>>> stateful private key is something of a non-sequitur.)
>> 
>> I agree that we do not want to define such a structure.  I'm not sure where to say anything about it.
> 
> The best place I can see is in Section 5 (Operational Considerations), as
> something like "Because of the need to maintain state across invocations of
> the signing algorithm, a COSE Key Type Parameter for encoding the private
> key (and its state) is deliberately not defined; serializing the state for
> conveyance presents too great a risk of state reuse to justify any
> potential benefit from doing so."

I suggest:

   A COSE Key Type Parameter for encoding the HSS/LMS private key and
   the state about which tree nodes have been used is deliberately not
   defined.  It was not defined to avoid creating the ability to save
   the private key and state, generate one or more signatures, and then
   restore the private key and state.  Such a restoration operation
   provides disastrous opportunities for tree node reuse.

Russ