From lynx@lo.psyced.org Sun Oct 5 07:54:25 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62B271A02EE for ; Sun, 5 Oct 2014 07:54:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.014 X-Spam-Level: X-Spam-Status: No, score=0.014 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.786] 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 bSTguVW6D1ol for ; Sun, 5 Oct 2014 07:54:23 -0700 (PDT) Received: from lo.psyced.org (lost.IN.psyced.org [188.40.42.221]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 406151A02EC for ; Sun, 5 Oct 2014 07:54:22 -0700 (PDT) Received: from lo.psyced.org (localhost [127.0.0.1]) by lo.psyced.org (8.14.3/8.14.3/Debian-9.4) with ESMTP id s95EsSi0026945 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 5 Oct 2014 16:54:29 +0200 Received: (from lynx@localhost) by lo.psyced.org (8.14.3/8.14.3/Submit) id s95EsSYj026944 for perpass@ietf.org; Sun, 5 Oct 2014 16:54:28 +0200 Date: Sun, 5 Oct 2014 16:54:27 +0200 From: lynX@youfixtheinternet.psyced.org To: perpass@ietf.org Message-ID: <20141005145427.GA26001@lo.psyced.org> References: <20140828160043.76ae962f@latte.josefsson.org> <5420A2A9.4030504@leap.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5420A2A9.4030504@leap.se> User-Agent: Mutt/1.5.20 (2009-06-14) Archived-At: http://mailarchive.ietf.org/arch/msg/perpass/uxspFg6wQbRubOIUSxjQk69X4ns Subject: Re: [perpass] OpenPGP mail/news header X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "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, 05 Oct 2014 15:16:05 -0000 On Mon, Sep 22, 2014 at 03:28:57PM -0700, Elijah Sparrow wrote: > I am excited to see that you have resumed work on this. There are a ton > of projects working on new forms of 'easy' secure email, and they are > all experimenting with, or planning to experiment with, new forms of key > discovery and validation [1]. The nearly universal goal is automatic key > management without the need for user intervention. Please update your https://github.com/OpenTechFund/secure-email document to also reflect the methods more advanced developers would choose. Currently it only shows a list of the LEAP methods while leaving out the following which to my understanding of the matter are a lot more like to get established in real world practice: 1. adopting new people from a trusted person's social vicinity (that is: using a social networking model) 2. using a graphic depiction of the public key (usually QR codes) printed on business cards or brochures 3. bringing end devices into bluetooth range of each other None of these methods require OpenPGP or SMTP. Instead a distributed open social networking platform is needed. Several projects are working on that, as it is the long-term reasonable solution - handling not just email and messaging but also social interaction appropriately. After all it's a bit pointless to spend all this effort in improving email while millions of people are flocking away to Facebook, Whatsapp and other PRISM platforms. We need a replacement for proprietary social interaction modeling, not cumbersome metadata-insecure mail systems. -- http://youbroketheinternet.org ircs://psyced.org/youbroketheinternet From nobody Mon Oct 6 03:12:38 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCACA1A1B85 for ; Mon, 6 Oct 2014 03:12:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.336 X-Spam-Level: X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, RP_MATCHES_RCVD=-0.786] 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 SNPPBsk3HcmF for ; Mon, 6 Oct 2014 03:12:34 -0700 (PDT) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2671C1A1B83 for ; Mon, 6 Oct 2014 03:12:34 -0700 (PDT) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id DD2D02801A0 for ; Mon, 6 Oct 2014 12:12:31 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx4.nic.fr (Postfix) with ESMTP id D8203280181 for ; Mon, 6 Oct 2014 12:12:31 +0200 (CEST) Received: from bortzmeyer.nic.fr (unknown [IPv6:2001:67c:1348:7::86:133]) by relay2.nic.fr (Postfix) with ESMTP id D69BFB3800C for ; Mon, 6 Oct 2014 12:12:01 +0200 (CEST) Date: Mon, 6 Oct 2014 12:12:01 +0200 From: Stephane Bortzmeyer To: perpass@ietf.org Message-ID: <20141006101201.GA17335@nic.fr> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="u3/rZRmxL6MmkK24" Content-Disposition: inline Content-Transfer-Encoding: 8bit X-Operating-System: Debian GNU/Linux jessie/sid X-Kernel: Linux 3.16-2-686-pae i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/perpass/Vp7Kwe39vckl6ohONLW9E-DO5a0 Subject: [perpass] [iesg-secretary@ietf.org: WG Review: DNS PRIVate Exchange (dprive)] X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "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, 06 Oct 2014 10:12:37 -0000 --u3/rZRmxL6MmkK24 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline This is relevant for this list. (But note the comments are to be sent to IESG.) --u3/rZRmxL6MmkK24 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 8bit Return-Path: ietf-announce-bounces@ietf.org Received: from hebe.prod-int.prive.th3.nic.fr [10.1.81.80] by batilda.nic.fr with IMAP (fetchmail-6.3.26) for (single-drop); Fri, 03 Oct 2014 19:40:58 +0200 (CEST) Received: from hebe.prod-int.prive.th3.nic.fr (LHLO zimbra.afnic.fr) (10.1.81.80) by zimbra.afnic.fr with LMTP; Fri, 3 Oct 2014 19:39:32 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.afnic.fr (Postfix) with ESMTP id 2FD668C8002 for ; Fri, 3 Oct 2014 19:39:32 +0200 (CEST) X-Virus-Scanned: amavisd-new at zimbra.afnic.fr X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-10 required=6.6 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=unavailable Authentication-Results: zimbra.afnic.fr (amavisd-new); dkim=pass header.i=@ietf.org Received: from zimbra.afnic.fr ([127.0.0.1]) by localhost (zimbra.afnic.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ZRgW0BgbwZy for ; Fri, 3 Oct 2014 19:39:28 +0200 (CEST) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by zimbra.afnic.fr (Postfix) with ESMTP id 4DECC8C8005 for ; Fri, 3 Oct 2014 19:39:28 +0200 (CEST) Received: by relay1.nic.fr (Postfix) id 4B01F4C007C; Fri, 3 Oct 2014 19:39:28 +0200 (CEST) Delivered-To: bortzmeyer@nic.fr Received: from mx5.nic.fr (mx5.nic.fr [IPv6:2001:67c:2218:2::4:13]) by relay1.nic.fr (Postfix) with ESMTP id 4A4E54C0029; Fri, 3 Oct 2014 19:39:28 +0200 (CEST) Received: from mx5.nic.fr (localhost [127.0.0.1]) by mx5.nic.fr (Postfix) with SMTP id 3F4DC300180; Fri, 3 Oct 2014 19:39:28 +0200 (CEST) Received: by mx5.nic.fr (Postfix, from userid 1137) id 1C2E13002D9; Fri, 3 Oct 2014 19:39:28 +0200 (CEST) Received: from mail.ietf.org (mail.ietf.org [4.31.198.44]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx5.nic.fr (Postfix) with ESMTPS id B614E300180; Fri, 3 Oct 2014 19:39:27 +0200 (CEST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A07D81A87BA; Fri, 3 Oct 2014 10:38:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1412357922; bh=ehJTjheiy6U0hxxGfs5ol58d1Q7VwJAUKUvj3maE+AA=; h=Content-Type:MIME-Version:Content-Transfer-Encoding:From:To: Subject:Message-ID:Date:Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:Sender; b=O0t7MnegHTBPVKrV8mQmHrmtYypOfRG2EfYqwhG6Fz6QFxWYUTsRTjcPD3prTxl/g RHd1jO9QqrVg/D2kwAytrNQN3MtCERvAuhlUOyD9g5FHwcI0jiiQHbJYuntRkXE8Xk jgPbqc2INOQlrxkCQDiP9z0EsJQyNQ3qavy0Vp5A= X-Original-To: ietf-announce@ietfa.amsl.com Delivered-To: ietf-announce@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A47841A87AF for ; Fri, 3 Oct 2014 10:38:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9wLqiESth4Mz for ; Fri, 3 Oct 2014 10:38:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 36B1C1A87AC for ; Fri, 3 Oct 2014 10:38:35 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Old-From: The IESG To: IETF-Announce Old-Subject: WG Review: DNS PRIVate Exchange (dprive) X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141003173835.19627.6784.idtracker@ietfa.amsl.com> Date: Fri, 03 Oct 2014 10:38:35 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/ietf-announce/VGGFOMLLqK-_5ZgycK9NgRdhSx8 X-BeenThere: ietf-announce@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: "IETF announcement list. No discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ietf-announce-bounces@ietf.org Sender: "IETF-Announce" X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.10.3.173319 X-PerlMx-Spam: Gauge=IIIIIIII, Probability=8%, Report=' HTML_00_01 0.05, HTML_00_10 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_2000_2999 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, DATE_TZ_NA 0, DKIM_SIGNATURE 0, __ANY_URI 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __FRAUD_PROPOSE 0, __HAS_FROM 0, __HAS_LIST_HEADER 0, __HAS_LIST_HELP 0, __HAS_LIST_SUBSCRIBE 0, __HAS_LIST_UNSUBSCRIBE 0, __HAS_MSGID 0, __HAS_REPLYTO 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __REPLYTO_SAMEAS_FROM_DOMAIN 0, __SANE_MSGID 0, __TO_MALFORMED_2 0, __URI_NO_PATH 0, __URI_NO_WWW 0, __URI_NS ' X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Subject: WG Review: DNS PRIVate Exchange (dprive) From: The IESG A new IETF working group has been proposed in the Internet Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by 2014-10-13. DNS PRIVate Exchange (dprive) ------------------------------------------------ Current Status: Proposed WG Assigned Area Director: Brian Haberman Charter: The DNS PRIVate Exchange (DPRIVE) Working Group develops mechanisms to provide confidentiality to DNS transactions, to address concerns surrounding pervasive monitoring (RFC 7258). The set of DNS requests that an individual makes can provide an attacker with a large amount of information about that individual. DPRIVE aims to deprive the attacker of this information. (The IETF defines pervasive monitoring as an attack [RFC7258]) The primary focus of this Working Group is to develop mechanisms that provide confidentiality between DNS Clients and Iterative Resolvers, but it may also later consider mechanisms that provide confidentiality between Iterative Resolvers and Authoritative Servers, or provide end-to-end confidentiality of DNS transactions. Some of the results of this working group may be experimental. DPRIVE is chartered to work on mechanisms that add confidentiality to the DNS. While it may be tempting to solve other DNS issues while adding confidentiality, DPRIVE is not the working group to do this. DPRIVE will not work on any integrity-only mechanisms. Examples of the sorts of risks that DPRIVE will address can be found in [draft-bortzmeyer-dnsop-dns-privacy], and include both passive wiretapping and more active attacks, such as MITM attacks. DPRIVE will address risks to end users’ privacy (for example, which websites an end user is accessing). Some of the main design goals (in no particular order) are: - Provide confidentiality to DNS transactions (for the querier). - Maintain backwards compatibility with legacy DNS implementations. - Require minimal application-level changes. - Require minimal additional configuration or effort from applications or users Milestones: Dec 2014 - WG LC on an problem statement document Mar 2015 - WG selects one or more primary protocol directions Jul 2015 - WG LC on primary protocol directions --u3/rZRmxL6MmkK24-- From nobody Tue Oct 7 09:35:24 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8051A1ACE3D for ; Tue, 7 Oct 2014 09:35:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.003 X-Spam-Level: X-Spam-Status: No, score=-0.003 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 t0u_w2w6mz9c for ; Tue, 7 Oct 2014 09:35:21 -0700 (PDT) Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) (using TLSv1.1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F097A1ACE3E for ; Tue, 7 Oct 2014 09:35:20 -0700 (PDT) X-Footer: Y2R0Lm9yZw== Received: from hypochilid-2.local ([199.119.118.21]) (authenticated user jhall@cdt.org) by mail.maclaboratory.net (using TLSv1 with cipher DHE-RSA-AES256-SHA (256 bits)) for perpass@ietf.org; Tue, 7 Oct 2014 12:35:18 -0400 Message-ID: <54341645.5010407@cdt.org> Date: Tue, 07 Oct 2014 12:35:17 -0400 From: Joseph Lorenzo Hall User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: perpass@ietf.org References: <5416FE26.7090705@cs.tcd.ie> In-Reply-To: <5416FE26.7090705@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/perpass/N2U2XALqh5mvROP1UHWUcfUku38 Subject: Re: [perpass] IAB security/privacy programme PM draft X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 16:35:23 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 As the showrunner for the confidentiality effort in the IAB privacy and security program, please do share your feedback with us. We are also contemplating a companion document on mitigations for the threats outlined in the threat model. best, Joe On 9/15/14, 10:56 AM, Stephen Farrell wrote: > > Hi all, > > Richard and a few folks started work on documenting a problem > statement [1] some time ago. As I think was stated here before it > seems like a good plan for that to be progressed as part of the > IAB's re-factored security/privacy programme. So Brian Trammell has > picked up the pen and pushed out [2]. > > Comments very welcome (I've still to read it myself so will send my > comments here too when I've had a chance), > > Cheers, S. > > > [1] http://tools.ietf.org/html/draft-barnes-pervasive-problem [2] > https://tools.ietf.org/html/draft-iab-privsec-confidentiality-threat > > _______________________________________________ perpass mailing > list perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > - -- Joseph Lorenzo Hall Chief Technologist Center for Democracy & Technology 1634 I ST NW STE 1100 Washington DC 20006-4011 (p) 202-407-8825 (f) 202-637-0968 joe@cdt.org PGP: https://josephhall.org/gpg-key fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (Darwin) iQIcBAEBCAAGBQJUNBZEAAoJEF+GaYdAqahxrEsP/28vDnQatU/cplFLiWz9+Xda 8lscV2uhxEaQYHgy4wvsd03vgfFCE/RfG7AwX8h1+S7XDUg27GpUHLPeXJesF6cy WOSnzYN6K/WmDMn8AKYv+/FDYf6JdB5yc0zmiivAbOTDwsi6LTbRMvwRhMyUXlEM OeZlbZz5GkyMmDccUNSjS6B8WrGnxilnQX07c7bRgeq9DR5DB8QwaRsg66Z757Bi vSqDAG/87aKU8Pov5gRRHNY9QskOneuFWEIOO4pl+eqodx3c45Lyx7Ain7vjy/nO l92FTyOyf47I99vWWyrit/KBPImxNFnP2txZu1WuWXz/yNYCKxrOMiTdIycjVwVK 7jpfcAtC7IB11+nMTy4xNl4kzRBcZnCXVaWhZ+b+5/SuZX4qKrwB4YeFlQQKJXXY +F9XeG1MAjaF4qmNFeLsIUO0wadRXQ23RSlKfDqNe8s+Y2BsvoUepzxmsbSsJCJ0 NAGEGNqBnwXQwbaJO9MtTU0RzXbe1KzJw26eHY5/nfCBfyn2hYw9TjzH0cmAOOXX IcxVYBfJLu/tUNvxtpaPhlu3yvzcU99KxdjLpBsD/wOk4mfblg9AAZiwxXdq5k7+ nCSPz+CodE2OWt7UsqdCIdBiW/yaC2qnLcnMw197lRxJnDwE2NrbQx72AQAd6u9Z ndxTiZ7dEsIuOJE0OCaL =4SpJ -----END PGP SIGNATURE----- From nobody Tue Oct 7 10:45:57 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EA371A86E2 for ; Tue, 7 Oct 2014 10:45:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, 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 4EDnHJBe583C for ; Tue, 7 Oct 2014 10:45:46 -0700 (PDT) Received: from mx0a-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B2741A8035 for ; Tue, 7 Oct 2014 10:45:41 -0700 (PDT) Received: from pps.filterd (m0045849.ppops.net [127.0.0.1]) by mx0a-0016f401.pphosted.com (8.14.5/8.14.5) with SMTP id s97HjNcv011847; Tue, 7 Oct 2014 10:45:23 -0700 Received: from sc-owa.marvell.com ([199.233.58.135]) by mx0a-0016f401.pphosted.com with ESMTP id 1pv145a9kf-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 07 Oct 2014 10:45:23 -0700 Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA.marvell.com ([::1]) with mapi; Tue, 7 Oct 2014 10:45:23 -0700 From: Paul Lambert To: Joseph Lorenzo Hall , "perpass@ietf.org" Date: Tue, 7 Oct 2014 10:45:20 -0700 Thread-Topic: [perpass] IAB security/privacy programme PM draft Thread-Index: Ac/iVnfaMYokrNGfSQCQ1Rb9JtEEQw== Message-ID: References: <5416FE26.7090705@cs.tcd.ie> <54341645.5010407@cdt.org> In-Reply-To: <54341645.5010407@cdt.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.28, 0.0.0000 definitions=2014-10-07_06:2014-10-07,2014-10-07,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1410070162 Archived-At: http://mailarchive.ietf.org/arch/msg/perpass/Fkc9CKB78iFeFhitxvazAA8pNYk Subject: Re: [perpass] IAB security/privacy programme PM draft X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 17:45:53 -0000 On 10/7/14, 9:35 AM, "Joseph Lorenzo Hall" wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA256 > >As the showrunner for the confidentiality effort in the IAB privacy >and security program, please do share your feedback with us. Great document =8A some observations on a missing topic area: The draft-iab-privsec-confidentiality-threat-00 provides a good overview of many issues, but does not mention the problems associated with static MAC addresses. MAC addresses, while perhaps considered beneath the purview of IETF have a significant impact on the system considerations for private Internet communications. MAC addresses are assigned to device interfaces to support link level communications on subnets. These addresses are assigned through a global registry with allocations to individual companies to distribute unique assignments. Being unique, the MAC addresses are often used as a device identification. Some operating systems use a device MAC address to create a GUID (globally unique identifier) that is then used to identify the host. The GUID is then embedded in documents to identify the source platform. MAC addresses are used to create IPv6 addresses. The unique MAC address provides a convenient mechanisms to assign a unique IP address. This convenience for unique IPv6 assignment makes a unique MAC address an integral part of many emerging architectures (e.g for IoT). Binding the device unique MAC address to an IPv6 address makes the communicating device identifiable by any observer end-to-end. Static MAC addresses are a particularly serious problem in wireless networks. Simply sniffing of traffic provides the device unique address which is readily correlated to the specific user. IEEE 802 does provide facilities for local MAC addresses. The local MAC addresses are not used widely and have been applied primarily for special purpose protocol applications (e.g. Local MAC used as BSSID for IBSS). The local MAC addresses does allow a random address to be used for the link provides significant improvements for privacy, but the impact on bridging, routing and device authentication need to be considered. Frequently changing MAC addresses will Potentially overflow routing tables. DHCP servers may run out of available addresses. Guidelines for protocols that use MAC addresses will need to be developed to prevent disruption of network communications. Some IETF protocols may need to be modified to facilitate the use of local MAC addresses. >We are >also contemplating a companion document on mitigations for the threats >outlined in the threat model. =8A if we want to build a private Internet we should ensure that we have a solid foundation at the bottom of the stack (MAC addresses). Addressing architectures must be be reconsidered to ensure that a static address is not necessary. Identity should not be an addresses, but some other non-assigned locally generated identifier that can be bound to a end device cryptographically. Paul > >best, Joe > >On 9/15/14, 10:56 AM, Stephen Farrell wrote: >>=20 >> Hi all, >>=20 >> Richard and a few folks started work on documenting a problem >> statement [1] some time ago. As I think was stated here before it >> seems like a good plan for that to be progressed as part of the >> IAB's re-factored security/privacy programme. So Brian Trammell has >> picked up the pen and pushed out [2]. >>=20 >> Comments very welcome (I've still to read it myself so will send my >> comments here too when I've had a chance), >>=20 >> Cheers, S. >>=20 >>=20 >> [1] http://tools.ietf.org/html/draft-barnes-pervasive-problem [2] >> https://tools.ietf.org/html/draft-iab-privsec-confidentiality-threat >> >> _______________________________________________ perpass mailing >> list perpass@ietf.org >> https://www.ietf.org/mailman/listinfo/perpass >>=20 > >- --=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 > > >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v1.4.13 (Darwin) > >iQIcBAEBCAAGBQJUNBZEAAoJEF+GaYdAqahxrEsP/28vDnQatU/cplFLiWz9+Xda >8lscV2uhxEaQYHgy4wvsd03vgfFCE/RfG7AwX8h1+S7XDUg27GpUHLPeXJesF6cy >WOSnzYN6K/WmDMn8AKYv+/FDYf6JdB5yc0zmiivAbOTDwsi6LTbRMvwRhMyUXlEM >OeZlbZz5GkyMmDccUNSjS6B8WrGnxilnQX07c7bRgeq9DR5DB8QwaRsg66Z757Bi >vSqDAG/87aKU8Pov5gRRHNY9QskOneuFWEIOO4pl+eqodx3c45Lyx7Ain7vjy/nO >l92FTyOyf47I99vWWyrit/KBPImxNFnP2txZu1WuWXz/yNYCKxrOMiTdIycjVwVK >7jpfcAtC7IB11+nMTy4xNl4kzRBcZnCXVaWhZ+b+5/SuZX4qKrwB4YeFlQQKJXXY >+F9XeG1MAjaF4qmNFeLsIUO0wadRXQ23RSlKfDqNe8s+Y2BsvoUepzxmsbSsJCJ0 >NAGEGNqBnwXQwbaJO9MtTU0RzXbe1KzJw26eHY5/nfCBfyn2hYw9TjzH0cmAOOXX >IcxVYBfJLu/tUNvxtpaPhlu3yvzcU99KxdjLpBsD/wOk4mfblg9AAZiwxXdq5k7+ >nCSPz+CodE2OWt7UsqdCIdBiW/yaC2qnLcnMw197lRxJnDwE2NrbQx72AQAd6u9Z >ndxTiZ7dEsIuOJE0OCaL >=3D4SpJ >-----END PGP SIGNATURE----- > >_______________________________________________ >perpass mailing list >perpass@ietf.org >https://www.ietf.org/mailman/listinfo/perpass From nobody Tue Oct 7 11:16:26 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA2C41A8739 for ; Tue, 7 Oct 2014 11:16:21 -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 dsfsDGIJIG7K for ; Tue, 7 Oct 2014 11:16:18 -0700 (PDT) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4C021ACEF7 for ; Tue, 7 Oct 2014 11:16:14 -0700 (PDT) Received: by mail-lb0-f177.google.com with SMTP id w7so6691537lbi.36 for ; Tue, 07 Oct 2014 11:16:13 -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=tQLLGMi2KOv1gPOPiWMgMr28a6ygsWbNCZ+K5Wt4HcA=; b=JOFc1JHYbMXCawGDsF2oupXyKjJSLz7wPsvIdSS/BXjnhgg1f8LQimkyeVpbpag/IK 4lzlBdbXx4PjHRgIE24ozUro7JdzA+8XCpKJfZTurWp1BKWh13bUDVZmS06pc4wIYyxp TbheLhmcTMotM91i6bpllonehIAfI7vbDttK3kKYCMdNrNG6bibUIWsXcl9xRbVFDgeV ZU6LgmgPsam0GS2RY4k5kAiIN+hkD1PKb3nQ9ze77P/12RhSG3LUM2STFFe7NeDZwP8i UdNuU0io+8EQEbGLuc4sxA4m8575wnxUsjPOofWQT5gHcMvTtpDdzb+ZsaQ52TJlxlhO NzKA== MIME-Version: 1.0 X-Received: by 10.152.205.38 with SMTP id ld6mr4979480lac.97.1412705772951; Tue, 07 Oct 2014 11:16:12 -0700 (PDT) Received: by 10.112.95.36 with HTTP; Tue, 7 Oct 2014 11:16:12 -0700 (PDT) In-Reply-To: References: <5416FE26.7090705@cs.tcd.ie> <54341645.5010407@cdt.org> Date: Tue, 7 Oct 2014 14:16:12 -0400 Message-ID: From: Kathleen Moriarty To: Paul Lambert Content-Type: multipart/alternative; boundary=001a11349bb2c4dd220504d9317f Archived-At: http://mailarchive.ietf.org/arch/msg/perpass/iOd1BkNrLJkgDOfkNXsa7aKMWo8 Cc: "perpass@ietf.org" , Joseph Lorenzo Hall Subject: Re: [perpass] IAB security/privacy programme PM draft X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 18:16:22 -0000 --001a11349bb2c4dd220504d9317f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Oct 7, 2014 at 1:45 PM, Paul Lambert wrote: > > On 10/7/14, 9:35 AM, "Joseph Lorenzo Hall" wrote: > > >-----BEGIN PGP SIGNED MESSAGE----- > >Hash: SHA256 > > > >As the showrunner for the confidentiality effort in the IAB privacy > >and security program, please do share your feedback with us. > > > Great document =C5=A0 some observations on a missing topic area: > > > The draft-iab-privsec-confidentiality-threat-00 provides a good > overview of many issues, but does not mention the problems associated > with static MAC addresses. MAC addresses, while perhaps considered > beneath the purview of IETF have a significant impact on the system > considerations for private Internet communications. > > MAC addresses are assigned to device interfaces to support > link level communications on subnets. These addresses are assigned > through a global registry with allocations to individual companies to > distribute unique assignments. Being unique, the MAC addresses are > often used as a device identification. Some operating systems use > a device MAC address to create a GUID (globally unique identifier) > that is then used to identify the host. The GUID is then embedded > in documents to identify the source platform. > > MAC addresses are used to create IPv6 addresses. The unique MAC address > provides a convenient mechanisms to assign a unique IP address. > This convenience for unique IPv6 assignment makes a unique > MAC address an integral part of many emerging architectures > (e.g for IoT). Binding the device unique MAC address to an IPv6 > address makes the communicating device identifiable by > any observer end-to-end. > > Static MAC addresses are a particularly serious problem in > wireless networks. Simply sniffing of traffic provides > the device unique address which is readily correlated > to the specific user. > > IEEE 802 does provide facilities for local MAC addresses. The > local MAC addresses are not used widely and have been applied > primarily for special purpose protocol applications > (e.g. Local MAC used as BSSID for IBSS). The local MAC > addresses does allow a random address to be used for the link > provides significant improvements for privacy, but the > impact on bridging, routing and device authentication need > to be considered. Frequently changing MAC addresses will > Potentially overflow routing tables. DHCP servers may run > out of available addresses. Guidelines for protocols that > use MAC addresses will need to be developed to prevent > disruption of network communications. Some IETF protocols > may need to be modified to facilitate the use of local > MAC addresses. > > Thanks, Paul. We've been working with the IEEE and in particular with Juan Carlos Zuniga on this topic. He has talked to us about work the IEEE is doing and presented at the last SAAG meeting. Your points are good ones on the interconnection between their work and ours. Here are his slides from the last SAAG meeting, this set doesn't go deep into that topic though. http://www.ietf.org/proceedings/90/slides/slides-90-saag-1.pdf > > > > >We are > >also contemplating a companion document on mitigations for the threats > >outlined in the threat model. > > =C5=A0 if we want to build a private Internet > we should ensure that we have a solid foundation at the > bottom of the stack (MAC addresses). Addressing architectures > must be be reconsidered to ensure that a static address is not > necessary. Identity should not be an addresses, but some other > non-assigned locally generated identifier that can be bound > to a end device cryptographically. > > Paul > > > > > > >best, Joe > > > >On 9/15/14, 10:56 AM, Stephen Farrell wrote: > >> > >> Hi all, > >> > >> Richard and a few folks started work on documenting a problem > >> statement [1] some time ago. As I think was stated here before it > >> seems like a good plan for that to be progressed as part of the > >> IAB's re-factored security/privacy programme. So Brian Trammell has > >> picked up the pen and pushed out [2]. > >> > >> Comments very welcome (I've still to read it myself so will send my > >> comments here too when I've had a chance), > >> > >> Cheers, S. > >> > >> > >> [1] http://tools.ietf.org/html/draft-barnes-pervasive-problem [2] > >> https://tools.ietf.org/html/draft-iab-privsec-confidentiality-threat > >> > >> _______________________________________________ perpass mailing > >> list perpass@ietf.org > >> https://www.ietf.org/mailman/listinfo/perpass > >> > > > >- -- > >Joseph Lorenzo Hall > >Chief Technologist > >Center for Democracy & Technology > >1634 I ST NW STE 1100 > >Washington DC 20006-4011 > >(p) 202-407-8825 > >(f) 202-637-0968 > >joe@cdt.org > >PGP: https://josephhall.org/gpg-key > >fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 > > > > > >-----BEGIN PGP SIGNATURE----- > >Version: GnuPG v1.4.13 (Darwin) > > > >iQIcBAEBCAAGBQJUNBZEAAoJEF+GaYdAqahxrEsP/28vDnQatU/cplFLiWz9+Xda > >8lscV2uhxEaQYHgy4wvsd03vgfFCE/RfG7AwX8h1+S7XDUg27GpUHLPeXJesF6cy > >WOSnzYN6K/WmDMn8AKYv+/FDYf6JdB5yc0zmiivAbOTDwsi6LTbRMvwRhMyUXlEM > >OeZlbZz5GkyMmDccUNSjS6B8WrGnxilnQX07c7bRgeq9DR5DB8QwaRsg66Z757Bi > >vSqDAG/87aKU8Pov5gRRHNY9QskOneuFWEIOO4pl+eqodx3c45Lyx7Ain7vjy/nO > >l92FTyOyf47I99vWWyrit/KBPImxNFnP2txZu1WuWXz/yNYCKxrOMiTdIycjVwVK > >7jpfcAtC7IB11+nMTy4xNl4kzRBcZnCXVaWhZ+b+5/SuZX4qKrwB4YeFlQQKJXXY > >+F9XeG1MAjaF4qmNFeLsIUO0wadRXQ23RSlKfDqNe8s+Y2BsvoUepzxmsbSsJCJ0 > >NAGEGNqBnwXQwbaJO9MtTU0RzXbe1KzJw26eHY5/nfCBfyn2hYw9TjzH0cmAOOXX > >IcxVYBfJLu/tUNvxtpaPhlu3yvzcU99KxdjLpBsD/wOk4mfblg9AAZiwxXdq5k7+ > >nCSPz+CodE2OWt7UsqdCIdBiW/yaC2qnLcnMw197lRxJnDwE2NrbQx72AQAd6u9Z > >ndxTiZ7dEsIuOJE0OCaL > >=3D4SpJ > >-----END PGP SIGNATURE----- > > > >_______________________________________________ > >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 Best regards, Kathleen --001a11349bb2c4dd220504d9317f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Oct 7, 2014 at 1:45 PM, Paul Lambert <paul@marvell.com><= /span> wrote:

On 10/7/14, 9:35 AM, "Joseph Lorenzo Hall" <joe@cdt.org> wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA256
>
>As the showrunner for the confidentiality effort in the IAB privacy
>and security program, please do share your feedback with us.


Great document =C5=A0 some observations on a missing topic area:


The draft-iab-privsec-confidentiality-threat-00 provides a good
overview of many issues, but does not mention the problems associated
with static MAC addresses. MAC addresses, while perhaps considered
beneath the purview of IETF have a significant impact on the system
considerations for private Internet communications.

MAC addresses are assigned to device interfaces to support
link level communications on subnets.=C2=A0 These addresses are assigned through a global registry with allocations to individual companies to
distribute unique assignments.=C2=A0 Being unique, the MAC addresses are often used as a device identification.=C2=A0 Some operating systems use
a device MAC address to create a GUID (globally unique identifier)
that is then used to identify the host.=C2=A0 The GUID is then embedded
in documents to identify the source platform.

MAC addresses are used to create IPv6 addresses.=C2=A0 The unique MAC addre= ss
provides a convenient=C2=A0 mechanisms to assign a unique IP address.
This convenience for unique IPv6 assignment makes a unique
MAC address an integral part of many emerging architectures
(e.g for IoT). Binding the device unique MAC address to an IPv6
address makes the communicating device identifiable by
any observer end-to-end.

Static MAC addresses are a particularly serious problem in
wireless networks.=C2=A0 Simply sniffing of traffic provides
the device unique address which is readily correlated
to the specific user.

IEEE 802 does provide facilities for local MAC addresses.=C2=A0 The
local MAC addresses are not used widely and have been applied
primarily for special purpose protocol applications
(e.g. Local MAC used as BSSID for IBSS).=C2=A0 The local MAC
addresses does allow a random address to be used for the link
provides significant improvements for privacy, but the
impact on bridging, routing and device authentication need
to be considered.=C2=A0 Frequently changing MAC addresses will
Potentially overflow routing tables.=C2=A0 DHCP servers may run
out of available addresses.=C2=A0 Guidelines for protocols that
use MAC addresses will need to be developed to prevent
disruption of network communications.=C2=A0 Some IETF protocols
may need to be modified to facilitate the use of local
MAC addresses.


Thanks, Paul.= =C2=A0 We've been working with the IEEE and in particular with Juan Car= los Zuniga on this topic.=C2=A0 He has talked to us about work the IEEE is = doing and presented at the last SAAG meeting.=C2=A0 Your points are good on= es on the interconnection between their work and ours.

=
Here are his slides from the last SAAG meeting, this set doesn't g= o deep into that topic though.



>We are
>also contemplating a companion document on mitigations for the threats<= br> >outlined in the threat model.

=C5=A0=C2=A0 if we want to build a private Internet
we should ensure that we have a solid foundation at the
bottom of the stack (MAC addresses).=C2=A0 Addressing architectures
must be be reconsidered to ensure that a static address is not
necessary.=C2=A0 Identity should not be an addresses, but some other
non-assigned locally generated identifier that can be bound
to a end device cryptographically.

Paul



>
>best, Joe
>
>On 9/15/14, 10:56 AM, Stephen Farrell wrote:
>>
>> Hi all,
>>
>> Richard and a few folks started work on documenting a problem
>> statement [1] some time ago. As I think was stated here before it<= br> >> seems like a good plan for that to be progressed as part of the >> IAB's re-factored security/privacy programme. So Brian Trammel= l has
>> picked up the pen and pushed out [2].
>>
>> Comments very welcome (I've still to read it myself so will se= nd my
>> comments here too when I've had a chance),
>>
>> Cheers, S.
>>
>>
>> [1] http://tools.ietf.org/html/draft-barnes-pervasive= -problem [2]
>> https://tools.ietf.org/html/draft-iab-priv= sec-confidentiality-threat
>>
>>=C2=A0 _______________________________________________ perpass mail= ing
>> list perpass@ietf.org
>> https://www.ietf.org/mailman/listinfo/perpass
>>
>
>- --
>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=C2=A0 1607 5F86 6987 40A9 A871 >
>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.4.13 (Darwin)
>
>iQIcBAEBCAAGBQJUNBZEAAoJEF+GaYdAqahxrEsP/28vDnQatU/cplFLiWz9+Xda
>8lscV2uhxEaQYHgy4wvsd03vgfFCE/RfG7AwX8h1+S7XDUg27GpUHLPeXJesF6cy
>WOSnzYN6K/WmDMn8AKYv+/FDYf6JdB5yc0zmiivAbOTDwsi6LTbRMvwRhMyUXlEM
>OeZlbZz5GkyMmDccUNSjS6B8WrGnxilnQX07c7bRgeq9DR5DB8QwaRsg66Z757Bi
>vSqDAG/87aKU8Pov5gRRHNY9QskOneuFWEIOO4pl+eqodx3c45Lyx7Ain7vjy/nO
>l92FTyOyf47I99vWWyrit/KBPImxNFnP2txZu1WuWXz/yNYCKxrOMiTdIycjVwVK
>7jpfcAtC7IB11+nMTy4xNl4kzRBcZnCXVaWhZ+b+5/SuZX4qKrwB4YeFlQQKJXXY
>+F9XeG1MAjaF4qmNFeLsIUO0wadRXQ23RSlKfDqNe8s+Y2BsvoUepzxmsbSsJCJ0
>NAGEGNqBnwXQwbaJO9MtTU0RzXbe1KzJw26eHY5/nfCBfyn2hYw9TjzH0cmAOOXX
>IcxVYBfJLu/tUNvxtpaPhlu3yvzcU99KxdjLpBsD/wOk4mfblg9AAZiwxXdq5k7+
>nCSPz+CodE2OWt7UsqdCIdBiW/yaC2qnLcnMw197lRxJnDwE2NrbQx72AQAd6u9Z
>ndxTiZ7dEsIuOJE0OCaL
>=3D4SpJ
>-----END PGP SIGNATURE-----
>
>_______________________________________________
>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



--
=

Best regards,
Kathleen
--001a11349bb2c4dd220504d9317f-- From nobody Tue Oct 7 18:50:15 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C37351A8AE8 for ; Tue, 7 Oct 2014 18:50:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, 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 J71ZErTkSn_n for ; Tue, 7 Oct 2014 18:50:05 -0700 (PDT) Received: from mx0a-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3B651A8AB3 for ; Tue, 7 Oct 2014 18:50:05 -0700 (PDT) Received: from pps.filterd (m0045849.ppops.net [127.0.0.1]) by mx0a-0016f401.pphosted.com (8.14.5/8.14.5) with SMTP id s981n9VD018858; Tue, 7 Oct 2014 18:49:49 -0700 Received: from sc-owa.marvell.com ([199.233.58.135]) by mx0a-0016f401.pphosted.com with ESMTP id 1pv145bad3-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 07 Oct 2014 18:49:49 -0700 Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA.marvell.com ([::1]) with mapi; Tue, 7 Oct 2014 18:49:48 -0700 From: Paul Lambert To: Kathleen Moriarty Date: Tue, 7 Oct 2014 18:49:46 -0700 Thread-Topic: [perpass] IAB security/privacy programme PM draft Thread-Index: Ac/imiRW0s9jC9yBQnKL57qN9Umcyg== Message-ID: References: <5416FE26.7090705@cs.tcd.ie> <54341645.5010407@cdt.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_D059DF1D4FB8Epaulmarvellcom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.28, 0.0.0000 definitions=2014-10-08_01:2014-10-08,2014-10-07,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1410080013 Archived-At: http://mailarchive.ietf.org/arch/msg/perpass/0lNWwCt0hyy0TB6_dwU4GCTMn-g Cc: "perpass@ietf.org" , Joseph Lorenzo Hall Subject: Re: [perpass] IAB security/privacy programme PM draft X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "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, 08 Oct 2014 01:50:09 -0000 --_000_D059DF1D4FB8Epaulmarvellcom_ Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable On Tue, Oct 7, 2014 at 1:45 PM, Paul Lambert > wrote: On 10/7/14, 9:35 AM, "Joseph Lorenzo Hall" = > wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA256 > >As the showrunner for the confidentiality effort in the IAB privacy >and security program, please do share your feedback with us. Great document =8A some observations on a missing topic area: The draft-iab-privsec-confidentiality-threat-00 provides a good overview of many issues, but does not mention the problems associated with static MAC addresses. MAC addresses, while perhaps considered beneath the purview of IETF have a significant impact on the system considerations for private Internet communications. MAC addresses are assigned to device interfaces to support link level communications on subnets. These addresses are assigned through a global registry with allocations to individual companies to distribute unique assignments. Being unique, the MAC addresses are often used as a device identification. Some operating systems use a device MAC address to create a GUID (globally unique identifier) that is then used to identify the host. The GUID is then embedded in documents to identify the source platform. MAC addresses are used to create IPv6 addresses. The unique MAC address provides a convenient mechanisms to assign a unique IP address. This convenience for unique IPv6 assignment makes a unique MAC address an integral part of many emerging architectures (e.g for IoT). Binding the device unique MAC address to an IPv6 address makes the communicating device identifiable by any observer end-to-end. Static MAC addresses are a particularly serious problem in wireless networks. Simply sniffing of traffic provides the device unique address which is readily correlated to the specific user. IEEE 802 does provide facilities for local MAC addresses. The local MAC addresses are not used widely and have been applied primarily for special purpose protocol applications (e.g. Local MAC used as BSSID for IBSS). The local MAC addresses does allow a random address to be used for the link provides significant improvements for privacy, but the impact on bridging, routing and device authentication need to be considered. Frequently changing MAC addresses will Potentially overflow routing tables. DHCP servers may run out of available addresses. Guidelines for protocols that use MAC addresses will need to be developed to prevent disruption of network communications. Some IETF protocols may need to be modified to facilitate the use of local MAC addresses. Thanks, Paul. We've been working with the IEEE and in particular with Juan= Carlos Zuniga on this topic. He has talked to us about work the IEEE is d= oing and presented at the last SAAG meeting. Your points are good ones on = the interconnection between their work and ours. Yes, I=92ve been pushing this in IEEE and the WFA for a year or two =85 We do have one specification already in the Wi-FI Alliance that will be usi= ng link local MAC addresses (to be announced soon). I=92m optimistic that = this will see some broad adoption, however, it is not your standard client = to hotspot messaging so there is still more work to do. I=92m hoping that = some devices will support both this new and old mode of operation simultane= ously and so adopt changing MAC addresses. Right now these recommendation= s for changing address are a little loose and only stipulate that the MAC a= ddress should remain the same for at least 30 minutes. The point in the narrative above, was not so much to describe the work in I= EEE that may be out-of-scope for the IETF, but to indicate that work in the= IETF will be required to adapt to constantly changing MAC addresses. Paul Here are his slides from the last SAAG meeting, this set doesn't go deep in= to that topic though. http://www.ietf.org/proceedings/90/slides/slides-90-saag-1.pdf >We are >also contemplating a companion document on mitigations for the threats >outlined in the threat model. =8A if we want to build a private Internet we should ensure that we have a solid foundation at the bottom of the stack (MAC addresses). Addressing architectures must be be reconsidered to ensure that a static address is not necessary. Identity should not be an addresses, but some other non-assigned locally generated identifier that can be bound to a end device cryptographically. Paul > >best, Joe > >On 9/15/14, 10:56 AM, Stephen Farrell wrote: >> >> Hi all, >> >> Richard and a few folks started work on documenting a problem >> statement [1] some time ago. As I think was stated here before it >> seems like a good plan for that to be progressed as part of the >> IAB's re-factored security/privacy programme. So Brian Trammell has >> picked up the pen and pushed out [2]. >> >> Comments very welcome (I've still to read it myself so will send my >> comments here too when I've had a chance), >> >> Cheers, S. >> >> >> [1] http://tools.ietf.org/html/draft-barnes-pervasive-problem [2] >> https://tools.ietf.org/html/draft-iab-privsec-confidentiality-threat >> >> _______________________________________________ perpass mailing >> list perpass@ietf.org >> https://www.ietf.org/mailman/listinfo/perpass >> > >- -- >Joseph Lorenzo Hall >Chief Technologist >Center for Democracy & Technology >1634 I ST NW STE 1100 >Washington DC 20006-4011 >(p) 202-407-8825 >(f) 202-637-0968 >joe@cdt.org >PGP: https://josephhall.org/gpg-key >fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 > > >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v1.4.13 (Darwin) > >iQIcBAEBCAAGBQJUNBZEAAoJEF+GaYdAqahxrEsP/28vDnQatU/cplFLiWz9+Xda >8lscV2uhxEaQYHgy4wvsd03vgfFCE/RfG7AwX8h1+S7XDUg27GpUHLPeXJesF6cy >WOSnzYN6K/WmDMn8AKYv+/FDYf6JdB5yc0zmiivAbOTDwsi6LTbRMvwRhMyUXlEM >OeZlbZz5GkyMmDccUNSjS6B8WrGnxilnQX07c7bRgeq9DR5DB8QwaRsg66Z757Bi >vSqDAG/87aKU8Pov5gRRHNY9QskOneuFWEIOO4pl+eqodx3c45Lyx7Ain7vjy/nO >l92FTyOyf47I99vWWyrit/KBPImxNFnP2txZu1WuWXz/yNYCKxrOMiTdIycjVwVK >7jpfcAtC7IB11+nMTy4xNl4kzRBcZnCXVaWhZ+b+5/SuZX4qKrwB4YeFlQQKJXXY >+F9XeG1MAjaF4qmNFeLsIUO0wadRXQ23RSlKfDqNe8s+Y2BsvoUepzxmsbSsJCJ0 >NAGEGNqBnwXQwbaJO9MtTU0RzXbe1KzJw26eHY5/nfCBfyn2hYw9TjzH0cmAOOXX >IcxVYBfJLu/tUNvxtpaPhlu3yvzcU99KxdjLpBsD/wOk4mfblg9AAZiwxXdq5k7+ >nCSPz+CodE2OWt7UsqdCIdBiW/yaC2qnLcnMw197lRxJnDwE2NrbQx72AQAd6u9Z >ndxTiZ7dEsIuOJE0OCaL >=3D4SpJ >-----END PGP SIGNATURE----- > >_______________________________________________ >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 -- Best regards, Kathleen --_000_D059DF1D4FB8Epaulmarvellcom_ Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable



On Tue, Oct 7, 2014 at 1:45 PM, Paul Lambert <paul@marvell= .com> wrote:

On 10/7/14, 9:35 AM, "Joseph Lorenzo Hall" <joe@cdt.org> wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA256
>
>As the showrunner for the confidentiality effort in the IAB privacy
>and security program, please do share your feedback with us.

Great document =8A some observations on a missing topic area:

The draft-iab-privsec-confidentiality-threat-00 provides a good
overview of many issues, but does not mention the problems associated
with static MAC addresses. MAC addresses, while perhaps considered
beneath the purview of IETF have a significant impact on the system
considerations for private Internet communications.

MAC addresses are assigned to device interfaces to support
link level communications on subnets.  These addresses are assigned through a global registry with allocations to individual companies to
distribute unique assignments.  Being unique, the MAC addresses are often used as a device identification.  Some operating systems use
a device MAC address to create a GUID (globally unique identifier)
that is then used to identify the host.  The GUID is then embedded
in documents to identify the source platform.

MAC addresses are used to create IPv6 addresses.  The unique MAC addre= ss
provides a convenient  mechanisms to assign a unique IP address.
This convenience for unique IPv6 assignment makes a unique
MAC address an integral part of many emerging architectures
(e.g for IoT). Binding the device unique MAC address to an IPv6
address makes the communicating device identifiable by
any observer end-to-end.

Static MAC addresses are a particularly serious problem in
wireless networks.  Simply sniffing of traffic provides
the device unique address which is readily correlated
to the specific user.

IEEE 802 does provide facilities for local MAC addresses.  The
local MAC addresses are not used widely and have been applied
primarily for special purpose protocol applications
(e.g. Local MAC used as BSSID for IBSS).  The local MAC
addresses does allow a random address to be used for the link
provides significant improvements for privacy, but the
impact on bridging, routing and device authentication need
to be considered.  Frequently changing MAC addresses will
Potentially overflow routing tables.  DHCP servers may run
out of available addresses.  Guidelines for protocols that
use MAC addresses will need to be developed to prevent
disruption of network communications.  Some IETF protocols
may need to be modified to facilitate the use of local
MAC addresses.


<= div>Thanks, Paul.  We've been working with the IEEE and in particular = with Juan Carlos Zuniga on this topic.  He has talked to us about work= the IEEE is doing and presented at the last SAAG meeting.  Your point= s are good ones on the interconnection between their work and ours.
Yes, I=92ve been pushing this in I= EEE and the WFA for a year or two =85

We do have o= ne specification already in the Wi-FI Alliance that will be using link loca= l MAC addresses (to be announced soon).  I=92m optimistic that this wi= ll see some broad adoption, however, it is not your standard client to hots= pot messaging so there is still more work to do.  I=92m hoping that so= me devices will support both this new and old mode of operation simultaneou= sly and so adopt changing MAC addresses.   Right now these recommendat= ions for changing address are a little loose and only stipulate that the MA= C address should remain the same for at least 30 minutes.

The point in the narrative above, was not so much to describe the w= ork in IEEE that may be out-of-scope for the IETF, but to indicate that wor= k in the IETF will be required to adapt to constantly changing MAC addresse= s.  

Paul


=

Here are his slides from the last SAAG meeting, = this set doesn't go deep into that topic though.
<= /blockquote>



=




>We are
>also contemplating a companion document on mitigations for the threats<= br> >outlined in the threat model.

=8A  if we want to bui= ld a private Internet
we should ensure that we have a solid foundation at the
bottom of the stack (MAC addresses).  Addressing architectures
must be be reconsidered to ensure that a static address is not
necessary.  Identity should not be an addresses, but some other
non-assigned locally generated identifier that can be bound
to a end device cryptographically.

Paul



>
>best, Joe
>
>On 9/15/14, 10:56 AM, Stephen Farrell wrote:
>>
>> Hi all,
>>
>> Richard and a few folks started work on documenting a problem
>> statement [1] some time ago. As I think was stated here before it<= br> >> seems like a good plan for that to be progressed as part of the >> IAB's re-factored security/privacy programme. So Brian Trammell ha= s
>> picked up the pen and pushed out [2].
>>
>> Comments very welcome (I've still to read it myself so will send m= y
>> comments here too when I've had a chance),
>>
>> Cheers, S.
>>
>>
>> [1] http://tools.ietf.org/html/draft-barnes-pervasive= -problem [2]
>> https://tools.ietf.org/html/draft-iab-priv= sec-confidentiality-threat
>>
>>  _______________________________________________ perpass mail= ing
>> list perpass@ietf.org
>> https://www.ietf.org/mailman/listinfo/perpass
>>
>
>- --
>Joseph Lorenzo Hall
>Chief Technologist
>Center for Democracy & Technology
>1634 I ST NW STE 1100
>Washington DC 20006-4011
>(p) 202-407-882= 5
>(f) 202-637-096= 8
>joe@cdt.org
>PGP: https= ://josephhall.org/gpg-key
>fingerprint: 3CA2 8D7B 9F6D DBD3 4B10  1607 5F86 6987 40A9 A871 >
>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.4.13 (Darwin)
>
>iQIcBAEBCAAGBQJUNBZEAAoJEF+GaYdAqahxrEsP/28vDnQatU/cplFLiWz9+Xd= a
>8lscV2uhxEaQYHgy4wvsd03vgfFCE/RfG7AwX8h1+S7XDUg27GpUHLPeXJesF6cy >WOSnzYN6K/WmDMn8AKYv+/FDYf6JdB5yc0zmiivAbOTDwsi6LTbRMvwRhMyUXlEM >OeZlbZz5GkyMmDccUNSjS6B8WrGnxilnQX07c7bRgeq9DR5DB8QwaRsg66Z757Bi
>vSqDAG/87aKU8Pov5gRRHNY9QskOneuFWEIOO4pl+eqodx3c45Lyx7Ain7vjy/nO >l92FTyOyf47I99vWWyrit/KBPImxNFnP2txZu1WuWXz/yNYCKxrOMiTdIycjVwVK
>7jpfcAtC7IB11+nMTy4xNl4kzRBcZnCXVaWhZ+b+5/SuZX4qKrwB4YeFlQQ= KJXXY
>+F9XeG1MAjaF4qmNFeLsIUO0wadRXQ23RSlKfDqNe8s+Y2BsvoUepzxmsbSsJCJ= 0
>NAGEGNqBnwXQwbaJO9MtTU0RzXbe1KzJw26eHY5/nfCBfyn2hYw9TjzH0cmAOOXX
>IcxVYBfJLu/tUNvxtpaPhlu3yvzcU99KxdjLpBsD/wOk4mfblg9AAZiwxXdq5k7+ >nCSPz+CodE2OWt7UsqdCIdBiW/yaC2qnLcnMw197lRxJnDwE2NrbQx72AQAd6u9Z >ndxTiZ7dEsIuOJE0OCaL
>=3D4SpJ
>-----END PGP SIGNATURE-----
>
>_______________________________________________
>perpass mailing list
>perpass@ietf.org
>https://www.ietf.org/mailman/listinfo/perpass

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



--

Best regards,
Kathleen
<= /blockquote>


--_000_D059DF1D4FB8Epaulmarvellcom_-- From nobody Wed Oct 8 14:03:12 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBC7D1A038D for ; Wed, 8 Oct 2014 14:03:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.685 X-Spam-Level: X-Spam-Status: No, score=-2.685 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.786] 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 znghCTYpSsCR for ; Wed, 8 Oct 2014 14:03:05 -0700 (PDT) Received: from smtp-in1.interdigital.com (smtp-in1.interdigital.com [64.208.228.133]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79EE81A0086 for ; Wed, 8 Oct 2014 14:03:05 -0700 (PDT) X-ASG-Debug-ID: 1412802183-06daaa3ff71b9480001-gildfX Received: from smtp-out1.interdigital.com (sahara.interdigital.com [10.0.128.27]) by smtp-in1.interdigital.com with ESMTP id bDiqDZAnEusZE3Lg for ; Wed, 08 Oct 2014 17:03:03 -0400 (EDT) X-Barracuda-Envelope-From: JuanCarlos.Zuniga@InterDigital.com Received: from interdigital.com ([10.0.128.12]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 8 Oct 2014 17:03:02 -0400 Received: from KYANITE.InterDigital.com ([10.1.64.253]) by interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 8 Oct 2014 17:03:02 -0400 Received: from KAINITE.InterDigital.com (10.1.64.252) by KYANITE.InterDigital.com (10.1.64.253) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 8 Oct 2014 17:03:02 -0400 Received: from NISSONITE.InterDigital.com (10.2.64.252) by KAINITE.InterDigital.com (10.1.64.252) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 8 Oct 2014 17:03:01 -0400 Received: from NABESITE.InterDigital.com ([fe80::4d8a:a889:67c2:f009]) by NISSONITE.InterDigital.com ([::1]) with mapi id 14.03.0195.001; Wed, 8 Oct 2014 17:03:01 -0400 From: "Zuniga, Juan Carlos" To: Paul Lambert , Kathleen Moriarty Thread-Topic: [perpass] IAB security/privacy programme PM draft X-ASG-Orig-Subj: RE: [perpass] IAB security/privacy programme PM draft Thread-Index: AQHP4lrLJXmaS0Ozwk6Sqazgox/HrJwmrPxA Date: Wed, 8 Oct 2014 21:03:01 +0000 Message-ID: <785DB11636645E438E2E096E1ADA47C402D16F@NABESITE.InterDigital.com> References: <5416FE26.7090705@cs.tcd.ie> <54341645.5010407@cdt.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.3.1.123] Content-Type: multipart/alternative; boundary="_000_785DB11636645E438E2E096E1ADA47C402D16FNABESITEInterDigi_" MIME-Version: 1.0 X-OriginalArrivalTime: 08 Oct 2014 21:03:02.0662 (UTC) FILETIME=[3F994A60:01CFE33B] X-Barracuda-Connect: sahara.interdigital.com[10.0.128.27] X-Barracuda-Start-Time: 1412802183 X-Barracuda-URL: http://10.1.245.3:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at interdigital.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.50 X-Barracuda-Spam-Status: No, SCORE=0.50 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=BSF_RULE7568M, HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.10348 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message 0.50 BSF_RULE7568M Custom Rule 7568M Archived-At: http://mailarchive.ietf.org/arch/msg/perpass/LDc-KxElqzawax74bMjI45O_oFk Cc: "perpass@ietf.org" , Joseph Lorenzo Hall Subject: Re: [perpass] IAB security/privacy programme PM draft X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "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, 08 Oct 2014 21:03:11 -0000 --_000_785DB11636645E438E2E096E1ADA47C402D16FNABESITEInterDigi_ Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Hi Paul, From: Paul Lambert [mailto:paul@marvell.com] Sent: Tuesday, October 07, 2014 9:50 PM To: Kathleen Moriarty Cc: perpass@ietf.org; Joseph Lorenzo Hall Subject: Re: [perpass] IAB security/privacy programme PM draft On Tue, Oct 7, 2014 at 1:45 PM, Paul Lambert > wrote: On 10/7/14, 9:35 AM, "Joseph Lorenzo Hall" = > wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA256 > >As the showrunner for the confidentiality effort in the IAB privacy >and security program, please do share your feedback with us. Great document =A9 some observations on a missing topic area: The draft-iab-privsec-confidentiality-threat-00 provides a good overview of many issues, but does not mention the problems associated with static MAC addresses. MAC addresses, while perhaps considered beneath the purview of IETF have a significant impact on the system considerations for private Internet communications. MAC addresses are assigned to device interfaces to support link level communications on subnets. These addresses are assigned through a global registry with allocations to individual companies to distribute unique assignments. Being unique, the MAC addresses are often used as a device identification. Some operating systems use a device MAC address to create a GUID (globally unique identifier) that is then used to identify the host. The GUID is then embedded in documents to identify the source platform. MAC addresses are used to create IPv6 addresses. The unique MAC address provides a convenient mechanisms to assign a unique IP address. This convenience for unique IPv6 assignment makes a unique MAC address an integral part of many emerging architectures (e.g for IoT). Binding the device unique MAC address to an IPv6 address makes the communicating device identifiable by any observer end-to-end. Static MAC addresses are a particularly serious problem in wireless networks. Simply sniffing of traffic provides the device unique address which is readily correlated to the specific user. IEEE 802 does provide facilities for local MAC addresses. The local MAC addresses are not used widely and have been applied primarily for special purpose protocol applications (e.g. Local MAC used as BSSID for IBSS). The local MAC addresses does allow a random address to be used for the link provides significant improvements for privacy, but the impact on bridging, routing and device authentication need to be considered. Frequently changing MAC addresses will Potentially overflow routing tables. DHCP servers may run out of available addresses. Guidelines for protocols that use MAC addresses will need to be developed to prevent disruption of network communications. Some IETF protocols may need to be modified to facilitate the use of local MAC addresses. Thanks, Paul. We've been working with the IEEE and in particular with Juan= Carlos Zuniga on this topic. He has talked to us about work the IEEE is d= oing and presented at the last SAAG meeting. Your points are good ones on = the interconnection between their work and ours. Yes, I've been pushing this in IEEE and the WFA for a year or two ... We do have one specification already in the Wi-FI Alliance that will be usi= ng link local MAC addresses (to be announced soon). I'm optimistic that th= is will see some broad adoption, however, it is not your standard client to= hotspot messaging so there is still more work to do. I'm hoping that some= devices will support both this new and old mode of operation simultaneousl= y and so adopt changing MAC addresses. Right now these recommendations fo= r changing address are a little loose and only stipulate that the MAC addre= ss should remain the same for at least 30 minutes. The point in the narrative above, was not so much to describe the work in I= EEE that may be out-of-scope for the IETF, but to indicate that work in the= IETF will be required to adapt to constantly changing MAC addresses. [JCZ] Yes, this is something that concerns IETF and that's why we are coord= inating as much as possible the joint effort between IEEE 802 and IETF. One of the main outcomes of the potential MAC randomization trial would be = to highlight the implications of MAC address changes on IETF protocols. As = you know, so far we have identified potential repercussions on DHCP, ARP/ND= , IPv6 SAA, switches and AAA infrastructure. Whether these will require cha= nges in the actual protocols or just changes/recommendations for configurat= ion, is still FFS. Regards, Juan Carlos Paul Here are his slides from the last SAAG meeting, this set doesn't go deep in= to that topic though. http://www.ietf.org/proceedings/90/slides/slides-90-saag-1.pdf >We are >also contemplating a companion document on mitigations for the threats >outlined in the threat model. =A9 if we want to build a private Internet we should ensure that we have a solid foundation at the bottom of the stack (MAC addresses). Addressing architectures must be be reconsidered to ensure that a static address is not necessary. Identity should not be an addresses, but some other non-assigned locally generated identifier that can be bound to a end device cryptographically. Paul > >best, Joe > >On 9/15/14, 10:56 AM, Stephen Farrell wrote: >> >> Hi all, >> >> Richard and a few folks started work on documenting a problem >> statement [1] some time ago. As I think was stated here before it >> seems like a good plan for that to be progressed as part of the >> IAB's re-factored security/privacy programme. So Brian Trammell has >> picked up the pen and pushed out [2]. >> >> Comments very welcome (I've still to read it myself so will send my >> comments here too when I've had a chance), >> >> Cheers, S. >> >> >> [1] http://tools.ietf.org/html/draft-barnes-pervasive-problem [2] >> https://tools.ietf.org/html/draft-iab-privsec-confidentiality-threat >> >> _______________________________________________ perpass mailing >> list perpass@ietf.org >> https://www.ietf.org/mailman/listinfo/perpass >> > >- -- >Joseph Lorenzo Hall >Chief Technologist >Center for Democracy & Technology >1634 I ST NW STE 1100 >Washington DC 20006-4011 >(p) 202-407-8825 >(f) 202-637-0968 >joe@cdt.org >PGP: https://josephhall.org/gpg-key >fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 > > >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v1.4.13 (Darwin) > >iQIcBAEBCAAGBQJUNBZEAAoJEF+GaYdAqahxrEsP/28vDnQatU/cplFLiWz9+Xda >8lscV2uhxEaQYHgy4wvsd03vgfFCE/RfG7AwX8h1+S7XDUg27GpUHLPeXJesF6cy >WOSnzYN6K/WmDMn8AKYv+/FDYf6JdB5yc0zmiivAbOTDwsi6LTbRMvwRhMyUXlEM >OeZlbZz5GkyMmDccUNSjS6B8WrGnxilnQX07c7bRgeq9DR5DB8QwaRsg66Z757Bi >vSqDAG/87aKU8Pov5gRRHNY9QskOneuFWEIOO4pl+eqodx3c45Lyx7Ain7vjy/nO >l92FTyOyf47I99vWWyrit/KBPImxNFnP2txZu1WuWXz/yNYCKxrOMiTdIycjVwVK >7jpfcAtC7IB11+nMTy4xNl4kzRBcZnCXVaWhZ+b+5/SuZX4qKrwB4YeFlQQKJXXY >+F9XeG1MAjaF4qmNFeLsIUO0wadRXQ23RSlKfDqNe8s+Y2BsvoUepzxmsbSsJCJ0 >NAGEGNqBnwXQwbaJO9MtTU0RzXbe1KzJw26eHY5/nfCBfyn2hYw9TjzH0cmAOOXX >IcxVYBfJLu/tUNvxtpaPhlu3yvzcU99KxdjLpBsD/wOk4mfblg9AAZiwxXdq5k7+ >nCSPz+CodE2OWt7UsqdCIdBiW/yaC2qnLcnMw197lRxJnDwE2NrbQx72AQAd6u9Z >ndxTiZ7dEsIuOJE0OCaL >=3D4SpJ >-----END PGP SIGNATURE----- > >_______________________________________________ >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 -- Best regards, Kathleen --_000_785DB11636645E438E2E096E1ADA47C402D16FNABESITEInterDigi_ Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable

Hi Paul,

 <= /p>

From: Paul L= ambert [mailto:paul@marvell.com]
Sent: Tuesday, October 07, 2014 9:50 PM
To: Kathleen Moriarty
Cc: perpass@ietf.org; Joseph Lorenzo Hall
Subject: Re: [perpass] IAB security/privacy programme PM draft<= /o:p>

 

 

 

 

 

On Tue, Oct 7, 2014 at 1:45= PM, Paul Lambert <paul@marvell.com> wrote:


On 10/7/14, 9:35 AM, "Joseph Lorenzo Hall" <joe@cdt.org> wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA256
>
>As the showrunner for the confidentiality effort in the IAB privacy
>and security program, please do share your feedback with us.


Great document =A9 some observations on a missing topic area:


The draft-iab-privsec-confidentiality-threat-00 provides a good
overview of many issues, but does not mention the problems associated
with static MAC addresses. MAC addresses, while perhaps considered
beneath the purview of IETF have a significant impact on the system
considerations for private Internet communications.

MAC addresses are assigned to device interfaces to support
link level communications on subnets.  These addresses are assigned through a global registry with allocations to individual companies to
distribute unique assignments.  Being unique, the MAC addresses are often used as a device identification.  Some operating systems use
a device MAC address to create a GUID (globally unique identifier)
that is then used to identify the host.  The GUID is then embedded
in documents to identify the source platform.

MAC addresses are used to create IPv6 addresses.  The unique MAC addre= ss
provides a convenient  mechanisms to assign a unique IP address.
This convenience for unique IPv6 assignment makes a unique
MAC address an integral part of many emerging architectures
(e.g for IoT). Binding the device unique MAC address to an IPv6
address makes the communicating device identifiable by
any observer end-to-end.

Static MAC addresses are a particularly serious problem in
wireless networks.  Simply sniffing of traffic provides
the device unique address which is readily correlated
to the specific user.

IEEE 802 does provide facilities for local MAC addresses.  The
local MAC addresses are not used widely and have been applied
primarily for special purpose protocol applications
(e.g. Local MAC used as BSSID for IBSS).  The local MAC
addresses does allow a random address to be used for the link
provides significant improvements for privacy, but the
impact on bridging, routing and device authentication need
to be considered.  Frequently changing MAC addresses will
Potentially overflow routing tables.  DHCP servers may run
out of available addresses.  Guidelines for protocols that
use MAC addresses will need to be developed to prevent
disruption of network communications.  Some IETF protocols
may need to be modified to facilitate the use of local
MAC addresses.

 

Thanks, Paul.  We've b= een working with the IEEE and in particular with Juan Carlos Zuniga on this= topic.  He has talked to us about work the IEEE is doing and presented at the last SAAG meeting.  Your points are good ones on the= interconnection between their work and ours.

Yes, I’ve been pushin= g this in IEEE and the WFA for a year or two …

 

We do have one specificatio= n already in the Wi-FI Alliance that will be using link local MAC addresses= (to be announced soon).  I’m optimistic that this will see some broad adoption, however, it is not your standard client to hotspo= t messaging so there is still more work to do.  I’m hoping that = some devices will support both this new and old mode of operation simultane= ously and so adopt changing MAC addresses.   Right now these recommendations for changing address are a little l= oose and only stipulate that the MAC address should remain the same for at = least 30 minutes.

 

The point in the narrative = above, was not so much to describe the work in IEEE that may be out-of-scop= e for the IETF, but to indicate that work in the IETF will be required to adapt to constantly changing MAC addresses.  

[JCZ] Yes, this is = something that concerns IETF and that’s why we are coordinating as mu= ch as possible the joint effort between IEEE 802 and IETF.

One of the main out= comes of the potential MAC randomization trial would be to highlight the im= plications of MAC address changes on IETF protocols. As you know, so far we have identified potential repercussions on DHCP, ARP/N= D, IPv6 SAA, switches and AAA infrastructure. Whether these will require ch= anges in the actual protocols or just changes/recommendations for configura= tion, is still FFS.

Regards,=

Juan Carlos<= /i>

 

Paul

 

 

 

Here are his slides from th= e last SAAG meeting, this set doesn't go deep into that topic though.<= /o:p>

 

 

 

 




>We are
>also contemplating a companion document on mitigations for the threats<= br> >outlined in the threat model.

=A9  if we want to build a private Internet
we should ensure that we have a solid foundation at the
bottom of the stack (MAC addresses).  Addressing architectures
must be be reconsidered to ensure that a static address is not
necessary.  Identity should not be an addresses, but some other
non-assigned locally generated identifier that can be bound
to a end device cryptographically.

Paul




>
>best, Joe
>
>On 9/15/14, 10:56 AM, Stephen Farrell wrote:
>>
>> Hi all,
>>
>> Richard and a few folks started work on documenting a problem
>> statement [1] some time ago. As I think was stated here before it<= br> >> seems like a good plan for that to be progressed as part of the >> IAB's re-factored security/privacy programme. So Brian Trammell ha= s
>> picked up the pen and pushed out [2].
>>
>> Comments very welcome (I've still to read it myself so will send m= y
>> comments here too when I've had a chance),
>>
>> Cheers, S.
>>
>>
>> [1] http://tools.ietf.org/html/draft-barnes-pervasive-problem [2]
>> https://tools.ietf.org/html/draft-iab-privsec-confidentiality-threat >>
>>  _______________________________________________ perpass mail= ing
>> list perpass@ietf.org
>> https://www.ietf.org/mailman/listinfo/perpass
>>
>
>- --
>Joseph Lorenzo Hall
>Chief Technologist
>Center for Democracy & Technology
>1634 I ST NW STE 1100
>Washington DC 20006-4011
>(p) 202-407-8825
>(f) 202-637-0968
>joe@cdt.org
>PGP: https= ://josephhall.org/gpg-key
>fingerprint: 3CA2 8D7B 9F6D DBD3 4B10  1607 5F86 6987 40A9 A871 >
>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.4.13 (Darwin)
>
>iQIcBAEBCAAGBQJUNBZEAAoJEF+GaYdAqahxrEsP/28vDnQatU/cplFLiWz9+Xd= a
>8lscV2uhxEaQYHgy4wvsd03vgfFCE/RfG7AwX8h1+S7XDUg27GpUHLPeXJesF6cy >WOSnzYN6K/WmDMn8AKYv+/FDYf6JdB5yc0zmiivAbOTDwsi6LTbRMvwRhMyUXlEM >OeZlbZz5GkyMmDccUNSjS6B8WrGnxilnQX07c7bRgeq9DR5DB8QwaRsg66Z757Bi
>vSqDAG/87aKU8Pov5gRRHNY9QskOneuFWEIOO4pl+eqodx3c45Lyx7Ain7vjy/nO >l92FTyOyf47I99vWWyrit/KBPImxNFnP2txZu1WuWXz/yNYCKxrOMiTdIycjVwVK
>7jpfcAtC7IB11+nMTy4xNl4kzRBcZnCXVaWhZ+b+5/SuZX4qKrwB4YeFlQQ= KJXXY
>+F9XeG1MAjaF4qmNFeLsIUO0wadRXQ23RSlKfDqNe8s+Y2BsvoUepzxmsbSsJCJ= 0
>NAGEGNqBnwXQwbaJO9MtTU0RzXbe1KzJw26eHY5/nfCBfyn2hYw9TjzH0cmAOOXX
>IcxVYBfJLu/tUNvxtpaPhlu3yvzcU99KxdjLpBsD/wOk4mfblg9AAZiwxXdq5k7+ >nCSPz+CodE2OWt7UsqdCIdBiW/yaC2qnLcnMw197lRxJnDwE2NrbQx72AQAd6u9Z >ndxTiZ7dEsIuOJE0OCaL
>=3D4SpJ
>-----END PGP SIGNATURE-----
>
>_______________________________________________
>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



 

--

 

Best regards,

Kathleen<= /p>

 

 

--_000_785DB11636645E438E2E096E1ADA47C402D16FNABESITEInterDigi_-- From nobody Mon Oct 20 01:42:18 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F98C1A6FE7 for ; Mon, 20 Oct 2014 01:42:17 -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 CTlPQrX8iJnr for ; Mon, 20 Oct 2014 01:42:16 -0700 (PDT) Received: from mail.bortzmeyer.org (aetius.bortzmeyer.org [IPv6:2001:4b98:dc0:41:216:3eff:fece:1902]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E68081A0AF7 for ; Mon, 20 Oct 2014 01:42:15 -0700 (PDT) Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 9F6A43BAD6; Mon, 20 Oct 2014 10:42:14 +0200 (CEST) Received: by tyrion (Postfix, from userid 1000) id 09E27F00A71; Mon, 20 Oct 2014 10:36:44 +0200 (CEST) Date: Mon, 20 Oct 2014 10:36:44 +0200 From: Stephane Bortzmeyer To: perpass@ietf.org Message-ID: <20141020083644.GA32187@laperouse.bortzmeyer.org> References: <20141006101201.GA17335@nic.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141006101201.GA17335@nic.fr> X-Transport: UUCP rules X-Operating-System: Ubuntu 14.04 (trusty) User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/perpass/dnagucvRRJclsIc-ViAnIV36ptc Subject: Re: [perpass] [iesg-secretary@ietf.org: WG Review: DNS PRIVate Exchange (dprive)] X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "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, 20 Oct 2014 08:42:17 -0000 On Mon, Oct 06, 2014 at 12:12:01PM +0200, Stephane Bortzmeyer wrote a message of 193 lines which said: > This is relevant for this list. (But note the comments are to be sent > to IESG.) The DPRIVE working group (work on some aspects of DNS privacy) has been created. It is currently discussing the adoption of its first draft. http://datatracker.ietf.org/wg/dprive/charter/ From nobody Mon Oct 27 00:46:51 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 022AF1A8A11; Mon, 27 Oct 2014 00:46:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.14 X-Spam-Level: * X-Spam-Status: No, score=1.14 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_FR=0.35, 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 ZRU60GUzWpPq; Mon, 27 Oct 2014 00:46:45 -0700 (PDT) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB3751A8A0E; Mon, 27 Oct 2014 00:46:45 -0700 (PDT) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id E5F162801BD; Mon, 27 Oct 2014 08:46:43 +0100 (CET) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx4.nic.fr (Postfix) with ESMTP id E143028014A; Mon, 27 Oct 2014 08:46:43 +0100 (CET) Received: from bortzmeyer.nic.fr (unknown [IPv6:2001:67c:1348:7::86:133]) by relay1.nic.fr (Postfix) with ESMTP id D54604C0081; Mon, 27 Oct 2014 08:46:13 +0100 (CET) Date: Mon, 27 Oct 2014 08:46:13 +0100 From: Stephane Bortzmeyer To: dns-privacy@ietf.org, perpass@ietf.org Message-ID: <20141027074613.GA14729@nic.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: Debian GNU/Linux jessie/sid X-Kernel: Linux 3.16-2-686-pae i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/perpass/6DWk3HeF8ggcQItk4qA6me7_ZRc Subject: [perpass] Privacy for engineers X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "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, 27 Oct 2014 07:46:48 -0000 Good reading about the "blind spots" of engineers about privacy: http://lockstep.com.au/blog/2014/08/28/engineers-and-privacy From nobody Mon Oct 27 06:17:16 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B31A1A8028 for ; Mon, 27 Oct 2014 06:12:55 -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 oyJ2aEHrkiIy for ; Mon, 27 Oct 2014 06:12:53 -0700 (PDT) Received: from mail-ob0-f179.google.com (mail-ob0-f179.google.com [209.85.214.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48A411AC3FC for ; Mon, 27 Oct 2014 06:12:50 -0700 (PDT) Received: by mail-ob0-f179.google.com with SMTP id m8so1214158obr.10 for ; Mon, 27 Oct 2014 06:12:49 -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:date :message-id:subject:from:to:cc:content-type; bh=tkIx2gk3NbUjHkvoEE+ZCNbpN3MNLcbdNShEYmxpm2g=; b=YBreya/8HhVjpa4HpV02Tro7MOBJseKwnVFhbmeVVnpuHY6Knk8wnxvtXxMQjGu52V ERAx7VBEVBcRd88Ops9RMufHOO7F1hKjIM/++Zfq2xwNZY1wntZSMVroMmuqsufwg5KV MITI1uY1GLesPtSc553n8NdalXSvlSYiEJHzBxSkyV+gpTeIsZUr3+GvQcu5ZTfJKT9Z 5yjxPNK1Pyd7LHPiAYhmEx1HUwRLtNp3a2ykL2Gw6URo0fA70uevLVYO/v9EKHgHjR3R E8LzAuRFCPWUqkjHsvsF4pR13aCPMkrbhX5lEvimNA3eG3XGZlsaSuMtmwXM2HzCLgEq oO+A== X-Gm-Message-State: ALoCoQnHufFZkjqdLHvvWLGAxLR7dslQ4lwhb8fejizAFF4Clm3+jcZGFJOoCsmYrjYZO3yGcpUu MIME-Version: 1.0 X-Received: by 10.202.56.6 with SMTP id f6mr1887849oia.68.1414415569351; Mon, 27 Oct 2014 06:12:49 -0700 (PDT) Received: by 10.76.133.130 with HTTP; Mon, 27 Oct 2014 06:12:49 -0700 (PDT) In-Reply-To: <20141027074613.GA14729@nic.fr> References: <20141027074613.GA14729@nic.fr> Date: Mon, 27 Oct 2014 09:12:49 -0400 Message-ID: From: Bob Harold To: Stephane Bortzmeyer Content-Type: multipart/alternative; boundary=001a113cc6c6939098050667493e Archived-At: http://mailarchive.ietf.org/arch/msg/perpass/Od4aJoPZIRdQNQjMZLcjy6G4vPs X-Mailman-Approved-At: Mon, 27 Oct 2014 06:16:59 -0700 Cc: "dns-privacy@ietf.org" , perpass@ietf.org Subject: Re: [perpass] [dns-privacy] Privacy for engineers X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "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, 27 Oct 2014 13:12:55 -0000 --001a113cc6c6939098050667493e Content-Type: text/plain; charset=UTF-8 Good reading, but I cannot agree with "the definition of PII is clear cut". Rather "*any* information pertaining to an identifiable individual" is extremely vague. And when they want us to try to 'secure' information that is already 'public', we have to scratch our heads and wonder. But at least he admits that there are tradeoffs. The law (or a typical organization's policy) does not seem to understand that. Disclaimer: definitely not speaking for my employer. -- Bob Harold On Mon, Oct 27, 2014 at 3:46 AM, Stephane Bortzmeyer wrote: > Good reading about the "blind spots" of engineers about privacy: > > http://lockstep.com.au/blog/2014/08/28/engineers-and-privacy > > _______________________________________________ > dns-privacy mailing list > dns-privacy@ietf.org > https://www.ietf.org/mailman/listinfo/dns-privacy > --001a113cc6c6939098050667493e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Good reading, but I cannot agree with "the definiti= on of PII is clear cut". =C2=A0 Rather "any=C2=A0inf= ormation pertaining to an identifiable individual" is extremely vague.= =C2=A0 And when they want us to try to 'secure' information that is= already 'public', we have to scratch our heads and wonder.<= div>But at least he admits that there are tradeoffs.=C2=A0 The law (or a = typical organization's policy) does not seem to understand that.=

Disclaimer: defini= tely not speaking for my employer.

--
Bob Har= old


On Mon, Oct 27, 2014 at 3:46 AM, Stephane Bo= rtzmeyer <bortzmeyer@nic.fr> wrote:
Good reading about the "blind spots" of engineers abou= t privacy:

http://lockstep.com.au/blog/2014/08/28/engineers-and-privac= y

_______________________________________________
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

--001a113cc6c6939098050667493e-- From nobody Mon Oct 27 07:54:59 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9009D1A87D4; Mon, 27 Oct 2014 07:51:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.365 X-Spam-Level: X-Spam-Status: No, score=0.365 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_ONLINE=2.3, 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 IM4C8lEtyB8g; Mon, 27 Oct 2014 07:51:50 -0700 (PDT) Received: from hub028-ca-6.exch028.serverdata.net (hub028-ca-6.exch028.serverdata.net [64.78.52.30]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 099941A87E2; Mon, 27 Oct 2014 07:51:50 -0700 (PDT) Received: from MBX028-W1-CA-2.exch028.domain.local ([10.254.18.52]) by HUB028-CA-6.exch028.domain.local ([10.254.18.230]) with mapi id 14.03.0174.001; Mon, 27 Oct 2014 07:51:49 -0700 From: Don Blumenthal To: Stephane Bortzmeyer , "dns-privacy@ietf.org" , "perpass@ietf.org" Thread-Topic: [dns-privacy] Privacy for engineers Thread-Index: AQHP8borcEVmNRUQuEeczgIqSAS3cpxEBHQw Date: Mon, 27 Oct 2014 14:51:48 +0000 Message-ID: References: <20141027074613.GA14729@nic.fr> In-Reply-To: <20141027074613.GA14729@nic.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [108.211.201.119] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/perpass/72shB85cJcGw5CKjr7JIulCYlPs X-Mailman-Approved-At: Mon, 27 Oct 2014 07:54:26 -0700 Subject: Re: [perpass] [dns-privacy] Privacy for engineers X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "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, 27 Oct 2014 14:51:51 -0000 Thanks, Stephane.=20 The article is excellent in discussing the intersection of privacy issues a= nd ICT. However, "[o]nline and in privacy law alike, things are very crisp.= " Maybe they are in Australia. However, one of the big challenges in the p= rivacy space is that definitions of PI, PII, and similar acronymed (word?) = concepts vary widely and may not be spelled at all in some jurisdictions. I find it curious that Mr. Wilson makes such a categorical statement in thi= s article while linking to another post where he discusses definitional unc= ertainties. http://lockstep.com.au/blog/2013/09/27/pii-or-not-pii. It was w= orthwhile following his links to get a full picture. Don -----Original Message----- From: dns-privacy [mailto:dns-privacy-bounces@ietf.org] On Behalf Of Stepha= ne Bortzmeyer Sent: Monday, October 27, 2014 3:46 AM To: dns-privacy@ietf.org; perpass@ietf.org Subject: [dns-privacy] Privacy for engineers Good reading about the "blind spots" of engineers about privacy: http://lockstep.com.au/blog/2014/08/28/engineers-and-privacy _______________________________________________ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy