IETF Logo Mail Archive

Re: [Cfrg] [Mathmesh] 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: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E7EE120020 for <cfrg@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=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 Wgue01G01ZI2 for <cfrg@ietfa.amsl.com>; Mon, 9 Sep 2019 20:02:53 -0700 (PDT)
Received: from mail-ot1-f54.google.com (mail-ot1-f54.google.com [209.85.210.54]) (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 522B41200BA for <cfrg@irtf.org>; Mon, 9 Sep 2019 20:02:53 -0700 (PDT)
Received: by mail-ot1-f54.google.com with SMTP id c10so15999617otd.9 for <cfrg@irtf.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=UE5fzQYmcqj///54JFMe11S17VlzYjJF9YZ6afMVJGDGvSigeHnd7DPIjZRnjvDzm2 wUuklFDU2f2nreEGh4sKh0By7ns/9TzwDRX/ruhSbNTywLb5sd4JkbvYWGvOXHYm8NXa jcnrG9zqs3WVHv9294aWzzpbJgEWryFCqalWXB9hwLGisulgvQ4IsSXw/C4as8lu14cu uo5gW9Fu3i0uHvS5+tgobcLd/EC4o6GjlGPTS13Sts1bShSj0O7aRm4Ybk91JmXtHFoH Yt6FJzFmYKvvWyOTJstbTz7LdfX6o63uU5nBjo9wGlnfDIKbkn+B3eD6tXJpZWGbbqGo nMmw==
X-Gm-Message-State: APjAAAW2eEeWJmGGUCXEJIJ7ck82k2Bnw3wo+LhNb52uGrP8ojgthFY5 Oq/018oUJakltRXe8wxCE+cE8/C0/iFxTrPhg7o=
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, 09 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/cfrg/W6w_jGu6a9OsRpPHvit4yDCwQos>
Subject: Re: [Cfrg] [Mathmesh] A different approach to key escrow
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Sep 2019 03:02:55 -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.

v2.23.0 | Report a Bug | By Email