On 06/21/2012 04:52 PM, intrigeri wrote: > Hi, > > Jacob Appelbaum wrote (21 Jun 2012 06:03:13 GMT) : >> On 06/20/2012 06:24 PM, intrigeri wrote: > >>> Wouldn't any of the following tricks work? >>> >>> - set 0.0.0.0 as proxy IP >>> - set a port number that is larger than the max. legal TCP port >>> number > >> I'm not sure, I bet it would work. > > Ah, some possibility of *really* failing closed on the horizon. > Sounds much better than the initial "There is no way to fail closed" :) >
There is no known, tested and sure way to fail closed. :) >>>> However, I think that it is absolutely imperative to use that option >>>> with gpg and thunderbird. Otherwise, we leak a cryptographic >>>> identity, directly, not indirectly. :( >>> >>> I'm not sure what exactly you mean by leaking a cryptographic >>> identity, but perhaps it's because the last time I have read your >>> threat model was months ago. >>> >>> I see two major problems with the default GnuPG behaviour: >>> >>> 1. if an encrypted message is Bcc'd to several recipients, >>> every recipient gets to know which other public OpenPGP >>> keys the message was encrypted to. >> This. > >>> 2. whoever can snoop along the email routing path can link recipient >>> email addresses with OpenPGP public key IDs. >> This. > >>> 3. < insert here what I'm missing :) > >> Also the mail servers who receive the message. > > I consider the email route to go from the sender's MUA to every > recipient's MUA, so this is part of "whoever can snoop along the email > routing path". > Ok. >>> To clarify, which one is the cryptographic identity leak that makes it >>> absolutely necessary to switch to the --throw-keyids mode? > >> All three above - especially if the mail servers in question do not >> use TLS or STARTTLS, or if the user is using 0.2.2.x Tor without the >> Isolated Streams work. > > Well... I think I now can see what you're trying to achieve by > enabling --throw-keyids, but doing this has a huge cost. > I agree there is a cost - I think the cost is minimal, any user with multiple keys and profiles likely can make a second Thunderbird profile as well, no? > Strategically speaking, > I'm not convinced we practically do all of this at the same time: > > 1. encourage widespread use of OpenPGP for email encryption > 2. encourage widespread use of contextual identities > 3. a) hide the "an unpublished OpenPGP public key X exists and presumably > belongs to the email address A" information > b) hide the other recipients to a recipient of a Bcc's email > > Given we want to keep #1, > I tend to prefer throwing away #3 to get #2, > than throwing away #2 to get #3 the contrary. > Unless I've misunderstood, it looks like we disagree on that point. I haven't really decided. I wanted to ensure that no one shot themselves in the foot in a way that we couldn't fix later. At the moment, things may simply break in an annoying but not de-anonymizing fashion. Basically, I want #1, #2 and #3b - I'm not too worried about #3a but it would be nice to have anyway. For example - I'd like to be able to use an anonymous remailer to send a message to you and no one would know *which* key is the one they need to beat out of you. > > A compromise could be to *not* use --throw-keyids by default, but > opportunistically enable it *only* when sending encrypted email to > a bunch of Bcc'd recipients. This way, #3.b is covered, and at the > same time #2 is not too much harmed. What do you think? That might be reasonable. Patches welcome and all that... :) All the best, Jake _______________________________________________ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
