Re: [perpass] perens-perpass-appropriate-response-01

Stephen Farrell <> Sat, 07 December 2013 13:14 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 57E5B1AE2FC for <>; Sat, 7 Dec 2013 05:14:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TgOao4IJ5wZf for <>; Sat, 7 Dec 2013 05:14:27 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id E11811AE2F9 for <>; Sat, 7 Dec 2013 05:14:24 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id C3A17BE8B; Sat, 7 Dec 2013 13:14:16 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id iiivV7nXWXue; Sat, 7 Dec 2013 13:14:15 +0000 (GMT)
Received: from [] (unknown []) by (Postfix) with ESMTPSA id 6BC4EBE8A; Sat, 7 Dec 2013 13:14:15 +0000 (GMT)
Message-ID: <>
Date: Sat, 07 Dec 2013 13:14:05 +0000
From: Stephen Farrell <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: Bruce Perens <>, Nicholas Weaver <nweaver@ICSI.Berkeley.EDU>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Subject: Re: [perpass] perens-perpass-appropriate-response-01
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 07 Dec 2013 13:14:29 -0000


On 12/07/2013 07:29 AM, Bruce Perens wrote:
> On 12/06/2013 01:20 PM, Nicholas Weaver wrote:
>> If the attacker can see your fetches he can execute a
>> man-on-the-side attack through packet injection.
> This is the first one I've seen that is actually compelling.

I agree that Nicholas' posting is compelling. It really is.

I also agree that a bunch of the non-technical analogy-driven
stuff is not at all compelling.

But one compelling argument is enough really.

> But it's an . authentication problem rather than a confidentiality
> one.

I don't think so. The lack of confidentiality lets the
adversary win the race unless you assume 100% coverage
of authenticated JS and 100% validation of that and that
there are no diginotar like entities involved in the
currently non-existent JS authentication infrastructure.

Even ignoring the race condition, it'd only be reasonable
to treat this as an authentication-only problem if there was
a solution for the JS authentication problem.

Today, there's no such solution for how to load JS with
integrity but without TLS after an https:// "landing page"
load. I've thought about ways to do it with RFC 6920, but
so far without finding a way that could scale or would be
likely to get adopted - apparently the JS code gets
updated too often for a 6920 based approach to help very

So, while authenticated-JS is also a fine problem on which
to work, today we have tooling for addressing the problem
via ubiquitous TLS but we do not have the kind of tooling
that would be needed for a solution that does not provide

Even if we only did opportunistic encryption then an
observatory could spot a pervasive attack against that, or
against that for Air France to use the example cited. (Air
France might be motivated to want such an observatory to
exist for example.)

Separately, if one considers the long-tail bits of JS code
loaded from the long-tail set of web sites then again there
is some benefit in confidentiality since without that the
adversary can pervasively find the vulnerable code and sites
from those. The "long-tail" here is relevant because we
should assume the adversary knows the vulnerabilities for the
top-10^N sites and JS packages. I think any IETF approach
to this kind of thing should not give a high preference to
the top-10^N anything really, which again argues for doing
this based on TLS or similar I think.

So what I see is a compelling problem-statement, and an
existing set of tools that can address that if more widely
deployed, and where confidentiality is in reality an inherent
part of doing that.