[perpass] mail tracking (was; Re: Getting started...)

Stephen Farrell <stephen.farrell@cs.tcd.ie> Sat, 17 August 2013 15:14 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: perpass@ietfa.amsl.com
Delivered-To: perpass@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B84A11E813D for <perpass@ietfa.amsl.com>; Sat, 17 Aug 2013 08:14:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hD-THQ+UWX5N for <perpass@ietfa.amsl.com>; Sat, 17 Aug 2013 08:14:21 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 5E54B11E813F for <perpass@ietf.org>; Sat, 17 Aug 2013 08:14:21 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 06B54BE24; Sat, 17 Aug 2013 16:14:19 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xMOYPsSw4jCz; Sat, 17 Aug 2013 16:14:17 +0100 (IST)
Received: from [10.87.48.8] (unknown [86.44.76.14]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 1218ABE1C; Sat, 17 Aug 2013 16:14:17 +0100 (IST)
Message-ID: <520F933E.4070309@cs.tcd.ie>
Date: Sat, 17 Aug 2013 16:14:06 +0100
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8
MIME-Version: 1.0
To: Ben Laurie <benl@google.com>
References: <520E5684.1090005@cs.tcd.ie> <CABrd9SS6txRujNLbLqscKncK+Q=9YLPzX_3-sNuLP56VFMBLiw@mail.gmail.com> <520F6405.6010102@cs.tcd.ie> <CABrd9SR-+ypxEOwrOgQEyUK6FcguoKmg_P++xKm5tWvUAsTV2w@mail.gmail.com>
In-Reply-To: <CABrd9SR-+ypxEOwrOgQEyUK6FcguoKmg_P++xKm5tWvUAsTV2w@mail.gmail.com>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: perpass@ietf.org
Subject: [perpass] mail tracking (was; Re: Getting started...)
X-BeenThere: perpass@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " <perpass.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/perpass>, <mailto:perpass-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/perpass>
List-Post: <mailto:perpass@ietf.org>
List-Help: <mailto:perpass-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/perpass>, <mailto:perpass-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 17 Aug 2013 15:14:26 -0000

Changed the subject...

On 08/17/2013 01:04 PM, Ben Laurie wrote:
> On 17 August 2013 07:52, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
> 
>>
>> Hi Ben,
>>
>> On 08/17/2013 12:37 PM, Ben Laurie wrote:
>>> On 16 August 2013 12:42, Stephen Farrell <stephen.farrell@cs.tcd.ie>
>> wrote:
>>>
>>>> what should we be doing?
>>>
>>>
>>> Certificate Transparency is an anti-monitoring tool, amongst other useful
>>> properties.
>>
>> Yep. Its a fine tool but more I guess directed at countering
>> an active attacker who spoofs as a web site and then monitors
>> or snarfs passwords or whatever.
>>
>>> The more generalised idea of a public, verifiable log of stuff is
>> probably
>>> useful in other ways, too.
>>>
>>> For example, DNSSEC Transparency (OK, hardly much different from CT).
>>>
>>> Someone mentioned default encrypting emails: sparse Merkle trees are an
>>> efficient data structure for making a verifiable map of email addresses
>> to
>>> public keys...
>>
>> neat idea... maybe.
>>
>> However, that and other foo-transparency ideas also require
>> clients to ask the log about stuff, in a way that the log
>> can.... log.
>>
> 
> So, Private Information Retrieval is a way around this issue. I don't know
> much about it, yet, but I'm told its fairly expensive. But I think not too
> expensive for this kind of operation.

Be interesting if that were the case. I'd otherwise have assumed
it was too expensive but be interested if you find out better.

> 
> As it happens, I am planning to do some work with Ian Goldberg on the
> subject, and so will have more to say about it in a while.
> 
> Also, it may be that simply retrieving the whole log is feasible. We're not
> talking about vast amounts of data.

I wondered about that. Anyone know how big the MIT PGP key server
DB is for example?

I'd say storing it locally would be fine, and probably figuring
out some kind of sharding thing and then asking for a full shard
rather than Ben's public key could work ok maybe.

>> For CT, thats ok since the web site itself (or its
>> auditors) can contact the CT log, but I wonder if that'd
>> become a problem for other foo-transparency applications,
>> e.g. how could an MUA query a log of public keys without
>> exposing the meta-data that I'm sending you an encrypted
>> message?
>>
> 
> I would observe that you already reveal that, unless you come up with some
> entirely novel way of delivering email. I am not suggesting that this means
> the problem should not be solved, but it seems that encrypting the payload
> routinely moves the needle a fair amount - enough to be worth doing while
> we figure out the whole thing.

Sure. The point is if we added a log that serves up the public keys
of my recipients, then I don't want to make that log yet another place
where monitoring can easily be done.

And aside from that you'd also want to clean up which mail headers are
protected, run SMTP/TLS always (maybe with a flag in the header to say
to barf if TLS isn't on) etc.

Seems like there are a bunch of imperfect things here that could
be pretty doable. I've no idea if people are really motivated to
do 'em though. Nor am I sure if they'd add up to enough to make
mail significantly more robust against monitoring.

S.


> 
> 
>>
>>> Yes, I have a hammer and I am looking for nails.
>>
>> :-)
>>
>> S.
>>
>>>
>>>
>>>
>>> _______________________________________________
>>> perpass mailing list
>>> perpass@ietf.org
>>> https://www.ietf.org/mailman/listinfo/perpass
>>>
>>
>