Re: [Mathmesh] Quick review of draft-hallambaker-mesh-architecture-12

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

Thanks for the comments.

The next update on the architecture draft will be simply an update to the
missing examples. My plan is to get the examples straight throughout the
series first and then go back and wordsmith.

I think the connections part needs to be shortened in the architecture
guide and moved out to another part and some more movements out of the
first draft.



On Wed, Jan 22, 2020 at 9:47 AM Alan DeKok <[e-mail]>
wrote:

>   Overall, nicely done.  I like the rants, too. :)
>
>   Some comments:
>
> 3.1. A Personal PKI
>
> The Mesh is a Public Key Infrastructure (PKI) that is designed to address
> the three major obstacles to deployment of end-to-end secure applications:
>
>         • Device management.
>         • Exchange of trusted credentials.
>         • Application configuration management.
> ...
>
>   I would add "authorization" to the list.  i.e. Section 1 says:
>
> A core principle of the design of the Mesh is that each person is their
> own source of authority. They may choose to delegate that authority to
> another to act on their behalf (i.e. a Trusted Third Party) and they may
> choose to surrender parts of that authority to others (e.g. an employer)
> for limited times and limited purposes.
>
>   This delegation / authorization is a critical part that should be
> reiterated in section 3.1.  For me, authorization is a process that happens
> before "Exchanged of trusted credentials".  i.e. I create a credential
> which authorizes you to do X, and then hand that credential to you.  The
> format of that authorization, and human workflow are important, too.
>
>   As a long time AAA guy, I'm tempted to add "accounting" there, but I
> don't think it's necessary.
>
>   Section 3.1.3:
>
> Configuration of cryptographic applications is typically worse than an
> afterthought.
> ...
>
>   Configuration of *most* applications is terrible.  There are few, if
> any, provisions for automatically importing and exporting configurations.
> This limitation means that the application programmers are pushing work
> onto the end user.  i.e. instead of the programmer spending 2 days to
> permit import / export in JSON format, millions of end users spend hours
> each fighting with the GUI.  That cost is hidden from the programmer.
>
>   It's a classic issue of the system lacking negative feedback.  As such,
> it is destined to spiral out of control.
>
>   Later:
>
> While most computer professionals who are required to do such tasks on a
> regular basis will create a tool for the purpose, most users do not have
> that option.
> ...
>
>   The situation is much worse than that.  The programmers who create the
> applications don't give users the tools the programmers themselves use.  So
> once an application is created, it is a "black box" than can only be
> interacted with in ways that the programmer allows.
>
>   3.2. Mesh Architecture
>
> The Mesh has four principal components:
> ...
>
>   This transition is a bit jarring.  "Here's a good idea.  Here's the
> design".
>
>   It may be useful to gently introduce the reader by going through a
> series of small use cases.  These use cases can show who needs what, and
> why these components solve a particular problem.  The use cases don't need
> to be more than a paragraph, I think.
>
> Mesh Device Management
> Each user has a personal Mesh profile that is used for management of their
> personal devices. A user may connect devices to or remove devices from
> their personal Mesh by use of a connected device that has been granted the
> 'administration' role.
> ...
>
>   I find the word "connect" to be a little confusing.  It has connotations
> of "TCP connections".  I suggest using "add", which is the counter to
> "remove", or "authorized".
>
> Each user has a personal Mesh profile that is used for management of their
> personal devices. A user may add devices to or remove devices from their
> personal Mesh by use of a authorized device that has been granted the
> 'administration' role.
> ...
>
>   Further:
>
> Mesh Account
> A Mesh account is similar in concept to a traditional email or messaging
> account but with the important difference that it belongs to the user and
> not a service provider. Users may maintain multiple Mesh accounts for
> different purposes.
> ...
>
>   The word "account" has historical connotations of "identity I get by
> signing up to a paid service, and which is owned by that service".  This
> short description does not make it not clear why this account is needed.
>
> Mesh Service
> A Mesh Service provides a service identifier (e.g. [e-mail])
> through which devices and other Mesh users may interact with a Mesh
> Account.
>
>   These are all words, but I'm not sure what they mean.  Perhaps an
> analogy is useful here?
>
>   Traditionally, a service provider also provides an identifier which is
> strongly tied to that provider.  So it's unclear to the historical reader
> how an user can change providers, without changing the identifier.
>
>   Perhaps a "Mesh account" is a like a destination / mailbox, and a "Mesh
> service" is a router which routes messages to that mailbox?
>
>   Further:
>
> If desired, Alice can escrow the master key associated with her Profile
> Master and delete it from her device(s), thus ensuring that compromise of
> the device does not result in a permanent compromise of her personal Mesh.
> ...
>
>   That's good, but this description largely assumes that the reader is
> familiar with the mathematical mesh, and understands how it works.  Perhaps
> this sentence means:
>
> There is no requirement that any one device "control" Alice's account, or
> be a "master" device.  Alice can escrow her master key information
> off-line, so that the loss or compromise of a device means only that the
> information on that device is lost of compromised.
>
>
>   I'll keep reading and see if I have more comments.
>
>   Alan DeKok.
>
> --
> Mathmesh mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mathmesh
>