### Re: [Secdispatch] [saag] The Mathematical Mesh

Phillip Hallam-Baker <phill@hallambaker.com> Tue, 23 April 2019 03:17 UTC

Return-Path: <hallam@gmail.com>

X-Original-To: secdispatch@ietfa.amsl.com

Delivered-To: secdispatch@ietfa.amsl.com

Received: from localhost (localhost [127.0.0.1])
by ietfa.amsl.com (Postfix) with ESMTP id 7AB381200FE;
Mon, 22 Apr 2019 20:17:20 -0700 (PDT)

X-Virus-Scanned: amavisd-new at amsl.com

X-Spam-Flag: NO

X-Spam-Score: -1.647

X-Spam-Level:

X-Spam-Status: No, score=-1.647 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25,
FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001,
HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001,
URIBL_BLOCKED=0.001] autolearn=no 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 Lc1qH7sEUO_J; Mon, 22 Apr 2019 20:17:19 -0700 (PDT)

Received: from mail-ot1-f67.google.com (mail-ot1-f67.google.com
[209.85.210.67])
(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 D20C7120075;
Mon, 22 Apr 2019 20:17:18 -0700 (PDT)

Received: by mail-ot1-f67.google.com with SMTP id u15so11498993otq.10;
Mon, 22 Apr 2019 20:17:18 -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=aEyqpNa6IORQoUWGrmIxPYHkXlkb/e8lfJhtd9Pg8WQ=;
b=bEfGt3hHPAosCQ1sOEF5ylSPaQ2SX8Pz0Ta8yjTjtZYgkJFfoKwSWrbuiFqamNBx1v
lkU2gXYHBuTKhQTN0aWYpBiHo0TIHsZIG7cpAnb8jJpErlcnRlZaHxLql8S/iII4OlNi
iLwCiQjP2nD7Oe3QmULPNojzNX/MGcnjF9h00DMqHAoF4MfIahnJ5c7opMXX4wgHRqqE
wnvLsvpGdM2rcrQCKBHT+2COo64ngLErHBAFwhBQFqJkadIxIb86hqPnQE82hRJzutUZ
jsGCerU7Akw3zMeY1Vip99FV4qrlS64MWXFXsX8v+gwjg4Sb7p6RgGzW7fHw+SD+VfKv
9lsw==

X-Gm-Message-State: APjAAAXHgLBibSwFqZTnncxADj60F6yVIb/1otkbpLTam7HE1x8QFf97
uUGqQE/mQ1ViALpH5H0nlSo7gIIfU0ReosF9b4KuFQ==

X-Google-Smtp-Source: APXvYqz6jxPoEYZpulY3FlAhcjQV5dWWtsl7p1rXzhEoWL1l/YBZM11mkOHQ19BjeF1h+ChDXyk6H052Qo+CW6/XhPs=

X-Received: by 2002:a9d:5a11:: with SMTP id v17mr14131893oth.150.1555989438056;
Mon, 22 Apr 2019 20:17:18 -0700 (PDT)

MIME-Version: 1.0

References: <CAMm+LwiF3iGiRO5reW4KCgf8vp=Kv=+4pD+_rGOcxEsD1Hxk4g@mail.gmail.com>
<20190422190302.GA3137@localhost>
<CAMm+Lwj1BV1=UQwE8-5tPO_mxOVixfkiUjXvu+U_AgnSzzkjvg@mail.gmail.com>
<20190422203812.GB3137@localhost>

In-Reply-To: <20190422203812.GB3137@localhost>

From: Phillip Hallam-Baker <phill@hallambaker.com>

Date: Mon, 22 Apr 2019 23:17:07 -0400

Message-ID: <CAMm+LwiFndekzHs3u8uUagbJJtxe3CFCbTvHyR4wYRBorK6ODA@mail.gmail.com>

To: Nico Williams <nico@cryptonector.com>

Cc: secdispatch@ietf.org, IETF SAAG <saag@ietf.org>

Content-Type: multipart/alternative; boundary="000000000000bacd7e05872a05cc"

Archived-At: <https://mailarchive.ietf.org/arch/msg/secdispatch/-u7sTDOZf5JmrnI0KhcgYmujRXA>

Subject: Re: [Secdispatch] [saag] The Mathematical Mesh

X-BeenThere: secdispatch@ietf.org

X-Mailman-Version: 2.1.29

Precedence: list

List-Id: Security Dispatch <secdispatch.ietf.org>

List-Unsubscribe: <https://www.ietf.org/mailman/options/secdispatch>,
<mailto:secdispatch-request@ietf.org?subject=unsubscribe>

List-Archive: <https://mailarchive.ietf.org/arch/browse/secdispatch/>

List-Post: <mailto:secdispatch@ietf.org>

List-Help: <mailto:secdispatch-request@ietf.org?subject=help>

List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdispatch>,
<mailto:secdispatch-request@ietf.org?subject=subscribe>

X-List-Received-Date: Tue, 23 Apr 2019 03:17:20 -0000

On Mon, Apr 22, 2019 at 4:38 PM Nico Williams <nico@cryptonector.com> wrote: > On Mon, Apr 22, 2019 at 03:33:22PM -0400, Phillip Hallam-Baker wrote: > > On Mon, Apr 22, 2019 at 3:03 PM Nico Williams <nico@cryptonector.com> > wrote: > > > Is it fair to characterize this as something of a PGP trust mesh on > > > steroids? If not, how does it differ? > > > > > > (Yes, I do see that your scheme has decentralized device management for > > > individuals, which is a bit of a new thing and very welcome.) > > > > The objective is to give users the power to control their own security > > environment. > > > > This includes but is not limited to the ability to make use of > Web-of-Trust > > approaches or delegated trust, delegated distrust or a combination of all > > three which is actually the approach I think works best. > > OK, so, all-of-the-above trust? > > But there's nothing new yet, besides hierarchical[0], and > web-of-trust[1], TOFU, and things in between[2] right? > > Just a new way of doing all-of-the-above? > > This is not a critique. I think a simple characterization will help. > > "All of the above on steroids" seems fair. > The objective here is to put the user in control and not try to force any particular model on them. One distinction I do feel very strongly on is that the configuration of trust relationships between devices belonging to the same entity is a completely different issue to the problem of trust between entities. Now I accept that there are some weasel words there, 'belonging' and 'entity'. But I still think there are important differences. Lets call the first problem the 'device-trust' problem and the second the 'inter-trust' problem Why I buy a new device I am adding it to my network which is in turn connected to the Internet. So the decision to trust the device is mine and mine alone. I am fairly certain I don't want to outsource the decision to grant trust. But I might under certain circumstances delegate the decision to distrust. So Symantec might tell me that my toaster is trying to kill me or the blender is trading crypto currencies and shut them down on my behalf. > But I do feel that the device management part is separable, even though > it's certainly critical for the UX. > I have no objections to an a-la-carte approach. The device management part is certainly the core here. The basic concept is that let us say that the device ships from the factory with a set of crypto keys burned in at the very chip level, cannot ever be altered or extracted. The protocols I have developed allow those keys to be used in conjunction with an overlay set of keys provided by the administration device. The net effect is that we get all the advantages of keys that are installed during manufacture and all the advantages of application generated keys. The combined key is secure against external attack if either of the key contributions is. The manufacturer key does not provide a backdoor capability unless the user generates a weak overlay key set. > > Right now, I am doing everything in JSON and the Mesh Assertion > > infrastructure. It is pretty obvious that some of this is SAML territory. > > But where should the boundary be and should we make use of the XML SAML > > binding or switch it to a JSON encoding? I don't know what the right > > decision is there or have time to think about it. > > It's always tempting to start from scratch... But it's already been > done via OAuth/JWT. Don't feel bad for not using SAML/XML. Just make > the right choice. > Naturally and this is one of the reasons I have steered clear of the inter-trust problem because it has been the part of the problem we like to beat on most.

- [Secdispatch] The Mathematical Mesh Phillip Hallam-Baker
- Re: [Secdispatch] The Mathematical Mesh Richard Barnes
- Re: [Secdispatch] The Mathematical Mesh Phillip Hallam-Baker
- Re: [Secdispatch] [saag] The Mathematical Mesh Nico Williams
- Re: [Secdispatch] [saag] The Mathematical Mesh Phillip Hallam-Baker
- Re: [Secdispatch] [saag] The Mathematical Mesh Nico Williams
- Re: [Secdispatch] [saag] The Mathematical Mesh Phillip Hallam-Baker
- Re: [Secdispatch] [saag] The Mathematical Mesh Nico Williams
- Re: [Secdispatch] [saag] The Mathematical Mesh Nico Williams
- Re: [Secdispatch] [saag] The Mathematical Mesh Ben Laurie
- Re: [Secdispatch] The Mathematical Mesh Michael Richardson
- Re: [Secdispatch] [saag] The Mathematical Mesh Phillip Hallam-Baker
- Re: [Secdispatch] [saag] The Mathematical Mesh Ben Laurie
- Re: [Secdispatch] [saag] The Mathematical Mesh Phillip Hallam-Baker
- Re: [Secdispatch] [saag] The Mathematical Mesh Ben Laurie
- Re: [Secdispatch] [saag] The Mathematical Mesh Nico Williams
- Re: [Secdispatch] [saag] The Mathematical Mesh Phillip Hallam-Baker
- Re: [Secdispatch] [saag] The Mathematical Mesh Ben Laurie
- Re: [Secdispatch] [saag] The Mathematical Mesh Ben Laurie
- Re: [Secdispatch] [saag] The Mathematical Mesh Phillip Hallam-Baker
- Re: [Secdispatch] [saag] The Mathematical Mesh Nico Williams
- Re: [Secdispatch] [saag] The Mathematical Mesh Phillip Hallam-Baker
- Re: [Secdispatch] [saag] The Mathematical Mesh Nico Williams
- Re: [Secdispatch] [saag] The Mathematical Mesh Phillip Hallam-Baker