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-----
- [perpass] On the perfect passive adversary, men a… Brian Trammell
- Re: [perpass] On the perfect passive adversary, m… Stephen Farrell
- Re: [perpass] On the perfect passive adversary, m… Peter Saint-Andre
- Re: [perpass] On the perfect passive adversary Brian Trammell
- Re: [perpass] On configuration versus mechanism Brian Trammell
- Re: [perpass] On men at the end Brian Trammell
- Re: [perpass] On the perfect passive adversary Brian Trammell
- Re: [perpass] On the perfect passive adversary Stephen Farrell
- Re: [perpass] On the perfect passive adversary Brian Trammell
- Re: [perpass] On the perfect passive adversary Stephen Farrell