On Tue, Jan 4, 2022 at 4:29 PM John C Klensin <john@xxxxxxx> wrote:
--On Tuesday, January 4, 2022 14:20 -0500 Phillip Hallam-Baker
<phill@xxxxxxxxxxxxxxx> wrote:
> So on the one hand we have John Klensin asking 'why not do it
> in SMTP' and on the other we have John Levine showing why not.
Except that is not what I said. You had said that it could not
be done in SMTP;
I did? I am pretty sure I did not. Not until I identified the separation of the contact establishment channel from the messaging channel as a design choice that cannot be changed.
What I have been saying is that having designed an infrastructure to make use of end-to-end encryption in SMTP, it is much easier from both the deployment and the technical point of view to build a new end-to-end messaging app on top of that than to try to reverse engineer upgrades into SMTP.
(1) We still do not have a clear explanation of the problem you
claim to have solved. "Better than SMTP", "fix holes in SMTP",
and comments about Alice's desires are not examples of such an
explanation.
The core value add is to secure data at rest. Alice creates a powerpoint, it is encrypted on her hard drive. She sends it to Bob, he can't read it. Alice adds Bob to the encryption group authorized to read the powerpoint, now he can. Oh Bob was fired, now he can't. Alice can grant and remove access to any person inside or outside the company without changing the content. Bring a contractor on board? They can be given access.
What I have built is an open specification for a content level security infrastructure. A replacement for SMTP is not the killer app here, securing data at rest, preventing a repeat of the Snowden attack because the key server is not able to decrypt, that is why people will buy in.
But everyone who is using that Mesh application will need to establish a Mesh profile and manage contacts to all the people they are exchanging DARE encrypted content with. And that contacts catalog is designed to synchronize across all of a user's devices and support all modes of communication. So its going to be the starting point for Signal/Skype/Zoom/etc. conversations as well.
And that will make it really easy to move from SMTP to a messaging system that is end-to-end secure by default and does not impose any restrictions on message size. All it takes is Alice and Bob having the necessary clients.
(2) Several, probably even most, of the approaches you are
suggesting look to us (and Keith and others) like things that
have been tried before and largely failed, or at least failed to
get sufficient traction to make them viable for the long term
and at scale.
There are many walled garden examples of these ideas succeeding. They just don't usually scale much further than ten million people or so because they are walled gardens. But Signal is a rip roaring success.
See above. Regardless of how any of us might feel about SMTP,
I don't see a long line of either users or MSPs clamoring for
its replacement and hence ready to switch to a newer and better
solution.
Incumbents rarely see the possibility of a threat to their business until it is too late.
If the Mesh does take off, it will be the providers of VPN and Anti-Virus services that step in as service providers. The communities they serve are willing to spend money for security. It is also likely to be of interest to ISPs.
The SMTP based MSPs will almost certainly ignore it until the customer base is a sufficiently large threat and then panic.
As a business matter it is much easier to persuade Fred that he can take over Alice's business niche with a new technology than to sell that new technology to Alice. Take SawStop for instance. Anyone with a brain could see that every high school in the country would have to replace their Delta Unisaw's with a SawStop because the insurers would make them. Delta couldn't see it so they passed up the opportunity to buy rights to the patents. They have all but lost the market to SawStop now.
