From nobody Wed Jan 22 06:47:26 2020 Return-Path: X-Original-To: mathmesh@ietfa.amsl.com Delivered-To: mathmesh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 796241200F3 for ; Wed, 22 Jan 2020 06:47:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 dIma73vV_wgC for ; Wed, 22 Jan 2020 06:47:21 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA1971200FB for ; Wed, 22 Jan 2020 06:47:21 -0800 (PST) Received: from [192.168.20.237] (206-248-138-162.dsl.teksavvy.com [206.248.138.162]) by mail.networkradius.com (Postfix) with ESMTPSA id 602C66D6 for ; Wed, 22 Jan 2020 14:47:19 +0000 (UTC) Authentication-Results: NetworkRADIUS; dmarc=none header.from=deployingradius.com From: Alan DeKok Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) Message-Id: Date: Wed, 22 Jan 2020 09:47:17 -0500 To: mathmesh@ietf.org X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: Subject: [Mathmesh] Quick review of draft-hallambaker-mesh-architecture-12 X-BeenThere: mathmesh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2020 14:47:24 -0000 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: =E2=80=A2 Device management. =E2=80=A2 Exchange of trusted credentials. =E2=80=A2 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. alice@example.com) = through which devices and other Mesh users may interact with a Mesh = Account.=20 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.=20 ... 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.=20 I'll keep reading and see if I have more comments. Alan DeKok. From nobody Wed Jan 22 15:01:52 2020 Return-Path: X-Original-To: mathmesh@ietfa.amsl.com Delivered-To: mathmesh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89EBD12010E for ; Wed, 22 Jan 2020 15:01:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.397 X-Spam-Level: X-Spam-Status: No, score=-1.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 o_tU2dTV8rMr for ; Wed, 22 Jan 2020 15:01:49 -0800 (PST) Received: from mail-ot1-f45.google.com (mail-ot1-f45.google.com [209.85.210.45]) (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 B8749120089 for ; Wed, 22 Jan 2020 15:01:49 -0800 (PST) Received: by mail-ot1-f45.google.com with SMTP id a15so1008422otf.1 for ; Wed, 22 Jan 2020 15:01:49 -0800 (PST) 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=QUzR8Zj98cECDFNfhGyHP3GYjnPd0rn1PHnn5MKijm8=; b=Ukk0qC6k3XX56aqbdm77d4SasOGd0lvYC2IJlQRFnK6OwJhTWYb7x/8VpNj8O4QK/Q CpEceYO9hZF+BEXS7xlRC3Wq40tyDT9tyYLH22LODU1l80KfCR1FYZ+cSIgseShjQPXw DqK7ajG0+F/uqot2Wxz1LHUs+IR8lbVE2B9v45dx21+TOS6Yx82zESHKB5IvxDjG/tEc 7Oxz3OVKNcldosJHPsE+6u99hWKL6Ra/UTKc0f1MPt6gA0/aVBJMzAaPR41EgDecAMsg Wn4F2KFQJ8rck2a0i6/33VegDu8fh4W0RRxGdEH7etYZmu7Vgb/nwi513eNDZT70cPnw +w2w== X-Gm-Message-State: APjAAAUqp0UUdY8+KZ/UrnQkVMnUp2GhtyDm9AzKkI+5cimzSHZxVtYU LJA54rAcDmtHoeCShokZYY3nVBNwpTDAejYQQ/I= X-Google-Smtp-Source: APXvYqx2tWhyV41XD4uogHax5qS36btG1K1U/R9mBQFhgoHEvqkSxll4SgVaR0SMf9Hu7usMsTLmNlKCFfQFifMNyYg= X-Received: by 2002:a9d:6758:: with SMTP id w24mr9502078otm.155.1579734108752; Wed, 22 Jan 2020 15:01:48 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Phillip Hallam-Baker Date: Wed, 22 Jan 2020 18:01:35 -0500 Message-ID: To: Alan DeKok Cc: mathmesh@ietf.org Content-Type: multipart/alternative; boundary="0000000000006450fe059cc28280" Archived-At: Subject: Re: [Mathmesh] Quick review of draft-hallambaker-mesh-architecture-12 X-BeenThere: mathmesh@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2020 23:01:52 -0000 --0000000000006450fe059cc28280 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 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= : > > =E2=80=A2 Device management. > =E2=80=A2 Exchange of trusted credentials. > =E2=80=A2 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 happe= ns > 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 nee= d > to be more than a paragraph, I think. > > Mesh Device Management > Each user has a personal Mesh profile that is used for management of thei= r > 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 th= e > 'administration' role. > ... > > I find the word "connect" to be a little confusing. It has connotation= s > 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 thei= r > 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. alice@example.com) > 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. Perha= ps > 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 > Mathmesh@ietf.org > https://www.ietf.org/mailman/listinfo/mathmesh > --0000000000006450fe059cc28280 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Tha= nks for the comments.

The= next update=C2=A0on the architecture draft will be simply an update to the= missing examples. My plan is to get the examples straight throughout the s= eries 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 movement= s out of the first draft.



On Wed, Jan 22, 2020 at 9:47 AM Alan DeKok <aland@deployingradius.com> wrote:
=C2=A0 Overall, nicely= done.=C2=A0 I like the rants, too. :)

=C2=A0 Some comments:

3.1. A Personal PKI

The Mesh is a Public Key Infrastructure (PKI) that is designed to address t= he three major obstacles to deployment of end-to-end secure applications:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=A2 Device management.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=A2 Exchange of trusted credentials.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=A2 Application configuration management.=
...

=C2=A0 I would add "authorization" to the list.=C2=A0 i.e. Sectio= n 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.

=C2=A0 This delegation / authorization is a critical part that should be re= iterated in section 3.1.=C2=A0 For me, authorization is a process that happ= ens before "Exchanged of trusted credentials".=C2=A0 i.e. I creat= e a credential which authorizes you to do X, and then hand that credential = to you.=C2=A0 The format of that authorization, and human workflow are impo= rtant, too.

=C2=A0 As a long time AAA guy, I'm tempted to add "accounting"= ; there, but I don't think it's necessary.

=C2=A0 Section 3.1.3:

Configuration of cryptographic applications is typically worse than an afte= rthought.
...

=C2=A0 Configuration of *most* applications is terrible.=C2=A0 There are fe= w, if any, provisions for automatically importing and exporting configurati= ons.=C2=A0 This limitation means that the application programmers are pushi= ng work onto the end user.=C2=A0 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.=C2=A0 That cost is hidden from the progra= mmer.

=C2=A0 It's a classic issue of the system lacking negative feedback.=C2= =A0 As such, it is destined to spiral out of control.

=C2=A0 Later:

While most computer professionals who are required to do such tasks on a re= gular basis will create a tool for the purpose, most users do not have that= option.
...

=C2=A0 The situation is much worse than that.=C2=A0 The programmers who cre= ate the applications don't give users the tools the programmers themsel= ves use.=C2=A0 So once an application is created, it is a "black box&q= uot; than can only be interacted with in ways that the programmer allows.
=C2=A0 3.2. Mesh Architecture

The Mesh has four principal components:
...

=C2=A0 This transition is a bit jarring.=C2=A0 "Here's a good idea= .=C2=A0 Here's the design".

=C2=A0 It may be useful to gently introduce the reader by going through a s= eries of small use cases.=C2=A0 These use cases can show who needs what, an= d why these components solve a particular problem.=C2=A0 The use cases don&= #39;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 thei= r personal Mesh by use of a connected device that has been granted the '= ;administration' role.
...

=C2=A0 I find the word "connect" to be a little confusing.=C2=A0 = It has connotations of "TCP connections".=C2=A0 I suggest using &= quot;add", which is the counter to "remove", or "author= ized".

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 pe= rsonal Mesh by use of a authorized device that has been granted the 'ad= ministration' role.
...

=C2=A0 Further:

Mesh Account
A Mesh account is similar in concept to a traditional email or messaging ac= count but with the important difference that it belongs to the user and not= a service provider. Users may maintain multiple Mesh accounts for differen= t purposes.
...

=C2=A0 The word "account" has historical connotations of "id= entity I get by signing up to a paid service, and which is owned by that se= rvice".=C2=A0 This short description does not make it not clear why th= is account is needed.

Mesh Service
A Mesh Service provides a service identifier (e.g. alice@example.com) through which devices= and other Mesh users may interact with a Mesh Account.

=C2=A0 These are all words, but I'm not sure what they mean.=C2=A0 Perh= aps an analogy is useful here?

=C2=A0 Traditionally, a service provider also provides an identifier which = is strongly tied to that provider.=C2=A0 So it's unclear to the histori= cal reader how an user can change providers, without changing the identifie= r.

=C2=A0 Perhaps a "Mesh account" is a like a destination / mailbox= , and a "Mesh service" is a router which routes messages to that = mailbox?

=C2=A0 Further:

If desired, Alice can escrow the master key associated with her Profile Mas= ter 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.
...

=C2=A0 That's good, but this description largely assumes that the reade= r is familiar with the mathematical mesh, and understands how it works.=C2= =A0 Perhaps this sentence means:

There is no requirement that any one device "control" Alice's= account, or be a "master" device.=C2=A0 Alice can escrow her mas= ter key information off-line, so that the loss or compromise of a device me= ans only that the information on that device is lost of compromised.


=C2=A0 I'll keep reading and see if I have more comments.

=C2=A0 Alan DeKok.

--
Mathmesh mailing list
Mathmesh@ietf.org
https://www.ietf.org/mailman/listinfo/mathmesh
--0000000000006450fe059cc28280--