Re: [Tails-dev] TorBirdy: first impressions

Delete this message

Reply to this message
Author: intrigeri
Date:  
To: Jacob Appelbaum
CC: tails-dev, Sukhbir Singh
Subject: Re: [Tails-dev] TorBirdy: first impressions
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" :)

>>> 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".

>> 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.

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.

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?

Cheers,
--
intrigeri
| GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc