Subject: [Secdispatch] The Mathematical Mesh

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 22 Apr 2019 12:58:11 -0400

Five years ago I started to look at the reasons that Internet users do not
use end-to-end secure mail despite the fact that almost every email client
in use supported S/MIME and OpenPGP had been available for decades.

In answering that question, I quickly realized that we were trying to solve
the problems we were interested in rather than the ones that the user
actually cared about. And yes, users do really care about security but
their security concerns are much broader than the ones raised on the
cypherpunks mailing lists. They are concerned about the control that
corporations might have over them much more than governments. They are
concerned with the risk of losing the pictures of their kids at 5 years old
to ransomware.

Carl Ellison says that the user base of any security protocol halves for
each click required to use it. This led me to ask, 'how can we reduce total
user effort' and not just effort required for security. Today we ask the
user to configure their email client twice, first to make use of email and
again to make email secure (and then we require them to redo the second
annually for S/MIME).

The result of this approach is an infrastructure I call the Mathematical
Mesh which I would like IETF participants to consider as a standards track
effort, either in part or in whole.

The goal of the Mesh is to make computers easier to use by making them more
secure. This is easier than people might imagine. The key here is that
every set of instructions that you write down and give to a human can be
written as code and given to a suitably authorized computer system.

The phrase suitably authorized is key here, often the reason manual
intervention is required to configure systems requires is that certain
system privileges are needed.

Like BitCoin, the Mesh extends the traditional cryptographic repertoire.
While all of the cryptographic techniques used in the Mesh are well
established in the academic field, this is the first time anyone has (to my
knowledge) proposed making use of them in an open standard.

The Mesh is designed to make full use of the capabilities of modern
computer systems: It is assumed that every user has access to a machine
with at least the capability of a Raspberry Pi Zero for purposes of
configuring an managing devices. Connection and use of constrained devices
of Arduino Mega class and above is also supported by offloading certain
security functions to a trusted gateway.

I am posting this here to solicit opinions as to whether I should bring
some or all of this work to the IETF or if I should take it to other forums.

The drafts are available in plaintext or HTML format. Since some of the
drafts make extensive use of mathematical notations, I recommend reading
them in the HTML format.

HTML:
http://mathmesh.com/Documents/draft-hallambaker-mesh-architecture.html
http://mathmesh.com/Documents/draft-hallambaker-mesh-udf.html
http://mathmesh.com/Documents/draft-hallambaker-mesh-dare.html
http://mathmesh.com/Documents/draft-hallambaker-mesh-schema.html
http://mathmesh.com/Documents/draft-hallambaker-mesh-protocol.html
http://mathmesh.com/Documents/draft-hallambaker-mesh-trust.html
http://mathmesh.com/Documents/draft-hallambaker-mesh-cryptography.html

Plaintext:
https://datatracker.ietf.org/doc/draft-hallambaker-mesh-architecture/
https://datatracker.ietf.org/doc/draft-hallambaker-mesh-udf/
https://datatracker.ietf.org/doc/draft-hallambaker-mesh-dare/
https://datatracker.ietf.org/doc/draft-hallambaker-mesh-schema/
https://datatracker.ietf.org/doc/draft-hallambaker-mesh-protocol/
https://datatracker.ietf.org/doc/draft-hallambaker-mesh-trust/
https://datatracker.ietf.org/doc/draft-hallambaker-mesh-cryptography/

These drafts are not yet complete as the example material and schema
documentation is still being revised. This will be addressed as the
reference code passes the remaining unit tests for each functional unit.
The principle adopted being that it is better to have no examples than
incorrect ones.

The following drafts are planned but not yet written:

https://datatracker.ietf.org/doc/draft-hallambaker-mesh-constrained/
https://datatracker.ietf.org/doc/draft-hallambaker-mesh-quantum/

The reference code is open source and runs in C# under .net Core. It is
currently tested only on the Windows platform but previous versions have
run on OSX and Linux.

https://github.com/hallambaker/Mathematical-Mesh

The code system is also open source. These tools allowed me to design,
implement and document a code base that is capable of performing
significant portions of the functions of PKIX, S/MIME, Blockchain, SMTP,
IMAP and TLS on my own in a little less than three years.

https://github.com/hallambaker/PHB-Build-Tools

---

From: Richard Barnes <[email-masked]>
Date: Mon, 22 Apr 2019 13:34:06 -0400

Hi Phil,

Thanks for the note.  The IETF typically works on specifications for
interoperability between multiple implementations.  Is there more than one
party involved / interested in implementing?

--Richard

On Mon, Apr 22, 2019 at 12:58 PM Phillip Hallam-Baker <[email-masked]>
wrote:

> In answering that question, I quickly realized that we were trying to
> solve the problems we were interested in rather than the ones that the user
> The goal of the Mesh is to make computers easier to use by making them
> more secure. This is easier than people might imagine. The key here is that
> http://mathmesh.com/Documents/draft-hallambaker-mesh-architecture..html
> <http://mathmesh.com/Documents/draft-hallambaker-mesh-architecture.html>
> <http://mathmesh..com/Documents/draft-hallambaker-mesh-trust.html>
> _______________________________________________
> Secdispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/secdispatch
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 22 Apr 2019 14:27:08 -0400

At this stage, I am trying to get people to actually look at the documents
before I start actively marketing this scheme.

I am currently in the process of spinning up my own company. When I worked
as a Principal Scientist for two major Internet concerns for a total of
over 20 years, one of my main job functions was identifying interesting
technologies.

The Mesh makes use of a unique set of cryptographic capabilities. It is the
first time to my knowledge that anyone has explored the potential of Torben
Pedersen or Matt Blaze's work.

If people would like this to be an open system based on non-proprietary
standards, this is your chance.

---

From: Nico Williams <[email-masked]>
Date: Mon, 22 Apr 2019 14:03:03 -0500

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.)

Nico
--

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 22 Apr 2019 15:33:22 -0400

> 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.

The primary focus is enabling real users to manage public key pairs on
their devices without being aware that they are doing it. Securely
establishing a set of public key pairs on each device and providing a
validation path to the user's personal axiom of trust is the main idea
here. Because if we achieve that, we are 80% of the way to securing almost
any communication pattern.

Trust topology is something I think we should be opportunistic on and use
every available option. For example:

* We meet at an IETF and exchange our master profile fingerprint directly
using the QR code exchange.
* You meet Alice at another meeting and directly exchange credentials using
the QR code exchange.
* I add Alice to the GitHub repo for the project based on your
recommendation.
* I add my personal banker to my account based on an Extended Validation
certificate authenticating his bank and an assertion issued by the bank
credentialing him as a current employee.

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.

I have only scratched the surface as far as applying the key co-generation
and splitting techniques I use. We could use them to distribute TLS
certificate key pairs as well.

---

From: Nico Williams <[email-masked]>
Date: Mon, 22 Apr 2019 15:38:13 -0500

> 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.

But I do feel that the device management part is separable, even though
it's certainly critical for the UX.

[0] E.g., PKI, DNSSEC, Kerberos.
[1] E.g., PGP.
[2] E.g., WebPKI, which isn't exactly hierarchical, and definitely isn't
    webby as to trust.

> any communication pattern.

Agreed.

Vendors will (already do) gladly help you do this within their walled
garden, natch.  The result is... a bit lame.

> every available option. For example:

Ah, "opportunistic".  TOFU.  Sure.

> credentialing him as a current employee.

OK, so WebPKI, PKI (if we had it, which, well, we do, since DNSSEC is a
PKI).

> 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.

Nico
--

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 22 Apr 2019 23:17:07 -0400

> "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.

> 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.

> done via OAuth/JWT.  Don't feel bad for not using SAML/XML.  Just make

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.

---

From: Nico Williams <[email-masked]>
Date: Mon, 22 Apr 2019 22:49:18 -0500

On Mon, Apr 22, 2019 at 11:17:07PM -0400, Phillip Hallam-Baker wrote:
>                    [...]. One distinction I do feel very strongly on is

So much so that it's even separable from the rest.

When it comes to one's own devices (for some value of "own"), the
introducer problem is trivially solved: one is the introduced, and
assuming physical access, the rest is trivial.

Indeed, smartphone vendors have even solved that -- within their walled
gardens anyways.

Getting an interoperable protocol for device key management widely
implemented would be a real coup.

> is certainly the core here.

I'm not asking for it to be separated, just noting that it is separable.

Again, I'm looking for a pithy description of the proposal.  It's now
"all ove the above as to trust" + "open device key management".
Anything else?

> inter-trust problem because it has been the part of the problem we like to

On the other hand, to follow an all-of-the-above path means
interoperating with existing protocols wherever that helps.

For example, there's no need for a replacement for PGP or S/MIME.  What
is needed is a way to simplify introductions and key exchange, to get it
down to scanning a QR code and pressing a button.  Ditto TOFU (though
that's trickier, naturally).  Ditto WebPKI.

I've this idea that DANE stapling in TLS could be used to provide not
just server authentication to clients, but also user authentication to
servers, using client EE certificates with rfc822Name SANs and DANE to
authenticate the domainname of a client certificate's rfc822Name SAN(s).

(Many don't trust the DNSSEC root any more than others trust WebPKI, but
for most users, anything is better than nothing.)

The varying levels of trust will surely complicate the UI somewhat.  At
least power users will want to be able to see some indication of trust
strength / how an introduction happened.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Mon, 22 Apr 2019 23:29:32 -0500

> authenticate the domainname of a client certificate's rfc822Name SAN(s).

Ugh, I meant that DANE would authenticate the client cert's issuer,
identified by the domainname of the rfc822Name SAN.

---

From: Ben Laurie <[email-masked]>
Date: Tue, 23 Apr 2019 13:16:23 +0100

> any communication pattern.

Where is the user testing for this? BTW, seems to me if users are not aware
that they are doing it, they will also not be aware when they are not doing
it. That doesn't seem like a path to security to me.

-- 
I am hiring! Formal methods, UX, management, SWE ... verified s/w and h/w.
#VerifyAllTheThings.

*https://grow.googleplex.com/jobs/search?query=team:%221944651479079%22
<https://grow.googleplex.com/jobs/search?query=team:%221944651479079%22>*

---

From: Michael Richardson <[email-masked]>
Date: Tue, 23 Apr 2019 16:14:47 -0400

I have been reading Phill's work off and on as he has progressed over a few
years.  I think that Richard Barnes' question, "who will implement this"
is relevant, but I prefer not to take it too strongly at this point.
We have published many things that seemed to have multi-vendor support, which
went nowhere, and some things that are uni-vendor (TACACS..) which are widely
used. 

BOF's attempt to establish such things, and at this point, I don't think
it is time for an IETF BOF yet.

Often things happen in the open source space and by the time it's clear that
it is popular, serious protocol mistakes have occured.  For instance, the
Matrix system had a version issue early on, and clearly would have benefitted
From having an open specification around it, and it probably could have
benefitting (maybe it is...) from our MLS work. 
   https://lwn.net/Articles/779331/
   (google found me this, while I was searching for this article.
   Looks like implementation not specification issue
      https://thehackernews.com/2019/04/france-Tchap-secure-messenger.html

Here are the directions (not mutually exclusive) that I suggest we consider:

1) an IRTF group. (We did this with HIP for instance)
2) publish some of the foundational documents as AD sponsor
3) thank PHB for his work, ask him to do an IAB plenary talk on it,
   and update us in 18 months.
4) Informational via the ISE.   

Having said this, I want to use the udf: mechanism to avoid sending large
IDevIDs across constrained networks (whether with DTLS or EDHOC).  I'm sure
that I can cook up something else, but it won't be as general.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 23 Apr 2019 17:22:52 -0400

On Tue, Apr 23, 2019 at 8:16 AM Ben Laurie <[email-masked]> wrote:

> Where is the user testing for this? BTW, seems to me if users are not
> aware that they are doing it, they will also not be aware when they are not
> doing it. That doesn't seem like a path to security to me.
>

Please make that point to the Chrome team who are busy stripping out the
security indicators so users don't know if they are on a secure site or
not.

I have done extensive user testing and come to the conclusion that almost
none of it gives useful results. Most 'usability' testing methodology is
designed to enable sales. So in 1980 when they started this, Apple was
really interested in how to make the first 20 minutes of use as easy and
productive a possible because that is the length of a typical sales
session. What concerns me is how people behave in normal use when faced
with an attack.

The usability people do tests that tell them the security indicators are
useless and strip them out so the user has no information to tell them
whether something is secure or not. And not just Google's usability people,
they all want to make the system easier to use by removing security. If you
set up the test to look at people's behavior over short time intervals you
will get a certain result. You also get that same result if you keep
changing the security indicator.

There are two concerns that must be addressed if a system is going to be
usably secure:

1) The user must not be required to think about security when they are
focused on their tasks.
2) The user must have the information they need to understand if their
security concerns have been met.

There are currently three device connection protocols, all provide a work
factor of 2^120 or better.

If we are using QR codes to connect devices, we can transmit the necessary
information without the user needing to notice that is what we are doing.
Otherwise, there are many existing protocols that make comparison of 15-30
character base 32 encoded strings as the basis for mutual authentication
and these have proved effective and acceptable.

---

From: Ben Laurie <[email-masked]>
Date: Wed, 24 Apr 2019 09:53:01 +0100

> security indicators so users don't know if they are on a secure site or

That is not what is happening. Chrome is switching from showing positive to
negative indicators.

> session. What concerns me is how people behave in normal use when faced

Indeed.

> whether something is secure or not.
>

Incorrect.

> And not just Google's usability people, they all want to make the system
> easier to use by removing security.
>

Also incorrect.

> If you set up the test to look at people's behavior over short time
> intervals you will get a certain result. You also get that same result if
> you keep changing the security indicator.
>
> focused on their tasks..
> security concerns have been met.

I agree with both of these points. I have no idea why you think you can get
to this state without doing user testing.

> and these have proved effective and acceptable.

Oh really? Evidence?

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 24 Apr 2019 12:47:01 -0400

>> and these have proved effective and acceptable.

We Chat has a billion accounts and is conservatively estimated to serve
about 50% of the population of China. They use QR codes for contact
exchange.

https://en.wikipedia.org/wiki/WeChat

One of the biggest problems that we have made for ourselves is making the
perfect be the enemy of the good. We insisted on end-to-end secure email
and got 0.1% of the mail user population enrolled for credentials of which
less than 1% use end-to-end email regularly.

If you want to offer security usability testing resources to improve on the
schemes I am proposing, I would be more than happy to make any changes they
suggest.

But right now the situation is that it took me over 15 minutes to configure
Thunderbird to use S/MIME. And I know what I am doing. It is a 17 step
process that requires use of a Web browser and email client and multiple
switches between the two. It took me another ten minutes to find the
instructions.

When the current situation is that users are required to poke themselves in
the eye with a sharp stick to get end-to-end security, it doesn't take very
much to improve on that.

---

From: Ben Laurie <[email-masked]>
Date: Wed, 24 Apr 2019 17:52:22 +0100

On Wed, 24 Apr 2019 at 17:47, Phillip Hallam-Baker <[email-masked]>
wrote:

>> If we are using QR codes to connect devices, we can transmit the
>>> necessary information without the user needing to notice that is what we
>>> are doing. Otherwise, there are many existing protocols that make
>>> comparison of 15-30 character base 32 encoded strings as the basis for
>>> mutual authentication and these have proved effective and acceptable.
>>>
>>
>> Oh really? Evidence?
>>
>

"In China, digital marketing around QR code is an environmental feature of
some international cities, such as Guangzhou, Shanghai and Beijing."

Not so much around these parts.

> less than 1% use end-to-end email regularly.

This I do very much agree with.

>
> If you want to offer security usability testing resources to improve on
> the schemes I am proposing, I would be more than happy to make any changes
> they suggest.
>
> But right now the situation is that it took me over 15 minutes to
> configure Thunderbird to use S/MIME. And I know what I am doing. It is a 17
> step process that requires use of a Web browser and email client and
> multiple switches between the two. It took me another ten minutes to find
> the instructions.
>
> When the current situation is that users are required to poke themselves
> in the eye with a sharp stick to get end-to-end security, it doesn't take
> very much to improve on that.
>

I don't disagree with this, either. I do object, however, to assertions
that things are obviously usable.

---

From: Nico Williams <[email-masked]>
Date: Wed, 24 Apr 2019 12:28:41 -0500

> >> doing it. That doesn't seem like a path to security to me.

Users absolutely have to be capable of being at least minimally aware.

Perhaps we should leave UI issues till much later, provided we get
consensus on a few "rules", with these as my proposal:

0) users absolutely have to be [capable of being] at least minimally
   aware of security

1) security UI indications should be minimally intrusive within
   constraint (0)

I'm sure there are many UI design options, such as:

 - non-modal  positive indicators
 - non-modal? negative indicators
 - reject negative interactions outright, with some sort of modal
   introducer option ("scan your peer's QR code" and such)
 - etc.

Perhaps with different UI choices for different kinds of devices.
Changes in device capabilities and form factors may well require
re-thinking UI design choices.

I don't care as much which if any or even all of the above are used, as
long as we get (0) and (1).

The degree of security indication UI intrusiveness is up for debate.  We
should give implementors guidance, but still let them experiment.

> That is not what is happening. Chrome is switching from showing positive to

Thanks for this.  Can you provide a link to justification/blogs/research
about that change?

Nico
--

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 24 Apr 2019 13:48:53 -0400

> that things are obviously usable.

My assertion was 'easier' not 'usable'. If a process has 17 steps and 16
are unnecessary, I don't need to do usability testing to know that it will
be easier to use if we eliminate them.

Well let me tell you what I am going to be doing on Sunday. I am going to
be taking the scafolding out of where it is stored in the garage and
building a tower in the master suite so that I can take down the #W$)(%$
Nest Protect device and update the WiFi settings to use a different WiFi
access point after the old one was stolen.

Someone obviously did a heck of a lot of user testing on the device but
they never thought about the management and maintenance features that would
be needed in the real world.

I have connected my device to my WiFi network three separate times. Why
does your product insist on tearing up my work and throwing it in my face?
You control both the device and the app used to establish the connection.
If you switched to using the Mesh approach, I would not need to repeat the
process yet again. (And incidentally, the connection process does use QR
codes and there is probably no need to change the user experience to enable
use of a standards based approach)

It is not just your company that has a problem with usability, Apple does
as well. I have to go and help people configure the television because the
Apple TV assumes that a person watching television can see well enough to
read. Which might sound like a really good assumption until a 90 year old
partially sighted deaf person wants to watch CNN. I would really like to be
able to set out a control that has a limited number of buttons that
directly provide the functions he needs but that would require a four or
five figure investment in coding on my part.

And the reason I brought up Apple and Nest is that they are produced by the
companies that are the leaders in the usability field.

But here is the thing, I don't think it was the usability testing that made
the difference so much as the knowledge that the polo shirted one would
have a screaming tantrum if someone had to climb a ladder to reconfigure a
device whose very function requires that it be installed in the ceiling.

The reason that the World Wide Web exists at all is that Tim Berners-Lee
ignored the sage advice of the hypertext community that referential
transparency was essential and pressed ahead with 'scruffy links'. Nobody
did usability testing to decide whether the gopher or Web UI was the
approach to follow until long after we knew the answer.

My criticism of usability testing is this: we do not find out if buildings
will stay up by building them and seeing if they fall down. That is exactly
how it was done in the past which is why the Bent Pyramid collapsed during
construction.

Usability testing is the scientific approach. We should have moved past
science and started practicing engineering. We should be able to predict
with some confidence how users will react by applying principles learned
from individual tests.

Some classes of usability failure are quite easy to analyze. If a user
faces two potential situations, case A and case B where one will lead to
disaster and the other will perform the intended task and has no means of
distinguishing these cases, the product is defective.

Right now, I have no means of knowing if an email from my bank is actually
an email from my bank or not. And that should be considered a problem. The
problem I have with discussions of usability is that the argument is made
that because we might not be able to serve every user we should just give
up and never try to change anything.

Like I said, if you want to propose changes to the protocol based on
testing or even just based on advice from usability specialists, I am more
than interested. But right now, the Mesh Reference Code is a command line
tool and I am pretty sure that is not going to be the means of delivery
that is most useful for end users.

It is however the most useful means of delivery for people who want to
build the Mesh into other applications and tools which is why we stopped
developing the GUI tool and wrote the command line tool instead.

---

From: Ben Laurie <[email-masked]>
Date: Wed, 24 Apr 2019 18:50:45 +0100

On Wed, 24 Apr 2019 at 18:29, Nico Williams <[email-masked]> wrote:

> > Chrome is switching from showing positive to
> > negative indicators.
>

https://blog.chromium.org/2018/05/evolving-chromes-security-indicators.html is
a good starting point.

Adrienne Porter Felt's research is also worth looking into.

---

From: Ben Laurie <[email-masked]>
Date: Wed, 24 Apr 2019 19:01:28 +0100

> approach to follow until long after we knew the answer.

This is a clear case of survivorship bias. The users did the usability
testing. WWW survived (despite being technically terrible in many ways),
the competitors did not.

> with some confidence how users will react by applying principles learned

Indeed, somewhat possible.

> up and never try to change anything.

Well, the problem I have with discussions of usability is the argument is
made that we should leave that until all the tech is figured out, or that
we don't need to bother because the thing is obviously better. Going from
.1% to 1% is clearly an improvement, but it is not a solution.

BTW, my original question was not about QR codes (though I have my doubts
about those), but about this assertion about usability: "Otherwise, there
are many existing protocols that make comparison of 15-30 character base 32
encoded strings as the basis for mutual authentication and these have
proved effective and acceptable."

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 24 Apr 2019 17:15:41 -0400

> testing. WWW survived (despite being technically terrible in many ways),

The Web had 100 users in the fall of 1992 when it was first demonstrated in
public. There were at least two dozen competing network hypertext systems,
most of which were far better financed than the Web which had two full time
staff at the time.

Nine months later the Web had over a million users and it was game over for
every other network hypertext scheme apart from Acrobat which had already
begun merging itself with the Web to survive.

There was rather more than survivor bias at work there. One of the biggest
differences between the Web and everything else was that Eric Binna paid
immense attention to the quality of his software distributions. He provided
binary distributions for a start and the code compiled from source.

We paid a great deal of attention to usability but we never had the
resources to test any of it. There was never a testing lab at CERN for a
start. Or at NCSA as far as I am aware. Come to think of it, when VeriSign
acquired the old Netscape HQ, I pushed for the construction of a usability
lab. Which means that there wasn't one in the building when we moved in.

> .1% to 1% is clearly an improvement, but it is not a solution.

Like I said, I am more than happy to accept input on how to do UI better.
But I am not going to be blocked on those resources. At this point I have
one employee and a seven figure budget. To start thinking about UI testing
I need to have more developers and a bigger budget.

> proved effective and acceptable."

I have entered product activation keys and lived. Adobe managed to sell
software with that requirements for decades. So they are not a show stopper
for at least some part of the audience. I am requiring only comparison of
two codes, not entry.

I accept that this is not the ideal approach and in the spec I suggest
using BASE32K encoding based on dictionaries of words or images. Since the
connection mechanism only requires comparison for equality, we don't have
to be restricted to something that can be entered on a keyboard. Images
would be the ideal of course because they can be language independent. 'Are
these nine pictures the same' is a pretty easy question to answer. The work
factor for the UDF approach would be (9*15)-8 = 127. 2^127 is sufficient
for most purposes. Comparing nine pictures for equality is relatively
straightforward.

I haven't gone into this in detail as yet, but my rough strategy for
managing the dictionaries is to

1) Sort the entries into a canonical sort order
2) Form a Merkle tree of the result.
3) Publish the apex of the tree in some tamper-proof fashion.

This avoids the need to store the entire dictionary on every device which
is important even for unconstrained devices. The image dictionary is going
to be huge and word dictionaries have to be customized to the user's
language.

It has not escaped my notice that I could use this as a funding mechanism
for the Mesh itself. The million dollar image dictionary. Companies could
pay to contribute images to the corpus, part of which could be reserved for
advertising. If the system was used a million times a day, $1 would buy
nine exposures of the image per day in perpetuity. Or until someone decided
to do an advert-free version.

---

From: Nico Williams <[email-masked]>
Date: Thu, 25 Apr 2019 11:14:05 -0500

Now that I understand what the proposal is, I have to say that I like
it.

There are some important new things in it, mostly the use of a
blockchain for PGP-style web-of-trust, and an Internet protocol for
device key management (which is separable but doesn't need to be
separated).  The first is a new application of existing ideas, but it
is critical to facilitating the use of web-of-trust.

The most important thing about the proposal is that it's a synthesis of
the above and an all-of-the-above approach to communication security for
average users, and that it's a proposal for Standards-Track Internet
protocols.  As such it has better chance of success than the disparate
piecemeal efforts of the industry as a whole until now.

Count on me as a reviewer,

Nico
--

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 25 Apr 2019 17:12:00 -0400

> is critical to facilitating the use of web-of-trust.

Just to be clear: It is a similar approach to blockchain. The encoding used
is entirely separate.

The DARE Container allows append only logs to be created with individual
entries of up to 2^63 bytes in length. So we could use the same format as a
file archiving format or even a software distribution format.

The encoding allows the container sequence to be read with equal efficiency
in the forward or the reverse direction and while every entry can have a
separate key exchange and signature, the entire container can be
authenticated and encrypted at the entry level using a single key exchange
in the first entry and a single signature entry on the last entry.

So we could use this as a ZIP file for distributing Web pages. But unlike
ZIP, the signatures are based on a Merkle tree so we can validate
individual entries.

So we could use this as a software distribution format. Put all the files
for all the distributions on all platforms into one big file. Then the
distribution system can extract the specific set of files needed for
specific platforms weeding out the ones that aren't needed.

The same approach can be used for software updates. since the containers
are append only. All you need to do to push out updates is to synchronize
the containers across devices.

The reason I was able to simplify the Mesh code was that I realized that
all my application protocols could be implemented as instances of
synchronizing containers between devices.

> Count on me as a reviewer,

Thanks, that is greatly appreciated. The status of the current drafts is
that the text is more or less complete, there are some missing images and
multiple missing examples.

The reason for that is that I alternate between writing the documentation
and implementing it. I began by writing the documentation, wrote the code,
went back and wrote new documentation describing the code and so on.

The last set of changes was motivated my my leaving Comodo. Originally, the
DARE work was an application that built on the Mesh capabilities. I rewrote
the code so that the Mesh is now built on top of DARE. That allowed me to
eliminate two thirds of it.

---

From: Nico Williams <[email-masked]>
Date: Thu, 25 Apr 2019 16:42:34 -0500

> Just to be clear: It is a similar approach to blockchain. The encoding used

Understood.  The point is that you end up with a cryptographic
append-only log.

> synchronizing containers between devices.

Nice.

> multiple missing examples.

Is that a request for review sooner than later?

> went back and wrote new documentation describing the code and so on.

Understood.

Nico
--

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 25 Apr 2019 18:14:37 -0400

> Understood.  The point is that you end up with a cryptographic

Yep.

> Is that a request for review sooner than later?

The current status is that the UDF and DARE drafts are essentially done. I
do not expect to make major changes to those drafts in response to my work.
I will of course expect to make changes due to the review cycle so if you
are interested in reviewing, those are the drafts to look at.

The next one I expect to be ready is the algorithms draft (8). This is
pretty complete except that I have moved in work from elsewhere which needs
attention and examples. Those will be the next examples generated by the
code.

If you want to see the scope of the work and how it hangs together, the
architecture guide has the text but not the pictures or conversations.