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

Peter Saint-Andre <> Mon, 19 August 2013 01:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8FED421F9C78 for <>; Sun, 18 Aug 2013 18:44:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.545
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PpbMLSgDdG5C for <>; Sun, 18 Aug 2013 18:44:00 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id F263721F9C86 for <>; Sun, 18 Aug 2013 18:43:58 -0700 (PDT)
Received: from ergon.local (unknown []) (Authenticated sender: stpeter) by (Postfix) with ESMTPSA id ADC49414F7; Sun, 18 Aug 2013 19:47:10 -0600 (MDT)
Message-ID: <>
Date: Sun, 18 Aug 2013 19:44:02 -0600
From: Peter Saint-Andre <>
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 <>
References: <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc:, Brian Trammell <>
Subject: Re: [perpass] On the perfect passive adversary, men at the end, and configuration versus mechanism
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. " <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 19 Aug 2013 01:44:04 -0000

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]
> 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 Saint-Andre

Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools -
Comment: Using GnuPG with Thunderbird -