Re: [Tails-dev] TorBirdy: first impressions

このメッセージを削除

このメッセージに返信
著者: Jacob Appelbaum
日付:  
To: intrigeri
CC: tails-dev, Sukhbir Singh
題目: Re: [Tails-dev] TorBirdy: first impressions
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