From nobody Mon Mar 9 08:55:41 2015 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47B111A8AA5 for ; Mon, 9 Mar 2015 08:55:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, MIME_QP_LONG_LINE=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 QUoaMz_xnJKF for ; Mon, 9 Mar 2015 08:55:30 -0700 (PDT) Received: from mail-qc0-x234.google.com (mail-qc0-x234.google.com [IPv6:2607:f8b0:400d:c01::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC37D1A8A6C for ; Mon, 9 Mar 2015 08:55:25 -0700 (PDT) Received: by qcyl6 with SMTP id l6so9551208qcy.13 for ; Mon, 09 Mar 2015 08:55:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-transfer-encoding:content-type:mime-version:subject :message-id:date:references:cc:to; bh=DJChYltn2jVh2cGW91Lws7YeAjKgBfQELaDhTtAltrA=; b=GZRM0M/cdvixrBd49PqxwUOj1B/vML/F3NsqkKNCwe0SSuaATibKiKbgbAlQwXzNTK Ab3A69Qxur9+JeyxSSyHRIAqiLExS+vYR/ZPQ55yZ+ZeyDuTx8SonvfdvfVr7gVfunI5 hVC6mSsqUyZKZzsuAtmFkt8cVJNrPFs/cB/iIGZR7RsgWuNGBlysyx2XXfGPqGLGk52N y4yfvpLcdUYbPUbfTABc/xkhenxf+BjGeUods3Z9liM4U07B5uWDvlRcwFXOB9LjIbSn B0Vyy+ucTgHS2mq1ZtVK/4fKGr8zpgKg6kFOMR5WgkRS1q7WsmZRHyJsUzS3Smc3BWxe L0jg== X-Received: by 10.55.27.42 with SMTP id b42mr56092292qkb.73.1425916525230; Mon, 09 Mar 2015 08:55:25 -0700 (PDT) Received: from [192.168.1.3] (209-6-114-252.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.114.252]) by mx.google.com with ESMTPSA id 80sm11772348qhb.26.2015.03.09.08.55.23 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 09 Mar 2015 08:55:23 -0700 (PDT) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-79B66364-E81F-4DE4-848C-F16517ED7278 Mime-Version: 1.0 (1.0) Message-Id: Date: Mon, 9 Mar 2015 11:55:23 -0400 References: <20150309151433.10503.17077.idtracker@ietfa.amsl.com> To: perpass@ietf.org X-Mailer: iPhone Mail (11D257) Archived-At: Cc: "ALFRED C MORTON \(AL\)" Subject: [perpass] Fwd: New Version Notification for draft-mm-wg-effect-encrypt-01.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: Mon, 09 Mar 2015 15:55:33 -0000 --Apple-Mail-79B66364-E81F-4DE4-848C-F16517ED7278 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hello, If you are interested in sending comments on this draft, please do so in SAA= G for now. I sent an intro to that list (hasn't posted yet). It will also g= o out to OPSAWG for operator input and collaboration as well later today. Thank you, Kathleen=20 Sent from my iPhone Begin forwarded message: > From: > Date: March 9, 2015 at 11:14:33 AM EDT > To: Kathleen Moriarty , Al Morton , Kathleen Moriarty , "Al C. Morton" > Subject: New Version Notification for draft-mm-wg-effect-encrypt-01.txt >=20 >=20 > A new version of I-D, draft-mm-wg-effect-encrypt-01.txt > has been successfully submitted by Kathleen Moriarty and posted to the > IETF repository. >=20 > Name: draft-mm-wg-effect-encrypt > Revision: 01 > Title: Effect of Ubiquitous Encryption > Document date: 2015-03-07 > Group: Individual Submission > Pages: 24 > URL: http://www.ietf.org/internet-drafts/draft-mm-wg-effect-enc= rypt-01.txt > Status: https://datatracker.ietf.org/doc/draft-mm-wg-effect-encryp= t/ > Htmlized: http://tools.ietf.org/html/draft-mm-wg-effect-encrypt-01 > Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-mm-wg-effect-encr= ypt-01 >=20 > Abstract: > Increased use of encryption will impact operations for security and > network management causing a shift in how these functions are > performed. In some cases, new methods to both monitor and protect > data will evolve. In more drastic circumstances, the ability to > monitor may be eliminated. This draft includes a collection of > current security and network management functions that may be > impacted by the shift to increased use of encryption. This draft > does not attempt to solve these problems, but rather document the > current state to assist in the development of alternate options to > achieve the intended purpose of the documented practices. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of submissi= on > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 --Apple-Mail-79B66364-E81F-4DE4-848C-F16517ED7278 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hello,

If you= are interested in sending comments on this draft, please do so in SAAG for n= ow.  I sent an intro to that list (hasn't posted yet).  It will al= so go out to OPSAWG for operator input and collaboration as well later today= .

Thank you,
Kathleen 

Sent f= rom my iPhone

Begin forwarded message:

From: <internet-drafts@ietf.org>
Date: March 9, 2015 at 11:1= 4:33 AM EDT
To: Kathleen Moriarty <kathleen.moriarty@emc.com>, Al Morton <acmorton@att.com>, Kathleen Moriarty <Kathleen.Moriarty@emc.com>= , "Al C. Morton" <acmorton@att.com>
Subject: New Version Notification for draft-mm-wg-effect-= encrypt-01.txt

=
A new version of I-D, draft-mm-wg-effect-encrypt-01.t= xt
has been successfully submitted by Kathleen Moriarty and p= osted to the
IETF repository.

Name:        draft-mm-wg-effect-encrypt
Revision:    01
Title:       &nb= sp;Effect of Ubiquitous Encryption
Document date:   &nb= sp;2015-03-07
Group:        Individual S= ubmission
Pages:        24
URL:            http://www.ietf.org/internet-drafts/draft-mm-wg-effect-encrypt-01.txt
Status:         https= ://datatracker.ietf.org/doc/draft-mm-wg-effect-encrypt/
= Htmlized:       http://tools.ietf.org/html/draft-mm-w= g-effect-encrypt-01
Diff:      =      http://www.ietf.org/rfcdiff?url2=3Ddraft-mm-w= g-effect-encrypt-01

Abstract:   Increased use of encryption will impact operations for s= ecurity and
  network management causing a shift i= n how these functions are
  performed.  In s= ome cases, new methods to both monitor and protect
 &n= bsp;data will evolve.  In more drastic circumstances, the ability to
  monitor may be eliminated.  This draft inclu= des a collection of
  current security and networ= k management functions that may be
  impacted by t= he shift to increased use of encryption.  This draft
&= nbsp; does not attempt to solve these problems, but rather document the=
  current state to assist in the development of a= lternate options to
  achieve the intended purpos= e of the documented practices.


<= span>

Please note that it may take a couple= of minutes from the time of submission
until the htmlized v= ersion and diff are available at tools.iet= f.org.

The IETF Secretariat
<= span>
= --Apple-Mail-79B66364-E81F-4DE4-848C-F16517ED7278-- From nobody Fri Mar 13 13:53:19 2015 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F9541A711A for ; Fri, 13 Mar 2015 13:53:17 -0700 (PDT) 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_05=-0.5, 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 qZ8v1FF-l3Sd for ; Fri, 13 Mar 2015 13:53:15 -0700 (PDT) Received: from mail-la0-f46.google.com (mail-la0-f46.google.com [209.85.215.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 618A21A7032 for ; Fri, 13 Mar 2015 13:53:15 -0700 (PDT) Received: by labgm9 with SMTP id gm9so25124251lab.13 for ; Fri, 13 Mar 2015 13:53:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=H3MIxHdg4qPfZlUnG26Xkwwobh+B3lYLfp0bsh8VJjw=; b=CSlHj5/K1oxuisk9G1R3lRQ+UNJrRjTWR6BrCPAEaSAhAL49HsEpl+oBbkWRlnhmOP 7HR+LpGb8QPbJStT0XEoAeBf5ge2VBfbMyWe53FDXwyc70FF0EthA+UWNIJ6ayU7VkBL tPTIfS1Quy81PYgHMy17E3+iaDBEgUnOoIn/ve4YBFssZ9ucf1LEGWfcSRuxY9+tPgKW JLe6ARSNweIsiJHf/l7q9J0isyvTLGWHer/3o3RvinGJTVQKUOKSrfZA5Gq4v3QXp03d PS5O8pjieOt/DNowt1sfssMRg/hVU6RhMyteKWNvL1DE5uRoFwoQHX1uZSHV3vSm4+rm zKzA== X-Gm-Message-State: ALoCoQlv6ZmG4IxRfe3alvpb3S2/ZJx0R68M/+W5F8Iozj6NPuXCeQxBKNXWduio4uSVyP06By7w X-Received: by 10.152.20.232 with SMTP id q8mr5587980lae.102.1426279993913; Fri, 13 Mar 2015 13:53:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.3.242 with HTTP; Fri, 13 Mar 2015 13:52:52 -0700 (PDT) X-Originating-IP: [122.56.202.140] From: Tim Bray Date: Sat, 14 Mar 2015 09:52:52 +1300 Message-ID: To: perpass Content-Type: multipart/alternative; boundary=089e01493f5a634a85051131b08f Archived-At: Subject: [perpass] draft-bray-privacy-choices-00.html X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "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 Mar 2015 20:53:18 -0000 --089e01493f5a634a85051131b08f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable This was about to expire so I was going to refresh it but uploader is closed of course. See https://www.tbray.org/tmp/draft-bray-privacy-choices-01.html Just a reminder that if this group wants to do anything in this space, my editorial services are available. --=20 - Tim Bray (If you=E2=80=99d like to send me a private message, see https://keybase.io/timbray) --089e01493f5a634a85051131b08f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thi= s was about to expire so I was going to refresh it but uploader is closed o= f course.=C2=A0 See=C2=A0https://www.tbray.org/tmp/draft-bray-privacy-choices= -01.html
Just a remin= der that if this group wants to do anything in this space, my editorial ser= vices are available.=C2=A0

--
- Tim Bray (If you=E2=80=99d like to send m= e a private message, see https://keybase.io/timbray)
--089e01493f5a634a85051131b08f-- From nobody Fri Mar 13 14:28:10 2015 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 302341A0092 for ; Fri, 13 Mar 2015 14:28:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-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 dIkjkQuuE-F2 for ; Fri, 13 Mar 2015 14:28:05 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 932331A0404 for ; Fri, 13 Mar 2015 14:28:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 1F37FBE87; Fri, 13 Mar 2015 21:28: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 qF35KtC2rtz7; Fri, 13 Mar 2015 21:28:02 +0000 (GMT) Received: from [10.87.48.73] (unknown [86.46.19.44]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id C37B7BE79; Fri, 13 Mar 2015 21:28:02 +0000 (GMT) Message-ID: <55035662.1070307@cs.tcd.ie> Date: Fri, 13 Mar 2015 21:28:02 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Tim Bray , perpass References: In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [perpass] draft-bray-privacy-choices-00.html X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "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 Mar 2015 21:28:07 -0000 Folks, On 13/03/15 20:52, Tim Bray wrote: > This was about to expire so I was going to refresh it but uploader is > closed of course. See > https://www.tbray.org/tmp/draft-bray-privacy-choices-01.html > > Just a reminder that if this group wants to do anything in this space, my > editorial services are available. I'd be interested in opinions as to how/whether we ought process this. Ta, S. > > > > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > From nobody Fri Mar 13 14:51:54 2015 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81AFA1A895A for ; Fri, 13 Mar 2015 14:51:53 -0700 (PDT) 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 G7KYQrZbk1Ks for ; Fri, 13 Mar 2015 14:51:51 -0700 (PDT) Received: from mail-qg0-x236.google.com (mail-qg0-x236.google.com [IPv6:2607:f8b0:400d:c04::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B70561A004B for ; Fri, 13 Mar 2015 14:51:51 -0700 (PDT) Received: by qgfi50 with SMTP id i50so29338701qgf.9 for ; Fri, 13 Mar 2015 14:51:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:mime-version:subject :message-id:date:references:in-reply-to:to; bh=/CLyrzMdgGbkZ9f1PeKM6qu8axtn/q9fx7+tqILaHPQ=; b=c2+XN5R21NOkJAc0ZNeACB5pEyM4+3y9kT1LOeEsokKuveeVb0YwZe305aiFZd2MyC WuAvuBgb7CHsb2i2bcomaX8CSI/MuVJqPyP5FQtQqEAAeXhQWrzOVaDOKLg5QYjeCKkc 8us5K9l4HHMkqNbFBsxR6uOgKD26crAVYm9bI1aWNRglIi+uyHIYwM1S97DasE339vuH 064Mab8OVgHC56oegl6zXsZLdKG4gTPTS5cddoqiW/sb6G7ZVu8YFrLKil+ml4G4ikgH 1TjEIXu+VJCLJkOTmDVvOmZEX0PgoAdkoOrkbZBUh97xKOe+ETLHQdQhk2+W2ukVqxQJ gJHQ== X-Received: by 10.55.55.12 with SMTP id e12mr49634439qka.50.1426283511047; Fri, 13 Mar 2015 14:51:51 -0700 (PDT) Received: from [192.168.1.3] (209-6-114-252.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.114.252]) by mx.google.com with ESMTPSA id o17sm2244644qko.49.2015.03.13.14.51.49 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 13 Mar 2015 14:51:50 -0700 (PDT) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Message-Id: <2AFA00D7-D9BB-478E-BF89-6F68CD58066F@gmail.com> Date: Fri, 13 Mar 2015 17:51:50 -0400 References: <55035662.1070307@cs.tcd.ie> In-Reply-To: <55035662.1070307@cs.tcd.ie> To: Stephen Farrell , Tim Bray , perpass@ietf.org X-Mailer: iPhone Mail (11D257) Archived-At: Subject: Re: [perpass] draft-bray-privacy-choices-00.html X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "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 Mar 2015 21:51:53 -0000 Hey, As the draft stands now, it needs more detail and contributions to be helpfu= l. If folks are interested, please contribute. IMO, It would have to be broken down further in terms of the types of encryp= tion and cost/benefits. =20 For instance, KMIP (yes, I know this is not an IETF standard) is on an upswi= ng. So is the general statement on cost of PKI specific to transport encryp= tion? How does OS factor into this and help with the cost/benefit? We shou= ld know more soon through efforts like Let's Encrypt and Fedora having IPsec= unauthenticated tunnel mode on by default (I think in version 23). What requests are SPs getting in regard to encryption (transport, applicatio= n data or data at rest) and what are the hurdles? =20 Operators may not be hanging out on this list, so maybe a post with the type= s if info you are looking for to build this out should go to opsawg with a p= ointer to the list you think this should be discussed on. Thanks, Kathleen=20 Sent from my iPhone > On Mar 13, 2015, at 5:28 PM, Stephen Farrell w= rote: >=20 >=20 > Folks, >=20 >> On 13/03/15 20:52, Tim Bray wrote: >> This was about to expire so I was going to refresh it but uploader is >> closed of course. See >> https://www.tbray.org/tmp/draft-bray-privacy-choices-01.html >>=20 >> Just a reminder that if this group wants to do anything in this space, my= >> editorial services are available. >=20 > I'd be interested in opinions as to how/whether we ought process > this. >=20 > Ta, > S. >=20 >=20 >>=20 >>=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 From nobody Sat Mar 14 02:27:50 2015 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7A761A1A11 for ; Sat, 14 Mar 2015 02:27:48 -0700 (PDT) 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 WJB3C3Ts655W for ; Sat, 14 Mar 2015 02:27:46 -0700 (PDT) Received: from mail-la0-f42.google.com (mail-la0-f42.google.com [209.85.215.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 121701A1A12 for ; Sat, 14 Mar 2015 02:27:46 -0700 (PDT) Received: by ladw1 with SMTP id w1so6657463lad.0 for ; Sat, 14 Mar 2015 02:27:44 -0700 (PDT) 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:from:date :message-id:subject:to:cc:content-type; bh=Tv82uHVs5SCgb8UHXTJ2LId7fXabUXIBmre77jQsuLc=; b=SQyoyy82N/sRp0u+uWk49eenJ0Rm7jzvfp+vdPGsYuAwCD8IkAbuiAFGdzcLNDaako wHDsDCGQLAoUd4MG++958qSogx8zSpjry9recRkm2j4GgnTrScOHidcgLnUHbhoTbqkU 1mxtHqixJnVv//22ua3VZN0zfxvZ75JAQPhZU95G2+hx67b2lowI2Cr3brGwGtYD9234 WaKLHP9S0/I6bv/u4exQc6wE8Ofr30QTIu0Cl8UAadgaZdv1A7Y7hM8K3SFntmdkq1rl 0ZcZHtFSPSaiUPKjxvHyl280ap0iVX77tKzK7Nwl53O9DneW/BQ7v9dF/t60eOFHhRLT Cu7w== X-Gm-Message-State: ALoCoQmq3DRcIWIp/4LXyOJ2/5MNKJ48Nxb33XqiAA74Cq2C+HHrxQAtpmhNb7qztpR+ghL2rBKb X-Received: by 10.152.43.67 with SMTP id u3mr47419199lal.10.1426325264338; Sat, 14 Mar 2015 02:27:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.3.242 with HTTP; Sat, 14 Mar 2015 02:27:24 -0700 (PDT) X-Originating-IP: [122.60.18.124] In-Reply-To: <2AFA00D7-D9BB-478E-BF89-6F68CD58066F@gmail.com> References: <55035662.1070307@cs.tcd.ie> <2AFA00D7-D9BB-478E-BF89-6F68CD58066F@gmail.com> From: Tim Bray Date: Sat, 14 Mar 2015 22:27:24 +1300 Message-ID: To: Kathleen Moriarty Content-Type: multipart/alternative; boundary=001a11c242deb7262805113c3af1 Archived-At: Cc: perpass , Stephen Farrell Subject: Re: [perpass] draft-bray-privacy-choices-00.html X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "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 Mar 2015 09:27:48 -0000 --001a11c242deb7262805113c3af1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I certainly agree that any draft-*-00 almost certainly needs heavy doses of IETF input. But I=E2=80=99m actually failing to understand where Kathleen= =E2=80=99s suggestions are trying to go. This draft is trying to make general points that are orthogonal to any particular technology, including: - Positive & negative privacy failures are asymmetrically harmful - the right choices are hard to make, so just don't ask inexpert uses to make them, - the cost of privacy technologies is monotonically falling I think this draft is most useful if it can restrict itself to saying things that are widely true across the tech-trade-off spectrum. So, while transport encryption is one of the most widely-used privacy technologies, the points above are also true (I think) when applied to entirely different things like message signing and server-side encryption-at-rest. Sorry, I=E2=80=99m entirely failing to think of what this draft might say a= bout OS. The admirable Let=E2=80=99s Encrypt work is I guess evidence of the monotonically-decreasing-cost premise. SPs are being asked to deploy a variety of privacy technologies,and I=E2=80= =99ve observed recurring patterns of muddy thinking in their pushbacks; this draft is an attempt to curate the arguments that are useful in these discussions, independent of any particular flavor of privacy technology. On Sat, Mar 14, 2015 at 10:51 AM, Kathleen Moriarty < kathleen.moriarty.ietf@gmail.com> wrote: > Hey, > > As the draft stands now, it needs more detail and contributions to be > helpful. If folks are interested, please contribute. > > IMO, It would have to be broken down further in terms of the types of > encryption and cost/benefits. > > For instance, KMIP (yes, I know this is not an IETF standard) is on an > upswing. So is the general statement on cost of PKI specific to transpor= t > encryption? How does OS factor into this and help with the cost/benefit? > We should know more soon through efforts like Let's Encrypt and Fedora > having IPsec unauthenticated tunnel mode on by default (I think in versio= n > 23). > > What requests are SPs getting in regard to encryption (transport, > application data or data at rest) and what are the hurdles? > > Operators may not be hanging out on this list, so maybe a post with the > types if info you are looking for to build this out should go to opsawg > with a pointer to the list you think this should be discussed on. > > Thanks, > Kathleen > > Sent from my iPhone > > > On Mar 13, 2015, at 5:28 PM, Stephen Farrell > wrote: > > > > > > Folks, > > > >> On 13/03/15 20:52, Tim Bray wrote: > >> This was about to expire so I was going to refresh it but uploader is > >> closed of course. See > >> https://www.tbray.org/tmp/draft-bray-privacy-choices-01.html > >> > >> Just a reminder that if this group wants to do anything in this space, > my > >> editorial services are available. > > > > I'd be interested in opinions as to how/whether we ought process > > this. > > > > Ta, > > S. > > > > > >> > >> > >> > >> _______________________________________________ > >> 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 > --=20 - Tim Bray (If you=E2=80=99d like to send me a private message, see https://keybase.io/timbray) --001a11c242deb7262805113c3af1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I c= ertainly agree that any draft-*-00 almost certainly needs heavy doses of IE= TF input.=C2=A0 But I=E2=80=99m actually failing to understand where Kathle= en=E2=80=99s suggestions are trying to go.=C2=A0 This draft is trying to ma= ke general points that are orthogonal to any particular technology, includi= ng:=C2=A0

<= /div>
- Positive &= ; negative privacy failures are asymmetrically harmful
- the right choices are hard to mak= e, so just don't ask inexpert uses to make them,
- the cost of privacy technologies is= monotonically falling

I = think this draft is most useful if it can restrict itself to saying things = that are widely true across the tech-trade-off spectrum.=C2=A0 So, while tr= ansport encryption is one of the most widely-used privacy technologies, the= points above are also true (I think) when applied to entirely different th= ings like message signing and server-side encryption-at-rest. =C2=A0
<= div class=3D"gmail_default" style=3D"font-size:small">
Sorry, I=E2=80=99m entirely fa= iling to think of what this draft might say about OS. The admirable Let=E2= =80=99s Encrypt work is I guess evidence of the monotonically-decreasing-co= st premise.
SPs are being= asked to deploy a variety of privacy technologies,and I=E2=80=99ve observe= d recurring patterns of muddy thinking in their pushbacks; this draft is an= attempt to curate the arguments that are useful in these discussions, inde= pendent of any particular flavor of privacy technology.

On Sat, Mar 14, 2015 at 1= 0:51 AM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.co= m> wrote:
Hey,

As the draft stands now, it needs more detail and contributions to be helpf= ul.=C2=A0 If folks are interested, please contribute.

IMO, It would have to be broken down further in terms of the types of encry= ption and cost/benefits.

For instance, KMIP (yes, I know this is not an IETF standard) is on an upsw= ing.=C2=A0 So is the general statement on cost of PKI specific to transport= encryption?=C2=A0 How does OS factor into this and help with the cost/bene= fit?=C2=A0 We should know more soon through efforts like Let's Encrypt = and Fedora having IPsec unauthenticated tunnel mode on by default (I think = in version 23).

What requests are SPs getting in regard to encryption (transport, applicati= on data or data at rest) and what are the hurdles?

Operators may not be hanging out on this list, so maybe a post with the typ= es if info you are looking for to build this out should go to opsawg with a= pointer to the list you think this should be discussed on.

Thanks,
Kathleen

Sent from my iPhone

> On Mar 13, 2015, at 5:28 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
>
>
> Folks,
>
>> On 13/03/15 20:52, Tim Bray wrote:
>> This was about to expire so I was going to refresh it but uploader= is
>> closed of course.=C2=A0 See
>> https://www.tbray.org/tmp/draft-bray-privacy-choic= es-01.html
>>
>> Just a reminder that if this group wants to do anything in this sp= ace, my
>> editorial services are available.
>
> I'd be interested in opinions as to how/whether we ought process > this.
>
> Ta,
> S.
>
>
>>
>>
>>
>> _______________________________________________
>> 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



--
=
- Tim Bray (If you=E2= =80=99d like to send me a private message, see https://keybase.io/timbray)
--001a11c242deb7262805113c3af1-- From nobody Sat Mar 14 04:27:35 2015 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D15F1A00A8 for ; Sat, 14 Mar 2015 04:27:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, MIME_QP_LONG_LINE=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 0eNIFKNCI4Ju for ; Sat, 14 Mar 2015 04:27:31 -0700 (PDT) Received: from mail-qg0-x22f.google.com (mail-qg0-x22f.google.com [IPv6:2607:f8b0:400d:c04::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9376A1A0084 for ; Sat, 14 Mar 2015 04:27:31 -0700 (PDT) Received: by qgg60 with SMTP id 60so6337597qgg.3 for ; Sat, 14 Mar 2015 04:27:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=RQL3wTUngEWADlVmiUpUkbqnaoG03PcPjoEn9OC4JwY=; b=G6UGzkK6CyN2mqX4ZbyPx3so+0dGoUpEocwPnOsZjfIwnzZuP6yKYY723kVamxKmFx V3aWQ8lWddwZUD24yKWKyrT1bQ4Lo9D4x+k0PRg99fSavMS6VqnQI1qcsfT/nRprJvOj WKM21E2HUmPa0suwiRHSEPD7/qnQW18LqNPh07eHmrchn3A5WnjI4ut3wE+wiLqkVSBf elcPOIXIYFYrUg076NAF+cUto+zvNobvGm1cPXaUeE2DBFh4VceDmRQ4Z38wuj+5znxS zCvWVIhaXKqMge4Jj5mDiZCxpsllRLqDvtEgx8U2fNMscOa8lWF8cqLb0Y419UQv32Ra 8pfg== X-Received: by 10.140.236.211 with SMTP id h202mr67788411qhc.88.1426332450893; Sat, 14 Mar 2015 04:27:30 -0700 (PDT) Received: from [192.168.1.3] (209-6-114-252.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.114.252]) by mx.google.com with ESMTPSA id d85sm3283820qkh.45.2015.03.14.04.27.28 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 14 Mar 2015 04:27:29 -0700 (PDT) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: multipart/alternative; boundary=Apple-Mail-DFEA32B2-62AA-43D4-A1F9-CB8D537DA101 Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (11D257) In-Reply-To: Date: Sat, 14 Mar 2015 07:27:29 -0400 Content-Transfer-Encoding: 7bit Message-Id: References: <55035662.1070307@cs.tcd.ie> <2AFA00D7-D9BB-478E-BF89-6F68CD58066F@gmail.com> To: Tim Bray Archived-At: Cc: perpass , Stephen Farrell Subject: Re: [perpass] draft-bray-privacy-choices-00.html X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "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 Mar 2015 11:27:34 -0000 --Apple-Mail-DFEA32B2-62AA-43D4-A1F9-CB8D537DA101 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Tim, Sent from my iPhone > On Mar 14, 2015, at 5:27 AM, Tim Bray wrote: >=20 > I certainly agree that any draft-*-00 almost certainly needs heavy doses o= f IETF input. But I=E2=80=99m actually failing to understand where Kathleen= =E2=80=99s suggestions are trying to go. This draft is trying to make gener= al points that are orthogonal to any particular technology, including:=20 >=20 > - Positive & negative privacy failures are asymmetrically harmful > - the right choices are hard to make, so just don't ask inexpert uses to m= ake them, > - the cost of privacy technologies is monotonically falling >=20 > I think this draft is most useful if it can restrict itself to saying thin= gs that are widely true across the tech-trade-off spectrum. So, while trans= port encryption is one of the most widely-used privacy technologies, the poi= nts above are also true (I think) when applied to entirely different things l= ike message signing and server-side encryption-at-rest. =20 >=20 > Sorry, I=E2=80=99m entirely failing to think of what this draft might say a= bout OS. The admirable Let=E2=80=99s Encrypt work is I guess evidence of the= monotonically-decreasing-cost premise. >=20 > SPs are being asked to deploy a variety of privacy technologies,and I=E2=80= =99ve observed recurring patterns of muddy thinking in their pushbacks; this= draft is an attempt to curate the arguments that are useful in these discus= sions, independent of any particular flavor of privacy technology. Ok, fair enough. I think some more text is needed to make your points clear= as it wasn't enough for me to see the direction you were heading. Thanks, Kathleen=20 >=20 >> On Sat, Mar 14, 2015 at 10:51 AM, Kathleen Moriarty wrote: >> Hey, >>=20 >> As the draft stands now, it needs more detail and contributions to be hel= pful. If folks are interested, please contribute. >>=20 >> IMO, It would have to be broken down further in terms of the types of enc= ryption and cost/benefits. >>=20 >> For instance, KMIP (yes, I know this is not an IETF standard) is on an up= swing. So is the general statement on cost of PKI specific to transport enc= ryption? How does OS factor into this and help with the cost/benefit? We s= hould know more soon through efforts like Let's Encrypt and Fedora having IP= sec unauthenticated tunnel mode on by default (I think in version 23). >>=20 >> What requests are SPs getting in regard to encryption (transport, applica= tion data or data at rest) and what are the hurdles? >>=20 >> Operators may not be hanging out on this list, so maybe a post with the t= ypes if info you are looking for to build this out should go to opsawg with a= pointer to the list you think this should be discussed on. >>=20 >> Thanks, >> Kathleen >>=20 >> Sent from my iPhone >>=20 >> > On Mar 13, 2015, at 5:28 PM, Stephen Farrell wrote: >> > >> > >> > Folks, >> > >> >> On 13/03/15 20:52, Tim Bray wrote: >> >> This was about to expire so I was going to refresh it but uploader is >> >> closed of course. See >> >> https://www.tbray.org/tmp/draft-bray-privacy-choices-01.html >> >> >> >> Just a reminder that if this group wants to do anything in this space,= my >> >> editorial services are available. >> > >> > I'd be interested in opinions as to how/whether we ought process >> > this. >> > >> > Ta, >> > S. >> > >> > >> >> >> >> >> >> >> >> _______________________________________________ >> >> 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 >=20 >=20 >=20 > --=20 > - Tim Bray (If you=E2=80=99d like to send me a private message, see https:= //keybase.io/timbray) --Apple-Mail-DFEA32B2-62AA-43D4-A1F9-CB8D537DA101 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi Tim,

Sent from my iPhone

On Mar 14, 2015, at 5:27 AM, Tim Bray <tbray@textuality.com> wrote:

I certainly agree that any draft-*-00 almost certainly need= s heavy doses of IETF input.  But I=E2=80=99m actually failing to under= stand where Kathleen=E2=80=99s suggestions are trying to go.  This draf= t is trying to make general points that are orthogonal to any particular tec= hnology, including: 

-= Positive & negative privacy failures are asymmetrically harmful
- the right choices are= hard to make, so just don't ask inexpert uses to make them,
- the cost of privacy technolog= ies is monotonically falling

I think this draft is most useful if it can restrict itself to saying thin= gs that are widely true across the tech-trade-off spectrum.  So, while t= ransport encryption is one of the most widely-used privacy technologies, the= points above are also true (I think) when applied to entirely different thi= ngs like message signing and server-side encryption-at-rest.  

Sorry, I=E2=80=99m entirely failing= to think of what this draft might say about OS. The admirable Let=E2=80=99s= Encrypt work is I guess evidence of the monotonically-decreasing-cost premi= se.

SPs are being asked to d= eploy a variety of privacy technologies,and I=E2=80=99ve observed recurring p= atterns of muddy thinking in their pushbacks; this draft is an attempt to cu= rate the arguments that are useful in these discussions, independent of any p= articular flavor of privacy technology.
<= br>
Ok, fair enough.  I think some more text is needed to make you= r points clear as it wasn't enough for me to see the direction you were head= ing.

Thanks,
Kathleen 

On S= at, Mar 14, 2015 at 10:51 AM, Kathleen Moriarty <kathleen.mor= iarty.ietf@gmail.com> wrote:
= Hey,

As the draft stands now, it needs more detail and contributions to be helpfu= l.  If folks are interested, please contribute.

IMO, It would have to be broken down further in terms of the types of encryp= tion and cost/benefits.

For instance, KMIP (yes, I know this is not an IETF standard) is on an upswi= ng.  So is the general statement on cost of PKI specific to transport e= ncryption?  How does OS factor into this and help with the cost/benefit= ?  We should know more soon through efforts like Let's Encrypt and Fedo= ra having IPsec unauthenticated tunnel mode on by default (I think in versio= n 23).

What requests are SPs getting in regard to encryption (transport, applicatio= n data or data at rest) and what are the hurdles?

Operators may not be hanging out on this list, so maybe a post with the type= s if info you are looking for to build this out should go to opsawg with a p= ointer to the list you think this should be discussed on.

Thanks,
Kathleen

Sent from my iPhone

> On Mar 13, 2015, at 5:28 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
>
>
> Folks,
>
>> On 13/03/15 20:52, Tim Bray wrote:
>> This was about to expire so I was going to refresh it but uploader i= s
>> closed of course.  See
>> https://www.tbray.org/tmp/draft-bray-privacy-choices= -01.html
>>
>> Just a reminder that if this group wants to do anything in this spa= ce, my
>> editorial services are available.
>
> I'd be interested in opinions as to how/whether we ought process
> this.
>
> Ta,
> S.
>
>
>>
>>
>>
>> _______________________________________________
>> 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



--
<= div class=3D"gmail_signature">
- Tim Bray (If you=E2=80= =99d like to send me a private message, see https://keybase.io/timbray)
= --Apple-Mail-DFEA32B2-62AA-43D4-A1F9-CB8D537DA101-- From nobody Sat Mar 14 06:36:04 2015 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FF1D1A0393 for ; Sat, 14 Mar 2015 06:36:02 -0700 (PDT) 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 O-axpHsJRXz0 for ; Sat, 14 Mar 2015 06:35:59 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0624.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::624]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 868821A038E for ; Sat, 14 Mar 2015 06:35:59 -0700 (PDT) Received: from CO2PR0601MB0983.namprd06.prod.outlook.com (25.160.7.28) by CO2PR0601MB0982.namprd06.prod.outlook.com (25.160.7.27) with Microsoft SMTP Server (TLS) id 15.1.99.14; Sat, 14 Mar 2015 13:35:42 +0000 Received: from CO2PR0601MB0983.namprd06.prod.outlook.com ([25.160.7.28]) by CO2PR0601MB0983.namprd06.prod.outlook.com ([25.160.7.28]) with mapi id 15.01.0099.004; Sat, 14 Mar 2015 13:35:42 +0000 From: Robin Wilton To: Stephen Farrell Thread-Topic: [perpass] draft-bray-privacy-choices-00.html Thread-Index: AQHQXc/AhfdvI7OZZUKCc7g7lWuc4Z0a7YsAgAEOXro= Date: Sat, 14 Mar 2015 13:35:42 +0000 Message-ID: <8CB555C3-1681-46AC-A161-218199AF1AED@isoc.org> References: , <55035662.1070307@cs.tcd.ie> In-Reply-To: <55035662.1070307@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [94.174.34.240] authentication-results: cs.tcd.ie; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO2PR0601MB0982; x-forefront-antispam-report: BMV:0; SFV:NSPM; SFS:(10009020)(6009001)(51704005)(129404003)(24454002)(53434003)(479174004)(2900100001)(2950100001)(87936001)(82746002)(19580405001)(19580395003)(122556002)(40100003)(551544002)(86362001)(50986999)(54356999)(15975445007)(2656002)(102836002)(83716003)(76176999)(230783001)(33656002)(36756003)(46102003)(92566002)(99286002)(62966003)(77156002)(66066001)(106116001)(110136001)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:CO2PR0601MB0982; H:CO2PR0601MB0983.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5001010)(5005006); SRVR:CO2PR0601MB0982; BCL:0; PCL:0; RULEID:; SRVR:CO2PR0601MB0982; x-forefront-prvs: 0515208626 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Mar 2015 13:35:42.2636 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR0601MB0982 Archived-At: Cc: perpass , Tim Bray Subject: Re: [perpass] draft-bray-privacy-choices-00.html X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "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 Mar 2015 13:36:02 -0000 I think this is an important and useful topic. And as Tim notes, I think it= 's worth getting to a very clear statement of the problem and associated fa= ctors, before getting to the level of technology-specific detail suggested = by Kathleen (though I agree that that level of technical detail should be o= ne of the destinations towards which this document moves us). My main gripe is with the label "privacy protection" as applied to the issu= es Tim raises. I think the problem statements are good, but I think they ar= e problems of confidentiality, not privacy. To try to illustrate why, I suggest the following scenario:=20 Primrose goes to InsureMe.com, where she will be asked for a lot of persona= l data. InsureMe.com invites her to register and create a new account, with= an ID and password; all this is done over https, so InsureMe.com is confid= ent it has taken suitable steps to protect the data from being visible to t= hird parties. Thereafter. Whenever Primrose returns to the site, she is ask= ed to log in before she can access any of her personal data. So far, this is all consistent with the requirements in Tim's paper. Howeve= r, InsureMe.com also has a B2B relationship with Gotcher.com, a targeted ad= vertising service. InsureMe.com shares Primrose's data (and that of all its= other account holders) with Gotcher.com, but when doing so it always makes= the Gotcher folks log in to a data server, and the data passes over an enc= rypted session.=20 I Primrose hasn't consented to this, her privacy has been violated - but I'= m not sure we've broken any of the principles Tim sets out. I think InsureM= e.com has put some confidentiality measures in place, between itself and Pr= imrose, and itself and Gotcher.com, but those have not protected Primrose's= privacy. I think there are two options: 1 - re-label the problem as one of confidentiality, not privacy, in which c= ase the document is already a good basis for further discussion; 2 - keep the "privacy protection" label, in which case the document needs t= o build on the existing confidentiality topic, but set it in the context of= the broader privacy problem, and explain what confidentiality services con= tribute towards solving it. I think both options would take us somewhere useful, because users' confide= ntiality and privacy are *both* affected by the asymmetries and market dyna= mics Tim describes. Hope this helps, Robin Robin Wilton Technical Outreach Director - Identity and Privacy On 13 Mar 2015, at 21:28, "Stephen Farrell" wro= te: >=20 > Folks, >=20 > On 13/03/15 20:52, Tim Bray wrote: >> This was about to expire so I was going to refresh it but uploader is >> closed of course. See >> https://www.tbray.org/tmp/draft-bray-privacy-choices-01.html >>=20 >> Just a reminder that if this group wants to do anything in this space, m= y >> editorial services are available. >=20 > I'd be interested in opinions as to how/whether we ought process > this. >=20 > Ta, > S. >=20 >=20 >>=20 >>=20 >>=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 From nobody Sat Mar 14 08:00:25 2015 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA04C1A03AA for ; Sat, 14 Mar 2015 08:00:24 -0700 (PDT) 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 bhJru4YBeZ0j for ; Sat, 14 Mar 2015 08:00:22 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CBAB1A044D for ; Sat, 14 Mar 2015 08:00:21 -0700 (PDT) Received: from [192.168.1.87] (76-218-8-156.lightspeed.sntcca.sbcglobal.net [76.218.8.156]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id t2EF0BT9031195 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 14 Mar 2015 08:00:17 -0700 Message-ID: <55044CF9.2060306@dcrocker.net> Date: Sat, 14 Mar 2015 08:00:09 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Tim Bray References: <55035662.1070307@cs.tcd.ie> <2AFA00D7-D9BB-478E-BF89-6F68CD58066F@gmail.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Sat, 14 Mar 2015 08:00:17 -0700 (PDT) Archived-At: Cc: perpass , Stephen Farrell Subject: Re: [perpass] draft-bray-privacy-choices-00.html 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: Sat, 14 Mar 2015 15:00:25 -0000 On 3/14/2015 2:27 AM, Tim Bray wrote: > This draft is trying to make general points that are orthogonal to any > particular technology, including: > > - Positive & negative privacy failures are asymmetrically harmful > - the right choices are hard to make, so just don't ask inexpert uses to > make them, > - the cost of privacy technologies is monotonically falling +1 to the nature and direction of this document. Especially for topics that are complex, poorly understood and/or are controversial, it can greatly help to discuss issues and tradeoffs in higher-level, non-technical terms. I usually cast this as needing statement about functional benefits and detriments for users (end-users, operators, etc.) The summary bullets Tim provided, above, are worth adding to the document early, with the rest of document providing substance to them. If there is enough community difficulty in readily seeing the nature and benefit of this exercise -- I usually assume that when any one reasonable reader has that sort of problem, others will too -- we should probably find an example to add that distinguishes between this level of discussion and the lower-level type that IETF work typical deals with -- and that ought to derive from these higher-level points. There might be an line of discussion to add to the document, namely tradeoffs and limitations of various technical approaches, especially popular ones. For example, transport-level encryption has notable benefits, but the deficiencies seem to be absent from most IETF discussions, leaving very large holes in the creator/consumer path. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sat Mar 14 14:14:55 2015 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A68F1A01F0 for ; Sat, 14 Mar 2015 14:14:54 -0700 (PDT) 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 KmYaY74bij0u for ; Sat, 14 Mar 2015 14:14:52 -0700 (PDT) Received: from mail-la0-f41.google.com (mail-la0-f41.google.com [209.85.215.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 704911A0107 for ; Sat, 14 Mar 2015 14:14:52 -0700 (PDT) Received: by lagg8 with SMTP id g8so13563515lag.1 for ; Sat, 14 Mar 2015 14:14:50 -0700 (PDT) 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:from:date :message-id:subject:to:cc:content-type; bh=eRFxDkdp24ATyvbroDm7mT/mQNkkiV1uKgru6b+1IF0=; b=f56ssW2EsUiKfCF3plxcOBLL8M4a5ciQRzu+t1/WQas95w53TE7jDyqaG54O4B4WFJ 1+Gz2jZthAbeVGadLzLx0hLjybN12r7YJpRRWdHSqwCw26T9TJMzpPcMHUs0DtLPgfYC 3LQy3u1TeZIdy25uoekddXbqZglkAKwwWJrcpoPpGcpus58TworwfwNBNF/v8y0n4Hpi E/HZEW2ZTfy/tA6/aVqY3pQzyqEeL0MwXumB5qNp46/at4YPV4TRPUFCT5VNIeowsIJd QSA/YnznbAtPfzHs9X29hy8GOiGga7xHkihkljDwrkHvfsTdivtqgG1DO8GKYTLPxRn0 Fylw== X-Gm-Message-State: ALoCoQlbbRbgA5eaeUOqrT9ursjHPvaEA/kCYOKR9CKMqlRMIjrsBm20NggBm7cl0QikoWLmzn/F X-Received: by 10.113.11.12 with SMTP id ee12mr48228447lbd.5.1426367690813; Sat, 14 Mar 2015 14:14:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.3.242 with HTTP; Sat, 14 Mar 2015 14:14:29 -0700 (PDT) X-Originating-IP: [122.60.18.124] In-Reply-To: <55044CF9.2060306@dcrocker.net> References: <55035662.1070307@cs.tcd.ie> <2AFA00D7-D9BB-478E-BF89-6F68CD58066F@gmail.com> <55044CF9.2060306@dcrocker.net> From: Tim Bray Date: Sun, 15 Mar 2015 10:14:29 +1300 Message-ID: To: Dave CROCKER Content-Type: multipart/alternative; boundary=001a1133a5b487cee40511461b64 Archived-At: Cc: perpass , Stephen Farrell Subject: Re: [perpass] draft-bray-privacy-choices-00.html X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "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 Mar 2015 21:14:54 -0000 --001a1133a5b487cee40511461b64 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable OK, I=E2=80=99ll go ahead and do an -01 with a better introduction, which i= s clearly needed. Interested to hear what others think of Robin=E2=80=99s privacy/confidentiality distinction. On Sun, Mar 15, 2015 at 4:00 AM, Dave Crocker wrote: > On 3/14/2015 2:27 AM, Tim Bray wrote: > > This draft is trying to make general points that are orthogonal to any > > particular technology, including: > > > > - Positive & negative privacy failures are asymmetrically harmful > > - the right choices are hard to make, so just don't ask inexpert uses t= o > > make them, > > - the cost of privacy technologies is monotonically falling > > > +1 to the nature and direction of this document. > > Especially for topics that are complex, poorly understood and/or are > controversial, it can greatly help to discuss issues and tradeoffs in > higher-level, non-technical terms. I usually cast this as needing > statement about functional benefits and detriments for users (end-users, > operators, etc.) > > The summary bullets Tim provided, above, are worth adding to the > document early, with the rest of document providing substance to them. > > If there is enough community difficulty in readily seeing the nature and > benefit of this exercise -- I usually assume that when any one > reasonable reader has that sort of problem, others will too -- we should > probably find an example to add that distinguishes between this level of > discussion and the lower-level type that IETF work typical deals with -- > and that ought to derive from these higher-level points. > > There might be an line of discussion to add to the document, namely > tradeoffs and limitations of various technical approaches, especially > popular ones. For example, transport-level encryption has notable > benefits, but the deficiencies seem to be absent from most IETF > discussions, leaving very large holes in the creator/consumer path. > > d/ > > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net > --=20 - Tim Bray (If you=E2=80=99d like to send me a private message, see https://keybase.io/timbray) --001a1133a5b487cee40511461b64 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
OK,= I=E2=80=99ll go ahead and do an -01 with a better introduction, which is c= learly needed. =C2=A0 =C2=A0Interested to hear what others think of Robin= =E2=80=99s privacy/confidentiality distinction.



On Sun, Mar 15, 2015 at 4:00 AM, Dave Crocker <dhc@dc= rocker.net> wrote:
On 3/14/2015 2:27 AM, Tim Bray wrote:
> This draft is trying to make general points that are orthogonal to any=
> particular technology, including:
>
> - Positive & negative privacy failures are asymmetrically harmful<= br> > - the right choices are hard to make, so just don't ask inexpert u= ses to
> make them,
> - the cost of privacy technologies is monotonically falling


+1 to the nature and direction of this document.

Especially for topics that are complex, poorly understood and/or are
controversial, it can greatly help to discuss issues and tradeoffs in
higher-level, non-technical terms.=C2=A0 I usually cast this as needing
statement about functional benefits and detriments for users (end-users, operators, etc.)

The summary bullets Tim provided, above, are worth adding to the
document early, with the rest of document providing substance to them.

If there is enough community difficulty in readily seeing the nature and benefit of this exercise -- I usually assume that when any one
reasonable reader has that sort of problem, others will too -- we should probably find an example to add that distinguishes between this level of discussion and the lower-level type that IETF work typical deals with -- and that ought to derive from these higher-level points.

There might be an line of discussion to add to the document, namely
tradeoffs and limitations of various technical approaches, especially
popular ones.=C2=A0 For example, transport-level encryption has notable
benefits, but the deficiencies seem to be absent from most IETF
discussions, leaving very large holes in the creator/consumer path.

d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net



--
- Tim Bray (If you= =E2=80=99d like to send me a private message, see https://keybase.io/timbray)
=
--001a1133a5b487cee40511461b64-- From nobody Mon Mar 16 07:22:35 2015 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 943E61A8758 for ; Mon, 16 Mar 2015 07:22:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.511 X-Spam-Level: X-Spam-Status: No, score=-1.511 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 zi2k0NGkMfC0 for ; Mon, 16 Mar 2015 07:22:31 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8443D1A877B for ; Mon, 16 Mar 2015 07:22:30 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:43015 helo=COMSEC.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1YXVuX-0004RT-BG for perpass@ietf.org; Mon, 16 Mar 2015 10:22:29 -0400 Message-ID: <5506E725.2050003@bbn.com> Date: Mon, 16 Mar 2015 10:22:29 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: perpass@ietf.org References: , <55035662.1070307@cs.tcd.ie> <8CB555C3-1681-46AC-A161-218199AF1AED@isoc.org> In-Reply-To: <8CB555C3-1681-46AC-A161-218199AF1AED@isoc.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [perpass] draft-bray-privacy-choices-00.html X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "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 Mar 2015 14:22:34 -0000 Robin, > ... > > Primrose goes to InsureMe.com, where she will be asked for a lot of personal data. InsureMe.com invites her to register and create a new account, with an ID and password; all this is done over https, so InsureMe.com is confident it has taken suitable steps to protect the data from being visible to third parties. Third parties on the wire. Experience shows that Primrose's data is most likely to be disclosed to third parties once it is on the InsureMe.com web site. Your example goes on to cite a privacy violation in the form of Gotcher.com. But, a successful attack against InsureMe.com also would violate the confidentiality of Primrose's data. Bottom line: I agree with your observation that privacy is not the same as confidentiality, and we often overly simplify these discussions. Steve From nobody Mon Mar 16 07:46:10 2015 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACD741A87E6 for ; Mon, 16 Mar 2015 07:46:09 -0700 (PDT) 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 rWNORmam8TFP for ; Mon, 16 Mar 2015 07:46:04 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0696.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:696]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 084B11A87E0 for ; Mon, 16 Mar 2015 07:46:04 -0700 (PDT) Received: from CO2PR0601MB0983.namprd06.prod.outlook.com (25.160.7.28) by CO2PR0601MB0982.namprd06.prod.outlook.com (25.160.7.27) with Microsoft SMTP Server (TLS) id 15.1.99.14; Mon, 16 Mar 2015 14:45:47 +0000 Received: from CO2PR0601MB0983.namprd06.prod.outlook.com ([25.160.7.28]) by CO2PR0601MB0983.namprd06.prod.outlook.com ([25.160.7.28]) with mapi id 15.01.0099.004; Mon, 16 Mar 2015 14:45:47 +0000 From: Robin Wilton To: Stephen Kent Thread-Topic: [perpass] draft-bray-privacy-choices-00.html Thread-Index: AQHQXc/AhfdvI7OZZUKCc7g7lWuc4Z0a7YsAgAEOXrqAAzG7gIAAB08A Date: Mon, 16 Mar 2015 14:45:47 +0000 Message-ID: References: , <55035662.1070307@cs.tcd.ie> <8CB555C3-1681-46AC-A161-218199AF1AED@isoc.org> <5506E725.2050003@bbn.com> In-Reply-To: <5506E725.2050003@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [94.174.34.240] authentication-results: bbn.com; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO2PR0601MB0982; x-forefront-antispam-report: BMV:0; SFV:NSPM; SFS:(10009020)(6009001)(51914003)(24454002)(51704005)(92566002)(33656002)(36756003)(46102003)(106116001)(110136001)(66066001)(77156002)(62966003)(99286002)(82746002)(19580395003)(19580405001)(2950100001)(87936001)(2900100001)(76176999)(15975445007)(93886004)(50986999)(2656002)(230783001)(40100003)(122556002)(102836002)(551544002)(86362001)(99936001)(83716003)(54356999)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:CO2PR0601MB0982; H:CO2PR0601MB0983.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5001010)(5005006); SRVR:CO2PR0601MB0982; BCL:0; PCL:0; RULEID:; SRVR:CO2PR0601MB0982; x-forefront-prvs: 05177D47DC Content-Type: multipart/signed; boundary="Apple-Mail=_9416F531-8848-4E2F-A298-52A2A5F44827"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Mar 2015 14:45:47.2778 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR0601MB0982 Archived-At: Cc: perpass Subject: Re: [perpass] draft-bray-privacy-choices-00.html X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "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 Mar 2015 14:46:09 -0000 --Apple-Mail=_9416F531-8848-4E2F-A298-52A2A5F44827 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Steve - and thanks for the correction. I agree with your additional use-cases/threat scenarios, naturally=85 I = was just trying to keep it to one simple illustration ;^) R On 16 Mar 2015, at 14:22, Stephen Kent wrote: > Robin, >> ... >>=20 >> Primrose goes to InsureMe.com, where she will be asked for a lot of = personal data. InsureMe.com invites her to register and create a new = account, with an ID and password; all this is done over https, so = InsureMe.com is confident it has taken suitable steps to protect the = data from being visible to third parties. > Third parties on the wire. Experience shows that Primrose's data is = most likely to be > disclosed to third parties once it is on the InsureMe.com web site. = Your example > goes on to cite a privacy violation in the form of Gotcher.com. But, a = successful attack > against InsureMe.com also would violate the confidentiality of = Primrose's data. >=20 > Bottom line: I agree with your observation that privacy is not the = same as > confidentiality, and we often overly simplify these discussions. >=20 > Steve >=20 > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass --Apple-Mail=_9416F531-8848-4E2F-A298-52A2A5F44827 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----- iEYEARECAAYFAlUG7UYACgkQx1kEWLxmyT1gygCggMe3iGX3AMrQ9bzaldekRLP/ QEoAoINzlEeIecs+kDOKJyNsYXUn3j5u =pShm -----END PGP SIGNATURE----- --Apple-Mail=_9416F531-8848-4E2F-A298-52A2A5F44827-- From nobody Wed Mar 18 13:58:55 2015 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 705EE1A910A for ; Wed, 18 Mar 2015 13:58:53 -0700 (PDT) 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 4SD6M7RDJgZC for ; Wed, 18 Mar 2015 13:58:51 -0700 (PDT) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D0251A9103 for ; Wed, 18 Mar 2015 13:58:51 -0700 (PDT) Received: by ieclw3 with SMTP id lw3so49682908iec.2 for ; Wed, 18 Mar 2015 13:58:51 -0700 (PDT) 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=W7k7Q8xRcYaNGeJwbQ2al2uXR0hJ33/0SEWoSVOw7Dg=; b=ODmKYbhfuFvYd368jUXAnZ0Se9cIhY747gWe/EtsiukOij0N800bR25695Pm5x2AB8 3fmwNxhHsrUMW+QYajZebgBlOkUDIivgyUIwDEDuHJD6lroGIbpvk0VJFri853mF07bE y1B542fZAkxJ8c+qnR1/WKJSj11jIEaRUACibd3IBsfG9dn6s/KK3/WOUQEFCfw2vNC5 8nRS320wrf1HeqKcrHF15kcGOMmc/HmeWc+W1KYnX9xRB0wFoUpYJjyPPjeu1hNSDhSK Vlu330c7lQCCBWKpIIJzD/owbqncjhE+IcLLO2rCDfV7S1QO81abr5fHHJUHbDesSBAt 7Jrg== MIME-Version: 1.0 X-Received: by 10.42.82.199 with SMTP id e7mr91488851icl.18.1426712331063; Wed, 18 Mar 2015 13:58:51 -0700 (PDT) Received: by 10.42.129.17 with HTTP; Wed, 18 Mar 2015 13:58:51 -0700 (PDT) In-Reply-To: <20150318205225.18860.41113.idtracker@ietfa.amsl.com> References: <20150318205225.18860.41113.idtracker@ietfa.amsl.com> Date: Wed, 18 Mar 2015 13:58:51 -0700 Message-ID: From: Ted Hardie To: "" Content-Type: multipart/alternative; boundary=20cf30334657b0bade051196595a Archived-At: Cc: "privsec-program@iab.org" Subject: [perpass] Fwd: [IAB] I-D ACTION:draft-iab-privsec-confidentiality-threat-04.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, 18 Mar 2015 20:58:53 -0000 --20cf30334657b0bade051196595a Content-Type: text/plain; charset=UTF-8 Howdy, This version updates the draft to reflect some of the recent feedback, and we'd appreciate fresh reviews. It is likely that this version will be the one the IAB sends for general community review, so an early look at it would be much appreciated. If you know of other folks who should review at this stage, please pass it along. thanks, Ted ---------- Forwarded message ---------- From: Date: Wed, Mar 18, 2015 at 1:52 PM Subject: [IAB] I-D ACTION:draft-iab-privsec-confidentiality-threat-04.txt To: i-d-announce@ietf.org Cc: iab@iab.org A new Internet-Draft is available from the on-line Internet-Drafts directories. Title : Confidentiality in the Face of Pervasive Surveillance: A Threat Model and Problem Statement Author(s) : R. Barnes, et al Filename : draft-iab-privsec-confidentiality-threat Pages : 23 Date : 2015-03-18 Documents published since initial revelations in 2013 have revealed several classes of pervasive surveillance attack on Internet communications. In this document we develop a threat model that describes these pervasive attacks. We start by assuming an attacker with an interest in undetected, indiscriminate eavesdropping, then expand the threat model with a set of verified attacks that have been published. A URL for this Internet-Draft is: https://www.ietf.org/internet-drafts/draft-iab-privsec-confidentiality-threat-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --20cf30334657b0bade051196595a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Howdy,

This version updat= es the draft to reflect some of the recent feedback, and we'd appreciat= e fresh reviews.=C2=A0 It is likely that this version will be the one the I= AB sends for general community review, so an early look at it would be much= appreciated.=C2=A0 If you know of other folks who should review at this st= age, please pass it along.

thanks,

Ted


---= ------- Forwarded message ----------
From: <Int= ernet-Drafts@ietf.org>
Date: Wed, Mar 18, 2015 at 1:52 PM<= br>Subject: [IAB] I-D ACTION:draft-iab-privsec-confidentiality-threat-04.tx= t
To: i-d-announce@ietf.org=
Cc: iab@iab.org


A new Int= ernet-Draft is available from the on-line Internet-Drafts directories.


=C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Confidentiality in t= he Face of Pervasive Surveillance: A Threat Model and Problem Statement
=C2=A0 =C2=A0 Author(s)=C2=A0 =C2=A0 =C2=A0: R. Barnes, et al
=C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 : draft-iab-privsec-confidential= ity-threat
=C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: 23
=C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 2015-03-18

=C2=A0 =C2=A0Documents published since initial revelations in 2013 have rev= ealed
=C2=A0 =C2=A0several classes of pervasive surveillance attack on Internet =C2=A0 =C2=A0communications.=C2=A0 In this document we develop a threat mod= el that
=C2=A0 =C2=A0describes these pervasive attacks.=C2=A0 We start by assuming = an attacker
=C2=A0 =C2=A0with an interest in undetected, indiscriminate eavesdropping, = then
=C2=A0 =C2=A0expand the threat model with a set of verified attacks that ha= ve been
=C2=A0 =C2=A0published.

A URL for this Internet-Draft is:
https://www.ietf.org/internet-draft= s/draft-iab-privsec-confidentiality-threat-04.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.



--20cf30334657b0bade051196595a-- From nobody Tue Mar 24 21:06:23 2015 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C7CC1ACD8E for ; Tue, 24 Mar 2015 21:06:21 -0700 (PDT) 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 xCV7Hx5sII8a for ; Tue, 24 Mar 2015 21:06:20 -0700 (PDT) Received: from mail-lb0-f174.google.com (mail-lb0-f174.google.com [209.85.217.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB30D1ACD82 for ; Tue, 24 Mar 2015 21:06:19 -0700 (PDT) Received: by lbbug6 with SMTP id ug6so8812476lbb.3 for ; Tue, 24 Mar 2015 21:06:18 -0700 (PDT) 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=l2uC9Dc5aHh5qUbFrF+ctUmKrX3IZjAThWtdUtDDh4E=; b=Tro0i1WRHddQ+Jq82LkvS26xkcjFMU/vJsfQ3J7sHOvc+U7rUwxmNL39yq5r4iQx2f Xl4S+/PACvNNxDDp7mZWZ4Wp2xMIhedqCmAOVUbmO8pQwQV6STmG3GPKpFqvoig6kpBv a7okKKmZUka0Eo64e6lIgRembQi3P9k6cKFKIAYD5W8zSFUDJy7xLkwjoFj3UnHA5HeK +dkIeq9tV0qOqkGPxEDhuNHE932DruYmWTfF5HTNtW1Lrix/2AKVnGNv3ZJIGhfoULY7 5RVZ7NMhfkVkU9S5fReaswiCwAHbM6SKftUY+ch+80NdBrpn+9IqTMQMCO1PMe3XxZSX 2G8w== X-Gm-Message-State: ALoCoQkLzuuPsxf45AUtkZamvF0m7WpMSB3/NnYTVZ4h6CRMlmudYi4mqIhXfhAG6+mtTWzUZI8K MIME-Version: 1.0 X-Received: by 10.112.141.106 with SMTP id rn10mr6662009lbb.100.1427256378175; Tue, 24 Mar 2015 21:06:18 -0700 (PDT) Received: by 10.114.3.242 with HTTP; Tue, 24 Mar 2015 21:06:18 -0700 (PDT) X-Originating-IP: [122.56.200.172] Received: by 10.114.3.242 with HTTP; Tue, 24 Mar 2015 21:06:18 -0700 (PDT) Date: Wed, 25 Mar 2015 17:06:18 +1300 Message-ID: From: Tim Bray To: perpass Content-Type: multipart/alternative; boundary=001a11c26b386cc6f6051215055b Archived-At: Subject: [perpass] https.CIO.gov X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "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, 25 Mar 2015 04:06:21 -0000 --001a11c26b386cc6f6051215055b Content-Type: text/plain; charset=UTF-8 Check out https://https.cio.gov/ - some good clear thinking there in the write-up. --001a11c26b386cc6f6051215055b Content-Type: text/html; charset=UTF-8

Check out https://https.cio.gov/ - some good clear thinking there in the write-up.

--001a11c26b386cc6f6051215055b-- From nobody Wed Mar 25 10:08:39 2015 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AEAE1A894A for ; Wed, 25 Mar 2015 10:08:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-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 70wtkKoEnUr0 for ; Wed, 25 Mar 2015 10:08:37 -0700 (PDT) Received: from newsmtp.well.com (newsmtp.well.com [107.20.247.102]) by ietfa.amsl.com (Postfix) with ESMTP id 122511A88E2 for ; Wed, 25 Mar 2015 10:08:36 -0700 (PDT) Received: from zimbra.well.com (zimbra.well.com [10.69.72.164]) by newsmtp.well.com (8.14.3/8.14.3) with ESMTP id t2PH8ZHV016866; Wed, 25 Mar 2015 10:08:35 -0700 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.well.com (Postfix) with ESMTP id 60D784010D34; Wed, 25 Mar 2015 10:08:36 -0700 (PDT) Received: from zimbra.well.com ([127.0.0.1]) by localhost (zimbra.well.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WtogjYLhEf5E; Wed, 25 Mar 2015 10:08:35 -0700 (PDT) Received: from MLiebhold.local (unknown [199.73.113.19]) by zimbra.well.com (Postfix) with ESMTPSA id 3BBCB4010D25; Wed, 25 Mar 2015 10:08:35 -0700 (PDT) Message-ID: <5512EB91.9060009@well.com> Date: Wed, 25 Mar 2015 10:08:33 -0700 From: Mike Liebhold User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Tim Bray , perpass References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------020901030003040603000707" Archived-At: Subject: Re: [perpass] https.CIO.gov X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "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, 25 Mar 2015 17:08:38 -0000 This is a multi-part message in MIME format. --------------020901030003040603000707 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit HTTPs everywhere is a critically important goal, but as Peter Eckersley at EFF points out, without best practices for keeping certificates current, with reliable cert authorities -- the -assumption- of a secure HTTPs connection can be undermined.. e.g. When encountering an "unrecognized certificate" warning - most people click through.... potentially connecting to a spoofed site.... even though it says HTTPs in the url bar. On 3/24/15 9:06 PM, Tim Bray wrote: > > Check out https://https.cio.gov/ - some good clear thinking there in > the write-up. > > > > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass --------------020901030003040603000707 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
HTTPs everywhere is a critically important goal, but as Peter Eckersley at EFF points out, without best practices for keeping certificates current, with reliable cert authorities -- the  -assumption-  of a secure HTTPs connection  can be undermined..

e.g. When encountering an "unrecognized certificate" warning - most people click through....  potentially  connecting to a spoofed site.... even though it says HTTPs in the url bar.




On 3/24/15 9:06 PM, Tim Bray wrote:

Check out https://https.cio.gov/ - some good clear thinking there in the write-up.



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

--------------020901030003040603000707-- From nobody Wed Mar 25 10:11:20 2015 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C7AD1A8989 for ; Wed, 25 Mar 2015 10:11:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-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 9K8Qff17SiGK for ; Wed, 25 Mar 2015 10:11:18 -0700 (PDT) Received: from newsmtp.well.com (newsmtp.well.com [107.20.247.102]) by ietfa.amsl.com (Postfix) with ESMTP id D86B11A879C for ; Wed, 25 Mar 2015 10:11:17 -0700 (PDT) Received: from zimbra.well.com (zimbra.well.com [10.69.72.164]) by newsmtp.well.com (8.14.3/8.14.3) with ESMTP id t2PHBGvw019571; Wed, 25 Mar 2015 10:11:16 -0700 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.well.com (Postfix) with ESMTP id 5DF334010D7E; Wed, 25 Mar 2015 10:11:17 -0700 (PDT) Received: from zimbra.well.com ([127.0.0.1]) by localhost (zimbra.well.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fcJL-HfRYadt; Wed, 25 Mar 2015 10:11:16 -0700 (PDT) Received: from MLiebhold.local (unknown [199.73.113.19]) by zimbra.well.com (Postfix) with ESMTPSA id E4DA64010D67; Wed, 25 Mar 2015 10:11:15 -0700 (PDT) Message-ID: <5512EC32.2030001@well.com> Date: Wed, 25 Mar 2015 10:11:14 -0700 From: Mike Liebhold User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Tim Bray , perpass References: <5512EB91.9060009@well.com> In-Reply-To: <5512EB91.9060009@well.com> Content-Type: multipart/alternative; boundary="------------060604000709080105080704" Archived-At: Subject: Re: [perpass] https.CIO.gov X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "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, 25 Mar 2015 17:11:19 -0000 This is a multi-part message in MIME format. --------------060604000709080105080704 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit I neglected to include the link to the new EFF/Mozilla Certificate authority initiative. Launching in 2015: A Certificate Authority to Encrypt the Entire Web https://www.eff.org/deeplinks/2014/11/certificate-authority-encrypt-entire-web On 3/25/15 10:08 AM, Mike Liebhold wrote: > HTTPs everywhere is a critically important goal, but as Peter > Eckersley at EFF points out, without best practices for keeping > certificates current, with reliable cert authorities -- the > -assumption- of a secure HTTPs connection can be undermined.. > > e.g. When encountering an "unrecognized certificate" warning - most > people click through.... potentially connecting to a spoofed > site.... even though it says HTTPs in the url bar. > > > > > On 3/24/15 9:06 PM, Tim Bray wrote: >> >> Check out https://https.cio.gov/ - some good clear thinking there in >> the write-up. >> >> >> >> _______________________________________________ >> perpass mailing list >> perpass@ietf.org >> https://www.ietf.org/mailman/listinfo/perpass > --------------060604000709080105080704 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
I neglected  to include the link to the new  EFF/Mozilla Certificate authority initiative.

Launching in 2015: A Certificate Authority to Encrypt the Entire Web
https://www.eff.org/deeplinks/2014/11/certificate-authority-encrypt-entire-web


On 3/25/15 10:08 AM, Mike Liebhold wrote:
HTTPs everywhere is a critically important goal, but as Peter Eckersley at EFF points out, without best practices for keeping certificates current, with reliable cert authorities -- the  -assumption-  of a secure HTTPs connection  can be undermined..

e.g. When encountering an "unrecognized certificate" warning - most people click through....  potentially  connecting to a spoofed site.... even though it says HTTPs in the url bar.




On 3/24/15 9:06 PM, Tim Bray wrote:

Check out https://https.cio.gov/ - some good clear thinking there in the write-up.



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


--------------060604000709080105080704-- From nobody Wed Mar 25 10:47:20 2015 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 443B71A9164 for ; Wed, 25 Mar 2015 10:47:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 U6fL2WFNST2j for ; Wed, 25 Mar 2015 10:47:18 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id EDD421A9149 for ; Wed, 25 Mar 2015 10:47:17 -0700 (PDT) Received: from [IPv6:2001:67c:1231:998:59fc:1802:aa5c:57ae] (unknown [IPv6:2001:67c:1231:998:59fc:1802:aa5c:57ae]) by toccata.fugue.com (Postfix) with ESMTPSA id 5827D23824E4; Wed, 25 Mar 2015 13:47:17 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: <5512EB91.9060009@well.com> Date: Wed, 25 Mar 2015 12:47:16 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <8050AF5E-A194-4E2B-88BC-921DB6A0BBC3@fugue.com> References: <5512EB91.9060009@well.com> To: Mike Liebhold X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: perpass , Tim Bray Subject: Re: [perpass] https.CIO.gov X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "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, 25 Mar 2015 17:47:19 -0000 On Mar 25, 2015, at 12:08 PM, Mike Liebhold wrote: > e.g. When encountering an "unrecognized certificate" warning - most = people click through.... potentially connecting to a spoofed site.... = even though it says HTTPs in the url bar. This is a UI fail. The browser should never display that alert, any = more than it should display an alert to click through proposing that you = might want to try a different web site if the one you were trying to = reach were simply unreachable. Of course, I realize that this makes captive portals more difficult, but = enabling this particular UI fail simply in order to allow captive = portals to work is a very expensive solution to an easily solved problem = (see http://datatracker.ietf.org/doc/draft-wkumari-dhc-capport/). From nobody Thu Mar 26 19:11:54 2015 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2601C1A8A4C for ; Thu, 26 Mar 2015 19:11:52 -0700 (PDT) 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] 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 ZfBu3bOrIZ29 for ; Thu, 26 Mar 2015 19:11:51 -0700 (PDT) Received: from palinka.tinho.net (palinka.tinho.net [166.84.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id DF1401A701E for ; Thu, 26 Mar 2015 19:11:50 -0700 (PDT) Received: by palinka.tinho.net (Postfix, from userid 126) id 9EB45228181; Thu, 26 Mar 2015 22:11:40 -0400 (EDT) Received: from palinka.tinho.net (localhost [127.0.0.1]) by palinka.tinho.net (Postfix) with ESMTP id 984CD228117 for ; Thu, 26 Mar 2015 22:11:40 -0400 (EDT) From: dan@geer.org To: perpass@ietf.org In-Reply-To: Your message of "Wed, 25 Mar 2015 10:11:14 -0700." <5512EC32.2030001@well.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <97067.1427422300.1@palinka.tinho.net> Date: Thu, 26 Mar 2015 22:11:40 -0400 Message-Id: <20150327021140.9EB45228181@palinka.tinho.net> Archived-At: Subject: Re: [perpass] https.CIO.gov X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "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 Mar 2015 02:11:52 -0000 Encryption everywhere all the time? No, thank you. Better said, and at effective length, by David Golumbia Opt-Out Citizenship: End-to-End Encryption and Constitutional Governance http://www.uncomputing.org/?p=272 --dan From nobody Thu Mar 26 19:42:51 2015 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D86A1A8F42 for ; Thu, 26 Mar 2015 19:42:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-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 0Z1YyiUmjQ4G for ; Thu, 26 Mar 2015 19:42:48 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F4E31A8F3D for ; Thu, 26 Mar 2015 19:42:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 3FD2BBEE0; Fri, 27 Mar 2015 02:42:47 +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 gS-ixS6SgQYP; Fri, 27 Mar 2015 02:42:45 +0000 (GMT) Received: from [31.133.139.135] (unknown [31.133.139.135]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 5F77CBE87; Fri, 27 Mar 2015 02:42:45 +0000 (GMT) Message-ID: <5514C3A3.4080107@cs.tcd.ie> Date: Fri, 27 Mar 2015 02:42:43 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: dan@geer.org, perpass@ietf.org References: <20150327021140.9EB45228181@palinka.tinho.net> In-Reply-To: <20150327021140.9EB45228181@palinka.tinho.net> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [perpass] https.CIO.gov X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "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 Mar 2015 02:42:50 -0000 On 27/03/15 02:11, dan@geer.org wrote: > Encryption everywhere all the time? No, thank you. Much more encryption, done well, almost all the time - yes please:-) > Better said, and at effective length, by David Golumbia > > Opt-Out Citizenship: End-to-End Encryption and > Constitutional Governance > http://www.uncomputing.org/?p=272 Had a quick flick. Arguments based on a presumption of "perfect end-to-end encryption" are utterly useless as they are counterfactual. Anything one likes can follow from a false assumption like that. S. > > > --dan > > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > > From nobody Thu Mar 26 21:02:25 2015 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A46641A1EED for ; Thu, 26 Mar 2015 21:02:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 gpSr3B_nL6VU for ; Thu, 26 Mar 2015 21:02:22 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 5FA0D1A1B46 for ; Thu, 26 Mar 2015 21:02:22 -0700 (PDT) Received: from dhcp-89e7.meeting.ietf.org (dhcp-89e7.meeting.ietf.org [31.133.137.231]) by toccata.fugue.com (Postfix) with ESMTPSA id 0C22023803BE; Fri, 27 Mar 2015 00:02:20 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: <5514C3A3.4080107@cs.tcd.ie> Date: Thu, 26 Mar 2015 23:02:19 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <610E1982-5E08-453D-AD81-6DB26ADD41F0@fugue.com> References: <20150327021140.9EB45228181@palinka.tinho.net> <5514C3A3.4080107@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: perpass@ietf.org, dan@geer.org Subject: Re: [perpass] https.CIO.gov X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "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 Mar 2015 04:02:23 -0000 On Mar 26, 2015, at 9:42 PM, Stephen Farrell = wrote: > Had a quick flick. Arguments based on a presumption of "perfect > end-to-end encryption" are utterly useless as they are counterfactual. > Anything one likes can follow from a false assumption like that. The article also makes the mistake of thinking that the NSA = eavesdropping on us is really the big failure mode. Whether or not you = think the NSA should eavesdrop on us, there are plenty of actors who = should not, but who can, if we don't have more encryption. The NSA is = just the bellwether. And the argument that we don't _really_ need privacy makes a lot of = sense until you start asking yourself who you want to have copies of = your credit card, who you want to know that you are away from your home = this week, who you want to have photos of you in indiscreet poses, which = gamergate trolls you want to have access to your private information, = etc. Come on, Dan, don't troll us! From nobody Fri Mar 27 04:26:41 2015 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5B4F1ACD5F for ; Fri, 27 Mar 2015 04:26:39 -0700 (PDT) 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 KKd4gYD5Hq3Y for ; Fri, 27 Mar 2015 04:26:37 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B64621ACD72 for ; Fri, 27 Mar 2015 04:26:35 -0700 (PDT) Received: from [172.20.1.163] (rrcs-71-41-251-196.sw.biz.rr.com [71.41.251.196]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id t2RBQFr4010009 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 27 Mar 2015 04:26:20 -0700 Message-ID: <55153E55.10806@dcrocker.net> Date: Fri, 27 Mar 2015 06:26:13 -0500 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Ted Lemon , Stephen Farrell References: <20150327021140.9EB45228181@palinka.tinho.net> <5514C3A3.4080107@cs.tcd.ie> <610E1982-5E08-453D-AD81-6DB26ADD41F0@fugue.com> In-Reply-To: <610E1982-5E08-453D-AD81-6DB26ADD41F0@fugue.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Fri, 27 Mar 2015 04:26:23 -0700 (PDT) Archived-At: Cc: perpass@ietf.org, dan@geer.org Subject: Re: [perpass] https.CIO.gov 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 Mar 2015 11:26:39 -0000 On 3/26/2015 11:02 PM, Ted Lemon wrote: > Come on, Dan, don't troll us! Ted, As far as I'm aware, this is a forum for discussing technical aspects of privacy, rather than policy aspects. As such, debating the policy implications of true 'perfect' e2e encryption seems out of scope, though I'd assume that being notified of useful articles about it is worthy. Still, a casual ad hominem like yours constitutes a far greater trolling action in the IETF than a serious posting to a an article about a difficult topic. Attempting to marginalize a serious person's serious posting by attacking their motives is supposed to be unacceptable in the IETF. In fact since it prompted Stephen's response, I'd say that the comment on downsides to 'perfect e2e encryption' was useful: I class Stephen's clarification of the difference between the goal of perfect e2e encryption, vs. the currently-attainable far-less-than-perfect, an essential clarification to discussions about efforts like https-everywhere. This is not an intimate conversation amongst well-acquainted colleagues subject to their own private social contract of behavior. It's a public forum. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Fri Mar 27 04:42:52 2015 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6140A1ACD6E for ; Fri, 27 Mar 2015 04:42:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.199 X-Spam-Level: X-Spam-Status: No, score=-1.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, 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 CsKeeQb0nI27 for ; Fri, 27 Mar 2015 04:42:50 -0700 (PDT) Received: from mail-la0-f47.google.com (mail-la0-f47.google.com [209.85.215.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D23671ACD5F for ; Fri, 27 Mar 2015 04:42:49 -0700 (PDT) Received: by labto5 with SMTP id to5so68341468lab.0 for ; Fri, 27 Mar 2015 04:42:48 -0700 (PDT) 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:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=IGZpGdM5V3WKu/OLUZI/V7DPy/twtiwH+vpWBq4CLNQ=; b=lr93CK2ICfSx2RbDzB4a6r+I4uaxmX7F9KGyQgjZOWiua06A7DMLWvPYU5LGsTX6/z grpOomYJlqvGKKUik7nCiy3gfIMyYpbWSaM7I2z7EaFyTGPix/xH/e3oeHmX6PM9JPnT PhXcApB5TxtVtxKAWZeFmEEx5+o6QIdkTy9cGI/aaGrwgwFWVTagM42XXGA9aNLGBDuI hmyDxRQvKkNKCoywnKASq5vMEcpCWdGXmlSreSemJrzPbaQ6esV9odvTRaziBsJRTiKk /S4yx235l6OoIVd27gOBZuZm49fgaqcOClSHaA+HdfaHrZBOmu3HsQKJ6avxrN+5FX9z xCxw== X-Gm-Message-State: ALoCoQk+Jco6ilawmE4xt75rrA8sIEmHnAVat6iy+WVTkB3gcsq6lyfdoANIxg70crthxMJxi0ZL X-Received: by 10.152.179.68 with SMTP id de4mr17512602lac.65.1427456568191; Fri, 27 Mar 2015 04:42:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.37.4 with HTTP; Fri, 27 Mar 2015 04:42:27 -0700 (PDT) In-Reply-To: <20150327021140.9EB45228181@palinka.tinho.net> References: <5512EC32.2030001@well.com> <20150327021140.9EB45228181@palinka.tinho.net> From: Joseph Lorenzo Hall Date: Fri, 27 Mar 2015 06:42:27 -0500 Message-ID: To: dan@geer.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: perpass@ietf.org Subject: Re: [perpass] https.CIO.gov X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "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 Mar 2015 11:42:51 -0000 On Thu, Mar 26, 2015 at 9:11 PM, wrote: > Encryption everywhere all the time? No, thank you. > > Better said, and at effective length, by David Golumbia > > Opt-Out Citizenship: End-to-End Encryption and > Constitutional Governance > http://www.uncomputing.org/?p=3D272 In addition to what others have said -- this does feel like a trolling of perpass -- I think Mike Masnick summed up a useful perspective on this from an article on FBI Director Comey's rather bizarre testimony yesterday where he asked for US legislation mandating backdoors. In short, just because we are mediating more of our lives through networked devices does not mean the government should be able to to access those flows, and it doesn't take away the responsibility to do good old police work. ---- https://www.techdirt.com/articles/20150325/17430330432/fbi-quietly-removes-= recommendation-to-encrypt-your-phone-as-fbi-director-warns-how-encryption-w= ill-lead-to-tears.shtml .... Not surprisingly, Comey pulls out the trifecta of FUD in trying to explain why it needs to spy on everyone: pedophiles, kidnappers and drug dealers: =E2=80=9CTech execs say privacy should be the paramount virtue,=E2=80=9D Co= mey continued, =E2=80=9CWhen I hear that I close my eyes and say try to image w= hat the world looks like where pedophiles can=E2=80=99t be seen, kidnapper can= =E2=80=99t be seen, drug dealers can=E2=80=99t be seen.=E2=80=9D Except we know exactly what that looks like -- because that's the world we've basically always lived with. And yet, law enforcement folks like the FBI and various police departments were able to use basic detective work to track down criminals. ---- The thinking from articles like the one Dan sent can naturally be extended to demanding government access to what are effectively our thoughts (the last bastion of freedom in a Democracy, I'd think) once we have computational cognitive support systems (which is not nearly as sci-fi as you might think. best, Joe --=20 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 From nobody Fri Mar 27 09:29:47 2015 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E899B1A1BA5 for ; Fri, 27 Mar 2015 09:29:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-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 ppeI-uTcyKSx for ; Fri, 27 Mar 2015 09:29:43 -0700 (PDT) Received: from mail-pd0-x235.google.com (mail-pd0-x235.google.com [IPv6:2607:f8b0:400e:c02::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0AAF1A03B3 for ; Fri, 27 Mar 2015 09:29:42 -0700 (PDT) Received: by pdnc3 with SMTP id c3so101266680pdn.0 for ; Fri, 27 Mar 2015 09:29:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to; bh=MOX8gB2R/FkTWPBOdwwPUqg7Q3X5g8HnGfiWTuqZuS8=; b=uqDAEUzSC90pzCgu5IL6xfRw7dm9EdtvbfjBVcQkNNRYYwcV9tiD9cJhycpu+BNIS/ X2WeKMy2S7zKJutmsqXYjzujhN/9mixjKVoXCh+9qXfQKXqYjamGzUSJzaDiBBOCGNkJ dzue2HR9kTvoLvuiBJE7AogJVlQw+RAbQ+DjIwYktIvvIuCor9YiV4fvuJD72zGDtgPQ qL3tNpENFqHBAGAI1qpjCzkioBab958hwfufZ5SKQI61IjLuq9SnduKtxAgYOwsJYlkN Af8pgDE6Mh3rJaoaOWaw9ekx2pawRHh893PaPeVdhRrGpqrnv5WrLzfJxJrBSyVQBWhS h1og== X-Received: by 10.69.13.225 with SMTP id fb1mr37052646pbd.104.1427473782496; Fri, 27 Mar 2015 09:29:42 -0700 (PDT) Received: from ?IPv6:2601:9:2b80:12f1:a930:f653:8e39:6fe9? ([2601:9:2b80:12f1:a930:f653:8e39:6fe9]) by mx.google.com with ESMTPSA id g10sm2639893pdm.29.2015.03.27.09.29.40 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 27 Mar 2015 09:29:41 -0700 (PDT) Sender: Nicholas Weaver Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_E33D99A5-81E2-4601-A370-A71A089C066F"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b6 From: Nicholas Weaver In-Reply-To: <20150327021140.9EB45228181@palinka.tinho.net> Date: Fri, 27 Mar 2015 09:29:39 -0700 Message-Id: References: <20150327021140.9EB45228181@palinka.tinho.net> To: dan@geer.org X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: perpass@ietf.org, Nicholas Weaver Subject: Re: [perpass] https.CIO.gov X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "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 Mar 2015 16:29:46 -0000 --Apple-Mail=_E33D99A5-81E2-4601-A370-A71A089C066F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Mar 26, 2015, at 7:11 PM, dan@geer.org wrote: >=20 > Encryption everywhere all the time? No, thank you. >=20 > Better said, and at effective length, by David Golumbia This assumes three things: a) That you are protected by US law b) That the systems are NOBUS ("Nobody But Us") c) That cleartext isn't a direct exploitable vulnerability. Unfortunately none is the case Lets take case A and assume you aren't a 5EYES citizen. The US is quite = explicit that if you aren't a 5EYES citizen, anything goes: There are = no legal limits, there are no protections against US activities. In particular, "economic espionage" in the classic sense [1] is on the = table: So if anything you do affects international commerce, you are an = in-scope target. Lets take case B: There is an implicit assumption that the only one = watching is the "good guys". Its quite true that the NSA has been = remarkably constrained in its monitoring outside its mandates = (unfortunately its mandates include "SIGINT development" and economic = issues.) But who says the NSA is the only one listening? The NSA's gross overreach in acting against others brings into play the = golden rule corollary: "Feel free to do unto others as they hath already = done unto you". [2] All it takes to monitor a 10 Gbps link is a load = balancer and a couple of 1u PCs: the software itself is pretty much = routine NIDS-type stuff [3]. We have near zero security on internal communications crossing the US. = You think a foreign country can't have a couple of "diplomats" hire a = bobcat? Place monitors at Foggy Bottom starbucks or every hotel in DC? And that isn't even beginning to consider all the things said countries = can do on their borders: If one endpoint of your communication is = outside the US, and the countries it cross (*cough* France *cough*) can = gain benefit from monitoring it, they will. And since the NSA did it to = them, they are welcome to do it back to us. Lets take case C, which is the kicker: Cleartext is not just an avenue = for monitoring, but a vector for attack. If your adversary can see your = cleartext communication, and can identify you as a target, they can = modify that communication to exploit you. This is the biggest problem. The NSA said "its OK for nation states to = directly 'shoot' exploits from the backbone". This also interacts very strongly with B: For <$200/each, I can deploy = an open WiFi monitor thats fully deniable (everything is COTS), = disguised (think 'plug in air freshener'), and tamper resistant, which = enables not just "monitor all on the wifi" but explicit "pwn by name": = injecting malicious responses into traffic of identified targets. And the allowed target set is effectively everybody: the GCHQ used this = to penetrate Belgacom. Yes, telecom is critical infrastructure, and = GCHQ used this to exploit a NATO ally's critical infrastructure. So if = you can penetrate an ally's critical infrastructure by injecting = exploits into cleartext communication, and the NSA and GCHQ said its OK = by doing it, why can't the DGSE do it to us? If you are lucky, your adversary can be any country where your traffic = passes through except your own. Taken together: If you aren't 5EYES, US law won't protect you. If you are, foreign law won't protect you. And in either case, cleartext, by being modified, is an exploitable = vulnerability, not just an observation hole. This is why we MUST encrypt all the things. There are no legal norms and niceties that can protect our interests, no = matter who "our" is: The US government, US companies, US individuals, = foreign governments, foreign companies, foreign individuals, they all = now face a practical UN full of adversaries who can and will exploit = anything they want. Its all on the table. By spying on every communication for words like "WTO." and = $CANDIDATE_NAME, by hacking Belgacom, Petrobras, Gemalto, Huawei, and = individuals like Quisquater, the NSA and company have told the rest of = the world that there are no limits on who you can spy on and who you can = hack, and the rest of the world will listen. [1] The typical NSA dodge is to redefine "economic espionage" to being = 'provide the information to US companies'. Thats true, they do not = appear to do that form of economic espionage. But they are quite = willing to hand the information over to other portions of the US = government, e.g. it is acceptable behavior to search every email seen on = the planet for voting information on the WTO, and we've seen the NZ = rules for this. [2] The biggest offender is not the NSA but the GCHQ (British). But = they did it with our toys and then "Putin's law" comes into effect: If = you give someone a missile, you are partially responsible for who they = shoot down. [3] The biggest limit is often asymmetric traffic. Bro in particular = doesn't handle seeing one-side of a link, and its been a low priority = for developers to change that. But you can always download Vortex and = start from there. -- 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=_E33D99A5-81E2-4601-A370-A71A089C066F 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 - https://gpgtools.org iQIcBAEBCgAGBQJVFYVzAAoJEG2B1w+SDi/uqAQQAIHWWVrMornPslGyv+nQOO+V 0H9iq1bJ6DxId3G2GBTcTCdZblva6uFNk3CABShcRRsokO/gQToRqhBXXPX0VMXh sg/SeaZhjPyp5l6K/ZpSr+Cn1daUvMbLsRx7IK9qBKaZkxkimwkn5VBG8pcaJpuT qXIomdOEtfNdiHrXaQ4ggErXU8yTJ1Y5iXkPYYjjA6SjhANod7E0YPaFpUi0+g44 6I74BQMWAlbrgCVVfD0BWzGeJP+rx4QjyWDR2ay5UG3yHW1AD6odEfBIIBsW1vEz 6kWtecVeGuPEZIkpV2TO2InvIdN1W+XAO+nrhix8521zaGkh4P7ZJiEKOBIuVxP8 ouGZ4xUXJaCMTMq3t5mHomU/3C/QoFzxT1PepctF9gc+nm0dI/lvm1TGeC09XLl8 qUs2pG7uD2Y4c7fOtmiovibyS+IeJdy9rZBELWWmr4FgkgrNAd/F4XP8ChAlYF4m 31dJaCRkFdpqWpcbeg85uBZDRVEkdTSqSMBDohlmTz/ebFJpzvY3XZeHD2fMP04d 48ap4eflDy2yjiFwFzGrrL1WUspw57qV5Fc1wmuRG+U/h735CRUxecC+ziWvX1KS 1wsF1IQMUHAToOaBoyli1q5mQuddUax5e4T7iOJieGVHB2WCVtDiGZTklY6bsbQM jvu8oAJ+GbTLIZfboNOn =9XSQ -----END PGP SIGNATURE----- --Apple-Mail=_E33D99A5-81E2-4601-A370-A71A089C066F-- From nobody Fri Mar 27 18:48:21 2015 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1736B1A1B17 for ; Fri, 27 Mar 2015 18:48:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 nKkpN11cgzXP for ; Fri, 27 Mar 2015 18:48:19 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id A9BC41A1B0B for ; Fri, 27 Mar 2015 18:48:19 -0700 (PDT) Received: from [10.0.20.107] (c-71-233-43-215.hsd1.nh.comcast.net [71.233.43.215]) by toccata.fugue.com (Postfix) with ESMTPSA id 5204F238031A; Fri, 27 Mar 2015 21:48:17 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: <55153E55.10806@dcrocker.net> Date: Fri, 27 Mar 2015 21:48:14 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <22D97A6B-AE0E-449D-8924-346E97A4B881@fugue.com> References: <20150327021140.9EB45228181@palinka.tinho.net> <5514C3A3.4080107@cs.tcd.ie> <610E1982-5E08-453D-AD81-6DB26ADD41F0@fugue.com> <55153E55.10806@dcrocker.net> To: dcrocker@bbiw.net X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: perpass@ietf.org, dan@geer.org, Stephen Farrell Subject: Re: [perpass] https.CIO.gov X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "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, 28 Mar 2015 01:48:21 -0000 On Mar 27, 2015, at 7:26 AM, Dave Crocker wrote: > This is not an intimate conversation amongst well-acquainted = colleagues > subject to their own private social contract of behavior. It's a = public > forum. My reaction was based on genuine surprise to see Dan repeating this = argument, since he lived through the last set of crypto wars just like = the rest of us. It was said with affection, but meant seriously. If = there is a new argument to be had here, it was not usefully presented in = that article. From nobody Fri Mar 27 19:36:33 2015 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFE461A1A86 for ; Fri, 27 Mar 2015 19:36:29 -0700 (PDT) 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 zbUibzQqoYwc for ; Fri, 27 Mar 2015 19:36:25 -0700 (PDT) Received: from palinka.tinho.net (palinka.tinho.net [166.84.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 322121A1A81 for ; Fri, 27 Mar 2015 19:36:25 -0700 (PDT) Received: by palinka.tinho.net (Postfix, from userid 126) id 251BE228164; Fri, 27 Mar 2015 22:36:14 -0400 (EDT) Received: from palinka.tinho.net (localhost [127.0.0.1]) by palinka.tinho.net (Postfix) with ESMTP id 1D2A0228155; Fri, 27 Mar 2015 22:36:14 -0400 (EDT) From: dan@geer.org To: Nicholas Weaver In-Reply-To: Your message of "Fri, 27 Mar 2015 09:29:39 -0700." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <98559.1427510174.1@palinka.tinho.net> Date: Fri, 27 Mar 2015 22:36:14 -0400 Message-Id: <20150328023614.251BE228164@palinka.tinho.net> Archived-At: Cc: perpass@ietf.org Subject: Re: [perpass] https.CIO.gov X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "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, 28 Mar 2015 02:36:30 -0000 I don't have the {skill,time,drive} to debate all this, for which I apologize. I will ask you a question that may produce the same response from you as I just gave, namely: In a world where the deployment curve of the IoT has a 17-month doubling time, who or what is going to do the key management that you would actually believe in? --dan From nobody Fri Mar 27 20:08:56 2015 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 628201A1B69 for ; Fri, 27 Mar 2015 20:08:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 BRn0Cf61gl3v for ; Fri, 27 Mar 2015 20:08:52 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2479E1A1A37 for ; Fri, 27 Mar 2015 20:08:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7264; q=dns/txt; s=iport; t=1427512132; x=1428721732; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=ZoVKHVbvIWC1PhtL2Q75I2rkEGej3f0wW2UlKitujSE=; b=Q+EK+6AKoCOi1hyRcc7hTm4G6l7yOyCGxOhJUpyTi4ahkm3yzQLirl3e Dta181rXXkOjKl5FeT9U52unKXNxgHxMiB/XQNkmOntz4JGAoCKGcmQnv ATFmewEH+cQ4pdDRozR2DPQ6UkLivR/Fmlyb6EJU76BXBoDv7sGn9MRSh 0=; X-Files: signature.asc : 486 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D6CgByGhZV/4MNJK1cgwZSXIMTwkGFcwKBMkwBAQEBAQF9QQGDUwEBAgEBDhVCBwoCEQshFgsCAgkDAgECAUUGAQwIAQEFiB4IDbJLmWgBAQEBAQEBAwEBAQEBAQEBGoopf4R/gmiBRQEEjkmDd4EyVIYBgRs6gneCOSGNCyKCAhyBbCIxAYJCAQEB X-IronPort-AV: E=Sophos;i="5.11,482,1422921600"; d="asc'?scan'208,217";a="136165854" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-4.cisco.com with ESMTP; 28 Mar 2015 03:08:51 +0000 Received: from [10.86.242.96] (che-vpn-cluster-2-96.cisco.com [10.86.242.96]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t2S38oB0008773; Sat, 28 Mar 2015 03:08:50 GMT Message-ID: <55161B3D.5010604@cisco.com> Date: Fri, 27 Mar 2015 23:08:45 -0400 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Stephen Farrell , dan@geer.org, Ted Lemon , Joseph Lorenzo Hall , perpass References: <20150327021140.9EB45228181@palinka.tinho.net> <5514C3A3.4080107@cs.tcd.ie> In-Reply-To: <5514C3A3.4080107@cs.tcd.ie> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="21LDvf4KHGtLj8ojaBFsGRHL5jC5oU8ba" Archived-At: Subject: Re: [perpass] https.CIO.gov X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "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, 28 Mar 2015 03:08:54 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --21LDvf4KHGtLj8ojaBFsGRHL5jC5oU8ba Content-Type: multipart/alternative; boundary="------------070404010001020706070900" This is a multi-part message in MIME format. --------------070404010001020706070900 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, It seems to me that having an honest discussion about our biases, goals, and assumptions might help. My goal: I want the Internet to continue to grow in a safe way. It can't do that if people don't trust the infrastructure. There are EU studies that discuss what happens when people experience some form of harm on the Internet.[1] Encryption has played a role in reducing that harm. But it can also increase harm for the very reasons stated in that article. Not acknowledging this would be absurd. Please now see below. On 3/26/15 9:42 PM, Stephen wrote: >> Better said, and at effective length, by David Golumbia >> >> Opt-Out Citizenship: End-to-End Encryption and >> Constitutional Governance >> http://www.uncomputing.org/?p=3D272 > Had a quick flick. Arguments based on a presumption of "perfect > end-to-end encryption" are utterly useless as they are counterfactual. > Anything one likes can follow from a false assumption like that. > Let me see if I understand this statement correctly: this group is working toward a world in which we encrypt our communications, and when someone discusses what that world might look like, you claim it's "counterfactual"? That's not a reasonable argument. Ted claims that the author argues that there is no need for a right to privacy. I didn't read that in the article at all, but rather that the Constitution must be taken as a whole: the same document that protects our rights also provides various balancing tests to protect the rights of others. On the other hand, the piece missing from that article is the need for confidence in the infrastructure, and Ted goes in this direction: if you give the good guys means to gain access to communications, in all likelihood you're giving the bad guys those very same capabilities.=20 That has been the cornerstone of the IETF position for a very long time, and it holds for whatever definition of "good guys" and "bad guys" you might have. Weakening end-to-end encryption weakens confidence in the infrastructure. This guy doesn't care because his focus is about the balance of needs from a legal sense. But these issues cannot be viewed in isolation from one another. Eliot [1] Riek, et. al, /Understanding the Influence of Cybercrime Risk on the E-Service Adoption of European Internet Users/, WEIS 2014.=20 http://weis2014.econinfosec.org/papers/RiekBoehmeMoore-WEIS2014.pdf --------------070404010001020706070900 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi,

It seems to me that having an honest discussion about our biases, goals, and assumptions might help.

My goal: I want the Internet to continue to grow in a safe way.=C2=A0= It can't do that if people don't trust the infrastructure.=C2=A0 There a= re EU studies that discuss what happens when people experience some form of harm on the Internet.[1]=C2=A0 Encryption has played a role i= n reducing that harm.=C2=A0 But it can also increase harm for the very reasons stated in that article.=C2=A0 Not acknowledging this would be= absurd.

Please now see below.

On 3/26/15 9:42 PM, Stephen wrote:
= 

Better said, and at effective length, by David Gol=
umbia

   Opt-Out Citizenship: End-to-End Encryption and
   Constitutional Governance
   http://www.uncomputing.org/?p=3D272

Had a quick flick. Arguments based on a presumption of "perfect
end-to-end encryption" are utterly useless as they are counterfactual.
Anything one likes can follow from a false assumption like that.

Let me see if I understand this statement correctly: this group is working toward a world in which we encrypt our communications, and when someone discusses what that world might look like, you claim it's "counterfactual"?=C2=A0 That's not a reasonable argument.

Ted claims that the author argues that there is no need for a right to privacy.=C2=A0 I didn't read that in the article at all, but rathe= r that the Constitution must be taken as a whole: the same document that protects our rights also provides various balancing tests to protect the rights of others.

On the other hand, the piece missing from that article is the need for confidence in the infrastructure, and Ted goes in this direction: if you give the good guys means to gain access to communications, in all likelihood you're giving the bad guys those very same capabilities.=C2=A0 That has been the cornerstone of the IE= TF position for a very long time, and it holds for whatever definition of "good guys" and "bad guys" you might have.=C2=A0 Weakening end-to-= end encryption weakens confidence in the infrastructure.=C2=A0 This guy doesn't care because his focus is about the balance of needs from a legal sense.=C2=A0 But these issues cannot be viewed in isolation fro= m one another.

Eliot
[1] Riek, et. al, Understanding the Influence of Cybercrime Risk on the E-Service Adoption of European Internet Users, WEIS 2014.=C2= =A0 http://weis2014.econinfosec.or= g/papers/RiekBoehmeMoore-WEIS2014.pdf

--------------070404010001020706070900-- --21LDvf4KHGtLj8ojaBFsGRHL5jC5oU8ba 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.9 (Darwin) iQEcBAEBAgAGBQJVFhtBAAoJEIe2a0bZ0noz5TcH/ApV2UHd7LNAvoybLrVaTAHd 17G6sBUXiXmfj9ZNe6m0H/qGr7wHqLia8jcF7rxrKCJE3YMmoV+f0gCJPafJpURe BIpIh/OZPJmo5IHd19LVOHcoqGAojkfpKLaGcULEIQlkjWOEVGw8/mdEekQQe6Hu Z3ASNTAmbRCyj3U0e11GcUwYwZue+Ir6k3CcPT/nX3NoAPLETFyWuCa0qxtmoYth PaowfIwm7LYmKC0BgTNvAqMWSTryV9afzKZF5mB4rmoCSWTeFHbIg7vcS3HUO1Kg TYaLgMKS9Bcblg3Vn6wCFzVKlL5kUKZLSDWmmKio4U41+Q91vtbz/7VAdV0/Ifc= =zrBt -----END PGP SIGNATURE----- --21LDvf4KHGtLj8ojaBFsGRHL5jC5oU8ba-- From nobody Fri Mar 27 21:23:04 2015 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98C9F1A1B95 for ; Fri, 27 Mar 2015 21:23:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.3 X-Spam-Level: X-Spam-Status: No, score=-3.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, J_CHICKENPOX_31=0.6, 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 FD4RjPiA7b_n for ; Fri, 27 Mar 2015 21:23:01 -0700 (PDT) Received: from xsmtp05.mail2web.com (xsmtp25.mail2web.com [168.144.250.191]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35C071A1BA2 for ; Fri, 27 Mar 2015 21:23:01 -0700 (PDT) Received: from [10.5.2.35] (helo=xmail10.myhosting.com) by xsmtp05.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1YbiGu-0008A4-PI for perpass@ietf.org; Sat, 28 Mar 2015 00:23:00 -0400 Received: (qmail 23358 invoked from network); 28 Mar 2015 04:22:55 -0000 Received: from unknown (HELO huitema1) (Authenticated-user:_huitema@huitema.net@[24.16.156.113]) (envelope-sender ) by xmail10.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 28 Mar 2015 04:22:55 -0000 From: "Christian Huitema" To: "'Eliot Lear'" , "'Stephen Farrell'" , , "'Ted Lemon'" , "'Joseph Lorenzo Hall'" , "'perpass'" References: <20150327021140.9EB45228181@palinka.tinho.net> <5514C3A3.4080107@cs.tcd.ie> <55161B3D.5010604@cisco.com> In-Reply-To: <55161B3D.5010604@cisco.com> Date: Fri, 27 Mar 2015 23:22:54 -0500 Message-ID: <004001d0690e$dd65cf80$98316e80$@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: AQNjBTd+tuLsDj40+b3iRfryWsdqvwHLDIxRAd/GYEeZ7rdlAA== Content-Language: en-us Archived-At: Subject: Re: [perpass] https.CIO.gov X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "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, 28 Mar 2015 04:23:03 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday, March 27, 2015 at 10:09 PM, Eliot Lear wrote: > Let me see if I understand this statement correctly: this group is = working toward a world in which we encrypt our communications, and when = someone discusses what that world might look like, you claim it's = "counterfactual"? That's not a reasonable argument. > Ted claims that the author argues that there is no need for a right to = privacy. I didn't read that in the article at all, but rather that the = Constitution must be taken as a whole: the same document that protects = our rights also provides various balancing tests to protect the rights = of others.=20 The author's point is that the state, with proper warrants, should be = able to conduct searches for evidence of crimes. While this is a = reasonable argument, it does not follow that people should not have the = right to protect their communications. For example, there is no mandate = anywhere that people should keep a copy of their private letters in some = kind of archive, so that they could later be found when the police asks = for it. And there is definitely no expectation that all our private = communications should be copied and archived by the state. And I am = pretty sure that there was no such expectation among the authors of the = US constitution and Bill of Rights. - -- Christian Huitema =20 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (MingW32) Comment: Using gpg4o v3.4.103.5490 - http://www.gpg4o.com/ Charset: utf-8 iQEcBAEBAgAGBQJVFiydAAoJELba05IUOHVQ2q4H/i0VxlhAxXgvGFEiIiNmVUT/ 9e3Ny+nmN/MJjM02PitbJoQkG+IarEgF6Dd+93fTXcH+sGtNdo5Z1UWr/MCCIuQ0 5ZJ9XeZWnuWfKHXA4OoKHwJQ+SITYv3CSo69r0h87OuESKk50fy2495ioCcOPyDU nqAMEVRTSKMh6MLBB8OOnLwmudWNp4W76/sGEg0JOtLpQbqXNuQgk9p2yBkZ9YKb Xu+Czovq3fKfLn2wSzKQ1KH+Qe1mkYT+km0mOs+5x+r3GyD9Ff7B/ghP8faDtm68 AcngF6bKppCHcRH0D0YxbBRFhNT0wCyzyvTh9kHJbm97UcSzMYsOu7FUR4WVLXg=3D =3DLlp/ -----END PGP SIGNATURE----- From nobody Sat Mar 28 05:50:31 2015 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 442D11A8771 for ; Sat, 28 Mar 2015 05:50:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.51 X-Spam-Level: X-Spam-Status: No, score=-16.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 ZGRvctapbiZ0 for ; Sat, 28 Mar 2015 05:50:28 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 971AC1A876F for ; Sat, 28 Mar 2015 05:50:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4815; q=dns/txt; s=iport; t=1427547028; x=1428756628; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=YNS9OY9VoD5xQHPnBI15NMbQ4uKHqWdqSPokvPFHJYg=; b=FoBv4Kq0FE1AtbOlooLqgnoFsYqCwp1EFsAcLNcsy2H+AW2tVOcqBLhx uvxHH6/A1gGS96YxpDR7Gleo7kWyRK3sbylGgz1R8iJtZs6I35rqcff+I 0VSDqTn8nT+D5BtCFePSB2sh0+/enXepg+xLiFbn5Ut9GUmoVH96y7tSa I=; X-Files: signature.asc : 486 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DsBACQohZV/4wNJK1cgwZSWoMQwHCBR4V9AoEpOBQBAQEBAQEBfIQUAQEBAwEOFUITBgsLBBQJFgsCAgkDAgECAUUGAQwIAQGIIwiyL5oLAQEBAQEBAQMBAQEBAQEBARqLIYR8gmiBRQEEkjiBMVSFf4FVhS6NJiKCAhyBbCIxgkMBAQE X-IronPort-AV: E=Sophos;i="5.11,484,1422921600"; d="asc'?scan'208,217";a="136123098" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-8.cisco.com with ESMTP; 28 Mar 2015 12:50:26 +0000 Received: from [10.86.242.96] (che-vpn-cluster-2-96.cisco.com [10.86.242.96]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t2SCoPSg021046; Sat, 28 Mar 2015 12:50:25 GMT Message-ID: <5516A38B.5020005@cisco.com> Date: Sat, 28 Mar 2015 08:50:19 -0400 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Christian Huitema , "'Stephen Farrell'" , dan@geer.org, "'Ted Lemon'" , "'Joseph Lorenzo Hall'" , "'perpass'" References: <20150327021140.9EB45228181@palinka.tinho.net> <5514C3A3.4080107@cs.tcd.ie> <55161B3D.5010604@cisco.com> <004001d0690e$dd65cf80$98316e80$@huitema.net> In-Reply-To: <004001d0690e$dd65cf80$98316e80$@huitema.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="hFBF65DDCUKj4s5IQXq1eM185sKXG1FqA" Archived-At: Subject: Re: [perpass] https.CIO.gov X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "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, 28 Mar 2015 12:50:30 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --hFBF65DDCUKj4s5IQXq1eM185sKXG1FqA Content-Type: multipart/alternative; boundary="------------070709070601040800080504" This is a multi-part message in MIME format. --------------070709070601040800080504 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Christian, On 3/28/15 12:22 AM, Christian Huitema wrote: > > The author's point is that the state, with proper warrants, should be > able to conduct searches for evidence of crimes. Yes. > While this is a reasonable argument, it does not follow that people > should not have the right to protect their communications. Yes. > For example, there is no mandate anywhere that people should keep a > copy of their private letters in some kind of archive, so that they > could later be found when the police asks for it. But if they *did* keep a copy they could be compelled to reveal it if the state had probable cause or a warrant. The technology to actually retain copies was beyond the horizon of the framers. > And there is definitely no expectation that all our private > communications should be copied and archived by the state.=20 Unless the state has a warrant or probable cause. > And I am pretty sure that there was no such expectation among the > authors of the US constitution and Bill of Rights. We'll never know, but they left a very strong hint in the 4th amendment that they would indeed seek an appropriate balance of rights, as the Massachusetts Compromise shows the Bill of Rights was hotly debated between federalists and anti-federalists. When we get beyond the United States, of course, different societies have different views about All Of This. Eliot --------------070709070601040800080504 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Christian,

On 3/28/15 12:22 AM, Christian Huitema wrote:

The author's point is that the state, with proper warrants, should be able to conduct searches for evidence of crimes.

Yes.

While this is a reasonable argument, it does not follow that people should not have the right to protect their communications.

Yes.

For example, there is no mandate anywhere that people should keep a copy of their private letters in some kind of archive, so that they could later be found when the police asks for it.

But if they did keep a copy they could be compelled to reveal it if the state had probable cause or a warrant.=C2=A0 The technology to actually retain copies was beyond the horizon of the framers.

And there is definitely no expectation tha= t all our private communications should be copied and archived by the state.

Unless the state has a warrant or probable cause.

And I am pretty sure that there was no such= expectation among the authors of the US constitution and Bill of Rights.

We'll never know, but they left a very strong hint in the 4th amendment that they would indeed seek an appropriate balance of rights, as the Massachusetts Compromise shows the Bill of Rights was hotly debated between federalists and anti-federalists.

When we get beyond the United States, of course, different societies have different views about All Of This.

Eliot

--------------070709070601040800080504-- --hFBF65DDCUKj4s5IQXq1eM185sKXG1FqA 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.9 (Darwin) iQEcBAEBAgAGBQJVFqOQAAoJEIe2a0bZ0noz2OIIAMG21HXLj6PmZA7eFhebqwh1 YtM4VQoo/vcwFeVDXoH9MbbT1mnLw91QECBZMA2zeCc5y2YKpU4PvkB7dFJ2m+Xb FvyuGLHvX9X+Ng+Vbrtj2W5G5LCJHHD6wSnL31BwgqgaTsoam/3GqNZFc5SxMd9R Phdh3xnWnil6zoM+OfOPNd27J4mr6woQK/aM45o0/OjPmIqXat5AHcIJPDjE4Y1o 0m6Slsd1S093nATQxs+Rp5lNnFnYjNWApPbCU6uGmB7xM7xyz36EhlnTwW1ahIcB 4a4CBT6jZbKTgRC7msLIaWjGJJb/jV1nYv8F6bq66f0XDmDO52FukNcRCK1yMBA= =YP1I -----END PGP SIGNATURE----- --hFBF65DDCUKj4s5IQXq1eM185sKXG1FqA-- From nobody Sat Mar 28 06:39:21 2015 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26C111A87BA for ; Sat, 28 Mar 2015 06:39:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.31 X-Spam-Level: X-Spam-Status: No, score=-2.31 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-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 6VrYN0Bf4xS2 for ; Sat, 28 Mar 2015 06:39:13 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8B1E1A8797 for ; Sat, 28 Mar 2015 06:39:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C42A2BEB1; Sat, 28 Mar 2015 13:39:06 +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 8InErtQ6Bt9q; Sat, 28 Mar 2015 13:39:04 +0000 (GMT) Received: from [127.0.0.1] (unknown [31.221.87.78]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 16483BEAF; Sat, 28 Mar 2015 13:39:04 +0000 (GMT) X-Priority: 3 To: lear@cisco.com From: stephen.farrell@cs.tcd.ie In-Reply-To: <55161B3D.5010604@cisco.com> References: <20150327021140.9EB45228181@palinka.tinho.net> <5514C3A3.4080107@cs.tcd.ie> <55161B3D.5010604@cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Date: Sat, 28 Mar 2015 13:39:02 +0000 Message-ID: MIME-Version: 1.0 Archived-At: Cc: perpass@ietf.org, dan@geer.org, Ted.Lemon@nominum.com, joe@cdt.org Subject: Re: [perpass] https.CIO.gov X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "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, 28 Mar 2015 13:39:15 -0000 RWxpb3QgDQoNCk9uIFNhdCBNYXIgMjggMDM6MDg6NDUgMjAxNSBHTVQsIEVsaW90IExlYXIgd3Jv dGU6DQo+IEhpLA0KPiANCj4gSXQgc2VlbXMgdG8gbWUgdGhhdCBoYXZpbmcgYW4gaG9uZXN0IGRp c2N1c3Npb24gYWJvdXQgb3VyIGJpYXNlcywgZ29hbHMsDQo+IGFuZCBhc3N1bXB0aW9ucyBtaWdo dCBoZWxwLg0KPiANCj4gTXkgZ29hbDogSSB3YW50IHRoZSBJbnRlcm5ldCB0byBjb250aW51ZSB0 byBncm93IGluIGEgc2FmZSB3YXkuICBJdA0KPiBjYW4ndCBkbyB0aGF0IGlmIHBlb3BsZSBkb24n dCB0cnVzdCB0aGUgaW5mcmFzdHJ1Y3R1cmUuICBUaGVyZSBhcmUgRVUNCj4gc3R1ZGllcyB0aGF0 IGRpc2N1c3Mgd2hhdCBoYXBwZW5zIHdoZW4gcGVvcGxlIGV4cGVyaWVuY2Ugc29tZSBmb3JtIG9m DQo+IGhhcm0gb24gdGhlIEludGVybmV0LlsxXSAgRW5jcnlwdGlvbiBoYXMgcGxheWVkIGEgcm9s ZSBpbiByZWR1Y2luZyB0aGF0DQo+IGhhcm0uICBCdXQgaXQgY2FuIGFsc28gaW5jcmVhc2UgaGFy bSBmb3IgdGhlIHZlcnkgcmVhc29ucyBzdGF0ZWQgaW4gdGhhdA0KPiBhcnRpY2xlLiAgTm90IGFj a25vd2xlZGdpbmcgdGhpcyB3b3VsZCBiZSBhYnN1cmQuDQo+IA0KPiBQbGVhc2Ugbm93IHNlZSBi ZWxvdy4NCj4gDQo+IE9uIDMvMjYvMTUgOTo0MiBQTSwgU3RlcGhlbiB3cm90ZToNCj4gDQo+ID4+ IEJldHRlciBzYWlkLCBhbmQgYXQgZWZmZWN0aXZlIGxlbmd0aCwgYnkgRGF2aWQgR29sdW1iaWEN Cj4gPj4NCj4gPj4gICAgT3B0LU91dCBDaXRpemVuc2hpcDogRW5kLXRvLUVuZCBFbmNyeXB0aW9u IGFuZA0KPiA+PiAgICBDb25zdGl0dXRpb25hbCBHb3Zlcm5hbmNlDQo+ID4+ICAgIGh0dHA6Ly93 d3cudW5jb21wdXRpbmcub3JnLz9wPTI3Mg0KPiA+IEhhZCBhIHF1aWNrIGZsaWNrLiBBcmd1bWVu dHMgYmFzZWQgb24gYSBwcmVzdW1wdGlvbiBvZiAicGVyZmVjdA0KPiA+IGVuZC10by1lbmQgZW5j cnlwdGlvbiIgYXJlIHV0dGVybHkgdXNlbGVzcyBhcyB0aGV5IGFyZSBjb3VudGVyZmFjdHVhbC4N Cj4gPiBBbnl0aGluZyBvbmUgbGlrZXMgY2FuIGZvbGxvdyBmcm9tIGEgZmFsc2UgYXNzdW1wdGlv biBsaWtlIHRoYXQuDQo+ID4NCj4gDQo+IExldCBtZSBzZWUgaWYgSSB1bmRlcnN0YW5kIHRoaXMg c3RhdGVtZW50IGNvcnJlY3RseTogdGhpcyBncm91cCBpcw0KPiB3b3JraW5nIHRvd2FyZCBhIHdv cmxkIGluIHdoaWNoIHdlIGVuY3J5cHQgb3VyIGNvbW11bmljYXRpb25zLCBhbmQgd2hlbg0KPiBz b21lb25lIGRpc2N1c3NlcyB3aGF0IHRoYXQgd29ybGQgbWlnaHQgbG9vayBsaWtlLCB5b3UgY2xh aW0gaXQncw0KPiAiY291bnRlcmZhY3R1YWwiPyAgVGhhdCdzIG5vdCBhIHJlYXNvbmFibGUgYXJn dW1lbnQuDQoNCldlIGRpc2FncmVlLiBBbGwgYXJndW1lbnRzIG9mIHRoZSBmb3JtICJ0aGUgKnBl cmZlY3QqIHRoaW5nIEkgZGlzbGlrZSBoYXMgdGhpcyBkb3duc2lkZSIgYXJlIGJvZ3VzLiBBbmQg d2Ugc2ltcGx5IGRvIG5vdCAoeWV0KSBrbm93IGhvdyBob3cgZG8gZG8gZXZlbiBpbXBlcmZlY3Qg YnV0IHVzYWJsZSBlMmUgc2VjdXJpdHkgZm9yIGludGVycGVyc29uYWwgbWVzc2FnaW5nIGF0IHNj YWxlLiBUaGUgYXJ0aWNsZSBpcyBmYXRhbGx5IGZsYXdlZC4NCg0KUy4NCiANCg0KPiANCj4gVGVk IGNsYWltcyB0aGF0IHRoZSBhdXRob3IgYXJndWVzIHRoYXQgdGhlcmUgaXMgbm8gbmVlZCBmb3Ig YSByaWdodCB0bw0KPiBwcml2YWN5LiAgSSBkaWRuJ3QgcmVhZCB0aGF0IGluIHRoZSBhcnRpY2xl IGF0IGFsbCwgYnV0IHJhdGhlciB0aGF0IHRoZQ0KPiBDb25zdGl0dXRpb24gbXVzdCBiZSB0YWtl biBhcyBhIHdob2xlOiB0aGUgc2FtZSBkb2N1bWVudCB0aGF0IHByb3RlY3RzDQo+IG91ciByaWdo dHMgYWxzbyBwcm92aWRlcyB2YXJpb3VzIGJhbGFuY2luZyB0ZXN0cyB0byBwcm90ZWN0IHRoZSBy aWdodHMNCj4gb2Ygb3RoZXJzLg0KPiANCj4gT24gdGhlIG90aGVyIGhhbmQsIHRoZSBwaWVjZSBt aXNzaW5nIGZyb20gdGhhdCBhcnRpY2xlIGlzIHRoZSBuZWVkIGZvcg0KPiBjb25maWRlbmNlIGlu IHRoZSBpbmZyYXN0cnVjdHVyZSwgYW5kIFRlZCBnb2VzIGluIHRoaXMgZGlyZWN0aW9uOiBpZiB5 b3UNCj4gZ2l2ZSB0aGUgZ29vZCBndXlzIG1lYW5zIHRvIGdhaW4gYWNjZXNzIHRvIGNvbW11bmlj YXRpb25zLCBpbiBhbGwNCj4gbGlrZWxpaG9vZCB5b3UncmUgZ2l2aW5nIHRoZSBiYWQgZ3V5cyB0 aG9zZSB2ZXJ5IHNhbWUgY2FwYWJpbGl0aWVzLiANCj4gVGhhdCBoYXMgYmVlbiB0aGUgY29ybmVy c3RvbmUgb2YgdGhlIElFVEYgcG9zaXRpb24gZm9yIGEgdmVyeSBsb25nIHRpbWUsDQo+IGFuZCBp dCBob2xkcyBmb3Igd2hhdGV2ZXIgZGVmaW5pdGlvbiBvZiAiZ29vZCBndXlzIiBhbmQgImJhZCBn dXlzIiB5b3UNCj4gbWlnaHQgaGF2ZS4gIFdlYWtlbmluZyBlbmQtdG8tZW5kIGVuY3J5cHRpb24g d2Vha2VucyBjb25maWRlbmNlIGluIHRoZQ0KPiBpbmZyYXN0cnVjdHVyZS4gIFRoaXMgZ3V5IGRv ZXNuJ3QgY2FyZSBiZWNhdXNlIGhpcyBmb2N1cyBpcyBhYm91dCB0aGUNCj4gYmFsYW5jZSBvZiBu ZWVkcyBmcm9tIGEgbGVnYWwgc2Vuc2UuICBCdXQgdGhlc2UgaXNzdWVzIGNhbm5vdCBiZSB2aWV3 ZWQNCj4gaW4gaXNvbGF0aW9uIGZyb20gb25lIGFub3RoZXIuDQo+IA0KPiBFbGlvdA0KPiBbMV0g UmllaywgZXQuIGFsLCAvVW5kZXJzdGFuZGluZyB0aGUgSW5mbHVlbmNlIG9mIEN5YmVyY3JpbWUg UmlzayBvbiB0aGUNCj4gRS1TZXJ2aWNlIEFkb3B0aW9uIG9mIEV1cm9wZWFuIEludGVybmV0IFVz ZXJzLywgV0VJUyAyMDE0LiANCj4gaHR0cDovL3dlaXMyMDE0LmVjb25pbmZvc2VjLm9yZy9wYXBl cnMvUmlla0JvZWhtZU1vb3JlLVdFSVMyMDE0LnBkZg0KPiANCj4= From nobody Sat Mar 28 07:00:35 2015 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AAB91A1BF8 for ; Fri, 27 Mar 2015 23:39:28 -0700 (PDT) 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, HELO_EQ_DK=1.009, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-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 DeTVqlfsVEZk for ; Fri, 27 Mar 2015 23:39:23 -0700 (PDT) Received: from spamfilter1.dtu.dk (spamfilter1.dtu.dk [130.225.73.112]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5B2E1A1B30 for ; Fri, 27 Mar 2015 23:39:22 -0700 (PDT) Received: from ait-pexedg01.win.dtu.dk (ait-pexedg01.win.dtu.dk [192.38.82.191]) by spamfilter1.dtu.dk with ESMTP id t2S6dF1J013694-t2S6dF1L013694 (version=TLSv1.0 cipher=AES128-SHA bits=128 verify=CAFAIL); Sat, 28 Mar 2015 07:39:15 +0100 Received: from ait-pex02mbx05.win.dtu.dk (192.38.82.185) by ait-pexedg01.win.dtu.dk (192.38.82.191) with Microsoft SMTP Server (TLS) id 14.3.224.2; Sat, 28 Mar 2015 07:39:26 +0100 Received: from ait-pex01mbx01.win.dtu.dk ([fe80::49f9:dd7a:cb60:3434]) by ait-pex02mbx05.win.dtu.dk ([fe80::5122:b451:7f84:8c28%16]) with mapi id 14.03.0224.002; Sat, 28 Mar 2015 07:40:36 +0100 From: Hugo Maxwell Connery To: "dan@geer.org" Thread-Topic: [perpass] https.CIO.gov Thread-Index: AQHQaDNccPqRicBUUEG97rnt79fKkZ0xbNBr Date: Sat, 28 Mar 2015 06:38:13 +0000 Message-ID: <6CB05D82CE245B4083BBF3B97E2ED47029463B@ait-pex01mbx01.win.dtu.dk> References: Your message of "Wed, 25 Mar 2015 10:11:14 -0700." <5512EC32.2030001@well.com>,<20150327021140.9EB45228181@palinka.tinho.net> In-Reply-To: <20150327021140.9EB45228181@palinka.tinho.net> Accept-Language: en-AU, da-DK, en-US Content-Language: en-AU X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.225.73.250] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Sat, 28 Mar 2015 07:00:32 -0700 Cc: "perpass@ietf.org" Subject: Re: [perpass] https.CIO.gov X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "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, 28 Mar 2015 06:39:28 -0000 Hi, Standard Fallacy: if communications are encrypted they cannot be read/obtai= ned. There are two places where 'encrypted' communications are viewable, at the sender and receiver. Thus, the government (or anyone) can obtain the communications by invading the sending or receiving system if either a plai= n-text of the message(s) or the key and cipher text are still obtainable on the de= vice. Metadata of the communication is often available in logs. The question is, under what circumstances should the government (or others) be able to do this? Recall that when people say 'encryption' what they usually mean is 'secure communication' and that means 3 things (CIA model): Confidentiality,=20 Integrity and Authenticity. =20 Sometimes only two of these properties are desired, and I suggest that we s= hould=20 be thinking about this. For example, a public forum wishes for integrity and authenticity but does not necessarily require confidentiality. No amount of digital 'secure communications' will prevent surveillance when an end-point device is compromised (e.g key logger). Additionally, current transport protocols include the addresses of the end-= points and thus expose the metadata of these connections to all locations in the=20 communications path, irrespective of 'secure communications'. =20 Thus, anonymity is another consideration that is entailed in these discussi= ons. -- Hugo Connery, Head of IT, DTU Environment, http://www.env.dtu.dk ________________________________________ From: perpass [perpass-bounces@ietf.org] on behalf of dan@geer.org [dan@gee= r.org] Sent: Friday, 27 March 2015 03:11 To: perpass@ietf.org Subject: Re: [perpass] https.CIO.gov Encryption everywhere all the time? No, thank you. Better said, and at effective length, by David Golumbia Opt-Out Citizenship: End-to-End Encryption and Constitutional Governance http://www.uncomputing.org/?p=3D272 --dan _______________________________________________ perpass mailing list perpass@ietf.org https://www.ietf.org/mailman/listinfo/perpass From nobody Sat Mar 28 07:09:59 2015 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A9B01A87E1 for ; Sat, 28 Mar 2015 07:09:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.31 X-Spam-Level: X-Spam-Status: No, score=-2.31 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-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 jpNeGUClep1J for ; Sat, 28 Mar 2015 07:09:57 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AF171A87D4 for ; Sat, 28 Mar 2015 07:09:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 6E80DBE8B; Sat, 28 Mar 2015 14:09: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 kbn8lpB-CXEb; Sat, 28 Mar 2015 14:09:54 +0000 (GMT) Received: from [10.32.65.98] (unknown [31.221.87.78]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id E7C91BEB1; Sat, 28 Mar 2015 14:09:53 +0000 (GMT) Message-ID: <5516B631.9050006@cs.tcd.ie> Date: Sat, 28 Mar 2015 14:09:53 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: dan@geer.org, Nicholas Weaver References: <20150328023614.251BE228164@palinka.tinho.net> In-Reply-To: <20150328023614.251BE228164@palinka.tinho.net> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: perpass@ietf.org Subject: Re: [perpass] https.CIO.gov X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "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, 28 Mar 2015 14:09:58 -0000 On 28/03/15 02:36, dan@geer.org wrote: > In a world where the deployment curve of the IoT > has a 17-month doubling time, who or what is going to do > the key management that you would actually believe in? I'm sorry but the article *you* quoted made just the opposite assumption (that doing "perfect" e2e crypto is possible) and now you want to argue the opposite side? (That it is not.) That's not IMO constructive. As to what we should be doing - we (participating in the IETF) should be (and I think are) doing the engineering to figure out if and how we can make the Internet more secure and privacy friendly without breaking it. Yes, there are unsolved problems there related to key management at scale and there are perhaps even more fundamental issues with privacy generally (in that we don't understand it nearly as well as other security things) but we ought not be trying to use both sides of arguments for what look to me like purely rhetorical purposes. Higher quality input is of course welcome. S. From nobody Sat Mar 28 07:58:02 2015 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 933201A889F for ; Sat, 28 Mar 2015 07:58:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.235 X-Spam-Level: X-Spam-Status: No, score=-3.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, GB_I_LETTER=-2, SPF_SOFTFAIL=0.665] 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 ZY7HDcsR72Bd for ; Sat, 28 Mar 2015 07:58:00 -0700 (PDT) Received: from resqmta-ch2-02v.sys.comcast.net (resqmta-ch2-02v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83B5B1A8881 for ; Sat, 28 Mar 2015 07:58:00 -0700 (PDT) Received: from resomta-ch2-10v.sys.comcast.net ([69.252.207.106]) by resqmta-ch2-02v.sys.comcast.net with comcast id 92xl1q0022JGN3p012xzva; Sat, 28 Mar 2015 14:57:59 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-10v.sys.comcast.net with comcast id 92xz1q00D3Ge9ey012xz76; Sat, 28 Mar 2015 14:57:59 +0000 Message-ID: <5516C176.7050608@alum.mit.edu> Date: Sat, 28 Mar 2015 10:57:58 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: perpass@ietf.org References: <20150327021140.9EB45228181@palinka.tinho.net> <5514C3A3.4080107@cs.tcd.ie> <55161B3D.5010604@cisco.com> <004001d0690e$dd65cf80$98316e80$@huitema.net> In-Reply-To: <004001d0690e$dd65cf80$98316e80$@huitema.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1427554679; bh=3k/hgaAOOIBjpJqdEPq90NIoXtgDWg71xCzOUfAfkpQ=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=wacaP5AQTJnzUiMMEOKBgNEZFehjXMESYdxtFvKSWoKkoWbXaqK825XSXgm0u7gMW e67VUAqNcDTavgIPQ+5gIqCL2+KFBa7mhV03EF94AXUjCiS5TUDTODPL6G7iU6QLOa 5+2GUJe+QmVLBt9poy8os4aUc13rI2CzPesoUDghMtuhK8T83vqjX0UyPBjvHErOTe I9bnAki7OLlBw40qLSOgTnO4RJaMafNG5AdldMNNYTbFBmVe5AD8J406JeYkLj0nfE 3eHcVJSr/KaPMARmymsjNkfX7q02hptByUtaoVYPGLSQ3upx/LFxgiME3c2V2FKgT9 n6Y2ZyFr6WKPg== Archived-At: Subject: Re: [perpass] https.CIO.gov X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "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, 28 Mar 2015 14:58:01 -0000 On 3/28/15 12:22 AM, Christian Huitema wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Friday, March 27, 2015 at 10:09 PM, Eliot Lear wrote: > >> Let me see if I understand this statement correctly: this group is working toward a world in which we encrypt our communications, and when someone discusses what that world might look like, you claim it's "counterfactual"? That's not a reasonable argument. >> Ted claims that the author argues that there is no need for a right to privacy. I didn't read that in the article at all, but rather that the Constitution must be taken as a whole: the same document that protects our rights also provides various balancing tests to protect the rights of others. > > The author's point is that the state, with proper warrants, should be able to conduct searches for evidence of crimes. While this is a reasonable argument, it does not follow that people should not have the right to protect their communications. For example, there is no mandate anywhere that people should keep a copy of their private letters in some kind of archive, so that they could later be found when the police asks for it. And there is definitely no expectation that all our private communications should be copied and archived by the state. And I am pretty sure that there was no such expectation among the authors of the US constitution and Bill of Rights. I also generally agree with this. The problem is that many non-technical proposals around this take it to mean that all communications should be blocked from being encrypted in a way that prevents presumed good actors from deciphering them. They fail to recognize that this will also allow bad actors to decipher them. Perhaps this can be addressed by focusing on the right of individuals to protect their communications from access by bad actors. (Even if this makes it more difficult for the "good" actors with warrants.) Thanks, Paul From nobody Sat Mar 28 22:38:52 2015 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 860151A9172 for ; Sat, 28 Mar 2015 22:38:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.035 X-Spam-Level: X-Spam-Status: No, score=-0.035 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 EUqXjyrnEP2n for ; Sat, 28 Mar 2015 22:38:49 -0700 (PDT) Received: from mail-qc0-f177.google.com (mail-qc0-f177.google.com [209.85.216.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A6DF1A916F for ; Sat, 28 Mar 2015 22:38:49 -0700 (PDT) Received: by qcfy6 with SMTP id y6so28111132qcf.2 for ; Sat, 28 Mar 2015 22:38:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:message-id:mime-version :subject:date:references:to:in-reply-to; bh=p5MzY8hmf68NArjbCsZBpgzTMiAOB8oyPKeBNhGI9VI=; b=dsUfMD5z1v7NxANbS9roTgN7SdCwaxXICdLoUoBuCFjlpwT+Jr8f1m4KdC1g61abMn 3dJCpqeZUbUMrVIsQ0gVSHIG3YJd6dUdkBBjyLRh3in2bzu9m4jxnhhhVY52EY2ojwIR jhj9KgN52byYAvLejLe0ANkrAljaTq1HgzeAmn9FZIhlLrM8hhteRLND0Pxoewcq3o70 bMuEDol97A+nTkFQjlDWC9sZ+FVvZahSodqRF0eElbXhBqWNXKvqdbSEbAeWI53QtVra iUKpT04Da7iPt22XF/QMs8zNquffMM9qEpQ+3blFBHXHbwhEktqpvDd1zV78xbRIIk+c YzTA== X-Gm-Message-State: ALoCoQnQ2pee6E3byMyyFmQIVypLhM2m3wJm+JJhfHl851GmeB13wEvqvzikoWJ9nMRIZpve2s9B X-Received: by 10.140.43.199 with SMTP id e65mr33471161qga.34.1427607528611; Sat, 28 Mar 2015 22:38:48 -0700 (PDT) Received: from [192.168.0.2] (cpe-158-222-146-11.nyc.res.rr.com. [158.222.146.11]) by mx.google.com with ESMTPSA id h6sm5160198qgf.14.2015.03.28.22.38.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 28 Mar 2015 22:38:47 -0700 (PDT) From: Seda Gurses Content-Type: multipart/alternative; boundary="Apple-Mail=_2D12B18D-11E4-4EFB-8A1F-F523336554EF" Message-Id: <59E1959A-B587-4B58-985A-D2CD8C2680C6@nyu.edu> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Date: Sun, 29 Mar 2015 01:38:45 -0400 References: To: perpass@ietf.org In-Reply-To: X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: Re: [perpass] perpass Digest, Vol 19, Issue 10 X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "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 Mar 2015 05:38:51 -0000 --Apple-Mail=_2D12B18D-11E4-4EFB-8A1F-F523336554EF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi everyone, I am following up on the discussion that was partially spurred by the = reference to the Golumbia article that argues against anonymous = communications as a universally accessible and acceptable service. I = agree with the issues that Golumbia has with respect to the unequally = distributed benefits of anonymous communications and absolutely = appreciate the engagement with the topic. Technically speaking, however, = I find his position uninformed and his legal analysis too short to do = justice to the issue. What is maybe worse is that his points are = uncomfortably aligned with the =93going dark=94 argument [0]: a popular = argument that is especially dubious when more private and public data is = available to law enforcement and government agencies than ever and the = number of non-commercial civilian use of encryption and anonymous = communications is abysmal. The latter is one important reason why = addressing privacy in standards is key. Having said that, the interaction between privacy laws and privacy = enhancing technologies is complex and worthy of further discussion. In = [1] you will find an outdated but hopefully still useful paper on this = topic. Also in that article is a distinction between types of PETs based = on the role of the service provider, which you may appreciate. Cheers, seda [0] Going Dark by James Comey = http://www.fbi.gov/news/speeches/going-dark-are-technology-privacy-and-pub= lic-safety-on-a-collision-course [1] Hero or Villain: The Data Controller in Privacy Law and = Technologies, Claudia Diaz, Omer Tene, Seda Gurses https://www.cosic.esat.kuleuven.be/publications/article-2365.pdf Constitutional privacy law in Europe and the United States = establishes the right to privacy as freedom from government = surveillance. It is based on suspicion of power and distrust in the = state, which can unleash ominous intrusions into the private sphere to = crush dissent and stifle democratic discourse and free speech. Over the = past forty years, an additional legal framework has emerged to protect = information privacy. Yet unlike the constitutional framework, = information privacy law provides little protection against the risk of = surveillance by either governments or private sector entities. Indeed, = such organizations are assumed by law to be trusted entities acting as = stewards of individuals=92 rights, essentially =93information = fiduciaries.=94 This Article demonstrates that an analysis of the assumptions and = principles underlining privacy enhancing technologies (PETs) highlights = the gap between the constitutional and information privacy frameworks. = It argues that by embracing PETs, information privacy law can = recalibrate to better protect individuals from surveillance and unwanted = intrusions into their private lives. Conversely, if the law continues on = its current trajectory, emphasizing organizational accountability and = marginalizing data minimization and transparency, PETs would become = unviable and individuals subject to increasingly stifling digital = oversight. >=20 > From: Hugo Maxwell Connery > Subject: Re: [perpass] https.CIO.gov > Date: March 28, 2015 at 2:38:13 AM EDT > To: "dan@geer.org" > Cc: "perpass@ietf.org" >=20 >=20 > Hi, >=20 > Standard Fallacy: if communications are encrypted they cannot be = read/obtained. >=20 > There are two places where 'encrypted' communications are viewable, at > the sender and receiver. Thus, the government (or anyone) can obtain = the > communications by invading the sending or receiving system if either a = plain-text > of the message(s) or the key and cipher text are still obtainable on = the device. > Metadata of the communication is often available in logs. >=20 > The question is, under what circumstances should the government (or = others) > be able to do this? >=20 > Recall that when people say 'encryption' what they usually mean is = 'secure > communication' and that means 3 things (CIA model): Confidentiality,=20= > Integrity and Authenticity. =20 >=20 > Sometimes only two of these properties are desired, and I suggest that = we should=20 > be thinking about this. For example, a public forum wishes for = integrity > and authenticity but does not necessarily require confidentiality. >=20 > No amount of digital 'secure communications' will prevent surveillance = when > an end-point device is compromised (e.g key logger). >=20 > Additionally, current transport protocols include the addresses of the = end-points > and thus expose the metadata of these connections to all locations in = the=20 > communications path, irrespective of 'secure communications'. =20 >=20 > Thus, anonymity is another consideration that is entailed in these = discussions. > -- > Hugo Connery, Head of IT, DTU Environment, http://www.env.dtu.dk > ________________________________________ > From: perpass [perpass-bounces@ietf.org] on behalf of dan@geer.org = [dan@geer.org] > Sent: Friday, 27 March 2015 03:11 > To: perpass@ietf.org > Subject: Re: [perpass] https.CIO.gov >=20 > Encryption everywhere all the time? No, thank you. >=20 > Better said, and at effective length, by David Golumbia >=20 > Opt-Out Citizenship: End-to-End Encryption and > Constitutional Governance > http://www.uncomputing.org/?p=3D272 >=20 >=20 > --dan >=20 > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass >=20 >=20 >=20 --Apple-Mail=_2D12B18D-11E4-4EFB-8A1F-F523336554EF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

Hi = everyone,

I am following up on the discussion = that was partially spurred by the reference to the Golumbia article that = argues against anonymous communications as a universally accessible and = acceptable service. I agree with the issues that Golumbia has with = respect to the unequally distributed benefits of anonymous = communications and absolutely appreciate the engagement with the topic. = Technically speaking, however, I find his position uninformed and his = legal analysis too short to do justice to the issue. What is maybe worse = is that his points are uncomfortably aligned with the =93going dark=94 = argument [0]: a popular argument that is especially dubious when more = private and public data is available to law enforcement and government = agencies than ever and the number of non-commercial civilian use of = encryption and anonymous communications is abysmal. The latter is one = important reason why addressing privacy in standards is = key.

Having said that, the interaction between = privacy laws and privacy enhancing technologies is complex and worthy of = further discussion. In [1] you will find an outdated but hopefully still = useful paper on this topic. Also in that article is a distinction = between types of PETs based on the role of the service provider, which = you may = appreciate.
Cheers,
seda


=



[1] Hero or Villain: The Data = Controller in Privacy Law and Technologies, Claudia Diaz, Omer Tene, = Seda Gurses
=

= Constitutional privacy law in Europe and the United States = establishes the right to privacy as freedom from government = surveillance. It is based on suspicion of power and distrust in the = state, which can unleash ominous intrusions into the private sphere to = crush dissent and stifle democratic discourse and free speech. Over the = past forty years, an additional legal framework has emerged to protect = information privacy. Yet unlike the constitutional framework, = information privacy law provides little protection against the risk of = surveillance by either governments or private sector entities. Indeed, = such organizations are assumed by law to be trusted entities acting as = stewards of individuals=92 rights, essentially =93information = fiduciaries.=94

This Article demonstrates that an analysis of the = assumptions and principles underlining privacy enhancing technologies = (PETs) highlights the gap between the constitutional and information = privacy frameworks. It argues that by embracing PETs, information = privacy law can recalibrate to better protect individuals from = surveillance and unwanted intrusions into their private lives. = Conversely, if the law continues on its current trajectory, emphasizing = organizational accountability and marginalizing data minimization and = transparency, PETs would become unviable and individuals subject to = increasingly stifling digital = oversight.



<= br>




=

From: Hugo = Maxwell Connery <hmco@env.dtu.dk>
Subject: Re: [perpass] https.CIO.gov
Date: March 28, 2015 at 2:38:13 AM = EDT
=

Hi,

Standard Fallacy: if communications are encrypted = they cannot be read/obtained.

There are two places where = 'encrypted' communications are viewable, at
the sender and receiver. =  Thus, the government (or anyone) can obtain the
communications = by invading the sending or receiving system if either a plain-text
of = the message(s) or the key and cipher text are still obtainable on the = device.
Metadata of the communication is often available in = logs.

The question is, under what circumstances should the = government (or others)
be able to do this?

Recall that when = people say 'encryption' what they usually mean is = 'secure
communication' and that means 3 things (CIA model): = Confidentiality,
Integrity and Authenticity.  

Sometimes = only two of these properties are desired, and I suggest that we should =
be thinking about this.  For example, a public forum wishes for = integrity
and authenticity but does not necessarily require = confidentiality.

No amount of digital 'secure communications' = will prevent surveillance when
an end-point device is compromised = (e.g key logger).

Additionally, current transport protocols = include the addresses of the end-points
and thus expose the metadata = of these connections to all locations in the
communications path, = irrespective of 'secure communications'.  

Thus, anonymity = is another consideration that is entailed in these = discussions.
--
Hugo Connery, Head of IT, DTU Environment, http://www.env.dtu.dk
______________= __________________________
From: perpass [perpass-bounces@ietf.org] = on behalf of dan@geer.org [dan@geer.org]
Sent: Friday, 27 March = 2015 03:11
To: perpass@ietf.org
Subject: Re: = [perpass] https.CIO.gov

Encryption = everywhere all the time?  No, thank you.

Better said, and at = effective length, by David Golumbia

  Opt-Out = Citizenship: End-to-End Encryption and
  Constitutional = Governance
  http://www.uncomputing.org/?p= =3D272


--dan

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




= = --Apple-Mail=_2D12B18D-11E4-4EFB-8A1F-F523336554EF-- From nobody Sun Mar 29 14:14:54 2015 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F7FA1A1A76 for ; Sun, 29 Mar 2015 14:14:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.5 X-Spam-Level: X-Spam-Status: No, score=-3.5 tagged_above=-999 required=5 tests=[BAYES_50=0.8, GB_I_LETTER=-2, 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 bZ7W6jsWPko3 for ; Sun, 29 Mar 2015 14:14:52 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3934C1A1A52 for ; Sun, 29 Mar 2015 14:14:52 -0700 (PDT) Received: from [192.168.1.141] (104-60-96-29.lightspeed.sntcca.sbcglobal.net [104.60.96.29]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id t2TLE1Uh023039 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 29 Mar 2015 14:14:04 -0700 Message-ID: <55186B16.5010109@dcrocker.net> Date: Sun, 29 Mar 2015 14:13:58 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Eliot Lear , Christian Huitema , "'Stephen Farrell'" , dan@geer.org, "'Ted Lemon'" , "'Joseph Lorenzo Hall'" , "'perpass'" References: <20150327021140.9EB45228181@palinka.tinho.net> <5514C3A3.4080107@cs.tcd.ie> <55161B3D.5010604@cisco.com> <004001d0690e$dd65cf80$98316e80$@huitema.net> <5516A38B.5020005@cisco.com> In-Reply-To: <5516A38B.5020005@cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Sun, 29 Mar 2015 14:14:08 -0700 (PDT) Archived-At: Subject: Re: [perpass] https.CIO.gov 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: Sun, 29 Mar 2015 21:14:53 -0000 On 3/28/2015 5:50 AM, Eliot Lear wrote: >> For example, there is no mandate anywhere that people should keep a >> copy of their private letters in some kind of archive, so that they >> could later be found when the police asks for it. > > But if they *did* keep a copy they could be compelled to reveal it if > the state had probable cause or a warrant. The technology to actually > retain copies was beyond the horizon of the framers. And it should be noted that compelling disclosure in this way is fundamentally different from prohibiting/defeating protection against lesser efforts. That is, being required to produce encryption keys is not the same as being required to use encryption that does not provide serious protection. (A backdoor is an example of not being serious.) This is probably obvious, but I think it worth noting, since I see it at the core of the encrypt-everything/don't-allow-it debate. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net