Re: [Secdispatch] [saag] The Mathematical Mesh

Phillip Hallam-Baker <> Tue, 23 April 2019 03:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7AB381200FE; Mon, 22 Apr 2019 20:17:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.647
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Lc1qH7sEUO_J; Mon, 22 Apr 2019 20:17:19 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D20C7120075; Mon, 22 Apr 2019 20:17:18 -0700 (PDT)
Received: by 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;; 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: <> <20190422190302.GA3137@localhost> <> <20190422203812.GB3137@localhost>
In-Reply-To: <20190422203812.GB3137@localhost>
From: Phillip Hallam-Baker <>
Date: Mon, 22 Apr 2019 23:17:07 -0400
Message-ID: <>
To: Nico Williams <>
Content-Type: multipart/alternative; boundary="000000000000bacd7e05872a05cc"
Archived-At: <>
Subject: Re: [Secdispatch] [saag] The Mathematical Mesh
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Dispatch <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 23 Apr 2019 03:17:20 -0000

On Mon, Apr 22, 2019 at 4:38 PM Nico Williams <> 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 <>
> 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'

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.