Re: Trying to do too much (was Re: the introduction problem, etc.)

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

I agree in part.

Over 90% of my emails are from mailing lists and SMTP mailing lists are a
real Rube Goldberg affair. This is the exact problem NNTP set about trying
to solve. It is a flawed solution but the idea that mailing lists are a
separate modality is sound.

That said, I think far too often IETF protocols have failed because they
have tried to do too little. Take PKIX which has three certificate status
mechanisms because each time we tried to do the job properly, there was a
chorus of 'don't try to boil the ocean'. And we ended up with an inadequate
solution that inevitably led to the next one.

What SMTP lacks did not exist when it was first proposed. We did not have
the technology even if we understood the requirements.

* We have portable telephone numbers, why don't we have portable email
addresses?

* Why do I have to use different protocols to send Alice a message of 100
characters, 10MB and 10 GB ?


I have phase 1 of the Mesh ready for release:
https://www.youtube.com/watch?v=zrBv717w8yY

The basic premise here is that the missing part of PUBLIC Key
Infrastructure was managing the private keys. The Mesh is designed to be a
configure and forget technology. Once you have connected a device to your
personal Mesh and said what its authorized functions are, all the
provisioning of keys and credentials takes place automatically.

No matter whether you want your end-to-end messaging scheme to be based on
OpenPGP, S/MIME or Mesh Messaging, the Mesh can do all the heavy lifting of
managing private keys and credentials for you.


Phase 1 of the Mesh provides an end to end secure password vault. Now
provisioning public key pairs to devices so that they can access a password
vault for authentication is a necessary transitional strategy but it is
clearly bogus long term. When I was cutting the demo reels I said the next
phase will be to provision out FIDO keys and credentials to the devices.

After reading the FIDO alliance materials and working on the problem a bit,
I have changed my mind: Every browser already supports everything I need in
TLS Client Authentication. All I need to do is use the Mesh to provision
TLS Client auth keys and certificates to each device.

All we need to do is to write a profile that allows Web sites to specify
Mesh TLS client auth certs and we are done (for authentication at least,
not for ceremony).


I do agree that we need multiple types of messaging interaction but I think
we can use a common messaging protocol base with all the authentication /
encryption / payment schemes in place.

Where I plan to go in phase 3 is workflow.


On Wed, May 18, 2022 at 7:53 PM Jim Fenton <[e-mail]> wrote:

> Reading this long thread on the introduction problem and all sorts of
> other things reminds me that it isn’t productive to try to solve all of
> email’s problems with a single protocol. Email evolved as an easy way to
> contact basically anyone, and as a result got used for a lot of
> applications with different (and even conflicting) requirements.
>
> We should be working defining a number of protocols that handle some of
> the things that email is used for today, and that email doesn’t do well.
> Some examples might be mailing lists, newsletters, advertising,
> notifications, and even personal correspondence. Some of these have an
> introduction problem, and others are explicitly opt-in and could solve the
> problem at opt-in time. They might even be merged together for the user so
> they don’t need to look at multiple things. And yes, there would still be
> email to handle the “everything else” cases.
>
> I’ve been playing around with something to handle notifications, but it’s
> not clear how that would achieve deployment even if it worked well. There
> is a definite chicken-and-egg problem here.
>
> -Jim
>
>