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

Yoav Nir <ynir@checkpoint.com> Wed, 04 December 2013 12:08 UTC

Return-Path: <ynir@checkpoint.com>
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 703FB1AE10C for <perpass@ietfa.amsl.com>; Wed, 4 Dec 2013 04:08:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.902
X-Spam-Level:
X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
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 hKLHNps_5xSS for <perpass@ietfa.amsl.com>; Wed, 4 Dec 2013 04:08:13 -0800 (PST)
Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id CD5C71AE100 for <perpass@ietf.org>; Wed, 4 Dec 2013 04:08:08 -0800 (PST)
Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id rB4C84SK016858; Wed, 4 Dec 2013 14:08:04 +0200
X-CheckPoint: {529F1806-8-1B221DC2-1FFFF}
Received: from IL-EX10.ad.checkpoint.com ([169.254.2.146]) by DAG-EX10.ad.checkpoint.com ([169.254.3.213]) with mapi id 14.03.0123.003; Wed, 4 Dec 2013 14:08:04 +0200
From: Yoav Nir <ynir@checkpoint.com>
To: Stephane Bortzmeyer <bortzmeyer@nic.fr>
Thread-Topic: [perpass] perens-perpass-appropriate-response-01
Thread-Index: AQHO8JgPgoGdSxG4zUeLBq0vLL1MJZpDwOmAgAAPVoA=
Date: Wed, 4 Dec 2013 12:08:03 +0000
Message-ID: <0FB50CCD-38AB-41B6-8617-30F2BB03C592@checkpoint.com>
References: <E2DA1477-C86E-441E-A33D-D47A0D67AFF3@iab.org> <EF9BD1E4-6EF3-4035-AC4E-1A2D3CADE615@mnot.net> <529E8494.7000806@perens.com> <20131204111309.GB11727@nic.fr>
In-Reply-To: <20131204111309.GB11727@nic.fr>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.31.21.79]
x-kse-antivirus-interceptor-info: scan successful
x-kse-antivirus-info: Clean
Content-Type: text/plain; charset="us-ascii"
Content-ID: <05321A7874B75641871D6099C671C19E@ad.checkpoint.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "<perpass@ietf.org>" <perpass@ietf.org>, Bruce Perens <bruce@perens.com>
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 12:08:16 -0000

On Dec 4, 2013, at 1:13 PM, Stephane Bortzmeyer <bortzmeyer@nic.fr> wrote:

> [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.

Or at least, making surreptitious surveillance more difficult. Although the political response should be discussed elsewhere, the technical requirements from protocols stem from the desired political response. Engineers don't get to make up the requirements.
 
> 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. 

It's even more true for the Internet attacks than for burglary. The police make some effort to stop burglaries. If your house is broken into, they will send a squad car and they will file a report, and they might even try to investigate. They are also watching for stolen property to get the thieves later on. They are not making anywhere near that effort for Internet crime. Try filing a report that someone sent you an email with a malware attachment. So as far as Internet crime is concerned, we're living in the movie version of the wild west, and we need to protect ourselves.

>> 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.

Law enforcement in your own country should also go through some vetting process before they can force you to decrypt traffic for them, usually an order signed by a court of law. At least that is the way it should be in free countries (corollary: if you're forced to decrypt your laptop at the airport or at home without a specific warrant, that is not a free country)

>> 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.

True, and the files you access say a lot about you regardless of their content. I don't know what people who saw a list of the Wikipedia articles I've read would think of me. I shouldn't care about it either, because it's nobody's business what Wikipedia articles I've read. But we don't even have to go for the privacy example. Imagine a semiconductor company specializing in chips for routers and switches, with offices around the world, and we can get a log of the URLs that they access. All of the sudden we see from several of their offices requests going to the following URLs:

http://en.wikipedia.org/wiki/Zigbee
http://en.wikipedia.org/wiki/IEEE_802.15.4
http://en.wikipedia.org/wiki/Internet_of_things
http://www.ayu.ics.keio.ac.jp/~bingo/research/EI_CPSCom.pdf
http://tools.ietf.org/wg/core/
http://tools.ietf.org/photo/bormann-carsten.jpg
http://tools.ietf.org/photo/mcgregor-andrew.jpg
http://tools.ietf.org/html/draft-ietf-core-coap-18
http://tools.ietf.org/html/draft-ietf-core-http-mapping-02

I think we have just learned something about this company's future plans, which is information they have not made public. If we protect the confidentiality of requests, all we have here is access to Wikipedia and tools, which isn't nearly as revealing as the specific resources. That's a kitten-less argument for encrypting access to public resources.

>> 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.

It really depends on what else you do with the data besides encrypting. The extreme example is a router than can either do or not do IPsec. In that case, you'll get around 10x or 20x the bandwidth with the non-encrypted traffic. For servers the ratio is much lower, because they have to do something to get the data that they intend to send, even if that just means loading the data from a file or database.
> 
>> 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.)

Gah. I expected this to be a www.ietf.org certificate vs a ietf.org URL, but this is far worse.

Yoav