Re: [perpass] On the perfect passive adversary, men at the end, and configuration versus mechanism

Peter Saint-Andre <stpeter@stpeter.im> Mon, 19 August 2013 01:44 UTC

Return-Path: <stpeter@stpeter.im>
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 8FED421F9C78 for <perpass@ietfa.amsl.com>; Sun, 18 Aug 2013 18:44:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.545
X-Spam-Level:
X-Spam-Status: No, score=-102.545 tagged_above=-999 required=5 tests=[AWL=0.054, 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 PpbMLSgDdG5C for <perpass@ietfa.amsl.com>; Sun, 18 Aug 2013 18:44:00 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id F263721F9C86 for <perpass@ietf.org>; Sun, 18 Aug 2013 18:43:58 -0700 (PDT)
Received: from ergon.local (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id ADC49414F7; Sun, 18 Aug 2013 19:47:10 -0600 (MDT)
Message-ID: <52117862.7050501@stpeter.im>
Date: Sun, 18 Aug 2013 19:44:02 -0600
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
References: <2941892B-9F23-46F9-B993-446D7800A0DF@tik.ee.ethz.ch> <521140EE.1080309@cs.tcd.ie>
In-Reply-To: <521140EE.1080309@cs.tcd.ie>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: perpass@ietf.org, Brian Trammell <trammell@tik.ee.ethz.ch>
Subject: Re: [perpass] On the perfect passive adversary, men at the end, and configuration versus mechanism
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: Mon, 19 Aug 2013 01:44:04 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 8/18/13 3:47 PM, Stephen Farrell wrote:
> 
> On 08/18/2013 07:45 PM, Brian Trammell wrote:
>> 
>> I would propose that we consider this as one of the threat models
>> we address; the exercise I propose is to examine the protocols
>> we're familiar with and think about (1) what's in the payload,
>> (2) what can be inferred from identifying metadata (IP addresses
>> and port numbers, application-layer addresses (email addresses,
>> URLs, etc) (3) what can be inferred from non-identifying metadata
>> (data volume and packet counts, interarrival times,  control
>> information such as sequence numbers, and so on).
> 
> Taking a look at [1] would be good also for folks who weren't at
> the TLS wg session in Berlin - an 83% probability of identifying
> users based on the size of their FB avatar images as sent over TLS
> is an interesting result I think.
> 
> [1] http://www.ietf.org/proceedings/87/slides/slides-87-tls-3.pdf
> 
> But I absolutely agree that if we can somehow inventory the
> protocols which we know (each of us having different knowledge)
> from this pov that'd be valuable.

I've thought about this over the last few months in relation to
XMPP-based instant messaging. My conclusions are (a) XMPP cannot be
made into a privacy-protecting technology (even if we could settle on
a sustainable approach to end-to-end encryption) and (b) we'll need to
develop new technologies that are universally encrypted, don't rely on
DNS-based addresses, a federated network of servers, etc.

I still think there is value in pushing for universal TLS for both
client-to-server and server-to-server connections in XMPP, publishing
an RFC for OTR and encouraging more implementations thereof, and so
on. However, I'm not confident that such improvements will address the
fundamental issues that have arisen over the last few months.

> (I'm hoping someone jumps in now to say they're interested in
> writing that up as an I-D or wiki or something.)

Right now I'm more interested in helping out on code and spec work
related to a project that I think has promise.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/




-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSEXhhAAoJEOoGpJErxa2pHNAP/3zKGs+2eXnSK8s4UmJHu/eU
dGW53BXkk8nJDBsj0qQsWwuvPRH/9hjRhpJXErRVKfKSB+lVPqL16HF/RBCvHZC7
WHlKxIHqJ+pGqgS6WXSOtl/3IyWB4wHvkzKYjLRJGYn/rCevGMkzrjMZ1UncMkGC
6P5Rl5Itpz1opCBijxBxYIIVXTaZXt+s4qGLxOhL+18oPZ1ujwuUtHpY5Mlk+mxJ
nHM2cebPIzJ38bI5MLqkTLvpSryydI+Hd6apq+U1yDWW4hr05wVDmsh3R0kH+9vU
sdqrKzKLDL9UtKwWa98uAMs+bBt91lDLgEg1lestd1K6SZ7sEvnUVYQJB+AZ8WfE
06NfmJ0O6nIJ978oZ4DSDi+EsBWX2375TJYzTdXWtt+Hq1zT8dgl2qwQBgwp+zPg
LYrHtlEPB3nug5GV0DU3JSRBXpd/Hqg+2IcSuUBME4SyYw6sirnhycl9WLJIGVjJ
BKKV2pWA69lunKbP6EsXHYPzJoL8eKT65FpmZxCoMlBy7djZ1NQUo7iXquD6uteZ
LutulZ2LNAopIxFoONcLs2JDKJmsmX6pAN7J1bduyaNXNqlt+aetlkT+jZ5VCPCv
aQI2l166tsRIqXF3QFO6PrikgaJpxN4Hfx2gxsTwO9mVOrcbSQY/NyE8hiMELJdC
Pwlo+M8Bp7gzlLtVQcO1
=TyeE
-----END PGP SIGNATURE-----