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

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