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

Benjamin Kaduk <kaduk@mit.edu> Wed, 11 December 2019 02:06 UTC

Return-Path: <kaduk@mit.edu>
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 C4BF6120086; Tue, 10 Dec 2019 18:06:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 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] 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 V0tfkggIfUGT; Tue, 10 Dec 2019 18:06:40 -0800 (PST)
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 3CFF1120059; Tue, 10 Dec 2019 18:06:40 -0800 (PST)
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 xBB26XGW030420 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 10 Dec 2019 21:06:35 -0500
Date: Tue, 10 Dec 2019 18:06:32 -0800
From: Benjamin Kaduk <kaduk@mit.edu>
To: Russ Housley <housley@vigilsec.com>
Cc: IESG <iesg@ietf.org>, Jim Schaad <jimsch@augustcellars.com>, cose <cose@ietf.org>
Message-ID: <20191211020632.GY13890@kduck.mit.edu>
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> <4A8E2FA1-C98D-45C3-B0F1-FF2B9FF056A0@vigilsec.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4A8E2FA1-C98D-45C3-B0F1-FF2B9FF056A0@vigilsec.com>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cose/M3VjrQHmCR0gy8t3ja9zR22bnYs>
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: Wed, 11 Dec 2019 02:06:42 -0000

Hi Russ,

On Fri, Dec 06, 2019 at 12:26:58PM -0500, Russ Housley wrote:
> 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.

That works for me; thanks!

-Ben