[messaging] The Simple Thing

[zaki at manian.org]

Breaking down Trevor's open question further.

The value proposition of CT remains ambiguous because the following
questions remain unanswered.
   - What are the practical barriers to serving a falsified key to a user
that does not appear in the globally available log?
   - What sort of evidence of malicious behavior by a key server would
be perceived as credible?
   - What incentives do auditors face? Would they face incentives to
collude with the identity providers or robustly investigate report of MITM
attacks?

The first two questions remain unanswered because CT proposals are still
incomplete. The third question may be incomplete because answering it
requires skills not present in our community. Analyzing incentives
governing the behavior of rational actors is the specialty of economists.



On Thu, Sep 25, 2014 at 1:48 AM, Trevor Perrin <trevp at trevp.net> wrote:

> 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
> _______________________________________________
> Messaging mailing list
> Messaging at moderncrypto.org
> https://moderncrypto.org/mailman/listinfo/messaging
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20140925/aa85d10c/attachment.html>