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

Phillip Hallam-Baker <phill@hallambaker.com> Tue, 10 September 2019 03:02 UTC

Return-Path: <hallam@gmail.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 D28AA120020 for <mathmesh@ietfa.amsl.com>; Mon, 9 Sep 2019 20:02:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.915
X-Spam-Level:
X-Spam-Status: No, score=-1.915 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 bwP_b9kx7c_c for <mathmesh@ietfa.amsl.com>; Mon, 9 Sep 2019 20:02:53 -0700 (PDT)
Received: from mail-ot1-f47.google.com (mail-ot1-f47.google.com [209.85.210.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5219F120059 for <mathmesh@ietf.org>; Mon, 9 Sep 2019 20:02:53 -0700 (PDT)
Received: by mail-ot1-f47.google.com with SMTP id b2so16003453otq.10 for <mathmesh@ietf.org>; Mon, 09 Sep 2019 20:02:53 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=PjtShIVawsm3/X681dfzQwcrSaHfn/SLTJMS2gJlEOY=; b=OsAuSSnBknKGGEElBFTmQHVPYn7YzzihtKODh6nP7Xu251q6W8i0Zul+22BJvO7Ju4 6CwTfNnOmIIlTXY7UHFFAGH6iIIdKRS4qcr8amkystlUaPJ7U8NfhNsxD80i6IiNyADP tV8Wa4+lz9B9s0LCj8SPjBPWDvRCyi8z2DAEGBB1TLXliAFEhsk5OjpqoOe+yYEO2Zj0 4ikdieHn5NIuPaM3hMir7RQCvSjz8t3hdOH36TlQVpv7PDqmh/DaycM8pTVGja1bY2jZ z/JVOMhwbQouBIWiACYNRUD/ASoY3jG2HyhkyaYFNpX+HvIaKC8FoVcdCpNonnH/9nb9 l8Yw==
X-Gm-Message-State: APjAAAUtFkJEaxMnIAIAhoHuU7PTeo7vKVa2eJOlbHO7iB28xhtOFfJE yL20p6cmcVDEFUiI5rGZYApUF8EQ1Q14+/k29ac3Kw==
X-Google-Smtp-Source: APXvYqzz2YzDOHL3JfUNR6udaw3uA6SVZP8+kTgI2XnonpdnSH25va7p86LBFFCLQymiGFA/MElP8Ei4jwhxbBfnwTk=
X-Received: by 2002:a9d:4786:: with SMTP id b6mr18179331otf.112.1568084572536; Mon, 09 Sep 2019 20:02:52 -0700 (PDT)
MIME-Version: 1.0
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> <20190909163813.GG7920@localhost>
In-Reply-To: <20190909163813.GG7920@localhost>
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Mon, 9 Sep 2019 23:02:41 -0400
Message-ID: <CAMm+LwizQf_s6rAw8x8m1rOU=5E+NyWsLaGpguBctOBhxcMhtw@mail.gmail.com>
To: Nico Williams <nico@cryptonector.com>
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, mathmesh@ietf.org, cfrg@irtf.org
Content-Type: multipart/alternative; boundary="000000000000ec837205922a2305"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mathmesh/NiJOMYVd16UNDHUZTIIDWYYRHRA>
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: Tue, 10 Sep 2019 03:02:56 -0000

On Mon, Sep 9, 2019 at 12:38 PM Nico Williams <nico@cryptonector.com>; wrote:

>
> Speaking of which, how does master secret change work?
>

That might not be so critical with the changes I made to the way accounts
work.

The master secret for the Mesh is only used in the management of the user's
Mesh devices. It is no longer something that is exposed to other people.
Only the account keys are exposed to other users.

What we probably need to do is to go through the scenarios that would
require re-keying a personal Mesh.

The way that would have least impact on other systems would be to simply
create a parallel Mesh and then create an assertion 'the person who used to
have fingerprint X now has fingerprint Y'. And then various parties would
have to decide the extent to which they trust that assertion.