Re: [perpass] politics and the ietf

Stephen Kent <kent@bbn.com> Fri, 06 December 2013 15:10 UTC

Return-Path: <kent@bbn.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 9F8A51ADF6E for <perpass@ietfa.amsl.com>; Fri, 6 Dec 2013 07:10:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.302
X-Spam-Level:
X-Spam-Status: No, score=-2.302 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 OWe54iT4k1Io for <perpass@ietfa.amsl.com>; Fri, 6 Dec 2013 07:10:53 -0800 (PST)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 5C4AF1AE03B for <perpass@ietf.org>; Fri, 6 Dec 2013 07:10:53 -0800 (PST)
Received: from dommiel.bbn.com ([192.1.122.15]:59539 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1Vox3J-000EFb-1K for perpass@ietf.org; Fri, 06 Dec 2013 10:10:49 -0500
Message-ID: <52A1E8F8.5080002@bbn.com>
Date: Fri, 06 Dec 2013 10:10:48 -0500
From: Stephen Kent <kent@bbn.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: perpass@ietf.org
References: <20131205072546.2740.2142915422.0@crow> <F979A3D1-0084-4DDF-8E16-9F063BE0295F@isoc.org> <529F8F94.3020506@gmx.net> <52A083C2.3030405@w3.org>
In-Reply-To: <52A083C2.3030405@w3.org>
Content-Type: multipart/alternative; boundary="------------050509080200060007050704"
Subject: Re: [perpass] politics and the ietf
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: Fri, 06 Dec 2013 15:10:56 -0000

Harry,

> ...
>
> In the "early days" of the Internet, to my knowlege, the Internet was 
> more of a research project amongst co-operative researchers at places 
> like MIT, SRI, and CERN with the Web so security and privacy concerns 
> were minimal at best. I'm not sure what else can explain early RFCs :) 
> Obviously this has changed, and now folks have to retro-fit these 
> security on top the system.
As one who has been actively involved since "the early days" I have to 
disagree with your characterization. Internet R&D was funded primarily 
by the U.S. DoD, and thuis security was a consideration. Moreover, the 
sort of passive and active wiretapping attacks that we're discussing, 
ones that can be carried out by nation states, were a concern. The
technical approach to dealing with such attacks was to employ 
encryption, on an end-to-end basis, for realtime communication. Sound 
familiar?

BBN built a basic e-t-e encryption device (the PLI) in the mid-1970's, 
for use in the ARPANET. Later in the 70's we worked with ARPA (now 
DARPA) to develop a more sophisticated system, one that worked with 
TCP/IP, provided per-connection security associations, and which used a 
KDC. (This was a few years before the MIT Kerberos project began and 
long before public key crypto was considered practical.)

All of this was well before development of the Web, even before DNS, in 
a simpler
environment. My point is that technology was developed to provide protection
against passive and active wiretapping of Internet protocols. It was not 
developed for
the software implementations that we see in OSes, because the DoD 
understood the vulnerabilities that arise in a software-based 
implementation. The solutions focused on external, hardware crypto, 
inline between a computer (or a gateway) and the Internet. That made the 
solutions developed for the DoD environment unattractive for typical 
commercial, much less, residential users.

Steve