Re: [Mathmesh] [Cfrg] A different approach to key escrow

Nico Williams <nico@cryptonector.com> Mon, 09 September 2019 16:38 UTC

Return-Path: <nico@cryptonector.com>
X-Original-To: mathmesh@ietfa.amsl.com
Delivered-To: mathmesh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB4C412080E for <mathmesh@ietfa.amsl.com>; Mon, 9 Sep 2019 09:38:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com
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 BAmEl2BxiE6x for <mathmesh@ietfa.amsl.com>; Mon, 9 Sep 2019 09:38:35 -0700 (PDT)
Received: from buffalo.birch.relay.mailchannels.net (buffalo.birch.relay.mailchannels.net [23.83.209.24]) (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 BF58B120853 for <mathmesh@ietf.org>; Mon, 9 Sep 2019 09:38:27 -0700 (PDT)
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id A66001A2631; Mon, 9 Sep 2019 16:38:26 +0000 (UTC)
Received: from pdx1-sub0-mail-a12.g.dreamhost.com (100-96-6-79.trex.outbound.svc.cluster.local [100.96.6.79]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 7FC111A27B4; Mon, 9 Sep 2019 16:38:21 +0000 (UTC)
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
Received: from pdx1-sub0-mail-a12.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.17.5); Mon, 09 Sep 2019 16:38:26 +0000
X-MC-Relay: Neutral
X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com
X-MailChannels-Auth-Id: dreamhost
X-Dime-Quick: 03b5db5d2d24c192_1568047102028_2740679145
X-MC-Loop-Signature: 1568047102028:4210485620
X-MC-Ingress-Time: 1568047102028
Received: from pdx1-sub0-mail-a12.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a12.g.dreamhost.com (Postfix) with ESMTP id 845F88009E; Mon, 9 Sep 2019 09:38:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=3AQTVD0v2j3k6E y3WBHa467iTzA=; b=dAnSvsgSosUhIw3aUnt1QOYfpv9oWzz6puZljspdM+8pej XcEuD7G6dnlZloYa65CWUpfXgPlZhur3ldzn+fXEfcODZWoHMdwBE9h8cUwoUlnM GU7r/FW25K7N4SLkpgfzw0MUhaVLVYDjcEabsWsc7RoYd0xz+eVRVFVyYYiMI=
Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a12.g.dreamhost.com (Postfix) with ESMTPSA id 6E7EA80064; Mon, 9 Sep 2019 09:38:17 -0700 (PDT)
Date: Mon, 9 Sep 2019 11:38:14 -0500
X-DH-BACKEND: pdx1-sub0-mail-a12
From: Nico Williams <nico@cryptonector.com>
To: Phillip Hallam-Baker <phill@hallambaker.com>
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, mathmesh@ietf.org, cfrg@irtf.org
Message-ID: <20190909163813.GG7920@localhost>
References: <CAMm+LwiZqA=M90YdmQOV+sAy+T-prhzphct2bsOyPmaQ4V2oOA@mail.gmail.com> <6241.1567487279@localhost> <CAMm+LwhKHHz8e6b2C61zjFDv+shsLsBgxaAv=88dFG3kdJ9Fiw@mail.gmail.com> <14973.1567579627@dooku.sandelman.ca> <CAMm+LwhYv+m3swyipb5_7_N0-f0wM4MBSW4KFz4c=WT4jQzHfw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAMm+LwhYv+m3swyipb5_7_N0-f0wM4MBSW4KFz4c=WT4jQzHfw@mail.gmail.com>
User-Agent: Mutt/1.9.4 (2018-02-28)
X-VR-OUT-STATUS: OK
X-VR-OUT-SCORE: -100
X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduvddrudekiedguddtvdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvuffkfhggtggujggfsehttdertddtredvnecuhfhrohhmpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqnecukfhppedvgedrvdekrddutdekrddukeefnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepvdegrddvkedruddtkedrudekfedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd
Archived-At: <https://mailarchive.ietf.org/arch/msg/mathmesh/S76tIQg4VU2NAxURmRtibHF-HIE>
Subject: Re: [Mathmesh] [Cfrg] A different approach to key escrow
X-BeenThere: mathmesh@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <mathmesh.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mathmesh>, <mailto:mathmesh-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mathmesh/>
List-Post: <mailto:mathmesh@ietf.org>
List-Help: <mailto:mathmesh-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mathmesh>, <mailto:mathmesh-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Sep 2019 16:38:42 -0000

On Thu, Sep 05, 2019 at 10:26:22PM -0400, Phillip Hallam-Baker wrote:
> On Wed, Sep 4, 2019 at 2:46 AM Michael Richardson <mcr+ietf@sandelman.ca>;
> wrote:
> > Nico Williams <nico@cryptonector.com>; wrote:
> >     > I don't see why in the first case you'd need a separate
> >     > service to store the private keys encrypted in the master
> >     > secret.  All the entities that hold secret shares can also
> >     > hold copies of the encrypted record along with the secret
> >     > shares.
> >
> > This allows the secrets to split and sent to appropriate entities
> > once at the beginning of the process, and they never need to be
> > updated again.  Alice can generate as many keys (and as frequently)
> > as she wishes, interacting only with the escrow service.  Assuming
> > that I understand correctly.

If you use a master secret to to generate all the others, indeed.

The first scheme, however, requires storing updated encrypted secrets
payloads.  That's the "service" that we'd asked about, but I assumed the
services that store secret shares would also store those payloads.

> >     > However, you might find it difficult to generate key pairs
> >     > from a master secret, especially if you ever need to generate
> >     > keys on a hardware token.  If you won't have that requirement,
> >     > and if you're willing to have that as an anti-requirement,
> >     > then the second scheme is simpler, indeed, and the entities
> >     > that store key shares will need to store smaller records.
> >
> > You are saying: If you use a hardware token, then you need the escrow
> > service.
> > Isn't it the case that some hardware tokens have no mechanism to get the
> > private key out?  I guess they are SOL regardless of scheme.

Yes, though I expect wrapped key export to be generally available,
still:

> I agree. If someone is using a hardware token, the hardware token needs to
> manage the escrow mechanism itself (e.g. like the way Luna cards do). But
> it will in any case need a way to import a private master key generated
> elsewhere.

not supporting such tokens is a reasonable thing to do.

> > Couldn't we generate per-key escrow keys from the master key using
> > the same KDF mechanism?  Doesn't that get us the best of both worlds,
> > with the confusion as to how the different

That enlarges the amount of secret share storage needed, which gets us
back to Phillip's desire to avoid that.  A nice feature of this scheme
is that there's a fixed number of fixed-sized keyshares generated early
on and this need never change unless you want to re-key everything.

Speaking of which, how does master secret change work?

> Hmm... that might be the way to do it. The only problem is that then you
> need access to the offline master to be able to generate application key
> sets and the idea of the offline master is that you should only need to
> ever use it when changing your administration device.


Nico
--