From nweaver@icsi.berkeley.edu Mon Dec 2 08:56:39 2013 Return-Path: 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 2C5D41AD738 for ; Mon, 2 Dec 2013 08:56:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 KVDe9YZINTgh for ; Mon, 2 Dec 2013 08:56:37 -0800 (PST) Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id 4249E1AD687 for ; Mon, 2 Dec 2013 08:56:29 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 441AF2C403F; Mon, 2 Dec 2013 08:56:27 -0800 (PST) X-Virus-Scanned: amavisd-new at ICSI.Berkeley.EDU Received: from rock.ICSI.Berkeley.EDU ([127.0.0.1]) by localhost (maihub.ICSI.Berkeley.EDU [127.0.0.1]) (amavisd-new, port 10024) with LMTP id qXktZd0igrAV; Mon, 2 Dec 2013 08:56:26 -0800 (PST) Received: from gala.icir.org (gala.icir.org [192.150.187.130]) (Authenticated sender: nweaver) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 8D6442C4038; Mon, 2 Dec 2013 08:56:26 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_C25FB1AD-48B6-4CFF-AD4F-3B37F5695EAE"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Nicholas Weaver In-Reply-To: <20131127150548.GA25960@nic.fr> Date: Mon, 2 Dec 2013 08:56:26 -0800 Message-Id: References: <9B79CCC3-853E-42F4-8390-ED0EE019C275@icsi.berkeley.edu> <20131127150548.GA25960@nic.fr> To: Stephane Bortzmeyer X-Mailer: Apple Mail (2.1510) Cc: perpass , Nicholas Weaver Subject: Re: [perpass] A reminder, the Network is the Enemy... 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 16:56:39 -0000 --Apple-Mail=_C25FB1AD-48B6-4CFF-AD4F-3B37F5695EAE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Nov 27, 2013, at 7:05 AM, Stephane Bortzmeyer = wrote: > On Wed, Nov 20, 2013 at 12:42:53PM -0800, > Nicholas Weaver wrote=20 > a message of 70 lines which said: >=20 >> = http://www.wired.com/opinion/2013/11/this-is-how-the-internet-backbone-has= -been-turned-into-a-weapon/ >=20 > You mention DNSSEC twice, as a solution against some man-on-the-side > attacks (injecting false DNS answers). >=20 > The Schneier paper > > about QUANTUM mentions packet injection but not the DNS. We don't know > if the NSA does DNS poisoning (but we may assume they - and other > actors - do it). We can bet they do: Its the easiest way (and just about the only way) = to privilege escalate a man on the side to a MITM, which is needed to = use things like a fake cert for SSL decryption. =20 A full MITM on a backbone link is a very dangerous thing to install, = because failures get noticed and its also far easier to get the friendly = ISP to install something that is "just a tap", while installing a full = MITM closer to the victim may often be very difficult or downright = impossible to do without getting caught. > However, if the attacker is the NSA, we have to take into account the > possibility that they can sign data with the root's private key, which > is under US management. Therefore, is DNSSEC still useful? Actually spoofing DNSSEC replies even with knowledge of the root key is = going to be difficult... Simply put, the attacker is going to need to create a fake path of trust = or an insecure delegation. So, eg, assuming the target is: target.example.com and the attacker only has a copy of the root key. They are going to have to create a fake NSEC for .com, wait for a query = for .com to go to the root (to enable the fake NSEC record), and then = wait until the victim queries for victim.example.com or the victim does = another query back to the root, which makes getting caught far more = likely. =20 And since .com and other TLDs support DNSSEC, you could hardcode "there = must be DS record from . for these TLDs", this wouldn't work. (An = alternative would be a fake DS, and then fake EVERY reply from .com with = new RRSIGs... And for that, you have a timing problem because your = injector may not know the answer TO inject!) And at the same time, its still packet injection (and therefore still = detectable, see = http://conferences.npl.co.uk/satin/papers/satin2012-Duan.pdf=E2=80=8E ). So although its possible that the root ZSK gets compromised by the NSA, = its something that I'd not only consider rather unlikely, but something = that even if they did, it would be something they wouldn't want to use, = especially now that packet injection IS on everybody's radar and if they = got caught, the own-goal damage against US interests (so much of DNSSEC = on the authority side has been driven by DHS) would be huge. -- Nicholas Weaver it is a tale, told by an idiot, nweaver@icsi.berkeley.edu full of sound and fury, 510-666-2903 .signifying nothing PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc --Apple-Mail=_C25FB1AD-48B6-4CFF-AD4F-3B37F5695EAE Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCgAGBQJSnLu6AAoJEG2B1w+SDi/unJ0P/R6IzJFKsiEwhdAKyIpWd9Ld NLSZNfpfLjO2/3fh3s1MBJnFncVfLO45Hfj77aN393zChh0UWXkg6aRnFBpJnoq/ WTe4I70tQGaBSQIoHkkd8hdsQ/VkuBEsCdh8mByqdseXrGjE7fywZmfwJuhgIRcy ySNQkS/0vLS7Iu53O8peFp902zNH2N6QEXacPuzJQ4JN4x+oILjgrnaRyjsTkkBC 2cbQu/tPGtGG1M2lHCyGYaMX15ZN7Cdlbp5zsAmemjq6KufI0LVZdleWGrDlP+3h R+eNeHnk3kydI8wCT2cc5tCP04X8VHDqW0tVexEsoqH7tSP5BLDy8NDhru1r4kDt pYqtfx8DZGXoQxErzMwrKbHtlq/sdLLNndUTYJUWBuaCm+deTXzSBxSA4zQkVcp6 NcztLZDFSfNGRp9u/i/Yofd9PfxStb6x6xB/pJbRXu33iwl6vKVn85oaY6e1UJfR GELb6pnvede0jE8CoCjtpfgQJ21QfeCFWFR4YQE6ma48ZI9VYM2OGMl3Ndt4DCZR ycE37Ow/ZcRMHNKNm1NuXA1ghMICJOIMH2w/PxcP0QDa2OP3g7QloO+2fRfw1qM0 LGRUU3Yx36yPsiVpoUupSwRPuZfvRVzPsX/xKVLHrKbseqP8j/ZWz2LP7gRIr/IY 6l5zCI2QtTvz16nRwZdq =JyaR -----END PGP SIGNATURE----- --Apple-Mail=_C25FB1AD-48B6-4CFF-AD4F-3B37F5695EAE-- From bortzmeyer@nic.fr Tue Dec 3 06:47:27 2013 Return-Path: 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 2431C1ADF0F for ; Tue, 3 Dec 2013 06:47:27 -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 eJ0WyTQroAXJ for ; Tue, 3 Dec 2013 06:47:25 -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 89E9C1AD9AB for ; Tue, 3 Dec 2013 06:47:25 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 6011D280231; Tue, 3 Dec 2013 15:47:22 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx4.nic.fr (Postfix) with ESMTP id 5B84B280173; Tue, 3 Dec 2013 15:47:22 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [IPv6:2001:67c:1348:8::7:113]) by relay2.nic.fr (Postfix) with ESMTP id 4EDA8B3800C; Tue, 3 Dec 2013 15:46:52 +0100 (CET) Date: Tue, 3 Dec 2013 15:46:52 +0100 From: Stephane Bortzmeyer To: Nicholas Weaver Message-ID: <20131203144652.GA3144@nic.fr> References: <9B79CCC3-853E-42F4-8390-ED0EE019C275@icsi.berkeley.edu> <20131127150548.GA25960@nic.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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] A reminder, the Network is the Enemy... 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 14:47:27 -0000 On Mon, Dec 02, 2013 at 08:56:26AM -0800, Nicholas Weaver wrote a message of 112 lines which said: > Actually spoofing DNSSEC replies even with knowledge of the root key > is going to be difficult... Very convincing reasoning. But I would feel better if it were actually tested in a lab with common resolvers. Any volunteer here? From sm@resistor.net Tue Dec 3 08:48:27 2013 Return-Path: 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 C4BBC1AE17D for ; Tue, 3 Dec 2013 08:48:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.6 X-Spam-Level: X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 R1YkN4k5PGEQ for ; Tue, 3 Dec 2013 08:48:26 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 703811AE120 for ; Tue, 3 Dec 2013 08:48:26 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id rB3GmIXZ007685; Tue, 3 Dec 2013 08:48:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1386089303; bh=Vxxmx+eRO1flpdx0Wp/DTsQPZuRAN5wGJhZJL5wakTE=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=hrTyjAq0685HHcGS5xndEliFx9L2myMXm8lQ1CvVlyX2/yBFB5EjuhHepgMlnbMZI 1OMw41Nl/cL82RWmGFj+dMN4AxJEKgRcMdRDXUHQZ3+EMzTf1wrNdSCcC56A2l+AqE x7aChlCUXQa4JUFcz8/76TXWVXYF18bVay+DF8MI= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1386089303; i=@resistor.net; bh=Vxxmx+eRO1flpdx0Wp/DTsQPZuRAN5wGJhZJL5wakTE=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=1yJXrRV4+7rdA/OgvlpPZxMplsDWMbxwGcBM7Nb4FTCkh5/c7E9eZhWqbW9bFks5h k9yxSLt5IwEUzUjLTOpch2JdEwue4+7iPSkUev1ibPU7MHmMtu5IXmCSrd/QFbzvyO iaNJbxsM+KClK38EypQoaNtQrlr8NCA3bB9lLYmA= Message-Id: <6.2.5.6.2.20131203082804.0e2a9168@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 03 Dec 2013 08:37:29 -0800 To: Eric Burger From: SM In-Reply-To: <9E17C7BF-FBFD-4C6C-81E9-34704FB24FC4@standardstrack.com> References: <5295FC4F.7060309@dcrocker.net> <5295FDE8.5000402@cs.tcd.ie> <5296C8CC.2060508@dcrocker.net> <027a01ceebfb$df99f290$9ecdd7b0$@huitema.net> <9E17C7BF-FBFD-4C6C-81E9-34704FB24FC4@standardstrack.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: perpass@ietf.org Subject: Re: [perpass] "Guide to intranet protection"? 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 16:48:28 -0000 Hi Eric, At 07:32 30-11-2013, Eric Burger wrote: >In the shameless self-promotion department, this IS my day job. See >http://s2erc.georgetown.edu/projects/cyberISE/ for the theoretical >work and http://gcsc.georgetown.edu/ if one needs an operational venue. The work looks interesting (on paper :-)). It is worthwhile, to get a broader view of what is at http://s2erc.georgetown.edu/projects/cyberISE/ as the topic is mentioned every now and then outside the IETF. Regards, -sm From stephen.farrell@cs.tcd.ie Tue Dec 3 09:53:37 2013 Return-Path: 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 BD6601ACC7D for ; Tue, 3 Dec 2013 09:53:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ImUeN9ST7DU8 for ; Tue, 3 Dec 2013 09:53:35 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 8D9DA1AC3DD for ; Tue, 3 Dec 2013 09:53:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id CAC97BEA4 for ; Tue, 3 Dec 2013 17:53:31 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id no1Lvue9lToN for ; Tue, 3 Dec 2013 17:53:30 +0000 (GMT) Received: from [10.43.49.206] (unknown [193.190.253.145]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 6D6D0BE87 for ; Tue, 3 Dec 2013 17:53:30 +0000 (GMT) Message-ID: <529E1A9A.7030202@cs.tcd.ie> Date: Tue, 03 Dec 2013 17:53:30 +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: perpass References: <20131203174853.21387.74650.idtracker@ietfa.amsl.com> In-Reply-To: <20131203174853.21387.74650.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.6 X-Forwarded-Message-Id: <20131203174853.21387.74650.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [perpass] Fwd: ID Tracker State Update Notice: 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 17:53:38 -0000 Hi all, We made various tweaks to the draft as a result of the shepherd (Sean) and sponsoring AD (Jari) reviews and Jari has now started an IETF LC. So I guess discussion of this will be on ietf@ietf.org now. That should be fun as always, but please do chime in as you see fit - personally I think this is an important part of the overall story to get done and done well. Cheers, S. -------- Original Message -------- Subject: ID Tracker State Update Notice: Date: Tue, 03 Dec 2013 09:48:53 -0800 From: IETF Secretariat To: stephen.farrell@cs.tcd.ie, Hannes.Tschofenig@gmx.net, draft-farrell-perpass-attack@tools.ietf.org Last call has been made for draft-farrell-perpass-attack and state has been changed to In Last Call ID Tracker URL: http://datatracker.ietf.org/doc/draft-farrell-perpass-attack/ From drc@virtualized.org Tue Dec 3 12:12:36 2013 Return-Path: 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 708581AC404 for ; Tue, 3 Dec 2013 12:12:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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 AnXP-5k2lTLh for ; Tue, 3 Dec 2013 12:12:34 -0800 (PST) Received: from alpha.virtualized.org (alpha.virtualized.org [199.233.229.186]) by ietfa.amsl.com (Postfix) with ESMTP id 209091AD8F5 for ; Tue, 3 Dec 2013 12:12:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by alpha.virtualized.org (Postfix) with ESMTP id 27712863E0; Tue, 3 Dec 2013 15:12:30 -0500 (EST) Received: from alpha.virtualized.org ([127.0.0.1]) by localhost (alpha.virtualized.org [127.0.0.1]) (maiad, port 10024) with ESMTP id 00405-09; Tue, 3 Dec 2013 15:12:29 -0500 (EST) Received: from [10.0.1.6] (c-24-4-109-25.hsd1.ca.comcast.net [24.4.109.25]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: drc@virtualized.org) by alpha.virtualized.org (Postfix) with ESMTPSA id D8330863C6; Tue, 3 Dec 2013 15:12:28 -0500 (EST) Content-Type: multipart/signed; boundary="Apple-Mail=_A198F4AA-051B-4B6B-A73F-0999EFD2D225"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: David Conrad In-Reply-To: <20131203144652.GA3144@nic.fr> Date: Tue, 3 Dec 2013 12:12:26 -0800 Message-Id: <5607F638-E332-4C6A-AC97-50AD738D56CB@virtualized.org> References: <9B79CCC3-853E-42F4-8390-ED0EE019C275@icsi.berkeley.edu> <20131127150548.GA25960@nic.fr> <20131203144652.GA3144@nic.fr> To: Stephane Bortzmeyer X-Mailer: Apple Mail (2.1822) Cc: perpass@ietf.org, Nicholas Weaver Subject: Re: [perpass] A reminder, the Network is the Enemy... 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 20:12:36 -0000 --Apple-Mail=_A198F4AA-051B-4B6B-A73F-0999EFD2D225 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Dec 3, 2013, at 6:46 AM, Stephane Bortzmeyer = wrote: > On Mon, Dec 02, 2013 at 08:56:26AM -0800, > Nicholas Weaver wrote a message of 112 = lines which said: >> Actually spoofing DNSSEC replies even with knowledge of the root key >> is going to be difficult... >=20 > Very convincing reasoning. But I would feel better if it were actually > tested in a lab with common resolvers. Any volunteer here? I think a better target for that question would be = dns-operations@lists.dns-oarc.net :) Regards, -drc --Apple-Mail=_A198F4AA-051B-4B6B-A73F-0999EFD2D225 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJSnjsqAAoJENV6ebf0/4rXWQkH/A8Arb0og67u9i5P/vvpnVni vQMOepC/3Ixl6/I3fSkPlZKkMUzvuj0iQsIhKIhqvHOF/iiV2++7gc4rju6r8mKm kX3V6jiSnvbYXmdeu5Mi6+NT6DOvnonsi0vuUrYq+Uast5kuaIhsyONZC6K4g3L2 V77K4wrIE81Vp/3oqMqxiq/uT2lOtOgUgdWXL5Z/Hsk+TiNvEQW3CWln5Zq2xPqx bd9Qmh6S+DCCKGWR+XK1b7WPtS92cnMRJPQ5D+lco12xhDU6wlhoRF45G7y9dJU4 ixrVtewnMERNNY3Jn5/o8IR2VqWq7u6+hr4UcvKSgsQONKgeleyEaruAaF+dFNo= =66LF -----END PGP SIGNATURE----- --Apple-Mail=_A198F4AA-051B-4B6B-A73F-0999EFD2D225-- From bruce@perens.com Tue Dec 3 17:25:41 2013 Return-Path: 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 DE5181ADFFD; Tue, 3 Dec 2013 17:25:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.177 X-Spam-Level: X-Spam-Status: No, score=-1.177 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, 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 31wOoak-EGhg; Tue, 3 Dec 2013 17:25:41 -0800 (PST) Received: from alchemy.perens.com (alchemy.perens.com [206.221.219.26]) by ietfa.amsl.com (Postfix) with ESMTP id E89BD1ADFC8; Tue, 3 Dec 2013 17:25:40 -0800 (PST) Received: from [192.168.10.146] (c-50-168-114-183.hsd1.ca.comcast.net [50.168.114.183]) by alchemy.perens.com (Postfix) with ESMTPSA id 0EADA50008A; Tue, 3 Dec 2013 17:25:37 -0800 (PST) Message-ID: <529E8494.7000806@perens.com> Date: Tue, 03 Dec 2013 17:25:40 -0800 From: Bruce Perens User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131103 Icedove/17.0.10 MIME-Version: 1.0 To: ietf@ietf.org, perpass@ietf.org, ietf-http-wg@ietf.org References: In-Reply-To: Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 02:24:57 -0000 I have written a reply to draft-farrell-perpass-attack-00
Please read it at http://perens.com/works/ietf/perpass/appropriate-response/01.pdf
The reply is _not_ in the form of an Internet Draft, because it's political discourse.

    Thanks

    Bruce Perens
From fallenpegasus@gmail.com Tue Dec 3 19:49:04 2013 Return-Path: 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 012101ADF91 for ; Tue, 3 Dec 2013 19:49:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-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 jCDKHgPMSwK9 for ; Tue, 3 Dec 2013 19:49:02 -0800 (PST) Received: from mail-ve0-x22a.google.com (mail-ve0-x22a.google.com [IPv6:2607:f8b0:400c:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 2CEE01AE192 for ; Tue, 3 Dec 2013 19:49:02 -0800 (PST) Received: by mail-ve0-f170.google.com with SMTP id oy12so11721998veb.1 for ; Tue, 03 Dec 2013 19:48:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=On82dtNDW1ww6RxYXjphV1sMcW3YfZVt9NWCBgubnzQ=; b=y+ZzGq9A6EXCrolVgAWymXGi6bYCkKSxZ8lbsTt6b7mn0sGYtKyMUrdqvWO2Oy1yVl 1SeMXuvsSGYvQ8AjF29oZ3iIIp7035BgugstQEgvjLTR4DL9MnZoqKHg/mT4jDVL1KY7 /b14BkLmmXAF+3/ARSBMy/Xr65kdHPcqqr9yWLjtH6SO/3KQ0YHqH8xlTSRG5a7UYCCe 8uGZSDXUI5/VR6I7LX5JsaWFkv2OBeJTV1ooVwO2S9LP2jgG6XYNes/t/ioV77+fyWFi jtbqcBqk3ItwSCpt/d6gj7Czzaz8DEmf4okJqLZN4ZeIhXnfv99XAFX6Gv+3nM1Wgpth 13lg== X-Received: by 10.220.50.18 with SMTP id x18mr528027vcf.29.1386128938918; Tue, 03 Dec 2013 19:48:58 -0800 (PST) MIME-Version: 1.0 Sender: fallenpegasus@gmail.com Received: by 10.52.177.168 with HTTP; Tue, 3 Dec 2013 19:48:30 -0800 (PST) In-Reply-To: <9E17C7BF-FBFD-4C6C-81E9-34704FB24FC4@standardstrack.com> References: <5295FC4F.7060309@dcrocker.net> <5295FDE8.5000402@cs.tcd.ie> <5296C8CC.2060508@dcrocker.net> <027a01ceebfb$df99f290$9ecdd7b0$@huitema.net> <9E17C7BF-FBFD-4C6C-81E9-34704FB24FC4@standardstrack.com> From: Mark Atwood Date: Tue, 3 Dec 2013 19:48:30 -0800 X-Google-Sender-Auth: RLI4-rGu5k4L1Hb8HfnrD2NsUvo Message-ID: To: Eric Burger Content-Type: text/plain; charset=UTF-8 Cc: perpass Subject: Re: [perpass] "Guide to intranet protection"? 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 03:49:04 -0000 I see "georgetown.edu" in this sort of context, and all I can think of is the famous statement "PGP could potentially become a widespread problem", stated by the NSA stooge Professor Dorothy Denning from Georgetown University. It makes me untrusting and suspicious. On Sat, Nov 30, 2013 at 7:32 AM, Eric Burger wrote: > In the shameless self-promotion department, this IS my day job. See http://s2erc.georgetown.edu/projects/cyberISE/ for the theoretical work and http://gcsc.georgetown.edu/ if one needs an operational venue. > > On Nov 28, 2013, at 9:49 AM, Phillip Hallam-Baker wrote: > >> On Thu, Nov 28, 2013 at 1:08 AM, Randy Bush wrote: >> > Randy is quite right. >> >> has to happen occasionally >> >> > The attacks reported in the news article were against the private >> > optical fibers linking the geographically distributed data centers of >> > large companies like Google or Yahoo. A discussion about that should >> > start with the folks in charge of securing these data centers at >> > Google, Yahoo, Facebook, Microsoft, et cetera. I can see some >> > difficulties, because a fair bit of the data centers architectures is >> > probably treated as trade secret. And I am really not sure that the >> > IETF is the best place to conduct such discussions. >> >> we had/have the same oroblem with datacenter* wgs. the folk who really >> do it think of it as secret sauce. so it becomes the vendors trying to >> sell solutions to problems they don't understand. hell, i don't even >> know iij datacentr technology to any depth. >> >> Just to be clear, when I said they are more willing to share than you said earlier, I was referring to a closed door sharing in some members only forum. That model definitely works. >> >> The IETF might play a role in brokering the setting up of such an organization but any sharing is not going to take place in public and not in the IETF and it is going to take place at a certain degree of abstraction. >> >> >> >> -- >> Website: http://hallambaker.com/ >> _______________________________________________ >> perpass mailing list >> perpass@ietf.org >> https://www.ietf.org/mailman/listinfo/perpass > > > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > From erik.josefsson@europarl.europa.eu Tue Dec 3 21:08:48 2013 Return-Path: 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 921001AE1EC; Tue, 3 Dec 2013 21:08:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 bRqbaJpPQKm2; Tue, 3 Dec 2013 21:08:45 -0800 (PST) Received: from SMTP35.europarl.europa.eu (smtp35.europarl.europa.eu [136.173.162.228]) by ietfa.amsl.com (Postfix) with ESMTP id 1897E1AE1D8; Tue, 3 Dec 2013 21:08:43 -0800 (PST) Received: from EMAILBRUSV62.ep.parl.union.eu (unverified) by SMTP35.europarl.europa.eu (European Parliament) with ESMTP id ; Wed, 4 Dec 2013 06:08:39 +0100 Received: from eicibwp079.ep.parl.union.eu ([136.173.96.209]) by EMAILBRUSV62.ep.parl.union.eu with Microsoft SMTPSVC(6.0.3790.4675); Wed, 4 Dec 2013 06:08:38 +0100 Received: from UCEXBWP021.ep.parl.union.eu ([10.127.249.55]) by eicibwp079.ep.parl.union.eu with Microsoft SMTPSVC(6.0.3790.4675); Wed, 4 Dec 2013 06:08:38 +0100 Received: from UCEXBWP007.ep.parl.union.eu (10.127.249.41) by UCEXBWP021.ep.parl.union.eu (10.127.249.55) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 4 Dec 2013 06:08:38 +0100 Received: from UCEXBWP009.ep.parl.union.eu ([169.254.7.236]) by UCEXBWP007.ep.parl.union.eu ([169.254.5.46]) with mapi id 14.03.0158.001; Wed, 4 Dec 2013 06:08:38 +0100 From: JOSEFSSON Erik To: Bruce Perens , "ietf@ietf.org" , "perpass@ietf.org" , "ietf-http-wg@ietf.org" Thread-Topic: [perpass] perens-perpass-appropriate-response-01 Thread-Index: AQHO8JgNacgtQZLGn06xw0NXsFVM55pDfIcH Date: Wed, 4 Dec 2013 05:08:38 +0000 Message-ID: <4B654B63C9A4614EA1F088B2490E8F3A05C30F@UCEXBWP009.ep.parl.union.eu> References: , <529E8494.7000806@perens.com> In-Reply-To: <529E8494.7000806@perens.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.127.249.6] Content-Type: multipart/alternative; boundary="_000_4B654B63C9A4614EA1F088B2490E8F3A05C30FUCEXBWP009epparlu_" MIME-Version: 1.0 X-OriginalArrivalTime: 04 Dec 2013 05:08:38.0854 (UTC) FILETIME=[E47A9E60:01CEF0AE] 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 05:08:48 -0000 --_000_4B654B63C9A4614EA1F088B2490E8F3A05C30FUCEXBWP009epparlu_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks! //Erik ________________________________ From: perpass [perpass-bounces@ietf.org] on behalf of Bruce Perens [bruce@p= erens.com] Sent: Wednesday 4 December 2013 02:25 To: ietf@ietf.org; perpass@ietf.org; ietf-http-wg@ietf.org Subject: [perpass] perens-perpass-appropriate-response-01 I have written a reply to draft-farrell-perpass-attack-00 Please read it at http://perens.com/works/ietf/perpass/appropriate-response= /01.pdf The reply is _not_ in the form of an Internet Draft, because it's political= discourse. Thanks Bruce Perens --_000_4B654B63C9A4614EA1F088B2490E8F3A05C30FUCEXBWP009epparlu_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Thanks!

//Erik

From: perpass [perpass-bounces@ietf.org] o= n behalf of Bruce Perens [bruce@perens.com]
Sent: Wednesday 4 December 2013 02:25
To: ietf@ietf.org; perpass@ietf.org; ietf-http-wg@ietf.org
Subject: [perpass] perens-perpass-appropriate-response-01

I have written a reply to draft-farrell-perpass-attack-00
Please read it at http://perens.com/works/ietf/perpass/appropriate-response/01.pdf
The reply is _not_ in the form of an Internet Draft, because it's political= discourse.

    Thanks

    Bruce Perens
--_000_4B654B63C9A4614EA1F088B2490E8F3A05C30FUCEXBWP009epparlu_-- From martin@millnert.se Wed Dec 4 02:07:28 2013 Return-Path: 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 5A00C1AE059; Wed, 4 Dec 2013 02:07:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.693 X-Spam-Level: X-Spam-Status: No, score=0.693 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, RDNS_NONE=0.793, SPF_PASS=-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 T3dVEaH9k7Qe; Wed, 4 Dec 2013 02:07:26 -0800 (PST) Received: from mail.millnert.se (unknown [95.80.32.84]) by ietfa.amsl.com (Postfix) with ESMTP id B6AA41AE067; Wed, 4 Dec 2013 02:07:25 -0800 (PST) Received: from [172.25.90.101] (gw.ipnett.ideon.se [85.235.1.171]) by mail.millnert.se (Postfix) with ESMTPSA id C1241B0; Wed, 4 Dec 2013 11:10:01 +0100 (CET) Message-ID: <1386151640.22570.70.camel@galileo.millnert.se> From: Martin Millnert To: Bruce Perens Date: Wed, 04 Dec 2013 11:07:20 +0100 In-Reply-To: <529E8494.7000806@perens.com> References: <529E8494.7000806@perens.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-xntkbTz+gwAJ0Uez//W5" X-Mailer: Evolution 3.4.4-3 Mime-Version: 1.0 Cc: ietf-http-wg@ietf.org, perpass@ietf.org, ietf@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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 10:07:28 -0000 --=-xntkbTz+gwAJ0Uez//W5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Bruce, On Tue, 2013-12-03 at 17:25 -0800, Bruce Perens wrote: > I have written a reply to draft-farrell-perpass-attack-00 > Please read it at > http://perens.com/works/ietf/perpass/appropriate-response/01.pdf > The reply is _not_ in the form of an Internet Draft, because it's > political discourse. The only technical argument that I found with any relevance and merit is that proper encryption of every HTTP operation in HTTP2 would make transparent proxying and caching without the end-users knowledge impossible. =20 I'd assume that has been discussed on HTTP-WG already, but in terms of perpass, that is a feature/bug which is of much much lesser importance than the dangers of pervasive surveillance. HTTP2 with encryption will not make CDNs impossible, or even really change them in any meaningful way since HTTP1/2 is merely the transport. (CDN redirection is done using DNS or HTTP headers/payload.) Nor will it make the enterprise with managed clients' content filtering appliances impossible. Uses, legitimate or not, of transparent proxy/caching will be hurt, AFAIK, and that's the only technical issue worth debating IMHO. Personally I'm ok with that. Even so, there are ways to signal existence of caching proxies which can be extended to cover some of these areas, by moving to non-transparent proxying. For the other, mostly technical, arguments put forth by you: p3. A sovereign entity may outlaw technical protocol X: It wouldn't be a sovereign entity if it couldn't. It could outlaw Pi =3D 3.1459... for all I care. Point is we should not let a single Sovereign Entity outlaw the correct definition of Pi, for the rest of us. It is precisely within IETF's jurisdiction to define our global common Internet communication protocols. If a single backwards Sovereign Entity held veto power over this we would be much poorer today. Instead the backwards sovereign entities will have to live without these protocols, which is what they in their sovereignty decided anyway, so everybody would be happy... p3. Unnecessary to encrypt static content: It has been quite clearly shown that precisely this traffic path on the web is an attack vector against a host. It makes perfect sense to secure that attack vector. p3. Pervasive surveillance glass half empty/half full (Technical solutions do not lead to justice): Prefer half full. p4. Encryption use a lot of power: It is strictly true that encryption spends more CPU cycles - how much could be estimated - I would expect single-digit % extra cycles, with proper stack and browser implementations. Spending these single-digit extra cycles does not increase power usage linearly, due to CPU caching and more. I personally guess the true power usage delta is less than 0.1% for ordinary web browsing. p5. IETF is forbidden from doing any work if there is a related political debate on a topic: Disagree. I do agree technical society should work closer with political society, and I think this is happening increasingly. It does not imply that a global political absolute consensus is required for every Internet protocol update, because that will never work, and will revert us to the stone-age. Let the IETF improve what they can and at the same time meet politicians half way.=20 Best, Martin --=-xntkbTz+gwAJ0Uez//W5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAABAgAGBQJSnv7YAAoJEKgraNdZrwxMSeMP/1djM9rUikQd3jyyuvoZnBio 8D5IO1wfCIb+ZUI4Ttu8cFgrDkZxQBkLrHGP+ouO61v4vpJAkJiDBldafSn6SMZn Ku80/fewbFq34G+mIYPchmkngisHAuwmirmGdyUxEGfycGvsJ9q6hNn6b+MkaqGz QlBhLeZ7+EjPWXdkZBgbFMsZpVh7cv95v519LvtWfIGq9wpKS97GFfbLMx9nvgu9 mtdb00znqYR8FSp0ROV1bdpL2tKP2LxKz/wlZ8+z7KYzP8LwWNf6j9gotaTsSGTN ZgKM7GABsTREdnaDVZt4nVgUj95siWEKTUB4gcRZhosfhRnKGvqN9uchOh9FszRA r154lhL23adG5EyH89OaE9CO/DukrfW82cyuQIihWwIoxnN6kFOIs1b5K8A+hx9M m+vziaNbTT6s1w7OCqETDanw8qOluszPSj+ka5JXXUikyw5zcQzIv7iEPFNTAokS Yf0ci8w0ALz/LelHqq+D0R6PeC34/hwNNYsYDwaoHTVz+OezsTFuKtpC0h7QAFs6 mvQM+Heji+wPOehbmWRnP0OS6v+0/HYLNQXdo16YHtPV47l78Zz1IEU1hsPwH8Fa BL0cKcmURgU/HnYC+oQ1G2fTtyrSkolg6JbbMmTQGTY0G4Th78dhr+UA1j/Bh4NJ P0CUQmFk7+iNHURDKebK =0N4l -----END PGP SIGNATURE----- --=-xntkbTz+gwAJ0Uez//W5-- From bortzmeyer@nic.fr Wed Dec 4 03:13:50 2013 Return-Path: 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 ; 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 ; 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 ; 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 To: Bruce Perens Message-ID: <20131204111309.GB11727@nic.fr> References: <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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 if you want a good laugh.) From hannes.tschofenig@gmx.net Wed Dec 4 03:50:44 2013 Return-Path: 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 E50C11AE249 for ; Wed, 4 Dec 2013 03:50:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.851 X-Spam-Level: X-Spam-Status: No, score=-0.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_12_24=1.049, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 bY2499NxlKUh for ; Wed, 4 Dec 2013 03:50:42 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id 926081AE210 for ; Wed, 4 Dec 2013 03:50:42 -0800 (PST) Received: from [192.168.10.128] ([62.49.66.12]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0LuwiT-1VfLGn3ABd-0106Ao for ; Wed, 04 Dec 2013 12:50:38 +0100 Message-ID: <529E5653.5000005@gmx.net> Date: Tue, 03 Dec 2013 22:08:19 +0000 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Stephane Bortzmeyer , Bruce Perens References: <529E8494.7000806@perens.com> <20131204111309.GB11727@nic.fr> In-Reply-To: <20131204111309.GB11727@nic.fr> Content-Type: multipart/alternative; boundary="------------090404070909030905060202" X-Provags-ID: V03:K0:w97Ka8hOWr9xf1M27zYwVDLbYpLATFX4YPJ9BME4O0IrIvsqGo0 k/L9oxj0OYEytlpvaVJCkQHTmN/dY2KiM00Rgy/CFaVBQpFUNgt2DlxsgL6wfKbqi5U2uED WXT0pbftfroA+pSM93/kGub3Gt4VD19bCvrgdFExjRPizOmEzdBPl7oumlkxlU7Jqzi7yZF vT8PzytTguxL0+3PEgZuw== 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 11:50:45 -0000 This is a multi-part message in MIME format. --------------090404070909030905060202 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 12/04/2013 11:13 AM, Stephane Bortzmeyer wrote: > problem is *political* and should > receive a *political* response I am not sure what "political" means. The attacks we have seen are exploiting vulnerabilities others had exploited before. Fixing security vulnerabilities in protocol specifications, in implementations, and in deployments is something we have done before. Do you guys expect that someone (pick your favourite person) would say "This is not good. You must not exploit security vulnerabilities in the future anymore." Then, the Internet would be more secure. I fail to see the story. Ciao Hannes PS: To me it sounds like pushing responsibilities around without a clear idea what that could mean. --------------090404070909030905060202 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 12/04/2013 11:13 AM, Stephane Bortzmeyer wrote:
problem is *political* and should
receive a *political* response

I am not sure what "political" means.

The attacks we have seen are exploiting vulnerabilities others had exploited before. Fixing security vulnerabilities in protocol specifications, in implementations, and in deployments is something we have done before.

Do you guys expect that someone (pick your favourite person) would say "This is not good. You must not exploit security vulnerabilities in the future anymore." Then, the Internet would be more secure.

I fail to see the story.

Ciao
Hannes

PS: To me it sounds like pushing responsibilities around without a clear idea what that could mean.

--------------090404070909030905060202-- From ynir@checkpoint.com Wed Dec 4 04:08:16 2013 Return-Path: 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 ; 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 ; 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 ; 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 To: Stephane Bortzmeyer 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: <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: "" , Bruce Perens 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 12:08:16 -0000 On Dec 4, 2013, at 1:13 PM, Stephane Bortzmeyer wrote: > [List of recipients trimmed to be more reasonable.] >=20 > On Tue, Dec 03, 2013 at 05:25:40PM -0800, > Bruce Perens wrote=20 > a message of 37 lines which said: >=20 >> 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 >=20 > 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 requiremen= ts from protocols stem from the desired political response. Engineers don't= get to make up the requirements. =20 > 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.=20 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 wil= l 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 attachme= nt. So as far as Internet crime is concerned, we're living in the movie ver= sion 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.=20 >=20 > IANAL but this does not seem to me to be true. In my country, > collecting illegal personal data is a criminal offense. >=20 >> 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. >=20 > 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 pro= cess before they can force you to decrypt traffic for them, usually an orde= r signed by a court of law. At least that is the way it should be in free c= ountries (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. >=20 > 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 cont= ent. 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 nob= ody'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 i= n 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 seve= ral 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, w= hich is information they have not made public. If we protect the confidenti= ality 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. >=20 > 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 ca= se, you'll get around 10x or 20x the bandwidth with the non-encrypted traff= ic. 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 t= he data from a file or database. >=20 >> It's almost universally held within the working groups that users >> can't be responsible for their own security, >=20 > 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) >=20 > (Go to if you want a good laugh.) Gah. I expected this to be a www.ietf.org certificate vs a ietf.org URL, bu= t this is far worse. Yoav From sm@elandsys.com Wed Dec 4 06:28:17 2013 Return-Path: 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 894191AE274 for ; Wed, 4 Dec 2013 06:28:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.791 X-Spam-Level: X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.001, T_DKIM_INVALID=0.01] 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 VKuDvEg8WdMC for ; Wed, 4 Dec 2013 06:28:16 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CE821AE272 for ; Wed, 4 Dec 2013 06:28:16 -0800 (PST) Received: from SUBMAN.elandsys.com ([197.224.137.184]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id rB4ERvgR011809 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Dec 2013 06:28:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1386167291; bh=Wvr5ErEr8LWa2kFV+CaNku4WIlXG0pgkgKjeBA1YFhY=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=tbvAQaHDn/OLBIpQbXiFtOiY/E7xkY/zk6inrQ7W1p0NGxOtrXWgGTGsEXtWIlkEi VSwBAjgl9zYMoRu//+0CrH+KqDGG1bqO1SCSWX4AEnlN5Kw+H4WT97OZMBhbfWGtmf 7ZGYcreptNbwLaID7xjiMaMXQPlu33C30BP42FHs= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1386167291; i=@elandsys.com; bh=Wvr5ErEr8LWa2kFV+CaNku4WIlXG0pgkgKjeBA1YFhY=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=x3DGl39puQbFiUkzdXPWsNm/6Oo8xQr8UgP7HlON3oa9iQ5aOYLIaWMP01/83G46v zbnF7ogkQoUfTxrh9eyJvqsMwaxbNwRIhtlSgtSdrRCP+V6PybCsnTiDLNr5fI58kD IF7hSEdMNW5Fl00ZCpLx74lR47fdHXc5kCmW1ISo= Message-Id: <6.2.5.6.2.20131204040355.0c2fae10@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 04 Dec 2013 06:08:48 -0800 To: Martin Millnert , Bruce Perens , Stephane Bortzmeyer From: S Moonesamy In-Reply-To: <1386151640.22570.70.camel@galileo.millnert.se> References: <529E8494.7000806@perens.com> <1386151640.22570.70.camel@galileo.millnert.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 14:28:17 -0000 Hi Martin, Bruce, Stephane, At 02:07 04-12-2013, Martin Millnert wrote: >For the other, mostly technical, arguments put forth by you: > > p3. A sovereign entity may outlaw technical protocol X: > It wouldn't be a sovereign entity if it couldn't. It could outlaw Pi >= 3.1459... for all I care. Point is we should not let a single >Sovereign Entity outlaw the correct definition of Pi, for the rest of >us. It is precisely within IETF's jurisdiction to define our global >common Internet communication protocols. If a single backwards >Sovereign Entity held veto power over this we would be much poorer >today. Instead the backwards sovereign entities will have to live >without these protocols, which is what they in their sovereignty decided >anyway, so everybody would be happy... Someone mentioned in a non-IETF discussion that there was a precedent about a technical question which might fit the above (3.146) argument. It was recently mentioned in a news article that there is a public misconception about the Internet. In my opinion it would be politically inappropriate for the IETF to state that some country would have to live without a protocol. On page 1 of the document, it is mentioned that it is a: "deliberate attempt to defeat the correct technical operation of the Internet. In this case, the feature of communications privacy" I would use "confidentiality" instead of "communications privacy" [1]. I agree that, as it is argued in the document, "attack" has a different meaning. It is difficult to ignore the context. I posted a draft (see http://tools.ietf.org/html/draft-moonesamy-traffic-peeking-00 ). I'll be candid; the objective of a spying organization is to spy. An in-depth discussion of that will alienate some IETF participants. Not saying anything about [I don't know what word to choose] is an alternative. Another alternative is to look at how the political problem affects the technical one. The document argues that there is "no technical solution to this conundrum". I agree to that. An interesting point (in the document) is that "universal encryption of HTTP connections proposed on the working group mailing lists would hinder the technical operation of the internet". I'd say yes. In my opinion there are reasons why a person would consider having encrypted access to "static content". For example, the "in the clear" access might disclose information which the user might be uncomfortable about. One alternative is to provide the user and the other parties involved in the communication session with choices. As Martin Millnert pointed out, providing those choices is not straight-forward. I'll adapt a comment from Stephane Bortzmeyer: Is it okay to ask Mr Smith to decide based on the information [being provided]? Or to put it differently, should a technical specification provide some guidance about that. Regards, S. Moonesamy 1. Credits to the Stephen Farrell and I'll take the blame if it is incorrect. :-) From bruce@perens.com Wed Dec 4 09:09:50 2013 Return-Path: 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 307401AE2EA for ; Wed, 4 Dec 2013 09:09:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.722 X-Spam-Level: X-Spam-Status: No, score=0.722 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, 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 6YUbOaiQoUgw for ; Wed, 4 Dec 2013 09:09:49 -0800 (PST) Received: from alchemy.perens.com (alchemy.perens.com [206.221.219.26]) by ietfa.amsl.com (Postfix) with ESMTP id 5FB561AE2E7 for ; Wed, 4 Dec 2013 09:09:49 -0800 (PST) Received: from [192.168.18.131] (mail.a10networks.com [12.207.16.167]) by alchemy.perens.com (Postfix) with ESMTPSA id 24A2350008A; Wed, 4 Dec 2013 09:09:45 -0800 (PST) Message-ID: <529F61D8.6030105@perens.com> Date: Wed, 04 Dec 2013 09:09:44 -0800 From: Bruce Perens User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131103 Icedove/17.0.10 MIME-Version: 1.0 To: Stephane Bortzmeyer References: <529E8494.7000806@perens.com> <20131204111309.GB11727@nic.fr> In-Reply-To: <20131204111309.GB11727@nic.fr> Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 17:09:50 -0000
On 12/04/2013 03:13 AM, Stephane Bortzmeyer wrote:
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.
France and the US are partners in NATO, and there are conflicting reports regarding France's participation in something called ECHELON.

The potential is that you could be giving aid and comfort to "the enemy" by constructing a technical hinderance to intelligence gathering by your own national intelligence agency or by your country's intelligence partners. It looks from here that this falls under the later paragraphs of France's penal code definition of treason.

IMO this is reason to be careful.
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.
I'm sure it isn't. The point is just about unnecessary waste.

    Thanks

    Bruce

From tytso@thunk.org Wed Dec 4 09:12:23 2013 Return-Path: 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 9DF041AE2ED for ; Wed, 4 Dec 2013 09:12:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.792 X-Spam-Level: X-Spam-Status: No, score=-1.792 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] 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 Yb5q3RLKg15L for ; Wed, 4 Dec 2013 09:12:22 -0800 (PST) Received: from imap.thunk.org (imap.thunk.org [IPv6:2600:3c02::f03c:91ff:fe96:be03]) by ietfa.amsl.com (Postfix) with ESMTP id E458C1AE309 for ; Wed, 4 Dec 2013 09:12:12 -0800 (PST) Received: from root (helo=closure.thunk.org) by imap.thunk.org with local-esmtp (Exim 4.80) (envelope-from ) id 1VoFzc-0003QL-Dt; Wed, 04 Dec 2013 17:12:08 +0000 Received: by closure.thunk.org (Postfix, from userid 15806) id ABD7758087B; Wed, 4 Dec 2013 12:12:07 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=thunk.org; s=mail; t=1386177127; bh=+s4pals79Yew0DEA1JU6luGYSq79vjMkojGLGo6G2ag=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=uZfCRsJuUImfGexGmmKjWM0uu2sQSGYu1OZr5/bTcPiucuJKdgRj9hQi7F6nNQr+g voXqx756lzCtnyAgUdxkq7CSapK9CCbwxLHvUdNuh8Rp52AMtugcRySw2DWbpndNaH Fr6sX2+W6l87ODIPISiQI0YEb7oVEU8Qwl18H7pA= Date: Wed, 4 Dec 2013 12:12:07 -0500 From: Theodore Ts'o To: Bruce Perens Message-ID: <20131204171207.GC19914@thunk.org> References: <529E8494.7000806@perens.com> <20131204111309.GB11727@nic.fr> <529F61D8.6030105@perens.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <529F61D8.6030105@perens.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: tytso@thunk.org X-SA-Exim-Scanned: No (on imap.thunk.org); SAEximRunCond expanded to false Cc: perpass@ietf.org, Stephane Bortzmeyer 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 17:12:23 -0000 On Wed, Dec 04, 2013 at 09:09:44AM -0800, Bruce Perens wrote: > The potential is that you could be giving aid and comfort to "the > enemy" by constructing a technical hinderance to intelligence > gathering by your own national intelligence agency or by your > country's intelligence partners. It looks from here that this falls > under the later paragraphs of France's penal code definition of > treason. We put door locks on homes. This makes it harder for "black bag" teams to put keyboard bugs on terrorists's homes. (Or at least people suspected of being terrorists.) Does this mean that creating building codes which require that doors have locks, or people who install locks on doors, are giving "aid and comfort" to the enemy? - Ted From bruce@perens.com Wed Dec 4 09:17:51 2013 Return-Path: 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 B53D01AE2E6 for ; Wed, 4 Dec 2013 09:17:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.577 X-Spam-Level: X-Spam-Status: No, score=-0.577 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, MIME_HTML_ONLY=0.723, 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 p5AKsiJJOS0t for ; Wed, 4 Dec 2013 09:17:51 -0800 (PST) Received: from alchemy.perens.com (alchemy.perens.com [206.221.219.26]) by ietfa.amsl.com (Postfix) with ESMTP id 131191AE193 for ; Wed, 4 Dec 2013 09:17:51 -0800 (PST) Received: from [192.168.18.131] (mail.a10networks.com [12.207.16.167]) by alchemy.perens.com (Postfix) with ESMTPSA id 3197450008A; Wed, 4 Dec 2013 09:17:48 -0800 (PST) Message-ID: <529F63C0.3040804@perens.com> Date: Wed, 04 Dec 2013 09:17:52 -0800 From: Bruce Perens User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131103 Icedove/17.0.10 MIME-Version: 1.0 To: Theodore Ts'o References: <529E8494.7000806@perens.com> <20131204111309.GB11727@nic.fr> <529F61D8.6030105@perens.com> <20131204171207.GC19914@thunk.org> In-Reply-To: <20131204171207.GC19914@thunk.org> Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: perpass@ietf.org, Stephane Bortzmeyer 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 17:17:51 -0000
On 12/04/2013 09:12 AM, Theodore Ts'o wrote:
Does this mean that creating building codes which require that doors have locks, or people who install locks on doors, are giving "aid and comfort" to the enemy?
Nobody cares what you do to your door. When your stated intention is to prevent a nation from collecting information that they use for law enforcement or national defense, they care.

    Thanks

    Bruce
From nweaver@icsi.berkeley.edu Wed Dec 4 09:19:25 2013 Return-Path: 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 872691AE307 for ; Wed, 4 Dec 2013 09:19:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_21=0.6, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 17i-2AkafYV0 for ; Wed, 4 Dec 2013 09:19:24 -0800 (PST) Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id 8F8981AE304 for ; Wed, 4 Dec 2013 09:19:24 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id C02EB2C401E; Wed, 4 Dec 2013 09:19:21 -0800 (PST) X-Virus-Scanned: amavisd-new at ICSI.Berkeley.EDU Received: from rock.ICSI.Berkeley.EDU ([127.0.0.1]) by localhost (maihub.ICSI.Berkeley.EDU [127.0.0.1]) (amavisd-new, port 10024) with LMTP id zrvoDcaIXc4y; Wed, 4 Dec 2013 09:19:21 -0800 (PST) Received: from gala.icir.org (gala.icir.org [192.150.187.130]) (Authenticated sender: nweaver) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 6311B2C4003; Wed, 4 Dec 2013 09:19:21 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_AD58F2DE-88D8-4B79-AD54-4C97D2378083"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Nicholas Weaver In-Reply-To: <529F63C0.3040804@perens.com> Date: Wed, 4 Dec 2013 09:19:20 -0800 Message-Id: <5A5B778C-1E8D-49BA-9AB9-8A5C5C9E46F0@icsi.berkeley.edu> References: <529E8494.7000806@perens.com> <20131204111309.GB11727@nic.fr> <529F61D8.6030105@perens.com> <20131204171207.GC19914@thunk.org> <529F63C0.3040804@perens.com> To: Bruce Perens X-Mailer: Apple Mail (2.1510) Cc: Theodore Ts'o , perpass@ietf.org, Nicholas Weaver , Stephane Bortzmeyer 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 17:19:25 -0000 --Apple-Mail=_AD58F2DE-88D8-4B79-AD54-4C97D2378083 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Dec 4, 2013, at 9:17 AM, Bruce Perens wrote: > On 12/04/2013 09:12 AM, Theodore Ts'o wrote: >> Does this mean that creating building codes which require that doors = have locks, or people who install locks on doors, are giving "aid and = comfort" to the enemy? > Nobody cares what you do to your door. When your stated intention is = to prevent a nation from collecting information that they use for law = enforcement or national defense, they care. The problem we need the locks on ALL the doors to preserve national = defense. All it takes is ONE unencrypted web request across a hostile network for = that hostile network to be used to attack the browser.=20 -- Nicholas Weaver it is a tale, told by an idiot, nweaver@icsi.berkeley.edu full of sound and fury, 510-666-2903 .signifying nothing PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc --Apple-Mail=_AD58F2DE-88D8-4B79-AD54-4C97D2378083 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCgAGBQJSn2QZAAoJEG2B1w+SDi/uxX8QAI/7dznUgWRcnOafRd6C3Erp tNpAZkH+3EX4885LwxmiMDnwzQreVHRk+sGNDriGlvI7yxm06KQgtnj23HgQ0S1v wzXGFD8peahi2pxbHfPBD7+nWYwxmXNHljOOrPRgaxOBBpTi7fEMh4CQlP3xtVkd ZsIjjhxaO65BlG1baLxDzbKF+hU4tOEY/8KSqxAJUJfXTLWBhZjfWQB2wKLaOMu8 6qLZqHgNInDSsosDoegoCyCrlRRjjlwGvw6benqBqRP+h3HCM/76GtIL+t6Pck2a bzgPjbVDnKF3oqVTEmKj7AQtXsNzjN/V5YsL1STRK6281uVYfLtVpECf0mEgjyUT lrq6tx9hcYclhpMAXhb3uty2QlxEfGAkoY8FlcMO+Assq6jrEpE+OIGPsfOwlpKS qEEZamGzlTzxDjjbr0gGPVuIEllBr+7vlx7JmaxNwpDzl6lv60tfSVQ3SS6u8hjO UxQfxwPIy2ry6i2Md0wiRDhY9jPncU/P9LCVPQgIDc6rxXjuv7Go80ITLLgC1iQL 8gPYYOlfnflwfSp4WYQWODIO0SUZSRLvR/J/cTHqKRdC4LouS+fMhNjXIK+A2Q1x Bhfv8bOBOw4yb8lMb/1Kfc8dVjh7fCGTtqFxhPvdujW3CjX1ljdxvgFFJVwrTeH/ TRQiSITexhkdtFgG9cLn =1tHY -----END PGP SIGNATURE----- --Apple-Mail=_AD58F2DE-88D8-4B79-AD54-4C97D2378083-- From bruce@perens.com Wed Dec 4 09:22:56 2013 Return-Path: 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 2EE831AE314 for ; Wed, 4 Dec 2013 09:22:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.177 X-Spam-Level: X-Spam-Status: No, score=-1.177 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, 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 Z_xsTR1qr1OH for ; Wed, 4 Dec 2013 09:22:55 -0800 (PST) Received: from alchemy.perens.com (alchemy.perens.com [206.221.219.26]) by ietfa.amsl.com (Postfix) with ESMTP id 87F341A802B for ; Wed, 4 Dec 2013 09:22:55 -0800 (PST) Received: from [192.168.18.131] (mail.a10networks.com [12.207.16.167]) by alchemy.perens.com (Postfix) with ESMTPSA id 8280050008A; Wed, 4 Dec 2013 09:22:52 -0800 (PST) Message-ID: <529F64F1.1090802@perens.com> Date: Wed, 04 Dec 2013 09:22:57 -0800 From: Bruce Perens User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131103 Icedove/17.0.10 MIME-Version: 1.0 To: Nicholas Weaver References: <529E8494.7000806@perens.com> <20131204111309.GB11727@nic.fr> <529F61D8.6030105@perens.com> <20131204171207.GC19914@thunk.org> <529F63C0.3040804@perens.com> <5A5B778C-1E8D-49BA-9AB9-8A5C5C9E46F0@icsi.berkeley.edu> In-Reply-To: <5A5B778C-1E8D-49BA-9AB9-8A5C5C9E46F0@icsi.berkeley.edu> Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Stephane Bortzmeyer , perpass@ietf.org, Theodore Ts'o 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 17:22:56 -0000
On 12/04/2013 09:19 AM, Nicholas Weaver wrote:
All it takes is ONE unencrypted web request across a hostile network for that hostile network to be used to attack the browser.
And that is one way in to the browser out of many.

    Thanks

    Bruce
From nweaver@icsi.berkeley.edu Wed Dec 4 09:24:02 2013 Return-Path: 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 B689B1AE316 for ; Wed, 4 Dec 2013 09:24:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 VSzSO5F2uAIz for ; Wed, 4 Dec 2013 09:24:01 -0800 (PST) Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id 8F60B1AE317 for ; Wed, 4 Dec 2013 09:24:00 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id D60FF2C401E; Wed, 4 Dec 2013 09:23:57 -0800 (PST) X-Virus-Scanned: amavisd-new at ICSI.Berkeley.EDU Received: from rock.ICSI.Berkeley.EDU ([127.0.0.1]) by localhost (maihub.ICSI.Berkeley.EDU [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 6UCaTHdZHS6c; Wed, 4 Dec 2013 09:23:57 -0800 (PST) Received: from gala.icir.org (gala.icir.org [192.150.187.130]) (Authenticated sender: nweaver) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 71A292C4003; Wed, 4 Dec 2013 09:23:57 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_737E5515-DB7C-4EF4-9042-4FD276D577DD"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Nicholas Weaver In-Reply-To: <529F64F1.1090802@perens.com> Date: Wed, 4 Dec 2013 09:23:57 -0800 Message-Id: <7A38D549-EFBB-4D59-BDD2-07EEB0E4EFAF@icsi.berkeley.edu> References: <529E8494.7000806@perens.com> <20131204111309.GB11727@nic.fr> <529F61D8.6030105@perens.com> <20131204171207.GC19914@thunk.org> <529F63C0.3040804@perens.com> <5A5B778C-1E8D-49BA-9AB9-8A5C5C9E46F0@icsi.berkeley.edu> <529F64F1.1090802@perens.com> To: Bruce Perens X-Mailer: Apple Mail (2.1510) Cc: Stephane Bortzmeyer , perpass@ietf.org, Nicholas Weaver , Theodore Ts'o 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 17:24:02 -0000 --Apple-Mail=_737E5515-DB7C-4EF4-9042-4FD276D577DD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Dec 4, 2013, at 9:22 AM, Bruce Perens wrote: > On 12/04/2013 09:19 AM, Nicholas Weaver wrote: >> All it takes is ONE unencrypted web request across a hostile network = for that hostile network to be used to attack the browser. > And that is one way in to the browser out of many. Except that it is a primary way that the NSA says is OK, and has a huge = attraction to nation states for system exploitation. Why bother with = watering hole attacks etc? -- Nicholas Weaver it is a tale, told by an idiot, nweaver@icsi.berkeley.edu full of sound and fury, 510-666-2903 .signifying nothing PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc --Apple-Mail=_737E5515-DB7C-4EF4-9042-4FD276D577DD Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCgAGBQJSn2UtAAoJEG2B1w+SDi/uga8QAJc53m0QM8Pz8fJH3PvdeJXA 2vVr+84fBfigd4QcQ1DvDYoLAOJFOwtdXJvt9VXvOXfIENu8BRAdMFP3+v/3mWWV TF/mskNjzoH1KUQpLKjPPi22awWk+yLknyrKpJuCjQTUe3fCZDABPJdOypXwT/24 syTqZwI4PWkxpXctSHTME2iyjAOteHFxazVTlxeqp01hfj4oMpRfSbEXIcsxrNM6 PAyczqw1kSvsuaazORbdSYRZBIvCPlwdJIpUVx0VZXlu+TBj668MMX9smeD6GFL7 ZGzT9E1awVZBm8C2o0rB6kruCCXr150uP2TRhyL32upYC31jVKQayFfbSlt/iksY CpLYPlF2INj/WhMWwevmz8dt/NCsqPkA6jhExpup7V/EsZDprmMqufJpHRQDV59S 1dqUZaqJk/JkVUjTLnteolxM5XerYUxLhAK1NcsOyNKUvnK9Fohq9EoaHoQrEovu AWoaakjUqpNO/UeQMcWj0febHDp99gPapwhlvFBaaAUKoQk7R0207JSWSRlOWUSO kSbHZDtEsTglhXXe+QRm4GMCY74ldZ8H+zn6OXNB2Bu1ZXAZiN+1Cn/6b2f4wjBx gbuFYPWFLemAZsSFjpX6Cw81a5CLxgTrrTuZY7pKFoTr4uM78Ocaj1Z7gqCyK+lA E4pdfFBXqhAzfnnHyEUR =3Get -----END PGP SIGNATURE----- --Apple-Mail=_737E5515-DB7C-4EF4-9042-4FD276D577DD-- From brian.e.carpenter@gmail.com Wed Dec 4 10:58:10 2013 Return-Path: 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 13C8F1AD943 for ; Wed, 4 Dec 2013 10:58:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 gea1_DI4Us-0 for ; Wed, 4 Dec 2013 10:58:07 -0800 (PST) Received: from mail-pb0-x22f.google.com (mail-pb0-x22f.google.com [IPv6:2607:f8b0:400e:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id C76EE1AD8F4 for ; Wed, 4 Dec 2013 10:58:07 -0800 (PST) Received: by mail-pb0-f47.google.com with SMTP id um1so24119225pbc.34 for ; Wed, 04 Dec 2013 10:58:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=VIalVY7MESRkdwFXQzmVB3sYKx+u4riaonQXxQ2nl7Q=; b=ljBOXFMpJx9G2MHhuGMGM/HY2Y9cBLMSpLHiVrjNE40br1AqRlJTRL7i+MtG9oOZoU mfuO0aT295Y8tS7xAFbrzS6VpY4IRLMjHI/yLcIdWFoUhRttQ4UUW4/FQgB7y+Zrmkn+ c/pU2wpwxI4o9dB0Jc4d5Q81bvlDmDtQkpIJ9Q/EspiQPN1jN2i9Dzvbi6BceHgvtQtU uXuU2Dp1uzwFIqIv3kvCwpKCY0B1cWJ1wRqImLPDYMI44sYUPb9brTLesl8bKh/yGobx sZuZRSB2NNCL+1f338tXemHf8R7DTzZUSp+AidRAuzTEXSfswpIg/OrwtoZhH+h7XolN 4WeA== X-Received: by 10.66.218.226 with SMTP id pj2mr83346737pac.62.1386183483750; Wed, 04 Dec 2013 10:58:03 -0800 (PST) Received: from [192.168.178.20] (41.199.69.111.dynamic.snap.net.nz. [111.69.199.41]) by mx.google.com with ESMTPSA id nn6sm87748647pbc.29.2013.12.04.10.58.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Dec 2013 10:58:03 -0800 (PST) Message-ID: <529F7B3B.5020901@gmail.com> Date: Thu, 05 Dec 2013 07:58:03 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Stephane Bortzmeyer References: <529E8494.7000806@perens.com> <20131204111309.GB11727@nic.fr> In-Reply-To: <20131204111309.GB11727@nic.fr> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: perpass@ietf.org, Bruce Perens 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 18:58:10 -0000 I've just read draft-farrell-perpass-attack-02 again. It carefully doesn't discuss political, legal or societal issues. It discusses monitoring and surveillance as a security threat model and states that the IETF will specify technical counter-measures to this threat model. That is well within the IETF's remit. Whether implementors and operators choose to implement the resulting counter- measures is a separate question that does have political, legal or societal aspects. I think that Bruce's concerns apply to deployment, not to the IETF's work. Regards Brian On 05/12/2013 00:13, Stephane Bortzmeyer wrote: > [List of recipients trimmed to be more reasonable.] > > On Tue, Dec 03, 2013 at 05:25:40PM -0800, > Bruce Perens 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 if you want a good laugh.) > > > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > From jacob@appelbaum.net Wed Dec 4 12:06:30 2013 Return-Path: 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 E07CB1AE24E for ; Wed, 4 Dec 2013 12:06:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FSL_HELO_BARE_IP_2=2, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-0.7] 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 OB2PsAzeGyr0 for ; Wed, 4 Dec 2013 12:06:28 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 520AE1AD6A4 for ; Wed, 4 Dec 2013 12:06:28 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id w62so10065927wes.3 for ; Wed, 04 Dec 2013 12:06:24 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:mime-version:to:cc:subject :references:in-reply-to:openpgp:content-type :content-transfer-encoding; bh=TgbIwtiEwzM+hYkeR1GjsjYi0UY9aOpvkKUzVh6ljtI=; b=j1kJArJU8W/x5yrqY8wbC5GtzUbYpvpuM62QXOgV8V7kbFrVWzMxCmigI+DqD0ZOUS /TrNH6Uxm6WhocSuR8+8SSDnn/jDkIciYvPkZIC0yu4VVNmfy4X1vYZkAzSmoK0FCQ8F uUjTQez0/zuz5C9tsIWjqt0rJ70G+d9wRo4CqRu3/kie+Bl56LhHaFQ9qWzvwezS379j i+mrFhhnUl+3Eh0g+tCPjnZJ0mZ3Gl7mYohsWiF5bxvEzLTQo6taPUg6Dh7tykkAQREB J9ZlWTyag8PAxZfOUNVR+P5r4IphFSdF4iregJ70t3unZgIx9FXuf9AmeS09o9OgI3iq o6+g== X-Gm-Message-State: ALoCoQk2Ra9Yi1n50AApmS74ZtC5K83gRa9E8EBCaT8bAfUUErlwmubt6xu42xRh4XDjU7/RT3o2 X-Received: by 10.194.89.233 with SMTP id br9mr64589891wjb.15.1386187584709; Wed, 04 Dec 2013 12:06:24 -0800 (PST) Received: from 127.0.0.1 ([77.109.139.87]) by mx.google.com with ESMTPSA id b7sm10017281wiz.8.2013.12.04.12.06.14 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Dec 2013 12:06:23 -0800 (PST) Message-ID: <529F88AC.3090904@appelbaum.net> Date: Wed, 04 Dec 2013 19:55:24 +0000 From: Jacob Appelbaum MIME-Version: 1.0 To: Bruce Perens References: <529E8494.7000806@perens.com> <20131204111309.GB11727@nic.fr> <529F61D8.6030105@perens.com> <20131204171207.GC19914@thunk.org> <529F63C0.3040804@perens.com> In-Reply-To: <529F63C0.3040804@perens.com> OpenPGP: id=4193A197 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: Stephane Bortzmeyer , perpass@ietf.org, Theodore Ts'o 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 20:06:30 -0000 Bruce Perens: > On 12/04/2013 09:12 AM, Theodore Ts'o wrote: >> Does this mean that creating building codes which require that doors have >> locks, or people who install locks on doors, are giving "aid and comfort" to >> the enemy? > Nobody cares what you do to your door. When your stated intention is to prevent > a nation from collecting information that they use for law enforcement or > national defense, they care. Dear Bruce, Why do you dignify these actions as 'law enforcement' or even as 'national defense' when we're discussing illegal spying? Rosa Luxemburg said something terribly relevant and it bares repeating after I've read your response: “Those who do not move, do not notice their chains.” The early internet protocols have major security issues and it is time to fix them. Pervasive surveillance, censorship and malware is a serious threat regardless of your feelings about the NSA. The vulnerabilities need to be fixed and pervasive strong end-user-controlled encryption is part of the solution. All the best, Jacob From bruce@perens.com Wed Dec 4 12:14:24 2013 Return-Path: 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 838AB1ADFBB for ; Wed, 4 Dec 2013 12:14:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.177 X-Spam-Level: X-Spam-Status: No, score=-1.177 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, 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 HHQ23ckSIbta for ; Wed, 4 Dec 2013 12:14:23 -0800 (PST) Received: from alchemy.perens.com (alchemy.perens.com [206.221.219.26]) by ietfa.amsl.com (Postfix) with ESMTP id BEC881AD957 for ; Wed, 4 Dec 2013 12:14:23 -0800 (PST) Received: from [192.168.18.131] (mail.a10networks.com [12.207.16.167]) by alchemy.perens.com (Postfix) with ESMTPSA id 01D3450008A for ; Wed, 4 Dec 2013 12:14:19 -0800 (PST) Message-ID: <529F8D1F.8090402@perens.com> Date: Wed, 04 Dec 2013 12:14:23 -0800 From: Bruce Perens User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131103 Icedove/17.0.10 MIME-Version: 1.0 To: perpass@ietf.org References: <529E8494.7000806@perens.com> <20131204111309.GB11727@nic.fr> In-Reply-To: <20131204111309.GB11727@nic.fr> Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 20:14:24 -0000
On 12/04/2013 03:13 AM, Stephane Bortzmeyer wrote:
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.
In my early teens I figured out how to tap telephones and actually tapped a neighbor and my friend's cop neighbor. The conclusion of my experimentation was that other people's phone calls are dreadfully boring.

I don't particularly care if someone can reconstruct a pattern of access from public file retrievals I make on the web. I can't imagine why anyone would ever be interested.

I have NDAs with various companies and confidentiality orders from a few courts, and I'm an insider stockholder for two companies. I'm careful with that data. But casual stuff on the web? Nothing to hide there.

    Thanks

    Bruce
From martin.thomson@gmail.com Wed Dec 4 12:17:53 2013 Return-Path: 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 5DABA1A1F79 for ; Wed, 4 Dec 2013 12:17:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 LMyIfTySHaGc for ; Wed, 4 Dec 2013 12:17:52 -0800 (PST) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) by ietfa.amsl.com (Postfix) with ESMTP id ACE7E1AD8EC for ; Wed, 4 Dec 2013 12:17:51 -0800 (PST) Received: by mail-wi0-f181.google.com with SMTP id hq4so8792746wib.8 for ; Wed, 04 Dec 2013 12:17:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HvglsfzV84Xj+1OgncfNpYcMQTDnU5Gp8o/QIqSvy38=; b=t29r67NMmSBSeoqbCVGTkwZ5y1lMBuvTd/dsGH1jv6KICiPsnQ2VWqo/CQgIyFNOcs T10p15AZxlLI9VYVSs5h3XdQIh1YrUdRt/N2T3xkaaSeLjIxHCy0XxvFMh3T1N6DATWs tqh6GpPTNvBQmsMPx0JnbTj7GEIEUVjIsjuZCbKUfQNHHhWgS99y4UJHBYu9iLjIHuwW ucjh8x9sXfPFTUJpkPhsEwE/lkaZ1dzXJfWinGwxs/no4kdF88QhHbUFi5CQ+U+c47XE wiYyWyNRkTSMXZCznSSYjwW8ytfKoC9umluMOtjDbRLnr999NXU1sdJ33Q0Qq87zRJi/ fOIA== MIME-Version: 1.0 X-Received: by 10.180.36.105 with SMTP id p9mr8768500wij.58.1386188268112; Wed, 04 Dec 2013 12:17:48 -0800 (PST) Received: by 10.227.134.195 with HTTP; Wed, 4 Dec 2013 12:17:48 -0800 (PST) In-Reply-To: <529F8D1F.8090402@perens.com> References: <529E8494.7000806@perens.com> <20131204111309.GB11727@nic.fr> <529F8D1F.8090402@perens.com> Date: Wed, 4 Dec 2013 12:17:48 -0800 Message-ID: From: Martin Thomson To: Bruce Perens Content-Type: text/plain; charset=UTF-8 Cc: perpass 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 20:17:53 -0000 On 4 December 2013 12:14, Bruce Perens wrote: > I don't particularly care if someone can reconstruct a pattern of access > from public file retrievals I make on the web. I can't imagine why anyone > would ever be interested. I can. You aren't thinking big enough. From bruce@perens.com Wed Dec 4 12:29:22 2013 Return-Path: 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 E612E1ADFBB for ; Wed, 4 Dec 2013 12:29:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.722 X-Spam-Level: X-Spam-Status: No, score=0.722 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, 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 Vixaxx_x5VyJ for ; Wed, 4 Dec 2013 12:29:20 -0800 (PST) Received: from alchemy.perens.com (alchemy.perens.com [206.221.219.26]) by ietfa.amsl.com (Postfix) with ESMTP id 17D361ADF46 for ; Wed, 4 Dec 2013 12:29:19 -0800 (PST) Received: from [192.168.18.131] (mail.a10networks.com [12.207.16.167]) by alchemy.perens.com (Postfix) with ESMTPSA id C2DFA50008A; Wed, 4 Dec 2013 12:29:16 -0800 (PST) Message-ID: <529F90A0.8000706@perens.com> Date: Wed, 04 Dec 2013 12:29:20 -0800 From: Bruce Perens User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131103 Icedove/17.0.10 MIME-Version: 1.0 To: Jacob Appelbaum References: <529E8494.7000806@perens.com> <20131204111309.GB11727@nic.fr> <529F61D8.6030105@perens.com> <20131204171207.GC19914@thunk.org> <529F63C0.3040804@perens.com> <529F88AC.3090904@appelbaum.net> In-Reply-To: <529F88AC.3090904@appelbaum.net> Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: Stephane Bortzmeyer , perpass@ietf.org, Theodore Ts'o 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 20:29:23 -0000
On 12/04/2013 11:55 AM, Jacob Appelbaum wrote:
Dear Bruce,

Why do you dignify these actions as 'law enforcement' or even as
'national defense' when we're discussing illegal spying?
Because some of them are in my interest. And yours.

We have a nasty part of government that thinks it is in an an endless war. Every liberal nation, historically, discontinues its nice rights and protections during wartime.

But I don't kid myself that nothing that they are doing is done to protect me and others like me from a zillion nut-cases who conspire to do people harm and sometimes actually carry it out. I have met some of those nut-cases.

Every society chooses its balance between freedom and enforcement. Ours isn't the right balance today, agreed. But the proposals I see here are the hacker approach - we're not patient to deal with this as a political problem, so we'll change everyone's web browser.
Pervasive surveillance, censorship and malware is a serious threat regardless of your feelings about the NSA.
And will continue to be so after all web transactions are encrypted. You're not going to actually solve any problems.

    Thanks

    Bruce
From bruce@perens.com Wed Dec 4 12:34:16 2013 Return-Path: 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 258A81AE12A for ; Wed, 4 Dec 2013 12:34:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.177 X-Spam-Level: X-Spam-Status: No, score=-1.177 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, 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 QbyrJiVqMsvX for ; Wed, 4 Dec 2013 12:34:15 -0800 (PST) Received: from alchemy.perens.com (alchemy.perens.com [206.221.219.26]) by ietfa.amsl.com (Postfix) with ESMTP id 969511AD945 for ; Wed, 4 Dec 2013 12:34:15 -0800 (PST) Received: from [192.168.18.131] (mail.a10networks.com [12.207.16.167]) by alchemy.perens.com (Postfix) with ESMTPSA id AE78450008A; Wed, 4 Dec 2013 12:34:12 -0800 (PST) Message-ID: <529F91C9.6060906@perens.com> Date: Wed, 04 Dec 2013 12:34:17 -0800 From: Bruce Perens User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131103 Icedove/17.0.10 MIME-Version: 1.0 To: Brian E Carpenter References: <529E8494.7000806@perens.com> <20131204111309.GB11727@nic.fr> <529F7B3B.5020901@gmail.com> In-Reply-To: <529F7B3B.5020901@gmail.com> Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: perpass@ietf.org, Stephane Bortzmeyer 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 20:34:16 -0000
So, we're just going to give the entire web all of the instructions, and we don't actually _care_ if they implement HTTP 2.0 or not. We're not responsible if they do.

Sort of like handing someone a weapon, and then disclaiming responsibility for what happens afterward because you had no idea he'd actually use it!

Sorry, this seems to me to be specious.

    Thanks

    Bruce

On 12/04/2013 10:58 AM, Brian E Carpenter wrote:
Whether
implementors and operators choose to implement the resulting counter-
measures is a separate question that does have political, legal or
societal aspects.

I think that Bruce's concerns apply to deployment, not to the
IETF's work.

From jacob@appelbaum.net Wed Dec 4 12:39:20 2013 Return-Path: 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 3BAB71AE1AA for ; Wed, 4 Dec 2013 12:39:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.517 X-Spam-Level: * X-Spam-Status: No, score=1.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FSL_HELO_BARE_IP_2=2, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77] 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 CJgAuB05C0Nj for ; Wed, 4 Dec 2013 12:39:19 -0800 (PST) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id 0319D1AE178 for ; Wed, 4 Dec 2013 12:39:18 -0800 (PST) Received: by mail-wi0-f170.google.com with SMTP id hq4so8605329wib.5 for ; Wed, 04 Dec 2013 12:39:15 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:mime-version:to:cc:subject :references:in-reply-to:openpgp:content-type :content-transfer-encoding; bh=h60yODUWoHBoPqiY4QKpMesSQhHBGCoGe3t1tdLpbj8=; b=Kj85bvfdMZWGJPEfy8esJvDuGADl1E+VduPBogHStNihXczGD+AU3TpzyZkUFq0pWp bXKXN4+KqNJ0L940hJvTDnr6NCziAQtiwkbWVlNwN7y1lxUphvlZCxpi6M/Dp9zSAaCJ rTGoH1PZffOPbqOctSOW6TPjfs8jTc/BIFfo2RcH92JlVsuWBZ3KXct/2Ip8ndM5ACGf 2aOgTsz9BNRBRwFQWBMyq1WHsOeprkxDUTY+eO5UZegt3IMwqGgr882Nrzr1rxfZw5o8 LH87IOsGhLoMTamAT6tDsNRlhOHgTrUC4BjgtOJCk7nd9MPpttO68Qx47uDtxzeemFXv aQEw== X-Gm-Message-State: ALoCoQlUQQMm/mllhH6gDGtYeypFEpww5FR1EsVfiuzg4xWzO95HdQMgBZqqYbIEwrtSNzDRyePp X-Received: by 10.194.110.138 with SMTP id ia10mr66100415wjb.3.1386189555311; Wed, 04 Dec 2013 12:39:15 -0800 (PST) Received: from 127.0.0.1 ([185.25.253.24]) by mx.google.com with ESMTPSA id w20sm10259702wia.5.2013.12.04.12.39.12 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Dec 2013 12:39:14 -0800 (PST) Message-ID: <529F90AC.9000102@appelbaum.net> Date: Wed, 04 Dec 2013 20:29:32 +0000 From: Jacob Appelbaum MIME-Version: 1.0 To: Bruce Perens References: <529E8494.7000806@perens.com> <20131204111309.GB11727@nic.fr> <529F8D1F.8090402@perens.com> In-Reply-To: <529F8D1F.8090402@perens.com> OpenPGP: id=4193A197 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 20:39:20 -0000 Bruce Perens: > On 12/04/2013 03:13 AM, Stephane Bortzmeyer wrote: >> 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. > In my early teens I figured out how to tap telephones and actually tapped a > neighbor and my friend's cop neighbor. The conclusion of my experimentation was > that other people's phone calls are dreadfully boring. Imagine if this was admissible in court and that someone else was telling this story about you? How would that have impacted your life? How could it impact your life in the future? > > I don't particularly care if someone can reconstruct a pattern of access from > public file retrievals I make on the web. I can't imagine why anyone would ever > be interested. > That seems like quite a privilege, doesn't it? Not everyone is so lucky as you - will you stand by their side or dismiss them simply because it doesn't apply to you, in your view? > I have NDAs with various companies and confidentiality orders from a few courts, > and I'm an insider stockholder for two companies. I'm careful with that data. > But casual stuff on the web? Nothing to hide there. Do you use the same computer for browsing the web as you do for your email? If so, I guess anyone who does would have some negligence to hide, no? Sincerely, Jacob From jacob@appelbaum.net Wed Dec 4 12:39:31 2013 Return-Path: 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 599611AE178 for ; Wed, 4 Dec 2013 12:39:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.517 X-Spam-Level: * X-Spam-Status: No, score=1.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FSL_HELO_BARE_IP_2=2, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77] 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 R8MJKBdtippw for ; Wed, 4 Dec 2013 12:39:30 -0800 (PST) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by ietfa.amsl.com (Postfix) with ESMTP id 0FC791AE24E for ; Wed, 4 Dec 2013 12:39:29 -0800 (PST) Received: by mail-wi0-f182.google.com with SMTP id en1so8806603wid.15 for ; Wed, 04 Dec 2013 12:39:26 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:mime-version:to:cc:subject :references:in-reply-to:openpgp:content-type :content-transfer-encoding; bh=UxJnaaeZsLHmaOrMC5aMpjQEj/xgQsDAWAAtmM4JGuY=; b=VyJ+TOAnd5nxs2/oebCB7inh/UWmBMWlZYKnmBP3Go3nafusBqxu/4jTMRzlrWpEyE S81Y5bhC234kzXZnVIqhcAr9fm/dLvT9NM6qDtkCgrweoP4btVuZvkyWEHpK/0FaD9tU 81exjQ2F+r+yww4qZPRh0fW/Hu6FLcTwR9GALWs971LPLJFtgcbz7BBXyRlpKGrBst3K UWk1spL+4pHd3zLEjxBCzvke4mnC9vMZGDVvwiniAm3pbSxKCnclAmoS8zqLK3hDW7gp KUyZ5uTUrixuk1BG/ibbruO2m5nl+I3GBAFOm7LkWRN4Am0+kv4hLBuvrIX2g2IlMv1W taVw== X-Gm-Message-State: ALoCoQmDljxa4wnsRk0WOo/dhRvjGZgNVtdrzIaj7QakuRNB38Pa5XLKYRyiwDmWbLE3hAeXtYQX X-Received: by 10.194.201.225 with SMTP id kd1mr48520359wjc.35.1386189566542; Wed, 04 Dec 2013 12:39:26 -0800 (PST) Received: from 127.0.0.1 ([185.25.253.24]) by mx.google.com with ESMTPSA id d2sm10209767wik.11.2013.12.04.12.39.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Dec 2013 12:39:25 -0800 (PST) Message-ID: <529F9205.30906@appelbaum.net> Date: Wed, 04 Dec 2013 20:35:17 +0000 From: Jacob Appelbaum MIME-Version: 1.0 To: Bruce Perens References: <529E8494.7000806@perens.com> <20131204111309.GB11727@nic.fr> <529F61D8.6030105@perens.com> <20131204171207.GC19914@thunk.org> <529F63C0.3040804@perens.com> <529F88AC.3090904@appelbaum.net> <529F90A0.8000706@perens.com> In-Reply-To: <529F90A0.8000706@perens.com> OpenPGP: id=4193A197 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: Stephane Bortzmeyer , perpass@ietf.org, Theodore Ts'o 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 20:39:31 -0000 Bruce Perens: > On 12/04/2013 11:55 AM, Jacob Appelbaum wrote: >> Dear Bruce, >> >> Why do you dignify these actions as 'law enforcement' or even as >> 'national defense' when we're discussing illegal spying? > Because some of them are in my interest. And yours. What about the illegal spying is in your interest? It certainly isn't in my interest - I have been targeted for years by this spying and I most certainly do not feel that it is in my interest. I'm sure the non-Americans on the list would also love to hear about it too. > > We have a nasty part of government that thinks it is in an an endless war. Every > liberal nation, historically, discontinues its nice rights and protections > during wartime. > This is an oversimplification that is not legally correct. > But I don't kid myself that nothing that they are doing is done to protect me > and others like me from a zillion nut-cases who conspire to do people harm and > sometimes actually carry it out. I have met some of those nut-cases. > ... > Every society chooses its balance between freedom and enforcement. Ours isn't > the right balance today, agreed. But the proposals I see here are the hacker > approach - we're not patient to deal with this as a political problem, so we'll > change everyone's web browser. This is the number one vector for the TAO at the NSA, fyi. Ensuring that Man-on-the-Side is impossible will improve the security of everyone. There will be other attack vectors, of course. >> Pervasive surveillance, censorship and malware is a serious threat regardless of your feelings about the NSA. > And will continue to be so after all web transactions are encrypted. You're not > going to actually solve any problems. I am actually working quite hard on solving these problems. We're having this discussion partially because of my efforts, so please speak for yourself and not for me, alright? I look forward to seeing some more positive contributions from you. You have a big brain and are a person of good character - come help us fix the serious issues on the internet, Bruce. All the best, Jacob From nweaver@icsi.berkeley.edu Wed Dec 4 12:44:03 2013 Return-Path: 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 444A51AE1AA for ; Wed, 4 Dec 2013 12:44:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Z_R0bdVgL8tN for ; Wed, 4 Dec 2013 12:44:01 -0800 (PST) Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id 6F6F11AD8F5 for ; Wed, 4 Dec 2013 12:44:01 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 952532C404B; Wed, 4 Dec 2013 12:43:58 -0800 (PST) X-Virus-Scanned: amavisd-new at ICSI.Berkeley.EDU Received: from rock.ICSI.Berkeley.EDU ([127.0.0.1]) by localhost (maihub.ICSI.Berkeley.EDU [127.0.0.1]) (amavisd-new, port 10024) with LMTP id TSDdU7lxcVnh; Wed, 4 Dec 2013 12:43:58 -0800 (PST) Received: from gala.icir.org (gala.icir.org [192.150.187.130]) (Authenticated sender: nweaver) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 1F6312C4003; Wed, 4 Dec 2013 12:43:58 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_270281A6-D8E9-43C7-B9B1-3A0D1FEE0BD5"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Nicholas Weaver In-Reply-To: <529F90A0.8000706@perens.com> Date: Wed, 4 Dec 2013 12:43:57 -0800 Message-Id: <66BF3306-7090-4E1F-8198-E3AE16FD8A5C@icsi.berkeley.edu> References: <529E8494.7000806@perens.com> <20131204111309.GB11727@nic.fr> <529F61D8.6030105@perens.com> <20131204171207.GC19914@thunk.org> <529F63C0.3040804@perens.com> <529F88AC.3090904@appelbaum.net> <529F90A0.8000706@perens.com> To: Bruce Perens X-Mailer: Apple Mail (2.1510) Cc: Stephane Bortzmeyer , perpass@ietf.org, Nicholas Weaver , Theodore Ts'o , Jacob Appelbaum 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 20:44:03 -0000 --Apple-Mail=_270281A6-D8E9-43C7-B9B1-3A0D1FEE0BD5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Dec 4, 2013, at 12:29 PM, Bruce Perens wrote: > On 12/04/2013 11:55 AM, Jacob Appelbaum wrote: >> Dear Bruce, >>=20 >> Why do you dignify these actions as 'law enforcement' or even as >> 'national defense' when we're discussing illegal spying? >>=20 > Because some of them are in my interest. And yours. >=20 > We have a nasty part of government that thinks it is in an an endless = war. Every liberal nation, historically, discontinues its nice rights = and protections during wartime. Unfortunately this nasty part of government is not just targeting the = nutcases, but practically everybody, using insanely intrusive methods = and setting series of insanely dangerous precedents. How do you think the US would react to word that, say, the French or = Chinese hacked AT&T (using packet injection, weaponizing the wiretaps), = in order to practice covert surveillance upon senators and businessmen = in the US? "Ballistic" wouldn't begin to describe the reaction. Not to = mention the obvious economic targets [1] as well. Yet now the NSA has said, "hey, its OK". So if there is a reason for = France, or China, or Russia, or Israel, or well anybody to not let their = intelligence services off the leash? =20 We know that the Chinese haven't been doing packet injection in the past = (because we've caught their intrusions in the past, and they've been = through phishing/watering hole), but they will in the future. Because = hey, why not? Universal encryption is needed, NOW, not to limit the damage of = surveillance but to reduce the huge attack surface that is now laid bare = for the world. =20 Your adversary is all countries which your traffic traverses except your = own. [1] The NSA is quite happy to say they don't give the information to US = companies, but its quite clear that a non-trivial amount of espionage is = to further US economic interests. IMO, its a waste. What good is = hacking Petrobras if you do NOT give the data to Exxon/Mobil? >> Pervasive surveillance, censorship and malware is a serious threat = regardless of your feelings about the NSA. > And will continue to be so after all web transactions are encrypted. = You're not going to actually solve any problems. Yes, because unencrypted traffic is a huge open attack vector, which is = now open-season. Enjoy... -- Nicholas Weaver it is a tale, told by an idiot, nweaver@icsi.berkeley.edu full of sound and fury, 510-666-2903 .signifying nothing PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc --Apple-Mail=_270281A6-D8E9-43C7-B9B1-3A0D1FEE0BD5 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCgAGBQJSn5QNAAoJEG2B1w+SDi/u3e8QAJIyF6w5BAaEiBnLOgCfMnRq xlY5U6TdDS64jKF5zWTET7JwG7Px5dk9exqEdIj02hhg3NCSzD+vg6qpIv5gvTyT p4E4k/+TIes1IoVhHNIEwbPVEEA/qpUnl0aBnlg9kmhcuLBxDigA4H/pB/aDJPlP TFT1f1P1fPXUb6xlVX1aGruMrFHycM1zr20/hrEgS4PCs5fzn5JskIgyphKK5SZM uhIp9ouqJE6vBq9tsnRjIzmdqx0PxLVjUxsx1ifD1VEcXK2VvuX14i2pKKSUDlgP Sdyj5Ca78eJQYjP0SwvrjWQtzz3poAaua9PbO8WS7HL+TaOnwPmAC5QXpblAmZic h07fBTjlyjXG7kWr+vYsVRKfCwbN3Pu+2V8kjGgoy8NyIqNMKVv/8L6+N58qgLAI fvwpijmIKVQXIUsDhh4+qn7HZ5YG+RjCYin2Q7jBPxiGU9YdrnkLCPiFnCXxxNzb Oj2yy7y/GqAtRnKYgaYu2A0gRo//HzFdwPBnQ4EHUVJMMGTgMR/wvdqSGFVJT/BE O4Oa2lJdP2RS+ZRPIHxM3W5JW78ow5WGdBOfVi18AvEXZe4XLDX0lru9NvN0sG9e TZB3xqPy8olBQggE3X8lAz+EYTxeOxz5OWhyTiKBEolNWbA+GnldPQ7iP4lK7aqa DtJ7MqLTjxijW3FP+9FH =6odV -----END PGP SIGNATURE----- --Apple-Mail=_270281A6-D8E9-43C7-B9B1-3A0D1FEE0BD5-- From a.kuckartz@ping.de Wed Dec 4 12:46:44 2013 Return-Path: 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 27E8F1AD8F5 for ; Wed, 4 Dec 2013 12:46:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.849 X-Spam-Level: * X-Spam-Status: No, score=1.849 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FSL_HELO_BARE_IP_2=2, HELO_EQ_DE=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 B0m-dSh9N8Ms for ; Wed, 4 Dec 2013 12:46:42 -0800 (PST) Received: from lilly.ping.de (lilly.ping.de [83.97.42.2]) by ietfa.amsl.com (Postfix) with SMTP id D2B701AE2C4 for ; Wed, 4 Dec 2013 12:46:41 -0800 (PST) Received: (qmail 1631 invoked from network); 4 Dec 2013 20:46:37 -0000 Received: (ofmipd 83.97.42.23); 4 Dec 2013 20:46:15 -0000 Received: from 85-22-117-32.ip.dokom21.de ([85.22.117.32] helo=127.0.0.1) by lucy.ping.de with esmtpa (Exim 4.72) (envelope-from ) id 1VoJLA-0003gW-9e; Wed, 04 Dec 2013 21:46:36 +0100 Date: 4 Dec 2013 21:46:35 +0100 Message-ID: <529F94AB.6080506@ping.de> From: "Andreas Kuckartz" To: "Bruce Perens" MIME-Version: 1.0 References: <529E8494.7000806@perens.com> <20131204111309.GB11727@nic.fr> <529F8D1F.8090402@perens.com> In-Reply-To: <529F8D1F.8090402@perens.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 20:46:44 -0000 Bruce Perens: > I don't particularly care if someone can reconstruct a pattern of access > from public file retrievals I make on the web. I can't imagine why > anyone would ever be interested. > > I have NDAs with various companies and confidentiality orders from a few > courts, and I'm an insider stockholder for two companies. I'm careful > with that data. But casual stuff on the web? Nothing to hide there. You sound like a troll. Anyway: Your personal life is irrelevant in this discussion. Cheers, Andreas From bruce@perens.com Wed Dec 4 12:50:04 2013 Return-Path: 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 6B5981AE2D0 for ; Wed, 4 Dec 2013 12:50:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.177 X-Spam-Level: X-Spam-Status: No, score=-1.177 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, 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 lHvy4dYbWbf1 for ; Wed, 4 Dec 2013 12:50:03 -0800 (PST) Received: from alchemy.perens.com (alchemy.perens.com [206.221.219.26]) by ietfa.amsl.com (Postfix) with ESMTP id 9512B1AD8F5 for ; Wed, 4 Dec 2013 12:50:03 -0800 (PST) Received: from [192.168.18.131] (mail.a10networks.com [12.207.16.167]) by alchemy.perens.com (Postfix) with ESMTPSA id A4DA650008A for ; Wed, 4 Dec 2013 12:50:00 -0800 (PST) Message-ID: <529F957D.1020902@perens.com> Date: Wed, 04 Dec 2013 12:50:05 -0800 From: Bruce Perens User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131103 Icedove/17.0.10 MIME-Version: 1.0 To: perpass@ietf.org References: <529E8494.7000806@perens.com> <20131204111309.GB11727@nic.fr> <529F8D1F.8090402@perens.com> <529F90AC.9000102@appelbaum.net> In-Reply-To: <529F90AC.9000102@appelbaum.net> Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 20:50:04 -0000
On 12/04/2013 12:29 PM, Jacob Appelbaum wrote:
Imagine if this was admissible in court and that someone else was telling this story about you? How would that have impacted your life? How could it impact your life in the future?
It is admissible in court. It's a public statement on a mailing list with a public archive. So I said it in public. Anyone who wants to quote my statement that I tapped phones in my early teens can now do so, in court or out of it.

I inhaled too. There it is, submit it to Slashdot or something. :-)
Not everyone is so lucky
as you - will you stand by their side or dismiss them simply because it
doesn't apply to you, in your view?
I support their right to use a web browser that requests https preferentially, if they think that will help. I would just like that to be their choice, not something that is imposed upon them.
Do you use the same computer for browsing the web as you do for your email? If so, I guess anyone who does would have some negligence to hide, no?
I sat on the jury of a negilgence case earlier this year. There are standards regarding common sense and what would reasonably be expected for someone to perform. My security practices fit such standards.

    Thanks

    Bruce
From bruce@perens.com Wed Dec 4 13:04:00 2013 Return-Path: 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 33A8F1AE323 for ; Wed, 4 Dec 2013 13:04:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.177 X-Spam-Level: X-Spam-Status: No, score=-1.177 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, 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 NcOktkGhOhRl for ; Wed, 4 Dec 2013 13:03:59 -0800 (PST) Received: from alchemy.perens.com (alchemy.perens.com [206.221.219.26]) by ietfa.amsl.com (Postfix) with ESMTP id 616DB1AE30A for ; Wed, 4 Dec 2013 13:03:59 -0800 (PST) Received: from [192.168.18.131] (mail.a10networks.com [12.207.16.167]) by alchemy.perens.com (Postfix) with ESMTPSA id 725C850008A; Wed, 4 Dec 2013 13:03:56 -0800 (PST) Message-ID: <529F98C0.9090808@perens.com> Date: Wed, 04 Dec 2013 13:04:00 -0800 From: Bruce Perens User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131103 Icedove/17.0.10 MIME-Version: 1.0 To: Jacob Appelbaum References: <529E8494.7000806@perens.com> <20131204111309.GB11727@nic.fr> <529F61D8.6030105@perens.com> <20131204171207.GC19914@thunk.org> <529F63C0.3040804@perens.com> <529F88AC.3090904@appelbaum.net> <529F90A0.8000706@perens.com> <529F9205.30906@appelbaum.net> In-Reply-To: <529F9205.30906@appelbaum.net> Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: Stephane Bortzmeyer , perpass@ietf.org, Theodore Ts'o 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 21:04:00 -0000
On 12/04/2013 12:35 PM, Jacob Appelbaum wrote:
What about the illegal spying is in your interest?
I am not 100% confident that it is illegal, although I am unhappy about FISA and a lot of other things done since 9/11. I testify for a living. I could make a good case that it is illegal, and maybe convince a court.

The part that is in my interest is that sometimes they do actually catch people who are out to hurt others.

I happen to have walked through LAX terminal 3 two days before the violence there, and I stayed in 7 World Trade Center a month before 9/11, traveling through the subway station and the main building basements that were buried. I could just as likely have intersected with the bad guys.

I am all for finding those guys before they can do harm. I am not for giving espionage and law enforcement a blank check, though. And I think there are obvious problems today that I'd like to fix through the political process.

    Thanks

    Bruce


From brian.e.carpenter@gmail.com Wed Dec 4 13:26:25 2013 Return-Path: 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 569891ADF73 for ; Wed, 4 Dec 2013 13:26:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 kMzQnpmOrT44 for ; Wed, 4 Dec 2013 13:26:23 -0800 (PST) Received: from mail-pd0-x234.google.com (mail-pd0-x234.google.com [IPv6:2607:f8b0:400e:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id 379041AD8F4 for ; Wed, 4 Dec 2013 13:26:23 -0800 (PST) Received: by mail-pd0-f180.google.com with SMTP id q10so23166969pdj.39 for ; Wed, 04 Dec 2013 13:26:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=pjsM+vHuD1DNcZIgekmsyVnrrpKCDig9eTxwShoHJDg=; b=pBUm/AqKI3N5u07K/DZ1wBm3e/gS0sdApsLdLbTjeTbn4QgsBQexvWD5K/mC99VtsH n7gr7FdW3+GaFA3Idg1FT8xeTXfRV+OUjCaP1lmyT9LCRvRbgftM7UxCJ+KOYzKM++9y ssvFnD8bhzsBjUuFODLeLt2KOn/GuOZi9rvc5JD1nMdefyXYsT+1AKz/56YxR85lzcGO bjIkXmmqKVDtTLzu1x/4qoSSC+Pmafe8ptKVB0e4FzU0t2wt7Lxn/x4/zj6ZqEJCqEkI yEQcjHk+9MK+ZDD1Jel5GS7xtAqEHmbVfPvBQNwQ5IAxitu4BvgFcZInCEPNqo18123X cLxQ== X-Received: by 10.66.250.163 with SMTP id zd3mr84148861pac.109.1386192380201; Wed, 04 Dec 2013 13:26:20 -0800 (PST) Received: from [130.216.38.108] (sc-cs-567-laptop.cs.auckland.ac.nz. [130.216.38.108]) by mx.google.com with ESMTPSA id gg10sm139597320pbc.46.2013.12.04.13.26.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Dec 2013 13:26:19 -0800 (PST) Message-ID: <529F9E01.2000306@gmail.com> Date: Thu, 05 Dec 2013 10:26:25 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Bruce Perens References: <529E8494.7000806@perens.com> <20131204111309.GB11727@nic.fr> <529F7B3B.5020901@gmail.com> <529F91C9.6060906@perens.com> In-Reply-To: <529F91C9.6060906@perens.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: perpass@ietf.org, Stephane Bortzmeyer 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 21:26:25 -0000 On 05/12/2013 09:34, Bruce Perens wrote: > So, we're just going to give the entire web all of the instructions, and we > don't actually _care_ if they implement HTTP 2.0 or not. We're not responsible > if they do. That is exactly right. All IETF standards are voluntary standards. Whether they are implemented or deployed is utterly outside the IETF's hands. > Sort of like handing someone a weapon, and then disclaiming responsibility for > what happens afterward because you had no idea he'd actually use it! Engineers have certain ethical responsibilities, indeed. You could certainly argue that the IETF has historically been too lax about security and privacy vulnerabilities in our specifications - I reviewed some of that history in my plenary talk in Vancouver - so what we "handed over" was a network vulnerable to spying and spoofing. > Sorry, this seems to me to be specious. Exactly not. There is a clear line between the technology (which needs to be secure) and society's use of the technology (which needs to be ethical). The IETF is on the technology side, and our ethical responsibility is to make the technology capable of being secure. I think this thread is off topic for this list, so I will leave it there. Brian > > Thanks > > Bruce > > On 12/04/2013 10:58 AM, Brian E Carpenter wrote: >> Whether >> implementors and operators choose to implement the resulting counter- >> measures is a separate question that does have political, legal or >> societal aspects. >> >> I think that Bruce's concerns apply to deployment, not to the >> IETF's work. >> > > . From Ted.Lemon@nominum.com Wed Dec 4 13:28:08 2013 Return-Path: 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 CA8B41ADF27; Wed, 4 Dec 2013 13:28:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 TRqx_uHrObc3; Wed, 4 Dec 2013 13:28:06 -0800 (PST) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by ietfa.amsl.com (Postfix) with ESMTP id 036B11AD8F5; Wed, 4 Dec 2013 13:28:05 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKUp+eYpIbZZCMsAVdG7X7HarVmfLxbhnV@postini.com; Wed, 04 Dec 2013 13:28:03 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id F411A1B82DE; Wed, 4 Dec 2013 13:28:01 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id D192A190043; Wed, 4 Dec 2013 13:28:01 -0800 (PST) Received: from [10.0.10.40] (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 4 Dec 2013 13:28:01 -0800 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ted Lemon In-Reply-To: <290E20B455C66743BE178C5C84F1240847E5103798@EXMB01CMS.surrey.ac.uk> Date: Wed, 4 Dec 2013 16:27:57 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: References: , <529E8494.7000806@perens.com> <290E20B455C66743BE178C5C84F1240847E5103798@EXMB01CMS.surrey.ac.uk> To: "" X-Mailer: Apple Mail (2.1822) X-Originating-IP: [192.168.1.10] Cc: ietf-http-wg@ietf.org, perpass , bruce@perens.com, IETF Discussion 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 21:28:09 -0000 On Dec 4, 2013, at 4:17 PM, = wrote: > Universal encryption is not a a laudable goal. Unsupported assertions are not helpful. From l.wood@surrey.ac.uk Wed Dec 4 13:19:44 2013 Return-Path: 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 536D01AE075; Wed, 4 Dec 2013 13:19:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 rOh83pLRJE5y; Wed, 4 Dec 2013 13:19:41 -0800 (PST) Received: from mail1.bemta14.messagelabs.com (mail1.bemta14.messagelabs.com [193.109.254.108]) by ietfa.amsl.com (Postfix) with ESMTP id 7E3B01AD94A; Wed, 4 Dec 2013 13:19:41 -0800 (PST) Received: from [193.109.255.147:9034] by server-4.bemta-14.messagelabs.com id D0/36-03916-96C9F925; Wed, 04 Dec 2013 21:19:37 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-13.tower-72.messagelabs.com!1386191977!9919777!1 X-Originating-IP: [131.227.200.43] X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5997 invoked from network); 4 Dec 2013 21:19:37 -0000 Received: from exht022p.surrey.ac.uk (HELO EXHT022P.surrey.ac.uk) (131.227.200.43) by server-13.tower-72.messagelabs.com with AES128-SHA encrypted SMTP; 4 Dec 2013 21:19:37 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.22]) by EXHT022P.surrey.ac.uk ([131.227.200.43]) with mapi; Wed, 4 Dec 2013 21:19:36 +0000 From: To: , , , Date: Wed, 4 Dec 2013 21:17:00 +0000 Thread-Topic: perens-perpass-appropriate-response-01 Thread-Index: Ac7xFyJSbvBBjrFJRnacvDR2Px9WTwAHwlH5 Message-ID: <290E20B455C66743BE178C5C84F1240847E5103798@EXMB01CMS.surrey.ac.uk> References: , <529E8494.7000806@perens.com> In-Reply-To: <529E8494.7000806@perens.com> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 04 Dec 2013 13:32:13 -0800 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 21:19:44 -0000 +1. Perens' response is well worth reading. Universal encryption is not a a laudable goal. (I'm also struck by the thought that Farrell's draft carefully defines 'att= ack', yet does not define 'defend'. To defend or not is a choice; that choi= ce is neglected.) Lloyd Wood http://sat-net.com/L.Wood/ ________________________________________ From: ietf [ietf-bounces@ietf.org] On Behalf Of Bruce Perens [bruce@perens.= com] Sent: 04 December 2013 01:25 To: ietf@ietf.org; perpass@ietf.org; ietf-http-wg@ietf.org Subject: perens-perpass-appropriate-response-01 I have written a reply to draft-farrell-perpass-attack-00 Please read it at http://perens.com/works/ietf/perpass/appropriate-response= /01.pdf The reply is _not_ in the form of an Internet Draft, because it's political= discourse. Thanks Bruce Perens From jacob@appelbaum.net Wed Dec 4 13:35:42 2013 Return-Path: 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 68FCC1AD94A for ; Wed, 4 Dec 2013 13:35:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.6 X-Spam-Level: X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FSL_HELO_BARE_IP_2=2, RCVD_IN_DNSWL_LOW=-0.7] 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 LoOPp_zFRGIA for ; Wed, 4 Dec 2013 13:35:41 -0800 (PST) Received: from mail-pb0-f50.google.com (mail-pb0-f50.google.com [209.85.160.50]) by ietfa.amsl.com (Postfix) with ESMTP id 6CA8B1AD8F5 for ; Wed, 4 Dec 2013 13:35:41 -0800 (PST) Received: by mail-pb0-f50.google.com with SMTP id rr13so24516364pbb.9 for ; Wed, 04 Dec 2013 13:35:38 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:mime-version:to:cc:subject :references:in-reply-to:openpgp:content-type :content-transfer-encoding; bh=9mNcRSRnOFS1VA7+6XC/qZd8rBO3DeuTkq5jC1oc2TA=; b=c+R/tGx3nEFrg76mdylElCpH06IEXL1hy3Akb3cOtT6CiMTNXTV0cHmhgPC+6xUyYL LwGu+ABt16kSgfVWEBRS917KOW18Q3HFlqPmsSusUXf7U7OgF8eZYLNI7AalT84I32ap ndkWjQkux0ZFLYgrSfcW3oC7Io4lZjIMeHfob+ye1mfYaAfT1D0w7t8Lgu4yZIkk8x37 KdMds4EBwSvUI2X82B91IXSNYsnL7mX9bPU3EUNpfrtvCBG5YM0YICXi08sWdYzeckRr Z/fxspLXXjhavBOiUa9DpueM3RFNYs3udZ0RSgnH0vs3kV2Fp328bbzcfvDAGcs589xU ShYg== X-Gm-Message-State: ALoCoQloPOgMqKOLBBQdRZiFlJnateHDGMBmI2l5fxF3FXySCXbsg+UEZtb1tLQQLYqm6Rw6QIk/ X-Received: by 10.68.134.98 with SMTP id pj2mr48031584pbb.110.1386192938343; Wed, 04 Dec 2013 13:35:38 -0800 (PST) Received: from 127.0.0.1 (manning2.torservers.net. [96.44.189.101]) by mx.google.com with ESMTPSA id oj6sm160403439pab.9.2013.12.04.13.35.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Dec 2013 13:35:37 -0800 (PST) Message-ID: <529F9898.7090309@appelbaum.net> Date: Wed, 04 Dec 2013 21:03:20 +0000 From: Jacob Appelbaum MIME-Version: 1.0 To: Bruce Perens References: <529E8494.7000806@perens.com> <20131204111309.GB11727@nic.fr> <529F8D1F.8090402@perens.com> <529F90AC.9000102@appelbaum.net> <529F957D.1020902@perens.com> In-Reply-To: <529F957D.1020902@perens.com> OpenPGP: id=4193A197 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 21:35:42 -0000 Bruce Perens: > On 12/04/2013 12:29 PM, Jacob Appelbaum wrote: >> Imagine if this was admissible in court and that someone else was telling this >> story about you? How would that have impacted your life? How could it impact >> your life in the future? > It is admissible in court. It's a public statement on a mailing list with a > public archive. So I said it in public. Anyone who wants to quote my statement > that I tapped phones in my early teens can now do so, in court or out of it. > > I inhaled too. There it is, submit it to Slashdot or something. :-) Did you notice that you decided about that disclosure? >>> Not everyone is so lucky >>> as you - will you stand by their side or dismiss them simply because it >>> doesn't apply to you, in your view? > I support their right to use a web browser that requests https preferentially, > if they think that will help. I would just like that to be their choice, not > something that is imposed upon them. It will help if it happens at scale - the masses of browsers being secure by default ensures that not only the privileged will be secure. Hardly anyone on the planet knows what 'https' is or how it works. If you support their right to be secure, consider that you more effectively support their rights by making it the default where knowledgeable folks can opt-out; the other way around doesn't make sense. >> Do you use the same computer for browsing the web as you do for your email? If >> so, I guess anyone who does would have some negligence to hide, no? > I sat on the jury of a negilgence case earlier this year. There are standards > regarding common sense and what would reasonably be expected for someone to > perform. My security practices fit such standards. > If I had to predict the future, I suspect that those standards will change in 2014 and not in your favor. All the best, Jacob From jacob@appelbaum.net Wed Dec 4 13:36:24 2013 Return-Path: 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 7C6E41AD8F5 for ; Wed, 4 Dec 2013 13:36:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.6 X-Spam-Level: X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FSL_HELO_BARE_IP_2=2, RCVD_IN_DNSWL_LOW=-0.7] 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 Swt-aXOhmuvU for ; Wed, 4 Dec 2013 13:36:23 -0800 (PST) Received: from mail-pb0-f51.google.com (mail-pb0-f51.google.com [209.85.160.51]) by ietfa.amsl.com (Postfix) with ESMTP id 2B3671ACC81 for ; Wed, 4 Dec 2013 13:36:23 -0800 (PST) Received: by mail-pb0-f51.google.com with SMTP id up15so24365319pbc.38 for ; Wed, 04 Dec 2013 13:36:20 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:mime-version:to:cc:subject :references:in-reply-to:openpgp:content-type :content-transfer-encoding; bh=LwL+gjCWkHSAxLxGnAmQGNYvfpRyuOyqBqAlmawF61A=; b=TpCuECd6mQkcRvIOpRjRyaBzJx1fXiUUUTSr69Vjy9nWO26zSutZsiGfBp08i3WyrE /tr/7JkqGsGA5/sXQIXDBbQtV0lviPVclab7M90thIVk7jtZc+CvjUxCOL8XfmakCcum twwIV82k3sJHto+SYzqFESzgiKaw+JN1w7bxFCM36eRankCriyBrC10lkn8pm98351mQ /R0aXsIpc0Tiu2xXG7Ett5IlNQYyxpFe592CVdaN+8EEx8aiWSIUQ+LUtY6Al+z4yqdj HPYLb886ZotBsMRVX+e5Mlyy61sbMAb+5ZHg3SWX3+Kv41ln2/GSVWb4ra5dS7AkY8cf xNUA== X-Gm-Message-State: ALoCoQmWs/xKy0y9nBbfXz08gDKhfW2Aw8S0stO3Zg/ynwKr5zH7M/VEqLc56WRgee/z4N7urg4D X-Received: by 10.68.0.35 with SMTP id 3mr47798785pbb.52.1386192980200; Wed, 04 Dec 2013 13:36:20 -0800 (PST) Received: from 127.0.0.1 (manning2.torservers.net. [96.44.189.101]) by mx.google.com with ESMTPSA id vh3sm106443563pbc.8.2013.12.04.13.36.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Dec 2013 13:36:19 -0800 (PST) Message-ID: <529F9F14.8050805@appelbaum.net> Date: Wed, 04 Dec 2013 21:31:00 +0000 From: Jacob Appelbaum MIME-Version: 1.0 To: Bruce Perens References: <529E8494.7000806@perens.com> <20131204111309.GB11727@nic.fr> <529F61D8.6030105@perens.com> <20131204171207.GC19914@thunk.org> <529F63C0.3040804@perens.com> <529F88AC.3090904@appelbaum.net> <529F90A0.8000706@perens.com> <529F9205.30906@appelbaum.net> <529F98C0.9090808@perens.com> In-Reply-To: <529F98C0.9090808@perens.com> OpenPGP: id=4193A197 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: Stephane Bortzmeyer , perpass@ietf.org, Theodore Ts'o 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 21:36:24 -0000 Bruce Perens: > On 12/04/2013 12:35 PM, Jacob Appelbaum wrote: >> What about the illegal spying is in your interest? > I am not 100% confident that it is illegal, although I am unhappy about FISA and > a lot of other things done since 9/11. I testify for a living. I could make a > good case that it is illegal, and maybe convince a court. > I'd encourage you to read some of the well written legal opinions by folks like Jennifer Granick or heck, even the NYT: http://justsecurity.org/2013/11/21/fisc-pen-register-opinion-its-matter-time-hurt/ http://www.nytimes.com/2013/08/09/opinion/breaking-through-limits-on-spying.html > The part that is in my interest is that sometimes they do actually catch people > who are out to hurt others. > Could you please cite a single case where the illegal NSA spying programs have done that? I believe there is exactly one and it could have been done legally. There are countless exmaples > I happen to have walked through LAX terminal 3 two days before the violence > there, and I stayed in 7 World Trade Center a month before 9/11, traveling > through the subway station and the main building basements that were buried. I > could just as likely have intersected with the bad guys. > Note that those examples happened with various levels of spying - in some cases the full monty - so we not only have lost our civil liberties, we've lost them without losing the danger, the risks or the tragedy. Surely you see this plain reality, right? I walked into Iraq in 2005 (as a journalist) and talked to people who had their entire family murdered by our war machine. The NSA spying was used in full during in our illegal war in Iraq. Surely, we should consider this as part of the balance, right? > I am all for finding those guys before they can do harm. I am not for giving > espionage and law enforcement a blank check, though. And I think there are > obvious problems today that I'd like to fix through the political process. > Policy alone cannot fix the technical problems in a vacuum. We require both policy and technology solutions. We should reflect on our ideas of liberty and enshrine them in our technology. I'd like to find the 'bad guys' too - have you looked at the NSA lately? They're not the good guys when they commit crimes against the American people or the rest of the world. Especially when they lie to the US Congress, I might add. There are real attackers and the NSA is merely one of them. We need to secure the DNS against tampering (DNSSEC), against observation (to resist specific targeting, censorship, etc) and we'll need to do similar things to other protocols. If you look ahead a few years, I encourage you to consider that your political fixes will not impact the Chinese, Russian, British or even *my* capabilities without concrete technical backing. That is one of the goals of perpass - to solve the technical problems and with that, a policy person may be able to present a political solution. Currently, we lack both political and technical solutions to mass surveillance. Sincerely, Jacob From hallam@gmail.com Wed Dec 4 13:39:47 2013 Return-Path: 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 B29D61AE177 for ; Wed, 4 Dec 2013 13:39:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 RMENJtomuXnq for ; Wed, 4 Dec 2013 13:39:46 -0800 (PST) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) by ietfa.amsl.com (Postfix) with ESMTP id AF9091AE13B for ; Wed, 4 Dec 2013 13:39:45 -0800 (PST) Received: by mail-wi0-f180.google.com with SMTP id hn9so4488829wib.1 for ; Wed, 04 Dec 2013 13:39:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vB1PqGoKrQt8Wz0fPG30lr/nLvHlKa2hC/JAbQeBiTQ=; b=NrtC6FGScsmkuzWEwggruIM9VFbZLodX5ZecVc4jdXA6arCig/SZEg6TXvCKfyrQFE bMHj7Mq85p0dHQ+grhDVbiXJ9Uk8GngwP679V7yHDOsQhb/+7F205RPrxiBmKjIkUGju oQcHtB05ZEEH4wh0ruLp9nMYgYkUo9Dz5L5ZFW13zb7iuID3nSydTiu4Rcv4f06lU8K2 pBlhU7+zBVLK8k9BR+PnYuZV2N286S26ycKvcgSPxh3q5gMkcfEeI2UsIN7BO9rcbW1Q L15yoXh9dmSzK+KzhCmFlJgDOQWa4aFUv65m6+F6JbwruFk9eyP0TpDpWRpNV+of/4B5 lIfA== MIME-Version: 1.0 X-Received: by 10.180.189.80 with SMTP id gg16mr9150661wic.32.1386193182187; Wed, 04 Dec 2013 13:39:42 -0800 (PST) Received: by 10.194.243.136 with HTTP; Wed, 4 Dec 2013 13:39:42 -0800 (PST) In-Reply-To: <529F98C0.9090808@perens.com> References: <529E8494.7000806@perens.com> <20131204111309.GB11727@nic.fr> <529F61D8.6030105@perens.com> <20131204171207.GC19914@thunk.org> <529F63C0.3040804@perens.com> <529F88AC.3090904@appelbaum.net> <529F90A0.8000706@perens.com> <529F9205.30906@appelbaum.net> <529F98C0.9090808@perens.com> Date: Wed, 4 Dec 2013 16:39:42 -0500 Message-ID: From: Phillip Hallam-Baker To: Bruce Perens Content-Type: multipart/alternative; boundary=001a11c2231436e7d004ecbc405f Cc: Theodore Ts'o , perpass , Stephane Bortzmeyer , Jacob Appelbaum 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 21:39:47 -0000 --001a11c2231436e7d004ecbc405f Content-Type: text/plain; charset=ISO-8859-1 On Wed, Dec 4, 2013 at 4:04 PM, Bruce Perens wrote: > On 12/04/2013 12:35 PM, Jacob Appelbaum wrote: > > What about the illegal spying is in your interest? > > I am not 100% confident that it is illegal, although I am unhappy about > FISA and a lot of other things done since 9/11. I testify for a living. I > could make a good case that it is illegal, and maybe convince a court. > I am pretty sure that the Russian courts would consider the activities of the NSA to be illegal. The authorities in Brazil do as well. And I am not at all keen on this idea that Alexander signed off on of using raw intelligence data for 'swapsies' with foreign governments that have a habit of murdering their political opponents (and using a British passport to cover their tracks to boot!). You have a very parochial view of the situation here and you are making the rather ridiculous claim that people who disagree with you are committing treason. If the US wants to help in the fight against terrorism it will ban all firearms and collect them for immediate disposal. Until that happens I see no reason to take them seriously. The number of deaths due to terrorism is inconsequential in comparison to the annual number of deaths due to firearms. -- Website: http://hallambaker.com/ --001a11c2231436e7d004ecbc405f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Dec 4, 2013 at 4:04 PM, Bruce Perens <= bruce@perens.com&= gt; wrote:
=20 =20 =20 =20
On 12/04/2013 12:35 PM, Jacob Appelbaum wrote:
What about the illegal spying is in your interest?
I am not 100% confident that it is illegal, although I am unhappy about FISA and a lot of other things done since 9/11. I testify for a living. I could make a good case that it is illegal, and maybe convince a court.

I am pretty= sure that the Russian courts would consider the activities of the NSA to b= e illegal.

The authorities in Brazil do as well.

And I am not at all keen on this idea that Alexander si= gned off on of using raw intelligence data for 'swapsies' with fore= ign governments that have a habit of murdering their political opponents (a= nd using a British passport to cover their tracks to boot!).


You have a very parochial view of the si= tuation here and you are making the rather ridiculous claim that people who= disagree with you are committing treason.

If the = US wants to help in the fight against terrorism it will ban all firearms an= d collect them for immediate disposal. Until that happens I see no reason t= o take them seriously. The number of deaths due to terrorism is inconsequen= tial in comparison to the annual number of deaths due to firearms.


--
Website: http://hallambaker.com/
--001a11c2231436e7d004ecbc405f-- From l.wood@surrey.ac.uk Wed Dec 4 14:06:25 2013 Return-Path: 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 2B2B61ADF7F; Wed, 4 Dec 2013 14:06:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 kLhr0DHRqAvn; Wed, 4 Dec 2013 14:06:23 -0800 (PST) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.146]) by ietfa.amsl.com (Postfix) with ESMTP id 0C6B81ADF64; Wed, 4 Dec 2013 14:06:14 -0800 (PST) Received: from [195.245.231.67:58950] by server-10.bemta-5.messagelabs.com id 29/AF-01405-257AF925; Wed, 04 Dec 2013 22:06:10 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-14.tower-82.messagelabs.com!1386194769!29585263!1 X-Originating-IP: [131.227.200.35] X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24555 invoked from network); 4 Dec 2013 22:06:09 -0000 Received: from exht021p.surrey.ac.uk (HELO EXHT021P.surrey.ac.uk) (131.227.200.35) by server-14.tower-82.messagelabs.com with AES128-SHA encrypted SMTP; 4 Dec 2013 22:06:09 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.22]) by EXHT021P.surrey.ac.uk ([131.227.200.35]) with mapi; Wed, 4 Dec 2013 22:05:16 +0000 From: To: Date: Wed, 4 Dec 2013 22:05:15 +0000 Thread-Topic: Commnets on draft-farrell-perpass-attack-00 was RE: perens-perpass-appropriate-response-01 Thread-Index: AQHO8TzpP5tlkNSKykiLz/9Jsx4RUQ== Message-ID: <290E20B455C66743BE178C5C84F1240847E5103799@EXMB01CMS.surrey.ac.uk> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: perpass@ietf.org, bruce@perens.com, ietf-http-wg@w3.org, ietf@ietf.org Subject: [perpass] Commnets on draft-farrell-perpass-attack-00 was RE: 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 22:06:25 -0000 (fixing ietf-http-wg address from ietf.org to w3.org) Perens' response at http://perens.com/works/ietf/perpass/appropriate-response/01.pdf (not an in= ternet draft, sigh - alienate your readers before they start!) commenting on http://tools.ietf.org/html/draft-farrell-perpass-attack gives some of the reasons in support of universal encryption not being a la= udable goal. This is a political problem, not a technical problem. From a technical pers= pective, caching static content matters. Trying to figure out problems that= aren't security problems matters. Mandating secure communications for worl= dwide http is pretty much the same as mandating secure encrypted email worl= dwide - large failure modes, resulting in an inability to communicate. Whic= h is why use of secure email is not widespread. As IETF security AD, Farrell's response must always be 'we need more securi= ty' and his draft - everything is an attack - is a reflection of that outl= ook. One recent time everything was viewed as an attack was in Digital Rights Ma= nagement by content providers. The result of DRM was to impose massive tech= nical costs and shift the modes of attack on content. If you want to consid= er the failure modes of a secured web with secure communications everywhere= , consider the failure modes of DRM. Meanwhile, the content providers pursu= ed legal remedies as more effective. Is the IETF now advocating a DRM appro= ach, when legal remedies would be more appropriate? Any security system or algorithm, can be broken; when it is, it is consider= ed as no longer fit for purposes, unfashionable, and to be discarded. Secur= ity is always raising the bar - e.g. MD5 is no longer secure enough for se= curity purposes (though still excellent in limited context as a reliability= check for large files), SHA256 may not be strong enough... this is an upgr= ade cycle that eventually every implementation steps off, becoming incompat= ible with the latest and greatest. And this upgrade cycle will break the we= b into little pools of not-compatible-with-latest security as a result. One= way to avoid that cycle is to always permit interoperability without secur= ity. (warn as much as you like, but permit it.) The benefits of interop testing, less power drain, less complexity, and of = actually being able to communicate if that is desired. are worthwhile. Dema= nd security everywhere if you like, and treat everything as an attack, just= as DRM did, but, as with DRM, it's a fool's errand. Lloyd Wood http://sat-net.com/L.Wood/ ________________________________________ From: Ted Lemon [ted.lemon@nominum.com] Sent: 04 December 2013 21:27 To: Wood L Dr (Electronic Eng) Cc: bruce@perens.com; IETF Discussion; perpass; ietf-http-wg@ietf.org Subject: Re: perens-perpass-appropriate-response-01 On Dec 4, 2013, at 4:17 PM, wro= te: > Universal encryption is not a a laudable goal. Unsupported assertions are not helpful. From Jeff.Hodges@KingsMountain.com Wed Dec 4 14:18:01 2013 Return-Path: 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 457031ADF63 for ; Wed, 4 Dec 2013 14:18:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.469 X-Spam-Level: * X-Spam-Status: No, score=1.469 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-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 iBNHPddQKUql for ; Wed, 4 Dec 2013 14:17:58 -0800 (PST) Received: from oproxy19-pub.mail.unifiedlayer.com (oproxy19-pub.mail.unifiedlayer.com [70.40.200.33]) by ietfa.amsl.com (Postfix) with SMTP id 758591AD8DA for ; Wed, 4 Dec 2013 14:17:58 -0800 (PST) Received: (qmail 5241 invoked by uid 0); 4 Dec 2013 22:17:54 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy19.mail.unifiedlayer.com with SMTP; 4 Dec 2013 22:17:54 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=HILPRgRrQ1QUbmLTO6Y/VHHHK63kwWOWdwfjU0jAmlY=; b=isaBDa6o2u/xOq9Fv9glnm9T+LVz6P838IpaedY6Vy18hXyo56H4V0IsX2PUKLNoYp7+A9HZpATSNXLUMXompaxpe8VjisTSaw5VrnduJdpivE3QYtvHc0SSJC7ET1Wp; Received: from [216.113.168.128] (port=34911 helo=[10.244.137.220]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.80) (envelope-from ) id 1VoKlV-0000QI-Pj; Wed, 04 Dec 2013 15:17:53 -0700 Message-ID: <529FAA11.4040500@KingsMountain.com> Date: Wed, 04 Dec 2013 14:17:53 -0800 From: =JeffH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130330 Thunderbird/17.0.5 MIME-Version: 1.0 To: ietf@ietf.org, perpass@ietf.org, ietf-http-wg@ietf.org Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Subject: Re: [perpass] perens-perpass-appropriate-response-01 (in plain text) 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 22:18:01 -0000 [here's a simplistic plaintext rendering such that Bruce's document itsel= f=20 will also be cached in the mailing list archives. original: ] perens-perpass-appropriate-response-01 Reply to draft-farrell-perpass-attack-00 On Appropriate Response by Internet Protocol Designers to Pervasive Monit= oring Bruce Perens +1 510-4PERENS 3-December-2013 "If I were my predecessor, I'd order a full-scale attack on Webistan.=20 Fortunately Webistan doesn't exist, so I've just had to deal." - Barack=20 Obama [1] Introduction Draft-farrell-perpass-attack-00 [2], or =93Farrell=94 for short in this=20 document, proposes that pervasive monitoring of the internet is an attack= ,=20 and that IETF should work to mitigate the attack. [3] When a standards organization attempts to deal with political issues,=20 discussion only poorly fits their normal working framework. Organizations= =20 like IETF vastly prefer to develop a virtually unanimous consensus based = on=20 technical merit before going forward with any proposal. Political discour= se=20 yields a majority position but consensus is very rarely achieved. Farrell is in the form of an Internet Draft. Such drafts are intended to = be=20 technical documents of the best practices of the Internet protocol=20 designers, and are not particularly appropriate for political discourse. = Thus, in this reply the Internet Draft form is discarded. The canonical home of this document on the Internet is=20 http://perens.com/works/ietf/perpass/appropriate-response/ Technical Attacks vs. Attacks Upon Sovereign Powers Farrell proposes that pervasive monitoring of the internet is an attack. = For=20 a protocol design organization such as IETF, =93attack=94 has a different= =20 meaning than an attack upon a sovereign power. An attack in this case is = a=20 deliberate attempt to defeat the correct technical operation of the=20 Internet. In this case, the feature of communications privacy [6]. We Can't Ignore The Context The context, obviously, is Edward Snowden's revelation of NSA's mass=20 surveilance program. This was discussed at IETF 88 in Vancouver, November= =20 3-8, 2013 and Farrell results from this discussion. Farrell avoids any discussion of context or intent: "The term [attack], when used technically, implies nothing about the=20 motivation of the bad-actor mounting the attack, who is still called a=20 bad-actor no matter what one really thinks about their motivation." Thus, Farrell rejects the motivation and identity of the attacker as irre= levant: "The motivation behind pervasive monitoring is not particularly relevant= =20 for this document, but can range from non-targeted nation-state=20 surveillance, to legal but privacy-unfriendly purposes by commercial=20 enterprises, to illegal purposes by criminals." This is an attempt to transpose what is actually a political problem into= a=20 purely technical one, and thus to arrive at consensus on a technical meri= t=20 basis alone within IETF's standards development framework. Technical Attacks by Sovereign Powers, vs. those by Commercial Entities o= r=20 Criminals The appropriate responses to attacks by sovereign powers, commercial=20 entities, and criminals are not necessarily the same, because of the lega= l=20 framework that applies to them: Criminal activity is, obviously, covered by criminal law, and technical=20 responses which deter or prevent criminal activity without otherwise caus= ing=20 damage are in general on a range from appropriate to required. Failing to= =20 lock a thief out of one's home is seen as a lapse of due diligence.=20 Marketing a lock which is easily subverted by thieves might be seen as=20 negligence. Attacks on consumer privacy by commercial entities are generally within t= he=20 domain of civil law. For example, HIPAA is a U.S. law defining civil righ= ts=20 with regard to the privacy of an individual's medical information. Howeve= r,=20 it is important to note that individual privacy is far from universally=20 guaranteed. In particular, the conduct of an individual using facilities = owned by another entity is not necessarily private, and the overriding=20 rights may be those of the property owner. Technical responses to attacks= on=20 individual privacy in the context of facilities owned by another entity m= ay=20 violate the rights of that entity to the extent that they fall under civi= l=20 or criminal law, or may be appropriate, depending on the context. Technical attacks by sovereign powers are in general justified by those=20 powers as being part of law enforcement. The justice of such enforcement = is=20 the topic of political discourse and the courts. In general, sovereign=20 powers enact and enforce laws against the hindrance of law enforcement by= =20 technical means. Such laws to some extent override civil rights such as t= he=20 right to privacy. Technical responses to attacks on individual privacy by= =20 sovereign entities may be held as acceptable, criminal, or even treasonou= s=20 conduct by those entities. Proposed Implementation It has been proposed on the HTTP 2 designers email list to implement the = intent of discussion at IETF 88 by encrypting every web access by everyon= e=20 in the next version of the HTTP protocol, despite the significant technic= al=20 disadvantages that would be caused by such encryption. The explicit purpo= se=20 given by more than one proposer on the mailing list was to make it=20 impractically expensive for a sovereign power, specifically the NSA actin= g=20 on behalf of the United States, to surveil the web [4]. As web servers an= d=20 browsers adopted the new HTTP 2 protocol and use of the older HTTP versio= n=20 diminished, NSA and its ilk would be overwhelmed by the amount of data th= at=20 would have to be decrypted in order to implement pervasive monitoring. Or= so=20 the proposers think. Most important about these proposals is their stated intent to hinder NSA= =20 and its ilk in the task of law enforcement. It may be that the means of t= his=20 law enforcement are themselves illegal, or they may simply be so repugnan= t=20 that they should be illegal. If so, the only acceptable forum for reformi= ng=20 them are political discourse and the courts. The Internet is not a Sovereign Entity It was once popular to think of the Internet as a virtual place outside o= f=20 the purview of governments. In reality, there has never been any signific= ant=20 obstacle to the enforcement of law regarding conduct carried out upon the= =20 Internet by a nation's citizens. IETF is not acting on behalf of a sovereign power, and has no power to=20 hinder monitoring for the purpose of law enforcement in contravention of = some nation's laws, no matter how unjust or repugnant that monitoring may= =20 be. The proposers and implementers of systems intended to hinder law=20 enforcement are arguably a criminal or treasonous conspiracy. Going ahead= =20 with implementation on this basis would be inadvisable. Exclusively Technical Solutions Do Not Lead To Justice There are some situations where surveillance by a sovereign entity is=20 appropriate, for example one in which there is a clear and present danger= of=20 criminal violence which can be avoided if law enforcement is properly=20 informed. Few would call for absolute protection of the privacy of those = who=20 carried out the Boston Massacre. The overriding right in this case is tha= t=20 of the common person to bodily integrity as they carry out their=20 conventional activities in society. A more mundane, but still important, use of surveillance is the monitorin= g=20 by network administrators of their own networks, including in their homes= =2E=20 For example, this is a significant issue with devices which we have but d= o=20 not entirely control, such as the ubiquitous iPhone. Autonomous software = on=20 such devices can make use of the camera and microphone for more invasive = surveillance than Orwell ever dreamed of. Monitoring of our own devices t= o=20 prevent such misconduct would be chaffed by the proposed universal=20 encryption, making good and harmful communication indistinguishable from = each other. [5] There are, obviously, situations in which surveillance by a sovereign ent= ity=20 is inappropriate and results in unacceptable injury, in particular=20 surveillance as part of the prosecution of peaceful political dissidence.= =20 Dissidents are imprisoned or executed in many parts of the world with the= =20 assistance of such surveillance, and the civil rights of entire populatio= ns=20 are curtailed. Thus: If we technically hinder appropriate surveillance, we will have blood on = our=20 hands. If we technically permit inappropriate surveillance, we will also have bl= ood=20 on our hands. There is no technical solution to this conundrum. The only thing that can= =20 excuse our conduct is our participation in the political process through = which we can do our best to find a balance and to mitigate the harmful us= es=20 of our technology. Inappropriateness of Universal Encryption The universal encryption of HTTP connections proposed on the working grou= p=20 mailing lists would hinder the technical operation of the internet. A great amount of Internet content, perhaps the majority, is in the form = of=20 static files or invariant information stored at public URLs that can be=20 accessed by anyone. I'll call this =93static content=94 for short. Images= ,=20 videos, web audio, JavaScript, CSS, and much of the text of the web fall = under this definition. None of these things are secret and there is littl= e=20 reason to obscure an individual's access to them. The encryption proposed= =20 does not obscure what web server is being accessed or the date and time o= f=20 the communication, nor is there a practical way to do so, so it would not= =20 hide much of the =93meta-data=94 which NSA is said to collect. Much of this static content is the =93background=94 of web pages, and URL= s to it=20 are not actually typed in by the user, but are a part of the web page its= elf=20 and are requested automatically by the browser as part of displaying the = page. Transferring this information =93in the clear=94 rather than by using enc= ryption=20 is the highest-performance means of providing web content. To encrypt all= of=20 this information would actually slow down the web. There is also an energ= y=20 cost: the electricity wasted by all of this encryption would likely resul= t=20 in megatons of additional carbon emitted from the burning of fossil fuel = for=20 electric generation, as well as otherwise-avoidable social and economic=20 costs of renewable energy sources. Encrypted content makes caching web proxies more difficult to implement, = and=20 much more likely to be avoided by the user. While such proxies were not=20 significant in the early years of the internet, the use of transparent=20 proxies by large internet providers has made their effect more significan= t=20 in recent time, as has the advent of commercial outbound proxy providers = such as Cloudflare. Web sites which I manage achieve a 50% bandwidth savi= ngs=20 today due to proxies and caching. Strategies that reduce rather than=20 increase the use of proxies would be a step backward for the internet,=20 further slowing down the user experience and increasing system costs. Bet= ter=20 to design strategies that increase caching while curbing its abuses. Universal Encryption Would Not Hinder Commercial Surveillance When you get a product for free on the web, you are usually the real=20 product. Thus, surveillance of web transactions by corporate entities is = ubiquitous, mainly for the purpose of targeting advertising so far.=20 Companies are collecting a huge database of all of our interests,=20 preferences, and activities. There are many completely legal uses for thi= s=20 information that might not really be in our best interest. Unfortunately, encryption doesn't help with this. The information being=20 collected comes predominantly from web servers and browser tool bars, whi= ch=20 are on the ends of the communication where it is necessarily decrypted. T= he=20 server owners and software providers profit from using or selling user da= ta. It has been proposed that anonymity be added as a universal Internet=20 feature, so that no server can identify who is behind the browser at any = moment. However, there is no onus upon web content providers to serve the= ir=20 pages to anonymous users, and if such service interferes with the profits= =20 derived from surveillance, they will stop doing so and will demand that=20 users log in or otherwise defeat anonymity. For many sites, this is alrea= dy=20 the case. Just try browsing the web without cookies enabled, and you'll=20 quickly find that many sites won't work at all. Proposals Would Take Away User Choice "He will *definitely* be punished severely if he proposes putting securi= ty=20 choices in the faces of ordinary humans; no =93probably expect=94 about i= t..." -=20 Tim Bray, to the HTTP Working Group Mailing List, December 3, 2013. The attitude within IETF working groups concerned with this issue,=20 unfortunately, appears to be one of contempt for users and even web site = operators. It's almost universally held within the working groups that us= ers=20 can't be responsible for their own security, even with the assistance of = web=20 browser designers, and that the choice must thus be taken away from them.= =20 Similarly, working group members are not confident that site operators ca= n=20 ever understand where to use HTTPS vs. HTTP, so the choice must be taken = from them as well. What makes the proposers better able to make this choi= ce=20 for the whole world was not obvious to me. Today, users have the option to request HTTPS URLs preferentially, and th= ey=20 can obtain browsers that do so automatically if they believe that this wi= ll=20 enhance their privacy. Some sites are already set up to always provide=20 HTTPS, at the site operator's choice rather than the user's. However, not everyone wants to be a new member of the Concealment Society= =2E=20 Just look at how much information people share on social networks,=20 enthusiastically feeding the corporate databases well beyond the reach of= =20 any encryption. Today's implementation of encryption that is turned on or off per page is= a=20 much better strategy than universal encryption. It lets us have encryptio= n=20 where it's useful, like on login pages and where we provide personal=20 information or our credit card number. It allows us to avoid the burden o= f=20 encryption elsewhere and not hide what there's no reason to hide. It lets= =20 those of us with special needs turn on encryption preferentially. And it = doesn't help someone to blow you up the next time you run a race. What's = not=20 to like about that? Conclusion The HTTP working groups have a lot to do just to make the web operate bet= ter=20 and more efficiently. Having them force unwanted, mostly ineffective, and= =20 sometimes outright harmful extra security on the whole world has already = distracted from the completion of their work. IETF is not the proper venue to handle pervasive surveillance, which is a= =20 political and legal issue rather than a technical one. IETF participants = simply don't have the right to make decisions about it for the whole worl= d.=20 But they can help, by participating in political discourse and bringing a= ll=20 of their knowledge to the table. Technical people are not politically empowered today, simply because so f= ew=20 of us have chosen to participate in politics. We must change, or others w= ill=20 change things in ways we don't like. Footnotes 1.In a campaign email sent to the Yes Lab list, 11/26/2013. Not a parody = as=20 far as I can tell. 2.At http://tools.ietf.org/html/draft-farrell-perpass-attack-00 3.Defined at http://en.wikipedia.org/wiki/HIPAA 4.Actually, NSA is perfectly capable of getting data from the end-points = of=20 a communication, thus making encryption irrelevant. This is especially=20 efficient when the end-point is a large entity operating an extremely=20 popular web destination, for example Google or Wikimedia Foundation, whic= h=20 can be legally compelled to hand over unencrypted data en masse. It's also possible for governments to compel the producers of computing=20 hardware, operating systems, encryption hardware, and web servers and=20 clients. Features for government access probably exist in most home=20 computers today. The entire paradigm of public-key encryption will always be suspect becau= se=20 it depends on the assumption that fast solutions do not exist to the=20 mathematical algorithms upon which it is based. Specific encryption=20 algorithms are also suspect because it is impossible to prevent governmen= t=20 influence upon their design. 5.Chaff, in this context, means the concealment of meaningful information= in=20 the midst of deliberately-created noise. This derives from the military=20 usage defined at http://en.wikipedia.org/wiki/Chaff_%28countermeasure%29 6.Communication privacy is a relatively recent feature of a few Internet = protocols, and one that is far from universally guaranteed. Thus Farrnell= is=20 actually a new-feature request. --- end From bruce@perens.com Wed Dec 4 14:42:41 2013 Return-Path: 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 D0C311ACCDC for ; Wed, 4 Dec 2013 14:42:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.177 X-Spam-Level: X-Spam-Status: No, score=-1.177 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, 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 R2N86TdEc78q for ; Wed, 4 Dec 2013 14:42:41 -0800 (PST) Received: from alchemy.perens.com (alchemy.perens.com [206.221.219.26]) by ietfa.amsl.com (Postfix) with ESMTP id 217B51AC7EE for ; Wed, 4 Dec 2013 14:42:41 -0800 (PST) Received: from [192.168.18.131] (mail.a10networks.com [12.207.16.167]) by alchemy.perens.com (Postfix) with ESMTPSA id 1053150008A for ; Wed, 4 Dec 2013 14:42:38 -0800 (PST) Message-ID: <529FAFE2.8060205@perens.com> Date: Wed, 04 Dec 2013 14:42:42 -0800 From: Bruce Perens User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131103 Icedove/17.0.10 MIME-Version: 1.0 To: perpass@ietf.org References: <529E8494.7000806@perens.com> <20131204111309.GB11727@nic.fr> <529F7B3B.5020901@gmail.com> <529F91C9.6060906@perens.com> <529F9E01.2000306@gmail.com> In-Reply-To: <529F9E01.2000306@gmail.com> Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 22:42:41 -0000
On 12/04/2013 01:26 PM, Brian E Carpenter wrote:
You could certainly argue that the IETF has historically been too lax about security and privacy vulnerabilities in our specifications - I reviewed some of that history in my plenary talk in Vancouver - so what we "handed over" was a network vulnerable to spying and spoofing.
It was incredibly successful. There was a competing stack design in the OSI protocols which went nowhere. IMO the reason for success was the simplicity. Don't abandon that now.

Yes, the IETF protocols are voluntary. But IETF has a certain degree of cachet by now, and there is a very high probability that the industry will follow IETF's lead because of that. Which IMO gives you the same responsibility that you would have if the protocols were not mandatory.

    Thanks

    Bruce
From Ted.Lemon@nominum.com Wed Dec 4 14:42:51 2013 Return-Path: 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 277A61ADE71; Wed, 4 Dec 2013 14:42:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 dW-sDGyYdJ_D; Wed, 4 Dec 2013 14:42:49 -0800 (PST) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by ietfa.amsl.com (Postfix) with ESMTP id 647C41AE16F; Wed, 4 Dec 2013 14:42:49 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKUp+v5l6CglowlHQpt2Wuy4OHqcrxhV3X@postini.com; Wed, 04 Dec 2013 14:42:46 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id CD81E1B82DD; Wed, 4 Dec 2013 14:42:45 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id B4592190043; Wed, 4 Dec 2013 14:42:45 -0800 (PST) Received: from [10.0.10.40] (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 4 Dec 2013 14:42:45 -0800 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ted Lemon In-Reply-To: <290E20B455C66743BE178C5C84F1240847E5103799@EXMB01CMS.surrey.ac.uk> Date: Wed, 4 Dec 2013 17:42:43 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <2C66A416-5F07-4803-A4C0-BB61734BA42E@nominum.com> References: <290E20B455C66743BE178C5C84F1240847E5103799@EXMB01CMS.surrey.ac.uk> To: "" X-Mailer: Apple Mail (2.1822) X-Originating-IP: [192.168.1.10] Cc: perpass , bruce@perens.com, ietf-http-wg@w3.org, IETF Discussion Subject: Re: [perpass] Commnets on draft-farrell-perpass-attack-00 was RE: 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 22:42:51 -0000 On Dec 4, 2013, at 5:05 PM, l.wood@surrey.ac.uk wrote: > This is a political problem, not a technical problem. =46rom a = technical perspective, caching static content matters. Trying to figure = out problems that aren't security problems matters. Mandating secure = communications for worldwide http is pretty much the same as mandating = secure encrypted email worldwide - large failure modes, resulting in an = inability to communicate. Which is why use of secure email is not = widespread. I take it you haven't been reading the responses to Bruce's essay, or = you would have seen that these points have already been discussed and = refuted. From bruce@perens.com Wed Dec 4 14:52:05 2013 Return-Path: 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 9D2991AE16F for ; Wed, 4 Dec 2013 14:52:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.177 X-Spam-Level: X-Spam-Status: No, score=-1.177 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, 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 u-L0nx-42dDV for ; Wed, 4 Dec 2013 14:52:05 -0800 (PST) Received: from alchemy.perens.com (alchemy.perens.com [206.221.219.26]) by ietfa.amsl.com (Postfix) with ESMTP id 135911ADBCA for ; Wed, 4 Dec 2013 14:52:05 -0800 (PST) Received: from [192.168.18.131] (mail.a10networks.com [12.207.16.167]) by alchemy.perens.com (Postfix) with ESMTPSA id 298C750008A for ; Wed, 4 Dec 2013 14:52:02 -0800 (PST) Message-ID: <529FB216.7010504@perens.com> Date: Wed, 04 Dec 2013 14:52:06 -0800 From: Bruce Perens User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131103 Icedove/17.0.10 MIME-Version: 1.0 To: perpass@ietf.org References: <290E20B455C66743BE178C5C84F1240847E5103799@EXMB01CMS.surrey.ac.uk> <2C66A416-5F07-4803-A4C0-BB61734BA42E@nominum.com> In-Reply-To: <2C66A416-5F07-4803-A4C0-BB61734BA42E@nominum.com> Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [perpass] Commnets on draft-farrell-perpass-attack-00 was RE: 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 22:52:05 -0000
On 12/04/2013 02:42 PM, Ted Lemon wrote:
I take it you haven't been reading the responses to Bruce's essay, or you would have seen that these points have already been discussed and refuted.
That might have been an accurate statement if this were a technical discussion rather than a political one. We saw opposing viewpoints. Opposition isn't refutation.

    Thanks

    Bruce
From hallam@gmail.com Wed Dec 4 14:57:10 2013 Return-Path: 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 E2C191AE120 for ; Wed, 4 Dec 2013 14:57:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 CqTejInyvB_d for ; Wed, 4 Dec 2013 14:57:09 -0800 (PST) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id EF3CF1ADF84 for ; Wed, 4 Dec 2013 14:57:08 -0800 (PST) Received: by mail-we0-f170.google.com with SMTP id w61so16014123wes.1 for ; Wed, 04 Dec 2013 14:57:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DKqBpO523DqsO7fGNv8Mn4up/LcOqs5CSB/J6pOZjw0=; b=XFIxQUIOLuClDvJksG0nqlfC8tMm2iWFnEedFUlXTm5OAUFVj9qA9W1Xd9H4xxPP/t k7yFuMVmsAGVC0i9etI0QIjNdadIlb5K5Y/GwYPKPOgAxk2KY8FpvbCwvgw4F0DnbSaT l9sVxVGYcAnsY/LsG53iX3LO7GyE96O0O+v4VTjjCb5tmFSsgfaHdFMQj3qCp8u0lr60 jTwoFknJU+3zSw9omvsuI2Him58Ak0qZDTGezuRlzqyX5z80JtfPaOHHSZZZcBZb/4zB QqsYiD5LlQZ2sb/g4wV1dlJ+fjpROmEeLWE88Vw1lLKg2y3GPH3SZ7xroew0fqD9jPrW yTow== MIME-Version: 1.0 X-Received: by 10.180.109.201 with SMTP id hu9mr9201859wib.59.1386197825387; Wed, 04 Dec 2013 14:57:05 -0800 (PST) Received: by 10.194.243.136 with HTTP; Wed, 4 Dec 2013 14:57:04 -0800 (PST) In-Reply-To: <529FB216.7010504@perens.com> References: <290E20B455C66743BE178C5C84F1240847E5103799@EXMB01CMS.surrey.ac.uk> <2C66A416-5F07-4803-A4C0-BB61734BA42E@nominum.com> <529FB216.7010504@perens.com> Date: Wed, 4 Dec 2013 17:57:04 -0500 Message-ID: From: Phillip Hallam-Baker To: Bruce Perens Content-Type: multipart/alternative; boundary=e89a8f2356bdf88b8f04ecbd54eb Cc: perpass Subject: Re: [perpass] Commnets on draft-farrell-perpass-attack-00 was RE: 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 22:57:11 -0000 --e89a8f2356bdf88b8f04ecbd54eb Content-Type: text/plain; charset=ISO-8859-1 On Wed, Dec 4, 2013 at 5:52 PM, Bruce Perens wrote: > On 12/04/2013 02:42 PM, Ted Lemon wrote: > > I take it you haven't been reading the responses to Bruce's essay, or you > would have seen that these points have already been discussed and refuted. > > That might have been an accurate statement if this were a technical > discussion rather than a political one. We saw opposing viewpoints. > Opposition isn't refutation. > When someone starts accusing everyone of treason it isn't so much refutation that is appropriate as the men in white coats. -- Website: http://hallambaker.com/ --e89a8f2356bdf88b8f04ecbd54eb Content-Type: text/html; charset=ISO-8859-1
On Wed, Dec 4, 2013 at 5:52 PM, Bruce Perens <bruce@perens.com> wrote:
On 12/04/2013 02:42 PM, Ted Lemon wrote:
I take it you haven't been reading the responses to Bruce's essay, or you would have seen that these points have already been discussed and refuted.
That might have been an accurate statement if this were a technical discussion rather than a political one. We saw opposing viewpoints. Opposition isn't refutation.

When someone starts accusing everyone of treason it isn't so much refutation that is appropriate as the men in white coats.

--
Website: http://hallambaker.com/
--e89a8f2356bdf88b8f04ecbd54eb-- From l.wood@surrey.ac.uk Wed Dec 4 15:00:07 2013 Return-Path: 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 5F1FF1AE22C; Wed, 4 Dec 2013 15:00:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 8aHeajq6ViWO; Wed, 4 Dec 2013 15:00:04 -0800 (PST) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.169]) by ietfa.amsl.com (Postfix) with ESMTP id 58E3B1AE19F; Wed, 4 Dec 2013 15:00:04 -0800 (PST) Received: from [85.158.137.99:30408] by server-9.bemta-3.messagelabs.com id 92/BB-13104-0F3BF925; Wed, 04 Dec 2013 23:00:00 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-7.tower-217.messagelabs.com!1386198000!13075477!1 X-Originating-IP: [131.227.200.35] X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17133 invoked from network); 4 Dec 2013 23:00:00 -0000 Received: from exht021p.surrey.ac.uk (HELO EXHT021P.surrey.ac.uk) (131.227.200.35) by server-7.tower-217.messagelabs.com with AES128-SHA encrypted SMTP; 4 Dec 2013 23:00:00 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.22]) by EXHT021P.surrey.ac.uk ([131.227.200.35]) with mapi; Wed, 4 Dec 2013 22:59:59 +0000 From: To: Date: Wed, 4 Dec 2013 22:55:49 +0000 Thread-Topic: Commnets on draft-farrell-perpass-attack-00 was RE: perens-perpass-appropriate-response-01 Thread-Index: Ac7xQii/iEXCGaHqTBySIYcN1jqYNgAAdEdC Message-ID: <290E20B455C66743BE178C5C84F1240847E510379A@EXMB01CMS.surrey.ac.uk> References: <290E20B455C66743BE178C5C84F1240847E5103799@EXMB01CMS.surrey.ac.uk>, <2C66A416-5F07-4803-A4C0-BB61734BA42E@nominum.com> In-Reply-To: <2C66A416-5F07-4803-A4C0-BB61734BA42E@nominum.com> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: perpass@ietf.org, bruce@perens.com, ietf-http-wg@w3.org, ietf@ietf.org Subject: Re: [perpass] Commnets on draft-farrell-perpass-attack-00 was RE: 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 23:00:07 -0000 Where are these being discussed? It's a response to an IETF draft, ergo iet= f@ietf.org is entirely appropriate. That Perens doesn't submit it as an int= ernet-draft in response just suggests lack of political nous. Way to go on the selective quoting - I see you ignore the DRM point. Sheesh= , you can't even give a pointer to the refutations you apparently cite. Don't you have anything substantial to say yourself, other than snarky onel= iners? Lloyd Wood http://sat-net.com/L.Wood/ ________________________________________ From: Ted Lemon [ted.lemon@nominum.com] Sent: 04 December 2013 22:42 To: Wood L Dr (Electronic Eng) Cc: bruce@perens.com; IETF Discussion; perpass; ietf-http-wg@w3.org Subject: Re: Commnets on draft-farrell-perpass-attack-00 was RE: perens-per= pass-appropriate-response-01 On Dec 4, 2013, at 5:05 PM, l.wood@surrey.ac.uk wrote: > This is a political problem, not a technical problem. From a technical pe= rspective, caching static content matters. Trying to figure out problems t= hat aren't security problems matters. Mandating secure communications for w= orldwide http is pretty much the same as mandating secure encrypted email w= orldwide - large failure modes, resulting in an inability to communicate. W= hich is why use of secure email is not widespread. I take it you haven't been reading the responses to Bruce's essay, or you w= ould have seen that these points have already been discussed and refuted. From Ted.Lemon@nominum.com Wed Dec 4 15:06:58 2013 Return-Path: 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 B34541AE2C2; Wed, 4 Dec 2013 15:06:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 bcJRdFQvH88J; Wed, 4 Dec 2013 15:06:57 -0800 (PST) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by ietfa.amsl.com (Postfix) with ESMTP id E73F21AE1DD; Wed, 4 Dec 2013 15:06:56 -0800 (PST) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKUp+1jjYhvXNIiaqwC7NDndhALRoQZgpk@postini.com; Wed, 04 Dec 2013 15:06:54 PST Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id DDB491B82D7; Wed, 4 Dec 2013 15:06:53 -0800 (PST) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id D7906190043; Wed, 4 Dec 2013 15:06:53 -0800 (PST) Received: from [10.0.10.40] (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 4 Dec 2013 15:06:53 -0800 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ted Lemon In-Reply-To: <290E20B455C66743BE178C5C84F1240847E510379A@EXMB01CMS.surrey.ac.uk> Date: Wed, 4 Dec 2013 18:06:51 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <5E0CD496-A3B2-430D-BE6D-119D633724D6@nominum.com> References: <290E20B455C66743BE178C5C84F1240847E5103799@EXMB01CMS.surrey.ac.uk>, <2C66A416-5F07-4803-A4C0-BB61734BA42E@nominum.com> <290E20B455C66743BE178C5C84F1240847E510379A@EXMB01CMS.surrey.ac.uk> To: "" X-Mailer: Apple Mail (2.1822) X-Originating-IP: [192.168.1.10] Cc: perpass , bruce@perens.com, ietf-http-wg@w3.org, IETF Discussion Subject: Re: [perpass] Commnets on draft-farrell-perpass-attack-00 was RE: 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 23:06:59 -0000 On Dec 4, 2013, at 5:55 PM, = wrote: > Where are these being discussed? It's a response to an IETF draft, = ergo ietf@ietf.org is entirely appropriate. That Perens doesn't submit = it as an internet-draft in response just suggests lack of political = nous. On the perpass mailing list. > Way to go on the selective quoting - I see you ignore the DRM point. = Sheesh, you can't even give a pointer to the refutations you apparently = cite. This too has been discussed. The point in the case of DRM is that = while DRM is indeed, as you say, eminently breakable, breaking it is = inconvenient. So putting DRM on everything increases costs for those = who want to see the plaintext of everything. > Don't you have anything substantial to say yourself, other than snarky = oneliners? I try not to repeat points that people smarter than I have already made, = but I do take your point that this discussion is sufficiently widely = splattered that nobody can possibly have followed every bit of it. From bruce@perens.com Wed Dec 4 15:09:13 2013 Return-Path: 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 CB9501AE2EA for ; Wed, 4 Dec 2013 15:09:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.177 X-Spam-Level: X-Spam-Status: No, score=-1.177 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, 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 ErQ6KLl60__M for ; Wed, 4 Dec 2013 15:09:13 -0800 (PST) Received: from alchemy.perens.com (alchemy.perens.com [206.221.219.26]) by ietfa.amsl.com (Postfix) with ESMTP id F10381AE2C2 for ; Wed, 4 Dec 2013 15:09:12 -0800 (PST) Received: from [192.168.18.131] (mail.a10networks.com [12.207.16.167]) by alchemy.perens.com (Postfix) with ESMTPSA id 03AD550008A; Wed, 4 Dec 2013 15:09:09 -0800 (PST) Message-ID: <529FB61A.7090604@perens.com> Date: Wed, 04 Dec 2013 15:09:14 -0800 From: Bruce Perens User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131103 Icedove/17.0.10 MIME-Version: 1.0 To: Jacob Appelbaum References: <529E8494.7000806@perens.com> <20131204111309.GB11727@nic.fr> <529F61D8.6030105@perens.com> <20131204171207.GC19914@thunk.org> <529F63C0.3040804@perens.com> <529F88AC.3090904@appelbaum.net> <529F90A0.8000706@perens.com> <529F9205.30906@appelbaum.net> <529F98C0.9090808@perens.com> <529F9F14.8050805@appelbaum.net> In-Reply-To: <529F9F14.8050805@appelbaum.net> Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: Stephane Bortzmeyer , perpass@ietf.org, Theodore Ts'o 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 23:09:14 -0000
On 12/04/2013 01:31 PM, Jacob Appelbaum wrote:
Could you please cite a single case where the illegal NSA spying programs have done that?
I don't know of any that you don't know of. I also don't believe they can ever tell us the full story, whether it's good or bad, because it would reveal operations and in some cases personnel.
I walked into Iraq in 2005 (as a journalist) and talked to people who had their entire family murdered by our war machine.
I never supported the Iraq war and it happened because so many were fooled by the Bush Administration. I strongly doubt that the Bush Administration did this because they had bad SIGINT.
We need to secure the DNS against tampering (DNSSEC)
Um. This has been in process for 14 years without success? And now you want _more_ encrypted protocols?
Currently, we lack both political and technical solutions to mass surveillance.
If there is any evidence that NSA is the slightest bit concerned about this, I've not seen it. I would guess that their technical capability is up to the task.

Political solutions have a chance of being effective.

    Thanks

    Bruce

From tytso@thunk.org Wed Dec 4 15:11:41 2013 Return-Path: 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 C78B81AE082; Wed, 4 Dec 2013 15:11:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.792 X-Spam-Level: X-Spam-Status: No, score=-1.792 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] 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 g-_JqUzP0Ebx; Wed, 4 Dec 2013 15:11:40 -0800 (PST) Received: from imap.thunk.org (imap.thunk.org [IPv6:2600:3c02::f03c:91ff:fe96:be03]) by ietfa.amsl.com (Postfix) with ESMTP id 24FF91AE006; Wed, 4 Dec 2013 15:11:40 -0800 (PST) Received: from root (helo=closure.thunk.org) by imap.thunk.org with local-esmtp (Exim 4.80) (envelope-from ) id 1VoLbS-0005Q7-Ge; Wed, 04 Dec 2013 23:11:34 +0000 Received: by closure.thunk.org (Postfix, from userid 15806) id A993158087B; Wed, 4 Dec 2013 18:11:33 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=thunk.org; s=mail; t=1386198693; bh=zGMdq7oU8twPNs3MAfR1Pz/QbXhmewh0a1sCQvpznP8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ygkQMZ+zFxecRrbrlnPQBZj4I33jJiSbAZuwaRM6gA3NnaU6rRq1ZNkJ8+kpu/a8S WL4UOup34f61g0ZCwbudyBFwtz7YYNgg57abNW9bQ9BMOH4GTssBiS/tdNZe2rphFG 6yN2iADEvlvcg/cy+GtifRsAHFifGmBIB+hkJRAc= Date: Wed, 4 Dec 2013 18:11:33 -0500 From: Theodore Ts'o To: Ted Lemon Message-ID: <20131204231133.GE19914@thunk.org> References: <290E20B455C66743BE178C5C84F1240847E5103799@EXMB01CMS.surrey.ac.uk> <2C66A416-5F07-4803-A4C0-BB61734BA42E@nominum.com> <290E20B455C66743BE178C5C84F1240847E510379A@EXMB01CMS.surrey.ac.uk> <5E0CD496-A3B2-430D-BE6D-119D633724D6@nominum.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5E0CD496-A3B2-430D-BE6D-119D633724D6@nominum.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: tytso@thunk.org X-SA-Exim-Scanned: No (on imap.thunk.org); SAEximRunCond expanded to false Cc: perpass , IETF Discussion , bruce@perens.com, "" , ietf-http-wg@w3.org Subject: Re: [perpass] Commnets on draft-farrell-perpass-attack-00 was RE: 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 23:11:42 -0000 On Wed, Dec 04, 2013 at 06:06:51PM -0500, Ted Lemon wrote: > > Don't you have anything substantial to say yourself, other than snarky oneliners? > > I try not to repeat points that people smarter than I have already > made, but I do take your point that this discussion is sufficiently > widely splattered that nobody can possibly have followed every bit > of it. After seeing Bruce accuse everyone who is trying to add encryption to prevent pervasive security to be a traitor, I decided that there was not much to be added by continuing to engage him in a discussion. I have full faith that the IESG, after the last call process, will give Bruce's comments all the weight that they deserve. Regards, - Ted From mellon@fugue.com Wed Dec 4 15:15:28 2013 Return-Path: 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 C384F1AE0F8 for ; Wed, 4 Dec 2013 15:15:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 FxDZVspCm_8X for ; Wed, 4 Dec 2013 15:15:26 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 83BD41AE006 for ; Wed, 4 Dec 2013 15:15:26 -0800 (PST) Received: from [10.0.10.40] (c-174-62-147-182.hsd1.nh.comcast.net [174.62.147.182]) by toccata.fugue.com (Postfix) with ESMTPSA id 4CB352380384; Wed, 4 Dec 2013 18:15:21 -0500 (EST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ted Lemon In-Reply-To: <529F61D8.6030105@perens.com> Date: Wed, 4 Dec 2013 18:15:20 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <170058A1-2D65-44E9-9319-47AD1F5D8202@fugue.com> References: <529E8494.7000806@perens.com> <20131204111309.GB11727@nic.fr> <529F61D8.6030105@perens.com> To: Bruce Perens X-Mailer: Apple Mail (2.1822) Cc: perpass , Stephane Bortzmeyer 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 23:15:29 -0000 On Dec 4, 2013, at 12:09 PM, Bruce Perens wrote: >> 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. > I'm sure it isn't. The point is just about unnecessary waste. I don't know if you missed this or just don't consider it important, but = essentially every video stream coming from a streaming video provider = that is streaming copyrighted entertainment is encrypted. The volume = of encrypted data traversing the internet in streams of this type vastly = outweighs the entirety of all traffic of the type that the IETF is = currently talking about encrypting for privacy reasons. From mellon@fugue.com Wed Dec 4 15:27:10 2013 Return-Path: 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 F2E481A1F7C for ; Wed, 4 Dec 2013 15:27:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 e89MCtR_uM_H for ; Wed, 4 Dec 2013 15:27:08 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 46A4E1A1F4A for ; Wed, 4 Dec 2013 15:27:08 -0800 (PST) Received: from [10.0.10.40] (c-174-62-147-182.hsd1.nh.comcast.net [174.62.147.182]) by toccata.fugue.com (Postfix) with ESMTPSA id D589D2380384; Wed, 4 Dec 2013 18:27:03 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ted Lemon In-Reply-To: <529F90A0.8000706@perens.com> Date: Wed, 4 Dec 2013 18:27:02 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <529E8494.7000806@perens.com> <20131204111309.GB11727@nic.fr> <529F61D8.6030105@perens.com> <20131204171207.GC19914@thunk.org> <529F63C0.3040804@perens.com> <529F88AC.3090904@appelbaum.net> <529F90A0.8000706@perens.com> To: Bruce Perens X-Mailer: Apple Mail (2.1822) Cc: Theodore Ts'o , perpass , Stephane Bortzmeyer , Jacob Appelbaum 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 23:27:10 -0000 On Dec 4, 2013, at 3:29 PM, Bruce Perens wrote: > Every society chooses its balance between freedom and enforcement. = Ours isn't the right balance today, agreed. But the proposals I see here = are the hacker approach - we're not patient to deal with this as a = political problem, so we'll change everyone's web browser. I think you're missing the point. The point is not that the NSA can = surveil you. The point is that _anyone_ can. The NSA is just who = most publicly did it recently. We know of a number of really = successful attacks that have actually been done, in the real world, by = law enforcement organizations, but that could be done as easily by a = criminal organization. The lesson here is not "okay, so let's stop law enforcement from = eavesdropping." It is "holy shit, we are really vulnerable." As to the question of encryption generally, nobody questions (I hope) = that we want our transactions with banks to be secure. I think it's = generally accepted that what videos we watch is private (there's a = federal law in the U.S. making it illegal for video stores to give out = that information). The Supreme Court recently decided that the FBI = couldn't put a GPS tracker on your car without a warrant. So at least = in the U.S., we are not navigating uncharted waters. Yes, we have a = problem with LEO spying. But as a country, we do recognize the need = for at least some communication to be confidential. And this is not a = legal understanding that is unique to the U.S. Canadian appellate = courts have held similarly, for example. So whether you think LEO spying is a good idea or not, there is clearly = a problem here with the protocols that we have deployed on the internet. = They make it too easy for _anybody_ to eavesdrop, and to use the = information they acquire whilst eavesdropping in really nefarious ways = (e.g. the watering hole attack someone referred to recently). And it = is entirely appropriate for the IETF to think very seriously about how = to make these protocols more secure. From hannes.tschofenig@gmx.net Wed Dec 4 15:31:37 2013 Return-Path: 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 EF30A1A1F7C for ; Wed, 4 Dec 2013 15:31:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.309 X-Spam-Level: X-Spam-Status: No, score=-0.309 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 hkumNQt7Lr1G for ; Wed, 4 Dec 2013 15:31:36 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id 6D5291ADED9 for ; Wed, 4 Dec 2013 15:31:36 -0800 (PST) Received: from [192.168.10.130] ([2.102.217.110]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0LqzIJ-1V9lxv08MV-00edgG for ; Thu, 05 Dec 2013 00:31:32 +0100 Message-ID: <529F7690.2050302@gmx.net> Date: Wed, 04 Dec 2013 18:38:08 +0000 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: l.wood@surrey.ac.uk, ted.lemon@nominum.com References: <290E20B455C66743BE178C5C84F1240847E5103799@EXMB01CMS.surrey.ac.uk>, <2C66A416-5F07-4803-A4C0-BB61734BA42E@nominum.com> <290E20B455C66743BE178C5C84F1240847E510379A@EXMB01CMS.surrey.ac.uk> In-Reply-To: <290E20B455C66743BE178C5C84F1240847E510379A@EXMB01CMS.surrey.ac.uk> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:e/pD7uSmBzEeW8ZAefOeYonzbbSsuE019q1yUNTjlIhpWt4WC5q OvMONAlIUBcL+hQjQJLzvZG0PCzUWAywJG0CWRGsch6UZeG36NPVLYLJS5V/XAEI/ZRxs87 J09tnDzbIXybWDzBLOLLFujGcwZRrqqqVlm8Waqc0ANowriKO/nOu5pKc/Ytuy988qS8Dav VaQR3L3ztlsR1GWcaqltw== Cc: perpass@ietf.org, ietf@ietf.org, bruce@perens.com, ietf-http-wg@w3.org Subject: Re: [perpass] Commnets on draft-farrell-perpass-attack-00 was RE: 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 23:31:38 -0000 Hi Lloyd, On 12/04/2013 10:55 PM, l.wood@surrey.ac.uk wrote: > I see you ignore the DRM point. I don't understand your DRM point to be honest. It also does not seem to be relevant to this conversation. DRM standards have not been been developed in the IETF either. draft-farrell-perpass-attack-00 does not specific solutions (which it states in the document). If your argument is that security adds complexity to protocols then that's certainly true. The other option would be not to have security in protocols at all to make them "more lightweight". Do you seriously think that this is useful option (even before the NSA revelations)? If your argument is that security problems on the Internet should be solved via legal / regulatory ways then please go ahead an make these proposals. Obviously, the IETF would be the wrong forum to do that. I am sure the European Commission, for example, is interested to listen to your proposals and will immediately issue new proposals for regulation. It would be great if those you think that there are regulatory solutions would in fact then work on those rather than just having technically minded people who push problems around. If your argument is aging cryptographic algorithms require software to be updated then let me tell you that software gets updated even for functionality reasons. Do you think that all the software updates you get for you smart phone apps are only security fixes? There are, however, many software updates that relate to security vulnerabilities. My approach would, however, be to incorporate software update mechanisms into products (which is what pretty everyone in the industry seems to be doing) instead. While this is largely a non-IETF issue it would still be interesting to hear whether you have other suggestions. Your suggestions to do more interoperability testing sounds reasonable to me. I have been involved in interoperability tests myself (and even organized a few). Those tend to have a different focus, namely to provide feedback about whether the implementations interpreted the specs correctly. Penetration testing is what you would typically do to discover security vulnerabilities. We typically don't do those (at least not that I have heard). As such, I would rather seen them as a orthogonal effort (which many in the IETF are involved in already anyway). Are you suggesting that we should also do penetration testing? Please also note that "security" is not a monolithic block, as you can see from RFC 3552. In various discussions with you I got the impression that you dislike security in general. That can hardly be true since I am sure you like some of the security features in there as well. For example, you might find authentication a pretty cool concept to avoid others accessing your email account. Ciao Hannes From bruce@perens.com Wed Dec 4 15:35:55 2013 Return-Path: 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 A95651ADED9 for ; Wed, 4 Dec 2013 15:35:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.577 X-Spam-Level: X-Spam-Status: No, score=-0.577 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, MIME_HTML_ONLY=0.723, 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 QDcCggpu8klI for ; Wed, 4 Dec 2013 15:35:55 -0800 (PST) Received: from alchemy.perens.com (alchemy.perens.com [206.221.219.26]) by ietfa.amsl.com (Postfix) with ESMTP id 1E1BE1AD9B8 for ; Wed, 4 Dec 2013 15:35:55 -0800 (PST) Received: from [192.168.18.131] (mail.a10networks.com [12.207.16.167]) by alchemy.perens.com (Postfix) with ESMTPSA id 1CA3050008A for ; Wed, 4 Dec 2013 15:35:52 -0800 (PST) Message-ID: <529FBC5C.60808@perens.com> Date: Wed, 04 Dec 2013 15:35:56 -0800 From: Bruce Perens User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131103 Icedove/17.0.10 MIME-Version: 1.0 To: perpass@ietf.org References: <290E20B455C66743BE178C5C84F1240847E5103799@EXMB01CMS.surrey.ac.uk> <2C66A416-5F07-4803-A4C0-BB61734BA42E@nominum.com> <290E20B455C66743BE178C5C84F1240847E510379A@EXMB01CMS.surrey.ac.uk> <5E0CD496-A3B2-430D-BE6D-119D633724D6@nominum.com> <20131204231133.GE19914@thunk.org> In-Reply-To: <20131204231133.GE19914@thunk.org> Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [perpass] Commnets on draft-farrell-perpass-attack-00 was RE: 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 23:35:55 -0000
On 12/04/2013 03:11 PM, Theodore Ts'o wrote:
After seeing Bruce accuse everyone who is trying to add encryption to prevent pervasive security to be a traitor
This is a completely unwarranted ad hominem, Ted. Nobody has been accused of being a traitor. I warned the group that they were at risk of getting in legal trouble wherever they are. That's my honest opinion.

    Bruce
From bruce@perens.com Wed Dec 4 15:35:59 2013 Return-Path: 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 A42271AE2DB for ; Wed, 4 Dec 2013 15:35:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.177 X-Spam-Level: X-Spam-Status: No, score=-1.177 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, 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 BpaPDYqiluDM for ; Wed, 4 Dec 2013 15:35:57 -0800 (PST) Received: from alchemy.perens.com (alchemy.perens.com [206.221.219.26]) by ietfa.amsl.com (Postfix) with ESMTP id BB9B81ADED9 for ; Wed, 4 Dec 2013 15:35:57 -0800 (PST) Received: from [192.168.18.131] (mail.a10networks.com [12.207.16.167]) by alchemy.perens.com (Postfix) with ESMTPSA id D05CB50008A; Wed, 4 Dec 2013 15:35:54 -0800 (PST) Message-ID: <529FBC5F.7050700@perens.com> Date: Wed, 04 Dec 2013 15:35:59 -0800 From: Bruce Perens User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131103 Icedove/17.0.10 MIME-Version: 1.0 To: Phillip Hallam-Baker References: <290E20B455C66743BE178C5C84F1240847E5103799@EXMB01CMS.surrey.ac.uk> <2C66A416-5F07-4803-A4C0-BB61734BA42E@nominum.com> <529FB216.7010504@perens.com> In-Reply-To: Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: perpass Subject: Re: [perpass] Commnets on draft-farrell-perpass-attack-00 was RE: 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 23:35:59 -0000
On 12/04/2013 02:57 PM, Phillip Hallam-Baker wrote:

When someone starts accusing everyone of treason it isn't so much refutation that is appropriate as the men in white coats.
Oh, come on Phillip. I did not accuse anyone, I said that it was arguably criminal or treasonous, and warned of the danger to you.

I work for law firms all day, bridging technology and law. I think

From bruce@perens.com Wed Dec 4 15:41:26 2013 Return-Path: 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 EF9281ADF59 for ; Wed, 4 Dec 2013 15:41:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.177 X-Spam-Level: X-Spam-Status: No, score=-1.177 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, 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 P_1rCyVw9kSb for ; Wed, 4 Dec 2013 15:41:25 -0800 (PST) Received: from alchemy.perens.com (alchemy.perens.com [206.221.219.26]) by ietfa.amsl.com (Postfix) with ESMTP id EBF231AD948 for ; Wed, 4 Dec 2013 15:41:24 -0800 (PST) Received: from [192.168.18.131] (mail.a10networks.com [12.207.16.167]) by alchemy.perens.com (Postfix) with ESMTPSA id 056CB50008A for ; Wed, 4 Dec 2013 15:41:22 -0800 (PST) Message-ID: <529FBDA6.9030100@perens.com> Date: Wed, 04 Dec 2013 15:41:26 -0800 From: Bruce Perens User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131103 Icedove/17.0.10 MIME-Version: 1.0 To: perpass@ietf.org References: <529E8494.7000806@perens.com> <20131204111309.GB11727@nic.fr> <529F61D8.6030105@perens.com> <20131204171207.GC19914@thunk.org> <529F63C0.3040804@perens.com> <529F88AC.3090904@appelbaum.net> <529F90A0.8000706@perens.com> In-Reply-To: Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 23:41:26 -0000
On 12/04/2013 03:27 PM, Ted Lemon wrote:
As to the question of encryption generally, nobody questions (I hope) that we want our transactions with banks to be secure.
And this is a solved problem except for the fact that they tend to get unencrypted laptops stolen with our data. Which we can't solve for them.
I think it's generally accepted that what videos we watch is private (there's a federal law in the U.S. making it illegal for video stores to give out that information).
They are private, and encrypted, but the encryption doesn't protect us. It only "protects" the video provider who believes that the whole internet will run away with their content if we are not forcibly restrained. If it works at all.

 They make it too easy for _anybody_ to eavesdrop, and to use the information they acquire whilst eavesdropping in really nefarious ways (e.g. the watering hole attack someone referred to recently).
So, build browsers that request https preferentially. Publish that as a recommendation. But please don't lock everyone into your solution.

    Thanks

    Bruce

From mnot@mnot.net Wed Dec 4 15:40:31 2013 Return-Path: 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 937C51ADF76; Wed, 4 Dec 2013 15:40:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-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 mfe9cFTf9FEL; Wed, 4 Dec 2013 15:40:29 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 30D411ADF59; Wed, 4 Dec 2013 15:40:29 -0800 (PST) Received: from [192.168.1.55] (unknown [118.209.134.50]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 6360550A88; Wed, 4 Dec 2013 18:40:19 -0500 (EST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Mark Nottingham In-Reply-To: <529F7690.2050302@gmx.net> Date: Thu, 5 Dec 2013 10:40:16 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <290E20B455C66743BE178C5C84F1240847E5103799@EXMB01CMS.surrey.ac.uk>, <2C66A416-5F07-4803-A4C0-BB61734BA42E@nominum.com> <290E20B455C66743BE178C5C84F1240847E510379A@EXMB01CMS.surrey.ac.uk> <529F7690.2050302@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1822) X-Mailman-Approved-At: Wed, 04 Dec 2013 15:41:59 -0800 Cc: IETF-Discussion Discussion , l.wood@surrey.ac.uk, perpass@ietf.org, Bruce Perens , HTTP Working Group , ted.lemon@nominum.com Subject: Re: [perpass] Commnets on draft-farrell-perpass-attack-00 was RE: 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 23:40:31 -0000 Hi, Can folks please stop cross-posting this to the HTTPbis WG? I'm sure = we'll become aware of any relevant outcome of the discussion, and = interested folks can join over on perpass. Thanks, On 5 Dec 2013, at 5:38 am, Hannes Tschofenig = wrote: > Hi Lloyd, >=20 > On 12/04/2013 10:55 PM, l.wood@surrey.ac.uk wrote: >> I see you ignore the DRM point. >=20 > I don't understand your DRM point to be honest. It also does not seem = to > be relevant to this conversation. DRM standards have not been been > developed in the IETF either. >=20 > draft-farrell-perpass-attack-00 does not specific solutions (which it > states in the document). >=20 > If your argument is that security adds complexity to protocols then > that's certainly true. The other option would be not to have security = in > protocols at all to make them "more lightweight". Do you seriously = think > that this is useful option (even before the NSA revelations)? >=20 > If your argument is that security problems on the Internet should be > solved via legal / regulatory ways then please go ahead an make these > proposals. Obviously, the IETF would be the wrong forum to do that. I = am > sure the European Commission, for example, is interested to listen to > your proposals and will immediately issue new proposals for = regulation. > It would be great if those you think that there are regulatory = solutions > would in fact then work on those rather than just having technically > minded people who push problems around. >=20 > If your argument is aging cryptographic algorithms require software to > be updated then let me tell you that software gets updated even for > functionality reasons. Do you think that all the software updates you > get for you smart phone apps are only security fixes? There are, > however, many software updates that relate to security = vulnerabilities. > My approach would, however, be to incorporate software update = mechanisms > into products (which is what pretty everyone in the industry seems to = be > doing) instead. While this is largely a non-IETF issue it would still = be > interesting to hear whether you have other suggestions. >=20 > Your suggestions to do more interoperability testing sounds reasonable > to me. I have been involved in interoperability tests myself (and even > organized a few). Those tend to have a different focus, namely to > provide feedback about whether the implementations interpreted the = specs > correctly. Penetration testing is what you would typically do to > discover security vulnerabilities. We typically don't do those (at = least > not that I have heard). As such, I would rather seen them as a > orthogonal effort (which many in the IETF are involved in already > anyway). Are you suggesting that we should also do penetration = testing? >=20 > Please also note that "security" is not a monolithic block, as you can > see from RFC 3552. In various discussions with you I got the = impression > that you dislike security in general. That can hardly be true since I = am > sure you like some of the security features in there as well. For > example, you might find authentication a pretty cool concept to avoid > others accessing your email account. >=20 > Ciao > Hannes >=20 -- Mark Nottingham http://www.mnot.net/ From bruce@perens.com Wed Dec 4 15:43:49 2013 Return-Path: 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 CA7C11AD9B8 for ; Wed, 4 Dec 2013 15:43:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.177 X-Spam-Level: X-Spam-Status: No, score=-1.177 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, 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 YZP-OK3YeqeJ for ; Wed, 4 Dec 2013 15:43:49 -0800 (PST) Received: from alchemy.perens.com (alchemy.perens.com [206.221.219.26]) by ietfa.amsl.com (Postfix) with ESMTP id 16C9B1AD948 for ; Wed, 4 Dec 2013 15:43:49 -0800 (PST) Received: from [192.168.18.131] (mail.a10networks.com [12.207.16.167]) by alchemy.perens.com (Postfix) with ESMTPSA id 2380050008A for ; Wed, 4 Dec 2013 15:43:46 -0800 (PST) Message-ID: <529FBE36.5090009@perens.com> Date: Wed, 04 Dec 2013 15:43:50 -0800 From: Bruce Perens User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131103 Icedove/17.0.10 MIME-Version: 1.0 To: perpass@ietf.org References: <290E20B455C66743BE178C5C84F1240847E5103799@EXMB01CMS.surrey.ac.uk> <2C66A416-5F07-4803-A4C0-BB61734BA42E@nominum.com> <529FB216.7010504@perens.com> <529FBC5F.7050700@perens.com> In-Reply-To: <529FBC5F.7050700@perens.com> Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [perpass] Commnets on draft-farrell-perpass-attack-00 was RE: 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 23:43:50 -0000
On 12/04/2013 03:35 PM, Bruce Perens wrote:
On 12/04/2013 02:57 PM, Phillip Hallam-Baker wrote:

When someone starts accusing everyone of treason it isn't so much refutation that is appropriate as the men in white coats.
Oh, come on Phillip. I did not accuse anyone, I said that it was arguably criminal or treasonous, and warned of the danger to you.

I work for law firms all day, bridging technology and law. I think
Sorry, incomlete sentence. Should be:

I think that some IETF participants, somewhere, and some browser implementors, somewhere, potentially have a legal problem. I would hate to see you treated the way some security experts have been treated. IMO you ignore that risk at your peril.

    Thanks

    Bruce

From jacob@appelbaum.net Wed Dec 4 15:51:31 2013 Return-Path: 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 957D51ADFBD for ; Wed, 4 Dec 2013 15:51:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.6 X-Spam-Level: X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FSL_HELO_BARE_IP_2=2, RCVD_IN_DNSWL_LOW=-0.7] 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 4oExC5bKjAkD for ; Wed, 4 Dec 2013 15:51:29 -0800 (PST) Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9A87C1ADF7F for ; Wed, 4 Dec 2013 15:51:29 -0800 (PST) Received: by mail-ea0-f172.google.com with SMTP id q10so10970577ead.31 for ; Wed, 04 Dec 2013 15:51:26 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:mime-version:to:cc:subject :references:in-reply-to:openpgp:content-type :content-transfer-encoding; bh=7rhWJCKGbsFj2J9hkUabtp3ckwKMQ1vlUAdNt6nQnto=; b=eCzQqsJOvfYFbIrQoObNnXdFrbUS2DrnpF1U8rEAIio1ZESsCEAAUEd1w5jWb/eVoy /uTUQqb1G7g7Kk3mt15sDQAe82X68P7SH7QqrhW2uyhty92jNlpgnmfpyEHF1yg5IsEf HUcjnBZOjK7bIJz0FT/9fAI1Ph4/HAF5XNknWWp41z4mvhL/GWxX4aGYM47btvBJd1Pz c+Dl/Wi0iiA58uS/XQ3N/2FU9F0Hzz5/xA9thXLQkGNPEzK/4/AXDp+gmpUhkx/XuAIB ekmUgbGvSZzbN2ZRV3ZD+8WGoLqdR+H3UZYslYDPYjK1O++OvjRb4CbGMzlMQGI+mh5+ 3+bQ== X-Gm-Message-State: ALoCoQmtZpvmLtdQ+uCvn1qnWCvu/Dcg8/CdCxz6LtLCjDKRB0ViMcQLHvQF90G5FxSUa+m0a4+r X-Received: by 10.15.44.4 with SMTP id y4mr9559200eev.71.1386201085931; Wed, 04 Dec 2013 15:51:25 -0800 (PST) Received: from 127.0.0.1 (spftor4e1.privacyfoundation.ch. [77.109.138.42]) by mx.google.com with ESMTPSA id a45sm99581274eem.6.2013.12.04.15.51.23 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Dec 2013 15:51:25 -0800 (PST) Message-ID: <529FBEF9.7030205@appelbaum.net> Date: Wed, 04 Dec 2013 23:47:05 +0000 From: Jacob Appelbaum MIME-Version: 1.0 To: Bruce Perens References: <529E8494.7000806@perens.com> <20131204111309.GB11727@nic.fr> <529F61D8.6030105@perens.com> <20131204171207.GC19914@thunk.org> <529F63C0.3040804@perens.com> <529F88AC.3090904@appelbaum.net> <529F90A0.8000706@perens.com> <529F9205.30906@appelbaum.net> <529F98C0.9090808@perens.com> <529F9F14.8050805@appelbaum.net> <529FB61A.7090604@perens.com> In-Reply-To: <529FB61A.7090604@perens.com> OpenPGP: id=4193A197 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: Stephane Bortzmeyer , perpass@ietf.org, Theodore Ts'o 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 23:51:31 -0000 Bruce Perens: > On 12/04/2013 01:31 PM, Jacob Appelbaum wrote: >> Could you please cite a single case where the illegal NSA spying programs have >> done that? > I don't know of any that you don't know of. I also don't believe they can ever > tell us the full story, whether it's good or bad, because it would reveal > operations and in some cases personnel. So basically, you were just blowing smoke? OK! >> I walked into Iraq in 2005 (as a journalist) and talked to people who had >> their entire family murdered by our war machine. > I never supported the Iraq war and it happened because so many were fooled by > the Bush Administration. I strongly doubt that the Bush Administration did this > because they had bad SIGINT. It happened because of similar arguments to those that you're making here, actually. >> We need to secure the DNS against tampering (DNSSEC) > Um. This has been in process for 14 years without success? And now you want > _more_ encrypted protocols? Good luck with a Man-On-The-Side attack on .se. domains that are properly configured. While DNSSEC has a lot of problems, it is an example of how to change the game, even if it is slow going. We've learned a lot too. >> Currently, we lack both political and technical solutions to mass surveillance. > If there is any evidence that NSA is the slightest bit concerned about this, > I've not seen it. I would guess that their technical capability is up to the task. > Huh? Did you totally miss my point, or what? > Political solutions have a chance of being effective. > What political solution do you envision exactly? I'm really curious to hear how you're going to defend your computer or from attackers with nation state capabilities (or less) with a political solution. It has so far failed for all of the nations subverted by the NSA surveillance. Ask Chancellor Merkel how that process worked out for her cell phone, eh? http://www.spiegel.de/international/world/merkel-calls-obama-over-suspicions-us-tapped-her-mobile-phone-a-929642.html Guess what she did after she tried the political solution? I believe she acquired some better hardware with meaningful crypto! All the best, Jacob From mellon@fugue.com Wed Dec 4 15:55:20 2013 Return-Path: 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 BA1E91ADDD3 for ; Wed, 4 Dec 2013 15:55:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 v_rG0g25mSZ7 for ; Wed, 4 Dec 2013 15:55:19 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 4A57B1ADFBD for ; Wed, 4 Dec 2013 15:55:19 -0800 (PST) Received: from [10.0.10.40] (c-174-62-147-182.hsd1.nh.comcast.net [174.62.147.182]) by toccata.fugue.com (Postfix) with ESMTPSA id 6DF512380384; Wed, 4 Dec 2013 18:55:15 -0500 (EST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ted Lemon In-Reply-To: <529FBDA6.9030100@perens.com> Date: Wed, 4 Dec 2013 18:55:13 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <529E8494.7000806@perens.com> <20131204111309.GB11727@nic.fr> <529F61D8.6030105@perens.com> <20131204171207.GC19914@thunk.org> <529F63C0.3040804@perens.com> <529F88AC.3090904@appelbaum.net> <529F90A0.8000706@perens.com> <529FBDA6.9030100@perens.com> To: Bruce Perens X-Mailer: Apple Mail (2.1822) Cc: perpass 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 23:55:20 -0000 On Dec 4, 2013, at 6:41 PM, Bruce Perens wrote: >> I think it's generally accepted that what videos we watch is private = (there's a federal law in the U.S. making it illegal for video stores to = give out that information). > They are private, and encrypted, but the encryption doesn't protect = us. It only "protects" the video provider who believes that the whole = internet will run away with their content if we are not forcibly = restrained. If it works at all. That's not my point. My point is that if you are worried about cycles = spent encrypting stuff, that's what you should be worried about, not the = relatively trivial percentage of cycles that would go to encrypt http. > So, build browsers that request https preferentially. Publish that as = a recommendation. But please don't lock everyone into your solution. The statements you've made thus far do not as far as I can tell provide = any logical basis as a consequence of which the IETF could sensibly = honor your request. For example, you haven't explained why you think = we should bowdlerize all our protocols to make sure that they are legal = in even the most repressive state. From jacob@appelbaum.net Wed Dec 4 15:56:40 2013 Return-Path: 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 9DAAA1AE177 for ; Wed, 4 Dec 2013 15:56:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.6 X-Spam-Level: X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FSL_HELO_BARE_IP_2=2, RCVD_IN_DNSWL_LOW=-0.7] 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 Pn1-s7HYfhBP for ; Wed, 4 Dec 2013 15:56:39 -0800 (PST) Received: from mail-ee0-f41.google.com (mail-ee0-f41.google.com [74.125.83.41]) by ietfa.amsl.com (Postfix) with ESMTP id 932131ADF28 for ; Wed, 4 Dec 2013 15:56:39 -0800 (PST) Received: by mail-ee0-f41.google.com with SMTP id t10so2832418eei.0 for ; Wed, 04 Dec 2013 15:56:36 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:mime-version:to:subject :references:in-reply-to:openpgp:content-type :content-transfer-encoding; bh=g2bErCWG3+XaRMNSnWkCq8Jf1TTSjFonv9qcVC44tA8=; b=SwmdIb7ff/ehwYnb7jPi/7gQ+9wYA773kIpLvRikTVCwMYHxZ1XKE/oHTZuuOAg1ob ATFbmsXrA8V8hvHl32dYRMyGEVaESpCb+9bxXmzPI81WpHlBIqL8nTgZAXHK1TJt+SOM 9MKXD1YPhF/FAMYt6N9qE/EwH0Y5tDMiDRiI7GXaUUU4+LQrTX16ZhuB/zamVQ19e0mp cx/YQ6HVEcrm7u4RO7WggbzERga+WiFf+45j5Dh6/ZEj46EDvxxQZVSfVDH4I3Y3EF1n cGN4ZlPAZOv6zOA0cID25vbOIpauMmmm0BZLfC29IPel87Xx/W3YM4rH56d1VYmHtXLm n2fg== X-Gm-Message-State: ALoCoQmr3OTj7tKzF708vWc8vCz8XzDxqJLOUpkH9aHBRNt58pBxk+Mi8Sk4VccUAm3S+zTfX1fX X-Received: by 10.14.219.4 with SMTP id l4mr9521946eep.94.1386201395968; Wed, 04 Dec 2013 15:56:35 -0800 (PST) Received: from 127.0.0.1 (spftor4e1.privacyfoundation.ch. [77.109.138.42]) by mx.google.com with ESMTPSA id e43sm88724144eep.7.2013.12.04.15.56.33 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Dec 2013 15:56:35 -0800 (PST) Message-ID: <529FC047.5000109@appelbaum.net> Date: Wed, 04 Dec 2013 23:52:39 +0000 From: Jacob Appelbaum MIME-Version: 1.0 To: perpass@ietf.org References: <290E20B455C66743BE178C5C84F1240847E5103799@EXMB01CMS.surrey.ac.uk> <2C66A416-5F07-4803-A4C0-BB61734BA42E@nominum.com> <529FB216.7010504@perens.com> <529FBC5F.7050700@perens.com> In-Reply-To: <529FBC5F.7050700@perens.com> OpenPGP: id=4193A197 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [perpass] Commnets on draft-farrell-perpass-attack-00 was RE: 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 23:56:40 -0000 Bruce Perens: > On 12/04/2013 02:57 PM, Phillip Hallam-Baker wrote: >> >> When someone starts accusing everyone of treason it isn't so much refutation >> that is appropriate as the men in white coats. > Oh, come on Phillip. I did not accuse anyone, I said that it was arguably > criminal or treasonous, and warned of the danger to you. It was very clearly implied and your general tone is so shitty, I had to read some headers to ensure you weren't being impersonated. I work on cryptographic software that does exactly what you suggest and we've been at it for ten years; your legal advice seems totally off base and frankly, unhelpful to those working on both political and technical solutions. Talk about FUD! > > I work for law firms all day, bridging technology and law. I think > Have you asked anyone at the EFF what they think of your legal opinions? I think they'd get a good laugh out of it and then they'd probably give you some reading material. Sincerely, Jacob From jacob@appelbaum.net Wed Dec 4 16:05:03 2013 Return-Path: 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 AED561AE1D7 for ; Wed, 4 Dec 2013 16:05:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.6 X-Spam-Level: X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FSL_HELO_BARE_IP_2=2, RCVD_IN_DNSWL_LOW=-0.7] 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 I9c65CP-Sim5 for ; Wed, 4 Dec 2013 16:05:02 -0800 (PST) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id 3222A1AE1CF for ; Wed, 4 Dec 2013 16:05:02 -0800 (PST) Received: by mail-wi0-f170.google.com with SMTP id hq4so118225wib.1 for ; Wed, 04 Dec 2013 16:04:58 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:mime-version:to:subject :references:in-reply-to:openpgp:content-type :content-transfer-encoding; bh=DK7pi6sJOH3jOhkYoXDykY0OshigEPw20CjI+PW4DyI=; b=h25kKdgWbGrwQ96IsfVRR+XTIAeRyKxMB7k/rhvrVvXwYc7Q2ihet1LDBqzL9ZlG+T dAgqDjnX/bzx8uED9Rf0VXr6n0stVKazeGMkTmcCqkcStyNtjZCNUEBuXvLRU/emUm8G GqOOn6tOr9mnotpvNy+nVWDZzPYmswb/PYWjrDj4HvM37Gs0vvAQa9+Nf30w5baGjB+w SgL5vLwbZAZN5/9/1ymAqNVfn9rW4vI6PVabXYEtoFV9ILvTWo4lTdu2tnMMStiWpopi xGvuN/+1EGalNQJ+HgJQYSVlR7DQ0NfdKrbjWN6FMRl2xGM/6ESh20MdfDnUD42mQD5D Z8jA== X-Gm-Message-State: ALoCoQk+Wbmoqfl9mEtckSYVL9gV8zkzcve5DFmpS/wM02wPQ3T09bYRFd0pY88YTYULqZr3wOYb X-Received: by 10.180.10.138 with SMTP id i10mr9570504wib.44.1386201898595; Wed, 04 Dec 2013 16:04:58 -0800 (PST) Received: from 127.0.0.1 (mozart.coqblin.net. [88.190.14.21]) by mx.google.com with ESMTPSA id f11sm863114wic.4.2013.12.04.16.04.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Dec 2013 16:04:57 -0800 (PST) Message-ID: <529FC231.4030308@appelbaum.net> Date: Thu, 05 Dec 2013 00:00:49 +0000 From: Jacob Appelbaum MIME-Version: 1.0 To: perpass@ietf.org References: <529E8494.7000806@perens.com> <20131204111309.GB11727@nic.fr> <529F61D8.6030105@perens.com> <20131204171207.GC19914@thunk.org> <529F63C0.3040804@perens.com> <529F88AC.3090904@appelbaum.net> <529F90A0.8000706@perens.com> <529FBDA6.9030100@perens.com> In-Reply-To: <529FBDA6.9030100@perens.com> OpenPGP: id=4193A197 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 00:05:03 -0000 Bruce Perens: > >> They make it too easy for _anybody_ to eavesdrop, and to use the information >> they acquire whilst eavesdropping in really nefarious ways (e.g. the watering >> hole attack someone referred to recently). > So, build browsers that request https preferentially. Publish that as a > recommendation. But please don't lock everyone into your solution. Wait, what? Please don't lock everyone into well understood vulnerabilities? Let us improve the protocols by opportunistically encrypting and when you think you have nothing to hide, you can opt-out, right? You have nothing to hide, right? Speaking of which, what is the content of your /etc/shadow Bruce? :) The attack surface of a browser is immense - the best way to protect against exploitation is to ensure that there is transport layer security. TLS (or something like it) helps us while we audit the image parsers, the javascript engines and it helps mitigate injection that would exploit vulnerable plugins; this is a very minimal amount of work to protect a lot of attack surface. At least then we're nearly back to watering hole attacks which requires, often, user interaction that is very detectable. I'd encourage you to read this: http://www.wired.com/opinion/2013/11/this-is-how-the-internet-backbone-has-been-turned-into-a-weapon/ Professor Weaver's article is very close to accurate. By the end of the month, I believe there will be much more clarity on the topic. This is a serious problem and it is internet wide. Sincerely, Jacob From bruce@perens.com Wed Dec 4 16:05:32 2013 Return-Path: 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 A582C1AE283 for ; Wed, 4 Dec 2013 16:05:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.177 X-Spam-Level: X-Spam-Status: No, score=-1.177 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, 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 NpKnRW-wIkHG for ; Wed, 4 Dec 2013 16:05:31 -0800 (PST) Received: from alchemy.perens.com (alchemy.perens.com [206.221.219.26]) by ietfa.amsl.com (Postfix) with ESMTP id 7BD481AE1DC for ; Wed, 4 Dec 2013 16:05:26 -0800 (PST) Received: from [192.168.18.131] (mail.a10networks.com [12.207.16.167]) by alchemy.perens.com (Postfix) with ESMTPSA id 8716350008A for ; Wed, 4 Dec 2013 16:05:23 -0800 (PST) Message-ID: <529FC347.3080806@perens.com> Date: Wed, 04 Dec 2013 16:05:27 -0800 From: Bruce Perens User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131103 Icedove/17.0.10 MIME-Version: 1.0 To: perpass@ietf.org References: <529E8494.7000806@perens.com> <20131204111309.GB11727@nic.fr> <529F61D8.6030105@perens.com> <20131204171207.GC19914@thunk.org> <529F63C0.3040804@perens.com> <529F88AC.3090904@appelbaum.net> <529F90A0.8000706@perens.com> <529F9205.30906@appelbaum.net> <529F98C0.9090808@perens.com> <529F9F14.8050805@appelbaum.net> <529FB61A.7090604@perens.com> <529FBEF9.7030205@appelbaum.net> In-Reply-To: <529FBEF9.7030205@appelbaum.net> Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 00:05:32 -0000
On 12/04/2013 03:47 PM, Jacob Appelbaum wrote:
So basically, you were just blowing smoke?
No. The organization is charged to protect us. However poorly or well it's actually working, and I assume that I do not have the whole story either way. They need reform, sure. Not elimination.

Throwing deliberate hurdles in their way is like spreading nails in the path of a police car. Cops have more than enough abuses, but most people accept that they do good stuff too, and nobody sensible suggests getting rid of them.
Good luck with a Man-On-The-Side attack on .se. domains that are properly configured.
OK. But I'm horrified that .se is the best demo you can cite.
What political solution do you envision exactly?
Given the choice, I would roll increases in executive authority related to the pursuit of war or espionage back to what we had before the PATRIOT act. This is something we can state in one sentence and that makes sense. IMO it is a workable campaign and one you should join.
 I'm really curious to
hear how you're going to defend your computer or from attackers with
nation state capabilities (or less) with a political solution.
How else can I defend my computer? I do not decieve myself that they are stopped by any technical measure that you or I are capable of. They can break down the door and water-board me if they want to. I am completely helpless before them except for what I can achieve politically.

    Thanks

    Bruce
From bruce@perens.com Wed Dec 4 16:14:02 2013 Return-Path: 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 A18E01AE113 for ; Wed, 4 Dec 2013 16:14:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.177 X-Spam-Level: X-Spam-Status: No, score=-1.177 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, 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 4_cjJXhHbSXE for ; Wed, 4 Dec 2013 16:14:02 -0800 (PST) Received: from alchemy.perens.com (alchemy.perens.com [206.221.219.26]) by ietfa.amsl.com (Postfix) with ESMTP id 061A61ADFB9 for ; Wed, 4 Dec 2013 16:14:02 -0800 (PST) Received: from [192.168.18.131] (mail.a10networks.com [12.207.16.167]) by alchemy.perens.com (Postfix) with ESMTPSA id EC5EC50008A for ; Wed, 4 Dec 2013 16:13:58 -0800 (PST) Message-ID: <529FC54A.7050209@perens.com> Date: Wed, 04 Dec 2013 16:14:02 -0800 From: Bruce Perens User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131103 Icedove/17.0.10 MIME-Version: 1.0 To: perpass@ietf.org References: <290E20B455C66743BE178C5C84F1240847E5103799@EXMB01CMS.surrey.ac.uk> <2C66A416-5F07-4803-A4C0-BB61734BA42E@nominum.com> <529FB216.7010504@perens.com> <529FBC5F.7050700@perens.com> <529FC047.5000109@appelbaum.net> In-Reply-To: <529FC047.5000109@appelbaum.net> Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [perpass] Commnets on draft-farrell-perpass-attack-00 was RE: 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 00:14:02 -0000
On 12/04/2013 03:52 PM, Jacob Appelbaum wrote:
It was very clearly implied and your general tone is so shitty, I had to read some headers to ensure you weren't being impersonated.
Well, you are reading me wrong. Please stop now.
Have you asked anyone at the EFF what they think of your legal opinions?
I have been in the position of stating my intention to violate national law and having EFF advise me to stop for my own safety. It was a DMCA issue. EFF does not advise you to put your own head on the block.

It's not what your software does, Jacob. It is the fact that folks here clearly and publicly presented this as not just a way to stop some random bad actor, but a way to stop NSA. For many of them, a branch of their own government's defense department. And I just told them they were ill-advised!

    Thanks

    Bruce
From bruce@perens.com Wed Dec 4 16:16:35 2013 Return-Path: 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 20AFA1AE17D for ; Wed, 4 Dec 2013 16:16:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.177 X-Spam-Level: X-Spam-Status: No, score=-1.177 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, 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 yvxacxJW2lrO for ; Wed, 4 Dec 2013 16:16:34 -0800 (PST) Received: from alchemy.perens.com (alchemy.perens.com [206.221.219.26]) by ietfa.amsl.com (Postfix) with ESMTP id 67ACD1AE177 for ; Wed, 4 Dec 2013 16:16:34 -0800 (PST) Received: from [192.168.18.131] (mail.a10networks.com [12.207.16.167]) by alchemy.perens.com (Postfix) with ESMTPSA id 6AF3F50008A; Wed, 4 Dec 2013 16:16:31 -0800 (PST) Message-ID: <529FC5E3.6090008@perens.com> Date: Wed, 04 Dec 2013 16:16:35 -0800 From: Bruce Perens User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131103 Icedove/17.0.10 MIME-Version: 1.0 To: Ted Lemon References: <529E8494.7000806@perens.com> <20131204111309.GB11727@nic.fr> <529F61D8.6030105@perens.com> <20131204171207.GC19914@thunk.org> <529F63C0.3040804@perens.com> <529F88AC.3090904@appelbaum.net> <529F90A0.8000706@perens.com> <529FBDA6.9030100@perens.com> In-Reply-To: Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: perpass 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 00:16:35 -0000
On 12/04/2013 03:55 PM, Ted Lemon wrote:
The statements you've made thus far do not as far as I can tell provide any logical basis as a consequence of which the IETF could sensibly honor your request. For example, you haven't explained why you think we should bowdlerize all our protocols to make sure that they are legal in even the most repressive state.
I'm not sure that's even possible. But legality was not the only reason I put forward. I am not in particular an NSA booster. My main concerns are that this will harm the operation of the Internet and take away user choice.

    Thanks

    Bruce

From stpeter@stpeter.im Wed Dec 4 16:18:33 2013 Return-Path: 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 34F3B1AE195 for ; Wed, 4 Dec 2013 16:18:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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 1Mfn-T-Dvboy for ; Wed, 4 Dec 2013 16:18:31 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id E66871AE177 for ; Wed, 4 Dec 2013 16:18:30 -0800 (PST) Received: from sjc-vpn2-300.cisco.com (unknown [128.107.239.235]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 24B0140332; Wed, 4 Dec 2013 17:18:26 -0700 (MST) Message-ID: <529FC651.1070909@stpeter.im> Date: Wed, 04 Dec 2013 17:18:25 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: perpass X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [perpass] administrative request 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 00:18:33 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 It strikes me that the current discussion, although interesting in its own way, has a low signal-to-noise ratio. Perhaps the list admins could suggest a one-day cooling-off period or some such? Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSn8ZQAAoJEOoGpJErxa2p00gQAJ/Q9dXkksddLZyDmYBjV7Vd Tp1fn6ZAxDoY+cym44D6e88UXbK4YhmhgcGlpTr7+NJK+fANT8vmciYlFzoWR2Sn n40aPzKod20OUaMLZTnPCIBsBtUKgMa3nXkuCGd8f2P90apU9DtPhO/rtnxthNcL 8NqgHYloA5g2qFMKzo1etxTFogZrtyY9v6TC7FK3YGnmK9yEY4uMh44C+A9mTWQq n1IbA5w2P7z0RWUu4Ta1mFuM+H9EaJucXydVlXFCSyYBgRRx54fvEAFVpZi0k/yo DpNsWU75sU3zwiRtxxor1RC/sbVDuupKYDf4xQSF7MVlociG2m3T0+EUX9HL++lt ZVxJvbnzB9qQ6CLJuFcXFnhGISXJzjbsJ07pPfzdMR7ralj/ttzsFIQrTPnrEOlt T1iYzyH6oIWyKQvqrN6Q+V/9k6TLQdsjpmxjn6bkKhLpFE8marmrlg9TO+kvIAjC ibBax8aNTDYkybjyRx7eiqAxUaM1X4bKWQHXHCr2JqhtMLpwfbIzFGPNRvb7Yeb7 95DH78Pq9oZdHf7Sqkiup8zCM248CUL9YzQwSJP+O8hGsT64lN/Y63tkvqW7YXgX tX/QBcDuTpO3Q0V1kxoDV5Oq+MTSHDKPC/SgJH6MhX25X9APNfMQwj3agtxmyssO i+eahDY4R3Ldi2Kcp7Gs =fgvC -----END PGP SIGNATURE----- From mellon@fugue.com Wed Dec 4 16:21:50 2013 Return-Path: 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 38B511AE1A9 for ; Wed, 4 Dec 2013 16:21:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 17MQDbfPSM8n for ; Wed, 4 Dec 2013 16:21:47 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 59AF41AE16F for ; Wed, 4 Dec 2013 16:21:47 -0800 (PST) Received: from [10.0.10.40] (c-174-62-147-182.hsd1.nh.comcast.net [174.62.147.182]) by toccata.fugue.com (Postfix) with ESMTPSA id 9FFDD2380384; Wed, 4 Dec 2013 19:21:43 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ted Lemon In-Reply-To: <529FC5E3.6090008@perens.com> Date: Wed, 4 Dec 2013 19:21:41 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <09EFA47D-6A4B-4BA7-9FC5-A564C11CA3FA@fugue.com> References: <529E8494.7000806@perens.com> <20131204111309.GB11727@nic.fr> <529F61D8.6030105@perens.com> <20131204171207.GC19914@thunk.org> <529F63C0.3040804@perens.com> <529F88AC.3090904@appelbaum.net> <529F90A0.8000706@perens.com> <529FBDA6.9030100@perens.com> <529FC5E3.6090008@perens.com> To: Bruce Perens X-Mailer: Apple Mail (2.1822) Cc: perpass 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 00:21:50 -0000 On Dec 4, 2013, at 7:16 PM, Bruce Perens wrote: > My main concerns are that this will harm the operation of the Internet = and take away user choice. Okay, there are two very definite statements. You should be able to = give examples. If your example for user choice is "a person in a country with a = repressive government will not have choice," that's not good enough, = because they already lack choice due to their government=97it's not = something we have the power to do anything about. If your example for "harm the operation of the internet" is transparent = caching, that point has been answered: define a protocol for caching = that is not transparent, and allow the incentive structure around end = users who benefit from that caching to motivate them to use it, rather = than simply forcing them to use it in their own best interest. Indeed, this precisely addresses the needs of users in the first case, = since their government can simply require them to go through the = non-transparent cache. They will know they are being watched, the = government will be able to watch them, and they will be able to access = any content they feel safe accessing in the awareness that they are = being watched as they do so. Everybody wins, for some value of "win." From jacob@appelbaum.net Wed Dec 4 16:31:23 2013 Return-Path: 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 86D4B1AE195 for ; Wed, 4 Dec 2013 16:31:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.6 X-Spam-Level: X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FSL_HELO_BARE_IP_2=2, RCVD_IN_DNSWL_LOW=-0.7] 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 78Hbr1tASvhY for ; Wed, 4 Dec 2013 16:31:21 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 843131AE1A2 for ; Wed, 4 Dec 2013 16:31:21 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id z5so9884699lbh.31 for ; Wed, 04 Dec 2013 16:31:17 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:mime-version:to:cc:subject :references:in-reply-to:openpgp:content-type :content-transfer-encoding; bh=vcoJJAvtBkQj88/yHiQ21jg1B1uQ2ogA+Qge6ZKdYYM=; b=hdLqJQpbcEuKEAuJa/NwA3HcsRwUcn0RmGS7DEuAiNHc7PbeGvetoab5m/IT8sQ+u8 KgCMMZO6NU2++vXKBi5x1VcEU/3gSpj8WivAb27yfiBkovvwGqEPmpSJg2xUhxVdvzyy 4hJ0/CQAzmTFPq8/VVqKYlpRKtfTdKTFOrLcoPzLiMUp/znQM30vH7Ze6iihE0U3VRrv j7fw4E3PHhQ7LbH7SYscKMABbJdOH6YRz9pBZCbpjNWCvMhGO/2GZJ/HVHP553LlqZqO KYb0g5Q9vPuArA4t6LmbdCaz1FHVxiVF3/tuoUZ5873BYmzxBdsROvge9rWXV0uS0QVj FbKQ== X-Gm-Message-State: ALoCoQlRLZeWD4/3rokQ2CV+aHUFeEzCZ5/JSKns8ae7IVMZWFOaOPJkssV++PjJxtZ6DbYwbLSX X-Received: by 10.152.36.101 with SMTP id p5mr18674laj.67.1386203477435; Wed, 04 Dec 2013 16:31:17 -0800 (PST) Received: from 127.0.0.1 (tor-exit0-readme.dfri.se. [171.25.193.20]) by mx.google.com with ESMTPSA id e10sm103336425laa.6.2013.12.04.16.31.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Dec 2013 16:31:16 -0800 (PST) Message-ID: <529FC942.9050400@appelbaum.net> Date: Thu, 05 Dec 2013 00:30:58 +0000 From: Jacob Appelbaum MIME-Version: 1.0 To: Bruce Perens References: <529E8494.7000806@perens.com> <20131204111309.GB11727@nic.fr> <529F61D8.6030105@perens.com> <20131204171207.GC19914@thunk.org> <529F63C0.3040804@perens.com> <529F88AC.3090904@appelbaum.net> <529F90A0.8000706@perens.com> <529F9205.30906@appelbaum.net> <529F98C0.9090808@perens.com> <529F9F14.8050805@appelbaum.net> <529FB61A.7090604@perens.com> <529FBEF9.7030205@appelbaum.net> <529FC347.3080806@perens.com> In-Reply-To: <529FC347.3080806@perens.com> OpenPGP: id=4193A197 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 00:31:23 -0000 Bruce Perens: > On 12/04/2013 03:47 PM, Jacob Appelbaum wrote: >> So basically, you were just blowing smoke? > No. The organization is charged to protect us. Us? Are you including the Dutch, German, Brazilian, Canadian, British and Swedes on the list? Or just 'us' Americans? It sounds to me like you're blowing smoke - specifically because they aren't actually protecting us in the ways that they assert. Global domination through criminal activity that results in hegemony? Sounds solidly protectionist but not in a way where we've consented! > However poorly or well it's > actually working, and I assume that I do not have the whole story either way. > They need reform, sure. Not elimination. Ah, I see, you think we need spies outside the rule of law - that pretty much sums up the problem. We either have the rule of law or we have this - that is how we found ourselves here. The fact that you're not entitled to know the whole story should tip you off that you might not want to give them the benefit of the doubt regarding reform. What is technically possible is effectively shown to be inevitable when the economics line up for the NSA and friends. Eliminate the NSA, they're (mass) criminals; the DNI lies to Congress. The NSA gives full feeds of their spying data to other nations. The examples are as boundless as BOUNDLESSINFORMANT and beyond. To boot they're hurting average Americans who write software. The taint of the NSA is like the Chinese state security all over Huawei gear. I think it is sadly deserved for many companies and their products. > > Throwing deliberate hurdles in their way is like spreading nails in the path of > a police car. Cops have more than enough abuses, but most people accept that > they do good stuff too, and nobody sensible suggests getting rid of them. I see that in your spare time, you're also a straw man factory; could you knock it off Bruce? It is surprisingly annoying and a total derailment. But while we're making funny jokes, I'll see you and raise you a muppet video: https://www.youtube.com/watch?v=CjMLZuuXDRQ Perhaps the discourse might be improved by not muddling intelligence services and police? ;-) >> Good luck with a Man-On-The-Side attack on .se. domains that are properly configured. > OK. But I'm horrified that .se is the best demo you can cite. DNSSEC has issues - a lack of query privacy for example - but what do you want? A full list of every DNSSEC enabled domain where someone has to steal keys to begin to perform such an attack? Here is some code by the way to implement QI: http://github.com/stealth/QI >> What political solution do you envision exactly? > Given the choice, I would roll increases in executive authority related to the > pursuit of war or espionage back to what we had before the PATRIOT act. This is > something we can state in one sentence and that makes sense. IMO it is a > workable campaign and one you should join. How do you propose that this will ensure we won't return here? And how will your political successes impact your safety when it is another government taking these actions? >> I'm really curious to >> hear how you're going to defend your computer or from attackers with >> nation state capabilities (or less) with a political solution. > How else can I defend my computer? I do not decieve myself that they are stopped > by any technical measure that you or I are capable of. They can break down the > door and water-board me if they want to. I am completely helpless before them > except for what I can achieve politically. Ah, I see. You're seriously wrong and pretty much provably so! The documents released by Snowden clearly state it - as an example in the Guardian Tor story, they specifically said that they can't deanonymize everyone all the time - it forces them to target and to target for memory corruption related exploitation specifically: http://www.theguardian.com/world/2013/oct/04/nsa-gchq-attack-tor-network-encryption http://www.theguardian.com/world/2013/oct/04/tor-attacks-nsa-users-online-anonymity http://www.theguardian.com/world/interactive/2013/oct/04/tor-stinks-nsa-presentation-document http://www.theguardian.com/world/interactive/2013/oct/04/tor-high-secure-internet-anonymity Technical counter measures causes NSA dragnet surveillance to fail and it reduces them to specific targeting of individuals. If you are targeted, as I am no doubt targeted, you're right - you're probably not up for the task. Seriously though - I would encourage you not to mistake your inability with a general inability. I have computers where the NSA would be foolish to touch them because the moment that they do, I'll drop their technique, their payloads and everything related on the front page of a major news paper. A political and a technical solution all in one, as it should be, I might add. Properly implemented cryptography works wonders and it will help reduce a lot of suffering if we deploy it widely. I'm not sure why you refuse to acknowledge this fact. All the best, Jacob From jacob@appelbaum.net Wed Dec 4 16:37:48 2013 Return-Path: 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 BD58D1AE1D1 for ; Wed, 4 Dec 2013 16:37:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.6 X-Spam-Level: X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FSL_HELO_BARE_IP_2=2, RCVD_IN_DNSWL_LOW=-0.7] 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 mBfM28R9-m8o for ; Wed, 4 Dec 2013 16:37:47 -0800 (PST) Received: from mail-la0-f52.google.com (mail-la0-f52.google.com [209.85.215.52]) by ietfa.amsl.com (Postfix) with ESMTP id 446191ADFD4 for ; Wed, 4 Dec 2013 16:37:47 -0800 (PST) Received: by mail-la0-f52.google.com with SMTP id y1so8290542lam.11 for ; Wed, 04 Dec 2013 16:37:43 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:mime-version:to:subject :references:in-reply-to:openpgp:content-type :content-transfer-encoding; bh=p9C0l/cbaFoEndKj4KhA0fHzq/s5tGRli4HtXhqJxEY=; b=KrQAxCooCdxwGDanmbhiu3Vum/LPBRAAzBF9YnVlGVLoixyjTzU7wlNFaxjAoRfNMH MwKic+H1rDkx/LW3hdeYN6wjwdue5KkiAlV8aGKHRs7u3Tb34/7dfTU3qtCjltdAegsr TsW35Kev/rsGfDwVvk5/pUZent1VD4Z2YPbKtm7QjEPjde4xtq72kgDvnQC8SjOb7/jv vHzpJ9fijaHxTXPqNk+ZYk/0oeHZYruXhMr9/cXZ7lD3V/ixbtTMrbMgCkrSkQZyZMyv ok3wY2e/G87PrgQHELe9aYizUwusCmqbYf2E76AxrPRe6axwA8YgdIg1dQVprvHwLCdy 5dow== X-Gm-Message-State: ALoCoQm7CnysN9pR+LkS+mO4e5HjFYV0q+Tsm7f9K/fmCtlCKDnNPz9bsHBf40U+Uk8JxrG1/nKA X-Received: by 10.112.199.225 with SMTP id jn1mr1540151lbc.49.1386203863280; Wed, 04 Dec 2013 16:37:43 -0800 (PST) Received: from 127.0.0.1 (tor-exit0-readme.dfri.se. [171.25.193.20]) by mx.google.com with ESMTPSA id tc8sm13859466lbb.9.2013.12.04.16.37.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Dec 2013 16:37:41 -0800 (PST) Message-ID: <529FCACD.6040206@appelbaum.net> Date: Thu, 05 Dec 2013 00:37:33 +0000 From: Jacob Appelbaum MIME-Version: 1.0 To: perpass@ietf.org References: <290E20B455C66743BE178C5C84F1240847E5103799@EXMB01CMS.surrey.ac.uk> <2C66A416-5F07-4803-A4C0-BB61734BA42E@nominum.com> <529FB216.7010504@perens.com> <529FBC5F.7050700@perens.com> <529FC047.5000109@appelbaum.net> <529FC54A.7050209@perens.com> In-Reply-To: <529FC54A.7050209@perens.com> OpenPGP: id=4193A197 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [perpass] Commnets on draft-farrell-perpass-attack-00 was RE: 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 00:37:48 -0000 Bruce Perens: > On 12/04/2013 03:52 PM, Jacob Appelbaum wrote: >> It was very clearly implied and your general tone is so shitty, I had to read >> some headers to ensure you weren't being impersonated. > Well, you are reading me wrong. Please stop now. I'm not clear that I am reading you incorrectly. >> Have you asked anyone at the EFF what they think of your legal opinions? > I have been in the position of stating my intention to violate national law and > having EFF advise me to stop for my own safety. It was a DMCA issue. EFF does > not advise you to put your own head on the block. Ill advised again: https://www.eff.org/nsa-spying So really, ask some folks at the EFF about your legal views here? They literally advise people to use Tor to defend against what they view as illegal state surveillance by the NSA: https://ssd.eff.org/foreign/summing-up > > It's not what your software does, Jacob. It is the fact that folks here clearly > and publicly presented this as not just a way to stop some random bad actor, but > a way to stop NSA. For many of them, a branch of their own government's defense > department. And I just told them they were ill-advised! The very same department that is not legally allowed to spy on those Americans, I might add. We're probably going to have to agree to disagree at this point. I'd be happy to buy you a drink to discuss this in person - if you happen to be attending the CCC 30c3 in Hamburg, I think it would make for a great discussion. All the best, Jacob From hallam@gmail.com Wed Dec 4 20:04:05 2013 Return-Path: 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 C52E51AE192 for ; Wed, 4 Dec 2013 20:04:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 ZjgUQl1Z2AJh for ; Wed, 4 Dec 2013 20:04:03 -0800 (PST) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 3040A1AE031 for ; Wed, 4 Dec 2013 20:04:02 -0800 (PST) Received: by mail-we0-f177.google.com with SMTP id u56so232287wes.8 for ; Wed, 04 Dec 2013 20:03:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NI0a7wfGHvFA3WPxh4wH7FLyTZaFTCjBTDbnYaJUDDw=; b=rlIKp/DqtNY4cTPdoUNdJkGFrFtigN9EM41U63mytVhbMAKixRj3trAZ7DNzHlBYqy 63Ty+iIuSrgPbeWk/I0EHeHDMAco9f70DwVGw5BTTmFT9Rm0dzxjGonmpGOiQT7Nk2ep bfuHZOpqZc2AYZlDIfmq7lLkBn/0HktcYN64yFg1z35jOctGsryomDKop3dI5wuBIMLZ V83GeJLPRDHmRh+0ZH6Np4rxxkrVtu39lRiZ5rAi5F8Q1ks23j6K+ngrv+DzpcJqvTWB XY7jZdY02BueVrlZrHXF5O+Sqrbrct+sHF7MCoyBB4W6VkNRpd9/L26JODg3QGwn5iIk tFSw== MIME-Version: 1.0 X-Received: by 10.180.79.163 with SMTP id k3mr10018998wix.34.1386216239509; Wed, 04 Dec 2013 20:03:59 -0800 (PST) Received: by 10.194.243.136 with HTTP; Wed, 4 Dec 2013 20:03:59 -0800 (PST) In-Reply-To: <529FBC5F.7050700@perens.com> References: <290E20B455C66743BE178C5C84F1240847E5103799@EXMB01CMS.surrey.ac.uk> <2C66A416-5F07-4803-A4C0-BB61734BA42E@nominum.com> <529FB216.7010504@perens.com> <529FBC5F.7050700@perens.com> Date: Wed, 4 Dec 2013 23:03:59 -0500 Message-ID: From: Phillip Hallam-Baker To: Bruce Perens Content-Type: multipart/alternative; boundary=f46d043d655789ba7404ecc19e6d Cc: perpass Subject: Re: [perpass] Commnets on draft-farrell-perpass-attack-00 was RE: 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 04:04:05 -0000 --f46d043d655789ba7404ecc19e6d Content-Type: text/plain; charset=ISO-8859-1 On Wed, Dec 4, 2013 at 6:35 PM, Bruce Perens wrote: > On 12/04/2013 02:57 PM, Phillip Hallam-Baker wrote: > > > When someone starts accusing everyone of treason it isn't so much > refutation that is appropriate as the men in white coats. > > Oh, come on Phillip. I did not accuse anyone, I said that it was arguably > criminal or treasonous, and warned of the danger to you. > It seemed like more of a threat to me. The NSA is very aware of the work that I am doing and its purpose. I presented the work at MIT the week before Vancouver with several current NSA employees present and a former NSA director. One thing we know the NSA is going to need is usable data level security. The only thing that differentiates my proposal from previous ones is that (1) it requires exactly the same degree of effort as regular mail, (2) it does not depend on building out infrastructure before deployment and (3) it supports a policy layer so that in addition to discovering the recipient's key, an application can determine the security policy of the recipient. In other words, what differentiates my proposal is that it has a chance of keeping Britain, American and their allies safe against the attacks that are now going to be coming from all the other governments that are now going to be playing copycat in the wake of Snowdonia. The NSA is charged with two missions, not one. Protecting the US and its allies from attack is far more important than attacking other countries. The US has an electricity infrastructure that would embarrass many third world countries, it has been defeated by squirrels let alone cyber-attacks. Cyberwarfare has many of the same characteristics as terrorism. the barriers to entry are low. It is inherently non-attributable and so deterrence is infeasible. Any attempt to set red lines opens up the risk of a false flag attack. And what might shock you is that people who have spent their lives studying war had to have that pointed out by me. Cyber is inherently destabilizing. And the risk is not just of a cyber attack against the US and its allies. An attack against Russia or China could lead to catastrophic consequences as well. Neither has the capacity to develop an effective cyber defense in their critical infrastructure unless the western powers develop the technology first. One of the ugly costs of relying on industrial espionage is that it destroys any chance of developing an indigenous research capacity. The issues are vastly more complex than you imagine. NSA 1.0 spent its time cracking mechanical ciphers to enable the CIA coups that stopped when the world moved to digital in the mid 70s. NSA 2.0 grew large fat and lazy while its military management spent their time boosting each other's egos with (unsecured) Powerpoint presentations that almost certainly exaggerate their capabilities. We don't know what NSA 3.0 is going to be doing but it isn't going to have anything like the intercept capabilities of the past and it will be two congresses before they have any ability to shape the political landscape again. -- Website: http://hallambaker.com/ --f46d043d655789ba7404ecc19e6d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Wed, Dec 4, 2013 at 6:35 PM, Bruce Perens <bruce@perens.com><= /span> wrote:
=20 =20 =20 =20
On 12/04/2013 02:57 PM, Phillip Hallam-Baker wrote:

When someone starts accusing everyone of treason it isn't so much refutation that is appropriate as the men i= n white coats.
Oh, come on Phillip. I did not accuse anyone, I said that it was arguably criminal or treasonous, and warned of the danger to you.

It seemed like more of a threat to me.=

The NSA is very aware of the work that I am doing= and its purpose. I presented the work at MIT the week before Vancouver wit= h several current NSA employees present and a former NSA director.

One thing we know the NSA is going to need is usable da= ta level security. The only thing that differentiates my proposal from prev= ious ones is that (1) it requires exactly the same degree of effort as regu= lar mail, (2) it does not depend on building out infrastructure before depl= oyment and (3) it supports a policy layer so that in addition to discoverin= g the recipient's key, an application can determine the security policy= of the recipient.

In other words, what differentiates my proposa= l is that it has a chance of keeping Britain, American and their allies saf= e against the attacks that are now going to be coming from all the other go= vernments that are now going to be playing copycat in the wake of Snowdonia= .


The NSA is charged with two missions, no= t one. Protecting the US and its allies from attack is far more important t= han attacking other countries. The US has an electricity infrastructure tha= t would embarrass many third world countries, it has been defeated by squir= rels let alone cyber-attacks.

Cyberwarfare has many of the same characteristics as te= rrorism. the barriers to entry are low. It is inherently non-attributable a= nd so deterrence is infeasible. Any attempt to set red lines opens up the r= isk of a false flag attack. And what might shock you is that people who hav= e spent their lives studying war had to have that pointed out by me.

Cyber is inherently destabilizing. And the risk is not = just of a cyber attack against the US and its allies. An attack against Rus= sia or China could lead to catastrophic consequences as well. Neither has t= he capacity to develop an effective cyber defense in their critical infrast= ructure unless the western powers develop the technology first. One of the = ugly costs of relying on industrial espionage is that it destroys any chanc= e of developing an indigenous research capacity.


The issues are vastly more complex than = you imagine. NSA 1.0 spent its time cracking mechanical ciphers to enable t= he CIA coups that stopped when the world moved to digital in the mid 70s. N= SA 2.0 grew large fat and lazy while its military management spent their ti= me boosting each other's egos with (unsecured) Powerpoint presentations= that almost certainly exaggerate their capabilities.

We don't know what NSA 3.0 is going to be doing but= it isn't going to have anything like the intercept capabilities of the= past and it will be two congresses before they have any ability to shape t= he political landscape again.


--
Website: http://hallambaker.com/
--f46d043d655789ba7404ecc19e6d-- From bruce@perens.com Wed Dec 4 21:19:01 2013 Return-Path: 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 4EA951AE351 for ; Wed, 4 Dec 2013 21:19:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jP3NcNtns279 for ; Wed, 4 Dec 2013 21:19:00 -0800 (PST) Received: from alchemy.perens.com (alchemy.perens.com [206.221.219.26]) by ietfa.amsl.com (Postfix) with ESMTP id 09D561AE344 for ; Wed, 4 Dec 2013 21:18:59 -0800 (PST) Received: from Bruce-ASUS-Transformer-Prime.home.perens.com (c-50-168-114-183.hsd1.ca.comcast.net [50.168.114.183]) by alchemy.perens.com (Postfix) with ESMTPSA id 614B050008A; Wed, 4 Dec 2013 21:18:56 -0800 (PST) User-Agent: K-9 Mail for Android In-Reply-To: References: <290E20B455C66743BE178C5C84F1240847E5103799@EXMB01CMS.surrey.ac.uk> <2C66A416-5F07-4803-A4C0-BB61734BA42E@nominum.com> <529FB216.7010504@perens.com> <529FBC5F.7050700@perens.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Bruce Perens Date: Wed, 04 Dec 2013 21:18:52 -0800 To: Phillip Hallam-Baker Message-ID: Cc: perpass Subject: Re: [perpass] Commnets on draft-farrell-perpass-attack-00 was RE: 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 05:19:01 -0000 Phillip Hallam-Baker wrote: >It seemed like more of a threat to me. I can't imagine what I have to threaten with. No, it was not a threat. >The NSA is very aware of the work that I am doing and its purpose. And your description doesn't make it sound as if it's intended to be a hinder to NSA. We were discussing the proposal to make the task of mass surveillance more difficult for one or more nation's intelligence services. That is where I feel the risk (not threat) is. >We don't know what NSA 3.0 is going to be doing but it isn't going to have anything like the intercept capabilities of the past Since you can now get an ASIC bitcoin miner that does 10 giga hashes per second for around $240, we might have to adjust our capabilities assessment on the assumption that espionage agencies have custom silicon that we've never heard of, and lots of it. I don't think we can say for sure that TLS is any hurdle to NSA's mass surveillance program at all. Thanks Bruce -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. From elijah@bitmask.net Wed Dec 4 23:25:55 2013 Return-Path: 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 1F82D1A802D for ; Wed, 4 Dec 2013 23:25:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.855 X-Spam-Level: ** X-Spam-Status: No, score=2.855 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.793, UNPARSEABLE_RELAY=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 Taa0MCkKFwcr for ; Wed, 4 Dec 2013 23:25:53 -0800 (PST) Received: from leech.bitmask.net (unknown [198.252.153.85]) by ietfa.amsl.com (Postfix) with ESMTP id D56941A8028 for ; Wed, 4 Dec 2013 23:25:53 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Authenticated sender: UNLIMITED4nkmaf29wdg6zmo8engw00hnz) with ESMTPS id 2ABFA1EC75 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha512"; boundary="===============0520920801666099461==" Date: Wed, 04 Dec 2013 23:25:44 -0800 From: Elijah Sparrow To: perpass@ietf.org Message-Id: <20131205072546.2740.2142915422.0@crow> OpenPGP: id=F53BC597A48FF10C; url="https://bitmask.net/key/elijah"; preference="signencrypt" Subject: [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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 07:25:55 -0000 --===============0520920801666099461== Received: by bitmask.local from 127.0.0.1 with ESMTP ; Wed, 04 Dec 2013 23:25:46 -0800 Message-ID: <52A02A78.5030705@bitmask.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 QXMgYW4gb3V0c2lkZXIgdG8gdGhlIElFVEYsIGFuZCBvbmUtdGltZSBzb2Npb2xvZ2lzdCwgSSBm b3VuZCB0aGUgDQpyZXBlYXRlZCBjYWxscyBpbiBWYW5jb3V2ZXIgODggYW5kIG9uIHRoaXMgbGlz dCBmb3IgZGVjaXNpb25zIHRvIGJlIG1hZGUgDQpiYXNlZCBzb2xlbHkgb24gdGVjaG5pY2FsIG1l cml0IGFuZCBub3QgcG9saXRpY2FsIGFyZ3VtZW50IHRvIGJlIA0KZXh0cmVtZWx5IGZhc2NpbmF0 aW5nLg0KDQpUaGVyZSB3YXMgb25jZSBhIHRpbWUgd2hlbiB0aGUgZGVzaWduIG9mIGEgcHJvdG9j b2wgb3Igc3RhbmRhcmQgY291bGQgYmUgDQpkb25lIGluIGEgbWFubmVyIHRoYXQgYmVuZWZpdGVk IG5lYXJseSBldmVyeW9uZSB3aG8gbWlnaHQgYmUgdG91Y2hlZCBieSANCml0LiBUaGVzZSBkYXlz IGFyZSBzdXJlbHkgcGFzdC4gTmVhcmx5IGV2ZXJ5IHNpbmdsZSBkZWJhdGUgb3IgcXVlc3Rpb24g DQp0aGF0IGhhcyBjb21lIHVwIG9uIHRoaXMgbGlzdCBpcyBkZWVwbHkgcG9saXRpY2FsLCBpZiBm b3Igbm8gb3RoZXIgDQpyZWFzb24gdGhhbiB3aGF0ZXZlciBkZWNpc2lvbnMgYXJlIG1hZGUgd2ls bCBjcmVhdGUgd2lubmVycyBhbmQgbG9zZXJzLCANCnBlb3BsZSB3aG8gYmVuZWZpdCBmcm9tIHRo ZSBjaG9pY2UgYW5kIHBlb3BsZSB3aG8gYXJlIGhhcm1lZCBieSB0aGUgY2hvaWNlLg0KDQpJbiB0 aGUgc3dlZXAgb2YgaGlzdG9yeSwgaW5mb3JtYXRpb24gY2FwaXRhbGlzbSBoYXMgY29tZSB0byBh IG1vbWVudCBvZiANCnRydXRoLCB3aGVyZSB0aGUgbWF0ZXJpYWwgaW5mcmFzdHJ1Y3R1cmUgdGhh dCB0aGUgSUVURiBhbmQgdGVjaG5vbG9naXN0cyANCnRoZSB3b3JsZCBhcm91bmQgaGF2ZSBoZWxw ZWQgdG8gY3JlYXRlIGhhcyBub3cgbWF0dXJlZCBpbnRvIGJvdGggYW4gDQplY29ub21pYyBlbmdp bmUgYW5kIGEgc3RhdGUgaW50ZWxsaWdlbmNlIHN5c3RlbSBiYXNlZCBvbiBtYXNzIA0Kc3VydmVp bGxhbmNlLiBQZXJoYXBzIHRoZSBtb3N0IGRpc3Rpbmd1aXNoaW5nIHBvbGl0aWNhbCBkZWJhdGUg b2Ygb3VyIA0KdGltZSBpcyBob3cgdGhlIHBvd2VyIG9mIHRoZSBzdGF0ZSBhbmQgb2YgYnVzaW5l c3Mgd2l0aCByZXNwZWN0IHRvIA0KY2l0aXplbnMgYW5kIGN1c3RvbWVycyBoYXMgYmVlbiByYWRp Y2FsbHkgdHJhbnNmb3JtZWQgdW5kZXIgdGhpcyBuZXcgDQpyZWdpbWUgb2YgdWJpcXVpdG91cyBz dXJ2ZWlsbGFuY2UuIE9idmlvdXNseSwgSSBmZWVsIGEgcGFydGljdWxhciB3YXkgDQphYm91dCB0 aGlzLCBidXQgSSBhbSBqdXN0IHN0YXRpbmcgdGhlIG9idmlvdXM6IHRoZXNlIGlzc3VlcyBhcmUg ZGVlcGx5IA0KcG9saXRpY2FsIGJlY2F1c2UgdGhlIGZyYWdpbGUgYmFsYW5jZSBvZiBwb3dlcnMg aW4gbGliZXJhbCBkZW1vY3JhY3kgYW5kIA0KaW4gb3VyIGNhcGl0YWxpc3QgZWNvbm9taWVzIGhh dmUgYmVlbiBpbmV4b3JhYmx5IHJvY2tlZCBieSB0ZWNobm9sb2dpY2FsIA0KY2hhbmdlcy4NCg0K SW4gdGhpcyBjb250ZXh0LCB0aGUgcXVlc3Rpb24gb2YgImhvdyBtdWNoIGVuY3J5cHRpb24iIGlz IGEgdGVjaG5pY2FsIA0KcXVlc3Rpb24gdGhhdCBpcyBhbHNvIGRlZXBseSBpbnRlcnR3aW5lZCB3 aXRoIHRoZSBtYWpvciBwb2xpdGljYWwgDQpkZWJhdGVzIG9mIG91ciBkYXkuIE9uZSBvbmx5IGhh cyB0byBub3RlIHRoZSBtYWpvciBoZWFkbGluZXMgYXJvdW5kIHRoZSANCndvcmxkIGFib3V0IHRo ZSBpZXRmIGNhbGxzIGZvciBlbmNyeXB0aW9uIGluIGh0dHAgMi4wLiBIb3cgb2Z0ZW4gaGF2ZSAN CmlldGYgbWVldGluZ3MgZ2FybmVyZWQgc3VjaCBnbG9iYWwgY292ZXJhZ2U/DQoNClNjaWVudGlz dHMgYW5kIGVuZ2luZWVycyBhcmUgb2Z0ZW4gZm9yY2VkIGludG8gcG9saXRpY2FsIGFyZW5hcyB3 aXRob3V0IA0KdGhlaXIgZGVzaXJlIG9yIGZvcmVzaWdodC4gVGFrZSwgZm9yIGV4YW1wbGUsIHRo ZSBoaXN0b3J5IG9mIGdlbm9taWNzLCANCmNsaW1hdGUgY2hhbmdlLCBvciBudWNsZWFyIHBoeXNp Y3MuIEhpc3RvcmljYWxseSwgdGhlIHNjaWVudGlzdHMgYW5kIA0KZW5naW5lZXJzIGhhdmUgY2x1 bmcgZGVzcGVyYXRlbHkgdG8gdGhlIGNsb2FrIG9mIG9iamVjdGl2ZSBzY2llbmNlLCBldmVuIA0K YXMgdGhlaXIgd29yayB0b29rIG9uIGluY3JlYXNpbmdseSBvYnZpb3VzIHBvbGl0aWNhbCByYW1p ZmljYXRpb25zLiBNeSANCmhvcGUgZm9yIHRoZSBpbnRlcm5ldCBpcyB0aGF0IHdlIGNvdWxkIHBl cmhhcHMgYnlwYXNzIHN1Y2ggc2lsbGluZXNzIGFuZCANCmVtYnJhY2UgdGhlIG9idmlvdXMgcG9s aXRpY2FsIG5hdHVyZSBvZiBvdXIgd29yay4gQmVpbmcgaG9uZXN0IHdpdGggDQpvdXJzZWx2ZXMg ZG9lcyBub3QgcHVzaCBhbnlvbmUgdG93YXJkIGFueSBwYXJ0aWN1bGFyIHRlY2huaWNhbCBvciAN CnBvbGl0aWNhbCBzdGFuY2UsIGV4Y2VwdCB0aGF0IHBlcmhhcHMgd2UgY2FuIGJlIG1vcmUgdHJh bnNwYXJlbnQgaW4gb3VyIA0KanVzdGlmaWNhdGlvbnMuDQoNCkluIHRoZSBpbW1vcnRhbCB3b3Jk cyBvZiBWb2x0YWlyZSwgYW5kIFNwaWRlcm1hbiwgd2l0aCBncmVhdCBwb3dlciBjb21lcyANCmdy ZWF0IHJlc3BvbnNpYmlsaXR5Lg0KDQotZWxpamFoDQoNCi0tDQpJIHByZWZlciBlbmNyeXB0ZWQg ZW1haWwgLSBodHRwczovL2JpdG1hc2submV0L2tleS9lbGlqYWguDQo= --===============0520920801666099461== Content-Type: application/pgp-signature; name="signature.asc" MIME-Version: 1.0 Content-Description: OpenPGP Digital Signature -----BEGIN PGP SIGNATURE----- iQIcBAABCgAGBQJSoCp7AAoJEPU7xZekj/EMoYYQAKrpF4s2iOjlUri+pS/w5b80 7oM29ioN1eATqRDCnxRsPUmsogq0xSsrSiryHfTiTAxlhJIhMVLaREC29wFIFmd8 ILUmtGyoEsdNbRAmEvQHTUB1vXSrNyrGFaDVzVlHhuh0IF1kJ9/WeUaGSOVPzDea OUrbatQbbm4q4nuD+BICl3DwGEj4eBZFKpJOedNuWv1u+fpyQY/4AVh+QFZsOcHJ y2UNDQmlg4opmqkkQ50X2pdTfi8O3FXAe5bGhY1Naa9pR8k4Jq31nZr7sDj1HvUd QT2aa2Qw21pJqyLWLopUT/9zmROv4SJduHOQjSMioPXGI47WMP3YIyqRoEl3z2xL k3hzVLBSr3aJSrrvt5VejjaVyCuQAdJpar3xWZG1q8oGvoKd/oM+fze7pnY2Oj4D OURwI5o4wix1Zi6Le/TL+S6YpUecW7jBw4iyR76Ga3hWVFSvO9ebWNBKqw04hhRx AGWCLyZAOKHFlJ7FQeSRCmOobNh/6cghAs9RAGvSfPe/+dUog5CzrEVettdJHbCR npB7y2sE8CintovwnoJSonRNOo3CFlVACXyuzJS0bLOGfFt5AS12o+e0Q0tntf7m rZAlJukj4KjckSF0bcCk63JSRlqSgksSiwmIcKHRANnfsuJlMPehJrK4NwBF7hmZ ODYz+SXNtiy43IA28T8g =pBo7 -----END PGP SIGNATURE----- --===============0520920801666099461==-- From randy@psg.com Thu Dec 5 00:23:12 2013 Return-Path: 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 320591AD6D2 for ; Thu, 5 Dec 2013 00:23:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fhk4OvnRHqfr for ; Thu, 5 Dec 2013 00:23:11 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id 3E7891AD6D1 for ; Thu, 5 Dec 2013 00:23:11 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1VoUDA-0003F5-3v; Thu, 05 Dec 2013 08:23:04 +0000 Date: Thu, 05 Dec 2013 09:23:04 +0100 Message-ID: From: Randy Bush To: Peter Saint-Andre In-Reply-To: <529FC651.1070909@stpeter.im> References: <529FC651.1070909@stpeter.im> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: perpass Subject: Re: [perpass] administrative request 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 08:23:12 -0000 > It strikes me that the current discussion, although interesting in its > own way, has a low signal-to-noise ratio. Perhaps the list admins > could suggest a one-day cooling-off period or some such? i simpletely deteled the thread. some folk have work to do. randy From sm@resistor.net Thu Dec 5 00:24:24 2013 Return-Path: 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 3E03B1AD6D1 for ; Thu, 5 Dec 2013 00:24:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 JqyuLImrHKQJ for ; Thu, 5 Dec 2013 00:24:23 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7919B1AC7F3 for ; Thu, 5 Dec 2013 00:24:23 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id rB58ODn2010344; Thu, 5 Dec 2013 00:24:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1386231858; bh=ao5EN98DY8aHlSItQ3BnXxPt/USO0ilqOg2VjGUfnnQ=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=QZAoLUWUTcNsaV5Tq4OD6xXRce3vx7A6N4qhCn0TbAcBoz/tlxAv6BMGSEpu1Ycws f9mGgARlhjp6+VT28Rij/WD84m+Jnzs4Tpw9jbYnXG42AKeaeGtaWGa+hE5+n6Tfsy ZQ7u6mSKY4PuuWyLkQC/hAFGervxzrZqZtwzHHek= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1386231858; i=@resistor.net; bh=ao5EN98DY8aHlSItQ3BnXxPt/USO0ilqOg2VjGUfnnQ=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=bqnKNCb1nTd9iRhM4O90J5YYWbEBBkUyMQNQHliPEv35HAn6vPx3jQmASUJIPuedG /VyGtIJHlbeAeS1tRrt2Yw/DfYSKwdrYLfnAmionfAts0H7WUEv3iQ1GKZPngUW0xC FDjhMY+oNVZc44oiVcE7U2el+YgTtThfun+TnWrM= Message-Id: <6.2.5.6.2.20131204235023.06de9118@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 05 Dec 2013 00:21:36 -0800 To: Elijah Sparrow From: SM In-Reply-To: <20131205072546.2740.2142915422.0@crow> References: <20131205072546.2740.2142915422.0@crow> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: perpass@ietf.org 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 08:24:24 -0000 Hi Elijah, At 23:25 04-12-2013, Elijah Sparrow wrote: >There was once a time when the design of a protocol or standard >could be done in a manner that benefited nearly everyone who might >be touched by it. These days are surely past. Nearly every single >debate or question that has come up on this list is deeply >political, if for no other reason than whatever decisions are made >will create winners and losers, people who benefit from the choice >and people who are harmed by the choice. Yes. >In this context, the question of "how much encryption" is a >technical question that is also deeply intertwined with the major >political debates of our day. One only has to note the major >headlines around the world about the ietf calls for encryption in >http 2.0. How often have ietf meetings garnered such global coverage? My guess is that it was the first time. The coverage wasn't that global. The approach would likely be more nuanced than what has been reported. Regards, -sm From bortzmeyer@nic.fr Thu Dec 5 01:14:56 2013 Return-Path: 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 173DF1AD937 for ; Thu, 5 Dec 2013 01:14:56 -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 gCrjpu4-cCXt for ; Thu, 5 Dec 2013 01:14:55 -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 D11AB1AC7F0 for ; Thu, 5 Dec 2013 01:14:54 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id F007E2802BB; Thu, 5 Dec 2013 10:14:50 +0100 (CET) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx4.nic.fr (Postfix) with ESMTP id EB6CC28019C; Thu, 5 Dec 2013 10:14:50 +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 DF3174C007C; Thu, 5 Dec 2013 10:14:20 +0100 (CET) Date: Thu, 5 Dec 2013 10:14:20 +0100 From: Stephane Bortzmeyer To: Elijah Sparrow Message-ID: <20131205091420.GB8524@nic.fr> References: <20131205072546.2740.2142915422.0@crow> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20131205072546.2740.2142915422.0@crow> 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] 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 09:14:56 -0000 On Wed, Dec 04, 2013 at 11:25:44PM -0800, Elijah Sparrow wrote a message of 95 lines which said: > As an outsider to the IETF, and one-time sociologist [...] whatever > decisions are made will create winners and losers, people who > benefit from the choice and people who are harmed by the choice. I fully agree and, for the benefit of my fellow engineers, the best paper to read about this issue is still "Tussle in Cyberspace: Defining Tomorrow's Internet" which claims that we should admit there are tussles (different interests and no hope of making everyone happy). From bortzmeyer@nic.fr Thu Dec 5 01:17:45 2013 Return-Path: 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 AAA141ACC8A for ; Thu, 5 Dec 2013 01:17:45 -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 OOPObB_FIpYb for ; Thu, 5 Dec 2013 01:17:45 -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 D32701AC4C5 for ; Thu, 5 Dec 2013 01:17:43 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 5A5672802BB; Thu, 5 Dec 2013 10:17:40 +0100 (CET) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx4.nic.fr (Postfix) with ESMTP id 5584328019C; Thu, 5 Dec 2013 10:17:40 +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 542EE4C007C; Thu, 5 Dec 2013 10:17:10 +0100 (CET) Date: Thu, 5 Dec 2013 10:17:10 +0100 From: Stephane Bortzmeyer To: Bruce Perens Message-ID: <20131205091710.GC8524@nic.fr> References: <529E8494.7000806@perens.com> <20131204111309.GB11727@nic.fr> <529F7B3B.5020901@gmail.com> <529F91C9.6060906@perens.com> <529F9E01.2000306@gmail.com> <529FAFE2.8060205@perens.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <529FAFE2.8060205@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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 09:17:45 -0000 On Wed, Dec 04, 2013 at 02:42:42PM -0800, Bruce Perens wrote a message of 51 lines which said: > It was incredibly successful. There was a competing stack design > in the OSI protocols which went nowhere. IMO the reason for > success was the simplicity. Do note there is an entire (and excellent) RFC dedicated to the reasons for success of a protocol, RFC 5218. Recommended reading before continuing this discussion. Executive summary of RFC 5218: better to have no security at the beginning (in order to be simple and easy) *but* to be able to add it later (because with success come security problems). From bortzmeyer@nic.fr Thu Dec 5 01:41:02 2013 Return-Path: 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 B92891ADBD0 for ; Thu, 5 Dec 2013 01:41:02 -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 s89ybC3t_5fy for ; Thu, 5 Dec 2013 01:41:02 -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 D05621ADBCE for ; Thu, 5 Dec 2013 01:41:01 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 4F2332802C6; Thu, 5 Dec 2013 10:40:58 +0100 (CET) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx4.nic.fr (Postfix) with ESMTP id 498B72802BB; Thu, 5 Dec 2013 10:40:58 +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 474E74C007C; Thu, 5 Dec 2013 10:40:28 +0100 (CET) Date: Thu, 5 Dec 2013 10:40:28 +0100 From: Stephane Bortzmeyer To: Bruce Perens Message-ID: <20131205094027.GA10388@nic.fr> References: <290E20B455C66743BE178C5C84F1240847E5103799@EXMB01CMS.surrey.ac.uk> <2C66A416-5F07-4803-A4C0-BB61734BA42E@nominum.com> <529FB216.7010504@perens.com> <529FBC5F.7050700@perens.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 , Phillip Hallam-Baker Subject: Re: [perpass] Commnets on draft-farrell-perpass-attack-00 was RE: 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 09:41:02 -0000 On Wed, Dec 04, 2013 at 09:18:52PM -0800, Bruce Perens wrote a message of 27 lines which said: > I don't think we can say for sure that TLS is any hurdle to NSA's > mass surveillance program at all. Besides obvious remarks (secret agencies are secret), what is the consequence to draw from this observation? That we should not use TLS because it is possible that NSA has successfully attacked it? If so, that would be a poor decision. First, there are other attackers, which do not have the same resources as the NSA. Second, even the NSA cannot break the law of physics (testing 2^256 possibilities take a lot of time, even when you have money). Third, since we don't know, it seems to me the reasonable thing to do would be to protect ourselves, just in case. [Insert here paranoid remarks about the NSA spreading the rumor that it can break TLS so people won't encrypt and therefore the NSA will not have to break TLS.] From wilton@isoc.org Thu Dec 5 01:51:19 2013 Return-Path: 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 44EE51ADBF7 for ; Thu, 5 Dec 2013 01:51:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 gM7AhpiVafGM for ; Thu, 5 Dec 2013 01:51:17 -0800 (PST) Received: from smtp118.iad3a.emailsrvr.com (smtp118.iad3a.emailsrvr.com [173.203.187.118]) by ietfa.amsl.com (Postfix) with ESMTP id EAD741ADBC7 for ; Thu, 5 Dec 2013 01:51:16 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp7.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 93D51400CB; Thu, 5 Dec 2013 04:51:13 -0500 (EST) X-Virus-Scanned: OK Received: by smtp7.relay.iad3a.emailsrvr.com (Authenticated sender: wilton-AT-isoc.org) with ESMTPSA id 67100400C7; Thu, 5 Dec 2013 04:51:13 -0500 (EST) References: <20131205072546.2740.2142915422.0@crow> In-Reply-To: <20131205072546.2740.2142915422.0@crow> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPad Mail (9B206) From: Robin Wilton Date: Thu, 5 Dec 2013 09:55:16 +0000 To: Elijah Sparrow Cc: "perpass@ietf.org" 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 09:51:19 -0000 Thanks Elijah, this is a very useful perspective on the whole question of te= chnologists' role - especially when the technology in question is so woven i= nto our political, economic and personal lives. As you say, much of the work of the IETF has an inescapably political dimens= ion - whether we choose to acknowledge that ourselves, or have it thrust upo= n us (Dual_EC_DRBG being a case in point).=20 I apologise for re-using a well-worn phrase, but I think this reinforces the= argument in favour of an open, multi-stakeholder process. That doesn't mean= forcing economists and policymakers into the drafting sessions for RFCs, bu= t it does mean creating a process that can take their (and others') input in= to account - and being able to articulate what we do in terms that make sens= e to other stakeholders. That approach isn't a guarantee against 'bad actors' exploiting the open nat= ure of the process for their own ends, but compared to alternative ways of a= rchitecting and governing the Internet, it offers the best prospects of dete= cting and mitigating that kind of harm. Best wishes, Robin Robin Wilton Technical Outreach Director - Identity and Privacy On 5 Dec 2013, at 07:25, Elijah Sparrow wrote: > As an outsider to the IETF, and one-time sociologist, I found the repeated= calls in Vancouver 88 and on this list for decisions to be made based solel= y on technical merit and not political argument to be extremely fascinating.= >=20 > There was once a time when the design of a protocol or standard could be d= one in a manner that benefited nearly everyone who might be touched by it. T= hese days are surely past. Nearly every single debate or question that has c= ome up on this list is deeply political, if for no other reason than whateve= r decisions are made will create winners and losers, people who benefit from= the choice and people who are harmed by the choice. >=20 > In the sweep of history, information capitalism has come to a moment of tr= uth, where the material infrastructure that the IETF and technologists the w= orld around have helped to create has now matured into both an economic engi= ne and a state intelligence system based on mass surveillance. Perhaps the m= ost distinguishing political debate of our time is how the power of the stat= e and of business with respect to citizens and customers has been radically t= ransformed under this new regime of ubiquitous surveillance. Obviously, I fe= el a particular way about this, but I am just stating the obvious: these iss= ues are deeply political because the fragile balance of powers in liberal de= mocracy and in our capitalist economies have been inexorably rocked by techn= ological changes. >=20 > In this context, the question of "how much encryption" is a technical ques= tion that is also deeply intertwined with the major political debates of our= day. One only has to note the major headlines around the world about the ie= tf calls for encryption in http 2.0. How often have ietf meetings garnered s= uch global coverage? >=20 > Scientists and engineers are often forced into political arenas without th= eir desire or foresight. Take, for example, the history of genomics, climate= change, or nuclear physics. Historically, the scientists and engineers have= clung desperately to the cloak of objective science, even as their work too= k on increasingly obvious political ramifications. My hope for the internet i= s that we could perhaps bypass such silliness and embrace the obvious politi= cal nature of our work. Being honest with ourselves does not push anyone tow= ard any particular technical or political stance, except that perhaps we can= be more transparent in our justifications. >=20 > In the immortal words of Voltaire, and Spiderman, with great power comes g= reat responsibility. >=20 > -elijah >=20 > -- > I prefer encrypted email - https://bitmask.net/key/elijah. > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass From matthaeus.wander@uni-due.de Thu Dec 5 02:09:47 2013 Return-Path: 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 4E5441ADDD1 for ; Thu, 5 Dec 2013 02:09:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.251 X-Spam-Level: X-Spam-Status: No, score=-1.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, 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 NjSam8_MwDbc for ; Thu, 5 Dec 2013 02:09:46 -0800 (PST) Received: from mailout.uni-due.de (mailout.uni-due.de [132.252.185.19]) by ietfa.amsl.com (Postfix) with ESMTP id B5AAA1ADD02 for ; Thu, 5 Dec 2013 02:09:45 -0800 (PST) Received: from [192.168.8.100] (wall-a.vs.uni-duisburg-essen.de [134.91.78.130]) (authenticated bits=0) by mailout.uni-due.de (8.13.1/8.13.1) with ESMTP id rB5A9fYs002215 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 5 Dec 2013 11:09:41 +0100 Message-ID: <52A050E7.8010405@uni-due.de> Date: Thu, 05 Dec 2013 11:09:43 +0100 From: =?ISO-8859-15?Q?Matth=E4us_Wander?= Organization: Verteilte Systeme User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: perpass@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080909070408020206070505" X-Virus-Scanned: Clam Anti Virus - http://www.clamav.net X-Spam-Scanned: SpamAssassin: 3.002004 - http://www.spamassassin.org X-Scanned-By: MIMEDefang 2.57 on 132.252.185.19 Subject: Re: [perpass] A reminder, the Network is the Enemy... 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 10:09:47 -0000 This is a cryptographically signed message in MIME format. --------------ms080909070408020206070505 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable * Nicholas Weaver [2013-12-02 17:56]: > Actually spoofing DNSSEC replies even with knowledge of the root key is= going to be difficult... If we assume the attacker can get the private root KSK from an US-based corp, then we should also assume they can get the private root ZSK from another US-based corp. As the owner of the root ZSK also owns the keys for .com, the attack becomes much easier. Regards, Matt --=20 Universit=E4t Duisburg-Essen Verteilte Systeme Bismarckstr. 90 / BC 316 47057 Duisburg --------------ms080909070408020206070505 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPTzCC BCEwggMJoAMCAQICAgDHMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNjEyMTkxMDI5MDBa Fw0xOTA2MzAyMzU5MDBaMFoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAw DgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U 1wBblSJ01CDrNI/W7MAxBAuZgeKmFNJSoCgjhIt0iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6 fL9KDhsAw4bpXCsxEXsM84IkQ4wcOItqaACa7txPeKvSxhObdq3u3ibo7wGvdA/BCaL2a869 080UME/15eOkyGKbghoDJzANAmVgTe3RCSMqljVYJ9N2xnG2kB3E7f81hn1vM7PbD8URwoqD oZRdQWvY0hD1TP3KUazZve+Sg7va64sWVlZDz+HVEz2mHycwzUlU28kTNJpxdcVs6qcLmPkh nSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjgdkwgdYwcAYDVR0fBGkwZzBloGOgYYZfaHR0cDov L3BraS50ZWxlc2VjLmRlL2NnaS1iaW4vc2VydmljZS9hZl9Eb3dubG9hZEFSTC5jcmw/LWNy bF9mb3JtYXQ9WF81MDkmLWlzc3Vlcj1EVF9ST09UX0NBXzIwHQYDVR0OBBYEFEm3xs/oPR9/ 6kR7Eyn38QpwPt5kMB8GA1UdIwQYMBaAFDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB /wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgECMA0GCSqGSIb3DQEBBQUAA4IBAQA74Vp3wEgX 3KkY7IGvWonwvSiSpspZGBJw7Cjy565/lizn8l0ZMfYTK3S9vYCyufdnyTmieTvhERHua3iR M347XyYndVNljjNj7s9zw7CSI0khUHUjoR8Y4pSFPT8z6XcgjaK95qGFKUD2P3MyWA0Ja6ba hWzAP7uNZmRWJE6uDT8yNQFb6YyC2XJZT7GGhfF0hVblw/hc843uR7NTBXDn5U2KaYMo4RMJ hp5eyOpYHgwf+aTUWgRo/Sg+iwK2WLX2oSw3VwBnqyNojWOl75lrXP1LVvarQIc01BGSbOyH xQoLBzNytG8MHVQs2FHHzL8w00Ny8TK/jM5JY6gA9/IcMIIFYDCCBEigAwIBAgIEDBrviDAN BgkqhkiG9w0BAQUFADBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZlcmVpbjEQMA4G A1UECxMHREZOLVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0gRzAxMB4X DTA4MDQwODEzMjQxMFoXDTE5MDYzMDAwMDAwMFowgcYxCzAJBgNVBAYTAkRFMSQwIgYDVQQK ExtVbml2ZXJzaXRhZXQgRHVpc2J1cmctRXNzZW4xNTAzBgNVBAsTLFplbnRydW0gZnVlciBJ bmZvcm1hdGlvbnMtIHVuZCBNZWRpZW5kaWVuc3RlMSwwKgYDVQQDEyNVbml2ZXJzaXRhZXQg RHVpc2J1cmctRXNzZW4gQ0EgLUcwMTEsMCoGCSqGSIb3DQEJARYdY2FhZG1pbkB1bmktZHVp c2J1cmctZXNzZW4uZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCrlesmTmiM kKzPuHIJDUpxpjiCkPL18fopC9Cue4n1xRBxPnSEssI/2XAb4kHWrJmlPjd2281P2HmIQkaj +mPOw0xGkzYan/rKRb8gvwb4v/cJhC7TIioPTQ7NfvfMg5hoNYW7mcykAEY0eFlO80dLHNLL MUQm8VRxPDS9sDlHgIUadmM1YNkgJ3PB0f0DqR7WiLoyggLdvxIZDkCncFpkhbrvfXU0kQVU cj8kMNG5F5EgNUa/1kTpqfOU+3jAikYMPlPhfW4NvKbSpm8p5BbRHJQlte20pTeWFGAatv6R jO10eWHoP88lS9qiOmH+kk/cqqP2tzPo4aE62BiGi4OJAgMBAAGjggG/MIIBuzASBgNVHRMB Af8ECDAGAQH/AgEBMAsGA1UdDwQEAwIBBjAdBgNVHQ4EFgQUZma8lptITejdvCKnplvVqEGf le4wHwYDVR0jBBgwFoAUSbfGz+g9H3/qRHsTKffxCnA+3mQwKAYDVR0RBCEwH4EdY2FhZG1p bkB1bmktZHVpc2J1cmctZXNzZW4uZGUwgYgGA1UdHwSBgDB+MD2gO6A5hjdodHRwOi8vY2Rw MS5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMD2gO6A5hjdo dHRwOi8vY2RwMi5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1Yi9jcmwvY2FjcmwuY3Js MIGiBggrBgEFBQcBAQSBlTCBkjBHBggrBgEFBQcwAoY7aHR0cDovL2NkcDEucGNhLmRmbi5k ZS9nbG9iYWwtcm9vdC1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwRwYIKwYBBQUHMAKGO2h0 dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NhY2VydC9jYWNlcnQu Y3J0MA0GCSqGSIb3DQEBBQUAA4IBAQCOZYvvu9iso7h38+NZkO9pxV5B7IqOutVj0U3c1b4W DgcGO+FIm61k4uFTr8FMh2CCZYl6mhJEimSIHMn5LUGAguLh7DrouddbPiHTfuS5obYEwf+g udzFutXFDD+D3zKaQE8+gZUzIWZQCP1Zw9r02X0K7N8y3l3cQRysh13vGAdK0DQShuRYIEaP fpkqJdBIvP+KzMjvAovEeg7v7emsGgZakVKrghmlzEiIxcEUY5XKhPZRSYvONTOO/rFQ28m6 mfmO8mPKSYni57PG26eNNyRQJXMO8lodXTIlw6wUSuncMSd0IrwDLcLA6ayxuQaFzChSIHaT nwdpvAv9QEu4MIIFwjCCBKqgAwIBAgIHFAVKqFI8xjANBgkqhkiG9w0BAQUFADCBxjELMAkG A1UEBhMCREUxJDAiBgNVBAoTG1VuaXZlcnNpdGFldCBEdWlzYnVyZy1Fc3NlbjE1MDMGA1UE CxMsWmVudHJ1bSBmdWVyIEluZm9ybWF0aW9ucy0gdW5kIE1lZGllbmRpZW5zdGUxLDAqBgNV BAMTI1VuaXZlcnNpdGFldCBEdWlzYnVyZy1Fc3NlbiBDQSAtRzAxMSwwKgYJKoZIhvcNAQkB Fh1jYWFkbWluQHVuaS1kdWlzYnVyZy1lc3Nlbi5kZTAeFw0xMjA2MjMxNDA1MTJaFw0xNTA2 MjMxNDA1MTJaMGoxCzAJBgNVBAYTAkRFMSQwIgYDVQQKExtVbml2ZXJzaXRhZXQgRHVpc2J1 cmctRXNzZW4xGjAYBgNVBAsTEVZlcnRlaWx0ZSBTeXN0ZW1lMRkwFwYDVQQDExBNYXR0aGFl dXMgV2FuZGVyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAnb3m8zkICsRFcXby DiMh6u5E68UcglCXg0Z10nmripU5DCJqWnPAiaFt14GL3S9Sgongm1z3lS88rbXJv/xW1yKh RcTbBCUx80+Cdz+JQsx2pQWVSY+0FwY4GsMFmZOgZAObJkcKP/LtGyQlLIonk8CxNtO5BM6Q x8h7IoYDbpKbPnPe8HxgQFdVHSrjsy/hM0gqskaxotsiDNd2Z1yeolYYqwJs3Q2FHcQctvCT oD66hCgJ/B1w6xqrVsHl0pKzrGsVHWzJ/4+BeyfU1vpqMfdnfGN8unIlpAh5SP7X1ayRY+Fg UsVVob++KQMtBWRrLeViiF0+XRo9K7k2GhIHJQIDAQABo4ICDjCCAgowHAYDVR0gBBUwEzAR Bg8rBgEEAYGtIYIsAQEEAgIwCQYDVR0TBAIwADALBgNVHQ8EBAMCBeAwHQYDVR0lBBYwFAYI KwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBTaAPmgfOfyKtJ9FoeGvPD28Uun8zAfBgNV HSMEGDAWgBRmZryWm0hN6N28IqemW9WoQZ+V7jAmBgNVHREEHzAdgRttYXR0aGFldXMud2Fu ZGVyQHVuaS1kdWUuZGUwgZcGA1UdHwSBjzCBjDBEoEKgQIY+aHR0cDovL2NkcDEucGNhLmRm bi5kZS91bmktZHVpc2J1cmctZXNzZW4tY2EvcHViL2NybC9jYWNybC5jcmwwRKBCoECGPmh0 dHA6Ly9jZHAyLnBjYS5kZm4uZGUvdW5pLWR1aXNidXJnLWVzc2VuLWNhL3B1Yi9jcmwvY2Fj cmwuY3JsMIGwBggrBgEFBQcBAQSBozCBoDBOBggrBgEFBQcwAoZCaHR0cDovL2NkcDEucGNh LmRmbi5kZS91bmktZHVpc2J1cmctZXNzZW4tY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0ME4G CCsGAQUFBzAChkJodHRwOi8vY2RwMi5wY2EuZGZuLmRlL3VuaS1kdWlzYnVyZy1lc3Nlbi1j YS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcNAQEFBQADggEBAAAtpWHGZfdNb8wT dDuYr5LAtcSOuXWn4l0ZHeIhdy13kIA3m9YN/E4Dz2UTkn0cyihDAX5LOSLzcvfM4qmG5A7i zT8m22fvj2UKxY3qnzoEGZqmGfk8otj121Sa10Ko69MyspewpqVkOfGpA5VCF92cuY6mHmnH HWEX75GgqRwSwYJmvgs+jC6w9rFA2ArhMj671PMrrd2EbiH9Nvmr5bEV+alumh5ismB1ujm2 4w1Zz2AdOKGnyaMNF37OyVAzmk1FTjfkVgSumha2w37QCmIJ4Wn0XKuYhJfoObbnaI/VHSO8 JPp8oLJ2z3c5cb3iSWkWjGQaqxSxtcr4dSdVDVIxggSXMIIEkwIBATCB0jCBxjELMAkGA1UE BhMCREUxJDAiBgNVBAoTG1VuaXZlcnNpdGFldCBEdWlzYnVyZy1Fc3NlbjE1MDMGA1UECxMs WmVudHJ1bSBmdWVyIEluZm9ybWF0aW9ucy0gdW5kIE1lZGllbmRpZW5zdGUxLDAqBgNVBAMT I1VuaXZlcnNpdGFldCBEdWlzYnVyZy1Fc3NlbiBDQSAtRzAxMSwwKgYJKoZIhvcNAQkBFh1j YWFkbWluQHVuaS1kdWlzYnVyZy1lc3Nlbi5kZQIHFAVKqFI8xjAJBgUrDgMCGgUAoIICmTAY BgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzEyMDUxMDA5NDNa MCMGCSqGSIb3DQEJBDEWBBQsXrTZyOVlhBrRHnwgY1w670HI8TBsBgkqhkiG9w0BCQ8xXzBd MAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHjBgkrBgEEAYI3EAQx gdUwgdIwgcYxCzAJBgNVBAYTAkRFMSQwIgYDVQQKExtVbml2ZXJzaXRhZXQgRHVpc2J1cmct RXNzZW4xNTAzBgNVBAsTLFplbnRydW0gZnVlciBJbmZvcm1hdGlvbnMtIHVuZCBNZWRpZW5k aWVuc3RlMSwwKgYDVQQDEyNVbml2ZXJzaXRhZXQgRHVpc2J1cmctRXNzZW4gQ0EgLUcwMTEs MCoGCSqGSIb3DQEJARYdY2FhZG1pbkB1bmktZHVpc2J1cmctZXNzZW4uZGUCBxQFSqhSPMYw geUGCyqGSIb3DQEJEAILMYHVoIHSMIHGMQswCQYDVQQGEwJERTEkMCIGA1UEChMbVW5pdmVy c2l0YWV0IER1aXNidXJnLUVzc2VuMTUwMwYDVQQLEyxaZW50cnVtIGZ1ZXIgSW5mb3JtYXRp b25zLSB1bmQgTWVkaWVuZGllbnN0ZTEsMCoGA1UEAxMjVW5pdmVyc2l0YWV0IER1aXNidXJn LUVzc2VuIENBIC1HMDExLDAqBgkqhkiG9w0BCQEWHWNhYWRtaW5AdW5pLWR1aXNidXJnLWVz c2VuLmRlAgcUBUqoUjzGMA0GCSqGSIb3DQEBAQUABIIBAF3tyOMkih0v0X+p1H5wBQ4eEgfg 2uDvo6bJZWrTktpIkQe72qEwtCysCheR3D8vpc5HqzTHgOcLyBNaVciSvSgYiCMOVKCY5hWn JGLTyDk4XTTacXl7BxcMVhicck3w5eJ7ebGqRM4NcOuUH9jwTnuJzBcQ01j+W7xIFVxoKcpU i8wDO++YBG1/MXwPLe3c8NgEPQq9gZLsQAdWggLzUliEanRK/22Ru5jRmu5yTVBmAA7kH29b EhLvYSgyVfb6JSHVZ7sLfFikf8jJvWxIOWWpoCpsbc08LqO4GnQeutQDcigQ7u9R8jQn+zkK 9iWn+ImL93jY0wxG24XR+bXxXosAAAAAAAA= --------------ms080909070408020206070505-- From hannes.tschofenig@gmx.net Thu Dec 5 02:53:48 2013 Return-Path: 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 473FA1ADF34 for ; Thu, 5 Dec 2013 02:53:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.851 X-Spam-Level: X-Spam-Status: No, score=-0.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_12_24=1.049, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 uJqryeCYIJK7 for ; Thu, 5 Dec 2013 02:53:45 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id 0E4F21ADF22 for ; Thu, 5 Dec 2013 02:53:45 -0800 (PST) Received: from [192.168.10.130] ([62.49.66.12]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MGAdz-1Vm4F11OOF-00FAlR for ; Thu, 05 Dec 2013 11:53:41 +0100 Message-ID: <529F8F94.3020506@gmx.net> Date: Wed, 04 Dec 2013 20:24:52 +0000 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Robin Wilton , Elijah Sparrow References: <20131205072546.2740.2142915422.0@crow> In-Reply-To: Content-Type: multipart/alternative; boundary="------------030901050204020807080902" X-Provags-ID: V03:K0:Iho1e0g8qPBRH2V27y1E0Ig+VGQt5WkNa8bzMXbsnDajf4H880W CvYByRP6RI0UcUHVV/bhKpdHswBi3lRAeSnn9UbirraV+XXdz5/Un55gPavzmgIB4WLDAHS rA25YwEqb5iDpo5l6j0wPOdBnDmmTa713/nycLnw1x+jWcj/hgJeyATFlQA0hg+kiVnmqOP GS7AFJGrqsVmEwEjkeqNQ== Cc: "perpass@ietf.org" 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 10:53:48 -0000 This is a multi-part message in MIME format. --------------030901050204020807080902 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Robin, Elijah, I am always curious how one manages to make a clear distinction between political decisions, technical decisions, economical decisions, and other decisions. The perception that "in the early days of the Internet" the decisions were purely technical as too simplistic. If you look at specific decisions of individuals in the IETF it is hard to put them into specific categories. Even if you believe you see a purely technical decision it may have economical implications, or at some time interfere with other design goals. Take the HTTP state management work as an example. The introduction of cookies was a technical mechanism to keep state for the otherwise mostly stateless HTTP protocol. As we now know, the way how cookies have been used later by various Web companies lead to privacy concerns. This lead to the famous technical work on Do Not Track, which has technical components, business implications, and raises legal questions. I wouldn't call the discussions on the list necessarily as "political" but rather non-actionable statements. Here is what I mean by that. Some of us try to take specific actions and that requires that you identify who needs to do what. There are things the IETF can do, but there are other communities as well. I tried to explain a simplified version of the Internet protocol development process in http://www.ietf.org/id/draft-tschofenig-perpass-surveillance-01.txt. As you can see different communities deal with different type of security vulnerabilities. Security problems are not a new thing - just check the OWASP top-10 security vulnerabilities of the last couple of years. These vulnerabilities are obviously be exploited by various folks (state actors, criminals, script kiddies, researchers, enterprise network administrators, etc.). A software that is vulnerable to, let's say, an SQL injection vulnerability is unfortunately not kind enough to take the motives, the organization, the hair colour, etc. of the attacker into account. Of course it would be possible to could come up with suggestions for other communities. But you have to start somewhere first. I don't see it as my task, for example, to tell the European Commission, the European Parliament, or the Council what they should be doing. I doubt that the IETF community would be interested in producing such recommendations. For everyone on the list who believes that regulators should take some actions then they should just approach them. It is just lame to say that others should do some work without even providing enough detail about what they should be doing. Ciao Hannes PS: I dislike the use of the term "politics", "policy makers", and alike. It just hides what you are really trying to say. Use other, more specific terms instead. For example, if you believe there is an action required by regulators then say "regulator". If you mean that the job is with enforcement agencies then say that. On 12/05/2013 09:55 AM, Robin Wilton wrote: > Thanks Elijah, this is a very useful perspective on the whole question of technologists' role - especially when the technology in question is so woven into our political, economic and personal lives. > > As you say, much of the work of the IETF has an inescapably political dimension - whether we choose to acknowledge that ourselves, or have it thrust upon us (Dual_EC_DRBG being a case in point). > > I apologise for re-using a well-worn phrase, but I think this reinforces the argument in favour of an open, multi-stakeholder process. That doesn't mean forcing economists and policymakers into the drafting sessions for RFCs, but it does mean creating a process that can take their (and others') input into account - and being able to articulate what we do in terms that make sense to other stakeholders. > > That approach isn't a guarantee against 'bad actors' exploiting the open nature of the process for their own ends, but compared to alternative ways of architecting and governing the Internet, it offers the best prospects of detecting and mitigating that kind of harm. > > Best wishes, > > Robin > > > > Robin Wilton > > Technical Outreach Director - Identity and Privacy > > On 5 Dec 2013, at 07:25, Elijah Sparrow wrote: > >> As an outsider to the IETF, and one-time sociologist, I found the repeated calls in Vancouver 88 and on this list for decisions to be made based solely on technical merit and not political argument to be extremely fascinating. >> >> There was once a time when the design of a protocol or standard could be done in a manner that benefited nearly everyone who might be touched by it. These days are surely past. Nearly every single debate or question that has come up on this list is deeply political, if for no other reason than whatever decisions are made will create winners and losers, people who benefit from the choice and people who are harmed by the choice. >> >> In the sweep of history, information capitalism has come to a moment of truth, where the material infrastructure that the IETF and technologists the world around have helped to create has now matured into both an economic engine and a state intelligence system based on mass surveillance. Perhaps the most distinguishing political debate of our time is how the power of the state and of business with respect to citizens and customers has been radically transformed under this new regime of ubiquitous surveillance. Obviously, I feel a particular way about this, but I am just stating the obvious: these issues are deeply political because the fragile balance of powers in liberal democracy and in our capitalist economies have been inexorably rocked by technological changes. >> >> In this context, the question of "how much encryption" is a technical question that is also deeply intertwined with the major political debates of our day. One only has to note the major headlines around the world about the ietf calls for encryption in http 2.0. How often have ietf meetings garnered such global coverage? >> >> Scientists and engineers are often forced into political arenas without their desire or foresight. Take, for example, the history of genomics, climate change, or nuclear physics. Historically, the scientists and engineers have clung desperately to the cloak of objective science, even as their work took on increasingly obvious political ramifications. My hope for the internet is that we could perhaps bypass such silliness and embrace the obvious political nature of our work. Being honest with ourselves does not push anyone toward any particular technical or political stance, except that perhaps we can be more transparent in our justifications. >> >> In the immortal words of Voltaire, and Spiderman, with great power comes great responsibility. >> >> -elijah >> >> -- >> I prefer encrypted email - https://bitmask.net/key/elijah. >> _______________________________________________ >> perpass mailing list >> perpass@ietf.org >> https://www.ietf.org/mailman/listinfo/perpass > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass --------------030901050204020807080902 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Robin, Elijah,

I am always curious how one manages to make a clear distinction between political decisions, technical decisions, economical decisions, and other decisions.

The perception that "in the early days of the Internet" the decisions were purely technical as too simplistic. If you look at specific decisions of individuals in the IETF it is hard to put them into specific categories. Even if you believe you see a purely technical decision it may have economical implications, or at some time interfere with other design goals. Take the HTTP state management work as an example. The introduction of cookies was a technical mechanism to keep state for the otherwise mostly stateless HTTP protocol. As we now know, the way how cookies have been used later by various Web companies lead to privacy concerns. This lead to the famous technical work on Do Not Track, which has technical components, business implications, and raises legal questions. 

I wouldn't call the discussions on the list necessarily as "political" but rather non-actionable statements. Here is what I mean by that.

Some of us try to take specific actions and that requires that you identify who needs to do what. There are things the IETF can do, but there are other communities as well. I tried to explain a simplified version of the Internet protocol development process in http://www.ietf.org/id/draft-tschofenig-perpass-surveillance-01.txt. As you can see different communities deal with different type of security vulnerabilities. Security problems are not a new thing - just check the OWASP top-10 security vulnerabilities of the last couple of years. These vulnerabilities are obviously be exploited by various folks (state actors, criminals, script kiddies, researchers, enterprise network administrators, etc.). A software that is vulnerable to, let's say, an SQL injection vulnerability is unfortunately not kind enough to take the motives, the organization, the hair colour, etc. of the attacker into account.

Of course it would be possible to could come up with suggestions for other communities. But you have to start somewhere first. I don't see it as my task, for example, to tell the European Commission, the European Parliament, or the Council what they should be doing. I doubt that the IETF community would be interested in producing such recommendations.

For everyone on the list who believes that regulators should take some actions then they should just approach them. It is just lame to say that others should do some work without even providing enough detail about what they should be doing.

Ciao
Hannes

PS: I dislike the use of the term "politics", "policy makers", and alike. It just hides what you are really trying to say. Use other, more specific terms instead. For example, if you believe there is an action required by regulators then say "regulator". If you mean that the job is with enforcement agencies then say that.

On 12/05/2013 09:55 AM, Robin Wilton wrote:
Thanks Elijah, this is a very useful perspective on the whole question of technologists' role - especially when the technology in question is so woven into our political, economic and personal lives.

As you say, much of the work of the IETF has an inescapably political dimension - whether we choose to acknowledge that ourselves, or have it thrust upon us (Dual_EC_DRBG being a case in point). 

I apologise for re-using a well-worn phrase, but I think this reinforces the argument in favour of an open, multi-stakeholder process. That doesn't mean forcing economists and policymakers into the drafting sessions for RFCs, but it does mean creating a process that can take their (and others') input into account - and being able to articulate what we do in terms that make sense to other stakeholders.

That approach isn't a guarantee against 'bad actors' exploiting the open nature of the process for their own ends, but compared to alternative ways of architecting and governing the Internet, it offers the best prospects of detecting and mitigating that kind of harm.

Best wishes,

Robin



Robin Wilton

Technical Outreach Director - Identity and Privacy

On 5 Dec 2013, at 07:25, Elijah Sparrow <elijah@bitmask.net> wrote:


As an outsider to the IETF, and one-time sociologist, I found the repeated calls in Vancouver 88 and on this list for decisions to be made based solely on technical merit and not political argument to be extremely fascinating.

There was once a time when the design of a protocol or standard could be done in a manner that benefited nearly everyone who might be touched by it. These days are surely past. Nearly every single debate or question that has come up on this list is deeply political, if for no other reason than whatever decisions are made will create winners and losers, people who benefit from the choice and people who are harmed by the choice.

In the sweep of history, information capitalism has come to a moment of truth, where the material infrastructure that the IETF and technologists the world around have helped to create has now matured into both an economic engine and a state intelligence system based on mass surveillance. Perhaps the most distinguishing political debate of our time is how the power of the state and of business with respect to citizens and customers has been radically transformed under this new regime of ubiquitous surveillance. Obviously, I feel a particular way about this, but I am just stating the obvious: these issues are deeply political because the fragile balance of powers in liberal democracy and in our capitalist economies have been inexorably rocked by technological changes.

In this context, the question of "how much encryption" is a technical question that is also deeply intertwined with the major political debates of our day. One only has to note the major headlines around the world about the ietf calls for encryption in http 2.0. How often have ietf meetings garnered such global coverage?

Scientists and engineers are often forced into political arenas without their desire or foresight. Take, for example, the history of genomics, climate change, or nuclear physics. Historically, the scientists and engineers have clung desperately to the cloak of objective science, even as their work took on increasingly obvious political ramifications. My hope for the internet is that we could perhaps bypass such silliness and embrace the obvious political nature of our work. Being honest with ourselves does not push anyone toward any particular technical or political stance, except that perhaps we can be more transparent in our justifications.

In the immortal words of Voltaire, and Spiderman, with great power comes great responsibility.

-elijah

--
I prefer encrypted email - https://bitmask.net/key/elijah.
_______________________________________________
perpass mailing list
perpass@ietf.org
https://www.ietf.org/mailman/listinfo/perpass

_______________________________________________
perpass mailing list
perpass@ietf.org
https://www.ietf.org/mailman/listinfo/perpass

--------------030901050204020807080902-- From Josh.Howlett@ja.net Thu Dec 5 02:53:19 2013 Return-Path: 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 8CE941ADF26; Thu, 5 Dec 2013 02:53:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 ytJmEQC7BWyk; Thu, 5 Dec 2013 02:53:17 -0800 (PST) Received: from egw001.ukerna.ac.uk (egw001.ukerna.ac.uk [194.82.140.74]) by ietfa.amsl.com (Postfix) with ESMTP id CBD731ADE72; Thu, 5 Dec 2013 02:53:16 -0800 (PST) Received: from egw001.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 12FB41AF2F0A_2A05B19B; Thu, 5 Dec 2013 10:53:13 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "staffmail.ja.net", Issuer "TERENA SSL CA" (verified OK)) by egw001.ukerna.ac.uk (Sophos Email Appliance) with ESMTPS id C04841AF2F0C_2A05B18F; Thu, 5 Dec 2013 10:53:12 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.03.0123.003; Thu, 5 Dec 2013 10:53:12 +0000 From: Josh Howlett To: Ted Lemon , "" Thread-Topic: Commnets on draft-farrell-perpass-attack-00 was RE: perens-perpass-appropriate-response-01 Thread-Index: AQHO8TzpP5tlkNSKykiLz/9Jsx4RUZpEodCAgADJ2QA= Date: Thu, 5 Dec 2013 10:53:12 +0000 Message-ID: References: <290E20B455C66743BE178C5C84F1240847E5103799@EXMB01CMS.surrey.ac.uk> <2C66A416-5F07-4803-A4C0-BB61734BA42E@nominum.com> In-Reply-To: <2C66A416-5F07-4803-A4C0-BB61734BA42E@nominum.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 05 Dec 2013 02:54:05 -0800 Cc: perpass , IETF Discussion , "bruce@perens.com" , "ietf-http-wg@w3.org" Subject: Re: [perpass] Commnets on draft-farrell-perpass-attack-00 was RE: 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 10:53:19 -0000 >> >>This is a political problem, not a technical problem. From a technical >>perspective, caching static content matters. Trying to figure out >>problems that aren't security problems matters. Mandating secure >>communications for worldwide http is pretty much the same as mandating >>secure encrypted email worldwide - large failure modes, resulting in an >>inability to communicate. Which is why use of secure email is not >>widespread. > >I take it you haven't been reading the responses to Bruce's essay, or you >would have seen that these points have already been discussed and refuted. Without naming specific territories, pervasive monitoring of the kind that has motivated this discussion has been imposed on a very large part of the world's Internet-connected population for many years, in full knowledge of the technical community (and, indeed, the educated layman); and allegedly assisted by some of the well-known vendors represented here. All that has happened is that the technical community, who are largely based in other world regions, has just discovered that it, too, has been subject to this pervasive monitoring. It is the indignation and affront arising from the sudden closure of the gap between expectation and reality that is driving this, not any novel specific technical threat or vulnerability. It is worth reflecting on what the reaction of the IAB/IESG might have been if these revelations had surfaced shortly before IETF 79, rather than around the bastions of liberalism in Berlin and Vancouver. Probably somewhat different. And let's not forget that many within the industry will have been aware of the generalities of the monitoring before the disclosures, even if they weren't familiar with the operational detail. This is, therefore, most assuredly a political problem. But that is not an argument not to increase security. I fully support action to increase security, where it responds to the prevailing threat environment. But it will be a perpetuation of the naivety that has characterised this debate to think that this alone will halt pervasive monitoring, because the threat is not technical in nature. The technical response must be coordinated with a political response, or else the perpetrators will find political means to route around the technical measures. The political response shouldn't be organised within the IETF, but it does need to liaise with those responsible for doing that. Unfortunately I am not observing any movement by any of the other parties within our wonderful multi-stakeholder system that you would think would be notionally responsible for this. My fear is that they are opting to drink the technology Kool-Aid, to avoid grasping the political nettle. That is what should be concerning us right now. Josh. Janet(UK) is a trading name of Jisc Collections and Janet Limited, a=20 not-for-profit company which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238 From stephen.farrell@cs.tcd.ie Thu Dec 5 03:10:05 2013 Return-Path: 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 8CEB31ADF38; Thu, 5 Dec 2013 03:10:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t6ARzWjCX7ZT; Thu, 5 Dec 2013 03:10:01 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 4CC4B1ADF26; Thu, 5 Dec 2013 03:10:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 10558BEE1; Thu, 5 Dec 2013 11:09:57 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CzKXkXgTL8RS; Thu, 5 Dec 2013 11:09:56 +0000 (GMT) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id C497ABE8B; Thu, 5 Dec 2013 11:09:56 +0000 (GMT) Message-ID: <52A05F05.3040506@cs.tcd.ie> Date: Thu, 05 Dec 2013 11:09:57 +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: Josh Howlett References: <290E20B455C66743BE178C5C84F1240847E5103799@EXMB01CMS.surrey.ac.uk> <2C66A416-5F07-4803-A4C0-BB61734BA42E@nominum.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: perpass , IETF Discussion Subject: Re: [perpass] Commnets on draft-farrell-perpass-attack-00 was RE: 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 11:10:05 -0000 Josh, On 12/05/2013 10:53 AM, Josh Howlett wrote: > > I fully support action to increase security, where it responds to the > prevailing threat environment. But it will be a perpetuation of the > naivety that has characterised this debate to think that this alone will > halt pervasive monitoring, because the threat is not technical in nature. Personally, I think anyone using the argument that "you can't solve the problem therefore do nothing" is talking about the same amount of nonsense as anyone who says "the IETF can halt pervasive monitoring." You don't quite say either of those above, but neither do you acknowledge that the draft in question, and all the sensible discussion (which is far from all the discussion;-) around that fully acknowledges that the technical things that can and should be done are only part of the story. > The technical response must be coordinated with a political response, or > else the perpetrators will find political means to route around the > technical measures. I disagree with "must be coordinated" for various reasons. Given the time it takes for us to do our part, which is measured in years before we get good deployment, imposing a requirement to start with coordination would mean doing nothing ever. Secondly, with whom would we coordinate? Again, trying to impose a requirement for coordination with a non-existent Internet-wide political entity is tantamount to doing nothing. If some other folks outside the IETF are working on the same issues that'll be good or bad, and for some such activities it'll be useful for us to know about and consider them. And maybe it'll be useful for others to know what we're up to, but we should not wait. > The political response shouldn't be organised within the IETF, but it does > need to liaise with those responsible for doing that. "The" political response? You expect only one? Again, I don't think we should hang around waiting - we should document the consensus from Vancouver and then follow that through in our normal work within working groups and elsewhere - considering threats, including this one, as we develop protocols. > Unfortunately I am > not observing any movement by any of the other parties within our > wonderful multi-stakeholder system that you would think would be > notionally responsible for this. My fear is that they are opting to drink > the technology Kool-Aid, to avoid grasping the political nettle. That is > what should be concerning us right now. Fully disagree. Its us should be grasping nettles and working to improve the security and privacy properties of our protocols. Regards, S. From mellon@fugue.com Thu Dec 5 04:27:18 2013 Return-Path: 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 A3B041ADF7B for ; Thu, 5 Dec 2013 04:27:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 NEVJIT904COw for ; Thu, 5 Dec 2013 04:27:16 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 8D6591ADF5D for ; Thu, 5 Dec 2013 04:27:16 -0800 (PST) Received: from [IPv6:2600:1000:b111:9324:48df:a9f5:36b3:33dc] (unknown [IPv6:2600:1000:b111:9324:48df:a9f5:36b3:33dc]) by toccata.fugue.com (Postfix) with ESMTPSA id 3EE4B23803AB; Thu, 5 Dec 2013 07:27:10 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ted Lemon In-Reply-To: <20131205072546.2740.2142915422.0@crow> Date: Thu, 5 Dec 2013 07:27:09 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <8B3C975C-2287-4A7B-969D-9C8568E5CEAB@fugue.com> References: <20131205072546.2740.2142915422.0@crow> To: Elijah Sparrow X-Mailer: Apple Mail (2.1822) Cc: perpass 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 12:27:18 -0000 Elijah, the IETF is well aware of politics, and has been for a long = time. Google "OSI layer 9" for a review. But what we mean by = politics is something very specific. You might get quite a few answers = from IETFers if you asked what "politics" is, but most of them would = boil down to this: a political argument is one where a person or group = of people bloviate loudly about some position they hold, but cannot or = will not expose the rationale for that position to the light of public = criticism. And the IETF has a strong, and I think important, tradition of trying = not to make decisions based on such bloviations. When we do, we = produce crap. When we stick to arguments that can be openly stated and = agreed upon, we produce goodness (at least often enough that people keep = coming). As for the question of great power and great responsibility, that's a = lovely sentiment, but it can mean whatever you want it to mean. We've = heard at least one person say that we should be careful not to do too = good a job, for fear of unstated but clearly bad consequences. I = personally think we should do a better job, because I know people who = have been victimized by 419 scams that couldn't have been perpetrated if = we had done a better job with SMTP. I also know people who have been = victimized and lost businesses because we didn't get security right in = HTTP. Bruce Schneier has a term that I really like, "movie plot threat," which = I think applies here. The reason the IETF insists on making decisions = in the open, and not accepting peoples' word that something really bad = might happen if we do X, but we can't say what it will be, is that = these arguments invariably boil down to "put these real people, with = real problems, here in the real world, at risk so that we can avoid a = movie plot threat scenario." This is actually a classic example of what we mean by "politics." From Josh.Howlett@ja.net Thu Dec 5 04:28:56 2013 Return-Path: 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 58EA61ADF9D; Thu, 5 Dec 2013 04:28:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 W0TrAT5olB2v; Thu, 5 Dec 2013 04:28:53 -0800 (PST) Received: from egw001.ukerna.ac.uk (egw001.ukerna.ac.uk [194.82.140.74]) by ietfa.amsl.com (Postfix) with ESMTP id BA3301ADF8D; Thu, 5 Dec 2013 04:28:52 -0800 (PST) Received: from egw001.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 3ED211AF3061_2A07180B; Thu, 5 Dec 2013 12:28:48 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "staffmail.ja.net", Issuer "TERENA SSL CA" (verified OK)) by egw001.ukerna.ac.uk (Sophos Email Appliance) with ESMTPS id E42AA1AF3053_2A0717FF; Thu, 5 Dec 2013 12:28:47 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.03.0123.003; Thu, 5 Dec 2013 12:28:46 +0000 From: Josh Howlett To: Stephen Farrell Thread-Topic: Commnets on draft-farrell-perpass-attack-00 was RE: perens-perpass-appropriate-response-01 Thread-Index: AQHO8TzpP5tlkNSKykiLz/9Jsx4RUZpEodCAgADJ2QCAAAbtgIAAFfcA Date: Thu, 5 Dec 2013 12:28:45 +0000 Message-ID: References: <290E20B455C66743BE178C5C84F1240847E5103799@EXMB01CMS.surrey.ac.uk> <2C66A416-5F07-4803-A4C0-BB61734BA42E@nominum.com> <52A05F05.3040506@cs.tcd.ie> In-Reply-To: <52A05F05.3040506@cs.tcd.ie> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-ID: <3C9554A19956144D925DC24F3E891E6D@ukerna.ac.uk> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: perpass , IETF Discussion Subject: Re: [perpass] Commnets on draft-farrell-perpass-attack-00 was RE: 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 12:28:56 -0000 Hi Stephen, I absolutely agree that the technical work is necessary, but it is not sufficient. The political environment controls the legal and regulatory environment within which CEOs, their lawyers, and the other minions whose role is to minimise corporate risk exposure, take the decisions on which products and services reach the market. The technical community can obviously choose to do the work regardless, but in the absence of conformant products and services it runs the risk of being a paper exercise. I am sympathetic to your argument that the technical work could happen in advance of policy, but that hands the advantage to the adversary who can use this intelligence to advance blocking political measures. I also agree that it is unfortunate that none of the numerous acronyms that claim to have a remit in Internet policy are working with the technical community. In the majority of the capitols of Europe there is clearly a political appetite to roll pervasive monitoring back, and these acronyms would be pushing on an open door (and, in fairness, perhaps they already are but it is not obvious to the outside world). It is not far from Geneva to Brussels... Josh. On 05/12/2013 11:09, "Stephen Farrell" wrote: > >Josh, > >On 12/05/2013 10:53 AM, Josh Howlett wrote: >>=20 >> I fully support action to increase security, where it responds to the >> prevailing threat environment. But it will be a perpetuation of the >> naivety that has characterised this debate to think that this alone will >> halt pervasive monitoring, because the threat is not technical in >>nature. > >Personally, I think anyone using the argument that "you can't solve >the problem therefore do nothing" is talking about the same amount >of nonsense as anyone who says "the IETF can halt pervasive monitoring." > >You don't quite say either of those above, but neither do you >acknowledge that the draft in question, and all the sensible discussion >(which is far from all the discussion;-) around that fully acknowledges >that the technical things that can and should be done are only part >of the story. > >> The technical response must be coordinated with a political response, or >> else the perpetrators will find political means to route around the >> technical measures. > >I disagree with "must be coordinated" for various reasons. > >Given the time it takes for us to do our part, which is measured >in years before we get good deployment, imposing a requirement >to start with coordination would mean doing nothing ever. > >Secondly, with whom would we coordinate? Again, trying to impose >a requirement for coordination with a non-existent Internet-wide >political entity is tantamount to doing nothing. > >If some other folks outside the IETF are working on the same >issues that'll be good or bad, and for some such activities it'll >be useful for us to know about and consider them. And maybe it'll >be useful for others to know what we're up to, but we should >not wait. > >> The political response shouldn't be organised within the IETF, but it >>does >> need to liaise with those responsible for doing that. > >"The" political response? You expect only one? Again, I don't >think we should hang around waiting - we should document the >consensus from Vancouver and then follow that through in our >normal work within working groups and elsewhere - considering >threats, including this one, as we develop protocols. > >> Unfortunately I am >> not observing any movement by any of the other parties within our >> wonderful multi-stakeholder system that you would think would be >> notionally responsible for this. My fear is that they are opting to >>drink >> the technology Kool-Aid, to avoid grasping the political nettle. That is >> what should be concerning us right now. > >Fully disagree. Its us should be grasping nettles and working >to improve the security and privacy properties of our protocols. > >Regards, >S. > Janet(UK) is a trading name of Jisc Collections and Janet Limited, a=20 not-for-profit company which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238 From stephen.farrell@cs.tcd.ie Thu Dec 5 04:40:51 2013 Return-Path: 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 BFB491ADF99; Thu, 5 Dec 2013 04:40:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3-bFZMXJ64Wc; Thu, 5 Dec 2013 04:40:48 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 0CB761ADFA1; Thu, 5 Dec 2013 04:40:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 0773CBEC3; Thu, 5 Dec 2013 12:40:44 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YOzGl+WhXeGT; Thu, 5 Dec 2013 12:40:43 +0000 (GMT) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id D54CEBE3F; Thu, 5 Dec 2013 12:40:43 +0000 (GMT) Message-ID: <52A0744C.8030501@cs.tcd.ie> Date: Thu, 05 Dec 2013 12:40:44 +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: Josh Howlett References: <290E20B455C66743BE178C5C84F1240847E5103799@EXMB01CMS.surrey.ac.uk> <2C66A416-5F07-4803-A4C0-BB61734BA42E@nominum.com> <52A05F05.3040506@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: perpass , IETF Discussion Subject: Re: [perpass] Commnets on draft-farrell-perpass-attack-00 was RE: 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 12:40:51 -0000 Josh, On 12/05/2013 12:28 PM, Josh Howlett wrote: > Hi Stephen, > > I absolutely agree that the technical work is necessary, but it is not > sufficient. So you agree this draft is necessary? If so, good. Nobody (sensible) claimed it was sufficient by itself to stop pervasive monitoring. It can nonetheless improve the Internet in any case, both when considering the pervasive monitoring threat and other threats. If e.g. the UTA WG is chartered later today then what they're going to do, which is directly spurred by this overall discussion, could significantly improve e.g. SMTP security. > The political environment controls the legal and regulatory environment > within which CEOs, their lawyers, and the other minions whose role is to > minimise corporate risk exposure, take the decisions on which products and > services reach the market. > > The technical community can obviously choose to do the work regardless, > but in the absence of conformant products and services it runs the risk of > being a paper exercise. That seems to apply to any new work that anyone does in the IETF and is not a reason to do nothing. > I am sympathetic to your argument that the technical work could happen in > advance of policy, That is not my argument. The technical work should happen and for technical reasons. > but that hands the advantage to the adversary who can > use this intelligence to advance blocking political measures. Game theory is fun, but not particularly productive for this draft IMO. That'd be more relevant for specific bits of protocol work where it might be the case that one could consider how an adversary could react to a particular mitigation for this or other threats. At the level of this draft I don't think there's anything useful to be done in that respect. Cheers, S. > > I also agree that it is unfortunate that none of the numerous acronyms > that claim to have a remit in Internet policy are working with the > technical community. In the majority of the capitols of Europe there is > clearly a political appetite to roll pervasive monitoring back, and these > acronyms would be pushing on an open door (and, in fairness, perhaps they > already are but it is not obvious to the outside world). It is not far > from Geneva to Brussels... > > Josh. > > On 05/12/2013 11:09, "Stephen Farrell" wrote: > >> >> Josh, >> >> On 12/05/2013 10:53 AM, Josh Howlett wrote: >>> >>> I fully support action to increase security, where it responds to the >>> prevailing threat environment. But it will be a perpetuation of the >>> naivety that has characterised this debate to think that this alone will >>> halt pervasive monitoring, because the threat is not technical in >>> nature. >> >> Personally, I think anyone using the argument that "you can't solve >> the problem therefore do nothing" is talking about the same amount >> of nonsense as anyone who says "the IETF can halt pervasive monitoring." >> >> You don't quite say either of those above, but neither do you >> acknowledge that the draft in question, and all the sensible discussion >> (which is far from all the discussion;-) around that fully acknowledges >> that the technical things that can and should be done are only part >> of the story. >> >>> The technical response must be coordinated with a political response, or >>> else the perpetrators will find political means to route around the >>> technical measures. >> >> I disagree with "must be coordinated" for various reasons. >> >> Given the time it takes for us to do our part, which is measured >> in years before we get good deployment, imposing a requirement >> to start with coordination would mean doing nothing ever. >> >> Secondly, with whom would we coordinate? Again, trying to impose >> a requirement for coordination with a non-existent Internet-wide >> political entity is tantamount to doing nothing. >> >> If some other folks outside the IETF are working on the same >> issues that'll be good or bad, and for some such activities it'll >> be useful for us to know about and consider them. And maybe it'll >> be useful for others to know what we're up to, but we should >> not wait. >> >>> The political response shouldn't be organised within the IETF, but it >>> does >>> need to liaise with those responsible for doing that. >> >> "The" political response? You expect only one? Again, I don't >> think we should hang around waiting - we should document the >> consensus from Vancouver and then follow that through in our >> normal work within working groups and elsewhere - considering >> threats, including this one, as we develop protocols. >> >>> Unfortunately I am >>> not observing any movement by any of the other parties within our >>> wonderful multi-stakeholder system that you would think would be >>> notionally responsible for this. My fear is that they are opting to >>> drink >>> the technology Kool-Aid, to avoid grasping the political nettle. That is >>> what should be concerning us right now. >> >> Fully disagree. Its us should be grasping nettles and working >> to improve the security and privacy properties of our protocols. >> >> Regards, >> S. >> > > > Janet(UK) is a trading name of Jisc Collections and Janet Limited, a > not-for-profit company which is registered in England under No. 2881024 > and whose Registered Office is at Lumen House, Library Avenue, > Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238 > > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > > From hhalpin@w3.org Thu Dec 5 05:47:07 2013 Return-Path: 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 381E71ADFE2 for ; Thu, 5 Dec 2013 05:47:07 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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 tYut5W5NjCJl for ; Thu, 5 Dec 2013 05:47:02 -0800 (PST) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id 34C441ADF99 for ; Thu, 5 Dec 2013 05:46:58 -0800 (PST) Received: from 155.210.19.93.rev.sfr.net ([93.19.210.155] helo=[192.168.1.93]) by jay.w3.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1VoZGV-0000dP-7D; Thu, 05 Dec 2013 08:46:51 -0500 Message-ID: <52A083C2.3030405@w3.org> Date: Thu, 05 Dec 2013 14:46:42 +0100 From: Harry Halpin User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Hannes Tschofenig , Robin Wilton , Elijah Sparrow References: <20131205072546.2740.2142915422.0@crow> <529F8F94.3020506@gmx.net> In-Reply-To: <529F8F94.3020506@gmx.net> Content-Type: multipart/alternative; boundary="------------040803070708010608090505" Cc: "perpass@ietf.org" 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 13:47:07 -0000 This is a multi-part message in MIME format. --------------040803070708010608090505 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 12/04/2013 09:24 PM, Hannes Tschofenig wrote: > Robin, Elijah, > > I am always curious how one manages to make a clear distinction > between political decisions, technical decisions, economical > decisions, and other decisions. Political decisions have to deal with sovereignty: Who makes binding decisions. I think what has escaped lots of folks in Internet governance is that now the Internet is at the centre of rather important political struggles over decision-making. The problem is "who" is making these decisions. Right now, for standards it's an open multi-stakeholder process that at least we who are involved in places like the IETF believes make technical decisions, but these decisions only have binding force insofar as they provide enough economic advantage that vendors implement them uniformly. However, we should never forget that the very process of making decisions means that standards bodies are *always* political in this large sense of making decisions. After all, it is very possible that some vendors and countries can go away and make their own decisions without the traditional Internet open and voluntary standards bodies, and bind their new technologies via the threat of coercive violence. While we have name-calling on IETF mailing lists, I'm not aware of coercive violence anywhere. I'm hoping we can bear the responsibility of creating an Internet free of pervasive surveillance. And we should be aware that even if we are successful in this, other pre-Internet political bodies ranging from nation-states to vendors will try to strip out whatever safeguards we try to put in in order to continue the value they gain from surveillance. A conflict between different bodies, each with its own plans for the future and its own overlapping sphere of decision-making, is self-evidently a political struggle. > > The perception that "in the early days of the Internet" the decisions > were purely technical as too simplistic. If you look at specific > decisions of individuals in the IETF it is hard to put them into > specific categories. Even if you believe you see a purely technical > decision it may have economical implications, or at some time > interfere with other design goals. Take the HTTP state management work > as an example. The introduction of cookies was a technical mechanism > to keep state for the otherwise mostly stateless HTTP protocol. As we > now know, the way how cookies have been used later by various Web > companies lead to privacy concerns. This lead to the famous technical > work on Do Not Track, which has technical components, business > implications, and raises legal questions. 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. > > I wouldn't call the discussions on the list necessarily as "political" > but rather non-actionable statements. Here is what I mean by that. > > Some of us try to take specific actions and that requires that you > identify who needs to do what. There are things the IETF can do, but > there are other communities as well. I tried to explain a simplified > version of the Internet protocol development process in > http://www.ietf.org/id/draft-tschofenig-perpass-surveillance-01.txt. > As you can see different communities deal with different type of > security vulnerabilities. Security problems are not a new thing - just > check the OWASP top-10 security vulnerabilities of the last couple of > years. These vulnerabilities are obviously be exploited by various > folks (state actors, criminals, script kiddies, researchers, > enterprise network administrators, etc.). A software that is > vulnerable to, let's say, an SQL injection vulnerability is > unfortunately not kind enough to take the motives, the organization, > the hair colour, etc. of the attacker into account. > > Of course it would be possible to could come up with suggestions for > other communities. But you have to start somewhere first. I don't see > it as my task, for example, to tell the European Commission, the > European Parliament, or the Council what they should be doing. I doubt > that the IETF community would be interested in producing such > recommendations. I think they'd want to create broad mandates based on policy decisions (hopefully made with consent or even involvement of general population) that then are respected by the details of technical standards bodies. Of course, that's not usually how it works in practice with governments, who tend to either overspecify technical details or do not actually represent the consent of their population in any meaningful sense of the term. > > For everyone on the list who believes that regulators should take some > actions then they should just approach them. It is just lame to say > that others should do some work without even providing enough detail > about what they should be doing. > > Ciao > Hannes > > PS: I dislike the use of the term "politics", "policy makers", and > alike. It just hides what you are really trying to say. Use other, > more specific terms instead. For example, if you believe there is an > action required by regulators then say "regulator". If you mean that > the job is with enforcement agencies then say that. In general, regulators are at the bequest of their government, who at the present moment is often in thrall of lobbies that prevent anything resembling effective regulation. There are political processes that do not have regulatory power per se but have the power to nonetheless mobilize actors (thinking ACTA/SOPA protests) that have the ability to change the decisions of sovereign bodies. So I don't think "politics" is the wrong word or empty word. Hopefully the IETF - with the help of ISOC of course - and others can continue to interface open, meritocratic political Internet processes with traditional per-Internet political actors. cheers, harry > > On 12/05/2013 09:55 AM, Robin Wilton wrote: >> Thanks Elijah, this is a very useful perspective on the whole question of technologists' role - especially when the technology in question is so woven into our political, economic and personal lives. >> >> As you say, much of the work of the IETF has an inescapably political dimension - whether we choose to acknowledge that ourselves, or have it thrust upon us (Dual_EC_DRBG being a case in point). >> >> I apologise for re-using a well-worn phrase, but I think this reinforces the argument in favour of an open, multi-stakeholder process. That doesn't mean forcing economists and policymakers into the drafting sessions for RFCs, but it does mean creating a process that can take their (and others') input into account - and being able to articulate what we do in terms that make sense to other stakeholders. >> >> That approach isn't a guarantee against 'bad actors' exploiting the open nature of the process for their own ends, but compared to alternative ways of architecting and governing the Internet, it offers the best prospects of detecting and mitigating that kind of harm. >> >> Best wishes, >> >> Robin >> >> >> >> Robin Wilton >> >> Technical Outreach Director - Identity and Privacy >> >> On 5 Dec 2013, at 07:25, Elijah Sparrow wrote: >> >>> As an outsider to the IETF, and one-time sociologist, I found the repeated calls in Vancouver 88 and on this list for decisions to be made based solely on technical merit and not political argument to be extremely fascinating. >>> >>> There was once a time when the design of a protocol or standard could be done in a manner that benefited nearly everyone who might be touched by it. These days are surely past. Nearly every single debate or question that has come up on this list is deeply political, if for no other reason than whatever decisions are made will create winners and losers, people who benefit from the choice and people who are harmed by the choice. >>> >>> In the sweep of history, information capitalism has come to a moment of truth, where the material infrastructure that the IETF and technologists the world around have helped to create has now matured into both an economic engine and a state intelligence system based on mass surveillance. Perhaps the most distinguishing political debate of our time is how the power of the state and of business with respect to citizens and customers has been radically transformed under this new regime of ubiquitous surveillance. Obviously, I feel a particular way about this, but I am just stating the obvious: these issues are deeply political because the fragile balance of powers in liberal democracy and in our capitalist economies have been inexorably rocked by technological changes. >>> >>> In this context, the question of "how much encryption" is a technical question that is also deeply intertwined with the major political debates of our day. One only has to note the major headlines around the world about the ietf calls for encryption in http 2.0. How often have ietf meetings garnered such global coverage? >>> >>> Scientists and engineers are often forced into political arenas without their desire or foresight. Take, for example, the history of genomics, climate change, or nuclear physics. Historically, the scientists and engineers have clung desperately to the cloak of objective science, even as their work took on increasingly obvious political ramifications. My hope for the internet is that we could perhaps bypass such silliness and embrace the obvious political nature of our work. Being honest with ourselves does not push anyone toward any particular technical or political stance, except that perhaps we can be more transparent in our justifications. >>> >>> In the immortal words of Voltaire, and Spiderman, with great power comes great responsibility. >>> >>> -elijah >>> >>> -- >>> I prefer encrypted email -https://bitmask.net/key/elijah. >>> _______________________________________________ >>> perpass mailing list >>> perpass@ietf.org >>> https://www.ietf.org/mailman/listinfo/perpass >> _______________________________________________ >> perpass mailing list >> perpass@ietf.org >> https://www.ietf.org/mailman/listinfo/perpass > > > > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass --------------040803070708010608090505 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 12/04/2013 09:24 PM, Hannes Tschofenig wrote:
Robin, Elijah,

I am always curious how one manages to make a clear distinction between political decisions, technical decisions, economical decisions, and other decisions.

Political decisions have to deal with sovereignty: Who makes binding decisions. I think what has escaped lots of folks in Internet governance is that now the Internet is at the centre of rather important political struggles over decision-making.

The problem is "who" is making these decisions. Right now, for standards it's an open multi-stakeholder process that at least we who are involved in places like the IETF believes make technical decisions, but these decisions only have binding force insofar as they provide enough economic advantage that vendors implement them uniformly.

However, we should never forget that the very process of making decisions means that standards bodies are *always* political in this large sense of making decisions. After all, it is very possible that some vendors and countries can go away and make their own decisions without the traditional Internet open and voluntary standards bodies, and bind their new technologies via the threat of coercive violence. While we have name-calling on IETF mailing lists, I'm not aware of coercive violence anywhere.

I'm hoping we can bear the responsibility of creating an Internet free of pervasive surveillance. And we should be aware that even if we are successful in this, other pre-Internet political bodies ranging from nation-states to vendors will try to strip out whatever safeguards we try to put in in order to continue the value they gain from surveillance. A conflict between different bodies, each with its own plans for the future and its own overlapping sphere of decision-making, is self-evidently a political struggle.


The perception that "in the early days of the Internet" the decisions were purely technical as too simplistic. If you look at specific decisions of individuals in the IETF it is hard to put them into specific categories. Even if you believe you see a purely technical decision it may have economical implications, or at some time interfere with other design goals. Take the HTTP state management work as an example. The introduction of cookies was a technical mechanism to keep state for the otherwise mostly stateless HTTP protocol. As we now know, the way how cookies have been used later by various Web companies lead to privacy concerns. This lead to the famous technical work on Do Not Track, which has technical components, business implications, and raises legal questions. 

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.

I wouldn't call the discussions on the list necessarily as "political" but rather non-actionable statements. Here is what I mean by that.

Some of us try to take specific actions and that requires that you identify who needs to do what. There are things the IETF can do, but there are other communities as well. I tried to explain a simplified version of the Internet protocol development process in http://www.ietf.org/id/draft-tschofenig-perpass-surveillance-01.txt. As you can see different communities deal with different type of security vulnerabilities. Security problems are not a new thing - just check the OWASP top-10 security vulnerabilities of the last couple of years. These vulnerabilities are obviously be exploited by various folks (state actors, criminals, script kiddies, researchers, enterprise network administrators, etc.). A software that is vulnerable to, let's say, an SQL injection vulnerability is unfortunately not kind enough to take the motives, the organization, the hair colour, etc. of the attacker into account.

Of course it would be possible to could come up with suggestions for other communities. But you have to start somewhere first. I don't see it as my task, for example, to tell the European Commission, the European Parliament, or the Council what they should be doing. I doubt that the IETF community would be interested in producing such recommendations.

I think they'd want to create broad mandates based on policy decisions (hopefully made with consent or even involvement of general population) that then are respected by the details of technical standards bodies. Of course, that's not usually how it works in practice with governments, who tend to either overspecify technical details or do not actually represent the consent of their population in any meaningful sense of the term.


For everyone on the list who believes that regulators should take some actions then they should just approach them. It is just lame to say that others should do some work without even providing enough detail about what they should be doing.

Ciao
Hannes

PS: I dislike the use of the term "politics", "policy makers", and alike. It just hides what you are really trying to say. Use other, more specific terms instead. For example, if you believe there is an action required by regulators then say "regulator". If you mean that the job is with enforcement agencies then say that.
In general, regulators are at the bequest of their government, who at the present moment is often in thrall of lobbies that prevent anything resembling effective regulation. There are political processes that do not have regulatory power per se but have the power to nonetheless mobilize actors (thinking ACTA/SOPA protests) that have the ability to change the decisions of sovereign bodies.

 So I don't think "politics" is the wrong word or empty word. Hopefully the IETF - with the help of ISOC of course - and others can continue to interface open, meritocratic political Internet processes with traditional per-Internet political actors.

 cheers,

           harry



On 12/05/2013 09:55 AM, Robin Wilton wrote:
Thanks Elijah, this is a very useful perspective on the whole question of technologists' role - especially when the technology in question is so woven into our political, economic and personal lives.

As you say, much of the work of the IETF has an inescapably political dimension - whether we choose to acknowledge that ourselves, or have it thrust upon us (Dual_EC_DRBG being a case in point). 

I apologise for re-using a well-worn phrase, but I think this reinforces the argument in favour of an open, multi-stakeholder process. That doesn't mean forcing economists and policymakers into the drafting sessions for RFCs, but it does mean creating a process that can take their (and others') input into account - and being able to articulate what we do in terms that make sense to other stakeholders.

That approach isn't a guarantee against 'bad actors' exploiting the open nature of the process for their own ends, but compared to alternative ways of architecting and governing the Internet, it offers the best prospects of detecting and mitigating that kind of harm.

Best wishes,

Robin



Robin Wilton

Technical Outreach Director - Identity and Privacy

On 5 Dec 2013, at 07:25, Elijah Sparrow <elijah@bitmask.net> wrote:


As an outsider to the IETF, and one-time sociologist, I found the repeated calls in Vancouver 88 and on this list for decisions to be made based solely on technical merit and not political argument to be extremely fascinating.

There was once a time when the design of a protocol or standard could be done in a manner that benefited nearly everyone who might be touched by it. These days are surely past. Nearly every single debate or question that has come up on this list is deeply political, if for no other reason than whatever decisions are made will create winners and losers, people who benefit from the choice and people who are harmed by the choice.

In the sweep of history, information capitalism has come to a moment of truth, where the material infrastructure that the IETF and technologists the world around have helped to create has now matured into both an economic engine and a state intelligence system based on mass surveillance. Perhaps the most distinguishing political debate of our time is how the power of the state and of business with respect to citizens and customers has been radically transformed under this new regime of ubiquitous surveillance. Obviously, I feel a particular way about this, but I am just stating the obvious: these issues are deeply political because the fragile balance of powers in liberal democracy and in our capitalist economies have been inexorably rocked by technological changes.

In this context, the question of "how much encryption" is a technical question that is also deeply intertwined with the major political debates of our day. One only has to note the major headlines around the world about the ietf calls for encryption in http 2.0. How often have ietf meetings garnered such global coverage?

Scientists and engineers are often forced into political arenas without their desire or foresight. Take, for example, the history of genomics, climate change, or nuclear physics. Historically, the scientists and engineers have clung desperately to the cloak of objective science, even as their work took on increasingly obvious political ramifications. My hope for the internet is that we could perhaps bypass such silliness and embrace the obvious political nature of our work. Being honest with ourselves does not push anyone toward any particular technical or political stance, except that perhaps we can be more transparent in our justifications.

In the immortal words of Voltaire, and Spiderman, with great power comes great responsibility.

-elijah

--
I prefer encrypted email - https://bitmask.net/key/elijah.
_______________________________________________
perpass mailing list
perpass@ietf.org
https://www.ietf.org/mailman/listinfo/perpass

_______________________________________________
perpass mailing list
perpass@ietf.org
https://www.ietf.org/mailman/listinfo/perpass




_______________________________________________
perpass mailing list
perpass@ietf.org
https://www.ietf.org/mailman/listinfo/perpass

--------------040803070708010608090505-- From joe@cdt.org Thu Dec 5 06:09:14 2013 Return-Path: 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 BCB571ADFD0 for ; Thu, 5 Dec 2013 06:09:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 aTId3ajRyUJl for ; Thu, 5 Dec 2013 06:09:12 -0800 (PST) Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by ietfa.amsl.com (Postfix) with ESMTP id B822A1ADF10 for ; Thu, 5 Dec 2013 06:09:11 -0800 (PST) X-Footer: Y2R0Lm9yZw== Received: from localhost ([127.0.0.1]) by mail.maclaboratory.net (using TLSv1/SSLv3 with cipher AES256-SHA (256 bits)) for perpass@ietf.org; Thu, 5 Dec 2013 09:09:06 -0500 Message-ID: <52A08902.6050509@cdt.org> Date: Thu, 05 Dec 2013 09:09:06 -0500 From: Joseph Lorenzo Hall User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: perpass@ietf.org References: <529E8494.7000806@perens.com> <20131204111309.GB11727@nic.fr> <529F61D8.6030105@perens.com> In-Reply-To: <529F61D8.6030105@perens.com> 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-BeenThere: perpass@ietf.org 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: Thu, 05 Dec 2013 14:09:15 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 12/4/13 12:09 PM, Bruce Perens wrote: > > The potential is that you could be giving aid and comfort to "the > enemy" by constructing a technical hinderance to intelligence > gathering by your own national intelligence agency or by your > country's intelligence partners. It looks from here that this falls > under the later paragraphs of France's penal code definition of > treason. (apologies this is long... hopefully it's fun to read) Hi Bruce, It's probably been a bit less than a decade since last we spoke, I hope you are well. Like many, I find much to disagree with in your draft response. First, I wouldn't use the adjective "political" but "policy" indicating that in addition to the technical side of communications infrastructure, there are also norms, rules, and laws to which we as a society agree (either globally through commitments to human rights or locally through culture, laws, and norms). There are many of us -- although I'd say not nearly enough, we're all hiring! -- that work in the policy space and try to advocate carefully for why the current state of affairs (and where entities like the USG want to go in the future) can not stand. A democracy is not a democracy if it is in a constant state of pervasive surveillance. At CDT we've worked with many people on this list -- and whome you likely know -- to advocate for infrastructural security and to point out that many, many countries are involved in essentially attacking users against the more broad public interest: https://www.cdt.org/files/pdfs/CALEAII-techreport.pdf https://www.cdt.org/files/pdfs/nsa-review-panel-tech-comment.pdf On the "downstream side, many of you may have missed this 2-year effort (before Snowden!!) to document "systematic access", or governments of the world demanding access to data the private sector holds... i.e., it's certainly not just the U.S. or FVEY countries exploiting data the private sector holds but increasingly every sovereign entity (note one of the authors, Lee, was a former general counsel to the NSA): https://www.cdt.org/systematic-access https://cdt.org/files/pdfs/govaccess2013/government-access-to-data-comparative-analysis.pdf The reason I excerpted what you say above is the following: just like it used to be many decades ago, the government cannot tap everything. That is a fact. There are methods of communication that it will not be able to tap, and there will be standards and tools that enable highly secure communication. It seems overwhelmingly rational to protect communications against strong adversaries in the passive case ("upstream" so to speak) and to beef up but not eliminate methods of surveillance that are both legal and further the public interest in safety as narrowly as possible. The reason the NSA, CIA, etc. in the US and FVEY countries can collect so much information is a combination of path dependence -- standards did not contemplated pervasive threats and our daily lives are increasingly mediated by protocols -- and over-zealous "we can, so we will" thinking inspired by a state of terror. Let me say that more clearly: if terrorism's goal is to put a populace into a state of terror, this has certainly been accomplished for our intelligence agencies, who justify any encroachment on the lives of normal citizens as "why not? if it saves 1 person"... without thinking about the very Heisenbergian conundrum that the act of pervasive surveillance -- and not just how it is executed -- will undoubtedly move us farther from democracy (and yes there are many other things that affect that... e.g., campaign finance, voting technology, and voting rights). What I would like to see is a recognition and acceptance that there will be secrets that governments can not know, and that they will inevitably have to get back to actual police work -- not exploiting the fabric of globally digital society. This is why it is imperative to many of us to make sure the technical side supports this to the best of our ability... as Nick said later on this thread, without pervasive encryption we are vulnerable to numerous adversaries, despite what you think of their intentions and goals (and effectiveness, as Jake rightly notes, is simply a joke). best, Joe - -- Joseph Lorenzo Hall Chief Technologist Center for Democracy & Technology 1634 I ST NW STE 1100 Washington DC 20006-4011 (p) 202-407-8825 (f) 202-637-0968 joe@cdt.org PGP: https://josephhall.org/gpg-key fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSoIkCAAoJEF+GaYdAqahxo2kP+wdYMOrOKLiQMi5DvVsbEBGh pXFZyyWvkIvsH8FSIKIY/+aOrLBuQ2ibqWNxdZqCtTomzCCjbpGkZWDm2LHYXSVG iTI/gTzL8wFbr9jIbtA2Rw1fnvfp6bxwCFv71/xRTXi4hLMbh979nkMkwx8i6pdH t9tc1R8G/pfbJ1ze93RNX7E+fm51ILvCIJPTqc6Tq+uZbcwA/55aXeWcymRtte72 AwygyLkGmy0En0G6tMovCKFIZO39KDr7ITcz/2pJJP0W/+yL8n8rH1RLy4+ZL7va SVYvteSi9rEsCs9HfLGprlvtZYWmSHSwkufrdmXSSteOqhzukQu9qcO7bHGkowpn CDpwl3WdZ/B44nxLBCM3BOQa4CKx2tCjNvtmkLcny6svhZnjS8O3LXhfX2WWxFah Cjdfd2HQIbDmc3ORTfwYPluKVHMgvEOTDUgYQIvigyCi20nOLbWM+cBPp47TC+9A +NcvzDDxt0c+KyX59K5ztbRMj/vEJ7A+IO0pJtaZp639BI4uU3RrRQ/3Iubt/hxp a1/keKsISpsAHRYa4rgJzZ0bZDY7xvfpKLzwkTM6Ue+w16+Vook+8qqrQE7Xf8/3 /6wmScJe8faddoNnnW5TQDVUmQxFFkK9RDGX0Nw/9euV79SIBqyl2ncHMBZOSi0I NMSTq+VVhg4RbdMwI2Su =SNG+ -----END PGP SIGNATURE----- From Josh.Howlett@ja.net Thu Dec 5 06:41:43 2013 Return-Path: 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 6BD561AE028; Thu, 5 Dec 2013 06:41:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 3M6Y0lWJMKiK; Thu, 5 Dec 2013 06:41:40 -0800 (PST) Received: from egw002.ukerna.ac.uk (egw002.ukerna.ac.uk [194.81.3.65]) by ietfa.amsl.com (Postfix) with ESMTP id 1AD901ADFD0; Thu, 5 Dec 2013 06:41:40 -0800 (PST) Received: from egw002.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 0D72920CABC6_2A0909FB; Thu, 5 Dec 2013 14:41:35 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "staffmail.ja.net", Issuer "TERENA SSL CA" (verified OK)) by egw002.ukerna.ac.uk (Sophos Email Appliance) with ESMTPS id 3334820C724E_2A0909EF; Thu, 5 Dec 2013 14:41:34 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.03.0123.003; Thu, 5 Dec 2013 14:41:33 +0000 From: Josh Howlett To: Stephen Farrell Thread-Topic: [perpass] Commnets on draft-farrell-perpass-attack-00 was RE: perens-perpass-appropriate-response-01 Thread-Index: AQHO8TzpP5tlkNSKykiLz/9Jsx4RUZpEodCAgADJ2QCAAAbtgIAAFfcAgAADZgCAACHCgQ== Date: Thu, 5 Dec 2013 14:41:33 +0000 Message-ID: <55DC663C2F4F9F439F23543E0078E8B39A183AE7@EXC001> References: <290E20B455C66743BE178C5C84F1240847E5103799@EXMB01CMS.surrey.ac.uk> <2C66A416-5F07-4803-A4C0-BB61734BA42E@nominum.com> <52A05F05.3040506@cs.tcd.ie> ,<52A0744C.8030501@cs.tcd.ie> In-Reply-To: <52A0744C.8030501@cs.tcd.ie> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: perpass , IETF Discussion Subject: Re: [perpass] Commnets on draft-farrell-perpass-attack-00 was RE: 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 14:41:43 -0000 Stephen, Yes I agree its necessary, but its not the hard part of the problem. We are= focusing on implementation detail, at the expense of the meaty political p= roblems; namely, (1) establishing the level of monitoring civil society is = willing to tolerate (on the spectrum none to pervasive) and (2) building wh= atever legislative consensus is necessary to enforce that. Moving straight = to (3) the solution space may deliver specs and running code, but not the m= otivations to deploy it (or worse, incentives not to). I applaud the effort= , even if it only serves to incrementally improve on the status quo, but gi= ven your adversaries I fear it is already doomed before it has started. Ser= iously, best of luck anyway :-) Josh. ________________________________ From: Stephen Farrell Sent: =E2=80=8E05/=E2=80=8E12/=E2=80=8E2013 12:41 To: Josh Howlett Cc: perpass; IETF Discussion Subject: Re: [perpass] Commnets on draft-farrell-perpass-attack-00 was RE: = perens-perpass-appropriate-response-01 Josh, On 12/05/2013 12:28 PM, Josh Howlett wrote: > Hi Stephen, > > I absolutely agree that the technical work is necessary, but it is not > sufficient. So you agree this draft is necessary? If so, good. Nobody (sensible) claimed it was sufficient by itself to stop pervasive monitoring. It can nonetheless improve the Internet in any case, both when considering the pervasive monitoring threat and other threats. If e.g. the UTA WG is chartered later today then what they're going to do, which is directly spurred by this overall discussion, could significantly improve e.g. SMTP security. > The political environment controls the legal and regulatory environment > within which CEOs, their lawyers, and the other minions whose role is to > minimise corporate risk exposure, take the decisions on which products and > services reach the market. > > The technical community can obviously choose to do the work regardless, > but in the absence of conformant products and services it runs the risk of > being a paper exercise. That seems to apply to any new work that anyone does in the IETF and is not a reason to do nothing. > I am sympathetic to your argument that the technical work could happen in > advance of policy, That is not my argument. The technical work should happen and for technical reasons. > but that hands the advantage to the adversary who can > use this intelligence to advance blocking political measures. Game theory is fun, but not particularly productive for this draft IMO. That'd be more relevant for specific bits of protocol work where it might be the case that one could consider how an adversary could react to a particular mitigation for this or other threats. At the level of this draft I don't think there's anything useful to be done in that respect. Cheers, S. > > I also agree that it is unfortunate that none of the numerous acronyms > that claim to have a remit in Internet policy are working with the > technical community. In the majority of the capitols of Europe there is > clearly a political appetite to roll pervasive monitoring back, and these > acronyms would be pushing on an open door (and, in fairness, perhaps they > already are but it is not obvious to the outside world). It is not far > from Geneva to Brussels... > > Josh. > > On 05/12/2013 11:09, "Stephen Farrell" wrote: > >> >> Josh, >> >> On 12/05/2013 10:53 AM, Josh Howlett wrote: >>> >>> I fully support action to increase security, where it responds to the >>> prevailing threat environment. But it will be a perpetuation of the >>> naivety that has characterised this debate to think that this alone will >>> halt pervasive monitoring, because the threat is not technical in >>> nature. >> >> Personally, I think anyone using the argument that "you can't solve >> the problem therefore do nothing" is talking about the same amount >> of nonsense as anyone who says "the IETF can halt pervasive monitoring." >> >> You don't quite say either of those above, but neither do you >> acknowledge that the draft in question, and all the sensible discussion >> (which is far from all the discussion;-) around that fully acknowledges >> that the technical things that can and should be done are only part >> of the story. >> >>> The technical response must be coordinated with a political response, or >>> else the perpetrators will find political means to route around the >>> technical measures. >> >> I disagree with "must be coordinated" for various reasons. >> >> Given the time it takes for us to do our part, which is measured >> in years before we get good deployment, imposing a requirement >> to start with coordination would mean doing nothing ever. >> >> Secondly, with whom would we coordinate? Again, trying to impose >> a requirement for coordination with a non-existent Internet-wide >> political entity is tantamount to doing nothing. >> >> If some other folks outside the IETF are working on the same >> issues that'll be good or bad, and for some such activities it'll >> be useful for us to know about and consider them. And maybe it'll >> be useful for others to know what we're up to, but we should >> not wait. >> >>> The political response shouldn't be organised within the IETF, but it >>> does >>> need to liaise with those responsible for doing that. >> >> "The" political response? You expect only one? Again, I don't >> think we should hang around waiting - we should document the >> consensus from Vancouver and then follow that through in our >> normal work within working groups and elsewhere - considering >> threats, including this one, as we develop protocols. >> >>> Unfortunately I am >>> not observing any movement by any of the other parties within our >>> wonderful multi-stakeholder system that you would think would be >>> notionally responsible for this. My fear is that they are opting to >>> drink >>> the technology Kool-Aid, to avoid grasping the political nettle. That is >>> what should be concerning us right now. >> >> Fully disagree. Its us should be grasping nettles and working >> to improve the security and privacy properties of our protocols. >> >> Regards, >> S. >> > > > Janet(UK) is a trading name of Jisc Collections and Janet Limited, a > not-for-profit company which is registered in England under No. 2881024 > and whose Registered Office is at Lumen House, Library Avenue, > Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238 > > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > > Janet(UK) is a trading name of Jisc Collections and Janet Limited, a=20 not-for-profit company which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238 From stephen.farrell@cs.tcd.ie Thu Dec 5 06:55:29 2013 Return-Path: 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 D48FF1AE011; Thu, 5 Dec 2013 06:55:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8V8xiQsjbgBP; Thu, 5 Dec 2013 06:55:27 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 10CAB1AE036; Thu, 5 Dec 2013 06:55:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 72218BEDC; Thu, 5 Dec 2013 14:55:17 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tyfTbw7uvbCD; Thu, 5 Dec 2013 14:55:17 +0000 (GMT) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 4CA21BE73; Thu, 5 Dec 2013 14:55:17 +0000 (GMT) Message-ID: <52A093D6.3030206@cs.tcd.ie> Date: Thu, 05 Dec 2013 14:55:18 +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: Josh Howlett References: <290E20B455C66743BE178C5C84F1240847E5103799@EXMB01CMS.surrey.ac.uk> <2C66A416-5F07-4803-A4C0-BB61734BA42E@nominum.com> <52A05F05.3040506@cs.tcd.ie> , <52A0744C.8030501@cs.tcd.ie> <55DC663C2F4F9F439F23543E0078E8B39A183AE7@EXC001> In-Reply-To: <55DC663C2F4F9F439F23543E0078E8B39A183AE7@EXC001> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: perpass , IETF Discussion Subject: Re: [perpass] Commnets on draft-farrell-perpass-attack-00 was RE: 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 14:55:30 -0000 On 12/05/2013 02:41 PM, Josh Howlett wrote: > Stephen, > > Yes I agree its necessary, but its not the hard part of the problem. > We are focusing on implementation detail, Great, I think we agree on that, maybe with slightly different emphases. > at the expense of the meaty > political problems; namely, (1) establishing the level of monitoring > civil society is willing to tolerate (on the spectrum none to > pervasive) and (2) building whatever legislative consensus is > necessary to enforce that. Those may be good things for folks to do in various other places, but I don't think they're for the IETF to do. Cheers, S. > Moving straight to (3) the solution space > may deliver specs and running code, but not the motivations to deploy > it (or worse, incentives not to). I applaud the effort, even if it > only serves to incrementally improve on the status quo, but given > your adversaries I fear it is already doomed before it has started. > Seriously, best of luck anyway :-) > > Josh. ________________________________ From: Stephen > Farrell Sent: ‎05/‎12/‎2013 12:41 > To: Josh Howlett Cc: > perpass; IETF > Discussion Subject: Re: [perpass] Commnets on > draft-farrell-perpass-attack-00 was RE: > perens-perpass-appropriate-response-01 > > > Josh, > > On 12/05/2013 12:28 PM, Josh Howlett wrote: >> Hi Stephen, >> >> I absolutely agree that the technical work is necessary, but it is >> not sufficient. > > So you agree this draft is necessary? If so, good. > > Nobody (sensible) claimed it was sufficient by itself to stop > pervasive monitoring. It can nonetheless improve the Internet in any > case, both when considering the pervasive monitoring threat and other > threats. If e.g. the UTA WG is chartered later today then what > they're going to do, which is directly spurred by this overall > discussion, could significantly improve e.g. SMTP security. > >> The political environment controls the legal and regulatory >> environment within which CEOs, their lawyers, and the other minions >> whose role is to minimise corporate risk exposure, take the >> decisions on which products and services reach the market. >> >> The technical community can obviously choose to do the work >> regardless, but in the absence of conformant products and services >> it runs the risk of being a paper exercise. > > That seems to apply to any new work that anyone does in the IETF and > is not a reason to do nothing. > >> I am sympathetic to your argument that the technical work could >> happen in advance of policy, > > That is not my argument. The technical work should happen and for > technical reasons. > >> but that hands the advantage to the adversary who can use this >> intelligence to advance blocking political measures. > > Game theory is fun, but not particularly productive for this draft > IMO. That'd be more relevant for specific bits of protocol work where > it might be the case that one could consider how an adversary could > react to a particular mitigation for this or other threats. At the > level of this draft I don't think there's anything useful to be done > in that respect. > > Cheers, S. > >> >> I also agree that it is unfortunate that none of the numerous >> acronyms that claim to have a remit in Internet policy are working >> with the technical community. In the majority of the capitols of >> Europe there is clearly a political appetite to roll pervasive >> monitoring back, and these acronyms would be pushing on an open >> door (and, in fairness, perhaps they already are but it is not >> obvious to the outside world). It is not far from Geneva to >> Brussels... >> >> Josh. >> >> On 05/12/2013 11:09, "Stephen Farrell" >> wrote: >> >>> >>> Josh, >>> >>> On 12/05/2013 10:53 AM, Josh Howlett wrote: >>>> >>>> I fully support action to increase security, where it responds >>>> to the prevailing threat environment. But it will be a >>>> perpetuation of the naivety that has characterised this debate >>>> to think that this alone will halt pervasive monitoring, >>>> because the threat is not technical in nature. >>> >>> Personally, I think anyone using the argument that "you can't >>> solve the problem therefore do nothing" is talking about the same >>> amount of nonsense as anyone who says "the IETF can halt >>> pervasive monitoring." >>> >>> You don't quite say either of those above, but neither do you >>> acknowledge that the draft in question, and all the sensible >>> discussion (which is far from all the discussion;-) around that >>> fully acknowledges that the technical things that can and should >>> be done are only part of the story. >>> >>>> The technical response must be coordinated with a political >>>> response, or else the perpetrators will find political means to >>>> route around the technical measures. >>> >>> I disagree with "must be coordinated" for various reasons. >>> >>> Given the time it takes for us to do our part, which is measured >>> in years before we get good deployment, imposing a requirement to >>> start with coordination would mean doing nothing ever. >>> >>> Secondly, with whom would we coordinate? Again, trying to impose >>> a requirement for coordination with a non-existent Internet-wide >>> political entity is tantamount to doing nothing. >>> >>> If some other folks outside the IETF are working on the same >>> issues that'll be good or bad, and for some such activities >>> it'll be useful for us to know about and consider them. And maybe >>> it'll be useful for others to know what we're up to, but we >>> should not wait. >>> >>>> The political response shouldn't be organised within the IETF, >>>> but it does need to liaise with those responsible for doing >>>> that. >>> >>> "The" political response? You expect only one? Again, I don't >>> think we should hang around waiting - we should document the >>> consensus from Vancouver and then follow that through in our >>> normal work within working groups and elsewhere - considering >>> threats, including this one, as we develop protocols. >>> >>>> Unfortunately I am not observing any movement by any of the >>>> other parties within our wonderful multi-stakeholder system >>>> that you would think would be notionally responsible for this. >>>> My fear is that they are opting to drink the technology >>>> Kool-Aid, to avoid grasping the political nettle. That is what >>>> should be concerning us right now. >>> >>> Fully disagree. Its us should be grasping nettles and working to >>> improve the security and privacy properties of our protocols. >>> >>> Regards, S. >>> >> >> >> Janet(UK) is a trading name of Jisc Collections and Janet Limited, >> a not-for-profit company which is registered in England under No. >> 2881024 and whose Registered Office is at Lumen House, Library >> Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. >> 614944238 >> >> _______________________________________________ perpass mailing >> list perpass@ietf.org >> https://www.ietf.org/mailman/listinfo/perpass >> >> > > Janet(UK) is a trading name of Jisc Collections and Janet Limited, a > not-for-profit company which is registered in England under No. > 2881024 and whose Registered Office is at Lumen House, Library > Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. > 614944238 > > _______________________________________________ perpass mailing list > perpass@ietf.org https://www.ietf.org/mailman/listinfo/perpass > From randy@psg.com Thu Dec 5 07:19:03 2013 Return-Path: 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 B379E1AE098 for ; Thu, 5 Dec 2013 07:19:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, 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 osK8tAhMQ7g2 for ; Thu, 5 Dec 2013 07:19:03 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id E4A621AE032 for ; Thu, 5 Dec 2013 07:19:02 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1VoahZ-0004Fy-JP; Thu, 05 Dec 2013 15:18:53 +0000 Date: Thu, 05 Dec 2013 16:18:52 +0100 Message-ID: From: Randy Bush To: =?ISO-8859-15?Q?Matth=E4us?= Wander In-Reply-To: <52A050E7.8010405@uni-due.de> References: <52A050E7.8010405@uni-due.de> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: perpass@ietf.org Subject: Re: [perpass] A reminder, the Network is the Enemy... 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 15:19:03 -0000 > If we assume the attacker can get the private root KSK from an US-based > corp, then we should also assume they can get the private root ZSK from > another US-based corp. As the owner of the root ZSK also owns the keys > for .com, the attack becomes much easier. let's start a list of juristictions which we believe are NOT compromised and dangerous. i will start it off by submitting andorra. randy From hallam@gmail.com Thu Dec 5 07:23:45 2013 Return-Path: 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 3377D1AE059 for ; Thu, 5 Dec 2013 07:23:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 S2IBiUg-RBZE for ; Thu, 5 Dec 2013 07:23:43 -0800 (PST) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) by ietfa.amsl.com (Postfix) with ESMTP id EBA231AE038 for ; Thu, 5 Dec 2013 07:23:42 -0800 (PST) Received: by mail-wi0-f171.google.com with SMTP id ca18so10065866wib.4 for ; Thu, 05 Dec 2013 07:23:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mAlgPVVKnBWtP3JL3yImcitcKm3wlleKgDSvTC0Ul2k=; b=QEwmbiO02umKjXvUKRBeEThu3++8vRFCGbnHhil7IpvaMJPYvNaB08qISF43u9YL/I J2BsOX6zFzdg+DnBk1xi9kL7qfktRmaTLZwwTpkdRCFWisJznS9If2ly/TIsLL6srv0H HdeEh3HcGpwefp6zn9FTSKpcNXyo2VOkjuGO5evgK2XmD2JAPCnAZtDpuGGxvuCitMCm bPpP0GVQM6uy3yElU6j/TfGgAL2sLL7e6yX45LZ8YQwv5q4UOMXawDG8IhN4minYQ98l cFxkz15D/lHN2dtpzYJPenUiOnBC6Qfim8BsM+Wp2q8UIzSwbYaWcHWFDPk1XN16S6y/ nlSQ== MIME-Version: 1.0 X-Received: by 10.194.78.77 with SMTP id z13mr62146604wjw.27.1386257018954; Thu, 05 Dec 2013 07:23:38 -0800 (PST) Received: by 10.194.243.136 with HTTP; Thu, 5 Dec 2013 07:23:38 -0800 (PST) In-Reply-To: <20131205072546.2740.2142915422.0@crow> References: <20131205072546.2740.2142915422.0@crow> Date: Thu, 5 Dec 2013 10:23:38 -0500 Message-ID: From: Phillip Hallam-Baker To: Elijah Sparrow Content-Type: multipart/alternative; boundary=047d7bfcfc982eb5ee04eccb1ddb Cc: perpass 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 15:23:45 -0000 --047d7bfcfc982eb5ee04eccb1ddb Content-Type: text/plain; charset=ISO-8859-1 Many people assume that technical people are unaware of the political implications of their work. This is not true and has never been true. In my case I contacted Jock Gill who was running the Clinton-Gore '92 campaign and told him about the Web and the political potential in 1992, the day after I returned from the first public presentation at the CHEP'92 conference in France. I discussed the potential of the Web with people who were working in Sarajevo during the siege. They used a Web server there to coordinate information, for example reporting positions of snipers. I also had conversations with the intelligence services at the time. The cold war had just ended and they were looking for a new role. >From 1991 through 1998 there was an event that is generally known in the field as the cryptowars which began as a fight between the NSA and the Internet and ended with Louis Freeh the FBI backing the Republican party attempt to impeach Bill Clinton in revenge for the administration reneging on what Freeh believed was a commitment to back his surveillance ambitions. Some of us have experience of national politics as well. I was a (full not youth) delegate to a national party conference at 20. I gave up that activity because building the net is far more consequential than most cabinet level political careers. More specifically, when I started work on the Web 95% of the UK newspaper industry was controlled by three individuals, Rupert Murdoch, Conrad Black and Robert Maxwell. Conrad Black has recently completed a prison sentence for fraud, Maxwell committed suicide just before his massive fraud was exposed and the senior management a Rupert Murdoch UK newspaper are currently on trial. I really did not see why a conspicuously corrupt and dishonest Austrialian newspaper magnate should get to choose the UK government which is what Murdoch claimed in the wake of the '92 election. It is hard to imagine that the Iraq war could have occurred without support from Murdoch's global propaganda machine. He has the blood of a half million people on his hands. In the case of cryptography in particular and security in general, the technology affects the balance of power and is always controversial. When the IETF tried to do anti-spam work the efforts were initially sabotaged by a large number of shills paid by the spammers themselves. Even though 99.99% of net users hate spam there are some parties that made their livings from it and wanted to protect them. DRM is contentious for the same reason. It affects the balance of power between the producer of content and the consumer. Payment security mechanisms are contentious because some net merchants have built their reputations on being a safe place to buy from and they have little incentive to make trust a commodity. --047d7bfcfc982eb5ee04eccb1ddb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Many people assume that technic= al people are unaware of the political implications of their work. This is = not true and has never been true.

In my case I contacted Jock Gill who was running the Clinton-Gore '92 c= ampaign and told him about the Web and the political potential in 1992, the= day after I returned from the first public presentation at the CHEP'92= conference in France.

I discussed= the potential of the Web with people who were working in Sarajevo during t= he siege. They used a Web server there to coordinate information, for examp= le reporting positions of snipers.

I also had = conversations with the intelligence services at the time. The cold war had = just ended and they were looking for a new role.=A0

From 1991 through 1998 there was an ev= ent that is generally known in the field as the cryptowars which began as a= fight between the NSA and the Internet and ended with Louis Freeh the FBI = backing the Republican party attempt to impeach Bill Clinton in revenge for= the administration reneging on what Freeh believed was a commitment to bac= k his surveillance ambitions.

Some of us = have experience of national politics as well. I was a (full not youth) dele= gate to a national party conference at 20. I gave up that activity because = building the net is far more consequential than most cabinet level politica= l careers.

More specif= ically, when I started work on the Web 95% of the UK newspaper industry was= controlled by three individuals, Rupert Murdoch, Conrad Black and Robert M= axwell. Conrad Black has recently completed a prison sentence for fraud, Ma= xwell committed suicide just before his massive fraud was exposed and the s= enior management a Rupert Murdoch UK newspaper are currently on trial. I re= ally did not see why a conspicuously corrupt and dishonest Austrialian news= paper magnate should get to choose the UK government which is what Murdoch = claimed in the wake of the '92 election.

It is hard = to imagine that the Iraq war could have occurred without support from Murdo= ch's global propaganda machine. He has the blood of a half million peop= le on his hands.


<= div class=3D"gmail_extra">In the case of cryptography in particular and sec= urity in general, the technology affects the balance of power and is always= controversial. When the IETF tried to do anti-spam work the efforts were i= nitially sabotaged by a large number of shills paid by the spammers themsel= ves. Even though 99.99% of net users hate spam there are some parties that = made their livings from it and wanted to protect them.

DRM is cont= entious for the same reason. It affects the balance of power between the pr= oducer of content and the consumer. Payment security mechanisms are content= ious because some net merchants have built their reputations on being a saf= e place to buy from and they have little incentive to make trust a commodit= y.=A0


<= /div> --047d7bfcfc982eb5ee04eccb1ddb-- From hallam@gmail.com Thu Dec 5 07:27:36 2013 Return-Path: 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 3F9CC1AE030 for ; Thu, 5 Dec 2013 07:27:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 IhoDQ0YSVn3J for ; Thu, 5 Dec 2013 07:27:33 -0800 (PST) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 1B0581ADF30 for ; Thu, 5 Dec 2013 07:27:32 -0800 (PST) Received: by mail-we0-f181.google.com with SMTP id x55so16989965wes.12 for ; Thu, 05 Dec 2013 07:27:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6zcAgsNGBACzmqL3/I0/nk7L94F5CycpawNzXVNz4Ps=; b=NLtlskw2IqI7//Thjr52AoCUKjoLPJJayA0bU0FB5AlKC08QRvk0ZZIbCQ8ECFDrwk BXI73uc5nh2UjTndQEymr6rB2OSupqsuptsxnLXOb7BchNdzoRvGtGJ25Fx3NGPcZfL5 k9v9uPsf2fCKKkdQo/2aQIGzc+DszGxHEOz4wt+PvTpI3PEVBv0ZAP/ctcBrlmUJVFS8 FZOZPyIE0fSdVXHf9EQtlbSIFm5dTcB14etZbwOR8qyK3CuZkFagdTaeXzNjsbQREyU+ y7q72vR8Mi4e5hL9TNHcfdCXekWAIqQFTJXG9tWfge1FzjY83gG8sFeISyEkd/1ZVJfp Dikw== MIME-Version: 1.0 X-Received: by 10.180.189.80 with SMTP id gg16mr12560784wic.32.1386257249300; Thu, 05 Dec 2013 07:27:29 -0800 (PST) Received: by 10.194.243.136 with HTTP; Thu, 5 Dec 2013 07:27:29 -0800 (PST) In-Reply-To: References: <52A050E7.8010405@uni-due.de> Date: Thu, 5 Dec 2013 10:27:29 -0500 Message-ID: From: Phillip Hallam-Baker To: Randy Bush Content-Type: multipart/alternative; boundary=001a11c22314e976fa04eccb2aa9 Cc: perpass , =?ISO-8859-1?Q?Matth=E4us_Wander?= Subject: Re: [perpass] A reminder, the Network is the Enemy... 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 15:27:36 -0000 --001a11c22314e976fa04eccb2aa9 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Dec 5, 2013 at 10:18 AM, Randy Bush wrote: > > If we assume the attacker can get the private root KSK from an US-based > > corp, then we should also assume they can get the private root ZSK from > > another US-based corp. As the owner of the root ZSK also owns the keys > > for .com, the attack becomes much easier. > > let's start a list of juristictions which we believe are NOT compromised > and dangerous. i will start it off by submitting andorra. > Finding the one person you can trust is a bad strategy. Andorra is considerably less likely to stand up to NSA bullying attempts than Microsoft is. Microsoft certainly has more lawyers. A better approach is to design the system so that it takes a defection by more than one party. Instead of relying on just the ICANN root KSK require a TLD to be signed by three out of five trusted national cryptolabs. -- Website: http://hallambaker.com/ --001a11c22314e976fa04eccb2aa9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On T= hu, Dec 5, 2013 at 10:18 AM, Randy Bush <randy@psg.com> wrote:
> If we assume the attacker can get the private root K= SK from an US-based
> corp, then we should also assume they can get the private root ZSK fro= m
> another US-based corp. As the owner of the root ZSK also owns the keys=
> for .com, the attack becomes much easier.

let's start a list of juristictions which we believe are NOT comp= romised
and dangerous. =A0i will start it off by submitting andorra.

Finding the one person you can trust is a bad strateg= y. Andorra is considerably less likely to stand up to NSA bullying attempts= than Microsoft is. Microsoft certainly has more lawyers.

A better approach is to design the system so that it ta= kes a defection by more than one party. Instead of relying on just the ICAN= N root KSK require a TLD to be signed by three out of five trusted national= cryptolabs.
=A0

--
Website: http://hallambaker.com/
--001a11c22314e976fa04eccb2aa9-- From elopez@fortinet.com Thu Dec 5 08:15:06 2013 Return-Path: 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 B07F91AE059 for ; Thu, 5 Dec 2013 08:15:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 YrIIEOpSw_15 for ; Thu, 5 Dec 2013 08:15:04 -0800 (PST) Received: from smtp.fortinet.com (smtp.fortinet.com [208.91.113.88]) by ietfa.amsl.com (Postfix) with ESMTP id 23A0E1AE043 for ; Thu, 5 Dec 2013 08:15:04 -0800 (PST) From: Edward Lopez To: Elijah Sparrow Thread-Topic: [perpass] politics and the ietf Thread-Index: AQHO8YtEAe6nJsinukWePesvAXKcyppFxz5b Date: Thu, 5 Dec 2013 16:15:09 +0000 Message-ID: <91FC9CE1-6C8E-4457-A767-6E8F0CDA730A@fortinet.com> References: <20131205072546.2740.2142915422.0@crow> In-Reply-To: <20131205072546.2740.2142915422.0@crow> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FEAS-SYSTEM-WL: 192.168.221.212 Cc: "perpass@ietf.org" 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 16:15:06 -0000 Elijah, I have a sociology background as well, and found resonance in your commen= ts. As a security technologist, I often tell people that security is not requ= ired for productivity. A new protocol or application can be highly produ= ctive without being secure. A significant challenge is in changing the m= indset of participants to incorporate security as a goal of design. But we have to consider the technical, political, and economic (cost) fac= tors of what we do. In the discussion of opportunistic encryption, we ha= ve to recognize that there is a significant barriers in all three areas. = Encryption everywhere is over-simplistic, and is biased on the idea that= the math works. But we have to remember that just like bad security is = equivalent to no security, bad implementations of encryption generate cos= ts and hassles without benefit. I have heard comments regarding pervasive surveillance as an attack on th= e Internet, and am concerned about cycles lost in overreaction, analogous= to how we perceive the Patriot Act, TSA, and Air Marshals as an overreac= tion to 9/11. We applaud the concept of Google searches, but are repelled by the concep= t of data analytics, which is an inherent byproduct of search engines. I= n a decade past we demanded 1Gbps wired to the desktop, but gave it up fo= r 11Mbps of shared wireless, even if it was not secure and subject to sur= veillance. But the productivity gained by searches and wireless are not i= n question, and the side effects seen as a reasonable cost/risk at the ti= me The reality is with the NSA, we have an ultimate peer-review organization= . One that is prepared to expend tremendous resources to find and exploit= weaknesses in the protocols we design. It's not that they are smarter (= although as Bruce points out, likely a decade ahead in math), but they ar= e more tenacious, and they play dirty. Collectively, we need to change our thinking. Ed Lopez Sent from my iPhone ... Sorry for any auto-correct errors > On Dec 5, 2013, at 2:26 AM, "Elijah Sparrow" wrote= : > > As an outsider to the IETF, and one-time sociologist, I found the repea= ted calls in Vancouver 88 and on this list for decisions to be made based= solely on technical merit and not political argument to be extremely fas= cinating. > > There was once a time when the design of a protocol or standard could b= e done in a manner that benefited nearly everyone who might be touched by= it. These days are surely past. Nearly every single debate or question t= hat has come up on this list is deeply political, if for no other reason = than whatever decisions are made will create winners and losers, people w= ho benefit from the choice and people who are harmed by the choice. > > In the sweep of history, information capitalism has come to a moment of= truth, where the material infrastructure that the IETF and technologists= the world around have helped to create has now matured into both an econ= omic engine and a state intelligence system based on mass surveillance. P= erhaps the most distinguishing political debate of our time is how the po= wer of the state and of business with respect to citizens and customers h= as been radically transformed under this new regime of ubiquitous surveil= lance. Obviously, I feel a particular way about this, but I am just stati= ng the obvious: these issues are deeply political because the fragile bal= ance of powers in liberal democracy and in our capitalist economies have = been inexorably rocked by technological changes. > > In this context, the question of "how much encryption" is a technical q= uestion that is also deeply intertwined with the major political debates = of our day. One only has to note the major headlines around the world abo= ut the ietf calls for encryption in http 2.0. How often have ietf meeting= s garnered such global coverage? > > Scientists and engineers are often forced into political arenas without= their desire or foresight. Take, for example, the history of genomics, c= limate change, or nuclear physics. Historically, the scientists and engin= eers have clung desperately to the cloak of objective science, even as th= eir work took on increasingly obvious political ramifications. My hope fo= r the internet is that we could perhaps bypass such silliness and embrace= the obvious political nature of our work. Being honest with ourselves do= es not push anyone toward any particular technical or political stance, e= xcept that perhaps we can be more transparent in our justifications. > > In the immortal words of Voltaire, and Spiderman, with great power come= s great responsibility. > > -elijah > > -- > I prefer encrypted email - https://bitmask.net/key/elijah. > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass *** Please note that this message and any attachments may contain confid= ential and proprietary material and information and are intended only for the us= e of the intended recipient(s). If you are not the intended recipient, you are= hereby notified that any review, use, disclosure, dissemination, distribution or= copying of this message and any attachments is strictly prohibited. If you have r= eceived this email in error, please immediately notify the sender and destroy thi= s e-mail and any attachments and all copies, whether electronic or printed. Please also note that any views, opinions, conclusions or commitments exp= ressed in this message are those of the individual sender and do not necessarily= reflect the views of Fortinet, Inc., its affiliates, and emails are not binding o= n Fortinet and only a writing manually signed by Fortinet's General Counsel= can be a binding commitment of Fortinet to Fortinet's customers or partners. Tha= nk you. *** From fergdawgster@mykolab.com Thu Dec 5 10:17:41 2013 Return-Path: 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 024201AE06C for ; Thu, 5 Dec 2013 10:17:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, 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 M05mKjce4Wg8 for ; Thu, 5 Dec 2013 10:17:39 -0800 (PST) Received: from mx01.mykolab.com (mx01.mykolab.com [95.128.36.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCCA51AE046 for ; Thu, 5 Dec 2013 10:17:38 -0800 (PST) X-Virus-Scanned: amavisd-new at kolabsys.net Sender: fergdawgster@mykolab.com Message-ID: <52A0C334.6010909@mykolab.com> Date: Thu, 05 Dec 2013 10:17:24 -0800 From: Paul Ferguson Organization: Clowns R. Mofos To: Edward Lopez References: <52A0C2D5.10503@people.ops-trust.net> In-Reply-To: <52A0C2D5.10503@people.ops-trust.net> X-Forwarded-Message-Id: <52A0C2D5.10503@people.ops-trust.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "perpass@ietf.org" Subject: Re: [perpass] politics and the ietf X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: fergdawgster@mykolab.com 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: Thu, 05 Dec 2013 18:17:41 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/5/2013 8:15 AM, Edward Lopez wrote: > As a security technologist, I often tell people that security is not > required for productivity. A new protocol or application can be highly > productive without being secure. A significant challenge is in changing > the mindset of participants to incorporate security as a goal of design. Sure, you can be 'productive' with a lack of 'security', but there are also the threats of losing your work/intellectual property/etc. via industrial espionage. This is a real threat, and efforts to raise the bar (by raising one's security posture) is a Good Thing (tm) in an effort to thwart that. - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 10.2.0 (Build 2317) Charset: utf-8 wj8DBQFSoMLLq1pz9mNUZTMRAgN6AJwJkvAXk/64jXkQ9pEwlb7E6Qo8ngCgz05A sAck4Kd5KtgUCbnNlgWjsyg= =BIgN -----END PGP SIGNATURE----- -- Paul Ferguson PGP Public Key ID: 0x63546533 From sm@elandsys.com Thu Dec 5 13:19:16 2013 Return-Path: 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 8DBC01AE180 for ; Thu, 5 Dec 2013 13:19:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.791 X-Spam-Level: X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.001, T_DKIM_INVALID=0.01] 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 z0qtn69Cf3zs for ; Thu, 5 Dec 2013 13:19:15 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 98A2F1AE174 for ; Thu, 5 Dec 2013 13:19:15 -0800 (PST) Received: from SUBMAN.elandsys.com ([197.226.232.172]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id rB5LIpNH022736 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Dec 2013 13:19:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1386278345; bh=a+unUyOloSlKnr3EoUaFqOSQp6sxIcVGeolNscGviYA=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=43OUR9Ur9JM3aR0MXWXIPwkLArIrjR9icxVlWf5v3RqohmkdqKqXsSvemJIG3ohtK 25FtCVJMGjiAkytRicUU0h+WI81IQF2raWORYL3dhjbmrE2Vb8xakORj/bAkEchxcI s89wLZz10/nsrkFDHllsjPwreBhU2kaoeOyisQgQ= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1386278345; i=@elandsys.com; bh=a+unUyOloSlKnr3EoUaFqOSQp6sxIcVGeolNscGviYA=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Yx31bqcClTDOUy7wVQ/4KC7zUDS8eF61At+3LYw2u0XGMQ2DA5ihQBDIKZnEVni5M 9iuoXSSEa7mPJ2y22diOb9nxCUMDkhfN7rNc1xQq0yckJ1VtlPuaCj/YG0WfwL9MrF E5z7RHEyvY0J7cwrZz8QCL1axx5f42s8k75JRsr0= Message-Id: <6.2.5.6.2.20131205115926.0dfbe000@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 05 Dec 2013 12:19:58 -0800 To: "Learmonth, Iain Ross" From: S Moonesamy In-Reply-To: <5e7d0e55fc83418aa2a9fbd86b0a9b5f@DB3PR01MB153.eurprd01.pro d.exchangelabs.com> References: <6.2.5.6.2.20131124121510.0aa47e40@elandnews.com> <5e7d0e55fc83418aa2a9fbd86b0a9b5f@DB3PR01MB153.eurprd01.prod.exchangelabs.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: perpass@ietf.org Subject: Re: [perpass] Traffic peeking 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 21:19:16 -0000 Hi Iain, At 14:37 24-11-2013, Learmonth, Iain Ross wrote: > > In 2007, Dan Shumow and Niels Ferguson discussed about the > > possibility of a backdoor in a Dual Elliptic Curve pseudorandom > > number generator [Rump]. > >I'm not sure how this paragraph is relevant to the rest of the >draft. You only discuss the use of encryption, not particular schemes. I submitted draft-moonesamy-traffic-peeking-01 [1]. Appendix D mentions a case where the Dual EC DRBG was implemented. There are some new appendices about Wiretapping and Lawful Interception. The incentives are not the same in every country. I added some references which may be related to the message posted by Brian Carpenter at https://www.ietf.org/mail-archive/web/perpass/current/msg00881.html As a general note, I did not change the name of the draft as it is easier. Regards, S. Moonesamy 1. http://tools.ietf.org/html/draft-moonesamy-traffic-peeking-01 From lear@cisco.com Thu Dec 5 14:10:44 2013 Return-Path: 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 D8C201AE1EE for ; Thu, 5 Dec 2013 14:10:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.502 X-Spam-Level: X-Spam-Status: No, score=-9.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 vUYB7JjxH9o2 for ; Thu, 5 Dec 2013 14:10:41 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id E15401AE1C8 for ; Thu, 5 Dec 2013 14:10:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=877; q=dns/txt; s=iport; t=1386281436; x=1387491036; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=wcwnUZk16WJ4BSGcrVSU09MhhmfhVdjXUYYQ0uJZs8Q=; b=ItJKac+uMFkjTaq36qibordWh66ejdAFOjhpa3EEhverRSh/wtfzPHHN Ul2UPiXkteMNs4O/D4UfJfFLF0LimY7ZZWx3cRvpK4KPZ7gi9EOAcspYo LTd+DkdlyoSOAQpEjeXLSoUoU32iUJtyCtj1k4j637idFJD2XjfqULz0I 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFAA/5oFKQ/khR/2dsb2JhbABZgweEB7VygR0WdIIlAQEBBCNVARALDgQGAgIFFgsCAgkDAgECATcOBgEMAQcBAYd+sUqPfxeBKY1XB4JrgUgDlDGDY5ITgyk8 X-IronPort-AV: E=Sophos;i="4.93,836,1378857600"; d="scan'208";a="1142226" Received: from ams-core-1.cisco.com ([144.254.72.81]) by aer-iport-2.cisco.com with ESMTP; 05 Dec 2013 22:10:34 +0000 Received: from ams3-vpn-dhcp8022.cisco.com (ams3-vpn-dhcp8022.cisco.com [10.61.95.85]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id rB5MASG6026078 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Dec 2013 22:10:30 GMT Message-ID: <52A0F9D5.1070907@cisco.com> Date: Thu, 05 Dec 2013 22:10:29 +0000 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Ted Lemon , Bruce Perens References: <529E8494.7000806@perens.com> <20131204111309.GB11727@nic.fr> <529F61D8.6030105@perens.com> <20131204171207.GC19914@thunk.org> <529F63C0.3040804@perens.com> <529F88AC.3090904@appelbaum.net> <529F90A0.8000706@perens.com> <529FBDA6.9030100@perens.com> <529FC5E3.6090008@perens.com> <09EFA47D-6A4B-4BA7-9FC5-A564C11CA3FA@fugue.com> In-Reply-To: <09EFA47D-6A4B-4BA7-9FC5-A564C11CA3FA@fugue.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: perpass 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 22:10:45 -0000 Hi Ted, On 12/5/13 12:21 AM, Ted Lemon wrote: > If your example for "harm the operation of the internet" is transparent caching, that point has been answered: define a protocol for caching that is not transparent, and allow the incentive structure around end users who benefit from that caching to motivate them to use it, rather than simply forcing them to use it in their own best interest. It's fine to have aspirations, and establishing an architecture in which intermediaries can be properly identified and authorized is important. However, let's not take aspirations that do not even exist in the form of an Internet-Draft, assume them as fact, and dismiss those who live in the real world where caching is a necessity in bandwidth-constrained environments. Please let's take this step by step. A few drafts that get us there seem in order. Eliot From pranesh@cis-india.org Thu Dec 5 20:53:32 2013 Return-Path: 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 DAEB11AE2B8 for ; Thu, 5 Dec 2013 20:53:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-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 pgNXUtn_-ONR for ; Thu, 5 Dec 2013 20:53:30 -0800 (PST) Received: from mail.cis-india.org (mail.cis-india.org [202.190.125.68]) by ietfa.amsl.com (Postfix) with ESMTP id 194091AE2B6 for ; Thu, 5 Dec 2013 20:53:30 -0800 (PST) Received: from [192.168.1.210] (unknown [162.243.72.125]) by mail.cis-india.org (Postfix) with ESMTPSA id DC2ABA7C804; Fri, 6 Dec 2013 04:53:19 +0000 (UTC) Message-ID: <52A15835.2070901@cis-india.org> Date: Thu, 05 Dec 2013 23:53:09 -0500 From: Pranesh Prakash Organization: Centre for Internet and Society 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 , perpass@ietf.org References: <529E8494.7000806@perens.com> <20131204111309.GB11727@nic.fr> <529F61D8.6030105@perens.com> <20131204171207.GC19914@thunk.org> <529F63C0.3040804@perens.com> <529F88AC.3090904@appelbaum.net> <529F90A0.8000706@perens.com> <529F9205.30906@appelbaum.net> <529F98C0.9090808@perens.com> <529F9F14.8050805@appelbaum.net> <529FB61A.7090604@perens.com> <529FBEF9.7030205@appelbaum.net> <529FC347.3080806@perens.com> In-Reply-To: <529FC347.3080806@perens.com> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7bqA7OoD8p4pflw82BeSrQl7T4GkoLtLl" 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 04:53:33 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --7bqA7OoD8p4pflw82BeSrQl7T4GkoLtLl Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Bruce Perens [2013-12-04 19:05]: > On 12/04/2013 03:47 PM, Jacob Appelbaum wrote: >> So basically, you were just blowing smoke? > No. The organization is charged to protect us.=20 1. Speak for yourself. The NSA is not charged with protecting non-Americans, i.e., the bulk of the population of the world, I may add, of the bulk of the users of the Internet standards that the IETF works on. The clue is in the word "National". India's National Technical Research Organization is not charged with protecting Chinese or Americans either. 2. Try telling that to the folks at Petrobras and all the diplomats at the UN HQ, the Indian Embassy in DC, the EC/CoE/European Council, G20 leaders, and those people whose porn habits were recorded for blackmail purposes. This is not a debate about whether surveillance is good or not. (Targetted surveillance which is allowed by a law, has a legitimate aim in a democratic society, is not arbitrary, is necessary to achieve those aims, is proportionate, authorized by a judicial process, etc., would be legitimate.) This is a debate about whether it is technically (and politically) desirable for protocols to prevent mass surveillance. > Throwing deliberate hurdles in their way is like spreading nails in the= path of=20 > a police car. Cops have more than enough abuses, but most people accept= that=20 > they do good stuff too, and nobody sensible suggests getting rid of the= m. That analogy is woefully inadequate. Spreading nails in the path of a police car is a targetted attack on the police car. Increasing encryption to improve confidentiality of communications is not a targetted attack against anyone. This, on the other hand, is like ensuring that you write *all* your communications in coded language instead of just some of your communicati= on. Will it frustrate targetted surveillance that complies with the standard set in the International Covenant on Civil and Political Rights of being "non-arbitrary" and "lawful"? Probably not, since there are other ways of getting to such targets by gaining access through their service providers or by gaining access to their person or to their communication devices. Will it frustrate mass surveillance / dragnet surveillance? Yes. The choice is clear to me. >> Good luck with a Man-On-The-Side attack on .se. domains that are prope= rly configured. > OK. But I'm horrified that .se is the best demo you can cite. >> What political solution do you envision exactly? > Given the choice, I would roll increases in executive authority related= to the=20 > pursuit of war or espionage back to what we had before the PATRIOT act.= This is=20 > something we can state in one sentence and that makes sense. IMO it is = a=20 > workable campaign and one you should join. I can't join it; I'm not a US citizen. Nor do I want to make the lack of security of the protocols that I use hostage to the some 'workable campaign' run by well-meaning Americans. I will whole-heartedly support you in your campaign to reform the law and policies in the USA. I don't see why you see technical and political solutions as being mutually exclusive. There is no reason why the 'default' insecurity of HTTP cannot be handled at the technical level. Do I believe all HTTP2 traffic MUST be encrypted? Perhaps, and perhaps not. But most certainly, the 'default' for HTTP2 traffic should be encryption. You can opt out of the Concealment Society if you want to. But please don't force me to stay within the Surveillance Society. --=20 Pranesh Prakash Policy Director Centre for Internet and Society T: +91 80 40926283 | W: http://cis-india.org PGP ID: 0x1D5C5F07 | Twitter: @pranesh_prakash -------------------- Access to Knowledge Fellow Information Society Project, Yale Law School T: +1 520 314 7147 | W: http://yaleisp.org --7bqA7OoD8p4pflw82BeSrQl7T4GkoLtLl Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) iEYEARECAAYFAlKhWDkACgkQ7JoSBR1cXwci0wCfZrz20RuX6g3KyHA3rG/e40xV EtgAnjMr0ClLtNB0PLM7HRx7EFZjt3oE =rZu/ -----END PGP SIGNATURE----- --7bqA7OoD8p4pflw82BeSrQl7T4GkoLtLl-- From david.lloydjones@gmail.com Fri Dec 6 01:03:02 2013 Return-Path: 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 3EB601A1F77 for ; Fri, 6 Dec 2013 01:03:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 eHueFJ6zaULW for ; Fri, 6 Dec 2013 01:03:01 -0800 (PST) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) by ietfa.amsl.com (Postfix) with ESMTP id A883F1AD7BE for ; Fri, 6 Dec 2013 01:03:00 -0800 (PST) Received: by mail-wi0-f170.google.com with SMTP id hq4so663488wib.5 for ; Fri, 06 Dec 2013 01:02:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=3qeVVPNOIP3w4dTcsitBXj1XB48SxuHWw8pF47Iudqs=; b=yeZkCbT0FhcemR6bzo/EeBwgQAqtSP4WA9KkR4ycAZlPmQJ2CllUNv1w7sOtHWUw8m eqf16wx9KEizQ0GJqYDhWAgSSAabdn045ZcmzEji0Alg2UfGpL97+Lu0H3hb4q6zOXRi 4gtetPW0xUM9xfPxONBNsMQSP07rU2Z1hdw78zn+FKOMAg5kPhCcrV/ASkexT3kH9ic/ 3jqMW3nYxkim3XOiyYZUaZA7y7lu/krTP3JXqJwvqpkVoyXbdfvT7WxtSsJA72itwkIo tlvIqE2NOzR7aMUgPR2BodRa7fZ2+c/wnkwBfo704165gqBeDMROJGa4dmlg53Y7LYB8 YL6g== MIME-Version: 1.0 X-Received: by 10.194.240.129 with SMTP id wa1mr2064815wjc.31.1386320576530; Fri, 06 Dec 2013 01:02:56 -0800 (PST) Received: by 10.194.110.169 with HTTP; Fri, 6 Dec 2013 01:02:56 -0800 (PST) Date: Fri, 6 Dec 2013 04:02:56 -0500 Message-ID: From: David Lloyd-Jones To: perpass Content-Type: multipart/alternative; boundary=089e013d1db282514304ecd9e90a Cc: Robin Wilton , Bruce Perens , Bradford DeLong Subject: [perpass] Henry Farrell Article 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 09:03:02 -0000 --089e013d1db282514304ecd9e90a Content-Type: text/plain; charset=UTF-8 Everybody will want to see Henry's good article at http://www.foreignaffairs.com/articles/140155/henry-farrell-and-martha-finnemore/the-end-of-hypocrisy?nocache=1 Foreign Affairs has made a remarkable comeback in the past year or 18 months; I'm not sure, but this may be the result of the excellent young Hamilton Fish III getting involved. Just an impression, not Gospel. Anyway, a fine place to see Henry's stuff appearing. -dlj. --089e013d1db282514304ecd9e90a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Everybody will want to see Henry's good article at=C2= =A0http://www.foreignaff= airs.com/articles/140155/henry-farrell-and-martha-finnemore/the-end-of-hypo= crisy?nocache=3D1
=C2=A0
Foreign Affairs has made a remarkable comeback in the past= year or 18 months; =C2=A0I'm not sure, but this may be the result of t= he excellent young Hamilton Fish III getting involved. =C2=A0
Just an impression, not Gospel. =C2=A0Anyway, a fine place to see Henry'= ;s stuff appearing.
=C2=A0
-dlj.
=C2=A0

--089e013d1db282514304ecd9e90a-- From wilton@isoc.org Fri Dec 6 01:33:31 2013 Return-Path: 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 E700D1AD8F1 for ; Fri, 6 Dec 2013 01:33:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=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 HerFUojpIomw for ; Fri, 6 Dec 2013 01:33:29 -0800 (PST) Received: from smtp78.iad3a.emailsrvr.com (smtp78.iad3a.emailsrvr.com [173.203.187.78]) by ietfa.amsl.com (Postfix) with ESMTP id 5AE251AD7C2 for ; Fri, 6 Dec 2013 01:33:29 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp10.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 8AEB9E80DB; Fri, 6 Dec 2013 04:33:25 -0500 (EST) X-Virus-Scanned: OK Received: by smtp10.relay.iad3a.emailsrvr.com (Authenticated sender: wilton-AT-isoc.org) with ESMTPSA id 10639E80C9; Fri, 6 Dec 2013 04:33:25 -0500 (EST) References: In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-2AC89B40-F98D-4044-9EAF-B6FBAB642D69 Message-Id: <97F8D445-19D6-41BE-BFBE-C13D58080F9B@isoc.org> X-Mailer: iPad Mail (9B206) From: Robin Wilton Date: Fri, 6 Dec 2013 09:37:28 +0000 To: David Lloyd-Jones Cc: perpass , Bruce Perens , Bradford DeLong Subject: Re: [perpass] Henry Farrell Article 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 09:33:32 -0000 --Apple-Mail-2AC89B40-F98D-4044-9EAF-B6FBAB642D69 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The only quibble I have is with the article's assertion that "hundreds of th= ousands" of people in the US have access to classified and potentially embar= rassing documents.=20 That figure is far too low.=20 The government's own figures for 2011 are that 4.8 million people have "clas= sified" clearance, and 1.4 million are cleared for Top Secret.=20 R Robin Wilton Technical Outreach Director - Identity and Privacy On 6 Dec 2013, at 09:02, David Lloyd-Jones wrot= e: > Everybody will want to see Henry's good article at http://www.foreignaffai= rs.com/articles/140155/henry-farrell-and-martha-finnemore/the-end-of-hypocri= sy?nocache=3D1 > =20 > Foreign Affairs has made a remarkable comeback in the past year or 18 mont= hs; I'm not sure, but this may be the result of the excellent young Hamilto= n Fish III getting involved. =20 >=20 > Just an impression, not Gospel. Anyway, a fine place to see Henry's stuff= appearing. > =20 > -dlj. > =20 >=20 --Apple-Mail-2AC89B40-F98D-4044-9EAF-B6FBAB642D69 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
The only quibble I have is= with the article's assertion that "hundreds of thousands" of people in the U= S have access to classified and potentially embarrassing documents. 

That figure is far too low. 

The government's own figures for 2011 are that 4.8 million people have= "classified" clearance, and 1.4 million are cleared for Top Secret. 

R

Robin Wilton

Technical Outreac= h Director - Identity and Privacy

On 6 Dec 2013, a= t 09:02, David Lloyd-Jones <david.lloydjones@gmail.com> wrote:

Everybody will want to see Henry's go= od article at http://= www.foreignaffairs.com/articles/140155/henry-farrell-and-martha-finnemore/th= e-end-of-hypocrisy?nocache=3D1
 
Foreign Affairs has made a remarkable comeback in the past y= ear or 18 months;  I'm not sure, but this may be the result of the exce= llent young Hamilton Fish III getting involved.  

<= div> Just an impression, not Gospel.  Anyway, a fine place to see Henry's st= uff appearing.
 
-dlj.
 
= --Apple-Mail-2AC89B40-F98D-4044-9EAF-B6FBAB642D69-- From sm@resistor.net Fri Dec 6 01:36:58 2013 Return-Path: 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 C92311AD93D for ; Fri, 6 Dec 2013 01:36:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01] 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 J3gfHtdj-F7p for ; Fri, 6 Dec 2013 01:36:57 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id BCB951AD8F1 for ; Fri, 6 Dec 2013 01:36:57 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id rB69acv0029523; Fri, 6 Dec 2013 01:36:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1386322603; bh=DA5UNFQ1WTCq+lisj9RyTlFM99XXiwOtnyfeRUTHNDA=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=0fddMUIBSNdKE2s0x7tTeUlVFHqkjNdB2KLZxDjCrjkloIfPXQ0fxQGhfulfiSh0u yFh4nETr2FApRkPyCGOS4b61detJxYBzo08+ieYRom+Wi9i29hgneirIPRMsuGeJuW SXpBow4OyPUhOOBu3HSg/lnoIIJOHK8G8c02uwKg= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1386322603; i=@resistor.net; bh=DA5UNFQ1WTCq+lisj9RyTlFM99XXiwOtnyfeRUTHNDA=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=2iwVhK9l6qLe51s9BrcCah7wbHJWKb7/yqB7zTEcTqnM5T4mjUoqLX0J9WWSr3wK6 K9sy/r4rEs7UhcrMt4TufBrdhYwmzXGv6FmYj7etXexSfOHsLmxKvtvTD4JVxFGklG c10lS1+9pPdx1op67cv5y81I7EZXv7WN61gOT9uo= Message-Id: <6.2.5.6.2.20131206000507.0bdb7c20@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 06 Dec 2013 01:20:17 -0800 To: Pranesh Prakash From: SM In-Reply-To: <52A15835.2070901@cis-india.org> References: <529E8494.7000806@perens.com> <20131204111309.GB11727@nic.fr> <529F61D8.6030105@perens.com> <20131204171207.GC19914@thunk.org> <529F63C0.3040804@perens.com> <529F88AC.3090904@appelbaum.net> <529F90A0.8000706@perens.com> <529F9205.30906@appelbaum.net> <529F98C0.9090808@perens.com> <529F9F14.8050805@appelbaum.net> <529FB61A.7090604@perens.com> <529FBEF9.7030205@appelbaum.net> <529FC347.3080806@perens.com> <52A15835.2070901@cis-india.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: perpass@ietf.org, Bruce Perens 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 09:36:59 -0000 Hi Pranesh, At 20:53 05-12-2013, Pranesh Prakash wrote: >This is not a debate about whether surveillance is good or not. >(Targetted surveillance which is allowed by a law, has a legitimate aim >in a democratic society, is not arbitrary, is necessary to achieve those >aims, is proportionate, authorized by a judicial process, etc., would be >legitimate.) This is a debate about whether it is technically (and >politically) desirable for protocols to prevent mass surveillance. I read http://cis-india.org/internet-governance/blog/indias-big-brother-the-central-monitoring-system There are likely similar cases in other countries. What could be the effect if (widely deployed) IETF protocols prevented such systems from working? It is possible to design a protocol which does not allow "in the clear" traffic [1]. It is not clear whether such a protocol would be widely deployed. >There is no reason why the 'default' insecurity of HTTP cannot be >handled at the technical level. Do I believe all HTTP2 traffic MUST be >encrypted? Perhaps, and perhaps not. But most certainly, the 'default' >for HTTP2 traffic should be encryption. Ok. Regards, -sm 1. That is different from the "default". From elijah@bitmask.net Fri Dec 6 02:05:52 2013 Return-Path: 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 24B551AE315 for ; Fri, 6 Dec 2013 02:05:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.855 X-Spam-Level: ** X-Spam-Status: No, score=2.855 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.793, UNPARSEABLE_RELAY=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 w1BlwBAAVMIo for ; Fri, 6 Dec 2013 02:05:50 -0800 (PST) Received: from leech.bitmask.net (unknown [198.252.153.85]) by ietfa.amsl.com (Postfix) with ESMTP id A09281AE318 for ; Fri, 6 Dec 2013 02:05:50 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Authenticated sender: UNLIMITED4nkmaf29wdg6zmo8engw00hnz) with ESMTPS id DB9231EC75 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha512"; boundary="===============6531062071695376651==" Date: Fri, 06 Dec 2013 02:05:38 -0800 From: Elijah Sparrow To: perpass@ietf.org References: <20131205072546.2740.2142915422.0@crow> In-Reply-To: <20131205072546.2740.2142915422.0@crow> Message-Id: <20131206100541.2819.1939647307.0@crow> OpenPGP: id=F53BC597A48FF10C; url="https://bitmask.net/key/elijah"; preference="signencrypt" 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 10:05:52 -0000 --===============6531062071695376651== Received: by bitmask.local from 127.0.0.1 with ESMTP ; Fri, 06 Dec 2013 02:05:40 -0800 Message-ID: <52A1A172.3020604@bitmask.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 QXMgaXQgaGFwcGVucywgdGhlIEd1YXJkaWFuIGp1c3QgcG9zdGVkIGEgY29tbWVudGFyeSBvbiB0 aGUgdmVyeSB0b3BpYw0Kb2YgZW5naW5lZXJpbmcgZXRoaWNzIGFuZCBzdXJ2ZWlsbGFuY2U6DQoN Cmh0dHA6Ly93d3cudGhlZ3VhcmRpYW4uY29tL2NvbW1lbnRpc2ZyZWUvMjAxMy9kZWMvMDUvZW5n aW5lZXJpbmctbW9yYWwtZWZmZWN0cy10ZWNobm9sb2d5LWltcGFjdA0KDQpJbiBicmllZjoNCg0K PiBIb3dldmVyLCB3ZSBhcmUgc3RpbGwgZXNzZW50aWFsbHkgcHJvZHVjaW5nIHdoYXQgaW5kdXN0 cnkgcmVxdWlyZXM6DQo+IGVuZ2luZWVycyBhYmxlIHRvIGNhcnJ5IG91dCB0ZWNobmljYWxseSBj b21wbGV4IHByb2plY3RzLCByYXRoZXIgdGhhbg0KPiBwcm9mZXNzaW9uYWxzIHdpdGggYW4gaW4t ZGVwdGggdW5kZXJzdGFuZGluZyBvZiB0aGUgc29jaWFsIGNvbXBsZXhpdHkNCj4gb2YgdGVjaG5v bG9neQ0KDQotZWxpamFoDQoNCi0tDQpJIHByZWZlciBlbmNyeXB0ZWQgZW1haWwgLSBodHRwczov L2JpdG1hc2submV0L2tleS9lbGlqYWguDQo= --===============6531062071695376651== Content-Type: application/pgp-signature; name="signature.asc" MIME-Version: 1.0 Content-Description: OpenPGP Digital Signature -----BEGIN PGP SIGNATURE----- iQIcBAABCgAGBQJSoaF1AAoJEPU7xZekj/EMSbUP/Roqu5S3e3svEr2gI1DLflxY vb9RA6i5n8X6hIhlx+Dt00BHxniIUxLxc1nsTLrqmjzcss3YH0PGlXsi7ecXHyEz Ej3GOIaXqp3YJyKXf07EYFKrIeunKa8oTsFusUGXx2kKtDCRnqA8Iwmt5ZKiWYet qS34/QjO+Ic8GE9XwZkqlMv9sQBrOIbBAnQ5WifZnPosUcVX/Hk2OnU1pQexV/bh 1SLk/7wSHVVLBCjZfi5w7zpWOdOef5l+90KVQjUZ1eOixaxrCcECdO7k3ca6wJa7 UGRRuE1gVg29e4FmEf2ZIduXfD9mJPac3aOSGf1j7otC0mCWCtWloPshHJHthBhm S/y12q5bEquhYge1OFTHw0no8xZHweBUQBAlV2Bbrqf10xnKJyNLKQfjyCzRzYL5 TsuubvZlptkSKzvxCYUe2Erdxxoym23R51AsYxu32X2t4EruHz9Cw3E+10CIIYlf rKBKzGHD+SI3kHdXCJSbvEez2zdiOYRlEkHlgS/cACr6hg3GpBMuXQnnPChX6btX K4vpvLv6g4h+dM1CqNZ5Wwd2ANNbDjjM+f0wvXcoIMXSp3+Y3iI8sPOZjr+CsCVi 21vxs2PzIeOaT3mwv3PEGI61nr+XHe3wpgFeIxO2W2QWmTFglphy0H2Utuz6W61P tiJAVvd7o80ujybEVIDI =MUsq -----END PGP SIGNATURE----- --===============6531062071695376651==-- From a.kuckartz@ping.de Fri Dec 6 03:31:18 2013 Return-Path: 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 353391AE34C for ; Fri, 6 Dec 2013 03:31:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.849 X-Spam-Level: * X-Spam-Status: No, score=1.849 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FSL_HELO_BARE_IP_2=2, HELO_EQ_DE=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 mqhPcsIwyQER for ; Fri, 6 Dec 2013 03:31:16 -0800 (PST) Received: from lilly.ping.de (lilly.ping.de [83.97.42.2]) by ietfa.amsl.com (Postfix) with SMTP id D51B91AE352 for ; Fri, 6 Dec 2013 03:31:15 -0800 (PST) Received: (qmail 15998 invoked from network); 6 Dec 2013 11:31:11 -0000 Received: (ofmipd 83.97.42.23); 6 Dec 2013 11:30:49 -0000 Received: from 85-22-27-195.ip.dokom21.de ([85.22.27.195] helo=127.0.0.1) by lucy.ping.de with esmtpa (Exim 4.72) (envelope-from ) id 1Votck-0006zR-3L; Fri, 06 Dec 2013 12:31:10 +0100 Date: 6 Dec 2013 12:30:56 +0100 Message-ID: <52A1B570.7000205@ping.de> From: "Andreas Kuckartz" To: "SM" MIME-Version: 1.0 References: <529E8494.7000806@perens.com> <20131204111309.GB11727@nic.fr> <529F61D8.6030105@perens.com> <20131204171207.GC19914@thunk.org> <529F63C0.3040804@perens.com> <529F88AC.3090904@appelbaum.net> <529F90A0.8000706@perens.com> <529F9205.30906@appelbaum.net> <529F98C0.9090808@perens.com> <529F9F14.8050805@appelbaum.net> <529FB61A.7090604@perens.com> <529FBEF9.7030205@appelbaum.net> <529FC347.3080806@perens.com> <52A15835.2070901@cis-india.org> <6.2.5.6.2.20131206000507.0bdb7c20@resistor.net> In-Reply-To: <6.2.5.6.2.20131206000507.0bdb7c20@resistor.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: perpass@ietf.org, Pranesh Prakash , Bruce Perens 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 11:31:18 -0000 SM: > I read > http://cis-india.org/internet-governance/blog/indias-big-brother-the-central-monitoring-system > There are likely similar cases in other countries. > > What could be the effect if (widely deployed) IETF protocols prevented > such systems from working? It is possible to design a protocol which > does not allow "in the clear" traffic [1]. It is not clear whether such > a protocol would be widely deployed. Jörg Ziercke, the president of the German Federal Criminal Office (BKA) three weeks ago suggested to restrict the right to use Tor by requiring the registration of users. Standards can not solve such political and legal attempts to attack the privacy and security of users. But that should not prevent the development of standards which disable mass surveillance when those standards are deployed. Cheers, Andreas From jacob@appelbaum.net Fri Dec 6 03:53:36 2013 Return-Path: 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 C19A71ADF60 for ; Fri, 6 Dec 2013 03:53:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.6 X-Spam-Level: X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FSL_HELO_BARE_IP_2=2, RCVD_IN_DNSWL_LOW=-0.7] 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 U14FU7dg1Ble for ; Fri, 6 Dec 2013 03:53:35 -0800 (PST) Received: from mail-ee0-f52.google.com (mail-ee0-f52.google.com [74.125.83.52]) by ietfa.amsl.com (Postfix) with ESMTP id 436DF1ADEBB for ; Fri, 6 Dec 2013 03:53:35 -0800 (PST) Received: by mail-ee0-f52.google.com with SMTP id d17so244964eek.39 for ; Fri, 06 Dec 2013 03:53:31 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:mime-version:to:subject :references:in-reply-to:openpgp:content-type :content-transfer-encoding; bh=XarRBEUT10VlsBHggugFqN4vtqAwgMNpxaNBTypeYiM=; b=UoTwVlpj9vAT8X9fj+EIvhMVmIQEl9DoJ4NhiFkTQ6GXNow2JieMJw5PMcQHQ0y1ZD kjH9ul0VemfTbL7ud2fEHYpoOfr9OQYLC/zYDgGO4aZ7FTcQtOWb+oXtxT/10NRQff74 S5Psqa7FcelygEADN6lQJ0xdgitB2TxcBCp2cgfvhT04ldszbnjfpOPz9tYdECmPHVvl yrEJp0Kp9n9UpStWpmATwGbqjn1rOWSC/1Qq7G6X68sxy7GK5W4qMV9hbgqgJWeYxIE8 76G7jWS0cDXIVEuA64DmP84+L+bF0gH1tvtp1OMxFGHgiB1M35kG53Dh53s51kyxdnK0 eE1g== X-Gm-Message-State: ALoCoQkMEKd6pG0ZnNjFnNiI/84s4SojkqTU+2q+1oXACGMCwZc+ahaH6jxCCRlJ8JAbxecuKeF4 X-Received: by 10.14.0.201 with SMTP id 49mr2307859eeb.38.1386330810805; Fri, 06 Dec 2013 03:53:30 -0800 (PST) Received: from 127.0.0.1 (tor-exit-01.thehappy3.com. [178.63.97.34]) by mx.google.com with ESMTPSA id h3sm91639167eem.15.2013.12.06.03.53.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 06 Dec 2013 03:53:30 -0800 (PST) Message-ID: <52A1B9AE.3030108@appelbaum.net> Date: Fri, 06 Dec 2013 11:49:02 +0000 From: Jacob Appelbaum MIME-Version: 1.0 To: perpass@ietf.org References: <529E8494.7000806@perens.com> <20131204111309.GB11727@nic.fr> <529F61D8.6030105@perens.com> <20131204171207.GC19914@thunk.org> <529F63C0.3040804@perens.com> <529F88AC.3090904@appelbaum.net> <529F90A0.8000706@perens.com> <529F9205.30906@appelbaum.net> <529F98C0.9090808@perens.com> <529F9F14.8050805@appelbaum.net> <529FB61A.7090604@perens.com> <529FBEF9.7030205@appelbaum.net> <529FC347.3080806@perens.com> <52A15835.2070901@cis-india.org> <6.2.5.6.2.20131206000507.0bdb7c20@resistor.net> <52A1B570.7000205@ping.de> In-Reply-To: <52A1B570.7000205@ping.de> OpenPGP: id=4193A197 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 11:53:37 -0000 Andreas Kuckartz: > SM: >> > I read >> > http://cis-india.org/internet-governance/blog/indias-big-brother-the-central-monitoring-system >> > There are likely similar cases in other countries. >> > >> > What could be the effect if (widely deployed) IETF protocols prevented >> > such systems from working? It is possible to design a protocol which >> > does not allow "in the clear" traffic [1]. It is not clear whether such >> > a protocol would be widely deployed. > Jörg Ziercke, the president of the German Federal Criminal Office (BKA) > three weeks ago suggested to restrict the right to use Tor by requiring > the registration of users. > Herr Ziercke clearly does not understand how Tor or even how IP networks actually function. > Standards can not solve such political and legal attempts to attack the > privacy and security of users. > I agree that standards will not solve political problems in the political sphere. Standards will however limit the political and legal options - as an example - forward secrecy with DHE makes forced key disclosure irrelevant for retroactive decryption - the past traffic cannot be decrypted as the session key is not derived from the identity key. > But that should not prevent the development of standards which disable > mass surveillance when those standards are deployed. I agree. All the best, Jacob From erik.josefsson@europarl.europa.eu Fri Dec 6 05:38:04 2013 Return-Path: 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 8318E1ADFC9 for ; Fri, 6 Dec 2013 05:38:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 maStl_zsWj9p for ; Fri, 6 Dec 2013 05:38:02 -0800 (PST) Received: from SMTP35.europarl.europa.eu (smtp35.europarl.europa.eu [136.173.162.228]) by ietfa.amsl.com (Postfix) with ESMTP id B169B1ADFAD for ; Fri, 6 Dec 2013 05:38:00 -0800 (PST) Received: from EMAILBRUSV63.ep.parl.union.eu (unverified) by SMTP35.europarl.europa.eu (European Parliament) with ESMTP id ; Fri, 6 Dec 2013 14:36:29 +0100 Received: from eicibwp080.ep.parl.union.eu ([136.173.96.210]) by EMAILBRUSV63.ep.parl.union.eu with Microsoft SMTPSVC(6.0.3790.4675); Fri, 6 Dec 2013 14:36:29 +0100 Received: from UCEXBWP021.ep.parl.union.eu ([10.127.249.55]) by eicibwp080.ep.parl.union.eu with Microsoft SMTPSVC(6.0.3790.4675); Fri, 6 Dec 2013 14:36:29 +0100 Received: from UCEXBWP015.ep.parl.union.eu (10.127.249.49) by UCEXBWP021.ep.parl.union.eu (10.127.249.55) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 6 Dec 2013 14:36:28 +0100 Received: from UCEXBWP009.ep.parl.union.eu ([169.254.7.236]) by UCEXBWP015.ep.parl.union.eu ([169.254.2.45]) with mapi id 14.03.0158.001; Fri, 6 Dec 2013 14:36:28 +0100 From: JOSEFSSON Erik To: 'Jacob Appelbaum' , "perpass@ietf.org" Thread-Topic: Study on Rule 103 - utmost transparency Thread-Index: Ac7yg13pYMcmUMqpQC+WnhQMLZL87Q== Date: Fri, 6 Dec 2013 13:36:28 +0000 Message-ID: <4B654B63C9A4614EA1F088B2490E8F3A05D80A@UCEXBWP009.ep.parl.union.eu> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.127.249.9] Content-Type: multipart/alternative; boundary="_000_4B654B63C9A4614EA1F088B2490E8F3A05D80AUCEXBWP009epparlu_" MIME-Version: 1.0 X-OriginalArrivalTime: 06 Dec 2013 13:36:29.0247 (UTC) FILETIME=[2B131CF0:01CEF288] Subject: [perpass] Study on Rule 103 - utmost transparency 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 13:38:04 -0000 --_000_4B654B63C9A4614EA1F088B2490E8F3A05D80AUCEXBWP009epparlu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Rule 103 says the European Parliament shall ensure that its activities are = conducted with the utmost transparency. The MEPs has urged for more than tw= o years its administrative leadership to commission a legal study on if and= how Rule 103 should inform its ICT decisions, see: https://joinup.ec.europ= a.eu/community/osor/news/greens/efa-press-eps-president-open-source That study has not yet been commissioned, still the Bureau of the EP will t= ake decisions, in camera, on Monday 9 December 2013 at 19h15 in Room LOW R1= .1 in Strasbourg (quoting from the public draft agenda): 5. Improving IT information security: immediate and mid-term measures - Not= e from the Secretary-General With Jacob reporting about imsi-catchers and others about mim-attacks in th= e European Parliament, I fear the Secretary-General will recommend to take = measures in breach of Rule 103. Best regards. //Erik --_000_4B654B63C9A4614EA1F088B2490E8F3A05D80AUCEXBWP009epparlu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Rule 103 says the European Parliament shall ensur= e that its activities are conducted with the utmost transparency. The MEPs = has urged for more than two years its administrative leadership to commissi= on a legal study on if and how Rule 103 should inform its ICT decisions, see: https://joinup.ec.europa.eu/comm= unity/osor/news/greens/efa-press-eps-president-open-source

 

That study has not yet been commissioned, still t= he Bureau of the EP will take decisions, in camera, on Monday 9 December 20= 13 at 19h15 in Room LOW R1.1 in Strasbourg (quoting from the public draft a= genda):

 

5. Improving IT i= nformation security: immediate and mid-term measures - Note from the Secret= ary-General

 

With Jacob reporting about imsi-catchers and othe= rs about mim-attacks in the European Parliament, I fear the Secretary-Gener= al will recommend to take measures in breach of Rule 103.

 

Best regards.

 

//Erik

--_000_4B654B63C9A4614EA1F088B2490E8F3A05D80AUCEXBWP009epparlu_-- From kent@bbn.com Fri Dec 6 07:10:56 2013 Return-Path: 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 ; 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 ; 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 ; 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 ) 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 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> <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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 15:10:56 -0000 This is a multi-part message in MIME format. --------------050509080200060007050704 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 --------------050509080200060007050704 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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
--------------050509080200060007050704-- From drc@virtualized.org Fri Dec 6 08:12:24 2013 Return-Path: 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 569E51AE092 for ; Fri, 6 Dec 2013 08:12:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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 OFBt4Ixmkw9x for ; Fri, 6 Dec 2013 08:12:22 -0800 (PST) Received: from alpha.virtualized.org (alpha.virtualized.org [199.233.229.186]) by ietfa.amsl.com (Postfix) with ESMTP id 33D531ADFFB for ; Fri, 6 Dec 2013 08:12:22 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by alpha.virtualized.org (Postfix) with ESMTP id EA65A84CEF; Fri, 6 Dec 2013 11:12:17 -0500 (EST) Received: from alpha.virtualized.org ([127.0.0.1]) by localhost (alpha.virtualized.org [127.0.0.1]) (maiad, port 10024) with ESMTP id 25333-05; Fri, 6 Dec 2013 11:12:17 -0500 (EST) Received: from [10.0.1.6] (c-24-4-109-25.hsd1.ca.comcast.net [24.4.109.25]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: drc@virtualized.org) by alpha.virtualized.org (Postfix) with ESMTPSA id 4BEF5848F1; Fri, 6 Dec 2013 11:12:15 -0500 (EST) Content-Type: multipart/signed; boundary="Apple-Mail=_DCAC32BC-8923-49F0-B075-7E9FC741B5FE"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: David Conrad In-Reply-To: Date: Fri, 6 Dec 2013 08:12:12 -0800 Message-Id: <30BA9CB8-129F-4D9A-AF5F-EB6309A4F15A@virtualized.org> References: <52A050E7.8010405@uni-due.de> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1822) Cc: Randy Bush , perpass , =?iso-8859-1?Q?Matth=E4us_Wander?= Subject: Re: [perpass] A reminder, the Network is the Enemy... 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 16:12:24 -0000 --Apple-Mail=_DCAC32BC-8923-49F0-B075-7E9FC741B5FE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Dec 5, 2013, at 7:27 AM, Phillip Hallam-Baker = wrote: > A better approach is to design the system so that it takes a defection = by more than one party. Instead of relying on just the ICANN root KSK = require a TLD to be signed by three out of five trusted national = cryptolabs. Trusted by whom? E.g., trusted like NIST now? (No disrespect of folks at = NIST intended: just observing some may no longer view them as trustable) I personally believe a better approach is to make the operation of the = system extremely public and documented such that it doesn't matter who = is involved since the risk would be too high that attempts at compromise = would be observed. This is what ICANN tried to do with the root KSK (one = can argue whether they succeeded).=20 Regards, -drc --Apple-Mail=_DCAC32BC-8923-49F0-B075-7E9FC741B5FE Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJSofddAAoJENV6ebf0/4rXNT4H/1zBQcsCV0nNlrQIGpiqwZGM Q7sX8hXvfajaIMr2afwDwx4t1YGxmNSm75etwCEzUW7olQsrF0pLLpIRXGzfsUs/ 1G3zc239JllUsBmFPv2cAFsKWhsFTvJAD9mZeESOQiQE7TOlbvu4Qzjx92IBKUFj MgLMUOMd//P6iplUIr4q8zZFoBeuNT4T/J5N08UiqlT2YSdU4hif1vvvWgMD9yYs JxUQflTrJAFj6z6bgYI+VNBQrxXARWCTcuUArhOC+MXGfhLhdBi3hykEFK3G4eZX HW4rP4YF0NcNz7KHvQc+61bFM3Sbg7LpJaYE3UcJXFvPUwS/O7v4NRmyACybI9o= =6fZs -----END PGP SIGNATURE----- --Apple-Mail=_DCAC32BC-8923-49F0-B075-7E9FC741B5FE-- From wilton@isoc.org Fri Dec 6 08:55:37 2013 Return-Path: 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 8A65D1AE3A2 for ; Fri, 6 Dec 2013 08:55:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 qr2TU8vAoNAd for ; Fri, 6 Dec 2013 08:55:35 -0800 (PST) Received: from smtp86.iad3a.emailsrvr.com (smtp86.iad3a.emailsrvr.com [173.203.187.86]) by ietfa.amsl.com (Postfix) with ESMTP id A04F41AE054 for ; Fri, 6 Dec 2013 08:55:35 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp11.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id D05AD28013A; Fri, 6 Dec 2013 11:55:31 -0500 (EST) X-Virus-Scanned: OK Received: by smtp11.relay.iad3a.emailsrvr.com (Authenticated sender: wilton-AT-isoc.org) with ESMTPSA id 4BB8B2800DD; Fri, 6 Dec 2013 11:55:31 -0500 (EST) References: <97F8D445-19D6-41BE-BFBE-C13D58080F9B@isoc.org> In-Reply-To: <97F8D445-19D6-41BE-BFBE-C13D58080F9B@isoc.org> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-98DC50C0-FF56-4E28-9A04-9A82F1705A30 Message-Id: <835ABB99-21BC-4ADF-95DE-F749D594DC0E@isoc.org> X-Mailer: iPad Mail (9B206) From: Robin Wilton Date: Fri, 6 Dec 2013 16:59:34 +0000 To: Robin Wilton Cc: perpass , David Lloyd-Jones , Bruce Perens , Bradford DeLong Subject: Re: [perpass] Henry Farrell Article 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 16:55:37 -0000 --Apple-Mail-98DC50C0-FF56-4E28-9A04-9A82F1705A30 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Many thanks to a couple of folks who have had the knowledge to point out tha= t having clearance is not the same as having access to sensitive material, a= nd the tact and kindness to let me know off-list. Have a good weekend, everyone, Robin Robin Wilton Technical Outreach Director - Identity and Privacy On 6 Dec 2013, at 09:37, Robin Wilton wrote: > The only quibble I have is with the article's assertion that "hundreds of t= housands" of people in the US have access to classified and potentially emba= rrassing documents.=20 >=20 > That figure is far too low.=20 >=20 > The government's own figures for 2011 are that 4.8 million people have "cl= assified" clearance, and 1.4 million are cleared for Top Secret.=20 >=20 > R >=20 > Robin Wilton >=20 > Technical Outreach Director - Identity and Privacy >=20 > On 6 Dec 2013, at 09:02, David Lloyd-Jones wr= ote: >=20 >> Everybody will want to see Henry's good article at http://www.foreignaffa= irs.com/articles/140155/henry-farrell-and-martha-finnemore/the-end-of-hypocr= isy?nocache=3D1 >> =20 >> Foreign Affairs has made a remarkable comeback in the past year or 18 mon= ths; I'm not sure, but this may be the result of the excellent young Hamilt= on Fish III getting involved. =20 >>=20 >> Just an impression, not Gospel. Anyway, a fine place to see Henry's stuf= f appearing. >> =20 >> -dlj. >> =20 >>=20 > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass --Apple-Mail-98DC50C0-FF56-4E28-9A04-9A82F1705A30 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Many thanks to a couple of= folks who have had the knowledge to point out that having clearance is not t= he same as having access to sensitive material, and the tact and kindness to= let me know off-list.

Have a good weekend, everyon= e,

Robin

Robin Wilton

Technical= Outreach Director - Identity and Privacy

On 6 Dec= 2013, at 09:37, Robin Wilton <wilton@= isoc.org> wrote:

The only quibble I have is with the article's assertion that "hundre= ds of thousands" of people in the US have access to classified and potential= ly embarrassing documents. 

That figure is far= too low. 

The government's own figures for 20= 11 are that 4.8 million people have "classified" clearance, and 1.4 million a= re cleared for Top Secret. 

R

Robin Wil= ton

Technical Outreach Director - Identity and Privacy

On 6 Dec 2013, at 09:02, David Lloyd-Jones <david.lloydjones@gmail.com> wrote:=

Eve= rybody will want to see Henry's good article at http://www.foreignaffairs.com/articles/140155/hen= ry-farrell-and-martha-finnemore/the-end-of-hypocrisy?nocache=3D1
 
Foreign Affairs has made a remarkable comeback in the past y= ear or 18 months;  I'm not sure, but this may be the result of the exce= llent young Hamilton Fish III getting involved.  

<= div> Just an impression, not Gospel.  Anyway, a fine place to see Henry's st= uff appearing.
 
-dlj.
 
_= ______________________________________________
perpass maili= ng list
perpass@ietf.org=
https://www.ietf.org/mailman/listinfo/perpass
= --Apple-Mail-98DC50C0-FF56-4E28-9A04-9A82F1705A30-- From sm@resistor.net Fri Dec 6 09:07:06 2013 Return-Path: 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 A1ED61AE0F7 for ; Fri, 6 Dec 2013 09:07:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01] 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 SWTdVaDXjv4R for ; Fri, 6 Dec 2013 09:07:05 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id C0CF71AE0A7 for ; Fri, 6 Dec 2013 09:07:05 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id rB6H6maL011796; Fri, 6 Dec 2013 09:06:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1386349614; bh=aKpNkegerBK8YGEPK/LzukBuhupOxEjoZ1A7pZn6N/Y=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=W4D/PvznWUHi4KrDOBJjKFcI6YZ+qF6cBPEWWpTWLeY+ebIOT76A6FhanFEcU97V5 2VgBh4uNCt14Ssoml8F1WEp+cuRubxLtn/ar1oDEL5rVaauURLeVQoYf/KbtkFRImX q0ZjV69C5QAxuvIOwR9IqNvFe++vnLqWmeGDzf8U= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1386349614; i=@resistor.net; bh=aKpNkegerBK8YGEPK/LzukBuhupOxEjoZ1A7pZn6N/Y=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=j7/QMQPy+JdjkeIz61E4RT2psEXtfZ7cYn4nUkHt6uOMx4VGL/exIY70H2E/jKzUk cOfhNL1OhEKSbmZVemv0f4yPVvZhJKjMA+VzMX5DRhlW+Jh7kSmFc9ckyOnw/HXO8z BoXKx0CYGqIXO1bWbtWZ2u6ofg9o52Axd4lZLmzU= Message-Id: <6.2.5.6.2.20131206083304.0c6fa0c8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 06 Dec 2013 09:01:25 -0800 To: "Andreas Kuckartz" From: SM In-Reply-To: <52A1B570.7000205@ping.de> References: <529E8494.7000806@perens.com> <20131204111309.GB11727@nic.fr> <529F61D8.6030105@perens.com> <20131204171207.GC19914@thunk.org> <529F63C0.3040804@perens.com> <529F88AC.3090904@appelbaum.net> <529F90A0.8000706@perens.com> <529F9205.30906@appelbaum.net> <529F98C0.9090808@perens.com> <529F9F14.8050805@appelbaum.net> <529FB61A.7090604@perens.com> <529FBEF9.7030205@appelbaum.net> <529FC347.3080806@perens.com> <52A15835.2070901@cis-india.org> <6.2.5.6.2.20131206000507.0bdb7c20@resistor.net> <52A1B570.7000205@ping.de> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Cc: perpass@ietf.org, Pranesh Prakash , Bruce Perens Subject: [perpass] Egal wie man diskutiert (was: 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 17:07:06 -0000 Hi Andreas, At 03:30 06-12-2013, Andreas Kuckartz wrote: >J=F6rg Ziercke, the president of the German Federal Criminal Office (BKA) >three weeks ago suggested to restrict the right to use Tor by requiring >the registration of users. Here is an (unverified) comment from someone working for the BKA: "Egal wie man diskutiert, man muss sich hier entscheiden, ob man den Ermittlungserfolg will oder nicht." >Standards can not solve such political and legal attempts to attack the >privacy and security of users. > >But that should not prevent the development of standards which disable >mass surveillance when those standards are deployed. The short answer is yes. Regards, -sm=20 From fergdawgster@mykolab.com Fri Dec 6 10:46:38 2013 Return-Path: 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 436101ADFF7 for ; Fri, 6 Dec 2013 10:46:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, 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 B8pf77It-wqW for ; Fri, 6 Dec 2013 10:46:36 -0800 (PST) Received: from mx01.mykolab.com (mx01.mykolab.com [95.128.36.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D1551A1F6F for ; Fri, 6 Dec 2013 10:46:35 -0800 (PST) X-Virus-Scanned: amavisd-new at kolabsys.net Sender: fergdawgster@mykolab.com Message-ID: <52A21B80.8070005@mykolab.com> Date: Fri, 06 Dec 2013 10:46:24 -0800 From: Paul Ferguson Organization: Clowns R. Mofos To: Pranesh Prakash References: <529E8494.7000806@perens.com> <20131204111309.GB11727@nic.fr> <529F61D8.6030105@perens.com> <20131204171207.GC19914@thunk.org> <529F63C0.3040804@perens.com> <529F88AC.3090904@appelbaum.net> <529F90A0.8000706@perens.com> <529F9205.30906@appelbaum.net> <529F98C0.9090808@perens.com> <529F9F14.8050805@appelbaum.net> <529FB61A.7090604@perens.com> <529FBEF9.7030205@appelbaum.net> <529FC347.3080806@perens.com> <52A15835.2070901@cis-india.org> In-Reply-To: <52A15835.2070901@cis-india.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 Reply-To: fergdawgster@mykolab.com 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: Fri, 06 Dec 2013 18:46:38 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/5/2013 8:53 PM, Pranesh Prakash wrote: > You can opt out of the Concealment Society if you want to. But please > don't force me to stay within the Surveillance Society. I really like this quote. Mind if I use it? :-) - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 10.2.0 (Build 2317) Charset: utf-8 wj8DBQFSoht8q1pz9mNUZTMRArnVAKDEM7glEWiNah/tHq+IBk5CCFLAOgCgqvId a/iwcG/ezo1+kXdOoGAtGzg= =j+po -----END PGP SIGNATURE----- -- Paul Ferguson PGP Public Key ID: 0x63546533 From bruce@perens.com Fri Dec 6 10:53:14 2013 Return-Path: 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 944391ADF6E for ; Fri, 6 Dec 2013 10:53:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.177 X-Spam-Level: X-Spam-Status: No, score=-1.177 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, 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 zeDGcyerJ33H for ; Fri, 6 Dec 2013 10:53:14 -0800 (PST) Received: from alchemy.perens.com (alchemy.perens.com [206.221.219.26]) by ietfa.amsl.com (Postfix) with ESMTP id E7A0A1ADF8A for ; Fri, 6 Dec 2013 10:53:13 -0800 (PST) Received: from [192.168.10.146] (c-50-168-114-183.hsd1.ca.comcast.net [50.168.114.183]) by alchemy.perens.com (Postfix) with ESMTPSA id EB32450008A for ; Fri, 6 Dec 2013 10:53:09 -0800 (PST) Message-ID: <52A21D1C.8020000@perens.com> Date: Fri, 06 Dec 2013 10:53:16 -0800 From: Bruce Perens User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131103 Icedove/17.0.10 MIME-Version: 1.0 To: perpass@ietf.org References: <529E8494.7000806@perens.com> <20131204111309.GB11727@nic.fr> <529F61D8.6030105@perens.com> <20131204171207.GC19914@thunk.org> <529F63C0.3040804@perens.com> <529F88AC.3090904@appelbaum.net> <529F90A0.8000706@perens.com> <529F9205.30906@appelbaum.net> <529F98C0.9090808@perens.com> <529F9F14.8050805@appelbaum.net> <529FB61A.7090604@perens.com> <529FBEF9.7030205@appelbaum.net> <529FC347.3080806@perens.com> <52A15835.2070901@cis-india.org> <52A21B80.8070005@mykolab.com> In-Reply-To: <52A21B80.8070005@mykolab.com> Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 18:53:14 -0000


> You can opt out of the Concealment Society if you want to.  But please
> don't force me to stay within the Surveillance Society.
This will be just fine if it's true. How do I opt out of the Concealment Society if browsers and servers implement HTTP 2.0 as proposed, eventually dropping support for HTTP 1, and neither the browser or server have an in-the-clear mode?

That's really all this discussion is about. Not any advisory to run https preferentially, but the fact that http isn't being left in the standard.

    Thanks

    Bruce
From nweaver@icsi.berkeley.edu Fri Dec 6 10:58:10 2013 Return-Path: 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 DC1141AE087 for ; Fri, 6 Dec 2013 10:58:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 UA7DRD5bMun0 for ; Fri, 6 Dec 2013 10:58:09 -0800 (PST) Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id 167141AE066 for ; Fri, 6 Dec 2013 10:58:09 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 9746A2C400B; Fri, 6 Dec 2013 10:58:05 -0800 (PST) X-Virus-Scanned: amavisd-new at ICSI.Berkeley.EDU Received: from rock.ICSI.Berkeley.EDU ([127.0.0.1]) by localhost (maihub.ICSI.Berkeley.EDU [127.0.0.1]) (amavisd-new, port 10024) with LMTP id jl-l2uAf-XTX; Fri, 6 Dec 2013 10:58:05 -0800 (PST) Received: from [192.168.0.4] (nweaver-monitored-ap.icir.org [192.150.187.133]) (Authenticated sender: nweaver) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 3BDCD2C4004; Fri, 6 Dec 2013 10:58:05 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_B3F64F1B-2325-4648-8518-937EFCE7BA80"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Nicholas Weaver In-Reply-To: <52A21D1C.8020000@perens.com> Date: Fri, 6 Dec 2013 10:58:04 -0800 Message-Id: References: <529E8494.7000806@perens.com> <20131204111309.GB11727@nic.fr> <529F61D8.6030105@perens.com> <20131204171207.GC19914@thunk.org> <529F63C0.3040804@perens.com> <529F88AC.3090904@appelbaum.net> <529F90A0.8000706@perens.com> <529F9205.30906@appelbaum.net> <529F98C0.9090808@perens.com> <529F9F14.8050805@appelbaum.net> <529FB61A.7090604@perens.com> <529FBEF9.7030205@appelbaum.net> <529FC347.3080806@perens.com> <52A15835.2070901@cis-india.org> <52A21B80.8070005@mykolab.com> <52A21D1C.8020000@perens.com> To: Bruce Perens X-Mailer: Apple Mail (2.1510) Cc: perpass@ietf.org, Nicholas Weaver 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 18:58:11 -0000 --Apple-Mail=_B3F64F1B-2325-4648-8518-937EFCE7BA80 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Dec 6, 2013, at 10:53 AM, Bruce Perens wrote: >>=20 >>=20 >> > You can opt out of the Concealment Society if you want to. But = please=20 >> > don't force me to stay within the Surveillance Society. > This will be just fine if it's true. How do I opt out of the = Concealment Society if browsers and servers implement HTTP 2.0 as = proposed, eventually dropping support for HTTP 1, and neither the = browser or server have an in-the-clear mode? >=20 > That's really all this discussion is about. Not any advisory to run = https preferentially, but the fact that http isn't being left in the = standard. Include a checkbox in the browser saying "Fuck it all, show my data to = the world" which broadcasts the session key in the clear. And see how many people click on it... Unencrypted traffic is a vulnerability. Failing to close a = vulnerability that is going to be exploited by every nation on the = planet but your own is lunacy. -- Nicholas Weaver it is a tale, told by an idiot, nweaver@icsi.berkeley.edu full of sound and fury, 510-666-2903 .signifying nothing PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc --Apple-Mail=_B3F64F1B-2325-4648-8518-937EFCE7BA80 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCgAGBQJSoh48AAoJEG2B1w+SDi/uZ5sP/0rAL6pYmPX23znzzc8ibkcy 9IlvOFccH/E4yEWzbI3KXkkbXCzyQ0MFAd/9CG9OR1nBvlLc/GPv7hv7dlpAhYNr A8rQuWj6GYnslmZTW3f9c5Dt9QAO71+QtbYNyAVcTyC2kk/hFihGwV6ZgS+W1Rnn V9Rw5uUHP1ukqoILOG0HjjnIkOGP4lKaIDkbfVugQd4/A/ltokjqhjSIfYDLXccj 3z+FHrtpR3QbCCRxv4zWQkwZ6B4MWpcjMBU0HEEy55o7Xm8EM/5kaxESrBQS6Z8G cAADyuDCUe6O0JqzuNJSLlel97C4CJ5uJtGjNMTTDAwocTEO80C7l7i0AZzlf3eX eIdo3W2Vc7OuVhicVdl6duPR6rNeAqgo6LsuylMGB5CUK7vgCZEs4vwYL7dcx3Zt 6oHVRBVcpe0sucHXbfBXu/Qv69yuYS3+W+taZrOdfntsBYW55qfYHECqfVGFhV47 mgIR7F2dOhDXMog1vG9NFMBeY0eZJN6Nn1C5uDPD3Jd+anmzo3BzVSqMAZKmY0Nf VppWwxKmm9EkOh6GhzEV6aCB7D7B3XvebHtLpNNnuW6bAZNgqrxrO7EJ7nHqJoYf q1SDU0WVeBKRHDZyqF/XgpbzUzA+Ar15o0asFfziZxDJhxGmKI2zpscK3ec1ou5u GOtYFc5/QQSPWvK1uLqz =Dk8q -----END PGP SIGNATURE----- --Apple-Mail=_B3F64F1B-2325-4648-8518-937EFCE7BA80-- From bruce@perens.com Fri Dec 6 11:19:52 2013 Return-Path: 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 1DBC71AE152 for ; Fri, 6 Dec 2013 11:19:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.177 X-Spam-Level: X-Spam-Status: No, score=-1.177 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, 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 TI3w3xY8-lrG for ; Fri, 6 Dec 2013 11:19:51 -0800 (PST) Received: from alchemy.perens.com (alchemy.perens.com [206.221.219.26]) by ietfa.amsl.com (Postfix) with ESMTP id 777631AE146 for ; Fri, 6 Dec 2013 11:19:51 -0800 (PST) Received: from [192.168.10.146] (c-50-168-114-183.hsd1.ca.comcast.net [50.168.114.183]) by alchemy.perens.com (Postfix) with ESMTPSA id D7C4250008A for ; Fri, 6 Dec 2013 11:19:47 -0800 (PST) Message-ID: <52A2235A.2030801@perens.com> Date: Fri, 06 Dec 2013 11:19:54 -0800 From: Bruce Perens User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131103 Icedove/17.0.10 MIME-Version: 1.0 To: perpass@ietf.org References: <529E8494.7000806@perens.com> <20131204111309.GB11727@nic.fr> <529F61D8.6030105@perens.com> <20131204171207.GC19914@thunk.org> <529F63C0.3040804@perens.com> <529F88AC.3090904@appelbaum.net> <529F90A0.8000706@perens.com> <529F9205.30906@appelbaum.net> <529F98C0.9090808@perens.com> <529F9F14.8050805@appelbaum.net> <529FB61A.7090604@perens.com> <529FBEF9.7030205@appelbaum.net> <529FC347.3080806@perens.com> <52A15835.2070901@cis-india.org> <52A21B80.8070005@mykolab.com> <52A21D1C.8020000@perens.com> In-Reply-To: Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 19:19:52 -0000
On 12/06/2013 10:58 AM, Nicholas Weaver wrote:
Include a checkbox in the browser saying "Fuck it all, show my data to the world" which broadcasts the session key in the clear.
I know you intended this to be sarcastic, but opting out of the concealment society does not mean that the user doesn't have the sense to conceal things when it is actually necessary, vs. when it is in their honest opinion an off-the-scale response to the problem.

Punishing them by revealing their credit card numbers is not an appropriate response to their wanting to load static images, javascripts, and CSS in the clear.

    Thanks

    Bruce
From leifj@mnt.se Fri Dec 6 11:22:01 2013 Return-Path: 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 BE32E1AD84D for ; Fri, 6 Dec 2013 11:22:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 Hx_pMsCMv5nI for ; Fri, 6 Dec 2013 11:22:00 -0800 (PST) Received: from mail-lb0-f169.google.com (mail-lb0-f169.google.com [209.85.217.169]) by ietfa.amsl.com (Postfix) with ESMTP id 967F41ADF6E for ; Fri, 6 Dec 2013 11:21:59 -0800 (PST) Received: by mail-lb0-f169.google.com with SMTP id y6so463514lbh.0 for ; Fri, 06 Dec 2013 11:21:55 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=MIEiUj6IA89E9pqjg2JrYXwSgO6gOIXk2df50lHpdGI=; b=A6Lemh7xSBW67yv0QIO/+ygAprkibexX/um4l6n/mG9gtDR15uuN4Ip0UdmtSyzIzm U2ZwjZwsIfSFm3B/cDviShGA5hNBh78AwKFKfxhQgsQqLOZie2Iuvq8A29qpoXswmGBc eOntCxN7GrhQx5tLH2tFZw0UMrWmSQXuAK7OeapA8OPSOt56uK0OLNaSZMOer5Lqd5U/ G0w4+Iz/15vFdrB9uEWGL3Z3q2uyEiuP04i1eiT4vl76i3WWPZg/7sdnJc+1DRN43NLm zSBqhcqmE3vXmkwkjQKZRcWIoUuE1inFLp2+j/OIobOGJxMXtd5PiPmY6y+Uq6d1BmqH Dnqg== X-Gm-Message-State: ALoCoQk0kU9fmMp9BMUOvDaDDSfvoQ1cTmJSdQQOB8WNOxkWqqcEvmCzMabKR6v0tKp/EvLAJBY2 X-Received: by 10.152.219.166 with SMTP id pp6mr1334966lac.46.1386357715123; Fri, 06 Dec 2013 11:21:55 -0800 (PST) Received: from [10.0.0.248] (tb62-102-145-131.cust.teknikbyran.com. [62.102.145.131]) by mx.google.com with ESMTPSA id mq10sm77498715lbb.12.2013.12.06.11.21.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 06 Dec 2013 11:21:54 -0800 (PST) Message-ID: <52A223D0.9000909@mnt.se> Date: Fri, 06 Dec 2013 20:21:52 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: perpass@ietf.org References: <97F8D445-19D6-41BE-BFBE-C13D58080F9B@isoc.org> In-Reply-To: <97F8D445-19D6-41BE-BFBE-C13D58080F9B@isoc.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [perpass] Henry Farrell Article 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 19:22:02 -0000 On 12/06/2013 10:37 AM, Robin Wilton wrote: > The only quibble I have is with the article's assertion that "hundreds > of thousands" of people in the US have access to classified and > potentially embarrassing documents. > > That figure is far too low. > > The government's own figures for 2011 are that 4.8 million people have > "classified" clearance, and 1.4 million are cleared for Top Secret. > Inflation at work. I'm sure there are EV^H^Hhigher cert^H^H^H^Hclassifications with fewer people in them. From nweaver@icsi.berkeley.edu Fri Dec 6 11:31:29 2013 Return-Path: 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 B9B561AE053 for ; Fri, 6 Dec 2013 11:31:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 JU3Y6NJ0YZYg for ; Fri, 6 Dec 2013 11:31:28 -0800 (PST) Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id A8BC81AD84D for ; Fri, 6 Dec 2013 11:31:28 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id E791B2C400B; Fri, 6 Dec 2013 11:31:24 -0800 (PST) X-Virus-Scanned: amavisd-new at ICSI.Berkeley.EDU Received: from rock.ICSI.Berkeley.EDU ([127.0.0.1]) by localhost (maihub.ICSI.Berkeley.EDU [127.0.0.1]) (amavisd-new, port 10024) with LMTP id HkwzqsTbDIMN; Fri, 6 Dec 2013 11:31:24 -0800 (PST) Received: from [192.168.0.4] (nweaver-monitored-ap.icir.org [192.150.187.133]) (Authenticated sender: nweaver) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 4CE6A2C4004; Fri, 6 Dec 2013 11:31:24 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_1DEFFF13-372B-4D1D-B00F-F034F52100A9"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Nicholas Weaver In-Reply-To: <52A2235A.2030801@perens.com> Date: Fri, 6 Dec 2013 11:31:23 -0800 Message-Id: References: <529E8494.7000806@perens.com> <20131204111309.GB11727@nic.fr> <529F61D8.6030105@perens.com> <20131204171207.GC19914@thunk.org> <529F63C0.3040804@perens.com> <529F88AC.3090904@appelbaum.net> <529F90A0.8000706@perens.com> <529F9205.30906@appelbaum.net> <529F98C0.9090808@perens.com> <529F9F14.8050805@appelbaum.net> <529FB61A.7090604@perens.com> <529FBEF9.7030205@appelbaum.net> <529FC347.3080806@perens.com> <52A15835.2070901@cis-india.org> <52A21B80.8070005@mykolab.com> <52A21D1C.8020000@perens.com> <52A2235A.2030801@perens.com> To: Bruce Perens X-Mailer: Apple Mail (2.1510) Cc: perpass@ietf.org, Nicholas Weaver 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 19:31:29 -0000 --Apple-Mail=_1DEFFF13-372B-4D1D-B00F-F034F52100A9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Dec 6, 2013, at 11:19 AM, Bruce Perens wrote: > On 12/06/2013 10:58 AM, Nicholas Weaver wrote: >> Include a checkbox in the browser saying "Fuck it all, show my data = to the world" which broadcasts the session key in the clear. > I know you intended this to be sarcastic, but opting out of the = concealment society does not mean that the user doesn't have the sense = to conceal things when it is actually necessary, vs. when it is in their = honest opinion an off-the-scale response to the problem. >=20 > Punishing them by revealing their credit card numbers is not an = appropriate response to their wanting to load static images, = javascripts, and CSS in the clear. Then make the checkbox "Fuck it all, show my data to the world IF THE = SERVER CONSENTS", and have the leakage require both the server and = client. I'm not kidding here.=20 Cleartext without data integrity is a outright risk on the current and = future Internet. I don't care about surveillance. (Well, I do, = but...). What I care about is attack surface for exploitation, an = attack surface that is enormous, easy to use, and hey, the US government = said "Game on!", and where everyone else can say "It wasn't me. And = hey, even if it was, you started it, sauce pour l'oie..." =20 Especially for "javascripts and CSS" which you seem so happy to pass in = the clear: You let an attacker see a SINGLE ONE of your cleartext = JavaScript or CSS fetches and you are FUBAR. Game over, you're p0wned, = have a nice day. -- Nicholas Weaver it is a tale, told by an idiot, nweaver@icsi.berkeley.edu full of sound and fury, 510-666-2903 .signifying nothing PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc --Apple-Mail=_1DEFFF13-372B-4D1D-B00F-F034F52100A9 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCgAGBQJSoiYLAAoJEG2B1w+SDi/urCoP+wbDqKEMbDxRuw4wpLqKEkal ipu2x9C68bu51zHZwfR6o7msmay4b12bb+pnwSKtd72J8JcJh9/efQSYc14UdfC7 QTrBvXBEz6wO2Bf9wQJhlK9LiVeNxc/H/ziZvjVFzMOOJzat7R6mguT9n7nOKc6L svTTfLxbyYZLOkCRbLhIXqm/plLKLJkAtpJFasuZ8guwB58DT9WnmO7wk/bnhLsF R0AZNnvaJW6U0NOWAKcBHfegICF2RADw/lxCgXkMeUQqzmfy2t4s8fqxDyd1e+RZ FvBPWw78WuDKQBsVdrk/FbOCGZJ1+JjTtJwmmuxB6W+GKfiNFn4klntQp3LTRlGz llZ00ooatoXbO+whCGOI0qEONW1sC7O0jtRIvDlWMTKS54g5K3DIQd8iDpQRDt0i 2usPVq3k9dluBBbdJL+5GBq3HVPBTILrtZ0qrEQzdWPNLv6dWJAo6+S7I/h7wqRd ol1MO+FFPuTd4wyAerXOMLL9cc82lbzBymZzV+QoyKcWFOf3eDp/XL66FfndGwo/ Em5W4AO0kttwjniAI+ZBhEozEEACqCQJbqnr1WQyn/dqo1TWoHf9B3Prc0/pbNWE XQE+aSXic5uAnanfnd9ARbqY1erU9m98sKkHf+D+Vw1abA98bRtevoTM1kTAF1M7 YcrXt+roSpuIO1gHPRjA =MDXv -----END PGP SIGNATURE----- --Apple-Mail=_1DEFFF13-372B-4D1D-B00F-F034F52100A9-- From bruce@perens.com Fri Dec 6 12:04:54 2013 Return-Path: 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 A93CE1AE078 for ; Fri, 6 Dec 2013 12:04:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, 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 iONXL4bkLFO2 for ; Fri, 6 Dec 2013 12:04:53 -0800 (PST) Received: from alchemy.perens.com (alchemy.perens.com [206.221.219.26]) by ietfa.amsl.com (Postfix) with ESMTP id D79F31AE074 for ; Fri, 6 Dec 2013 12:04:53 -0800 (PST) Received: from Bruce-ASUS-Transformer-Prime.home.perens.com (c-50-168-114-183.hsd1.ca.comcast.net [50.168.114.183]) by alchemy.perens.com (Postfix) with ESMTPSA id 5DD31500084; Fri, 6 Dec 2013 12:04:28 -0800 (PST) User-Agent: K-9 Mail for Android In-Reply-To: References: <529E8494.7000806@perens.com> <20131204111309.GB11727@nic.fr> <529F61D8.6030105@perens.com> <20131204171207.GC19914@thunk.org> <529F63C0.3040804@perens.com> <529F88AC.3090904@appelbaum.net> <529F90A0.8000706@perens.com> <529F9205.30906@appelbaum.net> <529F98C0.9090808@perens.com> <529F9F14.8050805@appelbaum.net> <529FB61A.7090604@perens.com> <529FBEF9.7030205@appelbaum.net> <529FC347.3080806@perens.com> <52A15835.2070901@cis-india.org> <52A21B80.8070005@mykolab.com> <52A21D1C.8020000@perens.com> <52A2235A.2030801@perens.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----OXZVTWQEJ21YECRN4MGKK762GTXC7Z" From: Bruce Perens Date: Fri, 06 Dec 2013 11:48:44 -0800 To: Nicholas Weaver Message-ID: 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 20:04:54 -0000 ------OXZVTWQEJ21YECRN4MGKK762GTXC7Z Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 12/06/2013 11:31 AM, Nicholas Weaver wrote: Then make the checkbox "Fuck it all, show my data to the world IF THE SERVER CONSENTS", and have the leakage require both the server and client. I'm not kidding here. So, first lose the obnoxious part. Then, provide them with a real choice: 1. Use HTTP preferentially except where the server specifies HTTPS. Servers will generally specify HTTPS for credit cards, login screens, and other sensitive data. This is potentially the fastest method, but the least secure. 2. Always use HTTPS preferentially for the body page and URLs from the address bar or bookmarks, but load embedded resources within the page using HTTP unless the server directs otherwise. This is a good compromise for most people. 3. Always use HTTPS preferentially for all requests. This is potentially most secure and slowest. Then make the default whatever your preference is. Especially for "javascripts and CSS" which you seem so happy to pass in the clear: You let an attacker see a SINGLE ONE of your cleartext JavaScript or CSS fetches and you are FUBAR. Game over, you're p0wned, have a nice day. See your fetches? I understand MITM, etc., but see them? Thanks Bruce -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. ------OXZVTWQEJ21YECRN4MGKK762GTXC7Z Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit On 12/06/2013 11:31 AM, Nicholas Weaver wrote:


Then make the checkbox "Fuck it all, show my data to the world IF THE SERVER CONSENTS", and have the leakage require both the server and client. I'm not kidding here.

So, first lose the obnoxious part. Then, provide them with a real choice:

1. Use HTTP preferentially except where the server specifies HTTPS. Servers will generally specify HTTPS for credit cards, login screens, and other sensitive data. This is potentially the fastest method, but the least secure.
2. Always use HTTPS preferentially for the body page and URLs from the address bar or bookmarks, but load embedded resources within the page using HTTP unless the server directs otherwise. This is a good compromise for most people.
3. Always use HTTPS preferentially for all requests. This is potentially most secure and slowest.

Then make the default whatever your preference is.

Especially for "javascripts and CSS" which you seem so happy to pass in the clear: You let an attacker see a SINGLE ONE of your cleartext JavaScript or CSS fetches and you are FUBAR. Game over, you're p0wned, have a nice day.

See your fetches? I understand MITM, etc., but see them?

Thanks

Bruce

--
Sent from my Android phone with K-9 Mail. Please excuse my brevity. ------OXZVTWQEJ21YECRN4MGKK762GTXC7Z-- From nweaver@icsi.berkeley.edu Fri Dec 6 13:20:52 2013 Return-Path: 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 976841AE09C for ; Fri, 6 Dec 2013 13:20:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_12=0.6, J_CHICKENPOX_14=0.6, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 j60TC-N4Mfrm for ; Fri, 6 Dec 2013 13:20:51 -0800 (PST) Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id EBF201AE08E for ; Fri, 6 Dec 2013 13:20:50 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 6E82A2C400B; Fri, 6 Dec 2013 13:20:47 -0800 (PST) X-Virus-Scanned: amavisd-new at ICSI.Berkeley.EDU Received: from rock.ICSI.Berkeley.EDU ([127.0.0.1]) by localhost (maihub.ICSI.Berkeley.EDU [127.0.0.1]) (amavisd-new, port 10024) with LMTP id gcFMahan56st; Fri, 6 Dec 2013 13:20:46 -0800 (PST) Received: from [192.168.0.4] (nweaver-monitored-ap.icir.org [192.150.187.133]) (Authenticated sender: nweaver) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id C18C12C4004; Fri, 6 Dec 2013 13:20:46 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_5E27A00F-567F-40F6-992A-6C06947DEB49"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Nicholas Weaver In-Reply-To: Date: Fri, 6 Dec 2013 13:20:46 -0800 Message-Id: <240A2D86-C352-4954-BE4E-6313BA25994E@icsi.berkeley.edu> References: <529E8494.7000806@perens.com> <20131204111309.GB11727@nic.fr> <529F61D8.6030105@perens.com> <20131204171207.GC19914@thunk.org> <529F63C0.3040804@perens.com> <529F88AC.3090904@appelbaum.net> <529F90A0.8000706@perens.com> <529F9205.30906@appelbaum.net> <529F98C0.9090808@perens.com> <529F9F14.8050805@appelbaum.net> <529FB61A.7090604@perens.com> <529FBEF9.7030205@appelbaum.net> <529FC347.3080806@perens.com> <52A15835.2070901@cis-india.org> <52A21B80.8070005@mykolab.com> <52A21D1C.8020000@perens.com> <52A2235A.2030801@perens.com> To: Bruce Perens X-Mailer: Apple Mail (2.1510) Cc: perpass@ietf.org, Nicholas Weaver 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 21:20:52 -0000 --Apple-Mail=_5E27A00F-567F-40F6-992A-6C06947DEB49 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Dec 6, 2013, at 11:48 AM, Bruce Perens wrote: > Then make the default whatever your preference is. The default MUST BE "ALWAYS HTTPS, ALWAYS". Period. Anything less is = abdicating user safety. >> Especially for "javascripts and CSS" which you seem so happy to pass = in the clear: You let an attacker see a SINGLE ONE of your cleartext = JavaScript or CSS fetches and you are FUBAR. Game over, you're p0wned, = have a nice day.=20 >>=20 > See your fetches? I understand MITM, etc., but see them? Yes, SEE just one of these "inconsequential" fetches is sufficient. If = the attacker can see your fetches he can execute a man-on-the-side = attack through packet injection. A wiretap is only passive if the = wiretapper doesn't want to bother spending the couple of hours of = from-scratch code to turn it into an active attacker. Lets take a concrete example. =20 You, Bruce, have nothing to fear from the US government. But hey, = you're doing stuff of some economic significance, and economic = significance =3D valid tagret. Therefore, in this brave new world, = you're a valid target to say, well, France. [1] And France's wiretap = infrastructure knows the IP you commonly use (there are several tricks = to possibly find this out). All the wiretap has to do is wait for that single inconsequential = Javascript fetch from your computer to pass by the wiretap, say, as part = of a completely innocent and unrelated Air France ad campaign that = happened to be on a web page you happened to visit. When it sees the TCP packet containing the HTTP GET, it spoofs an = injected reply packet back to you. If your browser gets the spoofed = reply first (and it will, the spoofed reply has a head start in the = race), it acts on the spoofed reply. This spoofed reply contains a small piece of Javascript which creates a = little, tiny 1x1 hidden iFrame that opens onto France's exploit server = [2], which now runs a full suite of code in your browser to p0wn you. =20= Actually doing packet injection is downright trivial: I've written up a = TCP packet injector in a few hours on a lark, and several years ago it = was a staple of Defcon WiFi pranks, say, by turning every large image = into goat.se. Off the shelf tools and a little glue are pretty much = sufficient for any country to do this [3].=20 In the past, it was only the purvue of pranksters and censorship (the = Great Firewall). And, it turns out the NSA. Thanks to the NSA, now the = future of packet injection is not, well, bright, but readily available = to a whole UN worth of attackers. So yes, a single fetch seen by the adversary is sufficient if the = adversary wants to attack you. If you are lucky, your adversary is all = countries your traffic traverses except your own. [1] I selected Country B, err, France for a reason in this. = http://www.foreignpolicy.com/articles/2013/07/01/espionage_moi_france But pick your country. =20 [2] The NSA's software suite for this is called FOXACID. Everybody else = just uses Metasploit's Browser Autopwn, its the same thing.=20 [3] For those without the exploit expertise, please contact your local = FinFly, Hacking Team, and Vupen sales representatives. They'd be happy = to help provide malcode and exploits to tie into your Metasploit autopwn = system. The packet injector itself? Just have an undergrad write it. = Its a good lab exercise for a networking class. -- Nicholas Weaver it is a tale, told by an idiot, nweaver@icsi.berkeley.edu full of sound and fury, 510-666-2903 .signifying nothing PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc --Apple-Mail=_5E27A00F-567F-40F6-992A-6C06947DEB49 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCgAGBQJSoj+uAAoJEG2B1w+SDi/u+LYP/3K6EQtKTHswPoeQDiczdIxz Gif8WXCmOufsI9vci7sX6+GUi4rKfvep7z1/zHEMMX3X4NcNPjc+HJaSchAqo6Vz t27IvY7GdrXO3ZfqcGdeVLuGMARxLg43SN3Wk5BBRBH6OtsJFUqgH/8bNWW8wMFZ BvfO7cEgLBvIgaDs3vz2JGca0yyevPJ8UZa4XavKLljdJyAxVRjROmh7YYoVIJi7 RrbZFKSkwINj/vvMSFg0v8HC7VeeD7gn8UXVVIa8sOxoB/mOQnBXwNZT7dHoGwig x/aHkSQfoPJaX4xjcKQSK+IXyc9tFibymj+lGgyIvy8+QBa2Hcy6z9GVuUV5XHPV zkAqWI+csId2KBwzpAES01ECG7kcoakTCaF/Ym6ozDQQNQjJcTk27noP9XJUNr14 t2skvDd6sgA6vqzW4FXnQqlPaUeakWSTwpRS8dYh45/VUyhGXbBS5lIq9Z1VLrAP mJAcYtGdM5L232/EA7OtLN/Er/aAbLG1DegMcl2eNoddwzb0yWkMcCfIqcS+VJV+ Cam14ZWPR9eZRjq8e/x2CENC2aBieYWSgyLM7YYaCqJphDeEGOGSuiNUhhPCnHWP o8K0tWwdEgw68wtLXhHIySwDCAj2Ixx0OdBMPURAcPOWoLeYPGDaYift2EYH9BK/ uRxYkah+OlHXaInr5k1f =HA4u -----END PGP SIGNATURE----- --Apple-Mail=_5E27A00F-567F-40F6-992A-6C06947DEB49-- From a.kuckartz@ping.de Fri Dec 6 13:34:34 2013 Return-Path: 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 945531AE072 for ; Fri, 6 Dec 2013 13:34:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.348 X-Spam-Level: ** X-Spam-Status: No, score=2.348 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FSL_HELO_BARE_IP_2=2, HELO_EQ_DE=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 kobyE1oFK8vE for ; Fri, 6 Dec 2013 13:34:33 -0800 (PST) Received: from lilly.ping.de (lilly.ping.de [83.97.42.2]) by ietfa.amsl.com (Postfix) with SMTP id AF27C1AE043 for ; Fri, 6 Dec 2013 13:34:32 -0800 (PST) Received: (qmail 17489 invoked from network); 6 Dec 2013 21:34:28 -0000 Received: (ofmipd 83.97.42.23); 6 Dec 2013 21:34:06 -0000 Received: from 85-22-27-195.ip.dokom21.de ([85.22.27.195] helo=127.0.0.1) by lucy.ping.de with esmtpa (Exim 4.72) (envelope-from ) id 1Vp32Y-0006GV-U4; Fri, 06 Dec 2013 22:34:28 +0100 Date: 6 Dec 2013 22:34:26 +0100 Message-ID: <52A242E2.70501@ping.de> From: "Andreas Kuckartz" To: "Jacob Appelbaum" MIME-Version: 1.0 References: <529E8494.7000806@perens.com> <20131204111309.GB11727@nic.fr> <529F61D8.6030105@perens.com> <20131204171207.GC19914@thunk.org> <529F63C0.3040804@perens.com> <529F88AC.3090904@appelbaum.net> <529F90A0.8000706@perens.com> <529F9205.30906@appelbaum.net> <529F98C0.9090808@perens.com> <529F9F14.8050805@appelbaum.net> <529FB61A.7090604@perens.com> <529FBEF9.7030205@appelbaum.net> <529FC347.3080806@perens.com> <52A15835.2070901@cis-india.org> <6.2.5.6.2.20131206000507.0bdb7c20@resistor.net> <52A1B570.7000205@ping.de> <52A1B9AE.3030108@appelbaum.net> In-Reply-To: <52A1B9AE.3030108@appelbaum.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 21:34:34 -0000 Jacob Appelbaum: > Andreas Kuckartz: >> Jörg Ziercke, the president of the German Federal Criminal Office (BKA) >> three weeks ago suggested to restrict the right to use Tor by requiring >> the registration of users. >> > > Herr Ziercke clearly does not understand how Tor or even how IP networks > actually function. Maybe. Unfortunately his proposals likely would get worse the more he knows about the technologies. Cheers, Andreas From skyper@thc.org Fri Dec 6 14:17:39 2013 Return-Path: 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 BE1231AE02E for ; Fri, 6 Dec 2013 14:17:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.022 X-Spam-Level: X-Spam-Status: No, score=0.022 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-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 qjRSJmGvw53S for ; Fri, 6 Dec 2013 14:17:38 -0800 (PST) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id CB78E1ADE87 for ; Fri, 6 Dec 2013 14:17:37 -0800 (PST) Received: by mail-ie0-f181.google.com with SMTP id e14so2434548iej.12 for ; Fri, 06 Dec 2013 14:17:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thc.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=RiR2lgdSCz7J6CKX3PMKwQUc1X9r8XqXOyWfPVdDjT0=; b=HmvEpj1PvzqmNawgVB9p3hghfvNuf1nXL51jKyz+uJEAOihvBih0b0Zr32/Yv2XsvI HTFLOkzrGaWHnloU+kg0LazGHiolE6SLvmtTDJN/ilsYRrDDUllQJeXT8UL+648MtHt7 2X/eDFxftImppA1qnEWWw44IajdcSIZR97Tl8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=RiR2lgdSCz7J6CKX3PMKwQUc1X9r8XqXOyWfPVdDjT0=; b=EiQ0rjH663hZQa7axR2nGjrO380+aYsoMKQ1JMgI7URvS4f71/nJIz8rpvtxXNdgb9 7zEVHhfbCjsml/oDc7YLgPcxd/B6mB86hbNfcHbXW6mVTV8vPnF1EqjlRbmxSg3qttfj SNO6VgT6es+AJG9nlPBtHUBr4jMB8FTsLwVOPW4RMpLgzPnLcja3JYBVhOTOQthDX1fL IFNv2f0Amn2KokHzYUSlxutgJvUXnKqb89yE234yqVo4oxAzMVhaD1qDfVrRyWLxMb3E 071grKl6GWfYw3p3cZcQKD82TKbVVJYz8BCp3z8gnjeJ5PIBgBH+hZHv5LTKkZwf1eyp BotA== X-Gm-Message-State: ALoCoQk2gtOz3X83PrnpFc9QSDkVmbKoPNCs3ADcNCXaxA3E5h9CnlgEkw5Mf5ETwNLFT/66udXh MIME-Version: 1.0 X-Received: by 10.43.98.202 with SMTP id cp10mr4633404icc.28.1386368253879; Fri, 06 Dec 2013 14:17:33 -0800 (PST) Received: by 10.64.9.41 with HTTP; Fri, 6 Dec 2013 14:17:33 -0800 (PST) X-Originating-IP: [87.106.82.87] In-Reply-To: References: <529E8494.7000806@perens.com> <20131204111309.GB11727@nic.fr> <529F61D8.6030105@perens.com> <20131204171207.GC19914@thunk.org> <529F63C0.3040804@perens.com> <529F88AC.3090904@appelbaum.net> <529F90A0.8000706@perens.com> <529F9205.30906@appelbaum.net> <529F98C0.9090808@perens.com> <529F9F14.8050805@appelbaum.net> <529FB61A.7090604@perens.com> <529FBEF9.7030205@appelbaum.net> <529FC347.3080806@perens.com> <52A15835.2070901@cis-india.org> <52A21B80.8070005@mykolab.com> <52A21D1C.8020000@perens.com> <52A2235A.2030801@perens.com> Date: Fri, 6 Dec 2013 22:17:33 +0000 Message-ID: From: Ralf Skyper Kaiser To: Bruce Perens Content-Type: multipart/alternative; boundary=bcaec51719114d01a704ece503a5 Cc: perpass , Nicholas Weaver , Jacob Appelbaum 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 22:17:39 -0000 --bcaec51719114d01a704ece503a5 Content-Type: text/plain; charset=ISO-8859-1 Hi Bruce, I understand that you have some doubts why we want to make pervasive surveillance harder and if pervasive surveillance is bad and draft-farrell-perpass-attack-00. I encourage you to read the Universal Declaration Of Human Rights [1]. Your country is a signatory to this declaration. You do not need to read the entire declaration. In fact I only ask you to read the Preamble itself. You do not have to read any further than the second sentence of the Preamble which reads: "Whereas disregard and contempt for human rights have resulted in barbarous acts which have outraged the conscience of mankind, and the advent of a world in which human beings shall enjoy freedom of speech and belief and freedom from fear and want has been proclaimed as the highest aspiration of the common people" North Korea, East Germany and the Stasi are just some examples where pervasive surveillance and the violation of this declaration leads to. I also understand that you are saying 'that you have nothing to hide'. I encourage you to book a holiday in Iran. While there please browse some gay websites. Then see what happens to you when you leave the country and please report back to us your opinion on pervasive surveillance afterwards. I promise a mind-changing experience. I am happy for you that you are living in a bubble where all this does not concern you (I really am). But sadly it concerns others and luckily we do not design the properties of the Internet to fit just your needs. Further on your "I have nothing to hide" argument I kindly ask you to install a video camera on your toilet and send the link of the webcam to this list. Still nothing to hide? Feeling good? There was also the discussion why we lock our house doors. There is some similarity with pervasive surveillance. Maybe you should hand a copy of your key to us. This way we can come around, unannounced and on our terms, without telling you, at any time, just to check up on you to make sure you are alright. It's for your own good! And that's what's happening with pervasive surveillance and there is an overwhelming consensus that this is not for our own good! regards, skyper [1] http://www.un.org/en/documents/udhr/ --bcaec51719114d01a704ece503a5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Bruce,

<= /div>I understand that you have some doubts why we want to make pervasive s= urveillance harder and if pervasive
surveillance is bad and draft-farrel= l-perpass-attack-00.

I encourage you to read the Universal Declaration Of Human Rights [1]. = Your country is a signatory to this declaration.

You do not need to = read the entire declaration. In fact I only ask you to read the Preamble it= self. You do not
have to read any further than the second sentence of the Preamble which rea= ds:

"Whereas disregard and contempt for human rights have resul= ted in =20 barbarous acts which have outraged the
conscience of mankind, and the = =20 advent of a world in which human beings shall enjoy freedom of speech =20 and
belief and freedom from fear and want has been proclaimed as the =20 highest aspiration of the common people"

North Kor= ea, East Germany and the Stasi are just some examples where pervasive surve= illance and the violation of
this declaration leads to.

I also understand that you are saying 'that you have nothing to hide= 9;.

I encourage you to book a holiday in Iran. While there ple= ase browse some gay websites. Then see what happens
to you when yo= u leave the country and please report back to us your opinion on pervasive = surveillance afterwards.

I promise a mind-changing experience.

I am happy for you that you are living in a bubble where all this does no= t concern you (I really am). But sadly it
concerns others and luckily we= do not design the properties of the Internet to fit just your needs.

Further on your "I have nothing to hide" argument= =A0 I kindly ask you to install a video camera on
your toilet and send t= he link of the webcam to this list. Still nothing to hide? Feeling good?
There was also the discussion why we lock our house doors. T= here is some similarity with pervasive surveillance.
Maybe you should ha= nd a copy of your key to us.

This way we can come around,= unannounced and on our terms, without telling you, at any time, just to check up on you to make sure you are alright. It's for your own good!
And that's what's happening with pervasive surveil= lance and there is an overwhelming consensus that this
is not for our ow= n good!

regards,

skyper


--bcaec51719114d01a704ece503a5-- From derhoermi@gmx.net Fri Dec 6 15:32:18 2013 Return-Path: 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 4B2001AE0EA for ; Fri, 6 Dec 2013 15:32:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 rHw9y1FYhcQR for ; Fri, 6 Dec 2013 15:32:16 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id B43711ADE87 for ; Fri, 6 Dec 2013 15:32:15 -0800 (PST) Received: from netb.Speedport_W_700V ([84.180.230.32]) by mail.gmx.com (mrgmx101) with ESMTPA (Nemesis) id 0MB2G8-1VhPMk3M7o-009xbj for ; Sat, 07 Dec 2013 00:32:11 +0100 From: Bjoern Hoehrmann To: Ralf Skyper Kaiser Date: Sat, 07 Dec 2013 00:32:13 +0100 Message-ID: References: <529FB61A.7090604@perens.com> <529FBEF9.7030205@appelbaum.net> <529FC347.3080806@perens.com> <52A15835.2070901@cis-india.org> <52A21B80.8070005@mykolab.com> <52A21D1C.8020000@perens.com> <52A2235A.2030801@perens.com> In-Reply-To: X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:xMv6xoXEcBpgbC/VHsWMUlGU0m49o1xftSshUrik4/8gg8dBOrD YXmCXXuXaj2QI6qTQqU+1MP97ZcQTJQPk5jRO91kWaTHVBnDwnahi3Fjvmd7WofueSCb4qb YissZwyZePbW4mdteEk5Bca9pcU6hVZpVDLW0pme/oq3/SRNj3zGfn20+tbYMbNl5XKoThC jnWdO6aDMAOCWqU3LzHIQ== Cc: perpass 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 23:32:18 -0000 * Ralf Skyper Kaiser wrote: >Further on your "I have nothing to hide" argument I kindly ask you to >install a video camera on >your toilet and send the link of the webcam to this list. Still nothing to >hide? Feeling good? It is interesting that this counter-argument is extremely common to the exclusion of most others. For instance, it is rarely pointed out that while resources are expended searching those who have nothing to hide, those who do have something to hide have time to get away or to improve their hiding methods, dispose of whatever they are hiding, or to commit more actions that would justify searching them. It is also uncommon to point out in response to this argument that by revealing things about ourself, we may also reveal things about others, which might do damage to common goods. You cannot have free elections, for instance, if most people reveal how they vote. I want others to hide how they voted so I can vote freely; so the Golden Rule gives me some- thing to hide. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From jtw@csail.mit.edu Fri Dec 6 16:00:17 2013 Return-Path: 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 337F41AE132 for ; Fri, 6 Dec 2013 16:00:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 PoEC-KqRSzh6 for ; Fri, 6 Dec 2013 16:00:15 -0800 (PST) Received: from ana-server.csail.mit.edu (ana-server.csail.mit.edu [18.26.1.3]) by ietfa.amsl.com (Postfix) with ESMTP id CA53E1AE0EA for ; Fri, 6 Dec 2013 16:00:14 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by ana-server.csail.mit.edu (Postfix) with ESMTP id AD5611C3FD26; Fri, 6 Dec 2013 19:00:10 -0500 (EST) X-Virus-Scanned: amavisd-new at ana-server.csail.mit.edu Received: from ana-server.csail.mit.edu ([127.0.0.1]) by localhost (ana-server.csail.mit.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6OvT+1EtvjRB; Fri, 6 Dec 2013 19:00:09 -0500 (EST) Received: from [128.9.184.156] (unknown [128.9.184.156]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ana-server.csail.mit.edu (Postfix) with ESMTPSA id 524FE1C3FD19; Fri, 6 Dec 2013 19:00:09 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: John Wroclawski In-Reply-To: Date: Fri, 6 Dec 2013 16:00:04 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <529FB61A.7090604@perens.com> <529FBEF9.7030205@appelbaum.net> <529FC347.3080806@perens.com> <52A15835.2070901@cis-india.org> <52A21B80.8070005@mykolab.com> <52A21D1C.8020000@perens.com> <52A2235A.2030801@perens.com> To: Bjoern Hoehrmann X-Mailer: Apple Mail (2.1822) Cc: perpass , Ralf Skyper Kaiser 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Dec 2013 00:00:17 -0000 Folks interested in this line of discussion should definitely take a = look at the writing of Daniel Solove, particularly =93=91I=92ve Got = Nothing to Hide=92 and Other Misunderstandings of Privacy=94, available = at . Beyond = that, his newer book = covers this space and more in greater depth. On Dec 6, 2013, at 3:32 PM, Bjoern Hoehrmann wrote: > * Ralf Skyper Kaiser wrote: >> Further on your "I have nothing to hide" argument I kindly ask you = to >> install a video camera on >> your toilet and send the link of the webcam to this list. Still = nothing to >> hide? Feeling good? >=20 > It is interesting that this counter-argument is extremely common to = the > exclusion of most others. For instance, it is rarely pointed out that > while resources are expended searching those who have nothing to hide, > those who do have something to hide have time to get away or to = improve > their hiding methods, dispose of whatever they are hiding, or to = commit > more actions that would justify searching them. >=20 > It is also uncommon to point out in response to this argument that by > revealing things about ourself, we may also reveal things about = others, > which might do damage to common goods. You cannot have free elections, > for instance, if most people reveal how they vote. I want others to = hide > how they voted so I can vote freely; so the Golden Rule gives me some- > thing to hide. > --=20 > Bj=F6rn H=F6hrmann =B7 mailto:bjoern@hoehrmann.de =B7 = http://bjoern.hoehrmann.de > Am Badedeich 7 =B7 Telefon: +49(0)160/4415681 =B7 = http://www.bjoernsworld.de > 25899 Dageb=FCll =B7 PGP Pub. KeyID: 0xA4357E78 =B7 = http://www.websitedev.de/=20 > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass From hallam@gmail.com Fri Dec 6 16:01:30 2013 Return-Path: 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 78E1A1AE11D for ; Fri, 6 Dec 2013 16:01:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 BS8URem6trmD for ; Fri, 6 Dec 2013 16:01:28 -0800 (PST) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) by ietfa.amsl.com (Postfix) with ESMTP id AC7B61AE0EA for ; Fri, 6 Dec 2013 16:01:27 -0800 (PST) Received: by mail-wi0-f175.google.com with SMTP id hi5so1609130wib.14 for ; Fri, 06 Dec 2013 16:01:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=m0rhn2f0G60ik3Aoau6Sooj5fYBGCGRPlPDqGaxN9Jk=; b=0OFNW7OvVGxFXxDywVlR+41gSWnDC6TlAODguBNgtlMp+k57zjvzbw33eH1dB9CbHR 3fWU0MpqaFQQjM+0HbOD2/iceQgvH9yBbACr/ba9wVEAEynIUCoso+K9ZukeyAZNIOUu RfOw0yNBwdN3gqmXkGPJh7QkoYKEp1OIVDg57cnlMdSAdu9GSRlwts5KCKFAGvxOug61 Bj0MgIFP0dsxEb4LJ3papQtK+Oa8hNE7x+7A2h+k+TpLka4Y2UxDJjNpJFIcrlqdwxJb FEsHauTNor21ZbmMHY6QcRFenS9U9EBXsUd8e4OQfMb5lQloZzKQzW4AH3H2NTOjtZiO W2cw== MIME-Version: 1.0 X-Received: by 10.180.108.97 with SMTP id hj1mr4615427wib.59.1386374483390; Fri, 06 Dec 2013 16:01:23 -0800 (PST) Received: by 10.194.243.136 with HTTP; Fri, 6 Dec 2013 16:01:23 -0800 (PST) In-Reply-To: <30BA9CB8-129F-4D9A-AF5F-EB6309A4F15A@virtualized.org> References: <52A050E7.8010405@uni-due.de> <30BA9CB8-129F-4D9A-AF5F-EB6309A4F15A@virtualized.org> Date: Fri, 6 Dec 2013 19:01:23 -0500 Message-ID: From: Phillip Hallam-Baker To: David Conrad Content-Type: multipart/alternative; boundary=e89a8f3bafef9bb68604ece6762e Cc: Randy Bush , perpass , =?ISO-8859-1?Q?Matth=E4us_Wander?= Subject: Re: [perpass] A reminder, the Network is the Enemy... 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Dec 2013 00:01:30 -0000 --e89a8f3bafef9bb68604ece6762e Content-Type: text/plain; charset=ISO-8859-1 On Fri, Dec 6, 2013 at 11:12 AM, David Conrad wrote: > On Dec 5, 2013, at 7:27 AM, Phillip Hallam-Baker wrote: > > A better approach is to design the system so that it takes a defection > by more than one party. Instead of relying on just the ICANN root KSK > require a TLD to be signed by three out of five trusted national cryptolabs. > > Trusted by whom? E.g., trusted like NIST now? (No disrespect of folks at > NIST intended: just observing some may no longer view them as trustable) > I mean trusted in the technical sense of relying on them (albeit to a qualified degree). And it is important to note that trusted does not mean the same thing as trustworthy, a point I raised at one of the early trusted computing group efforts (only Microsoft seemed to take note or maybe they came up with the understanding independently). If you have a three out of five scheme one should choose five labs that are very likely to collude. The UK, US, Australia, Canada and New Zealand would not be a very good choice. The UK, France, Russia, India and Brazil would be a rather better one. Of maybe you would want to have the EFF or the like in there (if they could set up a secure facility and maintain it at acceptable cost). > I personally believe a better approach is to make the operation of the > system extremely public and documented such that it doesn't matter who is > involved since the risk would be too high that attempts at compromise would > be observed. This is what ICANN tried to do with the root KSK (one can > argue whether they succeeded). > These do not need to be exclusive, nor was that my proposal. I would expect any national cryptolab to follow the established industry practices. -- Website: http://hallambaker.com/ --e89a8f3bafef9bb68604ece6762e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On F= ri, Dec 6, 2013 at 11:12 AM, David Conrad <drc@virtualized.org> wrote:
On Dec 5, 2013, at 7:27 AM= , Phillip Hallam-Baker <hallam@gmail= .com> wrote:
> A better approach is to design the system so that it takes a defection= by more than one party. Instead of relying on just the ICANN root KSK requ= ire a TLD to be signed by three out of five trusted national cryptolabs.
Trusted by whom? E.g., trusted like NIST now? (No disrespect of folks= at NIST intended: just observing some may no longer view them as trustable= )

I mean trusted in the technical sense= of relying on them (albeit to a qualified degree).

And it is important to note that trusted does not mean = the same thing as trustworthy, a point I raised at one of the early trusted= computing group efforts (only Microsoft seemed to take note or maybe they = came up with the understanding independently).

If you have a three out of five scheme one should choos= e five labs that are very likely to collude. The UK, US, Australia, Canada = and New Zealand would not be a very good choice. The UK, France, Russia, In= dia and Brazil would be a rather better one. Of maybe you would want to hav= e the EFF or the like in there (if they could set up a secure facility and = maintain it at acceptable cost).

=A0
I personally believe a better approach is to make the operation of the syst= em extremely public and documented such that it doesn't matter who is i= nvolved since the risk would be too high that attempts at compromise would = be observed. This is what ICANN tried to do with the root KSK (one can argu= e whether they succeeded).

These do not need to be exclusive, n= or was that my proposal. I would expect any national cryptolab to follow th= e established industry practices.=A0


-- =
Website: http://hallambaker.com/
--e89a8f3bafef9bb68604ece6762e-- From bruce@perens.com Fri Dec 6 23:20:48 2013 Return-Path: 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 2BDDC1AE271 for ; Fri, 6 Dec 2013 23:20:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.177 X-Spam-Level: X-Spam-Status: No, score=-1.177 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, 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 Hm81TNo5LR2E for ; Fri, 6 Dec 2013 23:20:47 -0800 (PST) Received: from alchemy.perens.com (alchemy.perens.com [206.221.219.26]) by ietfa.amsl.com (Postfix) with ESMTP id 73C4F1AE269 for ; Fri, 6 Dec 2013 23:20:47 -0800 (PST) Received: from [192.168.1.178] (66-214-223-54.static.reno.nv.charter.com [66.214.223.54]) by alchemy.perens.com (Postfix) with ESMTPSA id 239A5500084; Fri, 6 Dec 2013 23:20:43 -0800 (PST) Message-ID: <52A2CC66.9040907@perens.com> Date: Fri, 06 Dec 2013 23:21:10 -0800 From: Bruce Perens User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20131005 Icedove/17.0.9 MIME-Version: 1.0 To: Ralf Skyper Kaiser References: <529E8494.7000806@perens.com> <20131204111309.GB11727@nic.fr> <529F61D8.6030105@perens.com> <20131204171207.GC19914@thunk.org> <529F63C0.3040804@perens.com> <529F88AC.3090904@appelbaum.net> <529F90A0.8000706@perens.com> <529F9205.30906@appelbaum.net> <529F98C0.9090808@perens.com> <529F9F14.8050805@appelbaum.net> <529FB61A.7090604@perens.com> <529FBEF9.7030205@appelbaum.net> <529FC347.3080806@perens.com> <52A15835.2070901@cis-india.org> <52A21B80.8070005@mykolab.com> <52A21D1C.8020000@perens.com> <52A2235A.2030801@perens.com> In-Reply-To: Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: perpass , Nicholas Weaver , Jacob Appelbaum Subject: [perpass] Using the abusrd isn't a compelling argument 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Dec 2013 07:20:48 -0000 I have read a lot of absurd arguments on this list over the past 24 hours:

A GUI with a button title like "F**k security, I want to open myself to the world".
Put a camera in your bathroom.
Go to Iran (I would certainly act differently if I was there, and did in Tunisia).
Make polls public.
Don't use HTTPS even where it's appropriate.

People who don't necessarily want to encrypt everything don't have any reason to do this silly stuff and you don't win arguments this way.

    Thanks

    Bruce

From bruce@perens.com Fri Dec 6 23:26:00 2013 Return-Path: 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 0B1511AE271 for ; Fri, 6 Dec 2013 23:26:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.177 X-Spam-Level: X-Spam-Status: No, score=-1.177 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, 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 bokffmDcvAaq for ; Fri, 6 Dec 2013 23:25:57 -0800 (PST) Received: from alchemy.perens.com (alchemy.perens.com [206.221.219.26]) by ietfa.amsl.com (Postfix) with ESMTP id 553681AE290 for ; Fri, 6 Dec 2013 23:25:57 -0800 (PST) Received: from [192.168.1.178] (66-214-223-54.static.reno.nv.charter.com [66.214.223.54]) by alchemy.perens.com (Postfix) with ESMTPSA id 27ADB500084; Fri, 6 Dec 2013 23:25:53 -0800 (PST) Message-ID: <52A2CD9D.80609@perens.com> Date: Fri, 06 Dec 2013 23:26:21 -0800 From: Bruce Perens User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20131005 Icedove/17.0.9 MIME-Version: 1.0 To: Ralf Skyper Kaiser References: <529E8494.7000806@perens.com> <20131204111309.GB11727@nic.fr> <529F61D8.6030105@perens.com> <20131204171207.GC19914@thunk.org> <529F63C0.3040804@perens.com> <529F88AC.3090904@appelbaum.net> <529F90A0.8000706@perens.com> <529F9205.30906@appelbaum.net> <529F98C0.9090808@perens.com> <529F9F14.8050805@appelbaum.net> <529FB61A.7090604@perens.com> <529FBEF9.7030205@appelbaum.net> <529FC347.3080806@perens.com> <52A15835.2070901@cis-india.org> <52A21B80.8070005@mykolab.com> <52A21D1C.8020000@perens.com> <52A2235A.2030801@perens.com> In-Reply-To: Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: perpass , Nicholas Weaver , Jacob Appelbaum 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Dec 2013 07:26:00 -0000
On 12/06/2013 02:17 PM, Ralf Skyper Kaiser wrote:

There was also the discussion why we lock our house doors.
I was brought up to believe that the places where you had to lock yourself in at night were bad places to live. We only started locking the doors at night in my home in Bayville, Long Island sometime in the 80's as a result of a local crime wave.

Maybe you should hand a copy of your key to us.
Oops, I forgot to include this in the list of absurd arguments. Try winning the argument without suggesting a camera in my bathroom, etc.

From bruce@perens.com Fri Dec 6 23:29:23 2013 Return-Path: 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 0CD981AE290 for ; Fri, 6 Dec 2013 23:29:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.177 X-Spam-Level: X-Spam-Status: No, score=-1.177 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, 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 r2Ot2oIZloT6 for ; Fri, 6 Dec 2013 23:29:22 -0800 (PST) Received: from alchemy.perens.com (alchemy.perens.com [206.221.219.26]) by ietfa.amsl.com (Postfix) with ESMTP id 6A3901AE04A for ; Fri, 6 Dec 2013 23:29:22 -0800 (PST) Received: from [192.168.1.178] (66-214-223-54.static.reno.nv.charter.com [66.214.223.54]) by alchemy.perens.com (Postfix) with ESMTPSA id 75E96500084; Fri, 6 Dec 2013 23:29:18 -0800 (PST) Message-ID: <52A2CE6A.30408@perens.com> Date: Fri, 06 Dec 2013 23:29:46 -0800 From: Bruce Perens User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20131005 Icedove/17.0.9 MIME-Version: 1.0 To: Nicholas Weaver References: <529E8494.7000806@perens.com> <20131204111309.GB11727@nic.fr> <529F61D8.6030105@perens.com> <20131204171207.GC19914@thunk.org> <529F63C0.3040804@perens.com> <529F88AC.3090904@appelbaum.net> <529F90A0.8000706@perens.com> <529F9205.30906@appelbaum.net> <529F98C0.9090808@perens.com> <529F9F14.8050805@appelbaum.net> <529FB61A.7090604@perens.com> <529FBEF9.7030205@appelbaum.net> <529FC347.3080806@perens.com> <52A15835.2070901@cis-india.org> <52A21B80.8070005@mykolab.com> <52A21D1C.8020000@perens.com> <52A2235A.2030801@perens.com> <240A2D86-C352-4954-BE4E-6313BA25994E@icsi.berkeley.edu> In-Reply-To: <240A2D86-C352-4954-BE4E-6313BA25994E@icsi.berkeley.edu> Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Dec 2013 07:29:23 -0000
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. But it's an authentication problem rather than a confidentiality one.

From bruce@perens.com Fri Dec 6 23:46:04 2013 Return-Path: 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 CF2491AE074 for ; Fri, 6 Dec 2013 23:46:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.177 X-Spam-Level: X-Spam-Status: No, score=-1.177 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, 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 dkShzO3z-fvg for ; Fri, 6 Dec 2013 23:46:03 -0800 (PST) Received: from alchemy.perens.com (alchemy.perens.com [206.221.219.26]) by ietfa.amsl.com (Postfix) with ESMTP id E584F1AE039 for ; Fri, 6 Dec 2013 23:46:03 -0800 (PST) Received: from [192.168.1.178] (66-214-223-54.static.reno.nv.charter.com [66.214.223.54]) by alchemy.perens.com (Postfix) with ESMTPSA id A9554500084; Fri, 6 Dec 2013 23:45:57 -0800 (PST) Message-ID: <52A2D24F.4090505@perens.com> Date: Fri, 06 Dec 2013 23:46:23 -0800 From: Bruce Perens User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20131005 Icedove/17.0.9 MIME-Version: 1.0 To: John Wroclawski , perpass References: <529FB61A.7090604@perens.com> <529FBEF9.7030205@appelbaum.net> <529FC347.3080806@perens.com> <52A15835.2070901@cis-india.org> <52A21B80.8070005@mykolab.com> <52A21D1C.8020000@perens.com> <52A2235A.2030801@perens.com> In-Reply-To: Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Dec 2013 07:46:05 -0000 John,

Of course I have sympathy for all of those who have their human rights abridged, and would not begrudge them the use of Tor, preferential https, or whatever helps. I am not sanguine that encryption is any barrier to NSA due to the ASIC issue previously discussed, but it might well be a barrier to religious extremist oppressors, etc.

The problem with security is that however much you have is never enough, because there's always a new threat. And that is exactly why the United States is pursuing a continuously increasing war in whiich surveilance and odious security procedures only increase. And thus IETF will also end up on a continuously increasing war in which odious security procedures only increase, in response.

The next step after encrypting every web query is locking down the browser to the "trusted platform" and insisting on identifying certificates for all users. Our various corporate totalitarians are sure to want it, it already exists on the iPhone and other DRM platforms, and will only get tighter.

So, this ends with the death of the open web.

At some point, we have to draw a line and say this is enough, it doesn't really protect us, it protects someone else at our expense.

Where do you propose to do that? Right after _this_ change? And when the next proposal is to draw the line right after the _next_ change, and so on ad infinitum?

So, I don't want to be forced onto this next security upgrade. I want to be able to intelligently decide whether I need it and when, and to control whether I use it, and when to dispense with it when it's being used for things that are not in my interest.

    Thanks

    Bruce
From bruce@perens.com Sat Dec 7 00:00:33 2013 Return-Path: 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 453FA1ADFCA for ; Sat, 7 Dec 2013 00:00:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.523 X-Spam-Level: * X-Spam-Status: No, score=1.523 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, 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 j5NY82v7M1Xx for ; Sat, 7 Dec 2013 00:00:32 -0800 (PST) Received: from alchemy.perens.com (alchemy.perens.com [206.221.219.26]) by ietfa.amsl.com (Postfix) with ESMTP id 2C64C1AD8E1 for ; Sat, 7 Dec 2013 00:00:32 -0800 (PST) Received: from [192.168.1.178] (66-214-223-54.static.reno.nv.charter.com [66.214.223.54]) by alchemy.perens.com (Postfix) with ESMTPSA id 2C4E6500084 for ; Sat, 7 Dec 2013 00:00:25 -0800 (PST) Message-ID: <52A2D5AF.5010905@perens.com> Date: Sat, 07 Dec 2013 00:00:47 -0800 From: Bruce Perens User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20131005 Icedove/17.0.9 MIME-Version: 1.0 To: perpass Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [perpass] One way in which I really do not hide. 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Dec 2013 08:00:33 -0000 I am on the APRS network. What this means is that there is a GPS beacon in my car, and it transmits in cleartext on 144.39 MHz with 50 watts of power, and the packets are repeated by stations on mountaintops, etc. so that you can read it all across Northern California. Other hams in their cars see if I'm nearby, some of them as a moving waypoint on their GPS map. On occassion I've had surprise guests just walk into the restaurant where I was having lunch because they saw I was nearby and wanted to meet me.

This is gatewayed to the internet, and you can see on aprs.fi where I have driven my car for the past several months, and even when I was breaking the speed limit. The callsign is K6BP- and a number from 0 to 15. Indeed, if I am carrying the walkie talkie that does this, you can watch me go down a ski slope.

    Thanks

    Bruce
From jacob@appelbaum.net Sat Dec 7 02:47:21 2013 Return-Path: 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 045351AE2C3 for ; Sat, 7 Dec 2013 02:47:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.6 X-Spam-Level: X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FSL_HELO_BARE_IP_2=2, RCVD_IN_DNSWL_LOW=-0.7] 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 Z8JxgS6HZuMA for ; Sat, 7 Dec 2013 02:47:20 -0800 (PST) Received: from mail-bk0-f50.google.com (mail-bk0-f50.google.com [209.85.214.50]) by ietfa.amsl.com (Postfix) with ESMTP id B5A3A1ADE88 for ; Sat, 7 Dec 2013 02:47:19 -0800 (PST) Received: by mail-bk0-f50.google.com with SMTP id e11so662363bkh.23 for ; Sat, 07 Dec 2013 02:47:15 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:mime-version:to:cc:subject :references:in-reply-to:openpgp:content-type :content-transfer-encoding; bh=VnqEXLDghTL2taYNXhAnNOEWmrepqC+ZBvQRr+b3OIY=; b=WA/3y9HoAmr+n1kQtZNY8nbF3CSZ8FAFQnAsSKR/ZOPhbH8YKixEOleYSCLrukYBcw viVDqAaISoXteo9M4cdWd2GhVAesssI8MCB5OtQs6ZiIaJy0+7CU7L8cY635HlikywtJ 1geqy85tg/nenwbiZtOtZ4vKxzJIAGY4Drc11N+Jo8PN6l4DZj5ywHBT9Fd8rX6xH8WV CMl6d9Xp+52T0lVqw0IzqYWy2F883s04EmCmkJ+PLrJdcskzbVmdqLG7itfhmhw/Jvej UWrPq4U7U36UNtamkBHsCvRdiYAqL4NTKMFgOvbgJUfw7gPmQKFDIWb+nhzlMr0pFCGb Eq0w== X-Gm-Message-State: ALoCoQkS7Ys5mrvWwaeBpY18UJd9aH8igINhEXPJqDnBWhd23Z+Af/ozlNQo8/jSoT9X0OWquTV+ X-Received: by 10.205.38.199 with SMTP id tj7mr302541bkb.134.1386413235053; Sat, 07 Dec 2013 02:47:15 -0800 (PST) Received: from 127.0.0.1 (1508890005.dhcp.dbnet.dk. [89.239.213.149]) by mx.google.com with ESMTPSA id tn8sm1539573bkb.16.2013.12.07.02.47.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 07 Dec 2013 02:47:14 -0800 (PST) Message-ID: <52A2EB76.5090206@appelbaum.net> Date: Sat, 07 Dec 2013 09:33:42 +0000 From: Jacob Appelbaum MIME-Version: 1.0 To: Bruce Perens References: <529E8494.7000806@perens.com> <20131204111309.GB11727@nic.fr> <529F61D8.6030105@perens.com> <20131204171207.GC19914@thunk.org> <529F63C0.3040804@perens.com> <529F88AC.3090904@appelbaum.net> <529F90A0.8000706@perens.com> <529F9205.30906@appelbaum.net> <529F98C0.9090808@perens.com> <529F9F14.8050805@appelbaum.net> <529FB61A.7090604@perens.com> <529FBEF9.7030205@appelbaum.net> <529FC347.3080806@perens.com> <52A15835.2070901@cis-india.org> <52A21B80.8070005@mykolab.com> <52A21D1C.8020000@perens.com> <52A2235A.2030801@perens.com> <52A2CD9D.80609@perens.com> In-Reply-To: <52A2CD9D.80609@perens.com> OpenPGP: id=4193A197 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: perpass , Nicholas Weaver , Ralf Skyper Kaiser 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Dec 2013 10:47:21 -0000 Bruce Perens: > On 12/06/2013 02:17 PM, Ralf Skyper Kaiser wrote: >> >> There was also the discussion why we lock our house doors. > I was brought up to believe that the places where you had to lock yourself in at > night were bad places to live. We only started locking the doors at night in my > home in Bayville, Long Island sometime in the 80's as a result of a local crime > wave. Welcome to the internet with the NSA/CSE/GCHQ/GCSB/BND/FSB for nearly everyone in the world, Bruce. We're starting to protect communications because of an international crime wave and widespread vulnerability. All the best, Jacob From jacob@appelbaum.net Sat Dec 7 02:47:35 2013 Return-Path: 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 280F61AE2C7 for ; Sat, 7 Dec 2013 02:47:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.6 X-Spam-Level: X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FSL_HELO_BARE_IP_2=2, RCVD_IN_DNSWL_LOW=-0.7] 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 6PyLrZC5ynCg for ; Sat, 7 Dec 2013 02:47:34 -0800 (PST) Received: from mail-bk0-f48.google.com (mail-bk0-f48.google.com [209.85.214.48]) by ietfa.amsl.com (Postfix) with ESMTP id B02C91AE2C6 for ; Sat, 7 Dec 2013 02:47:33 -0800 (PST) Received: by mail-bk0-f48.google.com with SMTP id v10so675079bkz.21 for ; Sat, 07 Dec 2013 02:47:29 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:mime-version:to:subject :references:in-reply-to:openpgp:content-type :content-transfer-encoding; bh=K4+AtLpF9FvWPM32tJl8Pscy6zGDJKuuVLvJPX1+X74=; b=SFqpHmGBwCU7AfxYkSKnCVSWURtoihgNGAISzspn1NaShB2xEcJ0PgYOZf3MYBB0G0 AqA33bI02YCCFInDUeg9WvMtbM4dCU+1q1FR3hu9NsVKrZNV/ge4U7XhT0rnbM6Wopbx +Aiaf7O86GqypTaOrbrP+6DKhPV78z21LXoggTb54gbX5j2A/OdE+MhKA52sjEAInKgp od9dQe/jfRFIG+Yg8REqSfN74IB8jXUsGFAxfPSVu7V5HrOfvfLiFfjWAFu9R60pugE4 PMprDZH6MjndRlcNP3TE/PIVGOjWiGrf3BJzwnw8uYj41+4cqXa0Qj0S/fpDWJ0Buv3U IbzQ== X-Gm-Message-State: ALoCoQlHE7uaC5ZEfx9KGG6QZYB2Pq+3tHLkVC743fgCqqUSQLLhwFz3iLfhf1HTR7HShR0UxwMq X-Received: by 10.204.202.72 with SMTP id fd8mr2626139bkb.65.1386413248972; Sat, 07 Dec 2013 02:47:28 -0800 (PST) Received: from 127.0.0.1 (1508890005.dhcp.dbnet.dk. [89.239.213.149]) by mx.google.com with ESMTPSA id t2sm1566262bkh.3.2013.12.07.02.47.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 07 Dec 2013 02:47:28 -0800 (PST) Message-ID: <52A2EC34.9030305@appelbaum.net> Date: Sat, 07 Dec 2013 09:36:52 +0000 From: Jacob Appelbaum MIME-Version: 1.0 To: perpass@ietf.org References: <529E8494.7000806@perens.com> <20131204111309.GB11727@nic.fr> <529F61D8.6030105@perens.com> <20131204171207.GC19914@thunk.org> <529F63C0.3040804@perens.com> <529F88AC.3090904@appelbaum.net> <529F90A0.8000706@perens.com> <529F9205.30906@appelbaum.net> <529F98C0.9090808@perens.com> <529F9F14.8050805@appelbaum.net> <529FB61A.7090604@perens.com> <529FBEF9.7030205@appelbaum.net> <529FC347.3080806@perens.com> <52A15835.2070901@cis-india.org> <52A21B80.8070005@mykolab.com> <52A21D1C.8020000@perens.com> <52A2235A.2030801@perens.com> <240A2D86-C352-4954-BE4E-6313BA25994E@icsi.berkeley.edu> <52A2CE6A.30408@perens.com> In-Reply-To: <52A2CE6A.30408@perens.com> OpenPGP: id=4193A197 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Dec 2013 10:47:35 -0000 Bruce Perens: > 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. But it's an > authentication problem rather than a confidentiality one. Without confidentiality, a user may be targeted for specific tracking and more importantly, they may be targeted for client side exploitation. Do you find that compelling? All the best, Jacob From jacob@appelbaum.net Sat Dec 7 02:47:50 2013 Return-Path: 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 1131F1AE2CB for ; Sat, 7 Dec 2013 02:47:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.6 X-Spam-Level: X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FSL_HELO_BARE_IP_2=2, RCVD_IN_DNSWL_LOW=-0.7] 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 1dH_hnu26_co for ; Sat, 7 Dec 2013 02:47:48 -0800 (PST) Received: from mail-bk0-f48.google.com (mail-bk0-f48.google.com [209.85.214.48]) by ietfa.amsl.com (Postfix) with ESMTP id 490A41AD694 for ; Sat, 7 Dec 2013 02:47:48 -0800 (PST) Received: by mail-bk0-f48.google.com with SMTP id v10so675117bkz.21 for ; Sat, 07 Dec 2013 02:47:43 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:mime-version:to:cc:subject :references:in-reply-to:openpgp:content-type :content-transfer-encoding; bh=D5aHl9DloO0QeGAGPngfcRBWSJmBxmFE22ZZnKO8SLg=; b=TJsmaqJW2vcepsNZkVLc67QzSPttpeZB2L24C/gHKRTorI5Fgr2QKtsajxR61Zlnlo T/9JYN4xVRMDVgbFHlAsf0vutn00yt0ONAk89oY1yqIrOOPuzdIxvzo7+1cHQdkWE66E 93PNrAsR4EWjt5etlslgDf7SWwiz2HWpZpmi110deWc0jCGSa+xRaFNyiNfmnhhidKfZ 1WS8+qfxdfQp9ka1J7zLDT6dsEKtz/famhkFluYV3mixGd7e+D7K5SONo8ysm4UJhtLm tCejClRvFvZNvq6F2h+orroDzxXue7XfjCkGZqI8v9EZ+JGIkW1aUvecQiupwRv4Lgtf dYww== X-Gm-Message-State: ALoCoQnccwO1GBqDet7HTeGDQbgodaFGkk0+LO/zO2ZtKkghQ/u9TdQ1MNHocA3RIUNFQCO/+aPq X-Received: by 10.205.12.10 with SMTP id pg10mr35379bkb.158.1386413263713; Sat, 07 Dec 2013 02:47:43 -0800 (PST) Received: from 127.0.0.1 (1508890005.dhcp.dbnet.dk. [89.239.213.149]) by mx.google.com with ESMTPSA id sx5sm1572748bkb.0.2013.12.07.02.47.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 07 Dec 2013 02:47:42 -0800 (PST) Message-ID: <52A2F46D.7080501@appelbaum.net> Date: Sat, 07 Dec 2013 10:11:57 +0000 From: Jacob Appelbaum MIME-Version: 1.0 To: Bruce Perens References: <529FB61A.7090604@perens.com> <529FBEF9.7030205@appelbaum.net> <529FC347.3080806@perens.com> <52A15835.2070901@cis-india.org> <52A21B80.8070005@mykolab.com> <52A21D1C.8020000@perens.com> <52A2235A.2030801@perens.com> <52A2D24F.4090505@perens.com> In-Reply-To: <52A2D24F.4090505@perens.com> OpenPGP: id=4193A197 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: perpass , John Wroclawski 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Dec 2013 10:47:50 -0000 Bruce Perens: > John, > > Of course I have sympathy for all of those who have their human rights abridged, > and would not begrudge them the use of Tor, preferential https, or whatever > helps. Really? Where is your sympathy exactly? I am one of those who have my human rights abridged, as is everyone on this list, I might add. It is nearly impossible for me to protect myself, even with Tor, because nearly all services and systems are insecure in the face of specific attacker capabilities. Is your sympathy simply that you begrudgingly will allow us to protect ourselves from your (and my) spy agency, the NSA? Some sympathy! > I am not sanguine that encryption is any barrier to NSA due to the ASIC > issue previously discussed, but it might well be a barrier to religious > extremist oppressors, etc. Do you understand how the TURMOIL and TURBINE programs work? The first is a passive sensor system that does DPI (Deep Packet Inspection) and the second is an active sensor system that does DPI (Deep Packet Injection). The TURMOIL system is used for protocol classification and selector based surveillance. The TURBINE system takes actions, usually packet injections for Man-on-the-Side, based on the results of TURMOIL and similar systems. For any agency to build a system like TURMOIL, they must be able to scan the traffic in real time. The time to race a TCP connection is very small and as it stands, they do not win all of the time - latency of injection provides enough variance to stop QUANTUMINSERTION related attacks. Do you have any evidence that these systems use super computer, ASIC or FGPA based decryption techniques as part of the TURMOIL or TURBINE programs? It is clear that they do decryption from captured and stored data. It is also clear that they cannot store *everything* and so traffic analysis is part of how they decide what to store and thus how they are able to record the ciphertext for later attacks. Only basic traffic analysis resistance in common protocols will start to change this balance. This is part of how we will end massive surveillance of the internet. We will not end mass surveillance by keeping the current economic balance and the current social cost that is afforded to these spies and other criminals. > > The problem with security is that however much you have is never enough, because > there's always a new threat. And that is exactly why the United States is > pursuing a continuously increasing war in whiich surveilance and odious security > procedures only increase. And thus IETF will also end up on a continuously > increasing war in which odious security procedures only increase, in response. > This is false. A key problem here is that you refuse to acknowledge that well known, even practically solved problems, are a threat to the users of the internet. TLS for HTTP will reduce the attack surface of every computer from third party network based threats. We can very nearly eliminate these threats entirely and we can ensure that when the threat becomes reality, we may detect it and fail in a closed manner. > The next step after encrypting every web query is locking down the browser to > the "trusted platform" and insisting on identifying certificates for all users. > Our various corporate totalitarians are sure to want it, it already exists on > the iPhone and other DRM platforms, and will only get tighter. > This is a red herring and is also false. > So, this ends with the death of the open web. > The NSA has killed the open web as we know it. The Chinese "Great" firewall has killed the open web that most of China *never* knew anyway. > At some point, we have to draw a line and say this is enough, it doesn't really > protect us, it protects someone else at our expense. > The question I ask myself, Bruce, is if at some point, you're working to the benefit of someone else? You certainly don't seem to care about the common good in the face of real threats because of your privilege as a US citizen and your general arrogance rooted in other privileges. > Where do you propose to do that? Right after _this_ change? And when the next > proposal is to draw the line right after the _next_ change, and so on ad infinitum? > Attacks generally improve over time. We must iterate on protocols that have serious flaws and ensure that we defend against attackers. > So, I don't want to be forced onto this next security upgrade. I want to be able > to intelligently decide whether I need it and when, and to control whether I use > it, and when to dispense with it when it's being used for things that areck not in > my interest. > You're apparently not doing that now, why will you do that later? You're not being forced to do anything, are you? You could use HTTP 1.1 forever, right? Oh right, sometimes choice is removed! How does it feel to be like the rest of the world for just one moment? Sincerely, Jacob From jacob@appelbaum.net Sat Dec 7 02:48:03 2013 Return-Path: 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 95A591AE2CD for ; Sat, 7 Dec 2013 02:48:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.1 X-Spam-Level: ** X-Spam-Status: No, score=2.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FSL_HELO_BARE_IP_2=2, RCVD_IN_DNSWL_LOW=-0.7] 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 Q0OGeyv5xW3p for ; Sat, 7 Dec 2013 02:48:02 -0800 (PST) Received: from mail-bk0-f46.google.com (mail-bk0-f46.google.com [209.85.214.46]) by ietfa.amsl.com (Postfix) with ESMTP id 607C71AD694 for ; Sat, 7 Dec 2013 02:48:02 -0800 (PST) Received: by mail-bk0-f46.google.com with SMTP id u15so674043bkz.33 for ; Sat, 07 Dec 2013 02:47:57 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:mime-version:to:cc:subject :references:in-reply-to:openpgp:content-type :content-transfer-encoding; bh=JSjM1a1U9EgbV4WE4Yfy8Z4sVerJY1on8kw3QD3oAEI=; b=Jz/Ap5cgZeqDfqR9pjrFLo0fESH1/+2CH9HErC7WY399BxPI8UVC6rbrCZo75wU9Sz erhKy2hOGZvpNBpSQIoFdztz2iAsJ/XNpxiifzDhMmzMf77D5FAw6mOty6p+61S/LaE2 PnGEwjFhbXkwtu5Dq/FD7hw6WLr15ckGhj1CSaWUikZwzLDbfbGOCQsFS16oVeyH+1yv VFdT24nnLaO0RnQuSgfrpCyrWrfuWkjJPNBqmYHMNV+70CFj84dg0WqLcnHXQfjgfm2s rtPvupVLYmOXNNKhrIdXCKrjnFsMlBGQxRciAudLdmj1e2ZCtJU8JBr2mQH5ICDGf112 8AwQ== X-Gm-Message-State: ALoCoQk1u5Dyq6Qlf99Nop1V47LDAY7hrB6OA9sA0IagAphFMnB+H+ffoxwHpyM3qO7fH73seuHi X-Received: by 10.204.80.78 with SMTP id s14mr2736389bkk.6.1386413277614; Sat, 07 Dec 2013 02:47:57 -0800 (PST) Received: from 127.0.0.1 (1508890005.dhcp.dbnet.dk. [89.239.213.149]) by mx.google.com with ESMTPSA id z6sm1556859bkn.8.2013.12.07.02.47.54 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 07 Dec 2013 02:47:56 -0800 (PST) Message-ID: <52A2FB81.3070105@appelbaum.net> Date: Sat, 07 Dec 2013 10:42:09 +0000 From: Jacob Appelbaum MIME-Version: 1.0 To: Bruce Perens References: <52A2D5AF.5010905@perens.com> In-Reply-To: <52A2D5AF.5010905@perens.com> OpenPGP: id=4193A197 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: perpass Subject: Re: [perpass] One way in which I really do not hide. 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Dec 2013 10:48:03 -0000 Bruce Perens: > I am on the APRS network. What this means is that there is a GPS beacon in my > car, and it transmits in cleartext on 144.39 MHz with 50 watts of power, and the > packets are repeated by stations on mountaintops, etc. so that you can read it > all across Northern California. Other hams in their cars see if I'm nearby, some > of them as a moving waypoint on their GPS map. On occassion I've had surprise > guests just walk into the restaurant where I was having lunch because they saw I > was nearby and wanted to meet me. Isn't it nice that you've had a choice? Do you advocate for everyone to be forced to do something similar? If everyone was forced, would you also advocate against protection of the masses with strong privacy preserving standards? > > This is gatewayed to the internet, and you can see on aprs.fi where I have > driven my car for the past several months, and even when I was breaking the > speed limit. The callsign is K6BP- and a number from 0 to 15. Indeed, if I am > carrying the walkie talkie that does this, you can watch me go down a ski slope. I would encourage you to post this on your blog, with evidence and to email and call the California Highway Patrol. If you're willing, I'd also encourage you to ring up a local relevant California prosecutor and describe your regular and blatant disregard for the safety and road laws. When someone wants to create harm for you, they'll do this for you, right? I guess you won't report on yourself but I'd guess that many people here can tell you about how such things have happened in their lives. All the best, Jacob From stephen.farrell@cs.tcd.ie Sat Dec 7 05:14:29 2013 Return-Path: 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 57E5B1AE2FC for ; Sat, 7 Dec 2013 05:14:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TgOao4IJ5wZf for ; Sat, 7 Dec 2013 05:14:27 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id E11811AE2F9 for ; Sat, 7 Dec 2013 05:14:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C3A17BE8B; Sat, 7 Dec 2013 13:14:16 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iiivV7nXWXue; Sat, 7 Dec 2013 13:14:15 +0000 (GMT) Received: from [10.87.48.12] (unknown [86.42.23.185]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 6BC4EBE8A; Sat, 7 Dec 2013 13:14:15 +0000 (GMT) Message-ID: <52A31F1D.7040509@cs.tcd.ie> 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 References: <529E8494.7000806@perens.com> <20131204111309.GB11727@nic.fr> <529F61D8.6030105@perens.com> <20131204171207.GC19914@thunk.org> <529F63C0.3040804@perens.com> <529F88AC.3090904@appelbaum.net> <529F90A0.8000706@perens.com> <529F9205.30906@appelbaum.net> <529F98C0.9090808@perens.com> <529F9F14.8050805@appelbaum.net> <529FB61A.7090604@perens.com> <529FBEF9.7030205@appelbaum.net> <529FC347.3080806@perens.com> <52A15835.2070901@cis-india.org> <52A21B80.8070005@mykolab.com> <52A21D1C.8020000@perens.com> <52A2235A.2030801@perens.com> <240A2D86-C352-4954-BE4E-6313BA25994E@icsi.berkeley.edu> <52A2CE6A.30408@perens.com> In-Reply-To: <52A2CE6A.30408@perens.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Dec 2013 13:14:29 -0000 Bruce, 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 much. 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 confidentiality. 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. Cheers, S. From nweaver@icsi.berkeley.edu Sat Dec 7 07:48:10 2013 Return-Path: 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 D5D231AE388 for ; Sat, 7 Dec 2013 07:48:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 HSN8BRIl1xPr for ; Sat, 7 Dec 2013 07:48:08 -0800 (PST) Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id A70441AE050 for ; Sat, 7 Dec 2013 07:48:08 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id D34FD2C4033; Sat, 7 Dec 2013 07:48:04 -0800 (PST) X-Virus-Scanned: amavisd-new at ICSI.Berkeley.EDU Received: from rock.ICSI.Berkeley.EDU ([127.0.0.1]) by localhost (maihub.ICSI.Berkeley.EDU [127.0.0.1]) (amavisd-new, port 10024) with LMTP id iLrBVGY0lX-y; Sat, 7 Dec 2013 07:48:03 -0800 (PST) Received: from [10.0.1.14] (c-76-103-162-14.hsd1.ca.comcast.net [76.103.162.14]) (Authenticated sender: nweaver) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id A5C7A2C4004; Sat, 7 Dec 2013 07:48:03 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_3E15BCB3-7E1E-4F5D-B1A3-5BE9D2B4C9AE"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Nicholas Weaver In-Reply-To: <52A31F1D.7040509@cs.tcd.ie> Date: Sat, 7 Dec 2013 07:48:02 -0800 Message-Id: <5D026682-5457-4F00-B139-58D8D718BB0A@icsi.berkeley.edu> References: <529E8494.7000806@perens.com> <20131204111309.GB11727@nic.fr> <529F61D8.6030105@perens.com> <20131204171207.GC19914@thunk.org> <529F63C0.3040804@perens.com> <529F88AC.3090904@appelbaum.net> <529F90A0.8000706@perens.com> <529F9205.30906@appelbaum.net> <529F98C0.9090808@perens.com> <529F9F14.8050805@appelbaum.net> <529FB61A.7090604@perens.com> <529FBEF9.7030205@appelbaum.net> <529FC347.3080806@perens.com> <52A15835.2070901@cis-india.org> <52A21B80.8070005@mykolab.com> <52A21D1C.8020000@perens.com> <52A2235A.2030801@perens.com> <240A2D86-C352-4954-BE4E-6313BA25994E@icsi.berkeley.edu> <52A2CE6A.30408@perens.com> <52A31F1D.7040509@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1510) Cc: perpass@ietf.org, Nicholas Weaver , Bruce Perens 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Dec 2013 15:48:11 -0000 --Apple-Mail=_3E15BCB3-7E1E-4F5D-B1A3-5BE9D2B4C9AE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Dec 7, 2013, at 5:14 AM, Stephen Farrell = wrote: > 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 > much. We do actually have a system for data integrity without confidentiality. = Its called DNSSEC. And the lack of confidentiality is a deliberate = design decision due to its focus around offline signature generation and = a structure composed of various proven untrustworthy intermediaries. So if you really actually WANTED data integrity on elements (and it has = to be all HTML, CSS, JS, flash, etc.. since all of those are directly = executable content, so you might as well do ALL elements. After all, = there have been image rendering vulnerabilities too..), how about = storing them and just fetching them through DNSSEC... Indeed, thats a very silly and downright stupid idea. Nobody will do = it. Why? Because our model for HTTP is that content is often generated = dynamically, so each dynamic element would need to be signed = dynamically, so instead our focus on HTTP is on channel security: create = a secure channel and then keep using it. There is effectively zero call for "MAC w/o ENCRYPT", which is whats = necessary to answer "authentication problem rather than a = confidentiality one." in terms of channel security. We don't do it. = Why? Because its stupid. You'd still need to go through all the public = key certificate efforts, key exchange, server side computation, and all = the other crap needed for a TLS handshake or similar to generate a MAC = key. Adding in encryption is a practical no-op by this point. And without doing a key exchange for a MAC and instead doing signatures = for integrity, signature verification happens at the END of a = communication. Signatures are expensive to generate and validate (and = verification w/o a key exchange requires a lot more of them anyway), so = you'd hash all the data and then sign/verify, so you coludn't take = advantage of incremental rendering, lest you render an iframe at the = start that shouldn't be there. Yes, you could use some block-hash structure where at the start you get = a signature over a bunch of block hashes, but that instead requires that = the sender know in advance the WHOLE message. Its a silly thought, = since the server in many cases does NOT know what the full .html = document will be when it starts sending it over a TLS channel. So the idea of "authentication problem rather than a confidentiality = one" is a red herring: We have a solution that solves the = authentication problem for HTTP. Its called TLS. We MUST use it = everywhere, if only to protect US citizens from the French and Chinese, = and Russians, and Brazilians, and Israelis... And a solution which solves authentication w/o confidentiality may be = silly, but if you want it anyway, the best solution that gives = authentication w/o confidentiality for HTTP is, indeed, a browser button = that says: "F-confidentiality: broadcast my encryption key (but not the MAC key) in = the clear if the server consents". -- Nicholas Weaver it is a tale, told by an idiot, nweaver@icsi.berkeley.edu full of sound and fury, 510-666-2903 .signifying nothing PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc --Apple-Mail=_3E15BCB3-7E1E-4F5D-B1A3-5BE9D2B4C9AE Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCgAGBQJSo0MyAAoJEG2B1w+SDi/utCUQALVBdcPnshG5qHBQbqZMekzK QOk9LCkcFA0NS/p9dEQ8qferHtJ8/FCtbtylGnpM4FKBLMEm7vyld5u4W1LVcOPS JJBvpNvP8cky6KdLM5AqJWdO5+xjMRHAtguj7f9+wg3wWnMRXHg4yVBSixKUPbWh Ilbj173znzeTjNsh0lw5tUKVzNVXKdtXFtQH0ngoLxJnCFtlp/yAsQtb+VNFXRT6 jp7Y6xpn44PSgXLLtgOmuh/vWahxSsaGf+VOzC5EugLeR587DjL8qIcsWMXIEmxJ Jk8Rh4+0X8ScFgUOLfEflisz8Nz+26P5SuUuCgnjty+2fnCOetxz9H7TtZlH5Fcf mURDSsLzFddGzPNIqTVB/ci6M9sazdY4Bu3ZdiEZL33e92yhPlqbiV4vtqJ/pVtm 4qTL/NXaO7o+qHouYxuAeQF96JRsCSRMpjjRDyM7TSk9zpmpWc9/mj5NuBfqViev dH5adK4Vg++38K0n2JTugX6ygS31kYaPjngekaFJFLJ7orni0ajzTpRU0rCQZwJC nDdBFmaX5xDn/++JQnV+jPY3HInA8yzcYSjEegH5kZ9sBr3aJg8bsQzTAGA0KHUu /dNpyW/OhTgNs8cCHl8Aa9SFXau122UZYUSCuAjtBLGEzhcXPE/1h2gA40s4URpO 7GoQjkIG2g53i455nHlc =aRJM -----END PGP SIGNATURE----- --Apple-Mail=_3E15BCB3-7E1E-4F5D-B1A3-5BE9D2B4C9AE-- From hannes.tschofenig@gmx.net Sat Dec 7 10:16:17 2013 Return-Path: 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 DCD261AE08A for ; Sat, 7 Dec 2013 10:16:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 cPap_Ln0rfh4 for ; Sat, 7 Dec 2013 10:16:16 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id C3A891AE3B5 for ; Sat, 7 Dec 2013 10:16:15 -0800 (PST) Received: from [192.168.10.136] ([2.102.217.110]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MVedf-1W4xC10nVv-00Z0eW for ; Sat, 07 Dec 2013 19:16:10 +0100 Message-ID: <52A365E0.4080605@gmx.net> Date: Sat, 07 Dec 2013 18:16:00 +0000 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: SM , Andreas Kuckartz References: <529E8494.7000806@perens.com> <20131204111309.GB11727@nic.fr> <529F61D8.6030105@perens.com> <20131204171207.GC19914@thunk.org> <529F63C0.3040804@perens.com> <529F88AC.3090904@appelbaum.net> <529F90A0.8000706@perens.com> <529F9205.30906@appelbaum.net> <529F98C0.9090808@perens.com> <529F9F14.8050805@appelbaum.net> <529FB61A.7090604@perens.com> <529FBEF9.7030205@appelbaum.net> <529FC347.3080806@perens.com> <52A15835.2070901@cis-india.org> <6.2.5.6.2.20131206000507.0bdb7c20@resistor.net> <52A1B570.7000205@ping.de> <6.2.5.6.2.20131206083304.0c6fa0c8@resistor.net> In-Reply-To: <6.2.5.6.2.20131206083304.0c6fa0c8@resistor.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:C42gsUt+BOe8NJSB/0ci+srJU95SZSai90bnGtVN4iGdvOTIh5A 8Z0sTRGUs95U2h3HmGFfx5QbocUInfPcw58mM/lJOcProI1mwGBkAxRr79daQcR9Y6heYee GjWCZ3L941HoObis/8vMJzGl1IVgJHX2vLQFXmPBEa4rZb3kXuDuq1GHuFTubc2yikjfdEO YdJSiSgmSTxOj90GxlSUg== Cc: perpass@ietf.org, Pranesh Prakash , Bruce Perens Subject: Re: [perpass] Egal wie man diskutiert 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Dec 2013 18:16:18 -0000 The good thing is that Jörg Ziercke is not the only person to decide. To quote Bruce Schneier: " The FBI believes it can have it both ways: that it can open systems to its eavesdropping, but keep them secure from anyone else’s eavesdropping. That’s just not possible. It’s impossible to build a communications system that allows the FBI surreptitious access but doesn’t allow similar access by others. When it comes to security, we have two options: - We can build our systems to be as secure as possible from eavesdropping, or - we can deliberately weaken their security. We have to choose one or the other. " Ciao Hannes On 12/06/2013 05:01 PM, SM wrote: > Hi Andreas, > At 03:30 06-12-2013, Andreas Kuckartz wrote: >> Jörg Ziercke, the president of the German Federal Criminal Office (BKA) >> three weeks ago suggested to restrict the right to use Tor by requiring >> the registration of users. > > Here is an (unverified) comment from someone working for the BKA: > > "Egal wie man diskutiert, man muss sich hier entscheiden, ob man den > Ermittlungserfolg will oder nicht." > >> Standards can not solve such political and legal attempts to attack the >> privacy and security of users. >> >> But that should not prevent the development of standards which disable >> mass surveillance when those standards are deployed. > > The short answer is yes. > > Regards, > -sm > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass From bruce@perens.com Sat Dec 7 16:08:30 2013 Return-Path: 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 4EFE91AE460 for ; Sat, 7 Dec 2013 16:08:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.177 X-Spam-Level: X-Spam-Status: No, score=-1.177 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, 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 9zebhDDlc7N2 for ; Sat, 7 Dec 2013 16:08:29 -0800 (PST) Received: from alchemy.perens.com (alchemy.perens.com [206.221.219.26]) by ietfa.amsl.com (Postfix) with ESMTP id 97D431AE0F8 for ; Sat, 7 Dec 2013 16:08:29 -0800 (PST) Received: from [192.168.1.178] (66-214-223-54.static.reno.nv.charter.com [66.214.223.54]) by alchemy.perens.com (Postfix) with ESMTPSA id 54CA3500084 for ; Sat, 7 Dec 2013 16:08:23 -0800 (PST) Message-ID: <52A3B892.3040108@perens.com> Date: Sat, 07 Dec 2013 16:08:50 -0800 From: Bruce Perens User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20131005 Icedove/17.0.9 MIME-Version: 1.0 To: perpass References: <52A3AF02.8050103@perens.com> In-Reply-To: <52A3AF02.8050103@perens.com> X-Forwarded-Message-Id: <52A3AF02.8050103@perens.com> Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [perpass] Fwd: Re: 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Dec 2013 00:08:30 -0000


-------- Original Message --------
Subject: Re: [perpass] perens-perpass-appropriate-response-01
Date: Sat, 07 Dec 2013 15:28:02 -0800
From: Bruce Perens <bruce@perens.com>
To: Jacob Appelbaum <jacob@appelbaum.net>


On 12/07/2013 02:11 AM, Jacob Appelbaum wrote:
You're not being forced to do anything, are you? You could use HTTP 1.1 forever, right?
Once there's an HTTP 2.0, broad support for HTTP 1.1 on the web will not survive.

What I don't understand is why all of these people you've given me a long lecture about, including yourself, will necessarily be oppressed if they have a choice, and will not be oppressed if they have no choice. And why I have so little sympathy for them, according to you, simply because I would like to offer them a choice.

    Thanks

    Bruce


From bruce@perens.com Sat Dec 7 16:08:45 2013 Return-Path: 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 122E21AE3E5 for ; Sat, 7 Dec 2013 16:08:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.177 X-Spam-Level: X-Spam-Status: No, score=-1.177 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, 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 BD3aWEoydgkV for ; Sat, 7 Dec 2013 16:08:44 -0800 (PST) Received: from alchemy.perens.com (alchemy.perens.com [206.221.219.26]) by ietfa.amsl.com (Postfix) with ESMTP id 721A41AE0F8 for ; Sat, 7 Dec 2013 16:08:44 -0800 (PST) Received: from [192.168.1.178] (66-214-223-54.static.reno.nv.charter.com [66.214.223.54]) by alchemy.perens.com (Postfix) with ESMTPSA id 54332500084 for ; Sat, 7 Dec 2013 16:08:40 -0800 (PST) Message-ID: <52A3B8A4.6000309@perens.com> Date: Sat, 07 Dec 2013 16:09:08 -0800 From: Bruce Perens User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20131005 Icedove/17.0.9 MIME-Version: 1.0 To: perpass References: <52A3B32D.8000301@perens.com> In-Reply-To: <52A3B32D.8000301@perens.com> X-Forwarded-Message-Id: <52A3B32D.8000301@perens.com> Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [perpass] Fwd: Re: 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Dec 2013 00:08:45 -0000


-------- Original Message --------
Subject: Re: [perpass] perens-perpass-appropriate-response-01
Date: Sat, 07 Dec 2013 15:45:49 -0800
From: Bruce Perens <bruce@perens.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>


On 12/07/2013 05:14 AM, Stephen Farrell wrote:
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.
Well, we do have some HTTP uses where encryption that hides the content won't be allowed, and thus authentication is important.

We can't have encryption when we use HTTP over Amateur Radio in the US and many other countries. There is self-policing on ham frequencies that requires that people be able to copy other people's transmissions, and encryption defeats that. Obviously we don't put confidential data on those frequencies, that belongs on your cell phone. So, an authentication-only WiFi protocol is needed for Amateur Radio, and possibly an authentication-only version of TLS.

Even when authentication is not available end-to-end, we gain something by inserting it at the radio gateway.

There are also some situations involving legal minors or prisoners where there should be monitoring. So an authentication-only protocol is interesting for that too.

    Thanks

    Bruce


From huitema@huitema.net Sat Dec 7 17:57:46 2013 Return-Path: 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 6DC4B1AE47E for ; Sat, 7 Dec 2013 17:57:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001] 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 sPC1szwIE4p4 for ; Sat, 7 Dec 2013 17:57:45 -0800 (PST) Received: from xsmtp11.mail2web.com (xsmtp11.mail2web.com [168.144.250.181]) by ietfa.amsl.com (Postfix) with ESMTP id DC66A1AE172 for ; Sat, 7 Dec 2013 17:57:44 -0800 (PST) Received: from [10.5.2.49] (helo=xmail11.myhosting.com) by xsmtp11.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1VpTcp-0001dJ-Qy for perpass@ietf.org; Sat, 07 Dec 2013 20:57:40 -0500 Received: (qmail 9583 invoked from network); 8 Dec 2013 01:57:38 -0000 Received: from unknown (HELO HUITEMA5) (Authenticated-user:_huitema@huitema.net@[24.16.156.113]) (envelope-sender ) by xmail11.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 8 Dec 2013 01:57:38 -0000 From: "Christian Huitema" To: "'perpass'" References: <52A3B32D.8000301@perens.com> <52A3B8A4.6000309@perens.com> In-Reply-To: <52A3B8A4.6000309@perens.com> Date: Sat, 7 Dec 2013 17:57:37 -0800 Message-ID: <130f01cef3b8$df9885d0$9ec99170$@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQJkQ5KX8GOB7Lj9e87y7WTUvGmsIwJAdTJMmQziHnA= Content-Language: en-us Subject: Re: [perpass] Fwd: Re: 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Dec 2013 01:57:46 -0000 > We can't have encryption when we use HTTP over Amateur Radio in the US and many > other countries. There is self-policing on ham frequencies that requires that people be > able to copy other people's transmissions, and encryption defeats that. Obviously we > don't put confidential data on those frequencies, that belongs on your cell phone. So, an > authentication-only WiFi protocol is needed for Amateur Radio, and possibly an > authentication-only version of TLS. I for one cannot see why we would deliberately sabotage the security of the entire Internet just to enable amateur radio to conveniently use Internet applications and protocols. The amateur radio restrictions are very much the same restrictions that hampered the security of other Internet links before crypto was deregulated in the 90's. Governments used the power of regulation and licensing to ensure that these restrictions were kept in place for amateur radio. That's too bad, but we should not make the whole Internet insecure just to please the radio amateurs. -- Christian Huitema From nweaver@icsi.berkeley.edu Sun Dec 8 07:55:53 2013 Return-Path: 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 3A6C21ADFBF for ; Sun, 8 Dec 2013 07:55:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.003 X-Spam-Level: X-Spam-Status: No, score=-0.003 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 Oq_S18nKEZNy for ; Sun, 8 Dec 2013 07:55:51 -0800 (PST) Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id C0DFD1ADFBB for ; Sun, 8 Dec 2013 07:55:51 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 971E12C4042; Sun, 8 Dec 2013 07:55:47 -0800 (PST) X-Virus-Scanned: amavisd-new at ICSI.Berkeley.EDU Received: from rock.ICSI.Berkeley.EDU ([127.0.0.1]) by localhost (maihub.ICSI.Berkeley.EDU [127.0.0.1]) (amavisd-new, port 10024) with LMTP id IcXLnS1qafvX; Sun, 8 Dec 2013 07:55:47 -0800 (PST) Received: from [10.0.1.14] (c-76-103-162-14.hsd1.ca.comcast.net [76.103.162.14]) (Authenticated sender: nweaver) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 177D72C401A; Sun, 8 Dec 2013 07:55:47 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_F644DCAE-B6BB-4E91-A485-07765E1478AD"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Nicholas Weaver In-Reply-To: <52A3B8A4.6000309@perens.com> Date: Sun, 8 Dec 2013 07:55:50 -0800 Message-Id: <6FFED7BB-9272-4B94-AFC3-8689F3D3D325@icsi.berkeley.edu> References: <52A3B32D.8000301@perens.com> <52A3B8A4.6000309@perens.com> To: Bruce Perens X-Mailer: Apple Mail (2.1510) Cc: perpass , Nicholas Weaver Subject: Re: [perpass] Fwd: Re: 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Dec 2013 15:55:53 -0000 --Apple-Mail=_F644DCAE-B6BB-4E91-A485-07765E1478AD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Dec 7, 2013, at 4:09 PM, Bruce Perens wrote: > Well, we do have some HTTP uses where encryption that hides the = content won't be allowed, and thus authentication is important. >=20 > We can't have encryption when we use HTTP over Amateur Radio in the US = and many other countries. There is self-policing on ham frequencies that = requires that people be able to copy other people's transmissions, and = encryption defeats that. Obviously we don't put confidential data on = those frequencies, that belongs on your cell phone. So, an = authentication-only WiFi protocol is needed for Amateur Radio, and = possibly an authentication-only version of TLS. NO!!!! The reason is downgrade attacks. A huge problem with the IPSec standard = is that NULL encryption was allowed in there, and also known weak modes = (single DES, 720b D/H etc). Its one of the primary reasons why John = Gilmore and therefore others feel the IPSec process was sabotaged by the = NSA. To explicitly support downgraded, athuentication w/o encryption is = STUPID! it is DANGEROUS! =20 About the only thing that is not a horrid idea is to have the key = exchange generate a separate MAC and encryption key, using an encrypt = then MAC structure. Yet that loses out on the benefit of authenticated = encryption modes that build the MAC into the communication. So face it Bruce, your only option should be to have the client leak the = session keys keys, and thereby explicitly say "NO SECURITY ON THIS = CONNECTION, HAVE A NICE DAY". =20 And yes, this means the French can pwn you. Sorry, use a network that = allows encryption. Or have your session key leaker in UDP, and only 2-3 = hops on the TTL, so only locals can pwn you. [1]=20 Anything more built into the protocol to support unencrypted = communication represents a sabotage attempt on the rest of the Internet. [1] I'm just waiting for the Botnet that uses open-WiFi to pwn the = fellow computers in the local starbucks. Its an old idea, but a good = one... -- Nicholas Weaver it is a tale, told by an idiot, nweaver@icsi.berkeley.edu full of sound and fury, 510-666-2903 .signifying nothing PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc --Apple-Mail=_F644DCAE-B6BB-4E91-A485-07765E1478AD Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCgAGBQJSpJaGAAoJEG2B1w+SDi/uxjEQAK2M/oFvZFOLZlTmk3jz48jY bcCLpEfT0h5OFd+aoilfwsfY/oSPsrUuKvHFe+HWT3jFUemds43MuYBJ14C2INOm E9Y//cEKPsBwUBuSNnM1sLavetjN15NdVtiQe3Dc79AxhIDE2oHMY2afswPuya6d PUzkmnQ6NG1jYFgs9MtCgrtHElH70+zmIOqzj4MNVU/dkqr5igxh5kBR84NicMYE fytqg62aypnwtt+znerfutVlSZJF8GF5sdfbr96BTzVJk2GEt8buE9hpBABL+xTM 34iY48QnDbyoXp5T9aL8N93cu6ozXyhq1hXVDrdKIarJsYRuK/VktZF3A/enVPan BbMjPffsy2maTgIg0lyvgDNBxrPSunzsZtHCL2Ue2LBU0Vu31iRyI8elmCtIDqE7 s8QusuoNhGNxPX/1s04iXrFWukcQhUMPefe7x0gEds3DA/tZGTpYjW/CaECwCkH5 0Vf0wdvM9QrifRYpOzvqUWqfNsUIUWV9yxtU1L0X06ZDgCUXhix/ooUVe3BHH0ty 5VV3zENzhJM0yl2Oidgb34ixWZdqr7S3D3TMFjbq/RLJrd0hpFirhnXvidTSv4EI VK0NxO+S8HnAMUfoBwsJL+K2Rv5S2l9EmJpvwq1YeJ08cAEu4hW7wQX7Kx/l1jci FuY0JPrahtcOYLgiKXPW =W8ns -----END PGP SIGNATURE----- --Apple-Mail=_F644DCAE-B6BB-4E91-A485-07765E1478AD-- From hallam@gmail.com Sun Dec 8 09:33:09 2013 Return-Path: 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 2E5851AE020 for ; Sun, 8 Dec 2013 09:33:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.701 X-Spam-Level: * X-Spam-Status: No, score=1.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_PASS=-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 sUHZj9KIlSOm for ; Sun, 8 Dec 2013 09:33:07 -0800 (PST) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id 0AFBA1AE01F for ; Sun, 8 Dec 2013 09:33:06 -0800 (PST) Received: by mail-wg0-f41.google.com with SMTP id y10so2556091wgg.0 for ; Sun, 08 Dec 2013 09:33:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6/SIr7ZBuJlXwkiPtyCc147Sjcy3MrX7rTiw9UxvgHc=; b=w5vgxmzMxx0fmrN+8KyytzNfv9EmePmc/+ttvbHUIVZnLMnlMzuL8GkUQCo0Uf9X3p YcoPEUSHrtXv6Td1oMHFRX475bJCDkbFQeJUN6VSQ5Ooopuxp4rrBG0pLFME7ZRnVr7S gOvgUV8cY7IKyCrg9YuVFJ17dl6jRDFQNT9mLQfVog3UWkuSFDuGhBx4AlK5xjlbj49a WIefFh3i6FLw+JXlFwstsMlUx3+7rnn2Rd7A5Ahd3OYn3/9NBIb4uur7dc3ft0WAJnZk ZKuz55dM+qoy56/BOvjarJFLDe6gPWzbW1QpJcLcVHGANF/NogRN3N4FC1QVa/NuSjXt LhVw== MIME-Version: 1.0 X-Received: by 10.194.78.141 with SMTP id b13mr12230708wjx.32.1386523981917; Sun, 08 Dec 2013 09:33:01 -0800 (PST) Received: by 10.194.243.136 with HTTP; Sun, 8 Dec 2013 09:33:01 -0800 (PST) In-Reply-To: <52A365E0.4080605@gmx.net> References: <529E8494.7000806@perens.com> <20131204111309.GB11727@nic.fr> <529F61D8.6030105@perens.com> <20131204171207.GC19914@thunk.org> <529F63C0.3040804@perens.com> <529F88AC.3090904@appelbaum.net> <529F90A0.8000706@perens.com> <529F9205.30906@appelbaum.net> <529F98C0.9090808@perens.com> <529F9F14.8050805@appelbaum.net> <529FB61A.7090604@perens.com> <529FBEF9.7030205@appelbaum.net> <529FC347.3080806@perens.com> <52A15835.2070901@cis-india.org> <6.2.5.6.2.20131206000507.0bdb7c20@resistor.net> <52A1B570.7000205@ping.de> <6.2.5.6.2.20131206083304.0c6fa0c8@resistor.net> <52A365E0.4080605@gmx.net> Date: Sun, 8 Dec 2013 12:33:01 -0500 Message-ID: From: Phillip Hallam-Baker To: Hannes Tschofenig Content-Type: multipart/alternative; boundary=047d7bfcfc826a358904ed094538 Cc: SM , perpass , Bruce Perens , Pranesh Prakash , Andreas Kuckartz Subject: Re: [perpass] Egal wie man diskutiert 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Dec 2013 17:33:09 -0000 --047d7bfcfc826a358904ed094538 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Sat, Dec 7, 2013 at 1:16 PM, Hannes Tschofenig wrote: > The good thing is that J=F6rg Ziercke is not the only person to decide. > > To quote Bruce Schneier: > " > The FBI believes it can have it both ways: that it can open systems to > its eavesdropping, but keep them secure from anyone else=92s > eavesdropping. That=92s just not possible. It=92s impossible to build a > communications system that allows the FBI surreptitious access but > doesn=92t allow similar access by others. When it comes to security, we > have two options: > - We can build our systems to be as secure as possible from > eavesdropping, or > - we can deliberately weaken their security. > We have to choose one or the other. > +1 I have met the senior management of the NSA. My take is that they are generals fighting the last war. All they understand is attack or threat of attack as the best form of defense. Threat of attack does not work against terrorism but it can work against state sponsors, at least to some degree. Ghadaffi funded many of the European terrorist organizations, he supplied the IRA with the Semtex explosive used in the attack on my family. Ghadaffi stopped supplying the external groups after Reagan's bombing attack on Tripoli but he also downed two civilian airplanes in retaliation killing hundreds of people. At this point the traditional terrorist strategy is conspicuously bankrupt. The terrorists can't gather in sufficient force to be a significant threat unless they have a state sponsor or a failed state they can operate from. The new terrorist concern is that there will be a group of hackers with the sufficient skills and motivation to attack civil critical infrastructure. Water, electric, etc. And some of the proposals for how to deal with that threat are worse than the threat. Bombing Iran at the first sign of attack (which would give Netanyahu an easy way of achieving his objective). Declaring martial law at the first sign of a critical infrastructure attack= . The last should worry anyone who remembers the Peter Aspinal/James Goldsmith attempt to organize a coup in the UK. It was a harebrained scheme but they approached the head of MI5 (who immediately reported the plot to the PM and the Queen). The US has no shortage of politicians mouthing treason and they have a whole news infrastructure telling them how right they are. So yes, I do worry about terrorism. But I also worry about the people in charge of this surveillance infrastructure being the threat. I certainly do not think we can trust people who spend their time telling each other fairy stories about the President being illegitimate because he is not a US citizen. --=20 Website: http://hallambaker.com/ --047d7bfcfc826a358904ed094538 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable



On Sat, Dec 7, 2013 at 1:16 PM, Hannes Tschofenig <hannes.= tschofenig@gmx.net> wrote:
The good thing is that J=F6rg Ziercke is not= the only person to decide.

To quote Bruce Schneier:
"
The FBI believes it can have it both ways: that it can open systems to
its eavesdropping, but keep them secure from anyone else=92s
eavesdropping. That=92s just not possible. It=92s impossible to build a
communications system that allows the FBI surreptitious access but
doesn=92t allow similar access by others. When it comes to security, we
have two options:
- We can build our systems to be as secure as possible from
eavesdropping, or
- we can deliberately weaken their security.
We have to choose one or the other.

+1<= /div>

I have met the senior management of the NSA. My ta= ke is that they are generals fighting the last war. All they understand is = attack or threat of attack as the best form of defense.

Threat of attack does not work against terrorism but it= can work against state sponsors, at least to some degree. Ghadaffi funded = many of the European terrorist organizations, he supplied the IRA with the = Semtex explosive used in the attack on my family. Ghadaffi stopped supplyin= g the external groups after Reagan's bombing attack on Tripoli but he a= lso downed two civilian airplanes in retaliation killing hundreds of people= .


At this point the traditional terrorist = strategy is conspicuously bankrupt. The terrorists can't gather in suff= icient force to be a significant threat unless they have a state sponsor or= a failed state they can operate from.

The new terrorist concern is that there will be a group= of hackers with the sufficient skills and motivation to attack civil criti= cal infrastructure. Water, electric, etc. And some of the proposals for how= to deal with that threat are worse than the threat. Bombing Iran at the fi= rst sign of attack (which would give Netanyahu an easy way of achieving his= objective). Declaring martial law at the first sign of a critical infrastr= ucture attack.

The last should worry anyone who remembers the Peter As= pinal/James Goldsmith attempt to organize a coup in the UK. It was a harebr= ained scheme but they approached the head of MI5 (who immediately reported = the plot to the PM and the Queen). The US has no shortage of politicians mo= uthing treason and they have a whole news infrastructure telling them how r= ight they are.


So yes, I do worry about terrorism. But = I also worry about the people in charge of this surveillance infrastructure= being the threat. I certainly do not think we can trust people who spend t= heir time telling each other fairy stories about the President being illegi= timate because he is not a US citizen.


=A0
--
Website: http://hallambaker.com/
--047d7bfcfc826a358904ed094538-- From Kent_Landfield@mcafee.com Sun Dec 8 09:41:43 2013 Return-Path: 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 B91631AE041 for ; Sun, 8 Dec 2013 09:41:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 tJKPPy27hgZc for ; Sun, 8 Dec 2013 09:41:41 -0800 (PST) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) by ietfa.amsl.com (Postfix) with ESMTP id 823621AE03C for ; Sun, 8 Dec 2013 09:41:41 -0800 (PST) Received: from MIVEXAMER1N2.corp.nai.org (unknown [10.48.48.12]) by MIVWSMAILOUT1.mcafee.com with smtp id 18e7_6fae_5f8daf03_e1d7_4016_ab8f_2812cad33fc8; Sun, 08 Dec 2013 11:41:36 -0600 Received: from MIVEXEMEA1N1.corp.nai.org (10.48.48.31) by MIVEXAMER1N2.corp.nai.org (10.48.48.12) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sun, 8 Dec 2013 12:41:36 -0500 Received: from MIVEXAMER1N1.corp.nai.org ([169.254.2.68]) by MIVEXEMEA1N1.corp.nai.org ([169.254.3.231]) with mapi id 14.03.0158.001; Sun, 8 Dec 2013 12:41:36 -0500 From: To: Thread-Topic: [perpass] Egal wie man diskutiert Thread-Index: AQHO9Dy+bwYNMADEyk+otOXOZWvNPw== Date: Sun, 8 Dec 2013 17:41:36 +0000 Message-ID: References: <529E8494.7000806@perens.com> <20131204111309.GB11727@nic.fr> <529F61D8.6030105@perens.com> <20131204171207.GC19914@thunk.org> <529F63C0.3040804@perens.com> <529F88AC.3090904@appelbaum.net> <529F90A0.8000706@perens.com> <529F9205.30906@appelbaum.net> <529F98C0.9090808@perens.com> <529F9F14.8050805@appelbaum.net> <529FB61A.7090604@perens.com> <529FBEF9.7030205@appelbaum.net> <529FC347.3080806@perens.com> <52A15835.2070901@cis-india.org> <6.2.5.6.2.20131206000507.0bdb7c20@resistor.net> <52A1B570.7000205@ping.de> <6.2.5.6.2.20131206083304.0c6fa0c8@resistor.net> <52A365E0.4080605@gmx.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.48.48.242] Content-Type: multipart/alternative; boundary="_000_CECA0A235A892kentlandfieldmcafeecom_" MIME-Version: 1.0 Subject: Re: [perpass] Egal wie man diskutiert 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Dec 2013 17:41:43 -0000 --_000_CECA0A235A892kentlandfieldmcafeecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Really? Is this what this list is for? If you want to rant about your poli= tical views please go elsewhere. If you want to try to solve a problem, we= are all ears. This is not about one government or another doing something= bad since all governments do it. Some are just better at it today. Others = will catch up if we don't do something it. Regardless we need to address th= e problem not just post to see ourselves post=85 Or maybe I totally misund= erstood the reason for this list. From: Phillip Hallam-Baker > Date: Sunday, December 8, 2013 11:33 AM To: Hannes Tschofenig > Cc: SM >, perpass >, Bruce Perens >, Pranesh Prakash >, Andreas Kuckartz > Subject: Re: [perpass] Egal wie man diskutiert On Sat, Dec 7, 2013 at 1:16 PM, Hannes Tschofenig > wrote: The good thing is that J=F6rg Ziercke is not the only person to decide. To quote Bruce Schneier: " The FBI believes it can have it both ways: that it can open systems to its eavesdropping, but keep them secure from anyone else=92s eavesdropping. That=92s just not possible. It=92s impossible to build a communications system that allows the FBI surreptitious access but doesn=92t allow similar access by others. When it comes to security, we have two options: - We can build our systems to be as secure as possible from eavesdropping, or - we can deliberately weaken their security. We have to choose one or the other. +1 I have met the senior management of the NSA. My take is that they are gener= als fighting the last war. All they understand is attack or threat of attac= k as the best form of defense. Threat of attack does not work against terrorism but it can work against st= ate sponsors, at least to some degree. Ghadaffi funded many of the European= terrorist organizations, he supplied the IRA with the Semtex explosive use= d in the attack on my family. Ghadaffi stopped supplying the external group= s after Reagan's bombing attack on Tripoli but he also downed two civilian = airplanes in retaliation killing hundreds of people. At this point the traditional terrorist strategy is conspicuously bankrupt.= The terrorists can't gather in sufficient force to be a significant threat= unless they have a state sponsor or a failed state they can operate from. The new terrorist concern is that there will be a group of hackers with the= sufficient skills and motivation to attack civil critical infrastructure. = Water, electric, etc. And some of the proposals for how to deal with that t= hreat are worse than the threat. Bombing Iran at the first sign of attack (= which would give Netanyahu an easy way of achieving his objective). Declari= ng martial law at the first sign of a critical infrastructure attack. The last should worry anyone who remembers the Peter Aspinal/James Goldsmit= h attempt to organize a coup in the UK. It was a harebrained scheme but the= y approached the head of MI5 (who immediately reported the plot to the PM a= nd the Queen). The US has no shortage of politicians mouthing treason and t= hey have a whole news infrastructure telling them how right they are. So yes, I do worry about terrorism. But I also worry about the people in ch= arge of this surveillance infrastructure being the threat. I certainly do n= ot think we can trust people who spend their time telling each other fairy = stories about the President being illegitimate because he is not a US citiz= en. -- Website: http://hallambaker.com/ --_000_CECA0A235A892kentlandfieldmcafeecom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <2F369EE0F5A9CF418C7CBA955A688257@McAfee.com> Content-Transfer-Encoding: quoted-printable
Really? Is this what this list is for?  If you want to rant about= your political views please go elsewhere.  If you want to try to solv= e a problem, we are all ears.  This is not about one government or ano= ther doing something bad since all governments do it. Some are just better at it today. Others will catch up if we don't = do something it. Regardless we need to address the problem not just post to= see ourselves post=85  Or maybe I totally misunderstood the reason fo= r this list.

From: Phillip Hallam-Baker <hallam@gmail.com>
Date: Sunday, December 8, 2013 11:3= 3 AM
To: Hannes Tschofenig <hannes.tschofenig@gmx.net>
Cc: SM <sm@resistor.net>, perpass <perpass@ietf.org>, Bruce Perens <bruce@perens.com>, Pranesh Prakash <pranesh@cis-india.org>, Andreas Kuckartz <a.kuckartz@ping= .de>
Subject: Re: [perpass] Egal wie man= diskutiert




On Sat, Dec 7, 2013 at 1:16 PM, Hannes Tschofeni= g <hannes.t= schofenig@gmx.net> wrote:
The good thing is that J=F6rg Ziercke is not the only person to decide.

To quote Bruce Schneier:
"
The FBI believes it can have it both ways: that it can open systems to
its eavesdropping, but keep them secure from anyone else=92s
eavesdropping. That=92s just not possible. It=92s impossible to build a
communications system that allows the FBI surreptitious access but
doesn=92t allow similar access by others. When it comes to security, we
have two options:
- We can build our systems to be as secure as possible from
eavesdropping, or
- we can deliberately weaken their security.
We have to choose one or the other.

+1

I have met the senior management of the NSA. My take is that they are = generals fighting the last war. All they understand is attack or threat of = attack as the best form of defense.

Threat of attack does not work against terrorism but it can work again= st state sponsors, at least to some degree. Ghadaffi funded many of the Eur= opean terrorist organizations, he supplied the IRA with the Semtex explosiv= e used in the attack on my family. Ghadaffi stopped supplying the external groups after Reagan's bombing atta= ck on Tripoli but he also downed two civilian airplanes in retaliation kill= ing hundreds of people.


At this point the traditional terrorist strategy is conspicuously bank= rupt. The terrorists can't gather in sufficient force to be a significant t= hreat unless they have a state sponsor or a failed state they can operate f= rom.

The new terrorist concern is that there will be a group of hackers wit= h the sufficient skills and motivation to attack civil critical infrastruct= ure. Water, electric, etc. And some of the proposals for how to deal with t= hat threat are worse than the threat. Bombing Iran at the first sign of attack (which would give Netanyahu an ea= sy way of achieving his objective). Declaring martial law at the first sign= of a critical infrastructure attack.

The last should worry anyone who remembers the Peter Aspinal/James Gol= dsmith attempt to organize a coup in the UK. It was a harebrained scheme bu= t they approached the head of MI5 (who immediately reported the plot to the= PM and the Queen). The US has no shortage of politicians mouthing treason and they have a whole news infras= tructure telling them how right they are.


So yes, I do worry about terrorism. But I also worry about the people = in charge of this surveillance infrastructure being the threat. I certainly= do not think we can trust people who spend their time telling each other f= airy stories about the President being illegitimate because he is not a US citizen.


 
--
Website: http://hallambaker.com/
--_000_CECA0A235A892kentlandfieldmcafeecom_-- From hallam@gmail.com Sun Dec 8 10:09:08 2013 Return-Path: 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 D48041AE04A for ; Sun, 8 Dec 2013 10:09:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 DAFuo_47Vzu3 for ; Sun, 8 Dec 2013 10:09:06 -0800 (PST) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 935051AE03F for ; Sun, 8 Dec 2013 10:09:06 -0800 (PST) Received: by mail-wi0-f173.google.com with SMTP id hn9so2839818wib.0 for ; Sun, 08 Dec 2013 10:09:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=a+DDs6SLSLFutFBO5+lKF3Z1XZ8AAB4hHlvQCQITKlI=; b=hiTF/Dc4ylH/saMznlzWMn7rZcfAkRCubr+8K2F6wYalLMp7lT8x/aC5KL7igc9YCu ep3C76UFqnQrsnn65pg+QZPw/jbQn+0JgjvDL4lMjHSXELnbzG1YdIlylOyBYV3aRY4s XKJUc0PjvSw6lNuXtcCY4yxT5IiHSI5D8QJA4p1dYTwlaFq2pud5hsixoytGxyxMfnih 4ks/2df+dpI3Y/XY9Y+VYZNRNULCwWicuBrGYyBklLDUzvGcRWbRQN6swHWmUadFcQln qwFP/ZyrlTWBEyHW/1gvi+1yOtateM8K3IueMMxAxCgTmFPsQEX8jBTesHxgDcfOLKPs 2EBw== MIME-Version: 1.0 X-Received: by 10.194.187.101 with SMTP id fr5mr199259wjc.76.1386526141617; Sun, 08 Dec 2013 10:09:01 -0800 (PST) Received: by 10.194.243.136 with HTTP; Sun, 8 Dec 2013 10:09:01 -0800 (PST) In-Reply-To: References: <529E8494.7000806@perens.com> <20131204111309.GB11727@nic.fr> <529F61D8.6030105@perens.com> <20131204171207.GC19914@thunk.org> <529F63C0.3040804@perens.com> <529F88AC.3090904@appelbaum.net> <529F90A0.8000706@perens.com> <529F9205.30906@appelbaum.net> <529F98C0.9090808@perens.com> <529F9F14.8050805@appelbaum.net> <529FB61A.7090604@perens.com> <529FBEF9.7030205@appelbaum.net> <529FC347.3080806@perens.com> <52A15835.2070901@cis-india.org> <6.2.5.6.2.20131206000507.0bdb7c20@resistor.net> <52A1B570.7000205@ping.de> <6.2.5.6.2.20131206083304.0c6fa0c8@resistor.net> <52A365E0.4080605@gmx.net> Date: Sun, 8 Dec 2013 13:09:01 -0500 Message-ID: From: Phillip Hallam-Baker To: Kent_Landfield@mcafee.com Content-Type: multipart/alternative; boundary=047d7bd6b9ac249db504ed09c655 Cc: perpass Subject: Re: [perpass] Egal wie man diskutiert 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Dec 2013 18:09:09 -0000 --047d7bd6b9ac249db504ed09c655 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Sun, Dec 8, 2013 at 12:41 PM, wrote: > Really? Is this what this list is for? If you want to rant about your > political views please go elsewhere. If you want to try to solve a > problem, we are all ears. This is not about one government or another > doing something bad since all governments do it. Some are just better at = it > today. Others will catch up if we don't do something it. Regardless we ne= ed > to address the problem not just post to see ourselves post=85 Or maybe I > totally misunderstood the reason for this list. > I was responding to yet another poster suggesting that we should do nothing. If people want to argue about whether we should be doing this work then we are arguing politics, end of story. I have met the people and those are my personal opinions of their trustworthiness. Nor was I the only person to come to that conclusion. What I have suspected for some time is that our generals, the Chinese generals and the Russian generals would all rather like to have a cyber arms race and get the rest of us to all foot the bill for it. --=20 Website: http://hallambaker.com/ --047d7bd6b9ac249db504ed09c655 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable



On Sun, Dec 8, 2013 at 12:41 PM, <Kent_Landfield@mcafee.c= om> wrote:
Really? Is this what this list is for? =A0If you want to rant about yo= ur political views please go elsewhere. =A0If you want to try to solve a pr= oblem, we are all ears. =A0This is not about one government or another doin= g something bad since all governments do it. Some are just better at it today. Others will catch up if we don= 9;t do something it. Regardless we need to address the problem not just pos= t to see ourselves post=85 =A0Or maybe I totally misunderstood the reason f= or this list.

I was responding to yet anothe= r poster suggesting that we should do nothing. If people want to argue abou= t whether we should be doing this work then we are arguing politics, end of= story.

I have met the people and those are my personal opinion= s of their trustworthiness. Nor was I the only person to come to that concl= usion.=A0



What I hav= e suspected for some time is that our generals, the Chinese generals and th= e Russian generals would all rather like to have a cyber arms race and get = the rest of us to all foot the bill for it.




--
We= bsite: http://hallambaker.com/
--047d7bd6b9ac249db504ed09c655-- From hallam@gmail.com Sun Dec 8 10:51:34 2013 Return-Path: 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 9C64E1AE04D for ; Sun, 8 Dec 2013 10:51:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 0rzKnZF8r_9h for ; Sun, 8 Dec 2013 10:51:32 -0800 (PST) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 224191AE03E for ; Sun, 8 Dec 2013 10:51:31 -0800 (PST) Received: by mail-wi0-f173.google.com with SMTP id hn9so2864153wib.0 for ; Sun, 08 Dec 2013 10:51:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:in-reply-to:mime-version:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=h+bdYGOPJQ+1IuxsMCyE8N4+UT4tsHGKFUr7erFSOJU=; b=De1CjPoVz7FRbHifoNDUJ7GEcQgXSSNSsOH4gM5w/zej0FNryXXkcj73U9w2ofEiGN ZQkoiPgn25j5I/SacdvDVDb2aMjvVdSluv0F0zNAudW/nfIkMMDfpMwrG6UUr3y01itg 4XebFvx1qeIH3O/IS857qDBtAxXGwc1REnSSiLzuav1a4ZJ7npl6mzIN/r0pTIhfwh2e lf9K+UnvAEsOiyx5RmTjU2aYhyPJT2vl93bOnttWCe6iweAqrwuKCK9+Aq4Dzmh4AuR5 CUGs+732qenNAXY870phzQHmW5yMy29CBlxVHhtT1H/pSYeVyXr6k+XlYRc4ttKp4Qup XMqg== X-Received: by 10.180.189.80 with SMTP id gg16mr10912084wic.32.1386528687178; Sun, 08 Dec 2013 10:51:27 -0800 (PST) References: <52A3B32D.8000301@perens.com> <52A3B8A4.6000309@perens.com> <6FFED7BB-9272-4B94-AFC3-8689F3D3D325@icsi.berkeley.edu> In-Reply-To: <6FFED7BB-9272-4B94-AFC3-8689F3D3D325@icsi.berkeley.edu> Mime-Version: 1.0 (1.0) From: Phillip Hallam-Baker Date: Sun, 8 Dec 2013 13:51:25 -0500 Message-ID: <-917337036588491953@unknownmsgid> To: Nicholas Weaver Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: perpass , Bruce Perens Subject: Re: [perpass] Fwd: Re: 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Dec 2013 18:51:34 -0000 This is actually my reason for opposing making http a mandatory I am fine with the idea of requiring strong TLS I am fine with the idea of a new mechanism for weakly authenticated http. But do not weaken TLS so that it can be used as a proxy bypass strategy without strong crypto Do it right or write your own. Do not damage the only security protocol we have so some folk can shave a few msec off latency Sent from my difference engine > On Dec 8, 2013, at 10:55 AM, Nicholas Weaver = wrote: > > >> On Dec 7, 2013, at 4:09 PM, Bruce Perens wrote: >> Well, we do have some HTTP uses where encryption that hides the content = won't be allowed, and thus authentication is important. >> >> We can't have encryption when we use HTTP over Amateur Radio in the US a= nd many other countries. There is self-policing on ham frequencies that req= uires that people be able to copy other people's transmissions, and encrypt= ion defeats that. Obviously we don't put confidential data on those frequen= cies, that belongs on your cell phone. So, an authentication-only WiFi prot= ocol is needed for Amateur Radio, and possibly an authentication-only versi= on of TLS. > > NO!!!! > > The reason is downgrade attacks. A huge problem with the IPSec standard = is that NULL encryption was allowed in there, and also known weak modes (si= ngle DES, 720b D/H etc). Its one of the primary reasons why John Gilmore a= nd therefore others feel the IPSec process was sabotaged by the NSA. > > To explicitly support downgraded, athuentication w/o encryption is STUPID= ! it is DANGEROUS! > > > > About the only thing that is not a horrid idea is to have the key exchang= e generate a separate MAC and encryption key, using an encrypt then MAC str= ucture. Yet that loses out on the benefit of authenticated encryption mod= es that build the MAC into the communication. > > So face it Bruce, your only option should be to have the client leak the = session keys keys, and thereby explicitly say "NO SECURITY ON THIS CONNECTI= ON, HAVE A NICE DAY". > > And yes, this means the French can pwn you. Sorry, use a network that al= lows encryption. Or have your session key leaker in UDP, and only 2-3 hops= on the TTL, so only locals can pwn you. [1] > > Anything more built into the protocol to support unencrypted communicatio= n represents a sabotage attempt on the rest of the Internet. > > > [1] I'm just waiting for the Botnet that uses open-WiFi to pwn the fellow= computers in the local starbucks. Its an old idea, but a good one... > > -- > Nicholas Weaver it is a tale, told by an idiot, > nweaver@icsi.berkeley.edu full of sound and fury, > 510-666-2903 .signifying nothing > PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc > > > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass From hallam@gmail.com Sun Dec 8 10:59:50 2013 Return-Path: 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 AF17E1AE06D for ; Sun, 8 Dec 2013 10:59:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 txa9GZLj_Isn for ; Sun, 8 Dec 2013 10:59:48 -0800 (PST) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 3766B1AE03E for ; Sun, 8 Dec 2013 10:59:48 -0800 (PST) Received: by mail-wg0-f47.google.com with SMTP id n12so2518761wgh.26 for ; Sun, 08 Dec 2013 10:59:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:in-reply-to:mime-version:from:date:message-id:subject:to :cc:content-type; bh=cXpep/EMTJ2WxlWT1AFVld7Ke2Tx2R1dTtOOieHbZAs=; b=fUq8qk9t4W6KjDcPYPKLPpREYAfgYmK/yEMsGCf/UUjir2JUurilJMlOuUtJ0pMHmt X3nLh+eTLlEIy+ub5kwTlnfPHPY5qSZEywEnpMbzpkdHl43JtnY6QWdGKZu4BdMOogfB Eb+zKqSsBVS9GKnDt7SJKgkWSZNphyFybWR7S4XRoEAxyZFAi2FifNInpdmoS32zoSMx dupGQhPKXQ2ndzxmGaMLwUvcVvIQNl1ma6mklTIo187qQfzi+1Ckzz+P2SxLt6WWvuGd vGonAvJxcJZJjjA/jb7++VVCYG2dWPf4bjLkiRGPHLV70RuzyYSCvf0y6/ZKEXxSs1i2 3aLA== X-Received: by 10.180.13.74 with SMTP id f10mr10863513wic.34.1386529183266; Sun, 08 Dec 2013 10:59:43 -0800 (PST) References: <52A3AF02.8050103@perens.com> <52A3B892.3040108@perens.com> In-Reply-To: <52A3B892.3040108@perens.com> Mime-Version: 1.0 (1.0) From: Phillip Hallam-Baker Date: Sun, 8 Dec 2013 13:59:41 -0500 Message-ID: <211458524102891707@unknownmsgid> To: Bruce Perens Content-Type: multipart/alternative; boundary=001a11c24a94707eeb04ed0a7b0f Cc: perpass Subject: Re: [perpass] Fwd: Re: 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Dec 2013 18:59:50 -0000 --001a11c24a94707eeb04ed0a7b0f Content-Type: text/plain; charset=ISO-8859-1 Given how long it took to seethe end of http/0.9, it will be decades before http 2.0 is everywhere And some of the design choices might mean it does not happen at all. It could be another ipv5 or like http NG. That is the choices that must be made, not the decisions. The solution set might be null Don't assume success is automatic, that is likely to cause failure. Sent from my difference engine On Dec 7, 2013, at 7:08 PM, Bruce Perens wrote: -------- Original Message -------- Subject: Re: [perpass] perens-perpass-appropriate-response-01 Date: Sat, 07 Dec 2013 15:28:02 -0800 From: Bruce Perens To: Jacob Appelbaum On 12/07/2013 02:11 AM, Jacob Appelbaum wrote: You're not being forced to do anything, are you? You could use HTTP 1.1 forever, right? Once there's an HTTP 2.0, broad support for HTTP 1.1 on the web will not survive. What I don't understand is why all of these people you've given me a long lecture about, including yourself, will necessarily be oppressed if they have a choice, and will not be oppressed if they have no choice. And why I have so little sympathy for them, according to you, simply because I would like to offer them a choice. Thanks Bruce _______________________________________________ perpass mailing list perpass@ietf.org https://www.ietf.org/mailman/listinfo/perpass --001a11c24a94707eeb04ed0a7b0f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Given how long it took to seethe e= nd of http/0.9, it will be decades before http 2.0 is everywhere
=
And some of the design choices might mean it does not happen at all. I= t could be another ipv5 or like http NG. That is the choices that must be m= ade, not the decisions. The solution set might be null

Don't assume success is automatic, that is likely to cause failure= .

Sent from my difference engine

On Dec 7, 2013, at 7:08 PM, Bruce Perens <bruce@perens.com> wrote:

=20 =20 =20 =20


-------- Original Message --------
Subject: Re: [perpass] perens-perpass-appropriate-response-01
Date: Sat, 07 Dec 2013 15:28:02 -0800
From: Bruce Perens <bruce@perens.com>
To: Jacob Appelbaum <jacob@appelbaum.net>


On 12/07/2013 02:11 AM, Jacob Appelbaum wrote:
You're not being forced to do anything, are you? You could use HTTP 1.1 forever, right?
Once there's an HTTP 2.0, broad support for HTTP 1.1 on the web will not survive.

What I don't understand is why all of these people you've giv= en me a long lecture about, including yourself, will necessarily be oppressed if they have a choice, and will not be oppressed if they have no choice. And why I have so little sympathy for them, according to you, simply because I would like to offer them a choice.

=A0=A0=A0 Thanks

=A0=A0=A0 Bruce


=20
___________________= ____________________________
perpass mailing listperpass@ietf.org
https://www= .ietf.org/mailman/listinfo/perpass
= --001a11c24a94707eeb04ed0a7b0f-- From wilton@isoc.org Sun Dec 8 11:55:34 2013 Return-Path: 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 6969D1AE0C3 for ; Sun, 8 Dec 2013 11:55:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 z1s2fgbc7w43 for ; Sun, 8 Dec 2013 11:55:32 -0800 (PST) Received: from smtp118.iad3a.emailsrvr.com (smtp118.iad3a.emailsrvr.com [173.203.187.118]) by ietfa.amsl.com (Postfix) with ESMTP id F18391AE091 for ; Sun, 8 Dec 2013 11:55:31 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp23.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 6BB9528007E; Sun, 8 Dec 2013 14:55:27 -0500 (EST) X-Virus-Scanned: OK Received: by smtp23.relay.iad3a.emailsrvr.com (Authenticated sender: wilton-AT-isoc.org) with ESMTPSA id 043AF280078; Sun, 8 Dec 2013 14:55:26 -0500 (EST) References: <529E8494.7000806@perens.com> <20131204111309.GB11727@nic.fr> <529F61D8.6030105@perens.com> <20131204171207.GC19914@thunk.org> <529F63C0.3040804@perens.com> <529F88AC.3090904@appelbaum.net> <529F90A0.8000706@perens.com> <529F9205.30906@appelbaum.net> <529F98C0.9090808@perens.com> <529F9F14.8050805@appelbaum.net> <529FB61A.7090604@perens.com> <529FBEF9.7030205@appelbaum.net> <529FC347.3080806@perens.com> <52A15835.2070901@cis-india.org> <52A21B80.8070005@mykolab.com> <52A21D1C.8020000@perens.com> <52A2235A.2030801@perens.com> <240A2D86-C352-4954-BE4E-6313BA25994E@icsi.berkeley.edu> <52A2CE6A.30408@perens.com> <52A31F1D.7040509@cs.tcd.ie> <5D026682-5457-4F00-B139-58D8D718BB0A@icsi.berkeley.edu> In-Reply-To: <5D026682-5457-4F00-B139-58D8D718BB0A@icsi.berkeley.edu> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <454F08BE-5C79-408B-B356-6D895C9B1CC3@isoc.org> X-Mailer: iPad Mail (9B206) From: Robin Wilton Date: Sun, 8 Dec 2013 19:59:31 +0000 To: Nicholas Weaver Cc: "perpass@ietf.org" , Stephen Farrell 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Dec 2013 19:55:34 -0000 Nick,=20 I agree that there is a cost threshold for signature/MAC. It is something I u= ncovered in my PKI research: for PKI-enabled micropayments it is, arguably, n= ot worth signing the public key involved, if the number of disputed payments= is at normal levels... because normal levels, for most micropayment applica= tions, are low. It's more cost-effective to simply refund the tiny minority o= f disputed payments. That said, I think what we learned from IETF88 was that the strategy most li= kely to succeed against pervasive, unaccountable state interception is to ma= ke it more costly for the net reception to take place. (Essentially, forcing= accountability by forcing expenditure).=20 We have also seen evidence of large-scale MITM attacks, made easier by the w= eakness of integrity mechanisms in session establishment and key exchange. If that's the new context in which we find ourselves architecting systems, t= hen it may change the calculation that says "Integrity checks aren't worth p= aying for". NB - I am not saying that this necessarily justifies breaking all web traffi= c down to frames and applying MACs/DSigs at the element level; all I'm sayin= g is that the events of 2013 change the cost structure of integrity mechanis= ms, and we should adjust our architectural principles accordingly. Yrs., Robin Robin Wilton Technical Outreach Director - Identity and Privacy On 7 Dec 2013, at 15:48, Nicholas Weaver wrote: be=20 >=20 > On Dec 7, 2013, at 5:14 AM, Stephen Farrell wr= ote: >> 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 >> much. >=20 > We do actually have a system for data integrity without confidentiality. I= ts called DNSSEC. And the lack of confidentiality is a deliberate design de= cision due to its focus around offline signature generation and a structure c= omposed of various proven untrustworthy intermediaries. >=20 > So if you really actually WANTED data integrity on elements (and it has to= be all HTML, CSS, JS, flash, etc.. since all of those are directly executab= le content, so you might as well do ALL elements. After all, there have bee= n image rendering vulnerabilities too..), how about storing them and just fe= tching them through DNSSEC... >=20 > Indeed, thats a very silly and downright stupid idea. Nobody will do it. >=20 >=20 >=20 > Why? Because our model for HTTP is that content is often generated dynami= cally, so each dynamic element would need to be signed dynamically, so inste= ad our focus on HTTP is on channel security: create a secure channel and the= n keep using it. >=20 > There is effectively zero call for "MAC w/o ENCRYPT", which is whats neces= sary to answer "authentication problem rather than a confidentiality one." i= n terms of channel security. We don't do it. Why? Because its stupid. Y= ou'd still need to go through all the public key certificate efforts, key ex= change, server side computation, and all the other crap needed for a TLS han= dshake or similar to generate a MAC key. Adding in encryption is a practica= l no-op by this point. >=20 >=20 > And without doing a key exchange for a MAC and instead doing signatures fo= r integrity, signature verification happens at the END of a communication. S= ignatures are expensive to generate and validate (and verification w/o a key= exchange requires a lot more of them anyway), so you'd hash all the data an= d then sign/verify, so you coludn't take advantage of incremental rendering,= lest you render an iframe at the start that shouldn't be there. >=20 > Yes, you could use some block-hash structure where at the start you get a s= ignature over a bunch of block hashes, but that instead requires that the se= nder know in advance the WHOLE message. Its a silly thought, since the serv= er in many cases does NOT know what the full .html document will be when it s= tarts sending it over a TLS channel. >=20 >=20 > So the idea of "authentication problem rather than a confidentiality one" i= s a red herring: We have a solution that solves the authentication problem f= or HTTP. Its called TLS. We MUST use it everywhere, if only to protect US c= itizens from the French and Chinese, and Russians, and Brazilians, and Israe= lis... >=20 > And a solution which solves authentication w/o confidentiality may be sill= y, but if you want it anyway, the best solution that gives authentication w/= o confidentiality for HTTP is, indeed, a browser button that says: >=20 > "F-confidentiality: broadcast my encryption key (but not the MAC key) in t= he clear if the server consents". >=20 > -- > Nicholas Weaver it is a tale, told by an idiot, > nweaver@icsi.berkeley.edu full of sound and fury, > 510-666-2903 .signifying nothing > PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc >=20 >=20 > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass From wilton@isoc.org Sun Dec 8 12:13:12 2013 Return-Path: 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 819CF1AE049 for ; Sun, 8 Dec 2013 12:13:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 KZG1suvKN5gW for ; Sun, 8 Dec 2013 12:13:11 -0800 (PST) Received: from smtp94.iad3a.emailsrvr.com (smtp94.iad3a.emailsrvr.com [173.203.187.94]) by ietfa.amsl.com (Postfix) with ESMTP id D4B7B1AE009 for ; Sun, 8 Dec 2013 12:13:10 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp4.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 573DB260097; Sun, 8 Dec 2013 15:13:06 -0500 (EST) X-Virus-Scanned: OK Received: by smtp4.relay.iad3a.emailsrvr.com (Authenticated sender: wilton-AT-isoc.org) with ESMTPSA id C7276260073; Sun, 8 Dec 2013 15:13:03 -0500 (EST) References: <529E8494.7000806@perens.com> <20131204111309.GB11727@nic.fr> <529F61D8.6030105@perens.com> <20131204171207.GC19914@thunk.org> <529F63C0.3040804@perens.com> <529F88AC.3090904@appelbaum.net> <529F90A0.8000706@perens.com> <529F9205.30906@appelbaum.net> <529F98C0.9090808@perens.com> <529F9F14.8050805@appelbaum.net> <529FB61A.7090604@perens.com> <529FBEF9.7030205@appelbaum.net> <529FC347.3080806@perens.com> <52A15835.2070901@cis-india.org> <52A21B80.8070005@mykolab.com> <52A21D1C.8020000@perens.com> <52A2235A.2030801@perens.com> In-Reply-To: <52A2235A.2030801@perens.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <88AF8C70-1FCE-4A79-A716-B32A4786D152@isoc.org> X-Mailer: iPad Mail (9B206) From: Robin Wilton Date: Sun, 8 Dec 2013 20:16:32 +0000 To: Bruce Perens 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Dec 2013 20:13:12 -0000 The point about the "nothing to hide" fallacy, as others better qualified th= an me have pointed out, is not that people might not care if their static im= ages, CSS and JavaScript are loaded in clear, but the fact that in a "nothin= g to hide, nothing to fear" society, the individual does not get to choose w= hat is "acceptable" and what leads to chilling effects, curtailment of liber= ties, or even punitive sanctions. Daniel Solove has written persuasively about the pernicious harms of NTHNTF,= but he is "just" a trailblazer. We should never lose sight of the fact that= we are in the infancy of understanding the effects of Total Informational A= wareness on social norms, social behaviour, and social outcomes. I think we s= hould have the level-headedness to acknowledge that, when it has occurred in= the past, in pre-digital societies, massive informational awareness has, mo= re often than not, been abused, with harmful social consequences. R Robin Wilton Technical Outreach Director - Identity and Privacy On 6 Dec 2013, at 19:19, Bruce Perens wrote: > On 12/06/2013 10:58 AM, Nicholas Weaver wrote: >> Include a checkbox in the browser saying "Fuck it all, show my data to th= e world" which broadcasts the session key in the clear. > I know you intended this to be sarcastic, but opting out of the concealmen= t society does not mean that the user doesn't have the sense to conceal thin= gs when it is actually necessary, vs. when it is in their honest opinion an o= ff-the-scale response to the problem. >=20 > Punishing them by revealing their credit card numbers is not an appropriat= e response to their wanting to load static images, javascripts, and CSS in t= he clear. >=20 > Thanks >=20 > Bruce > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass From stephen.farrell@cs.tcd.ie Sun Dec 8 12:50:11 2013 Return-Path: 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 2F5F31AE0E2 for ; Sun, 8 Dec 2013 12:50:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UdA1Z2R6dnz3 for ; Sun, 8 Dec 2013 12:50:09 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 986271AE0E1 for ; Sun, 8 Dec 2013 12:50:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 83E17BE5B; Sun, 8 Dec 2013 20:50:04 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XFVAkLH2Q9X7; Sun, 8 Dec 2013 20:50:03 +0000 (GMT) Received: from [10.87.48.12] (unknown [86.44.71.228]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 5A537BE59; Sun, 8 Dec 2013 20:50:03 +0000 (GMT) Message-ID: <52A4DB71.8040806@cs.tcd.ie> Date: Sun, 08 Dec 2013 20:49:53 +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: Nicholas Weaver References: <52A3B32D.8000301@perens.com> <52A3B8A4.6000309@perens.com> <6FFED7BB-9272-4B94-AFC3-8689F3D3D325@icsi.berkeley.edu> In-Reply-To: <6FFED7BB-9272-4B94-AFC3-8689F3D3D325@icsi.berkeley.edu> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: perpass Subject: Re: [perpass] Fwd: Re: 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Dec 2013 20:50:11 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/08/2013 03:55 PM, Nicholas Weaver wrote: > > On Dec 7, 2013, at 4:09 PM, Bruce Perens wrote: >> Well, we do have some HTTP uses where encryption that hides the >> content won't be allowed, and thus authentication is important. >> >> We can't have encryption when we use HTTP over Amateur Radio in >> the US and many other countries. There is self-policing on ham >> frequencies that requires that people be able to copy other >> people's transmissions, and encryption defeats that. Obviously >> we don't put confidential data on those frequencies, that belongs >> on your cell phone. So, an authentication-only WiFi protocol is >> needed for Amateur Radio, and possibly an authentication-only >> version of TLS. > > NO!!!! > > The reason is downgrade attacks. A huge problem with the IPSec > standard is that NULL encryption was allowed in there, and also > known weak modes (single DES, 720b D/H etc). Its one of the > primary reasons why John Gilmore and therefore others feel the > IPSec process was sabotaged by the NSA. Really? That makes no sense to me. I've never heard any report of a use of IPsec that "accidentally" used a NULL or weak cipher. Have you? And Jeff Schiller I think convincingly repudiated claims that either the development process for IPsec or the output were saobtaged in any such way. I wasn't much involved myself but my impression was that we (the IETF security community) shot ourselves in the foot a bit via complexity and various refusals to prioritise progress and deployment over purity. We need to carefully balance security and pragmatism here IMO if our goal is to make for a more secure and privacy friendly Internet. I also think that throwing "sabotage" into the mix damages that discussion so should be avoided. S. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) iQEcBAEBAgAGBQJSpNtuAAoJEC88hzaAX42iZbIH/iT8GFrHPhn/+4fUq4Z1+fIb zZyMhypk0bV4LJaSRXvke2ExU0q8NuMp1OTqhw1baxGPpTR5WK6Xj0H6Dm5iRNKK 61ONTbeTnPwp8AW1CaRzT+3kX82D+vy1guz7pEP0iE4EQIKRtsFsIo/JaUtDIv1k +xvHdyjnUFcSPQQqh4T969IpB0WpGT1Iw9RNGjqrEws9CqakMyVw8k2BiT7GtQOt X71Z9DWdjZkohEEDvzZGj9m0NyeZz//r1qNDgKTWCPM6YLtHxhjyzyI7Qv38Lcyo SV/5+OOSbjpenQp8rStTFvfZVeFzXYe5vr5l+vZJARfJLUv+d3HdVK/jYT0U2gU= =m8H+ -----END PGP SIGNATURE----- From hannes.tschofenig@gmx.net Sun Dec 8 14:00:32 2013 Return-Path: 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 569E31AE121 for ; Sun, 8 Dec 2013 14:00:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 Dc3vfvOa2UcJ for ; Sun, 8 Dec 2013 14:00:30 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id 4A1F81AE120 for ; Sun, 8 Dec 2013 14:00:30 -0800 (PST) Received: from [192.168.10.137] ([2.102.217.110]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MU0U9-1VykWn0J8b-00QkyU for ; Sun, 08 Dec 2013 23:00:24 +0100 Message-ID: <52A4EBF3.4000001@gmx.net> Date: Sun, 08 Dec 2013 22:00:19 +0000 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Stephen Farrell , Nicholas Weaver References: <52A3B32D.8000301@perens.com> <52A3B8A4.6000309@perens.com> <6FFED7BB-9272-4B94-AFC3-8689F3D3D325@icsi.berkeley.edu> <52A4DB71.8040806@cs.tcd.ie> In-Reply-To: <52A4DB71.8040806@cs.tcd.ie> Content-Type: multipart/alternative; boundary="------------060909000101040809060802" X-Provags-ID: V03:K0:+CHYQpTXgAnsIk1kWY35/3IIrSKYSbP2BWxWdEyv1Dw6lxkMlih JPfJGVpFXIgZi/oZzyrhIk1wvHJag4Da/mTC0FJPWn36AyaDVPinYWQ1rvB1Wm5iBEp8Yzz rNeL0w0j18xRPC9uhn3bXaCGjqzAccMhQfv9bDxxVcIJyf5wZqeVnyWTnHTG78g2Sf4Evnj 2hn2do+i/N8qA54NoWXjA== Cc: perpass Subject: Re: [perpass] Fwd: Re: 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Dec 2013 22:00:32 -0000 This is a multi-part message in MIME format. --------------060909000101040809060802 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Stephen, Hi Nicholas, it would be interesting (as a history lesson) if someone could tell us why the group at that time decided to develop a NULL encryption mechanism. Stephen Kent (co-author of RFC 2410) might remember. I have no heard In context of our discussion on this list the answer will give us a lot of guidance for the future. Even 2 years ago I had lots of people arguing in the OAuth working group that authentication and integrity protection is sufficient and that we do not need confidentiality protection. So, I wouldn't be surprised if the same argument showed up 10 years earlier. We have to look forward, with our knowledge of the changed threat landscape, so that we make better design choices in ongoing and future IETF work. Ciao Hannes On 12/08/2013 08:49 PM, Stephen Farrell wrote: > > > On 12/08/2013 03:55 PM, Nicholas Weaver wrote: > > > On Dec 7, 2013, at 4:09 PM, Bruce Perens wrote: > >> Well, we do have some HTTP uses where encryption that hides the > >> content won't be allowed, and thus authentication is important. > >> > >> We can't have encryption when we use HTTP over Amateur Radio in > >> the US and many other countries. There is self-policing on ham > >> frequencies that requires that people be able to copy other > >> people's transmissions, and encryption defeats that. Obviously > >> we don't put confidential data on those frequencies, that belongs > >> on your cell phone. So, an authentication-only WiFi protocol is > >> needed for Amateur Radio, and possibly an authentication-only > >> version of TLS. > > > NO!!!! > > > The reason is downgrade attacks. A huge problem with the IPSec > > standard is that NULL encryption was allowed in there, and also > > known weak modes (single DES, 720b D/H etc). Its one of the > > primary reasons why John Gilmore and therefore others feel the > > IPSec process was sabotaged by the NSA. > > Really? That makes no sense to me. I've never heard any report of a > use of IPsec that "accidentally" used a NULL or weak cipher. Have > you? And Jeff Schiller I think convincingly repudiated claims that > either the development process for IPsec or the output were > saobtaged in any such way. > > I wasn't much involved myself but my impression was that we (the > IETF security community) shot ourselves in the foot a bit via > complexity and various refusals to prioritise progress and > deployment over purity. > > We need to carefully balance security and pragmatism here IMO if > our goal is to make for a more secure and privacy friendly Internet. > > I also think that throwing "sabotage" into the mix damages that > discussion so should be avoided. > > S. > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass --------------060909000101040809060802 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Stephen, Hi Nicholas,

it would be interesting (as a history lesson) if someone could tell us why the group at that time decided to develop a NULL encryption mechanism. Stephen Kent (co-author of RFC 2410) might remember. I have no heard

In context of our discussion on this list the answer will give us a lot of guidance for the future.  Even 2 years ago I had lots of people arguing in the OAuth working group that authentication and integrity protection is sufficient and that we do not need confidentiality protection. So, I wouldn't be surprised if the same argument showed up 10 years earlier.

We have to look forward, with our knowledge of the changed threat landscape, so that we make better design choices in ongoing and future IETF work.

Ciao
Hannes

 
On 12/08/2013 08:49 PM, Stephen Farrell wrote:


On 12/08/2013 03:55 PM, Nicholas Weaver wrote:

> On Dec 7, 2013, at 4:09 PM, Bruce Perens <bruce@perens.com> wrote:
>> Well, we do have some HTTP uses where encryption that hides the
>> content won't be allowed, and thus authentication is important.
>>
>> We can't have encryption when we use HTTP over Amateur Radio in
>> the US and many other countries. There is self-policing on ham
>> frequencies that requires that people be able to copy other
>> people's transmissions, and encryption defeats that. Obviously
>> we don't put confidential data on those frequencies, that belongs
>> on your cell phone. So, an authentication-only WiFi protocol is
>> needed for Amateur Radio, and possibly an authentication-only
>> version of TLS.

> NO!!!!

> The reason is downgrade attacks.  A huge problem with the IPSec
> standard is that NULL encryption was allowed in there, and also
> known weak modes (single DES, 720b D/H etc).  Its one of the
> primary reasons why John Gilmore and therefore others feel the
> IPSec process was sabotaged by the NSA.

Really? That makes no sense to me. I've never heard any report of a
use of IPsec that "accidentally" used a NULL or weak cipher. Have
you? And Jeff Schiller I think convincingly repudiated claims that
either the development process for IPsec or the output were
saobtaged in any such way.

I wasn't much involved myself but my impression was that we (the
IETF security community) shot ourselves in the foot a bit via
complexity and various refusals to prioritise progress and
deployment over purity.

We need to carefully balance security and pragmatism here IMO if
our goal is to make for a more secure and privacy friendly Internet.

I also think that throwing "sabotage" into the mix damages that
discussion so should be avoided.

S.
> _______________________________________________
> perpass mailing list
> perpass@ietf.org
> https://www.ietf.org/mailman/listinfo/perpass


--------------060909000101040809060802-- From atlunde@panix.com Sun Dec 8 16:24:21 2013 Return-Path: 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 B24661AE0DB for ; Sun, 8 Dec 2013 16:24:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 FWL8z5AQV5Eb for ; Sun, 8 Dec 2013 16:24:20 -0800 (PST) Received: from mailbackend.panix.com (mailbackend.panix.com [166.84.1.89]) by ietfa.amsl.com (Postfix) with ESMTP id 02D581AE0A9 for ; Sun, 8 Dec 2013 16:24:19 -0800 (PST) Received: from [192.168.15.5] (unknown [50.9.9.201]) by mailbackend.panix.com (Postfix) with ESMTP id C88F5352E2; Sun, 8 Dec 2013 19:24:14 -0500 (EST) Message-ID: <52A50DAC.7040601@panix.com> Date: Sun, 08 Dec 2013 18:24:12 -0600 From: Albert Lunde User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: "perpass@ietf.org" References: <529E8494.7000806@perens.com> <20131204111309.GB11727@nic.fr> <529F61D8.6030105@perens.com> <20131204171207.GC19914@thunk.org> <529F63C0.3040804@perens.com> <529F88AC.3090904@appelbaum.net> <529F90A0.8000706@perens.com> <529F9205.30906@appelbaum.net> <529F98C0.9090808@perens.com> <529F9F14.8050805@appelbaum.net> <529FB61A.7090604@perens.com> <529FBEF9.7030205@appelbaum.net> <529FC347.3080806@perens.com> <52A15835.2070901@cis-india.org> <52A21B80.8070005@mykolab.com> <52A21D1C.8020000@perens.com> <52A2235A.2030801@perens.com> <240A2D86-C352-4954-BE4E-6313BA25994E@icsi.berkeley.edu> <52A2CE6A.30408@perens.com> <52A31F1D.7040509@cs.tcd.ie> <5D026682-5457-4F00-B139-58D8D718BB0A@icsi.berkeley.edu> <454F08BE-5C79-408B-B356-6D895C9B1CC3@isoc.org> In-Reply-To: <454F08BE-5C79-408B-B356-6D895C9B1CC3@isoc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 00:24:21 -0000 On 12/8/2013 1:59 PM, Robin Wilton wrote: > Nick, > > > I agree that there is a cost threshold for signature/MAC. It is > something I uncovered in my PKI research: for PKI-enabled micropayments > it is, arguably, not worth signing the public key involved, if the > number of disputed payments is at normal levels... because normal > levels, for most micropayment applications, are low. It's more > cost-effective to simply refund the tiny minority of disputed payments. It seems like a threat model that assumes the sole risk is disputed payments "at the normal rate" is broken in the presence of automated attacks. I don't think the NSA is the only bad actor, in the short term, for-profit criminal groups seem more likely to do active or tailored attacks. This can result in bursts of fraud and/or malware affecting particular clients or sites disproportionately. From hallam@gmail.com Sun Dec 8 17:53:01 2013 Return-Path: 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 3D9BB1AE0EE for ; Sun, 8 Dec 2013 17:53:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_PASS=-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 dHeCQ9OtuHcO for ; Sun, 8 Dec 2013 17:52:59 -0800 (PST) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) by ietfa.amsl.com (Postfix) with ESMTP id D49E31AE0E3 for ; Sun, 8 Dec 2013 17:52:58 -0800 (PST) Received: by mail-wi0-f177.google.com with SMTP id cc10so3038636wib.4 for ; Sun, 08 Dec 2013 17:52:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=6+SFYUxtw4375k65Ll44UAq3PMKHdmXkxzDLQIwqa9A=; b=YOP4yRWuR96yM/cJHk1yDA0a9/e2sY1gBYQI8NSAnHiGZtMPfnTwRpcmtt87Xzmawr pm9E+AhslWKaXydnVmefKK+y4VqeCRdwZ+Vrj4SmEi9L/JVDtmnbzWILokoU6jo8neap xD2oVQlynsmWE+CcT8JjpFLIlylwLcb3CS+QV2JUPxl0Qf3lO6bXwMGB7citWGJVcX1B OGKrgZMSg/cJfD0bsR+dmWeoCNUt8Maq+lB3t2shkHIZAxboRXnfs7bmjO0CQfMRowy8 n76ujo3K4nrAd6MYhGX6Kp+Ts199ocPj1Le7A2NnSPd7QyPFQEklPzNi4XrW5ZMZ5h2A svRw== MIME-Version: 1.0 X-Received: by 10.180.108.97 with SMTP id hj1mr11644945wib.59.1386553973598; Sun, 08 Dec 2013 17:52:53 -0800 (PST) Received: by 10.194.243.136 with HTTP; Sun, 8 Dec 2013 17:52:53 -0800 (PST) Date: Sun, 8 Dec 2013 20:52:53 -0500 Message-ID: From: Phillip Hallam-Baker To: Hannes Tschofenig Content-Type: multipart/alternative; boundary=e89a8f3bafef0ef2f004ed104179 Cc: perpass , Nicholas Weaver , Stephen Farrell Subject: [perpass] NULL Cipher RFC 2410 to HISTORIC ??? 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 01:53:01 -0000 --e89a8f3bafef0ef2f004ed104179 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Dec 8, 2013 at 5:00 PM, Hannes Tschofenig wrote: > Hi Stephen, Hi Nicholas, > > it would be interesting (as a history lesson) if someone could tell us why > the group at that time decided to develop a NULL encryption mechanism. > Stephen Kent (co-author of RFC 2410) might remember. I have no heard > It was for testing and it all happened long before any of the evidence of the NSA peddling bongoed crypto suggests that it was going on. I think it highly unlikely that anything of the sort was going on before 9/11 and my sources claim that the change came much later, if it happened at all. I really don't think that any of the people involved in IETF process have had a hand in knowingly peddling bongoed crypto either. But as I have been making plain in another forum, the slides openly bragging about such an operation have had a serious cost in terms of erosion of trust. I think any interference would have been 'action at a distance'. Rather than come here and make the case for protecting some hole that was going to be used to propagate Flame, I would expect the NSA people running the DoD CA would call up their contacts in IETF space and make up some story about their operational difficulties caused by still running the old Netscape CA that hasn't been maintained for a decade now or some such hokum. I can't see how that sort of cover story would work for peddling a NULL cipher. There are some vulnerabilities I think can be laid at their door but not that one. We did that one to ourselves. IPSEC is sufficiently complicated that interop is a non trivial problem. Or at least the people who implemented it found it to be so. Some people tried to make the same suggestion for S/MIME (and people might remember my reaction). Having a NULL cipher for interop testing was not an unfounded proposal but it was certainly never one I supported. Remember that IPSEC has always supported an 'authentication only' mode. So turning on encryption with a null cipher was not an obvious difference. In fact it would probably have made sense to have killed the integrity only option at the start and just had a null cipher. Perhaps we should write a draft and move it to HISTORIC, just to avoid any confusion. > In context of our discussion on this list the answer will give us a lot of > guidance for the future. Even 2 years ago I had lots of people arguing in > the OAuth working group that authentication and integrity protection is > sufficient and that we do not need confidentiality protection. So, I > wouldn't be surprised if the same argument showed up 10 years earlier. > That is a different argument and maybe there is a case to be made for relying on HTTPS. I don't like that approach, in fact I super-encrypt within HTTPS quite often and always super-authenticate end to end in my Web Services. -- Website: http://hallambaker.com/ --e89a8f3bafef0ef2f004ed104179 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On S= un, Dec 8, 2013 at 5:00 PM, Hannes Tschofenig <hannes.tschofenig@g= mx.net> wrote:
=20 =20 =20
Hi Stephen, Hi Nicholas,

it would be interesting (as a history lesson) if someone could tell us why the group at that time decided to develop a NULL encryption mechanism. Stephen Kent (co-author of RFC 2410) might remember. I have no heard

It was for tes= ting and it all happened long before any of the evidence of the NSA peddlin= g bongoed crypto suggests that it was going on. I think it highly unlikely = that anything of the sort was going on before 9/11 and my sources claim tha= t the change came much later, if it happened at all.

I really don't think that any of the people involve= d in IETF process have had a hand in knowingly peddling bongoed crypto eith= er. But as I have been making plain in another forum, the slides openly bra= gging about such an operation have had a serious cost in terms of erosion o= f trust.

I think any interference would have been 'action at= a distance'. Rather than come here and make the case for protecting so= me hole that was going to be used to propagate Flame, I would expect the NS= A people running the DoD CA would call up their contacts in IETF space and = make up some story about their operational difficulties caused by still run= ning the old Netscape CA that hasn't been maintained for a decade now o= r some such hokum.

I can't see how that sort of cover story would work= for peddling a NULL cipher. There are some vulnerabilities I think can be = laid at their door but not that one. We did that one to ourselves.


IPSEC is sufficiently complicated that i= nterop is a non trivial problem. Or at least the people who implemented it = found it to be so. Some people tried to make the same suggestion for S/MIME= (and people might remember my reaction). Having a NULL cipher for interop = testing was not an unfounded proposal but it was certainly never one I supp= orted.

Remember that IPSEC has always supported an 'authen= tication only' mode. So turning on encryption with a null cipher was no= t an obvious difference. In fact it would probably have made sense to have = killed the integrity only option at the start and just had a null cipher.


Perhaps we should write a draft and move= it to HISTORIC, just to avoid any confusion.

= =A0
In context of our discussion on this list the answer will give us a lot of guidance for the future.=A0 Even 2 years ago I had lots of people arguing in the OAuth working group that authentication and integrity protection is sufficient and that we do not need confidentiality protection. So, I wouldn't be surprised if the same argument showed up 10 years earlier.

That is a different argument and maybe there is a case to be made = for relying on HTTPS. I don't like that approach, in fact I super-encry= pt within HTTPS quite often and always super-authenticate end to end in my = Web Services.




--
We= bsite: http://hallambaker.com/
--e89a8f3bafef0ef2f004ed104179-- From mundy@tislabs.com Sun Dec 8 20:14:31 2013 Return-Path: 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 5D1951A1F7C for ; Sun, 8 Dec 2013 20:14:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 1Yv_bLs0-5lV for ; Sun, 8 Dec 2013 20:14:29 -0800 (PST) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) by ietfa.amsl.com (Postfix) with ESMTP id 401421AC499 for ; Sun, 8 Dec 2013 20:14:29 -0800 (PST) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 86E2E28B0017 for ; Sun, 8 Dec 2013 23:14:24 -0500 (EST) Received: from spiff.tislabs.com (nova.tislabs.com [10.66.1.77]) by nova.tislabs.com (Postfix) with ESMTP id 7FD3A1F8034 for ; Sun, 8 Dec 2013 23:14:24 -0500 (EST) Received: from ubvm (unknown [10.66.1.77]) by spiff.tislabs.com (Postfix) with ESMTPS id 435645BBBD68; Thu, 5 Dec 2013 10:35:33 -0500 (EST) Received: from [127.0.0.1] (unknown [172.16.115.10]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mundy) by ubvm (Postfix) with ESMTPSA id 0076F27F007; Thu, 5 Dec 2013 10:35:31 -0500 (EST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Russ Mundy In-Reply-To: <52A050E7.8010405@uni-due.de> Date: Thu, 5 Dec 2013 10:35:30 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <52A050E7.8010405@uni-due.de> To: perpass@ietf.org X-Mailer: Apple Mail (2.1510) Cc: Russ Mundy , =?iso-8859-1?Q?Matth=E4us_Wander?= Subject: Re: [perpass] A reminder, the Network is the Enemy... 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 04:14:31 -0000 On Dec 5, 2013, at 5:09 AM, Matth=E4us Wander = wrote: > * Nicholas Weaver [2013-12-02 17:56]: >> Actually spoofing DNSSEC replies even with knowledge of the root key = is going to be difficult... >=20 > If we assume the attacker can get the private root KSK from an = US-based > corp, then we should also assume they can get the private root ZSK = from > another US-based corp. As the owner of the root ZSK also owns the keys > for .com, the attack becomes much easier. If we (as the IETF) make an assumption that the DNSSEC private key(s) = are "available" to some "unauthorized entity" (govt or otherwise) = because a significant part of a particular operation is located in a = particular geographic region then we need to also make a similar = assumption for any/all Certification Authorities' root private key(s) = since the underlying cryptographic technology widely used by TLS is = basically the same. The DigiNotar attack, though not geographically = related, clearly illustrates that very bad things can happen when an = "unauthorized entity" is able to have access to and use of root private = keys for a CA. I've seen some references on this list saying (essentially) that it is a = valid assumption that an "attacker" ("unauthorized entity" might be a = better term) can get or already has the DNS root (& maybe .com) private = key. Although I do not believe that this is a valid assumption, I do = assert that if we (as the IETF) decide to make such an assumption = relative to DNS/DNSSEC then we must make the same assumptions about = "unauthorized entities" being able to access private root key(s) for = any/all CAs. I'm not sure how the IETF would somehow factor = geopolitical boundaries into defining protocol assumptions, I suspect = that any useful results would probably take longer than it's taken to = design, redesign, redesign and begin deployment of DNSSEC :-). OTOH, if there is real interest and need to change and/or enhance the = security operations &/or protocols for the DNS or CA realms, having = concrete proposals (such as = draft-grothoff-iesg-special-use-p2p-names-00.txt) is much more useful = than trying to reach agreement on assumptions like the above (& other = earlier email assertions). Russ >=20 > Regards, > Matt >=20 > --=20 > Universit=E4t Duisburg-Essen > Verteilte Systeme > Bismarckstr. 90 / BC 316 > 47057 Duisburg >=20 > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass From merike@doubleshotsecurity.com Sun Dec 8 20:20:09 2013 Return-Path: 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 6791D1AE195 for ; Sun, 8 Dec 2013 20:20:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 8h5jNsPco-NO for ; Sun, 8 Dec 2013 20:20:05 -0800 (PST) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) by ietfa.amsl.com (Postfix) with ESMTP id 8DAC51AE144 for ; Sun, 8 Dec 2013 20:20:05 -0800 (PST) Received: from [192.168.0.12] ([216.160.75.206]) (authenticated bits=0) by d.mail.sonic.net (8.14.4/8.14.4) with ESMTP id rB94JJMp000338 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 8 Dec 2013 20:19:50 -0800 Content-Type: multipart/signed; boundary="Apple-Mail=_6D8EFA92-DC0B-4176-8F5A-398D7F92B3D3"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Merike Kaeo In-Reply-To: Date: Sun, 8 Dec 2013 20:19:19 -0800 Message-Id: <0FE7905C-950F-4030-8A47-37C523FB497A@doubleshotsecurity.com> References: To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1510) X-Sonic-ID: C;yJ3lEolg4xGamduF53gOpw== M;Uss5JYlg4xGamduF53gOpw== Cc: perpass , Hannes Tschofenig , Nicholas Weaver , Stephen Farrell Subject: Re: [perpass] NULL Cipher RFC 2410 to HISTORIC ??? 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 04:20:09 -0000 --Apple-Mail=_6D8EFA92-DC0B-4176-8F5A-398D7F92B3D3 Content-Type: multipart/alternative; boundary="Apple-Mail=_BCBE3DC7-A0EB-488F-A4D2-B99F0F223491" --Apple-Mail=_BCBE3DC7-A0EB-488F-A4D2-B99F0F223491 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Apologies in advance for top-posting. I keep meaning to get caught up = on this mailing list but never quite manage it. However, the IPsec NULL = is something that I see so misrepresented everywhere that I wanted to = chime in. It was to the best of my recollection developed after the 1998 = bake-off in Cary North Carolina (I was there) to enable integrity = protection thru NAT's. AH had issues transversing NAT devices which if = some others of you were around will remember was a technology that was = just taking off at that time. It was felt that using the NULL = encryption gave you at least integrity protection for the data even = though it did not protect the IP addresses (or anything else that was = part of the IP header that wasn't morphed in transit). However, for = anyone who is very well versed with IPsec, you will note that if a SPD = requires IP src and dst address as well as SPI, then the IP addresses = are implicitly protected. Note that the NAT traversal protocol had its = beginnings from that 1998 event as well. Also please remember that at the time IPsec was being developed there = were still global import/export restrictions relating to cryptographic = protection. Not just in the US mind you=85.I have a table in a book I = wrote in 1999 that actually listed a bunch of countries and the = restrictions at that time. There typically wasn't a restriction on key = length for cryptographically protected integrity protocols but there was = one for cryptographically protected confidentiality (i.e. encryption) = protocols. In the US it was 40 bit restriction on encryption. I = believe for some *limited* subset of countries this is still true for US = export controls on cryptography today. Anyhow=85just to get some of the history straight. And I speak as = someone who was at cisco at the time and did a lot of performance and = interoperability testing=85.and sat in the back of the room at *all* of = the IPsec meetings since the original BoF back in 1993/4 and discussed = issues in background (I don't write code=85.but can find bugs :)). And = as someone who spent well over a decade trying to get vendors and users = to understand issues of IPsec implementations and usability in a v6 = world [while an independent consultant]. I gave up 4 years ago. And FWIW, for IPsec the primary deployment issues are in implementation = terminology and interoperable defaults. I will gladly argue that point = over beers anytime.=20 - merike On Dec 8, 2013, at 5:52 PM, Phillip Hallam-Baker = wrote: > On Sun, Dec 8, 2013 at 5:00 PM, Hannes Tschofenig = wrote: > Hi Stephen, Hi Nicholas,=20 >=20 > it would be interesting (as a history lesson) if someone could tell us = why the group at that time decided to develop a NULL encryption = mechanism. Stephen Kent (co-author of RFC 2410) might remember. I have = no heard=20 >=20 > It was for testing and it all happened long before any of the evidence = of the NSA peddling bongoed crypto suggests that it was going on. I = think it highly unlikely that anything of the sort was going on before = 9/11 and my sources claim that the change came much later, if it = happened at all. >=20 > I really don't think that any of the people involved in IETF process = have had a hand in knowingly peddling bongoed crypto either. But as I = have been making plain in another forum, the slides openly bragging = about such an operation have had a serious cost in terms of erosion of = trust. >=20 > I think any interference would have been 'action at a distance'. = Rather than come here and make the case for protecting some hole that = was going to be used to propagate Flame, I would expect the NSA people = running the DoD CA would call up their contacts in IETF space and make = up some story about their operational difficulties caused by still = running the old Netscape CA that hasn't been maintained for a decade now = or some such hokum. >=20 > I can't see how that sort of cover story would work for peddling a = NULL cipher. There are some vulnerabilities I think can be laid at their = door but not that one. We did that one to ourselves. >=20 >=20 > IPSEC is sufficiently complicated that interop is a non trivial = problem. Or at least the people who implemented it found it to be so. = Some people tried to make the same suggestion for S/MIME (and people = might remember my reaction). Having a NULL cipher for interop testing = was not an unfounded proposal but it was certainly never one I = supported. >=20 > Remember that IPSEC has always supported an 'authentication only' = mode. So turning on encryption with a null cipher was not an obvious = difference. In fact it would probably have made sense to have killed the = integrity only option at the start and just had a null cipher. >=20 >=20 > Perhaps we should write a draft and move it to HISTORIC, just to avoid = any confusion. >=20 > =20 > In context of our discussion on this list the answer will give us a = lot of guidance for the future. Even 2 years ago I had lots of people = arguing in the OAuth working group that authentication and integrity = protection is sufficient and that we do not need confidentiality = protection. So, I wouldn't be surprised if the same argument showed up = 10 years earlier.=20 >=20 > That is a different argument and maybe there is a case to be made for = relying on HTTPS. I don't like that approach, in fact I super-encrypt = within HTTPS quite often and always super-authenticate end to end in my = Web Services. >=20 >=20 >=20 >=20 > --=20 > Website: http://hallambaker.com/ > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass --Apple-Mail=_BCBE3DC7-A0EB-488F-A4D2-B99F0F223491 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 hallam@gmail.com> = wrote:

On Sun, Dec 8, 2013 at 5:00 PM, Hannes Tschofenig = <hannes.tschofenig@gmx.net> wrote:
=20 =20 =20
Hi Stephen, Hi Nicholas,

it would be interesting (as a history lesson) if someone could tell us why the group at that time decided to develop a NULL encryption mechanism. Stephen Kent (co-author of RFC 2410) might remember. I have no heard

It was for = testing and it all happened long before any of the evidence of the NSA = peddling bongoed crypto suggests that it was going on. I think it highly = unlikely that anything of the sort was going on before 9/11 and my = sources claim that the change came much later, if it happened at = all.

I really don't think that any of the people involved = in IETF process have had a hand in knowingly peddling bongoed crypto = either. But as I have been making plain in another forum, the slides = openly bragging about such an operation have had a serious cost in terms = of erosion of trust.

I think any interference would have been 'action at = a distance'. Rather than come here and make the case for protecting some = hole that was going to be used to propagate Flame, I would expect the = NSA people running the DoD CA would call up their contacts in IETF space = and make up some story about their operational difficulties caused by = still running the old Netscape CA that hasn't been maintained for a = decade now or some such hokum.

I can't see how that sort of cover story would work = for peddling a NULL cipher. There are some vulnerabilities I think can = be laid at their door but not that one. We did that one to = ourselves.


IPSEC is sufficiently complicated = that interop is a non trivial problem. Or at least the people who = implemented it found it to be so. Some people tried to make the same = suggestion for S/MIME (and people might remember my reaction). Having a = NULL cipher for interop testing was not an unfounded proposal but it was = certainly never one I supported.

Remember that IPSEC has always supported an = 'authentication only' mode. So turning on encryption with a null cipher = was not an obvious difference. In fact it would probably have made sense = to have killed the integrity only option at the start and just had a = null cipher.


Perhaps we should write a draft and = move it to HISTORIC, just to avoid any = confusion.

 
In context of our discussion on this list the answer will give us a lot of guidance for the future.  Even 2 years ago I had lots of people arguing in the OAuth working group that authentication and integrity protection is sufficient and that we do not need confidentiality protection. So, I wouldn't be surprised if the same argument showed up 10 years earlier. =

That is a different argument = and maybe there is a case to be made for relying on HTTPS. I don't like = that approach, in fact I super-encrypt within HTTPS quite often and = always super-authenticate end to end in my Web Services.




-- =
Website: http://hallambaker.com/
_______________________________________________
perpass mailing = list
perpass@ietf.org
https://www.ietf.= org/mailman/listinfo/perpass

= = --Apple-Mail=_BCBE3DC7-A0EB-488F-A4D2-B99F0F223491-- --Apple-Mail=_6D8EFA92-DC0B-4176-8F5A-398D7F92B3D3 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJSpUTHAAoJEA7gPO9LJuahmjEH/29Xu4wSwShj/yCJHCohD9Jx 0pudl/a8LmSsMDApIoNWQ69B08HwhYtV3j5buknw/AZ93QjnjWy4JzsSYIeWxMc7 7iLgg5BW1u/HPdkIEMZ9pA6fwid5elH0fSiD369fVWt1XfxuagFvtg7zd+yoL97k 7Ke04WS43knsfB28/dN46kzOw3V5c1lGCuRg4x1TyFHJizHxwSiL/1ZFSgY1bJOV J1rI3lHJIPdAVygljjDxgxI8kFjsIguyUtWXU68k9fhdTAPmrPgtsIv1V5gyY99N c82/h2mX1g5XPu0DrdEsxc7tQiMCaLH7r9/fUOFSrWU7JgjD1CKhd8Vj88Yz/DQ= =Fonh -----END PGP SIGNATURE----- --Apple-Mail=_6D8EFA92-DC0B-4176-8F5A-398D7F92B3D3-- From merike@doubleshotsecurity.com Sun Dec 8 21:12:36 2013 Return-Path: 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 BADF91ACCD8 for ; Sun, 8 Dec 2013 21:12:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 ORqffvcSU9Aa for ; Sun, 8 Dec 2013 21:12:33 -0800 (PST) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) by ietfa.amsl.com (Postfix) with ESMTP id C5D2F1AC4A3 for ; Sun, 8 Dec 2013 21:12:33 -0800 (PST) Received: from [192.168.0.12] ([216.160.75.206]) (authenticated bits=0) by c.mail.sonic.net (8.14.4/8.14.4) with ESMTP id rB95Bk6d005495 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 8 Dec 2013 21:12:17 -0800 Content-Type: multipart/signed; boundary="Apple-Mail=_B2C0A0E8-46FA-4054-951B-9ABDB3A02EEC"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Merike Kaeo In-Reply-To: <0FE7905C-950F-4030-8A47-37C523FB497A@doubleshotsecurity.com> Date: Sun, 8 Dec 2013 21:11:46 -0800 Message-Id: <95276F1E-2293-41F3-A6E7-7AEF4B22E811@doubleshotsecurity.com> References: <0FE7905C-950F-4030-8A47-37C523FB497A@doubleshotsecurity.com> To: perpass X-Mailer: Apple Mail (2.1510) X-Sonic-ID: C;/qiPZpBg4xGOsIk96sd3kQ== M;bhjpeJBg4xGOsIk96sd3kQ== Cc: Nicholas Weaver , Hannes Tschofenig , Phillip Hallam-Baker , Stephen Farrell Subject: Re: [perpass] NULL Cipher RFC 2410 to HISTORIC ??? 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 05:12:36 -0000 --Apple-Mail=_B2C0A0E8-46FA-4054-951B-9ABDB3A02EEC Content-Type: multipart/alternative; boundary="Apple-Mail=_1CF0819C-3DE4-4C4D-9A31-B16758F4EC18" --Apple-Mail=_1CF0819C-3DE4-4C4D-9A31-B16758F4EC18 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 And so I reply to myself but got curious and wanted evidence. I found = first references of AH/ESP and NULL in 1996 June IPsec archives. = http://www.sandelman.ottawa.on.ca/ipsec/1996/06/msg00030.html And while some interesting tidbits, the joggle for my memory banks was = that there was a bunch of discussion on where AH would be used with ESP = and whether ESP only would also be relevant. And while I couldn't find = exact reference to the March 1998 interop testing in North Carolina that = showed issues with AH not traversing NATs I am fairly certain that was = the case and why in practice people starting using ESP-Null. (it wasn't = in the notes for the follow-up IETF IPsec meeting). Someone else from that time may also be able to chime in. - merike On Dec 8, 2013, at 8:19 PM, Merike Kaeo = wrote: > Apologies in advance for top-posting. I keep meaning to get caught up = on this mailing list but never quite manage it. However, the IPsec NULL = is something that I see so misrepresented everywhere that I wanted to = chime in. It was to the best of my recollection developed after the 1998 = bake-off in Cary North Carolina (I was there) to enable integrity = protection thru NAT's. AH had issues transversing NAT devices which if = some others of you were around will remember was a technology that was = just taking off at that time. It was felt that using the NULL = encryption gave you at least integrity protection for the data even = though it did not protect the IP addresses (or anything else that was = part of the IP header that wasn't morphed in transit). However, for = anyone who is very well versed with IPsec, you will note that if a SPD = requires IP src and dst address as well as SPI, then the IP addresses = are implicitly protected. Note that the NAT traversal protocol had its = beginnings from that 1998 event as well. >=20 > Also please remember that at the time IPsec was being developed there = were still global import/export restrictions relating to cryptographic = protection. Not just in the US mind you=85.I have a table in a book I = wrote in 1999 that actually listed a bunch of countries and the = restrictions at that time. There typically wasn't a restriction on key = length for cryptographically protected integrity protocols but there was = one for cryptographically protected confidentiality (i.e. encryption) = protocols. In the US it was 40 bit restriction on encryption. I = believe for some *limited* subset of countries this is still true for US = export controls on cryptography today. >=20 > Anyhow=85just to get some of the history straight. And I speak as = someone who was at cisco at the time and did a lot of performance and = interoperability testing=85.and sat in the back of the room at *all* of = the IPsec meetings since the original BoF back in 1993/4 and discussed = issues in background (I don't write code=85.but can find bugs :)). And = as someone who spent well over a decade trying to get vendors and users = to understand issues of IPsec implementations and usability in a v6 = world [while an independent consultant]. I gave up 4 years ago. >=20 > And FWIW, for IPsec the primary deployment issues are in = implementation terminology and interoperable defaults. I will gladly = argue that point over beers anytime.=20 >=20 > - merike >=20 >=20 > On Dec 8, 2013, at 5:52 PM, Phillip Hallam-Baker = wrote: >=20 >> On Sun, Dec 8, 2013 at 5:00 PM, Hannes Tschofenig = wrote: >> Hi Stephen, Hi Nicholas,=20 >>=20 >> it would be interesting (as a history lesson) if someone could tell = us why the group at that time decided to develop a NULL encryption = mechanism. Stephen Kent (co-author of RFC 2410) might remember. I have = no heard=20 >>=20 >> It was for testing and it all happened long before any of the = evidence of the NSA peddling bongoed crypto suggests that it was going = on. I think it highly unlikely that anything of the sort was going on = before 9/11 and my sources claim that the change came much later, if it = happened at all. >>=20 >> I really don't think that any of the people involved in IETF process = have had a hand in knowingly peddling bongoed crypto either. But as I = have been making plain in another forum, the slides openly bragging = about such an operation have had a serious cost in terms of erosion of = trust. >>=20 >> I think any interference would have been 'action at a distance'. = Rather than come here and make the case for protecting some hole that = was going to be used to propagate Flame, I would expect the NSA people = running the DoD CA would call up their contacts in IETF space and make = up some story about their operational difficulties caused by still = running the old Netscape CA that hasn't been maintained for a decade now = or some such hokum. >>=20 >> I can't see how that sort of cover story would work for peddling a = NULL cipher. There are some vulnerabilities I think can be laid at their = door but not that one. We did that one to ourselves. >>=20 >>=20 >> IPSEC is sufficiently complicated that interop is a non trivial = problem. Or at least the people who implemented it found it to be so. = Some people tried to make the same suggestion for S/MIME (and people = might remember my reaction). Having a NULL cipher for interop testing = was not an unfounded proposal but it was certainly never one I = supported. >>=20 >> Remember that IPSEC has always supported an 'authentication only' = mode. So turning on encryption with a null cipher was not an obvious = difference. In fact it would probably have made sense to have killed the = integrity only option at the start and just had a null cipher. >>=20 >>=20 >> Perhaps we should write a draft and move it to HISTORIC, just to = avoid any confusion. >>=20 >> =20 >> In context of our discussion on this list the answer will give us a = lot of guidance for the future. Even 2 years ago I had lots of people = arguing in the OAuth working group that authentication and integrity = protection is sufficient and that we do not need confidentiality = protection. So, I wouldn't be surprised if the same argument showed up = 10 years earlier.=20 >>=20 >> That is a different argument and maybe there is a case to be made for = relying on HTTPS. I don't like that approach, in fact I super-encrypt = within HTTPS quite often and always super-authenticate end to end in my = Web Services. >>=20 >>=20 >>=20 >>=20 >> --=20 >> Website: http://hallambaker.com/ >> _______________________________________________ >> perpass mailing list >> perpass@ietf.org >> https://www.ietf.org/mailman/listinfo/perpass >=20 > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass --Apple-Mail=_1CF0819C-3DE4-4C4D-9A31-B16758F4EC18 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 And = so I reply to myself but got curious and wanted evidence.  I found = first references of AH/ESP and NULL in 1996 June IPsec archives. =  htt= p://www.sandelman.ottawa.on.ca/ipsec/1996/06/msg00030.html

And while  some interesting tidbits, the joggle for my = memory banks was that there was a bunch of discussion on where AH would = be used with ESP and whether ESP only would also be relevant.  And = while I couldn't find exact reference to the March 1998 interop testing = in North Carolina that showed issues with AH not traversing NATs I am = fairly certain that was the case and why in practice people starting = using ESP-Null.  (it wasn't in the notes for the follow-up IETF = IPsec meeting).

Someone else from that time may also = be able to chime in.

- = merike


On Dec 8, 2013, at 8:19 = PM, Merike Kaeo <merike@doubleshotsecurity.co= m> wrote:

hallam@gmail.com> = wrote:

On Sun, Dec 8, 2013 at 5:00 PM, Hannes Tschofenig = <hannes.tschofenig@gmx.net> wrote:
=20 =20 =20
Hi Stephen, Hi Nicholas,

it would be interesting (as a history lesson) if someone could tell us why the group at that time decided to develop a NULL encryption mechanism. Stephen Kent (co-author of RFC 2410) might remember. I have no heard

It was for = testing and it all happened long before any of the evidence of the NSA = peddling bongoed crypto suggests that it was going on. I think it highly = unlikely that anything of the sort was going on before 9/11 and my = sources claim that the change came much later, if it happened at = all.

I really don't think that any of the people involved = in IETF process have had a hand in knowingly peddling bongoed crypto = either. But as I have been making plain in another forum, the slides = openly bragging about such an operation have had a serious cost in terms = of erosion of trust.

I think any interference would have been 'action at = a distance'. Rather than come here and make the case for protecting some = hole that was going to be used to propagate Flame, I would expect the = NSA people running the DoD CA would call up their contacts in IETF space = and make up some story about their operational difficulties caused by = still running the old Netscape CA that hasn't been maintained for a = decade now or some such hokum.

I can't see how that sort of cover story would work = for peddling a NULL cipher. There are some vulnerabilities I think can = be laid at their door but not that one. We did that one to = ourselves.


IPSEC is sufficiently complicated = that interop is a non trivial problem. Or at least the people who = implemented it found it to be so. Some people tried to make the same = suggestion for S/MIME (and people might remember my reaction). Having a = NULL cipher for interop testing was not an unfounded proposal but it was = certainly never one I supported.

Remember that IPSEC has always supported an = 'authentication only' mode. So turning on encryption with a null cipher = was not an obvious difference. In fact it would probably have made sense = to have killed the integrity only option at the start and just had a = null cipher.


Perhaps we should write a draft and = move it to HISTORIC, just to avoid any = confusion.

 
In context of our discussion on this list the answer will give us a lot of guidance for the future.  Even 2 years ago I had lots of people arguing in the OAuth working group that authentication and integrity protection is sufficient and that we do not need confidentiality protection. So, I wouldn't be surprised if the same argument showed up 10 years earlier. =

That is a different argument = and maybe there is a case to be made for relying on HTTPS. I don't like = that approach, in fact I super-encrypt within HTTPS quite often and = always super-authenticate end to end in my Web Services.




-- =
Website: http://hallambaker.com/
_______________________________________________
perpass mailing = list
perpass@ietf.org
https://www.ietf.or= g/mailman/listinfo/perpass

_______________________________________________
perpass mailing = list
perpass@ietf.org
https://www.ietf.= org/mailman/listinfo/perpass

= = --Apple-Mail=_1CF0819C-3DE4-4C4D-9A31-B16758F4EC18-- --Apple-Mail=_B2C0A0E8-46FA-4054-951B-9ABDB3A02EEC Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJSpVESAAoJEA7gPO9LJuahbxUH/iXAVdHZjN+4Cf9AjMzKRL56 3AszUhFSqbfupQ68Mircs9KKEHyZ82Ix+QCQxD+JxlX5bPANzcDLoltJwaClcz9u g9keT9pgzSgK8PIbhqn6lx8a+8dOFjLH2O89NzIK4v8nKOsQ2C9AlPheh+B998Bw c2ce2N3xB/raANc6aIBCUoEIwMsY1DtpZT/tQZkMcTg63BxJbXGfFGHkiYKjLQH9 5+sVl7Pi0HProjFSMat/2hV5+DRmZxPIgnsLyFojJo1vtmqczWZsEGCYQmuf/Doy eb5tS9eiF3ClvN1UeG4EIRjnoEgDI3dyHE7HcMctd4b0Y7moTNfp5uw72t8A7Ac= =QgQz -----END PGP SIGNATURE----- --Apple-Mail=_B2C0A0E8-46FA-4054-951B-9ABDB3A02EEC-- From hallam@gmail.com Sun Dec 8 21:46:32 2013 Return-Path: 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 237431AD8DC for ; Sun, 8 Dec 2013 21:46:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 qqFYwe31mBu3 for ; Sun, 8 Dec 2013 21:46:30 -0800 (PST) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 08F9A1AD7C1 for ; Sun, 8 Dec 2013 21:46:29 -0800 (PST) Received: by mail-wi0-f171.google.com with SMTP id bz8so3104778wib.16 for ; Sun, 08 Dec 2013 21:46:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KZNBn9B1+0vxWEsOGMprrZfAu7rkGq+sbDx9AkGWixI=; b=D124faXml2p7zBwbYNY4lVgPGYvUHQO3SB6nSDAYiDwFF0a+wYRSjKE/0rUzCfIOJd Ade8cMoiNMm6VAj7thPa5LW0Ar5CRGIZeAEEUfOCh8ccQyCg++M+Ou7dZAvk+Ybo3eTJ P+9+Nkvns11ixb8mwFVdbpVAMriDKLakM1PHz43UQM8LzP9cE+YeZDvSt48J+E1EsW2g XyT2VTetRFsg6oWZQgqDJgGdSAR37FIbdb/Q6F37enM/sxwfwo4HGSjNaf9Tcur+UZxu OlKKjoHz/9nstaw1Tfpse1eDrpxmXPWEtCKA5693ti0D0HB3D+1cbYGxIudnzfEQQDm8 6RIA== MIME-Version: 1.0 X-Received: by 10.194.94.167 with SMTP id dd7mr33276759wjb.43.1386567984806; Sun, 08 Dec 2013 21:46:24 -0800 (PST) Received: by 10.194.243.136 with HTTP; Sun, 8 Dec 2013 21:46:24 -0800 (PST) In-Reply-To: <95276F1E-2293-41F3-A6E7-7AEF4B22E811@doubleshotsecurity.com> References: <0FE7905C-950F-4030-8A47-37C523FB497A@doubleshotsecurity.com> <95276F1E-2293-41F3-A6E7-7AEF4B22E811@doubleshotsecurity.com> Date: Mon, 9 Dec 2013 00:46:24 -0500 Message-ID: From: Phillip Hallam-Baker To: Merike Kaeo Content-Type: multipart/alternative; boundary=047d7bb03c4631004c04ed1384a1 Cc: perpass , Hannes Tschofenig , Nicholas Weaver , Stephen Farrell Subject: Re: [perpass] NULL Cipher RFC 2410 to HISTORIC ??? 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 05:46:32 -0000 --047d7bb03c4631004c04ed1384a1 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Dec 9, 2013 at 12:11 AM, Merike Kaeo wrote: > And so I reply to myself but got curious and wanted evidence. I found > first references of AH/ESP and NULL in 1996 June IPsec archives. > http://www.sandelman.ottawa.on.ca/ipsec/1996/06/msg00030.html > > And while some interesting tidbits, the joggle for my memory banks was > that there was a bunch of discussion on where AH would be used with ESP and > whether ESP only would also be relevant. And while I couldn't find exact > reference to the March 1998 interop testing in North Carolina that showed > issues with AH not traversing NATs I am fairly certain that was the case > and why in practice people starting using ESP-Null. (it wasn't in the > notes for the follow-up IETF IPsec meeting). > > Someone else from that time may also be able to chime in. > The wording of the RFC does not help. It suggests that the cipher is something of a joke and it states the original requirement came out of a meeting for interop testing. I am not sure that authentication only VPN is something that we would see the need for these days. If the base protocol still doesn't do NAT right without a NULL cipher then it is broken. -- Website: http://hallambaker.com/ --047d7bb03c4631004c04ed1384a1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, Dec 9, 2013 at 12:11 AM, Merike Kaeo <= merike@d= oubleshotsecurity.com> wrote:
And so I= reply to myself but got curious and wanted evidence. =A0I found first refe= rences of AH/ESP and NULL in 1996 June IPsec archives. =A0= http://www.sandelman.ottawa.on.ca/ipsec/1996/06/msg00030.html

And while =A0some interesting tidbits, the joggle for my mem= ory banks was that there was a bunch of discussion on where AH would be use= d with ESP and whether ESP only would also be relevant. =A0And while I coul= dn't find exact reference to the March 1998 interop testing in North Ca= rolina that showed issues with AH not traversing NATs I am fairly certain t= hat was the case and why in practice people starting using ESP-Null. =A0(it= wasn't in the notes for the follow-up IETF IPsec meeting).

Someone else from that time may also be able to chime in.

The wording of the RFC does= not help. It suggests that the cipher is something of a joke and it states= the original requirement came out of a meeting for interop testing.

I am not sure that authentication only VPN is something= that we would see the need for these days. If the base protocol still does= n't do NAT right without a NULL cipher then it is broken.
=A0

--
Website: http://hallambaker.com/
--047d7bb03c4631004c04ed1384a1-- From hallam@gmail.com Sun Dec 8 21:54:12 2013 Return-Path: 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 ECFAB1AD8DA for ; Sun, 8 Dec 2013 21:54:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 h1VqOXuY_M_d for ; Sun, 8 Dec 2013 21:54:09 -0800 (PST) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 878A71AD7BE for ; Sun, 8 Dec 2013 21:54:09 -0800 (PST) Received: by mail-wi0-f175.google.com with SMTP id hi5so3237589wib.14 for ; Sun, 08 Dec 2013 21:54:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EG3GSVTbfrQqO0AcpzMjd40KxBQBuT0l8pQPbtPZvLM=; b=lSCARn+c6PHGMyPSdyUp4Nt9Xk6gSgcgDyq1aXYOhnXeJoyaKY0zWkkfg42+pkQeim WrFoTpKBkGiOzvtx8Bp5hsuDx0edO8KZwLA1wDlmp2T1Zka8ITnznHiqry7MR6Vjj6fx tKowRTApksfxy8LVLs/iBEcTJlJlNiEtdXh4pHjV3/T/DgNGFRCKQlUF2h6ggLCoQjPY p+N1QJtYloq6GuIj2FyWaPIeeCZuh+poS6eOnFsmWiiOASLrssZhbMViwaIKkiOHYi8M B7VSYtGdlGUaOLy+TPy8ctMLxIZ+A39vZV+wu0qeTkroWZgksLGxv/x0GyWr0xeazCRv 1Y7w== MIME-Version: 1.0 X-Received: by 10.194.78.77 with SMTP id z13mr13865186wjw.27.1386568444431; Sun, 08 Dec 2013 21:54:04 -0800 (PST) Received: by 10.194.243.136 with HTTP; Sun, 8 Dec 2013 21:54:04 -0800 (PST) In-Reply-To: References: <52A050E7.8010405@uni-due.de> Date: Mon, 9 Dec 2013 00:54:04 -0500 Message-ID: From: Phillip Hallam-Baker To: Russ Mundy Content-Type: multipart/alternative; boundary=047d7bfcfc9896544904ed139fc3 Cc: perpass , =?ISO-8859-1?Q?Matth=E4us_Wander?= Subject: Re: [perpass] A reminder, the Network is the Enemy... 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 05:54:12 -0000 --047d7bfcfc9896544904ed139fc3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Dec 5, 2013 at 10:35 AM, Russ Mundy wrote: > > On Dec 5, 2013, at 5:09 AM, Matth=E4us Wander > wrote: > > > * Nicholas Weaver [2013-12-02 17:56]: > >> Actually spoofing DNSSEC replies even with knowledge of the root key i= s > going to be difficult... > > > > If we assume the attacker can get the private root KSK from an US-based > > corp, then we should also assume they can get the private root ZSK from > > another US-based corp. As the owner of the root ZSK also owns the keys > > for .com, the attack becomes much easier. > > If we (as the IETF) make an assumption that the DNSSEC private key(s) are > "available" to some "unauthorized entity" (govt or otherwise) because a > significant part of a particular operation is located in a particular > geographic region then we need to also make a similar assumption for > any/all Certification Authorities' root private key(s) since the underlyi= ng > cryptographic technology widely used by TLS is basically the same. The > DigiNotar attack, though not geographically related, clearly illustrates > that very bad things can happen when an "unauthorized entity" is able to > have access to and use of root private keys for a CA. > I agree with respect to covert attacks. Yes there is a risk in both cases and the right control is to establish a very high probability of detection so that it becomes an overt attack. What is unique in the case of the DNSSEC is that there is only one root and thus a government can perform a denial of service attack against TLDs.For example asserting that signing the Cuba or Palestine roots would breach existing sanctions legislation or passing new legislation. And such scenarios do not seem at all far fetched to me having watched the government shutdown. --=20 Website: http://hallambaker.com/ --047d7bfcfc9896544904ed139fc3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Thu, Dec 5, 2013 at 10:35 AM, Russ Mundy <<= a href=3D"mailto:mundy@tislabs.com" target=3D"_blank">mundy@tislabs.com= > wrote:

On Dec 5, 2013, at 5:09 AM, Matth=E4us Wander <matthaeus.wander@uni-due.de> wrote:

> * Nicholas Weaver [2013-12-02 17:56]:
>> Actually spoofing DNSSEC replies even with knowledge of the root k= ey is going to be difficult...
>
> If we assume the attacker can get the private root KSK from an US-base= d
> corp, then we should also assume they can get the private root ZSK fro= m
> another US-based corp. As the owner of the root ZSK also owns the keys=
> for .com, the attack becomes much easier.

If we (as the IETF) make an assumption that the DNSSEC private key(s)= are "available" to some "unauthorized entity" (govt or= otherwise) because a significant part of a particular operation is located= in a particular geographic region then we need to also make a similar assu= mption for any/all Certification Authorities' root private key(s) since= the underlying cryptographic technology widely used by TLS is basically th= e same. =A0The DigiNotar attack, though not geographically related, clearly= illustrates that very bad things can happen when an "unauthorized ent= ity" is able to have access to and use of root private keys for a CA.<= br>

I agree with respect to covert attacks. Ye= s there is a risk in both cases and the right control is to establish a ver= y high probability of detection so that it becomes an overt attack.

What is unique in the case of the DNSSEC is that there = is only one root and thus a government can perform a denial of service atta= ck against TLDs.For example asserting that signing the Cuba or Palestine ro= ots would breach existing sanctions legislation or passing new legislation.=

And such scenarios do not seem at all far fetched to me= having watched the government shutdown.
=A0
--
We= bsite: http://hallambaker.com/
--047d7bfcfc9896544904ed139fc3-- From ynir@checkpoint.com Sun Dec 8 23:24:09 2013 Return-Path: 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 EAF351AE1C8 for ; Sun, 8 Dec 2013 23:24:09 -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 EnL9kbQ1xkyY for ; Sun, 8 Dec 2013 23:24:08 -0800 (PST) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id ACDB51AD7BE for ; Sun, 8 Dec 2013 23:24:07 -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 rB97NfxT020180; Mon, 9 Dec 2013 09:23:41 +0200 X-CheckPoint: {52A56C95-2-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; Mon, 9 Dec 2013 09:23:41 +0200 From: Yoav Nir To: Phillip Hallam-Baker Thread-Topic: [perpass] NULL Cipher RFC 2410 to HISTORIC ??? Thread-Index: AQHO9IFu4/5YzgvJX0aB14ruAS2e45pLIR6AgAAOqACAAAmtAIAAOKIw Date: Mon, 9 Dec 2013 07:23:40 +0000 Message-ID: <4613980CFC78314ABFD7F85CC302772121B1EC40@IL-EX10.ad.checkpoint.com> References: <0FE7905C-950F-4030-8A47-37C523FB497A@doubleshotsecurity.com> <95276F1E-2293-41F3-A6E7-7AEF4B22E811@doubleshotsecurity.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [91.90.139.27] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: perpass , Merike Kaeo Subject: Re: [perpass] NULL Cipher RFC 2410 to HISTORIC ??? 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 07:24:10 -0000 Phil, The issue is not that ESP needs a NULL cipher. It's that AH wouldn't traver= se NAT, and so they needed ESP to do the work that AH was designed to do. But beyond that little technicality, it stands out that they standardized A= H at all. So they felt that there was a need for integrity-only IPsec. I gu= ess part of this is that the perceived threats were different - there was l= ess personal information on the Internet, and IPsec (unlike TLS) is much co= ncerned with protecting non-confidential stuff like DNS, routing protocols.= Today, about the only good use case I can think of that doesn't ever need = confidentiality is NTP, and I don't know why we would want to design a prot= ocol specifically for securing NTP. Another part is that this was 1996 and in 1996 you had the "Pentium Pro" wi= th a 150 MHz clock and a 60 MHz bus, which could probably do a few Mbps of = 3DES+HMAC-MD5, or four times that with HMAC-MD5 alone. These are not today'= s processors that do 4 Gbps per core with AES-GCM. BTW: this is not unique to IPsec. TLS also defines some NULL encryption cip= hersuites. Yoav =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D From: perpass [mailto:perpass-bounces@ietf.org] On Behalf Of Phillip Hallam= -Baker Sent: Monday, December 09, 2013 7:46 AM To: Merike Kaeo Cc: perpass; Hannes Tschofenig; Nicholas Weaver; Stephen Farrell Subject: Re: [perpass] NULL Cipher RFC 2410 to HISTORIC ??? On Mon, Dec 9, 2013 at 12:11 AM, Merike Kaeo wrote: And so I reply to myself but got curious and wanted evidence. =A0I found fi= rst references of AH/ESP and NULL in 1996 June IPsec archives. =A0http://ww= w.sandelman.ottawa.on.ca/ipsec/1996/06/msg00030.html And while =A0some interesting tidbits, the joggle for my memory banks was t= hat there was a bunch of discussion on where AH would be used with ESP and = whether ESP only would also be relevant. =A0And while I couldn't find exact= reference to the March 1998 interop testing in North Carolina that showed = issues with AH not traversing NATs I am fairly certain that was the case an= d why in practice people starting using ESP-Null. =A0(it wasn't in the note= s for the follow-up IETF IPsec meeting). Someone else from that time may also be able to chime in. The wording of the RFC does not help. It suggests that the cipher is someth= ing of a joke and it states the original requirement came out of a meeting = for interop testing. I am not sure that authentication only VPN is something that we would see t= he need for these days. If the base protocol still doesn't do NAT right wit= hout a NULL cipher then it is broken. =A0 --=20 Website: http://hallambaker.com/ From david.lloydjones@gmail.com Mon Dec 9 00:21:29 2013 Return-Path: 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 7641B1AE23A for ; Mon, 9 Dec 2013 00:21:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.702 X-Spam-Level: X-Spam-Status: No, score=0.702 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_IMAGE_RATIO_06=0.001, HTML_MESSAGE=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 JzhSbdU14UOK for ; Mon, 9 Dec 2013 00:21:27 -0800 (PST) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 3DAD31AE236 for ; Mon, 9 Dec 2013 00:21:26 -0800 (PST) Received: by mail-wg0-f42.google.com with SMTP id a1so3051436wgh.5 for ; Mon, 09 Dec 2013 00:21:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=+/KMLIvKE2SrzZZBSkyrhz58nuy5jsm+xnR6GphnTuw=; b=bdf1NI3nHaDYG7d6hpBJKzQ7klWfa8+2+x+3GdlYRUbkTKk4eNAemVz4ZXDZcZr5ue bcYIU4Z3SZt3eGF2w1vbDtCAp9iX1roq/niQYik08EiRtGVYqjd66PJ6lYNBy6t9qWuv 5dweLD9V6yrQtdYP/MeWNNW/T/lCt6Zdaj2/4ktjNEzXsy2ee2zX9EawpM1ya1bplGoE rQ4+hn574t7MQmhbaDYQvEOFCXRkCX8b03S8YQKP6KtGg1DAw6i7//1A7vgL6VZitVvE Knwvq2T5owvzlv6UfqGYl9oyDMfQNzHmJBp6K5OmEuaCeMToez9KAIuOkDpgseUz34Cr 3hhQ== MIME-Version: 1.0 X-Received: by 10.180.108.132 with SMTP id hk4mr13102799wib.12.1386577280865; Mon, 09 Dec 2013 00:21:20 -0800 (PST) Received: by 10.194.110.169 with HTTP; Mon, 9 Dec 2013 00:21:20 -0800 (PST) Date: Mon, 9 Dec 2013 03:21:20 -0500 Message-ID: From: David Lloyd-Jones To: perpass Content-Type: multipart/alternative; boundary=e89a8f3baad5479a3204ed15ae96 Subject: [perpass] Today's Paper 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 08:21:29 -0000 --e89a8f3baad5479a3204ed15ae96 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable http://www.nytimes.com/2013/12/09/technology/tech-giants-issue-call-for-lim= its-on-government-surveillance-of-users.html?src=3Drecg Tech Giants Issue Call for Limits on Government Surveillance of Users Connie Zhou/Google Servers in a Google data center in Oregon. The company is tightening its networks against government spying. By EDWARD WYATT and CLAIRE CAIN MILLERPublished: December 9, 2013 Eight prominent technology companies, bruised by revelations of government spying on their customers=E2=80=99 data and scrambling to repair the damage= to their reputations, are mounting a public campaign to urge President Obama and Congress to set new limits on government surveillance . --e89a8f3baad5479a3204ed15ae96 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
http://www.nytimes.com/2013/12/09/technology/tech-giants-issue-ca= ll-for-limits-on-government-surveillance-of-users.html?src=3Drecg

Tech Gian= ts Issue Call for Limits on Government Surveillance of Users

3D""
Connie Zhou/Google

Servers in a Google data center in Oregon.= The company is tightening its networks against government spying.

By=C2=A0EDWARD WYATT=C2=A0and=C2=A0CLAIRE CAIN MI= LLER
<= h6 class=3D"" style=3D"margin:0px;color:rgb(128,128,128);font-size:1em;line= -height:1.2em;font-weight:normal;font-family:arial,helvetica,sans-serif"> Published: December 9, 2013

Eight prominent technology companies, bruised by revelations of government = spying on their customers=E2=80=99 data and scrambling to repair the damage= to their reputations, are mounting a public campaign to urge President Oba= ma and Congress to set new limits on government surveillance

.

--e89a8f3baad5479a3204ed15ae96-- From wilton@isoc.org Mon Dec 9 00:38:30 2013 Return-Path: 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 E88A81AE0CE for ; Mon, 9 Dec 2013 00:38:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 LCjk1_a1OFS7 for ; Mon, 9 Dec 2013 00:38:28 -0800 (PST) Received: from smtp78.iad3a.emailsrvr.com (smtp78.iad3a.emailsrvr.com [173.203.187.78]) by ietfa.amsl.com (Postfix) with ESMTP id C197F1AE0F9 for ; Mon, 9 Dec 2013 00:38:27 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp26.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 0C7563380BC; Mon, 9 Dec 2013 03:38:23 -0500 (EST) X-Virus-Scanned: OK Received: by smtp26.relay.iad3a.emailsrvr.com (Authenticated sender: wilton-AT-isoc.org) with ESMTPSA id 7F0D33380B3; Mon, 9 Dec 2013 03:38:22 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/signed; boundary="Apple-Mail=_CC0D4B9A-0E66-4E21-89B3-61E26F2BFBA7"; protocol="application/pkcs7-signature"; micalg=sha1 From: Robin Wilton In-Reply-To: <52A50DAC.7040601@panix.com> Date: Mon, 9 Dec 2013 09:38:11 +0100 Message-Id: References: <529E8494.7000806@perens.com> <20131204111309.GB11727@nic.fr> <529F61D8.6030105@perens.com> <20131204171207.GC19914@thunk.org> <529F63C0.3040804@perens.com> <529F88AC.3090904@appelbaum.net> <529F90A0.8000706@perens.com> <529F9205.30906@appelbaum.net> <529F98C0.9090808@perens.com> <529F9F14.8050805@appelbaum.net> <529FB61A.7090604@perens.com> <529FBEF9.7030205@appelbaum.net> <529FC347.3080806@perens.com> <52A15835.2070901@cis-india.org> <52A21B80.8070005@mykolab.com> <52A21D1C.8020000@perens.com> <52A2235A.2030801@perens.com> <240A2D86-C352-4954-BE4E-6313BA25994E@icsi.berkeley.edu> <52A2CE6A.30408@perens.com> <52A31F1D.7040509@cs.tcd.ie> <5D026682-5457-4F00-B139-58D8D718BB0A@icsi.berkeley.edu> <454F08BE-5C79-408B-B356-6D895C9B1CC3@isoc.org> <52A50DAC. 7040601@panix.com> To: Albert Lunde X-Mailer: Apple Mail (2.1283) 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 08:38:30 -0000 --Apple-Mail=_CC0D4B9A-0E66-4E21-89B3-61E26F2BFBA7 Content-Type: multipart/alternative; boundary="Apple-Mail=_921553D7-A1A6-45C9-8385-BE93F0E17AF6" --Apple-Mail=_921553D7-A1A6-45C9-8385-BE93F0E17AF6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thanks Albert -=20 Right... but I'm not excluding cases where micropayment systems are = subjected to automated attack; I'm suggesting that that would represent = 'abnormal' levels of disputed payment. I was considering integrity = protection (MAC/signing) in the context of disputed micropayments at = 'normal' (i.e. personal, non-automated) volumes.=20 I think the countermeasures for that threat model differ from the = countermeasures for automated attack. I hope this helps clarify the point I was trying to make. R Robin Wilton Technical Outreach Director - Identity and Privacy Internet Society email: wilton@isoc.org Phone: +44 705 005 2931 Twitter: @futureidentity On 9 Dec 2013, at 01:24, Albert Lunde wrote: > On 12/8/2013 1:59 PM, Robin Wilton wrote: >> Nick, >> > >> I agree that there is a cost threshold for signature/MAC. It is >> something I uncovered in my PKI research: for PKI-enabled = micropayments >> it is, arguably, not worth signing the public key involved, if the >> number of disputed payments is at normal levels... because normal >> levels, for most micropayment applications, are low. It's more >> cost-effective to simply refund the tiny minority of disputed = payments. >=20 > It seems like a threat model that assumes the sole risk is disputed = payments "at the normal rate" is broken in the presence of automated = attacks. >=20 > I don't think the NSA is the only bad actor, in the short term, = for-profit criminal groups seem more likely to do active or tailored = attacks. This can result in bursts of fraud and/or malware affecting = particular clients or sites disproportionately. >=20 > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass --Apple-Mail=_921553D7-A1A6-45C9-8385-BE93F0E17AF6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Robin = Wilton
Technical Outreach Director - Identity and = Privacy
Internet Society

Phone: +44 = 705 005 2931
Twitter: = @futureidentity




On 9 Dec 2013, at 01:24, Albert Lunde wrote:

On = 12/8/2013 1:59 PM, Robin Wilton wrote:
Nick,
>
I agree = that there is a cost threshold for signature/MAC. It = is
something I uncovered in my = PKI research: for PKI-enabled micropayments
it is, arguably, not worth signing the public key = involved, if the
number of = disputed payments is at normal levels... because = normal
levels, for most = micropayment applications, are low. It's = more
cost-effective to simply = refund the tiny minority of disputed payments.

It = seems like a threat model that assumes the sole risk is disputed = payments "at the normal rate" is broken in the presence of automated = attacks.

I don't think the NSA is the only bad actor, in the = short term, for-profit criminal groups seem more likely to do active or = tailored attacks.  This can result in bursts of fraud and/or = malware affecting particular clients or sites = disproportionately.

_______________________________________________=
perpass mailing list
perpass@ietf.org
https://www.ietf.= org/mailman/listinfo/perpass

= = --Apple-Mail=_921553D7-A1A6-45C9-8385-BE93F0E17AF6-- --Apple-Mail=_CC0D4B9A-0E66-4E21-89B3-61E26F2BFBA7 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIIvDCCBBYw ggL+oAMCAQICCwQAAAAAAS9O4SzhMA0GCSqGSIb3DQEBBQUAMFcxCzAJBgNVBAYTAkJFMRkwFwYD VQQKExBHbG9iYWxTaWduIG52LXNhMRAwDgYDVQQLEwdSb290IENBMRswGQYDVQQDExJHbG9iYWxT aWduIFJvb3QgQ0EwHhcNMTEwNDEzMTAwMDAwWhcNMTkwNDEzMTAwMDAwWjBUMQswCQYDVQQGEwJC RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEqMCgGA1UEAxMhR2xvYmFsU2lnbiBQZXJzb25h bFNpZ24gMSBDQSAtIEcyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA8aUcr5BvPNGj x0+LH0uRqeZCHrYQ7KN3QuahfxY8fAzAbnvNDzGdEMyKn3+YX+k/QbAGNJOSFRxrAfhviF7WGcqD lin3HracDqMRgwrknWuFeqxhN2J7uXs3Y0zluJEkEittRXv+ZdXOG/Gp3gtoz5P9noc5jBbfWQpQ BhcaJA2ucABbUVTHDTxi7dBY8mTWq6kRAkGWBybHwq0YX+jaHudtQw0oBEmxjpJFP9qIXu0ckU/+ OhtnAhrgzrsd4oAyqgc6u4dBYERcjDJFohihjbzPozgKDSSbdr44uO3p9Bg6ibjCxn2besLrIE7u poxvV09Fsf7hDeD/jcvs64z8pQIDAQABo4HlMIHiMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8E CDAGAQH/AgEAMB0GA1UdDgQWBBTsrJjMJ3KTz1YyzSPHnY1FhfQiAzBHBgNVHSAEQDA+MDwGBFUd IAAwNDAyBggrBgEFBQcCARYmaHR0cHM6Ly93d3cuZ2xvYmFsc2lnbi5jb20vcmVwb3NpdG9yeS8w MwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5nbG9iYWxzaWduLm5ldC9yb290LmNybDAfBgNV HSMEGDAWgBRge2YaRQ2XyolQL30EzTSo//z9SzANBgkqhkiG9w0BAQUFAAOCAQEAr7unyEtmt9Ia 7hmNpqP+xMd0t5hLM0QBY8G3Dlg70XI6F+ZeSZeeXgCtUT/JhdQ+HsJ8+c6HypDuvg/OZ0gILDFI a9LDfRWm+tHIgxKaJjtCy0izg838dLwwnt/O3kA9N/htEYev2lsmWYCV9cVUm5V1tW3XuYNg6Sbt cDRH+Ki1RED9es3R0BgHSm012KPxsiAOOxuhm1D3Iqs1qe6ms5WTKXVgwb/j/kplOa13nshhc8zU LVO+oAlD4+7czNK2RJiTvhJiDJDRTZy3DJ3BCQ8rXOGdWzDEI5uiB8TZ0s327g44Ylc6dgKgYelN n9RLYjNETX8OIJZlr0tFYpcYrDCCBJ4wggOGoAMCAQICEGZgT+TGYtW+XJFC/uaWLhwwDQYJKoZI hvcNAQEFBQAwVDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExKjAoBgNV BAMTIUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIDEgQ0EgLSBHMjAeFw0xMzA3MDIxMzA4NTBaFw0x NjA3MDIxMzA4NTBaMDoxGDAWBgNVBAMMD3dpbHRvbkBpc29jLm9yZzEeMBwGCSqGSIb3DQEJARYP d2lsdG9uQGlzb2Mub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAoXFv/b3D0Hgt yFZ0fwd7y1X2zNMap0xTZn4a5nonOFedmZA626x88a0jv9GRNWpzjAu2AycDSdLH1qlWPurMLIiX 5JsEKlByX879TizmNbHlUnIpDQwXq4ODfsrPstSNyh88Cov4WXAqr1T3CREjN5We7L7h/hfTc2rC iCPXqbSnob6OhOAi46PWoed2SGqorNQYlETt6h2KU+U+iY4jyRqHIgPG82ylCXoWJC3zl2+e48PS Qy62a/4dUGIoMLLPztIIgzJS6Hq58ZgO8tkNwoED5OdtbbY1MYzAifb3bQQjOjZyM31kapseEeiy DYqHel5Gpoz1GfW2Qv0NMZ0ANwIDAQABo4IBhDCCAYAwDgYDVR0PAQH/BAQDAgWgMEwGA1UdIARF MEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8vd3d3Lmdsb2JhbHNpZ24uY29t L3JlcG9zaXRvcnkvMBoGA1UdEQQTMBGBD3dpbHRvbkBpc29jLm9yZzAJBgNVHRMEAjAAMB0GA1Ud JQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDBDBgNVHR8EPDA6MDigNqA0hjJodHRwOi8vY3JsLmds b2JhbHNpZ24uY29tL2dzL2dzcGVyc29uYWxzaWduMWcyLmNybDBVBggrBgEFBQcBAQRJMEcwRQYI KwYBBQUHMAKGOWh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzcGVyc29uYWxz aWduMWcyLmNydDAdBgNVHQ4EFgQUQjRxfdqFc6xPpajaSzuD2wzsV4owHwYDVR0jBBgwFoAU7KyY zCdyk89WMs0jx52NRYX0IgMwDQYJKoZIhvcNAQEFBQADggEBAFmkOj2M8636zFdLGl30Hc/njsvX 8mlA76DAUuV/d3EtbtyVrURAvugN+Q6yfl5pSSvqjr2vQzREdJZcw+eEGsqw0BMNvN3BOs9WiK9a m/BKsQr22W/k006T8aJIluvEPj0wIoJ6jM/1O4ll6vpYmeGFzZ//5OnZmgRbfwD6u4lblbFzb1rW bMkO7wyMgzwcnmDpENlIoqL0poqDz0TfagKG2/0UKS2OYmZW7WfmkKxq3ODoRp4XLTyrSycDUsB1 7VIjQG9Wx7FNZREfYf/OLOFHatoMLIiGCvLTMc/f3ijGadNGSTTZ5SE3Y7vXM7KmSsraGRhV2BQI iapDLC2ImnkxggLkMIIC4AIBATBoMFQxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWdu IG52LXNhMSowKAYDVQQDEyFHbG9iYWxTaWduIFBlcnNvbmFsU2lnbiAxIENBIC0gRzICEGZgT+TG YtW+XJFC/uaWLhwwCQYFKw4DAhoFAKCCAVEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMTMxMjA5MDgzODExWjAjBgkqhkiG9w0BCQQxFgQU/2C7yOD9/u5OW1vEdK37 L0W4aS8wdwYJKwYBBAGCNxAEMWowaDBUMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2ln biBudi1zYTEqMCgGA1UEAxMhR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gMSBDQSAtIEcyAhBmYE/k xmLVvlyRQv7mli4cMHkGCyqGSIb3DQEJEAILMWqgaDBUMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQ R2xvYmFsU2lnbiBudi1zYTEqMCgGA1UEAxMhR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gMSBDQSAt IEcyAhBmYE/kxmLVvlyRQv7mli4cMA0GCSqGSIb3DQEBAQUABIIBAI87uR8TalNcbppr0lqTRuVZ TooWyckbo/LpjJydbSF3gwVqV1N5YCoJRrDLhb1R5eEKML+iGUcJ1J8tHcAAA0WAFOxNWWAdQBqM AUyGQnlQ4AxHHnEmxjB2K3yUG1aIhAGaCKOHsqHXPZz17x7SWWQunkq8wjeMeMMgXP+6cjEov68G MV+DxPzBTihv0KgVzHyLiQcvTWbt1Ll7AbO4aFY6LgC9Md+B4chdLwk29hV0vxbYgPhpSeKq8V0H ZEWGIiWTMZMTi7xmyevbMIkNbaDokyOVSgW7UV6R+UJkRxEgW4jGDlLWco2J0qpTnGqXChJ/kEKe nviq9LbYbEofkh8AAAAAAAA= --Apple-Mail=_CC0D4B9A-0E66-4E21-89B3-61E26F2BFBA7-- From bmanning@isi.edu Mon Dec 9 00:59:10 2013 Return-Path: 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 1C8101ADF4C for ; Mon, 9 Dec 2013 00:59:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-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 ubyoUPRlwCnd for ; Mon, 9 Dec 2013 00:59:08 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id BF6601ADEDC for ; Mon, 9 Dec 2013 00:59:08 -0800 (PST) Received: from [192.168.0.3] (cpe-24-24-228-167.socal.res.rr.com [24.24.228.167]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id rB98wX74004237 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 9 Dec 2013 00:58:36 -0800 (PST) From: manning bill Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 9 Dec 2013 00:58:34 -0800 To: perpass Message-Id: <86BC54D4-7D2F-42F1-BA46-A73585605D58@isi.edu> Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: bmanning@isi.edu Subject: [perpass] into the legal arena 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 08:59:10 -0000 piecemeal approach - a fact of life in todays environment. = http://www.washingtonpost.com/blogs/the-switch/wp/2013/09/25/author-of-cal= ifornia-online-eraser-law-its-not-always-easy-to-find-the-delete-button/ /bill Neca eos omnes. Deus suos agnoscet. From lear@cisco.com Mon Dec 9 04:29:26 2013 Return-Path: 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 986F51AE291; Mon, 9 Dec 2013 04:29:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.502 X-Spam-Level: X-Spam-Status: No, score=-9.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable 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 zi8r05mJj8lZ; Mon, 9 Dec 2013 04:29:25 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id 9E8941ADF6E; Mon, 9 Dec 2013 04:29:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3142; q=dns/txt; s=iport; t=1386592160; x=1387801760; h=message-id:date:from:mime-version:to:cc:subject: content-transfer-encoding; bh=Oa7KuxQC6L95Ka63+bO1jBfwKNBD99mrvnoBwX/HTSk=; b=CzN9KAFOfpoPc5I70Rh77MJgmw2TmKwhF33y4HJkolsrkzHqExxjJnwz umV9yTP3SaBKsVDXZd2S3HYcGCR+mQLVRFVCPCGoY1eaxBYfBJX/+SH+s wmU4fXV7NizQQ4+SY5bqxaP0ue91/xrAgWDhQZwm9RTu1VDL5R8+274hb M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFAFa2pVKQ/khM/2dsb2JhbABZgwc4g1K2FYEtFnSCJQEBAQMPFUIJCgEFMAIFDAoLAgsDAgECAUsBDAEHAQGHeAayBY8lF4EpjQ9YEYJhgUgDlDGDY5ITgyo7gSw X-IronPort-AV: E=Sophos;i="4.93,857,1378857600"; d="scan'208";a="1297337" Received: from ams-core-3.cisco.com ([144.254.72.76]) by aer-iport-2.cisco.com with ESMTP; 09 Dec 2013 12:29:19 +0000 Received: from ams3-vpn-dhcp5161.cisco.com (ams3-vpn-dhcp5161.cisco.com [10.61.84.40]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id rB9CT9dV006481 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Dec 2013 12:29:10 GMT Message-ID: <52A5B79E.2040202@cisco.com> Date: Mon, 09 Dec 2013 13:29:18 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: "ietf-interest(mailer list)" , perpass X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Auto-Response-Suppress: DR, OOF, AutoReply Cc: Internet Architecture Board , 'IESG' Subject: [perpass] comments and questions for the group on draft-farrell-perpass-attack-02 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 12:29:26 -0000 These comments follow a thread from the IAB/IESG mailing list. There has been some confusion over how this proposed BCP should be taken by working groups. At least one working group chair has inferred, if not suggested, that a document before the IESG that does not demonstrate it has mitigated pervasive surveillance will get returned. That wouldn't be appropriate, in my opinion. A working group must consider the operational realities that it is attempting to code to. There are many tensions to consider, not just a narrow view of network management (a phrase that might itself be left to ambiguous interpretation). I have in mind as an example a service provider that does transparent/intercepting HTTP caching for purposes of bandwidth preservation in bandwidth-constrained environments. Another example would be an environment in which security and governance are key. As such, I propose the following two changes to clarify the text in Section 2: 2nd para: OLD: > This BCP simply records the consensus to design > protocols so as to mitigate the attack, where possible. NEW: > This BCP simply records the consensus to design > protocols so as to mitigate the attack, taking into account > operational realities of network operators. Next para: OLD: > More limited-scope monitoring to assist with network management that > is required in order to operate the network or an application is not > considered pervasive monitoring. There is though a clear potential > for such limited monitoring mechanisms to be abused as part of > pervasive monitoring, so this tension needs careful consideration in > protocol design. Making networks unmanageable in order to mitigate > pervasive monitoring would not be an acceptable outcome. But > equally, ignoring pervasive monitoring in designing network > management mechanisms would go against the consensus documented in > this BCP. An appropriate balance will likely emerge over time as > real instances of this tension are considered. NEW: > More limited-scope monitoring or other services or to assist with > network operations that > is required in order to operate the network or an application is not > considered pervasive monitoring, > There is though a clear potential > for such mechanisms to be abused as part of > pervasive monitoring, so this tension needs careful consideration in > protocol design. Making networks unmanageable in order to mitigate > pervasive monitoring would not be an acceptable outcome. But > equally, ignoring pervasive monitoring in designing network > management mechanisms would go against the consensus documented in > this BCP. An appropriate balance will likely emerge over time as > real instances of this tension are considered. And so someone operating a small ISP with a cache in Madagascar or the SP trying to manage bandwidth on a train can also have their considerations taken into account. It's for a working group to decide how far to accommodate them, of course. Eliot From eburger@standardstrack.com Mon Dec 9 04:44:02 2013 Return-Path: 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 37BC81AE2AF; Mon, 9 Dec 2013 04:44:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.278 X-Spam-Level: * X-Spam-Status: No, score=1.278 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, MIME_BAD_LINEBREAK=0.5, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779] 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 4QnfdoIbgo22; Mon, 9 Dec 2013 04:44:00 -0800 (PST) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [173.247.246.244]) by ietfa.amsl.com (Postfix) with ESMTP id 6E37F1AE2A2; Mon, 9 Dec 2013 04:44:00 -0800 (PST) Received: from 217.sub-70-208-162.myvzw.com ([70.208.162.217]:6988 helo=[10.176.192.142]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.80.1) (envelope-from ) id 1Vq0Bi-00010x-Jz; Mon, 09 Dec 2013 04:43:54 -0800 Date: Mon, 09 Dec 2013 07:43:48 -0500 Message-ID: <7wmom0dq1s8yyc5t1qpvdxxl.1386593028146@email.android.com> Importance: normal From: Eric Burger To: Eliot Lear , "ietf-interest(mailer list)" , perpass MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.android.email_1411917445541780" X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed X-Source: X-Source-Args: X-Source-Dir: Cc: Internet Architecture Board , 'IESG' Subject: Re: [perpass] comments and questions for the group on draft-farrell-perpass-attack-02 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 12:44:02 -0000 ----_com.android.email_1411917445541780 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 U28gaWYgdGhlICJvcGVyYXRpb25hbCByZWFsaXRpZXMiIG9mIHRoZSBvcGVyYXRvciBpbmNsdWRl IGEgbWFuZGF0ZSB0byBpbnRlcmNlcHQsIGxpa2Ugd2l0aCBhIGxhdyBsaWtlIENBTEVBIGluIHRo ZSBVbml0ZWQgU3RhdGVzLCB0aGVuIHBlcnZhc2l2ZSBtb25pdG9yaW5nIGlzIE9LPwoKClNlbnQg ZnJvbSBteSBtb2JpbGUgZGV2aWNlLiBUaGFua3MgYmUgdG8gTEVNT05BREU6IGh0dHA6Ly93d3cu c3RhbmRhcmRzdHJhY2suY29tL2lldGYvbGVtb25hZGUKUzJFUkM6IGh0dHA6Ly9zMmVyYy5nZW9y Z2V0b3duLmVkdS8KR0NTQzogaHR0cDovL2djc2MuZ2VvcmdldG93bi5lZHUvCk1lOiBodHRwOi8v d3d3LmNzLmdlb3JnZXRvd24uZWR1L34gZWJ1cmdlcgoKLS0tLS0tLS0gT3JpZ2luYWwgbWVzc2Fn ZSAtLS0tLS0tLQpGcm9tOiBFbGlvdCBMZWFyIDxsZWFyQGNpc2NvLmNvbT4gCkRhdGU6MTIvMDkv MjAxMyAgNzoyOSBBTSAgKEdNVC0wNTowMCkgClRvOiAiaWV0Zi1pbnRlcmVzdChtYWlsZXIgbGlz dCkiIDxpZXRmLWludGVyZXN0QGNpc2NvLmNvbT4scGVycGFzcyA8cGVycGFzc0BpZXRmLm9yZz4g CkNjOiBJbnRlcm5ldCBBcmNoaXRlY3R1cmUgQm9hcmQgPGlhYkBpYWIub3JnPiwnSUVTRycgPGll c2dAaWV0Zi5vcmc+IApTdWJqZWN0OiBbcGVycGFzc10gY29tbWVudHMgYW5kIHF1ZXN0aW9ucyBm b3IgdGhlIGdyb3VwIG9uDSAJZHJhZnQtZmFycmVsbC1wZXJwYXNzLWF0dGFjay0wMiAKClRoZXNl IGNvbW1lbnRzIGZvbGxvdyBhIHRocmVhZCBmcm9tIHRoZSBJQUIvSUVTRyBtYWlsaW5nIGxpc3Qu CgpUaGVyZSBoYXMgYmVlbiBzb21lIGNvbmZ1c2lvbiBvdmVyIGhvdyB0aGlzIHByb3Bvc2VkIEJD UCBzaG91bGQgYmUgdGFrZW4KYnkgd29ya2luZyBncm91cHMuwqAgQXQgbGVhc3Qgb25lIHdvcmtp bmcgZ3JvdXAgY2hhaXIgaGFzIGluZmVycmVkLCBpZgpub3Qgc3VnZ2VzdGVkLCB0aGF0IGEgZG9j dW1lbnQgYmVmb3JlIHRoZSBJRVNHIHRoYXQgZG9lcyBub3QgZGVtb25zdHJhdGUKaXQgaGFzIG1p dGlnYXRlZCBwZXJ2YXNpdmUgc3VydmVpbGxhbmNlIHdpbGwgZ2V0IHJldHVybmVkLsKgIFRoYXQK d291bGRuJ3QgYmUgYXBwcm9wcmlhdGUsIGluIG15IG9waW5pb24uwqAgQSB3b3JraW5nIGdyb3Vw IG11c3QgY29uc2lkZXIKdGhlIG9wZXJhdGlvbmFsIHJlYWxpdGllcyB0aGF0IGl0IGlzIGF0dGVt cHRpbmcgdG8gY29kZSB0by7CoCBUaGVyZSBhcmUKbWFueSB0ZW5zaW9ucyB0byBjb25zaWRlciwg bm90IGp1c3QgYSBuYXJyb3cgdmlldyBvZiBuZXR3b3JrIG1hbmFnZW1lbnQKKGEgcGhyYXNlIHRo YXQgbWlnaHQgaXRzZWxmIGJlIGxlZnQgdG8gYW1iaWd1b3VzIGludGVycHJldGF0aW9uKS7CoCBJ CmhhdmUgaW4gbWluZCBhcyBhbiBleGFtcGxlIGEgc2VydmljZSBwcm92aWRlciB0aGF0IGRvZXMK dHJhbnNwYXJlbnQvaW50ZXJjZXB0aW5nIEhUVFAgY2FjaGluZyBmb3IgcHVycG9zZXMgb2YgYmFu ZHdpZHRoCnByZXNlcnZhdGlvbiBpbiBiYW5kd2lkdGgtY29uc3RyYWluZWQgZW52aXJvbm1lbnRz LsKgIEFub3RoZXIgZXhhbXBsZQp3b3VsZCBiZSBhbiBlbnZpcm9ubWVudCBpbiB3aGljaCBzZWN1 cml0eSBhbmQgZ292ZXJuYW5jZSBhcmUga2V5LgoKQXMgc3VjaCwgSSBwcm9wb3NlIHRoZSBmb2xs b3dpbmcgdHdvIGNoYW5nZXMgdG8gY2xhcmlmeSB0aGUgdGV4dCBpbgpTZWN0aW9uIDI6CgoybmQg cGFyYToKCk9MRDoKPsKgwqDCoCBUaGlzIEJDUCBzaW1wbHkgcmVjb3JkcyB0aGUgY29uc2Vuc3Vz IHRvIGRlc2lnbgo+wqDCoMKgIHByb3RvY29scyBzbyBhcyB0byBtaXRpZ2F0ZSB0aGUgYXR0YWNr LCB3aGVyZSBwb3NzaWJsZS4KCk5FVzoKCj7CoMKgwqAgVGhpcyBCQ1Agc2ltcGx5IHJlY29yZHMg dGhlIGNvbnNlbnN1cyB0byBkZXNpZ24KPsKgwqDCoCBwcm90b2NvbHMgc28gYXMgdG8gbWl0aWdh dGUgdGhlIGF0dGFjaywgdGFraW5nIGludG8gYWNjb3VudAo+IG9wZXJhdGlvbmFsIHJlYWxpdGll cyBvZiBuZXR3b3JrIG9wZXJhdG9ycy4KCk5leHQgcGFyYToKCk9MRDoKPsKgwqDCoCBNb3JlIGxp bWl0ZWQtc2NvcGUgbW9uaXRvcmluZyB0byBhc3Npc3Qgd2l0aCBuZXR3b3JrIG1hbmFnZW1lbnQg dGhhdAo+wqDCoMKgIGlzIHJlcXVpcmVkIGluIG9yZGVyIHRvIG9wZXJhdGUgdGhlIG5ldHdvcmsg b3IgYW4gYXBwbGljYXRpb24gaXMgbm90Cj7CoMKgwqAgY29uc2lkZXJlZCBwZXJ2YXNpdmUgbW9u aXRvcmluZy7CoCBUaGVyZSBpcyB0aG91Z2ggYSBjbGVhciBwb3RlbnRpYWwKPsKgwqDCoCBmb3Ig c3VjaCBsaW1pdGVkIG1vbml0b3JpbmcgbWVjaGFuaXNtcyB0byBiZSBhYnVzZWQgYXMgcGFydCBv Zgo+wqDCoMKgIHBlcnZhc2l2ZSBtb25pdG9yaW5nLCBzbyB0aGlzIHRlbnNpb24gbmVlZHMgY2Fy ZWZ1bCBjb25zaWRlcmF0aW9uIGluCj7CoMKgwqAgcHJvdG9jb2wgZGVzaWduLsKgIE1ha2luZyBu ZXR3b3JrcyB1bm1hbmFnZWFibGUgaW4gb3JkZXIgdG8gbWl0aWdhdGUKPsKgwqDCoCBwZXJ2YXNp dmUgbW9uaXRvcmluZyB3b3VsZCBub3QgYmUgYW4gYWNjZXB0YWJsZSBvdXRjb21lLsKgIEJ1dAo+ wqDCoMKgIGVxdWFsbHksIGlnbm9yaW5nIHBlcnZhc2l2ZSBtb25pdG9yaW5nIGluIGRlc2lnbmlu ZyBuZXR3b3JrCj7CoMKgwqAgbWFuYWdlbWVudCBtZWNoYW5pc21zIHdvdWxkIGdvIGFnYWluc3Qg dGhlIGNvbnNlbnN1cyBkb2N1bWVudGVkIGluCj7CoMKgwqAgdGhpcyBCQ1AuwqAgQW4gYXBwcm9w cmlhdGUgYmFsYW5jZSB3aWxsIGxpa2VseSBlbWVyZ2Ugb3ZlciB0aW1lIGFzCj7CoMKgwqAgcmVh bCBpbnN0YW5jZXMgb2YgdGhpcyB0ZW5zaW9uIGFyZSBjb25zaWRlcmVkLgoKTkVXOgoKPsKgwqDC oCBNb3JlIGxpbWl0ZWQtc2NvcGUgbW9uaXRvcmluZyBvciBvdGhlciBzZXJ2aWNlcyBvciB0byBh c3Npc3Qgd2l0aAo+IG5ldHdvcmsgb3BlcmF0aW9ucyB0aGF0Cj7CoMKgwqAgaXMgcmVxdWlyZWQg aW4gb3JkZXIgdG8gb3BlcmF0ZSB0aGUgbmV0d29yayBvciBhbiBhcHBsaWNhdGlvbiBpcyBub3QK PsKgwqDCoCBjb25zaWRlcmVkIHBlcnZhc2l2ZSBtb25pdG9yaW5nLAo+wqDCoMKgIFRoZXJlIGlz IHRob3VnaCBhIGNsZWFyIHBvdGVudGlhbAo+wqDCoMKgIGZvciBzdWNoIG1lY2hhbmlzbXMgdG8g YmUgYWJ1c2VkIGFzIHBhcnQgb2YKPsKgwqDCoCBwZXJ2YXNpdmUgbW9uaXRvcmluZywgc28gdGhp cyB0ZW5zaW9uIG5lZWRzIGNhcmVmdWwgY29uc2lkZXJhdGlvbiBpbgo+wqDCoMKgIHByb3RvY29s IGRlc2lnbi7CoCBNYWtpbmcgbmV0d29ya3MgdW5tYW5hZ2VhYmxlIGluIG9yZGVyIHRvIG1pdGln YXRlCj7CoMKgwqAgcGVydmFzaXZlIG1vbml0b3Jpbmcgd291bGQgbm90IGJlIGFuIGFjY2VwdGFi bGUgb3V0Y29tZS7CoCBCdXQKPsKgwqDCoCBlcXVhbGx5LCBpZ25vcmluZyBwZXJ2YXNpdmUgbW9u aXRvcmluZyBpbiBkZXNpZ25pbmcgbmV0d29yawo+wqDCoMKgIG1hbmFnZW1lbnQgbWVjaGFuaXNt cyB3b3VsZCBnbyBhZ2FpbnN0IHRoZSBjb25zZW5zdXMgZG9jdW1lbnRlZCBpbgo+wqDCoMKgIHRo aXMgQkNQLsKgIEFuIGFwcHJvcHJpYXRlIGJhbGFuY2Ugd2lsbCBsaWtlbHkgZW1lcmdlIG92ZXIg dGltZSBhcwo+wqDCoMKgIHJlYWwgaW5zdGFuY2VzIG9mIHRoaXMgdGVuc2lvbiBhcmUgY29uc2lk ZXJlZC4KCkFuZCBzbyBzb21lb25lIG9wZXJhdGluZyBhIHNtYWxsIElTUCB3aXRoIGEgY2FjaGUg aW4gTWFkYWdhc2NhciBvciB0aGUKU1AgdHJ5aW5nIHRvIG1hbmFnZSBiYW5kd2lkdGggb24gYSB0 cmFpbiBjYW4gYWxzbyBoYXZlIHRoZWlyCmNvbnNpZGVyYXRpb25zIHRha2VuIGludG8gYWNjb3Vu dC7CoCBJdCdzIGZvciBhIHdvcmtpbmcgZ3JvdXAgdG8gZGVjaWRlCmhvdyBmYXIgdG8gYWNjb21t b2RhdGUgdGhlbSwgb2YgY291cnNlLgoKRWxpb3QKCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fCnBlcnBhc3MgbWFpbGluZyBsaXN0CnBlcnBhc3NAaWV0Zi5v cmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wZXJwYXNzCg== ----_com.android.email_1411917445541780 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keSA+PGRpdj5TbyBpZiB0aGUgIm9wZXJh dGlvbmFsIHJlYWxpdGllcyIgb2YgdGhlIG9wZXJhdG9yIGluY2x1ZGUgYSBtYW5kYXRlIHRvIGlu dGVyY2VwdCwgbGlrZSB3aXRoIGEgbGF3IGxpa2UgQ0FMRUEgaW4gdGhlIFVuaXRlZCBTdGF0ZXMs IHRoZW4gcGVydmFzaXZlIG1vbml0b3JpbmcgaXMgT0s/PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRp dj48YnI+PC9kaXY+U2VudCBmcm9tIG15IG1vYmlsZSBkZXZpY2UuIFRoYW5rcyBiZSB0byBMRU1P TkFERTogaHR0cDovL3d3dy5zdGFuZGFyZHN0cmFjay5jb20vaWV0Zi9sZW1vbmFkZTxkaXY+UzJF UkM6IGh0dHA6Ly9zMmVyYy5nZW9yZ2V0b3duLmVkdS88L2Rpdj48ZGl2PkdDU0M6IGh0dHA6Ly9n Y3NjLmdlb3JnZXRvd24uZWR1LzwvZGl2PjxkaXY+TWU6IGh0dHA6Ly93d3cuY3MuZ2VvcmdldG93 bi5lZHUvfiBlYnVyZ2VyPC9kaXY+PGJyPjxicj4tLS0tLS0tLSBPcmlnaW5hbCBtZXNzYWdlIC0t LS0tLS0tPGJyPkZyb206IEVsaW90IExlYXIgPGxlYXJAY2lzY28uY29tPiA8YnI+RGF0ZToxMi8w OS8yMDEzICA3OjI5IEFNICAoR01ULTA1OjAwKSA8YnI+VG86ICJpZXRmLWludGVyZXN0KG1haWxl ciBsaXN0KSIgPGlldGYtaW50ZXJlc3RAY2lzY28uY29tPixwZXJwYXNzIDxwZXJwYXNzQGlldGYu b3JnPiA8YnI+Q2M6IEludGVybmV0IEFyY2hpdGVjdHVyZSBCb2FyZCA8aWFiQGlhYi5vcmc+LCdJ RVNHJyA8aWVzZ0BpZXRmLm9yZz4gPGJyPlN1YmplY3Q6IFtwZXJwYXNzXSBjb21tZW50cyBhbmQg cXVlc3Rpb25zIGZvciB0aGUgZ3JvdXAgb24NIAlkcmFmdC1mYXJyZWxsLXBlcnBhc3MtYXR0YWNr LTAyIDxicj48YnI+VGhlc2UgY29tbWVudHMgZm9sbG93IGEgdGhyZWFkIGZyb20gdGhlIElBQi9J RVNHIG1haWxpbmcgbGlzdC48YnI+PGJyPlRoZXJlIGhhcyBiZWVuIHNvbWUgY29uZnVzaW9uIG92 ZXIgaG93IHRoaXMgcHJvcG9zZWQgQkNQIHNob3VsZCBiZSB0YWtlbjxicj5ieSB3b3JraW5nIGdy b3Vwcy4mbmJzcDsgQXQgbGVhc3Qgb25lIHdvcmtpbmcgZ3JvdXAgY2hhaXIgaGFzIGluZmVycmVk LCBpZjxicj5ub3Qgc3VnZ2VzdGVkLCB0aGF0IGEgZG9jdW1lbnQgYmVmb3JlIHRoZSBJRVNHIHRo YXQgZG9lcyBub3QgZGVtb25zdHJhdGU8YnI+aXQgaGFzIG1pdGlnYXRlZCBwZXJ2YXNpdmUgc3Vy dmVpbGxhbmNlIHdpbGwgZ2V0IHJldHVybmVkLiZuYnNwOyBUaGF0PGJyPndvdWxkbid0IGJlIGFw cHJvcHJpYXRlLCBpbiBteSBvcGluaW9uLiZuYnNwOyBBIHdvcmtpbmcgZ3JvdXAgbXVzdCBjb25z aWRlcjxicj50aGUgb3BlcmF0aW9uYWwgcmVhbGl0aWVzIHRoYXQgaXQgaXMgYXR0ZW1wdGluZyB0 byBjb2RlIHRvLiZuYnNwOyBUaGVyZSBhcmU8YnI+bWFueSB0ZW5zaW9ucyB0byBjb25zaWRlciwg bm90IGp1c3QgYSBuYXJyb3cgdmlldyBvZiBuZXR3b3JrIG1hbmFnZW1lbnQ8YnI+KGEgcGhyYXNl IHRoYXQgbWlnaHQgaXRzZWxmIGJlIGxlZnQgdG8gYW1iaWd1b3VzIGludGVycHJldGF0aW9uKS4m bmJzcDsgSTxicj5oYXZlIGluIG1pbmQgYXMgYW4gZXhhbXBsZSBhIHNlcnZpY2UgcHJvdmlkZXIg dGhhdCBkb2VzPGJyPnRyYW5zcGFyZW50L2ludGVyY2VwdGluZyBIVFRQIGNhY2hpbmcgZm9yIHB1 cnBvc2VzIG9mIGJhbmR3aWR0aDxicj5wcmVzZXJ2YXRpb24gaW4gYmFuZHdpZHRoLWNvbnN0cmFp bmVkIGVudmlyb25tZW50cy4mbmJzcDsgQW5vdGhlciBleGFtcGxlPGJyPndvdWxkIGJlIGFuIGVu dmlyb25tZW50IGluIHdoaWNoIHNlY3VyaXR5IGFuZCBnb3Zlcm5hbmNlIGFyZSBrZXkuPGJyPjxi cj5BcyBzdWNoLCBJIHByb3Bvc2UgdGhlIGZvbGxvd2luZyB0d28gY2hhbmdlcyB0byBjbGFyaWZ5 IHRoZSB0ZXh0IGluPGJyPlNlY3Rpb24gMjo8YnI+PGJyPjJuZCBwYXJhOjxicj48YnI+T0xEOjxi cj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoaXMgQkNQIHNpbXBseSByZWNvcmRzIHRoZSBjb25z ZW5zdXMgdG8gZGVzaWduPGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsgcHJvdG9jb2xzIHNvIGFz IHRvIG1pdGlnYXRlIHRoZSBhdHRhY2ssIHdoZXJlIHBvc3NpYmxlLjxicj48YnI+TkVXOjxicj48 YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBUaGlzIEJDUCBzaW1wbHkgcmVjb3JkcyB0aGUgY29u c2Vuc3VzIHRvIGRlc2lnbjxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHByb3RvY29scyBzbyBh cyB0byBtaXRpZ2F0ZSB0aGUgYXR0YWNrLCB0YWtpbmcgaW50byBhY2NvdW50PGJyPiZndDsgb3Bl cmF0aW9uYWwgcmVhbGl0aWVzIG9mIG5ldHdvcmsgb3BlcmF0b3JzLjxicj48YnI+TmV4dCBwYXJh Ojxicj48YnI+T0xEOjxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE1vcmUgbGltaXRlZC1zY29w ZSBtb25pdG9yaW5nIHRvIGFzc2lzdCB3aXRoIG5ldHdvcmsgbWFuYWdlbWVudCB0aGF0PGJyPiZn dDsmbmJzcDsmbmJzcDsmbmJzcDsgaXMgcmVxdWlyZWQgaW4gb3JkZXIgdG8gb3BlcmF0ZSB0aGUg bmV0d29yayBvciBhbiBhcHBsaWNhdGlvbiBpcyBub3Q8YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNw OyBjb25zaWRlcmVkIHBlcnZhc2l2ZSBtb25pdG9yaW5nLiZuYnNwOyBUaGVyZSBpcyB0aG91Z2gg YSBjbGVhciBwb3RlbnRpYWw8YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBmb3Igc3VjaCBsaW1p dGVkIG1vbml0b3JpbmcgbWVjaGFuaXNtcyB0byBiZSBhYnVzZWQgYXMgcGFydCBvZjxicj4mZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IHBlcnZhc2l2ZSBtb25pdG9yaW5nLCBzbyB0aGlzIHRlbnNpb24g bmVlZHMgY2FyZWZ1bCBjb25zaWRlcmF0aW9uIGluPGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsg cHJvdG9jb2wgZGVzaWduLiZuYnNwOyBNYWtpbmcgbmV0d29ya3MgdW5tYW5hZ2VhYmxlIGluIG9y ZGVyIHRvIG1pdGlnYXRlPGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsgcGVydmFzaXZlIG1vbml0 b3Jpbmcgd291bGQgbm90IGJlIGFuIGFjY2VwdGFibGUgb3V0Y29tZS4mbmJzcDsgQnV0PGJyPiZn dDsmbmJzcDsmbmJzcDsmbmJzcDsgZXF1YWxseSwgaWdub3JpbmcgcGVydmFzaXZlIG1vbml0b3Jp bmcgaW4gZGVzaWduaW5nIG5ldHdvcms8YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBtYW5hZ2Vt ZW50IG1lY2hhbmlzbXMgd291bGQgZ28gYWdhaW5zdCB0aGUgY29uc2Vuc3VzIGRvY3VtZW50ZWQg aW48YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyB0aGlzIEJDUC4mbmJzcDsgQW4gYXBwcm9wcmlh dGUgYmFsYW5jZSB3aWxsIGxpa2VseSBlbWVyZ2Ugb3ZlciB0aW1lIGFzPGJyPiZndDsmbmJzcDsm bmJzcDsmbmJzcDsgcmVhbCBpbnN0YW5jZXMgb2YgdGhpcyB0ZW5zaW9uIGFyZSBjb25zaWRlcmVk Ljxicj48YnI+TkVXOjxicj48YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBNb3JlIGxpbWl0ZWQt c2NvcGUgbW9uaXRvcmluZyBvciBvdGhlciBzZXJ2aWNlcyBvciB0byBhc3Npc3Qgd2l0aDxicj4m Z3Q7IG5ldHdvcmsgb3BlcmF0aW9ucyB0aGF0PGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsgaXMg cmVxdWlyZWQgaW4gb3JkZXIgdG8gb3BlcmF0ZSB0aGUgbmV0d29yayBvciBhbiBhcHBsaWNhdGlv biBpcyBub3Q8YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBjb25zaWRlcmVkIHBlcnZhc2l2ZSBt b25pdG9yaW5nLDxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoZXJlIGlzIHRob3VnaCBhIGNs ZWFyIHBvdGVudGlhbDxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGZvciBzdWNoIG1lY2hhbmlz bXMgdG8gYmUgYWJ1c2VkIGFzIHBhcnQgb2Y8YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBwZXJ2 YXNpdmUgbW9uaXRvcmluZywgc28gdGhpcyB0ZW5zaW9uIG5lZWRzIGNhcmVmdWwgY29uc2lkZXJh dGlvbiBpbjxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHByb3RvY29sIGRlc2lnbi4mbmJzcDsg TWFraW5nIG5ldHdvcmtzIHVubWFuYWdlYWJsZSBpbiBvcmRlciB0byBtaXRpZ2F0ZTxicj4mZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IHBlcnZhc2l2ZSBtb25pdG9yaW5nIHdvdWxkIG5vdCBiZSBhbiBh Y2NlcHRhYmxlIG91dGNvbWUuJm5ic3A7IEJ1dDxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGVx dWFsbHksIGlnbm9yaW5nIHBlcnZhc2l2ZSBtb25pdG9yaW5nIGluIGRlc2lnbmluZyBuZXR3b3Jr PGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsgbWFuYWdlbWVudCBtZWNoYW5pc21zIHdvdWxkIGdv IGFnYWluc3QgdGhlIGNvbnNlbnN1cyBkb2N1bWVudGVkIGluPGJyPiZndDsmbmJzcDsmbmJzcDsm bmJzcDsgdGhpcyBCQ1AuJm5ic3A7IEFuIGFwcHJvcHJpYXRlIGJhbGFuY2Ugd2lsbCBsaWtlbHkg ZW1lcmdlIG92ZXIgdGltZSBhczxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHJlYWwgaW5zdGFu Y2VzIG9mIHRoaXMgdGVuc2lvbiBhcmUgY29uc2lkZXJlZC48YnI+PGJyPkFuZCBzbyBzb21lb25l IG9wZXJhdGluZyBhIHNtYWxsIElTUCB3aXRoIGEgY2FjaGUgaW4gTWFkYWdhc2NhciBvciB0aGU8 YnI+U1AgdHJ5aW5nIHRvIG1hbmFnZSBiYW5kd2lkdGggb24gYSB0cmFpbiBjYW4gYWxzbyBoYXZl IHRoZWlyPGJyPmNvbnNpZGVyYXRpb25zIHRha2VuIGludG8gYWNjb3VudC4mbmJzcDsgSXQncyBm b3IgYSB3b3JraW5nIGdyb3VwIHRvIGRlY2lkZTxicj5ob3cgZmFyIHRvIGFjY29tbW9kYXRlIHRo ZW0sIG9mIGNvdXJzZS48YnI+PGJyPkVsaW90PGJyPjxicj5fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxicj5wZXJwYXNzIG1haWxpbmcgbGlzdDxicj5wZXJw YXNzQGlldGYub3JnPGJyPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGVy cGFzczxicj48L2JvZHk+ ----_com.android.email_1411917445541780-- From hallam@gmail.com Mon Dec 9 04:55:03 2013 Return-Path: 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 57D831AE2B3 for ; Mon, 9 Dec 2013 04:55:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 keN8igWjURcW for ; Mon, 9 Dec 2013 04:55:01 -0800 (PST) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 390321AE2AF for ; Mon, 9 Dec 2013 04:55:01 -0800 (PST) Received: by mail-we0-f182.google.com with SMTP id q59so3413724wes.27 for ; Mon, 09 Dec 2013 04:54:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XJDYBdR7McZnxn87q7Xw23QxY+RE5PdBG4mg3SiDUT4=; b=mkVL6OzGvoE0lV3KNTpERvV1iUHETY0aNhNZYUbHPQrP62J4qbtckyZMx+eAnJ+saI rtACErMUMO9YPRoLRB7+kW2T1Do3aKnP/d1p5R4NzJNTo3f6qhqMfNHsr/+tAZ/VnF+t CB9WjRGXzyC7w1+2QzbrQzsVIDmIIpg6Dny9TKx8U17jfUj6/QR/dyPbFxIn7+hbcmdH gFNY3KylvEqMH1SmG0s83sx+gczRIeBSRAnmlJJfICP0CGJT3J++QcCQjXGwdnmpvRap v6gwB1f2Yk8NFzOBCCi6LdXYopEgV7uKDXeS08XgC0MDzl1Ir/XSUxfQR+3VJY63rb2n Gpww== MIME-Version: 1.0 X-Received: by 10.180.107.168 with SMTP id hd8mr14024910wib.32.1386593695917; Mon, 09 Dec 2013 04:54:55 -0800 (PST) Received: by 10.194.243.136 with HTTP; Mon, 9 Dec 2013 04:54:55 -0800 (PST) In-Reply-To: <4613980CFC78314ABFD7F85CC302772121B1EC40@IL-EX10.ad.checkpoint.com> References: <0FE7905C-950F-4030-8A47-37C523FB497A@doubleshotsecurity.com> <95276F1E-2293-41F3-A6E7-7AEF4B22E811@doubleshotsecurity.com> <4613980CFC78314ABFD7F85CC302772121B1EC40@IL-EX10.ad.checkpoint.com> Date: Mon, 9 Dec 2013 07:54:55 -0500 Message-ID: From: Phillip Hallam-Baker To: Yoav Nir Content-Type: multipart/alternative; boundary=e89a8f2356dfb1780604ed198031 Cc: perpass , Merike Kaeo Subject: Re: [perpass] NULL Cipher RFC 2410 to HISTORIC ??? 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 12:55:03 -0000 --e89a8f2356dfb1780604ed198031 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Dec 9, 2013 at 2:23 AM, Yoav Nir wrote: > Phil, > > The issue is not that ESP needs a NULL cipher. It's that AH wouldn't > traverse NAT, and so they needed ESP to do the work that AH was designed to > do. > I understand that, though the fact that ESP with authentication would work through NAT but not AH seems remarkably odd to me. It suggests that the design is wrong. That flags a design error in the protocol AFIAK. As a remote access protocol, IPSEC has fallen far short of satisfactory. It has been necessary to install a plug in to use every corporate VPN I have used to date. > But beyond that little technicality, it stands out that they standardized > AH at all. So they felt that there was a need for integrity-only IPsec. I > guess part of this is that the perceived threats were different - there was > less personal information on the Internet, and IPsec (unlike TLS) is much > concerned with protecting non-confidential stuff like DNS, routing > protocols. Today, about the only good use case I can think of that doesn't > ever need confidentiality is NTP, and I don't know why we would want to > design a protocol specifically for securing NTP. > And to do authentication only twice seems even stranger. > Another part is that this was 1996 and in 1996 you had the "Pentium Pro" > with a 150 MHz clock and a 60 MHz bus, which could probably do a few Mbps > of 3DES+HMAC-MD5, or four times that with HMAC-MD5 alone. These are not > today's processors that do 4 Gbps per core with AES-GCM. > That is not the motivation that the RFC suggests. > BTW: this is not unique to IPsec. TLS also defines some NULL encryption > ciphersuites. > I know, but the problem is that people are now pointing to the NULL ciphers as precedent. -- Website: http://hallambaker.com/ --e89a8f2356dfb1780604ed198031 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On M= on, Dec 9, 2013 at 2:23 AM, Yoav Nir <ynir@checkpoint.com>= wrote:
Phil,

The issue is not that ESP needs a NULL cipher. It's that AH wouldn'= t traverse NAT, and so they needed ESP to do the work that AH was designed = to do.

I understand that, though the fa= ct that ESP with authentication would work through NAT but not AH seems rem= arkably odd to me. It suggests that the design is wrong.

That flags a design error in the protocol AFIAK.=A0

As a remote access protocol, IPSEC has fallen far sho= rt of satisfactory. It has been necessary to install a plug in to use every= corporate VPN I have used to date.

=A0
But beyond that little technicality, it stands out that they standardized A= H at all. So they felt that there was a need for integrity-only IPsec. I gu= ess part of this is that the perceived threats were different - there was l= ess personal information on the Internet, and IPsec (unlike TLS) is much co= ncerned with protecting non-confidential stuff like DNS, routing protocols.= Today, about the only good use case I can think of that doesn't ever n= eed confidentiality is NTP, and I don't know why we would want to desig= n a protocol specifically for securing NTP.

And to do authentication only twice seems = even stranger.

=A0
Another part is that this was 1996 and in 1996 you had the "Pentium Pr= o" with a 150 MHz clock and a 60 MHz bus, which could probably do a fe= w Mbps of 3DES+HMAC-MD5, or four times that with HMAC-MD5 alone. These are = not today's processors that do 4 Gbps per core with AES-GCM.

That is not the motivation that the RFC su= ggests.

=A0
BTW: this is not unique to IPsec. TLS also defines some NULL encryption cip= hersuites.

I know, but the problem is t= hat people are now pointing to the NULL ciphers as precedent.



--
Website: http://hallambaker.com/
--e89a8f2356dfb1780604ed198031-- From wilton@isoc.org Mon Dec 9 04:56:51 2013 Return-Path: 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 BA28A1ADF32; Mon, 9 Dec 2013 04:56:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 1lym-0FhBsGa; Mon, 9 Dec 2013 04:56:49 -0800 (PST) Received: from smtp94.iad3a.emailsrvr.com (smtp94.iad3a.emailsrvr.com [173.203.187.94]) by ietfa.amsl.com (Postfix) with ESMTP id 56D4A1ADF6C; Mon, 9 Dec 2013 04:56:49 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp12.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 8F86CF00C2; Mon, 9 Dec 2013 07:56:44 -0500 (EST) X-Virus-Scanned: OK Received: by smtp12.relay.iad3a.emailsrvr.com (Authenticated sender: wilton-AT-isoc.org) with ESMTPSA id 32205F00A5; Mon, 9 Dec 2013 07:56:44 -0500 (EST) References: <52A5B79E.2040202@cisco.com> In-Reply-To: <52A5B79E.2040202@cisco.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <2FF9686C-7DEA-42E3-B2FA-DCD72A5E5168@isoc.org> X-Mailer: iPad Mail (9B206) From: Robin Wilton Date: Mon, 9 Dec 2013 14:00:49 +0100 To: Eliot Lear Cc: "ietf-interest\(mailer list\)" , perpass , Internet Architecture Board , IESG Subject: Re: [perpass] comments and questions for the group on draft-farrell-perpass-attack-02 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 12:56:51 -0000 Eliot,=20 I think your second edit is probably too broad, in the sense that it could c= reate quite a lot of room for abuse. You currently have: >> More limited-scope monitoring or other services or to assist with >> network operations that >> is required in order to operate the network or an application is not >> considered pervasive monitoring I would suggest something along the following lines. The first part is just a= rewording of your text; the part in square brackets is prompted by what I t= hink we can learn from existing approaches to pervasive monitoring. Where monitoring is of limited scope, or services in support of network oper= ations are required in order to operate the network, these are not necessari= ly to be considered de facto pervasive monitoring [; however, thought should= be given to whether they enable pervasive monitoring, either directly or as= a by-product of their primary purpose]. I hope this is helpful, Robin Robin Wilton Technical Outreach Director - Identity and Privacy On 9 Dec 2013, at 13:29, Eliot Lear wrote: > These comments follow a thread from the IAB/IESG mailing list. >=20 > There has been some confusion over how this proposed BCP should be taken > by working groups. At least one working group chair has inferred, if > not suggested, that a document before the IESG that does not demonstrate > it has mitigated pervasive surveillance will get returned. That > wouldn't be appropriate, in my opinion. A working group must consider > the operational realities that it is attempting to code to. There are > many tensions to consider, not just a narrow view of network management > (a phrase that might itself be left to ambiguous interpretation). I > have in mind as an example a service provider that does > transparent/intercepting HTTP caching for purposes of bandwidth > preservation in bandwidth-constrained environments. Another example > would be an environment in which security and governance are key. >=20 > As such, I propose the following two changes to clarify the text in > Section 2: >=20 > 2nd para: >=20 > OLD: >> This BCP simply records the consensus to design >> protocols so as to mitigate the attack, where possible. >=20 > NEW: >=20 >> This BCP simply records the consensus to design >> protocols so as to mitigate the attack, taking into account >> operational realities of network operators. >=20 > Next para: >=20 > OLD: >> More limited-scope monitoring to assist with network management that >> is required in order to operate the network or an application is not >> considered pervasive monitoring. There is though a clear potential >> for such limited monitoring mechanisms to be abused as part of >> pervasive monitoring, so this tension needs careful consideration in >> protocol design. Making networks unmanageable in order to mitigate >> pervasive monitoring would not be an acceptable outcome. But >> equally, ignoring pervasive monitoring in designing network >> management mechanisms would go against the consensus documented in >> this BCP. An appropriate balance will likely emerge over time as >> real instances of this tension are considered. >=20 > NEW: >=20 >> More limited-scope monitoring or other services or to assist with >> network operations that >> is required in order to operate the network or an application is not >> considered pervasive monitoring, >> There is though a clear potential >> for such mechanisms to be abused as part of >> pervasive monitoring, so this tension needs careful consideration in >> protocol design. Making networks unmanageable in order to mitigate >> pervasive monitoring would not be an acceptable outcome. But >> equally, ignoring pervasive monitoring in designing network >> management mechanisms would go against the consensus documented in >> this BCP. An appropriate balance will likely emerge over time as >> real instances of this tension are considered. >=20 > And so someone operating a small ISP with a cache in Madagascar or the > SP trying to manage bandwidth on a train can also have their > considerations taken into account. It's for a working group to decide > how far to accommodate them, of course. >=20 > Eliot >=20 > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass From stephen.farrell@cs.tcd.ie Mon Dec 9 05:23:44 2013 Return-Path: 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 B6DA31ADF87 for ; Mon, 9 Dec 2013 05:23:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DPiMB8xzAvs3 for ; Mon, 9 Dec 2013 05:23:42 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 385751ADF75 for ; Mon, 9 Dec 2013 05:23:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 3709EBE55; Mon, 9 Dec 2013 13:23:37 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qC0WMm+g2pJa; Mon, 9 Dec 2013 13:23:37 +0000 (GMT) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 176E9BE1C; Mon, 9 Dec 2013 13:23:37 +0000 (GMT) Message-ID: <52A5C458.200@cs.tcd.ie> Date: Mon, 09 Dec 2013 13:23:36 +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: Eliot Lear , perpass References: <52A5B79E.2040202@cisco.com> In-Reply-To: <52A5B79E.2040202@cisco.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [perpass] comments and questions for the group on draft-farrell-perpass-attack-02 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 13:23:44 -0000 Hi Eliot, I've trimmed the cc list to perpass. (I'll send a link to your mail to ietf@ietf.org which is arguably where this discussion should happen since the draft is in IETF LC. But I guess most of the folks who care are on here too so its not a huge deal.) On 12/09/2013 12:29 PM, Eliot Lear wrote: > These comments follow a thread from the IAB/IESG mailing list. > > There has been some confusion over how this proposed BCP should be taken > by working groups. At least one working group chair has inferred, if > not suggested, that a document before the IESG that does not demonstrate > it has mitigated pervasive surveillance will get returned. Can we establish the reality here? The chair you mean is Mark Nottingham in this [1] mail to the httpbis list. [1] http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1453.html I definitely did not read him the way you appear to have and that distinction matters. If you are the only one to take him as saying that then I guess you'd agree that your changes would be based on a fallacy. Maybe Mark can clarify but I think its already crystal clear that he was not saying "ignore everything else" - I'd be stunned if that was what he meant. And I'm sure even if it were, the httpbis WG participants would either ignore that or beat him up for it (which they've not done). That said, it is clear that individual WGs and other IETF activities will have to figure out what it means to properly consider pervasive monitoring as an attack, but the draft says that already I think. What I read Mark as saying was that if the httpbis WG ignored or didn't properly consider pervasive monitoring and if this BCP gets approved then that could impact on their schedule. There's nothing surprising there at all IMO. > That > wouldn't be appropriate, in my opinion. A working group must consider > the operational realities that it is attempting to code to. There are > many tensions to consider, not just a narrow view of network management > (a phrase that might itself be left to ambiguous interpretation). "Operational realities" is far more vague IMO. Perhaps even dangerously so since it could be used to attempt to justify pretty much anything. And as Eric Burger already noted, what you propose would also seem to fly in the face of RFC 2804, which is entirely antithetical to the intent of this draft. I think the current wording is much better than your proposed changes. > I > have in mind as an example a service provider that does > transparent/intercepting HTTP caching for purposes of bandwidth > preservation in bandwidth-constrained environments. The httpbis WG are discussing how to handle proxies. That's a complex and involved thread and I don't think any of us will benefit from re-running the discussion here. Folks who care about that should subscribe to that list and discuss it there. > Another example > would be an environment in which security and governance are key. I've no idea what that means. If you mean something that's broader than http, then what? If you just mean for http then again that's better dealt with in httpbis. > > As such, I propose the following two changes to clarify the text in > Section 2: > > 2nd para: > > OLD: >> This BCP simply records the consensus to design >> protocols so as to mitigate the attack, where possible. > > NEW: > >> This BCP simply records the consensus to design >> protocols so as to mitigate the attack, taking into account >> operational realities of network operators. > > Next para: > > OLD: >> More limited-scope monitoring to assist with network management that >> is required in order to operate the network or an application is not >> considered pervasive monitoring. There is though a clear potential >> for such limited monitoring mechanisms to be abused as part of >> pervasive monitoring, so this tension needs careful consideration in >> protocol design. Making networks unmanageable in order to mitigate >> pervasive monitoring would not be an acceptable outcome. But >> equally, ignoring pervasive monitoring in designing network >> management mechanisms would go against the consensus documented in >> this BCP. An appropriate balance will likely emerge over time as >> real instances of this tension are considered. > > NEW: > >> More limited-scope monitoring or other services or to assist with >> network operations that >> is required in order to operate the network or an application is not >> considered pervasive monitoring, >> There is though a clear potential >> for such mechanisms to be abused as part of >> pervasive monitoring, so this tension needs careful consideration in >> protocol design. Making networks unmanageable in order to mitigate >> pervasive monitoring would not be an acceptable outcome. But >> equally, ignoring pervasive monitoring in designing network >> management mechanisms would go against the consensus documented in >> this BCP. An appropriate balance will likely emerge over time as >> real instances of this tension are considered. To be clear, I'd prefer we make neither change. > And so someone operating a small ISP with a cache in Madagascar or the > SP trying to manage bandwidth on a train can also have their > considerations taken into account. It's for a working group to decide > how far to accommodate them, of course. And that's already clearly the case. This proposed BCP doesn't do away with either working groups or common sense. S. > > Eliot > > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > > From kathleen.moriarty@emc.com Mon Dec 9 05:44:09 2013 Return-Path: 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 ED8D71AE2CB for ; Mon, 9 Dec 2013 05:44:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 O4aMjhzCD_ZN for ; Mon, 9 Dec 2013 05:44:04 -0800 (PST) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) by ietfa.amsl.com (Postfix) with ESMTP id 1B7201ADF75 for ; Mon, 9 Dec 2013 05:44:03 -0800 (PST) Received: from maildlpprd54.lss.emc.com (maildlpprd54.lss.emc.com [10.106.48.158]) by mailuogwprd52.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id rB9DgfK6023630 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Dec 2013 08:42:44 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com rB9DgfK6023630 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1386596564; bh=hD0rbQyBTdclCy7at0Uuvxxgmok=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=R3Jb5F7lBq8upRyNKKyXukPaLfvmYWUn3QPPstrybudjyvtDjh4VegG+rfHIHZvrg xRGQ2X0hoh0BCPZtsvdkN52KUynwI9C11z1ex1K/sz7dcKtZhDf/Qv0WX5kfuhNXek zlkJTxi4xOCsNLwIgh5MRjzY2yezJg2iQ+YdVbBQ= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com rB9DgfK6023630 Received: from mailusrhubprd01.lss.emc.com (mailusrhubprd01.lss.emc.com [10.253.24.19]) by maildlpprd54.lss.emc.com (RSA Interceptor); Mon, 9 Dec 2013 08:42:25 -0500 Received: from mxhub10.corp.emc.com (mxhub10.corp.emc.com [10.254.92.105]) by mailusrhubprd01.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id rB9DgOmp015464 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 9 Dec 2013 08:42:24 -0500 Received: from mx15a.corp.emc.com ([169.254.1.239]) by mxhub10.corp.emc.com ([10.254.92.105]) with mapi; Mon, 9 Dec 2013 08:42:24 -0500 From: "Moriarty, Kathleen" To: Merike Kaeo , perpass Date: Mon, 9 Dec 2013 08:42:23 -0500 Thread-Topic: [perpass] NULL Cipher RFC 2410 to HISTORIC ??? Thread-Index: Ac70ncUZmI8Ys0PAQjClc61OxkhmdgARY7RQ Message-ID: References: <0FE7905C-950F-4030-8A47-37C523FB497A@doubleshotsecurity.com> <95276F1E-2293-41F3-A6E7-7AEF4B22E811@doubleshotsecurity.com> In-Reply-To: <95276F1E-2293-41F3-A6E7-7AEF4B22E811@doubleshotsecurity.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_F5063677821E3B4F81ACFB7905573F240654095E9CMX15Acorpemcc_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd01.lss.emc.com X-RSA-Classifications: public Cc: Phillip Hallam-Baker , Hannes Tschofenig , Nicholas Weaver , Stephen Farrell Subject: Re: [perpass] NULL Cipher RFC 2410 to HISTORIC ??? 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 13:44:09 -0000 --_000_F5063677821E3B4F81ACFB7905573F240654095E9CMX15Acorpemcc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I only configured an AH only session once around 2000, but lots of other IP= Sec sessions using ESP. The purpose of the AH only session was to make sur= e a public data file that was transferred was not altered or corrupted befo= re it was used in automated analytics. The use case made perfect sense, bu= t most people were not thinking about that usage at the time. This probabl= y fits into your description when people thought ESP alone would be relevan= t, hence a NULL cipher. The issue here was not NAT, but maybe it was for o= thers. I think this use case just wasn't a big concern and most people did= n't think to protect the integrity of transfers of public data files at the= time. Best regards, Kathleen From: perpass [mailto:perpass-bounces@ietf.org] On Behalf Of Merike Kaeo Sent: Monday, December 09, 2013 12:12 AM To: perpass Cc: Nicholas Weaver; Hannes Tschofenig; Phillip Hallam-Baker; Stephen Farre= ll Subject: Re: [perpass] NULL Cipher RFC 2410 to HISTORIC ??? And so I reply to myself but got curious and wanted evidence. I found firs= t references of AH/ESP and NULL in 1996 June IPsec archives. http://www.sa= ndelman.ottawa.on.ca/ipsec/1996/06/msg00030.html And while some interesting tidbits, the joggle for my memory banks was tha= t there was a bunch of discussion on where AH would be used with ESP and wh= ether ESP only would also be relevant. And while I couldn't find exact ref= erence to the March 1998 interop testing in North Carolina that showed issu= es with AH not traversing NATs I am fairly certain that was the case and wh= y in practice people starting using ESP-Null. (it wasn't in the notes for = the follow-up IETF IPsec meeting). Someone else from that time may also be able to chime in. - merike On Dec 8, 2013, at 8:19 PM, Merike Kaeo > wrote: Apologies in advance for top-posting. I keep meaning to get caught up on t= his mailing list but never quite manage it. However, the IPsec NULL is som= ething that I see so misrepresented everywhere that I wanted to chime in. I= t was to the best of my recollection developed after the 1998 bake-off in C= ary North Carolina (I was there) to enable integrity protection thru NAT's.= AH had issues transversing NAT devices which if some others of you were a= round will remember was a technology that was just taking off at that time.= It was felt that using the NULL encryption gave you at least integrity p= rotection for the data even though it did not protect the IP addresses (or = anything else that was part of the IP header that wasn't morphed in transit= ). However, for anyone who is very well versed with IPsec, you will note t= hat if a SPD requires IP src and dst address as well as SPI, then the IP ad= dresses are implicitly protected. Note that the NAT traversal protocol had= its beginnings from that 1998 event as well. Also please remember that at the time IPsec was being developed there were = still global import/export restrictions relating to cryptographic protectio= n. Not just in the US mind you....I have a table in a book I wrote in 1999= that actually listed a bunch of countries and the restrictions at that tim= e. There typically wasn't a restriction on key length for cryptographicall= y protected integrity protocols but there was one for cryptographically pro= tected confidentiality (i.e. encryption) protocols. In the US it was 40 bi= t restriction on encryption. I believe for some *limited* subset of countr= ies this is still true for US export controls on cryptography today. Anyhow...just to get some of the history straight. And I speak as someone = who was at cisco at the time and did a lot of performance and interoperabil= ity testing....and sat in the back of the room at *all* of the IPsec meetin= gs since the original BoF back in 1993/4 and discussed issues in background= (I don't write code....but can find bugs :)). And as someone who spent we= ll over a decade trying to get vendors and users to understand issues of IP= sec implementations and usability in a v6 world [while an independent consu= ltant]. I gave up 4 years ago. And FWIW, for IPsec the primary deployment issues are in implementation ter= minology and interoperable defaults. I will gladly argue that point over b= eers anytime. - merike On Dec 8, 2013, at 5:52 PM, Phillip Hallam-Baker > wrote: On Sun, Dec 8, 2013 at 5:00 PM, Hannes Tschofenig > wrote: Hi Stephen, Hi Nicholas, it would be interesting (as a history lesson) if someone could tell us why = the group at that time decided to develop a NULL encryption mechanism. Step= hen Kent (co-author of RFC 2410) might remember. I have no heard It was for testing and it all happened long before any of the evidence of t= he NSA peddling bongoed crypto suggests that it was going on. I think it hi= ghly unlikely that anything of the sort was going on before 9/11 and my sou= rces claim that the change came much later, if it happened at all. I really don't think that any of the people involved in IETF process have h= ad a hand in knowingly peddling bongoed crypto either. But as I have been m= aking plain in another forum, the slides openly bragging about such an oper= ation have had a serious cost in terms of erosion of trust. I think any interference would have been 'action at a distance'. Rather tha= n come here and make the case for protecting some hole that was going to be= used to propagate Flame, I would expect the NSA people running the DoD CA = would call up their contacts in IETF space and make up some story about the= ir operational difficulties caused by still running the old Netscape CA tha= t hasn't been maintained for a decade now or some such hokum. I can't see how that sort of cover story would work for peddling a NULL cip= her. There are some vulnerabilities I think can be laid at their door but n= ot that one. We did that one to ourselves. IPSEC is sufficiently complicated that interop is a non trivial problem. Or= at least the people who implemented it found it to be so. Some people trie= d to make the same suggestion for S/MIME (and people might remember my reac= tion). Having a NULL cipher for interop testing was not an unfounded propos= al but it was certainly never one I supported. Remember that IPSEC has always supported an 'authentication only' mode. So = turning on encryption with a null cipher was not an obvious difference. In = fact it would probably have made sense to have killed the integrity only op= tion at the start and just had a null cipher. Perhaps we should write a draft and move it to HISTORIC, just to avoid any = confusion. In context of our discussion on this list the answer will give us a lot of = guidance for the future. Even 2 years ago I had lots of people arguing in = the OAuth working group that authentication and integrity protection is suf= ficient and that we do not need confidentiality protection. So, I wouldn't = be surprised if the same argument showed up 10 years earlier. That is a different argument and maybe there is a case to be made for relyi= ng on HTTPS. I don't like that approach, in fact I super-encrypt within HTT= PS quite often and always super-authenticate end to end in my Web Services. -- Website: http://hallambaker.com/ _______________________________________________ perpass mailing list perpass@ietf.org https://www.ietf.org/mailman/listinfo/perpass _______________________________________________ perpass mailing list perpass@ietf.org https://www.ietf.org/mailman/listinfo/perpass --_000_F5063677821E3B4F81ACFB7905573F240654095E9CMX15Acorpemcc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I only co= nfigured an AH only session once around 2000, but lots of other IPSec sessi= ons using ESP.  The purpose of the AH only session was to make sure a = public data file that was transferred was not altered or corrupted before i= t was used in automated analytics.  The use case made perfect sense, b= ut most people were not thinking about that usage at the time.  This p= robably fits into your description when people thought ESP alone would be r= elevant, hence a NULL cipher.  The issue here was not NAT, but maybe i= t was for others.  I think this use case just wasn’t a big conce= rn and most people didn’t think to protect the integrity of transfers= of public data files at the time.

 

Best regar= ds,

Kathleen

 

From: perpass [mailto:perpass-bounces@ietf.org] On= Behalf Of Merike Kaeo
Sent: Monday, December 09, 2013 12:12 = AM
To: perpass
Cc: Nicholas Weaver; Hannes Tschofenig; = Phillip Hallam-Baker; Stephen Farrell
Subject: Re: [perpass] NULL= Cipher RFC 2410 to HISTORIC ???

 

And so I reply to my= self but got curious and wanted evidence.  I found first references of= AH/ESP and NULL in 1996 June IPsec archives.  http://www.sandelman.ott= awa.on.ca/ipsec/1996/06/msg00030.html

 

And while  = ;some interesting tidbits, the joggle for my memory banks was that there wa= s a bunch of discussion on where AH would be used with ESP and whether ESP = only would also be relevant.  And while I couldn't find exact referenc= e to the March 1998 interop testing in North Carolina that showed issues wi= th AH not traversing NATs I am fairly certain that was the case and why in = practice people starting using ESP-Null.  (it wasn't in the notes for = the follow-up IETF IPsec meeting).

=  

Someone else from that= time may also be able to chime in.

 

- merike

 

 

On De= c 8, 2013, at 8:19 PM, Merike Kaeo <merike@doubleshotsecurity.com> wrote:



Ap= ologies in advance for top-posting.  I keep meaning to get caught up o= n this mailing list but never quite manage it.  However, the IPsec NUL= L is something that I see so misrepresented everywhere that I wanted to chi= me in. It was to the best of my recollection developed after the 1998 bake-= off in Cary North Carolina (I was there) to enable integrity protection thr= u NAT's.  AH had issues transversing NAT devices which if some others = of you were around will remember was a technology that was just taking off = at that time.   It was felt that using the NULL encryption gave you at= least integrity protection for the data even though it did not protect the= IP addresses (or anything else that was part of the IP header that wasn't = morphed in transit).  However, for anyone who is very well versed with= IPsec, you will note that if a SPD requires IP src and dst address as well= as SPI, then the IP addresses are implicitly protected.  Note that th= e NAT traversal protocol had its beginnings from that 1998 event as well.

 

Also please remember that at the time IPsec was being deve= loped there were still global import/export restrictions relating to crypto= graphic protection.  Not just in the US mind you….I have a table= in a book I wrote in 1999 that actually listed a bunch of countries and th= e restrictions at that time.  There typically wasn't a restriction on = key length for cryptographically protected integrity protocols but there wa= s one for cryptographically protected confidentiality (i.e. encryption) pro= tocols.  In the US it was 40 bit restriction on encryption.  I be= lieve for some *limited* subset of countries this is still true for US expo= rt controls on cryptography today.

 

Anyhow…jus= t to get some of the history straight.  And I speak as someone who was= at cisco at the time and did a lot of performance and interoperability tes= ting….and sat in the back of the room at *all* of the IPsec meetings = since the original BoF back in 1993/4 and discussed issues in background (I= don't write code….but can find bugs :)).  And as someone who sp= ent well over a decade trying to get vendors and users to understand issues= of IPsec implementations and usability in a v6 world [while an independent= consultant].  I gave up 4 years ago.

 

And FWIW= , for IPsec the primary deployment issues are in implementation terminology= and interoperable defaults.  I will gladly argue that point over beer= s anytime. 

 <= /o:p>

- merike

 

&n= bsp;

On Dec 8, 2013, at 5:52 PM, Ph= illip Hallam-Baker <hallam@gmail.com= > wrote:



On Sun, Dec 8, 2013 at 5:00 PM, Ha= nnes Tschofenig <hannes.tschofenig@gmx.net> wrote:

Hi Stephen, Hi Nicholas,

it would be interesting (as = a history lesson) if someone could tell us why the group at that time decid= ed to develop a NULL encryption mechanism. Stephen Kent (co-author of RFC 2= 410) might remember. I have no heard

 

It was for te= sting and it all happened long before any of the evidence of the NSA peddli= ng bongoed crypto suggests that it was going on. I think it highly unlikely= that anything of the sort was going on before 9/11 and my sources claim th= at the change came much later, if it happened at all.

<= div>

 

I really don't think that any of the people involved in IETF process hav= e had a hand in knowingly peddling bongoed crypto either. But as I have bee= n making plain in another forum, the slides openly bragging about such an o= peration have had a serious cost in terms of erosion of trust.

 

I think any interference would have been 'action at a distance= '. Rather than come here and make the case for protecting some hole that wa= s going to be used to propagate Flame, I would expect the NSA people runnin= g the DoD CA would call up their contacts in IETF space and make up some st= ory about their operational difficulties caused by still running the old Ne= tscape CA that hasn't been maintained for a decade now or some such hokum.<= o:p>

 

I can't see how that sort of cover story would work= for peddling a NULL cipher. There are some vulnerabilities I think can be = laid at their door but not that one. We did that one to ourselves.

 

 

IPSEC = is sufficiently complicated that interop is a non trivial problem. Or at le= ast the people who implemented it found it to be so. Some people tried to m= ake the same suggestion for S/MIME (and people might remember my reaction).= Having a NULL cipher for interop testing was not an unfounded proposal but= it was certainly never one I supported.

 

Remember = that IPSEC has always supported an 'authentication only' mode. So turning o= n encryption with a null cipher was not an obvious difference. In fact it w= ould probably have made sense to have killed the integrity only option at t= he start and just had a null cipher.

 

 

Perhaps we should write a draft and = move it to HISTORIC, just to avoid any confusion.

=

 

&= nbsp;

In context of our discussion on this list the = answer will give us a lot of guidance for the future.  Even 2 years ag= o I had lots of people arguing in the OAuth working group that authenticati= on and integrity protection is sufficient and that we do not need confident= iality protection. So, I wouldn't be surprised if the same argument showed = up 10 years earlier.

 

That is a differ= ent argument and maybe there is a case to be made for relying on HTTPS. I d= on't like that approach, in fact I super-encrypt within HTTPS quite often a= nd always super-authenticate end to end in my Web Services.

<= /div>

 

 

 

 

--
Website: http= ://hallambaker.com/

____= ___________________________________________
perpass mailing list
perpass@ietf.org
https://www.ietf.org/mailman/listinf= o/perpass

 

___________________________________= ____________
perpass mailing list
perpass@ietf.org
https://www.ietf.org/mailman/listinfo/perpass

 

= --_000_F5063677821E3B4F81ACFB7905573F240654095E9CMX15Acorpemcc_-- From ynir@checkpoint.com Mon Dec 9 05:48:53 2013 Return-Path: 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 ECF591AE2C5 for ; Mon, 9 Dec 2013 05:48:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 YumPUysKgCPs for ; Mon, 9 Dec 2013 05:48:51 -0800 (PST) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id CACF71AE2BF for ; Mon, 9 Dec 2013 05:48:50 -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 rB9DmIKh029297; Mon, 9 Dec 2013 15:48:19 +0200 X-CheckPoint: {52A5C6B7-F-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; Mon, 9 Dec 2013 15:47:13 +0200 From: Yoav Nir To: Phillip Hallam-Baker Thread-Topic: [perpass] NULL Cipher RFC 2410 to HISTORIC ??? Thread-Index: AQHO9IFu4/5YzgvJX0aB14ruAS2e45pLIR6AgAAOqACAAAmtAIAAOKIwgAA/GICAAA6bAA== Date: Mon, 9 Dec 2013 13:47:12 +0000 Message-ID: <2611BD08-EA51-42DF-BFDF-4031DEDA9F3F@checkpoint.com> References: <0FE7905C-950F-4030-8A47-37C523FB497A@doubleshotsecurity.com> <95276F1E-2293-41F3-A6E7-7AEF4B22E811@doubleshotsecurity.com> <4613980CFC78314ABFD7F85CC302772121B1EC40@IL-EX10.ad.checkpoint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.111] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: multipart/alternative; boundary="_000_2611BD08EA5142DFBFDF4031DEDA9F3Fcheckpointcom_" MIME-Version: 1.0 Cc: perpass , Merike Kaeo Subject: Re: [perpass] NULL Cipher RFC 2410 to HISTORIC ??? 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 13:48:53 -0000 --_000_2611BD08EA5142DFBFDF4031DEDA9F3Fcheckpointcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Dec 9, 2013, at 2:54 PM, Phillip Hallam-Baker > wrote: On Mon, Dec 9, 2013 at 2:23 AM, Yoav Nir > wrote: Phil, The issue is not that ESP needs a NULL cipher. It's that AH wouldn't traver= se NAT, and so they needed ESP to do the work that AH was designed to do. I understand that, though the fact that ESP with authentication would work = through NAT but not AH seems remarkably odd to me. It suggests that the des= ign is wrong. Of ESP (because it doesn't protect the IP header), or of AH (because if can= not traverse NAT) ? That flags a design error in the protocol AFIAK. As a remote access protocol, IPSEC has fallen far short of satisfactory. I don't think anyone is arguing against that. We wouldn't implement L2TP ov= er IPsec or stuff IP packets into TLS connections if it was. It has been necessary to install a plug in to use every corporate VPN I hav= e used to date. But beyond that little technicality, it stands out that they standardized A= H at all. So they felt that there was a need for integrity-only IPsec. I gu= ess part of this is that the perceived threats were different - there was l= ess personal information on the Internet, and IPsec (unlike TLS) is much co= ncerned with protecting non-confidential stuff like DNS, routing protocols.= Today, about the only good use case I can think of that doesn't ever need = confidentiality is NTP, and I don't know why we would want to design a prot= ocol specifically for securing NTP. And to do authentication only twice seems even stranger. Another part is that this was 1996 and in 1996 you had the "Pentium Pro" wi= th a 150 MHz clock and a 60 MHz bus, which could probably do a few Mbps of = 3DES+HMAC-MD5, or four times that with HMAC-MD5 alone. These are not today'= s processors that do 4 Gbps per core with AES-GCM. That is not the motivation that the RFC suggests. It doesn't, but at the time you couldn't say "just encrypt everything" with= out seeming out of touch with reality. Today, you can. BTW: this is not unique to IPsec. TLS also defines some NULL encryption cip= hersuites. I know, but the problem is that people are now pointing to the NULL ciphers= as precedent. The current algorithm draft ([1]) still has NULL as MTI. It's interesting t= hat opinions range from MTI to HISTORIC. Yoav [1] http://tools.ietf.org/html/draft-ietf-ipsecme-esp-ah-reqts-01#section-2= .2 --_000_2611BD08EA5142DFBFDF4031DEDA9F3Fcheckpointcom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
On Dec 9, 2013, at 2:54 PM, Phillip Hallam-Baker <hallam@gmail.com> wrote:

On Mon, Dec 9, 2013 at 2:23 AM, Yoav Nir <ynir@checkpoin= t.com> wrote:
Phil,

The issue is not that ESP needs a NULL cipher. It's that AH wouldn't traver= se NAT, and so they needed ESP to do the work that AH was designed to do.

I understand that, though the fact that ESP with authentication would = work through NAT but not AH seems remarkably odd to me. It suggests that th= e design is wrong.

Of ESP (because it doesn't protect the IP header), or of AH (because if can= not traverse NAT) ?


That flags a design error in the protocol AFIAK. 

As a remote access protocol, IPSEC has fallen far short of satisfactor= y.

I don't think anyone is arguing against that. We wouldn't implement L2TP ov= er IPsec or stuff IP packets into TLS connections if it was.

It has been necessary to install a plug in to use every corporate VPN = I have used to date.

 
But beyond that little technicality, it stands out that they standardized A= H at all. So they felt that there was a need for integrity-only IPsec. I gu= ess part of this is that the perceived threats were different - there was l= ess personal information on the Internet, and IPsec (unlike TLS) is much concerned with protecting non-con= fidential stuff like DNS, routing protocols. Today, about the only good use= case I can think of that doesn't ever need confidentiality is NTP, and I d= on't know why we would want to design a protocol specifically for securing NTP.

And to do authentication only twice seems even stranger.

 
Another part is that this was 1996 and in 1996 you had the "Pentium Pr= o" with a 150 MHz clock and a 60 MHz bus, which could probably do a fe= w Mbps of 3DES+HMAC-MD5, or four times that with HMAC-MD5 alone. These = are not today's processors that do 4 Gbps per core with AES-GCM.

That is not the motivation that the RFC suggests.

It doesn't, but at the time you couldn't say "just encrypt everything&= quot; without seeming out of touch with reality. Today, you can.

BTW: this is not unique to IPsec. TLS also defines some NULL encryption cip= hersuites.

I know, but the problem is that people are now pointing to the NULL ci= phers as precedent.

The current algorithm draft ([1]) still has NULL as MTI. It's interest= ing that opinions range from MTI to HISTORIC.

Yoav


--_000_2611BD08EA5142DFBFDF4031DEDA9F3Fcheckpointcom_-- From lear@cisco.com Mon Dec 9 05:59:22 2013 Return-Path: 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 0528C1AE2C1; Mon, 9 Dec 2013 05:59:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.501 X-Spam-Level: X-Spam-Status: No, score=-9.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 T4em6_u0u5Qe; Mon, 9 Dec 2013 05:59:19 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id 7931B1ADF52; Mon, 9 Dec 2013 05:59:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1428; q=dns/txt; s=iport; t=1386597556; x=1387807156; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=g4IDJMnQoAV6MIXwxmtVciPhI18wzB544YV773+4tzk=; b=MtuNU6GCobZvNG5F2GPtgYdYo8IeUgKIsHQYeWK440sR4Gfyd55cjEyl 45XCM8itr3wN8kh68n4eqj6KJx4UvYnHlecHBqQYZ4nTKLurm81+lIK0/ crn+DLJUpWRhp3kEMpqwXscjqLQyAXwKD2/FLIKZDZfTDt3MxDTGtXGE9 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAIDLpVKQ/khN/2dsb2JhbABZgweECrYWgS8WdIIcCQEBAQQjVQEQCwMBCgoJFgsCAgkDAgECAUUGAQwBBwEBh36yAo8sF48QB4JrgUgDmBSSE4FrgT87 X-IronPort-AV: E=Sophos;i="4.93,858,1378857600"; d="scan'208,217";a="1301566" Received: from ams-core-4.cisco.com ([144.254.72.77]) by aer-iport-2.cisco.com with ESMTP; 09 Dec 2013 13:59:14 +0000 Received: from ams3-vpn-dhcp5161.cisco.com (ams3-vpn-dhcp5161.cisco.com [10.61.84.40]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id rB9DxAD7006452 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Dec 2013 13:59:10 GMT Message-ID: <52A5CCB6.8070108@cisco.com> Date: Mon, 09 Dec 2013 14:59:18 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Eric Burger , perpass References: <7wmom0dq1s8yyc5t1qpvdxxl.1386593028146@email.android.com> In-Reply-To: <7wmom0dq1s8yyc5t1qpvdxxl.1386593028146@email.android.com> X-Enigmail-Version: 1.6 Content-Type: multipart/alternative; boundary="------------080703020501070104060109" Cc: Internet Architecture Board , 'IESG' Subject: Re: [perpass] comments and questions for the group on draft-farrell-perpass-attack-02 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 13:59:22 -0000 This is a multi-part message in MIME format. --------------080703020501070104060109 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 12/9/13 1:43 PM, Eric Burger wrote: > So if the "operational realities" of the operator include a mandate to > intercept, like with a law like CALEA in the United States, then > pervasive monitoring is OK? > This does not negate the existing RFCs that speak to that. Eliot --------------080703020501070104060109 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit
On 12/9/13 1:43 PM, Eric Burger wrote:
So if the "operational realities" of the operator include a mandate to intercept, like with a law like CALEA in the United States, then pervasive monitoring is OK?


This does not negate the existing RFCs that speak to that.

Eliot

--------------080703020501070104060109-- From lear@cisco.com Mon Dec 9 06:00:56 2013 Return-Path: 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 983A51AE2E8; Mon, 9 Dec 2013 06:00:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.502 X-Spam-Level: X-Spam-Status: No, score=-9.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 wtDFrx31VSL9; Mon, 9 Dec 2013 06:00:55 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id D5A751AE2E3; Mon, 9 Dec 2013 06:00:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1051; q=dns/txt; s=iport; t=1386597651; x=1387807251; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=3z7OBa41undPiaea7w9/u+RlP70O16QyeeTUDnQEZhM=; b=MmNQNy2yRzbnDI8sEWOMJL1APONFUEjGvPtKQzDF23r7xxtBHVaRtjpL tsItABoYZvvfHYTIHj1WJh0RMZ2jOdo4ncIc9MqH1wr5FrKoWN4/IzKZI wR5H4Hvox33ivE10cGoJl3CL/on+JlWnOwbkW9cwkc6dtRStDVM7ZeuZX c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah0FALLMpVKQ/khM/2dsb2JhbABZgweECrYWgS8WdIIlAQEBBCNVARALGAICBRYLAgIJAwIBAgFFBg0BBwEBh36yAo8sF4EpjQ9YB4JrgUgDlDGDY5ITgWuBPzuBLA X-IronPort-AV: E=Sophos;i="4.93,858,1378857600"; d="scan'208";a="1301639" Received: from ams-core-3.cisco.com ([144.254.72.76]) by aer-iport-2.cisco.com with ESMTP; 09 Dec 2013 14:00:50 +0000 Received: from ams3-vpn-dhcp5161.cisco.com (ams3-vpn-dhcp5161.cisco.com [10.61.84.40]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id rB9E0jxS000921 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Dec 2013 14:00:45 GMT Message-ID: <52A5CD16.3050905@cisco.com> Date: Mon, 09 Dec 2013 15:00:54 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Robin Wilton References: <52A5B79E.2040202@cisco.com> <2FF9686C-7DEA-42E3-B2FA-DCD72A5E5168@isoc.org> In-Reply-To: <2FF9686C-7DEA-42E3-B2FA-DCD72A5E5168@isoc.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: perpass , Internet Architecture Board , IESG Subject: Re: [perpass] comments and questions for the group on draft-farrell-perpass-attack-02 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 14:00:57 -0000 Robin, On 12/9/13 2:00 PM, Robin Wilton wrote: > Eliot, > > I think your second edit is probably too broad, in the sense that it could create quite a lot of room for abuse. You currently have: > >>> More limited-scope monitoring or other services or to assist with >>> network operations that >>> is required in order to operate the network or an application is not >>> considered pervasive monitoring > I would suggest something along the following lines. The first part is just a rewording of your text; the part in square brackets is prompted by what I think we can learn from existing approaches to pervasive monitoring. > > Where monitoring is of limited scope, or services in support of network operations are required in order to operate the network, these are not necessarily to be considered de facto pervasive monitoring [; however, thought should be given to whether they enable pervasive monitoring, either directly or as a by-product of their primary purpose]. > Your alternative would be fine with me. Eliot From mcr@sandelman.ca Mon Dec 9 06:14:44 2013 Return-Path: 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 01DA71AE2D4 for ; Mon, 9 Dec 2013 06:14:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.892 X-Spam-Level: X-Spam-Status: No, score=-1.892 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_TVD_MIME_NO_HEADERS=0.01] 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 CYc2VnAr2Gjw for ; Mon, 9 Dec 2013 06:14:42 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id AB4A81ADF7F for ; Mon, 9 Dec 2013 06:14:42 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 784AF20038; Mon, 9 Dec 2013 10:28:13 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id D869B63B89; Mon, 9 Dec 2013 09:14:30 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id C2AE663848; Mon, 9 Dec 2013 09:14:30 -0500 (EST) From: Michael Richardson To: Phillip Hallam-Baker In-Reply-To: References: X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Cc: perpass , Hannes Tschofenig , Nicholas Weaver , Stephen Farrell Subject: Re: [perpass] NULL Cipher RFC 2410 to HISTORIC ??? 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 14:14:44 -0000 --=-=-= Phillip Hallam-Baker wrote: > Hi Stephen, Hi Nicholas, > it would be interesting (as a history lesson) if someone could tell > us why the group at that time decided to develop a NULL encryption > mechanism. Stephen Kent (co-author of RFC 2410) might remember. I have > no heard > It was for testing and it all happened long before any of the evidence > of the NSA peddling bongoed crypto suggests that it was going on. I > think it highly unlikely that anything of the sort was going on before > 9/11 and my sources claim that the change came much later, if it > happened at all. It was an alternative to using AH, which did not traverse NAT. Yes, it was also useful for debugging. ESP has both authentication and encryption, and historically, they are provided by different algorithms (3DES+HMAC_SHA1) vs the way AES-GCM-type modes work. -- Michael Richardson , Sandelman Software Works --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUqXQRIqHRg3pndX9AQJyjQP+N41Xew+GWJc/CDCvvWUSPcpGRqwjuBxe /Vfw4CMuNMI9GRkidW1Cu0T9zJzBEaNgIrP0uKFR9dIynDRB9plRJZyuKfTk0uvC EIuNJ6u29G9PeovGUv3IX6/IukudSnBBclDNSgLm66XbApD71fscs+qRrD6K3f/O QywKpo6MtWQ= =sU3a -----END PGP SIGNATURE----- --=-=-=-- From kent@bbn.com Mon Dec 9 06:53:21 2013 Return-Path: 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 5AB7B1AE30A for ; Mon, 9 Dec 2013 06:53:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 AKzpXf7xn0TR for ; Mon, 9 Dec 2013 06:53:20 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id DEB8B1AE2F6 for ; Mon, 9 Dec 2013 06:53:19 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:53615 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Vq2Cw-000831-Oo for perpass@ietf.org; Mon, 09 Dec 2013 09:53:14 -0500 Message-ID: <52A5D95A.1020405@bbn.com> Date: Mon, 09 Dec 2013 09:53:14 -0500 From: Stephen Kent 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: <52A3B32D.8000301@perens.com> <52A3B8A4.6000309@perens.com> <6FFED7BB-9272-4B94-AFC3-8689F3D3D325@icsi.berkeley.edu> <52A4DB71.8040806@cs.tcd.ie> <52A4EBF3.4000001@gmx.net> In-Reply-To: <52A4EBF3.4000001@gmx.net> Content-Type: multipart/alternative; boundary="------------000808020302020004050009" Subject: Re: [perpass] Fwd: Re: 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 14:53:21 -0000 This is a multi-part message in MIME format. --------------000808020302020004050009 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hannes, > Hi Stephen, Hi Nicholas, > > it would be interesting (as a history lesson) if someone could tell us > why the group at that time decided to develop a NULL encryption > mechanism. Stephen Kent (co-author of RFC 2410) might remember. I have > no heard NULL encryption is offered as an option for ESP to enable ESP to be used in contexts where data integrity, authentication and anti-replay may be required, but confidentiality is not desired. AH was designed to offer this set of security requirements, but we found that ESP was much more efficient, and thus we included NULL encryption as an option for ESP. BTW, the most common motivation for not imposing confidentially is a need to perform packet inspection in an enterprise environment. Steve --------------000808020302020004050009 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hannes,
Hi Stephen, Hi Nicholas,

it would be interesting (as a history lesson) if someone could tell us why the group at that time decided to develop a NULL encryption mechanism. Stephen Kent (co-author of RFC 2410) might remember. I have no heard
NULL encryption is offered as an option for ESP to enable ESP to be used in contexts
where data integrity, authentication and anti-replay may be required, but confidentiality is not desired. AH was designed to offer this set of security requirements, but we found that ESP was much more efficient, and thus we included NULL encryption as an option for ESP. BTW, the most common motivation for not imposing confidentially is a need to perform packet inspection in an enterprise environment.

Steve
--------------000808020302020004050009-- From lear@cisco.com Mon Dec 9 06:53:25 2013 Return-Path: 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 5B51B1AE316; Mon, 9 Dec 2013 06:53:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.502 X-Spam-Level: X-Spam-Status: No, score=-9.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 kHYXliM4jfO9; Mon, 9 Dec 2013 06:53:23 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id 17B991AE308; Mon, 9 Dec 2013 06:53:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1589; q=dns/txt; s=iport; t=1386600799; x=1387810399; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=ohCOPrjeKA2qe0J5RJgyJNXM4oHa2cMFRtyET91duTQ=; b=Cfo5FfUrUqSbfQdkaEgjEFqrXwDjgPQDffQWgafxtDF5YvrP0Qn0o0tj EzGoL41vTYpQv5OnYm/RvAda9Q9hgk0qI1hKHv6xhDyav5hlZQIbpG87A fQvCqowjeBO8ULuPIx4aW4v0IQMKGEFctZXL58dzMr2xNWQvPqh41jeAs Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah8FAIjYpVKQ/khN/2dsb2JhbABZgwc4g1K2FoEvFnSCJQEBAQMBAQIgMSQGCwsaAgUWCwICCQMCAQIBFi8GAQwIAQGHeAYNsX2PLReBKY0WAQFWgmuBSAOVRYJPgTCQY4FrgT87gTU X-IronPort-AV: E=Sophos;i="4.93,858,1378857600"; d="scan'208";a="1304075" Received: from ams-core-4.cisco.com ([144.254.72.77]) by aer-iport-2.cisco.com with ESMTP; 09 Dec 2013 14:53:18 +0000 Received: from ams3-vpn-dhcp5161.cisco.com (ams3-vpn-dhcp5161.cisco.com [10.61.84.40]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id rB9ErDuM022387 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Dec 2013 14:53:14 GMT Message-ID: <52A5D962.3090708@cisco.com> Date: Mon, 09 Dec 2013 15:53:22 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Stephen Farrell , perpass , IETF@ietf.org References: <52A5B79E.2040202@cisco.com> <52A5C458.200@cs.tcd.ie> In-Reply-To: <52A5C458.200@cs.tcd.ie> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [perpass] comments and questions for the group on draft-farrell-perpass-attack-02 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 14:53:25 -0000 Hi Stephen, I'm not comfortable with having this discussion just in perpass, since the impact of what you are proposing is quite broad, as is my concern. This is an IETF last call comment. The IESG directed those comments to go to the IETF list. On 12/9/13 2:23 PM, Stephen Farrell wrote: > The chair you mean is Mark > Nottingham in this [1] mail to the httpbis list. > > [1] http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1453.html > > I definitely did not read him the way you appear to have and > that distinction matters. If you are the only one to take him > as saying that then I guess you'd agree that your changes > would be based on a fallacy. Maybe Mark can clarify but I think > its already crystal clear that he was not saying "ignore > everything else" - I'd be stunned if that was what he meant. The point was and is that I wanted to respond to him to clarify that one should not ignore everything else, when in fact I found the opposite: since you laid out explicitly only network management considerations, the implication is that all other considerations are excluded. The purpose of my change is to remove that implied exclusion, and leave this to working groups to wrestle with. I'm happy with Robin's wording as well, and I don't mind you proposing other wording further to your liking, so long as we recognize that there are other considerations. If you can show me where in your text it allows for those other considerations as I believe I've done in the reverse, I'll be happy to stand corrected. Eliot From kent@bbn.com Mon Dec 9 06:55:09 2013 Return-Path: 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 02C901AE305 for ; Mon, 9 Dec 2013 06:55:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 l8vT4NQ9_XhQ for ; Mon, 9 Dec 2013 06:55:07 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 1C9E71AE2F3 for ; Mon, 9 Dec 2013 06:55:07 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:44400 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Vq2Eg-0004ed-17 for perpass@ietf.org; Mon, 09 Dec 2013 09:55:02 -0500 Message-ID: <52A5D9C5.1050700@bbn.com> Date: Mon, 09 Dec 2013 09:55:01 -0500 From: Stephen Kent 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: In-Reply-To: Content-Type: multipart/alternative; boundary="------------050400010409050703010606" Subject: Re: [perpass] NULL Cipher RFC 2410 to HISTORIC ??? 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 14:55:09 -0000 This is a multi-part message in MIME format. --------------050400010409050703010606 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Phillip, > On Sun, Dec 8, 2013 at 5:00 PM, Hannes Tschofenig > > wrote: > > Hi Stephen, Hi Nicholas, > > it would be interesting (as a history lesson) if someone could > tell us why the group at that time decided to develop a NULL > encryption mechanism. Stephen Kent (co-author of RFC 2410) might > remember. I have no heard > > > It was for testing no, it was not. please see my response to Hannes. Steve --------------050400010409050703010606 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Phillip,
On Sun, Dec 8, 2013 at 5:00 PM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
Hi Stephen, Hi Nicholas,

it would be interesting (as a history lesson) if someone could tell us why the group at that time decided to develop a NULL encryption mechanism. Stephen Kent (co-author of RFC 2410) might remember. I have no heard

It was for testing
no, it was not. please see my response to Hannes.

Steve
--------------050400010409050703010606-- From lear@cisco.com Mon Dec 9 06:57:34 2013 Return-Path: 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 7748B1AE31E; Mon, 9 Dec 2013 06:57:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.502 X-Spam-Level: X-Spam-Status: No, score=-9.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 nObnfRSqUBqN; Mon, 9 Dec 2013 06:57:33 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id AD60B1AE2F5; Mon, 9 Dec 2013 06:57:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=466; q=dns/txt; s=iport; t=1386601048; x=1387810648; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=WBIZ2eJHkq1D2A2EN3TW6QHboaRxFxEwcBX4XQAvGQo=; b=UItD9XKOGU4NGzusfPa31M6avgaeVsMYpO3D2l0JdbJzS+pQK5+jsQVE fK9pdddkxTv9qKNleDAijtH0zTR3FXMf5TWhfiZV9fzEX9l5wRQwqAHg2 iTE2aGgs/nT07YUbP+3q8HVvCpxYxtcVky6f+qsgUDRA1AYS3g1PdMb9Q o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFAPfZpVKQ/khM/2dsb2JhbABZgweECrYWgS8WdIIlAQEBBCMxNQsYAgIFIQICDwJGBgEMCAEBh36yDI8uF4EpjW6Ca4FIA5gUkhOBa4E/Ow X-IronPort-AV: E=Sophos;i="4.93,858,1378857600"; d="scan'208";a="1913235" Received: from ams-core-3.cisco.com ([144.254.72.76]) by aer-iport-1.cisco.com with ESMTP; 09 Dec 2013 14:57:27 +0000 Received: from ams3-vpn-dhcp5161.cisco.com (ams3-vpn-dhcp5161.cisco.com [10.61.84.40]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id rB9EvMdv019346 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Dec 2013 14:57:23 GMT Message-ID: <52A5DA5B.908@cisco.com> Date: Mon, 09 Dec 2013 15:57:31 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Stephen Farrell , perpass , IETF@ietf.org References: <52A5B79E.2040202@cisco.com> <52A5C458.200@cs.tcd.ie> <52A5D962.3090708@cisco.com> In-Reply-To: <52A5D962.3090708@cisco.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [perpass] comments and questions for the group on draft-farrell-perpass-attack-02 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 14:57:34 -0000 On 12/9/13 3:53 PM, Eliot Lear wrote: > Hi Stephen, > > I'm not comfortable with having this discussion just in perpass, since > the impact of what you are proposing is quite broad, as is my concern. > This is an IETF last call comment. The IESG directed those comments to > go to the IETF list. Just on this point, Stephen pointed out that I had originally CC'd the wrong list. Apologies to Stephen and others for any confusion about that. Eliot From kent@bbn.com Mon Dec 9 06:58:43 2013 Return-Path: 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 CFAD51AE305 for ; Mon, 9 Dec 2013 06:58:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 BZdFCm7cqUYq for ; Mon, 9 Dec 2013 06:58:41 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 99BC51AE2F5 for ; Mon, 9 Dec 2013 06:58:41 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:55971 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Vq2I8-00087X-G7 for perpass@ietf.org; Mon, 09 Dec 2013 09:58:36 -0500 Message-ID: <52A5DA9C.7010709@bbn.com> Date: Mon, 09 Dec 2013 09:58:36 -0500 From: Stephen Kent 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: <0FE7905C-950F-4030-8A47-37C523FB497A@doubleshotsecurity.com> <95276F1E-2293-41F3-A6E7-7AEF4B22E811@doubleshotsecurity.com> In-Reply-To: <95276F1E-2293-41F3-A6E7-7AEF4B22E811@doubleshotsecurity.com> Content-Type: multipart/alternative; boundary="------------090507050307090701080002" Subject: Re: [perpass] NULL Cipher RFC 2410 to HISTORIC ??? 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 14:58:44 -0000 This is a multi-part message in MIME format. --------------090507050307090701080002 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Merike, > And so I reply to myself but got curious and wanted evidence. I found > first references of AH/ESP and NULL in 1996 June IPsec archives. > http://www.sandelman.ottawa.on.ca/ipsec/1996/06/msg00030.html > > And while some interesting tidbits, the joggle for my memory banks > was that there was a bunch of discussion on where AH would be used > with ESP and whether ESP only would also be relevant. And while I > couldn't find exact reference to the March 1998 interop testing in > North Carolina that showed issues with AH not traversing NATs I am > fairly certain that was the case and why in practice people starting > using ESP-Null. (it wasn't in the notes for the follow-up IETF IPsec > meeting). > > Someone else from that time may also be able to chime in. > The very first IPsec designs called for use of AH plus ESP to offer authentication, integrity and confidentiality. That dual protocol use was a significant burden, so ESP was extended to offer all three services, and AH remained as an auth/integ but no confid alternative, for various reasons. (One reason, as you noted, was export controls on encryption.) Later we revised ESP to incorporate NULL encryption for the reasons I cited earlier; I forgot about the NAT problem. Steve --------------090507050307090701080002 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Merike,
And so I reply to myself but got curious and wanted evidence.  I found first references of AH/ESP and NULL in 1996 June IPsec archives.  http://www.sandelman.ottawa.on.ca/ipsec/1996/06/msg00030.html

And while  some interesting tidbits, the joggle for my memory banks was that there was a bunch of discussion on where AH would be used with ESP and whether ESP only would also be relevant.  And while I couldn't find exact reference to the March 1998 interop testing in North Carolina that showed issues with AH not traversing NATs I am fairly certain that was the case and why in practice people starting using ESP-Null.  (it wasn't in the notes for the follow-up IETF IPsec meeting).

Someone else from that time may also be able to chime in.

The very first IPsec designs called for use of AH plus ESP to offer authentication, integrity and confidentiality. That dual protocol use was a significant burden, so
ESP was extended to offer all three services, and AH remained as an auth/integ but no confid alternative, for various reasons.  (One reason, as you noted, was export controls on encryption.) Later we revised ESP to incorporate NULL encryption for the reasons I cited earlier; I forgot about the NAT problem.

Steve
--------------090507050307090701080002-- From kent@bbn.com Mon Dec 9 07:00:30 2013 Return-Path: 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 87AED1AE332 for ; Mon, 9 Dec 2013 07:00:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 2zUdOEMi_FfE for ; Mon, 9 Dec 2013 07:00:29 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id C85151AE2F5 for ; Mon, 9 Dec 2013 07:00:28 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:56011 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Vq2Jm-00089x-Ja for perpass@ietf.org; Mon, 09 Dec 2013 10:00:18 -0500 Message-ID: <52A5DB02.1000709@bbn.com> Date: Mon, 09 Dec 2013 10:00:18 -0500 From: Stephen Kent 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: <0FE7905C-950F-4030-8A47-37C523FB497A@doubleshotsecurity.com> <95276F1E-2293-41F3-A6E7-7AEF4B22E811@doubleshotsecurity.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------020805050204080800060704" Subject: Re: [perpass] NULL Cipher RFC 2410 to HISTORIC ??? 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 15:00:30 -0000 This is a multi-part message in MIME format. --------------020805050204080800060704 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Phillip, > On Mon, Dec 9, 2013 at 12:11 AM, Merike Kaeo > > > wrote: > > And so I reply to myself but got curious and wanted evidence. I > found first references of AH/ESP and NULL in 1996 June IPsec > archives. > http://www.sandelman.ottawa.on.ca/ipsec/1996/06/msg00030.html > > And while some interesting tidbits, the joggle for my memory > banks was that there was a bunch of discussion on where AH would > be used with ESP and whether ESP only would also be relevant. And > while I couldn't find exact reference to the March 1998 interop > testing in North Carolina that showed issues with AH not > traversing NATs I am fairly certain that was the case and why in > practice people starting using ESP-Null. (it wasn't in the notes > for the follow-up IETF IPsec meeting). > > Someone else from that time may also be able to chime in. > > > The wording of the RFC does not help. It suggests that the cipher is > something of a joke and it states the original requirement came out of > a meeting for interop testing. I like to think of the text in RFC 2410 as delightfully tongue in cheek. Steve --------------020805050204080800060704 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Phillip,
On Mon, Dec 9, 2013 at 12:11 AM, Merike Kaeo <merike@doubleshotsecurity.com> wrote:
And so I reply to myself but got curious and wanted evidence.  I found first references of AH/ESP and NULL in 1996 June IPsec archives.  http://www.sandelman.ottawa.on.ca/ipsec/1996/06/msg00030.html

And while  some interesting tidbits, the joggle for my memory banks was that there was a bunch of discussion on where AH would be used with ESP and whether ESP only would also be relevant.  And while I couldn't find exact reference to the March 1998 interop testing in North Carolina that showed issues with AH not traversing NATs I am fairly certain that was the case and why in practice people starting using ESP-Null.  (it wasn't in the notes for the follow-up IETF IPsec meeting).

Someone else from that time may also be able to chime in.

The wording of the RFC does not help. It suggests that the cipher is something of a joke and it states the original requirement came out of a meeting for interop testing.
I like to think of the text in RFC 2410 as delightfully tongue in cheek.

Steve
--------------020805050204080800060704-- From kent@bbn.com Mon Dec 9 07:20:27 2013 Return-Path: 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 844761AE33B for ; Mon, 9 Dec 2013 07:20:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Iw-87o_6G27S for ; Mon, 9 Dec 2013 07:20:25 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id A37B91AE338 for ; Mon, 9 Dec 2013 07:20:25 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:33975 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Vq2dA-0008M9-2W for perpass@ietf.org; Mon, 09 Dec 2013 10:20:20 -0500 Message-ID: <52A5DFB3.90309@bbn.com> Date: Mon, 09 Dec 2013 10:20:19 -0500 From: Stephen Kent 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: <52A3B32D.8000301@perens.com> <52A3B8A4.6000309@perens.com> <6FFED7BB-9272-4B94-AFC3-8689F3D3D325@icsi.berkeley.edu> In-Reply-To: <6FFED7BB-9272-4B94-AFC3-8689F3D3D325@icsi.berkeley.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [perpass] Fwd: Re: 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 15:20:27 -0000 Nicholas, > On Dec 7, 2013, at 4:09 PM, Bruce Perens wrote: >> Well, we do have some HTTP uses where encryption that hides the content won't be allowed, and thus authentication is important. >> >> We can't have encryption when we use HTTP over Amateur Radio in the US and many other countries. There is self-policing on ham frequencies that requires that people be able to copy other people's transmissions, and encryption defeats that. Obviously we don't put confidential data on those frequencies, that belongs on your cell phone. So, an authentication-only WiFi protocol is needed for Amateur Radio, and possibly an authentication-only version of TLS. > NO!!!! > > The reason is downgrade attacks. A huge problem with the IPSec standard is that NULL encryption was allowed in there, and also known weak modes (single DES, 720b D/H etc). Its one of the primary reasons why John Gilmore and therefore others feel the IPSec process was sabotaged by the NSA. John's assertions in this context are not informed by participation in the IPsec WG process at that time, to the best of my recollection. > To explicitly support downgraded, athuentication w/o encryption is STUPID! it is DANGEROUS! Not at all. We already had AH; we offered ESP with NULL encryption as a more efficient way to achieve the same security goals. > About the only thing that is not a horrid idea is to have the key exchange generate a separate MAC and encryption key, using an encrypt then MAC structure. Yet that loses out on the benefit of authenticated encryption modes that build the MAC into the communication. The use of distinct algs for the distinct security services was consistent with the standard alg options of the original time frame. Note that combined mode algs, that offer confidentiality and integrity, are explciitly accommodated in later versions of the specs, e.g., 4303. Steve From llynch@civil-tongue.net Mon Dec 9 07:34:47 2013 Return-Path: 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 793B61AE30E for ; Mon, 9 Dec 2013 07:34:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 e_0KHwmajdB9 for ; Mon, 9 Dec 2013 07:34:46 -0800 (PST) Received: from hans.rg.net (hans.rg.net [IPv6:2001:418:1::42]) by ietfa.amsl.com (Postfix) with ESMTP id 4107A1ADF9F for ; Mon, 9 Dec 2013 07:34:46 -0800 (PST) Received: from hiroshima.bogus.com (hiroshima.bogus.com [IPv6:2001:418:1::80]) (authenticated bits=0) by hans.rg.net (8.14.7/8.14.7) with ESMTP id rB9FYfuf009796 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 9 Dec 2013 15:34:41 GMT (envelope-from llynch@civil-tongue.net) Date: Mon, 9 Dec 2013 07:34:41 -0800 (PST) From: Lucy Lynch X-X-Sender: llynch@hiroshima.bogus.com To: manning bill In-Reply-To: <86BC54D4-7D2F-42F1-BA46-A73585605D58@isi.edu> Message-ID: References: <86BC54D4-7D2F-42F1-BA46-A73585605D58@isi.edu> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: perpass Subject: Re: [perpass] into the legal arena 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 15:34:47 -0000 On Mon, 9 Dec 2013, manning bill wrote: > piecemeal approach - a fact of life in todays environment. > > http://www.washingtonpost.com/blogs/the-switch/wp/2013/09/25/author-of-california-online-eraser-law-its-not-always-easy-to-find-the-delete-button/ > binding is easy, revocation is hard. > > /bill > Neca eos omnes. Deus suos agnoscet. > > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > > From mcr@sandelman.ca Mon Dec 9 07:47:07 2013 Return-Path: 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 6855C1ADFB2 for ; Mon, 9 Dec 2013 07:47:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 UVJCjhdHJ3ni for ; Mon, 9 Dec 2013 07:47:06 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id E202C1ADF6E for ; Mon, 9 Dec 2013 07:47:05 -0800 (PST) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 789DF2017E; Mon, 9 Dec 2013 12:00:36 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 9365D63B89; Mon, 9 Dec 2013 10:46:53 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 85B1C63848; Mon, 9 Dec 2013 10:46:53 -0500 (EST) From: Michael Richardson To: Phillip Hallam-Baker In-Reply-To: References: <0FE7905C-950F-4030-8A47-37C523FB497A@doubleshotsecurity.com> <95276F1E-2293-41F3-A6E7-7AEF4B22E811@doubleshotsecurity.com> <4613980CFC78314ABFD7F85CC302772121B1EC40@IL-EX10.ad.checkpoint.com> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Cc: perpass , Yoav Nir , Merike Kaeo Subject: Re: [perpass] NULL Cipher RFC 2410 to HISTORIC ??? 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 15:47:07 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Phillip Hallam-Baker wrote: > Phil, > The issue is not that ESP needs a NULL cipher. It's that AH > wouldn't traverse NAT, and so they needed ESP to do the work that AH > was designed to do. > I understand that, though the fact that ESP with authentication would > work through NAT but not AH seems remarkably odd to me. It suggests > that the design is wrong. > That flags a design error in the protocol AFIAK.=C2=A0 No, it's because NAT is an attack by a middle box on end to end flow, and back in 1994, we didn't think anyone would be so stupid as to do that kind = of thing. =2D- Michael Richardson , Sandelman Software Works --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUqXl64qHRg3pndX9AQIfGgP/S7fyQXlXAGvNA8E6cN571P8cSv22fm3t nbKDoWeJ/Mb6kXttvcsINhTkRpBdRCzjXixSODeUeqwAgp8Mh+B6sxr+hm9vpvAr D7OTzx023xI8CuVrsewHQSuc2qq6J02CxsbYt4a/DN7XPdygNS+FCi15O7vKPNzt i2ELHB6C5QY= =t/ZH -----END PGP SIGNATURE----- --=-=-=-- From alexander.m.clark@gmail.com Mon Dec 9 08:04:19 2013 Return-Path: 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 1C2651AE370 for ; Mon, 9 Dec 2013 08:04:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 v78hsu3iPoVK for ; Mon, 9 Dec 2013 08:04:17 -0800 (PST) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 0CD6E1AE341 for ; Mon, 9 Dec 2013 08:04:16 -0800 (PST) Received: by mail-la0-f48.google.com with SMTP id n7so1731229lam.35 for ; Mon, 09 Dec 2013 08:04:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OjJScTFZlmQLmqaFcqXmKP3jU09hbUde8zz2PBdcdec=; b=EPIIqFMSXKHS8KPF/iTrx2i96UV48HiFC4+I/dz63R1Y+G8Wu2P49c8tth0mnUiAet 2KUVYoznpYMbZCtvkQFWDlacTvbyfOSuPZnMXQZu2beIjdqW8MhckoToESc19sFkj9e9 kHHZPeT8ZFr5MZzrBvmRfoyMSIUnUfrdnkrbL73VvLsr8Gnq4qr+2tV+XjwHZrmkQDs1 2hnzePmzyB8frkjalLIU59Yk92gI2LgKW/9dsbs5ZyxoJ8O12BByCMhi1J6CPMHIkr91 o13hE9McDve0S3X1c4eOzq3B1UCzKteXfOqcPFu/X/SedNgqLUXeJX3BNs5dY8h9xJ4L 3dNA== MIME-Version: 1.0 X-Received: by 10.152.121.105 with SMTP id lj9mr5659742lab.6.1386605051500; Mon, 09 Dec 2013 08:04:11 -0800 (PST) Received: by 10.114.82.228 with HTTP; Mon, 9 Dec 2013 08:04:11 -0800 (PST) In-Reply-To: References: <86BC54D4-7D2F-42F1-BA46-A73585605D58@isi.edu> Date: Mon, 9 Dec 2013 11:04:11 -0500 Message-ID: From: Al Clark To: Lucy Lynch Content-Type: multipart/alternative; boundary=089e0122771689dbfd04ed1c25b5 Cc: perpass , manning bill Subject: Re: [perpass] into the legal arena 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 16:04:19 -0000 --089e0122771689dbfd04ed1c25b5 Content-Type: text/plain; charset=ISO-8859-1 I'm encouraged by the political impulse behind this, but I do wonder about the cost of implementing it and whether it will meet its stated goals. That it's coming from California is also heartening, again on the political level. 2013/12/9 Lucy Lynch > On Mon, 9 Dec 2013, manning bill wrote: > > piecemeal approach - a fact of life in todays environment. >> >> http://www.washingtonpost.com/blogs/the-switch/wp/2013/09/ >> 25/author-of-california-online-eraser-law-its-not- >> always-easy-to-find-the-delete-button/ >> >> > binding is easy, revocation is hard. > > > >> /bill >> Neca eos omnes. Deus suos agnoscet. >> >> _______________________________________________ >> perpass mailing list >> perpass@ietf.org >> https://www.ietf.org/mailman/listinfo/perpass >> >> >> _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > --089e0122771689dbfd04ed1c25b5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I'm encouraged by the political impulse behind this, b= ut I do wonder about the cost of implementing it and whether it will meet i= ts stated goals. =A0That it's coming from California is also heartening= , again on the political level.


2013/12/9 Luc= y Lynch <llynch@civil-tongue.net>
On Mon, 9 Dec 2013, manning bill wrote:

piecemeal approach - a fact of life in todays environment.

http://www.washingtonpost.com/blogs/the-s= witch/wp/2013/09/25/author-of-california-online-eraser-law-it= s-not-always-easy-to-find-the-delete-button/


binding is easy, revocation is hard.



/bill
Neca eos omnes. =A0Deus suos agnoscet.

_______________________________________________
perpass mailing list
perpass@ietf.org<= br> https://www.ietf.org/mailman/listinfo/perpass


_______________________________________________
perpass mailing list
perpass@ietf.org<= br> https://www.ietf.org/mailman/listinfo/perpass

--089e0122771689dbfd04ed1c25b5-- From kathleen.moriarty@emc.com Mon Dec 9 08:13:54 2013 Return-Path: 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 497191ADF62 for ; Mon, 9 Dec 2013 08:13:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 nOOX7tQvwlLM for ; Mon, 9 Dec 2013 08:13:52 -0800 (PST) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 793FB1ADF55 for ; Mon, 9 Dec 2013 08:13:52 -0800 (PST) Received: from maildlpprd04.lss.emc.com (maildlpprd04.lss.emc.com [10.253.24.36]) by mailuogwprd02.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id rB9GDUoA014539 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Dec 2013 11:13:31 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com rB9GDUoA014539 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1386605611; bh=RN/LILZ6QHKa3XEMKhJt2/EPCNY=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=Z2bZAb0ugRaumz2NbA1siJM9B3WW+PuL5KjjEPaRvU9UmYBR2XzV4W2rX8e2tlvUZ LssRB7PRywkqRKowlFt9cZy0z1tP8RB/MGWg+qCCO/OPx9j8I6bqGnwtkjXkWgHzDQ VYL1K9K4w5a/1eDhM2j1sC/fb7dg39uf3laZfsb0= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com rB9GDUoA014539 Received: from mailusrhubprd03.lss.emc.com (mailusrhubprd03.lss.emc.com [10.253.24.21]) by maildlpprd04.lss.emc.com (RSA Interceptor); Mon, 9 Dec 2013 08:13:20 -0800 Received: from mxhub08.corp.emc.com (mxhub08.corp.emc.com [128.222.70.205]) by mailusrhubprd03.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id rB9GDKWn025006 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 9 Dec 2013 11:13:20 -0500 Received: from mx15a.corp.emc.com ([169.254.1.239]) by mxhub08.corp.emc.com ([128.222.70.205]) with mapi; Mon, 9 Dec 2013 11:13:19 -0500 From: "Moriarty, Kathleen" To: Michael Richardson , Phillip Hallam-Baker Date: Mon, 9 Dec 2013 11:13:18 -0500 Thread-Topic: [perpass] NULL Cipher RFC 2410 to HISTORIC ??? Thread-Index: Ac709jXYEJ2XxXKIRbuyNgBeuE34nQAAqDjA Message-ID: References: <0FE7905C-950F-4030-8A47-37C523FB497A@doubleshotsecurity.com> <95276F1E-2293-41F3-A6E7-7AEF4B22E811@doubleshotsecurity.com> <4613980CFC78314ABFD7F85CC302772121B1EC40@IL-EX10.ad.checkpoint.com> <2962.1386604013@sandelman.ca> In-Reply-To: <2962.1386604013@sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd03.lss.emc.com X-RSA-Classifications: DLM_1, public Cc: perpass , Yoav Nir , Merike Kaeo Subject: Re: [perpass] NULL Cipher RFC 2410 to HISTORIC ??? 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 16:13:54 -0000 QUggd2FzIGludGVuZGVkIHRvIHByZXNlcnZlIGludGVncml0eSwgc28gTWljaGFlbCdzIGFyZ3Vt ZW50IG1ha2VzIHBlcmZlY3Qgc2Vuc2UuICBJZiB5b3UgYXJlIGdvaW5nIHRvIHVzZSBBSCwgeW91 IHdhbnQgdG8gZW5zdXJlIGludGVncml0eSBmcm9tIGVuZC10by1lbmQuDQoNClVzZSBjYXNlcyBm b3IgdGhpcyBhcmUgdmFsaWQsIGJ1dCBJIGp1c3QgZG9uJ3QgdGhpbmsgdGhlcmUgd2FzIG11Y2gg aW50ZXJlc3QgZm9yIGFjdHVhbCBkZXBsb3ltZW50LiAgSSBvbmx5IGNhbWUgYWNyb3NzIGl0IG9u Y2UgYW5kIGFncmVlZCB3aXRoIHRoZSB1c2FnZSwgYnV0IHBlb3BsZSAob3BlcmF0b3JzKSBpbiBn ZW5lcmFsIHdlcmUgbm90IGludGVyZXN0ZWQuICBEYXRhIGNvcnJ1cHRpb24gd2FzIHRoZSBtb3Rp dmF0b3IgaW4gdGhlIG9uZSB1c2UgY2FzZSBJIHdvcmtlZCBvbiwgYnV0IHlvdSBjb3VsZCBjaGVj ayBhIGhhc2ggb24gdGhlIHJlY2VpdmVkIGRhdGEgdG8gYWNjb21wbGlzaCB0aGF0IGFueXdheS4g IEkgdGhpbmsgdGhlIHZpZXdzIHdlcmUgZGlmZmVyZW50IGZyb20gcmVzZWFyY2gvcHJvdG9jb2wg ZGVzaWduIHRvIG9wZXJhdG9ycyBpbiB0aGlzIGNhc2UuDQoNCk5BVCBtYXkgYmUgcGFydCBvZiBp dCwgYnV0IGlmIG5vIG9uZSBpcyBpbnRlcmVzdGVkIHRvIHVzZSBpdC4uLg0KDQpCZXN0IHJlZ2Fy ZHMsDQpLYXRobGVlbg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogcGVycGFz cyBbbWFpbHRvOnBlcnBhc3MtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1pY2hhZWwg UmljaGFyZHNvbg0KU2VudDogTW9uZGF5LCBEZWNlbWJlciAwOSwgMjAxMyAxMDo0NyBBTQ0KVG86 IFBoaWxsaXAgSGFsbGFtLUJha2VyDQpDYzogcGVycGFzczsgWW9hdiBOaXI7IE1lcmlrZSBLYWVv DQpTdWJqZWN0OiBSZTogW3BlcnBhc3NdIE5VTEwgQ2lwaGVyIFJGQyAyNDEwIHRvIEhJU1RPUklD ID8/Pw0KDQoNClBoaWxsaXAgSGFsbGFtLUJha2VyIDxoYWxsYW1AZ21haWwuY29tPiB3cm90ZToN CiAgICA+ICAgICBQaGlsLA0KDQogICAgPiAgICAgVGhlIGlzc3VlIGlzIG5vdCB0aGF0IEVTUCBu ZWVkcyBhIE5VTEwgY2lwaGVyLiBJdCdzIHRoYXQgQUgNCiAgICA+IHdvdWxkbid0IHRyYXZlcnNl IE5BVCwgYW5kIHNvIHRoZXkgbmVlZGVkIEVTUCB0byBkbyB0aGUgd29yayB0aGF0IEFIDQogICAg PiB3YXMgZGVzaWduZWQgdG8gZG8uDQoNCg0KICAgID4gSSB1bmRlcnN0YW5kIHRoYXQsIHRob3Vn aCB0aGUgZmFjdCB0aGF0IEVTUCB3aXRoIGF1dGhlbnRpY2F0aW9uIHdvdWxkDQogICAgPiB3b3Jr IHRocm91Z2ggTkFUIGJ1dCBub3QgQUggc2VlbXMgcmVtYXJrYWJseSBvZGQgdG8gbWUuIEl0IHN1 Z2dlc3RzDQogICAgPiB0aGF0IHRoZSBkZXNpZ24gaXMgd3JvbmcuDQoNCiAgICA+IFRoYXQgZmxh Z3MgYSBkZXNpZ24gZXJyb3IgaW4gdGhlIHByb3RvY29sIEFGSUFLLsKgDQoNCk5vLCBpdCdzIGJl Y2F1c2UgTkFUIGlzIGFuIGF0dGFjayBieSBhIG1pZGRsZSBib3ggb24gZW5kIHRvIGVuZCBmbG93 LCBhbmQgYmFjayBpbiAxOTk0LCB3ZSBkaWRuJ3QgdGhpbmsgYW55b25lIHdvdWxkIGJlIHNvIHN0 dXBpZCBhcyB0byBkbyB0aGF0IGtpbmQgb2YgdGhpbmcuDQoNCg0KDQotLQ0KTWljaGFlbCBSaWNo YXJkc29uIDxtY3IrSUVURkBzYW5kZWxtYW4uY2E+LCBTYW5kZWxtYW4gU29mdHdhcmUgV29ya3MN Cg0KDQo= From warren@kumari.net Mon Dec 9 09:11:18 2013 Return-Path: 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 5EFF41AE355 for ; Mon, 9 Dec 2013 09:11:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-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 Qmdz9dudldwj for ; Mon, 9 Dec 2013 09:11:14 -0800 (PST) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9792B1AE00A for ; Mon, 9 Dec 2013 09:11:14 -0800 (PST) Received: from [192.168.1.153] (unknown [66.84.81.105]) by vimes.kumari.net (Postfix) with ESMTPSA id 3480B1B40379; Mon, 9 Dec 2013 12:11:09 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Warren Kumari In-Reply-To: Date: Mon, 9 Dec 2013 12:11:07 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <805B66E1-2145-4EAA-9AF3-4F5FFC6EB986@kumari.net> References: To: David Lloyd-Jones X-Mailer: Apple Mail (2.1822) Cc: perpass , Warren Kumari Subject: Re: [perpass] Today's Paper 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 17:11:18 -0000 On Dec 9, 2013, at 3:21 AM, David Lloyd-Jones = wrote: > = http://www.nytimes.com/2013/12/09/technology/tech-giants-issue-call-for-li= mits-on-government-surveillance-of-users.html?src=3Drecg >=20 > Tech Giants Issue Call for Limits on Government Surveillance of Users >=20 > Connie Zhou/Google > Servers in a Google data center in Oregon. The company is tightening = its networks against government spying. > By EDWARD WYATT and CLAIRE CAIN MILLER > Published: December 9, 2013 > Eight prominent technology companies, bruised by revelations of = government spying on their customers=92 data and scrambling to repair = the damage to their reputations, are mounting a public campaign to urge = President Obama and Congress to set new limits on government = surveillance >=20 > . Related to this is the "Reform ECPA: Tell the Government to Get a = Warrant=94 petition - = https://petitions.whitehouse.gov/petition/reform-ecpa-tell-government-get-= warrant/nq258dxk "We call on the Obama Administration to support ECPA reform and to = reject any special rules that would force online service providers to = disclose our email without a warrant." If you are a US person, you can sign this and try reform the Electronic = Communications Privacy Act > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass --=20 Outside of a dog, a book is your best friend, and inside of a dog, it's = too dark to read=20 From bmanning@isi.edu Mon Dec 9 10:05:44 2013 Return-Path: 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 C43AC1AE419 for ; Mon, 9 Dec 2013 10:05:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jY_P1dpHl9B6 for ; Mon, 9 Dec 2013 10:05:43 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 4347E1AE418 for ; Mon, 9 Dec 2013 10:05:43 -0800 (PST) Received: from [128.9.184.131] ([128.9.184.131]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id rB9I4xZP011589 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 9 Dec 2013 10:04:59 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: manning bill In-Reply-To: Date: Mon, 9 Dec 2013 10:04:59 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <86BC54D4-7D2F-42F1-BA46-A73585605D58@isi.edu> To: Lucy Lynch X-Mailer: Apple Mail (2.1283) X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: bmanning@isi.edu Cc: perpass Subject: Re: [perpass] into the legal arena 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 18:05:45 -0000 revocation of the binding still leaves the data in play=85.=20 this is an oldie but goodie=85 http://www.oii.ox.ac.uk/news/?id=3D465 ISBN-10: 0691138613 /bill Neca eos omnes. Deus suos agnoscet. On 9December2013Monday, at 7:34, Lucy Lynch wrote: > On Mon, 9 Dec 2013, manning bill wrote: >=20 >> piecemeal approach - a fact of life in todays environment. >>=20 >> = http://www.washingtonpost.com/blogs/the-switch/wp/2013/09/25/author-of-cal= ifornia-online-eraser-law-its-not-always-easy-to-find-the-delete-button/ >>=20 >=20 > binding is easy, revocation is hard. >=20 >>=20 >> /bill >> Neca eos omnes. Deus suos agnoscet. >>=20 >> _______________________________________________ >> perpass mailing list >> perpass@ietf.org >> https://www.ietf.org/mailman/listinfo/perpass >>=20 >>=20 From hallam@gmail.com Mon Dec 9 10:05:48 2013 Return-Path: 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 275521AE41D for ; Mon, 9 Dec 2013 10:05:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 PL35FVla2bNa for ; Mon, 9 Dec 2013 10:05:46 -0800 (PST) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 0BBE51AE418 for ; Mon, 9 Dec 2013 10:05:45 -0800 (PST) Received: by mail-we0-f180.google.com with SMTP id t61so3801987wes.39 for ; Mon, 09 Dec 2013 10:05:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZCi2CVaASctJsN1YCsxmOiBAB2g0sBABCuCzcGGXei0=; b=VqWpLyb3jzf7UN0QR/XWj7ERvDvMIYEtkofi3sX+aadx7Nw8u7eWfgrgrgS4AtVvcw 572U7ImBmsK1He/8XGNsufsqTIezM2Pfo73Ykb6mh9QV1Y4m1L2OrYkaJiFQslRMb2ql Xiq9tRMKImyo96AJzpMKP9J1GllOEkc3MB42usyurW2nKxp0GfGO8FWNDp8pvkXt+3h7 r2g7t1dFMilbPwFF6PlyTrbu3TWupNaUhroAsHnR2TNjtIuw94c0lg6DntFzhK/80a1H tK788OCQrijDeKwJrImv55pijqyrGWCk8Az0S8KpGRuC271JVvtUHbs29Us2VpvIE6zu J2MA== MIME-Version: 1.0 X-Received: by 10.180.108.97 with SMTP id hj1mr15246543wib.59.1386612340762; Mon, 09 Dec 2013 10:05:40 -0800 (PST) Received: by 10.194.243.136 with HTTP; Mon, 9 Dec 2013 10:05:40 -0800 (PST) In-Reply-To: <52A5D9C5.1050700@bbn.com> References: <52A5D9C5.1050700@bbn.com> Date: Mon, 9 Dec 2013 13:05:40 -0500 Message-ID: From: Phillip Hallam-Baker To: Stephen Kent Content-Type: multipart/alternative; boundary=e89a8f3bafef032fea04ed1dd87f Cc: perpass Subject: Re: [perpass] NULL Cipher RFC 2410 to HISTORIC ??? 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 18:05:48 -0000 --e89a8f3bafef032fea04ed1dd87f Content-Type: text/plain; charset=ISO-8859-1 On Mon, Dec 9, 2013 at 9:55 AM, Stephen Kent wrote: > Phillip, > > On Sun, Dec 8, 2013 at 5:00 PM, Hannes Tschofenig < > hannes.tschofenig@gmx.net> wrote: > >> Hi Stephen, Hi Nicholas, >> >> it would be interesting (as a history lesson) if someone could tell us >> why the group at that time decided to develop a NULL encryption mechanism. >> Stephen Kent (co-author of RFC 2410) might remember. I have no heard >> > > It was for testing > > no, it was not. please see my response to Hannes. > > Steve > Well what I should have said is 'testing and other legit stuff'. The people I talked to said they wanted it for testing. The point was that it was a completely reasonable proposal. Given the attitude of the IETF to NAT back in those days there would be good reason not to lead with NAT bypass as the motivation for the spec. As for the language being 'delightfully tongue in cheek', its the sort of thing that looks fun when written but can look awfully bad if there is an issue resulting. At any rate, I think the point is made sufficiently that NULL ciphers in legacy suites do not represent a policy precedent against the PERPASS work. --- Website: http://hallambaker.com/ --e89a8f3bafef032fea04ed1dd87f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, Dec 9, 2013 at 9:55 AM, Stephen Kent <= kent@bbn.com> wrote:
=20 =20 =20
Phillip,

On Sun, Dec 8, 2013 at 5:00 PM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
Hi Stephen, Hi Nicholas,

it would be interesting (as a history lesson) if someone could tell us why the group at that time decided to develop a NULL encryption mechanism. Stephen Kent (co-author of RFC 2410) might remember. I have no heard

It was for testing
no, it was not. please see my response to Hannes.

Steve

Well what I should have said is 'testing and other legit stuff&= #39;. The people I talked to said they wanted it for testing. The point was= that it was a completely reasonable proposal.

Given the a= ttitude of the IETF to NAT back in those days there would be good reason no= t to lead with NAT bypass as the motivation for the spec.


A= s for the language being 'delightfully tongue in cheek', its the so= rt of thing that looks fun when written but can look awfully bad if there i= s an issue resulting.

At any rate= , I think the point is made sufficiently that NULL ciphers in legacy suites= do not represent a policy precedent against the PERPASS work.

---
Website: http://hallam= baker.com/
--e89a8f3bafef032fea04ed1dd87f-- From joe@cdt.org Mon Dec 9 10:14:45 2013 Return-Path: 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 AC6E51AE42D for ; Mon, 9 Dec 2013 10:14:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 mdedOKEImB2V for ; Mon, 9 Dec 2013 10:14:43 -0800 (PST) Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by ietfa.amsl.com (Postfix) with ESMTP id C898D1AE02D for ; Mon, 9 Dec 2013 10:14:42 -0800 (PST) X-Footer: Y2R0Lm9yZw== Received: from localhost ([127.0.0.1]) by mail.maclaboratory.net (using TLSv1/SSLv3 with cipher AES256-SHA (256 bits)) for perpass@ietf.org; Mon, 9 Dec 2013 13:14:36 -0500 Message-ID: <52A6088B.7040100@cdt.org> Date: Mon, 09 Dec 2013 13:14:35 -0500 From: Joseph Lorenzo Hall User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: perpass@ietf.org References: <86BC54D4-7D2F-42F1-BA46-A73585605D58@isi.edu> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [perpass] into the legal arena 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 18:14:45 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 (while this is what we do, I have a sinking suspicion that this is off-topic for perpass; please let me know if you fell that way.) On 12/9/13 11:04 AM, Al Clark wrote: > I'm encouraged by the political impulse behind this, but I do > wonder about the cost of implementing it and whether it will meet > its stated goals. That it's coming from California is also > heartening, again on the political level. We testified against this bill, emphasizing that one person's request to take something down off the internet can be an infringement on another person's free expression: https://www.cdt.org/blogs/2506cdt-testifies-two-california-bills-threaten-free-expression-and-privacy-online And here's a more recent review of this genre of legislation as applied to minors, which has us troubled: https://cdt.org/blogs/emma-llanso/2611do-not-track-kids-bill-revives-minors%E2%80%99-online-privacy-debate - -- Joseph Lorenzo Hall Chief Technologist Center for Democracy & Technology 1634 I ST NW STE 1100 Washington DC 20006-4011 (p) 202-407-8825 (f) 202-637-0968 joe@cdt.org PGP: https://josephhall.org/gpg-key fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSpgiLAAoJEF+GaYdAqahxkqUP/2TRq72Ow38ydiaL4UkRAASE nsuLDeSA3oMzf3FsfHVmNnMIucvpQVsqXFwt6JND9f4P9anRN39m1ULWAfayN08q S7AVPQDlSKubiujpKeF517eftrpEwboPNIKhIEW6OHBrCU/+BglK/zX/efslinWT Z0C1x8C/0sYRffLITbmaUmC2KHWcwtS6Vh36GHk7YVIC8lct9v4EzDb6fdR7ew9K cZtQzc8C67BOD9XSZE+9PjLhp69GH/YOSuChIaKzTieWAcU7FcLUtnRhg9NKePIA Yn5a6WZF70Qbv4cHsWb0pnhIdJWqT3eQBlse+voTAqEPEvDVgB+minwd4JUpUctw 7vqrX4VzBu77uI48fx/bx+ol1y4eev/Y4+k2hoAdBdXyGNvKT9HWccj1CEGpVz0h vSxxg2BFhY19L0AFhCSu1hMsuXciJw+6bJs5BfDmp5RjRNrvE5URyEE9ndwun5fW 9+CT6dNaOWj8AcavkL055ww3JneSX142cC4HLlMn0OnCm5TN+UdapEKMfgSnXQsx D4r9/0rwoBX0/7PHlNJKt8ciwePoYVNVse9Y9h4PoDGr0LFG1qmSH1MGxVHzifh3 bk2CiIbd1oDzqvM2dAnbY85tL9yDgqHP2mCGbbmcqu1yNedFrT80PYPeUsj0mA6Y 21IRj8RHlYoe9NaoiaYG =wnA4 -----END PGP SIGNATURE----- From paul@cypherpunks.ca Mon Dec 9 10:50:17 2013 Return-Path: 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 C373D1AE3DE for ; Mon, 9 Dec 2013 10:50:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_44=0.6] 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 RTysvhF1-119 for ; Mon, 9 Dec 2013 10:50:16 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 5FA841AE04B for ; Mon, 9 Dec 2013 10:50:16 -0800 (PST) Received: by bofh.nohats.ca (Postfix, from userid 500) id B7F8B80A04; Mon, 9 Dec 2013 13:50:10 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id AA51E80A01 for ; Mon, 9 Dec 2013 13:50:10 -0500 (EST) Date: Mon, 9 Dec 2013 13:50:10 -0500 (EST) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: perpass In-Reply-To: Message-ID: References: <52A5D9C5.1050700@bbn.com> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [perpass] NULL Cipher RFC 2410 to HISTORIC ??? 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 18:50:17 -0000 On Mon, 9 Dec 2013, Phillip Hallam-Baker wrote: > At any rate, I think the point is made sufficiently that NULL ciphers in legacy suites do not represent a policy precedent against the > PERPASS work. I think that calling something NULL ENCRYPTION is pretty clear. There are clear testing and benchmark reasons to keep these. However, to bring this back to perpass focus, it _is_ our job to ensure these proposals are never picked automatically, or are ever part of a "default set" or proposals that are valid. Speaking for libreswan, we only allow it when configured specifically using, eg esp=null-md5 and even then we issue a warning: # ipsec auto --up westnet-eastnet-null 104 "westnet-eastnet-null" #1: STATE_MAIN_I1: initiate 003 "westnet-eastnet-null" #1: received Vendor ID payload [Dead Peer Detection] 003 "westnet-eastnet-null" #1: received Vendor ID payload [FRAGMENTATION] 106 "westnet-eastnet-null" #1: STATE_MAIN_I2: sent MI2, expecting MR2 108 "westnet-eastnet-null" #1: STATE_MAIN_I3: sent MI3, expecting MR3 003 "westnet-eastnet-null" #1: received Vendor ID payload [CAN-IKEv2] 004 "westnet-eastnet-null" #1: STATE_MAIN_I4: ISAKMP SA established {auth=OAKLEY_RSA_SIG cipher=aes_128 prf=oakley_sha group=modp2048} 117 "westnet-eastnet-null" #2: STATE_QUICK_I1: initiate 003 "westnet-eastnet-null" #2: You should NOT use insecure/broken ESP algorithms [ESP_NULL (0)]! 004 "westnet-eastnet-null" #2: STATE_QUICK_I2: sent QI2, IPsec SA established tunnel mode {ESP=>0xESPESP<0xESPESP xfrm=NULL_0-HMAC_MD5 NATOA =none NATD=none DPD=none} That said, I think it is more much more important to ensure we get rid of algorithms people still use not being aware their strength is as good as NULL. We still cannot remove 1DES code from our tree because it will break "legitimate" deployments. As an opensource vendor, we have subverted these to be compile-time options (default off), and tell vendors not to enable that compilation option. As for whether we should move AH, Transport Mode, Compression, Narrowing, MD5, and other IPsec ideas to historirc, that is probably better discussed on the ipsecme list. Paul From brian.e.carpenter@gmail.com Mon Dec 9 11:47:33 2013 Return-Path: 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 BE0D31AE511 for ; Mon, 9 Dec 2013 11:47:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 bHtXOHWwCFcM for ; Mon, 9 Dec 2013 11:47:31 -0800 (PST) Received: from mail-pd0-x230.google.com (mail-pd0-x230.google.com [IPv6:2607:f8b0:400e:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id 64C711AE50E for ; Mon, 9 Dec 2013 11:47:31 -0800 (PST) Received: by mail-pd0-f176.google.com with SMTP id w10so5732098pde.7 for ; Mon, 09 Dec 2013 11:47:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=fc6fs07NCY315mP7JbTxdbzLQ+EiUTZ4L3axnJOBOak=; b=sC4H5Y6kKmzJQTTd+q6isc86Bevb5k27sV6uJrnU7OJQ3RTs51OqxuLaI20sBApqNk 4nKXppOEKXlONrrV/gP/D5K+gQ8TnU3QTW83c+1VMTHED3ruZ86VW8K5G0hg1Q1QgpHj s4d2eK0EDqJz0Wc3m/MIfxW78d0X9npThGyqwtcQ3cXB/D66UQDtj9lA2mg1Dy0yxyZ4 XNjeGMBYtH6kxJ+Dvtw6hX5qv1Kr81uuqapIRkaYGtcDTMhK/Zt8+SOBk4yRLSDU6WFG 0Eh7uIsIiwOKM9vWQCarMnfSDjp2+2jzlHYlxKISsHyJG8b6Htds3P18cC4H6IfaCDp1 4jvg== X-Received: by 10.68.143.231 with SMTP id sh7mr23195809pbb.7.1386618446528; Mon, 09 Dec 2013 11:47:26 -0800 (PST) Received: from [192.168.178.20] (208.199.69.111.dynamic.snap.net.nz. [111.69.199.208]) by mx.google.com with ESMTPSA id sg1sm20033265pbb.16.2013.12.09.11.47.24 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 09 Dec 2013 11:47:25 -0800 (PST) Message-ID: <52A61E4C.6020403@gmail.com> Date: Tue, 10 Dec 2013 08:47:24 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Stewart Bryant (stbryant)" References: <290E20B455C66743BE178C5C84F1240847E5103799@EXMB01CMS.surrey.ac.uk>, <2C66A416-5F07-4803-A4C0-BB61734BA42E@nominum.com> <290E20B455C66743BE178C5C84F1240847E510379A@EXMB01CMS.surrey.ac.uk>, <529F7690.2050302@gmx.net> <290E20B455C66743BE178C5C84F1240847E510379C@EXMB01CMS.surrey.ac.uk>, <52A1BBBC.9090509@cs.tcd.ie> <290E20B455C66743BE178C5C84F1240847E510379D@EXMB01CMS.surrey.ac.uk> <52A4D7D9.9000603@cs.tcd.ie>, <52A4E412.4030804@gmail.com> <72B86100-E73E-46BD-ABD6-8E35D56DBDDA@cisco.com> In-Reply-To: <72B86100-E73E-46BD-ABD6-8E35D56DBDDA@cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: perpass@ietf.org Subject: [perpass] Tiny stacks 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 19:47:34 -0000 On 09/12/2013 11:04, Stewart Bryant (stbryant) wrote: (on a different list and under a differeny Subject header) ... > Remembering of course that some platforms which wish > to use the Internet simply do not have the capability for > other than a very tiny very basic stack. > > I always use the PIC and the Arduino to remind myself what the > lower end of the franchise looks like. It seems to me that perpass should think a little bit about privacy and anti-surveillance issues for devices with tiny stacks, and see if that calls for any specific IETF work items. Brian From rlb@ipv.sx Mon Dec 9 12:04:31 2013 Return-Path: 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 875971AE284 for ; Mon, 9 Dec 2013 12:04:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 yqQJR3WrgURA for ; Mon, 9 Dec 2013 12:04:30 -0800 (PST) Received: from mail-oa0-f53.google.com (mail-oa0-f53.google.com [209.85.219.53]) by ietfa.amsl.com (Postfix) with ESMTP id DD0EC1ADFB2 for ; Mon, 9 Dec 2013 12:04:29 -0800 (PST) Received: by mail-oa0-f53.google.com with SMTP id m1so4490354oag.12 for ; Mon, 09 Dec 2013 12:04:25 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=hDmhDbBRHm713S+G+/6XzABcbODBDgWysbU/nzAZ6hU=; b=Rjpqb0GPt5GnFaqk6cQNtikpM/xg/aocJzG3/KChbYCLFpZmU74UTChBhMrs0MstqV EQMFFD6DA34ZU1ASmF7FqqvvEFBwIcg15hspccqtM/bEQZra4zfQvZ8WkvOg6oSsmPQV Exm977J+Cxqlb6K1IuP7AT1nsOPNckbeyUSNl8TTnYBPo234cPXmAIhaQGUpauOfICIB AY9TgqY481x2SRcbxdoscgMw2ej90p0Ge05Gm8JBQLF3t0EedxskkQ0jh0RDfj/Wccwb IoffLxozczHF7Umff+PnE78ZVTXAavuAzHA5psHfhPopTkb4TxfMHDwUWS0pc03QVWtB ukTw== X-Gm-Message-State: ALoCoQmihXM6K7PHCidX8DxMPTbVN1qkqHGgkGrzulG2lNG7mg2tqGmZ7oNDP6Si8k3PwyPqAhm8 MIME-Version: 1.0 X-Received: by 10.60.150.238 with SMTP id ul14mr14042993oeb.28.1386619464933; Mon, 09 Dec 2013 12:04:24 -0800 (PST) Received: by 10.60.31.74 with HTTP; Mon, 9 Dec 2013 12:04:24 -0800 (PST) In-Reply-To: <52A61E4C.6020403@gmail.com> References: <290E20B455C66743BE178C5C84F1240847E5103799@EXMB01CMS.surrey.ac.uk> <2C66A416-5F07-4803-A4C0-BB61734BA42E@nominum.com> <290E20B455C66743BE178C5C84F1240847E510379A@EXMB01CMS.surrey.ac.uk> <529F7690.2050302@gmx.net> <290E20B455C66743BE178C5C84F1240847E510379C@EXMB01CMS.surrey.ac.uk> <52A1BBBC.9090509@cs.tcd.ie> <290E20B455C66743BE178C5C84F1240847E510379D@EXMB01CMS.surrey.ac.uk> <52A4D7D9.9000603@cs.tcd.ie> <52A4E412.4030804@gmail.com> <72B86100-E73E-46BD-ABD6-8E35D56DBDDA@cisco.com> <52A61E4C.6020403@gmail.com> Date: Mon, 9 Dec 2013 15:04:24 -0500 Message-ID: From: Richard Barnes To: Brian E Carpenter Content-Type: multipart/alternative; boundary=047d7b5d35b8a572a504ed1f80fb Cc: perpass , "Stewart Bryant \(stbryant\)" Subject: Re: [perpass] Tiny stacks 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 20:04:31 -0000 --047d7b5d35b8a572a504ed1f80fb Content-Type: text/plain; charset=ISO-8859-1 On Mon, Dec 9, 2013 at 2:47 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > On 09/12/2013 11:04, Stewart Bryant (stbryant) wrote: > (on a different list and under a differeny Subject header) > ... > > > Remembering of course that some platforms which wish > > to use the Internet simply do not have the capability for > > other than a very tiny very basic stack. > > > > I always use the PIC and the Arduino to remind myself what the > > lower end of the franchise looks like. > > It seems to me that perpass should think a little bit about > privacy and anti-surveillance issues for devices with tiny > stacks, and see if that calls for any specific IETF work items. > This is not unexplored territory. > > Brian > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > --047d7b5d35b8a572a504ed1f80fb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On M= on, Dec 9, 2013 at 2:47 PM, Brian E Carpenter <brian.e.carpenter= @gmail.com> wrote:
On 09/12/2013 11:04, Stewart Bryant (stbryant) wrote:
(on a different list and under a differeny Subject header)
...

> Remembering of course that some platforms which wish
> to use the Internet simply do not have the capability for
> other than a very tiny very basic stack.
>
> I always use the PIC and the Arduino to remind myself what the
> lower end of the franchise looks like.

It seems to me that perpass should think a little bit about
privacy and anti-surveillance issues for devices with tiny
stacks, and see if that calls for any specific IETF work items.

This is not unexplored territory.
<http://tools.i= etf.org/html/draft-ietf-core-coap-18>


=A0

=A0 =A0 Brian
_______________________________________________
perpass mailing list
perpass@ietf.org
https://www.ietf.org/mailman/listinfo/perpass

--047d7b5d35b8a572a504ed1f80fb-- From fergdawgster@mykolab.com Mon Dec 9 12:40:18 2013 Return-Path: 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 ACFE21AE0A7 for ; Mon, 9 Dec 2013 12:40:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, 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 eyrF52x_WtT2 for ; Mon, 9 Dec 2013 12:40:16 -0800 (PST) Received: from mx01.mykolab.com (mx01.mykolab.com [95.128.36.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59E631AE559 for ; Mon, 9 Dec 2013 12:40:16 -0800 (PST) X-Virus-Scanned: amavisd-new at kolabsys.net Sender: fergdawgster@mykolab.com Message-ID: <52A62AA0.40809@mykolab.com> Date: Mon, 09 Dec 2013 12:40:00 -0800 From: Paul Ferguson Organization: Clowns R. Mofos To: Stephen Farrell , Eliot Lear References: <52A5B79E.2040202@cisco.com> <52A5C458.200@cs.tcd.ie> In-Reply-To: <52A5C458.200@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: perpass Subject: Re: [perpass] comments and questions for the group on draft-farrell-perpass-attack-02 X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: fergdawgster@mykolab.com 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: Mon, 09 Dec 2013 20:40:18 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/9/2013 5:23 AM, Stephen Farrell wrote: >> That >> >wouldn't be appropriate, in my opinion. A working group must consider >> >the operational realities that it is attempting to code to. There are >> >many tensions to consider, not just a narrow view of network management >> >(a phrase that might itself be left to ambiguous interpretation). > "Operational realities" is far more vague IMO. Perhaps even dangerously > so since it could be used to attempt to justify pretty much anything. That is also my interpretation/fear here. :-/ - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 10.2.0 (Build 2317) Charset: utf-8 wj8DBQFSpiqbq1pz9mNUZTMRAqmRAKDvetOQM3wAAD5q/NqMNSVRL/7yxgCdGOdD 7kOXcUdQiPWaxZmpptdNmiw= =U5uT -----END PGP SIGNATURE----- -- Paul Ferguson PGP Public Key ID: 0x63546533 From wilton@isoc.org Mon Dec 9 12:46:28 2013 Return-Path: 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 7C4C21AE4C9 for ; Mon, 9 Dec 2013 12:46:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 1fXmHn9uIkVs for ; Mon, 9 Dec 2013 12:46:26 -0800 (PST) Received: from smtp70.iad3a.emailsrvr.com (smtp70.iad3a.emailsrvr.com [173.203.187.70]) by ietfa.amsl.com (Postfix) with ESMTP id B87951AE312 for ; Mon, 9 Dec 2013 12:46:26 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp17.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id B240F2A007B; Mon, 9 Dec 2013 15:46:21 -0500 (EST) X-Virus-Scanned: OK Received: by smtp17.relay.iad3a.emailsrvr.com (Authenticated sender: wilton-AT-isoc.org) with ESMTPSA id 72BF92A00AE; Mon, 9 Dec 2013 15:46:20 -0500 (EST) References: <290E20B455C66743BE178C5C84F1240847E5103799@EXMB01CMS.surrey.ac.uk> <2C66A416-5F07-4803-A4C0-BB61734BA42E@nominum.com> <290E20B455C66743BE178C5C84F1240847E510379A@EXMB01CMS.surrey.ac.uk> <529F7690.2050302@gmx.net> <290E20B455C66743BE178C5C84F1240847E510379C@EXMB01CMS.surrey.ac.uk> <52A1BBBC.9090509@cs.tcd.ie> <290E20B455C66743BE178C5C84F1240847E510379D@EXMB01CMS.surrey.ac.uk> <52A4D7D9.9000603@cs.tcd.ie> <52A4E412.4030804@gmail.com> <72B86100-E73E-46BD-ABD6-8E35D56DBDDA@cisco.com> <52A61E4C.6020403@gmail.com> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-7CF43E25-625E-434D-9F8B-A76C1F413ECC Message-Id: X-Mailer: iPad Mail (9B206) From: Robin Wilton Date: Mon, 9 Dec 2013 21:50:11 +0100 To: Richard Barnes Cc: perpass , "Stewart Bryant \(stbryant\)" Subject: Re: [perpass] Tiny stacks 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 20:46:28 -0000 --Apple-Mail-7CF43E25-625E-434D-9F8B-A76C1F413ECC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii And in some cases, a tiny stack is an advantage. It shortens the path whose t= rustworthiness one has to assure. Robin Wilton Technical Outreach Director - Identity and Privacy On 9 Dec 2013, at 21:04, Richard Barnes wrote: > On Mon, Dec 9, 2013 at 2:47 PM, Brian E Carpenter wrote: > On 09/12/2013 11:04, Stewart Bryant (stbryant) wrote: > (on a different list and under a differeny Subject header) > ... >=20 > > Remembering of course that some platforms which wish > > to use the Internet simply do not have the capability for > > other than a very tiny very basic stack. > > > > I always use the PIC and the Arduino to remind myself what the > > lower end of the franchise looks like. >=20 > It seems to me that perpass should think a little bit about > privacy and anti-surveillance issues for devices with tiny > stacks, and see if that calls for any specific IETF work items. >=20 > This is not unexplored territory. > > > >=20 >=20 > =20 >=20 > Brian > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass >=20 > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass --Apple-Mail-7CF43E25-625E-434D-9F8B-A76C1F413ECC Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=utf-8
And in some cases, a tiny stack is an advantage. It shortens the path whose trustworthiness one has to assure.

Robin Wilton

Technical Outreach Director - Identity and Privacy

On 9 Dec 2013, at 21:04, Richard Barnes <rlb@ipv.sx> wrote:

On Mon, Dec 9, 2013 at 2:47 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
On 09/12/2013 11:04, Stewart Bryant (stbryant) wrote:
(on a different list and under a differeny Subject header)
...

> Remembering of course that some platforms which wish
> to use the Internet simply do not have the capability for
> other than a very tiny very basic stack.
>
> I always use the PIC and the Arduino to remind myself what the
> lower end of the franchise looks like.

It seems to me that perpass should think a little bit about
privacy and anti-surveillance issues for devices with tiny
stacks, and see if that calls for any specific IETF work items.

This is not unexplored territory.


 

    Brian
_______________________________________________
perpass mailing list
perpass@ietf.org
https://www.ietf.org/mailman/listinfo/perpass

_______________________________________________
perpass mailing list
perpass@ietf.org
https://www.ietf.org/mailman/listinfo/perpass
--Apple-Mail-7CF43E25-625E-434D-9F8B-A76C1F413ECC-- From fergdawgster@mykolab.com Mon Dec 9 12:52:32 2013 Return-Path: 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 0819D1AE0A6 for ; Mon, 9 Dec 2013 12:52:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO=1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 W3TA9CPR5XjX for ; Mon, 9 Dec 2013 12:52:30 -0800 (PST) Received: from mx01.mykolab.com (mx01.mykolab.com [95.128.36.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08DDD1AE06F for ; Mon, 9 Dec 2013 12:52:29 -0800 (PST) X-Virus-Scanned: amavisd-new at kolabsys.net Sender: fergdawgster@mykolab.com Message-ID: <52A62D80.5010504@mykolab.com> Date: Mon, 09 Dec 2013 12:52:16 -0800 From: Paul Ferguson Organization: Clowns R. Mofos To: Phillip Hallam-Baker References: <52A5D9C5.1050700@bbn.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: perpass Subject: Re: [perpass] NULL Cipher RFC 2410 to HISTORIC ??? X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: fergdawgster@mykolab.com 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: Mon, 09 Dec 2013 20:52:32 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Below: On 12/9/2013 10:05 AM, Phillip Hallam-Baker wrote: > > > > On Mon, Dec 9, 2013 at 9:55 AM, Stephen Kent > wrote: > > Phillip, > >> On Sun, Dec 8, 2013 at 5:00 PM, Hannes Tschofenig >> > >> wrote: >> >> Hi Stephen, Hi Nicholas, >> >> it would be interesting (as a history lesson) if someone could >> tell us why the group at that time decided to develop a NULL >> encryption mechanism. Stephen Kent (co-author of RFC 2410) >> might remember. I have no heard >> >> >> It was for testing > no, it was not. please see my response to Hannes. > > Steve > > > Well what I should have said is 'testing and other legit stuff'. The > people I talked to said they wanted it for testing. The point was that > it was a completely reasonable proposal. > > Given the attitude of the IETF to NAT back in those days there would be > good reason not to lead with NAT bypass as the motivation for the spec. > Regardless of the IETF's position on NAT then (I was *much* more active in various IETF WGs back then) or now, NAT is a operational reality, will be for the foreseeable future. It's "technical impurities" matter not, in that regard. - - ferg > > As for the language being 'delightfully tongue in cheek', its the sort > of thing that looks fun when written but can look awfully bad if there > is an issue resulting. > > At any rate, I think the point is made sufficiently that NULL ciphers in > legacy suites do not represent a policy precedent against the PERPASS > work. > > --- > Website: http://hallambaker.com/ > > > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 10.2.0 (Build 2317) Charset: utf-8 wj8DBQFSpi14q1pz9mNUZTMRAlooAKDi4+KZtbzbvLK4ZNPiqr9BCZfIJwCcDH23 wZwZcquGS3e8f/Zh0pqfaRQ= =7K0s -----END PGP SIGNATURE----- -- Paul Ferguson PGP Public Key ID: 0x63546533 From fergdawgster@mykolab.com Mon Dec 9 12:56:57 2013 Return-Path: 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 DEF441AE0CF for ; Mon, 9 Dec 2013 12:56:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO=1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 8ARftefJXN-e for ; Mon, 9 Dec 2013 12:56:56 -0800 (PST) Received: from mx01.mykolab.com (mx01.mykolab.com [95.128.36.1]) by ietfa.amsl.com (Postfix) with ESMTP id A75D21AE312 for ; Mon, 9 Dec 2013 12:56:56 -0800 (PST) X-Virus-Scanned: amavisd-new at kolabsys.net Sender: fergdawgster@mykolab.com Message-ID: <52A62E8A.8060209@mykolab.com> Date: Mon, 09 Dec 2013 12:56:42 -0800 From: Paul Ferguson Organization: Clowns R. Mofos To: Robin Wilton References: <290E20B455C66743BE178C5C84F1240847E5103799@EXMB01CMS.surrey.ac.uk> <2C66A416-5F07-4803-A4C0-BB61734BA42E@nominum.com> <290E20B455C66743BE178C5C84F1240847E510379A@EXMB01CMS.surrey.ac.uk> <529F7690.2050302@gmx.net> <290E20B455C66743BE178C5C84F1240847E510379C@EXMB01CMS.surrey.ac.uk> <52A1BBBC.9090509@cs.tcd.ie> <290E20B455C66743BE178C5C84F1240847E510379D@EXMB01CMS.surrey.ac.uk> <52A4D7D9.9000603@cs.tcd.ie> <52A4E412.4030804@gmail.com> <72B86100-E73E-46BD-ABD6-8E35D56DBDDA@cisco.com> <52A61E4C.6020403@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: perpass Subject: Re: [perpass] Tiny stacks X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: fergdawgster@mykolab.com 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: Mon, 09 Dec 2013 20:56:58 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 We'll most likely find out sooner rather than later if this whole "Internet of Things" materializes. :-) That should only be a half-smiley above, since we are talking about 'smart' TVs, home security systems, vacuum cleaners, etc. - - ferg On 12/9/2013 12:50 PM, Robin Wilton wrote: > And in some cases, a tiny stack is an advantage. It shortens the path > whose trustworthiness one has to assure. > > Robin Wilton > > Technical Outreach Director - Identity and Privacy > > On 9 Dec 2013, at 21:04, Richard Barnes > > wrote: > >> On Mon, Dec 9, 2013 at 2:47 PM, Brian E Carpenter >> > >> wrote: >> >> On 09/12/2013 11:04, Stewart Bryant (stbryant) wrote: >> (on a different list and under a differeny Subject header) >> ... >> >> > Remembering of course that some platforms which wish >> > to use the Internet simply do not have the capability for >> > other than a very tiny very basic stack. >> > >> > I always use the PIC and the Arduino to remind myself what the >> > lower end of the franchise looks like. >> >> It seems to me that perpass should think a little bit about >> privacy and anti-surveillance issues for devices with tiny >> stacks, and see if that calls for any specific IETF work items. >> >> >> This is not unexplored territory. >> >> >> >> >> >> >> Brian -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 10.2.0 (Build 2317) Charset: utf-8 wj8DBQFSpi55q1pz9mNUZTMRAiMNAJ4/mw4i+lpRs8meIHgWnwovzCbRKgCeNnNc ZJPDPA3dFw4qPu0V24nCqU4= =mnxl -----END PGP SIGNATURE----- -- Paul Ferguson PGP Public Key ID: 0x63546533 From hannes.tschofenig@gmx.net Mon Dec 9 12:57:06 2013 Return-Path: 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 D7E2A1AE55F for ; Mon, 9 Dec 2013 12:57:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 WvWJzeVFuzCO for ; Mon, 9 Dec 2013 12:57:04 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id 5CEA91AE554 for ; Mon, 9 Dec 2013 12:57:04 -0800 (PST) Received: from [192.168.10.140] ([2.102.217.110]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MfAog-1WDqlP44E6-00Oset for ; Mon, 09 Dec 2013 21:56:58 +0100 Message-ID: <52A62E98.2060705@gmx.net> Date: Mon, 09 Dec 2013 20:56:56 +0000 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Brian E Carpenter , "Stewart Bryant (stbryant)" References: <290E20B455C66743BE178C5C84F1240847E5103799@EXMB01CMS.surrey.ac.uk>, <2C66A416-5F07-4803-A4C0-BB61734BA42E@nominum.com> <290E20B455C66743BE178C5C84F1240847E510379A@EXMB01CMS.surrey.ac.uk>, <529F7690.2050302@gmx.net> <290E20B455C66743BE178C5C84F1240847E510379C@EXMB01CMS.surrey.ac.uk>, <52A1BBBC.9090509@cs.tcd.ie> <290E20B455C66743BE178C5C84F1240847E510379D@EXMB01CMS.surrey.ac.uk> <52A4D7D9.9000603@cs.tcd.ie>, <52A4E412.4030804@gmail.com> <72B86100-E73E-46BD-ABD6-8E35D56DBDDA@cisco.com> <52A61E4C.6020403@gmail.com> In-Reply-To: <52A61E4C.6020403@gmail.com> Content-Type: multipart/alternative; boundary="------------060301000301010301070908" X-Provags-ID: V03:K0:qEFD/9pDN8QfUa2zdHSn6a5JQ9xnw1Nxo1qbLxWPl3d/onOc5oD q0Yfa3EyNOgqxl2lL6uCen82i8j44G/Nc9ZYJUxFCAOsbOihAlLLtMYSJRQ6fEcmiq7cTZg RbHUwhCM3JLOFfbGNFdEBlj/s3dp07z6PJL6yCWxH+xSOBRLqELaJGoXykBHnl7NMuWywYg gOsR1ZDOM5eA/znOaUaJA== Cc: perpass@ietf.org Subject: Re: [perpass] Tiny stacks 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 20:57:07 -0000 This is a multi-part message in MIME format. --------------060301000301010301070908 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Many of us are actually thinking about how to get the IP stack on these devices. The IAB had a workshop in 2011 on smart objects and the report can be found here: http://tools.ietf.org/html/rfc6574 We then had a workshop specifically dedicated to security in 2012: http://tools.ietf.org/html/draft-gilger-smart-object-security-workshop-02 (pending publication as an RFC). There is even an IAB document in development that touches this topic: http://tools.ietf.org/html/draft-iab-smart-object-architecture-03 (Comments welcome) [Recent comments indicated that there is a desire to talk more about IPv6, and the transition mechanisms. Great that we worked on so many -- will for sure make it easier to fit them all on these devices.] As you know, we even have the IETF LWIG group that discusses these issues. If you look at recent events, like the Internet census http://internetcensus2012.bitbucket.org/paper.html, then it should be clear that even "small device" need security since otherwise we are building the next generation botnet. This would not be good (tm). Ciao Hannes On 12/09/2013 07:47 PM, Brian E Carpenter wrote: > On 09/12/2013 11:04, Stewart Bryant (stbryant) wrote: > (on a different list and under a differeny Subject header) > ... > >> Remembering of course that some platforms which wish >> to use the Internet simply do not have the capability for >> other than a very tiny very basic stack. >> >> I always use the PIC and the Arduino to remind myself what the >> lower end of the franchise looks like. > It seems to me that perpass should think a little bit about > privacy and anti-surveillance issues for devices with tiny > stacks, and see if that calls for any specific IETF work items. > > Brian > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass --------------060301000301010301070908 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Many of us are actually thinking about how to get the IP stack on these devices.

The IAB had a workshop in 2011 on smart objects and the report can be found here: http://tools.ietf.org/html/rfc6574

We then had a workshop specifically dedicated to security in 2012:
http://tools.ietf.org/html/draft-gilger-smart-object-security-workshop-02
(pending publication as an RFC).

There is even an IAB document in development that touches this topic:
http://tools.ietf.org/html/draft-iab-smart-object-architecture-03
(Comments welcome)

[Recent comments indicated that there is a desire to talk more about IPv6, and the transition mechanisms. Great that we worked on so many -- will for sure make it easier to fit them all on these devices.]

As you know, we even have the IETF LWIG group that discusses these issues.

If you look at recent events, like the Internet census http://internetcensus2012.bitbucket.org/paper.html, then it should be clear that even "small device" need security since otherwise we are building the next generation botnet. This would not be good (tm).

Ciao
Hannes


On 12/09/2013 07:47 PM, Brian E Carpenter wrote:
On 09/12/2013 11:04, Stewart Bryant (stbryant) wrote:
(on a different list and under a differeny Subject header)
...


Remembering of course that some platforms which wish
to use the Internet simply do not have the capability for
other than a very tiny very basic stack.

I always use the PIC and the Arduino to remind myself what the
lower end of the franchise looks like.

It seems to me that perpass should think a little bit about
privacy and anti-surveillance issues for devices with tiny
stacks, and see if that calls for any specific IETF work items.

    Brian
_______________________________________________
perpass mailing list
perpass@ietf.org
https://www.ietf.org/mailman/listinfo/perpass

--------------060301000301010301070908-- From martin@millnert.se Mon Dec 9 13:55:52 2013 Return-Path: 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 1F5351AE108 for ; Mon, 9 Dec 2013 13:55:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.693 X-Spam-Level: X-Spam-Status: No, score=0.693 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, RDNS_NONE=0.793, SPF_PASS=-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 1xYiftdhi1EO for ; Mon, 9 Dec 2013 13:55:50 -0800 (PST) Received: from mail.millnert.se (unknown [95.80.32.84]) by ietfa.amsl.com (Postfix) with ESMTP id 295FC1AE0D0 for ; Mon, 9 Dec 2013 13:55:49 -0800 (PST) Received: from [192.168.120.241] (dynamic.1.9.c0255cb5b480.f46d4e0fc2a.afb.bredband2.com [31.208.64.196]) by mail.millnert.se (Postfix) with ESMTPSA id A0294A3; Mon, 9 Dec 2013 22:58:27 +0100 (CET) Message-ID: <1386626136.7652.24.camel@pishuli.lund.millnert.se> From: Martin Millnert To: Brian E Carpenter Date: Mon, 09 Dec 2013 22:55:36 +0100 In-Reply-To: <52A61E4C.6020403@gmail.com> References: <290E20B455C66743BE178C5C84F1240847E5103799@EXMB01CMS.surrey.ac.uk> , <2C66A416-5F07-4803-A4C0-BB61734BA42E@nominum.com> <290E20B455C66743BE178C5C84F1240847E510379A@EXMB01CMS.surrey.ac.uk> , <529F7690.2050302@gmx.net> <290E20B455C66743BE178C5C84F1240847E510379C@EXMB01CMS.surrey.ac.uk> , <52A1BBBC.9090509@cs.tcd.ie> <290E20B455C66743BE178C5C84F1240847E510379D@EXMB01CMS.surrey.ac.uk> <52A4D7D9.9000603@cs.tcd.ie>, <52A4E412.4030804@gmail.com> <72B86100-E73E-46BD-ABD6-8E35D56DBDDA@cisco.com> <52A61E4C.6020403@gmail.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-OUg5HbYbl+gkRFNUCpcD" X-Mailer: Evolution 3.4.4-3 Mime-Version: 1.0 Cc: perpass@ietf.org, "Stewart Bryant \(stbryant\)" Subject: [perpass] Way forward? [Was: Tiny stacks] 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 21:55:52 -0000 --=-OUg5HbYbl+gkRFNUCpcD Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2013-12-10 at 08:47 +1300, Brian E Carpenter wrote: > It seems to me that perpass should think a little bit about > privacy and anti-surveillance issues for devices with tiny > stacks, and see if that calls for any specific IETF work items. I completely agree it's good to understand consequences on security requirements. That will probably follow naturally on the other hand, once said requirements become known. But what's more important, is what failure to fulfill the requirements mean. For example: Requirements & considerations for mitigating pervasive passive surveillance are . Device D or protocol P fulfills 50% of . Thus, D / P are not [insert pervasive surveillance-resistant consumer logo here] compliant. That would be some form of ideal information to possess, allowing protocols & implementations, etc. to more easily be benchmarked on their performance of surveillance-resistance. Divide and conquer. By enumerating and specifying the threats (on all stack layers, even if implementation of mitigation is not up to IETF) and what's generally required to avoid them separately from guidance on how to avoid them, or guidance for protocol wg's, I believe we can better avoid the... detours and distractions. Vendors have been building TLS MITM for enterprises for a long time. That is not necessarily going to be stopped by always-on-TLS in HTTP 2.0. That, and how to balance bandwidth saving caching functions with perpass-resistant protocols, is probably better discussed in their respective wg's. What should be perfectly clear is however, that for example in HTTP 2.0, allowing transparent proxies, will score very, very low on perpass-resistance. That benchmarking feature is IMO useful output from perpass following draft-farrell-perpass-attack-02, which to me reads completely fine. My 2c, Martin --=-OUg5HbYbl+gkRFNUCpcD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAABAgAGBQJSpjxYAAoJEKgraNdZrwxMBvoP/3a3A5l6tB4Tp5k0gcbv5yzR jXBOieYIK3H7pQLPbRiIpej06o9k5KikVJ14oEXYvUNzV+KwzhfroURqwk3H7tf/ NLNYHnggCED4XCST6uUTqjJnHlzXk/VWZXHMQv8Au0BDVhRz+xx0dI5xBzypaCUA j6SM6lPwiwS591qRTWcUCbynMg/KZmordCU5/W+Dl96n+pQa67LY9D7imLyngMwG ODjnJdZqGMltiUX7mXhGW42b5H22i6/N3lD8GSRiY/ZQBrbL+Q8BFEYslNiA9Gkx y3+kkw5UixzSQm4w8jLx7ICqlyzguMdV9A+Bgg/A+9AxTfQoa4AQgvBjs1KHMPQg vVXvWC4+M7g2qrkeUA/P3r1ZbkuzbbFNO36HkA9+Mq+ZXYi7ue001VIi0zF+gxc9 RFKsFI1kkp4P0BqiINUSEt+fpjGjdEycPJQywmYAFcJoAdQnVs8txGrcmaoTA6v+ LgVPSJc8cJMgoOEYkDWJEF1XSHBhOP7CBEVJD20ANSxduSzKvCx6l0GXPh5n0J3h iCsTQu8OnM/KWiO9dBxRYGBCiksX6mEyYaZjUMdJaiTbVMFSIytUMOPRbk4/pQR4 Vel8AJet3sRKi/5ucwgw5BiyOlsfDw05EB4eToZxnukvQbLE/Dcc4ioa6cUsK0G7 aVN5a9rDgNFUsioKiDZt =2MI7 -----END PGP SIGNATURE----- --=-OUg5HbYbl+gkRFNUCpcD-- From brian.e.carpenter@gmail.com Mon Dec 9 13:58:25 2013 Return-Path: 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 A06561AE5BD for ; Mon, 9 Dec 2013 13:58:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 dIh1G1ALPtRv for ; Mon, 9 Dec 2013 13:58:23 -0800 (PST) Received: from mail-pd0-x236.google.com (mail-pd0-x236.google.com [IPv6:2607:f8b0:400e:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id 901E61AE57C for ; Mon, 9 Dec 2013 13:58:23 -0800 (PST) Received: by mail-pd0-f182.google.com with SMTP id v10so5934854pde.41 for ; Mon, 09 Dec 2013 13:58:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Xa6Kof7YCQbx9kLLpR6WxPHjI0jRDa/81gq596gI8w4=; b=DTKakwLkFqCvLvWapgTzLBpp1u79iYueiveoZmW0ucjg9cdkaqU4JPZ8frX1N2++is /rxFixOzhTzUtiaMyKH+Pzt7zKcOEuE3GcODYGeTu4yL+/UTnst/daJ7HivyPRM+3gtP BZR1CWQ8/kZLjuK4A7IRzezy6pgfdMkQ3NZfZGiOFY5gDUSrUQVXX/rdZPlyJzWP9dSJ MK0xPSo5ytUm0a17gq/au/w4tUBRyFPBRfaj/79Vji4hyBXpNuiO9Ey0usfUCwLisloO iKHPTY9eONhJVHXmz8am+hlxSMhSIwrFkzDUhPQgZ9UpfpkIGknnX5x7yofCbDbUkWaY euKg== X-Received: by 10.68.99.162 with SMTP id er2mr23734644pbb.10.1386626298729; Mon, 09 Dec 2013 13:58:18 -0800 (PST) Received: from [192.168.178.20] (208.199.69.111.dynamic.snap.net.nz. [111.69.199.208]) by mx.google.com with ESMTPSA id sd3sm20440407pbb.42.2013.12.09.13.58.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 09 Dec 2013 13:58:17 -0800 (PST) Message-ID: <52A63CF9.7020303@gmail.com> Date: Tue, 10 Dec 2013 10:58:17 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Hannes Tschofenig References: <290E20B455C66743BE178C5C84F1240847E5103799@EXMB01CMS.surrey.ac.uk>, <2C66A416-5F07-4803-A4C0-BB61734BA42E@nominum.com> <290E20B455C66743BE178C5C84F1240847E510379A@EXMB01CMS.surrey.ac.uk>, <529F7690.2050302@gmx.net> <290E20B455C66743BE178C5C84F1240847E510379C@EXMB01CMS.surrey.ac.uk>, <52A1BBBC.9090509@cs.tcd.ie> <290E20B455C66743BE178C5C84F1240847E510379D@EXMB01CMS.surrey.ac.uk> <52A4D7D9.9000603@cs.tcd.ie>, <52A4E412.4030804@gmail.com> <72B86100-E73E-46BD-ABD6-8E35D56DBDDA@cisco.com> <52A61E4C.6020403@gmail.com> <52A62E98.2060705@gmx.net> In-Reply-To: <52A62E98.2060705@gmx.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: perpass@ietf.org, "Stewart Bryant \(stbryant\)" Subject: Re: [perpass] Tiny stacks 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 21:58:25 -0000 Hannes, On 10/12/2013 09:56, Hannes Tschofenig wrote: > Many of us are actually thinking about how to get the IP stack on these > devices. > > The IAB had a workshop in 2011 on smart objects and the report can be > found here: http://tools.ietf.org/html/rfc6574 > > We then had a workshop specifically dedicated to security in 2012: > http://tools.ietf.org/html/draft-gilger-smart-object-security-workshop-02 > (pending publication as an RFC). Fair enough, but did you consider specifically the privacy and surveillance aspects? I'm concerned that counter-measures that can be easily incorporated in full size devices may be too heavy for tiny devices. If this is not a real concern, I will be delighted of course. And there is the usual problem of converting workshop conclusions into WG action. Brian > There is even an IAB document in development that touches this topic: > http://tools.ietf.org/html/draft-iab-smart-object-architecture-03 > (Comments welcome) > > [Recent comments indicated that there is a desire to talk more about > IPv6, and the transition mechanisms. Great that we worked on so many -- > will for sure make it easier to fit them all on these devices.] > > As you know, we even have the IETF LWIG group that discusses these issues. > > If you look at recent events, like the Internet census > http://internetcensus2012.bitbucket.org/paper.html, then it should be > clear that even "small device" need security since otherwise we are > building the next generation botnet. This would not be good (tm). > > Ciao > Hannes > > > On 12/09/2013 07:47 PM, Brian E Carpenter wrote: >> On 09/12/2013 11:04, Stewart Bryant (stbryant) wrote: >> (on a different list and under a differeny Subject header) >> ... >> >>> Remembering of course that some platforms which wish >>> to use the Internet simply do not have the capability for >>> other than a very tiny very basic stack. >>> >>> I always use the PIC and the Arduino to remind myself what the >>> lower end of the franchise looks like. >> It seems to me that perpass should think a little bit about >> privacy and anti-surveillance issues for devices with tiny >> stacks, and see if that calls for any specific IETF work items. >> >> Brian >> _______________________________________________ >> perpass mailing list >> perpass@ietf.org >> https://www.ietf.org/mailman/listinfo/perpass > > From brian.e.carpenter@gmail.com Mon Dec 9 14:08:44 2013 Return-Path: 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 5993F1AE5E7; Mon, 9 Dec 2013 14:08:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 7xVlHpJ8BQS1; Mon, 9 Dec 2013 14:08:42 -0800 (PST) Received: from mail-pb0-x22b.google.com (mail-pb0-x22b.google.com [IPv6:2607:f8b0:400e:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id B31E51AE5E3; Mon, 9 Dec 2013 14:08:42 -0800 (PST) Received: by mail-pb0-f43.google.com with SMTP id rq2so6244429pbb.2 for ; Mon, 09 Dec 2013 14:08:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=/23L9bBJZVoXlAUDpZP6jVEE3iPQVBPcVfSn5Mx9k18=; b=kzIO/kl2cyPH8HO8tKDoimZ6uuxbS5tZ36Ze36p+QgKnxgifO1kBUs9SVjm5u9weSs g5wZfcP6nzEKYgKyxYqNLD9XwD4hvpRyj4oxLnt5nE/oEb4JbTxY2tO0PKRy+oEJrsyj qd6NNWeAVM6Mz6J6z4YFJ3mBtUcjlZ00UJHprboqjNx57JhCLT6eIsCCfMmiJ6SZKRbL jJZ4xKbXZHO4Ir6l6axh2T9XNcBGrCPc4wd4pQfCl6/em4cMinAu6AA4gz8ZSAlq1b5W wKqvKWn1KDevFuvY8NnGbL0IzHyxJnCjgn/2+XdV3Rx38alXAVUhM5Wlg3yOVtLeI3ji hA9g== X-Received: by 10.66.144.227 with SMTP id sp3mr23856275pab.100.1386626917872; Mon, 09 Dec 2013 14:08:37 -0800 (PST) Received: from [192.168.178.20] (208.199.69.111.dynamic.snap.net.nz. [111.69.199.208]) by mx.google.com with ESMTPSA id uf2sm20487133pbc.28.2013.12.09.14.08.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 09 Dec 2013 14:08:37 -0800 (PST) Message-ID: <52A63F64.3090908@gmail.com> Date: Tue, 10 Dec 2013 11:08:36 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Eliot Lear References: <7wmom0dq1s8yyc5t1qpvdxxl.1386593028146@email.android.com> <52A5CCB6.8070108@cisco.com> In-Reply-To: <52A5CCB6.8070108@cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: perpass , Internet Architecture Board , 'IESG' , Eric Burger Subject: Re: [perpass] comments and questions for the group on draft-farrell-perpass-attack-02 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 22:08:44 -0000 On 10/12/2013 02:59, Eliot Lear wrote: > On 12/9/13 1:43 PM, Eric Burger wrote: >> So if the "operational realities" of the operator include a mandate to >> intercept, like with a law like CALEA in the United States, then >> pervasive monitoring is OK? >> > > This does not negate the existing RFCs that speak to that. My understanding of the debate in Vancouver was that we intend to go one step beyond the RAVEN consensus (RFC 2804). Then, we agreed not to consider wiretapping requirements as part of the standards development process. This time, we agreed to treat pervasive surveillance as an attack, and therefore to try to make protocols resistant to it. Which is completely disjoint from whether operators deploy anti-surveillance measures; that is a matter of national law and not our department. Brian From hallam@gmail.com Mon Dec 9 14:53:09 2013 Return-Path: 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 1EE111A1F5B for ; Mon, 9 Dec 2013 14:53:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 oZtTtp6KNcNC for ; Mon, 9 Dec 2013 14:53:06 -0800 (PST) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) by ietfa.amsl.com (Postfix) with ESMTP id 59DB61A1F4E for ; Mon, 9 Dec 2013 14:53:06 -0800 (PST) Received: by mail-wi0-f178.google.com with SMTP id bz8so4410998wib.17 for ; Mon, 09 Dec 2013 14:53:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Dygka+s3/Svf7/3/7Jo6Ege54AaSW9nNy+0F3jX2lhk=; b=qL+Jpe4wY1tTfSPOf58r614HlSvxl1gzmxHm6JrT8JmYPV0uNsncriwMT36oBngTHs ybhmHjpjlf0z59z9AE0QJiTV2R9XZScUHnRmuurLFuwnbnR2o42+zE5G6ISgixkKlFI6 Tfqv2kdANCcCQC9VOwxMOuEFh4qSV6qntpUWyLB1QEYFo/hIkC9DskAnm7LimCXUHtT3 sbCRkE93KASumFzqOJkHr9sVpsuE1lKH7SZU+iiVzYwPKZLDuQnlUPiPdzO+xh/bQb/V chKie3PeLzAOEEYQusu07WkAJdcuEVyAUzS77O877AydOPrmqhBdyFF5rdN/FonkC7Cz wDJA== MIME-Version: 1.0 X-Received: by 10.194.94.167 with SMTP id dd7mr37708729wjb.43.1386629580738; Mon, 09 Dec 2013 14:53:00 -0800 (PST) Received: by 10.194.243.136 with HTTP; Mon, 9 Dec 2013 14:53:00 -0800 (PST) In-Reply-To: References: <290E20B455C66743BE178C5C84F1240847E5103799@EXMB01CMS.surrey.ac.uk> <2C66A416-5F07-4803-A4C0-BB61734BA42E@nominum.com> <290E20B455C66743BE178C5C84F1240847E510379A@EXMB01CMS.surrey.ac.uk> <529F7690.2050302@gmx.net> <290E20B455C66743BE178C5C84F1240847E510379C@EXMB01CMS.surrey.ac.uk> <52A1BBBC.9090509@cs.tcd.ie> <290E20B455C66743BE178C5C84F1240847E510379D@EXMB01CMS.surrey.ac.uk> <52A4D7D9.9000603@cs.tcd.ie> <52A4E412.4030804@gmail.com> <72B86100-E73E-46BD-ABD6-8E35D56DBDDA@cisco.com> <52A61E4C.6020403@gmail.com> Date: Mon, 9 Dec 2013 17:53:00 -0500 Message-ID: From: Phillip Hallam-Baker To: Richard Barnes Content-Type: multipart/alternative; boundary=047d7bb03c469855e704ed21dbd9 Cc: perpass , "Stewart Bryant \(stbryant\)" Subject: Re: [perpass] Tiny stacks 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 22:53:09 -0000 --047d7bb03c469855e704ed21dbd9 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Dec 9, 2013 at 3:04 PM, Richard Barnes wrote: > On Mon, Dec 9, 2013 at 2:47 PM, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > >> On 09/12/2013 11:04, Stewart Bryant (stbryant) wrote: >> (on a different list and under a differeny Subject header) >> ... >> >> > Remembering of course that some platforms which wish >> > to use the Internet simply do not have the capability for >> > other than a very tiny very basic stack. >> > >> > I always use the PIC and the Arduino to remind myself what the >> > lower end of the franchise looks like. >> >> It seems to me that perpass should think a little bit about >> privacy and anti-surveillance issues for devices with tiny >> stacks, and see if that calls for any specific IETF work items. >> > > This is not unexplored territory. > > > > COAP on a PIC? Really? Or are you talking about the 32bit one rather than the 8 bit one that is made in roughly double quantities year on year. The 8 bit one comes with 4Kbytes. I don't think you can get a TCP/IP stack in there. But you do quite often need to get some form of end to end security from a control system to an end point with a 6502 or Z80 class embedded device that is connected over an I2C or RS485 link. Right now that territory is occupied by MODBUS which is a protocol that hasn't changed since I used it thirty years ago before I went to college. It has no authentication or encryption and only limited error checking capabilities. We run nuclear power plants off MODBUS but the folk who do firework displays use MIDI because it has better error checking (oh I kid you not). We don't necessarily need to do IP end to end. I have never been a fan of that particular dogma. IP is a rotten match for RS485 at 9600baud. But being able to authenticate control messages and sensor readings end to end is badly needed. -- Website: http://hallambaker.com/ --047d7bb03c469855e704ed21dbd9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, Dec 9, 2013 at 3:04 PM, Richard Barnes &l= t;rlb@ipv.sx>= wrote:
=
On Mon, Dec 9, 2013 at 2:47 PM= , Brian E Carpenter <brian.e.carpenter@gmail.com> = wrote:
On 09/12/2013 11:04, Stewart Bryant (stbryant) wrote:
(on a different list and under a differeny Subject header)
...

> Remembering of course that some platforms which wish
> to use the Internet simply do not have the capability for
> other than a very tiny very basic stack.
>
> I always use the PIC and the Arduino to remind myself what the
> lower end of the franchise looks like.

It seems to me that perpass should think a little bit about
privacy and anti-surveillance issues for devices with tiny
stacks, and see if that calls for any specific IETF work items.

This is not unexplored territory.

COAP on a PIC? Really?

Or are you talking about the 32bit one rather than = the 8 bit one that is made in roughly double quantities year on year. The 8= bit one comes with 4Kbytes. I don't think you can get a TCP/IP stack i= n there.

But you do quite often need to get some form of end to = end security from a control system to an end point with a 6502 or Z80 class= embedded device that is connected over an I2C or RS485 link.=A0

Right now that territory is occupied by MODBUS which is a pr= otocol that hasn't changed since I used it thirty years ago before I we= nt to college. It has no authentication or encryption and only limited erro= r checking capabilities. We run nuclear power plants off MODBUS but the fol= k who do firework displays use MIDI because it has better error checking (o= h I kid you not).


We don't necessarily need to do IP e= nd to end. I have never been a fan of that particular dogma. IP is a rotten= match for RS485 at 9600baud. But being able to authenticate control messag= es and sensor readings end to end is badly needed.=A0

=A0
--
Website: http://hallambaker.com/
--047d7bb03c469855e704ed21dbd9-- From rlb@ipv.sx Mon Dec 9 15:03:14 2013 Return-Path: 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 2CB7D1A8028 for ; Mon, 9 Dec 2013 15:03:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_102=0.6, RCVD_IN_DNSWL_LOW=-0.7] 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 GSPsaB296hNw for ; Mon, 9 Dec 2013 15:03:12 -0800 (PST) Received: from mail-ob0-f180.google.com (mail-ob0-f180.google.com [209.85.214.180]) by ietfa.amsl.com (Postfix) with ESMTP id B07311AD84D for ; Mon, 9 Dec 2013 15:03:12 -0800 (PST) Received: by mail-ob0-f180.google.com with SMTP id wo20so4489852obc.39 for ; Mon, 09 Dec 2013 15:03:07 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=JOJgIBUJ0/U8OW4Yd0zLK/3l8HGbwvTdzYtGoZUyDsI=; b=GahLcB0l8QGkTdl3UB8/G/3B2jApYG1xkpaLgHIi4SM852YuTCbDzON/tI12iEWDcU Mbz7Mq+CLKkDon5MPEFEXKTgOdGxMjB/XTcL1OWmv9IbNhbDsKiV4TxWcEB1BFphgsly zNuVquHyMw/7nNFE8Fb5+TtHNz+uihj5Ict5vE8N/rgYlriHEnobYekNjGXrg+Ne89BY 2T0ZbMFTjbkG0zv7ncHJFUm8zsrGzZw1zuZXbu80DOl/ZH1kFGUqO8ZjNdb7M+WXDvlW GfwnOop+0AKhXNl7jtTJ6A19hXommkeaYdBK0rt/a/nP91ZfDFnSbj78lstkVKhnFjEg arng== X-Gm-Message-State: ALoCoQnRbpiZbryKJsu+lk4fmrLsM0ZkwtxQPBlwhD3IfCuJAD/Om9hOaCHmN8v/GvQ4rC0IuGjQ MIME-Version: 1.0 X-Received: by 10.60.146.229 with SMTP id tf5mr14552301oeb.27.1386630187581; Mon, 09 Dec 2013 15:03:07 -0800 (PST) Received: by 10.60.31.74 with HTTP; Mon, 9 Dec 2013 15:03:07 -0800 (PST) In-Reply-To: <52A63CF9.7020303@gmail.com> References: <290E20B455C66743BE178C5C84F1240847E5103799@EXMB01CMS.surrey.ac.uk> <2C66A416-5F07-4803-A4C0-BB61734BA42E@nominum.com> <290E20B455C66743BE178C5C84F1240847E510379A@EXMB01CMS.surrey.ac.uk> <529F7690.2050302@gmx.net> <290E20B455C66743BE178C5C84F1240847E510379C@EXMB01CMS.surrey.ac.uk> <52A1BBBC.9090509@cs.tcd.ie> <290E20B455C66743BE178C5C84F1240847E510379D@EXMB01CMS.surrey.ac.uk> <52A4D7D9.9000603@cs.tcd.ie> <52A4E412.4030804@gmail.com> <72B86100-E73E-46BD-ABD6-8E35D56DBDDA@cisco.com> <52A61E4C.6020403@gmail.com> <52A62E98.2060705@gmx.net> <52A63CF9.7020303@gmail.com> Date: Mon, 9 Dec 2013 18:03:07 -0500 Message-ID: From: Richard Barnes To: Brian E Carpenter Content-Type: multipart/alternative; boundary=047d7b5d98e9c41aae04ed21ff54 Cc: perpass , Hannes Tschofenig , "Stewart Bryant \(stbryant\)" Subject: Re: [perpass] Tiny stacks 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 23:03:14 -0000 --047d7b5d98e9c41aae04ed21ff54 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Dec 9, 2013 at 4:58 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > Hannes, > > On 10/12/2013 09:56, Hannes Tschofenig wrote: > > Many of us are actually thinking about how to get the IP stack on these > > devices. > > > > The IAB had a workshop in 2011 on smart objects and the report can be > > found here: http://tools.ietf.org/html/rfc6574 > > > > We then had a workshop specifically dedicated to security in 2012: > > > http://tools.ietf.org/html/draft-gilger-smart-object-security-workshop-02 > > (pending publication as an RFC). > > Fair enough, but did you consider specifically the privacy and > surveillance aspects? I'm concerned that counter-measures that can > be easily incorporated in full size devices may be too heavy for > tiny devices. If this is not a real concern, I will be delighted > of course. > > And there is the usual problem of converting workshop conclusions > into WG action. > As I recall, the major upshot of the workshop, from a security point of view, was that (1) security protocols are tough but tractable, and (2) the really hard problem is the introduction problem. By which I mean: Smart/IoT devices are going to, by their nature, talk to something else (otherwise they wouldn't need connectivity). The "introduction problem" is the challenge of telling devices whom they should talk to, and how to authenticate them, in such a way that doesn't allow an attacker to insert himself, with the very limited interfaces that IoT devices tend to have. At one layer, it's just an authentication / authorization problem, but it's one that has much more impact on hardware/software configuration than on protocol. That is my understanding, at least, of how we arrived at the current state, where most of the protocol work is focused on making the security protocols nicer (e.g., CoAP, DICE). Nobody has found an approach to the introduction problem that applies everywhere^Wa lot of places. In point of fact, most of the interesting IoT vulnerabilities we've seen so far have not been due to either of the above problems, but rather to manufacturers making stupid decisions that couldn't have been fixed by any number of RFCs. --Richard > Brian > > > There is even an IAB document in development that touches this topic: > > http://tools.ietf.org/html/draft-iab-smart-object-architecture-03 > > (Comments welcome) > > > > [Recent comments indicated that there is a desire to talk more about > > IPv6, and the transition mechanisms. Great that we worked on so many -- > > will for sure make it easier to fit them all on these devices.] > > > > As you know, we even have the IETF LWIG group that discusses these > issues. > > > > If you look at recent events, like the Internet census > > http://internetcensus2012.bitbucket.org/paper.html, then it should be > > clear that even "small device" need security since otherwise we are > > building the next generation botnet. This would not be good (tm). > > > > Ciao > > Hannes > > > > > > On 12/09/2013 07:47 PM, Brian E Carpenter wrote: > >> On 09/12/2013 11:04, Stewart Bryant (stbryant) wrote: > >> (on a different list and under a differeny Subject header) > >> ... > >> > >>> Remembering of course that some platforms which wish > >>> to use the Internet simply do not have the capability for > >>> other than a very tiny very basic stack. > >>> > >>> I always use the PIC and the Arduino to remind myself what the > >>> lower end of the franchise looks like. > >> It seems to me that perpass should think a little bit about > >> privacy and anti-surveillance issues for devices with tiny > >> stacks, and see if that calls for any specific IETF work items. > >> > >> Brian > >> _______________________________________________ > >> perpass mailing list > >> perpass@ietf.org > >> https://www.ietf.org/mailman/listinfo/perpass > > > > > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > --047d7b5d98e9c41aae04ed21ff54 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On M= on, Dec 9, 2013 at 4:58 PM, Brian E Carpenter <brian.e.carpenter= @gmail.com> wrote:
Hannes,

On 10/12/2013 09:56, Hannes Tschofenig wrote:
> Many of us are actually thinking about how to get the IP stack on thes= e
> devices.
>
> The IAB had a workshop in 2011 on smart objects and the report can be<= br> > found here: http://tools.ietf.org/html/rfc6574
>
> We then had a workshop specifically dedicated to security in 2012:
> http://tools.ietf.org/html/draft-gilger-s= mart-object-security-workshop-02
> (pending publication as an RFC).

Fair enough, but did you consider specifically the privacy and
surveillance aspects? I'm concerned that counter-measures that can
be easily incorporated in full size devices may be too heavy for
tiny devices. If this is not a real concern, I will be delighted
of course.

And there is the usual problem of converting workshop conclusions
into WG action.

As I recall, the major = upshot of the workshop, from a security point of view, was that (1) securit= y protocols are tough but tractable, and (2) the really hard problem is the= introduction problem. =A0By which I mean: Smart/IoT devices are going to, = by their nature, talk to something else (otherwise they wouldn't need c= onnectivity). =A0The "introduction problem" is the challenge of t= elling devices whom they should talk to, and how to authenticate them, in s= uch a way that doesn't allow an attacker to insert himself, with the ve= ry limited interfaces that IoT devices tend to have. =A0At one layer, it= 9;s just an authentication / authorization problem, but it's one that h= as much more impact on hardware/software configuration than on protocol.=A0=

That is my understanding, at least, of how we arrived a= t the current state, where most of the protocol work is focused on making t= he security protocols nicer (e.g., CoAP, DICE). =A0Nobody has found an appr= oach to the introduction problem that applies everywhere^Wa lot of places.<= /div>

In point of fact, most of the interesting IoT vulnerabi= lities we've seen so far have not been due to either of the above probl= ems, but rather to manufacturers making stupid decisions that couldn't = have been fixed by any number of RFCs.

--Richard

=A0


=A0 =A0 Brian

> There is even an IAB document in development that touches this topic:<= br> > http://tools.ietf.org/html/draft-iab-smart-object= -architecture-03
> (Comments welcome)
>
> [Recent comments indicated that there is a desire to talk more about > IPv6, and the transition mechanisms. Great that we worked on so many -= -
> will for sure make it easier to fit them all on these devices.]
>
> As you know, we even have the IETF LWIG group that discusses these iss= ues.
>
> If you look at recent events, like the Internet census
> http://internetcensus2012.bitbucket.org/paper.html, then it= should be
> clear that even "small device" need security since otherwise= we are
> building the next generation botnet. This would not be good (tm).
>
> Ciao
> Hannes
>
>
> On 12/09/2013 07:47 PM, Brian E Carpenter wrote:
>> On 09/12/2013 11:04, Stewart Bryant (stbryant) wrote:
>> (on a different list and under a differeny Subject header)
>> ...
>>
>>> Remembering of course that some platforms which wish
>>> to use the Internet simply do not have the capability for
>>> other than a very tiny very basic stack.
>>>
>>> I always use the PIC and the Arduino to remind myself what the=
>>> lower end of the franchise looks like.
>> It seems to me that perpass should think a little bit about
>> privacy and anti-surveillance issues for devices with tiny
>> stacks, and see if that calls for any specific IETF work items. >>
>> =A0 =A0 Brian
>> _______________________________________________
>> perpass mailing list
>> perpass@ietf.org
>> https://www.ietf.org/mailman/listinfo/perpass
>
>
_______________________________________________
perpass mailing list
perpass@ietf.org
https://www.ietf.org/mailman/listinfo/perpass

--047d7b5d98e9c41aae04ed21ff54-- From martin.thomson@gmail.com Mon Dec 9 15:07:41 2013 Return-Path: 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 3CE801AD945 for ; Mon, 9 Dec 2013 15:07:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 DMZfWKDZIInk for ; Mon, 9 Dec 2013 15:07:39 -0800 (PST) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) by ietfa.amsl.com (Postfix) with ESMTP id 79C211AD943 for ; Mon, 9 Dec 2013 15:07:39 -0800 (PST) Received: by mail-wi0-f179.google.com with SMTP id z2so4525676wiv.0 for ; Mon, 09 Dec 2013 15:07:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OKvvmnphcoU7Oi/lAWnp2MMGcUo8Fx8EAbIdDLSQw8g=; b=vSzOZ7EHha4t9RTh2rggeveZiFHVpgeOgi/+yYHa7d/fId77Qy+JhEuFxygew+78bR ddDYx5yqMd4xZwuOYsKnkJFS5bxPxML4y0UkjDhwQj5d+VncadubVdltyy/4x+Jh5EVM cURdkGJU9hC4/OINJAgwwpe6RiW8c2FNn3TfcEoP3GWxuQP9pXBciugp0bIERrxk91Ve +yx+2yg9f+GZEdWk2LLF+HrJRzHpsoU0+4NCMcRlRmSg29Oir1D35Hai+vg7YvZGujZr fb4tFuXHYSxJAlMyXfK8kRSXCy72NULg1sKmxX/UFzWUEhHwRlPvLDW5a+P5i9t2njkz +Tew== MIME-Version: 1.0 X-Received: by 10.180.36.105 with SMTP id p9mr16303492wij.58.1386630454111; Mon, 09 Dec 2013 15:07:34 -0800 (PST) Received: by 10.227.134.195 with HTTP; Mon, 9 Dec 2013 15:07:34 -0800 (PST) In-Reply-To: References: <290E20B455C66743BE178C5C84F1240847E5103799@EXMB01CMS.surrey.ac.uk> <2C66A416-5F07-4803-A4C0-BB61734BA42E@nominum.com> <290E20B455C66743BE178C5C84F1240847E510379A@EXMB01CMS.surrey.ac.uk> <529F7690.2050302@gmx.net> <290E20B455C66743BE178C5C84F1240847E510379C@EXMB01CMS.surrey.ac.uk> <52A1BBBC.9090509@cs.tcd.ie> <290E20B455C66743BE178C5C84F1240847E510379D@EXMB01CMS.surrey.ac.uk> <52A4D7D9.9000603@cs.tcd.ie> <52A4E412.4030804@gmail.com> <72B86100-E73E-46BD-ABD6-8E35D56DBDDA@cisco.com> <52A61E4C.6020403@gmail.com> <52A62E98.2060705@gmx.net> <52A63CF9.7020303@gmail.com> Date: Mon, 9 Dec 2013 15:07:34 -0800 Message-ID: From: Martin Thomson To: Richard Barnes Content-Type: text/plain; charset=UTF-8 Cc: perpass Subject: Re: [perpass] Tiny stacks 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 23:07:41 -0000 On 9 December 2013 15:03, Richard Barnes wrote: > In point of fact, most of the interesting IoT vulnerabilities we've seen so > far have not been due to either of the above problems, but rather to > manufacturers making stupid decisions that couldn't have been fixed by any > number of RFCs. Do you mean to say that RFCs are not the place to address this introduction problem, or that people ignore RFCs? The latter is something we already deal with; the former seems doable, were there the will to do so. From stephen.farrell@cs.tcd.ie Mon Dec 9 15:21:07 2013 Return-Path: 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 8A0C51ADF27 for ; Mon, 9 Dec 2013 15:21:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_102=0.6, 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 nRR8FgZApgBT for ; Mon, 9 Dec 2013 15:21:04 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 310761ADF4B for ; Mon, 9 Dec 2013 15:21:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id D01CEBE49; Mon, 9 Dec 2013 23:20:53 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tHJqQJb3gBKT; Mon, 9 Dec 2013 23:20:52 +0000 (GMT) Received: from [10.87.48.12] (unknown [86.42.25.130]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 14D71BE25; Mon, 9 Dec 2013 23:20:52 +0000 (GMT) Message-ID: <52A65049.2070903@cs.tcd.ie> Date: Mon, 09 Dec 2013 23:20:41 +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: Richard Barnes , Brian E Carpenter References: <290E20B455C66743BE178C5C84F1240847E5103799@EXMB01CMS.surrey.ac.uk> <2C66A416-5F07-4803-A4C0-BB61734BA42E@nominum.com> <290E20B455C66743BE178C5C84F1240847E510379A@EXMB01CMS.surrey.ac.uk> <529F7690.2050302@gmx.net> <290E20B455C66743BE178C5C84F1240847E510379C@EXMB01CMS.surrey.ac.uk> <52A1BBBC.9090509@cs.tcd.ie> <290E20B455C66743BE178C5C84F1240847E510379D@EXMB01CMS.surrey.ac.uk> <52A4D7D9.9000603@cs.tcd.ie> <52A4E412.4030804@gmail.com> <72B86100-E73E-46BD-ABD6-8E35D56DBDDA@cisco.com> <52A61E4C.6020403@gmail.com> <52A62E98.2060705@gmx.net> <52A63CF9.7020303@gmail.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: perpass , Hannes Tschofenig , "Stewart Bryant \(stbryant\)" Subject: Re: [perpass] Tiny stacks 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 23:21:07 -0000 On 12/09/2013 11:03 PM, Richard Barnes wrote: > As I recall, the major upshot of the workshop, from a security point of > view, was that (1) security protocols are tough but tractable, and (2) the > really hard problem is the introduction problem. By which I mean: > Smart/IoT devices are going to, by their nature, talk to something else > (otherwise they wouldn't need connectivity). The "introduction problem" is > the challenge of telling devices whom they should talk to, and how to > authenticate them, in such a way that doesn't allow an attacker to insert > himself, with the very limited interfaces that IoT devices tend to have. > At one layer, it's just an authentication / authorization problem, but > it's one that has much more impact on hardware/software configuration than > on protocol. Doesn't the same problem exist in homenet? Perhaps with more immediately tractable devices, esp. if there's new work that can be done in terms of avoiding pervasive monitoring. Could be that homenet is an easier target for work related to this space, at least initially. > That is my understanding, at least, of how we arrived at the current state, > where most of the protocol work is focused on making the security protocols > nicer (e.g., CoAP, DICE). Nobody has found an approach to the introduction > problem that applies everywhere^Wa lot of places. > > In point of fact, most of the interesting IoT vulnerabilities we've seen so > far have not been due to either of the above problems, but rather to > manufacturers making stupid decisions that couldn't have been fixed by any > number of RFCs. Its not directly relevant to pervasive monitoring, but IMO the worst security thing about tiny devices is the lack of s/w or firmware update. Without that, we're basically screwed istm. And we don't look like we're getting that, not even in proprietary flavours. Or maybe I'm out of date on that? Would love to be. S. > > --Richard > > > > >> Brian >> >>> There is even an IAB document in development that touches this topic: >>> http://tools.ietf.org/html/draft-iab-smart-object-architecture-03 >>> (Comments welcome) >>> >>> [Recent comments indicated that there is a desire to talk more about >>> IPv6, and the transition mechanisms. Great that we worked on so many -- >>> will for sure make it easier to fit them all on these devices.] >>> >>> As you know, we even have the IETF LWIG group that discusses these >> issues. >>> >>> If you look at recent events, like the Internet census >>> http://internetcensus2012.bitbucket.org/paper.html, then it should be >>> clear that even "small device" need security since otherwise we are >>> building the next generation botnet. This would not be good (tm). >>> >>> Ciao >>> Hannes >>> >>> >>> On 12/09/2013 07:47 PM, Brian E Carpenter wrote: >>>> On 09/12/2013 11:04, Stewart Bryant (stbryant) wrote: >>>> (on a different list and under a differeny Subject header) >>>> ... >>>> >>>>> Remembering of course that some platforms which wish >>>>> to use the Internet simply do not have the capability for >>>>> other than a very tiny very basic stack. >>>>> >>>>> I always use the PIC and the Arduino to remind myself what the >>>>> lower end of the franchise looks like. >>>> It seems to me that perpass should think a little bit about >>>> privacy and anti-surveillance issues for devices with tiny >>>> stacks, and see if that calls for any specific IETF work items. >>>> >>>> Brian >>>> _______________________________________________ >>>> perpass mailing list >>>> perpass@ietf.org >>>> https://www.ietf.org/mailman/listinfo/perpass >>> >>> >> _______________________________________________ >> perpass mailing list >> perpass@ietf.org >> https://www.ietf.org/mailman/listinfo/perpass >> > > > > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > From rlb@ipv.sx Mon Dec 9 15:21:30 2013 Return-Path: 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 B6A7E1ADE8B for ; Mon, 9 Dec 2013 15:21:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 84UcxuBQKvrt for ; Mon, 9 Dec 2013 15:21:29 -0800 (PST) Received: from mail-ob0-f171.google.com (mail-ob0-f171.google.com [209.85.214.171]) by ietfa.amsl.com (Postfix) with ESMTP id DD0F01AD8EE for ; Mon, 9 Dec 2013 15:21:28 -0800 (PST) Received: by mail-ob0-f171.google.com with SMTP id wp18so4540794obc.30 for ; Mon, 09 Dec 2013 15:21:23 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=cU6Ci7CCIpPlL5VEN/hn8jw6yBRxJZBweJ4lTaktQM0=; b=SVwIKcUrnOLOt1AZpkYm2hqmp7iCucj8BlD0J8chABixYLN3AeBzU68zyVZ4OollF+ boZEc7SG8ijKlxZs62KTt2O2BL0+mIyhlGF0WKbmWtfylHI+y8Z5oW9ygXzvmw/7LJ/Z Ha03n15A897Qwi2D02QCGf1fGrDmfsAzChB7vNBpELGq41CQuIV7oIdl9889jhixqUBg VZiYVVdwFUp3wDRKpdSUKMLlyuelNzc1FUPpJorqva+bgqnX2TLW4XhIGpc25HB8QQkZ jXTDp5zBGJf/Lwapo0mYxF10WJSetGeZ2K6rugqKQniFVDrNXVZnkveRubrChVoKv0/w ZoGQ== X-Gm-Message-State: ALoCoQkFI6fQXDumQGdsnXeD5yrJHdnCn2+pbOVArBh3cqCcOztuTjaNB+uCezM2+E/l06bCUCe0 MIME-Version: 1.0 X-Received: by 10.182.107.164 with SMTP id hd4mr4523359obb.58.1386631283755; Mon, 09 Dec 2013 15:21:23 -0800 (PST) Received: by 10.60.31.74 with HTTP; Mon, 9 Dec 2013 15:21:23 -0800 (PST) In-Reply-To: References: <290E20B455C66743BE178C5C84F1240847E5103799@EXMB01CMS.surrey.ac.uk> <2C66A416-5F07-4803-A4C0-BB61734BA42E@nominum.com> <290E20B455C66743BE178C5C84F1240847E510379A@EXMB01CMS.surrey.ac.uk> <529F7690.2050302@gmx.net> <290E20B455C66743BE178C5C84F1240847E510379C@EXMB01CMS.surrey.ac.uk> <52A1BBBC.9090509@cs.tcd.ie> <290E20B455C66743BE178C5C84F1240847E510379D@EXMB01CMS.surrey.ac.uk> <52A4D7D9.9000603@cs.tcd.ie> <52A4E412.4030804@gmail.com> <72B86100-E73E-46BD-ABD6-8E35D56DBDDA@cisco.com> <52A61E4C.6020403@gmail.com> <52A62E98.2060705@gmx.net> <52A63CF9.7020303@gmail.com> Date: Mon, 9 Dec 2013 18:21:23 -0500 Message-ID: From: Richard Barnes To: Martin Thomson Content-Type: multipart/alternative; boundary=089e01175e4d1a608404ed2241df Cc: perpass Subject: Re: [perpass] Tiny stacks 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 23:21:31 -0000 --089e01175e4d1a608404ed2241df Content-Type: text/plain; charset=ISO-8859-1 On Mon, Dec 9, 2013 at 6:07 PM, Martin Thomson wrote: > On 9 December 2013 15:03, Richard Barnes wrote: > > In point of fact, most of the interesting IoT vulnerabilities we've seen > so > > far have not been due to either of the above problems, but rather to > > manufacturers making stupid decisions that couldn't have been fixed by > any > > number of RFCs. > > Do you mean to say that RFCs are not the place to address this > introduction problem, or that people ignore RFCs? The latter is > something we already deal with; the former seems doable, were there > the will to do so. > I'm thinking of things like these... < http://thehackernews.com/2013/08/hacking-HP-printers-Vulnerability-wifi-password.html# > ... which do not seem like RFC-able things (so, the latter). Both are poor design decisions; the first not applying authentication/authorization, and the second, well, just epically failing. What are you going to do, require someone to set a jumper for DNT? --089e01175e4d1a608404ed2241df Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On M= on, Dec 9, 2013 at 6:07 PM, Martin Thomson <martin.thomson@gmail.co= m> wrote:
On 9 December 2013 15:03, Richard Barnes= <rlb@ipv.sx> wrote:
> In point of fact, most of the interesting IoT vulnerabilities we'v= e seen so
> far have not been due to either of the above problems, but rather to > manufacturers making stupid decisions that couldn't have been fixe= d by any
> number of RFCs.

Do you mean to say that RFCs are not the place to address this
introduction problem, or that people ignore RFCs? =A0The latter is
something we already deal with; the former seems doable, were there
the will to do so.

I'm thinking of= things like these...
<http://thehackernews.com/2013/08/hacking-HP-printers-Vulnerability-w= ifi-password.html#>
<http://bgr.co= m/2013/11/20/lg-smart-tv-spying/>

... which do not seem like RFC-able things (so= , the latter). =A0Both are poor design decisions; the first not applying au= thentication/authorization, and the second, well, just epically failing. Wh= at are you going to do, require someone to set a jumper for DNT?


<= /div> --089e01175e4d1a608404ed2241df-- From derhoermi@gmx.net Mon Dec 9 15:46:28 2013 Return-Path: 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 89C5C1ADF5A for ; Mon, 9 Dec 2013 15:46:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 Ilx-HOI7q-B9 for ; Mon, 9 Dec 2013 15:46:26 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id D07D41AD94A for ; Mon, 9 Dec 2013 15:46:25 -0800 (PST) Received: from netb.Speedport_W_700V ([84.180.228.227]) by mail.gmx.com (mrgmx102) with ESMTPA (Nemesis) id 0LvzF3-1VVdY63p5J-017pod for ; Tue, 10 Dec 2013 00:46:20 +0100 From: Bjoern Hoehrmann To: Richard Barnes Date: Tue, 10 Dec 2013 00:46:19 +0100 Message-ID: References: <290E20B455C66743BE178C5C84F1240847E510379D@EXMB01CMS.surrey.ac.uk> <52A4D7D9.9000603@cs.tcd.ie> <52A4E412.4030804@gmail.com> <72B86100-E73E-46BD-ABD6-8E35D56DBDDA@cisco.com> <52A61E4C.6020403@gmail.com> <52A62E98.2060705@gmx.net> <52A63CF9.7020303@gmail.com> In-Reply-To: X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:tD8BzYGVuLnL5r7AfKo2M9H6Y4qCAZW9HTcxRsszVnK6/xLkOkT xrzWy6gg7RGGAIhYZq0E3i0IbsWFbFrP6qASdzR+heAZwDiAb7u3aZ7FJGk8u7duJZRd/SV I7j21gorInSiQTKiSIzJxt4BuYcdrcGMbc3nvvPWrHvNcUcbPcNxlGeaCG3dWqmgdWjM3v6 sypl53dP3gD6quFX0bnMQ== Cc: perpass , Martin Thomson Subject: Re: [perpass] Tiny stacks 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 23:46:28 -0000 * Richard Barnes wrote: >I'm thinking of things like these... > > >... which do not seem like RFC-able things (so, the latter). Both are poor >design decisions; the first not applying authentication/authorization, and >the second, well, just epically failing. What are you going to do, require >someone to set a jumper for DNT? An LG Smart TV owner in the United Kingdom has shockingly discovered that his device is sending unencrypted data over Wi-Fi containing TV watching habits, as well as file names from external storage units hooked up to the TV to an LG website, even though the TV’s privacy settings should have prevented such behavior. Next device this data will be sent encrypted, with the keys and the software secured by the TV's "DRM" system so Smart TV owners will no longer be able to find out about such problems. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From rlb@ipv.sx Mon Dec 9 16:07:54 2013 Return-Path: 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 DD9FD1ADFB3 for ; Mon, 9 Dec 2013 16:07:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 Eenv1WaqX95f for ; Mon, 9 Dec 2013 16:07:52 -0800 (PST) Received: from mail-ob0-f176.google.com (mail-ob0-f176.google.com [209.85.214.176]) by ietfa.amsl.com (Postfix) with ESMTP id 37E561ADFAF for ; Mon, 9 Dec 2013 16:07:52 -0800 (PST) Received: by mail-ob0-f176.google.com with SMTP id va2so4545168obc.21 for ; Mon, 09 Dec 2013 16:07:47 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=2BSNT/XCoGeIqLdkKKJNJVnaK8J0dbujRkaM2ERNYS4=; b=c3vLYUH+vYuL6p9UkbywVXHGvjs9ZeUDS5i21iu5TEQ1glBiLxz8upsplqSHyotXml SUf+/HRJGCbtD37tYBAXVruX7hheEkb8vq+lVzmxgzD++RV8qwFktNBFBAhFztfUyLVv hBmkYDMD74qETAFCtI62JIOC4j44GsqCDYKeoiU1fe0F3d3kGm2qtqbA4o0WLZBC6KMe mciNpGh8TjPSVpTEwJImf1fZcgtcrL4MgKSlAqwz8SoGnHtOOipMNNwGoMOAZfaMRsq+ oWFbebV1+A1c5LBSOGlYLSSt2xiThVw6ilJbU9C7bco/G55ocrg5RDxPA/kFXqbXSe8/ fHog== X-Gm-Message-State: ALoCoQlmHfzcrENEa3mNLlr/rXCaDcvSnEoxpLYqS6kcsWfeuDgFPiCyY3Hkhf2+i439/u/SRTfY MIME-Version: 1.0 X-Received: by 10.60.60.105 with SMTP id g9mr14665223oer.8.1386634067023; Mon, 09 Dec 2013 16:07:47 -0800 (PST) Received: by 10.60.31.74 with HTTP; Mon, 9 Dec 2013 16:07:46 -0800 (PST) In-Reply-To: References: <290E20B455C66743BE178C5C84F1240847E510379D@EXMB01CMS.surrey.ac.uk> <52A4D7D9.9000603@cs.tcd.ie> <52A4E412.4030804@gmail.com> <72B86100-E73E-46BD-ABD6-8E35D56DBDDA@cisco.com> <52A61E4C.6020403@gmail.com> <52A62E98.2060705@gmx.net> <52A63CF9.7020303@gmail.com> Date: Mon, 9 Dec 2013 19:07:46 -0500 Message-ID: From: Richard Barnes To: Bjoern Hoehrmann Content-Type: multipart/alternative; boundary=089e0149d0aeffcd9f04ed22e643 Cc: perpass , Martin Thomson Subject: Re: [perpass] Tiny stacks 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 00:07:55 -0000 --089e0149d0aeffcd9f04ed22e643 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Mon, Dec 9, 2013 at 6:46 PM, Bjoern Hoehrmann wrote: > * Richard Barnes wrote: > >I'm thinking of things like these... > > > > > > >... which do not seem like RFC-able things (so, the latter). Both are > poor > >design decisions; the first not applying authentication/authorization, a= nd > >the second, well, just epically failing. What are you going to do, requi= re > >someone to set a jumper for DNT? > > An LG Smart TV owner in the United Kingdom has shockingly discovered > that his device is sending unencrypted data over Wi-Fi containing TV > watching habits, as well as file names from external storage units > hooked up to the TV to an LG website, even though the TV=92s privacy > settings should have prevented such behavior. > > Next device this data will be sent encrypted, with the keys and the > software secured by the TV's "DRM" system so Smart TV owners will no > longer be able to find out about such problems. > That actually seems like kind of a compelling rationale for authentication-only modes (as Bruce suggested) -- so we the network owners can see what our devices are doing. It's isomorphic to the enterprise case, but a little more intuitive for we end users. --Richard > -- > Bj=F6rn H=F6hrmann =B7 mailto:bjoern@hoehrmann.de =B7 http://bjoern.hoehr= mann.de > Am Badedeich 7 =B7 Telefon: +49(0)160/4415681 =B7 http://www.bjoernsworld= .de > 25899 Dageb=FCll =B7 PGP Pub. KeyID: 0xA4357E78 =B7 http://www.websitedev= .de/ > --089e0149d0aeffcd9f04ed22e643 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On M= on, Dec 9, 2013 at 6:46 PM, Bjoern Hoehrmann <derhoermi@gmx.net> wrote:
* Richard Barnes wrote: >I'm thinking of things like these...

><http://bgr.com/2013/11/20/lg-smart-tv-spyi= ng/>
>
>... which do not seem like RFC-able things (so, the latter). =A0Both ar= e poor
>design decisions; the first not applying authentication/authorization, = and
>the second, well, just epically failing. What are you going to do, requ= ire
>someone to set a jumper for DNT?

=A0 An LG Smart TV owner in the United Kingdom has shockingly discove= red
=A0 that his device is sending unencrypted data over Wi-Fi containing TV =A0 watching habits, as well as file names from external storage units
=A0 hooked up to the TV to an LG website, even though the TV=92s privacy =A0 settings should have prevented such behavior.

Next device this data will be sent encrypted, with the keys and the
software secured by the TV's "DRM" system so Smart TV owners = will no
longer be able to find out about such problems.

That actually seems like kind of a compelling rationale for authen= tication-only modes (as Bruce suggested) -- so we the network owners can se= e what our devices are doing. =A0It's isomorphic to the enterprise case= , but a little more intuitive for we end users.

--Richard

=A0
--
Bj=F6rn H=F6hrmann =B7 mailto:bjoern= @hoehrmann.de =B7 http://bjoern.hoehrmann.de
Am Badedeich 7 =B7 Telefon: +49(0)160/4415681 =B7 http://www.bjoernsworld.de
25899 Dageb=FCll =B7 PGP Pub. KeyID: 0xA4357E78 =B7 http://www.websitedev.de/

--089e0149d0aeffcd9f04ed22e643-- From stephen.farrell@cs.tcd.ie Mon Dec 9 16:19:30 2013 Return-Path: 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 F0E091ADFA1 for ; Mon, 9 Dec 2013 16:19:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Pux7PYQHXwr for ; Mon, 9 Dec 2013 16:19:28 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 036841ADFC1 for ; Mon, 9 Dec 2013 16:19:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id B7AD1BE4C; Tue, 10 Dec 2013 00:19:22 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z9XJ1JjGqcCE; Tue, 10 Dec 2013 00:19:19 +0000 (GMT) Received: from [10.87.48.12] (unknown [86.42.25.130]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 2DF19BE4D; Tue, 10 Dec 2013 00:19:18 +0000 (GMT) Message-ID: <52A65DFB.7080603@cs.tcd.ie> Date: Tue, 10 Dec 2013 00:19:07 +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: Richard Barnes , Bjoern Hoehrmann References: <290E20B455C66743BE178C5C84F1240847E510379D@EXMB01CMS.surrey.ac.uk> <52A4D7D9.9000603@cs.tcd.ie> <52A4E412.4030804@gmail.com> <72B86100-E73E-46BD-ABD6-8E35D56DBDDA@cisco.com> <52A61E4C.6020403@gmail.com> <52A62E98.2060705@gmx.net> <52A63CF9.7020303@gmail.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: perpass , Martin Thomson Subject: Re: [perpass] Tiny stacks 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 00:19:30 -0000 On 12/10/2013 12:07 AM, Richard Barnes wrote: > On Mon, Dec 9, 2013 at 6:46 PM, Bjoern Hoehrmann wrote: > >> * Richard Barnes wrote: >>> I'm thinking of things like these... >> >>> >>> >>> ... which do not seem like RFC-able things (so, the latter). Both are >> poor >>> design decisions; the first not applying authentication/authorization, and >>> the second, well, just epically failing. What are you going to do, require >>> someone to set a jumper for DNT? >> >> An LG Smart TV owner in the United Kingdom has shockingly discovered >> that his device is sending unencrypted data over Wi-Fi containing TV >> watching habits, as well as file names from external storage units >> hooked up to the TV to an LG website, even though the TV’s privacy >> settings should have prevented such behavior. >> >> Next device this data will be sent encrypted, with the keys and the >> software secured by the TV's "DRM" system so Smart TV owners will no >> longer be able to find out about such problems. >> > > That actually seems like kind of a compelling rationale for > authentication-only modes (as Bruce suggested) -- so we the network owners > can see what our devices are doing. It's isomorphic to the enterprise > case, but a little more intuitive for we end users. I disagree. As Bjorn says the device manuf will encrypt next time no doubt irrespective of whatever HTTP does, perhaps using the JS WebCrypto API;-) May as well encrypt the HTTP then since you'll need to spot the badness via traffic analysis yourself! (Only kidding, the always-encrypt-HTTP argument isn't that simple and should be rehashed here:-) But yes, the privacy-unfriendly behaviour of our devices and service providers is a major deal. I don't think that justifies arguments to give up our privacy to everyone in between though. S > > --Richard > > > >> -- >> Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de >> Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de >> 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ >> > > > > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > From stephen.farrell@cs.tcd.ie Mon Dec 9 16:28:04 2013 Return-Path: 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 3A93A1ADFD5 for ; Mon, 9 Dec 2013 16:28:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bh05jvtv84Ev for ; Mon, 9 Dec 2013 16:28:01 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 5E2DB1ADFD2 for ; Mon, 9 Dec 2013 16:28:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id BBC02BE4D; Tue, 10 Dec 2013 00:27:55 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dfMJzLxnCxtl; Tue, 10 Dec 2013 00:27:54 +0000 (GMT) Received: from [10.87.48.12] (unknown [86.42.25.130]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 91F16BE4C; Tue, 10 Dec 2013 00:27:54 +0000 (GMT) Message-ID: <52A6600A.6050008@cs.tcd.ie> Date: Tue, 10 Dec 2013 00:27:54 +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: Richard Barnes , Bjoern Hoehrmann References: <290E20B455C66743BE178C5C84F1240847E510379D@EXMB01CMS.surrey.ac.uk> <52A4D7D9.9000603@cs.tcd.ie> <52A4E412.4030804@gmail.com> <72B86100-E73E-46BD-ABD6-8E35D56DBDDA@cisco.com> <52A61E4C.6020403@gmail.com> <52A62E98.2060705@gmx.net> <52A63CF9.7020303@gmail.com> <52A65DFB.7080603@cs.tcd.ie> In-Reply-To: <52A65DFB.7080603@cs.tcd.ie> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: perpass , Martin Thomson Subject: Re: [perpass] Tiny stacks 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 00:28:04 -0000 Oops On 12/10/2013 12:19 AM, Stephen Farrell wrote: > should be rehashed I meant "should not be rehashed" ;-) S. From brian.e.carpenter@gmail.com Mon Dec 9 16:28:58 2013 Return-Path: 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 50E8A1ADFD8 for ; Mon, 9 Dec 2013 16:28:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 s6ppYI6zC2uO for ; Mon, 9 Dec 2013 16:28:57 -0800 (PST) Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 04AD71ADFD2 for ; Mon, 9 Dec 2013 16:28:56 -0800 (PST) Received: by mail-pd0-f175.google.com with SMTP id w10so6167884pde.34 for ; Mon, 09 Dec 2013 16:28:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=jNTzk1NQGhgRCjejh9Uj5zQ0VT4yPDmePg6CJEkOjp8=; b=YDQfXj5w2aQ7mfGMVgCSn5bkLlnBCMEumDpYSu6wkvu7V6CBx9AFW5Kg7lzsOUbUEg ozCSNg0cdy0LP/6GHiu30v6DWEfhu+fBfTbXTqlxRR7Gl7zewNTov7w1mNn4ZxhlwJcC sIE9GRe0LDqK7XfA1RwLI8R1kI8hcKKxrAoaxPuQuUpj3VinkxQRPjYhxMWL4Y+NumpP WHCR+MXiTt2PSD6Pz9CL9FdMJyU5YTOa9+yalSqIDXuOWtoVPkaZRVWhjznQXkCllMIy Iouuo+fFCc1fxQEJ5NXp2JwBiNkGJR95t/Jm7fZdzE95rClAzj1CY6/LWEOAIacdXjeT 9dDA== X-Received: by 10.66.144.227 with SMTP id sp3mr24513555pab.100.1386635332118; Mon, 09 Dec 2013 16:28:52 -0800 (PST) Received: from [192.168.178.20] (208.199.69.111.dynamic.snap.net.nz. [111.69.199.208]) by mx.google.com with ESMTPSA id gv10sm20984763pbd.0.2013.12.09.16.28.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 09 Dec 2013 16:28:51 -0800 (PST) Message-ID: <52A66042.9060801@gmail.com> Date: Tue, 10 Dec 2013 13:28:50 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Stephen Farrell References: <290E20B455C66743BE178C5C84F1240847E5103799@EXMB01CMS.surrey.ac.uk> <2C66A416-5F07-4803-A4C0-BB61734BA42E@nominum.com> <290E20B455C66743BE178C5C84F1240847E510379A@EXMB01CMS.surrey.ac.uk> <529F7690.2050302@gmx.net> <290E20B455C66743BE178C5C84F1240847E510379C@EXMB01CMS.surrey.ac.uk> <52A1BBBC.9090509@cs.tcd.ie> <290E20B455C66743BE178C5C84F1240847E510379D@EXMB01CMS.surrey.ac.uk> <52A4D7D9.9000603@cs.tcd.ie> <52A4E412.4030804@gmail.com> <72B86100-E73E-46BD-ABD6-8E35D56DBDDA@cisco.com> <52A61E4C.6020403@gmail.com> <52A62E98.2060705@gmx.net> <52A63CF9.7020303@gmail.com> <52A65049.2070903@cs.tcd.ie> In-Reply-To: <52A65049.2070903@cs.tcd.ie> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Richard Barnes , perpass , Hannes Tschofenig , "Stewart Bryant \(stbryant\)" Subject: Re: [perpass] Tiny stacks 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 00:28:58 -0000 On 10/12/2013 12:20, Stephen Farrell wrote: ... > Its not directly relevant to pervasive monitoring, but IMO the > worst security thing about tiny devices is the lack of s/w or > firmware update. Without that, we're basically screwed istm. And > we don't look like we're getting that, not even in proprietary > flavours. Or maybe I'm out of date on that? Would love to be. We're not screwed if (and only if) such devices can only communicate with the rest of the world via some larger box. That needs to include all forms of communication, of course, including near-field, to avoid walk-by snooping. Indeed I am not sure that's possible. At some point we'll need to start suspecting give-away pens of being surveillance devices distributed by the thousand. Brian From hallam@gmail.com Mon Dec 9 16:43:30 2013 Return-Path: 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 070AF1AE027 for ; Mon, 9 Dec 2013 16:43:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 ngl0pTmseS2q for ; Mon, 9 Dec 2013 16:43:27 -0800 (PST) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 242AD1AE021 for ; Mon, 9 Dec 2013 16:43:26 -0800 (PST) Received: by mail-wg0-f47.google.com with SMTP id n12so4265353wgh.14 for ; Mon, 09 Dec 2013 16:43:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=m179xwrckmr6OyW4xZ840XHldrQoQHZ4/05UZGeP7c4=; b=R7csohqwPlJfUmjCj4wFlRYHthvKZJ6KCtFoVGH5Y9anjhWepHaWGPD2j+97Hun06A 0z6VLvuz9AhRT1hMmdcCQY4XTx+RzpBzZylKO/FZQw2VHgPyfgLtLCDnih1fKhGcohK7 j9gRmqo/CBYquREfVyfJdep4y1FApkNx8n/uJcRAvQ/SPdzUDk+nGtP2k4PX327+qsoX yVLLmLlvjONFmB+F1gkBqryUZiEaHqF6opmZyIkDoRYVvIbi67vXgi4mcY8gtuai6QuF ox1c9Kld0wcbM2eLhbECT3bxh/ZoeS9Vlfc4JeSxLIZcgnfWt7T1kxkHwhtZ+naewG/L Bzjw== MIME-Version: 1.0 X-Received: by 10.194.94.167 with SMTP id dd7mr38034874wjb.43.1386636201635; Mon, 09 Dec 2013 16:43:21 -0800 (PST) Received: by 10.194.243.136 with HTTP; Mon, 9 Dec 2013 16:43:21 -0800 (PST) In-Reply-To: <52A66042.9060801@gmail.com> References: <290E20B455C66743BE178C5C84F1240847E5103799@EXMB01CMS.surrey.ac.uk> <2C66A416-5F07-4803-A4C0-BB61734BA42E@nominum.com> <290E20B455C66743BE178C5C84F1240847E510379A@EXMB01CMS.surrey.ac.uk> <529F7690.2050302@gmx.net> <290E20B455C66743BE178C5C84F1240847E510379C@EXMB01CMS.surrey.ac.uk> <52A1BBBC.9090509@cs.tcd.ie> <290E20B455C66743BE178C5C84F1240847E510379D@EXMB01CMS.surrey.ac.uk> <52A4D7D9.9000603@cs.tcd.ie> <52A4E412.4030804@gmail.com> <72B86100-E73E-46BD-ABD6-8E35D56DBDDA@cisco.com> <52A61E4C.6020403@gmail.com> <52A62E98.2060705@gmx.net> <52A63CF9.7020303@gmail.com> <52A65049.2070903@cs.tcd.ie> <52A66042.9060801@gmail.com> Date: Mon, 9 Dec 2013 19:43:21 -0500 Message-ID: From: Phillip Hallam-Baker To: Brian E Carpenter Content-Type: multipart/alternative; boundary=047d7bb03c463b35fe04ed236671 Cc: Richard Barnes , "Stewart Bryant \(stbryant\)" , perpass , Hannes Tschofenig , Stephen Farrell Subject: Re: [perpass] Tiny stacks 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 00:43:30 -0000 --047d7bb03c463b35fe04ed236671 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Dec 9, 2013 at 7:28 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > On 10/12/2013 12:20, Stephen Farrell wrote: > ... > > Its not directly relevant to pervasive monitoring, but IMO the > > worst security thing about tiny devices is the lack of s/w or > > firmware update. Without that, we're basically screwed istm. And > > we don't look like we're getting that, not even in proprietary > > flavours. Or maybe I'm out of date on that? Would love to be. > > We're not screwed if (and only if) such devices can only communicate > with the rest of the world via some larger box. That needs to > include all forms of communication, of course, including near-field, > to avoid walk-by snooping. > > Indeed I am not sure that's possible. At some point we'll need > to start suspecting give-away pens of being surveillance devices > distributed by the thousand. We are already at that point with USB memory sticks. Quite a few have ended up being corrupted with malware. There is certainly a need here and it is significant. But I think the answers are going to have to be regulation and audits and the like. What we can do about this in the IETF is quite limited. What we could do is to have some sort of device registration protocol whereby the device gains access to the network by first proposing a 'contract' specifying all the ports and protocols it is going to speak. The network infrastructure could then default-deny any access outside that contract. This would then reduce the audit task from observing the behavior of the device to checking the facilities it asks for and seeing if they are acceptable. -- Website: http://hallambaker.com/ --047d7bb03c463b35fe04ed236671 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, Dec 9, 2013 at 7:28 PM, Brian E Carpenter <brian= .e.carpenter@gmail.com> wrote:
On 10/12/2013 12:20, Stephen Farrell wrote:<= br> ...
> Its not directly relevant to pervasive monitoring, b= ut IMO the
> worst security thing about tiny devices is the lack of s/w or
> firmware update. Without that, we're basically screwed istm. And > we don't look like we're getting that, not even in proprietary=
> flavours. Or maybe I'm out of date on that? Would love to be.

We're not screwed if (and only if) such devices can only communic= ate
with the rest of the world via some larger box. That needs to
include all forms of communication, of course, including near-field,
to avoid walk-by snooping.

Indeed I am not sure that's possible. At some point we'll need
to start suspecting give-away pens of being surveillance devices
distributed by the thousand.

We are already= at that point with USB memory sticks. Quite a few have ended up being corr= upted with malware.

There is certainly a need here= and it is significant. But I think the answers are going to have to be reg= ulation and audits and the like.

What we can do about this in the IETF is quite limited.= What we could do is to have some sort of device registration protocol wher= eby the device gains access to the network by first proposing a 'contra= ct' specifying all the ports and protocols it is going to speak. The ne= twork infrastructure could then default-deny any access outside that contra= ct.=A0

This would then reduce the audit task from observing th= e behavior of the device to checking the facilities it asks for and seeing = if they are acceptable.=A0



=A0
--
Website: htt= p://hallambaker.com/
--047d7bb03c463b35fe04ed236671-- From stephen.farrell@cs.tcd.ie Mon Dec 9 16:46:29 2013 Return-Path: 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 D46FB1AE02E for ; Mon, 9 Dec 2013 16:46:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7-u3NE2-1xbl for ; Mon, 9 Dec 2013 16:46:28 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 5D3A31AE02C for ; Mon, 9 Dec 2013 16:46:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 23AD6BE4C; Tue, 10 Dec 2013 00:46:23 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IF+mldySShws; Tue, 10 Dec 2013 00:46:21 +0000 (GMT) Received: from [10.87.48.12] (unknown [86.42.25.130]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 1BD84BE8B; Tue, 10 Dec 2013 00:46:17 +0000 (GMT) Message-ID: <52A6644E.5050904@cs.tcd.ie> Date: Tue, 10 Dec 2013 00:46:06 +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: Phillip Hallam-Baker , Brian E Carpenter References: <290E20B455C66743BE178C5C84F1240847E5103799@EXMB01CMS.surrey.ac.uk> <2C66A416-5F07-4803-A4C0-BB61734BA42E@nominum.com> <290E20B455C66743BE178C5C84F1240847E510379A@EXMB01CMS.surrey.ac.uk> <529F7690.2050302@gmx.net> <290E20B455C66743BE178C5C84F1240847E510379C@EXMB01CMS.surrey.ac.uk> <52A1BBBC.9090509@cs.tcd.ie> <290E20B455C66743BE178C5C84F1240847E510379D@EXMB01CMS.surrey.ac.uk> <52A4D7D9.9000603@cs.tcd.ie> <52A4E412.4030804@gmail.com> <72B86100-E73E-46BD-ABD6-8E35D56DBDDA@cisco.com> <52A61E4C.6020403@gmail.com> <52A62E98.2060705@gmx.net> <52A63CF9.7020303@gmail.com> <52A65049.2070903@cs.tcd.ie> <52A66042.9060801@gmail.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Richard Barnes , perpass , Hannes Tschofenig , "Stewart Bryant \(stbryant\)" Subject: Re: [perpass] Tiny stacks 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 00:46:30 -0000 On 12/10/2013 12:43 AM, Phillip Hallam-Baker wrote: > What we can do about this in the IETF is quite limited. Tend to agree. Maybe a good topic for that workshop in London though. [1] :-) S. [1] http://www.iab.org/activities/workshops/strint/ From hallam@gmail.com Mon Dec 9 19:34:28 2013 Return-Path: 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 7939B1AE164 for ; Mon, 9 Dec 2013 19:34:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 Bx9QET63PNvb for ; Mon, 9 Dec 2013 19:34:26 -0800 (PST) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id 9F29C1AE153 for ; Mon, 9 Dec 2013 19:34:26 -0800 (PST) Received: by mail-wg0-f41.google.com with SMTP id y10so4168311wgg.4 for ; Mon, 09 Dec 2013 19:34:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ng51M+A5MI6aixVJAwmygOjD7KKw6ok0HOE1pQlKJm8=; b=GcClxWjGeDO/A8n9yfQ+I8X2Q+OzhwaRJCoWPt3rK6n5gE58ogsh+sYpVqSUkXe2yl pjs0OY5N2EPn2W7f8ugPDlXj2vuLGXi26M69OCNKNMpZyybqjab9SOCVZbGI0OILgKs3 Fg5ZBtQp4IW1Z9nr/c64XG1V9Ao6V3RrXcHMUG5Q8LXTMy/cJDqAS17kjhzu1aMuF7U+ BjRduCpqrjrP5OfPaTDw4BroWTbFgPkyX/X2ha/i0fV/E+Y/7Nj5P+tPIrTjrSoBc6HL oBXlO16/qwce7LPa4Khttz0rwSwwU7IGLt3lJ90BrCgzVmOjQaIYKuaRQ8YOPicY2U5L m8lg== MIME-Version: 1.0 X-Received: by 10.194.59.240 with SMTP id c16mr18957024wjr.13.1386646461216; Mon, 09 Dec 2013 19:34:21 -0800 (PST) Received: by 10.194.243.136 with HTTP; Mon, 9 Dec 2013 19:34:21 -0800 (PST) In-Reply-To: <52A6644E.5050904@cs.tcd.ie> References: <290E20B455C66743BE178C5C84F1240847E5103799@EXMB01CMS.surrey.ac.uk> <2C66A416-5F07-4803-A4C0-BB61734BA42E@nominum.com> <290E20B455C66743BE178C5C84F1240847E510379A@EXMB01CMS.surrey.ac.uk> <529F7690.2050302@gmx.net> <290E20B455C66743BE178C5C84F1240847E510379C@EXMB01CMS.surrey.ac.uk> <52A1BBBC.9090509@cs.tcd.ie> <290E20B455C66743BE178C5C84F1240847E510379D@EXMB01CMS.surrey.ac.uk> <52A4D7D9.9000603@cs.tcd.ie> <52A4E412.4030804@gmail.com> <72B86100-E73E-46BD-ABD6-8E35D56DBDDA@cisco.com> <52A61E4C.6020403@gmail.com> <52A62E98.2060705@gmx.net> <52A63CF9.7020303@gmail.com> <52A65049.2070903@cs.tcd.ie> <52A66042.9060801@gmail.com> <52A6644E.5050904@cs.tcd.ie> Date: Mon, 9 Dec 2013 22:34:21 -0500 Message-ID: From: Phillip Hallam-Baker To: Stephen Farrell Content-Type: multipart/alternative; boundary=047d7b86dca4c0008e04ed25c993 Cc: Richard Barnes , perpass , Hannes Tschofenig , "Stewart Bryant \(stbryant\)" Subject: Re: [perpass] Tiny stacks 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 03:34:28 -0000 --047d7b86dca4c0008e04ed25c993 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Dec 9, 2013 at 7:46 PM, Stephen Farrell wrote: > > > On 12/10/2013 12:43 AM, Phillip Hallam-Baker wrote: > > What we can do about this in the IETF is quite limited. > > Tend to agree. Maybe a good topic for that workshop in > London though. [1] :-) > > S. > > [1] http://www.iab.org/activities/workshops/strint/ > I already wrote my paper for that with my proposal for solving end-to-end email. I'll add a footnote to say that I have a solution but I can't fit it in the margin, does that count? Perhaps Satoshi Nakamoto could write a paper. -- Website: http://hallambaker.com/ --047d7b86dca4c0008e04ed25c993 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On M= on, Dec 9, 2013 at 7:46 PM, Stephen Farrell <stephen.farrell@cs.= tcd.ie> wrote:


On 12/10/2013 12:43 AM, Phillip Hallam-Baker wrote:
> What we can do about this in the IETF is quite limited.

Tend to agree. Maybe a good topic for that workshop in
London though. [1] :-)

S.

[1] http://www.iab.org/activities/workshops/strint/

I already wrote my paper for that with my proposal f= or solving end-to-end email.

I'll add a footnote to say that I have a solutio= n but I can't fit it in the margin, does that count?

Perhaps=A0<= span style=3D"color:rgb(68,68,68);font-family:arial,sans-serif;line-height:= 14.545454025268555px">Satoshi Nakamoto could write a paper.

--
Website: http://h= allambaker.com/
--047d7b86dca4c0008e04ed25c993-- From wilton@isoc.org Mon Dec 9 22:42:52 2013 Return-Path: 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 EFAB71AE05B for ; Mon, 9 Dec 2013 22:42:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 Kky-krp5LL8k for ; Mon, 9 Dec 2013 22:42:50 -0800 (PST) Received: from smtp126.iad3a.emailsrvr.com (smtp126.iad3a.emailsrvr.com [173.203.187.126]) by ietfa.amsl.com (Postfix) with ESMTP id 2B1C21AE04D for ; Mon, 9 Dec 2013 22:42:50 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp24.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 0D3C11500D4; Tue, 10 Dec 2013 01:42:45 -0500 (EST) X-Virus-Scanned: OK Received: by smtp24.relay.iad3a.emailsrvr.com (Authenticated sender: wilton-AT-isoc.org) with ESMTPSA id 7ACED1500CE; Tue, 10 Dec 2013 01:42:44 -0500 (EST) References: <290E20B455C66743BE178C5C84F1240847E5103799@EXMB01CMS.surrey.ac.uk> <2C66A416-5F07-4803-A4C0-BB61734BA42E@nominum.com> <290E20B455C66743BE178C5C84F1240847E510379A@EXMB01CMS.surrey.ac.uk> <529F7690.2050302@gmx.net> <290E20B455C66743BE178C5C84F1240847E510379C@EXMB01CMS.surrey.ac.uk> <52A1BBBC.9090509@cs.tcd.ie> <290E20B455C66743BE178C5C84F1240847E510379D@EXMB01CMS.surrey.ac.uk> <52A4D7D9.9000603@cs.tcd.ie> <52A4E412.4030804@gmail.com> <72B86100-E73E-46BD-ABD6-8E35D56DBDDA@cisco.com> <52A61E4C.6020403@gmail.com> <52A62E98.2060705@gmx.net> <52A63CF9.7020303@gmail.com> <52A65049.2070903@cs.tcd.ie> <52A66042.9060801@gmail.com> <52A6644E.5050904@cs.tcd.ie> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-FC71BCF3-2694-45C5-B7EC-0A94DFD65E6B Message-Id: <136DE139-F25E-4790-B58E-CE90656C2B8E@isoc.org> X-Mailer: iPad Mail (9B206) From: Robin Wilton Date: Tue, 10 Dec 2013 07:46:49 +0100 To: Phillip Hallam-Baker Cc: Richard Barnes , "Stewart Bryant \(stbryant\)" , perpass , Hannes Tschofenig , Stephen Farrell Subject: Re: [perpass] Tiny stacks 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 06:42:52 -0000 --Apple-Mail-FC71BCF3-2694-45C5-B7EC-0A94DFD65E6B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii If the margin doesn't provide you with enough space, perhaps you should re-Fe= rmat it. Robin Wilton Technical Outreach Director - Identity and Privacy On 10 Dec 2013, at 04:34, Phillip Hallam-Baker wrote: > On Mon, Dec 9, 2013 at 7:46 PM, Stephen Farrell wrote: >=20 >=20 > On 12/10/2013 12:43 AM, Phillip Hallam-Baker wrote: > > What we can do about this in the IETF is quite limited. >=20 > Tend to agree. Maybe a good topic for that workshop in > London though. [1] :-) >=20 > S. >=20 > [1] http://www.iab.org/activities/workshops/strint/ >=20 > I already wrote my paper for that with my proposal for solving end-to-end e= mail. >=20 > I'll add a footnote to say that I have a solution but I can't fit it in th= e margin, does that count? >=20 > Perhaps Satoshi Nakamoto could write a paper. >=20 > --=20 > Website: http://hallambaker.com/ > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass --Apple-Mail-FC71BCF3-2694-45C5-B7EC-0A94DFD65E6B Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=utf-8
If the margin doesn't provide you with enough space, perhaps you should re-Fermat it.

Robin Wilton

Technical Outreach Director - Identity and Privacy

On 10 Dec 2013, at 04:34, Phillip Hallam-Baker <hallam@gmail.com> wrote:

On Mon, Dec 9, 2013 at 7:46 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:


On 12/10/2013 12:43 AM, Phillip Hallam-Baker wrote:
> What we can do about this in the IETF is quite limited.

Tend to agree. Maybe a good topic for that workshop in
London though. [1] :-)

S.

[1] http://www.iab.org/activities/workshops/strint/

I already wrote my paper for that with my proposal for solving end-to-end email.

I'll add a footnote to say that I have a solution but I can't fit it in the margin, does that count?

Perhaps Satoshi Nakamoto could write a paper.

--
Website: http://hallambaker.com/
_______________________________________________
perpass mailing list
perpass@ietf.org
https://www.ietf.org/mailman/listinfo/perpass
--Apple-Mail-FC71BCF3-2694-45C5-B7EC-0A94DFD65E6B-- From wilton@isoc.org Tue Dec 10 00:41:05 2013 Return-Path: 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 4F1301AE450 for ; Tue, 10 Dec 2013 00:41:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.85 X-Spam-Level: X-Spam-Status: No, score=-0.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_12_24=1.049, HTML_MESSAGE=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 cy4krNMWGqAr for ; Tue, 10 Dec 2013 00:41:03 -0800 (PST) Received: from smtp126.iad3a.emailsrvr.com (smtp126.iad3a.emailsrvr.com [173.203.187.126]) by ietfa.amsl.com (Postfix) with ESMTP id 35B4F1AE446 for ; Tue, 10 Dec 2013 00:41:03 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp16.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 15FA63C00CE; Tue, 10 Dec 2013 03:40:58 -0500 (EST) X-Virus-Scanned: OK Received: by smtp16.relay.iad3a.emailsrvr.com (Authenticated sender: wilton-AT-isoc.org) with ESMTPSA id 400083C00C5; Tue, 10 Dec 2013 03:40:57 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/signed; boundary="Apple-Mail=_80D060FA-9AB4-4F9D-9A52-EEFEF6A52DE7"; protocol="application/pkcs7-signature"; micalg=sha1 From: Robin Wilton In-Reply-To: Date: Mon, 9 Dec 2013 17:14:57 +0100 Message-Id: <428DED67-3978-4EBE-9B71-4B70A8117046@isoc.org> References: <86BC54D4-7D2F-42F1-BA46-A73585605D58@isi.edu> To: Al Clark X-Mailer: Apple Mail (2.1283) Cc: Lucy Lynch , perpass , manning bill Subject: Re: [perpass] into the legal arena 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 08:41:05 -0000 --Apple-Mail=_80D060FA-9AB4-4F9D-9A52-EEFEF6A52DE7 Content-Type: multipart/alternative; boundary="Apple-Mail=_9DA16D1B-1F83-4247-9F08-BDCF700D45B7" --Apple-Mail=_9DA16D1B-1F83-4247-9F08-BDCF700D45B7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 I think it looks well-intentioned, but from the interview, it also seems = worryingly clear that the political sponsor has little or no = understanding of the technicalities - and not just from a techie point = of view. His 'description' of what this looks like from an end-user = point of view doesn't fill me with confidence. So, I worry that = legislation will evolve on the basis of a very shaky foundation, in = terms of clarity of requirements, achievable/measurable outcomes etc. R =20 Robin Wilton Technical Outreach Director - Identity and Privacy Internet Society email: wilton@isoc.org Phone: +44 705 005 2931 Twitter: @futureidentity On 9 Dec 2013, at 17:04, Al Clark wrote: > I'm encouraged by the political impulse behind this, but I do wonder = about the cost of implementing it and whether it will meet its stated = goals. That it's coming from California is also heartening, again on = the political level. >=20 >=20 > 2013/12/9 Lucy Lynch > On Mon, 9 Dec 2013, manning bill wrote: >=20 > piecemeal approach - a fact of life in todays environment. >=20 > = http://www.washingtonpost.com/blogs/the-switch/wp/2013/09/25/author-of-cal= ifornia-online-eraser-law-its-not-always-easy-to-find-the-delete-button/ >=20 >=20 > binding is easy, revocation is hard. >=20 >=20 >=20 > /bill > Neca eos omnes. Deus suos agnoscet. >=20 > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass >=20 >=20 > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass >=20 > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass --Apple-Mail=_9DA16D1B-1F83-4247-9F08-BDCF700D45B7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 I = think it looks well-intentioned, but from the interview, it also seems = worryingly clear that the political sponsor has little or no = understanding of the technicalities - and not just from a techie point = of view. His 'description' of what this looks like from an end-user = point of view doesn't fill me with confidence. So, I worry that = legislation will evolve on the basis of a very shaky foundation, in = terms of clarity of requirements, achievable/measurable outcomes = etc.

R  

Robin = Wilton
Technical Outreach Director - Identity and = Privacy
Internet Society

Phone: +44 = 705 005 2931
Twitter: = @futureidentity




On 9 Dec 2013, at 17:04, Al Clark wrote:

I'm encouraged by the political impulse behind this, but I = do wonder about the cost of implementing it and whether it will meet its = stated goals.  That it's coming from California is also heartening, = again on the political level.


2013/12/9 = Lucy Lynch <llynch@civil-tongue.net>
On Mon, 9 Dec 2013, manning bill wrote:

piecemeal approach - a fact of life in todays environment.

http://www.washingtonpost.com/blogs/the-switch/wp= /2013/09/25/author-of-california-online-eraser-law-its-not-<= u>always-easy-to-find-the-delete-button/


binding is easy, revocation is hard.



/bill
Neca eos omnes.  Deus suos agnoscet.

_______________________________________________
perpass mailing list
perpass@ietf.org
https://www.ietf.org/mailman/listinfo/perpass=


_______________________________________________
perpass mailing list
perpass@ietf.org
https://www.ietf.org/mailman/listinfo/perpass=

_______________________________________________
perpass mailing = list
perpass@ietf.org
https://www.ietf.= org/mailman/listinfo/perpass

= = --Apple-Mail=_9DA16D1B-1F83-4247-9F08-BDCF700D45B7-- --Apple-Mail=_80D060FA-9AB4-4F9D-9A52-EEFEF6A52DE7 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIIvDCCBBYw ggL+oAMCAQICCwQAAAAAAS9O4SzhMA0GCSqGSIb3DQEBBQUAMFcxCzAJBgNVBAYTAkJFMRkwFwYD VQQKExBHbG9iYWxTaWduIG52LXNhMRAwDgYDVQQLEwdSb290IENBMRswGQYDVQQDExJHbG9iYWxT aWduIFJvb3QgQ0EwHhcNMTEwNDEzMTAwMDAwWhcNMTkwNDEzMTAwMDAwWjBUMQswCQYDVQQGEwJC RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEqMCgGA1UEAxMhR2xvYmFsU2lnbiBQZXJzb25h bFNpZ24gMSBDQSAtIEcyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA8aUcr5BvPNGj x0+LH0uRqeZCHrYQ7KN3QuahfxY8fAzAbnvNDzGdEMyKn3+YX+k/QbAGNJOSFRxrAfhviF7WGcqD lin3HracDqMRgwrknWuFeqxhN2J7uXs3Y0zluJEkEittRXv+ZdXOG/Gp3gtoz5P9noc5jBbfWQpQ BhcaJA2ucABbUVTHDTxi7dBY8mTWq6kRAkGWBybHwq0YX+jaHudtQw0oBEmxjpJFP9qIXu0ckU/+ OhtnAhrgzrsd4oAyqgc6u4dBYERcjDJFohihjbzPozgKDSSbdr44uO3p9Bg6ibjCxn2besLrIE7u poxvV09Fsf7hDeD/jcvs64z8pQIDAQABo4HlMIHiMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8E CDAGAQH/AgEAMB0GA1UdDgQWBBTsrJjMJ3KTz1YyzSPHnY1FhfQiAzBHBgNVHSAEQDA+MDwGBFUd IAAwNDAyBggrBgEFBQcCARYmaHR0cHM6Ly93d3cuZ2xvYmFsc2lnbi5jb20vcmVwb3NpdG9yeS8w MwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5nbG9iYWxzaWduLm5ldC9yb290LmNybDAfBgNV HSMEGDAWgBRge2YaRQ2XyolQL30EzTSo//z9SzANBgkqhkiG9w0BAQUFAAOCAQEAr7unyEtmt9Ia 7hmNpqP+xMd0t5hLM0QBY8G3Dlg70XI6F+ZeSZeeXgCtUT/JhdQ+HsJ8+c6HypDuvg/OZ0gILDFI a9LDfRWm+tHIgxKaJjtCy0izg838dLwwnt/O3kA9N/htEYev2lsmWYCV9cVUm5V1tW3XuYNg6Sbt cDRH+Ki1RED9es3R0BgHSm012KPxsiAOOxuhm1D3Iqs1qe6ms5WTKXVgwb/j/kplOa13nshhc8zU LVO+oAlD4+7czNK2RJiTvhJiDJDRTZy3DJ3BCQ8rXOGdWzDEI5uiB8TZ0s327g44Ylc6dgKgYelN n9RLYjNETX8OIJZlr0tFYpcYrDCCBJ4wggOGoAMCAQICEGZgT+TGYtW+XJFC/uaWLhwwDQYJKoZI hvcNAQEFBQAwVDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExKjAoBgNV BAMTIUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIDEgQ0EgLSBHMjAeFw0xMzA3MDIxMzA4NTBaFw0x NjA3MDIxMzA4NTBaMDoxGDAWBgNVBAMMD3dpbHRvbkBpc29jLm9yZzEeMBwGCSqGSIb3DQEJARYP d2lsdG9uQGlzb2Mub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAoXFv/b3D0Hgt yFZ0fwd7y1X2zNMap0xTZn4a5nonOFedmZA626x88a0jv9GRNWpzjAu2AycDSdLH1qlWPurMLIiX 5JsEKlByX879TizmNbHlUnIpDQwXq4ODfsrPstSNyh88Cov4WXAqr1T3CREjN5We7L7h/hfTc2rC iCPXqbSnob6OhOAi46PWoed2SGqorNQYlETt6h2KU+U+iY4jyRqHIgPG82ylCXoWJC3zl2+e48PS Qy62a/4dUGIoMLLPztIIgzJS6Hq58ZgO8tkNwoED5OdtbbY1MYzAifb3bQQjOjZyM31kapseEeiy DYqHel5Gpoz1GfW2Qv0NMZ0ANwIDAQABo4IBhDCCAYAwDgYDVR0PAQH/BAQDAgWgMEwGA1UdIARF MEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8vd3d3Lmdsb2JhbHNpZ24uY29t L3JlcG9zaXRvcnkvMBoGA1UdEQQTMBGBD3dpbHRvbkBpc29jLm9yZzAJBgNVHRMEAjAAMB0GA1Ud JQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDBDBgNVHR8EPDA6MDigNqA0hjJodHRwOi8vY3JsLmds b2JhbHNpZ24uY29tL2dzL2dzcGVyc29uYWxzaWduMWcyLmNybDBVBggrBgEFBQcBAQRJMEcwRQYI KwYBBQUHMAKGOWh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzcGVyc29uYWxz aWduMWcyLmNydDAdBgNVHQ4EFgQUQjRxfdqFc6xPpajaSzuD2wzsV4owHwYDVR0jBBgwFoAU7KyY zCdyk89WMs0jx52NRYX0IgMwDQYJKoZIhvcNAQEFBQADggEBAFmkOj2M8636zFdLGl30Hc/njsvX 8mlA76DAUuV/d3EtbtyVrURAvugN+Q6yfl5pSSvqjr2vQzREdJZcw+eEGsqw0BMNvN3BOs9WiK9a m/BKsQr22W/k006T8aJIluvEPj0wIoJ6jM/1O4ll6vpYmeGFzZ//5OnZmgRbfwD6u4lblbFzb1rW bMkO7wyMgzwcnmDpENlIoqL0poqDz0TfagKG2/0UKS2OYmZW7WfmkKxq3ODoRp4XLTyrSycDUsB1 7VIjQG9Wx7FNZREfYf/OLOFHatoMLIiGCvLTMc/f3ijGadNGSTTZ5SE3Y7vXM7KmSsraGRhV2BQI iapDLC2ImnkxggLkMIIC4AIBATBoMFQxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWdu IG52LXNhMSowKAYDVQQDEyFHbG9iYWxTaWduIFBlcnNvbmFsU2lnbiAxIENBIC0gRzICEGZgT+TG YtW+XJFC/uaWLhwwCQYFKw4DAhoFAKCCAVEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMTMxMjA5MTYxNDU4WjAjBgkqhkiG9w0BCQQxFgQUcV+hw6NeSLQGxTHw/h+u 3gOaNCswdwYJKwYBBAGCNxAEMWowaDBUMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2ln biBudi1zYTEqMCgGA1UEAxMhR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gMSBDQSAtIEcyAhBmYE/k xmLVvlyRQv7mli4cMHkGCyqGSIb3DQEJEAILMWqgaDBUMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQ R2xvYmFsU2lnbiBudi1zYTEqMCgGA1UEAxMhR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gMSBDQSAt IEcyAhBmYE/kxmLVvlyRQv7mli4cMA0GCSqGSIb3DQEBAQUABIIBAAbDMoHRlPInyva4nInlkayw oxwWsLouP8WkVBRyOr6XdG5L+eDgWl8dVI3DE8LYZEQqEb6pt1z3xSrCgTxygFDYY289FGgnL/kk GPYCd4nmDIMwnvmFWmWyK5Mgn08QscMQEIOcLBK9cYqTWNod6fkJ+S2SeqeqTuoQ+LLdWiS9Kb6r 0hIRwRig2LnObEFAtX458ZMKQAcRZuKxXRTTW3eMMkAj2oOPFcf3hhicvFDLl8g3pJ0pF/hX4U/P ccJMPTPlYiEnbzBgIL/b2iZ8IftEwKEaGkFVH1PpcEPXg2UP4BnZAAidk4ugwC8Ad5UIcit0K4nc pCvIKGAHh0dIq/AAAAAAAAA= --Apple-Mail=_80D060FA-9AB4-4F9D-9A52-EEFEF6A52DE7-- From joe@cdt.org Tue Dec 10 09:24:50 2013 Return-Path: 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 5C3211ADFAB for ; Tue, 10 Dec 2013 09:24:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 7fxVR0TpuxYt for ; Tue, 10 Dec 2013 09:24:48 -0800 (PST) Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by ietfa.amsl.com (Postfix) with ESMTP id EA7241ADF74 for ; Tue, 10 Dec 2013 09:24:47 -0800 (PST) X-Footer: Y2R0Lm9yZw== Received: from localhost ([127.0.0.1]) by mail.maclaboratory.net (using TLSv1/SSLv3 with cipher AES256-SHA (256 bits)) for perpass@ietf.org; Tue, 10 Dec 2013 12:24:41 -0500 Message-ID: <52A74E58.4000708@cdt.org> Date: Tue, 10 Dec 2013 12:24:40 -0500 From: Joseph Lorenzo Hall User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: perpass@ietf.org References: <290E20B455C66743BE178C5C84F1240847E5103799@EXMB01CMS.surrey.ac.uk> <2C66A416-5F07-4803-A4C0-BB61734BA42E@nominum.com> <290E20B455C66743BE178C5C84F1240847E510379A@EXMB01CMS.surrey.ac.uk> <529F7690.2050302@gmx.net> <290E20B455C66743BE178C5C84F1240847E510379C@EXMB01CMS.surrey.ac.uk> <52A1BBBC.9090509@cs.tcd.ie> <290E20B455C66743BE178C5C84F1240847E510379D@EXMB01CMS.surrey.ac.uk> <52A4D7D9.9000603@cs.tcd.ie> <52A4E412.4030804@gmail.com> <72B86100-E73E-46BD-ABD6-8E35D56DBDDA@cisco.com> <52A61E4C.6020403@gmail.com> <52A62E98.2060705@gmx.net> <52A63CF9.7020303@gmail.com> <52A65049.2070903@cs.tcd.ie> <52A66042.9060801@gmail.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Subject: Re: [perpass] Tiny stacks 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 17:24:50 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 12/9/13 7:43 PM, Phillip Hallam-Baker wrote: > What we can do about this in the IETF is quite limited. What we > could do is to have some sort of device registration protocol > whereby the device gains access to the network by first proposing a > 'contract' specifying all the ports and protocols it is going to > speak. The network infrastructure could then default-deny any > access outside that contract. > > This would then reduce the audit task from observing the behavior > of the device to checking the facilities it asks for and seeing if > they are acceptable. I have been thinking similarly... sort of a standards-supported network monitor for the internet of things: from p. 4 of https://www.cdt.org/files/pdfs/CDT-Internet-of-Things-Comments.pdf: "There may be technological solutions to these barrier-crossing issues that consumers can configure to control the amount and nature of data transmitted by IoT-capable sensors and devices in sensitive locations. For example, it may be possible to design “middleware” networking equipment that a member of the household or business could configure to selectively allow or disallow networked objects from communicating outside of the household network. Ideally, such a privacy appliance could easily identify data emitted by IoT-capable products in the home network, but that relies on manufacturers inserting the right tags into their network communication that such an appliance could read. This would probably require significant standards work and manufacturer buy-in (or a legislative or regulatory mandate) to support this kind of functionality. Another option may be to design a standard element to the networkable components of IoT objects — say a pull-off tab or shielding element — that consumers can activate in order to toggle or disable networking functionality. Given that certain activities and areas in one’s home are particularly sensitive towards arbitrary data collection — bedrooms, bathrooms, children’s areas — there may be a level of tracking and data usage that above which is simply not appropriate for those products or that industry commits to making connected and disconnected versions." Would love to know if there is work (standards, research, whatever) in this area I should be aware of. best, Joe - -- Joseph Lorenzo Hall Chief Technologist Center for Democracy & Technology 1634 I ST NW STE 1100 Washington DC 20006-4011 (p) 202-407-8825 (f) 202-637-0968 joe@cdt.org PGP: https://josephhall.org/gpg-key fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSp05YAAoJEF+GaYdAqahx388P/3Mg/JTS5SOqpjdKLakv3+dm PyjbV2IZgojQI/x6bQO7JBggSo5djess7GzK2BdKH5U8gzSHv4Q7+OXYEooiO+c/ 01QC0vJCO7mCw3Sr0hfpRB1s59cIimqR44yNT1bi0R3EU6d1e+l3UGftqOlBrQ6O IU6yp0puY9lXsZ6S6vY5zIbKwpGDsCBAaqx7872VEwjjKEnf0yDsmQsur1xe4vGt AF1G64kwq5brGjCz0plAcawDU4ljoOBHSaCaxcXt1co4fJzM1EcsrRKKg3dZruRr aEDDKuFO6oHv4mtHmG//54XXSglEXnaaVs1tPCFevXTUgdBtooKVhmj26xoTe4i6 FtT9p0LUtY01UMzNz9KtmvYG1LvCjKScx86lqFb7In2sOcrPTngx6f8mxbTzzSMF SL1UWqjHazeWuIQtSVk2mSuYvlT/Ja9eQ+p/BRYcQdKF5e/koezuTclP+2DTWITd iX6JNuUY9msEaL9e0/8glioT7DC+maBLX06rsuXzWZ3OenNLxLW3eINgxYq1469O 3e2TLa29uM3UnC/ya61bsLMVlx9wy169O6iuZA6g78e6cN11CYzf0JewGidhZ5sA /vuQXZ5ChLtMhrJPOlzJmA9HLqQ9mXrUbdKwRvABjaBimehcb8geYloae4WwQEtF JoIicWI8Yf2OqCzsOI3x =RYCM -----END PGP SIGNATURE----- From scott.brim@gmail.com Tue Dec 10 10:50:50 2013 Return-Path: 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 8D3BE1AE052 for ; Tue, 10 Dec 2013 10:50:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 lyUyZDGsVUPe for ; Tue, 10 Dec 2013 10:50:49 -0800 (PST) Received: from mail-oa0-x234.google.com (mail-oa0-x234.google.com [IPv6:2607:f8b0:4003:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id 04CCC1AE02A for ; Tue, 10 Dec 2013 10:50:48 -0800 (PST) Received: by mail-oa0-f52.google.com with SMTP id h16so5945980oag.25 for ; Tue, 10 Dec 2013 10:50:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=QOsecu2scUuksxLp0TWPB3w5LKx2JWMKsXhjzvjW48s=; b=sp0MFIRQQqWdriocBaOIHLZjn0qYbXVpX31X5ZfCJCmhm3Rgq7M/XzE3M/FxwD5QJZ 3Jm3sk/heBTHT3Q7xtsxuKHvNmaERr5u1UyYxGuGBD+Se3WHnYVINARp/7tBZh4f4gHc vzXi6jQGqM0bgpooWLBYB3gtTToGBP28k3+uB747ZcTpzxyH9ZlwVhm+0X05D6a9SXUh 5epVzJ3GIxLaeWeXpHRm9TUoTOeofIdqjJ9VLUA0OyHUc0jAq6f6PcTq7QFAbceP8/u6 BNM8ut/GYIXhmquoixRlSs0uqt5lTHaxKEzFrR2PMjR5jd8ltYAOuVJ1m7D9aNJ85PSl P7wg== X-Received: by 10.60.115.138 with SMTP id jo10mr1389871oeb.71.1386701443621; Tue, 10 Dec 2013 10:50:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.48.9 with HTTP; Tue, 10 Dec 2013 10:50:23 -0800 (PST) In-Reply-To: References: <290E20B455C66743BE178C5C84F1240847E5103799@EXMB01CMS.surrey.ac.uk> <2C66A416-5F07-4803-A4C0-BB61734BA42E@nominum.com> <290E20B455C66743BE178C5C84F1240847E510379A@EXMB01CMS.surrey.ac.uk> <529F7690.2050302@gmx.net> <290E20B455C66743BE178C5C84F1240847E510379C@EXMB01CMS.surrey.ac.uk> <52A1BBBC.9090509@cs.tcd.ie> <290E20B455C66743BE178C5C84F1240847E510379D@EXMB01CMS.surrey.ac.uk> <52A4D7D9.9000603@cs.tcd.ie> <52A4E412.4030804@gmail.com> <72B86100-E73E-46BD-ABD6-8E35D56DBDDA@cisco.com> <52A61E4C.6020403@gmail.com> From: Scott Brim Date: Tue, 10 Dec 2013 13:50:23 -0500 Message-ID: To: Robin Wilton Content-Type: text/plain; charset=ISO-8859-1 Cc: Richard Barnes , perpass , "Stewart Bryant \(stbryant\)" Subject: Re: [perpass] Tiny stacks 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 18:50:50 -0000 On Mon, Dec 9, 2013 at 3:50 PM, Robin Wilton wrote: > And in some cases, a tiny stack is an advantage. It shortens the path whose > trustworthiness one has to assure. ... except that to keep unit costs down, usually they pick up code from a low bidder. From scott.brim@gmail.com Tue Dec 10 10:55:27 2013 Return-Path: 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 D8C2A1ADFAA for ; Tue, 10 Dec 2013 10:55:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 7L-rF7uGwx3j for ; Tue, 10 Dec 2013 10:55:26 -0800 (PST) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id AFA411A1F78 for ; Tue, 10 Dec 2013 10:55:26 -0800 (PST) Received: by mail-ob0-f179.google.com with SMTP id wm4so5826597obc.10 for ; Tue, 10 Dec 2013 10:55:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=R121+xNqFFFYp8bJ+n0S57I+qcROxLC5Uf5wE9Mm28k=; b=K1Dlvtga05Wk9DQj/ngIEDU+v2ogBWLuRvCtJ6CdPcbzs4mki8ujSEAdHaAA/K8Tve CQRr2aPigyGOusu0yJ3lRm1nUmzupgM+/sYurt2pwl39uNkF+ua/FvkMAVHsuyYTpLtV k4ntxSR/svKeM7KJTgCWuGRcdUZBMAlg7zw6D7R4GwjGqnogZESGwW573NVtQq9G+SJ2 k97N5UT2+vA//jlZc1R5PHXgwdt74TN7uR4it99BvVnIrpFaNYHqwBrXV2V1cgQWuKhH PwPHuCQPFygM4SVPWtNbwD4RXiHuxCwWpLcDnjY3sId5DtPxkfD/VoNVT42cXvITq6+z 2ZiA== X-Received: by 10.182.42.105 with SMTP id n9mr17911039obl.33.1386701721335; Tue, 10 Dec 2013 10:55:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.48.9 with HTTP; Tue, 10 Dec 2013 10:55:01 -0800 (PST) In-Reply-To: <52A63CF9.7020303@gmail.com> References: <290E20B455C66743BE178C5C84F1240847E5103799@EXMB01CMS.surrey.ac.uk> <2C66A416-5F07-4803-A4C0-BB61734BA42E@nominum.com> <290E20B455C66743BE178C5C84F1240847E510379A@EXMB01CMS.surrey.ac.uk> <529F7690.2050302@gmx.net> <290E20B455C66743BE178C5C84F1240847E510379C@EXMB01CMS.surrey.ac.uk> <52A1BBBC.9090509@cs.tcd.ie> <290E20B455C66743BE178C5C84F1240847E510379D@EXMB01CMS.surrey.ac.uk> <52A4D7D9.9000603@cs.tcd.ie> <52A4E412.4030804@gmail.com> <72B86100-E73E-46BD-ABD6-8E35D56DBDDA@cisco.com> <52A61E4C.6020403@gmail.com> <52A62E98.2060705@gmx.net> <52A63CF9.7020303@gmail.com> From: Scott Brim Date: Tue, 10 Dec 2013 13:55:01 -0500 Message-ID: To: Brian E Carpenter Content-Type: text/plain; charset=ISO-8859-1 Cc: perpass , Hannes Tschofenig , "Stewart Bryant \(stbryant\)" Subject: Re: [perpass] Tiny stacks 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 18:55:28 -0000 On Mon, Dec 9, 2013 at 4:58 PM, Brian E Carpenter wrote: > Fair enough, but did you consider specifically the privacy and > surveillance aspects? I'm concerned that counter-measures that can > be easily incorporated in full size devices may be too heavy for > tiny devices. Brian: I'm not in the field but people I've spoken to have certainly _considered_ the problems. I don't know what's made it into deployment. On the other hand, there's a good chance that industry groups would be where these problems get worked on more than the IETF. From brian.e.carpenter@gmail.com Tue Dec 10 10:58:07 2013 Return-Path: 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 C267C1ADFA1 for ; Tue, 10 Dec 2013 10:58:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 pPRvXPUpBgav for ; Tue, 10 Dec 2013 10:58:06 -0800 (PST) Received: from mail-pb0-x22c.google.com (mail-pb0-x22c.google.com [IPv6:2607:f8b0:400e:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 83A171ADF5B for ; Tue, 10 Dec 2013 10:58:06 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id rq2so8243006pbb.31 for ; Tue, 10 Dec 2013 10:58:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=yGSvPVdduINZsXqeuJsGpwIl4QQy4kOg+AuCeizUoBI=; b=BiVceNOnuA4Aqw4LNL1j1E5nB9KgszM9ewVjqmfG1FHtIY3K+O/y4KjuU7JgGSHI+5 SCVrhFEXtaV2jvF2l3+yRz+ZdApVquerTJ8bK47r9jOr6mJdjwPusRTqfSV9rSIQIKw0 vwcRIf/vW8xzlK21mEkTsQQYky1vBpvxNC3kqARvMJZ2HWAWUkr99+lluFSow6GoiZag ciNoklB1Fd28i+TUfz1Ovf87VQ6xDHpKQRawgTZeXY7qn9xC6UaxVM0PAeqHmc54BEkq HxqWOYEL7On0pV6NzkjhvGOotSguCv5fFycTOAkTXgji0rusYEU9uXTVeDYUMvnrbXrD U1Ow== X-Received: by 10.66.121.131 with SMTP id lk3mr29497009pab.61.1386701881265; Tue, 10 Dec 2013 10:58:01 -0800 (PST) Received: from [192.168.178.20] (146.199.69.111.dynamic.snap.net.nz. [111.69.199.146]) by mx.google.com with ESMTPSA id nn6sm27302252pbc.29.2013.12.10.10.57.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 10 Dec 2013 10:58:00 -0800 (PST) Message-ID: <52A76436.6080809@gmail.com> Date: Wed, 11 Dec 2013 07:57:58 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: perpass@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [perpass] SSL threat model 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 18:58:08 -0000 As I said in my plenary talk... it's not just the NSA we have to worry about... http://www.theregister.co.uk/2013/12/10/french_gov_dodgy_ssl_cert_reprimand/ From hallam@gmail.com Tue Dec 10 17:41:31 2013 Return-Path: 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 835EE1AD945 for ; Tue, 10 Dec 2013 17:41:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 EgtZEuwbUF-C for ; Tue, 10 Dec 2013 17:41:28 -0800 (PST) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) by ietfa.amsl.com (Postfix) with ESMTP id 43F8E1ADFDD for ; Tue, 10 Dec 2013 17:41:28 -0800 (PST) Received: by mail-wi0-f177.google.com with SMTP id cc10so173156wib.16 for ; Tue, 10 Dec 2013 17:41:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1TJ9uBTRQ74c02d95CHOakLi77w2wSSd3lhzmo3yacQ=; b=TO47iheTZ/mga0RGhvMLb+5GjuHrjQlz4wH+uKazpTQTvAAPZRP6zCTHLpW7mMy2R3 SY0EY4wooa9r4kITm1kcxyGdlwCQAHOuA8YOxcEkgKb2FQzhLwODAv3u97qdoNALNyJN TRRx0zERIrebaak3/9uHK3ktgAvB/z5PBHX45AN8SctlWrYLapXzzbZvp8VfiexgkCbD MglDH1PeDEk1dyK42A00mndJfj7/GsdE95attZX/A+6vEPYi8A+WUgFxWcH1UJtxJd/S bKKOtf+3oO/AWN3e7leACSYeLIY29w2CsqQwI0PNr3DF3Ar56tnIZRBtQ8JYSz5uqVYO fBTg== MIME-Version: 1.0 X-Received: by 10.180.13.74 with SMTP id f10mr21893556wic.34.1386726082383; Tue, 10 Dec 2013 17:41:22 -0800 (PST) Received: by 10.194.243.136 with HTTP; Tue, 10 Dec 2013 17:41:22 -0800 (PST) In-Reply-To: <52A74E58.4000708@cdt.org> References: <290E20B455C66743BE178C5C84F1240847E5103799@EXMB01CMS.surrey.ac.uk> <2C66A416-5F07-4803-A4C0-BB61734BA42E@nominum.com> <290E20B455C66743BE178C5C84F1240847E510379A@EXMB01CMS.surrey.ac.uk> <529F7690.2050302@gmx.net> <290E20B455C66743BE178C5C84F1240847E510379C@EXMB01CMS.surrey.ac.uk> <52A1BBBC.9090509@cs.tcd.ie> <290E20B455C66743BE178C5C84F1240847E510379D@EXMB01CMS.surrey.ac.uk> <52A4D7D9.9000603@cs.tcd.ie> <52A4E412.4030804@gmail.com> <72B86100-E73E-46BD-ABD6-8E35D56DBDDA@cisco.com> <52A61E4C.6020403@gmail.com> <52A62E98.2060705@gmx.net> <52A63CF9.7020303@gmail.com> <52A65049.2070903@cs.tcd.ie> <52A66042.9060801@gmail.com> <52A74E58.4000708@cdt.org> Date: Tue, 10 Dec 2013 20:41:22 -0500 Message-ID: From: Phillip Hallam-Baker To: Joseph Lorenzo Hall Content-Type: multipart/alternative; boundary=001a11c24a948a971304ed38539b Cc: perpass Subject: Re: [perpass] Tiny stacks 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 01:41:31 -0000 --001a11c24a948a971304ed38539b Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Tue, Dec 10, 2013 at 12:24 PM, Joseph Lorenzo Hall wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > > On 12/9/13 7:43 PM, Phillip Hallam-Baker wrote: > > What we can do about this in the IETF is quite limited. What we > > could do is to have some sort of device registration protocol > > whereby the device gains access to the network by first proposing a > > 'contract' specifying all the ports and protocols it is going to > > speak. The network infrastructure could then default-deny any > > access outside that contract. > > > > This would then reduce the audit task from observing the behavior > > of the device to checking the facilities it asks for and seeing if > > they are acceptable. > > I have been thinking similarly... sort of a standards-supported > network monitor for the internet of things: > > from p. 4 of > https://www.cdt.org/files/pdfs/CDT-Internet-of-Things-Comments.pdf: > > "There may be technological solutions to these barrier-crossing issues > that consumers can configure to control the amount and nature of data > transmitted by IoT-capable sensors and devices in sensitive locations. > For example, it may be possible to design =93middleware=94 networking > equipment that a member of the household or business could configure > to selectively allow or disallow networked objects from communicating > outside of the household network. Ideally, such a privacy appliance > could easily identify data emitted by IoT-capable products in the home > network, but that relies on manufacturers inserting the right tags into > their network communication that such an appliance could read. This > would probably require significant standards work and manufacturer > buy-in (or a legislative or regulatory mandate) to support this kind > of functionality. Another option may be to design a standard element > to the networkable components of IoT objects =97 say a pull-off tab or > shielding element =97 that consumers can activate in order to toggle or > disable networking functionality. Given that certain activities and > areas in one=92s home are particularly sensitive towards arbitrary data > collection =97 bedrooms, bathrooms, children=92s areas =97 there may be a > level of tracking and data usage that above which is simply not > appropriate for those products or that industry commits to making > connected and disconnected versions." > > Would love to know if there is work (standards, research, whatever) in > this area I should be aware of. > The first step is to have a protocol that allows a device, application, whatever that is connecting to the local network to announce themselves and the services they intend to provide. If you would like to do this in JSON, I have a protocol to do that: http://tools.ietf.org/html/draft-hallambaker-omnibroker-06 The explanation of how to manage the protocol is incomplete because I am currently doing the email hack thing. But I do intend to finish this work because I intend to build on it. --=20 Website: http://hallambaker.com/ --001a11c24a948a971304ed38539b Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable



On Tue, Dec 10, 2013 at 12:24 PM, Joseph Lorenzo Hall <joe@cdt.org&g= t; wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256


On 12/9/13 7:43 PM, Phillip Hallam-Baker wrote:
> What we can do about this in the IETF is quite limited. What we
> could do is to have some sort of device registration protocol
> whereby the device gains access to the network by first proposing a > 'contract' specifying all the ports and protocols it is going = to
> speak. The network infrastructure could then default-deny any
> access outside that contract.
>
> This would then reduce the audit task from observing the behavior
> of the device to checking the facilities it asks for and seeing if
> they are acceptable.

I have been thinking similarly... sort of a standards-supported
network monitor for the internet of things:

from p. 4 of
https://www.cdt.org/files/pdfs/CDT-Internet-of-Things= -Comments.pdf:

"There may be technological solutions to these barrier-crossing issues=
that consumers can configure to control the amount and nature of data
transmitted by IoT-capable sensors and devices in sensitive locations.
For example, it may be possible to design =93middleware=94 networking
equipment that a member of the household or business could configure
to selectively allow or disallow networked objects from communicating
outside of the household network. Ideally, such a privacy appliance
could easily identify data emitted by IoT-capable products in the home
network, but that relies on manufacturers inserting the right tags into
their network communication that such an appliance could read. This
would probably require significant standards work and manufacturer
buy-in (or a legislative or regulatory mandate) to support this kind
of functionality. Another option may be to design a standard element
to the networkable components of IoT objects =97 say a pull-off tab or
shielding element =97 that consumers can activate in order to toggle or
disable networking functionality. Given that certain activities and
areas in one=92s home are particularly sensitive towards arbitrary data
collection =97 bedrooms, bathrooms, children=92s areas =97 there may be a level of tracking and data usage that above which is simply not
appropriate for those products or that industry commits to making
connected and disconnected versions."

Would love to know if there is work (standards, research, whatever) in
this area I should be aware of.

The fir= st step is to have a protocol that allows a device, application, whatever t= hat is connecting to the local network to announce themselves and the servi= ces they intend to provide.=A0

If you would like to do this in JSON, I have a protocol= to do that:



The explanation of how to manage t= he protocol is incomplete because I am currently doing the email hack thing= . But I do intend to finish this work because I intend to build on it.


--
Website: http://hallambaker.com/
--001a11c24a948a971304ed38539b-- From lear@cisco.com Wed Dec 11 00:40:55 2013 Return-Path: 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 5E8C31ADF63 for ; Wed, 11 Dec 2013 00:40:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.501 X-Spam-Level: X-Spam-Status: No, score=-9.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 a76op7zpZCRX for ; Wed, 11 Dec 2013 00:40:53 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id 579351AE323 for ; Wed, 11 Dec 2013 00:40:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7879; q=dns/txt; s=iport; t=1386751247; x=1387960847; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=ZZNFQ2mOcQUqBm4mB/P69W0xOOqLS8r/stfCQ8SzIhE=; b=SP1selEu9bO5+kjiJLtM6WOdcnH6j04cechEOfrH3Zwj8VG8P8glKJVJ wdLtPK5Jd8dKqE3AZJ2UcTbuom2PNuZ+RrJ2+3wSQZ17AheAv+JLYVC/7 OCzgaf0ZaA4xB065yME/OyiazeF8d0igVqUtoMesgOeIJHlJ5NwBzhZOI 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFAPAjqFKQ/khM/2dsb2JhbABZgwc4g1aFXbBDgSAWdIIlAQEBAgIOFUITARAjCRYLAgIJAwIBAgFFBg0BBwEBh34NsVCPVxeOIxEBUAeCbIFIBJFkhjCBMJBjgWuBPzuBNQ X-IronPort-AV: E=Sophos;i="4.93,870,1378857600"; d="scan'208,217";a="1999310" Received: from ams-core-3.cisco.com ([144.254.72.76]) by aer-iport-1.cisco.com with ESMTP; 11 Dec 2013 08:40:46 +0000 Received: from ams3-vpn-dhcp5477.cisco.com (ams3-vpn-dhcp5477.cisco.com [10.61.85.100]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id rBB8egtA026251 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Dec 2013 08:40:42 GMT Message-ID: <52A8250A.7060604@cisco.com> Date: Wed, 11 Dec 2013 09:40:42 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Stefan Winter References: <20131203174852.21387.26099.idtracker@ietfa.amsl.com> <002501cef266$b0b8a540$4001a8c0@gateway.2wire.net> <52A1A3AA.3080101@restena.lu> <009701cef2b3$f6c69400$4001a8c0@gateway.2wire.net>, <52A5786A.8040308@restena.lu>, <290E20B455C66743BE178C5C84F1240847E51037A1@EXMB01CMS.surrey.ac.uk> <290E20B455C66743BE178C5C84F1240847E51037A2@EXMB01CMS.surrey.ac.uk> <52A815AE.9070408@restena.lu> In-Reply-To: <52A815AE.9070408@restena.lu> X-Enigmail-Version: 1.6 Content-Type: multipart/alternative; boundary="------------090101030501060203080301" Cc: perpass , Mark Nottingham Subject: [perpass] on encryption and social networks (Was Last call: draft-farrell-perpass-attack-02) 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 08:40:55 -0000 This is a multi-part message in MIME format. --------------090101030501060203080301 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi Stefan, On 12/11/13 8:35 AM, Stefan Winter wrote: > Hi, > >>> Knives are easily available to anyone, just like encryption. >> ...and just like pervasive monitoring? > That's a very good thought. > > Yes, I believe encrpytion and the ability to pervasively monitor are > both easily available to everyone. > > The next step after availability is actual usage, and this is where > things get interesting. > > I believe that where encryption is not actually *used*, pervasice > monitoring *will* happen. Or, to state it a bit more in a logic-oriented > way: > > Either the use of encryption proliferates, or the use of pervasive > monitoring proliferates. > > It is a strict XOR: you can't have both, and you can't have none of the two. Pervasive monitoring is not just about encryption, and I suspect you fully understand this, but have simplified your argument for the purposes of focusing on encryption. Even so, I like your analogy, in as much as you are not looking at one big XOR but many little small ones and then summing them on either side of the equation. That's the nature of engineering tradeoffs, to be fair. In reviewing some other work on another list, I came across a paper that talked about pervasive surveillance from an economics sense, written in 2006 entitled /The Economics of Mass Surveillance and the Questionable Value of Anonymous Communications/.[1] It's early work to be sure, and actually argues that the adversary has to actually do very little to achieve quite a lot in monitoring everyone. But it also alludes to the use of social network theory to answer questions of "who" not "what". While there are many different aspects of surveillance, social networks are clearly a component. Masking the "who" is much harder than the what, and yet the "who" may be as or more valuable. Unfortunately for us, the who can be represented by IP address (as an example). It's why there's some interest in TOR. Fortunately for us, use of services like Google or Facebook or Twitter provide a means to obscure paths of communication. Unfortunately for us, they become single points of failure.[*] This goes to a point that Mark Nottingham made in the plenary. How do we strike a balance between those single points of failure on the one hand and the potential benefits that some amount of aggregation can bring? There has been other related work on this topic from the context of platform diversity and cybersecurity, but I regret that I couldn't find the paper I wanted to cite for this email (I tried- it's there- maybe others can dig it up) that is worth some consideration. My point in raising this now and my point of intervening several times in the plenary is to highlight that many of the issues around pervasive surveillance are complex and have many tradeoffs to be made. There's some research to be reviewed, and perhaps some research to be performed. When we say that we the IETF are going to do something, we need to be looking at a long term view, while taking reasonable actions in the short term that heads us in the right direction. Eliot [1] http://weis2006.econinfosec.org/docs/36.pdf [*] I imagine there's an undiscovered Rogers and Hammerstein song called "Fortunately/Unfortunately" buried in here. --------------090101030501060203080301 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi Stefan,


On 12/11/13 8:35 AM, Stefan Winter wrote:
Hi,


Knives are easily available to anyone, just like encryption.

...and just like pervasive monitoring?

That's a very good thought.

Yes, I believe encrpytion and the ability to pervasively monitor are
both easily available to everyone.

The next step after availability is actual usage, and this is where
things get interesting.

I believe that where encryption is not actually *used*, pervasice
monitoring *will* happen. Or, to state it a bit more in a logic-oriented
way:

Either the use of encryption proliferates, or the use of pervasive
monitoring proliferates.

It is a strict XOR: you can't have both, and you can't have none of the two.

Pervasive monitoring is not just about encryption, and I suspect you fully understand this, but have simplified your argument for the purposes of focusing on encryption.  Even so, I like your analogy, in as much as you are not looking at one big XOR but many little small ones and then summing them on either side of the equation.  That's the nature of engineering tradeoffs, to be fair.

In reviewing some other work on another list, I came across a paper that talked about pervasive surveillance from an economics sense, written in 2006 entitled The Economics of Mass Surveillance and the Questionable Value of Anonymous Communications.[1]  It's early work to be sure, and actually argues that the adversary has to actually do very little to achieve quite a lot in monitoring everyone.  But it also alludes to the use of social network theory to answer questions of "who" not "what".  While there are many different aspects of surveillance, social networks are clearly a component.

Masking the "who" is much harder than the what, and yet the "who" may be as or more valuable.  Unfortunately for us, the who can be represented by IP address (as an example).  It's why there's some interest in TOR.  Fortunately for us, use of services like Google or Facebook or Twitter provide a means to obscure paths of communication.  Unfortunately for us, they become single points of failure.[*]

This goes to a point that Mark Nottingham made in the plenary.  How do we strike a balance between those single points of failure on the one hand and the potential benefits that some amount of aggregation can bring?  There has been other related work on this topic from the context of platform diversity and cybersecurity, but I regret that I couldn't find the paper I wanted to cite for this email (I tried- it's there- maybe others can dig it up) that is worth some consideration.

My point in raising this now and my point of intervening several times in the plenary is to highlight that many of the issues around pervasive surveillance are complex and have many tradeoffs to be made.  There's some research to be reviewed, and perhaps some research to be performed.  When we say that we the IETF are going to do something, we need to be looking at a long term view, while taking reasonable actions in the short term that heads us in the right direction.

Eliot

[1] http://weis2006.econinfosec.org/docs/36.pdf
[*] I imagine there's an undiscovered Rogers and Hammerstein song called "Fortunately/Unfortunately" buried in here.
--------------090101030501060203080301-- From stefan.winter@restena.lu Wed Dec 11 02:40:56 2013 Return-Path: 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 BE84E1AE033 for ; Wed, 11 Dec 2013 02:40:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.879 X-Spam-Level: X-Spam-Status: No, score=-0.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RP_MATCHES_RCVD=-0.001, WEIRD_PORT=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 QOdy-7GbG_f4 for ; Wed, 11 Dec 2013 02:40:54 -0800 (PST) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 29DF01AE029 for ; Wed, 11 Dec 2013 02:40:54 -0800 (PST) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 6745E10583 for ; Wed, 11 Dec 2013 11:40:48 +0100 (CET) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 5585410580 for ; Wed, 11 Dec 2013 11:40:48 +0100 (CET) Message-ID: <52A8412F.2090703@restena.lu> Date: Wed, 11 Dec 2013 11:40:47 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 CC: perpass References: <20131203174852.21387.26099.idtracker@ietfa.amsl.com> <002501cef266$b0b8a540$4001a8c0@gateway.2wire.net> <52A1A3AA.3080101@restena.lu> <009701cef2b3$f6c69400$4001a8c0@gateway.2wire.net>, <52A5786A.8040308@restena.lu>, <290E20B455C66743BE178C5C84F1240847E51037A1@EXMB01CMS.surrey.ac.uk> <290E20B455C66743BE178C5C84F1240847E51037A2@EXMB01CMS.surrey.ac.uk> <52A815AE.9070408@restena.lu> <52A8250A.7060604@cisco.com> In-Reply-To: <52A8250A.7060604@cisco.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="3rJrTMK2FpoPh0q8BhIGcpmnUgNPMem2F" X-Virus-Scanned: ClamAV Subject: Re: [perpass] on encryption and social networks (Was Last call: draft-farrell-perpass-attack-02) 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 10:40:57 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --3rJrTMK2FpoPh0q8BhIGcpmnUgNPMem2F Content-Type: multipart/mixed; boundary="------------060708080204020500090905" This is a multi-part message in MIME format. --------------060708080204020500090905 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, >> I believe that where encryption is not actually *used*, pervasice >> monitoring *will* happen. Or, to state it a bit more in a logic-orient= ed >> way: >> >> Either the use of encryption proliferates, or the use of pervasive >> monitoring proliferates. >> >> It is a strict XOR: you can't have both, and you can't have none of th= e two. >=20 > Pervasive monitoring is not just about encryption, and I suspect you > fully understand this, but have simplified your argument for the > purposes of focusing on encryption. Well, yes, the thread was massively around encryption (which was probably off-topic (sorry), as perpass doesn't explicitly touch this). > Even so, I like your analogy, in as > much as you are not looking at one big XOR but many little small ones > and then summing them on either side of the equation. That's the natur= e > of engineering tradeoffs, to be fair. I think my main point is that the world at large wasn't aware that there is an equation at play at all. For a very long time we (for some definition of we; I suggest "internet users") thought that when lowering the encryption/privacy/etc. side, there would be no adverse effect; essentially thinking "Nah, there is nobody who wants to exploit my not-very-important data, and nobody would be able to do this on a big scale anyway; we can afford to ignore/depriorise security properties". What we've learned from the Snowden documents is that we have to expect capable adversaries to be at all the important spots who will merrily exploit any opportunity we give them and make the most out of it. They even collect our digital junk and find it a valuable asset. Only at that point did it become clear that there actually *is* an equation, and that the other side of the equation is an ugly-looking beas= t. And by consequence, that any lapse on our side of the equation will have an effect on the other side. (To be fair, the equation is of course a lot more complicated than my simplistic XOR ;-) ) In a way, using the same half-baked mathemetical expression repertoire: perpass attacks are a function of encryption, authentication, traffic volume analysis, ...; or: f(level of use of encrpytion, level of use of anonymity, level of use of traffic volume concealment, ...) =3D actual surveillance level Before Snowden, I would not have put an equals there, but merely: "presents an upper bound for". I have become less optimistic :-/ We should tune all parameters of the function to minimise the outcome of the function; under the condition of keeping in mind that the left side should still remain *usable* with this tuning in place. > Masking the "who" is much harder than the what, and yet the "who" may b= e > as or more valuable. Unfortunately for us, the who can be represented > by IP address (as an example). It's why there's some interest in TOR. = > Fortunately for us, use of services like Google or Facebook or Twitter > provide a means to obscure paths of communication. Unfortunately for > us, they become single points of failure.[*] Thanks for the link to the paper, a good read! It suggests there's not just something to be learned from "who" and "what" but also the "how much= ". One of the reasons why I jumped on the encryption part of things is because I consider those to be the low-hanging fruit - it's the "what". About the what: Developing encryption for protocols is "what we do", so doing more of that comes easy. About the who: very exact and deterministic routing of packets to known IP addresses is what we do. Changing things towards introducing untracable, indeterministic detours and artificially making communication less effective by creating noise is not what we usually do. So working in that area is harder. If we don't mind taking non-IETF work into our hands we could of course say: every router MUST TOR (both for outgoing user payload, and as a relay and exit node) - but do we want that? The implications on traffic volume and routing efficiency are totally non-obvious. About the "how much", only a crazy idea: it would be kind of nice to have a program on every internet user's computer who "keeps the line busy" at all times. Equipped with a random selection of URLs to visit, it just downloads stuff and moves it to /dev/null. Just to make the SNR to a passive listener uninteresting. An external viewer can't determine if a URL was automated junk download or something the user actually saw. Such a scheme would make perpass attacks much less useful, all without encryption. It could even help with plausible deniability in case a government finds a particularly "bad" URL was visited by the user - it's quite plausible that it was not him, but some daemon on his machine, and the user never saw the result of the download. Google has a pretty good DB of URLs to visit - and it's even largely copyright-infringement clean, because the copyright holders are nice enough to force Google to cleanse infringing entries. Thanks! Greetings, Stefan Winter > This goes to a point that Mark Nottingham made in the plenary. How do > we strike a balance between those single points of failure on the one > hand and the potential benefits that some amount of aggregation can > bring? There has been other related work on this topic from the contex= t > of platform diversity and cybersecurity, but I regret that I couldn't > find the paper I wanted to cite for this email (I tried- it's there- > maybe others can dig it up) that is worth some consideration. >=20 > My point in raising this now and my point of intervening several times > in the plenary is to highlight that many of the issues around pervasive= > surveillance are complex and have many tradeoffs to be made. There's > some research to be reviewed, and perhaps some research to be > performed. When we say that we the IETF are going to do something, we > need to be looking at a long term view, while taking reasonable actions= > in the short term that heads us in the right direction. >=20 > Eliot >=20 > [1] http://weis2006.econinfosec.org/docs/36.pdf > [*] I imagine there's an undiscovered Rogers and Hammerstein song calle= d > "Fortunately/Unfortunately" buried in here. --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=C3=A9seau T=C3=A9l=C3=A9informatique de l'Education= Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xC0DE6A358A39DC66 --------------060708080204020500090905 Content-Type: application/pgp-keys; name="0x8A39DC66.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x8A39DC66.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2.0.19 (GNU/Linux) mQINBFIplEwBEADTSz+DS8nio+RSvfSLLfaOnCGi1nqpn8Pb1laVUyEvnAAzZ5je miS88GxfiDH6hUGlWzcaW0hCfUHGiohr485adbjxRksPngWgAt/1bRxpifsW3zOb Fjgog01WWQV5Sihlwc4zr8zvYbFA5BJZ6YdkR9C5J015riv5OS30WTjA65SSXgYr b7zJWPwmegTFwE093uBFvC39waz3xYpVu5j87nO6w2MVQt/8sY2/2BFPEq+xfOaj l18UEwc7w8SCgnZdlVNcmEK4UBvJuwS/1lsR2JeQa8Gu1EDxC7PRgMgNXsDSWnnB e9aVmfG54+6ILe1QH2dwk9sPBQT5w2+vjijrb3Dv9ur+1kN+TNU2XE436jVpnnY/ 3OsLdix30STQn4Q/XOm7YoVMeDwwviefilRxzK0dXA+wKj92T68Od82CFxuZqPAg BCVmWfQM91iK9piqFK+QP+R3vF6+NGDBdwbe68iVKs0v5L8XmbxBQndjpmo+lo2a smBR2TAIfZHaKdgtBw13u3GPVVKlg/Mpko8ki9JOSem2aFyi3kQEVKptWgXT3POl 97DWJzsR5VyKz6GOx9kJAEISRyLZwm0wqh8+9LCza5oeIKW381lzq1b9x30vOh8C BSQQJ+cG9ko0yPHAj7Suw2TmPXx1qMctmE6Ahq82ZW30SljdZby8WQuR2wARAQAB tDxTdGVmYW4gV2ludGVyIChSRVNURU5BIGtleSAyMDEzKykgPHN0ZWZhbi53aW50 ZXJAcmVzdGVuYS5sdT6JAjkEEwECACMFAlIplEwCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRDA3mo1ijncZj7/D/99hVS+mJr8dSPCaDaUFFxBiT2eI1Lo R8VKEerTCRw5BsdL6pN2eRJZ9NmsqWo1ynWVHEzO91bNZ+oZGgyoNohcBAI7p+r0 qUTzkyqwdZO4kMm0pqKoM9xkP3tf2mjGujKjOz4Y7S7wnz2ZFokeUsecoRVJF/++ /qHnmeWLn44J1HUKLHYCjMu+QXGOgGXgz024jQ5eUrnPwzNp0Z90AFVHlWC+bymt y/ToIUUCQqS5Ff0jzdWLd8U695OG9iGvjBQT1LdEjsfbAwuKV5UcnpxNqUpUwKa5 9hdX5/2cMZP07FI1UXwnBlxa8rJfdb13FLjSKX4vUUHedYUZMjMPgcwl1a+zGE22 lHiSQWgP8QLA/W3BLsi22ERCEPZBfexOeOtaWIItDIz18fIaQoMDoRPshzar0JI2 CzLYsyeKySAtYJEHFVoLmMvhkwzBmgqA/BEswUA67CfCr1jFHRXdpmWM7YkyAmMa 9q6LwquWKS5+MXlUXe/3oZUcgpw/T9Uuy3Jo3RdS7B3jFcWaVr6KsO/A9u1gr/aY n5M+iJTQSj4vzqtkQaJTpSspRZoKa66HZt3IwSYiDiYZqtM83ynuj9kjnZzGfnuT aNIi996q6Mptr33mOzIE1wmMqnJYwTr3EcNtf483q/qrJwh5ES8Q9xY7aat/ZcSl 8fKubW4TlfVr8YhGBBARAgAGBQJSKZUGAAoJEPo5vdH/HhVmYTgAn24eoqO/O98o vNpt08Uab/+/tmYKAJ9kjXm9Njz5h33efzeelZUa484rr7kCDQRSKZRMARAAvBPp n7FQq7LQ5glohtbL6XIEo1U4X67S0TzUYieENSWSVYuWYIhCBldmWdmH8Bpj/qHe qdon7v+SLtR4WngzMR9toupKcFfHnbP9kpazTSB2ySHxXWGX1gJOpPXdCcg9iveK BHEsDn00ThTcPsvtXpnnzET16pXIvOXO0bxTmVZ4INIF1SWgvYma/g8kBbgXLpkj 8tOywBqFiiYPEZlDeCxDHiMgUDh6olda9K/0TZFTdMPUgjKuubfAeaDNCOrVt4Rj mFOaRLikcZocmgJhm3z/j25x7/mnNu+0di1H/S67YGQJ+pqCFInzIXDx7aRW2+JC iqsY2X3xOPWZZzjyis5SNnfOcPH3gt2hYz1fy+thsBGf4NgCN01JRqIJ2/MOQCgU dwh+9l8xqaJvCkUHM4hVh4W62MAe1u7UEqQbvvNEqxM5034vcvlE+/LRkrDCspw+ 2YJ9QyroLerVRwW5DVleP8Ifi8VB3yD80nqXYs9aqRy0BkDNIQ43ERhESMt8dJqr NkxgC6pemZrhNwyDh+hy2kPNGQh/iBpdKuH1o3E24TIZoV2v3YHvzob7aAYHddE/ PofAXhJW7I9mAs+HdWDmnI8ckuPDFpFH+Y/BFGvEXgcnJAJ1wEvf+4LuiIi0MHjR 4EWFn9vvoFDAIqD10h3FSd3D59HGtdSsNn4XaCsAEQEAAYkCHwQYAQIACQUCUimU TAIbDAAKCRDA3mo1ijncZhBtEACL036ddjc5pFoYIdoUY1vT8SMXJNquewCnL1qu DADzqDZFU5GNlQEy10krSfBwlTb9ahTtE0JFrOdZwUZtoa1Pgfr8nU6KOgrXPHbN jS/9dyc5CwGVVIpOavIm2CsMVDJ9LCF/NT+u/t1k6eGfHhPVl3dUQyDa/lzc1chK UIVQYQkFmr0A/iXP+29lFCaI+IeyU0bSdZhezDwUROn5vEx+fiPZyHDShCb+BxJv /o2LQp9JHenCiSbO+ioRZdxgbWfoKBuXOfmSStqMWXas/gZ5vS3xq72LNtKPRxgp jX3P8Zml1XDqpcBau7eK75VKE0Yd06YxnUIsbcEzInUc3uzW/u0DFpXYkMJb0XIv JyUt5yYPKfV13N8kSkPi5pLxm8yuftXMzfgeFMR7nafY3glTVj/TxElzg6xeZNqf C2ZjIbBtZg9ylHU8u8wwB+dX282crs0R3N9A064C71/cXlBqcjzjlKH2NUIWGxr+ od3TXFIFjszSU3NgMPKrWNhFLLwS81MpbkOe73s6aDhS8RDyNucoxtKXriLR+4Xi u4+pyj5ukYP1JqpB3ZobY/XZgCnJMye+7xeTpIDJ1LPORxM3NNAElyb26lxAK2P+ km+EpI0Zzz6rNSCfg5jYQ474+e/GBgaSG4MlaPoZ+XAfN46u1Xjjv1/AkkA4IA6m 5zP5og=3D=3D =3D3NUt -----END PGP PUBLIC KEY BLOCK----- --------------060708080204020500090905 Content-Type: application/pgp-keys; name="0x8A39DC66.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x8A39DC66.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2.0.19 (GNU/Linux) mQINBFIplEwBEADTSz+DS8nio+RSvfSLLfaOnCGi1nqpn8Pb1laVUyEvnAAzZ5je miS88GxfiDH6hUGlWzcaW0hCfUHGiohr485adbjxRksPngWgAt/1bRxpifsW3zOb Fjgog01WWQV5Sihlwc4zr8zvYbFA5BJZ6YdkR9C5J015riv5OS30WTjA65SSXgYr b7zJWPwmegTFwE093uBFvC39waz3xYpVu5j87nO6w2MVQt/8sY2/2BFPEq+xfOaj l18UEwc7w8SCgnZdlVNcmEK4UBvJuwS/1lsR2JeQa8Gu1EDxC7PRgMgNXsDSWnnB e9aVmfG54+6ILe1QH2dwk9sPBQT5w2+vjijrb3Dv9ur+1kN+TNU2XE436jVpnnY/ 3OsLdix30STQn4Q/XOm7YoVMeDwwviefilRxzK0dXA+wKj92T68Od82CFxuZqPAg BCVmWfQM91iK9piqFK+QP+R3vF6+NGDBdwbe68iVKs0v5L8XmbxBQndjpmo+lo2a smBR2TAIfZHaKdgtBw13u3GPVVKlg/Mpko8ki9JOSem2aFyi3kQEVKptWgXT3POl 97DWJzsR5VyKz6GOx9kJAEISRyLZwm0wqh8+9LCza5oeIKW381lzq1b9x30vOh8C BSQQJ+cG9ko0yPHAj7Suw2TmPXx1qMctmE6Ahq82ZW30SljdZby8WQuR2wARAQAB tDxTdGVmYW4gV2ludGVyIChSRVNURU5BIGtleSAyMDEzKykgPHN0ZWZhbi53aW50 ZXJAcmVzdGVuYS5sdT6JAjkEEwECACMFAlIplEwCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRDA3mo1ijncZj7/D/99hVS+mJr8dSPCaDaUFFxBiT2eI1Lo R8VKEerTCRw5BsdL6pN2eRJZ9NmsqWo1ynWVHEzO91bNZ+oZGgyoNohcBAI7p+r0 qUTzkyqwdZO4kMm0pqKoM9xkP3tf2mjGujKjOz4Y7S7wnz2ZFokeUsecoRVJF/++ /qHnmeWLn44J1HUKLHYCjMu+QXGOgGXgz024jQ5eUrnPwzNp0Z90AFVHlWC+bymt y/ToIUUCQqS5Ff0jzdWLd8U695OG9iGvjBQT1LdEjsfbAwuKV5UcnpxNqUpUwKa5 9hdX5/2cMZP07FI1UXwnBlxa8rJfdb13FLjSKX4vUUHedYUZMjMPgcwl1a+zGE22 lHiSQWgP8QLA/W3BLsi22ERCEPZBfexOeOtaWIItDIz18fIaQoMDoRPshzar0JI2 CzLYsyeKySAtYJEHFVoLmMvhkwzBmgqA/BEswUA67CfCr1jFHRXdpmWM7YkyAmMa 9q6LwquWKS5+MXlUXe/3oZUcgpw/T9Uuy3Jo3RdS7B3jFcWaVr6KsO/A9u1gr/aY n5M+iJTQSj4vzqtkQaJTpSspRZoKa66HZt3IwSYiDiYZqtM83ynuj9kjnZzGfnuT aNIi996q6Mptr33mOzIE1wmMqnJYwTr3EcNtf483q/qrJwh5ES8Q9xY7aat/ZcSl 8fKubW4TlfVr8YhGBBARAgAGBQJSKZUGAAoJEPo5vdH/HhVmYTgAn24eoqO/O98o vNpt08Uab/+/tmYKAJ9kjXm9Njz5h33efzeelZUa484rr7kCDQRSKZRMARAAvBPp n7FQq7LQ5glohtbL6XIEo1U4X67S0TzUYieENSWSVYuWYIhCBldmWdmH8Bpj/qHe qdon7v+SLtR4WngzMR9toupKcFfHnbP9kpazTSB2ySHxXWGX1gJOpPXdCcg9iveK BHEsDn00ThTcPsvtXpnnzET16pXIvOXO0bxTmVZ4INIF1SWgvYma/g8kBbgXLpkj 8tOywBqFiiYPEZlDeCxDHiMgUDh6olda9K/0TZFTdMPUgjKuubfAeaDNCOrVt4Rj mFOaRLikcZocmgJhm3z/j25x7/mnNu+0di1H/S67YGQJ+pqCFInzIXDx7aRW2+JC iqsY2X3xOPWZZzjyis5SNnfOcPH3gt2hYz1fy+thsBGf4NgCN01JRqIJ2/MOQCgU dwh+9l8xqaJvCkUHM4hVh4W62MAe1u7UEqQbvvNEqxM5034vcvlE+/LRkrDCspw+ 2YJ9QyroLerVRwW5DVleP8Ifi8VB3yD80nqXYs9aqRy0BkDNIQ43ERhESMt8dJqr NkxgC6pemZrhNwyDh+hy2kPNGQh/iBpdKuH1o3E24TIZoV2v3YHvzob7aAYHddE/ PofAXhJW7I9mAs+HdWDmnI8ckuPDFpFH+Y/BFGvEXgcnJAJ1wEvf+4LuiIi0MHjR 4EWFn9vvoFDAIqD10h3FSd3D59HGtdSsNn4XaCsAEQEAAYkCHwQYAQIACQUCUimU TAIbDAAKCRDA3mo1ijncZhBtEACL036ddjc5pFoYIdoUY1vT8SMXJNquewCnL1qu DADzqDZFU5GNlQEy10krSfBwlTb9ahTtE0JFrOdZwUZtoa1Pgfr8nU6KOgrXPHbN jS/9dyc5CwGVVIpOavIm2CsMVDJ9LCF/NT+u/t1k6eGfHhPVl3dUQyDa/lzc1chK UIVQYQkFmr0A/iXP+29lFCaI+IeyU0bSdZhezDwUROn5vEx+fiPZyHDShCb+BxJv /o2LQp9JHenCiSbO+ioRZdxgbWfoKBuXOfmSStqMWXas/gZ5vS3xq72LNtKPRxgp jX3P8Zml1XDqpcBau7eK75VKE0Yd06YxnUIsbcEzInUc3uzW/u0DFpXYkMJb0XIv JyUt5yYPKfV13N8kSkPi5pLxm8yuftXMzfgeFMR7nafY3glTVj/TxElzg6xeZNqf C2ZjIbBtZg9ylHU8u8wwB+dX282crs0R3N9A064C71/cXlBqcjzjlKH2NUIWGxr+ od3TXFIFjszSU3NgMPKrWNhFLLwS81MpbkOe73s6aDhS8RDyNucoxtKXriLR+4Xi u4+pyj5ukYP1JqpB3ZobY/XZgCnJMye+7xeTpIDJ1LPORxM3NNAElyb26lxAK2P+ km+EpI0Zzz6rNSCfg5jYQ474+e/GBgaSG4MlaPoZ+XAfN46u1Xjjv1/AkkA4IA6m 5zP5og=3D=3D =3D3NUt -----END PGP PUBLIC KEY BLOCK----- --------------060708080204020500090905-- --3rJrTMK2FpoPh0q8BhIGcpmnUgNPMem2F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJSqEEvAAoJEMDeajWKOdxmkt0P/3EmFjYdhFzMrXQW9kP4B3jg +rUpLxZqD0aHbHnF/Uy52weSpsFucIsR/tryQxgJCevbFir9TTptgXPh7CewdP+O SuOGFK3oIqbEOxz96fvCnsygNS3j3zEgdZARaeAPv+7btflNXqHM0Tin1E9X9sQH MpM97LjgAWJahFr3DbiiVQRyWFoR7f/0PaJyM8GRAPsemN2gcb7iudneOlDGY689 7cjSAh13oLm/VYiIbxYNVkUMe3HHXjzV7P1S3LdeEYAv+WSNvAkDBSrgTUTqXlEi bzUTRr7AjTJWlTEAC3HrhnsVOzmWmfuGS/euj5a1MMXM0Zusf1CIiFEi0n15SVw4 /JArtOAhLNrYaWvUCcx/Ma4H0bebESf8WHa5R06iI+9C7sw3Jv8EqL2SLyyjAbYR 8qvC3sxM7wT/r+PB9WgormxAv9jyseiZxrD20UGjNW5AwaPFx9cTo/QN0ny8uo2a nHLC8HZAGEQQDw9HPfajvufA6xOhVUbs9hrdKf5B8iOruvNAHs/PVTMEJ3IdRauv +Sf0RGzFop/zKWFpioAyznwD7zeI1+hLviyQnOE4M8YvaipOGJTbbnuKmjSSuHFZ Vxf90DN2UipZhb6LxArRBL4Lb273/jUkknVu4pSTy7jsRld8oBr7DvIpMqpFJHS4 aRnmfBODJS5o9yILBZts =Yp4H -----END PGP SIGNATURE----- --3rJrTMK2FpoPh0q8BhIGcpmnUgNPMem2F-- From nweaver@icsi.berkeley.edu Wed Dec 11 07:44:03 2013 Return-Path: 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 B33AC1AE001 for ; Wed, 11 Dec 2013 07:44:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 kLDi9CGSc09v for ; Wed, 11 Dec 2013 07:44:01 -0800 (PST) Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id CC0721ADFFA for ; Wed, 11 Dec 2013 07:44:01 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 8C7F62C403B for ; Wed, 11 Dec 2013 07:43:56 -0800 (PST) X-Virus-Scanned: amavisd-new at ICSI.Berkeley.EDU Received: from rock.ICSI.Berkeley.EDU ([127.0.0.1]) by localhost (maihub.ICSI.Berkeley.EDU [127.0.0.1]) (amavisd-new, port 10024) with LMTP id qnM4rAqPkiSI; Wed, 11 Dec 2013 07:43:56 -0800 (PST) Received: from gala.icir.org (gala.icir.org [192.150.187.130]) (Authenticated sender: nweaver) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 0F8D42C4003; Wed, 11 Dec 2013 07:43:56 -0800 (PST) From: Nicholas Weaver Content-Type: multipart/signed; boundary="Apple-Mail=_FAD739A1-FEC8-41DF-A7CB-8639E6FD25AA"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Wed, 11 Dec 2013 07:43:55 -0800 Message-Id: <0932E601-895B-457B-9F2D-DD79626AE0F0@icsi.berkeley.edu> To: perpass Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Cc: Nicholas Weaver Subject: [perpass] Yet Another Reason why ALL CLEARTEXT MUST BE ELIMINATED! 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 15:44:03 -0000 --Apple-Mail=_FAD739A1-FEC8-41DF-A7CB-8639E6FD25AA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Cookies and user tracking are wonderful things. If you are a = intelligence service, that is. Its now clear that the NSA (and, remember, any other intelligence = service that might see such traffic can do the same thing) uses = cookies/advertising for both tracking (e.g. HAPPYFOOT: Advertisement = libraries (esp on Android) which broadcast location + IMEI in the clear = -> easy user tracking) and targeting (e.g. Know the victim's google = PREFID cookie through other means, then use it to target exploitation:=20= = http://apps.washingtonpost.com/g/page/national/nsa-signal-surveillance-suc= cess-stories/647/#document/p3/a135602 = http://www.washingtonpost.com/blogs/the-switch/wp/2013/12/10/nsa-uses-goog= le-cookies-to-pinpoint-targets-for-hacking/ ) Everyone on this list should now consider themselves an in-scope target = from at least one foreign intelligence service... But the intelligence services can do even better if they want. Here's = how: The NSA or foreign intelligence wiretap has a possible candidate for = attack, but not probable. That is, they THINK they may want to do an = exploitation attack but aren't sure... 1) On the packet-injecting wiretap, it sees a possible candidate and it = does a packet injection of a 302 redirect to a "User ID" script on the = exploit server for something inconsequentially small. 2) The user-ID script creates a hidden iframe. Within that iframe, it opens up a bunch of other iframes to various = sites, e.g.www.youtube.com,www.linkedin.com, www.yahoo.com, = slashdot.org, etc. Namely ANLY (and well, all) sites which a) Identifies the user in the response b) Uses a user-identifying cookie that can be sent in the clear. This causes the possible victim's browser to visit all these sites, = identifying the victim to any wiretap that can see it. 3) Back on the packet-injecting wiretap, it looks for request/response = pairs to the targeted sites, using the request to extract the user ID = cookies and the response to match the user identification by quick & = dirty parsing of the HTML in the response. Since the wiretap knows the user identifications it wants to exploit, it = now knows the user ID cookies it wants to exploit as well. 4) Back on the user-ID script, after a ~10 second delay, it then = creates a second set of iframes to the various sites for different URLs. = This causes the possible victim's browser to revisit all the sites. = These requests contain the user's ID cookies, which any wiretap has now = been able to map to "is this the actual person I want to target" 5) The packet injecting wiretap, now that it knows the user ID cookies = it might want to target, packet injects an exploit against any desired = user ID cookie... This enables the packet injection/exploitation system to leverage all = known user-identifying sites in the clear to target their exploitation = with high precision, even when the potential victim doesn't attempt to = visit the user identifying sites in the clear. The requirements for ANY intelligence service to do this to target YOU = are: a) They must see ONE web request from you in the clear pass ONE of = their wiretaps when they consider you "just might be a possible target" b) They must see ONE of the user-identifying web requests pass ONE of = their wiretaps, and you must be logged into that site. As you can imagine, the set of possible actors able to do this actually = ends up being pretty darn big... The IETF needs to work for HTTPS-only, NOW, out of simple self defense. -- Nicholas Weaver it is a tale, told by an idiot, nweaver@icsi.berkeley.edu full of sound and fury, 510-666-2903 .signifying nothing PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc --Apple-Mail=_FAD739A1-FEC8-41DF-A7CB-8639E6FD25AA Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCgAGBQJSqIg7AAoJEG2B1w+SDi/uhyYP/RnqCfaLSL8FPy8HLPJRwje2 6FwA6AY0zlwGh+B0GKsp3M8Lkmi9BofARYzSaqCM/D6QrGcWNIe3kM3I4ld7nm/a jcsg3uFsuQ48nrKY7R7q/ORQGQzqnxAR9scYGGPdJKRCmmQjntfRZkivMfpb9GH0 jMX3efXxsohpKKTahKFmwbXrwfuekg5cQ8KG9qpuD4+KlnwJuDVm7KuPSxlCUd7Q Vmn+xsydvae9rEOfSQ6rSrXxx57mNbxxTwUO5wMINHTSVJS6FMxw5bTc093Ra7SL r1YBK2X29I73bWo07nBLOPn5bxNUJc0Hm+1qus8fa4+QOsBgtB0/RxrypkC8fI+0 7BjFszsjkiLUKF0nC4xYL76VpteAPpCHyq6UMm9w0he4VeQLqrrjsiiIMqyh3VVB FR2Xy/uCk8YpQFl1m+nq9sodEFFDfr6WuCoArxi/nkZx3R2poxFisi6T2zoQ8gkL nCP7iOyIewjOOHuq8IelBkes0gcr2ui+TK1pfDwXauxIBwmry8yrmchcwETKIlj+ /tFOHgQ0tO1QpStJeourRV12sERAj4qP5Pmk/GxhSaUnnWQF4IsTMK7OrhzSGMTo PlFWWAy4h1+NQKL2g1EL5PLYQOv9f2sfUsj3sahRhuqn//o9LonWaVgFL78iSKWp mAxtaBdYIKfZLZrAGmn6 =95dQ -----END PGP SIGNATURE----- --Apple-Mail=_FAD739A1-FEC8-41DF-A7CB-8639E6FD25AA-- From wilton@isoc.org Wed Dec 11 08:22:03 2013 Return-Path: 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 749F51ADFA4 for ; Wed, 11 Dec 2013 08:22:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 ph17gPc9Zw_K for ; Wed, 11 Dec 2013 08:22:00 -0800 (PST) Received: from smtp126.iad3a.emailsrvr.com (smtp126.iad3a.emailsrvr.com [173.203.187.126]) by ietfa.amsl.com (Postfix) with ESMTP id 074A41AE043 for ; Wed, 11 Dec 2013 08:22:00 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp24.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 47B2C1500BA; Wed, 11 Dec 2013 11:21:54 -0500 (EST) X-Virus-Scanned: OK Received: by smtp24.relay.iad3a.emailsrvr.com (Authenticated sender: wilton-AT-isoc.org) with ESMTPSA id A211C150093; Wed, 11 Dec 2013 11:21:53 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_AA8DFFD9-4256-4A93-BDB9-B9B306D568BB" From: Robin Wilton In-Reply-To: <0932E601-895B-457B-9F2D-DD79626AE0F0@icsi.berkeley.edu> Date: Wed, 11 Dec 2013 17:23:11 +0100 Message-Id: <7D801592-36E4-4C5E-8AC9-B8940A72CC8B@isoc.org> References: <0932E601-895B-457B-9F2D-DD79626AE0F0@icsi.berkeley.edu> To: Nicholas Weaver X-Mailer: Apple Mail (2.1283) Cc: perpass Subject: Re: [perpass] Yet Another Reason why ALL CLEARTEXT MUST BE ELIMINATED! 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 16:22:03 -0000 --Apple-Mail=_AA8DFFD9-4256-4A93-BDB9-B9B306D568BB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thanks Nicholas - this is useful and relevant analysis. In case you haven't already seen it, this piece about some new research = (at Stanford... sorry ;^) ) gives a similarly worrying perspective on = the role of "hub" sites in expanding the scope of the "three hops" rule. = Your Step 2 is, I think, a very similar mechanism, and has significant = privacy impact. Yrs., Robin Robin Wilton Technical Outreach Director - Identity and Privacy Internet Society email: wilton@isoc.org Phone: +44 705 005 2931 Twitter: @futureidentity On 11 Dec 2013, at 16:43, Nicholas Weaver wrote: >=20 > Cookies and user tracking are wonderful things. If you are a = intelligence service, that is. >=20 > Its now clear that the NSA (and, remember, any other intelligence = service that might see such traffic can do the same thing) uses = cookies/advertising for both tracking (e.g. HAPPYFOOT: Advertisement = libraries (esp on Android) which broadcast location + IMEI in the clear = -> easy user tracking) and targeting (e.g. Know the victim's google = PREFID cookie through other means, then use it to target exploitation:=20= >=20 > = http://apps.washingtonpost.com/g/page/national/nsa-signal-surveillance-suc= cess-stories/647/#document/p3/a135602 >=20 > = http://www.washingtonpost.com/blogs/the-switch/wp/2013/12/10/nsa-uses-goog= le-cookies-to-pinpoint-targets-for-hacking/ > ) >=20 > Everyone on this list should now consider themselves an in-scope = target from at least one foreign intelligence service... >=20 >=20 > But the intelligence services can do even better if they want. Here's = how: >=20 > The NSA or foreign intelligence wiretap has a possible candidate for = attack, but not probable. That is, they THINK they may want to do an = exploitation attack but aren't sure... >=20 >=20 > 1) On the packet-injecting wiretap, it sees a possible candidate and = it does a packet injection of a 302 redirect to a "User ID" script on = the exploit server for something inconsequentially small. >=20 >=20 > 2) The user-ID script creates a hidden iframe. >=20 > Within that iframe, it opens up a bunch of other iframes to various = sites, e.g.www.youtube.com,www.linkedin.com, www.yahoo.com, = slashdot.org, etc. Namely ANLY (and well, all) sites which >=20 > a) Identifies the user in the response >=20 > b) Uses a user-identifying cookie that can be sent in the clear. >=20 > This causes the possible victim's browser to visit all these sites, = identifying the victim to any wiretap that can see it. >=20 >=20 > 3) Back on the packet-injecting wiretap, it looks for = request/response pairs to the targeted sites, using the request to = extract the user ID cookies and the response to match the user = identification by quick & dirty parsing of the HTML in the response. >=20 > Since the wiretap knows the user identifications it wants to exploit, = it now knows the user ID cookies it wants to exploit as well. >=20 >=20 > 4) Back on the user-ID script, after a ~10 second delay, it then = creates a second set of iframes to the various sites for different URLs. = This causes the possible victim's browser to revisit all the sites. = These requests contain the user's ID cookies, which any wiretap has now = been able to map to "is this the actual person I want to target" >=20 >=20 > 5) The packet injecting wiretap, now that it knows the user ID = cookies it might want to target, packet injects an exploit against any = desired user ID cookie... >=20 >=20 > This enables the packet injection/exploitation system to leverage all = known user-identifying sites in the clear to target their exploitation = with high precision, even when the potential victim doesn't attempt to = visit the user identifying sites in the clear. >=20 >=20 >=20 > The requirements for ANY intelligence service to do this to target YOU = are: >=20 > a) They must see ONE web request from you in the clear pass ONE of = their wiretaps when they consider you "just might be a possible target" >=20 > b) They must see ONE of the user-identifying web requests pass ONE of = their wiretaps, and you must be logged into that site. >=20 >=20 > As you can imagine, the set of possible actors able to do this = actually ends up being pretty darn big... >=20 > The IETF needs to work for HTTPS-only, NOW, out of simple self = defense. >=20 >=20 > -- > Nicholas Weaver it is a tale, told by an idiot, > nweaver@icsi.berkeley.edu full of sound and fury, > 510-666-2903 .signifying nothing > PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc >=20 > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass --Apple-Mail=_AA8DFFD9-4256-4A93-BDB9-B9B306D568BB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

Yrs.,
Robin

Robin = Wilton
Technical Outreach Director - Identity and = Privacy
Internet Society

Phone: +44 = 705 005 2931
Twitter: = @futureidentity




On 11 Dec 2013, at 16:43, Nicholas Weaver wrote:


Cookies and user tracking are wonderful things. =  If you are a intelligence service, that is.

Its now clear = that the NSA (and, remember, any other intelligence service that might = see such traffic can do the same thing) uses cookies/advertising for = both tracking (e.g. HAPPYFOOT: Advertisement libraries (esp on Android) = which broadcast location + IMEI in the clear -> easy user tracking) = and targeting (e.g. Know the victim's google PREFID cookie through other = means, then use it to target exploitation:

http://apps.washingtonpost.= com/g/page/national/nsa-signal-surveillance-success-stories/647/#document/= p3/a135602

http://www.washingtonpost.com/blogs/the-switch/wp/20= 13/12/10/nsa-uses-google-cookies-to-pinpoint-targets-for-hacking/
)
=
Everyone on this list should now consider themselves an in-scope = target from at least one foreign intelligence service...


But = the intelligence services can do even better if they want.  Here's = how:

The NSA or foreign intelligence wiretap has a possible = candidate for attack, but not probable.  That is, they THINK they = may want to do an exploitation attack but aren't sure...


1) =  On the packet-injecting wiretap, it sees a possible candidate and = it does a packet injection of a 302 redirect to a "User ID" script on = the exploit server for something inconsequentially small.


2) =  The user-ID script creates a hidden iframe.

Within that = iframe, it opens up a bunch of other iframes to various sites, = e.g.www.youtube.com,www.linkedin.com, www.yahoo.com, slashdot.org, etc. =  Namely ANLY (and well, all) sites which

a)  Identifies = the user in the response

b)  Uses a user-identifying cookie = that can be sent in the clear.

This causes the possible victim's = browser to visit all these sites, identifying the victim to any wiretap = that can see it.


3)  Back on the packet-injecting = wiretap, it looks for request/response pairs to the targeted sites, = using the request to extract the user ID cookies and the response to = match the user identification by quick & dirty parsing of the HTML = in the response.

Since the wiretap knows the user identifications = it wants to exploit, it now knows the user ID cookies it wants to = exploit as well.


4)  Back on the user-ID script, after a = ~10 second delay, it then creates a second set of iframes to the various = sites for different URLs.  This causes the possible victim's = browser to revisit all the sites.  These requests contain the = user's ID cookies, which any wiretap has now been able to map to "is = this the actual person I want to target"


5)  The packet = injecting wiretap, now that it knows the user ID cookies it might want = to target, packet injects an exploit against any desired user ID = cookie...


This enables the packet injection/exploitation = system to leverage all known user-identifying sites in the clear to = target their exploitation with high precision, even when the potential = victim doesn't attempt to visit the user identifying sites in the = clear.



The requirements for ANY intelligence service to = do this to target YOU are:

a)  They must see ONE web request = from you in the clear pass ONE of their wiretaps when they consider you = "just might be a possible target"

b)  They must see ONE of = the user-identifying web requests pass ONE of their wiretaps, and you = must be logged into that site.


As you can imagine, the set of = possible actors able to do this actually ends up being pretty darn = big...

The IETF needs to work for HTTPS-only, NOW, out of simple = self defense.


--
Nicholas Weaver =             &n= bsp;    it is a tale, told by an = idiot,
nweaver@icsi.berkeley.edu =             &n= bsp;  full of sound and fury,
510-666-2903 =             &n= bsp;           &nbs= p;       .signifying nothing
PGP: = http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc

_______= ________________________________________
perpass mailing = list
perpass@ietf.org
https://www.ietf.org/mailman/listinfo/perpass<= br>

= --Apple-Mail=_AA8DFFD9-4256-4A93-BDB9-B9B306D568BB-- From wilton@isoc.org Wed Dec 11 10:16:32 2013 Return-Path: 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 F0E461ADD02 for ; Wed, 11 Dec 2013 10:16:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 3tazitLEPeQp for ; Wed, 11 Dec 2013 10:16:28 -0800 (PST) Received: from smtp118.iad3a.emailsrvr.com (smtp118.iad3a.emailsrvr.com [173.203.187.118]) by ietfa.amsl.com (Postfix) with ESMTP id 77EDF1ADBCB for ; Wed, 11 Dec 2013 10:16:28 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp7.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id AEC8F400A3; Wed, 11 Dec 2013 13:16:22 -0500 (EST) X-Virus-Scanned: OK Received: from app47.wa-webapps.iad3a (relay.iad3a.rsapps.net [172.27.255.110]) by smtp7.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 97D3E400B1; Wed, 11 Dec 2013 13:16:22 -0500 (EST) Received: from isoc.org (localhost.localdomain [127.0.0.1]) by app47.wa-webapps.iad3a (Postfix) with ESMTP id 8F330380046; Wed, 11 Dec 2013 13:16:22 -0500 (EST) Received: by apps.rackspace.com (Authenticated sender: wilton@isoc.org, from: wilton@isoc.org) with HTTP; Wed, 11 Dec 2013 13:16:22 -0500 (EST) Date: Wed, 11 Dec 2013 13:16:22 -0500 (EST) From: wilton@isoc.org To: "Nicholas Weaver" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_20131211131622000000_92675" Importance: Normal X-Priority: 3 (Normal) X-Type: html In-Reply-To: <0932E601-895B-457B-9F2D-DD79626AE0F0@icsi.berkeley.edu> References: <0932E601-895B-457B-9F2D-DD79626AE0F0@icsi.berkeley.edu> Message-ID: <1386785782.584816710@apps.rackspace.com> X-Mailer: webmail7.0 Cc: perpass , Nicholas Weaver Subject: Re: [perpass] Yet Another Reason why ALL CLEARTEXT MUST BE ELIMINATED! 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 18:16:32 -0000 ------=_20131211131622000000_92675 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0AAnd this time *with* the link... I hate it when I do that.=0A=0A[http://= webpolicy.org/2013/12/09/metaphone-the-nsa-three-hop/] http://webpolicy.org= /2013/12/09/metaphone-the-nsa-three-hop/=0A=0ARobin=0A=0A=0AOn 11 Dec 2013,= at 17:23, Robin Wilton wrote:=0A=0AThanks Nicholas - this is useful and re= levant analysis.=0A=0AIn case you haven't already seen it, this piece about= some new research (at Stanford... sorry ;^) ) gives a similarly worrying = perspective on the role of "hub" sites in expanding the scope of the "three= hops" rule. Your Step 2 is, I think, a very similar mechanism, and has sig= nificant privacy impact.=0A=0AYrs.,=0ARobin=0A=0A=0A=0A=0ARobin Wilton=0ATe= chnical Outreach Director - Identity and Privacy=0AInternet Society=0A=0Aem= ail: [mailto:wilton@isoc.org] wilton@isoc.org=0APhone: +44 705 005 2931=0AT= witter: @futureidentity=0A =0A-----Original Message-----=0AFrom: "Nicholas = Weaver" =0ASent: Wednesday, December 11, 2013 10= :43am=0ATo: "perpass" =0ACc: "Nicholas Weaver" =0ASubject: [perpass] Yet Another Reason why ALL CLEARTEXT= MUST BE ELIMINATED!=0A=0A=0A=0A___________________________________________= ____=0Aperpass mailing list=0Aperpass@ietf.org=0Ahttps://www.ietf.org/mailm= an/listinfo/perpass=0A=0ACookies and user tracking are wonderful things. I= f you are a intelligence service, that is.=0A=0AIts now clear that the NSA = (and, remember, any other intelligence service that might see such traffic = can do the same thing) uses cookies/advertising for both tracking (e.g. HAP= PYFOOT: Advertisement libraries (esp on Android) which broadcast location += IMEI in the clear -> easy user tracking) and targeting (e.g. Know the vict= im's google PREFID cookie through other means, then use it to target exploi= tation: =0A=0Ahttp://apps.washingtonpost.com/g/page/national/nsa-signal-sur= veillance-success-stories/647/#document/p3/a135602=0A=0Ahttp://www.washingt= onpost.com/blogs/the-switch/wp/2013/12/10/nsa-uses-google-cookies-to-pinpoi= nt-targets-for-hacking/=0A)=0A=0AEveryone on this list should now consider = themselves an in-scope target from at least one foreign intelligence servic= e...=0A=0A=0ABut the intelligence services can do even better if they want.= Here's how:=0A=0AThe NSA or foreign intelligence wiretap has a possible c= andidate for attack, but not probable. That is, they THINK they may want t= o do an exploitation attack but aren't sure...=0A=0A=0A1) On the packet-in= jecting wiretap, it sees a possible candidate and it does a packet injectio= n of a 302 redirect to a "User ID" script on the exploit server for somethi= ng inconsequentially small.=0A=0A=0A2) The user-ID script creates a hidden= iframe.=0A=0AWithin that iframe, it opens up a bunch of other iframes to v= arious sites, e.g.www.youtube.com,www.linkedin.com, www.yahoo.com, slashdot= .org, etc. Namely ANLY (and well, all) sites which=0A=0Aa) Identifies the= user in the response=0A=0Ab) Uses a user-identifying cookie that can be s= ent in the clear.=0A=0AThis causes the possible victim's browser to visit a= ll these sites, identifying the victim to any wiretap that can see it.=0A= =0A=0A3) Back on the packet-injecting wiretap, it looks for request/respon= se pairs to the targeted sites, using the request to extract the user ID co= okies and the response to match the user identification by quick & dirty pa= rsing of the HTML in the response.=0A=0ASince the wiretap knows the user id= entifications it wants to exploit, it now knows the user ID cookies it want= s to exploit as well.=0A=0A=0A4) Back on the user-ID script, after a ~10 s= econd delay, it then creates a second set of iframes to the various sites f= or different URLs. This causes the possible victim's browser to revisit al= l the sites. These requests contain the user's ID cookies, which any wiret= ap has now been able to map to "is this the actual person I want to target"= =0A=0A=0A5) The packet injecting wiretap, now that it knows the user ID co= okies it might want to target, packet injects an exploit against any desire= d user ID cookie...=0A=0A=0AThis enables the packet injection/exploitation = system to leverage all known user-identifying sites in the clear to target = their exploitation with high precision, even when the potential victim does= n't attempt to visit the user identifying sites in the clear.=0A=0A=0A=0ATh= e requirements for ANY intelligence service to do this to target YOU are:= =0A=0Aa) They must see ONE web request from you in the clear pass ONE of t= heir wiretaps when they consider you "just might be a possible target"=0A= =0Ab) They must see ONE of the user-identifying web requests pass ONE of t= heir wiretaps, and you must be logged into that site.=0A=0A=0AAs you can im= agine, the set of possible actors able to do this actually ends up being pr= etty darn big...=0A=0AThe IETF needs to work for HTTPS-only, NOW, out of si= mple self defense.=0A=0A=0A--=0ANicholas Weaver it is a ta= le, told by an idiot,=0Anweaver@icsi.berkeley.edu full of so= und and fury,=0A510-666-2903 .signifying no= thing=0APGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc=0A= =0A ------=_20131211131622000000_92675 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

And this time *with* the link... I hate it when I do = that.=0A

=0A=0A
=0A
Robin
=0A
=0A
= =0A
On 11 Dec 2013, at 17:23, Robin Wilton wrote:
=0A
=0A=0A
Thanks Nicholas - this is = useful and relevant analysis.=0A
=0A
In case you haven't alre= ady seen it, this piece about some new research (at Stanford... sorry ;^) &= nbsp;) gives a similarly worrying perspective on the role of "hub" sites in= expanding the scope of the "three hops" rule. Your Step 2 is, I think, a v= ery similar mechanism, and has significant privacy impact.
=0A
=0A
Yrs.,
=0A
Robin
=0A

=0A
=0A
=0A
Robin Wilton
=0A
Technical Ou= treach Director - Identity and Privacy
=0A
Internet Society
= =0A
=0A=0A
Phone: +44 705 005 2931
=0A
Twitter: @f= utureidentity
=0A
=0A
=0A
=0A
=0A=0A<= /div>=0A

=0A

 

=0A

-----Original Message-----
From: "Nicholas W= eaver" <nweaver@icsi.berkeley.edu>
Sent: Wednesday, December 11,= 2013 10:43am
To: "perpass" <perpass@ietf.org>
Cc: "Nichola= s Weaver" <nweaver@icsi.berkeley.edu>
Subject: [perpass] Yet Ano= ther Reason why ALL CLEARTEXT MUST BE ELIMINATED!

=0A
=0A

_____________= __________________________________
perpass mailing list
perpass@i= etf.org
https://www.ietf.org/mailman/listinfo/perpass

Cooki= es and user tracking are wonderful things. If you are a intelligence servi= ce, that is.

Its now clear that the NSA (and, remember, any othe= r intelligence service that might see such traffic can do the same thing) u= ses cookies/advertising for both tracking (e.g. HAPPYFOOT: Advertisement li= braries (esp on Android) which broadcast location + IMEI in the clear ->= easy user tracking) and targeting (e.g. Know the victim's google PREFID co= okie through other means, then use it to target exploitation:

h= ttp://apps.washingtonpost.com/g/page/national/nsa-signal-surveillance-succe= ss-stories/647/#document/p3/a135602

http://www.washingtonpost.co= m/blogs/the-switch/wp/2013/12/10/nsa-uses-google-cookies-to-pinpoint-target= s-for-hacking/
)

Everyone on this list should now consider = themselves an in-scope target from at least one foreign intelligence servic= e...


But the intelligence services can do even better if t= hey want. Here's how:

The NSA or foreign intelligence wiretap h= as a possible candidate for attack, but not probable. That is, they THINK = they may want to do an exploitation attack but aren't sure...

1) On the packet-injecting wiretap, it sees a possible candidate and i= t does a packet injection of a 302 redirect to a "User ID" script on the ex= ploit server for something inconsequentially small.


2) Th= e user-ID script creates a hidden iframe.

Within that iframe, it= opens up a bunch of other iframes to various sites, e.g.www.youtube.com,ww= w.linkedin.com, www.yahoo.com, slashdot.org, etc. Namely ANLY (and well, a= ll) sites which

a) Identifies the user in the response
b) Uses a user-identifying cookie that can be sent in the clear.
<= br />This causes the possible victim's browser to visit all these sites, id= entifying the victim to any wiretap that can see it.


3) B= ack on the packet-injecting wiretap, it looks for request/response pairs to= the targeted sites, using the request to extract the user ID cookies and t= he response to match the user identification by quick & dirty parsing o= f the HTML in the response.

Since the wiretap knows the user ide= ntifications it wants to exploit, it now knows the user ID cookies it wants= to exploit as well.


4) Back on the user-ID script, after= a ~10 second delay, it then creates a second set of iframes to the various= sites for different URLs. This causes the possible victim's browser to re= visit all the sites. These requests contain the user's ID cookies, which a= ny wiretap has now been able to map to "is this the actual person I want to= target"


5) The packet injecting wiretap, now that it kno= ws the user ID cookies it might want to target, packet injects an exploit a= gainst any desired user ID cookie...


This enables the pack= et injection/exploitation system to leverage all known user-identifying sit= es in the clear to target their exploitation with high precision, even when= the potential victim doesn't attempt to visit the user identifying sites i= n the clear.



The requirements for ANY intelligence s= ervice to do this to target YOU are:

a) They must see ONE web r= equest from you in the clear pass ONE of their wiretaps when they consider = you "just might be a possible target"

b) They must see ONE of t= he user-identifying web requests pass ONE of their wiretaps, and you must b= e logged into that site.


As you can imagine, the set of po= ssible actors able to do this actually ends up being pretty darn big...

The IETF needs to work for HTTPS-only, NOW, out of simple self defe= nse.


--
Nicholas Weaver it is a tale= , told by an idiot,
nweaver@icsi.berkeley.edu full of s= ound and fury,
510-666-2903 .signifyin= g nothing
PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub= .asc

=0A
 ------=_20131211131622000000_92675-- From benl@google.com Wed Dec 11 10:33:06 2013 Return-Path: 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 38AA61AC4C5 for ; Wed, 11 Dec 2013 10:33:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.38 X-Spam-Level: X-Spam-Status: No, score=-1.38 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 mMMJ5bHEQOAN for ; Wed, 11 Dec 2013 10:33:05 -0800 (PST) Received: from mail-vc0-x22c.google.com (mail-vc0-x22c.google.com [IPv6:2607:f8b0:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 2873D1AE07B for ; Wed, 11 Dec 2013 10:33:05 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id ij19so4068892vcb.17 for ; Wed, 11 Dec 2013 10:32:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=ni5C9w+7qny63dmRG3PiuwWWKhBpBoarH/hWJ1h/b68=; b=f9/WsxsGYTLyqaMiybL9VEJuBkY5Db6jXVCbK6mg04JUr1MGiQVy4z6FGproF28uXk TT50v/UL8C6TneCcN82HMnr0YHTB5kD6am7XGCguTCZMcbP79sJPYonYKnQelx12AYQU j+ryAEMYGNap6lX4BS7rpYLHiC0VOMzN2mlDIBxw2IFMtaJzebB3ZlwZprTNJfKe0R+d HPjk2IhOMef7JvH5FnAmlSApKRG+05ZqJObrCvj13T5MCzx3sNynj9qpXtRBBB1klUn2 Zi0pTM3G3Qr6c3SQ6w9q6MQJg89edQLAtaMjhPQWBm2AGT9p+uS1aAr0IrLV/A4EFkRW YA2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=ni5C9w+7qny63dmRG3PiuwWWKhBpBoarH/hWJ1h/b68=; b=k4Td5j0SlLjs5/exx5GK/INXjpr/UsCwC+Zykonl97xzCEYsV9bS01POZen2+Tt001 Hgri9g6SBTq2OHaUL4Fr8AJg2RXD3ujn9QNTA8IdZ/9sBqeM5x1QU6+F3nE63NuZrkGZ w+yoOOrAZWjvvraOX2E9JsAdqFEzhrSZl7hv4i2miMQUdDehn3iHq1q0hrpTS4TNuaqM VUCl9hdBWUe9YZfBtdBNkuV0pASTd/8I7Rh55yXg7fG/02iz+fQzCqgcp5BTdm5c7w9G AVjyUJdOY9TN/zfNvgk+OBeVL+JcOba8WvF+8+LPRRrxKvKrzDC4scnyegarDRMm3soU p6TQ== X-Gm-Message-State: ALoCoQmUvMTYt2/lxxkng1yYbCmERxaXJ0/eWLaBnqxPAD3+Tnr35tnxx9GvoHDcc7+uOOsxyNiUpuhogrpWLeuqEJwYEbJviYccXu5I72Zll+pQuuvvrglJdTvayRngpCKzAC/9tnW4OXBAChJA+YOVxcuGyZqKbho684qsn4SnqvaJPTxGu8dh7dvIDFkQQ0ypouDBfEEG MIME-Version: 1.0 X-Received: by 10.52.22.40 with SMTP id a8mr943914vdf.49.1386786779345; Wed, 11 Dec 2013 10:32:59 -0800 (PST) Received: by 10.52.183.65 with HTTP; Wed, 11 Dec 2013 10:32:59 -0800 (PST) Date: Wed, 11 Dec 2013 18:32:59 +0000 Message-ID: From: Ben Laurie To: perpass , "saag@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: [perpass] Draft charter for a Transparency Working Group 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 18:33:06 -0000 http://www.ietf.org/mail-archive/web/therightkey/current/msg00680.html From dhc@dcrocker.net Wed Dec 11 10:42:37 2013 Return-Path: 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 390981AE109; Wed, 11 Dec 2013 10:42:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 hRYuw8EiFuXA; Wed, 11 Dec 2013 10:42:35 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id C3D471AE107; Wed, 11 Dec 2013 10:42:34 -0800 (PST) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id rBBIgOww008968 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 11 Dec 2013 10:42:27 -0800 Message-ID: <52A8B1D0.2080304@dcrocker.net> Date: Wed, 11 Dec 2013 10:41:20 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Ben Laurie , perpass , "saag@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Wed, 11 Dec 2013 10:42:27 -0800 (PST) Subject: Re: [perpass] Draft charter for a Transparency Working Group X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net 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: Wed, 11 Dec 2013 18:42:37 -0000 On 12/11/2013 10:32 AM, Ben Laurie wrote: > http://www.ietf.org/mail-archive/web/therightkey/current/msg00680.html The text isn't a draft charter. It's a very generic statement of an idea. Formulating that into the detail an actual charter will be helpful. The text needs to give some explanation of what is being proposed, beyond a highly cryptic label like "Cryptographically verifiable logs". A term like that could mean many things and from the message, I can't tell what is meant. The text needs to explain what sort of usage scenario is expected, with enough detail to make the scenario substantive. That permits the reader to get a sense of basic/likely relevance to operational environments. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From benl@google.com Wed Dec 11 10:53:05 2013 Return-Path: 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 E805E1AE159 for ; Wed, 11 Dec 2013 10:53:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.38 X-Spam-Level: X-Spam-Status: No, score=-1.38 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 E6WNbtky-ALO for ; Wed, 11 Dec 2013 10:53:04 -0800 (PST) Received: from mail-vc0-x234.google.com (mail-vc0-x234.google.com [IPv6:2607:f8b0:400c:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id A5F3A1ADF74 for ; Wed, 11 Dec 2013 10:53:02 -0800 (PST) Received: by mail-vc0-f180.google.com with SMTP id if17so5819436vcb.25 for ; Wed, 11 Dec 2013 10:52:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GulL1XNID9Z/onmYIilfZWVDcoTsC7wlDeqmEAr39n8=; b=IcQZGKFMS5jx63rpNl0Br7av9kdt2c+7MZVyReCdVeA3OVxnwp59Osj+FbrY/Lezqo 9RVb4V95dfrPRy5z+nbiBpdaiwt2kMuEJvOY5DPgCULjeRS2SEnQ8Hul1x+dFMxheEyG M0rBPhOsZZjQ+9tIA78NF1FX/yo32sbEPB/sNegJ76PwaZr9ogRmoUhmxWwN17lSbPq5 ioZA3QZJr/BJWbVsr46angHrR5xzuYowvWeWe2sava4lOwMLjhae7jkzBKcRyiD08u5x eY+WOVxbwahjSIlhEhkXy9JfInVOLV1c/GJftt4gnLil9aGFm5UAhi1R5erMpxuYz06e X51Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=GulL1XNID9Z/onmYIilfZWVDcoTsC7wlDeqmEAr39n8=; b=bK8rgsG/RQWmtlGC+YZ1OaeukEUyLTtaOxySwA9WqA+ESRhIrYXo9rm4VP8cXBOLx2 ADdfaNEA4FxJpgpLHXZ0Lk5Kv0Kj2b5loUR65zoVYadkXEfKh0wStY4H94vrI6NNtmaI 7yjJ4kYlNI3LOwWRzip2hJEWbZUu1a6Ce4k/DrHX5J1OHxAwPBQhqBCuCakUZbvZhVtQ 5H6uY8uNBVtBTgDdAueZmRABldiVRBuF1+YqWR/2ZuDit5/yP0fBe6MigXo2+p9VQBWM H9pbbrgIsJZAFeQ1L3e5Jd7f9myGEgdSA1W4cXktdv1VNhKSCtSZWOKR4GGPpgfZ3O/d 8jXw== X-Gm-Message-State: ALoCoQkD5kymCvnJFrBC/x1BLAM/j3DQ10cGmXqXBsDd2jyrVr0o3cHRWk5i2ffpc4gZJz7FposMhssq/vtg1Z0Dqly2Rm5z8GGalGpSsH9NDT3qL++BqdQ7t0FkuiBVjk2wVpEJHTMmvqGx2ssmk/pfg9LBV0aeepWjg8/Nhrr38Ktmead7mWDYQvBOnEKeQpIyvRFbvSO+ MIME-Version: 1.0 X-Received: by 10.52.232.135 with SMTP id to7mr633102vdc.58.1386787976907; Wed, 11 Dec 2013 10:52:56 -0800 (PST) Received: by 10.52.183.65 with HTTP; Wed, 11 Dec 2013 10:52:56 -0800 (PST) In-Reply-To: <52A8B1D0.2080304@dcrocker.net> References: <52A8B1D0.2080304@dcrocker.net> Date: Wed, 11 Dec 2013 18:52:56 +0000 Message-ID: From: Ben Laurie To: Dave Crocker Content-Type: text/plain; charset=ISO-8859-1 Cc: perpass , "saag@ietf.org" Subject: Re: [perpass] Draft charter for a Transparency Working Group 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 18:53:06 -0000 On 11 December 2013 18:41, Dave Crocker wrote: > On 12/11/2013 10:32 AM, Ben Laurie wrote: >> >> http://www.ietf.org/mail-archive/web/therightkey/current/msg00680.html > > > > The text isn't a draft charter. It's a very generic statement of an idea. > Formulating that into the detail an actual charter will be helpful. > > The text needs to give some explanation of what is being proposed, beyond a > highly cryptic label like "Cryptographically verifiable logs". A term like > that could mean many things and from the message, I can't tell what is > meant. > > The text needs to explain what sort of usage scenario is expected, with > enough detail to make the scenario substantive. That permits the reader to > get a sense of basic/likely relevance to operational environments. Am I allowed to refer to RFC 6962 for background? Reiterating what's in there doesn't seem useful. From atlunde@panix.com Wed Dec 11 11:31:31 2013 Return-Path: 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 2F41E1AE195 for ; Wed, 11 Dec 2013 11:31:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 5jy0_7oJRDek for ; Wed, 11 Dec 2013 11:31:29 -0800 (PST) Received: from mailbackend.panix.com (mailbackend.panix.com [166.84.1.89]) by ietfa.amsl.com (Postfix) with ESMTP id 14E3A1AE15B for ; Wed, 11 Dec 2013 11:31:28 -0800 (PST) Received: from [192.168.15.3] (unknown [50.9.9.201]) by mailbackend.panix.com (Postfix) with ESMTP id E19DE35956; Wed, 11 Dec 2013 14:31:22 -0500 (EST) Message-ID: <52A8BD80.4070603@panix.com> Date: Wed, 11 Dec 2013 13:31:12 -0600 From: Albert Lunde User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: perpass References: <44FFE527-F884-4E29-BA29-167CF909F78D@mnot.net> In-Reply-To: <44FFE527-F884-4E29-BA29-167CF909F78D@mnot.net> X-Forwarded-Message-Id: <44FFE527-F884-4E29-BA29-167CF909F78D@mnot.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [perpass] Fwd: New Version Notification for draft-nottingham-http2-encryption-02.txt 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 19:31:31 -0000 This draft is a proposal for "opportunistic" encryption, that allows using TLS in more circumstances. My interpretations is: I don't think there's a consensus to make encryption universal, but this "lowers the bar" for deploying or using TLS more widely. -------- Original Message -------- Subject: Fwd: New Version Notification for draft-nottingham-http2-encryption-02.txt Resent-Date: Wed, 11 Dec 2013 04:20:10 +0000 Resent-From: ietf-http-wg@w3.org Date: Wed, 11 Dec 2013 15:19:11 +1100 From: Mark Nottingham To: HTTP Working Group FYI. Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for draft-nottingham-http2-encryption-02.txt > Date: 11 December 2013 3:18:55 pm AEDT > To: Mark Nottingham > > > A new version of I-D, draft-nottingham-http2-encryption-02.txt > has been successfully submitted by Mark Nottingham and posted to the > IETF repository. > > Filename: draft-nottingham-http2-encryption > Revision: 02 > Title: Opportunistic Encryption for HTTP URIs > Creation date: 2013-12-11 > Group: Individual Submission > Number of pages: 10 > URL: http://www.ietf.org/internet-drafts/draft-nottingham-http2-encryption-02.txt > Status: http://datatracker.ietf.org/doc/draft-nottingham-http2-encryption > Htmlized: http://tools.ietf.org/html/draft-nottingham-http2-encryption-02 > Diff: http://www.ietf.org/rfcdiff?url2=draft-nottingham-http2-encryption-02 > > Abstract: > This document proposes two changes to HTTP/2.0; first, it suggests > using ALPN Protocol Identifies to identify the specific stack of > protocols in use, including TLS, and second, it proposes a way to > opportunistically encrypt HTTP/2.0 using TLS for HTTP URIs. > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > -- Mark Nottingham http://www.mnot.net/ From nweaver@icsi.berkeley.edu Wed Dec 11 11:44:49 2013 Return-Path: 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 E80B31AE1DB for ; Wed, 11 Dec 2013 11:44:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 M2-EkkvN66qv for ; Wed, 11 Dec 2013 11:44:48 -0800 (PST) Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id 433351AE1A3 for ; Wed, 11 Dec 2013 11:44:48 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id E90272C403B; Wed, 11 Dec 2013 11:44:42 -0800 (PST) X-Virus-Scanned: amavisd-new at ICSI.Berkeley.EDU Received: from rock.ICSI.Berkeley.EDU ([127.0.0.1]) by localhost (maihub.ICSI.Berkeley.EDU [127.0.0.1]) (amavisd-new, port 10024) with LMTP id rRI+Jgu+FKuf; Wed, 11 Dec 2013 11:44:42 -0800 (PST) Received: from gala.icir.org (gala.icir.org [192.150.187.130]) (Authenticated sender: nweaver) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 6F2302C4003; Wed, 11 Dec 2013 11:44:42 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Content-Type: multipart/signed; boundary="Apple-Mail=_AB38F92F-BD92-4CB9-BFE2-5E18068278C9"; protocol="application/pgp-signature"; micalg=pgp-sha512 From: Nicholas Weaver X-Priority: 3 (Normal) In-Reply-To: <1386785782.584816710@apps.rackspace.com> Date: Wed, 11 Dec 2013 11:44:41 -0800 Message-Id: <7E5F9EAE-053F-46BF-A47A-E66CFC74CEB8@icsi.berkeley.edu> References: <0932E601-895B-457B-9F2D-DD79626AE0F0@icsi.berkeley.edu> <1386785782.584816710@apps.rackspace.com> To: wilton@isoc.org X-Mailer: Apple Mail (2.1510) Cc: perpass , Nicholas Weaver Subject: Re: [perpass] Yet Another Reason why ALL CLEARTEXT MUST BE ELIMINATED! 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 19:44:50 -0000 --Apple-Mail=_AB38F92F-BD92-4CB9-BFE2-5E18068278C9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Dec 11, 2013, at 10:16 AM, wilton@isoc.org wrote: > And this time *with* the link... I hate it when I do that. > http://webpolicy.org/2013/12/09/metaphone-the-nsa-three-hop/ > Robin Everyone on this group should be considered within the "3 hop" rule. Edward Snowden <-> Various Reporters And Others I've Identified <-> Me = <-> You all. Enjoy. -- Nicholas Weaver it is a tale, told by an idiot, nweaver@icsi.berkeley.edu full of sound and fury, 510-666-2903 .signifying nothing PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc --Apple-Mail=_AB38F92F-BD92-4CB9-BFE2-5E18068278C9 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCgAGBQJSqMCpAAoJEG2B1w+SDi/usKkP/jg08xhthXg6u8XsXh+ShZkD 7babN+dSgKcyDmj5//1hT3JPbMmrG2mEUBcYFM7Ga9j/w+QuQoAcYlIEilweDnj3 vkSjAFLt+XVYZd/PxVDItupAVZGilZhufZRexi/XTHUKGHI4iZmZv6+cbCJieNM9 VQeVGhnBifEQPN/Zd3ApF1W0RDzaH0snCUgfzxWqXYXHQ0DSJYrRytMWVVW7Oacq tUsNXR3khzRvLVGDvVWg7p5KEh8+Ndq9B2UMH81lEX3m+d8EcWzBzhpz8OLmpCXJ 5wtx39Nuq7VfiObrINwOdr2C5Ob67CUK/TZlRnZrCln58Yk+g8iYJtW2QqH+KJPn Aemw/Uem7rhtTv0DpBZuxA/QsJRmoDtJ23PfrId4KBZq8teuxjlMj5GcfIdJugWv BvqFyaDCTQGbj1qJiS3TitGI9OVwCIN7jC47dnaTXX300dJio42iBzkKbOuQu4f7 xrRV9mijqkswYswN988l3SRC7Vcyx1mimEO1OZYPEgtTyM39Dc/hZorauw6EjV/e eYGtgBYJ0HevRkRjuHuFxUiEAFqN4mtPGa3lYb1MZJLTSufNxmq4sF0rDtmoCEx9 MZR1HvHJCCWw9E+9ZfZS2aPUwydK7zKj8RwJyya9bvccuJuAkxtc12lGOS5jflJ5 K4XQRM1i1FtevODitcBz =hmQx -----END PGP SIGNATURE----- --Apple-Mail=_AB38F92F-BD92-4CB9-BFE2-5E18068278C9-- From martin@millnert.se Wed Dec 11 12:21:08 2013 Return-Path: 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 AD0001AE036 for ; Wed, 11 Dec 2013 12:21:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.693 X-Spam-Level: X-Spam-Status: No, score=0.693 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_EQ_SE=0.35, RDNS_NONE=0.793, SPF_PASS=-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 sybNv_jQiCcm for ; Wed, 11 Dec 2013 12:21:07 -0800 (PST) Received: from mail.millnert.se (unknown [95.80.32.84]) by ietfa.amsl.com (Postfix) with ESMTP id 03DF11ADFD6 for ; Wed, 11 Dec 2013 12:21:06 -0800 (PST) Received: from [192.168.120.241] (dynamic.1.9.c0255cb5b480.f46d4e0fc2a.afb.bredband2.com [31.208.64.196]) by mail.millnert.se (Postfix) with ESMTPSA id AB98F135; Wed, 11 Dec 2013 21:23:45 +0100 (CET) Message-ID: <1386793256.7652.31.camel@pishuli.lund.millnert.se> From: Martin Millnert To: Nicholas Weaver Date: Wed, 11 Dec 2013 21:20:56 +0100 In-Reply-To: <7E5F9EAE-053F-46BF-A47A-E66CFC74CEB8@icsi.berkeley.edu> References: <0932E601-895B-457B-9F2D-DD79626AE0F0@icsi.berkeley.edu> <1386785782.584816710@apps.rackspace.com> <7E5F9EAE-053F-46BF-A47A-E66CFC74CEB8@icsi.berkeley.edu> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-deW3yuI8e/SKcSR36cWV" X-Mailer: Evolution 3.4.4-3 Mime-Version: 1.0 Cc: wilton@isoc.org, perpass Subject: Re: [perpass] Yet Another Reason why ALL CLEARTEXT MUST BE ELIMINATED! 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 20:21:08 -0000 --=-deW3yuI8e/SKcSR36cWV Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 2013-12-11 at 11:44 -0800, Nicholas Weaver wrote: > On Dec 11, 2013, at 10:16 AM, wilton@isoc.org wrote: >=20 > > And this time *with* the link... I hate it when I do that. > > http://webpolicy.org/2013/12/09/metaphone-the-nsa-three-hop/ > > Robin >=20 > Everyone on this group should be considered within the "3 hop" rule. >=20 > Edward Snowden <-> Various Reporters And Others I've Identified <-> Me <-= > You all. >=20 > Enjoy. Two hop is actually sufficient, since Jake's participating here. :-) Regards, Martin --=-deW3yuI8e/SKcSR36cWV Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAABAgAGBQJSqMkoAAoJEKgraNdZrwxM5fkP/iQNzuwTHsQsvTXw38LK2XUS cA4b0UpyiS7EePj1plWiRxZ0ArQLULXTAfUdeFaUAi3YcvK6Hf9tUp4LMIwZJWDC P1Okq2iu1jC8iVyxbBDB7K/qLy5lo51nW22zJQGKWXn4u9dfLUm4fertdIGUMfsW 6KJW9gwjCDitoFpjzpQ+i5x8iTE3DQtstNk+HAXUvniVXV5dtOESBPp5rPKi4ttH EwOTHbT+g6BWH7is6s3nOmuWw5I6rFi0KBghRDpger+uXeYb2SaBtS2kIJv07cBI TUk1bctLTauFB6bEpgEmAxoWl+wzPj+QJYp//+rQ5upVohrp/dArMr0th2p0QlaR PCFqeiRa2g5x62cqHVVW6R9gF67JZeWJ7wj5HGrEMzWcnofMLAe37LIgWUCjkWm5 iijNPZLxgie4XDNJtXdYx5o3s0VYxD/CASt4KRNfL00eXneKh0NpHcoJO26NstBI KCoINX3dyqqXZ8qV4G2CojZacwES8Nnkx1YTgj0pTPVKSW7VEtI8RrES/cayNesV ie1hsbxZULXB3VSASI91Sn5BIuJEiq89EgcDiXSNsOnKhEBZKnPzVa93r0SWbcfa 4JIbfRYycj1mWuGXM1qR2eWlSNv5X01eQCttyAI/foQg+pj4CgyLjj3Y7khRpWPT i9e3ktrshwtWgGlIYCHG =mMUK -----END PGP SIGNATURE----- --=-deW3yuI8e/SKcSR36cWV-- From hallam@gmail.com Wed Dec 11 13:50:17 2013 Return-Path: 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 2B5C61AE12D; Wed, 11 Dec 2013 13:50:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 KlNblSQJCldC; Wed, 11 Dec 2013 13:50:15 -0800 (PST) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 6D26B1AE11B; Wed, 11 Dec 2013 13:50:15 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id w62so7213185wes.3 for ; Wed, 11 Dec 2013 13:50:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=YdmJWSnNncl1loJeB6cYYWy3ycRbKGb3wgMVHc7zTSQ=; b=l5u3y8o3tMR/x32hBwc1tC7ZWp5JzF6/0GnxReCWqDdfxKS6VJez+uSb7d/ZxGyY7O BmI2tF9hgtIaJLEI792qJPo/qmRbnwpOzx0pllOVQ5YilByCE3zORvtlfIxazuL4/RfO cYG1fFBD0s99r+jun8jcI9AGFZCFazeOXFM+HHkBlbJi9F6by8hPAXyV9mNVgjM6WJ4w iFF1BEGKPUNtT3i6nazgK+79qB3JfoZ77xyb5xgExeDjF+8ic+xRHwFRy/GIQ0XreO9j uw5kSnSfTbCzGxiUoIFZH60zGACK3BDd/Yn3tIRLCuWMj0NVcvmjX7HKNraN7ZpVZWPg 1L7A== MIME-Version: 1.0 X-Received: by 10.194.11.38 with SMTP id n6mr3357557wjb.25.1386798609207; Wed, 11 Dec 2013 13:50:09 -0800 (PST) Received: by 10.194.243.136 with HTTP; Wed, 11 Dec 2013 13:50:08 -0800 (PST) In-Reply-To: References: <52A8B1D0.2080304@dcrocker.net> Date: Wed, 11 Dec 2013 16:50:08 -0500 Message-ID: From: Phillip Hallam-Baker To: Ben Laurie Content-Type: multipart/alternative; boundary=047d7b5d57107a377504ed4936fc Cc: perpass , Dave Crocker , "saag@ietf.org" Subject: Re: [perpass] Draft charter for a Transparency Working Group 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 21:50:17 -0000 --047d7b5d57107a377504ed4936fc Content-Type: text/plain; charset=ISO-8859-1 On Wed, Dec 11, 2013 at 1:52 PM, Ben Laurie wrote: > On 11 December 2013 18:41, Dave Crocker wrote: > > On 12/11/2013 10:32 AM, Ben Laurie wrote: > >> > >> http://www.ietf.org/mail-archive/web/therightkey/current/msg00680.html > > > > > > > > The text isn't a draft charter. It's a very generic statement of an > idea. > > Formulating that into the detail an actual charter will be helpful. > > > > The text needs to give some explanation of what is being proposed, > beyond a > > highly cryptic label like "Cryptographically verifiable logs". A term > like > > that could mean many things and from the message, I can't tell what is > > meant. > > > > The text needs to explain what sort of usage scenario is expected, with > > enough detail to make the scenario substantive. That permits the reader > to > > get a sense of basic/likely relevance to operational environments. > > Am I allowed to refer to RFC 6962 for background? > > Reiterating what's in there doesn't seem useful. Well how far do we want the group to be allowed to stray from RFC 6962? One approach would be to divide the problem up into two parts: * An append only log that provides a cryptographic assurance of integrity that is independent of the trustworthiness of the log maintainer from the time of the last checkpoint. * Application of the above to the specific use cases Initial use cases that the WG agreed to deliver might be * PKIX certificate signing certificates * PKIX TLS end entity certificates Use cases that are in scope but without a delivery undertaking might be OpenPGP, S/MIME, etc. -- Website: http://hallambaker.com/ --047d7b5d57107a377504ed4936fc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Dec 11, 2013 at 1:52 PM, Ben Laurie <<= a href=3D"mailto:benl@google.com" target=3D"_blank">benl@google.com>= wrote:
On 11 December 2013 18:41,= Dave Crocker <dhc@dcrocker.net&= gt; wrote:
> On 12/11/2013 10:32 AM, Ben Laurie wrote:
>>
>> http://www.ietf.org/mail-archive/web/the= rightkey/current/msg00680.html
>
>
>
> The text isn't a draft charter. =A0It's a very generic stateme= nt of an idea.
> Formulating that into the detail an actual charter will be helpful. >
> The text needs to give some explanation of what is being proposed, bey= ond a
> highly cryptic label like "Cryptographically verifiable logs"= ;. =A0A term like
> that could mean many things and from the message, I can't tell wha= t is
> meant.
>
> The text needs to explain what sort of usage scenario is expected, wit= h
> enough detail to make the scenario substantive. =A0That permits the re= ader to
> get a sense of basic/likely relevance to operational environments.

Am I allowed to refer to RFC 6962 for background?

Reiterating what's in there doesn't seem useful.
<= br>
Well how far do we want the group to be allowed to stray from= RFC 6962?

One approach would be to divide the pro= blem up into two parts:

* An append only log that provides a cryptographic assu= rance of integrity that is independent of the trustworthiness of the log ma= intainer from the time of the last checkpoint.

* Application of the above to the specific use cases

Initial use cases that the WG agreed to deliver might be
<= br>
* PKIX certificate signing certificates
* PKIX TLS = end entity certificates

Use cases that are in scope but without a delivery unde= rtaking might be OpenPGP, S/MIME, etc.


<= div>

--
Website: http://hallambaker.com/
--047d7b5d57107a377504ed4936fc-- From benl@google.com Wed Dec 11 13:57:02 2013 Return-Path: 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 D90971AE0DE for ; Wed, 11 Dec 2013 13:57:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.38 X-Spam-Level: X-Spam-Status: No, score=-1.38 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 78a4dIgkY57I for ; Wed, 11 Dec 2013 13:57:01 -0800 (PST) Received: from mail-vc0-x229.google.com (mail-vc0-x229.google.com [IPv6:2607:f8b0:400c:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 7ABD51AE06B for ; Wed, 11 Dec 2013 13:57:01 -0800 (PST) Received: by mail-vc0-f169.google.com with SMTP id hu19so6229063vcb.0 for ; Wed, 11 Dec 2013 13:56:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=h0eD1n/qbWAHOSFWMo/Tt3zemr505xe+E8q27A830Z8=; b=DvNUodh/H4kR/LMKCyQL4cYDSTuXA3LLOJeWEmJmLahgygcud/S9MwYB6A5VJDNb8+ qDghJo7aSOgoBipIvhwD6IASMr+EWyT234LfZdj2MkjWxNk2Iigi4EG4KxSmOM/dSCbe b90Lk5x7x6GzWwnUbVTYm0wwOp3aWrGtEixN7pvEf+NQ8btjApsu4KU2LCtRJeF/dVsP 04cGDXGb8pdnWnwHWRLrZlageBYG960E0pTmgxpVIRrHYwqGZJUkxGoGnqYgOGsTUvGu UxkCaVYFuG9aYiCygNO490VWHF+huz3+Cf3d/Be4aHGjeDGiTx3Un6RKQU6K2fMwfRdI YrfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=h0eD1n/qbWAHOSFWMo/Tt3zemr505xe+E8q27A830Z8=; b=FTSA8ECP2Qt/p2sEnsM2cTmhxAIJcWBDiagamM+ST7u+P0Bt6OcnM0Q9wfQD6n1QIm 0OeVkOFRhYcsT8QSeL19VM7y0EI0va2Qf4gtA3TfYxlsfSMQqOTe1RbNuV188Yb2W0gB zpnh0OtL3PCU7AKKM913PiJ/qH+E9W/obf/5INXogChBP8YaNiqa1tmsRowuE1Mb2whO 2/7J1OBKjZuXonqKcPTdnXbXTnWcjNUNvu4b8Bs5aE+RSPa4Yapl5m63qjOt7lognhKf y4SkUVvi/xdAbWDcMRxOZaxlLKn8OJvotytokFhEEWcSetXae0FBEpYwfMNe+wsNNPOH vhZg== X-Gm-Message-State: ALoCoQkQVWLwXZLtVIF8l/BFbSqKx+i+BmJubyB09A7GdBDa7o8rd5vgffGMqwBByY/w3rWeyjEScRHytEbuxtuIE9mznOOAeE+irBHUlX1Bwjc4yNu+fXQ7U4Tu2EMfJuRZJdNRTjRcHuhLwN48L1gxoIS3OOu4BBUwLmqJoTJHSfQApgncBS4KRbFy2YP8MjIL5B7YmY8L MIME-Version: 1.0 X-Received: by 10.221.64.17 with SMTP id xg17mr1589166vcb.5.1386799015491; Wed, 11 Dec 2013 13:56:55 -0800 (PST) Received: by 10.52.183.65 with HTTP; Wed, 11 Dec 2013 13:56:55 -0800 (PST) In-Reply-To: References: <52A8B1D0.2080304@dcrocker.net> Date: Wed, 11 Dec 2013 21:56:55 +0000 Message-ID: From: Ben Laurie To: Phillip Hallam-Baker Content-Type: text/plain; charset=ISO-8859-1 Cc: perpass , Dave Crocker , "saag@ietf.org" Subject: Re: [perpass] Draft charter for a Transparency Working Group 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 21:57:03 -0000 On 11 December 2013 21:50, Phillip Hallam-Baker wrote: > > > > On Wed, Dec 11, 2013 at 1:52 PM, Ben Laurie wrote: >> >> On 11 December 2013 18:41, Dave Crocker wrote: >> > On 12/11/2013 10:32 AM, Ben Laurie wrote: >> >> >> >> http://www.ietf.org/mail-archive/web/therightkey/current/msg00680.html >> > >> > >> > >> > The text isn't a draft charter. It's a very generic statement of an >> > idea. >> > Formulating that into the detail an actual charter will be helpful. >> > >> > The text needs to give some explanation of what is being proposed, >> > beyond a >> > highly cryptic label like "Cryptographically verifiable logs". A term >> > like >> > that could mean many things and from the message, I can't tell what is >> > meant. >> > >> > The text needs to explain what sort of usage scenario is expected, with >> > enough detail to make the scenario substantive. That permits the reader >> > to >> > get a sense of basic/likely relevance to operational environments. >> >> Am I allowed to refer to RFC 6962 for background? >> >> Reiterating what's in there doesn't seem useful. > > > Well how far do we want the group to be allowed to stray from RFC 6962? > > One approach would be to divide the problem up into two parts: > > * An append only log that provides a cryptographic assurance of integrity > that is independent of the trustworthiness of the log maintainer from the > time of the last checkpoint. > > * Application of the above to the specific use cases > > Initial use cases that the WG agreed to deliver might be > > * PKIX certificate signing certificates > * PKIX TLS end entity certificates > > Use cases that are in scope but without a delivery undertaking might be > OpenPGP, S/MIME, etc. Agree, I just want to be able to refer to 6962 for what "cryptographically verifiable log" means. From dhc@dcrocker.net Wed Dec 11 14:03:31 2013 Return-Path: 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 6A2D81ADEBB; Wed, 11 Dec 2013 14:03:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 Kkagd7zmzJyZ; Wed, 11 Dec 2013 14:03:30 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 78EB61ADDBD; Wed, 11 Dec 2013 14:03:30 -0800 (PST) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id rBBM3Kh6012986 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 11 Dec 2013 14:03:23 -0800 Message-ID: <52A8E0E9.5020409@dcrocker.net> Date: Wed, 11 Dec 2013 14:02:17 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Ben Laurie References: <52A8B1D0.2080304@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Wed, 11 Dec 2013 14:03:24 -0800 (PST) Cc: perpass , "saag@ietf.org" Subject: Re: [perpass] Draft charter for a Transparency Working Group X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net 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: Wed, 11 Dec 2013 22:03:31 -0000 On 12/11/2013 1:56 PM, Ben Laurie wrote: > Agree, I just want to be able to refer to 6962 for what > "cryptographically verifiable log" means. Being able to cite a doc that defines the term is always nice; so yes, please do cite freely. My own view is that charters need to have some pedagogy, since one goal of a charter is to explain the work to folk who might get involved (eventually). While a citation is formally sufficient, it's not the best pedagogy. So I tend to prefer to have a charter be somewhat self-explanatory about its basic constructs, unless they are already very well established in industry. In this case, I think what you mean is /not/ obvious to a reader who is not already immersed in the topic. So some sort of superficial explanation would help, with the citation pointing the reader to the deeper discussion. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From doug.mtview@gmail.com Wed Dec 11 15:48:42 2013 Return-Path: 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 AC7781AE17D; Wed, 11 Dec 2013 15:48:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 zYU1zYu_rwi0; Wed, 11 Dec 2013 15:48:41 -0800 (PST) Received: from mail-pb0-x236.google.com (mail-pb0-x236.google.com [IPv6:2607:f8b0:400e:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 067F91AE154; Wed, 11 Dec 2013 15:48:40 -0800 (PST) Received: by mail-pb0-f54.google.com with SMTP id un15so11002308pbc.27 for ; Wed, 11 Dec 2013 15:48:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=g/uFLdeCHwhqZ8DsOtxNEZEoVwDWI/zhDaLnFcmteis=; b=jxXU35zKeppK8OXLpjIao/e+A19HPUrAo0rvUXtnqirCPIy/rilU5uorNGIk0Qh219 Ae+pkUbPJm6WXdGtxSdA5cHOELrVz2rSDGdx4B/cZiSapsm9zfEV6OA4S3OHIsKx1OzC h0KI9Vn6R/4w7iFWxL6cdZ0JKCCy+rUx5ftL652VxRuwKBoOLTgjfPttcVeiOlluINMi RzVhwvmoBie5hLRKcFXCzxymAo9H9ABF0VBBDVLjPNf4k6q/KHuBydpLMgco/fuOiKF0 MN1PE3M4RkvmnNfzkDUTuwKFUpAQOqK6tkRfaSWafOsDimvlMKsjwgk5g9btmskOCjP9 tkQQ== X-Received: by 10.68.236.133 with SMTP id uu5mr5836245pbc.153.1386805715350; Wed, 11 Dec 2013 15:48:35 -0800 (PST) Received: from [192.168.0.54] (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id hw10sm35438286pbc.24.2013.12.11.15.48.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 11 Dec 2013 15:48:34 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_7668D34D-229A-4CED-916E-7CD7BBF2477B" Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Douglas Otis In-Reply-To: Date: Wed, 11 Dec 2013 15:48:31 -0800 Message-Id: References: <52A8B1D0.2080304@dcrocker.net> To: Ben Laurie X-Mailer: Apple Mail (2.1822) Cc: perpass , Phillip Hallam-Baker , Dave Crocker , "saag@ietf.org" Subject: Re: [perpass] Draft charter for a Transparency Working Group 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 23:48:42 -0000 --Apple-Mail=_7668D34D-229A-4CED-916E-7CD7BBF2477B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Dec 11, 2013, at 1:56 PM, Ben Laurie wrote: > Agree, I just want to be able to refer to 6962 for what > "cryptographically verifiable log" means. Dear Ben, There was an eXtensible Access Method, XAM, developed by SNIA. This = permitted vendors a means to implement strategies for handling massive = amounts of data in a manner called Content Addressable Storage, such as = EMC^2's Centera product. The data blobs create multiple secure hashes = that act within a standardized label. The blobs are combined with = timestamps and XML MIME tags. This removes a need for difficult to = manage file hierarchy. One of the benefits of this scheme is data can = not change without detection. SNIA now seems focused on identifying individuals. Perhaps this is an = outgrowth of their data-deduplication? http://www.snia.org/tech_activities/standards/curr_standards/xam Regards, Douglas Otis --Apple-Mail=_7668D34D-229A-4CED-916E-7CD7BBF2477B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Dec 11, 2013, at 1:56 PM, = Ben Laurie <benl@google.com> = wrote:

Agree, I just want to be able to = refer to 6962 for what
"cryptographically verifiable log" = means.

Dear Ben,

There = was an eXtensible Access Method, XAM, developed by SNIA.  This = permitted vendors a means to implement strategies for handling massive = amounts of data in a manner called Content Addressable Storage, such as = EMC^2's Centera product. The data blobs create multiple secure hashes = that act within a standardized label. The blobs are combined with = timestamps and XML MIME tags. This removes a need for difficult to = manage file hierarchy.  One of the benefits of this scheme is data = can not change without detection.

SNIA now = seems focused on identifying individuals.  Perhaps this is an = outgrowth of their data-deduplication?
=

Regards,
Douglas = Otis



<= /html>= --Apple-Mail=_7668D34D-229A-4CED-916E-7CD7BBF2477B-- From huitema@huitema.net Wed Dec 11 20:44:27 2013 Return-Path: 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 A07D21AE009 for ; Wed, 11 Dec 2013 20:44:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001] 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 Yah6HVvapjDY for ; Wed, 11 Dec 2013 20:44:26 -0800 (PST) Received: from xsmtp03.mail2web.com (xsmtp23.mail2web.com [168.144.250.186]) by ietfa.amsl.com (Postfix) with ESMTP id 051561AE00F for ; Wed, 11 Dec 2013 20:44:26 -0800 (PST) Received: from [10.5.2.52] (helo=xmail12.myhosting.com) by xsmtp03.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1Vqy8I-00081L-Lz for perpass@ietf.org; Wed, 11 Dec 2013 23:44:19 -0500 Received: (qmail 9398 invoked from network); 12 Dec 2013 04:44:17 -0000 Received: from unknown (HELO HUITEMA5) (Authenticated-user:_huitema@huitema.net@[24.16.156.113]) (envelope-sender ) by xmail12.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 12 Dec 2013 04:44:17 -0000 From: "Christian Huitema" To: "'Nicholas Weaver'" , "'perpass'" References: <0932E601-895B-457B-9F2D-DD79626AE0F0@icsi.berkeley.edu> In-Reply-To: <0932E601-895B-457B-9F2D-DD79626AE0F0@icsi.berkeley.edu> Date: Wed, 11 Dec 2013 20:44:16 -0800 Message-ID: <001601cef6f4$d0f84df0$72e8e9d0$@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQJ263E1zdoccH5QFLMtPiSsSJg56JkADFEA Content-Language: en-us Subject: Re: [perpass] Yet Another Reason why ALL CLEARTEXT MUST BE ELIMINATED! 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2013 04:44:27 -0000 > Cookies and user tracking are wonderful things. If you are a = intelligence service, that is. We actually described that attack in draft-trammell-perpass-ppa-01, = which we submitted last month: 4.3.5. Tracking address use with web cookies Many web sites only encrypt a small fraction of their transactions. A popular pattern was to use HTTPS for the login information, and then use a "cookie" to associate following clear-text transactions with the user's identity. Cookies are also used by various advertisement services to quickly identify the users and serve them with "personalized" advertisements. Such cookies are particularly useful if the advertisement services want to keep tracking the user across multiple sessions that may use different IP addresses. As cookies are sent in clear text, a PPA can build a database that associates cookies to IP addresses for non-HTTPS traffic. If the IP address is already identified, the cookie can be linked to the user identify. After that, if the same cookie appears on a new IP address, the new IP address can be immediately associated with the pre-determined identity. Your analysis goes one step further, linking cookies to active attacks. = We only considered "pervasive passive attacks" in the problem statement, = but it is pretty clear that we want to also consider the active attacks. = Packet injection can act as an efficiency multiplier on top of the = passive monitoring. In any case, it is pretty clear that if a connection carries identifying = data such as cookies, then it should be encrypted. Alternately, we may = want to convince browser developers to allow a privacy setting "no = cookies in clear text." -- Christian Huitema From jacob@appelbaum.net Thu Dec 12 02:44:59 2013 Return-Path: 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 02B431AE05B for ; Thu, 12 Dec 2013 02:44:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.6 X-Spam-Level: X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FSL_HELO_BARE_IP_2=2, RCVD_IN_DNSWL_LOW=-0.7] 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 BnGdriTJfGdo for ; Thu, 12 Dec 2013 02:44:57 -0800 (PST) Received: from mail-qe0-f46.google.com (mail-qe0-f46.google.com [209.85.128.46]) by ietfa.amsl.com (Postfix) with ESMTP id 8D9961AE124 for ; Thu, 12 Dec 2013 02:44:57 -0800 (PST) Received: by mail-qe0-f46.google.com with SMTP id a11so136403qen.5 for ; Thu, 12 Dec 2013 02:44:51 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:mime-version:to:cc:subject :references:in-reply-to:openpgp:content-type :content-transfer-encoding; bh=si+8iOfVzpDAtem6Mg4BfLTGUTis2J9n/dQqthVD+Ak=; b=a2oVu9Xx4kEUeIlceYVjfXJNOL8MmcT0mtZHt4iHODMBGa3YJSrGGMRk44B/Nj78qU b0ZPLGTjj39iNShliY8OkB5fj08l+fI2xmhAcBV/rXztqOjscyAleWBsEvYPDPmjxMOH 0L9AiimClQR1XGiVNB1j5iejYhfpKSmorSU55+2VS1oORKQ3dmcZJlondVkp9VXZ6fOk h4Uayv5Cv3NRZuQYLV4INsdYezdOUXjjNJJfbu69NpOANCIosgKNJ/H1BPazxIzSAa7z lit0M2S+diblvkM4gXgk7gJfKqB+3RJS3qw96eRdYeKPW1WGpRyjjH979WIz4sZD+WE+ yQcg== X-Gm-Message-State: ALoCoQmVg5r8ArMi5tzJv342Hvs9l/Qwbm27vLY2Kbs52jMeXPe4rM0I1/w79SfNc1DSWDVUUmig X-Received: by 10.49.38.37 with SMTP id d5mr11805358qek.17.1386845091393; Thu, 12 Dec 2013 02:44:51 -0800 (PST) Received: from 127.0.0.1 (cs-tor.bu.edu. [204.8.156.142]) by mx.google.com with ESMTPSA id ki4sm62373223qeb.0.2013.12.12.02.44.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 12 Dec 2013 02:44:50 -0800 (PST) Message-ID: <52A98BF0.2080804@appelbaum.net> Date: Thu, 12 Dec 2013 10:12:00 +0000 From: Jacob Appelbaum MIME-Version: 1.0 To: Martin Millnert References: <0932E601-895B-457B-9F2D-DD79626AE0F0@icsi.berkeley.edu> <1386785782.584816710@apps.rackspace.com> <7E5F9EAE-053F-46BF-A47A-E66CFC74CEB8@icsi.berkeley.edu> <1386793256.7652.31.camel@pishuli.lund.millnert.se> In-Reply-To: <1386793256.7652.31.camel@pishuli.lund.millnert.se> OpenPGP: id=4193A197 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: wilton@isoc.org, perpass , Nicholas Weaver Subject: Re: [perpass] Yet Another Reason why ALL CLEARTEXT MUST BE ELIMINATED! 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2013 10:44:59 -0000 Martin Millnert: > On Wed, 2013-12-11 at 11:44 -0800, Nicholas Weaver wrote: >> On Dec 11, 2013, at 10:16 AM, wilton@isoc.org wrote: >> >>> And this time *with* the link... I hate it when I do that. >>> http://webpolicy.org/2013/12/09/metaphone-the-nsa-three-hop/ >>> Robin >> >> Everyone on this group should be considered within the "3 hop" rule. >> >> Edward Snowden <-> Various Reporters And Others I've Identified <-> Me <-> You all. >> >> Enjoy. > > Two hop is actually sufficient, since Jake's participating here. :-) > Indeed. I'm happy to have all of you in my graph - especially those who are the most stubborn and accidental supporters of decisions that increase surveillance! All the best, Jacob From benl@google.com Thu Dec 12 03:00:03 2013 Return-Path: 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 92BB61AE216 for ; Thu, 12 Dec 2013 03:00:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.38 X-Spam-Level: X-Spam-Status: No, score=-1.38 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 wBZg1mmOpT38 for ; Thu, 12 Dec 2013 03:00:02 -0800 (PST) Received: from mail-ve0-x22a.google.com (mail-ve0-x22a.google.com [IPv6:2607:f8b0:400c:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 1A05C1AE020 for ; Thu, 12 Dec 2013 03:00:02 -0800 (PST) Received: by mail-ve0-f170.google.com with SMTP id oy12so160770veb.29 for ; Thu, 12 Dec 2013 02:59:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=eacEjswDijWna5jYWqt65RIk1B5Rh7IWLNcsQxUgtH8=; b=JTW4BMkZNYr1+ntUmmrHyPbzjInbfEBMu1/wzt+7r4IoMSlTsPoVFhOh+RjoANFFhs Hudlpb3zRZfG1ikhnEVruNUSsSSSsCIjgA9By8o1Y3PIZqWToNKoGDegUegcEPyP27dQ wJ+/h8WGnukZZLMtTltxgaw6Cgb6CwFEsxXp8Rx8WGK0CIj7duPZwLUB6M9farX11+aO lXGCXb3D4Yy8zhL0ACRozevkZaofDC4Wh7Vn+WMXIE8EPN3xhCnl+VhR/nM1D8uLM0TT 2nTGAY6G+KTDZaUoOXatfOAa/BsLM/IuhQbTmfzjOiTR/Vw1rEIWeiXifNi1Y4DxchUZ x8IQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=eacEjswDijWna5jYWqt65RIk1B5Rh7IWLNcsQxUgtH8=; b=A7+MAiflfWum2j2VArJI5mmRD8OamUVW2Y20yb23NE6ml4Zk0wCO3blDYpNU8suI+o 0KSbUvkH1nYdUYKetkUFZvAe61udrcfpZF+xXeUmznQr/zyWuLMvnEZYTvoeEdc2qNW0 1YjpORgZ+FjnFvS6QeBTq0vmoRpaslo1G8UtdvgJLEpqYb9qFxicwYc5pwFg3QrJDjLX sWwGyPF0rZXXEn5Pqya+4/KFEDWbb72BwHk6iXRuanGefkBkGaeqLRlr69EyWHFtLQKh r87JNNP0N4TmxjfDqpyDarghYjLHY7zmDRAJ571l7alJsYkFAnc4QQI1XWg/frnlSeZe qNZQ== X-Gm-Message-State: ALoCoQnuRWoVixFFDVQBfRGQiwJ5T9bgjaibynvGIfnjTNwd2YVv0b/xOy0y7iGiCX+SmpN1gkP1UZVTdwhghRdqqSYEh0D7vLlkHhT5md3VHGN7gLBU6Oedt7XvCoy0LdWlDfaZfwCWaCCmy4/W4lNpZiQDidwOmfXefq1bm8t/ZRtovSHQ96+qdjpxHJosYOuEuuUwotsl MIME-Version: 1.0 X-Received: by 10.220.144.80 with SMTP id y16mr3265725vcu.4.1386845995978; Thu, 12 Dec 2013 02:59:55 -0800 (PST) Received: by 10.52.183.65 with HTTP; Thu, 12 Dec 2013 02:59:55 -0800 (PST) In-Reply-To: <52A8E0E9.5020409@dcrocker.net> References: <52A8B1D0.2080304@dcrocker.net> <52A8E0E9.5020409@dcrocker.net> Date: Thu, 12 Dec 2013 10:59:55 +0000 Message-ID: From: Ben Laurie To: Dave Crocker , "therightkey@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Cc: perpass , "saag@ietf.org" Subject: Re: [perpass] Draft charter for a Transparency Working Group 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2013 11:00:03 -0000 [please include therightkey on replies] On 11 December 2013 22:02, Dave Crocker wrote: > On 12/11/2013 1:56 PM, Ben Laurie wrote: >> >> Agree, I just want to be able to refer to 6962 for what >> "cryptographically verifiable log" means. > > > > Being able to cite a doc that defines the term is always nice; so yes, > please do cite freely. > > My own view is that charters need to have some pedagogy, since one goal of a > charter is to explain the work to folk who might get involved (eventually). > While a citation is formally sufficient, it's not the best pedagogy. So I > tend to prefer to have a charter be somewhat self-explanatory about its > basic constructs, unless they are already very well established in industry. > > In this case, I think what you mean is /not/ obvious to a reader who is not > already immersed in the topic. So some sort of superficial explanation > would help, with the citation pointing the reader to the deeper discussion. How about this footnote? "A cryptographically verifiable log is an append-only log of hashes of more-or-less anything that can prove its own correctness cryptographically. See RFC 6962, http://www.links.org/files/CertificateTransparencyVersion2.1a.pdf and http://www.links.org/files/RevocationTransparency.pdf for background." From benl@google.com Thu Dec 12 03:06:33 2013 Return-Path: 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 950241AE1EC for ; Thu, 12 Dec 2013 03:06:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.38 X-Spam-Level: X-Spam-Status: No, score=-1.38 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 dnL28VQKmgnW for ; Thu, 12 Dec 2013 03:06:32 -0800 (PST) Received: from mail-vc0-x229.google.com (mail-vc0-x229.google.com [IPv6:2607:f8b0:400c:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id D47AC1AE08D for ; Thu, 12 Dec 2013 03:06:31 -0800 (PST) Received: by mail-vc0-f169.google.com with SMTP id hu19so158244vcb.14 for ; Thu, 12 Dec 2013 03:06:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/C//b7RfRfNcZF3yIEQq1pZ7cT8QuUVfudAWowNhHQA=; b=mRRRGVjYYbieMZwlMMgVnohI6OphgBXVBNydg6HaRk2zL4t8GptaomJbWUhh3shq5S h9VEniux84YJinbNd2POsAWqc8aRYD73Wk50ASX37RsAGNY2DzP1nJpcZD7DqF/2WehP qpbBwyIeaRavApXdyNkgok49YZm1+zdCJcsQnJ4r8GhYC8NFyXeizMQA+jDeFwkwLHwn 15TZFTIcGmoMoVLdXekgufKn1Pm/4K7a5Q1IdncqHQr6QSmBVpSEikrAZiKQX9oe2+S5 2sQqD6cOHaAz5K8x6Iucka1UB7ImJRwEQRKNIouTqLhCDtGgQGZwXiMYy/jaXWWtCSaZ JIbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=/C//b7RfRfNcZF3yIEQq1pZ7cT8QuUVfudAWowNhHQA=; b=f75X/KxO82gY1Y15sbCalOZnFpUKUmmm5alsMFpGxkDTbiTYf9+C1mXnU+o65YcbL5 7V5+sdPkhHi0wmZTf8pXBPpdv6v4PrhoIVtPUwrltWmXxaRYGrzcG+Psmw54VtUDpM9a yiJXD+79Cl3RquBqo1SURe7WHVL8Z1EdXf7bfP+hfypuZRyGAPRV2K+Gz+t9dgvHkvu1 d2H0Gm2e+uXGVEKPfhF2OnXaq+nfNQ8d0X1CLhugEcBddHjs/hL82duW+izdP3Zqhi06 ILe7Umz8DwS84avK8P3/o70kxK0hXt49tew4dNd6fbpVeIuTGCCzXu7XhBuvi5arfNc6 fWng== X-Gm-Message-State: ALoCoQnOcYo2t7Gku9d/zmnGYoYVfJR8eSFpEEPAZ5AezX4Rghs/lgab5H9ZlFZoFKSlVpJlyfAkU43JXThcB3d8fVHGcRZ/x1o2WreTlisup+48foOOXWdtQV4r/Ly5oPlAwR7BfMWaCCtK944MlZWcMKwpSjcMLM/Dlw27TOlr8no4d+O1JsSst+tytRi8LL9BTAOM04zw MIME-Version: 1.0 X-Received: by 10.58.54.69 with SMTP id h5mr3166755vep.25.1386846385755; Thu, 12 Dec 2013 03:06:25 -0800 (PST) Received: by 10.52.183.65 with HTTP; Thu, 12 Dec 2013 03:06:25 -0800 (PST) In-Reply-To: References: <52A8B1D0.2080304@dcrocker.net> Date: Thu, 12 Dec 2013 11:06:25 +0000 Message-ID: From: Ben Laurie To: Douglas Otis Content-Type: text/plain; charset=ISO-8859-1 Cc: perpass , Phillip Hallam-Baker , Dave Crocker , "saag@ietf.org" Subject: Re: [perpass] Draft charter for a Transparency Working Group 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2013 11:06:33 -0000 On 11 December 2013 23:48, Douglas Otis wrote: > > On Dec 11, 2013, at 1:56 PM, Ben Laurie wrote: > > Agree, I just want to be able to refer to 6962 for what > "cryptographically verifiable log" means. > > > Dear Ben, > > There was an eXtensible Access Method, XAM, developed by SNIA. This > permitted vendors a means to implement strategies for handling massive > amounts of data in a manner called Content Addressable Storage, such as > EMC^2's Centera product. The data blobs create multiple secure hashes that > act within a standardized label. The blobs are combined with timestamps and > XML MIME tags. This removes a need for difficult to manage file hierarchy. > One of the benefits of this scheme is data can not change without detection. A brief romp through the spec suggests that XUIDs could be hashes, but don't have to be. In particular, identical XSets do not have to have identical XUIDs. In the case where they are hashes (or are otherwise one-to-one linked to XSets), then a transparent log might well be usefully applied to them. From wilton@isoc.org Thu Dec 12 05:45:51 2013 Return-Path: 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 2AE021AE2DA for ; Thu, 12 Dec 2013 05:45:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 OZOzXYgT0FWL for ; Thu, 12 Dec 2013 05:45:49 -0800 (PST) Received: from smtp70.iad3a.emailsrvr.com (smtp70.iad3a.emailsrvr.com [173.203.187.70]) by ietfa.amsl.com (Postfix) with ESMTP id 5791B1AE226 for ; Thu, 12 Dec 2013 05:45:49 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp9.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 714E6980CF; Thu, 12 Dec 2013 08:45:43 -0500 (EST) X-Virus-Scanned: OK Received: by smtp9.relay.iad3a.emailsrvr.com (Authenticated sender: wilton-AT-isoc.org) with ESMTPSA id 4EA54980D0; Thu, 12 Dec 2013 08:45:40 -0500 (EST) References: <0932E601-895B-457B-9F2D-DD79626AE0F0@icsi.berkeley.edu> <1386785782.584816710@apps.rackspace.com> <7E5F9EAE-053F-46BF-A47A-E66CFC74CEB8@icsi.berkeley.edu> <1386793256.7652.31.camel@pishuli.lund.millnert.se> <52A98BF0.2080804@appelbaum.net> In-Reply-To: <52A98BF0.2080804@appelbaum.net> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPad Mail (9B206) From: Robin Wilton Date: Thu, 12 Dec 2013 14:49:11 +0100 To: Jacob Appelbaum Cc: Martin Millnert , perpass , Nicholas Weaver Subject: Re: [perpass] Yet Another Reason why ALL CLEARTEXT MUST BE ELIMINATED! 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2013 13:45:51 -0000 Sounds like a call for a t-shirt to me: "I'm a Friend Of Jake: if you know me, They know you" ;^) R Robin Wilton Technical Outreach Director - Identity and Privacy On 12 Dec 2013, at 11:12, Jacob Appelbaum wrote: > Martin Millnert: >> On Wed, 2013-12-11 at 11:44 -0800, Nicholas Weaver wrote: >>> On Dec 11, 2013, at 10:16 AM, wilton@isoc.org wrote: >>>=20 >>>> And this time *with* the link... I hate it when I do that. >>>> http://webpolicy.org/2013/12/09/metaphone-the-nsa-three-hop/ >>>> Robin >>>=20 >>> Everyone on this group should be considered within the "3 hop" rule. >>>=20 >>> Edward Snowden <-> Various Reporters And Others I've Identified <-> Me <= -> You all. >>>=20 >>> Enjoy. >>=20 >> Two hop is actually sufficient, since Jake's participating here. :-) >>=20 >=20 > Indeed. I'm happy to have all of you in my graph - especially those who > are the most stubborn and accidental supporters of decisions that > increase surveillance! >=20 > All the best, > Jacob > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass From hallam@gmail.com Thu Dec 12 05:58:41 2013 Return-Path: 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 C968D1AE2CF; Thu, 12 Dec 2013 05:58:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 J7HML06Udnjv; Thu, 12 Dec 2013 05:58:38 -0800 (PST) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) by ietfa.amsl.com (Postfix) with ESMTP id 4BD0E1AE2B5; Thu, 12 Dec 2013 05:58:38 -0800 (PST) Received: by mail-wi0-f179.google.com with SMTP id z2so2512693wiv.6 for ; Thu, 12 Dec 2013 05:58:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tBFcfDpAKp4bMDkp2SeS+kWP177NdjlQx41ferR2l20=; b=ssjFnXmxC2Qvd7OtPmSoGJHCNfmhGsS7aGi6SmRXrtymheL3zirqp7czehp4rKoxWW JgxnldM9OZKnh3hk4Qxy5HTJC8vUj+hUjy6M7Ct3wGfoVXWCE1Yx5I+L9uLLrt1TQATY 7c1uRKkkD7EmAK0K9wPZknDbU6ukmxWd65oqz5ut2DPgfP7eRmm2GfPjfiNGfuTkawrf h21YIj4htTGDWWPumCfFzEl3FnKzUvBhwfWk0mxAvJj7VbaU8vUTXlHsnZz1VrXo5Tvy VFM2sRrByQJtnVdBZ+L4LenrUjK7VnOAujEk1pMXhn45A9jfkUujYT/pAvAmm8THUdLi OHXQ== MIME-Version: 1.0 X-Received: by 10.180.109.201 with SMTP id hu9mr7690708wib.59.1386856711905; Thu, 12 Dec 2013 05:58:31 -0800 (PST) Received: by 10.194.243.136 with HTTP; Thu, 12 Dec 2013 05:58:31 -0800 (PST) In-Reply-To: References: <52A8B1D0.2080304@dcrocker.net> Date: Thu, 12 Dec 2013 08:58:31 -0500 Message-ID: From: Phillip Hallam-Baker To: Ben Laurie Content-Type: multipart/alternative; boundary=e89a8f2356bdaae8fc04ed56bdf3 Cc: "saag@ietf.org" , perpass , Douglas Otis , Dave Crocker Subject: Re: [perpass] Draft charter for a Transparency Working Group 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2013 13:58:42 -0000 --e89a8f2356bdaae8fc04ed56bdf3 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Dec 12, 2013 at 6:06 AM, Ben Laurie wrote: > On 11 December 2013 23:48, Douglas Otis wrote: > > > > On Dec 11, 2013, at 1:56 PM, Ben Laurie wrote: > > > > Agree, I just want to be able to refer to 6962 for what > > "cryptographically verifiable log" means. > > > > > > Dear Ben, > > > > There was an eXtensible Access Method, XAM, developed by SNIA. This > > permitted vendors a means to implement strategies for handling massive > > amounts of data in a manner called Content Addressable Storage, such as > > EMC^2's Centera product. The data blobs create multiple secure hashes > that > > act within a standardized label. The blobs are combined with timestamps > and > > XML MIME tags. This removes a need for difficult to manage file > hierarchy. > > One of the benefits of this scheme is data can not change without > detection. > > A brief romp through the spec suggests that XUIDs could be hashes, but > don't have to be. In particular, identical XSets do not have to have > identical XUIDs. > > In the case where they are hashes (or are otherwise one-to-one linked > to XSets), then a transparent log might well be usefully applied to > them. > If we get into that area I have to point out that I am currently engaged by a client who is defending a case in which a relevant patent is being asserted. -- Website: http://hallambaker.com/ --e89a8f2356bdaae8fc04ed56bdf3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Thu, Dec 12, 2013 at 6:06 AM, Ben Laurie <<= a href=3D"mailto:benl@google.com" target=3D"_blank">benl@google.com>= wrote:
On 11 December 2013 23:48,= Douglas Otis <doug.mtview@gmai= l.com> wrote:
>
> On Dec 11, 2013, at 1:56 PM, Ben Laurie <benl@google.com> wrote:
>
> Agree, I just want to be able to refer to 6962 for what
> "cryptographically verifiable log" means.
>
>
> Dear Ben,
>
> There was an eXtensible Access Method, XAM, developed by SNIA. =A0This=
> permitted vendors a means to implement strategies for handling massive=
> amounts of data in a manner called Content Addressable Storage, such a= s
> EMC^2's Centera product. The data blobs create multiple secure has= hes that
> act within a standardized label. The blobs are combined with timestamp= s and
> XML MIME tags. This removes a need for difficult to manage file hierar= chy.
> One of the benefits of this scheme is data can not change without dete= ction.

A brief romp through the spec suggests that XUIDs could be hashes, bu= t
don't have to be. In particular, identical XSets do not have to have identical XUIDs.

In the case where they are hashes (or are otherwise one-to-one linked
to XSets), then a transparent log might well be usefully applied to
them.

If we get into that area I have to point out that I = am currently engaged by a client who is defending a case in which a relevan= t patent is being asserted.


--
Website: http://h= allambaker.com/
--e89a8f2356bdaae8fc04ed56bdf3-- From kent@bbn.com Thu Dec 12 08:36:52 2013 Return-Path: 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 6E1DA1ADFF8; Thu, 12 Dec 2013 08:36:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 fGO89yiL6ZgQ; Thu, 12 Dec 2013 08:36:50 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id BC1071ADF9A; Thu, 12 Dec 2013 08:36:50 -0800 (PST) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:54108) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Vr9Fk-00083k-Fx; Thu, 12 Dec 2013 11:36:44 -0500 Message-ID: <52A9E61C.8030300@bbn.com> Date: Thu, 12 Dec 2013 11:36:44 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: perpass@ietf.org, saag References: <52A8B1D0.2080304@dcrocker.net> <52A8E0E9.5020409@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [perpass] Draft charter for a Transparency Working Group 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2013 16:36:52 -0000 Ben > How about this footnote? > > "A cryptographically verifiable log is an append-only log of hashes of > more-or-less anything that can prove its own correctness > cryptographically. See RFC 6962, > I'd like something a bit more technical, since the phrase "prove its own correctness" is pretty general. Hopefully there is text in 6962 that you can use. Steve From dhc@dcrocker.net Thu Dec 12 08:41:49 2013 Return-Path: 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 9D18C1AE034; Thu, 12 Dec 2013 08:41:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 hSxyo1VVPNZf; Thu, 12 Dec 2013 08:41:48 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id E4BCB1ADFFE; Thu, 12 Dec 2013 08:41:47 -0800 (PST) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id rBCGfZhN029845 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 12 Dec 2013 08:41:38 -0800 Message-ID: <52A9E6FE.6060207@dcrocker.net> Date: Thu, 12 Dec 2013 08:40:30 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Stephen Kent , Ben Laurie References: <52A8B1D0.2080304@dcrocker.net> <52A8E0E9.5020409@dcrocker.net> <52A9E61C.8030300@bbn.com> In-Reply-To: <52A9E61C.8030300@bbn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Thu, 12 Dec 2013 08:41:38 -0800 (PST) Cc: perpass@ietf.org, saag Subject: Re: [perpass] Draft charter for a Transparency Working Group X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net 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: Thu, 12 Dec 2013 16:41:49 -0000 On 12/12/2013 8:36 AM, Stephen Kent wrote: > I'd like something a bit more technical, since the phrase "prove its > own correctness" is pretty general. Hopefully there is text in 6962 > that you can use. Ben, The other piece of information I'm suggesting is some text that explains how this mechanism will be used for the purpose that's claimed. Enough text to make clear why this is useful work. Although the utility might seem intuitively obvious (to some folk), having the charter make this explicit will help other readers who are less immersed in the topic. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From paul@marvell.com Thu Dec 12 08:48:43 2013 Return-Path: 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 C4A471AE028; Thu, 12 Dec 2013 08:48:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.566 X-Spam-Level: X-Spam-Status: No, score=-1.566 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, SPF_PASS=-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 Z_TCEVqsxf1X; Thu, 12 Dec 2013 08:48:42 -0800 (PST) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) by ietfa.amsl.com (Postfix) with ESMTP id 5DD0D1AD2EC; Thu, 12 Dec 2013 08:48:42 -0800 (PST) Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.14.5/8.14.5) with SMTP id rBCGmSHd019528; Thu, 12 Dec 2013 08:48:28 -0800 Received: from sc-owa.marvell.com ([199.233.58.135]) by mx0b-0016f401.pphosted.com with ESMTP id 1gpgd4n56a-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 12 Dec 2013 08:48:28 -0800 Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA.marvell.com ([::1]) with mapi; Thu, 12 Dec 2013 08:48:27 -0800 From: Paul Lambert To: Douglas Otis , Ben Laurie Date: Thu, 12 Dec 2013 08:48:26 -0800 Thread-Topic: [saag] [perpass] Draft charter for a Transparency Working Group Thread-Index: Ac73Wfrd+LJkHtEQRe2UEqFDYRYh6A== Message-ID: References: <52A8B1D0.2080304@dcrocker.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CECF27342A043paulmarvellcom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.87, 1.0.14, 0.0.0000 definitions=2013-12-12_04:2013-12-12,2013-12-12,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1312120072 X-Mailman-Approved-At: Thu, 12 Dec 2013 08:50:06 -0800 Cc: perpass , Phillip Hallam-Baker , Dave Crocker , "saag@ietf.org" Subject: Re: [perpass] [saag] Draft charter for a Transparency Working Group 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2013 16:48:44 -0000 --_000_CECF27342A043paulmarvellcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Dec 11, 2013, at 1:56 PM, Ben Laurie > wrote: Agree, I just want to be able to refer to 6962 for what "cryptographically verifiable log" means. Dear Ben, There was an eXtensible Access Method, XAM, developed by SNIA. This permit= ted vendors a means to implement strategies for handling massive amounts of= data in a manner called Content Addressable Storage, such as EMC^2's Cente= ra product. The data blobs create multiple secure hashes that act within a = standardized label. The blobs are combined with timestamps and XML MIME tag= s. This removes a need for difficult to manage file hierarchy. One of the = benefits of this scheme is data can not change without detection. Interesting =85 in IEEE we=92re defining =91services=92 as a hash/UUID-lik= e identifier https://mentor.ieee.org/802.11/dcn/12/11-12-0706-00-0isd-servi= ce-discovery-proposal.pptx ). UPnP and Bonjour are both mapped to a hash. = We=92re truncating them to 6 octets =85 but that=92s a different discussio= n. In looking at Transparency for =93X=94, I=92d suggest that the X can be an = arbitrary service identified as a hash. Paul SNIA now seems focused on identifying individuals. Perhaps this is an outg= rowth of their data-deduplication? http://www.snia.org/tech_activities/standards/curr_standards/xam Regards, Douglas Otis --_000_CECF27342A043paulmarvellcom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

On Dec 11, 2013, at 1:56 PM, Ben Laurie <benl@google.com> wrote:

Agree, = I just want to be able to refer to 6962 for what
"cryptographically verifiable log" means.
Dear Ben,

There was an eXtensible Access Method, XAM, developed b= y SNIA.  This permitted vendors a means to implement strategies for ha= ndling massive amounts of data in a manner called Content Addressable Stora= ge, such as EMC^2's Centera product. The data blobs create multiple secure hashes that act within a standardized label. The bl= obs are combined with timestamps and XML MIME tags. This removes a need for= difficult to manage file hierarchy.  One of the benefits of this sche= me is data can not change without detection.
=

Interesting =85 in IEEE we=92re  defining = =91services=92 as a hash/UUID-like identifier htt= ps://mentor.ieee.org/802.11/dcn/12/11-12-0706-00-0isd-service-discovery-pro= posal.pptx ).  UPnP and Bonjour are both mapped to a hash. &n= bsp;We=92re truncating them to 6 octets =85 but that=92s a different discus= sion.

In looking at Transparency for =93X=94, I=92= d suggest that the X can be an arbitrary service identified as a hash. &nbs= p;

Paul


SNIA now seems focused on identif= ying individuals.  Perhaps this is an outgrowth of their data-deduplic= ation?

Regards,
Douglas Otis
=





--_000_CECF27342A043paulmarvellcom_-- From nweaver@icsi.berkeley.edu Thu Dec 12 09:59:36 2013 Return-Path: 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 BA9D31AE39E for ; Thu, 12 Dec 2013 09:59:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.003 X-Spam-Level: X-Spam-Status: No, score=-0.003 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 Iv4XATc4OvsH for ; Thu, 12 Dec 2013 09:59:35 -0800 (PST) Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id 2BC741AE3A2 for ; Thu, 12 Dec 2013 09:59:35 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 7B5BA2C402B for ; Thu, 12 Dec 2013 09:59:29 -0800 (PST) X-Virus-Scanned: amavisd-new at ICSI.Berkeley.EDU Received: from rock.ICSI.Berkeley.EDU ([127.0.0.1]) by localhost (maihub.ICSI.Berkeley.EDU [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 6ZhT97ba9gMQ; Thu, 12 Dec 2013 09:59:29 -0800 (PST) Received: from gala.icir.org (gala.icir.org [192.150.187.130]) (Authenticated sender: nweaver) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 2CAD62C4010; Thu, 12 Dec 2013 09:59:29 -0800 (PST) From: Nicholas Weaver Content-Type: multipart/signed; boundary="Apple-Mail=_B9F26ADA-C8AB-4A14-8CF3-4B44A69E7536"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Thu, 12 Dec 2013 09:59:28 -0800 Message-Id: <35116104-02EA-4C4F-B364-F65FBD7FA62E@icsi.berkeley.edu> To: perpass Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Cc: Nicholas Weaver Subject: [perpass] A bit more detail on QUANTUM advanced targeting... 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2013 17:59:37 -0000 --Apple-Mail=_B9F26ADA-C8AB-4A14-8CF3-4B44A69E7536 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I've written up a more detailed take on how active cookie discovery = could be used for exploitation targeting... https://medium.com/p/bb8816e88d86 The real fun bit, however, is: > Yet foreign intelligence agencies can do even better. Want to target = every Senator, every DC staffer, and every lobbyist by name? Do you have = their Gmail addresses, LinkedIn profile, and/or Warcraft player names? = Have a couple of =93diplomats=94 you can afford to get kicked out of the = country on the very remote chance your caught? If so, this one is for = you. So the DGSE (the French version of the NSA) should listen up. Using packet injection on the WiFi at the local starbucks... Enjoy this brave new world. Fun times all, fun times. -- Nicholas Weaver it is a tale, told by an idiot, nweaver@icsi.berkeley.edu full of sound and fury, 510-666-2903 .signifying nothing PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc --Apple-Mail=_B9F26ADA-C8AB-4A14-8CF3-4B44A69E7536 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCgAGBQJSqfmAAAoJEG2B1w+SDi/uIrkQAIMAaW6VB+uxV9FrnAD1jnvx JCoxihZ6qTBk5yAFBI5QRZmUDF+CtMiqJti331pgWagDWDT9L1+dFgImMZ5Jf16Q kDg6StZcSlyElVRwJeoeMOtHV5485DmnW0XJ7GJ0Yosri+LP5KyqoGS3oq67SkCR F7MF2o+bblPNJFbHv0NIigdmFBHjtKFXtENbMSAhnxkq9N3NKYRr1YOsThfBKT5k yari5etwIBqhQiTfFFVci6OmBc9l2J3k1CuMNlIZAHRsZyMXo6B3R2BAOFq9M8Ac 8q5Vyfo4QE5RmQXUvoBHYxkrNr+kmbt8ZPU11OIoTKR52Vm/XVdjMFXTBjHj5fPk 6+cOPaDl+/ogWIts/zQjh5lSIp6eNNT0G3PbUCvqyWGnbmjte6wM+tFUKYS/+BII kSJAqXrHwRKx7SdKiCjeoXuKF4w3hmsZk49f/TF7nbrY0TA25cbDDdVVnqe+JOWh UReHoj5bMG/qVclO60BazR5tmiHZ2SiqOgaGCsxE9Wx9aZuzAEbtqQHLJCtmLmG8 7QG/dpCs38ILRHODyvWbg3scuSnGoV/o238v2mnH013DDJVE09aAQGfDNWAGozJW RnxVMCxBxrDWJDYrK7xPCKErKnx6xPZICwsR+TbA5kDaE5axeNUpW6kZC6AVZnyI D+Lmiqz/YocxRqLyrzXu =oXfC -----END PGP SIGNATURE----- --Apple-Mail=_B9F26ADA-C8AB-4A14-8CF3-4B44A69E7536-- From rlb@ipv.sx Thu Dec 12 10:20:42 2013 Return-Path: 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 947921AE0BE for ; Thu, 12 Dec 2013 10:20:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 F1HN3eRMnRAq for ; Thu, 12 Dec 2013 10:20:40 -0800 (PST) Received: from mail-oa0-f41.google.com (mail-oa0-f41.google.com [209.85.219.41]) by ietfa.amsl.com (Postfix) with ESMTP id 399691AE00E for ; Thu, 12 Dec 2013 10:20:40 -0800 (PST) Received: by mail-oa0-f41.google.com with SMTP id j17so867420oag.14 for ; Thu, 12 Dec 2013 10:20:34 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=xqUEQxSZzof1xPTgQb/ERA5AVC1f09ouXq+48Ad/QUg=; b=O8xkOZ3pE+MSkhbKXHP0Fa8+rNouIK6oW4uXrvMX7eU75Rb3rYj57zBVfyu0xUGev8 hAHV8LCVYXsgOFq+WZt/79dC8SBRWBLqrzW6Dtl7NspeHW9etTDSxQjtjv6aA0DFv1KX blE2Y/A284u3QwLL3P+2VwgnpO6QF66hTMpj1dveZ9egEBaTFgQfa5qEZ2BOdc/wMAFk WW87AP1l1Uv4Srjo4HWfO2WVV5aqDxldb5+HpAJUacZHjkgptOqse9JeBAjCxR0ShvbN Am33DawMpBmIavNuldWTofysFPkz7k31LsX3Py2i/gCAs5DxX8VC1hzawH3XXJp9THX+ bzWg== X-Gm-Message-State: ALoCoQlL2rvQy3nIy1yZpa9VHxGAXUKNoG9f9ldxKcNLsvTX/USdJ+tO6tOeDjXbkL1VTT14Zhna MIME-Version: 1.0 X-Received: by 10.182.194.5 with SMTP id hs5mr6556738obc.19.1386872434033; Thu, 12 Dec 2013 10:20:34 -0800 (PST) Received: by 10.60.31.74 with HTTP; Thu, 12 Dec 2013 10:20:33 -0800 (PST) In-Reply-To: <35116104-02EA-4C4F-B364-F65FBD7FA62E@icsi.berkeley.edu> References: <35116104-02EA-4C4F-B364-F65FBD7FA62E@icsi.berkeley.edu> Date: Thu, 12 Dec 2013 13:20:33 -0500 Message-ID: From: Richard Barnes To: Nicholas Weaver Content-Type: multipart/alternative; boundary=f46d0444eb29c78d9304ed5a66ba Cc: perpass Subject: Re: [perpass] A bit more detail on QUANTUM advanced targeting... 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2013 18:20:42 -0000 --f46d0444eb29c78d9304ed5a66ba Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Thu, Dec 12, 2013 at 12:59 PM, Nicholas Weaver wrote: > I've written up a more detailed take on how active cookie discovery could > be used for exploitation targeting... > > https://medium.com/p/bb8816e88d86 > > The real fun bit, however, is: > > > Yet foreign intelligence agencies can do even better. Want to target > every Senator, every DC staffer, and every lobbyist by name? Do you have > their Gmail addresses, LinkedIn profile, and/or Warcraft player names? Ha= ve > a couple of =93diplomats=94 you can afford to get kicked out of the count= ry on > the very remote chance your caught? If so, this one is for you. So the DG= SE > (the French version of the NSA) should listen up. > > Using packet injection on the WiFi at the local starbucks... > I would note that attack at this level does not really qualify as "pervasive". And that there are sizeable technical differences between doing injection on a WiFi link and doing injection in, say, an OC-192. So we should not regard passive and active attack as equivalent. --Richard > > Enjoy this brave new world. Fun times all, fun times. > > -- > Nicholas Weaver it is a tale, told by an idiot, > nweaver@icsi.berkeley.edu full of sound and fury, > 510-666-2903 .signifying nothing > PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc > > > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > > --f46d0444eb29c78d9304ed5a66ba Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

= On Thu, Dec 12, 2013 at 12:59 PM, Nicholas Weaver <nweaver@icsi.be= rkeley.edu> wrote:
I've written up a more detailed take on = how active cookie discovery could be used for exploitation targeting...

https://med= ium.com/p/bb8816e88d86

The real fun bit, however, is:

> Yet foreign intelligence agencies can do even better. Want to target e= very Senator, every DC staffer, and every lobbyist by name? Do you have the= ir Gmail addresses, LinkedIn profile, and/or Warcraft player names? Have a = couple of =93diplomats=94 you can afford to get kicked out of the country o= n the very remote chance your caught? If so, this one is for you. So the DG= SE (the French version of the NSA) should listen up.

Using packet injection on the WiFi at the local starbucks...

I would note that attack at this level does not reall= y qualify as "pervasive". =A0And that there are sizeable technica= l differences between doing injection on a WiFi link and doing injection in= , say, an OC-192. =A0So we should not regard passive and active attack as e= quivalent.

--Richard


=A0

Enjoy this brave new world. =A0Fun times all, fun times.

--
Nicholas Weaver =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0it is a tale, told by an= idiot,
nweaver@icsi.berkeley.edu = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0full of sound and fury,
510-666-2903=A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0.signifying not= hing
PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub= .asc


_______________________________________________
perpass mailing list
perpass@ietf.org
https://www.ietf.org/mailman/listinfo/perpass


--f46d0444eb29c78d9304ed5a66ba-- From nweaver@icsi.berkeley.edu Thu Dec 12 10:25:01 2013 Return-Path: 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 2AE5B1AE39E for ; Thu, 12 Dec 2013 10:25:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 BYPtq_sz8mQE for ; Thu, 12 Dec 2013 10:24:59 -0800 (PST) Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id 7D0B51AE0BE for ; Thu, 12 Dec 2013 10:24:59 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id B7BF32C4010; Thu, 12 Dec 2013 10:24:53 -0800 (PST) X-Virus-Scanned: amavisd-new at ICSI.Berkeley.EDU Received: from rock.ICSI.Berkeley.EDU ([127.0.0.1]) by localhost (maihub.ICSI.Berkeley.EDU [127.0.0.1]) (amavisd-new, port 10024) with LMTP id xSuGGsRv6B9W; Thu, 12 Dec 2013 10:24:53 -0800 (PST) Received: from gala.icir.org (gala.icir.org [192.150.187.130]) (Authenticated sender: nweaver) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 601F42C4002; Thu, 12 Dec 2013 10:24:53 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_93588B28-29D4-4FC8-9D6A-4A3FB522C209"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Nicholas Weaver In-Reply-To: Date: Thu, 12 Dec 2013 10:24:52 -0800 Message-Id: References: <35116104-02EA-4C4F-B364-F65FBD7FA62E@icsi.berkeley.edu> To: Richard Barnes X-Mailer: Apple Mail (2.1510) Cc: perpass , Nicholas Weaver Subject: Re: [perpass] A bit more detail on QUANTUM advanced targeting... 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2013 18:25:01 -0000 --Apple-Mail=_93588B28-29D4-4FC8-9D6A-4A3FB522C209 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Dec 12, 2013, at 10:20 AM, Richard Barnes wrote: > Using packet injection on the WiFi at the local starbucks... >=20 > I would note that attack at this level does not really qualify as = "pervasive". And that there are sizeable technical differences between = doing injection on a WiFi link and doing injection in, say, an OC-192. = So we should not regard passive and active attack as equivalent. >=20 > --Richard There is no difference between the two scenarios, just the cost of the = hardware: a $35 Raspberry Pi vs a $5000 multicore box running Bro. The = technology, techniques, and attacker abilities are the same. And dollars to doughnuts says France can use this within their boarders = on OC-192 links. -- Nicholas Weaver it is a tale, told by an idiot, nweaver@icsi.berkeley.edu full of sound and fury, 510-666-2903 .signifying nothing PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc --Apple-Mail=_93588B28-29D4-4FC8-9D6A-4A3FB522C209 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCgAGBQJSqf90AAoJEG2B1w+SDi/uQewP/RpbSZwk8CRUDzH5JqEK8KV1 ahCIh6uXWtRv6Emy1jJYBLcVnE5aB53aF/IZOknQOPNXBmOvTnM1imKtdjRZfGqr SHwJdnuSD9u9q1tBVeXo43wsaDYDQrHE/okGOwzhF2YPIlw7o2QtHFwUE/3MrAF9 IVWxLIgX9lgVg5Qx/mNjtGmvgRY5P5rVAoB1AEtCOd2GJjguhxHnxUKhDfJfYW+2 peeg8BOlIem8+apMB+Q15eR8LEAyKNLSwk8kj4QT7xMyMAZKu+aiLk4+BSOlSI7l B/E1tQxCiXnNLhmywgfZbxVEHYWz1PJYPuklo3YtEHU8LS1s3TFoeLSEmxO46qbE quye9g/I4aiXOFJx7pFaoYIc3tK0O8RvM+WY1qLsuMIsL86bz95RpqklccjlIQxx A5ZQsOypRBfCafw+1ssf4VmeE4QlXMCSnQMBzHnTQO/0O1BmBGUz6y5whi60T2E4 h43+xxfKfY7rI27ar3YXLvlRiaA5GF9cifBHOJHLVTh7/mYGG7sYDNwpDzIWbTwS ZfpDvsEozM+Ph3bk/C1rMFKTn1QyhP2PS6KRnyRTPn41phreeIAEAnOt1j5QtJDe qivSZfWNn2+hiiNn8atcud+Li/ZDeW+1aMh56VVmbjS15V2w8TANoS4BaKomtPjj aWTaKmC/DRKWnyX37hDU =gfN1 -----END PGP SIGNATURE----- --Apple-Mail=_93588B28-29D4-4FC8-9D6A-4A3FB522C209-- From rlb@ipv.sx Thu Dec 12 10:29:19 2013 Return-Path: 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 707CD1AE3C9 for ; Thu, 12 Dec 2013 10:29:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 rJD2rZdOl8MM for ; Thu, 12 Dec 2013 10:29:16 -0800 (PST) Received: from mail-ob0-f181.google.com (mail-ob0-f181.google.com [209.85.214.181]) by ietfa.amsl.com (Postfix) with ESMTP id BDB141AD75F for ; Thu, 12 Dec 2013 10:29:16 -0800 (PST) Received: by mail-ob0-f181.google.com with SMTP id uy5so847549obc.40 for ; Thu, 12 Dec 2013 10:29:10 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=vOCTndT8cZB2XwAUY5+hMdDZt0ul0o26SFHGNWoUjk4=; b=Zth2NfaqAwoFHtTzfzDTeyMzCzZnH5APod/pH3d5p7Y8OAu8da7a25sFDsR4NYaniL RoPddgpxXEtU5Qij89Dg2w9UIjPAOOn/AgQCIynlHvFYPyQIb0B+WY2oWHJqzYqdctkZ UATAHzEEB5cjrCnENApvKpRq6dEMT/ky/YHGFlO/sp/ivBPMPB/PtfvyOhtKSrh0QVXj CkQFb4yNVWYVvsmbwfMIsooFctP3H42Bi1WGAzujnjM3EoEL8ZD26fmX+THyiiTLCjRV 2NCacqzrQmRrkkF3GaCYCDLZnEZ7g0C4ViT7vh+Bu0fNWwBi0rdU69TSMq/ONzr01jtc QE9A== X-Gm-Message-State: ALoCoQkDM2dO7yXwFRQJ69qHavj99cgGFYnCZEEAd7EIFOytPts9eEVxnTo0E8DcOx/nC9w8l8Dz MIME-Version: 1.0 X-Received: by 10.60.65.227 with SMTP id a3mr6609375oet.13.1386872950616; Thu, 12 Dec 2013 10:29:10 -0800 (PST) Received: by 10.60.31.74 with HTTP; Thu, 12 Dec 2013 10:29:10 -0800 (PST) In-Reply-To: References: <35116104-02EA-4C4F-B364-F65FBD7FA62E@icsi.berkeley.edu> Date: Thu, 12 Dec 2013 13:29:10 -0500 Message-ID: From: Richard Barnes To: Nicholas Weaver Content-Type: multipart/alternative; boundary=001a11c2570091fca204ed5a85ea Cc: perpass Subject: Re: [perpass] A bit more detail on QUANTUM advanced targeting... 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2013 18:29:19 -0000 --001a11c2570091fca204ed5a85ea Content-Type: text/plain; charset=ISO-8859-1 Maybe it's just me, but I consider a 100x cost increase significant. And I don't buy your assertion that you can do real-time, line-rate scanning and filtering with a $5k box. Otherwise routers wouldn't need ASICs. On Thu, Dec 12, 2013 at 1:24 PM, Nicholas Weaver wrote: > > On Dec 12, 2013, at 10:20 AM, Richard Barnes wrote: > > Using packet injection on the WiFi at the local starbucks... > > > > I would note that attack at this level does not really qualify as > "pervasive". And that there are sizeable technical differences between > doing injection on a WiFi link and doing injection in, say, an OC-192. So > we should not regard passive and active attack as equivalent. > > > > --Richard > > There is no difference between the two scenarios, just the cost of the > hardware: a $35 Raspberry Pi vs a $5000 multicore box running Bro. The > technology, techniques, and attacker abilities are the same. > > And dollars to doughnuts says France can use this within their boarders on > OC-192 links. > > -- > Nicholas Weaver it is a tale, told by an idiot, > nweaver@icsi.berkeley.edu full of sound and fury, > 510-666-2903 .signifying nothing > PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc > > --001a11c2570091fca204ed5a85ea Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Maybe it's just me, but I consider a 100x cost increas= e significant. =A0And I don't buy your assertion that you can do real-t= ime, line-rate scanning and filtering with a $5k box. =A0Otherwise routers = wouldn't need ASICs. =A0



On Thu, Dec 12, 2013 at 1:24 PM, Nicholas Weaver <nweaver@icsi.berkeley.edu> wrote:

On Dec 12, 2013, at 10:20 AM, Richard Barnes <rlb@ipv.sx> wrote:
> Using packet injection on the WiFi at the local starbucks...
>
> I would note that attack at this level does not really qualify as &quo= t;pervasive". =A0And that there are sizeable technical differences bet= ween doing injection on a WiFi link and doing injection in, say, an OC-192.= =A0So we should not regard passive and active attack as equivalent.
>
> --Richard

There is no difference between the two scenarios, just the cost of th= e hardware: a $35 Raspberry Pi vs a $5000 multicore box running Bro. =A0The= technology, techniques, and attacker abilities are the same.

And dollars to doughnuts says France can use this within their boarders on = OC-192 links.

--
Nicholas Weaver =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0it is a tale, told by an= idiot,
nweaver@icsi.berkeley.edu = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0full of sound and fury,
510-666-2903=A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0.signifying not= hing
PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub= .asc


--001a11c2570091fca204ed5a85ea-- From scott.brim@gmail.com Thu Dec 12 10:33:06 2013 Return-Path: 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 6A66A1AE3C9 for ; Thu, 12 Dec 2013 10:33:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 vkyesZgbECOC for ; Thu, 12 Dec 2013 10:33:05 -0800 (PST) Received: from mail-oa0-x22c.google.com (mail-oa0-x22c.google.com [IPv6:2607:f8b0:4003:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id D4F3E1AE0BE for ; Thu, 12 Dec 2013 10:33:04 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id m1so878807oag.17 for ; Thu, 12 Dec 2013 10:32:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=aG7afS21FMEvuIb5cwhPpSfu12HFnSgqHhKTFUo+myc=; b=cra3rF39XqNk71GtKboOJAp7lyVjMJRxEcHwaz8ThyaNZejE44OAEa7p0wf4Bs0WJD J1QEE0yHQvlb0CroXLK43zp3KRwEKf/F8U8qN3PPS9JNedO2stLwamHd8nbBgnxeuSkz VOcs8JtivJyQWvz+/jkLH8GIxK6gNfL9A/nfkVGUgv7GQmaKq8poRjLMfVsojiSq7r26 2bwvtC4nRRU3f3M0ZQuY6yw+gQ9HNB+MGnxcG0ETMgVV2B381VdoU0BA+VRpocZypk4t NGAgpGbsCvLGwykxV23RjtxVcYDyRdgp8XuASPnhI5FOxerk7i6Ql5lLVVyvZCYGadxz KhNQ== MIME-Version: 1.0 X-Received: by 10.182.153.226 with SMTP id vj2mr6707548obb.26.1386873178743; Thu, 12 Dec 2013 10:32:58 -0800 (PST) Received: by 10.182.48.9 with HTTP; Thu, 12 Dec 2013 10:32:58 -0800 (PST) Received: by 10.182.48.9 with HTTP; Thu, 12 Dec 2013 10:32:58 -0800 (PST) In-Reply-To: References: <35116104-02EA-4C4F-B364-F65FBD7FA62E@icsi.berkeley.edu> Date: Thu, 12 Dec 2013 13:32:58 -0500 Message-ID: From: Scott Brim To: Richard Barnes Content-Type: multipart/alternative; boundary=089e013d0dc02ae96504ed5a931c Cc: perpass , Nicholas Weaver Subject: Re: [perpass] A bit more detail on QUANTUM advanced targeting... 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2013 18:33:06 -0000 --089e013d0dc02ae96504ed5a931c Content-Type: text/plain; charset=ISO-8859-1 On Dec 12, 2013 1:20 PM, "Richard Barnes" wrote: > I would note that attack at this level does not really qualify as "pervasive". And that there are sizeable technical differences between doing injection on a WiFi link and doing injection in, say, an OC-192. So we should not regard passive and active attack as equivalent. Yes, so maybe it's the wrong time and place, but I for one hope the IETF will give new emphasis to personal privacy as well. Scott --089e013d0dc02ae96504ed5a931c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Dec 12, 2013 1:20 PM, "Richard Barnes" <rlb@ipv.sx> wrot= e:
> I would note that attack at this level does not really qualify as &quo= t;pervasive". =A0And that there are sizeable technical differences bet= ween doing injection on a WiFi link and doing injection in, say, an OC-192.= =A0So we should not regard passive and active attack as equivalent.

Yes, so maybe it's the wrong time and place, but I for o= ne hope the IETF will give new emphasis to personal privacy as well.=A0

Scott

--089e013d0dc02ae96504ed5a931c-- From benl@google.com Thu Dec 12 10:51:57 2013 Return-Path: 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 BFBD91AE3BF for ; Thu, 12 Dec 2013 10:51:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.38 X-Spam-Level: X-Spam-Status: No, score=-1.38 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 FqIi6HFpUTvH for ; Thu, 12 Dec 2013 10:51:56 -0800 (PST) Received: from mail-ve0-x22f.google.com (mail-ve0-x22f.google.com [IPv6:2607:f8b0:400c:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id B05051AE04D for ; Thu, 12 Dec 2013 10:51:56 -0800 (PST) Received: by mail-ve0-f175.google.com with SMTP id jx11so624110veb.6 for ; Thu, 12 Dec 2013 10:51:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=LC886EfhybIYLGMdPT6RkODYa4OITZ8eIEjiH6Rx7CY=; b=K3pZlCnBiXXOCAMYSE9Zm2PjK3E71MhcNLuc70mH7SH1PPNaeHmuVGnc7aVz+X2D90 GZ7D8RupojFwzFxyIh6myOhzviCFsdC39OSb9Wc2wlA9Nzob7+1OQXGKnf9ZdUWmZEVr M7tUzhx/cPOrTAHuR73xa5/lUtOmyyA296toObzQZSaFgGpnPdzihn1tn55UYZICVEuU 5g+6DBIcRXtC2XK6hseFiwBplIEn0OaenanTRJX+Ec82jo612o2H97uUqlK6mxDOno/q i1HnjCma9c3Cxk4W2H5+FSfnTBQcybrs6t09PqznuSAZBA9yC2pxH4bNdbPfaB+YGhnN XDqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=LC886EfhybIYLGMdPT6RkODYa4OITZ8eIEjiH6Rx7CY=; b=DWMSU4r5DxbJZoTtmOUFodlnfwnhB50umndm7RQLYhwWbgOSIJUh+WjCcFdA/hw18c 1/+Tei2jDDDbbnFDJrF+nOVAPpcZaH4tfIJebTJjCyJjbk6KWN6mD7tvVoD4WTnyY+3B Kt8o8q0cWtpbTysp65a09xOgWJLrpFRyciZ8sXFSKorwWqJQQa//Aw9tzGAf0/udVr1F OqQ1aRWaGqaTnrmWyR8Fr2Zx0KPNONsgesMyfQB7YHlGWLXxFAGDnlIp6ZyUKBJOBbbL v7fJENDyFymSuz/cBUbzC+lHSqrB5Z8m5v9p6jnugAaJcDV5t9Q3Zt6cJnHDlbvI/1zM WKNA== X-Gm-Message-State: ALoCoQlEEM8en7fZkuiVFvCA72NEu5cXS11Uq7s33cg9gesT4BuLf6s7WqS4GEhSSOUQqiPK/wy1X6QqT8EzN19UMfNhMO1fKCyOfOe2fH5ElHVO1ikVQlvJruYX0zbQ9ZiD/Yk8efqX2EJiBmGFO8KuapPX5mGJIbTEPiZvVK7hrDERVGBPNiB6AOivzQRgc06ND+ikkMg6 MIME-Version: 1.0 X-Received: by 10.220.84.65 with SMTP id i1mr307084vcl.51.1386874310544; Thu, 12 Dec 2013 10:51:50 -0800 (PST) Received: by 10.52.183.65 with HTTP; Thu, 12 Dec 2013 10:51:50 -0800 (PST) In-Reply-To: <52A9E61C.8030300@bbn.com> References: <52A8B1D0.2080304@dcrocker.net> <52A8E0E9.5020409@dcrocker.net> <52A9E61C.8030300@bbn.com> Date: Thu, 12 Dec 2013 18:51:50 +0000 Message-ID: From: Ben Laurie To: Stephen Kent Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: perpass , saag Subject: Re: [perpass] Draft charter for a Transparency Working Group 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2013 18:51:58 -0000 How's this? [1] A cryptographically verifiable log is an append-only log of hashes of more-or-less anything that can prove its own correctness cryptographically. For example, from RFC 6962: =93The append-only property of each log is technically achieved using Merkle Trees, which can be used to show that any particular version of the log is a superset of any particular previous version. Likewise, Merkle Trees avoid the need to blindly trust logs: if a log attempts to show different things to different people, this can be efficiently detected by comparing tree roots and consistency proofs. Similarly, other misbehaviours of any log (e.g., issuing signed timestamps for certificates they then don't log) can be efficiently detected and proved to the world at large.=94 See RFC 6962, http://www.links.org/files/CertificateTransparencyVersion2.1a= .pdf and http://www.links.org/files/RevocationTransparency.pdf for background. On 12 December 2013 16:36, Stephen Kent wrote: > Ben > > >> How about this footnote? >> >> "A cryptographically verifiable log is an append-only log of hashes of >> more-or-less anything that can prove its own correctness >> cryptographically. See RFC 6962, >> > I'd like something a bit more technical, since the phrase "prove its > own correctness" is pretty general. Hopefully there is text in 6962 > that you can use. > > Steve > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass From nweaver@icsi.berkeley.edu Thu Dec 12 10:54:19 2013 Return-Path: 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 322391AE3CC for ; Thu, 12 Dec 2013 10:54:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 plT_Ufdgnte7 for ; Thu, 12 Dec 2013 10:54:17 -0800 (PST) Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id 585AC1AE04D for ; Thu, 12 Dec 2013 10:54:17 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id A8A6A2C4010; Thu, 12 Dec 2013 10:54:11 -0800 (PST) X-Virus-Scanned: amavisd-new at ICSI.Berkeley.EDU Received: from rock.ICSI.Berkeley.EDU ([127.0.0.1]) by localhost (maihub.ICSI.Berkeley.EDU [127.0.0.1]) (amavisd-new, port 10024) with LMTP id rXMJfjGfXW7y; Thu, 12 Dec 2013 10:54:11 -0800 (PST) Received: from gala.icir.org (gala.icir.org [192.150.187.130]) (Authenticated sender: nweaver) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 465352C4002; Thu, 12 Dec 2013 10:54:11 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_9AA31766-B48D-4603-BDDC-B8C4BD5E5631"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Nicholas Weaver In-Reply-To: Date: Thu, 12 Dec 2013 10:54:10 -0800 Message-Id: <40008957-5E31-42D5-9E2C-BE81A38F3E42@icsi.berkeley.edu> References: <35116104-02EA-4C4F-B364-F65FBD7FA62E@icsi.berkeley.edu> To: Richard Barnes X-Mailer: Apple Mail (2.1510) Cc: perpass , Nicholas Weaver Subject: Re: [perpass] A bit more detail on QUANTUM advanced targeting... 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2013 18:54:19 -0000 --Apple-Mail=_9AA31766-B48D-4603-BDDC-B8C4BD5E5631 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Dec 12, 2013, at 10:29 AM, Richard Barnes wrote: > Maybe it's just me, but I consider a 100x cost increase significant. = And I don't buy your assertion that you can do real-time, line-rate = scanning and filtering with a $5k box. Otherwise routers wouldn't need = ASICs. =20 $5K can easily handle 10 Gbps links on a single computer, with just a = bit of hacking. You don't even need to do TCP stream reassembly, and = there are trivial parallelizations. And if thats not fast enough, then add in a hardware load balancer in = front to do tuple-distribution (those exist for the IDS application = area, and are pretty simple, just a hash of the SRC/DST 2-tuple to = rewrite the MAC address and toss at a switch), and use a $50K cluster. =20= Its an insanely scalable problem, and there are off the shelf designs. = Not to mention you can handle packet loss a lot easier on an on-path = device rather than in-path device, which is one of=20 And packet injection on backbone links is reality, with at least two = major users: Packet injection on backbone links is USED by the NSA. The NSA calls it = QUANTUM. =20 Packet injection on backbone links is USED by China. We call it the = "great firewall of China". They've only been using it for censorship = to-date that we know of, but it is downright trivia to turn it into an = exploitation tool. This is not rocket science, and it is not magic. Rather, the limitation = of packet injection is the ability to place suitable hardware at = suitable vantage points. The NSA has the ability to place their hardware throughout the world. = Most other countries are limited to their national borders OR techniques = they can install near the edge surreptitiously. =20 And all it takes is a SINGLE request which identifies the potential = victim as a VALID target passing a SINGLE adversarial wiretap for this = type of attack to be launched. And, finally, don't underestimate the power of software running on = commodity hardware: RouteBricks showed you can do 35 Gbps in software = using Click on a single, 2 CPU, 4 cores/cpu server, back in 2009! -- Nicholas Weaver it is a tale, told by an idiot, nweaver@icsi.berkeley.edu full of sound and fury, 510-666-2903 .signifying nothing PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc --Apple-Mail=_9AA31766-B48D-4603-BDDC-B8C4BD5E5631 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCgAGBQJSqgZSAAoJEG2B1w+SDi/upEUQAKYBmsokG3L+Wj85lNa790hK 8CX+JzkeLSxKl40TMPog0kfSLSFwKXsVzaYikjv069/eeBCPuG8zfCsVyZYQojk5 5TPewz8mQ0vPpoYdiCPpPWNtGy0FZynRRXyTZYTJV1DiWkRxadjMNBG8yfOfms3p OMkXnu/z1UTGy+MG+jOlAc4DaGNgmMF4YLYrHFm8GwcgXTZYF6WnZD4BOxBKGdUV pUcwgBiC3wNKDOV5NcSrAuvhQlhFratetIuh3f+BmPbfu/dvNBhBW7U7zVRGhMgo 79zHYt/IbbEw/BF91aSPLzK8d02M4zo3r3nzlfcj9yylhgbiYP30sKFwGg/L2oGw vBfEOXof3DH2j+An/vxuxq/yuJkbiACTAfHXLKRntCRI3IbG0InTugBWR/1xb8Kv 1iTu9bKF+J1HnmNQnvQrdn2/qnRNjQwLltuQP6o2zkIvoYReakIS/vq+6NjdNOp5 HhBiLK2qljbGyPon67nzQ1utf0RnOIfUAdg55yYLv9aJqmpIgSUURpbj1D3R4DAR 93KMJ5guAUbnnVPqOa7sBeiNb+ed0+7BMu8jju0S20mehe85FcQKyf8ukPBN8N6G qldARHhGY/QkaGTS1lUbJ0JpGcYt1e8Z2oYwcTfVvmi4m1VPSWO/cBgu7gcGKZx5 /w3p06oL4BWmfb1PsYCK =kjD1 -----END PGP SIGNATURE----- --Apple-Mail=_9AA31766-B48D-4603-BDDC-B8C4BD5E5631-- From hartmans@mit.edu Thu Dec 12 13:08:03 2013 Return-Path: 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 513A71AE4C7 for ; Thu, 12 Dec 2013 13:08:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] 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 V5gyj8Pf3Zn0 for ; Thu, 12 Dec 2013 13:08:02 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 460CC1AE025 for ; Thu, 12 Dec 2013 13:08:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id B0772205DF; Thu, 12 Dec 2013 16:06:41 -0500 (EST) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LnxMJ7_cA0eF; Thu, 12 Dec 2013 16:06:41 -0500 (EST) Received: from carter-zimmerman.suchdamage.org (c-50-136-31-107.hsd1.ma.comcast.net [50.136.31.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Thu, 12 Dec 2013 16:06:41 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 78EFA91395; Thu, 12 Dec 2013 16:07:55 -0500 (EST) From: Sam Hartman To: Richard Barnes References: <35116104-02EA-4C4F-B364-F65FBD7FA62E@icsi.berkeley.edu> Date: Thu, 12 Dec 2013 16:07:55 -0500 In-Reply-To: (Richard Barnes's message of "Thu, 12 Dec 2013 13:20:33 -0500") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Thu, 12 Dec 2013 13:11:10 -0800 Cc: perpass , Nicholas Weaver Subject: Re: [perpass] A bit more detail on QUANTUM advanced targeting... 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2013 21:08:03 -0000 >>>>> "Richard" == Richard Barnes writes: Richard> I would note that attack at this level does not really Richard> qualify as "pervasive". And that there are sizeable Richard> technical differences between doing injection on a WiFi Richard> link and doing injection in, say, an OC-192. So we should Richard> not regard passive and active attack as equivalent. I do buy the arguments about being able to handle 10 gbps on commodity hardware. However, let's assume I didn't buy that. Why would I choose to inject on the oc-192? To get a packet in, I just need to inject somewhere where it will not get filtered out. There are a lot of exploits I can run if I can see your traffic (my permasive monitoring) and if I can insert packets, even if I cannot suppress or modify packets. Yeah, perhaps you'll get some images that fail to download correctly, or some strange TCP resets observed at one end but not the other. I suspect I'm not the only one on this list who fails to inventigate all the events of that class that affect me. So, I think understanding how permasive monitoring enables these other attacks is very much in scope for the high-level picture and is definitely something the March workshop should consider. It's also the sort of analysis I'd expect people to look into when doing security considerations sections after the passive threat BCP is approved. From huitema@huitema.net Thu Dec 12 13:57:34 2013 Return-Path: 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 E71891AE00C for ; Thu, 12 Dec 2013 13:57:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 UG5FYUIbOCEx for ; Thu, 12 Dec 2013 13:57:32 -0800 (PST) Received: from xsmtp12.mail2web.com (xsmtp12.mail2web.com [168.144.250.177]) by ietfa.amsl.com (Postfix) with ESMTP id 8E89C1AD8E2 for ; Thu, 12 Dec 2013 13:57:32 -0800 (PST) Received: from [10.5.2.52] (helo=xmail12.myhosting.com) by xsmtp12.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1VrEG5-0002KA-Jw for perpass@ietf.org; Thu, 12 Dec 2013 16:57:26 -0500 Received: (qmail 11326 invoked from network); 12 Dec 2013 21:57:24 -0000 Received: from unknown (HELO HUITEMA5) (Authenticated-user:_huitema@huitema.net@[173.160.170.98]) (envelope-sender ) by xmail12.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 12 Dec 2013 21:57:23 -0000 From: "Christian Huitema" To: "'Sam Hartman'" , "'Richard Barnes'" References: <35116104-02EA-4C4F-B364-F65FBD7FA62E@icsi.berkeley.edu> In-Reply-To: Date: Thu, 12 Dec 2013 13:57:20 -0800 Message-ID: <016001cef785$22ecfa30$68c6ee90$@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQIoKa3xATIJkoMri2GtvtjQh2K9ygGx2frkAYrwhRiZhMooQA== Content-Language: en-us Cc: 'perpass' , 'Nicholas Weaver' Subject: Re: [perpass] A bit more detail on QUANTUM advanced targeting... 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2013 21:57:35 -0000 > So, I think understanding how permasive monitoring enables these other > attacks is very much in scope for the high-level picture and is > definitely something the March workshop should consider. > It's also the sort of analysis I'd expect people to look into when doing > security considerations sections after the passive threat BCP is > approved. The basic point is that it is fairly easy for agencies with wide monitoring capabilities to observe third party cookies, and to associate them with user identities. Once you have that, you can identify the IP address of the target, and start prepping for the injection. To mount an active attack, you only need to observe the SYN packet, and immediately send a SYN-ACK, a DATA packet containing the HTTP Redirect, and a FIN. You don't need to actually receive the ACK from the remote site. If you beat the race against the actual web site, you win. And you can certainly do that "from the side," you just need to find a router that will let you inject packets without checking the origin address. After that, up to your imagination. Targets are unlikely to find out that one of dozen or so trackers on the web page was redirected. Or thFor exat it downloaded some exploit... I don't think we will be able to eradicate clear text HTTP, but we can certainly limit the damage and create momentum. For example, we could assume that any clear text HTTP connection is untrusted, and ask browsers to treat them as such. No cookies, no scripts, definitely no download. That would be a nice way to push sites towards HTTPS. The various trackers will probably be the first to move... -- Christian Huitema From hallam@gmail.com Thu Dec 12 19:23:28 2013 Return-Path: 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 1EB571AE609 for ; Thu, 12 Dec 2013 19:23:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 8F1OTPzl8OcU for ; Thu, 12 Dec 2013 19:23:25 -0800 (PST) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) by ietfa.amsl.com (Postfix) with ESMTP id 8ED341ADFA7 for ; Thu, 12 Dec 2013 19:23:25 -0800 (PST) Received: by mail-wi0-f179.google.com with SMTP id z2so493649wiv.0 for ; Thu, 12 Dec 2013 19:23:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ks3LbbOd84KGF7fFqPp0Hwfv/KKz+C2Nb/zr7mp6q8k=; b=uRpKFQUtyfOP2tAf9c2LhtgRsmSNkHf80Qdl0Em12ICcROd5snrxa+ct+lEjq/p1lP uO0xLUgXQAFh8FC85eQ8ZxOChIIwbmuab1h1JQLbpD9/g9sOTwJKeR30MmDSYEKwiSaU hiBUbll2CJKsVzchKOpOiMv54KyXTewFW7ro6aFd8t3oTVye/jk3x38NvbLkaRUOkZuA 2repf9I6DcWraqS0MCYnwxztJ9HDNZw5b9XGp87Oti9WwTgVHTUyKqg3cl6AK8JU/xGY LwxBoFpqSVZyARWjLFWvNeM+L102I/IAHbqxT6wLyk15jurDr9Do29DYGo46iJaIJKNZ escw== MIME-Version: 1.0 X-Received: by 10.180.108.97 with SMTP id hj1mr856745wib.59.1386904999013; Thu, 12 Dec 2013 19:23:19 -0800 (PST) Received: by 10.194.243.136 with HTTP; Thu, 12 Dec 2013 19:23:18 -0800 (PST) In-Reply-To: <1386793256.7652.31.camel@pishuli.lund.millnert.se> References: <0932E601-895B-457B-9F2D-DD79626AE0F0@icsi.berkeley.edu> <1386785782.584816710@apps.rackspace.com> <7E5F9EAE-053F-46BF-A47A-E66CFC74CEB8@icsi.berkeley.edu> <1386793256.7652.31.camel@pishuli.lund.millnert.se> Date: Thu, 12 Dec 2013 22:23:18 -0500 Message-ID: From: Phillip Hallam-Baker To: Martin Millnert Content-Type: multipart/alternative; boundary=e89a8f3bafefcdb37d04ed61fbe3 Cc: Robin Wilton , perpass , Nicholas Weaver Subject: Re: [perpass] Yet Another Reason why ALL CLEARTEXT MUST BE ELIMINATED! 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 03:23:28 -0000 --e89a8f3bafefcdb37d04ed61fbe3 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Dec 11, 2013 at 3:20 PM, Martin Millnert wrote: > On Wed, 2013-12-11 at 11:44 -0800, Nicholas Weaver wrote: > > On Dec 11, 2013, at 10:16 AM, wilton@isoc.org wrote: > > > > > And this time *with* the link... I hate it when I do that. > > > http://webpolicy.org/2013/12/09/metaphone-the-nsa-three-hop/ > > > Robin > > > > Everyone on this group should be considered within the "3 hop" rule. > > > > Edward Snowden <-> Various Reporters And Others I've Identified <-> Me > <-> You all. > > > > Enjoy. > > Two hop is actually sufficient, since Jake's participating here. :-) > > Regards, > Martin > I know Glenn Greenwald, I think he is considered a prime target, not a secondary. So the whole IETF is two hop. -- Website: http://hallambaker.com/ --e89a8f3bafefcdb37d04ed61fbe3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Dec 11, 2013 at 3:20 PM, Martin Millnert = <martin@millnert= .se> wrote:
On Wed, 2013-12-11 at 11:4= 4 -0800, Nicholas Weaver wrote:
> On Dec 11, 2013, at 10:16 AM, wilto= n@isoc.org wrote:
>
> > And this time *with* the link... I hate it when I do that.
> > http://webpolicy.org/2013/12/09/metaphone-the-nsa= -three-hop/
> > Robin
>
> Everyone on this group should be considered within the "3 hop&quo= t; rule.
>
> Edward Snowden <-> Various Reporters And Others I've Identif= ied <-> Me <-> You all.
>
> Enjoy.

Two hop is actually sufficient, since Jake's participating here. = :-)

Regards,
Martin

I know Glenn Greenwald, I think = he is considered a prime target, not a secondary.

= So the whole IETF is two hop.
=A0
--
Website: http://hallambaker.com/
--e89a8f3bafefcdb37d04ed61fbe3-- From hallam@gmail.com Fri Dec 13 06:08:40 2013 Return-Path: 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 9928A1AE29B; Fri, 13 Dec 2013 06:08:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 UMJ89fghltla; Fri, 13 Dec 2013 06:08:39 -0800 (PST) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) by ietfa.amsl.com (Postfix) with ESMTP id A32401AE28B; Fri, 13 Dec 2013 06:08:38 -0800 (PST) Received: by mail-wi0-f180.google.com with SMTP id hn9so1114194wib.13 for ; Fri, 13 Dec 2013 06:08:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=AxXzbcHWcTDgTy0T2xecALWFBj4PHbcM4Xqn7lewtkg=; b=P4roaLWrzKnC6YIZd+9YRtsK3YhQiVdcAug7u984MMQ614ZbmoZSRwYceVn2CxFv5q cWzxUt7SAVJgdaKVeI171viefOtWbe0GNThIVl7enNjrya3yKJmKheophMQkQwHfGhl7 QAm0Wpb+uYEP6rq8e1XW6jU/kzNM056HRuPlTZXP4Y+rd6li5Su/1+uscdIZBTkRsKDM I0f3yAfy65Kv/UidbsJHeMqf6ZfDRT8CsAPk65ZnUnEvHbzr9KoQTTrtfK/H3d0KwBH4 +KCX+vGP6tHdXiYRSu38Hjia4RJmLBuAsjNUdXZt5vF9cOq9IUUAZylTL9E8uQ6rwemH UiHw== MIME-Version: 1.0 X-Received: by 10.194.94.167 with SMTP id dd7mr2493667wjb.43.1386943711881; Fri, 13 Dec 2013 06:08:31 -0800 (PST) Received: by 10.194.243.136 with HTTP; Fri, 13 Dec 2013 06:08:30 -0800 (PST) In-Reply-To: <52A9E61C.8030300@bbn.com> References: <52A8B1D0.2080304@dcrocker.net> <52A8E0E9.5020409@dcrocker.net> <52A9E61C.8030300@bbn.com> Date: Fri, 13 Dec 2013 09:08:30 -0500 Message-ID: From: Phillip Hallam-Baker To: Stephen Kent Content-Type: multipart/alternative; boundary=047d7bb03c464531d304ed6aff70 Cc: perpass , saag Subject: Re: [perpass] Draft charter for a Transparency Working Group 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 14:08:40 -0000 --047d7bb03c464531d304ed6aff70 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Dec 12, 2013 at 11:36 AM, Stephen Kent wrote: > Ben > > > How about this footnote? >> >> "A cryptographically verifiable log is an append-only log of hashes of >> more-or-less anything that can prove its own correctness >> cryptographically. See RFC 6962, >> >> I'd like something a bit more technical, since the phrase "prove its > own correctness" is pretty general. Hopefully there is text in 6962 > that you can use. > How about just call it a catenate certificate append-only notary log which is the technical term of are that Harber and Stornetta introduced in their paper and patents? -- Website: http://hallambaker.com/ --047d7bb03c464531d304ed6aff70 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Thu, Dec 12, 2013 at 11:36 AM, Stephen Kent &l= t;kent@bbn.com> wrote:
Ben


How about this footnote?

"A cryptographically verifiable log is an append-only log of hashes of=
more-or-less anything that can prove its own correctness
cryptographically. See RFC 6962,

I'd like something a bit more technical, since the phrase "prove i= ts
own correctness" is pretty general. Hopefully there is text in 6962 that you can use.

How about just call i= t a catenate certificate append-only notary log which is the technical term= of are that Harber and Stornetta introduced in their paper and patents?

=A0
--
Website: http://hallambaker.com/
--047d7bb03c464531d304ed6aff70-- From hallam@gmail.com Fri Dec 13 06:17:14 2013 Return-Path: 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 C1EF81AE2B4; Fri, 13 Dec 2013 06:17:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 G7cnG8KbhsHs; Fri, 13 Dec 2013 06:17:12 -0800 (PST) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 412881AE2B0; Fri, 13 Dec 2013 06:17:12 -0800 (PST) Received: by mail-we0-f170.google.com with SMTP id w61so1943958wes.15 for ; Fri, 13 Dec 2013 06:17:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mluI2uBD81K80pxJsICygTVb1wQ3spH0o+tS+rCSCDE=; b=YjGOwlCgGwC2zyjjO3pkk7wppRCKPsLJibJn4zZEebtxUoEqckKKBUVMmF70zc3gAD yeuSsAGIAaKdQ48PmGCtZ1JEWRK3usl+utBtMFVE5n9d7Wv3/FyDi9jtimtR1IhVtr6K 3hWDN63toAAA5VNsjg8RJ2TKwJuSfbnNraL+eZtT8mL4VYORjh2MuoPl+zaHySdpp7dP Ji2SgKUOLHcW5lgjLNaxqoGlxpnihDokiESr+Q4qqfPhTtez+QJCDoUQOSdOyvdVSVY8 AWzK+Oxqkg5+bltRudxDkRGA2W4jJDsaEZfUmdsOaN9Q7SmfdcZ8NeycUoeFg+BDEmWJ xdog== MIME-Version: 1.0 X-Received: by 10.194.119.132 with SMTP id ku4mr2473022wjb.51.1386944225447; Fri, 13 Dec 2013 06:17:05 -0800 (PST) Received: by 10.194.243.136 with HTTP; Fri, 13 Dec 2013 06:17:05 -0800 (PST) In-Reply-To: References: <52A8B1D0.2080304@dcrocker.net> <52A8E0E9.5020409@dcrocker.net> <52A9E61C.8030300@bbn.com> Date: Fri, 13 Dec 2013 09:17:05 -0500 Message-ID: From: Phillip Hallam-Baker To: Ben Laurie Content-Type: multipart/alternative; boundary=089e01228d72e1991904ed6b1d5c Cc: perpass , Stephen Kent , saag Subject: Re: [perpass] Draft charter for a Transparency Working Group 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 14:17:15 -0000 --089e01228d72e1991904ed6b1d5c Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Thu, Dec 12, 2013 at 1:51 PM, Ben Laurie wrote: > How's this? > > [1] A cryptographically verifiable log is an append-only log of hashes > of more-or-less anything that can prove its own correctness > cryptographically. > > For example, from RFC 6962: =93The append-only property of each log is > technically achieved using Merkle Trees, which can be used to show > that any particular version of the log is a superset of any particular > previous version. Likewise, Merkle Trees avoid the need to blindly > trust logs: if a log attempts to show different things to different > people, this can be efficiently detected by comparing tree roots and > consistency proofs. Similarly, other misbehaviours of any log (e.g., > issuing signed timestamps for certificates they then don't log) can be > efficiently detected and proved to the world at large.=94 I disagree. The Merkle tree part is only relevant to verification efficiency. And I would want to look into it a lot further before committing to that particular approach due to the Micali patents and other patents applying Merkle to catenate certs. The property that is important is the chaining of one hash to the next and that is the property that is definitively out of patent. For email security I am not planning to use trees at all or at least not in that way. Chains are simpler to debug and the additional overhead largely irrelevant as all the certificate validation and evaluation can be done offline. Latency is not a concern as this is a store and forward protocol or a messaging protocol. The time it takes someone to pick up the phone is always going to be much longer than any key evaluation process. --=20 Website: http://hallambaker.com/ --089e01228d72e1991904ed6b1d5c Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable



On Thu, Dec 12, 2013 at 1:51 PM, Ben Laurie <<= a href=3D"mailto:benl@google.com" target=3D"_blank">benl@google.com>= wrote:
How's this?

[1] A cryptographically verifiable log is an append-only log of hashes
of more-or-less anything that can prove its own correctne= ss
cryptographically.

For example, from RFC 6962: =93The append-only property of each log i= s
technically achieved using Merkle Trees, which can be used to show
that any particular version of the log is a superset of any particular
previous version. Likewise, Merkle Trees avoid the need to blindly
trust logs: if a log attempts to show different things to different
people, this can be efficiently detected by comparing tree roots and
consistency proofs. Similarly, other misbehaviours of any log (e.g.,
issuing signed timestamps for certificates they then don't log) can be<= br> efficiently detected and proved to the world at large.=94
=
I disagree. The Merkle tree part is only relevant to verific= ation efficiency. And I would want to look into it a lot further before com= mitting to that particular approach due to the Micali patents and other pat= ents applying Merkle to catenate certs.
=A0
The property that is important is the chaining of = one hash to the next and that is the property that is definitively out of p= atent.


For email security I am not = planning to use trees at all or at least not in that way. Chains are simple= r to debug and the additional overhead largely irrelevant as all the certif= icate validation and evaluation can be done offline.

Latency is not a concern as this is a store and forward= protocol or a messaging protocol. The time it takes someone to pick up the= phone is always going to be much longer than any key evaluation process.

--
Website: http://h= allambaker.com/
--089e01228d72e1991904ed6b1d5c-- From benl@google.com Fri Dec 13 06:25:32 2013 Return-Path: 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 E02991AE281 for ; Fri, 13 Dec 2013 06:25:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.38 X-Spam-Level: X-Spam-Status: No, score=-1.38 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 tFZZg5K_7kAV for ; Fri, 13 Dec 2013 06:25:31 -0800 (PST) Received: from mail-ve0-x22d.google.com (mail-ve0-x22d.google.com [IPv6:2607:f8b0:400c:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id AE0611AE124 for ; Fri, 13 Dec 2013 06:25:31 -0800 (PST) Received: by mail-ve0-f173.google.com with SMTP id oz11so1400726veb.4 for ; Fri, 13 Dec 2013 06:25:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=6K4SDPkNl0Y8hAvxrxYgE3eFqKN6ebP2kVJIcYipmtw=; b=KDBY63wpqHYQOqd89c5WVeO9OskPdnyEFMcRmT3VRHLNBMaGRbnCyP96w+nBuZ+Pdp BR7WZtv+VDP+sNODGLNolYARER1p7AJ3uxU6Wy7VPhh5LYMiErL3Yk9YTEJuoxtsTU1S dRHCxSfYwgOjL1HJg8ApEjMe62TB4WXG7m3SVvxCiB9qpLNBs6HK8bqUInCCfx558oZI BVo5B9gn6FDYogEPoJhX7zpBYIbeMQhZceE2DSQpH45KV3UTKVn1oKIfOtTgF16G12ka OHLH9LQqOse1FpiVuWuCjWqfqjKre5cF4QDuAzrWxVoaeZre9qlL7Hyz7PIdDzSiqsFB B35Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=6K4SDPkNl0Y8hAvxrxYgE3eFqKN6ebP2kVJIcYipmtw=; b=VngTFcoRBgDtFN/+upX7p3gF6IXIrJkfarWgjOo1MLt2JhLnf8pdcph0TDJpyqoRVO maHrZMfKZYDFeG660uvUWjv5ei+NmdTc1cVpMxtVxXPySRfScmW6eT0zQ2uNFIuZwJIz mt+cy0nYv+uYF6gwKAkRbNbhShf5HmBdNtQ4uwSyri99336LrynShQvA9TmypcQmZ0Pm b65o2ai9gmxsHSAAGm/IXEAZ1CDx20XeX265B+tHR8NCTE7fVfkM6+s1VEZKm4A14Z1Y 85tq59K9b/kkMthiAG55GE2JfhTT4Oi+cNeqPBqDBw1/quzqDnIBxXk9ZJRgb+NYfsLK DqPg== X-Gm-Message-State: ALoCoQli+beatQ/s78ZVhsLAkiQP9Y64pOfCxoLOqh2BUUTVrB+KCoy6fDE3X8rSO/GX8NJ67wu8fxyJlz0I2j56M4oe6ddj+7Ig/11221+IIcDx615nI3kM1K2tBR3Uuz2axd5oUvrXaFqWDck/M88eKxqIAGDPOXHh+olOSEpg6i1i2Jfr2vpUrHLOYckVxnp9PI+fx4fx MIME-Version: 1.0 X-Received: by 10.58.118.84 with SMTP id kk20mr1316676veb.26.1386944725023; Fri, 13 Dec 2013 06:25:25 -0800 (PST) Received: by 10.52.183.65 with HTTP; Fri, 13 Dec 2013 06:25:24 -0800 (PST) In-Reply-To: References: <52A8B1D0.2080304@dcrocker.net> <52A8E0E9.5020409@dcrocker.net> <52A9E61C.8030300@bbn.com> Date: Fri, 13 Dec 2013 14:25:24 +0000 Message-ID: From: Ben Laurie To: Phillip Hallam-Baker Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: perpass , Stephen Kent , saag Subject: Re: [perpass] Draft charter for a Transparency Working Group 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 14:25:33 -0000 On 13 December 2013 14:17, Phillip Hallam-Baker wrote: > > > > On Thu, Dec 12, 2013 at 1:51 PM, Ben Laurie wrote: >> >> How's this? >> >> [1] A cryptographically verifiable log is an append-only log of hashes >> of more-or-less anything that can prove its own correctness >> cryptographically. >> >> For example, from RFC 6962: =93The append-only property of each log is >> technically achieved using Merkle Trees, which can be used to show >> that any particular version of the log is a superset of any particular >> previous version. Likewise, Merkle Trees avoid the need to blindly >> trust logs: if a log attempts to show different things to different >> people, this can be efficiently detected by comparing tree roots and >> consistency proofs. Similarly, other misbehaviours of any log (e.g., >> issuing signed timestamps for certificates they then don't log) can be >> efficiently detected and proved to the world at large.=94 > > > I disagree. The Merkle tree part is only relevant to verification > efficiency. And I would want to look into it a lot further before committ= ing > to that particular approach due to the Micali patents and other patents > applying Merkle to catenate certs. You disagree that RFC 6962 provides an example? I'm not sure what you're disagreeing with... > The property that is important is the chaining of one hash to the next an= d > that is the property that is definitively out of patent. The property that is important is the ability to prove correctness, by whatever means. From wilton@isoc.org Sat Dec 14 11:25:00 2013 Return-Path: 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 1718E1ADFF7 for ; Sat, 14 Dec 2013 11:25:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=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 xG6CLWNAEK9T for ; Sat, 14 Dec 2013 11:24:53 -0800 (PST) Received: from smtp94.iad3a.emailsrvr.com (smtp94.iad3a.emailsrvr.com [173.203.187.94]) by ietfa.amsl.com (Postfix) with ESMTP id 9ABF51AE142 for ; Sat, 14 Dec 2013 11:24:53 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp28.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id DC5D81E0178; Sat, 14 Dec 2013 14:24:46 -0500 (EST) X-Virus-Scanned: OK Received: by smtp28.relay.iad3a.emailsrvr.com (Authenticated sender: wilton-AT-isoc.org) with ESMTPSA id 456D41E017A; Sat, 14 Dec 2013 14:24:46 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_B584DE1B-C7FD-46C0-9135-4BF295BAE7EE" From: Robin Wilton In-Reply-To: <7D801592-36E4-4C5E-8AC9-B8940A72CC8B@isoc.org> Date: Wed, 11 Dec 2013 19:14:45 +0100 Message-Id: <61B1D772-CAFF-46A0-8295-CD54C8790C4C@isoc.org> References: <0932E601-895B-457B-9F2D-DD79626AE0F0@icsi.berkeley.edu> <7D801592-36E4-4C5E-8AC9-B8940A72CC8B@isoc.org> To: Nicholas Weaver X-Mailer: Apple Mail (2.1283) Cc: perpass Subject: Re: [perpass] Yet Another Reason why ALL CLEARTEXT MUST BE ELIMINATED! 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Dec 2013 19:25:01 -0000 --Apple-Mail=_B584DE1B-C7FD-46C0-9135-4BF295BAE7EE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii And this time *with* the link... I hate it when I do that. http://webpolicy.org/2013/12/09/metaphone-the-nsa-three-hop/ Robin On 11 Dec 2013, at 17:23, Robin Wilton wrote: > Thanks Nicholas - this is useful and relevant analysis. >=20 > In case you haven't already seen it, this piece about some new = research (at Stanford... sorry ;^) ) gives a similarly worrying = perspective on the role of "hub" sites in expanding the scope of the = "three hops" rule. Your Step 2 is, I think, a very similar mechanism, = and has significant privacy impact. >=20 > Yrs., > Robin >=20 > Robin Wilton > Technical Outreach Director - Identity and Privacy > Internet Society >=20 > email: wilton@isoc.org > Phone: +44 705 005 2931 > Twitter: @futureidentity >=20 >=20 >=20 >=20 > On 11 Dec 2013, at 16:43, Nicholas Weaver wrote: >=20 >>=20 >> Cookies and user tracking are wonderful things. If you are a = intelligence service, that is. >>=20 >> Its now clear that the NSA (and, remember, any other intelligence = service that might see such traffic can do the same thing) uses = cookies/advertising for both tracking (e.g. HAPPYFOOT: Advertisement = libraries (esp on Android) which broadcast location + IMEI in the clear = -> easy user tracking) and targeting (e.g. Know the victim's google = PREFID cookie through other means, then use it to target exploitation:=20= >>=20 >> = http://apps.washingtonpost.com/g/page/national/nsa-signal-surveillance-suc= cess-stories/647/#document/p3/a135602 >>=20 >> = http://www.washingtonpost.com/blogs/the-switch/wp/2013/12/10/nsa-uses-goog= le-cookies-to-pinpoint-targets-for-hacking/ >> ) >>=20 >> Everyone on this list should now consider themselves an in-scope = target from at least one foreign intelligence service... >>=20 >>=20 >> But the intelligence services can do even better if they want. = Here's how: >>=20 >> The NSA or foreign intelligence wiretap has a possible candidate for = attack, but not probable. That is, they THINK they may want to do an = exploitation attack but aren't sure... >>=20 >>=20 >> 1) On the packet-injecting wiretap, it sees a possible candidate and = it does a packet injection of a 302 redirect to a "User ID" script on = the exploit server for something inconsequentially small. >>=20 >>=20 >> 2) The user-ID script creates a hidden iframe. >>=20 >> Within that iframe, it opens up a bunch of other iframes to various = sites, e.g.www.youtube.com,www.linkedin.com, www.yahoo.com, = slashdot.org, etc. Namely ANLY (and well, all) sites which >>=20 >> a) Identifies the user in the response >>=20 >> b) Uses a user-identifying cookie that can be sent in the clear. >>=20 >> This causes the possible victim's browser to visit all these sites, = identifying the victim to any wiretap that can see it. >>=20 >>=20 >> 3) Back on the packet-injecting wiretap, it looks for = request/response pairs to the targeted sites, using the request to = extract the user ID cookies and the response to match the user = identification by quick & dirty parsing of the HTML in the response. >>=20 >> Since the wiretap knows the user identifications it wants to exploit, = it now knows the user ID cookies it wants to exploit as well. >>=20 >>=20 >> 4) Back on the user-ID script, after a ~10 second delay, it then = creates a second set of iframes to the various sites for different URLs. = This causes the possible victim's browser to revisit all the sites. = These requests contain the user's ID cookies, which any wiretap has now = been able to map to "is this the actual person I want to target" >>=20 >>=20 >> 5) The packet injecting wiretap, now that it knows the user ID = cookies it might want to target, packet injects an exploit against any = desired user ID cookie... >>=20 >>=20 >> This enables the packet injection/exploitation system to leverage all = known user-identifying sites in the clear to target their exploitation = with high precision, even when the potential victim doesn't attempt to = visit the user identifying sites in the clear. >>=20 >>=20 >>=20 >> The requirements for ANY intelligence service to do this to target = YOU are: >>=20 >> a) They must see ONE web request from you in the clear pass ONE of = their wiretaps when they consider you "just might be a possible target" >>=20 >> b) They must see ONE of the user-identifying web requests pass ONE = of their wiretaps, and you must be logged into that site. >>=20 >>=20 >> As you can imagine, the set of possible actors able to do this = actually ends up being pretty darn big... >>=20 >> The IETF needs to work for HTTPS-only, NOW, out of simple self = defense. >>=20 >>=20 >> -- >> Nicholas Weaver it is a tale, told by an idiot, >> nweaver@icsi.berkeley.edu full of sound and fury, >> 510-666-2903 .signifying nothing >> PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc >>=20 >> _______________________________________________ >> perpass mailing list >> perpass@ietf.org >> https://www.ietf.org/mailman/listinfo/perpass >=20 --Apple-Mail=_B584DE1B-C7FD-46C0-9135-4BF295BAE7EE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii And = this time *with* the link... I hate it when I do = that.

Robin

On 11 Dec 2013, at = 17:23, Robin Wilton wrote:

Thanks Nicholas - this is = useful and relevant analysis.

In case you haven't = already seen it, this piece about some new research (at Stanford... = sorry ;^)  ) gives a similarly worrying perspective on the role of = "hub" sites in expanding the scope of the "three hops" rule. Your Step 2 = is, I think, a very similar mechanism, and has significant privacy = impact.

Yrs.,
Robin

Robin = Wilton
Technical Outreach Director - Identity and = Privacy
Internet Society

Phone: +44 = 705 005 2931
Twitter: = @futureidentity




On 11 Dec 2013, at 16:43, Nicholas Weaver wrote:


Cookies and user tracking are wonderful things. =  If you are a intelligence service, that is.

Its now clear = that the NSA (and, remember, any other intelligence service that might = see such traffic can do the same thing) uses cookies/advertising for = both tracking (e.g. HAPPYFOOT: Advertisement libraries (esp on Android) = which broadcast location + IMEI in the clear -> easy user tracking) = and targeting (e.g. Know the victim's google PREFID cookie through other = means, then use it to target exploitation:

http://apps.washingtonpost.= com/g/page/national/nsa-signal-surveillance-success-stories/647/#document/= p3/a135602

http://www.washington= post.com/blogs/the-switch/wp/2013/12/10/nsa-uses-google-cookies-to-pinpoin= t-targets-for-hacking/
)

Everyone on this list should now = consider themselves an in-scope target from at least one foreign = intelligence service...


But the intelligence services can do = even better if they want.  Here's how:

The NSA or foreign = intelligence wiretap has a possible candidate for attack, but not = probable.  That is, they THINK they may want to do an exploitation = attack but aren't sure...


1)  On the packet-injecting = wiretap, it sees a possible candidate and it does a packet injection of = a 302 redirect to a "User ID" script on the exploit server for something = inconsequentially small.


2)  The user-ID script creates = a hidden iframe.

Within that iframe, it opens up a bunch of other = iframes to various sites, e.g.www.youtube.com,www.linkedin.com, www.yahoo.com, slashdot.org, etc.  Namely ANLY = (and well, all) sites which

a)  Identifies the user in the = response

b)  Uses a user-identifying cookie that can be sent = in the clear.

This causes the possible victim's browser to visit = all these sites, identifying the victim to any wiretap that can see = it.


3)  Back on the packet-injecting wiretap, it looks = for request/response pairs to the targeted sites, using the request to = extract the user ID cookies and the response to match the user = identification by quick & dirty parsing of the HTML in the = response.

Since the wiretap knows the user identifications it = wants to exploit, it now knows the user ID cookies it wants to exploit = as well.


4)  Back on the user-ID script, after a ~10 = second delay, it then creates a second set of iframes to the various = sites for different URLs.  This causes the possible victim's = browser to revisit all the sites.  These requests contain the = user's ID cookies, which any wiretap has now been able to map to "is = this the actual person I want to target"


5)  The packet = injecting wiretap, now that it knows the user ID cookies it might want = to target, packet injects an exploit against any desired user ID = cookie...


This enables the packet injection/exploitation = system to leverage all known user-identifying sites in the clear to = target their exploitation with high precision, even when the potential = victim doesn't attempt to visit the user identifying sites in the = clear.



The requirements for ANY intelligence service to = do this to target YOU are:

a)  They must see ONE web request = from you in the clear pass ONE of their wiretaps when they consider you = "just might be a possible target"

b)  They must see ONE of = the user-identifying web requests pass ONE of their wiretaps, and you = must be logged into that site.


As you can imagine, the set of = possible actors able to do this actually ends up being pretty darn = big...

The IETF needs to work for HTTPS-only, NOW, out of simple = self defense.


--
Nicholas Weaver =             &n= bsp;    it is a tale, told by an idiot,
nweaver@icsi.berkeley.edu =             &n= bsp;  full of sound and fury,
510-666-2903 =             &n= bsp;           &nbs= p;       .signifying nothing
PGP: = http:= //www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc

________= _______________________________________
perpass mailing list
perpass@ietf.org
https://www.ietf.= org/mailman/listinfo/perpass

<= /blockquote>

= --Apple-Mail=_B584DE1B-C7FD-46C0-9135-4BF295BAE7EE-- From bortzmeyer@nic.fr Mon Dec 16 00:11:48 2013 Return-Path: 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 0F5691AE0D9 for ; Mon, 16 Dec 2013 00:11:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, RP_MATCHES_RCVD=-0.538] 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 I1ifCLsjKrkX for ; Mon, 16 Dec 2013 00:11:40 -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 481F11AE193 for ; Mon, 16 Dec 2013 00:11:39 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 5EF212806CF; Mon, 16 Dec 2013 09:11:37 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx4.nic.fr (Postfix) with ESMTP id 59A9B2806CC; Mon, 16 Dec 2013 09:11:37 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [IPv6:2001:67c:1348:8::7:113]) by relay2.nic.fr (Postfix) with ESMTP id 57B4CB3800C; Mon, 16 Dec 2013 09:11:07 +0100 (CET) Date: Mon, 16 Dec 2013 09:11:07 +0100 From: Stephane Bortzmeyer To: Russ Mundy Message-ID: <20131216081107.GA21632@nic.fr> References: <52A050E7.8010405@uni-due.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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, =?utf-8?B?TWF0dGjDpHVz?= Wander Subject: Re: [perpass] A reminder, the Network is the Enemy... 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2013 08:11:48 -0000 On Thu, Dec 05, 2013 at 10:35:30AM -0500, Russ Mundy wrote a message of 67 lines which said: > I've seen some references on this list saying (essentially) that it > is a valid assumption that an "attacker" ("unauthorized entity" > might be a better term) can get or already has the DNS root (& maybe > .com) private key. Small fix: I did not say so (the root private key is in an HSM and presumably, nobody, not even the NSA, can take it out). I said "the NSA can probably sign arbitrary data with the private key of the root". In practice, it has the same consequences. But it is a common mistake when people assert the security of things like domain name registries. You don't need to hold the private key, you just need the ability to feed data to the signer and get the result, which is typically much easier. From TurnerS@ieca.com Mon Dec 16 06:08:10 2013 Return-Path: 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 2888B1AE328 for ; Mon, 16 Dec 2013 06:08:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.566 X-Spam-Level: X-Spam-Status: No, score=-1.566 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 wG6YittYCI6a for ; Mon, 16 Dec 2013 06:08:05 -0800 (PST) Received: from gateway09.websitewelcome.com (gateway09.websitewelcome.com [69.93.154.26]) by ietfa.amsl.com (Postfix) with ESMTP id 6B71C1ADFE5 for ; Mon, 16 Dec 2013 06:08:05 -0800 (PST) Received: by gateway09.websitewelcome.com (Postfix, from userid 507) id B056712085820; Mon, 16 Dec 2013 08:08:04 -0600 (CST) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway09.websitewelcome.com (Postfix) with ESMTP id 7B5D312085716 for ; Mon, 16 Dec 2013 08:08:04 -0600 (CST) Received: from [198.180.150.142] (port=52937 helo=v142.vpn.iad.rg.net) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1VsYq3-0000mc-Oe for perpass@ietf.org; Mon, 16 Dec 2013 08:08:04 -0600 From: Sean Turner Content-Type: multipart/signed; boundary="Apple-Mail=_AFBFF60D-C917-496C-AF3F-0027B6722938"; protocol="application/pkcs7-signature"; micalg=sha1 Date: Mon, 16 Dec 2013 09:08:01 -0500 References: <52AA44A4.9060608@bbn.com> To: perpass Message-Id: Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) X-Mailer: Apple Mail (2.1822) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 198.180.150.142 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (v142.vpn.iad.rg.net) [198.180.150.142]:52937 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 2 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Subject: [perpass] Fwd: here's my message to perpass from yesterday, see any problems with it? 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2013 14:08:10 -0000 --Apple-Mail=_AFBFF60D-C917-496C-AF3F-0027B6722938 Content-Type: multipart/alternative; boundary="Apple-Mail=_22D88439-0431-4B76-917E-92F60F0DB12A" --Apple-Mail=_22D88439-0431-4B76-917E-92F60F0DB12A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Forwarding on behalf on Steve Kent. spt > -------- Original Message -------- > Subject: My comments on aft-farrell-perpass-attack-02.txt seem to = post here, so ... > Date: Wed, 11 Dec 2013 11:13:20 -0500 > From: Stephen Kent > To: perpass >=20 > I have several concerns about this I-D = (draft-farrell-perpass-attack-02.txt), as currently written. I do not = support publication of the document in its current form. >=20 > I think this document should include a clear description of what the = IETF considers to be =93pervasive monitoring=94 (PM) and how it differs = form the informal security model we have (often implicitly) used for = many years. Even the term =93pervasive=94 needs to be clarified here, as = there are two definitions one finds via a quick search: >=20 > Merriam-Webster: =93existing in or spreading through every part of = something=94 >=20 > Oxford Dictionaries: =93=85 spreading widely throughout an area ..=94 >=20 > If we mean to imply the former definition, we leave ourselves open to = criticism by those who will argue that the monitoring of which we have = been made aware is not literally through every part of the Internet. The = second definition seems more appropriate, i.e., the sense of widespread = monitoring. >=20 > For many years the IETF security community has used an attack model = that envisions an adversary who can engage in passive and active = wiretapping at any point along a communication path. We commonly also = attribute the ability to engage in MiTM attacks to such an = adversary. Thus we have long believed that plaintext communications are = vulnerable to passive wiretapping along a communication path if the = content is not protected via encryption. We also have noted that, for = staged delivery applications, e.g., mail, content is vulnerable to = disclosure and modification in storage, especially en route. In response = to this model we have developed a set of security protocols, (e.g., = IPsec, TLS, DTLS, S/MIME, SSH, etc.) that can be used to protect = transmitted content against passive wiretapping, based on use of = encryption. These protocols also usually incorporate data integrity and = authentication mechanisms, and, where appropriate, anti-replay = mechanisms, to address MiTM attacks. Thus we have offered users and = system designers a set of tools that address the adversarial = capabilities based on our model.=20 >=20 > When pervasive monitoring is effected via passive wiretapping, or a = mix of active and passive wiretapping (e.g., using packet injection = attacks) it is not a new class of attack. It is precisely what we have = long considered when designing security protocols. Thus I believe this = document should include comments of the sort noted above, to help = establish a context for this declaration about =93pervasive monitoring=94.= =20 >=20 > Having established this context, the next task is to explain why = pervasive monitoring is significantly different from our long-standing = model. The extent of such monitoring seems much bigger in scope than = folks may have imagined, given that intelligence services of numerous = countries have been identified as carrying on such monitoring. I think = this document needs to explain, in a technical context, why what = pervasive monitoring is qualitatively different, and thus merits this = declaration. We ought not lead readers to believe that we have not = tended to consider passive and active wiretapping as likely attacks in = the past. >=20 > Some of the reported forms of pervasive monitoring may have involved = the cooperation of or subversion of an ISP or a telecom provider. This = is not a qualitatively different form of attack from the generic passive = wiretapping that out informal security model has always assumed. If we = had articulated a threat model, in which we discuss adversaries, = motivations and capabilities, we could either cite it here or cite the = need to revise it based on recent revelations. Unfortunately, I don=92t = recall the IETF having ever published such a document :-). Anyway, here = too it is important that readers be told that this way of effecting a = passive wiretapping attack is not new, relative to the attack model we = adopted long ago. >=20 > Some of the reported forms of pervasive monitoring have involved the = cooperation of or subversion of application service providers. If = attacks take place at a point after which IETF protocols terminate, then = it seems to be largely outside of our purview as a protocol-focused = standards organization. For example, if I access e-mail via a web = interface at an MSP, IETF security standards largely do not seem to = apply to vulnerabilities associated with storage of the mail at the MSP; = my mail can=92t be protected e-t-e because I=92m not using S/MIME to = read the mail. I can use TLS to protect the HTTPS session via which I = access messages, and we can recommend that TLS be used with SMTP to = deliver the mail to the MSP, but that seems to be the limit of our = security protocols. So, again, cooperation or coercion of app service = providers is not a new, unanticipated form of attack. >=20 > I described this example because I think this document should = acknowledge, explicitly, that there are limits to the scope of what the = IETF can/should do in responding to pervasive monitoring. The IETF is = not responsible for all aspects of Internet security. To first order, we = develop protocols and thus we should focus on security mechanisms = offered by implementations of those protocols. We may choose to issue = guidance that goes beyond our standards, but we ought to be very careful = in so doing. >=20 > I believe this document should include a discussion about what we = perceive to be the scope of IETF standards for security in the context = of pervasive monitoring. You could note, for example, that the IEEE is = responsible for encryption standards for WiFi. ETSI and 3GPP have been = responsible for over the air encryption standards for cellular devices. = The W3C may be the more appropriate venue for some web security topics, = e.g., beyond the scope of HTTPS. I realize that we do, sometimes, = generate RFCs that call for security-relevant actions by hosts, e.g., = random number generation guidance. And we sometimes provide = implementation guidance in support of security. But these documents = don=92t address host security as their primary focus, so there do seem = to be limits to what we consider to be in scope.=20 >=20 > The security focus of most of our security protocols has been = protection of (application layer) content. A few security protocols, = e.g., ESP, do offer optional traffic flow confidentiality security, but = most do not. We have considered it a secondary concern, one that we = believe most users would not see as important. Few of our security = standards address confidentiality of communication metadata. So, this = document could state that, in light of revelations about pervasive = monitoring, the IETF will revisit our assumptions about the need for = metadata confidentiality in our architecture. That might be a good = justification for why pervasive monitoring is qualitatively different = from our previous security model. >=20 > The discussion of the term "attack" is necessary and useful. However, = the document elects to refer to pervasive monitoring as one attack, even = while acknowledging that it may require multiple, coordinated attacks = of different sorts. This muddies the discussion, from a technical = perspective. I'd prefer to see a discussion of the sort I outlined = above, which is a bit more precise. While I agree that we ought to = consider commercial privacy-violating activities at the same time that = we explore countermeasures to nation-state and criminal violations of = confidentiality, I believe that the document, as worded, conflates the = two too much.=20 >=20 > Others have already commented that the term "mitigate" is overused = here. I agree. We're going to develop new countermeasures, or remind = folks of existing ones that are not being used. The use of these = countermeasures will help mitigate attacks. Countermeasures are not all = encompassing, contrary to what the text states. A protocol may have one = or more vulnerabilities, in its design and/or implementation. An attack = exploits one or more vulnerabilities. A countermeasure thwarts one or = more types of attacks. It does not cause vulnerabilities to go away, nor = does it thwart all possible attacks. >=20 > The security considerations section says that privacy is the focus of = the document, but does not define the term or provide a cite. I think = security should be the primary focus of this document, emphasizing = confidentiality, a term with a technical definition that typically used = in well-written IETF security standards. > If this document is going to stand as a declaration of principle in = terms of an IETF response to pervasive monitoring, it needs to be = carefully worded, technically accurate, and persuasive. >=20 > Steve=20 >=20 >=20 --Apple-Mail=_22D88439-0431-4B76-917E-92F60F0DB12A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Forwarding on behalf on Steve = Kent.

spt


-------- Original Message --------
Subject: My comments on aft-farrell-perpass-attack-02.txt seem to post here, so ...
Date: Wed, 11 Dec 2013 11:13:20 -0500
From: Stephen Kent <kent@bbn.com>
To: = perpass <perpass@ietf.org>


I have several concerns about this I-D (draft-farrell-perpass-attack-02.txt), as currently written. I do not support publication of the document in its current form.

I think this document should include a clear description of what the IETF considers to be =93pervasive monitoring=94 (PM) and how it = differs form the informal security model we have (often implicitly) used for many years. Even the term =93pervasive=94 needs to be clarified here, as there are two definitions one finds via a quick search:

Merriam-Webster: =93existing in or spreading through every part of something=94

Oxford Dictionaries: =93=85 spreading widely throughout an area ..=94

If we mean to imply the former definition, we leave ourselves open to criticism by those who will argue that the monitoring of which we have been made aware is not literally through every part of the Internet. The second definition seems more appropriate, i.e., the sense of widespread monitoring.

For many years the IETF security community has used an attack model that envisions an adversary who can engage in passive and active wiretapping at any point along a communication path. We commonly also attribute the ability to engage in MiTM attacks to such an adversary. Thus we have long believed that plaintext communications are vulnerable to passive wiretapping along a communication path if the content is not protected via encryption. We also have noted that, for staged delivery applications, e.g., mail, content is vulnerable to disclosure and modification in storage, especially en route. In response to this model we have developed a set of security protocols, (e.g., IPsec, TLS, DTLS, S/MIME, SSH, etc.) that can be used to protect transmitted content against passive wiretapping, based on use of encryption. These protocols also usually incorporate data integrity and authentication mechanisms, and, where appropriate, anti-replay mechanisms, to address MiTM attacks. Thus we have offered users and system designers a set of tools that address the adversarial capabilities based on our model.

When pervasive monitoring is effected via passive wiretapping, or a mix of active and passive wiretapping (e.g., using packet injection attacks) it is not a new class of attack. It is precisely what we have long considered when designing security protocols. Thus I believe this document should include comments of the sort noted above, to help establish a context for this declaration about =93pervasive monitoring=94.

Having established this context, the next task is to explain why pervasive monitoring is significantly different from our long-standing model. The extent of such monitoring seems much bigger in scope than folks may have imagined, given that intelligence services of numerous countries have been identified as carrying on such monitoring. I think this document needs to explain, in a technical context, why what pervasive monitoring is qualitatively different, and thus merits this declaration. We ought not lead readers to believe that we have not tended to consider passive and active wiretapping as likely attacks in the past.

Some of the reported forms of pervasive monitoring may have involved the cooperation of or subversion of an ISP or a telecom provider. This is not a qualitatively different form of attack from the generic passive wiretapping that out informal security model has always assumed. If we had articulated a threat model, in which we discuss adversaries, motivations and capabilities, we could either cite it here or cite the need to revise it based on recent revelations. Unfortunately, I don=92t recall the = IETF having ever published such a document :-).  Anyway, here = too it is important that readers be told that this way of effecting a passive wiretapping attack is not new, relative to the attack model we adopted long ago.

Some of the reported forms of pervasive monitoring have involved the cooperation of or subversion of application service providers. If attacks take place at a point after which IETF protocols terminate, then it seems to be largely outside of our purview as a protocol-focused standards organization. For example, if I access e-mail via a web interface at an MSP, IETF security standards largely do not seem to apply to vulnerabilities associated with storage of the mail at the MSP; my mail can=92t be protected e-t-e because I=92m not = using S/MIME to read the mail. I can use TLS to protect the HTTPS session via which I access messages, and we can recommend that TLS be used with SMTP to deliver the mail to the MSP, but that seems to be the limit of our security protocols. So, again, cooperation or coercion of app service providers is not a new, unanticipated form of attack.

I described this example because I think this document should acknowledge, explicitly, that there are limits to the scope of what the IETF can/should do in responding to pervasive monitoring. The IETF is not responsible for all aspects of Internet security. To first order, we develop protocols and thus we should focus on security mechanisms offered by implementations of those protocols. We may choose to issue guidance that goes beyond our standards, but we ought to be very careful in so = doing.

I believe this document should include a discussion about what we perceive to be the scope of IETF standards for security in the context of pervasive monitoring. You could note, for example, that the IEEE is responsible for encryption standards for WiFi. ETSI and 3GPP have been responsible for over the air encryption standards for cellular devices. The W3C may be the more appropriate venue for some web security topics, e.g., beyond the scope of HTTPS. I realize that we do, sometimes, generate RFCs that call for security-relevant actions by hosts, e.g., random number generation guidance. And we sometimes provide implementation guidance in support of security. But these documents don=92t address host security as their primary = focus, so there do seem to be limits to what we consider to be = in  scope.

The security focus of most of our security protocols has been = protection  of (application = layer) content. A few security protocols, e.g., ESP, do offer optional traffic flow confidentiality security, but most do not. We have considered it a secondary concern, one that we believe most users would not see as important. Few of our security standards address confidentiality of communication metadata. So, this document could state that, in light of revelations about pervasive monitoring, the IETF will revisit our assumptions about the need for metadata confidentiality in our architecture. That might be a good justification for why pervasive monitoring is qualitatively different from our previous security model.

The discussion of the term "attack" is necessary and useful. However, the document elects to refer to pervasive monitoring as one attack, even while acknowledging that it may require multiple, coordinated  attacks of different sorts. This muddies the discussion, from a technical perspective. I'd prefer to see a discussion of the sort I outlined above, which is a bit more precise. While I agree that we ought to consider commercial privacy-violating activities at the same time that we explore countermeasures to nation-state and criminal violations of confidentiality, I believe that the document, as worded, conflates the two too much.

Others have already commented that the term "mitigate" is overused here. I agree. We're going to develop new countermeasures, or remind folks of existing ones that are not being used. The use of these countermeasures will help mitigate attacks. Countermeasures are not all encompassing, contrary to what the text states. A protocol may have one or more vulnerabilities, in its design and/or implementation. An attack exploits one or more vulnerabilities. A countermeasure thwarts one or more types of attacks. It does not cause vulnerabilities to go away, nor does it thwart all possible attacks.

The security considerations section says that privacy is the focus of the document, but does not define the term or provide a cite. I think security should be the primary focus of this document, emphasizing confidentiality, a term with a technical definition that typically used in well-written IETF security = standards.

If this document is going to stand as a declaration of principle in terms of an IETF response to pervasive monitoring, it needs to be carefully worded, technically accurate, and persuasive. =

Steve



= --Apple-Mail=_22D88439-0431-4B76-917E-92F60F0DB12A-- --Apple-Mail=_AFBFF60D-C917-496C-AF3F-0027B6722938 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIEgDCCBHww ggJkoAMCAQICCQCdWMxKNutUeTANBgkqhkiG9w0BAQsFADAiMQswCQYDVQQGEwJVUzETMBEGA1UE ChMKSUVDQSwgSW5jLjAeFw0xMzA0MDMxNDUxMThaFw0xNDA0MDMxNDUxMThaMDgxCzAJBgNVBAYT AlVTMRMwEQYDVQQKEwpJRUNBLCBJbmMuMRQwEgYDVQQDEwtTZWFuIFR1cm5lcjCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAOpCGCRptT1m+bIpLTmbahZLZ0Qe4X99f8SgTQ7QISvUfpmn tfOD1oA1AttXlOULEERYubzvDnUTXvstFomQx0XTA67IaV+mw9ODRtG1hPN/erdKX6sU6rH4tsEb ba3Drr/I0HT3YVvD3SjWtGXjF12XLvTP6+LfMIIDTCAPiEd9KPG23D7skVu/4BvvmdLFI96OARhg wQ86M+lTIn83KRJlbbfAeIevbRx/rUB7D+uvMdWxOzR0KZJhd6dEeTXVwBXZG4rnQ4uFM+mRSiD4 rxDCyOuIuOzR07tnOyCRio6sRipOZvwQUWttdsgMEs6IxLdWsaTXcs1HjCsxrdedovMCAwEAAaOB njCBmzAOBgNVHQ8BAf8EBAMCBeAwHwYDVR0jBBgwFoAUAHRsSeXJUmFxTVY4q2HJ8uHl+w0wGwYD VR0RBBQwEoEQVHVybmVyU0BpZWNhLmNvbTAyBgNVHR8EKzApMCegJaAjhiFodHRwOi8vd3d3Lmll Y2EuY29tL2NybHMvaWVjYS5jcmwwFwYDVR0gBBAwDjAMBgorBgEEAYHXAAAAMA0GCSqGSIb3DQEB CwUAA4ICAQAimDYm77ppTi4vK6qJSUhyvCDMGb8mngiEXEYKxsfdHPWoDO7+06j7dAZ8sDD9/FtE kiUMyoNGSUmKHR+tGperVnNiM/Zk6WwCJv8dYZwhGXNQeEGzeys/UkFv7CFX7uDSn8GQeB8sOAZ1 N1hxV/TvT8qXvcRxP5+aWTAGAq3TKtCQxZjuU74L3st2hZiOhJlhjhqz0K5FIwWzXUK9uwhZe1th GUpDbRustVgmKN2Xa0pzwqI1VUO0jnWt24A4u59xo6DJQXzQVMhCx0xhpemuT9BrsBDTX8eJdI1i Wv9wp3ivSrfHjKXp8y8OGD+usiG40HCjj0W9C+dH0VfbgrB6QOI4vA9+kTg4mANth1cxyxwPYOSJ v0zi1qR0eDIGI//2v2/s6TmGuNqbnRa26Ldv5gGqS7xj32Fiaby6UOXs4+aAIWGZEOH+BXjozcvE eGBwjU/VRQYu6itR28PaNhNVji4D5ITaGxWWiycqK1EUaFraWHtk7W100ROX69xTeFVZP86D2ymi /aohl5Vb1vlYHdqlbgqjDRl9dPbTxVCXEHf+jkexcuwlLTvr7F+5DIN6c/EbCpRqQx3edy193L48 OGyRDh1/Wmzpew0VWWAWOSXGl/P9VzXf3Z6GPt7flN/V9iEJAa3Mo+w+eIdzJkHBWR+yJcqQcCRM MSyishMwLDGCAjgwggI0AgEBMC8wIjELMAkGA1UEBhMCVVMxEzARBgNVBAoTCklFQ0EsIEluYy4C CQCdWMxKNutUeTAJBgUrDgMCGgUAoIHfMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEzMTIxNjE0MDgwMlowIwYJKoZIhvcNAQkEMRYEFDqbRpJ/VisYkIBLABP0uxcG aBMGMD4GCSsGAQQBgjcQBDExMC8wIjELMAkGA1UEBhMCVVMxEzARBgNVBAoTCklFQ0EsIEluYy4C CQCdWMxKNutUeTBABgsqhkiG9w0BCRACCzExoC8wIjELMAkGA1UEBhMCVVMxEzARBgNVBAoTCklF Q0EsIEluYy4CCQCdWMxKNutUeTANBgkqhkiG9w0BAQEFAASCAQBuDSMPftZgpfXn2A2Umun0kO9A 9AeQ48F3bIkcXQ9wBNzoe6y6RVRsMw7URu1zLZiFenROMxesY/qPPlrUA1rYyONI9TvzSn6NCSaG +WBjx4Wb2saJNZNjL9rpAjl2h0bbKNLKF3zzjqTWHjDOkRi2H05+wT03MmUi3nYJlw0lIm6xLdnt djHoQqWj/trp4r8iOPhMfOz0KzyStPSNZF8vfvZfB6qYi0TKw9QNV5OIiqkT3/SU2WjxsAvjWb7T 0lNlsWMBhofaNoVtigVLICxMvb0J/foIZG9o0FelqAgepl0Lns/FM+N9kk2lht4itRnKL+Xg1h/l 132akk6UlUtcAAAAAAAA --Apple-Mail=_AFBFF60D-C917-496C-AF3F-0027B6722938-- From stephen.farrell@cs.tcd.ie Mon Dec 16 06:19:08 2013 Return-Path: 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 4FE301AE330 for ; Mon, 16 Dec 2013 06:19:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] 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 MSy7g7Qzgidh for ; Mon, 16 Dec 2013 06:19:06 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id A0DBC1AE323 for ; Mon, 16 Dec 2013 06:19:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C1C20BE59; Mon, 16 Dec 2013 14:19:04 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5aV4cxehdOMZ; Mon, 16 Dec 2013 14:19:04 +0000 (GMT) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A8C5EBE3F; Mon, 16 Dec 2013 14:19:04 +0000 (GMT) Message-ID: <52AF0BD8.2060503@cs.tcd.ie> Date: Mon, 16 Dec 2013 14:19:04 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Sean Turner , perpass References: <52AA44A4.9060608@bbn.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Subject: Re: [perpass] Fwd: here's my message to perpass from yesterday, see any problems with it? 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2013 14:19:08 -0000 On 12/16/2013 02:08 PM, Sean Turner wrote: > Forwarding on behalf on Steve Kent. Ta. That did make it to the ietf list over the weekend and I replied, but whatever's gumming up the system for Steve also hit my reply;-) The IETF list is the right place for the discussion though rather than this list I think so if folks can wait a while until we unstick whatever's gummed up that'd be good. I'll send mail when I think that's done. (I figure there's some spam filter somewhere that's messing up or something, based on the ticket I saw generated.) S. > > spt > > >> -------- Original Message -------- >> Subject: My comments on aft-farrell-perpass-attack-02.txt seem to post here, so ... >> Date: Wed, 11 Dec 2013 11:13:20 -0500 >> From: Stephen Kent >> To: perpass >> >> I have several concerns about this I-D (draft-farrell-perpass-attack-02.txt), as currently written. I do not support publication of the document in its current form. >> >> I think this document should include a clear description of what the IETF considers to be “pervasive monitoring” (PM) and how it differs form the informal security model we have (often implicitly) used for many years. Even the term “pervasive” needs to be clarified here, as there are two definitions one finds via a quick search: >> >> Merriam-Webster: “existing in or spreading through every part of something” >> >> Oxford Dictionaries: “… spreading widely throughout an area ..” >> >> If we mean to imply the former definition, we leave ourselves open to criticism by those who will argue that the monitoring of which we have been made aware is not literally through every part of the Internet. The second definition seems more appropriate, i.e., the sense of widespread monitoring. >> >> For many years the IETF security community has used an attack model that envisions an adversary who can engage in passive and active wiretapping at any point along a communication path. We commonly also attribute the ability to engage in MiTM attacks to such an adversary. Thus we have long believed that plaintext communications are vulnerable to passive wiretapping along a communication path if the content is not protected via encryption. We also have noted that, for staged delivery applications, e.g., mail, content is vulnerable to disclosure and modification in storage, especially en route. In response to this model we have developed a set of security protocols, (e.g., IPsec, TLS, DTLS, S/MIME, SSH, etc.) that can be used to protect transmitted content against passive wiretapping, based on use of encryption. These protocols also usually incorporate data integrity and authentication mechanisms, and, where appropriate, anti-replay mechanisms, to address MiTM atta cks. Thus we have offered users and system designers a set of tools that address the adversarial capabilities based on our model. >> >> When pervasive monitoring is effected via passive wiretapping, or a mix of active and passive wiretapping (e.g., using packet injection attacks) it is not a new class of attack. It is precisely what we have long considered when designing security protocols. Thus I believe this document should include comments of the sort noted above, to help establish a context for this declaration about “pervasive monitoring”. >> >> Having established this context, the next task is to explain why pervasive monitoring is significantly different from our long-standing model. The extent of such monitoring seems much bigger in scope than folks may have imagined, given that intelligence services of numerous countries have been identified as carrying on such monitoring. I think this document needs to explain, in a technical context, why what pervasive monitoring is qualitatively different, and thus merits this declaration. We ought not lead readers to believe that we have not tended to consider passive and active wiretapping as likely attacks in the past. >> >> Some of the reported forms of pervasive monitoring may have involved the cooperation of or subversion of an ISP or a telecom provider. This is not a qualitatively different form of attack from the generic passive wiretapping that out informal security model has always assumed. If we had articulated a threat model, in which we discuss adversaries, motivations and capabilities, we could either cite it here or cite the need to revise it based on recent revelations. Unfortunately, I don’t recall the IETF having ever published such a document :-). Anyway, here too it is important that readers be told that this way of effecting a passive wiretapping attack is not new, relative to the attack model we adopted long ago. >> >> Some of the reported forms of pervasive monitoring have involved the cooperation of or subversion of application service providers. If attacks take place at a point after which IETF protocols terminate, then it seems to be largely outside of our purview as a protocol-focused standards organization. For example, if I access e-mail via a web interface at an MSP, IETF security standards largely do not seem to apply to vulnerabilities associated with storage of the mail at the MSP; my mail can’t be protected e-t-e because I’m not using S/MIME to read the mail. I can use TLS to protect the HTTPS session via which I access messages, and we can recommend that TLS be used with SMTP to deliver the mail to the MSP, but that seems to be the limit of our security protocols. So, again, cooperation or coercion of app service providers is not a new, unanticipated form of attack. >> >> I described this example because I think this document should acknowledge, explicitly, that there are limits to the scope of what the IETF can/should do in responding to pervasive monitoring. The IETF is not responsible for all aspects of Internet security. To first order, we develop protocols and thus we should focus on security mechanisms offered by implementations of those protocols. We may choose to issue guidance that goes beyond our standards, but we ought to be very careful in so doing. >> >> I believe this document should include a discussion about what we perceive to be the scope of IETF standards for security in the context of pervasive monitoring. You could note, for example, that the IEEE is responsible for encryption standards for WiFi. ETSI and 3GPP have been responsible for over the air encryption standards for cellular devices. The W3C may be the more appropriate venue for some web security topics, e.g., beyond the scope of HTTPS. I realize that we do, sometimes, generate RFCs that call for security-relevant actions by hosts, e.g., random number generation guidance. And we sometimes provide implementation guidance in support of security. But these documents don’t address host security as their primary focus, so there do seem to be limits to what we consider to be in scope. >> >> The security focus of most of our security protocols has been protection of (application layer) content. A few security protocols, e.g., ESP, do offer optional traffic flow confidentiality security, but most do not. We have considered it a secondary concern, one that we believe most users would not see as important. Few of our security standards address confidentiality of communication metadata. So, this document could state that, in light of revelations about pervasive monitoring, the IETF will revisit our assumptions about the need for metadata confidentiality in our architecture. That might be a good justification for why pervasive monitoring is qualitatively different from our previous security model. >> >> The discussion of the term "attack" is necessary and useful. However, the document elects to refer to pervasive monitoring as one attack, even while acknowledging that it may require multiple, coordinated attacks of different sorts. This muddies the discussion, from a technical perspective. I'd prefer to see a discussion of the sort I outlined above, which is a bit more precise. While I agree that we ought to consider commercial privacy-violating activities at the same time that we explore countermeasures to nation-state and criminal violations of confidentiality, I believe that the document, as worded, conflates the two too much. >> >> Others have already commented that the term "mitigate" is overused here. I agree. We're going to develop new countermeasures, or remind folks of existing ones that are not being used. The use of these countermeasures will help mitigate attacks. Countermeasures are not all encompassing, contrary to what the text states. A protocol may have one or more vulnerabilities, in its design and/or implementation. An attack exploits one or more vulnerabilities. A countermeasure thwarts one or more types of attacks. It does not cause vulnerabilities to go away, nor does it thwart all possible attacks. >> >> The security considerations section says that privacy is the focus of the document, but does not define the term or provide a cite. I think security should be the primary focus of this document, emphasizing confidentiality, a term with a technical definition that typically used in well-written IETF security standards. >> If this document is going to stand as a declaration of principle in terms of an IETF response to pervasive monitoring, it needs to be carefully worded, technically accurate, and persuasive. >> >> Steve >> >> > > > > > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > From stephen.farrell@cs.tcd.ie Mon Dec 16 07:53:36 2013 Return-Path: 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 9619F1AE357 for ; Mon, 16 Dec 2013 07:53:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] 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 Wj3e99_a2X0I for ; Mon, 16 Dec 2013 07:53:35 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id CD3C21AE34D for ; Mon, 16 Dec 2013 07:53:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E2C55BE6E for ; Mon, 16 Dec 2013 15:53:33 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LXaVP8gow6rt for ; Mon, 16 Dec 2013 15:53:33 +0000 (GMT) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id C5EC0BE63 for ; Mon, 16 Dec 2013 15:53:33 +0000 (GMT) Message-ID: <52AF21FD.8060305@cs.tcd.ie> Date: Mon, 16 Dec 2013 15:53:33 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: perpass References: <52AA44A4.9060608@bbn.com> <52AF0BD8.2060503@cs.tcd.ie> In-Reply-To: <52AF0BD8.2060503@cs.tcd.ie> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [perpass] Fwd: here's my message to perpass from yesterday, see any problems with it? 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2013 15:53:36 -0000 On 12/16/2013 02:19 PM, Stephen Farrell wrote: > Ta. That did make it to the ietf list over the weekend > and I replied, but whatever's gumming up the system > for Steve also hit my reply;-) > > The IETF list is the right place for the discussion > though rather than this list I think so if folks can > wait a while until we unstick whatever's gummed up > that'd be good. I'll send mail when I think that's > done. (I figure there's some spam filter somewhere > that's messing up or something, based on the ticket > I saw generated.) The explanation arrived. My response to Steve's mail contained the string "route" at the end of a sentence, so then a full stop "." and was followed by a sentence that started with "In" but with no spaces between those. That was interpreted as a URI for somewhere naughty enough to apparently get the message a spam score sufficiently high that the message is just dropped. I just fixed that in my response and my mail is on the IETF discuss list [1] so follow up there if commenting further please. If you're also replying to Steve, [2] or to my reply, please watch out for rewrapping the text if you don't see your mail hit the list. What a world;-) S. [1] http://www.ietf.org/mail-archive/web/ietf/current/msg84998.html [2] http://www.ietf.org/mail-archive/web/ietf/current/msg84975.html From dhc@dcrocker.net Wed Dec 18 11:13:19 2013 Return-Path: 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 72A7D1AE0EB for ; Wed, 18 Dec 2013 11:13:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 WZVa-HAvOvmT for ; Wed, 18 Dec 2013 11:13:15 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id A5A301AE15B for ; Wed, 18 Dec 2013 11:13:11 -0800 (PST) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id rBIJCu8l015943 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 18 Dec 2013 11:12:59 -0800 Message-ID: <52B1F36E.7020704@dcrocker.net> Date: Wed, 18 Dec 2013 11:11:42 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Nicholas Weaver , Stephen Farrell References: <529E8494.7000806@perens.com> <20131204111309.GB11727@nic.fr> <529F61D8.6030105@perens.com> <20131204171207.GC19914@thunk.org> <529F63C0.3040804@perens.com> <529F88AC.3090904@appelbaum.net> <529F90A0.8000706@perens.com> <529F9205.30906@appelbaum.net> <529F98C0.9090808@perens.com> <529F9F14.8050805@appelbaum.net> <529FB61A.7090604@perens.com> <529FBEF9.7030205@appelbaum.net> <529FC347.3080806@perens.com> <52A15835.2070901@cis-india.org> <52A21B80.8070005@mykolab.com> <52A21D1C.8020000@perens.com> <52A2235A.2030801@perens.com> <240A2D86-C352-4954-BE4E-6313BA25994E@icsi.berkeley.edu> <52A2CE6A.30408@perens.com> <52A31F1D.7040509@cs.tcd.ie> <5D026682-5457-4F00-B139-58D8D718BB0A@icsi.berkeley.edu> In-Reply-To: <5D026682-5457-4F00-B139-58D8D718BB0A@icsi.berkeley.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Wed, 18 Dec 2013 11:13:02 -0800 (PST) Cc: perpass@ietf.org, Bruce Perens Subject: Re: [perpass] perens-perpass-appropriate-response-01 X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net 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: Wed, 18 Dec 2013 19:13:19 -0000 On 12/7/2013 7:48 AM, Nicholas Weaver wrote: > We do actually have a system for data integrity without confidentiality. Its called DNSSEC. Although 10 days later and just to get this into the record: It's also called DKIM. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From rlb@ipv.sx Wed Dec 18 11:50:51 2013 Return-Path: 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 67C991AE108 for ; Wed, 18 Dec 2013 11:50:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 J4e7bwPPgPOc for ; Wed, 18 Dec 2013 11:50:49 -0800 (PST) Received: from mail-oa0-f51.google.com (mail-oa0-f51.google.com [209.85.219.51]) by ietfa.amsl.com (Postfix) with ESMTP id C42A31AE0D1 for ; Wed, 18 Dec 2013 11:50:49 -0800 (PST) Received: by mail-oa0-f51.google.com with SMTP id i7so149512oag.24 for ; Wed, 18 Dec 2013 11:50:48 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ZffFjfamxsOGKcKwrr4NRD2El7jz5mmh8plhfcp+g/w=; b=AkETiBmQgW+UDltXvDLS2lxHWMSJcYWKGCtD+26Pn6JbaWFa7h0UALwLztOZCx6Yn5 clfFeFc4myI01Xq/oaTpKIsT5uAbMBqEAT+2GWlQfsvNbAlCcWkwqOZa3Ha5Uu17lhag IsAQB0MzNnoKUIjYA9QXr9WPqQv5yj2zRnWR+rouhv0u2yEw5STGMIiLIaeS7XSNyaQz CjABNcSZcO8klpnulnROsrWKU0FZmks9rJ66RT/JvQUrqUeMeCe6oH+bpjrQAwTjGtNC sWgpoQnuEdsXIs1uKdjS1LXcutLJhstbG4PRueNWibpcbF9LVkt0lMYwI1pCNnIZWZfT gQyg== X-Gm-Message-State: ALoCoQkXuTisQN1V9Mh936AsJW/8d22oXHeASkwPd4Ba3rXw7a/jrJZhfaq5RlKn1uGAcqCiR6df MIME-Version: 1.0 X-Received: by 10.60.33.196 with SMTP id t4mr2123728oei.81.1387396247899; Wed, 18 Dec 2013 11:50:47 -0800 (PST) Received: by 10.60.54.65 with HTTP; Wed, 18 Dec 2013 11:50:47 -0800 (PST) In-Reply-To: <52B1F36E.7020704@dcrocker.net> References: <529E8494.7000806@perens.com> <20131204111309.GB11727@nic.fr> <529F61D8.6030105@perens.com> <20131204171207.GC19914@thunk.org> <529F63C0.3040804@perens.com> <529F88AC.3090904@appelbaum.net> <529F90A0.8000706@perens.com> <529F9205.30906@appelbaum.net> <529F98C0.9090808@perens.com> <529F9F14.8050805@appelbaum.net> <529FB61A.7090604@perens.com> <529FBEF9.7030205@appelbaum.net> <529FC347.3080806@perens.com> <52A15835.2070901@cis-india.org> <52A21B80.8070005@mykolab.com> <52A21D1C.8020000@perens.com> <52A2235A.2030801@perens.com> <240A2D86-C352-4954-BE4E-6313BA25994E@icsi.berkeley.edu> <52A2CE6A.30408@perens.com> <52A31F1D.7040509@cs.tcd.ie> <5D026682-5457-4F00-B139-58D8D718BB0A@icsi.berkeley.edu> <52B1F36E.7020704@dcrocker.net> Date: Wed, 18 Dec 2013 14:50:47 -0500 Message-ID: From: Richard Barnes To: Dave Crocker Content-Type: multipart/alternative; boundary=089e01227fd286783004edd45c48 Cc: perpass , Nicholas Weaver , Bruce Perens , Stephen Farrell 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Dec 2013 19:50:51 -0000 --089e01227fd286783004edd45c48 Content-Type: text/plain; charset=ISO-8859-1 If we're going go enumerate these, there's also CMS Signed Data, JSON Web Signature, TLS_RSA_WITH_NULL_SHA256, etc., etc. I don't think that's really the point of the discussion, though. --Richard On Wed, Dec 18, 2013 at 2:11 PM, Dave Crocker wrote: > On 12/7/2013 7:48 AM, Nicholas Weaver wrote: > >> We do actually have a system for data integrity without confidentiality. >> Its called DNSSEC. >> > > > Although 10 days later and just to get this into the record: > > It's also called DKIM. > > d/ > > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net > > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > --089e01227fd286783004edd45c48 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
If we're going go enumerate these, there's also CM= S Signed Data, JSON Web Signature,=A0TLS_RSA_WITH_NULL_SHA256, etc., etc.

I don't think that's real= ly the point of the discussion, though.

--Richard

On Wed, Dec 18, 2013 at 2:11 PM, Dave Cr= ocker <dhc@dcrocker.net> wrote:
On 12/7/2013 7:48 AM, Nicholas Weaver wrote:
We do actually have a system for data integrity without confidentiality. = =A0Its called DNSSEC.


Although 10 days later and just to get this into the record:

=A0 =A0It's also called DKIM.

d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

_______________________________________________
perpass mailing list
perpass@ietf.org<= br> https://www.ietf.org/mailman/listinfo/perpass

--089e01227fd286783004edd45c48-- From dean.willis@softarmor.com Thu Dec 26 11:44:12 2013 Return-Path: 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 015361AE02F for ; Thu, 26 Dec 2013 11:44:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.102 X-Spam-Level: X-Spam-Status: No, score=-0.102 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 CeJqZutO1mfR for ; Thu, 26 Dec 2013 11:44:10 -0800 (PST) Received: from mail-pd0-x235.google.com (mail-pd0-x235.google.com [IPv6:2607:f8b0:400e:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id 9473B1ADFB4 for ; Thu, 26 Dec 2013 11:44:10 -0800 (PST) Received: by mail-pd0-f181.google.com with SMTP id p10so8235332pdj.26 for ; Thu, 26 Dec 2013 11:44:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=softarmor.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=NEXdHynKsjUCuSxyTXzsbhnse9BsiZzufED7XSspBIo=; b=EsWL0LlgSXfmKR9b0gqqmMN7QnYJgN5egs8ylg/+nfrpXS/R/KuS3bRKZnoopnzFaN Ns7NWk78hC48pO2+GOAgeJfKpksIYYDJ+guTYYNKhIh5rmMZdzJ+kKJHCt970SRfwB5y q1fE4exaDnryUC1wx371xLYZ7yW58v7cabkDU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=NEXdHynKsjUCuSxyTXzsbhnse9BsiZzufED7XSspBIo=; b=If65BGQW/Y+65/gM9VI67R29MFi4TJN+bdTWJ+f4nK9JNKFsQLaRH3nBxNGILL5HW5 ztZBS75pa1+/LKq1rUxsvXX9vAIn+vXRvPZ5N7eMEsDBRrV5kiTbpvpoijPWTnaDhy/E W8JDZCAQydneeFEM7n2WQr7afSGLCg/vxA7GN0YtzDVwDxgW54vZFkV7pb14MpDZajmz zsW8WI3epYpsix2Nj5oyrnU8Zoi3l8AI/6m30kdHf4qQEJWanBthqkCkUqnZiODE6KkJ YQ3RymFy+dE5kAvymOVMyL6j/nH0uw+qbf5D7DX1B2pwEIvV6qxBXrllh2aPC8fBbfgU pQjw== X-Gm-Message-State: ALoCoQlF/Nq0HcWMuwwOU05+B3sDw/KQNJUCw9g5aUIEzjHdJ/LlnId/JtZvrCcOgoObpZNt8su7 X-Received: by 10.66.221.199 with SMTP id qg7mr46665789pac.13.1388087045987; Thu, 26 Dec 2013 11:44:05 -0800 (PST) Received: from [192.168.2.112] (cpe-72-181-149-113.tx.res.rr.com. [72.181.149.113]) by mx.google.com with ESMTPSA id qw8sm57042714pbb.27.2013.12.26.11.44.04 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 26 Dec 2013 11:44:05 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Dean Willis In-Reply-To: <52A61E4C.6020403@gmail.com> Date: Thu, 26 Dec 2013 13:44:00 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <290E20B455C66743BE178C5C84F1240847E5103799@EXMB01CMS.surrey.ac.uk>, <2C66A416-5F07-4803-A4C0-BB61734BA42E@nominum.com> <290E20B455C66743BE178C5C84F1240847E510379A@EXMB01CMS.surrey.ac.uk>, <529F7690.2050302@gmx.net> <290E20B455C66743BE178C5C84F1240847E510379C@EXMB01CMS.surrey.ac.uk>, <52A1BBBC.9090509@cs.tcd.ie> <290E20B455C66743BE178C5C84F1240847E510379D@EXMB01CMS.surrey.ac.uk> <52A4D7D9.9000603@cs.tcd.ie>, <52A4E412.4030804@gmail.com> <72B86100-E73E-46BD-ABD6-8E35D56DBDDA@cisco.com> <52A61E4C.6020403@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1827) Cc: perpass , "Stewart Bryant \(stbryant\)" Subject: Re: [perpass] Tiny stacks 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Dec 2013 19:44:12 -0000 On Dec 9, 2013, at 1:47 PM, Brian E Carpenter = wrote: > On 09/12/2013 11:04, Stewart Bryant (stbryant) wrote: > (on a different list and under a differeny Subject header) > ... >=20 >> Remembering of course that some platforms which wish >> to use the Internet simply do not have the capability for >> other than a very tiny very basic stack. >>=20 >> I always use the PIC and the Arduino to remind myself what the >> lower end of the franchise looks like. >=20 > It seems to me that perpass should think a little bit about > privacy and anti-surveillance issues for devices with tiny > stacks, and see if that calls for any specific IETF work items. Always a good plan. You might enjoy one of my former student=92s books: =95 ASIN: B00GA2XKG8 Security for Wireless Sensor Networks using Identity-Based Cryptography = by Patil, Harsh Kupwade (Jan 14, 2013) From dhc@dcrocker.net Thu Dec 26 17:16:37 2013 Return-Path: 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 F0E871AE0CD for ; Thu, 26 Dec 2013 17:16:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3] 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 FfbKKWTJDrhj for ; Thu, 26 Dec 2013 17:16:36 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id EE9E31AE0CA for ; Thu, 26 Dec 2013 17:16:35 -0800 (PST) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id rBR1GRW8028860 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 26 Dec 2013 17:16:30 -0800 Message-ID: <52BCD497.20501@dcrocker.net> Date: Thu, 26 Dec 2013 17:15:03 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Nicholas Weaver References: <529E8494.7000806@perens.com> <20131204111309.GB11727@nic.fr> <529F61D8.6030105@perens.com> <20131204171207.GC19914@thunk.org> <529F63C0.3040804@perens.com> <529F88AC.3090904@appelbaum.net> <529F90A0.8000706@perens.com> <529F9205.30906@appelbaum.net> <529F98C0.9090808@perens.com> <529F9F14.8050805@appelbaum.net> <529FB61A.7090604@perens.com> <529FBEF9.7030205@appelbaum.net> <529FC347.3080806@perens.com> <52A15835.2070901@cis-india.org> <52A21B80.8070005@mykolab.com> <52A21D1C.8020000@perens.com> <52A2235A.2030801@perens.com> <240A2D86-C352-4954-BE4E-6313BA25994E@icsi.berkeley.edu> <52A2CE6A.30408@perens.com> <52A31F1D.7040509@cs.tcd.ie> <5D026682-5457-4F00-B139-58D8D718BB0A@icsi.berkeley.edu> In-Reply-To: <5D026682-5457-4F00-B139-58D8D718BB0A@icsi.berkeley.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Thu, 26 Dec 2013 17:16:30 -0800 (PST) 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 Reply-To: dcrocker@bbiw.net 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: Fri, 27 Dec 2013 01:16:37 -0000 On 12/7/2013 7:48 AM, Nicholas Weaver wrote: > So the idea of "authentication problem rather than a confidentiality > one" is a red herring: We have a solution that solves the > authentication problem for HTTP. Its called TLS. We MUST use it > everywhere, if only to protect US citizens from the French and > Chinese, and Russians, and Brazilians, and Israelis... Except that it solves only a narrow case of authentication. It's a hop-by-hop solution and mostly authenticates the server, rather than the data the server is feeding the client. For the data the server truly is creating, that's probably ok. For data it's merely relaying, on behalf of the actual author, it's probably not. So while, yes, authenticating the content is more hassle, it's also more meaningful. And therefore, contrary to Richard's assessment, I think the question of widely-used content-based authentication mechanisms is relevant, specifically because it demonstrates the viability of actual, end-to-end identification, rather than hop-by-hop (and therefore within-relay-exposed) channel-based approaches. The question then is not what mechanisms exist, but what mechanisms are actually in widespread use. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net -- Dave Crocker Brandenburg InternetWorking bbiw.net From dean.willis@softarmor.com Thu Dec 26 22:24:28 2013 Return-Path: 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 5B0FC1AECA9 for ; Thu, 26 Dec 2013 22:24:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.521 X-Spam-Level: X-Spam-Status: No, score=0.521 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-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 KFQhde_OngBc for ; Thu, 26 Dec 2013 22:24:27 -0800 (PST) Received: from mail-vc0-x22c.google.com (mail-vc0-x22c.google.com [IPv6:2607:f8b0:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id E78551AECA8 for ; Thu, 26 Dec 2013 22:24:26 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id ij19so4638293vcb.31 for ; Thu, 26 Dec 2013 22:24:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=softarmor.com; s=google; h=mime-version:date:message-id:subject:from:to:content-type; bh=vAaoUf7WA5E4mBa2u9EU5W2XpjydZ1qCrQX+EsyKvzk=; b=B0TD66RAvR5pKvn1YdzfhMDiYh4mM4Tah2t+7cJZADp84MV+6vBPHdSEQqXAMSf4Hr /fPZ3IqSK/xT8VeRuj07ul42VkSUGdgRkKoy8pu1h7rh34B+Jo3itwbZ9hmPhfHdvpX4 cb3bTPsEkDPAmLA6fTVxHV3xx/Y0HU6Bh0xFc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=vAaoUf7WA5E4mBa2u9EU5W2XpjydZ1qCrQX+EsyKvzk=; b=YfhIhCKj1gYb6Rbl8Av0vGjHYgX0Yf+28j23KTWk9n6LFuBvSAmDGdoaKMxnSi46+1 p+4iVQHArs+1pRKZDKD5hIvxV2Exgj972daaayU6bkwfGmIPurk8lHzfx+va4jTaLzqe Z9x+i1UeLzPIbCq4YS9yJ60oo3KmmGfBo7F6mO3v6MezdlYbA5jPOnSYSyYcwMiq3i6h 9nHmFsyK1rLbffMFk3LzhuZ3db6P1JXwXWnvhy5cH9hoS7N3KwudrXfj14xai1wVivK5 MbOC2ttS7Zv2d7/il3wGyWbqErSCtoNbb2w4KlUn+eYRKQnQou25oQDoA7fhOIci0zKt 9FJQ== X-Gm-Message-State: ALoCoQmHZwVWkyGSb5JddYgTNrjtf5/2Oy9wGauTFUG1fBNDjBabb0TwY2UsCYL7K9UDIRBqTsMi MIME-Version: 1.0 X-Received: by 10.52.248.238 with SMTP id yp14mr163615vdc.81.1388125462057; Thu, 26 Dec 2013 22:24:22 -0800 (PST) Received: by 10.58.56.4 with HTTP; Thu, 26 Dec 2013 22:24:22 -0800 (PST) Received: by 10.58.56.4 with HTTP; Thu, 26 Dec 2013 22:24:22 -0800 (PST) Date: Fri, 27 Dec 2013 00:24:22 -0600 Message-ID: From: Dean Willis To: perpass Content-Type: multipart/alternative; boundary=089e0149bdbe11f03204ee7e256f Subject: [perpass] Don't forget St. Nsaclaus' cookies 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Dec 2013 06:24:28 -0000 --089e0149bdbe11f03204ee7e256f Content-Type: text/plain; charset=ISO-8859-1 Article link, cookies combined with leaky non-enc location data target users for exploits. Encrypt everything, dude! "NSA reportedly leveraging Google cookies and leaked mobile location data to identify hacking targets" http://feedly.com/k/1co0lQ5 --089e0149bdbe11f03204ee7e256f Content-Type: text/html; charset=ISO-8859-1

Article link, cookies combined with leaky non-enc location data target users for exploits. Encrypt everything, dude!

"NSA reportedly leveraging Google cookies and leaked mobile location data to identify hacking targets" http://feedly.com/k/1co0lQ5

--089e0149bdbe11f03204ee7e256f-- From bruce@perens.com Thu Dec 26 23:48:55 2013 Return-Path: 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 491BD1AE183 for ; Thu, 26 Dec 2013 23:48:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538] 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 CYuDKqiprIJN for ; Thu, 26 Dec 2013 23:48:54 -0800 (PST) Received: from alchemy.perens.com (alchemy.perens.com [206.221.219.26]) by ietfa.amsl.com (Postfix) with ESMTP id 57F681AD67B for ; Thu, 26 Dec 2013 23:48:54 -0800 (PST) Received: from bruce-transformer.home.perens.com (c-50-168-114-183.hsd1.ca.comcast.net [50.168.114.183]) by alchemy.perens.com (Postfix) with ESMTPSA id 19A3550008D; Thu, 26 Dec 2013 23:48:49 -0800 (PST) User-Agent: K-9 Mail for Android In-Reply-To: <52BCD497.20501@dcrocker.net> References: <529E8494.7000806@perens.com> <20131204111309.GB11727@nic.fr> <529F61D8.6030105@perens.com> <20131204171207.GC19914@thunk.org> <529F63C0.3040804@perens.com> <529F88AC.3090904@appelbaum.net> <529F90A0.8000706@perens.com> <529F9205.30906@appelbaum.net> <529F98C0.9090808@perens.com> <529F9F14.8050805@appelbaum.net> <529FB61A.7090604@perens.com> <529FBEF9.7030205@appelbaum.net> <529FC347.3080806@perens.com> <52A15835.2070901@cis-india.org> <52A21B80.8070005@mykolab.com> <52A21D1C.8020000@perens.com> <52A2235A.2030801@perens.com> <240A2D86-C352-4954-BE4E-6313BA25994E@icsi.berkeley.edu> <52A2CE6A.30408@perens.com> <52A31F1D.7040509@cs.tcd.ie> <5D026682-5457-4F00-B139-58D8D718BB0A@icsi.berkeley.edu> <52BCD497.20501@dcrocker.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----B2J8XB4A0K9M8ZP77DLT7BSJFNSUB3" From: Bruce Perens Date: Thu, 26 Dec 2013 23:48:43 -0800 To: dcrocker@bbiw.net, Dave Crocker , Nicholas Weaver Message-ID: <2aa980cd-ee22-4e9c-8122-812ae0c9c650@email.android.com> 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Dec 2013 07:48:55 -0000 ------B2J8XB4A0K9M8ZP77DLT7BSJFNSUB3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit eTag is a partial step in this direction. But not very far. There's no defined way for the client to independently verify it, and it isn't necessarily identical across different lossless compressions of the object. A tighter specification could add end-to-end authentication of an object while retaining the existing functions of eTag. The most oft-used convention is a separate checksum file. Less often, the checksum file is signed. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. ------B2J8XB4A0K9M8ZP77DLT7BSJFNSUB3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit eTag is a partial step in this direction. But not very far. There's no defined way for the client to independently verify it, and it isn't necessarily identical across different lossless compressions of the object. A tighter specification could add end-to-end authentication of an object while retaining the existing functions of eTag.

The most oft-used convention is a separate checksum file. Less often, the checksum file is signed.
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity. ------B2J8XB4A0K9M8ZP77DLT7BSJFNSUB3-- From huitema@huitema.net Fri Dec 27 14:14:40 2013 Return-Path: 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 D340E1AE735 for ; Fri, 27 Dec 2013 14:14:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.298 X-Spam-Level: * X-Spam-Status: No, score=1.298 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, MISSING_MID=0.497, RCVD_IN_DNSWL_NONE=-0.0001] 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 EeFaZ3WJ4JT5 for ; Fri, 27 Dec 2013 14:14:39 -0800 (PST) Received: from xsmtp04.mail2web.com (xsmtp24.mail2web.com [168.144.250.190]) by ietfa.amsl.com (Postfix) with ESMTP id 6CD171AE72B for ; Fri, 27 Dec 2013 14:14:39 -0800 (PST) Received: from [10.5.2.18] (helo=xmail08.myhosting.com) by xsmtp04.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1Vwfft-0006PJ-FS for perpass@ietf.org; Fri, 27 Dec 2013 17:14:34 -0500 Received: (qmail 642 invoked from network); 27 Dec 2013 22:14:32 -0000 Received: from unknown (HELO [192.168.200.74]) (Authenticated-user:_huitema@huitema.net@[72.235.170.205]) (envelope-sender ) by xmail08.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 27 Dec 2013 22:14:31 -0000 MIME-Version: 1.0 To: Dean Willis , perpass From: Christian Huitema Date: Fri, 27 Dec 2013 12:14:11 -1000 Content-Type: multipart/alternative; boundary="_65EA7D5B-2E3B-4C0A-A18C-11C6EB206385_" Subject: Re: [perpass] Don't forget St. Nsaclaus' cookies 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Dec 2013 22:14:41 -0000 --_65EA7D5B-2E3B-4C0A-A18C-11C6EB206385_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" At a minimum, never send third party cookies over unencrypted links. -----Original Message----- From: "Dean Willis" Sent: =E2=80=8E12/=E2=80=8E26/=E2=80=8E2013 8:24 PM To: "perpass" Subject: [perpass] Don't forget St. Nsaclaus' cookies Article link, cookies combined with leaky non-enc location data target user= s for exploits. Encrypt everything, dude! "NSA reportedly leveraging Google cookies and leaked mobile location data t= o identify hacking targets" http://feedly.com/k/1co0lQ5 = --_65EA7D5B-2E3B-4C0A-A18C-11C6EB206385_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
At a minimu= m, never send third party cookies over unencrypted links.
From: Dean Willis
Sent: =E2=80=8E12/=E2=80=8E26/=E2=80=8E2013 8:24 PMTo: perpass
Subject: [perpass] Don't forget St. Nsaclaus' cookies

Article link, cookies combined with leaky non-enc location dat= a target users for exploits. Encrypt everything, dude!

"NSA reportedly leveraging Google cookies and leaked mobile lo= cation data to identify hacking targets" http://feedly.com/k/1co0lQ5

= --_65EA7D5B-2E3B-4C0A-A18C-11C6EB206385_-- From watsonbladd@gmail.com Sun Dec 29 11:38:58 2013 Return-Path: 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 C47C61AE328 for ; Sun, 29 Dec 2013 11:38:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 5FR80lLAFCX6 for ; Sun, 29 Dec 2013 11:38:57 -0800 (PST) Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 173AE1AE318 for ; Sun, 29 Dec 2013 11:38:56 -0800 (PST) Received: by mail-we0-f171.google.com with SMTP id q58so9661484wes.16 for ; Sun, 29 Dec 2013 11:38:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=+FxWJPDKWcFEuvmkqaRtMm/ObVT05smHViBNdngCLWU=; b=jlTeJEhyGT4fhR6jGVNM7To8Ym3gY3PEKl537Uf/WixiD1gHTYfdWE1WZnNLvPP2Rm ri5to9CmFdWU1ZuurQzPS0zjISLyv6+48JVS3qIWEhF1Ss38A6mSGzTL3ejUY7YusRWW +DPxnts4YBjXP4GmqtAnPfoUJVVwuThstFl8YF68SA6OdswzTfPzgtaUv6tJUFWGRrtH tBunjaMGczAKRPjm6LcE7tzgZvmTis3MERifJM2TonF1f1ZAP2sb4vS6UMXa1Gu1A1dw IunuxwKy6Egb2fj+GRxmWGfYCnC2LPa3B/86ir2/TwOjRT9U9f9mL0VhPAvBBn22CeJv V2gw== MIME-Version: 1.0 X-Received: by 10.180.13.242 with SMTP id k18mr41268210wic.44.1388345931125; Sun, 29 Dec 2013 11:38:51 -0800 (PST) Received: by 10.194.242.131 with HTTP; Sun, 29 Dec 2013 11:38:51 -0800 (PST) Date: Sun, 29 Dec 2013 14:38:51 -0500 Message-ID: From: Watson Ladd To: perpass@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: [perpass] ID based encryption for email 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Dec 2013 19:38:59 -0000 One obvious solution for end-to-end email encryption is to use ID-based cryptography: a new record type would be defined in the DNS containing the system key for an ID-based system, and the username (everything before the '@') would be the identity used. This would not obscure addresses or the fact of communication right now, but would prevent interception at intermediate nodes. It would be webmail compatible. Are there any issues beyond the merely cryptographic that I need to consider here? Can this be shoehorned into S/MIME, or do we need to do something new? In the next few days I will try to make a draft/implementation for this. Sincerely, Watson Ladd From hallam@gmail.com Sun Dec 29 14:08:29 2013 Return-Path: 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 4EAE71AE31F for ; Sun, 29 Dec 2013 14:08:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 HA_DnbRZnAJj for ; Sun, 29 Dec 2013 14:08:27 -0800 (PST) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) by ietfa.amsl.com (Postfix) with ESMTP id 1E0E51AE31B for ; Sun, 29 Dec 2013 14:08:26 -0800 (PST) Received: by mail-lb0-f169.google.com with SMTP id u14so5340962lbd.28 for ; Sun, 29 Dec 2013 14:08:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=sUrN58aN5QrO2OKvpAWQMVF5XqBWhvarQfXBZpFTWDw=; b=aTMXTWmgN+HU4smOcpCdDeS8rX0xyTFjetVZtBzK29lazTAzGV4At2ueqn/YHxMix9 Mv/jcT3TpK0nFcUT/pDAv+Pv2X/sv8HUPP6h9S11gRC4XyqY6hkEqI6Sl9ZtdwAcLUWB +tJUy4RaE+FUfKZuAA/YCm2FvRUmzEA65oCKlf4f7GYXAVUW9FxMHMEBWnk4DOrBpjWy HrSc5DnYoOmjH0hXux6T55jv5lVvTCFMIuJ22/b07SBRAfw/1sa+IwKLwOmDrRudte59 U0CzQImKVk2svSgSK6b89P+hXw3pEUClG2MJuU3LCJ+YJ1R5K6OLTEEP572FFJFtb6De vtFA== MIME-Version: 1.0 X-Received: by 10.112.53.201 with SMTP id d9mr22594339lbp.26.1388354900542; Sun, 29 Dec 2013 14:08:20 -0800 (PST) Received: by 10.112.37.172 with HTTP; Sun, 29 Dec 2013 14:08:20 -0800 (PST) In-Reply-To: References: Date: Sun, 29 Dec 2013 17:08:20 -0500 Message-ID: From: Phillip Hallam-Baker To: Watson Ladd Content-Type: multipart/alternative; boundary=001a11c3f172ab49a404eeb390b5 Cc: perpass Subject: Re: [perpass] ID based encryption for email 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Dec 2013 22:08:29 -0000 --001a11c3f172ab49a404eeb390b5 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Dec 29, 2013 at 2:38 PM, Watson Ladd wrote: > One obvious solution for end-to-end email encryption is to use > ID-based cryptography: a new record type would be defined in the DNS > containing the system key for an ID-based system, and the username > (everything before the '@') would be the identity used. This would not > obscure addresses or the fact of communication right now, but would > prevent interception at intermediate nodes. It would be webmail > compatible. > > Are there any issues beyond the merely cryptographic that I need to > consider here? Can this be shoehorned into S/MIME, or do we need to do > something new? In the next few days I will try to make a > draft/implementation for this. > There are several problems with identity based crypto. The main one being that the technology 1) Requires a trusted third party 2) The trusted third party has knowledge of every user's private key 3) There is no way to revoke a private key in the case of key compromise There are of course various proposals to mitigate the last problem but none that does not completely erase all the benefits of identity based crypto. If the relying party is going to check some service to get key status they might was well check for a certificate. -- Website: http://hallambaker.com/ --001a11c3f172ab49a404eeb390b5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Sun, Dec 29, 2013 at 2:38 PM, Watson Ladd <= watsonbladd@gmai= l.com> wrote:
One obvious solution for end-to-end email en= cryption is to use
ID-based cryptography: a new record type would be defined in the DNS
containing the system key for an ID-based system, and the username
(everything before the '@') would be the identity used. This would = not
obscure addresses or the fact of communication right now, but would
prevent interception at intermediate nodes. It would be webmail
compatible.

Are there any issues beyond the merely cryptographic that I need to
consider here? Can this be shoehorned into S/MIME, or do we need to do
something new? =A0In the next few days I will try to make a
draft/implementation for this.

There ar= e several problems with identity based crypto. The main one being that the = technology=A0

1) Requires a trusted third party
2) The trusted third party has knowledge of every user's private k= ey
3) There is no way to revoke a private key in the case of key = compromise
=A0
There are of course various propos= als to mitigate the last problem but none that does not completely erase al= l the benefits of identity based crypto.

If the relying party is going to check some service to = get key status they might was well check for a certificate.

<= /div>


--
Website: http://hallambaker.com/
--001a11c3f172ab49a404eeb390b5-- From watsonbladd@gmail.com Sun Dec 29 14:11:46 2013 Return-Path: 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 9C9CB1AE31B for ; Sun, 29 Dec 2013 14:11:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 9KoNX0RrHq5k for ; Sun, 29 Dec 2013 14:11:43 -0800 (PST) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 305761AE31C for ; Sun, 29 Dec 2013 14:11:43 -0800 (PST) Received: by mail-we0-f170.google.com with SMTP id w61so9754169wes.1 for ; Sun, 29 Dec 2013 14:11:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=FMh6tTWf/VJRISQpNsuHrEUqrn5ALb0f+KnX8xjJslU=; b=alWY35A2QN1zTrRqWa6ZhJ+8bYgXAt64XDWpo5/UoXQVhhWCrVUxlHezEpWcTxxQi9 CzgXuzoXtw0lVTuUFEdnBWt461ld4t+JWp6doUpJzUPiuSLS+DqkN+kPNXlFslTCMLyX uno4OoC2939WdTx4HWST+ZOjAZFBgCOELijeGR0iMTFU/fctigmIikuczFRDtSDxD4qM SfumEKGQvMPm+l8xMHGsjhjbwgYg2sXyAAJN3zdDSQm6C7fC4zofYsZDCL9CPgcArLx7 XwrWdIHPBjaDDnoz7HUve+UwJC8UgHhnyWazgRYSi+H0FGgqbgLLJUmsFI9rJXi9KADt a4bQ== MIME-Version: 1.0 X-Received: by 10.180.13.242 with SMTP id k18mr41551905wic.44.1388355097139; Sun, 29 Dec 2013 14:11:37 -0800 (PST) Received: by 10.194.242.131 with HTTP; Sun, 29 Dec 2013 14:11:37 -0800 (PST) In-Reply-To: <52C09394.9080500@cs.tcd.ie> References: <52C07436.2040709@cs.tcd.ie> <04C32948-02A2-44F4-B4C1-CF29D4146715@vpnc.org> <52C09394.9080500@cs.tcd.ie> Date: Sun, 29 Dec 2013 17:11:37 -0500 Message-ID: From: Watson Ladd To: Stephen Farrell , perpass@ietf.org, "cfrg@irtf.org" Content-Type: text/plain; charset=UTF-8 Subject: Re: [perpass] [Cfrg] CFRG and thwarting pervasive montoring 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Dec 2013 22:11:46 -0000 On Sun, Dec 29, 2013 at 4:26 PM, Stephen Farrell wrote: > > > On 12/29/2013 09:12 PM, Paul Hoffman wrote: >> On Dec 29, 2013, at 11:12 AM, Stephen Farrell >> wrote: >> >>> . . . >> >>> I would love to see ongoing detailed work within CFRG as to how to >>> counter pervasive monitoring. >> >> Wearing your perpass hat, how can CFRG help? I ask this because I >> have seen little on the perpass mailing list that indicated that an >> even minor problem has been lack of crypto, or the use of crypto that >> is thought to be breakable. What type of crypto research or >> assessment would help perpass? Sending to perpass to get feedback on this question. >> >> Note that deprecating the use of crypto that is widely known to be >> broken is the purview of IETF WGs, not the CFRG. The relevant WGs >> (particularly TLS) seem to already be doing that. I don't agree with this assessment: the BCP Yaron Sheffer wrote on depreciating RC4 got kicked to the newly formed UTA WG, which has done nothing with it. The biggest changes here have been AGL pushing stuff into Chrome, but he can't do the server side nearly as easily. It's been a controversial topic in the TLS WG, even with Marsh Ray and AGL pushing for it. > > One question might be whether some modes of operation are > really inherently more likely to have side-channels in their > implementation or not and whether the impact of that might > be practically usable by an attacker. That assumes crypto is being used, and can hide the relevant information. DNS is still in cleartext, and even HTTPS reveals what sites you are looking at. The only fixes are PIR protocols, onion routing, and related tricks. We can also try to reduce what is revealed: version numbers, configurations, and options can be quite interesting for targeting, particularly if they are linkable across sessions. Side-channels are fixable with good, freely usable implementations: I don't understand why we are concerned with bad implementers. (Of course, the standard needs to allow a good side channel free implementation.) The lazy would rather copy than innovate incorrectly. Anyway, AES-GCM has side channel issues, but with HMAC+Salsa20/Chacha or Chacha/Poly1305 it is easier to avoid them with as they have efficient circuits which CPUs can do. > > Another might relate to whether things like nonces might > provide a way for borked implementations to leak key bits > and if so, whether there are practical ways for susceptible > protocols to mitigate that, or bits of advice that should > be included in such protocol specs. (And finding some > susceptible protocols would be cool too if CFRG folks were > willing.) As in leak a key via the bits of an IV? That's not borked but deliberate. For signing quite a few covert channels are known in ECDSA. This is rumored to be an issue in the Test Ban Treaty negotiations, but good luck finding out about that! The easy countermeasure for some algorithms is to use nonces that are implicit, incrementing with message number. That way each peer enforces the algorithm on the other. Robert Ransom deserves credit for this recognition AFAIK, but I am sure this has been done before. > > I'm sure clever folk can come up with more once they start > to think about it. > > S. > > >> >> --Paul Hoffman >> > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From watsonbladd@gmail.com Sun Dec 29 14:33:00 2013 Return-Path: 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 888FC1AE329 for ; Sun, 29 Dec 2013 14:33:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.6 X-Spam-Level: X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 lf-spSCDK3r4 for ; Sun, 29 Dec 2013 14:32:58 -0800 (PST) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) by ietfa.amsl.com (Postfix) with ESMTP id 5E1AE1AE325 for ; Sun, 29 Dec 2013 14:32:58 -0800 (PST) Received: by mail-wi0-f176.google.com with SMTP id hq4so15822645wib.15 for ; Sun, 29 Dec 2013 14:32:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PGIPT8qhlUMv5eJvwD+SeBL3iFrXWDcLOTVCHp9wD8k=; b=al9lUl/yh3SWBwq/mmfn2h/5Ks9sy/80P1IfdNGwxejHHq+h4uyNnS4jI7IkzrIZwO Va1DME/PZ26VsXdCnNO3UY5EYb0cboufP+GRDYxHsOVwFo4yfYOZn+6iv7XD+rWyw3Br MZr0khE//aG2LyZIiyvEKBFOWeNUPinX0ckHs13gzDFA8isSIiWwXXiKE42HcBAyicKT ix5/LqADZNYtBwHcE5VZpe8mqBbx3MwgUxNoVAUWAnsdwHLmNFnrpfp65x4WjjjWmwyw SJibOOhCNI152YSh5l3EhXygIdE4CcnXAh9HaeDlsz5i9X1CIT3KED2IMcDRMLpO9W00 ziXQ== MIME-Version: 1.0 X-Received: by 10.194.175.66 with SMTP id by2mr16900015wjc.59.1388356372365; Sun, 29 Dec 2013 14:32:52 -0800 (PST) Received: by 10.194.242.131 with HTTP; Sun, 29 Dec 2013 14:32:52 -0800 (PST) In-Reply-To: References: Date: Sun, 29 Dec 2013 17:32:52 -0500 Message-ID: From: Watson Ladd To: Phillip Hallam-Baker Content-Type: text/plain; charset=UTF-8 Cc: perpass Subject: Re: [perpass] ID based encryption for email 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Dec 2013 22:33:00 -0000 On Sun, Dec 29, 2013 at 5:08 PM, Phillip Hallam-Baker wrote: > > > > On Sun, Dec 29, 2013 at 2:38 PM, Watson Ladd wrote: >> >> One obvious solution for end-to-end email encryption is to use >> ID-based cryptography: a new record type would be defined in the DNS >> containing the system key for an ID-based system, and the username >> (everything before the '@') would be the identity used. This would not >> obscure addresses or the fact of communication right now, but would >> prevent interception at intermediate nodes. It would be webmail >> compatible. >> >> Are there any issues beyond the merely cryptographic that I need to >> consider here? Can this be shoehorned into S/MIME, or do we need to do >> something new? In the next few days I will try to make a >> draft/implementation for this. > > > There are several problems with identity based crypto. The main one being > that the technology > > 1) Requires a trusted third party In this system the trusted third party is already trusted right now: they are the recipients ISP. This system doesn't interfere with spam trapping and advertising, and so is easy to adopt. I'm not trying to replace PGP, just make something we can turn on by default. > 2) The trusted third party has knowledge of every user's private key A user can opt-out by running their own receiving mail server. > 3) There is no way to revoke a private key in the case of key compromise This one is probably the most serious limitation. I think the best way to fix it is to use keys with limited temporal validity periods, say by hashing with the year or month/year as well. Then you wait a month and the old key is expired. Accessing old mail gets a bit tricky here, but clients could store local copies or servers could hand out the needed keys if you are logged in. > > There are of course various proposals to mitigate the last problem but none > that does not completely erase all the benefits of identity based crypto. > > If the relying party is going to check some service to get key status they > might was well check for a certificate. I was thinking sender mail client. Certificates could work, but then we would have to serve them up efficiently, and that's likely to be a bit of a mess, particularly if we don't want to reveal address books. If you could give every Gmail user a Google signed S/MIME certificate, and have Google distribute the list (s/Google/mail provider of choice/) that solves the issue, but adding 64 bytes (or maybe 128 bytes) in a DNS extension is much easier operationally. > > > > -- > Website: http://hallambaker.com/ -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From leifj@mnt.se Mon Dec 30 05:16:15 2013 Return-Path: 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 3AB4A1AE001 for ; Mon, 30 Dec 2013 05:16:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 8XV5sE3kbLxl for ; Mon, 30 Dec 2013 05:16:13 -0800 (PST) Received: from mail-la0-f46.google.com (mail-la0-f46.google.com [209.85.215.46]) by ietfa.amsl.com (Postfix) with ESMTP id B8F871ADF71 for ; Mon, 30 Dec 2013 05:16:12 -0800 (PST) Received: by mail-la0-f46.google.com with SMTP id eh20so5474866lab.5 for ; Mon, 30 Dec 2013 05:16:06 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=uSKWkEWtBlJQBEJbMmX/qHYA78Gr7jUuwDQ4QlP7eHc=; b=fl3L+/yX8dd3YtJNegB8JNOX/oSFayvUJtkyDpfTAAj3KhySosEUMJS2/2HLoUCxBP sqw+O/Ohvm74Sm+Sf6x8A/mjuTYa971/XVORyWKg+x9YrIrY93pVlX7+7SsKlE1HYzvu 0yF2AGZeLHmoAhK/kEgjNtyDifmASrmcJNuybEvmwgf25fsAeAah+ErtURFzLNB64tdP zYBWsckBJYAJxiHF3s3gdNyMJ9muBWfwgs3xog5WIDauNEX1cxxmuXmeu98ylkTs3O2w RjrcShQlqEpD4LHAII4ABCQi0NQVH+lseUr9gRAdVAEvb2Tkc8ndHJIY+kzhXSnQXnXi LMZw== X-Gm-Message-State: ALoCoQlZi70xQgK7kUn7ztdXigJLIk1/HBErdCqf9B61PM+y2H0JvcrhMg/4u/5+78Dukpbf6Ho5 X-Received: by 10.152.88.8 with SMTP id bc8mr12188444lab.47.1388409366032; Mon, 30 Dec 2013 05:16:06 -0800 (PST) Received: from [2.65.68.50] (2.65.68.50.mobile.tre.se. [2.65.68.50]) by mx.google.com with ESMTPSA id mx3sm27798944lbc.14.2013.12.30.05.16.04 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 30 Dec 2013 05:16:04 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Leif Johansson X-Mailer: iPhone Mail (11B554a) In-Reply-To: Date: Mon, 30 Dec 2013 14:16:04 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <52C07436.2040709@cs.tcd.ie> <04C32948-02A2-44F4-B4C1-CF29D4146715@vpnc.org> <52C09394.9080500@cs.tcd.ie> To: Watson Ladd Cc: "perpass@ietf.org" , "cfrg@irtf.org" , Stephen Farrell Subject: Re: [perpass] [Cfrg] CFRG and thwarting pervasive montoring 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Dec 2013 13:16:15 -0000 > 29 dec 2013 kl. 23:11 skrev Watson Ladd : >=20 > On Sun, Dec 29, 2013 at 4:26 PM, Stephen Farrell > wrote: >>=20 >>=20 >>> On 12/29/2013 09:12 PM, Paul Hoffman wrote: >>> On Dec 29, 2013, at 11:12 AM, Stephen Farrell >>> wrote: >>>=20 >>>> . . . >>>=20 >>>> I would love to see ongoing detailed work within CFRG as to how to >>>> counter pervasive monitoring. >>>=20 >>> Wearing your perpass hat, how can CFRG help? I ask this because I >>> have seen little on the perpass mailing list that indicated that an >>> even minor problem has been lack of crypto, or the use of crypto that >>> is thought to be breakable. What type of crypto research or >>> assessment would help perpass? >=20 > Sending to perpass to get feedback on this question. >=20 >>>=20 >>> Note that deprecating the use of crypto that is widely known to be >>> broken is the purview of IETF WGs, not the CFRG. The relevant WGs >>> (particularly TLS) seem to already be doing that. >=20 > I don't agree with this assessment: the BCP Yaron Sheffer wrote on > depreciating RC4 got kicked > to the newly formed UTA WG, which=20 huh? who did what to what? the uta list is just barely open and we've hardly hardly had time to get org= anized, let alone decide which drafts to take on. lets take a deep breath & settle down Leif > has done nothing with it. The > biggest changes here have > been AGL pushing stuff into Chrome, but he can't do the server side From kent@bbn.com Mon Dec 30 07:36:41 2013 Return-Path: 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 D98731AE0B9; Mon, 30 Dec 2013 07:36:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.039 X-Spam-Level: X-Spam-Status: No, score=-2.039 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, 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 G5lMCUfKz2r8; Mon, 30 Dec 2013 07:36:40 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 0184B1ADF4F; Mon, 30 Dec 2013 07:36:39 -0800 (PST) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:65173) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1VxetM-000CmF-D4; Mon, 30 Dec 2013 10:36:32 -0500 Message-ID: <52C19300.3050201@bbn.com> Date: Mon, 30 Dec 2013 10:36:32 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Ben Laurie References: <52A8B1D0.2080304@dcrocker.net> <52A8E0E9.5020409@dcrocker.net> <52A9E61C.8030300@bbn.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: perpass , saag Subject: Re: [perpass] Draft charter for a Transparency Working Group 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Dec 2013 15:36:42 -0000 Ben, > How's this? > > [1] A cryptographically verifiable log is an append-only log of hashes > of more-or-less anything that can prove its own correctness > cryptographically. > > For example, from RFC 6962: “The append-only property of each log is > technically achieved using Merkle Trees, which can be used to show > that any particular version of the log is a superset of any particular > previous version. Likewise, Merkle Trees avoid the need to blindly > trust logs: if a log attempts to show different things to different > people, this can be efficiently detected by comparing tree roots and > consistency proofs. Similarly, other misbehaviours of any log (e.g., > issuing signed timestamps for certificates they then don't log) can be > efficiently detected and proved to the world at large.” > > See RFC 6962, http://www.links.org/files/CertificateTransparencyVersion2.1a.pdf > and http://www.links.org/files/RevocationTransparency.pdf for > background. > Sorry to be so late in responding; holidays ... The text describing how 6962 uses Merkle trees is good. I think the phrase "prove its own correctness" is way too broad. The example you cite shows how to demonstrate internal consistency for a log, and to enable third parties to verify certain lob properties. That is much narrower than what the term "correctness" implies. Steve From kent@bbn.com Mon Dec 30 07:42:45 2013 Return-Path: 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 185931AE105 for ; Mon, 30 Dec 2013 07:42:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.739 X-Spam-Level: X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, 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 JYCCwMM2OQF0 for ; Mon, 30 Dec 2013 07:42:43 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id CA23D1ADF4F for ; Mon, 30 Dec 2013 07:42:43 -0800 (PST) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:65195) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1VxezF-000Con-Ol for perpass@ietf.org; Mon, 30 Dec 2013 10:42:37 -0500 Message-ID: <52C1946D.8030807@bbn.com> Date: Mon, 30 Dec 2013 10:42:37 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: perpass@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [perpass] ID based encryption for email 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Dec 2013 15:42:45 -0000 Watson, > One obvious solution for end-to-end email encryption is to use > ID-based cryptography: a new record type would be defined in the DNS > containing the system key for an ID-based system, and the username > (everything before the '@') would be the identity used. This would not > obscure addresses or the fact of communication right now, but would > prevent interception at intermediate nodes. It would be webmail > compatible. IBE requires an infrastructure in which we trust CAs not only to correctly identify subjects, but also to not snoop on traffic, since the CAs intrinsically have access to the private keys. It also requires an infrastructure in which the CAs are directly tied to e-mail names, and then into some bigger hierarchy, else we wind up with tens of thousands of TAs. It would be much simpler, and more secure, to use DANE. > Are there any issues beyond the merely cryptographic that I need to > consider here? Can this be shoehorned into S/MIME, or do we need to do > something new? In the next few days I will try to make a > draft/implementation for this. IBE for S/MINE was defined in RFC 5408, in 2008. But, the issues I noted above, plus IPR issues, have diminished enthusiasm for its deployment. Steve From ajs@anvilwalrusden.com Mon Dec 30 08:04:14 2013 Return-Path: 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 C87BA1AE4FE for ; Mon, 30 Dec 2013 08:04:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.141 X-Spam-Level: X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 MOwOG7wpR925 for ; Mon, 30 Dec 2013 08:04:13 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id C20C21AE4FB for ; Mon, 30 Dec 2013 08:04:13 -0800 (PST) Received: from mx1.yitter.info (nat-02-mht.dyndns.com [216.146.45.241]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 667C08A031 for ; Mon, 30 Dec 2013 16:04:07 +0000 (UTC) Date: Mon, 30 Dec 2013 11:04:04 -0500 From: Andrew Sullivan To: perpass@ietf.org Message-ID: <20131230160404.GF4291@mx1.yitter.info> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [perpass] ID based encryption for email 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Dec 2013 16:04:15 -0000 On Sun, Dec 29, 2013 at 02:38:51PM -0500, Watson Ladd wrote: > Are there any issues beyond the merely cryptographic that I need to > consider here? It seems like the scaling properties are going to be a little tricky in places with very large numbers of users at a mail domain. How will the data get into the DNS? Dynamic update? What if people don't know abou this new RRTYPE (please don't say "TXT record" for this use case without explaining how you're going to subtype the TXT record without stepping on other things). A -- Andrew Sullivan ajs@anvilwalrusden.com From leifj@mnt.se Mon Dec 30 08:05:48 2013 Return-Path: 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 3ADF41ADF4F for ; Mon, 30 Dec 2013 08:05:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 9Zz1lcsXPPDx for ; Mon, 30 Dec 2013 08:05:46 -0800 (PST) Received: from mail-la0-f45.google.com (mail-la0-f45.google.com [209.85.215.45]) by ietfa.amsl.com (Postfix) with ESMTP id 389C11AE1FE for ; Mon, 30 Dec 2013 08:05:46 -0800 (PST) Received: by mail-la0-f45.google.com with SMTP id eh20so5601428lab.4 for ; Mon, 30 Dec 2013 08:05:39 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=UsB2z18SczgjrSESoOxT+zcEd3gRR/PiYWn9iTat1Gc=; b=azqKXP2LRtP/pxs8+QJXFXtuIOuKH87T7CE0RcQ4uh+/x5zKDvrU175mweTeL0KdI1 bJGrsk9UONQps2fpByDCvKlCVTEsmRjO1dtT7q3aT3vWAmyMKwO25ozr/pyMSBhGMVoR DqLaCZY9KC67DDkQMEjqCUDBDIAT97wy11XOJDiUdTHJFl80iMR8DjwRzXMV1HWxSpq7 NtrmLZmyKT6WJ2R6jheo/H+dNDVbLg31EvH5I9YO9C0HRrSA0MvOg6WxOfXrtpsJMaVn pCHpLlZPPQTkDROLh2irwlLAF5hJ8JQOQNiG0mG2hJrcvWvmDx7HZKBQayVDtJlMO565 7W1Q== X-Gm-Message-State: ALoCoQkec0nYm484hn3UPoVE0AtAQYiWlQ8YQ/3iu2mhIqI+XsRSVcL6I/2uHdY/uXJTHNdcaEWA X-Received: by 10.152.197.67 with SMTP id is3mr1697014lac.61.1388419539447; Mon, 30 Dec 2013 08:05:39 -0800 (PST) Received: from [172.20.10.5] (2.64.190.127.mobile.tre.se. [2.64.190.127]) by mx.google.com with ESMTPSA id r10sm36077740lag.7.2013.12.30.08.05.37 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 30 Dec 2013 08:05:38 -0800 (PST) Message-ID: <52C199CD.4010200@mnt.se> Date: Mon, 30 Dec 2013 17:05:33 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: perpass@ietf.org References: <52C1946D.8030807@bbn.com> In-Reply-To: <52C1946D.8030807@bbn.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [perpass] ID based encryption for email 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Dec 2013 16:05:48 -0000 On 2013-12-30 16:42, Stephen Kent wrote: > Watson, >> One obvious solution for end-to-end email encryption is to use >> ID-based cryptography: a new record type would be defined in the DNS >> containing the system key for an ID-based system, and the username >> (everything before the '@') would be the identity used. This would not >> obscure addresses or the fact of communication right now, but would >> prevent interception at intermediate nodes. It would be webmail >> compatible. > IBE requires an infrastructure in which we trust CAs not only to > correctly identify subjects, but also to not snoop on traffic, > since the CAs intrinsically have access to the private keys. It also > requires an infrastructure in which the CAs are directly tied to e-mail > names, and then into some bigger hierarchy, else we wind up with tens of > thousands of TAs. It would be much simpler, and more secure, to use DANE. +1 - we already have that hierarchy lying about... >> Are there any issues beyond the merely cryptographic that I need to >> consider here? Can this be shoehorned into S/MIME, or do we need to do >> something new? In the next few days I will try to make a >> draft/implementation for this. > IBE for S/MINE was defined in RFC 5408, in 2008. But, the issues > I noted above, plus IPR issues, have diminished enthusiasm for its > deployment. > > Steve > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass From ajs@anvilwalrusden.com Mon Dec 30 08:07:23 2013 Return-Path: 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 E7B381AE26E for ; Mon, 30 Dec 2013 08:07:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.141 X-Spam-Level: X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 aN9Mjv4xmhuq for ; Mon, 30 Dec 2013 08:07:22 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id B3D931ADF4F for ; Mon, 30 Dec 2013 08:07:22 -0800 (PST) Received: from mx1.yitter.info (nat-02-mht.dyndns.com [216.146.45.241]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 942F88A031 for ; Mon, 30 Dec 2013 16:07:16 +0000 (UTC) Date: Mon, 30 Dec 2013 11:07:16 -0500 From: Andrew Sullivan To: perpass@ietf.org Message-ID: <20131230160716.GG4291@mx1.yitter.info> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [perpass] ID based encryption for email 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Dec 2013 16:07:24 -0000 On Sun, Dec 29, 2013 at 05:32:52PM -0500, Watson Ladd wrote: > is to use keys with limited temporal validity periods, say by hashing > with the year or > month/year as well. Then you wait a month and the old key is expired. > Accessing old > mail gets a bit tricky here, but clients could store local copies or > servers could hand out > the needed keys if you are logged in. You better think hard about caches in the DNS, as well, for this. Consider the timing problems that have bedeviled DNSSEC deployment. A -- Andrew Sullivan ajs@anvilwalrusden.com From kent@bbn.com Mon Dec 30 09:07:10 2013 Return-Path: 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 70F0E1AE512 for ; Mon, 30 Dec 2013 09:07:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.84 X-Spam-Level: X-Spam-Status: No, score=-2.84 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, 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 hQzR3SAMes7N for ; Mon, 30 Dec 2013 09:07:08 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 9EEAC1AE29F for ; Mon, 30 Dec 2013 09:07:06 -0800 (PST) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:49342) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1VxgIt-000DMu-Gr for perpass@ietf.org; Mon, 30 Dec 2013 12:06:59 -0500 Message-ID: <52C1A82E.807@bbn.com> Date: Mon, 30 Dec 2013 12:06:54 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: perpass@ietf.org References: <52C07436.2040709@cs.tcd.ie> <04C32948-02A2-44F4-B4C1-CF29D4146715@vpnc.org> <52C09394.9080500@cs.tcd.ie> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [perpass] [Cfrg] CFRG and thwarting pervasive montoring 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Dec 2013 17:07:10 -0000 Watson, > I don't understand why we are concerned with bad implementers. because the world is full of implementation errors? >> Another might relate to whether things like nonces might >> provide a way for borked implementations to leak key bits >> and if so, whether there are practical ways for susceptible >> protocols to mitigate that, or bits of advice that should >> be included in such protocol specs. (And finding some >> susceptible protocols would be cool too if CFRG folks were >> willing.) > As in leak a key via the bits of an IV? That's not borked but > deliberate. For signing quite a few covert channels are known in > ECDSA. This is rumored to be an issue in the Test Ban Treaty negotiations, > but good luck finding out about that! In the TBT context the focus was exactly the opposite of what you suggested, according to my recollection. The parties to the treaty (the US and the Soviet Union) wanted to make sure that the signed data being sent didn't have any covert exfiltration capabilities. > The easy countermeasure for some algorithms is to use nonces that are > implicit, incrementing with message number. That way > each peer enforces the algorithm on the other. Many years ago we explored the issue of using sequence numbers in ESP in lieu of random IVs. One problem is that, from a security assurance perspective, the software (or hardware) that manages sequence numbers is usually outside the perimeter that is evaluated for crypto alg security. Thus, if one used an ESP sequence number as an IV, an implementation would not qualify as FIPS 140-x compliant, unless most (all) of the ESP implementation were part of the evaluation. That was not desirable side effect of an implicit IV design. There were other problems, some of which were IPsec-specific, that also caused us to stick with random IVs. Finally, for very high speed implementations (hardware) there are some advantages to allowing a sender to choose it's own approach to IV generation. Steve From hannes.tschofenig@gmx.net Mon Dec 30 10:19:27 2013 Return-Path: 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 1E0301AE51C for ; Mon, 30 Dec 2013 10:19:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.538, 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 EC7r7ojHWH_5 for ; Mon, 30 Dec 2013 10:19:23 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id 960C31AE511 for ; Mon, 30 Dec 2013 10:19:23 -0800 (PST) Received: from [192.168.131.132] ([80.92.116.74]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0Le69A-1Veo9P417c-00pr0a for ; Mon, 30 Dec 2013 19:19:16 +0100 Message-ID: <52C1B8C0.8090607@gmx.net> Date: Mon, 30 Dec 2013 18:17:36 +0000 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Watson Ladd , perpass@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:G/3ViSMOgzVqZWH942rIeG3aOY4FxaSz1yTM2PWFm5BeXNAGEoZ IX7dbgesvvJR4Zpld3WaWNd2JM9dyD3UZF1jwcTprsV1+GXQXvG1CWfA8TZBonh0rWMEaXm GIwg4Wd3TQoXAikP3ZPEMlUKzU77LLTm5SItIAqluRwaM+DoyHwN6echtEwIGMcgaoGaZPU U1iIjCqH4pvsXynkC4L6A== Subject: Re: [perpass] ID based encryption for email 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Dec 2013 18:19:27 -0000 Hi Watson, ID-based crypto is not at all an obvious choice for email security. I would even go further by saying that ID-based crypto has been a solution in search for a problem so far. In my investigations (based on prior proposals in the IETF) I could not find benefits with ID-based crypto. Ciao Hannes On 12/29/2013 07:38 PM, Watson Ladd wrote: > One obvious solution for end-to-end email encryption is to use > ID-based cryptography: a new record type would be defined in the DNS > containing the system key for an ID-based system, and the username > (everything before the '@') would be the identity used. This would not > obscure addresses or the fact of communication right now, but would > prevent interception at intermediate nodes. It would be webmail > compatible. > > Are there any issues beyond the merely cryptographic that I need to > consider here? Can this be shoehorned into S/MIME, or do we need to do > something new? In the next few days I will try to make a > draft/implementation for this. > > Sincerely, > Watson Ladd > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass From paul@marvell.com Mon Dec 30 10:26:18 2013 Return-Path: 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 3AED91AE51D for ; Mon, 30 Dec 2013 10:26:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.557 X-Spam-Level: X-Spam-Status: No, score=-1.557 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] 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 lAWdKp58Z9rA for ; Mon, 30 Dec 2013 10:26:17 -0800 (PST) Received: from mx0a-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) by ietfa.amsl.com (Postfix) with ESMTP id 33C8A1AE51C for ; Mon, 30 Dec 2013 10:26:17 -0800 (PST) Received: from pps.filterd (m0045849.ppops.net [127.0.0.1]) by mx0a-0016f401.pphosted.com (8.14.5/8.14.5) with SMTP id rBUIQAOp007077; Mon, 30 Dec 2013 10:26:10 -0800 Received: from sc-owa.marvell.com ([199.233.58.135]) by mx0a-0016f401.pphosted.com with ESMTP id 1h3awd0qjj-11 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 30 Dec 2013 10:26:10 -0800 Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA.marvell.com ([::1]) with mapi; Mon, 30 Dec 2013 10:26:08 -0800 From: Paul Lambert To: Watson Ladd , "perpass@ietf.org" Date: Mon, 30 Dec 2013 10:26:06 -0800 Thread-Topic: [perpass] ID based encryption for email Thread-Index: Ac8FjJtRNZd2MbmPQdqTwQipMzW74g== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.87, 1.0.14, 0.0.0000 definitions=2013-12-30_02:2013-12-30,2013-12-30,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1312300119 Subject: Re: [perpass] ID based encryption for email 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Dec 2013 18:26:18 -0000 Why do we even need DNS and names for email encryption? The path/address to reach a peer should be independent of the cryptographic identity used for peer-to-peer authentication/encryption. IMHO we should be looking a key centric approaches that loosely bind one or more sets of names/email addresses to public key identifiers. Paul On 12/29/13, 11:38 AM, "Watson Ladd" wrote: >One obvious solution for end-to-end email encryption is to use >ID-based cryptography: a new record type would be defined in the DNS >containing the system key for an ID-based system, and the username >(everything before the '@') would be the identity used. This would not >obscure addresses or the fact of communication right now, but would >prevent interception at intermediate nodes. It would be webmail >compatible. > >Are there any issues beyond the merely cryptographic that I need to >consider here? Can this be shoehorned into S/MIME, or do we need to do >something new? In the next few days I will try to make a >draft/implementation for this. > >Sincerely, >Watson Ladd >_______________________________________________ >perpass mailing list >perpass@ietf.org >https://www.ietf.org/mailman/listinfo/perpass From hallam@gmail.com Mon Dec 30 11:25:44 2013 Return-Path: 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 D63F01AE2D7 for ; Mon, 30 Dec 2013 11:25:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 3XaV18IIAi-T for ; Mon, 30 Dec 2013 11:25:41 -0800 (PST) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 2254E1AE511 for ; Mon, 30 Dec 2013 11:25:40 -0800 (PST) Received: by mail-la0-f42.google.com with SMTP id ec20so5857913lab.1 for ; Mon, 30 Dec 2013 11:25:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TxAVEf9B1kD/GcHpzSQCeJJsTFqwhDWPh6aPglTsFSA=; b=vkF+RZ3viL06+7Jms14mzhxkraMl7BE/SPkEoW9yJ7/7A4TyD0E8KT3SdO0LMZf+5G xFn2y2SkfMIM99JxsGVhpLLHHlP8jSpMs8/H+ZztmT82meBMyYaXzl5x+VznRbQdSinf wXp0wHnADAf/RTZZK1VYiXGWPUAqlsFgxsgdywdRYlx96iKkx/0ZJN3Uz0ey3G7/bc6k gqIiWHd+I6dXx5tJN/+VEsVNgseFTsVtWiOVerouVs6YRnJFyrz5dp3smnUXmJ26ZEkM 1lzAdXqhD4s52OQ0ou6X+HRVrq4EMEWzY18o/2TgnRFo5VShQB51cU5/bGiHnrids2pq 4JGg== MIME-Version: 1.0 X-Received: by 10.152.238.34 with SMTP id vh2mr10581602lac.50.1388431534509; Mon, 30 Dec 2013 11:25:34 -0800 (PST) Received: by 10.112.37.172 with HTTP; Mon, 30 Dec 2013 11:25:34 -0800 (PST) In-Reply-To: References: Date: Mon, 30 Dec 2013 14:25:34 -0500 Message-ID: From: Phillip Hallam-Baker To: Watson Ladd Content-Type: multipart/alternative; boundary=001a1134989c68d42804eec568de Cc: perpass Subject: Re: [perpass] ID based encryption for email 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Dec 2013 19:25:45 -0000 --001a1134989c68d42804eec568de Content-Type: text/plain; charset=ISO-8859-1 On Sun, Dec 29, 2013 at 5:32 PM, Watson Ladd wrote: > On Sun, Dec 29, 2013 at 5:08 PM, Phillip Hallam-Baker > wrote: > > > > > > > > On Sun, Dec 29, 2013 at 2:38 PM, Watson Ladd > wrote: > >> > >> One obvious solution for end-to-end email encryption is to use > >> ID-based cryptography: a new record type would be defined in the DNS > >> containing the system key for an ID-based system, and the username > >> (everything before the '@') would be the identity used. This would not > >> obscure addresses or the fact of communication right now, but would > >> prevent interception at intermediate nodes. It would be webmail > >> compatible. > >> > >> Are there any issues beyond the merely cryptographic that I need to > >> consider here? Can this be shoehorned into S/MIME, or do we need to do > >> something new? In the next few days I will try to make a > >> draft/implementation for this. > > > > > > There are several problems with identity based crypto. The main one being > > that the technology > > > > 1) Requires a trusted third party > > In this system the trusted third party is already trusted right now: > they are the recipients ISP. > That is a bigger bug than you imagine. If you are going to accept the ISP is trusted then we might as well just use STARTTLS which is a done and dusted technology. The only problem TLS does not solve is that the ISPs have to be trusted. If the objective here is to allow the sender to know that only the authorized recipients can read the message, having the receiving ISP in the look isn't helping at all. It puts them at risk of being suborned. > This system doesn't interfere with spam trapping and advertising, and > so is easy to adopt. > I'm not trying to replace PGP, just make something we can turn on by > default. PGP has not met the original goal of becoming ubiquitous so replacing PGP seems to me to be a very worthwhile goal. Replacing STARTTLS with something that has message scope but is not end to end does not seem like a good proposition. > > 2) The trusted third party has knowledge of every user's private key > > A user can opt-out by running their own receiving mail server. And how then do they get the root key for their identity based crypto published? Any answer that you give here can be used to authenticate a STARTTLS key or a site wide wildcard S/MIME key. > > 3) There is no way to revoke a private key in the case of key compromise > > This one is probably the most serious limitation. I think the best way to > fix it > is to use keys with limited temporal validity periods, say by hashing > with the year or > month/year as well. Then you wait a month and the old key is expired. > Accessing old > mail gets a bit tricky here, but clients could store local copies or > servers could hand out > the needed keys if you are logged in. Which gets us back to the need to automate the key management and if we can do that then we can use traditional public key with much less effort. I know the Identity based crypto looks like it should be really fantastically useful but I have been looking at schemes for 15 odd years and still not seen any practical application where it gives value except as a device key. Identity based crypto would be a very good way for Apple, Microsoft, Google and co to put ignition crypto into a device. Every ethernet and wifi address should come with a built in crypto key that is installed during device manufacture and never leaves the device. I would never ever want to encrypt data under an ignition key but I would be happy to use such a key to authenticate an initial bootstrap process to install the long term crypto credentials for that device to use in my network. > > > > There are of course various proposals to mitigate the last problem but > none > > that does not completely erase all the benefits of identity based crypto. > > > > If the relying party is going to check some service to get key status > they > > might was well check for a certificate. > > I was thinking sender mail client. Certificates could work, but then > we would have > to serve them up efficiently, and that's likely to be a bit of a mess, > particularly if > we don't want to reveal address books. If you could give every Gmail > user a Google > signed S/MIME certificate, and have Google distribute the list > (s/Google/mail provider of choice/) > that solves the issue, but adding 64 bytes (or maybe 128 bytes) in a > DNS extension is much > easier operationally. > > > > > > > > > -- > > Website: http://hallambaker.com/ > > > > -- > "Those who would give up Essential Liberty to purchase a little > Temporary Safety deserve neither Liberty nor Safety." > -- Benjamin Franklin > -- Website: http://hallambaker.com/ --001a1134989c68d42804eec568de Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Sun, Dec 29, 2013 at 5:32 PM, Watson Ladd <= watsonbladd@gmai= l.com> wrote:
On Sun, Dec 29, 2013 at 5:= 08 PM, Phillip Hallam-Baker <hallam@= gmail.com> wrote:
>
>
>
> On Sun, Dec 29, 2013 at 2:38 PM, Watson Ladd <watsonbladd@gmail.com> wrote:
>>
>> One obvious solution for end-to-end email encryption is to use
>> ID-based cryptography: a new record type would be defined in the D= NS
>> containing the system key for an ID-based system, and the username=
>> (everything before the '@') would be the identity used. Th= is would not
>> obscure addresses or the fact of communication right now, but woul= d
>> prevent interception at intermediate nodes. It would be webmail >> compatible.
>>
>> Are there any issues beyond the merely cryptographic that I need t= o
>> consider here? Can this be shoehorned into S/MIME, or do we need t= o do
>> something new? =A0In the next few days I will try to make a
>> draft/implementation for this.
>
>
> There are several problems with identity based crypto. The main one be= ing
> that the technology
>
> 1) Requires a trusted third party

In this system the trusted third party is already trusted right now:<= br> they are the recipients ISP.

That is a = bigger bug than you imagine. If you are going to accept the ISP is trusted = then we might as well just use STARTTLS which is a done and dusted technolo= gy. The only problem TLS does not solve is that the ISPs have to be trusted= .

If the objective here is to allow the sender to know th= at only the authorized recipients can read the message, having the receivin= g ISP in the look isn't helping at all. It puts them at risk of being s= uborned.

=A0
This system doesn't interfere with spam trapping and advertising, and so is easy to adopt.
I'm not trying to replace PGP, just make something we can turn on by de= fault.

PGP has not met the original goal of= becoming ubiquitous so replacing PGP seems to me to be a very worthwhile g= oal. Replacing STARTTLS with something that has message scope but is not en= d to end does not seem like a good proposition.

=A0
> 2) The trusted third party has knowledge of every user's private k= ey

A user can opt-out by running their own receiving mail server.

And how then do they get the root key for their i= dentity based crypto published?

Any answer that yo= u give here can be used to authenticate a STARTTLS key or a site wide wildc= ard S/MIME key.

=A0
> 3) There is no way to revoke a private key in the case of key compromi= se

This one is probably the most serious limitation. I think the best wa= y to fix it
is to use keys with limited temporal validity periods, say by hashing
with the year or
month/year as well. Then you wait a month and the old key is expired.
Accessing old
mail gets a bit tricky here, but clients could store local copies or
servers could hand out
the needed keys if you are logged in.

Which= gets us back to the need to automate the key management and if we can do t= hat then we can use traditional public key with much less effort.

I know the Identity based crypto looks like it should b= e really fantastically useful but I have been looking at schemes for 15 odd= years and still not seen any practical application where it gives value ex= cept as a device key.


Identity based crypto would be a very go= od way for Apple, Microsoft, Google and co to put ignition crypto into a de= vice. Every ethernet and wifi address should come with a built in crypto ke= y that is installed during device manufacture and never leaves the device.= =A0

I would never ever want to encrypt data under an igniti= on key but I would be happy to use such a key to authenticate an initial bo= otstrap process to install the long term crypto credentials for that device= to use in my network.

=A0
>
> There are of course various proposals to mitigate the last problem but= none
> that does not completely erase all the benefits of identity based cryp= to.
>
> If the relying party is going to check some service to get key status = they
> might was well check for a certificate.

I was thinking sender mail client. Certificates could work, but then<= br> we would have
to serve them up efficiently, and that's likely to be a bit of a mess,<= br> particularly if
we don't want to reveal address books. If you could give every Gmail user a Google
signed S/MIME certificate, and have Google distribute the list
(s/Google/mail provider of choice/)
that solves the issue, but adding 64 bytes (or maybe 128 bytes) in a
DNS extension is much
easier operationally.

>
>
>
> --
> Website: http://= hallambaker.com/



--
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither =A0Liberty nor Safety."
-- Benjamin Franklin



-- Website: http://hallambaker.com/<= br>
--001a1134989c68d42804eec568de-- From hannes.tschofenig@gmx.net Mon Dec 30 11:48:44 2013 Return-Path: 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 4FB801AE30A for ; Mon, 30 Dec 2013 11:48:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.428 X-Spam-Level: X-Spam-Status: No, score=-2.428 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] 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 xR3JseE3TBSH for ; Mon, 30 Dec 2013 11:48:42 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id D9F1F1AE1DE for ; Mon, 30 Dec 2013 11:48:41 -0800 (PST) Received: from [192.168.131.132] ([80.92.116.74]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0Lwnem-1VMA6k38GG-016Qaz for ; Mon, 30 Dec 2013 20:48:34 +0100 Message-ID: <52C1CD57.2080909@gmx.net> Date: Mon, 30 Dec 2013 19:45:27 +0000 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Paul Lambert , Watson Ladd , "perpass@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:UgqLxpbHaovQBjUg0VbKS+TXw7N7Kys7lfxrgF2nXH1fDpuxdK7 Q+Q2NclBzg99Aimr2wIK/7tKJvMcS2EAw1kJnsnydcZkHfCo7wB0xV+dKgM7+knRkk2aHJj Nfq0r3JSZvjMzdEJARikqc+go8lFk5e5jH+5oWSIZqgsxGocpPthvXMTgmDes8kDRi47ggX 1uTGkiQjMb0bCwKe/Xr5A== Subject: Re: [perpass] ID based encryption for email 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Dec 2013 19:48:44 -0000 Hi Paul, I am now guess what you are trying to say here. So, apologies for misinterpreting your suggestion. Some on this list are trying to do the following: they take the existing email infrastructure as a starting point and brainstorm about how to add end-to-end security to it. Of course, there are solutions available already (namely S/MIME and PGP) but both are not widely deployed for a variety of reasons *. Another approach, however, is to start from scratch and to define an entirely new email system, which uses cryptographic addresses instead of human-readable identifiers. I guess that's the approach you are suggesting. Is this correct? Ciao Hannes PS: It would be great if someone could point me to a good write-up about the reasons why these two solutions are not widely deployed. I know about a number of "not-so-useful" write-ups... On 12/30/2013 06:26 PM, Paul Lambert wrote: > Why do we even need DNS and names for email encryption? > > The path/address to reach a peer should be independent > of the cryptographic identity used for peer-to-peer > authentication/encryption. > > IMHO we should be looking a key centric approaches that loosely > bind one or more sets of names/email addresses to public key identifiers. > > Paul > > > > On 12/29/13, 11:38 AM, "Watson Ladd" wrote: > >> One obvious solution for end-to-end email encryption is to use >> ID-based cryptography: a new record type would be defined in the DNS >> containing the system key for an ID-based system, and the username >> (everything before the '@') would be the identity used. This would not >> obscure addresses or the fact of communication right now, but would >> prevent interception at intermediate nodes. It would be webmail >> compatible. >> >> Are there any issues beyond the merely cryptographic that I need to >> consider here? Can this be shoehorned into S/MIME, or do we need to do >> something new? In the next few days I will try to make a >> draft/implementation for this. >> >> Sincerely, >> Watson Ladd >> _______________________________________________ >> perpass mailing list >> perpass@ietf.org >> https://www.ietf.org/mailman/listinfo/perpass > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass From perpass@bleeter.id.au Mon Dec 30 11:56:18 2013 Return-Path: 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 90C981AE29A for ; Mon, 30 Dec 2013 11:56:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-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 QUB9UYwP3faM for ; Mon, 30 Dec 2013 11:56:17 -0800 (PST) Received: from obsidian.cagechimps.com (obsidian.cagechimps.com [216.218.196.40]) by ietfa.amsl.com (Postfix) with ESMTP id 4E1141AE254 for ; Mon, 30 Dec 2013 11:56:17 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by obsidian.cagechimps.com (Postfix) with ESMTP id A116B526F4A; Mon, 30 Dec 2013 19:56:11 +0000 (UTC) Received: from obsidian.cagechimps.com ([127.0.0.1]) by localhost (obsidian.cagechimps.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 1IjruHBbJ3mk; Mon, 30 Dec 2013 19:56:10 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by obsidian.cagechimps.com (Postfix) with ESMTP id 6AE29526FE8; Mon, 30 Dec 2013 19:56:10 +0000 (UTC) X-Virus-Scanned: amavisd-new at obsidian.cagechimps.com Received: from obsidian.cagechimps.com ([127.0.0.1]) by localhost (obsidian.cagechimps.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id dZaY5YlN_d1r; Mon, 30 Dec 2013 19:56:10 +0000 (UTC) Received: from carl.vla.bleet (ppp108-18.static.internode.on.net [150.101.108.18]) by obsidian.cagechimps.com (Postfix) with ESMTPSA id A6707526FBC; Mon, 30 Dec 2013 19:56:09 +0000 (UTC) Message-ID: <52C1CFD7.3080104@bleeter.id.au> Date: Tue, 31 Dec 2013 06:56:07 +1100 From: Peter Lawler User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: perpass References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Phillip Hallam-Baker Subject: Re: [perpass] ID based encryption for email 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Dec 2013 19:56:18 -0000 On 31/12/13 06:25, Phillip Hallam-Baker wrote: > > PGP has not met the original goal of becoming ubiquitous so replacing PGP > seems to me to be a very worthwhile goal. Replacing STARTTLS with something > that has message scope but is not end to end does not seem like a good > proposition. > Maybe a little OT on this thread, but for those who missed it (OpenPGPv4) Key IDs seem to have problems (at least when those pesky humans get involved) http://www.ietf.org/mail-archive/web/openpgp/current/msg07195.html http://debian-administration.org/users/dkg/weblog/105 +1 for replacing PGP. Pete. From paul@marvell.com Mon Dec 30 12:38:55 2013 Return-Path: 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 68A871AE22B for ; Mon, 30 Dec 2013 12:38:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.557 X-Spam-Level: X-Spam-Status: No, score=-1.557 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] 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 1h0W5k39t43f for ; Mon, 30 Dec 2013 12:38:54 -0800 (PST) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) by ietfa.amsl.com (Postfix) with ESMTP id 0BCBE1AE149 for ; Mon, 30 Dec 2013 12:38:53 -0800 (PST) Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.14.5/8.14.5) with SMTP id rBUKciri010548; Mon, 30 Dec 2013 12:38:44 -0800 Received: from sc-owa02.marvell.com ([199.233.58.137]) by mx0b-0016f401.pphosted.com with ESMTP id 1h0e8wj8x0-12 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 30 Dec 2013 12:38:44 -0800 Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by sc-owa02.marvell.com ([10.93.76.22]) with mapi; Mon, 30 Dec 2013 12:38:43 -0800 From: Paul Lambert To: Hannes Tschofenig , "perpass@ietf.org" Date: Mon, 30 Dec 2013 12:38:41 -0800 Thread-Topic: [perpass] ID based encryption for email Thread-Index: Ac8FnyE0MnWoLyCNT4WOWZz66V1rlQ== Message-ID: References: <52C1CD57.2080909@gmx.net> In-Reply-To: <52C1CD57.2080909@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.87, 1.0.14, 0.0.0000 definitions=2013-12-30_02:2013-12-30,2013-12-30,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1312300145 Cc: Watson Ladd Subject: Re: [perpass] ID based encryption for email 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Dec 2013 20:38:55 -0000 Hi Hannes, >Hi Paul, > >I am now guess what you are trying to say here. So, apologies for >misinterpreting your suggestion. No apologies required .. You should always ignore what I type and only pay attention to what I mean :-) > >Some on this list are trying to do the following: they take the existing >email infrastructure as a starting point and brainstorm about how to add >end-to-end security to it. Of course, there are solutions available >already (namely S/MIME and PGP) but both are not widely deployed for a >variety of reasons *. S/MIME and PGP have specific public key trust models that have > >Another approach, however, is to start from scratch and to define an >entirely new email system, which uses cryptographic addresses instead of >human-readable identifiers. I guess that's the approach you are >suggesting. Is this correct? Yes - we should start from scratch (versus direct augmentation of S/MIME/PKI or PGP). In a key centric model, the recipient would be identified by a cryptographic identifier. P2P authentication would be based on the identifier and the friendly human readable email address would be secondary or even unbound. Decentralized transitive binding of email addresses to a identifier should be possible, but not mandated (e.g. signed bindings/certificates of id to Email address). This would be =8Cforest=B9 versus =8Csingle tree=B9 model for name/attribute binding. Where there was no visible explicit binding, some level of anonymity and traffic analysis protection could be provided. =20 Public keys and identifiers for public keys (e.g. Hash of key) could be used for more than email. I=B9m currently working on layer 2 proposals for P2P authentication with these ideas, but see no reason that the same model should not work quite well for email. Paul > > >Ciao >Hannes > >PS: It would be great if someone could point me to a good write-up about >the reasons why these two solutions are not widely deployed. I know >about a number of "not-so-useful" write-ups... > > > >On 12/30/2013 06:26 PM, Paul Lambert wrote: >> Why do we even need DNS and names for email encryption? >> >> The path/address to reach a peer should be independent >> of the cryptographic identity used for peer-to-peer >> authentication/encryption. >> >> IMHO we should be looking a key centric approaches that loosely >> bind one or more sets of names/email addresses to public key >>identifiers. >> >> Paul >> >> >> >> On 12/29/13, 11:38 AM, "Watson Ladd" wrote: >> >>> One obvious solution for end-to-end email encryption is to use >>> ID-based cryptography: a new record type would be defined in the DNS >>> containing the system key for an ID-based system, and the username >>> (everything before the '@') would be the identity used. This would not >>> obscure addresses or the fact of communication right now, but would >>> prevent interception at intermediate nodes. It would be webmail >>> compatible. >>> >>> Are there any issues beyond the merely cryptographic that I need to >>> consider here? Can this be shoehorned into S/MIME, or do we need to do >>> something new? In the next few days I will try to make a >>> draft/implementation for this. >>> >>> Sincerely, >>> Watson Ladd >>> _______________________________________________ >>> perpass mailing list >>> perpass@ietf.org >>> https://www.ietf.org/mailman/listinfo/perpass >> _______________________________________________ >> perpass mailing list >> perpass@ietf.org >> https://www.ietf.org/mailman/listinfo/perpass > From dhc@dcrocker.net Mon Dec 30 12:45:45 2013 Return-Path: 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 80B601AE550 for ; Mon, 30 Dec 2013 12:45:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 5Qak6I90hyv1 for ; Mon, 30 Dec 2013 12:45:44 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 756401AE22B for ; Mon, 30 Dec 2013 12:45:44 -0800 (PST) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id rBUKjUq6020737 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 30 Dec 2013 12:45:33 -0800 Message-ID: <52C1DB11.4080706@dcrocker.net> Date: Mon, 30 Dec 2013 12:44:01 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Paul Lambert , Hannes Tschofenig , "perpass@ietf.org" References: <52C1CD57.2080909@gmx.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Mon, 30 Dec 2013 12:45:33 -0800 (PST) Cc: Watson Ladd Subject: Re: [perpass] ID based encryption for email X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net 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: Mon, 30 Dec 2013 20:45:45 -0000 On 12/30/2013 12:38 PM, Paul Lambert wrote: >> Another approach, however, is to start from scratch and to define an >> >entirely new email system, which uses cryptographic addresses instead of >> >human-readable identifiers. I guess that's the approach you are >> >suggesting. Is this correct? > Yes - we should start from scratch (versus direct > augmentation of S/MIME/PKI or PGP). Starting from scratch to build a new email system is not likely to succeed, any more than the various, earlier efforts to do that succeeded, back when the installed base was a few orders of magnitude smaller and adoption of a new system relatively easier. And then there is the small matter of wondering how viable the human factors of cryptographic email addresses will prove to be... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From paul@marvell.com Mon Dec 30 13:42:29 2013 Return-Path: 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 827B91AE2AB for ; Mon, 30 Dec 2013 13:42:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.567 X-Spam-Level: X-Spam-Status: No, score=-1.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, SPF_PASS=-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 YVboQJWnUaEa for ; Mon, 30 Dec 2013 13:42:28 -0800 (PST) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) by ietfa.amsl.com (Postfix) with ESMTP id 778A51AE279 for ; Mon, 30 Dec 2013 13:42:28 -0800 (PST) Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.14.5/8.14.5) with SMTP id rBULgE1w027353; Mon, 30 Dec 2013 13:42:14 -0800 Received: from sc-owa01.marvell.com ([199.233.58.136]) by mx0b-0016f401.pphosted.com with ESMTP id 1h0e8wjf8e-11 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 30 Dec 2013 13:42:14 -0800 Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA01.marvell.com ([10.93.76.21]) with mapi; Mon, 30 Dec 2013 13:42:10 -0800 From: Paul Lambert To: "dcrocker@bbiw.net" , Hannes Tschofenig , "perpass@ietf.org" Date: Mon, 30 Dec 2013 13:42:09 -0800 Thread-Topic: [perpass] ID based encryption for email Thread-Index: Ac8Fp/5EIGGHLW9hQC+Z5JS1a5f28w== Message-ID: References: <52C1CD57.2080909@gmx.net> <52C1DB11.4080706@dcrocker.net> In-Reply-To: <52C1DB11.4080706@dcrocker.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.87, 1.0.14, 0.0.0000 definitions=2013-12-30_02:2013-12-30,2013-12-30,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1312300159 Cc: Watson Ladd Subject: Re: [perpass] ID based encryption for email 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Dec 2013 21:42:29 -0000 On 12/30/13, 12:44 PM, "Dave Crocker" wrote: >On 12/30/2013 12:38 PM, Paul Lambert wrote: >>> Another approach, however, is to start from scratch and to define an >>> >entirely new email system, which uses cryptographic addresses instead >>>of >>> >human-readable identifiers. I guess that's the approach you are >>> >suggesting. Is this correct? >> Yes - we should start from scratch (versus direct >> augmentation of S/MIME/PKI or PGP). > > >Starting from scratch to build a new email system is not likely to >succeed, any more than the various, earlier efforts to do that >succeeded, back when the installed base was a few orders of magnitude >smaller and adoption of a new system relatively easier. To be clear, I am not advocating replacing the underlying protocols for email delivery (SMTP, IMAP, etc.) MIME encapsulation would likely still be the best transport. > >And then there is the small matter of wondering how viable the human >factors of cryptographic email addresses will prove to be... My proposal is to unbind the cryptographic identifier - it would not need to be part of the address. However, using such an identifier in an address might be an interesting transport technique. UIs already map user name to email address =8A S/MIME, PGP or anything new all need some supporting user model and software to map address to perceived identity. Paul > >d/ > >--=20 >Dave Crocker >Brandenburg InternetWorking >bbiw.net From yaojk@cnnic.cn Mon Dec 30 17:49:28 2013 Return-Path: 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 365211AE35E for ; Mon, 30 Dec 2013 17:49:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538] 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 qjbDf8H7VOix for ; Mon, 30 Dec 2013 17:49:26 -0800 (PST) Received: from cnnic.cn (smtp.cnnic.cn [218.241.118.7]) by ietfa.amsl.com (Postfix) with SMTP id 43B371AE305 for ; Mon, 30 Dec 2013 17:49:25 -0800 (PST) X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown127.0.0.1 (HELO healthyao-think) (127.0.0.1) by 127.0.0.1 with SMTP; Tue, 31 Dec 2013 09:49:17 +0800 Date: Tue, 31 Dec 2013 09:49:18 +0800 From: "Jiankang Yao" To: "Watson Ladd" References: , X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.92[cn] Mime-Version: 1.0 Message-ID: <2013123109484927181884@cnnic.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart765637176718_=----" Cc: perpass Subject: Re: [perpass] ID based encryption for email X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Jiankang 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: Tue, 31 Dec 2013 01:49:28 -0000 This is a multi-part message in MIME format. ------=_001_NextPart765637176718_=---- Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 DQpGcm9tOiBXYXRzb24gTGFkZA0KRGF0ZTogMjAxMy0xMi0zMCAwNjozMg0KVG86IFBoaWxsaXAg SGFsbGFtLUJha2VyDQpDQzogcGVycGFzcw0KU3ViamVjdDogUmU6IFtwZXJwYXNzXSBJRCBiYXNl ZCBlbmNyeXB0aW9uIGZvciBlbWFpbA0KT24gU3VuLCBEZWMgMjksIDIwMTMgYXQgNTowOCBQTSwg UGhpbGxpcCBIYWxsYW0tQmFrZXIgPGhhbGxhbUBnbWFpbC5jb20+IHdyb3RlOg0KPg0KPg0KPg0K PiBPbiBTdW4sIERlYyAyOSwgMjAxMyBhdCAyOjM4IFBNLCBXYXRzb24gTGFkZCA8d2F0c29uYmxh ZGRAZ21haWwuY29tPiB3cm90ZToNCj4+DQo+PiBPbmUgb2J2aW91cyBzb2x1dGlvbiBmb3IgZW5k LXRvLWVuZCBlbWFpbCBlbmNyeXB0aW9uIGlzIHRvIHVzZQ0KPj4gSUQtYmFzZWQgY3J5cHRvZ3Jh cGh5OiBhIG5ldyByZWNvcmQgdHlwZSB3b3VsZCBiZSBkZWZpbmVkIGluIHRoZSBETlMNCj4+IGNv bnRhaW5pbmcgdGhlIHN5c3RlbSBrZXkgZm9yIGFuIElELWJhc2VkIHN5c3RlbSwgYW5kIHRoZSB1 c2VybmFtZQ0KPj4gKGV2ZXJ5dGhpbmcgYmVmb3JlIHRoZSAnQCcpIHdvdWxkIGJlIHRoZSBpZGVu dGl0eSB1c2VkLiBUaGlzIHdvdWxkIG5vdA0KPj4gb2JzY3VyZSBhZGRyZXNzZXMgb3IgdGhlIGZh Y3Qgb2YgY29tbXVuaWNhdGlvbiByaWdodCBub3csIGJ1dCB3b3VsZA0KPj4gcHJldmVudCBpbnRl cmNlcHRpb24gYXQgaW50ZXJtZWRpYXRlIG5vZGVzLiANCg0KDQplbWFpbCBpbmNsdWRlcyBtYW55 IGhlYWRlciBmaWVsZHM7IHNvbWUgZmllbGRzIG1heSBub3QgYmUgZW5jcnlwdGVkLiANCnlvdSBw bGFuIHRvIGVuY3J5cHQgdGhlIGFkZHJlc3MgZm9yICJtYWlsIGZyb20iIGFuZCAicmNwdCB0byIg dG9vPw== ------=_001_NextPart765637176718_=---- Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
 
Date: 2013-12-30 06:32
CC: perpass
Subject: Re: [perpass] ID based encryption for=20 email
On Sun, Dec 29, 2013 at 5:08 PM,&n= bsp;Phillip Hallam-Baker <hallam@gmail.com> wrote:
>
>
>
> On Sun, Dec 29, 2013 at 2:38&= nbsp;PM, Watson Ladd <watsonbladd@gmail.com> wro= te:
>>
>> One obvious solution for end-to-end=  email encryption is to use
>> ID-based cryptography: a new record=  type would be defined in the DNS
>> containing the system key for = an ID-based system, and the username
>> (everything before the '@') would&n= bsp;be the identity used. This would not
>> obscure addresses or the fact = of communication right now, but would
>> prevent interception at intermediate&nbs= p;nodes. 
 
 
email includes many header fields; some fields may not be=20 encrypted.
you plan to encrypt the address for "mail from" and "rcpt to" too?
 
------=_001_NextPart765637176718_=------ From mcr@sandelman.ca Tue Dec 31 05:21:39 2013 Return-Path: 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 C122F1AE2A3 for ; Tue, 31 Dec 2013 05:21:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.918 X-Spam-Level: ** X-Spam-Status: No, score=2.918 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FH_RELAY_NODNS=1.451, RDNS_NONE=0.793, SPF_SOFTFAIL=0.665, T_TVD_MIME_NO_HEADERS=0.01] 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 2LyfuSCwqNE7 for ; Tue, 31 Dec 2013 05:21:38 -0800 (PST) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id 20D511AE28E for ; Tue, 31 Dec 2013 05:21:37 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 057572003B; Tue, 31 Dec 2013 09:36:22 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 789F363AD9; Tue, 31 Dec 2013 08:21:25 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 6AA2E63AD7; Tue, 31 Dec 2013 08:21:25 -0500 (EST) From: Michael Richardson To: Phillip Hallam-Baker In-Reply-To: References: X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Cc: Watson Ladd , perpass Subject: Re: [perpass] ID based encryption for email 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Dec 2013 13:21:40 -0000 --=-=-= Phillip Hallam-Baker wrote: > PGP has not met the original goal of becoming ubiquitous so replacing > PGP seems to me to be a very worthwhile goal. Replacing STARTTLS with > something that has message scope but is not end to end does not seem > like a good proposition. I reluctantly agree that maintaining any kind of backwards compatibility with PGP or S/MIME SHOULD NOT be a requirement. (If it happens that I can leverage, through new code/protocol, my existing web of trust, that could be a MAY) PGP did not take off because it was too decentralized and therefore very enterprise hostile, and so it failed to get past early adopters. S/MIME did not take off because it was too centralized and therefore early adopter hostile. Both then ran up against webmail systems, e.g: hotmail/gmail/etc. in the early 2000s, when having had the RSA patent run out, a renewed push could have occured. That problem will affect any new solution as well. I look forward to reviewing drafts, and running beta code. Who is going to make money on this system? What's the market incentive to deploy? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting for hire =- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUsLE0oqHRg3pndX9AQIs9AQAmHEGiRaMl5wbvBTgKJw+8mLYPzLUkGm9 /gnpMuSbf4TO0Ru5s1NFs1pFhS1gkdxzlEfSBDxrCdYhdRwFWKcc0AyG1g7jnj6c V0uAxVJKsGl9y5+jYNGc6AdDDAq00EVmNJfb3HYeQv7if3vYX+LaLaOgP5BOhrd4 RTfLDjf761Q= =b6BN -----END PGP SIGNATURE----- --=-=-=-- From derhoermi@gmx.net Tue Dec 31 10:27:09 2013 Return-Path: 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 6D8921AE0E7 for ; Tue, 31 Dec 2013 10:27:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.262 X-Spam-Level: X-Spam-Status: No, score=0.262 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.538, 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 OFLvcpHLXrwa for ; Tue, 31 Dec 2013 10:27:06 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id 802FC1AE31B for ; Tue, 31 Dec 2013 10:27:06 -0800 (PST) Received: from netb.Speedport_W_700V ([91.35.2.90]) by mail.gmx.com (mrgmx103) with ESMTPA (Nemesis) id 0M09Ee-1VAlEU3v00-00uKvt for ; Tue, 31 Dec 2013 19:26:59 +0100 From: Bjoern Hoehrmann To: dcrocker@bbiw.net Date: Tue, 31 Dec 2013 19:26:59 +0100 Message-ID: References: <52C1CD57.2080909@gmx.net> <52C1DB11.4080706@dcrocker.net> In-Reply-To: <52C1DB11.4080706@dcrocker.net> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:UMqx4GHdL8OLUs96j9RrDA1i4Ac6oBHKfKce88Dwx8s31zgSs7K Qe7f/n80CvPfmB0D/AuPmfiDVMEKQJxUu/B0GjBjPs1nOd4pAnhzn3IOMsGS9TWuJ2naQiR K2aFih/HjI4wn5XDykNNWMVCVFph0JnnzKY89BVAgBwNC298UzZAPpdnnAKVOhrfxcr7Vbh zPK7rfT1WKyuL5EpliJ1Q== Cc: "perpass@ietf.org" Subject: Re: [perpass] ID based encryption for email 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Dec 2013 18:27:09 -0000 * Dave Crocker wrote: >Starting from scratch to build a new email system is not likely to >succeed, any more than the various, earlier efforts to do that >succeeded, back when the installed base was a few orders of magnitude >smaller and adoption of a new system relatively easier. What makes the new email system different from other new communication media with hundreds of millions of users and why is it necessary for it to have those properties? Looking at Skype, WhatsApp, Facebook, Bit- Torrent, and many others, it seems simple to achieve mass adoption. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From derhoermi@gmx.net Tue Dec 31 10:47:19 2013 Return-Path: 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 EBA6B1AE2F2 for ; Tue, 31 Dec 2013 10:47:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.538, 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 ySpfxq3SjBJ4 for ; Tue, 31 Dec 2013 10:47:17 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id 4DE2C1AE2EB for ; Tue, 31 Dec 2013 10:47:17 -0800 (PST) Received: from netb.Speedport_W_700V ([91.35.2.90]) by mail.gmx.com (mrgmx102) with ESMTPA (Nemesis) id 0MIPhr-1W0Ye91SZj-00480Y for ; Tue, 31 Dec 2013 19:47:10 +0100 From: Bjoern Hoehrmann To: Hannes Tschofenig Date: Tue, 31 Dec 2013 19:47:11 +0100 Message-ID: References: <52C1CD57.2080909@gmx.net> In-Reply-To: <52C1CD57.2080909@gmx.net> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:X6aORrtD/1GJM1wM82E80DzSJIyjokkSK6atpMUSNvok+uxWJ47 D0KG7mWRDWxGcrpEsJTk0OPZtc3hBCAe7kEd6zBkhnyEsGae9H+cvYlcS/e/KSssB+zDZfo 8B/O2AquHjV6v/XXvzwzPv9IPWWUl8KjB3WakQJTbHqzXSiG57z0mOZN900Zn1Lj/kfBf2h nHvyhXjuPn1sq5DP7bbmw== Cc: "perpass@ietf.org" Subject: Re: [perpass] ID based encryption for email 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Dec 2013 18:47:19 -0000 * Hannes Tschofenig wrote: >PS: It would be great if someone could point me to a good write-up about >the reasons why these two solutions are not widely deployed. I know >about a number of "not-so-useful" write-ups... A current problem is that "webmail" systems cannot support either with- out compromising the long term keys involved and the confidentiality of the messages without proprietary and privileged web browser extensions. That is something that probably can reasonably be addressed but if some standardisation effort to that effect exists, then I have missed it. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From hallam@gmail.com Tue Dec 31 10:50:59 2013 Return-Path: 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 8C27F1AE3D3 for ; Tue, 31 Dec 2013 10:50:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 6sRUaoXtN1Oj for ; Tue, 31 Dec 2013 10:50:56 -0800 (PST) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 0F8341AE372 for ; Tue, 31 Dec 2013 10:50:55 -0800 (PST) Received: by mail-la0-f43.google.com with SMTP id n7so6539539lam.30 for ; Tue, 31 Dec 2013 10:50:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=w8ZBkV50GwO3KJ0XB732e57xB3yiiLU0J4T6kcTWA4U=; b=jIYtvwiKyiCLR3WliQ7btKyslLrWt6V/WxF4N+9R1cDY3V574iAgn32Ng78kZJSDZJ VmrPceo4mMtqwpp6YFUvYzrrxCwlxzAyIfoQ207qKiyvUyCFLrf8slvDBP9mFQ++oAH2 T5m8tvfXCvd1bvpOlGCEZREI89rh/rebZR/sX6Dkv0GGrx3c8XAMK7MxBBdLxP2TH4Mg 2Waagj/yOHXbuM/BAWyHzEvl6Dzts5yKofzNj/D5FVO5PNj/XVWi51ZoZ+NYKmUVHdAL 5yNL0JvCK8CdF0XKdqywWGOISqybaRZqpDKlKxj3P6C6UlhwWqBi3qxGboQYCWrQAi2M u5Zg== MIME-Version: 1.0 X-Received: by 10.152.1.197 with SMTP id 5mr30481926lao.0.1388515848881; Tue, 31 Dec 2013 10:50:48 -0800 (PST) Received: by 10.112.37.172 with HTTP; Tue, 31 Dec 2013 10:50:48 -0800 (PST) In-Reply-To: <31111.1388496085@sandelman.ca> References: <31111.1388496085@sandelman.ca> Date: Tue, 31 Dec 2013 13:50:48 -0500 Message-ID: From: Phillip Hallam-Baker To: Michael Richardson Content-Type: multipart/alternative; boundary=089e0112bfcef00b8504eed909ca Cc: Watson Ladd , perpass Subject: Re: [perpass] ID based encryption for email 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Dec 2013 18:50:59 -0000 --089e0112bfcef00b8504eed909ca Content-Type: text/plain; charset=ISO-8859-1 On Tue, Dec 31, 2013 at 8:21 AM, Michael Richardson wrote: > > Phillip Hallam-Baker wrote: > > PGP has not met the original goal of becoming ubiquitous so replacing > > PGP seems to me to be a very worthwhile goal. Replacing STARTTLS with > > something that has message scope but is not end to end does not seem > > like a good proposition. > > I reluctantly agree that maintaining any kind of backwards compatibility > with > PGP or S/MIME SHOULD NOT be a requirement. > No, I did not say that. Backwards compatibility is probably a deployment requirement. But I don't think that there is any group that is slavishly devoted to PGP or nothing. There is an S/MIME or nothing group but that is a different matter and their commitment does not exclude adding PGP like features. My original point was that re-inventing the wheel is only a bad thing if a scheme has already succeeded and is ubiquitously deployed and in use. So people need not be afraid of re-inventing PGP or S/MIME but proposals for a new scheme that would meet the STARTTLS use cases have to meet a much higher bar. > (If it happens that I can leverage, through new code/protocol, my existing > web of trust, that could be a MAY) > I can make use of PGP keys and fingerprints in my proposal. But they are more limited than the phingerprints that I use in strong email addresses. In the current code a phingerprint is a digest of a master key that is only used to sign policy statements. which in turn authorize the use of encryption and/or signature keys. So there is always a policy layer. The advantage this brings is that if people are using my scheme the infrastructure will always support publication of a statement such as 'PGP format encryption preferred'. While S/MIME and PGP both lack this essential capability. [And no, the fact that some dufuses have made a hash of security policy in the past does not make it an impossible problem or one to avoid tackling] > PGP did not take off because it was too decentralized and therefore very > enterprise > hostile, and so it failed to get past early adopters. > S/MIME did not take off because it was too centralized and therefore early > adopter hostile. > I think the issue is actually simpler. The criteria for ubiquitous adoption of a security technology is that it has to be 100% right and S/MIME, PGP are only 95% there. Good enough for government work doesn't cut it for mass adoption of S/MIME. The PGP ideology gets in the way of PGP use. Building the toll booths and hoping the revenues will pay for building the highway is never a good strategy. > Both then ran up against webmail systems, e.g: hotmail/gmail/etc. in the > early 2000s, when having had the RSA patent run out, a renewed push could > have occured. That problem will affect any new solution as well. > I don't think Webmail needs to be considered a show stopper. I use Gmail to organize all my mail through mailing lists because it has the search capability and it can handle my mail volume (I am atg 8.09 GB (53%) of 15 GB used) I would have no problem using a different client to send encrypted mail and a browser extension could make reading encrypted mail possible. Making this work is important to me as I invented WebMail back when I was at CERN. Implementing Web Mail is what lead to the Content-Length header in HTTP after I discovered that the HTTP POST spec was broken in 1993. (And yes this is prior art for a certain patent claim). > I look forward to reviewing drafts, and running beta code. > Who is going to make money on this system? > What's the market incentive to deploy? > Good https://sourceforge.net/projects/prismproof The market incentive is that the Web+SLL gave us the Internet e-commerce boom which added several percent to world GDP in the 1990s. Email is the other killer application of the Internet and there is the potential for another economic boost albeit maybe a smaller one. Current e-commerce is limited to the patterns that are supported by our current security tools. If we add more security tools we may see more e-commerce patterns. -- Website: http://hallambaker.com/ --089e0112bfcef00b8504eed909ca Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Dec 31, 2013 at 8:21 AM, Michael Richardson <mcr+ietf@= sandelman.ca> wrote:

Phillip Hallam-Baker <hallam@gmail.c= om> wrote:
=A0 =A0 > PGP has not met the original goal of becoming ubiquitous so re= placing
=A0 =A0 > PGP seems to me to be a very worthwhile goal. Replacing STARTT= LS with
=A0 =A0 > something that has message scope but is not end to end does no= t seem
=A0 =A0 > like a good proposition.

I reluctantly agree that maintaining any kind of backwards compatibil= ity with
PGP or S/MIME SHOULD NOT be a requirement.

<= div>No, I did not say that. Backwards compatibility is probably a deploymen= t requirement. But I don't think that there is any group that is slavis= hly devoted to PGP or nothing. There is an S/MIME or nothing group but that= is a different matter and their commitment does not exclude adding PGP lik= e features.

My original point was that re-inventing the wheel is on= ly a bad thing if a scheme has already succeeded and is ubiquitously deploy= ed and in use. So people need not be afraid of re-inventing PGP or S/MIME b= ut proposals for a new scheme that would meet the STARTTLS use cases have t= o meet a much higher bar.

=A0
(If it happens that I can leverage, through new code/protocol, my existing<= br> web of trust, that could be a MAY)

I ca= n make use of PGP keys and fingerprints in my proposal. But they are more l= imited than the phingerprints that I use in strong email addresses.

In the current code a phingerprint is a digest of a mas= ter key that is only used to sign policy statements. which in turn authoriz= e the use of encryption and/or signature keys. So there is always a policy = layer.=A0

The advantage this brings is that if people are using m= y scheme the infrastructure will always support publication of a statement = such as 'PGP format encryption preferred'. While S/MIME and PGP bot= h lack this essential capability. [And no, the fact that some dufuses have = made a hash of security policy in the past does not make it an impossible p= roblem or one to avoid tackling]

=A0
PGP did not take off because it was too decentralized and therefore very en= terprise
=A0 =A0 hostile, and so it failed to get past early adopters.
S/MIME did not take off because it was too centralized and therefore early<= br> =A0 =A0 adopter hostile.

I think the is= sue is actually simpler. The criteria for ubiquitous adoption of a security= technology is that it has to be 100% right and S/MIME, PGP are only 95% th= ere.

Good enough for government work doesn't cut it for = mass adoption of S/MIME. The PGP ideology gets in the way of PGP use. Build= ing the toll booths and hoping the revenues will pay for building the highw= ay is never a good strategy.

=A0
Both then ran up against webmail systems, e.g: hotmail/gmail/etc. in the early 2000s, when having had the RSA patent run out, a renewed push could have occured. =A0That problem will affect any new solution as well.

I don't think Webmail needs to be consider= ed a show stopper. I use Gmail to organize all my mail through mailing list= s because it has the search capability and it can handle my mail volume (I = am atg=A08.09 GB=A0(= 53%) of=A015 GB I look forward to reviewing drafts, and running beta code.
Who is going to make money on this system?
What's the market incentive to deploy?

<= div>Good


The market incentive is that the Web+SLL gave us the Interne= t e-commerce boom which added several percent to world GDP in the 1990s. Em= ail is the other killer application of the Internet and there is the potent= ial for another economic boost albeit maybe a smaller one.

Current e-commerce is limited to the patterns that are = supported by our current security tools. If we add more security tools we m= ay see more e-commerce patterns.

--
Website: = http://hallambaker.com/
--089e0112bfcef00b8504eed909ca-- From hallam@gmail.com Tue Dec 31 11:03:16 2013 Return-Path: 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 9AD621AE3CC for ; Tue, 31 Dec 2013 11:03:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 ny3JoU45panG for ; Tue, 31 Dec 2013 11:03:15 -0800 (PST) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id B4AC91AE2D5 for ; Tue, 31 Dec 2013 11:03:14 -0800 (PST) Received: by mail-la0-f51.google.com with SMTP id ec20so6482650lab.10 for ; Tue, 31 Dec 2013 11:03:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JLszJVC/ot9sbSvXzi7Udtex7WSV9tjTQ+k2I9ZpGhQ=; b=iXfNAw6IT8Up+YzbGBOG+p7sb+QdSH7azChRjj6p+w/YmGhGT33QXNZ4uXta89/zQW DyzmLuFlXpCaZKMdUdVqYw1j+JLtQRK0pkyBWeVii2XGgLPkrK18B8YQbgrdV5GVelvb 27PRgNDQWSgXFzZoqGeK4KP4XFQe/OUyI1fEG+dHLoaVM0fu8dUhYgOvj/YJTy8HemLH V1DfAc8biuMaekKXROznrRhGXFyApYHf7zwn4rA6nZ3eMgB7FiZgwzAm13JOQhQtoWT5 6GM6z2bwkQ/Jxd4fUlWoN7qXXvQs11GfI80hcnHPIXxSkv+xUu21rDDPbREuSc5OfzD5 vBhA== MIME-Version: 1.0 X-Received: by 10.152.120.7 with SMTP id ky7mr458869lab.83.1388516587757; Tue, 31 Dec 2013 11:03:07 -0800 (PST) Received: by 10.112.37.172 with HTTP; Tue, 31 Dec 2013 11:03:07 -0800 (PST) In-Reply-To: <52C1DB11.4080706@dcrocker.net> References: <52C1CD57.2080909@gmx.net> <52C1DB11.4080706@dcrocker.net> Date: Tue, 31 Dec 2013 14:03:07 -0500 Message-ID: From: Phillip Hallam-Baker To: Dave Crocker Content-Type: multipart/alternative; boundary=089e0117690dfa64fc04eed935e2 Cc: Paul Lambert , Watson Ladd , "perpass@ietf.org" , Hannes Tschofenig Subject: Re: [perpass] ID based encryption for email 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Dec 2013 19:03:16 -0000 --089e0117690dfa64fc04eed935e2 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Dec 30, 2013 at 3:44 PM, Dave Crocker wrote: > On 12/30/2013 12:38 PM, Paul Lambert wrote: > >> Another approach, however, is to start from scratch and to define an >>> >entirely new email system, which uses cryptographic addresses instead of >>> >human-readable identifiers. I guess that's the approach you are >>> >suggesting. Is this correct? >>> >> Yes - we should start from scratch (versus direct >> augmentation of S/MIME/PKI or PGP). >> > > > Starting from scratch to build a new email system is not likely to > succeed, any more than the various, earlier efforts to do that succeeded, > back when the installed base was a few orders of magnitude smaller and > adoption of a new system relatively easier. > > And then there is the small matter of wondering how viable the human > factors of cryptographic email addresses will prove to be... Starting from scratch is not likely to succeed. Any new scheme has to support SMTP for legacy. But when I am looking at adding crypto to SMTP+JABBER+SIP etc and realize that 90% of the effort required is due to having to retrofit the security to a badly designed protocol, I think that it is quite likely easier to support secure JABBER etc. through a new protocol with crypto designed in from the start and that if the messaging protocol is done right it would be capable of being used as an SMTP replacement as well. The reason for replacing SMTP would be not so much to replace the protocol as to distinguish infrastructure that is designed with some sort of clue from the muck that festers out in SMTP land. There will always be some twit bleating on about how a change to the protocol is completely unacceptable because he might have to stop using his 30 year old mail server program. Mailing lists will never work well in SMTP because the protocol does not really support them properly and the extensions designed to add support are not supported in the clients. The only way to fix support properly is for control messages to follow the same path as outbound messages and the only way to make that change is to move to a new protocol. That can't be done in the current mail system but it is easy to do if there is a policy layer. Any mechanism that can be used to tell the sending mail client that S/MIME or PGP format mail is preferred can in principle be used to say that the mail should be sent over some JSON-B based REST scheme that provides a superset of SMTP and JABBER capabilities. -- Website: http://hallambaker.com/ --089e0117690dfa64fc04eed935e2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, Dec 30, 2013 at 3:44 PM, Dave Crocker <= ;dhc@dcrocker.net= > wrote:
On 12/30/2013 12:38 PM, Pa= ul Lambert wrote:
Another approach, however, is to start from scratch and to define an
>entirely new email system, which uses cryptographic addresses instead o= f
>human-readable identifiers. I guess that's the approach you are
>suggesting. Is this correct?
Yes - we should start from scratch (versus direct
augmentation of S/MIME/PKI or PGP).


Starting from scratch to build a new email system is not likely to succeed,= any more than the various, earlier efforts to do that succeeded, back when= the installed base was a few orders of magnitude smaller and adoption of a= new system relatively easier.

And then there is the small matter of wondering how viable the human factor= s of cryptographic email addresses will prove to be...
Starting from scratch is not likely to succeed. Any new scheme = has to support SMTP for legacy.

But when I am looking at adding crypto to SMTP+JABBER+S= IP etc and realize that 90% of the effort required is due to having to retr= ofit the security to a badly designed protocol, I think that it is quite li= kely easier to support secure JABBER etc. through a new protocol with crypt= o designed in from the start and that if the messaging protocol is done rig= ht it would be capable of being used as an SMTP replacement as well.


The reason for replacing SMTP would be n= ot so much to replace the protocol as to distinguish infrastructure that is= designed with some sort of clue from the muck that festers out in SMTP lan= d. There will always be some twit bleating on about how a change to the pro= tocol is completely unacceptable because he might have to stop using his 30= year old mail server program.

Mailing lists will never work well in SMTP because the = protocol does not really support them properly and the extensions designed = to add support are not supported in the clients. The only way to fix suppor= t properly is for control messages to follow the same path as outbound mess= ages and the only way to make that change is to move to a new protocol.


That can't be done in the current ma= il system but it is easy to do if there is a policy layer. Any mechanism th= at can be used to tell the sending mail client that S/MIME or PGP format ma= il is preferred can in principle be used to say that the mail should be sen= t over some JSON-B based REST scheme that provides a superset of SMTP and J= ABBER capabilities.

--
Website: ht= tp://hallambaker.com/
--089e0117690dfa64fc04eed935e2-- From dhc@dcrocker.net Tue Dec 31 11:10:22 2013 Return-Path: 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 B806C1AE3D6 for ; Tue, 31 Dec 2013 11:10:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 qvcFtpt85-T2 for ; Tue, 31 Dec 2013 11:10:20 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3476F1AE34B for ; Tue, 31 Dec 2013 11:10:20 -0800 (PST) Received: from [192.168.1.6] (cpe-76-93-140-82.san.res.rr.com [76.93.140.82]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id rBVJA75v006413 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 31 Dec 2013 11:10:10 -0800 Message-ID: <52C31636.4040205@dcrocker.net> Date: Tue, 31 Dec 2013 11:08:38 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Bjoern Hoehrmann References: <52C1CD57.2080909@gmx.net> <52C1DB11.4080706@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Tue, 31 Dec 2013 11:10:11 -0800 (PST) Cc: "perpass@ietf.org" Subject: Re: [perpass] ID based encryption for email X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net 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: Tue, 31 Dec 2013 19:10:23 -0000 On 12/31/2013 10:26 AM, Bjoern Hoehrmann wrote: > What makes the new email system different from other new communication > media with hundreds of millions of users and why is it necessary for it > to have those properties? Looking at Skype, WhatsApp, Facebook, Bit- > Torrent, and many others, it seems simple to achieve mass adoption. Wow. Please consider that things always look easy if one only studies successes. In the case of new messaging systems, you need to look at the long and varied history of the very many failures to gain adoption. Early Arpanet efforts at multi-media and then X.400 offer early examples of failures. Facebook and Google had major projects that more offer recent examples. Anyone who thinks that gaining global adoption of an infrastructure service is easy either hasn't done it or doesn't understand what caused their success. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From perpass@bleeter.id.au Tue Dec 31 13:25:57 2013 Return-Path: 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 2EA0E1AE149 for ; Tue, 31 Dec 2013 13:25:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.597 X-Spam-Level: X-Spam-Status: No, score=0.597 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, J_CHICKENPOX_42=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-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 n0LoVSju0WvO for ; Tue, 31 Dec 2013 13:25:55 -0800 (PST) Received: from obsidian.cagechimps.com (obsidian.cagechimps.com [216.218.196.40]) by ietfa.amsl.com (Postfix) with ESMTP id D70B71AE13C for ; Tue, 31 Dec 2013 13:25:55 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by obsidian.cagechimps.com (Postfix) with ESMTP id 7BE1F1A27EC0; Tue, 31 Dec 2013 21:25:49 +0000 (UTC) Received: from obsidian.cagechimps.com ([127.0.0.1]) by localhost (obsidian.cagechimps.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id HpX9sz6shd-M; Tue, 31 Dec 2013 21:25:48 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by obsidian.cagechimps.com (Postfix) with ESMTP id DADBF1A27EC1; Tue, 31 Dec 2013 21:25:48 +0000 (UTC) X-Virus-Scanned: amavisd-new at obsidian.cagechimps.com Received: from obsidian.cagechimps.com ([127.0.0.1]) by localhost (obsidian.cagechimps.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Ah3SWPYIUslt; Tue, 31 Dec 2013 21:25:48 +0000 (UTC) Received: from carl.vla.bleet (ppp108-18.static.internode.on.net [150.101.108.18]) by obsidian.cagechimps.com (Postfix) with ESMTPSA id 46A231A27EC0; Tue, 31 Dec 2013 21:25:47 +0000 (UTC) Message-ID: <52C33659.30708@bleeter.id.au> Date: Wed, 01 Jan 2014 08:25:45 +1100 From: Peter Lawler User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Phillip Hallam-Baker References: <52C1CD57.2080909@gmx.net> <52C1DB11.4080706@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Paul Lambert , Watson Ladd , "perpass@ietf.org" , Hannes Tschofenig , Dave Crocker Subject: Re: [perpass] ID based encryption for email 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Dec 2013 21:25:57 -0000 On 01/01/14 06:03, Phillip Hallam-Baker wrote: > On Mon, Dec 30, 2013 at 3:44 PM, Dave Crocker wrote: > >> On 12/30/2013 12:38 PM, Paul Lambert wrote: >> >>> Another approach, however, is to start from scratch and to define an >>>>> entirely new email system, which uses cryptographic addresses instead of >>>>> human-readable identifiers. I guess that's the approach you are >>>>> suggesting. Is this correct? >>>> >>> Yes - we should start from scratch (versus direct >>> augmentation of S/MIME/PKI or PGP). >> >> Starting from scratch to build a new email system is not likely to >> succeed, any more than the various, earlier efforts to do that succeeded, >> back when the installed base was a few orders of magnitude smaller and >> adoption of a new system relatively easier. >> >> And then there is the small matter of wondering how viable the human >> factors of cryptographic email addresses will prove to be... > > That can't be done in the current mail system but it is easy to do if there > is a policy layer. Any mechanism that can be used to tell the sending mail > client that S/MIME or PGP format mail is preferred can in principle be used > to say that the mail should be sent over some JSON-B based REST scheme that > provides a superset of SMTP and JABBER capabilities. (I'm new to IETF lists so I beg some leeway with my comments whilst I get a grip on the netiquette of posting) It would seem to me the main stumbling block for mass adoption of PGP on SMTP and OTR on IM has been the multiplicity of additional software layers. The typical day to day users I encounter understandably find it hard to understand why they should need multiple additional applications to provide these services and they're just way too busy with the kids/education/work balance to spend time learning both, let alone other tools. The people I believe to be typical end users don't want to have to mess around with different encryption systems (nor do I believe should they need to) to the extent that even installing a 'no-click' solution is too much.[1] A policy layer, to my mind at least, could go a very long way in reducing this all too human overhead. I suspect XMPP/XEP may provide some ideas with regards to areas of crossover between SMTP and IM. As I've seen it, a Group Chat is somewhat analogous to a mail list, an IM sent in 'offline' mode is somewhat analogous to SMTP and XMPP Federation is somewhat analogous to SMTP relaying. Certainly, I recall a time when a certain major webmail provider had XMPP chats turn up in their webmail view[2]. Pete. [1] It was a long fight to get users to look for the 'lock' icon in their web browser. Now, I'm finding I have to get them to check whether PFS is enabled, how about cipher size and type etc. as well as trying to get what I'd call critical business infrastructure (ISPs, banks, certain Govt depts) to fix their web servers so that people not using outdated/broken ciphers can talk to them. The other day I went to report some breakage to my ISP but couldn't because... their webserver was using what I consider broken ciphers. I thus tried reporting this in less than 140 characters using to me what was an obvious string [cipher overlap] and the response was basically 'CANNOTREPRODUCE: I submitted the forms successfully, try a different browser'. I get the feeling that each type of encryption/security we make available for typical users increases difficulty of uptake exponentially and would probably have a go at proving this mathematically if it weren't 2014/01/01 08:15 where I am at the moment [2] If memory serves correctly, this was removed recently when they federated their new Social platform with their Chat platform and disabled external XMPP federation. From derhoermi@gmx.net Tue Dec 31 16:32:28 2013 Return-Path: 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 DD92F1AE45C for ; Tue, 31 Dec 2013 16:32:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.538, 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 47ZmlAqg2d17 for ; Tue, 31 Dec 2013 16:32:27 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id B26B01AE425 for ; Tue, 31 Dec 2013 16:32:26 -0800 (PST) Received: from netb.Speedport_W_700V ([91.35.5.131]) by mail.gmx.com (mrgmx103) with ESMTPA (Nemesis) id 0MWTSA-1VvKKv2Iws-00XdjL for ; Wed, 01 Jan 2014 01:32:20 +0100 From: Bjoern Hoehrmann To: dcrocker@bbiw.net Date: Wed, 01 Jan 2014 01:32:20 +0100 Message-ID: References: <52C1CD57.2080909@gmx.net> <52C1DB11.4080706@dcrocker.net> <52C31636.4040205@dcrocker.net> In-Reply-To: <52C31636.4040205@dcrocker.net> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:KIZ1+S5Re2EwGTMfFWiSGjxRE5J/ev+evpZVjdH2chFiMVYI20M OtWEq4vSUgDpJENTYubetQXd5Z1IsesWtwSPv6no1dtJgsojGRtcgNbDCbYDnauiTJNQNAE n+Ed76NZ45Q/fnPMqmUDRIRmbtX+NBbza5paInw3UJy3vNx7yVYko5reL6n7GSWhM+0Jki8 zTsTfPwbHxSjIob1jU0kg== Cc: "perpass@ietf.org" Subject: Re: [perpass] ID based encryption for email 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. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jan 2014 00:32:29 -0000 * Dave Crocker wrote: >On 12/31/2013 10:26 AM, Bjoern Hoehrmann wrote: >> What makes the new email system different from other new communication >> media with hundreds of millions of users and why is it necessary for it >> to have those properties? Looking at Skype, WhatsApp, Facebook, Bit- >> Torrent, and many others, it seems simple to achieve mass adoption. > >Wow. > >Please consider that things always look easy if one only studies successes. My bicycle is protected by a combination lock. Breaking it without any special equipment is simple, you just try different combinations until it opens. But it is not easy because there are so many combinations to try and you have limited time until you get exhausted or caught. >In the case of new messaging systems, you need to look at the long and >varied history of the very many failures to gain adoption. Early >Arpanet efforts at multi-media and then X.400 offer early examples of >failures. Facebook and Google had major projects that more offer recent >examples. Perhaps incremental changes to the deployed email systems to improve cryptographic properties have not succeeded because taken alone they offer too little benefit. If the goal is to have a messaging system with those cryptographic properties, then starting from scratch might be the only way to succeed? It goes without saying that designing and deploying a new planetary messaging system is not easy, but I do not want to be stuck with the limitations of the deployed email system forever, and I do not want end up stuck with a proprietary replacement instead. A useful response to my question would be to say, for instance, most of the recently successful communication media are proprietary single vendor systems, but a new email system necessarily must be federated. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From dhc@dcrocker.net Tue Dec 31 16:56:10 2013 Return-Path: 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 20E671AE477 for ; Tue, 31 Dec 2013 16:56:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 ym_mdx6rtEqG for ; Tue, 31 Dec 2013 16:56:09 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 445121AE42F for ; Tue, 31 Dec 2013 16:56:09 -0800 (PST) Received: from [192.168.1.6] (cpe-76-93-140-82.san.res.rr.com [76.93.140.82]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s010tlTT010950 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 31 Dec 2013 16:55:51 -0800 Message-ID: <52C3673B.3090300@dcrocker.net> Date: Tue, 31 Dec 2013 16:54:19 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Bjoern Hoehrmann References: <52C1CD57.2080909@gmx.net> <52C1DB11.4080706@dcrocker.net> <52C31636.4040205@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Tue, 31 Dec 2013 16:55:59 -0800 (PST) Cc: "perpass@ietf.org" Subject: Re: [perpass] ID based encryption for email X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net 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: Wed, 01 Jan 2014 00:56:10 -0000 On 12/31/2013 4:32 PM, Bjoern Hoehrmann wrote: > It goes without saying that designing and deploying a new planetary > messaging system is not easy, but I do not want to be stuck with the > limitations of the deployed email system forever, and I do not want > end up stuck with a proprietary replacement instead. Thia proposal fits a template in the form of: 1. Throw out existing email 2. Start over 3. The new system will fix major problems It has been a popular refrain due to spam and other abuse, for at least 20 years. It is the template you are using, for proposing encrypted mail. A decade or two or ago, I developed my own response template: 1. Specify the details of whatever functional improvements are being proposed. 2. Gain community rough consensus in favor of those differences from existing email. 3. Give the email technical community an opportunity to add the changes to the existing infrastructure. There will come a point at which some needed change can't be accommodated, but we've done remarkably well over the last 35 years... 4. When we indeed fail to add the changes, then throw out existing mail and start over. I've never seen anyone get past step 2. > A useful response to my question would be to say, for instance, most > of the recently successful communication media are proprietary single > vendor systems, but a new email system necessarily must be federated. Indeed, standards for truly distributed architectures do seem to be far more difficult to gain adoption. But note that proprietary, centralized architectures fail regularly too. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net