Re: [perpass] On the perfect passive adversary

Brian Trammell <> Wed, 04 September 2013 14:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A896B21F99C3 for <>; Wed, 4 Sep 2013 07:29:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id eTji6p8+M5cm for <>; Wed, 4 Sep 2013 07:29:03 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id E4D9311E812E for <>; Wed, 4 Sep 2013 07:28:27 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 794F5D9307; Wed, 4 Sep 2013 16:28:26 +0200 (MEST)
X-Virus-Scanned: by amavisd-new on
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with LMTP id tOzECdanUde8; Wed, 4 Sep 2013 16:28:26 +0200 (MEST)
Received: from ( []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by (Postfix) with ESMTPSA id 33478D9305; Wed, 4 Sep 2013 16:28:26 +0200 (MEST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Brian Trammell <>
In-Reply-To: <>
Date: Wed, 4 Sep 2013 16:28:25 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: Stephen Farrell <>
X-Mailer: Apple Mail (2.1508)
Subject: Re: [perpass] On the perfect passive adversary
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: Wed, 04 Sep 2013 14:29:07 -0000

hi Stephen, all,

One update, inline...

On 19 Aug 2013, at 9:00 , Brian Trammell <> wrote:

> hi Stephen, all,
> Yeah, sorry for the giant multitopic rant. I'll split this out into a few threads to continue...
> On Aug 18, 2013, at 11:47 PM, Stephen Farrell <> wrote:
>> Hi Brian,
>> First, thanks for the thoughtful post. You make some good points.
>> A few responses below. Might be better to follow up in separate
>> mails, since you raise too many interesting points probably:-)
>> On 08/18/2013 07:45 PM, Brian Trammell wrote:
>>> Greetings, all,
>>> On the floor of my home directory, there are notes for a paper we
>>> never finished called "The Perfect Passive Adversary"; intended as a
>>> survey of the state of the network security and measurement
>>> literature and practice to explain what is possible if one assumes an
>>> adversary which can (1) observe every packet of every communication
>>> at every point within a network but (2) does not have access to the
>>> endpoints beyond the network interface (i.e. no keyloggers, and no
>>> bulk access to user data at a service provider) and (3) cannot
>>> influence packet forwarding. It grew to be rather too wide in scope
>>> and too paranoid in tone to have a realistic chance at publication,
>>> so we dropped it, which in retrospect seems a silly choice.
>> So publish it! As an I-D even:-) But if you have a version that
>> you're happy to share, that'd be great to see.
> I dusted this off and had a look at it last night, and it's in worse shape than I'd thought as a coherent piece of work. But completing it (to -00 I-D quality, at least) and publishing an I-D -- especially given the scope of the conversation on this list -- seems like a great idea. I'll get started.

This is now available at; the current revision works mainly on the definition of the threat model and the justification thereof. There are notes on what's observable and what's inferable and some initial guidance, but mainly the point of this revision is to determine whether we think it's a useful definition of the adversary and a good structure for guidance to take from that definition.

On review of RFC 6973, I see it addresses many of the points relevant to the threat posed by pervasive surveillance. The main difference is that its definition of surveillance (section 5.1.1.) makes an assumption that there is a given target of surveillance, which in pervasive surveillance is not necessarily the case: one "advantage" of pervasive surveillance is the ability to select targets after the fact of the communications capture. But in general, surveillance is an attack against privacy, and 6973 presents a very good framework for talking about privacy in a protocol design context. So, if we move forward with this document, I'd like to see it grow as an extension of 6973.

Best regards,