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
