Subject: Re: Proposal, open up .arpa

From: John C Klensin <[email-masked]>
Date: Sat, 01 Jan 2022 11:20:27 -0500

--On Friday, December 31, 2021 19:03 -0500 Phillip Hallam-Baker
<[email-masked]> wrote:

> On Fri, Dec 31, 2021 at 6:04 PM John C Klensin
> <[email-masked]> wrote:
> 
>> 
>> 
>> --On Friday, December 31, 2021 17:09 -0500 Phillip
>> Hallam-Baker <[email-masked]> wrote:
>> 
>> > ...
>> > It is not in the callsign system itself, but once there is a
>> > directory that maps @alice onto a public key fingerprint
>> > plus a service from which a contact assertion signed under
>> > that key can be obtained, we can bootstrap to new messaging
>> > protocols that give us any desired communication properties
>> > very easily.
>> > 
>> > The reason SMTP email is so sticky is that all Bob has is
>> > the address [email-masked]. So Alice is limited to the
>> > set of protocols supported by example.com in the case of
>> > Alice and the least common denominator in the general case
>> > which is SMTP. There is no way to negotiate a service
>> > upgrade to OpenPGP over SMTP.
>> 
>> Sorry but, having spent much of the last several days working
>> on rfc5321bis, I don't understand that at all.
>> 
>> First of all, at least in principle, absolutely nothing
>> prevents Alice from creating [email-masked] (or,
>> preferably, something much more obscure) and then discarding
>> or rejecting anything that does not come from Bob, using
>> whatever authentication mechanism the two of them can work
>> out.
 
> My goal is to allow Madonna to use @madonna as her callsign for
> personal and business use.

(rearranging for convenience)
> A naming system where Alice has to create a new name for every
> set of people she wants to communicate with isn't really a
> naming scheme. And you still don't do anything to address the
> issue of SMTP spam. Oh and please don't suggest that because
> an anti-spam solution has a very small chance of allowing a
> few pieces of unwanted messages through that it is no
> improvement on SMTP.

Ok, but "Madonna uses a single callsign and has things routed
selectively depending on the senders" is different from "Madonna
gets to use multiple callsigns".  I was picking up on and
responding to the latter.

> Only the callers she authorizes get
> access to her personal inbox, everyone else gets her PA or her
> fan club secretary.
>...

In principle, not hard to do that in an SMTP environment and
there is a great deal of deployed proof of concept.

Alice can simply set up filtering, possibly in her MUA, possibly
with SIEVE or something like it, or possibly in other ways, that
maintains a "people I want to hear from directly" list, routing
everything else to the PA, the fan club, and/or spam as she (and
the configurations and tools she uses) have available and find
appropriate.  That solves the authorization problem but not the
authentication one.  We have ways to do the latter too but have
had extreme problems getting people to understand and bother to
use them.

Or she might do something else (or combine it with the above),
which would be to prioritize messages, or route them to
different folders or mailboxes, based on whether those messages
could be authenticated at the user level.  I can't be the only
one who has experimented with that and found it useful but
impeded by lack of general usage of signing or other
authentication mechanisms by senders.  Depending on
configuration, SPF, DKIM, and DMARC can be seen as variations on
that theme (my opinion, or yours, about them is another matter).

But that was not the point I was trying to make -- I obviously
didn't make the point clear.  So...

My main point was something else.  Your assertion that these
things cannot be done with SMTP and supplemental tools is simply
false.  An assertion that your method is better, or would be
much better if we were starting from a clean slate, might be
true, but that is different from saying "can't be done".
Similarly, an assertion that doing them on an SMTP base would be
quite ugly is different from "can't be done".  I, and I believe
almost everyone else who has worked closely with SMTP (and/or
other aspects of Internet mail) for many years, have a list of
things we would do differently if we were starting from scratch
while knowing what we know now.  The bar for "do better than
today's SMTP if one were starting over" is actually fairly low.  

So, from my point of view, there are three questions, with the
first being purely speculative.  I don't have answers to the
second or third, but I do have a hunch about the second:

(1) If we were starting from a completely clean slate today,
trying to build a communications system for messages longer than
typical 19th century telegrams, would we base it on something
resembling the postal services and/or SMTP models or on
something closer to your model?   In thinking about that,
remember that --the present situation with a small number of
dominant providers notwithstanding-- the SMTP design is for an
extremely distributed system with no central authority while
yours, as I understand it, requires a centralized mechanism for
(at least) callsign registration and handling no matter how
benign, profit-free, and robust that mechanism might be.

(2) Given that we probably cannot start over and that SMTP-based
systems are very widely deployed and used (the rapid growth of
systems optimized for very short and quick communications
notwithstanding), is your system sufficiently better to take
over despite the considerable inertia implied by the installed
base?  Of course, if "take over" is not your goal but, instead,
you would be satisfied to help out a small and sophisticated set
of users who would be happy with a new system to communicate
with each other while continuing to use traditional email for
communications with others, the threshold of "sufficiently
better" might be much lower. 

(3) Given how poorly we have done with deployment and active use
of S/MIME and [Open]PGP (and scaling the PKI required for the
former and the web of trust for the latter) to the
non-specialist public and the almost equally poor track record
of new and incompatible systems taking over from ones that are
widely used --at least in the absence of the "new" version being
completely free and/or having huge amounts of bundled marketing
muscle and money behind them-- would your system be more likely
to be accepted and deployed if, instead of saying, "SMTP is dead
or irretrievably broken and needs to be replaced", you were
looking at hybrids and transition strategies?

Again, I don't know the answers but, no matter how much better
your ideas might be (at least in your opinion), the installed
base (or at least the portion of it that has not abandoned
conversations like this for << 500 character messages) so far
does not agree with your opinion about the non-usability and
non-adaptivity of contemporary Internet email models.  And every
time someone looks at your messages or specs and makes comments
about telephone numbering, X.500 or other universal directory
systems, the DNS as it has evolved, or transnational use of
national identity or certification systems, it is a challenge to
you, not just to show that you can do better but that your
system won't ultimately succumb to the problems for which those
systems have been criticized.

best,
   john

---

From: Keith Moore <[email-masked]>
Date: Sat, 1 Jan 2022 12:03:32 -0500

On 12/31/21 6:04 PM, John C Klensin wrote:

> Second, I'm not sure what you mean by "OpenPGP over SMTP" but
> cannot think of anything that would prevent defining an SMTP
> extension that asserted that no message was welcome unless the
> content was in OpenPGP (signed, encrypted, or both).

You don't even need an SMTP extension to do that, you just need an SMTP 
server that can be configured to refuse or bounce mail that isn't signed 
and/or encrypted.

The missing piece is a public key+cert discovery mechanism.  This can 
also be added to SMTP.

Then you need mail user agents that query recipients' SMTP servers to 
find the recipient's public keys+certs, and verify the keys used to sign 
the certs as being trusted.

Then it gets messier.

A lot of enterprises would probably like to use encrypted mail but they 
also want (for arguably legitimate reasons like looking for malware) to 
be able to see the outgoing and incoming content in cleartext.   So they 
might want to encrypt the outgoing mail after the submission server, and 
decrypt the incoming mail after the mail exchanger SMTP server gets 
it.   So they'd at least want copies of the private keys, even if they 
forward incoming mail to its destination with encryption intact.   Since 
the enterprises at least in theory control their SMTP servers that would 
also be used for key discovery (as well as the DNS names used to find 
those servers), they can enforce such a restriction.

Individuals don't want their MSPs to have their private keys. It's 
possible that MSPs (at least in certain countries) would use the same 
mechanism as enterprises to force disclosure of private keys.   In 
theory individuals can have their own DNS names and set up their own 
SMTP servers.  (making this manageable by ordinary people at scale is 
still an unsolved problem but might be solvable)   But oppressive states 
would probably try to thwart that.

Decrypting messages prior to delivery might be attractive to some 
individuals and enterprises so that MUA searching of messages for 
content would still work.   Making searching work efficiently on a 
message store full of e2e encrypted messages is ... difficult.

There's also a question of mail that's automatically forwarded from its 
original address to one or more new destinations (including mailing 
lists).    Should it be decrypted before forwarding, and perhaps 
re-encrypted for the new recipient(s)? The right answer might not be the 
same for all cases.

Senders of messages would justifiably want to reliably know whether the 
messages they sent would remain encrypted end-to-end or whether they 
would be decrypted en route.   The key discovery service could try to 
provide some indication of that, but there's no way to prove it.   The 
simplest and in some sense most honest answer would probably be "we 
cannot guarantee that the message is not decrypted en route and if other 
servers make such a guarantee you should not trust it".

...

This is just an off the top of my head example.    But the point is that 
if you try to make the ideal system you end up optimizing for some 
specific set of use cases, and in doing so you are very likely to 
pessimize the system for a lot of other potentially legitimate use cases.

I think there's room to add mail encryption to SMTP.  The protocol 
extensions can be worked out, and major MSPs would probably find them 
attractive to their customers.   I believe that doing so would raise the 
bar for some kinds of attacks and malicious behavior.   But there's no 
way to please everybody, and maybe no way to really provide the privacy 
that many of us would like to provide.

Keith

---

From: "Theodore Ts'o" <[email-masked]>
Date: Sat, 1 Jan 2022 12:25:24 -0500

On Sat, Jan 01, 2022 at 12:03:32PM -0500, Keith Moore wrote:
> attractive to their customers.   I believe that doing so would raise the bar
> for some kinds of attacks and malicious behavior.   But there's no way to
> please everybody, and maybe no way to really provide the privacy that many
> of us would like to provide.

There are (multiple) mail encryption extensions to SMTP.  Hop-by-hop
using TLS, end-to-end encryption/authentication using S/MIME,
end-to-end encryption/authentication using PGP, etc.  Major MSP have
adopted some of these already (TLS and S/MIME integrity protection are
used by GMail, for example).

The real problem is the "no way to please everybody", which means that
these deployments are all optional and certainly not universal.

      		      	  	       - Ted

---

From: Keith Moore <[email-masked]>
Date: Sat, 1 Jan 2022 12:33:43 -0500

> used by GMail, for example).

Fair point, but as you pointed out there are lots of gaps in the current 
support.   We can probably significantly reduce the number of gaps but 
not to zero.

And of course there are also a lot of proprietary encrypted messaging 
solutions that don't interact with SMTP at all, making the users' view 
of messaging much more fragmented than it needs to be.   And most of 
those systems are profoundly dysfunctional when compared to SMTP.

Keith

---

From: John C Klensin <[email-masked]>
Date: Sat, 01 Jan 2022 15:57:31 -0500

--On Saturday, January 1, 2022 12:03 -0500 Keith Moore
<[email-masked]> wrote:

> You don't even need an SMTP extension to do that, you just
> need an SMTP server that can be configured to refuse or bounce
> mail that isn't signed and/or encrypted.
>...

Or an MDA or MUA that can do the same thing.  My point, again,
was that the claim that these things would be done with/over
SMTP.  I did not claim that it would be easy to get wide
adoption (it clearly isn't) or that there were no other issues
(there obviously are).  The other thing, which I didn't say but
hoped was obvious, is that claiming a brand new method with some
additional or different features would inherently be easier to
deploy on a wide scale than either the existing mechanisms that
you pointed out in the rest of your message, Ted pointed out in
his, and suggested (especially if the main issue is mail routing
or some additional extensions/ twitches to SMTP if they were
needed.

I think that, ultimately, there are two key problems.   First,
as you and Ted both pointed out, there is "no way to please
everybody", which means that these deployments are all optional
and certainly not universal.

Second, if we care about identities and authorization (and not
only about encryption), then we either need to make credentials
and their management easy enough to convince users they care, to
be educated about the issues, and to be
willing to put in the effort _or_ the situation turns into a
"who do you trust" exercise.  There are many possible answers to
the latter, but the choice will always involve tradeoffs (e.g.,
not liking governments excludes a large collection of options.
Or one can try bypassing part of the problem by saying, e.g.,
that the first Alice to show up is the real Alice and anyone
showing up later must further qualify the name.   That, of
course, involves its own set of risks and tradeoffs.

If there is a magical and painless solution to either of those
problems, one that also would scale to a major fraction of the
world population or even the Internet user population, it has
not been greatly in evidence.

And...

> A lot of enterprises would probably like to use encrypted mail
> but they also want (for arguably legitimate reasons like
> looking for malware) to be able to see the outgoing and
> incoming content in cleartext.   So they might want to
> encrypt the outgoing mail after the submission server, and
> decrypt the incoming mail after the mail exchanger SMTP server
> gets it.
>...

And that, as you point out less generally (including the
exploder problem), turns into another case of "who do you trust"
and maybe far more complicated versions of it.

> Senders of messages would justifiably want to reliably know
> whether the messages they sent would remain encrypted
> end-to-end or whether they would be decrypted en route.  
> The key discovery service could try to provide some indication
> of that, but there's no way to prove it.   The simplest and
> in some sense most honest answer would probably be "we cannot
> guarantee that the message is not decrypted en route and if
> other servers make such a guarantee you should not trust it".
> 
> This is just an off the top of my head example.    But the
> point is that if you try to make the ideal system you end up
> optimizing for some specific set of use cases, and in doing so
> you are very likely to pessimize the system for a lot of other
> potentially legitimate use cases.

Yep.

> I think there's room to add mail encryption to SMTP.  The
> protocol extensions can be worked out, and major MSPs would
> probably find them attractive to their customers.   I believe
> that doing so would raise the bar for some kinds of attacks
> and malicious behavior.   But there's no way to please
> everybody, and maybe no way to really provide the privacy that
> many of us would like to provide.

Exactly.

And, again, what caused me to make those comments was that, for
some definition of "work", one could make encryption in or over
SMTP work (and for some definitions and audiences, we already
have) and that shifting to a different identifier or mail
transport model would not automatically eliminate those core
problems no matter how clever the method.

   john

---

From: "John Levine" <[email-masked]>
Date: 1 Jan 2022 17:17:05 -0500

>the certs as being trusted.

People have been reinventing this idea for about 30 years now.  We have
S/MIME, which works pretty well in non-web MUAs if you can get an S/MIME
key which you generally can't unless you work for an organization with
a signing key.

We have various ways to wrap mail messages with PGP signatures and
encryption, a fairly well understood PGP key server scheme, and RFC
7929 which says how to publish PGP keys in the DNS.

One aspect these all share is that, within rounding error, nobody
uses them.  I don't see any reason to think that yet another version
of basically the same thing would turn out any differently.

R's,
John

PS: For "query recipients' SMTP servers", there are reasons
that nobody supports the SMTP VRFY and EXPN commands any more.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 1 Jan 2022 18:11:18 -0500

> true, but that is different from saying "can't be done".

I am not saying we can't fix SMTP, on the contrary, I am saying that I have
fixed it. I have a solution to every one of the issues that I originally
set out to fix and I don't require a lot of mechanism to do that.

The Mesh is very compact, it is based on a very small number of components
which have been stripped down to the bare essentials. It is essentially a
LISP approach only instead of 'everything is a list', 'everything is a list
represented as an encrypted append only log authenticated by a Merkle tree."

The problem is the Internet fax problem. Sure, you can send faxes over the
Internet. My last boss made a small fortune out of a company that did
exactly that. Fax-to-email.

The problem is that fax-by-email is a transitional technology that cannot
possibly survive for very long because every user of fax-to-email has the
ability to send and receive email attachments eliminating the fax machine
altogether.

> benign, profit-free, and robust that mechanism might be.

It can make use of but does not require the callsign registry.

SMTP does have a central authority. It is called ICANN. I am proposing a
system that offers users a choice of the ICANN authority or the new
authority.

> better" might be much lower.

The Web was originally designed to allow particle physicists to exchange
research electronically. It succeeded on a larger scale in part because it
was designed to scale but mostly because the scheme field in the URL
allowed a single client to access information via Gopher, NNTP, WAIS, FTP,
etc. etc. in addition to HTTP.

The Mesh contact book is designed to provide users with a central hub from
which they can effect a secure communication via any modality supported by
the device, not just mail, but chat, voice, video, Office collaboration,
discord, VR, etc. and via any mutually supported protocol, not just XMPP,
but IRC, Telegram, Signal, etc. etc.

I know that the providers of those protocols will resist interoperability
but folk who try to build walled gardens can expect to find folk knocking
holes in their walls.

> looking at hybrids and transition strategies?

At present, the only Mesh messaging applications are the confirmation
interaction which is an upgrade on 2FA, the contact exchange
interaction and the device connection interaction. I am not doing a mail
replacement yet.

Back in 1992 when Tim B-L persuaded me to work on the Web, he asked me to
help fix the protocol before the user base grew to the point it became
impossible. Well Mosaic bjorked that idea. It took five years to implement
about half the fixes I had hoped we would get to and many of those fixes
are a lot kludgier than I hoped.

Since then, I have made a point of designing for the success-disaster case
because once you pull the deployment lever, thats it, there is no recall
button.

The Mesh has been running in the lab for almost 9 months now.

> systems have been criticized.

There is actually another option that you missed: I take the other person's
idea and add it to my own.

I don't often take someone's entire idea but I have frequently changed
course when someone has made a comment that has led to a better idea.

---

From: Keith Moore <[email-masked]>
Date: Sat, 1 Jan 2022 19:40:50 -0500

On 1/1/22 5:17 PM, John Levine wrote:

> People have been reinventing this idea for about 30 years now.

Actually, no.   And the things you mentioned were not examples of 
"reinventing this idea".

It should be clear in hindsight, and should have been clear all along, 
that just having a standard format for encrypted messages is not 
sufficient to facilitate widespread adoption.

> We have

Nor do I, which is why I was explicitly mentioning barriers that have 
not yet been addressed.

But hey, you do you.

Keith

---

From: Keith Moore <[email-masked]>
Date: Sat, 1 Jan 2022 19:56:26 -0500

> and certainly not universal.

And _cannot_ be universal.  Though they could be widely enough adopted 
to be useful.

(I'm not really interested in defeatist arguments.  I'm much more 
interested in constructive arguments like "here's one particular 
problem, how can we solve it or a good part of it?")

> willing to put in the effort_or_  the situation turns into a
> "who do you trust" exercise.

I don't think the latter can actually be solved.  There will never be 
(and never should be) any party who is universally trusted to 
authenticate everyone's public keys.   So the problem should be either 
considered out-of-scope or perhaps a challenge for user interface 
design.    That's not a happy answer, but the real world never works as 
cleanly as we'd like.    We can't always be absolutely certain about the 
validity of signatures on paper either, but they're still useful.

As for making credentials management easier, I believe this can be done, 
but not if people insist on it being perfect.   For example, it's 
difficult to store a private key securely if you also insist that the 
key be recoverable if the device where it is stored is damaged or 
lost.   There are lots of potential compromises for addressing that 
problem, but none of them will suit everybody.   So each individual 
might need to make their own choice, and different enterprises will 
choose different solutions for managing their principals' keys.

The real challenge, I believe, is not to create a perfect email 
encryption system, but to make the strengths and weaknesses of the 
system easy for ordinary people to understand.

> not been greatly in evidence.

Right, but that's not evidence that it cannot be done.   It may instead 
be evidence that nobody has tried to solve the right problem yet.

(or maybe there are people trying to keep that problem from being solved)

Keith

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 1 Jan 2022 22:28:40 -0500

> The missing piece is a public key+cert discovery mechanism.  This can

Sharon Boyen and I proposed a solution to that.

The bigger problem is how to issue certs to people. RFC822 email addresses
don't work for individuals and we mucked up how to deploy S/MIME in
organizations. It should have been an organization cert as for the WebPKI
but people got greedy.

That leaves raw keys, fingerprints of keys and names issued on registration
of a key.

> the certs as being trusted.

Verifying certs is easy. Issuing them and managing the private keys is the
hard part.

> forward incoming mail to its destination with encryption intact.

Threshold meets the compliance concerns better. Every message can be logged
and held but exceptional access is subject to accountability.

---

From: Vittorio Bertola <[email-masked]>
Date: Mon, 3 Jan 2022 13:10:53 +0100 (CET)

> Il 01/01/2022 18:03 Keith Moore <[email-masked]> ha scritto:
> 

Actually, today the biggest obstacle for those users (like me) that insist on running their own 1-domain, 1-user SMTP server is that the "intelligent" antispam filters of Gmail and the likes will very frequently treat you as a spammer by default, and taint or even reject your messages. The message flows are simply too small for data-based heuristics to work well. 

In general, any hurdle against the deployment of personal or small-scale email servers - apart from the usual consolidation issues - will hit exactly those users who care about their privacy up to the point of running their own server. This is something we should pay attention to.

> that many of us would like to provide.

As a webmail provider to several big ISPs, we offer an OpenPGP-based UI extension that allows users to encrypt/decrypt messages, managing keys etc. Not all of our customers want it, and in general, the feedback is that the end-user demand for e2e-encrypted email is very low. In the past years we put quite some educational effort in promoting STARTTLS and proper encryption configuration (e.g., disable insecure ciphersuites) and that seems to be the most of encryption that currently the mass market demands.

-- 
Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[email-masked] 
Office @ Via Treviso 12, 10144 Torino, Italy

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 3 Jan 2022 08:42:33 -0500

On Mon, Jan 03, 2022 at 01:10:53PM +0100, Vittorio Bertola wrote:

> As a webmail provider to several big ISPs, we offer an OpenPGP-based
> UI extension that allows users to encrypt/decrypt messages, managing
> keys etc. Not all of our customers want it, and in general, the
> feedback is that the end-user demand for e2e-encrypted email is very
> low. In the past years we put quite some educational effort in
> promoting STARTTLS and proper encryption configuration (e.g., disable
> insecure ciphersuites) and that seems to be the most of encryption
> that currently the mass market demands.

My take is that the biggest obstacle to adoption of E2E message
encryption is not key management but usability of the encrypted
content post delivery.  No IMAP user-agent supports search of
encrypted messages, private key rollover, validation of long
ago delivered messages whose signing keys are now expired, ...

Nobody has ever paid enough attention to the whole lifecycle.
Just getting the message encrypted and delivered is only the
first step.

For usability, encrypted messages would need to be decrypted
by the MUA, tagged with the verification status, indexed for
(encrypted) search, re-encrypted under a long-term storage key
separate from the recipient extant private key, ...

Making search usable is particularly challenging under various attack
scenarios, but something like an encrypted AFS volume for the mailstore
(instead of IMAP) could be a first approximation, with the MUA searching
a locally cached index.  For most users attacks that monitor which
blocks are accessed during search are not a relevant threat model.

-- 
    Viktor.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 3 Jan 2022 10:59:52 -0500

> ago delivered messages whose signing keys are now expired, ...

I don't think we need to rank the issues, merely observe that no solution
is viable unless it is the complete package and works exactly as well as
legacy mail.

> Just getting the message encrypted and delivered is only the

The Mesh is best described as a Private Key Infrastructure. PKI has failed
to deliver for end users because Public Key Infrastructure only provided
management for the PUBLIC key. The private key was ignored.

> separate from the recipient extant private key, ...

The reason I am not interested in building on SMTP and PKIX is that the
constraints they impose outweigh the benefits. I certainly plan to make use
of the existing infrastructure of WebPKI CAs and it makes sense for them to
deliver their work product in X.509v3 form but they are validating
attributes, not keys.

> blocks are accessed during search are not a relevant threat model.

Encrypted search is a really hard problem as the 'scholars' who kept the
dead sea scrolls suppressed for over 30 years discovered when someone
reverse engineered the concordance.

PHB

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 3 Jan 2022 11:21:06 -0500

On Mon, Jan 3, 2022 at 7:11 AM Vittorio Bertola <vittorio.bertola=
[email-masked]> wrote:

> Actually, today the biggest obstacle for those users (like me) that insist
> on running their own 1-domain, 1-user SMTP server is that the "intelligent"
> antispam filters of Gmail and the likes will very frequently treat you as a
> spammer by default, and taint or even reject your messages. The message
> flows are simply too small for data-based heuristics to work well.
>
> In general, any hurdle against the deployment of personal or small-scale
> email servers - apart from the usual consolidation issues - will hit
> exactly those users who care about their privacy up to the point of running
> their own server. This is something we should pay attention to.
>

The big benefit of moving to a separate infrastructure in which every
message is authenticated and subject to access control with a default deny
posture is we can leave the SMTP anti-spam heuristics behind.

Heuristics are the worst sin any protocol designer can commit. The original
sin in SMTP was the chap who decided to wrap the lines of email in the
server rather than the email client. If you run Windows in compatibility
mode, files do not register as being deleted for some time after they are
erased because that behavior was necessary to make some program to work in
the DOS era.

When people ask me 'why not use SMTP', they start with the assumption that
this is should be the default. That is not the way I work. After 40 years,
it is pretty clear that every avenue for incremental improvement of SMTP
has been exhausted. But the thing that really sealed the fate of SMTP was
the anti-spam heuristics. Once you have resort to heuristics, you cease
having a proper standard. It was a necessary decision at the time but it
came at a cost.

> As a webmail provider to several big ISPs, we offer an OpenPGP-based UI
> extension that allows users to encrypt/decrypt messages, managing keys etc.
> Not all of our customers want it, and in general, the feedback is that the
> end-user demand for e2e-encrypted email is very low. In the past years we
> put quite some educational effort in promoting STARTTLS and proper
> encryption configuration (e.g., disable insecure ciphersuites) and that
> seems to be the most of encryption that currently the mass market demands.
>

The DNC attack changed the course of the 2016 US presidential election.
People should have learned data at rest security is the issue and email at
rest the most critical issue.

They won't of course which is why I am not proposing an email replacement.
I am proposing an end-to-end messaging infrastructure on top of which
secure workflow systems can be built.

One of the first applications I have built on that infrastructure
configures email clients such as Outlook and Thunderbird for use with
SMTP/IMAP/POP and provisions OpenPGP and S/MIME credentials.

It also handles the contact exchange so that we can exchange our OpenPGP
and S/MIME credentials through multiple modalities ranging from bumping
phones, QR codes, CA brokered, message loopback, etc.

But this is like building a monorail to every house in the city and using
it to deliver hay for the horses pulling people's buggies. Sure it works
and some people prefer the horse and buggy solution (mostly the folk don't
have to deal with the manure'. But if you build it, sooner or later, the
people are going to be riding the monorail.

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 03 Jan 2022 18:22:30 +0100

Hi,

To start with I think it is important to separate "message" from "transport". Then when we have agreed to that distinction (which I claim exists in the IETF) we can discuss securing transport as one thing and securing the message as one thing. And with "securing" I include both signing and encrypting and what not (or choose to do neither).

If that is the architecture we (still) use, it is I claim easy to see that we can never ever replace the security of the transport with the security on the message.

This at the same time as one can look at implementation of solutions where an end user decides to get the service from someone else to manage the security of the message, and then the communication between the end user and this service should probably be some transport/access which is extraordinary (or rather is some TLS secured transport with some MFA authentication).

Anyway, I feel the discussion to some degree mixes the integrity and security of a message with the transport. And I want us to remind ourselves that these are two different things.

And many want both...

   Patrik

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 3 Jan 2022 13:18:56 -0500

On Mon, Jan 3, 2022 at 12:22 PM Patrik Fältström <[email-masked]> wrote:

> Hi,
>
> To start with I think it is important to separate "message" from
> "transport". Then when we have agreed to that distinction (which I claim
> exists in the IETF) we can discuss securing transport as one thing and
> securing the message as one thing. And with "securing" I include both
> signing and encrypting and what not (or choose to do neither).
>

+1

I am actually using three layers of encryption. Besides message and
transport, there is a further level applied when keys and key shares are
transported.

If that is the architecture we (still) use, it is I claim easy to see that
> we can never ever replace the security of the transport with the security
> on the message.
>

Absolutely. Transport security is essential to prevent traffic analysis
attacks. Most of the surveillance infrastructure in authoritarian regimes
is focused on identifying social networks. The message content is secondary.

I am not claiming to build systems suitable for use by dissidents, that
takes a much higher degree of attention to detail and steganography.

> This at the same time as one can look at implementation of solutions where
> an end user decides to get the service from someone else to manage the
> security of the message, and then the communication between the end user
> and this service should probably be some transport/access which is
> extraordinary (or rather is some TLS secured transport with some MFA
> authentication).
>

If we are dealing with messages in a corporate environment, the messages
themselves are not confidential to the corporation. If Alice Trader is
sending messages through the trading desk to Bob Customer, those are sent
by and on behalf of the brokerage.

In this respect, corporations are people in that this is a communication
between parts of the same whole. Past approaches have tended to fall into
the trap of rampant individualism which denies the legitimacy of any
oversight in any circumstance.

But having identified this as a requirement, the solution is not to just
throw in an uber-decrypt key because when we deal with any organization, we
have to consider insider threats. Hence the need for threshold control of
any decryption shares.

Anyway, I feel the discussion to some degree mixes the integrity and
> security of a message with the transport. And I want us to remind ourselves
> that these are two different things.
>
> And many want both...
>

And we also need to deal with the fact that the SMTP design conflates
content metadata and routing headers.

Right now, I am composing in Gmail which due to my SMTP spam problem is the
only mail client I can use (like many former anti-spam technology people I
have a spam problem that is several orders of magnitude worse than 99.999%
of users. At VeriSign I received about a third of the total email sent to
the company server.)

Gmail has lots of formatting controls but if I actually use any of them,
people are going to be squawking about their teletype machine not being
able to work. And despite the fact that HTML is a standard, there is no
standard for a subset of HTML for use in email. We should fix that as well
and fix things like quoting other emails which fail badly.

--- PHB

---

From: "John Levine" <[email-masked]>
Date: 3 Jan 2022 14:45:58 -0500

>posture is we can leave the SMTP anti-spam heuristics behind.

Well, for about 15 minutes until we are reminded the hard way that
"authenticated" is not a synonym for "not spam".  Spammers are if
anything better at DMARC, DKIM, et al., than legit senders.

The reason e-mail has remained useful and that we put so much effort into
it is that it's still the only way for anyone to send a message to someone
else on the Internet without a previous introduction.  We know how to
build walled gardens, and there's a reason mail isn't one.

Also, as I have said a few times before, any walled garden big enough
to be interesting is big enough to have people you don't want to hear
from, even if the people are authenticated.  The ur example is Facebook.

R's,
John

---

From: Christopher Morrow <[email-masked]>
Date: Mon, 3 Jan 2022 15:41:35 -0500

> anything better at DMARC, DKIM, et al., than legit senders.
'If there is value to be had, bad folk[0] will find a way to exploit it'

> from, even if the people are authenticated.  The ur example is Facebook.

a bunch of the conversation about this seems a whole lot like 'tilting at
windmills'.
The fact that 'encrypted email, end-to-end, has effectively 0% market
share' really
says a lot about it as a product.

Perhaps, along with Patrik's note about: "Define which layer you are trying
to secure"
a clear and concise requirements list would help the discussion along.
Also, a reminder
that as you add difficulty to the traffic interception world you move the
attack target up
the stack.. Now your dissidents (or enterprise users) are targeted not
through their
network traffic, but through the applications they use, which aid in
exploitation and
intelligence gathering at the endpoint. (substitute 'intelligence
gathering' with 'making
crypto-miner-bots' or whatever the current fashion of the day is)

0: define as you may

---

From: "John Levine" <[email-masked]>
Date: 3 Jan 2022 18:12:55 -0500

It appears that Christopher Morrow  <[email-masked]> said:
>a bunch of the conversation about this seems a whole lot like 'tilting at windmills'.
>The fact that 'encrypted email, end-to-end, has effectively 0% market share' really

It really feels like a lot of the threat models are stuck in the distant past.

In about 1990 a guy named Brad Councilman ran an early e-commerce site to
sell used books, both from his bookstore and from other stores, and provided
e-mail accounts to those other stores.  He was accused (falsely, it later
turned out) of using procmail to make copies of his competitors' mail, and
a long and complicated court case turned on the detail of whether mail was
"in transit" or "in storage" for the moment when procmail putatively made
the copy.  

We uucp users used bang paths to route mail through long chains of
hosts to limit phone costs and Internet mail had at least two
different ways to say to route a message through intermediate hosts,
the official one and the percent hack, to get around connectivity
gaps.

You know what?  Mail doesn't work that way any more.  It all goes
directly over the Internet from the sending host to the recipient
host.  STARTTLS prevents snooping in transit, and MTA-STS lets you
detect attempts to snoop by host spoofing.  The plague of spam and
malware makes it essential for the recipient system to be able to
look inside the mail and decide if it's worth delivering.  Maybe some
people don't trust their mail providers, but considering how many
mail users use ad-supported free mail systems, most do.

So I'd be interested in a clear statement (preferably on the
ietf-smtp list) what problem a proposed solution is intended
to solve before arguing about the implementation details.

R's,
John

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 4 Jan 2022 02:15:11 -0500

> anything better at DMARC, DKIM, et al., than legit senders.

authenticated *and subject to access control with a default deny posture *

The access control is the key. J random grifter cannot send Alice spam
BECAUSE SHE HAS NOT AUTHORIZED HIM TO SEND MESSAGES TO HER.

DMARC, DKIM etc cannot provide anything of the sort because authentication
is an afterthought and only really authenticates the outbound MTA, not the
original sender.

If Alice authorizes Bob to send her mail *every message will be delivered*.
There are no heuristics involved. No content filtering. This is the key
thing for me, I want to have guaranteed delivery for messages sent from my
family, certain colleagues, etc etc, SMTP cannot deliver that.

And solving spam without content inspection is of course an absolute
precondition for use of end-to-end encryption.

Of course, nobody is going to be able to stop spam according to every
single person's definition of spam. But I can address 100% of the
reasonable definitions:

* Nigerian letters - not unless Alice authorizes the sender
* NFT offers - not unless Alice authorizes the sender
* Political mailings- not unless Alice authorizes the sender
* Mailing lists - not unless Alice actually signed up

> build walled gardens, and there's a reason mail isn't one.

Bob can request authorization to send Alice messages by first sending a
contact request message. These are deliberately limited in size and
content. No HTML, no images. Can't send them repeatedly.

And these are also access controlled.

Most users will probably leave their contact request open allowing anyone
to send them. People like Madonna and Lewis Hamilton will likely have
someone managing their contact requests.

> from, even if the people are authenticated.  The ur example is Facebook.

There are better ways to manage access than allowing anyone to send
anything to anyone and then have some heuristics guess whether they are
likely to want to read it.

For example, let's say Bob has checked into 4 IETFs, that is almost
certainly someone I am interested in receiving mail from. Lets say Carol
has been to 8 RSA Conferences, well maybe, strong possibility they are in
sales but very likely sales relevant to me.

---

From: Dave Cridland <[email-masked]>
Date: Tue, 4 Jan 2022 09:04:48 +0000

> BECAUSE SHE HAS NOT AUTHORIZED HIM TO SEND MESSAGES TO HER.

And how does one legitimately get such authorization? By messaging her on
Twitter?

The reason that email remains ubiquitous is not because it's broken, it's
because it remains the sole method by which one arbitrary endpoint can
contact another. This is the same as the telephone, and successful walled
gardens - such as WhatsApp - have emulated the same level of default access.

XMPP also does this, but many users block anyone without a presence
subscription. The result is that there's an increasing amount of spam based
around presence subscription requests. A solution based on the "contact
request messages" you suggest will have exactly the same problems, and
result in exactly the same behaviour.

If you have a communication path, people will abuse it. If you have no
communication path, people will find one, or else your solution will fail.

In some ways, spam isn't a definition of failure, it's a measure of success.

Dave.

---

From: Christopher Morrow <[email-masked]>
Date: Tue, 4 Jan 2022 12:49:14 -0500

> is an afterthought and only really authenticates the outbound MTA, not the
dmarc/dkim/spf all operate at the MTA level.
Or, possibly you could think of these at not operating at the end of the
discussion, but in the middle.

> family, certain colleagues, etc etc, SMTP cannot deliver that.
Sure, but email can. An MUA can certainly implement these restrictions.
There's a cost in exposing the relationship data to the MTAs though, which
will move the attack targets.

> * Mailing lists - not unless Alice actually signed up
you don't need any new technology to do any of the above, you just need
your MUA to deny all mail except
that which matches a regex <bob}alce|jane|jim> etc...

again, i'd say there's a lot of tilting at windmills still and not a lot of
requirements list, that could be matched against both the current
capabilities/misses and placement in the layer hierarchy.

---

From: "John R Levine" <[email-masked]>
Date: 4 Jan 2022 13:33:21 -0500

>> BECAUSE SHE HAS NOT AUTHORIZED HIM TO SEND MESSAGES TO HER.

I have to say I'm surprised to see this ancient chestnut reappearing. 
For about 30 years people have been reinventing this idea, trying to turn 
the spam problem into the introduction problem, and only accepting mail 
from people who've been introduced.  Which might work except that the 
introduction problem is harder than the spam problem and as people have 
pointed out, it is not a bug that you can send email to people you haven't 
written to before.

If each person maintains her own list of correspndents and authorization 
tokens, that's Zoemail, described in US patent 5,930,479 which was filed 
in 1996.  If an external authority decides who gets to be introduced, 
that's Facebook.

For a particularly bad version of this idea, take a look at the original 
version of Boxbe, in which you could charge people to send you mail.  It 
died from unrelated patent problems but it was a big hit among the pudit 
class who imagined that they were so important that people would pay them 
to read messages, and that those messages would nonetheless be worth 
reading.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Christopher Morrow <[email-masked]>
Date: Tue, 4 Jan 2022 14:17:09 -0500

On Tue, Jan 4, 2022 at 1:33 PM John R Levine <[email-masked]> wrote:

to be clear, I think Phillip said / wrote the quote below, not me...

> I have to say I'm surprised to see this ancient chestnut reappearing.

I admit i didn't know about the patent materials, but yes... good times.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 4 Jan 2022 14:20:10 -0500

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.

And again, I am not proposing the objective here is to replace SMTP, just
that I expect SMTP to be collateral damage because anything that can fix
the holes in SMTP will provide a means to escape from it.

> pointed out, it is not a bug that you can send email to people you haven't

Take a look at what is happening on the Internet. SMTP is dying. Young
people are turning away from it. Many people use Facebook Messenger,
WhatsApp, Telegram, Signal, etc. etc. and they are using it:

INSTEAD OF SMTP.

These 'walled gardens' you are referring to in mocking tones are whipping
SMTP's sorry hide. If SMTP was a MLB player, it would have been relegated
to the minor leagues many seasons ago.

The only thing I am proposing that is new here is that the users can choose
their own service provider and talk to people using a different service
provider.

> in 1996.  If an external authority decides who gets to be introduced,

And every major feature of Facebook was anticipated in the Open Meeting of
1994.

As Blockchain proved, a patent (Surety, 1990) is a pretty good way of
killing ideas for 20 years, often longer.

> to read messages, and that those messages would nonetheless be worth

Which is not what I proposed so why raise it?

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 4 Jan 2022 15:13:48 -0500

On Tue, Jan 4, 2022 at 12:49 PM Christopher Morrow <[email-masked]>
wrote:

> again, i'd say there's a lot of tilting at windmills still and not a lot
> of requirements list, that could be matched against both the current

So what?

The arguments in this thread are the reason I am not going to bother trying
to fix SMTP. Why on earth would I want to try to work with a group of
people who show no interest in the user's actual needs, react to every
issue with denial, propose as solutions use of technology 99% of users do
not understand and have no interest in learning, yet somehow think that the
starting point for any idea should be 'how do we make this happen in our
scheme'.

Also, the tribesplaining and the condescension is rather wearing to say the
least.

I have been doing this work for three decades now. I have helped to build
very large infrastructures that people use every day. None of the
objections being raised is new to me or something I have not considered at
considerable length.

Some people do get it. Some of the people who do get it are people whose
opinions are very highly rated in this community. Can you guess why they
are not interested in discussing them here? Given the way people see fit to
respond to my ideas, are people surprised that the IETF tends to be avoided
by people with new ideas? How long do people think an institution can
survive if the response to every proposal to do something new is 'we tried
that in 1543 and there was no demand for it'.

Oh and given the amount of cryptography it takes to do PKI right in the
Mesh, there is absolutely no way it was feasible as a user facing
infrastructure until 2005. While the Mesh does run fine on a Raspberry Pi,
that machine is much faster than the mainframe class machines in 1995.

I am not going to try to save SMTP because what matters to me is preserving
the open connectivity that SMTP and the telephone network provide. It is
the openness that is valuable, not the implementation.

---

From: John C Klensin <[email-masked]>
Date: Tue, 04 Jan 2022 16:29:44 -0500

--On Tuesday, January 4, 2022 14:20 -0500 Phillip Hallam-Baker
<[email-masked]> 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 pointed out that everything you had described
up to that point could be done (to at least a rough
approximation) using SMTP or extensions that SMTP allows.  I
tried to carefully avoid saying that doing any of it in SMTP
would be a good idea, much less optimal, only that it was
possible. 

And John Levine's "why not", particularly the introduction
problems and authentication of those were introduced, are not
about SMTP.   As I read his comments, they would apply to any
messaging system that required introduction or individual
authorization.

I believe that John, Christopher, myself and a few others are
saying more or less the same thing:

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

(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.  Most of the problems were not technical
deficiencies (aka "holes") but human/social issues that made
large-scale deployment impractical.  At least AFAICT, you have,
so far, not provided an analysis of those issues and why your
system would not succumb to the same or similar ones.

> And again, I am not proposing the objective here is to replace
> SMTP, just that I expect SMTP to be collateral damage because
> anything that can fix the holes in SMTP will provide a means
> to escape from it.

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.

   best,
   john

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 4 Jan 2022 16:30:25 -0500

OK so after some offline discussion, I think I now have a technical reason
for not trying to build on SMTP.

TL;DR; When you design the wheel from scratch you can start off with a
round one.
[Jay Carlson just posted that in response to another discussion]

The Mesh does allow people to establish new contacts. But that is an
entirely separate protocol to messaging. That separation is impossible to
introduce into SMTP at this point but it does work if introduced at the
very start of a messaging system.

Sure, people can spam the contact request channel. But applying heuristics
to mitigate abuse in that channel is nowhere near as problematic as spam
filtering my SMTP mail or my telephone calls.

I get almost no spam in contact request channels in the protocols that
support it and for fairly straightforward reasons:

1) The channel is very narrow, no attachments, limited text
2) The channel has a very specific purpose, anyone who is abusing that
purpose to sell stuff is easily identified.
3) There are many good reasons to make 1000 outbound messages in a day, no
good reason to make 1000 contact requests
4) For users who do have issues, we can apply friend-of-a-friend type
controls

There are problems with the way Facebook manages contacts. One of the
biggest is that if I add someone because they are in your contact list,
they will become a first class contact in my contact list even though I
have no idea who they are. While I am probably willing to accept messages
from anyone you introduce, I can't tell those apart from people you don't
know but accepted because someone else knew them and so on...

Of course Nathaniel Bornstein's email callback loop failed horribly. But it
was trying to modify behavior in an existing system. Also, the usability
factors were horrid and there was no separation between the contact
establishment channel and the messaging channel.

It isn't the walled garden aspect of Signal/Telegram/etc that keeps them
spam free, it is the fact that every communication requires a prior
authorization. And I would move out of Signal in a heartbeat because
contact maintenance in Signal is truly horrid. No, I don't want anything
tied to my phone and who the hell are you to be telling me that I can't
take a call on my desktop NOW because I have to rebind it to my phone
because of some cretinous half baked notion that my desktop which sits
inside a TEMPEST secured environment with Tier 3 physical security is less
secure than my mobile phone I take to parties.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 4 Jan 2022 16:59:39 -0500

On Tue, Jan 4, 2022 at 4:29 PM John C Klensin <[email-masked]> wrote:

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

> and comments about Alice's desires are not examples of such an

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.

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

> its replacement and hence ready to switch to a newer and better

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.

---

From: "Theodore Ts'o" <[email-masked]>
Date: Tue, 4 Jan 2022 17:05:30 -0500

> WhatsApp, Telegram, Signal, etc. etc. and they are using it:

Many people are using multiple applications for different purposes
---- e.g., there are some people who only use Facebook for talking to
their grandparents; they might use Weibo to connect with their Hong
Kong Student Association (HKSA) Unversity friends that made when
attending the University of Illinouis; and they might use e-mail when
they are developing the Linux kernel, or for work since that's the
contact information that's on their business card, etc.

So it's really not that simple.  If the success metric is that there
must be one messaging app to rule them all, then sure, SMTP has
failed.

> SMTP's sorry hide.

Many of these 'walled gardens' problem only solve part of the general
problem (or are only used for some people's subset of their
communication needs).

Also, never underestimate the network effects.  If you want to
communicate with the community which makes up the Soaring Eagle Kung
Fu school in Palatine, Illinois, you *have* to use Weibo, because
that's where the Kung Fu masters are.  If you want to submit patches
for review in the upstream Linux kernel, you *must* use SMTP to
vger.kernel.org.  (If you try to send a pull request via github, you
will be ingored if you are lucky, or socially "counseled" about why
that's not the way to go if you are not.  :-)

For other communities, code reviews have to be done via Github, or
Gerrit, and not via SMTP.  Does that mean that Github is "whipping
SMTP's butt"?  Well, that's not the language I would use.

> their own service provider and talk to people using a different service

... and that's not new either.  Several decades ago, I could
communicate with people using SMTP, some of which used UUCP for their
messaging neeeds, some of which used BITNET, some of which used used
SMS text messages, using e-mail gateways.  :-)

							- Ted

---

From: Christopher Morrow <[email-masked]>
Date: Tue, 4 Jan 2022 17:12:59 -0500

On Tue, Jan 4, 2022 at 3:14 PM Phillip Hallam-Baker <[email-masked]>
wrote:

> On Tue, Jan 4, 2022 at 12:49 PM Christopher Morrow <
> [email-masked]> wrote:
>
Requirements make it easier to discuss solutions or direction.
It's also easier to see which parts of those requirements do/don't work in
today's world.
I don't think SMTP is specific to the discussion, actually.

<snip>

> the openness that is valuable, not the implementation.

I don't think 'save smtp' is required, but if your discussion is spread all
over the various layers of 'messaging'
and references particular things in 'email' that you dislike, or are aiming
to solve, or believe are anathema to
a functioning solution you are going to get some rebuttal in the form:
"Well, not quite? you CAN do this/that in <existing protocol>..."

If the discussion was a bit more like:
  "It would be great if a system that offers:
     0) a system to be used in sending/receiving messages between parties
    1) strong guarantees that Alice is the Alice I mean
    2) limitations on whom/what can contact me
    3) prevention of intercept/inspection (except where required) of
messages in transit
    4) prevention of inspection of messages at rest
    5) ability to have an open specification for transport, message-format,
addressing, and message storage
    6) other things

  These things are not all solved in today's messaging systems <examples
which are relevant>
  I think these things would be beneficial because....<reasons>"

it might have been a little easier to have a conversation about this...

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 4 Jan 2022 18:02:06 -0500

> I don't think SMTP is specific to the discussion, actually.

Erm, the part I had intended to respond to was 'you don't need any new
technology to do any of the above, you just need your MUA to deny all mail
except that which matches a regex <bob}alce|jane|jim> etc...'

If you are talking about regex you absolutely do not get it and you never
will. This is not about making the Internet work for US.

Why not SMTP? Why not Xanadu? We could make Xanadu do that! No need for the
Web. Just work on Xanadu! Xanadu, thats all you need, just make it work...

As for requirements analysis, sure, I have done a lot. And SMTP is kind of
irrelevant because I am not building a replacement for SMTP.  I am building
an infrastructure that supports every mode of communication.

Alice meets Bob, they bump phones, they have each other in their contacts
catalog.

Alice wants to phone Bob, she selects his contact, selects phone and a
voice call is set up. Alice wants video, she selects video. Wants to send a
short message, long message, 30TB of video, same interaction.

Every interaction, secured by end-to-end encryption and authentication.
Every interaction, subject to access control driven by the same policy
source.

This doesn't work if Alice has to think which contact app to fire up for a
particular modality or remember that if she sends it as a mail, it might
not get through because of spam filtering or go to different apps to
separately authorize Bob for voice, video, mail and messaging.

Dream small and you will never do anything of consequence. SMTP and the
telephone system are dying. Many, many proprietary walled gardens have been
successfully created. The notion that an open system could also succeed in
the same way they have succeeded is not 'tilting at windmills', it is *the
only job that is worth our time* here.

---

From: John C Klensin <[email-masked]>
Date: Tue, 04 Jan 2022 21:06:56 -0500

--On Tuesday, January 4, 2022 16:30 -0500 Phillip Hallam-Baker
<[email-masked]> wrote:

> OK so after some offline discussion, I think I now have a
> technical reason for not trying to build on SMTP.
> 
> TL;DR; When you design the wheel from scratch you can start
> off with a round one. [Jay Carlson just posted that in
> response to another discussion]

That original, somewhat-square, wheel was refined over many
millennia so that it is round and rolls smoothly, is very widely
deployed, and various versions of it are widely available and
interoperable from many sources. There are many studies and
examples that new, whiz-band technologies to replace it don't go
anywhere.  Instead, when major new developments/improvements
come along (think, e.g., pneumatic tires), they get retrofitted
onto more or less the same old wheel rather than replacing it.

If SMTP is irrelevant to your plans except insofar as you think
your ideas will cause it to be less {useful | accepted |
relevant} then let's stop talking about it and instead,
concentrate on the problems you are trying to solve and how you
determine success... as Christopher and others (including
myself) keep suggesting.  I would personally predict that, like
that historical wheel, the wide deployment and use of SMTP would
make it much harder to displace than you seem to be assuming --
a prediction that seems to be reinforced by the large number of
"better than SMTP" that have fallen by the wayside.  But, if you
disagree or don't care, go for it and let's move on.

Very similar comments apply to trying to break or supercede an
ICANN-controlled DNS and the consequences of the name-renting
behavior that it has enabled and encouraged.   If you see that
as a goal, then we need to understand and perspective and why it
is relevant to your success with the Mesh.  If it would be just
a desirable side-effect when you succeed, then let's move on.

best,
   john

---

From: Christopher Morrow <[email-masked]>
Date: Tue, 4 Jan 2022 21:59:20 -0500

On Tue, Jan 4, 2022 at 6:02 PM Phillip Hallam-Baker <[email-masked]>
wrote:

>> On Tue, Jan 4, 2022 at 3:14 PM Phillip Hallam-Baker <
>> [email-masked]> wrote:
>>
>>>> again, i'd say there's a lot of tilting at windmills still and not a
>>>> lot of requirements list, that could be matched against both the current
>> It's also easier to see which parts of those requirements do/don't work
>> in today's world.
oh good. except that the fragment there is part of a rebuttal to your
comment about: "you can never do this with..."
again though, as others have also said: "lets skip past the smtp+-
discussion" that seems to keep getting put back into the conversation
and move along to: "What is it you are trying to do here, really,
concretely?"

> As for requirements analysis, sure, I have done a lot.
>

great! then you can point to a document? paper? presentation? git
repository?

> I am building an infrastructure that supports every mode of communication.
>
>
excellent. Requirements though?

> Every interaction, subject to access control driven by the same policy
sounds nice. This sounds, though, like something a bunch more integrated
into the lower levels
of the OS which the user is using on whatever device(s) they are
interacting through. Or, it seems
as though putting a bunch of this into the OS and letting 'applications'
hook through APIs to enable
this sort of functionality is a direction to look at. Maybe you've already
covered that in your
analysis/requirements?

> separately authorize Bob for voice, video, mail and messaging.
I hear you here, the current world can get annoying, but... if the
underlying infrastructure just does
the right thing then any application alice/bob use to interact (or
applications!) could benefit from the
goal(s) you have sort of outlined.

I really do think that the partial space you've described would be awesome
to have a solution to,
I don't think that individual 'applications' are a solution, though, it
really does sound like infrastructure
and apis which the various applications can take advantage of, seamlessly.

> only job that is worth our time* here.
you seem really fired up, that's great, I think my original question about:
"Hey, got requirements?"
was really an attempt to get away from the particular 'better than X' and
'y is a fail because!' and some
very over-the-top language, trying to get back to:
  "This is the problem(s) I see, here are the things I think we need to do
to fix these problems"
instead of the other conversation.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 4 Jan 2022 23:11:35 -0500

> excellent. Requirements though?

I circulated them three years ago before I started writing the code.

Mesh-00 Requirements (mathmesh.com)
<https://mathmesh.com/Documentation/Design/mesh-01-requirements.html>

> this sort of functionality is a direction to look at. Maybe you've already

Ideally, right into the silicon. And if people start using the Mesh at the
application layer, it is designed as a platform, it would be logical to
absorb it into the platform layer.
I designed the Mesh to make it possible for an application to make use of a
HSM built into the device by an untrusted source. Not because Intel/ARM
etc. are untrustworthy but because 1) maintaining a trustworthy supply
chain is really expensive and 2) even if the US military considers Intel
trustworthy, the Chinese military might not.

> and apis which the various applications can take advantage of, seamlessly.

I am one person, albeit with extensive resources. In the space of three
years I have redesigned the entire application layer of the Internet
starting from the proposition 'what if we started from scratch knowing what
we know now'. I have running code that passes the unit tests for the
initial deployment so we can test it out in something close to the real
world.

The last time I did something similar was in 1998 when I designed the Trust
Assertion XML Infrastructure for VeriSign where they asked 'what would PKI
look like if we redesigned it from scratch'. Nobody ever used TAXI but the
assertion infrastructure became the A in SAML.

> you seem really fired up, that's great, I think my original question
> about: "Hey, got requirements?"

The demo reel will cover that.

---

From: Christopher Morrow <[email-masked]>
Date: Tue, 4 Jan 2022 23:32:03 -0500

On Tue, Jan 4, 2022 at 11:11 PM Phillip Hallam-Baker <[email-masked]>
wrote:

>> On Tue, Jan 4, 2022 at 6:02 PM Phillip Hallam-Baker <
oh cool, thanks!

>> this sort of functionality is a direction to look at. Maybe you've
>> already covered that in your
>> analysis/requirements?
>>
>
> I designed the Mesh to make it possible for an application to make use of
> a HSM built into the device by an untrusted source. Not because Intel/ARM
sure. your point is that: "in the infra, yes" ok :) that makes sense to me
as a goal.

> The last time I did something similar was in 1998 when I designed the
> Trust Assertion XML Infrastructure for VeriSign where they asked 'what
> would PKI look like if we redesigned it from scratch'. Nobody ever used
> TAXI but the assertion infrastructure became the A in SAML.
>
>
funny, I actually thought taxi was getting pretty decent use in SEIM
deployments... or at least 'security event exchange'.

>>   "This is the problem(s) I see, here are the things I think we need to
>> do to fix these problems"
ok thanks, really.
maybe now less tilting and more progress!

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 5 Jan 2022 10:51:54 +0000

John C Klensin wrote on 05/01/2022 02:06:
> millennia so that it is round and rolls smoothly

anyone can redesign the wheel. The bits that need skill are the axle and 
bearings.

Nick

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 5 Jan 2022 12:09:42 +0000

> On 5 Jan 2022, at 10:51, Nick Hilliard <[email-masked]> wrote:
> 
> anyone can redesign the wheel. The bits that need skill are the axle and bearings.
> 
> Nick
> 

… and the tyre (tire) and the suspension system….

S

---

From: John C Klensin <[email-masked]>
Date: Wed, 05 Jan 2022 08:17:56 -0500

> … and the tyre (tire) and the suspension system….

Absolutely.  But all of those are extensions and (historically
incremental) improvements on the original design, not "toss the
original design principles of the wheel and replace it with a
completely new model".  Depending on how far one wants to push
the analogy, the idea of a suspension system might be an
exception to that but suspension systems did not replace the
idea of using wheels without them, only solved some specific
problems for some specific types of applications.

But, again, I think we are going around in circles.  Other than
acting as a two dimensional prototype or representation for said
wheel, this doesn't appear to be about SMTP (with or without
encryption) except for an (IMO extravagant and unrealistic)
claim that the proposed new system will supplant it.  Can we get
to clear statements about what specific problems are being
solved, how the proposed mechanisms will solve them, and what
their scope/ applicability are?

best,
   john

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 5 Jan 2022 14:26:34 -0500

On Wed, Jan 5, 2022 at 8:18 AM John C Klensin <[email-masked]> wrote:

> their scope/ applicability are?

If people care to look back, I am really not the person who keeps raising
SMTP.

My goal is to build a communication later that is end-to-end secure and
supports all communications modalities, both synchronous and asynchronous
and puts people in full control of their digital life:

* An account that belongs to Alice, not the service provider that she is
using
* Zero switching costs when changing providers
* The ability to send messages of 1 character to 10TB
* User defined workflow interactions
* Separation of contact hailing interaction from messaging

These requirements are not entirely new of course, I have raised similar
requirements over the years on this list. The reaction to my earlier
proposals was 'you cannot possibly build such a thing'. So over the last
three years I have done exactly that. I have running code and documentation
with examples generated from that running code. They do not currently meet
every requirement in full but they do provide a proof of concept for a
system that does.

Now to be fair, these are not the only requirements that I have raised,
architecture is an iterative process and requirements are dialectic to
implementation. Those are the requirements that I have met. If people want
to discuss adding or changing the requirements, it is a bit late. The code
I will be releasing this month is Phase 0. Meeting the remaining
requirements and going to a Beta release is Phase 1. The Callsign proposal
that began this discussion was my attempt to begin discussion of
requirements for Phase 2.

When I raised requirements, people dismissed my proposals as impossible to
implement, I was a fool tilting at windmills then. I was met by derision
and contempt by the usual bullies who see every new idea as a threat to
their personal position. Yet I do have running code.

The reason I knew the Mesh was possible was that I have a much wider grasp
of the available technology than most people in this organization. I
identified Threshold cryptography as the key technical advance required to
meet my requirements and persuaded two very senior ex-NSA people
they should try to put that technology on the NIST roadmap.

The reason I have no interest in creating any development dependence on
SMTP or Jabber is that having built my system, I can see that the technical
requirements implicit in the architectural requirements lead to the
following situation:

*Use cases:*
Alice knows Bob having met him. They exchange contact details. Bob supports
receipt of encrypted messages. Alice can now send Bob end-to-end encrypted
messages.
Alice knows Carol having met her. They exchange contact details. Carol does
not support receipt of encrypted messages. Alice sends messages to Carol
plaintext

*Architectural requirement:*
Sender must know the messaging protocols/formats they accept and the public
key of the recipient if supported

*Technical requirement:*
A contact catalog synchronized across all of the user's devices that are
authorized to send messages
Means of publishing, updating and verifying contact information

At the moment, I do not have a messaging interaction specified. But I do
address Mail and the use of OpenPGP and S/MIME credentials. I have not
written the scripts themselves yet but the idea is that all Alice needs to
do to be able to receive OpenPGP or S/MIME email is to run a script and it
will automatically configulate Outlook or Thunderbird with her keys. And
she can do that on all of her devices so that they can all read the S/MIME
etc. mail. Which makes it much easier for Alice to post a note in her
contact saying 'end-to-end encrypted messages preferred' which in turn
allows the client to automatically encrypt messages without Alice needing
to lift a finger on her mouse.

Sure, I can and I have done (most of) that. But just think through what it
means.

The only people who are going to be using automatically encrypted mail
messages are going to be the people who are using Mesh extensions or
something that provides the same functionality to their email client. And
every one of those users has an email client that is integrated to a
contact book that gives Bob the ability to post, 'I accept NG-MTP' in their
contact. And then, instead of sending the message via SMTP to be mauled and
harassed by anti-spam filtering heuristics, the MUA is going to post the
message via NG-MTP instead.

If Jabber was a rip roaring success, building on top of SMTP/Jabber might
make sense but it is barely on life support. Meanwhile Slack was bought for
how much?

The Web didn't just happen by accident, we spent a lot of time thinking
about deployment strategy. I ran simulations to test out different
strategies. I think I know where this goes. Finding all the companies who
felt threatened by Time Warner's Interactive TV and persuading them to work
together worked out well for us then. Why shouldn't it work now when even
more companies are afraid of being gobbled up and commoditized by Big Tech?

---

From: Jim Fenton <[email-masked]>
Date: Wed, 05 Jan 2022 12:17:19 -0800

On 1 Jan 2022, at 9:03, Keith Moore wrote:

> You don't even need an SMTP extension to do that, you just need an SMTP server that can be configured to refuse or bounce mail that isn't signed and/or encrypted.

I continue to think that the sender of a message containing potentially sensitive information is a better judge of its need for encryption than the recipient. The only example I can think of where it would be useful for the recipient to refuse unsigned/unencrypted content is a whistleblower mailbox, and then only to remind the sender to use those things, and then it’s probably too late because the message may already have been sent to an intermediate relay.

I should probably point out RFC 8689, “SMTP Require TLS Option”, that allows the sender of a message to require that it be sent via TLS. Unfortunately there isn’t any operational deployment of REQUIRETLS, perhaps in part because it requires deployment of DANE or MTA-STS to make it secure against MX record spoofing attacks and the like. Those attacks would also need to be considered when discussing anything involving public key discovery through an SMTP option or command.

-Jim

---

From: Keith Moore <[email-masked]>
Date: Wed, 5 Jan 2022 23:00:07 -0500

> I should probably point out RFC 8689, “SMTP Require TLS Option”, that allows the sender of a message to require that it be sent via TLS. Unfortunately there isn’t any operational deployment of REQU…

Also I think there's widespread agreement that hop-by-hop encryption is 
necessary but insufficient; we need message encryption also.

Agree with you that the sender, rather than any recipients, should be 
the one to determine whether a message requires encryption.   Of course 
nothing stops any sender today from encrypting outgoing messages, other 
than a lack of support by most recipients MUAs and the difficulty of 
obtaining and verifying recipients' public keys.

Keith

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 5 Jan 2022 23:15:39 -0500

> necessary but insufficient; we need message encryption also.

This is often said, but rarely seriously meant, and I don't think it
amounts to "widespread agreement".  There's been little progress or
likelihood thereof towards making E2E encrypted email usable.

> obtaining and verifying recipients' public keys.

As mentioned earlier, the public key distribution is one barrier, but
far more serious is that encrypted email is largely unusable once
received.  Point in time decryption is fine for ephemeral messages, but
I expect to be able to find and read email years or decades later, and
here S/MIME and PGP fail rather badly.

-- 
    Viktor.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 6 Jan 2022 09:28:03 -0500

On Wed, Jan 5, 2022 at 11:00 PM Keith Moore <[email-masked]>
wrote:

> > I should probably point out RFC 8689, “SMTP Require TLS Option”, that
> allows the sender of a message to require that it be sent via TLS.
> Unfortunately there isn’t any operational deployment of REQUIRETLS, perhaps
> in part because it requires deployment of DANE or MTA-STS to make it secure
> against MX record spoofing attacks and the like. Those attacks would also
> need to be considered when discussing anything involving public key
> discovery through an SMTP option or command.
>

Whether there is 'widespread agreement' is irrelevant. The facts and the
evidence prove that messages need to be encrypted end to end.

We spent the entire 2016 election with Trump's team attacking Clinton's
handling of email. The director of the FBI despicably abused his office to
join in that partisan attack. On and on and on.

Meanwhile, agents of the GRU and FSB hacked into the DNC and stole the
Democrats campaign strategy off the mail server. These were passed to the
Trump campaign and other emails were released through a Russian operative
based in London.

These events are not disputable. They are facts. Email insecurity has
changed the course of history and democracy in the US is still under threat
as a result.

Oh and if people are allowed to demean and denigrate my work as 'tilting at
windmills' without them being told they are out of line, I am going to feel
free to make partisan political points. If it is ok to make personal
attacks on other people in this group, I am going to feel free to tell
the truth about authoritarians when it is relevant to my argument,
which it is in this case.

Every one of the top 20 data breaches in history was a breach of data at
rest. And there is a good reason for that: TLS has pretty much shut down
attacks on data in transit. Data in transit is in any case the harder
attack.

We have to protect data at rest. Of course, if we are dealing with
government communications, there is going to have to be extraordinary
access. Not least because you can't have a situation where nobody knows
what the Secretary of State agreed to at a meeting because they keeled over
with a heart attack etc. Fortunately, threshold allows those types of
access to be supported with accountability controls in closed systems like
a department or agency.

If we had done our job and secured data at rest, the entire 'but her
emails' issue would have been irrelevant.

It is my belief that the entire reason that Clinton had that unauthorized
server was that she didn't trust the GSA. And she was completely right not
to. Security at the GSA is even more lax than at the NSA where a 29 year
old contractor was the administrator of the key server that had the ability
to decrypt every document. She couldn't say that was the reason of course
because people would have ridiculed the notion that a GSA employee with
access to the emails would have leaked them despite the fact there are
multiple former federal employees in prison right now for doing just that.

And yes, as Victor points out, it is necessary to do the whole job and do
it right. End-to-end encrypted mail must be exactly the same as regular
email. An email encryption scheme that requires people to remember to click
a button every time they send a message is not going to be used. Nor is a
scheme where people can't read their messages on other devices or have to
endure complex configuration.

---

From: Keith Moore <[email-masked]>
Date: Thu, 6 Jan 2022 10:40:59 -0500

On 1/6/22 9:28 AM, Phillip Hallam-Baker wrote:

> Whether there is 'widespread agreement' is irrelevant. The facts and 
> the evidence prove that messages need to be encrypted end to end.
>
> We spent the entire 2016 election with Trump's team attacking 
> Clinton's handling of email. The director of the FBI despicably abused 
> his office to join in that partisan attack. On and on and on.
Yes, but as I understand those attacks, they occurred _after_ the 
received messages were stored.  Even if we manage to protect messages 
end-to-end (from the originator's mail client until they are received by 
the server), keeping the sender-supplied encryption after the messages 
are received is a much harder problem (as I and others have pointed 
out).   People need to be able to search through received emails.
> Democrats campaign strategy off the mail server. These were passed to 
> the Trump campaign and other emails were released through a Russian 
> operative based in London.

It seemed that their security was so lax that attacking their email 
didn't require the resources of a state-supported agency.

And I think you make a good point that it's necessary to protect data at 
rest.  But if the cleartext is still easily accessible by users running 
insecure computers, that encryption will do little good.   If that 
cleartext is still accessible by users with passwords, the encryption 
will do no good at all.   Had the Clinton campaign used an encrypted 
file store to store their email, their email would have been exfiltrated 
just the same.  2FA might have helped though.

Keith

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 6 Jan 2022 11:20:08 -0500

On Thu, Jan 6, 2022 at 10:41 AM Keith Moore <[email-masked]>
wrote:

> Yes, but as I understand those attacks, they occurred _after_ the received
> messages were stored.  Even if we manage to protect messages end-to-end
> (from the originator's mail client until they are received by the server),
> keeping the sender-supplied encryption after the messages are received is a
> much harder problem (as I and others have pointed out).   People need to be
> able to search through received emails.
>

The reason I avoid using the term 'end-to-end encryption' when I can is
that people fail to understand what the ends are.

If Alice sends a personal message to Bob, end to end is Alice's brain to
Bob's brain. End to end is impossible, there must be compromises. Alice's
phone to Bob's phone is about as close as we can get to end-to-end. Alice's
phone to Bob's email server is not end-to-end by my definition.

If Alice sends a business message to Bob at his work, end to end is Alice's
brain to Bob's employer which isn't a person and doesn't have a material
existence. So the destination end is not a person, it is a process. Hence
designs like XKMS.

> It seemed that their security was so lax that attacking their email didn't
> require the resources of a state-supported agency.
>
I have spoken with multiple principals with direct knowledge of the breach.
It was a very sophisticated attack using two separate very sophisticated,
proprietary tool chains. Every one of my contacts in the Threat
Intelligence field who tracks APTs that I have talked to is confident that
the Cloudstrike attribution to cosy bear/fancy bear is correct.

I will also note that my contacts in  Threat Intelligence are
disproportionately Republican. Or at least were.

> cleartext is still accessible by users with passwords, the encryption will
> do no good at all.   Had the Clinton campaign used an encrypted file store
> to store their email, their email would have been exfiltrated just the
> same.  2FA might have helped though.
>
The current implementation of Mesh Messaging is not complete, only the
platform independent parts are currently integrated in the distribution.
But the Windows variant does have the code to store keys in DAPI and I plan
to add the same to macOS using the key manager (it is what it is for).

So in my end-to-end system, it is not sufficient to compromise the service
host. Every part of the service can be compromised, including the service
keys and key service, that is not sufficient to result in a breach of any
user data.

Again, this is not 1980s public key, it is threshold. I am using the right
technology for the task. Everyone who came before me was trying to climb
Everest without oxygen and they failed. I am using oxygen. (And
yes, Messner, 1978: he was following the route found by people
wearing oxygen).

The only way my design can be compromised is if one of the
user endpoint devices is compromised. With the DAPI code re-integrated,
that means the Windows login password has to be compromised.

I have defense in depth: The Phase #0 release isn't for securing messages,
it is for securing the powerpoint, word and excel attachments that would
contain the actual strategy details. It was the fact that Trump's people
knew where Clinton had spent her money that really damaged the campaign.

So even if an attacker gets the messages, they still have to decrypt the
contents. And they need to have authorization from the key service to do
that. And the key service can be configured to detect suspicious access
patterns (too many requests, requests from odd IP addresses) and request
out-of-band confirmation. So it is not enough for cozy beart to install
malware on her laptop, they have to compromise her smart watch as well.

In short, I have spent four and a half years thinking about this particular
set of attacks and how to block them.

Now if only 1% of the skepticism that greets every proposal to secure data
was directed at the people peddling ponzi-currency schemes. Why is it that
when people describe how to secure data, the blast shields are raised and
nothing can possibly work at all, yet suggest a half-baked scheme to move
money about while turning coal into gold and a hundred VC companies are
queued up to throw their money at it.