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

Stephane Bortzmeyer <bortzmeyer@nic.fr> Wed, 04 December 2013 11:13 UTC

Return-Path: <bortzmeyer@nic.fr>
X-Original-To: perpass@ietfa.amsl.com
Delivered-To: perpass@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D9201AE106 for <perpass@ietfa.amsl.com>; Wed, 4 Dec 2013 03:13:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.551
X-Spam-Level:
X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, RP_MATCHES_RCVD=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7DziPyYTylSb for <perpass@ietfa.amsl.com>; Wed, 4 Dec 2013 03:13:49 -0800 (PST)
Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) by ietfa.amsl.com (Postfix) with ESMTP id 5C11E1AE222 for <perpass@ietf.org>; Wed, 4 Dec 2013 03:13:43 -0800 (PST)
Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id B4461280294; Wed, 4 Dec 2013 12:13:39 +0100 (CET)
Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx4.nic.fr (Postfix) with ESMTP id AFB1F28019F; Wed, 4 Dec 2013 12:13:39 +0100 (CET)
Received: from bortzmeyer.nic.fr (batilda.nic.fr [IPv6:2001:67c:1348:8::7:113]) by relay1.nic.fr (Postfix) with ESMTP id AD1844C007C; Wed, 4 Dec 2013 12:13:09 +0100 (CET)
Date: Wed, 4 Dec 2013 12:13:09 +0100
From: Stephane Bortzmeyer <bortzmeyer@nic.fr>
To: Bruce Perens <bruce@perens.com>
Message-ID: <20131204111309.GB11727@nic.fr>
References: <E2DA1477-C86E-441E-A33D-D47A0D67AFF3@iab.org> <EF9BD1E4-6EF3-4035-AC4E-1A2D3CADE615@mnot.net> <529E8494.7000806@perens.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <529E8494.7000806@perens.com>
X-Operating-System: Debian GNU/Linux 7.2
X-Kernel: Linux 3.2.0-4-686-pae i686
Organization: NIC France
X-URL: http://www.nic.fr/
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: perpass@ietf.org
Subject: Re: [perpass] perens-perpass-appropriate-response-01
X-BeenThere: perpass@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " <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: Wed, 04 Dec 2013 11:13:50 -0000

[List of recipients trimmed to be more reasonable.]

On Tue, Dec 03, 2013 at 05:25:40PM -0800,
 Bruce Perens <bruce@perens.com> wrote 
 a message of 37 lines which said:

>    I have written a reply to draft-farrell-perpass-attack-00
>    Please read it at
>    [1]http://perens.com/works/ietf/perpass/appropriate-response/01.pdf

I fully agree with the idea that the problem is *political* and should
receive a *political* response. However, as you noted, IETF is not a
political forum and is not the right place for this sort of
action. But, if the *main* response should be political, the IETF can
still *help* by making mass surveillance more difficult. It is a
general principle in security: make laws but do not neglect technical
measures to make the lives of the attackers more difficult. We have
laws against burglary, for instance, but we still develop better
locks, and for good reasons. So, yes, the work of perpass is perfectly
legitimate and reasonable.

> Attacks on consumer privacy by commercial entities are generally
> within the domain of civil law. 

IANAL but this does not seem to me to be true. In my country,
collecting illegal personal data is a criminal offense.

> Technical attacks by sovereign powers are in general justified by
> those powers as being part of law enforcement. The justice of such
> enforcement is the topic of political discourse and the
> courts. [...] Technical responses to attacks on individual privacy
> by sovereign entities may be held as acceptable, criminal, or even
> treasonous conduct by those entities. [...] The proposers and
> implementers of systems intended to hinder law enforcement are
> arguably a criminal or treasonous conspiracy.

But the Internet is international. My surveillance (not me,
personally, but because it monitors everyone) by the NSA is certainly
illegal in my country. Whether or not it is legal in the USA is
irrelevant to me. Therefore, any technical measure against it is fair
game.

> None of these things [static JS or CSS files] are secret and there
> is little reason to obscure an individual's access to them.

Excuse me, but it seems you did not participate in the many
discussions about privacy in the last ten years. It is now well-known
that any information can be processed and used to find out about
users. Monitoring access to these files is one of the simplest means
to deduce (from the pattern of access) what an user is doing. There
are therefore many reasons to obscure it.

> There is also an energy cost: the electricity wasted by all of this
> encryption would likely result in megatons of additional carbon
> emitted from the burning of fossil fuel for electric generation, as
> well as otherwise-avoidable social and economic costs of renewable
> energy sources.

Is there a serious comparison somewhere about the relative cost of
encryption when we routinely access HD video files? I am not sure at
all that encryption is the main cost.

> Unfortunately, encryption doesn't help with this. The information
> being collected comes predominantly from web servers and browser
> tool bars, which are on the ends of the communication where it is
> necessarily decrypted. The server owners and software providers
> profit from using or selling user data.

Indeed, that's the main weakness of RFC 6973. But it is not a reason
to avoid encryption, because there are still threats by sniffing
third-parties. We have many holes by which private information
leak. We try to plug these holes. All of them. (Remember that the NSA
has PRISM, with the participation of the big Web silos like Google or
Facebook, but also has MUSCULAR - spying on unencrypted links -
because they prefer to have belts *and* suspenders. Following this
line, we have to secure both the endpoints and the links.)

> It's almost universally held within the working groups that users
> can't be responsible for their own security,

It is not IETF-specific, it is the opinion of most security experts,
backed by many observations and studies. This is not contempt, just
the recognition that a message "X.509 certificate has the wrong
issuer, do you want to continue?" is not easy to analyse and to act
upon, even for an expert. It is not fair to ask Mr Smith to decide
based on this information. He knows nothing about security (and that's
fine with me, I don't blame him for that, I know nothing about Mr
Smith's own area of expertise)

(Go to <https://ietf.org/> if you want a good laugh.)