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 [email protected] https://moderncrypto.org/mailman/listinfo/messaging
