Re: the introduction problem, was Email and reputation (was Re: Service outages planned for April 25)

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

On Tue, May 3, 2022 at 12:47 AM Viktor Dukhovni <[e-mail]>
wrote:

> > On 3 May 2022, at 12:24 am, Keith Moore <[e-mail]>
> wrote:
> >
> > I'm not convinced that that's the (only or even most important) reason,
> or that it's even true.  From my perspective there have been several
> barriers to adopting S/MIME and/or PGPMIME, e.g. lack of MUA support, lack
> of email domain CAs and support for them among root CAs, lack of a well
> known and trusted set of root CAs such as exist for the web (it's not clear
> that they should should be the same set), lack of a standard key discovery
> mechanism, and (mostly I suspect) lack of mindshare.
> >
> > When there are multiple barriers to solving a problem, any one of those
> problems can become an excuse to avoid solving the other problems.
>
> Key distribution and discovery isn't the fatal problem, the fatal problem
> is that encrypted email is unusable once received and stored.
>
> Until encrypted email is usable (**search**, long-term signature
> validation,
> personal private key rollover, ...), all the key distribution tech in the
> world won't make it worth adopting.
>
> PHB's mathematical mesh might come closer to addressing the key
> distribution
> problem, but then we'll still have all the hard MUA issues.  Someone will
> have
> to want to build MUAs that really solve the usability issues.  I don't see
> that
> happening in a space dominated by cloud web mail providers, not sure it
> lines up
> with their business models...
>

I have the perfect solution to private key rollover - my keys never expire.
I don't allow use of weak crypto. If Ed448 or X448 can be broken at all,
rotating your keys once a year won't help.

What I do instead is to partition the keys so that every device has its own
key set. For decryption, the use of the keys can be withdrawn if they are
issued as threshold shares instead of a direct key.
So my signature keys never expire. The part of the Mesh I am currently
working on is the callsign infrastructure and cross-notarization scheme
which has the effect of locking all the user's personal append only logs
together so that if Alice is validating a signature, Alice becomes the root
of trust for that process.


So Alice has an append only log with a hash chain (its actually Merkle
Trees, but for simplicity, chain)

Every day, Alice signs her final hash value and send the resulting notary
token to her MSP which enrolls the token in its own log.
Every day, Alice's MSP signs its final hash value and send the resulting
notary token to Alice to enroll in her log.
Every hour, every MSP performs the same cross notarization with the
Callsign registry.

So when Bob signs a document, he adds an entry to his personal append only
log. This is cross notarized with his MSP which cross notarizes with
Alice's MSP which cross notarizes with Alice.

As a result, when Alice comes to check a signature, she can check the
signature value against a proof chain that is rooted in her own personal
append only log. Alice thus knows that the signature was created on that
day and with which key.

[It doesn't need to be the callsign registry that acts as the
synchronization point, nor is it necessary for there to be only one. The
point is that all the personal trust logs mesh together. It is impossible
for any user to defect without detection. There is no reliance on a trusted
third party. There is no proof of work, waste, there is no Ponzi coin]


OK so search is hard. The Mesh system is entirely end to end and the
service has no visibility. In fact, the service doesn't even know the
account name the user uses. The only thing the MSP knows is the fingerprint
of the user's profile signature key.

In order to do search then, a search index is going to have to be compiled
on at least one of the user's devices. Depending on the user's security
concerns, it might be acceptable for the user to have a device that has her
account encryption key decrypting every message, compiling an index and
uploading it to the MSP.

Failing that, devices are going to have to do search locally. But that
might not be quite as hard as it appears because unlike SMTP, Mesh Messages
are limited to 32KB. All the images, videos, etc. are passed as external
attachments. If there is a looong email message, the text part is also an
external attachment. But even so, I only have 35GB of gmail and much of
that is from mailing lists and an even greater amount is clutter. The text
parts of my emails are probably less than 1GB and my iPhone can easily
handle that.

So in summary, yes search is a hard problem and I do not currently have
code. But it is certainly not an insoluble problem.


Again, going back to the Web. One of the reasons the Web worked was that we
pushed the search problem out to later on.

Most of the searches I do on my emails are actually trying to find emails I
sent or received and the search terms are limited to the subject line. Text
search is actually a poor way to do what I am trying to do most which is to
find invoices for orders I placed in the past so I can order spare parts or
make a repeat order. And again, the sheer amount of junk mail makes it a
lot harder.


Tim B-L was really onto something when he was talking about the Semantic
Web. The Web would be a heck of a lot more powerful if there was some easy
way for the machine to recognize a mail message as an invoice or delivery
note so that my house management system knows that I just bought an XYZ
fridge and it will need PDQ filters every 6 months.

But maybe the missing link in that workflow was security and the lack of a
decent security base was the reason we never got round to build the
semantic components on top.