On Fri, Dec 31, 2021 at 6:04 PM John C Klensin <john-ietf@xxxxxxx> wrote:
--On Friday, December 31, 2021 17:09 -0500 Phillip Hallam-Baker
<phill@xxxxxxxxxxxxxxx> 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 alice@xxxxxxxxxxx. 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 alice-bob-only@xxxxxxxxxxx (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. Only the callers she authorizes get access to her personal inbox, everyone else gets her PA or her fan club secretary.
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.
If there
were one reasonable, network-wide authentication mechanism
(which might or might not involve a key server), they would not
need to negotiate.
The whole point of tying the naming system to the key service is to effect that scheme.
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).
The fact that the user's application never talks to the recipient's inbound mail server in the SMTP model as deployed makes that unworkable. And you can't change that either because there are multiple layers of services between that inbound email server and the user's inbox.
Alternately, it would be fairly easy to write an extension,
probably cloning and modifying STARTTLS, that would use OpenPGP
to hide most of the envelope or, indeed, use OpenPGP as an
alternative to all elements of TLS except the tunnel itself.
Some versions of the latter would have the same problem that
using TLS with SMTP does, naming having to have keys scattered
around and get the envelope (and maybe the message) at least
partially into cleartext at each relay. But, unless one says
"no relays", one has to be satisfied with either encrypting
content (maybe including message headers) but not envelopes or
having things in clear on the relay almost no matter what one
does.
By the time you have made those changes, you have a sufficiently different protocol to need a signaling mechanism to advise the existence of an upgrade option. That is how I got to building the Mesh in the first place.
The Mesh does make using S/MIME and OpenPGP email pretty easy. But the messaging infrastructure it uses to make SMTP palatable can be applied to build a mail system vastly superior to and more capable than SMTP.
My system is designed from the ground up as the basis for a workflow system. Alice sends a task to Bob or Carol, Bob accepts it first, completes it creating a task for Doug. Meanwhile Alice can view the whole process flow in real time and see what is happening. Sure, I could try to make that work with SMTP, OpenPGP and a cargo container full of duct tape. But it would suck because messages would be dropped all the time by all the other ad hoc in the system.
> In my scheme, Alice can decide she is only going to accept
> calls from @bob and @carol. She can put @stalker on a
> blocklist that prevents him from retrieving her contact
> assertion, posting messages, placing calls, etc. etc.
For accepting calls and running blocklists all of that can be
done with SMTP. Whether it can be done with SMTP as provided by
a particular mail service provider is another question, but that
just implies either finding a different provider or supplying
the current provider enough incentive to offer it.
It has proved impossible to go from a default permit security posture to default deny. The only way to really deal with spam is to have a situation where every email is authenticated by its originator and the originating service.
The core of the proposal here is an infrastructure that maintains a mapping from a persistent identifier to contact assertions that can be authenticated to a public key signature.
That enables each user to maintain a contact book that is always up to date and tells each user what the best way to communicate with each contact.
If Alice and Bob both think Signal is the best way to communicate for messaging, that is how their apps will establish a messaging communication between them. If they think it is Splunge, they will use that.
Of course, applications that allow those communications to be established under keys trusted explicitly and directly are going to be preferable to me than those which require me to trust some key server that is functionally a CA but they won't admit functions as a CA and lacks all the controls a proper CA might have.
@alice is merely a layer of syntactic sugar for Alice's public key that is her personal root of trust.
