Re: [Secdispatch] [saag] The Mathematical Mesh

[Phillip Hallam-Baker <[e-mail]>]

On Mon, Apr 22, 2019 at 4:38 PM Nico Williams <[e-mail]> 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 <[e-mail]>
> 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.