[messaging] The Simple Thing

[Trevor Perrin]

Hi Elijah,

Here's my take on the relationship between the 98% / 2% argument, and
Moxie's "simple thing":

The 98% encrypt / 2% encrypt+authenticate argument was first made by
Tom Ritter [1], and I've advocated for it as "Opportunistic
Encryption" [2].

I think it makes sense assuming:
 1) end-to-end encryption is easy to deploy widely
 2) end-to-end authentication is not
 3) E2E encryption has value, even without E2E auth (i.e. active
attack has costs and risks, particularly if authentication is
stealthy)

I've argued that for an authentication method to be "compatible" with
OE, only users who perform E2E authentication should pay its costs
[2].  Both TOFU + fingerprints (Moxie's "simple thing") and
"transparency logs" are compatible with OE in this sense.  Key-centric
approaches (eg keys-as-addresses and NameCoin) are not, as they
replace existing names and name semantics, imposing new costs on all
users.

Moxie made a cost/benefit argument for TOFU+fingerprints, instead of
transparency logs:  they both do "roughly the same thing" [3] in
detecting key changes, but supporting TOFU and fingerprints is easy,
whereas transparency logs require a new infrastructure of logs,
monitors, gossip protocols, publishing all addresses, etc.

On the list, no one answered Moxie with a detailed argument as to how
transparency logs add enough benefit to justify the cost, compared to
the "simple thing".  It seems like an open question.


You wrote:
"""
(1) The client should use whatever latest key is advertised inline via
headers in email it receives. Ideally, this would be validated by the
provider via a very simple mechanism (such as grab user Bob's key from
this well-known https URL).
[...]
There are still a few edge cases. Alice might email Bob using a key for
Bob that he no longer uses. Should the provider bounce the email to let
Alice know? Or should Alice ask the provider if the key is still valid
every time she sends a message to Bob (or once a day)?
"""

Bouncing messages whenever Bob changes his key seems bad.  Alice might
send a message and then disconnect, so you can't count on her mail
client to auto-resend, and the message might be lost or delayed.

So Alice should probably confirm the key with the recipient's provider
before sending a message.  In which case Bob's email header doesn't
need to list Bob's key, it just says "X-Lookup-Key: True", and Alice
remembers that.

Bob's server would get two connections per message (one from Alice,
one from Alice's MTA).  It would be nice if Alice could contact Bob's
MTA once to confirm the key and send the message.  I suppose that's
feasible in a centralized system where the server handles spam by
tracking reputations for Alice and Bob.  But it doesn't seem feasible
for email.

---

Bigger question:  Is this a route to widespread OE?  Or is this
something only a tiny fraction of users would turn on?

Widespread OE for email seems hard.  Much of the userbase is on
browsers, relying on ad-funded infrastructure and server search.
Worse, to manage spam it seems like email has evolved to be fairly
hostile to content encryption, identity-hiding, and
relationship-hiding.

So if we're not attempting OE, and we just want email-like messaging
for the small population that will install special security tools, I
guess I'm not sure why should build those on email at all (vs
Pond/Petmail, SMTorP, etc.)?


Trevor


[1] https://moderncrypto.org/mail-archive/messaging/2014/000229.html
[2] https://moderncrypto.org/mail-archive/messaging/2014/000767.html
[3] https://moderncrypto.org/mail-archive/messaging/2014/000723.html