Re: [Mathmesh] A different approach to key escrow

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 04 September 2019 06:46 UTC

Return-Path: <mcr@sandelman.ca>
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 C72C11200CE for <mathmesh@ietfa.amsl.com>; Tue, 3 Sep 2019 23:46:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 F5cG9Iksk-mO for <mathmesh@ietfa.amsl.com>; Tue, 3 Sep 2019 23:46:35 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 975C81200C3 for <mathmesh@ietf.org>; Tue, 3 Sep 2019 23:46:35 -0700 (PDT)
Received: from dooku.sandelman.ca (unknown [89.248.140.11]) by relay.sandelman.ca (Postfix) with ESMTPS id A92711F45A; Wed, 4 Sep 2019 06:46:33 +0000 (UTC)
Received: by dooku.sandelman.ca (Postfix, from userid 179) id 61688FE9; Wed, 4 Sep 2019 02:47:07 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Phillip Hallam-Baker <phill@hallambaker.com>
cc: mathmesh@ietf.org, cfrg@irtf.org
In-reply-to: <CAMm+LwhKHHz8e6b2C61zjFDv+shsLsBgxaAv=88dFG3kdJ9Fiw@mail.gmail.com>
References: <CAMm+LwiZqA=M90YdmQOV+sAy+T-prhzphct2bsOyPmaQ4V2oOA@mail.gmail.com> <6241.1567487279@localhost> <CAMm+LwhKHHz8e6b2C61zjFDv+shsLsBgxaAv=88dFG3kdJ9Fiw@mail.gmail.com>
Comments: In-reply-to Phillip Hallam-Baker <phill@hallambaker.com> message dated "Tue, 03 Sep 2019 10:51:11 -0400."
X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Wed, 04 Sep 2019 02:47:07 -0400
Message-ID: <14973.1567579627@dooku.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/mathmesh/Av2FBxL3hJVO-KFAWQUP44uLaB4>
Subject: Re: [Mathmesh] 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: Wed, 04 Sep 2019 06:46:38 -0000

Phillip Hallam-Baker <phill@hallambaker.com> wrote:
    > OK so here is the difference.

okay, thank you.
I didn't realize the "done now" version encrypted the private keys like that.
I assumed in my brain that it would always be the KDF version :-)

> Escrow Key = HKDF ( [97 BE C3 8C EC 32 E3 A8 14 BE 38 AC 49 B3 58 D0],
> "mmm/mesh-escrow/X448", 448) 
>
>So now recovery of the escrow record ONLY requires the master secret
>ECL3-5Q4M-5QZO-HKAU-XY4K-YSNT-LDIA. There is no encrypted escrow record.

I'm confused here.  Isn't the private key is deterministically created from the
master key, why do we need an escrow key?   Won't the key need to be numbered
so that one knows which of potentially many pieces are generated? Or is
there a master key for each key that Alice needs to generate?

    > Pros: More convenient.  Cons: The private keys have less ergodicity and
    > are related by means of the HMAC function.

I think that it's okay for the reasons you gave.

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.

    > 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.

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 

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [