On 02/09/2015 12:40 PM, Bjarni Runar Einarsson wrote: > We considered something very similar to what Whiteout are doing, and > decided against it for a few reasons. The main ones being: > 1. Just because a user has a key in a key server, does not mean they > currently can (or want to) read encrypted mail.
At LEAP, we faced this same dilemma. At first, we choose the Whiteout path (always opportunistic if listed in keyservers) and then switched to Mailpile (do not always send first email encrypted). We might switch back. There may be some middle ground: if a key is of sufficient key length, and updated within a recent window of time, then there is a much higher likelihood that the user does in fact desire encrypted email. If you look at the actual keys in the keyservers, a shocking number of them are really old and 1024 bit RSA. There are two failures: (1) the keyserver has the bogus key (2) the recipient did not expect or desire encrypted email. I don't think #1 is just a targeted attack, since probably some troll will soon figure out how easy it is to fill the keyservers with imposter keys, for the lulz. Until then, #2 is still a big problem. We will only enrage the user if too many of their recipients can't read their mail. On 02/09/2015 11:40 AM, Trevor Perrin wrote: > Moreover, it doesn't solve the entire problem - if you want > reliable automatic encryption, key lookup isn't just a *first* message > problem, it's an *every* message problem, because keys change. This is extremely important. Perhaps I should get this in tattoo form. For the short term, it seems necessary and fine for TOFU to be part of any automatic key management strategy. But this is just the first step, the real question is how these keys are handled after the TOFU. The rules LEAP is going by are described here: https://pad.riseup.net/p/key-validation On 02/09/2015 12:58 AM, Tankred Hase wrote: > we've added HKP key server support to Whiteout Wail and have written a > post about usability. Though I'd share it here: Cool. We are playing with a similar system, although federated, where we proxy HKP lookups, but return authoritative results for the home provider (every LEAP-powered service provider runs a key lookup service, and the response is authoritative for addresses owned by the provider but proxied for foreign requests [with longish delay], and falls back to HKP proxy cache if no better source can be found). Those of us working on email are grappling with the same issues. Many of the common issues relate to how different projects will interact with one another. This list has had fruitful discussions on key validation, but there are other important topics too, for example: (1) Subject header. Ugh. (2) We need a new protocol that allows a sender to advertise to the recipient what their key is and that they prefer encrypted email. The email signature is a good signal, but not ideal because there is no real binding between the fingerprint on the signature and the email address (unless the provider is in the habit of uploading signatures to the public keyservers). The OpenPGP header has the same problem. One solution would be an "X-Provider-Key-Endorsement" header that allowed the client to pick among well defined methods for retrieving a key endorsed by the provider (could be super simple, like webfinger). A universal system of key validation would obviate the need for this, but until we all agree on a single standard... (3) We need common practices for "verified key transitions". (4) Metadata, mega woes. There are many approaches, but Pond's is probably the best. The cool thing is that direct delivery to recipient provider can be an opportunist option when the recipient supports it. LEAP is one of the parties that will soon start on the PANORAMIX project from George Danezis to develop and deploy a new mix network infrastructure. We plan to use this for user -> server direct delivery of email (in addition to server-to-server). and so on... -elijah _______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
