From stephen.farrell@cs.tcd.ie Wed Aug 14 17:04:58 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC72121F9ABB for ; Wed, 14 Aug 2013 17:04:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ymVUm8NDspDy for ; Wed, 14 Aug 2013 17:04:46 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 6958B21F8E7C for ; Wed, 14 Aug 2013 17:04:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 97F8CBE53 for ; Thu, 15 Aug 2013 01:04:40 +0100 (IST) 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 pjxhx1qSGMCS for ; Thu, 15 Aug 2013 01:04:39 +0100 (IST) Received: from [10.87.48.8] (unknown [86.44.78.40]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 3F373BE38 for ; Thu, 15 Aug 2013 01:04:39 +0100 (IST) Message-ID: <520C1B0D.4030607@cs.tcd.ie> Date: Thu, 15 Aug 2013 01:04:29 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: perpass@ietf.org X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [perpass] List scope X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2013 00:04:58 -0000 This'll be elsewhere, but no harm having it in the archive too. S. The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. The list is not intended to be a precursor to formation of a Working Group, but rather to (for example) discuss ways in which IETF protocols at any layer can be made more robust against pervasive passive monitoring. If subsequent protocol work is to be done in the IETF, that would likely happen in existing or new protocol-specific Working Groups. From ietf-secretariat@ietf.org Thu Aug 15 08:15:00 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C77121F9A74; Thu, 15 Aug 2013 08:14:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tERziF3Ip73k; Thu, 15 Aug 2013 08:14:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 83D1F21F88BA; Thu, 15 Aug 2013 08:14:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: IETF Announcement List X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130815151448.6751.75655.idtracker@ietfa.amsl.com> Date: Thu, 15 Aug 2013 08:14:48 -0700 Cc: perpass@ietf.org, turners@ieca.com, stephen.farrell@cs.tcd.ie Subject: [perpass] New Non-WG Mailing List: perpass X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2013 15:15:00 -0000 A new IETF non-working group email list has been created. List address: perpass@ietf.org Archive: http://www.ietf.org/mail-archive/web/perpass/ To subscribe: https://www.ietf.org/mailman/listinfo/perpass Purpose: The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. The list is not intended to be a precursor to formation of a Working Group, but rather to (for example) discuss ways in which IETF protocols at any layer can be made more robust against pervasive passive monitoring. If subsequent protocol work is to be done in the IETF, that would likely happen in existing or new protocol-specific Working Groups. For additional information, please contact the list administrators. From stephen.farrell@cs.tcd.ie Fri Aug 16 09:42:51 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EC2B11E8193 for ; Fri, 16 Aug 2013 09:42:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jeQ+x8PwVGWL for ; Fri, 16 Aug 2013 09:42:46 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id DC5D611E8169 for ; Fri, 16 Aug 2013 09:42:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id A53EEBE59 for ; Fri, 16 Aug 2013 17:42:44 +0100 (IST) 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 0hdPuLwp68sl for ; Fri, 16 Aug 2013 17:42:44 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 7D551BE58 for ; Fri, 16 Aug 2013 17:42:44 +0100 (IST) Message-ID: <520E5684.1090005@cs.tcd.ie> Date: Fri, 16 Aug 2013 17:42:44 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: perpass@ietf.org X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [perpass] Getting started... X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2013 16:42:51 -0000 Hi all, We've enough folks subscribed now (50ish) to kick off. For those who weren't in Berlin, here's a bit of context. We had a (hastily arranged:-) meeting after the tech plenary with about 30 or so folks including Jacob and Linus from the Tor project. Topics ranged from that day's announcements from the Guardian newspaper to issues the Tor project have faced with fingerprinting, and that lead to a good discussion about how the current threat models we use in the IETF (whether more or less formally) don't usually take into account the potential for very widespread passive (or active) monitoring of nodes using IETF protocols. That was followed up in the bar in various ways (please chime in if you remember bits of that or the earlier chat I've missed out on:-) and we figured that setting up this list would be a good starting point for us to try see what work related to this topic might make sense in the IETF. You should have seen the scope Sean and I figured might work for this list [1] so let's try to keep to that, but its not a strict charter or anything so don't be too constrained by it for now. As this is an IETF list, normal rules (IPR and netiquette) apply, if you're not sure if something is appropriate for this list, feel free to ask Sean or I offlist, but our hope is to try make progress on some or all of the following: - experiences with IETF protocols and how they allow for fingerprinting and monitoring, esp. in unexpected ways - things we might practically do about that in the IETF, ideally in terms of concrete ideas for protocol or operational changes, and even more ideally with protocols that have active working groups who're interested in taking on such work - ideas for new work that'd make our protocols more robust in the face of such pervasive monitoring - descriptions of new threat models that might help people doing protocol work in the IETF - how to get to a "privacy by default" situation as Randy called it - whatever else fits the scope:-) The only thing to add to that for now is that since the kinds of monitoring we're considering can be done at many layers, we should not only be considering the web, or application layer or just security protocols, but the full suite of protocols and areas in which the IETF works. And as usual, since its an IETF list, people need to grab a topic and organise themselves to do the work or it probably won't happen. But Sean and I are both supportive of this and willing to help make sensible stuff happen if we can. So over to you, what should we be doing? Thanks, Sean & Stephen. [1] http://www.ietf.org/mail-archive/web/ietf-announce/current/msg11780.html From sm@resistor.net Fri Aug 16 17:41:54 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3473B11E8158 for ; Fri, 16 Aug 2013 17:41:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.404 X-Spam-Level: X-Spam-Status: No, score=-102.404 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sLfhXs+4CQnq for ; Fri, 16 Aug 2013 17:41:53 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 38B8811E80D7 for ; Fri, 16 Aug 2013 17:41:53 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r7H0eREs006052; Fri, 16 Aug 2013 17:40:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1376700033; bh=vxuzcHLmH0TzY9eWQ2YJyTd6ooRZjWJliiMCyA+Y/a0=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=vfvhuj1vfs/cvItdZ+wfblT2z4CDKMXVVYh6sLHZ34vyunY9dJV1j9fSd2EvGzBrP 1stiK6F1M9JUzb/ffrNdPpWJr1fgfWaR7xwRLSFZg3qW2RE2/orbkbMTKhLn8OAuNL W/8nGKfdBY9kcPBfkH3XuFRJxUVr9nefTgTI71+w= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1376700033; i=@resistor.net; bh=vxuzcHLmH0TzY9eWQ2YJyTd6ooRZjWJliiMCyA+Y/a0=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=KfnqNaV2a3X6rEh191kziXhBpaR3Sgf6dLhphDpjYT00Ixi2XT3l9I2tFXdyAaOv1 gYfig7FqjDhwhliw9sWIn6kJHVkr50ovFXnvmWTju+O4CBhRceLa4FYTLZgqJG9PUR f6AgcTEt+e/qGRZ+hIiaGw6QKx4wccItAo0t4Xjw= Message-Id: <6.2.5.6.2.20130816171144.0c01f738@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 16 Aug 2013 17:40:12 -0700 To: Stephen Farrell From: SM In-Reply-To: <520E5684.1090005@cs.tcd.ie> References: <520E5684.1090005@cs.tcd.ie> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: perpass@ietf.org Subject: Re: [perpass] Getting started... X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Aug 2013 00:41:54 -0000 Hi Stephen, At 09:42 16-08-2013, Stephen Farrell wrote: >IETF list, normal rules (IPR and netiquette) apply, if you're not >sure if something is appropriate for this list, feel free to ask Sean >or I offlist, but our hope is to try make progress on some or all of >the following: > >- experiences with IETF protocols and how they allow for > fingerprinting and monitoring, esp. in unexpected ways >- things we might practically do about that in the IETF, ideally in > terms of concrete ideas for protocol or operational changes, and even > more ideally with protocols that have active working groups who're > interested in taking on such work >- ideas for new work that'd make our protocols more robust in the > face of such pervasive monitoring >- descriptions of new threat models that might help people doing > protocol work in the IETF >- how to get to a "privacy by default" situation as Randy called > it >- whatever else fits the scope:-) > >The only thing to add to that for now is that since the kinds of >monitoring we're considering can be done at many layers, we should >not only be considering the web, or application layer or just >security protocols, but the full suite of protocols and areas in >which the IETF works. "Privacy by default" has, up to now, been a failure in the IETF. As you pointed out things do not happen unless someone volunteers to do the work. There has been a lack of volunteers. I don't know why. I don't know who is trying to fix that. Discussions about monitoring is a sensitive subject. I am curious to see whether the 50 people are willing to discuss about that on this mailing list. :-) Regards, -sm From stephen.farrell@cs.tcd.ie Sat Aug 17 03:05:44 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2B8F21F888F for ; Sat, 17 Aug 2013 03:05:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vSOlwBtJPade for ; Sat, 17 Aug 2013 03:05:36 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id ADB5F21F8CDD for ; Sat, 17 Aug 2013 03:05:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C79B0BE29; Sat, 17 Aug 2013 11:05:24 +0100 (IST) 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 C+4SRt2PblBY; Sat, 17 Aug 2013 11:05:23 +0100 (IST) Received: from [10.87.48.8] (unknown [86.44.67.197]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id EDEC7BE25; Sat, 17 Aug 2013 11:05:22 +0100 (IST) Message-ID: <520F4AE1.5040403@cs.tcd.ie> Date: Sat, 17 Aug 2013 11:05:21 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: SM References: <520E5684.1090005@cs.tcd.ie> <6.2.5.6.2.20130816171144.0c01f738@resistor.net> In-Reply-To: <6.2.5.6.2.20130816171144.0c01f738@resistor.net> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: perpass@ietf.org Subject: Re: [perpass] Getting started... X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Aug 2013 10:05:45 -0000 Hi SM, On 08/17/2013 01:40 AM, SM wrote: > Hi Stephen, > At 09:42 16-08-2013, Stephen Farrell wrote: >> IETF list, normal rules (IPR and netiquette) apply, if you're not >> sure if something is appropriate for this list, feel free to ask Sean >> or I offlist, but our hope is to try make progress on some or all of >> the following: >> >> - experiences with IETF protocols and how they allow for >> fingerprinting and monitoring, esp. in unexpected ways >> - things we might practically do about that in the IETF, ideally in >> terms of concrete ideas for protocol or operational changes, and even >> more ideally with protocols that have active working groups who're >> interested in taking on such work >> - ideas for new work that'd make our protocols more robust in the >> face of such pervasive monitoring >> - descriptions of new threat models that might help people doing >> protocol work in the IETF >> - how to get to a "privacy by default" situation as Randy called >> it >> - whatever else fits the scope:-) >> >> The only thing to add to that for now is that since the kinds of >> monitoring we're considering can be done at many layers, we should >> not only be considering the web, or application layer or just >> security protocols, but the full suite of protocols and areas in >> which the IETF works. > > "Privacy by default" has, up to now, been a failure in the IETF. Not sure that I agree. We don't do that, sure. But it'll only be a failure when we've actually tried, and we've not. And partly that's because not enough of us know what can be done. > As you > pointed out things do not happen unless someone volunteers to do the > work. There has been a lack of volunteers. I don't know why. I don't > know who is trying to fix that. "We" are trying to fix that, where we == this list. > Discussions about monitoring is a sensitive subject. Yes. However, even those who want to be able to monitor at point X, probably don't want their sensitive stuff monitored at points Y,Z,... So you don't actually have to have inhaled all the fumes to think its a good plan for Internet protocols to be more robust against pervasive monitoring. > I am curious to > see whether the 50 people are willing to discuss about that on this > mailing list. :-) I hope so. We had some good discussions in Berlin at any rate and my hope is that at least the people involved in that will chime in. But I guess we'll see when we see. S. > > Regards, > -sm > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > From trammell@tik.ee.ethz.ch Sat Aug 17 03:17:58 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 635AD11E80D9 for ; Sat, 17 Aug 2013 03:17:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iMDrzbURuTDV for ; Sat, 17 Aug 2013 03:17:52 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 7A7A811E80DF for ; Sat, 17 Aug 2013 03:17:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 85DE6D9316; Sat, 17 Aug 2013 12:17:46 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id wsWdoXQk1XKy; Sat, 17 Aug 2013 12:17:46 +0200 (MEST) Received: from [10.0.27.100] (cust-integra-122-165.antanet.ch [80.75.122.165]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 284CBD9307; Sat, 17 Aug 2013 12:17:46 +0200 (MEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Brian Trammell In-Reply-To: <520F4AE1.5040403@cs.tcd.ie> Date: Sat, 17 Aug 2013 12:17:44 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <520E5684.1090005@cs.tcd.ie> <6.2.5.6.2.20130816171144.0c01f738@resistor.net> <520F4AE1.5040403@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1508) Cc: SM , perpass@ietf.org Subject: Re: [perpass] Getting started... X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Aug 2013 10:17:58 -0000 hi SM, Stephen, all, On Aug 17, 2013, at 12:05 PM, Stephen Farrell = wrote: >=20 >> Discussions about monitoring is a sensitive subject. =20 >=20 > Yes. However, even those who want to be able to monitor at point X, > probably don't want their sensitive stuff monitored at points Y,Z,... > So you don't actually have to have inhaled all the fumes to think > its a good plan for Internet protocols to be more robust against > pervasive monitoring. >=20 >> I am curious to >> see whether the 50 people are willing to discuss about that on this >> mailing list. :-) >=20 > I hope so. We had some good discussions in Berlin at any rate and > my hope is that at least the people involved in that will chime in. > But I guess we'll see when we see. There's also a difference between the threat models of pervasive = monitoring (an analysis of what can be done) and operational practice (a = report of what _is_ done). We should, to the extent possible, work from = the former, referring to the latter anecdotally -- because that, I = suspect, is all we're going to get. Of course, if the threat model is "the adversary cooperates with the = endpoint(s) of the communication", there's not a whole lot you can do at = the protocol level. But that is, I think, a point for wider discussion, = and there is significant work to be done, even if it just ends up being = a cross-area awareness-building exercise; on which more soon. Cheers, Brian= From randy@psg.com Sat Aug 17 03:19:06 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDDE111E80DF for ; Sat, 17 Aug 2013 03:19:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.516 X-Spam-Level: X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zlCGdxyCq6qt for ; Sat, 17 Aug 2013 03:19:06 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id 619CD21F9A25 for ; Sat, 17 Aug 2013 03:19:03 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1VAdb1-0000BO-Ab; Sat, 17 Aug 2013 10:18:59 +0000 Date: Sat, 17 Aug 2013 19:18:57 +0900 Message-ID: From: Randy Bush To: Stephen Farrell In-Reply-To: <520F4AE1.5040403@cs.tcd.ie> References: <520E5684.1090005@cs.tcd.ie> <6.2.5.6.2.20130816171144.0c01f738@resistor.net> <520F4AE1.5040403@cs.tcd.ie> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: perpass@ietf.org Subject: Re: [perpass] Getting started... X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Aug 2013 10:19:06 -0000 > I hope so. We had some good discussions in Berlin at any rate and my > hope is that at least the people involved in that will chime in. But > I guess we'll see when we see. ok, ok. imiho, there are a vast number of areas we can improve. as you point out, a privacy version of jeff's danvers rfc is one start. another is just painting privacy by default on the walls at home. i know bgp payload does not excite a lot of folk, but encrypting it makes ip space tracability just that much harder. and opportunistic encryption would be trivial to negotiate in the bgp open. and i am looking at bgpsec doing payload encryption. i would love it if my email client ( well, normal email clients :-) automagically encrypted to the recipients for whom i have a public key. maybe the folk way up there at layer seven can come up with an even better idea. i could drivel on. but there are a lot of folk far smarter at this stuff than i. oh, and can we try to take the constructive road, not the negative games? my .procmailrc is too long already. randy From stephen.farrell@cs.tcd.ie Sat Aug 17 03:30:30 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A769721F9958 for ; Sat, 17 Aug 2013 03:30:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H5X62jtkE1ZR for ; Sat, 17 Aug 2013 03:30:24 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id A8EB521F8C0C for ; Sat, 17 Aug 2013 03:30:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 0BCCBBE25; Sat, 17 Aug 2013 11:30:24 +0100 (IST) 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 AwE22j-JL2S0; Sat, 17 Aug 2013 11:30:23 +0100 (IST) Received: from [10.87.48.8] (unknown [86.44.67.197]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 7F0B0BE24; Sat, 17 Aug 2013 11:30:23 +0100 (IST) Message-ID: <520F50B5.1010209@cs.tcd.ie> Date: Sat, 17 Aug 2013 11:30:13 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: Brian Trammell References: <520E5684.1090005@cs.tcd.ie> <6.2.5.6.2.20130816171144.0c01f738@resistor.net> <520F4AE1.5040403@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: SM , perpass@ietf.org Subject: Re: [perpass] Getting started... X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Aug 2013 10:30:30 -0000 Hi Brian, On 08/17/2013 11:17 AM, Brian Trammell wrote: > Of course, if the threat model is "the adversary cooperates with the > endpoint(s) of the communication", there's not a whole lot you can do > at the protocol level. That's correct. But (and yes, anecdotally;-) the submarine cable monitoring was apparently done with the co-operation of the cable owners and not of (all) the n/w operators using those cables. So even when there is "co-operation," it may be that not everyone at every n/w layer is co-operating. > But that is, I think, a point for wider > discussion, and there is significant work to be done, even if it just > ends up being a cross-area awareness-building exercise; on which more > soon. Looking forward to that. S. From stephen.farrell@cs.tcd.ie Sat Aug 17 03:37:28 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A44821F9BBD for ; Sat, 17 Aug 2013 03:37:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JZ+pv88wm32n for ; Sat, 17 Aug 2013 03:37:20 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id E492B21F9BC3 for ; Sat, 17 Aug 2013 03:37:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 30C84BE25; Sat, 17 Aug 2013 11:37:17 +0100 (IST) 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 TjYosNPqSs0p; Sat, 17 Aug 2013 11:37:16 +0100 (IST) Received: from [10.87.48.8] (unknown [86.44.67.197]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 8B0B4BE24; Sat, 17 Aug 2013 11:37:16 +0100 (IST) Message-ID: <520F525C.5020800@cs.tcd.ie> Date: Sat, 17 Aug 2013 11:37:16 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: Randy Bush References: <520E5684.1090005@cs.tcd.ie> <6.2.5.6.2.20130816171144.0c01f738@resistor.net> <520F4AE1.5040403@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: perpass@ietf.org Subject: Re: [perpass] Getting started... X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Aug 2013 10:37:28 -0000 Hi Randy, On 08/17/2013 11:18 AM, Randy Bush wrote: >> I hope so. We had some good discussions in Berlin at any rate and my >> hope is that at least the people involved in that will chime in. But >> I guess we'll see when we see. > > ok, ok. > > imiho, there are a vast number of areas we can improve. as you point > out, a privacy version of jeff's danvers rfc is one start. another is > just painting privacy by default on the walls at home. > > i know bgp payload does not excite a lot of folk, but encrypting it > makes ip space tracability just that much harder. and opportunistic > encryption would be trivial to negotiate in the bgp open. and i am > looking at bgpsec doing payload encryption. I think that's a great example of the kind of nob-obvious changes that could be useful and doable. I'd welcome more... and since we're just starting out, makng a list of those would maybe be a useful thing so it'd be great to get suggestions for putting on that list... > i would love it if my email client ( well, normal email clients :-) > automagically encrypted to the recipients for whom i have a public key. > maybe the folk way up there at layer seven can come up with an even > better idea. My own fav. would be to actually encrypt the entire message, incl. sensitive header fields (e.g. To: From: Subject:) - without that PGP and S/MIME seem to still expose too much to the pervasive monitor. > i could drivel on. but there are a lot of folk far smarter at this > stuff than i. > > oh, and can we try to take the constructive road, not the negative > games? my .procmailrc is too long already. Hope so. But in this case I'm more confident than elsewhere, for this list. (That is, until we turn up on some wg's list with our great plan for fixing their stuff. Things might get more challenging then, but there's fun in that too:-) S. > > randy > > From benl@google.com Sat Aug 17 04:31:21 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4186411E80F0 for ; Sat, 17 Aug 2013 04:31:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.377 X-Spam-Level: X-Spam-Status: No, score=-0.377 tagged_above=-999 required=5 tests=[AWL=1.600, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TytWIJNlmFlC for ; Sat, 17 Aug 2013 04:31:20 -0700 (PDT) Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id C88E011E80E3 for ; Sat, 17 Aug 2013 04:31:20 -0700 (PDT) Received: by mail-ob0-f181.google.com with SMTP id dn14so2957903obc.26 for ; Sat, 17 Aug 2013 04:31:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OBgMbSLEPUthV+Y8F846VFGnpq6Hu0pKrn/MOutjlJk=; b=meDm627zQ9iUxjOMoRNtUzi6i5S43sVh1wXfSsYksFvIjsl9dqs4HQvMR2hYCVYSaX uqijBA9pRvhStBf0+FeZi1JKQnh5afza6LQNZ25k6hTK7tpUFXdXzTPe6tK3q4icfz0f NiiiyjyQp5sNjB09/+rhXatBLu0yn8zL2TO8DHI4udLv7CtdGoCwojfhqBGFmvr1Ezl1 NCP8Si0jIb031X8WW5cxDwXw34ZIgOmpihOpcTNGQoGp4D50ri5B2BumuvwqUCmPpkHW IA225nYK3L4u4ZFZlgRzgNGohJR8LgdZa/TbfD5+bovtXip7dnKvYCPi21tDj0dl+Urt z4OQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=OBgMbSLEPUthV+Y8F846VFGnpq6Hu0pKrn/MOutjlJk=; b=GLM0tfC743emEXdBiTVYkowDTt3vYr/tYKcc6cEjZnCqYQ6HXOVUzgZVoDL2WOVQeH 9szZj+8i0Cnrwu4Bs5SFhvl3TVSc7QDpdiYmyIU8WoFXzXU7hfcyv19i7PLCEdt4eVXL 2p2gU8WyTO0mQyEbgztKZxuRE/W/sb4wPh2Vzef0J8Bgj08ikwCClPjjRK1+7ben79qO NZQ7ejSjjvRkv+cRyUmP1ciHB7gdlsBvtzX6jktIrAaHdNdtMKunpR4YcZm3giw8Ml+Q IpdEkg5c9Fw2gg//jxst9n2UB5rDx8QNiIyiyh+QxnZQS98uEX7jy9Jj9TvglBel4Jza A6wA== X-Gm-Message-State: ALoCoQnhHySkwf1TfMGxOiPCdfgIBF1OE9PnOyzNmysYDWbejo200hbpR3f0cLkC+gVaR4zrfhKEwHjbIyAXGDcyEvtQx0P5enk++9zBlSU2Ou2CcKpzUelyy8QoCdzuN2vFyk4u9ogO0sbpLAsTVbOJxqU+bid7Oig8u3BHd2L2iddGhQBCBUPqOQqlhTsYyxMN8PuUwiYY MIME-Version: 1.0 X-Received: by 10.60.62.38 with SMTP id v6mr599023oer.45.1376739080078; Sat, 17 Aug 2013 04:31:20 -0700 (PDT) Received: by 10.182.49.133 with HTTP; Sat, 17 Aug 2013 04:31:20 -0700 (PDT) In-Reply-To: References: <520E5684.1090005@cs.tcd.ie> <6.2.5.6.2.20130816171144.0c01f738@resistor.net> <520F4AE1.5040403@cs.tcd.ie> Date: Sat, 17 Aug 2013 07:31:20 -0400 Message-ID: From: Ben Laurie To: Randy Bush Content-Type: multipart/alternative; boundary=089e0153761ed12de304e4230bd6 Cc: perpass@ietf.org, Stephen Farrell Subject: Re: [perpass] Getting started... X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Aug 2013 11:31:21 -0000 --089e0153761ed12de304e4230bd6 Content-Type: text/plain; charset=ISO-8859-1 On 17 August 2013 06:18, Randy Bush wrote: > > i know bgp payload does not excite a lot of folk, but encrypting it > makes ip space tracability just that much harder. and opportunistic > encryption would be trivial to negotiate in the bgp open. and i am > looking at bgpsec doing payload encryption. What? Surely: a) The results of BGP are manifestly observable, regardless of whether you can see the payload or not, and b) The decrypted payload is necessarily visible to pretty much anyone who wants to see it (otherwise debugging routing problems is impossible) I feel like I must be missing something. --089e0153761ed12de304e4230bd6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

= On 17 August 2013 06:18, Randy Bush <randy@psg.com> wrote:

i know bgp payload does not excite a lot of folk, but encrypting it
makes ip space tracability just that much harder. =A0and opportunistic
encryption would be trivial to negotiate in the bgp open. =A0and i am
looking at bgpsec doing payload encryption.

What? Sur= ely:

a= ) The results of BGP are manifestly observable, regardless of whether you c= an see the payload or not, and

b) The decr= ypted payload is necessarily visible to pretty much anyone who wants to see= it (otherwise debugging routing problems is impossible)

I feel like I must be missing somethin= g.

--089e0153761ed12de304e4230bd6-- From benl@google.com Sat Aug 17 04:37:37 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB2D911E8103 for ; Sat, 17 Aug 2013 04:37:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.91 X-Spam-Level: X-Spam-Status: No, score=-0.91 tagged_above=-999 required=5 tests=[AWL=1.067, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Innag8ZPgjf for ; Sat, 17 Aug 2013 04:37:36 -0700 (PDT) Received: from mail-oa0-x235.google.com (mail-oa0-x235.google.com [IPv6:2607:f8b0:4003:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id 4DB9111E80F0 for ; Sat, 17 Aug 2013 04:37:24 -0700 (PDT) Received: by mail-oa0-f53.google.com with SMTP id k18so3396249oag.12 for ; Sat, 17 Aug 2013 04:37:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=11NcxfsP62cNWqlGJcL9JYpQuoIHKEhCbf+falrNxno=; b=CTPOct0sxR9RPDSj+4CaRkhbkRsqYOvfB2tzhQDgQgh8KQoSr8wWvCg4wAEtpFHF1M xC65bgJV5AVQi3cXNQrq0ftQYM3h5Y3piGc4wZK8Lxjj7r5jrOJy4DXvfxTJwQ8N/0k/ 08JW9L/ptHlDzkvPcQbJMZGFcnD7mMM5HD0rlpVn1hAWMJ1U6BCa0m1z/2tIlXW0McCT 3MXygUQCFj38a0+Qj1YgNroELDgocrzlHWax7vt6OFYFD4rUf3jFNqIvh6awiothgqO8 s05OhqXVwr4UzaItS2GoQaQc6jzKwJc0tW9hsT4bzrvI8E8GTVkmehXpJqV6mrU5Nw5K EhFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=11NcxfsP62cNWqlGJcL9JYpQuoIHKEhCbf+falrNxno=; b=TqitYSO6g9tbLN6gclBpb0j6kNrp/c3GyWjWBt4uQUwN8q68PqTOSsQMlQEfq83kdS BIMfpn1zKdz3HkG5utkC2QsSLS3lbEPv0iaJiG5h0J1pJg9HgmgOCQA9F9pJxSFsnBxt NimKCxByQehkX5gURsGgj7s68AuVK+Nep3bHI8Gsyviz+kyhZuMLrwKe21v6u/gXoy+F 6/Vyxqo2PPHbPl4wd4zEpY7OoBTVBA18LThNRkrmqpb6vF/JWf+vyLIEnHaSiuo4WCBQ saMcMhgXe35/rUgFfEcHzPSWLPST4/50SbjQdnZzJ/oYwbZIlaj+pDGFzDIH5Ty+VA2q y9PA== X-Gm-Message-State: ALoCoQlzpTeyojuf1SwkS+zjpafZoidJF/hzjw1bqcD6xNN6vByRoF6DGzd2bY9qEsUykilS61KQrTIqf0/97K7dCAgE3vxKYj/wzLfLPlmbR50ntabZsXsrGy9BOS7deh2PzRYodPOu0D08Hti9PKiR65VXCLtvWqCms1z5qH2arsfGnnIM2/wIQsMz115notsfr+raKGmN MIME-Version: 1.0 X-Received: by 10.60.96.131 with SMTP id ds3mr531021oeb.50.1376739438156; Sat, 17 Aug 2013 04:37:18 -0700 (PDT) Received: by 10.182.49.133 with HTTP; Sat, 17 Aug 2013 04:37:18 -0700 (PDT) In-Reply-To: <520E5684.1090005@cs.tcd.ie> References: <520E5684.1090005@cs.tcd.ie> Date: Sat, 17 Aug 2013 07:37:18 -0400 Message-ID: From: Ben Laurie To: Stephen Farrell Content-Type: multipart/alternative; boundary=089e01227b7c290b9204e4232172 Cc: perpass@ietf.org Subject: Re: [perpass] Getting started... X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Aug 2013 11:37:37 -0000 --089e01227b7c290b9204e4232172 Content-Type: text/plain; charset=ISO-8859-1 On 16 August 2013 12:42, Stephen Farrell wrote: > what should we be doing? Certificate Transparency is an anti-monitoring tool, amongst other useful properties. The more generalised idea of a public, verifiable log of stuff is probably useful in other ways, too. For example, DNSSEC Transparency (OK, hardly much different from CT). Someone mentioned default encrypting emails: sparse Merkle trees are an efficient data structure for making a verifiable map of email addresses to public keys... Yes, I have a hammer and I am looking for nails. --089e01227b7c290b9204e4232172 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

= On 16 August 2013 12:42, Stephen Farrell <stephen.farrell@cs.tcd.i= e> wrote:
what should we be doing?
<= br>Certificate Transparency is an anti-monitoring tool, amongst other usefu= l properties.

The more ge= neralised idea of a public, verifiable log of stuff is probably useful in o= ther ways, too.

For example, DNSSEC Transparency (OK, hardly much different from CT).
=

Someone men= tioned default encrypting emails: sparse Merkle trees are an efficient data= structure for making a verifiable map of email addresses to public keys...=

Yes, I have= a hammer and I am looking for nails.

<= /div>
--089e01227b7c290b9204e4232172-- From yaronf.ietf@gmail.com Sat Aug 17 04:51:29 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA0AC11E80F6 for ; Sat, 17 Aug 2013 04:51:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sl+wIMgISdoc for ; Sat, 17 Aug 2013 04:51:29 -0700 (PDT) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 0D28A11E80C5 for ; Sat, 17 Aug 2013 04:51:28 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id j13so1952301wgh.3 for ; Sat, 17 Aug 2013 04:51:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=KvQOQVwM7r/AMlcwPd8Tz/mmwZoufEjxf8XY1hTbUi0=; b=yjqIQ45BppbBo0rEJq1vULGcimHXay1RC+WTICJ95DiUk3QxCkAB5lO59zzRHwwYlB 3mhcpJ944FJldi7RMbxiMT5UE1+ZM4TjGTgbssrFFst9VIX2D1Sb4/TjiApCBD3u8BnI +WwOOr9vP4pvU7Q8MJra9ALlrx0ogi1MF5u8Stk9+CI6X6xhZZjmD04L5S790Q8txHBG Zynn9b4ovqhX8L72XlRW46DXu12iZzQnEAW3Ch5PbjeBqcS29RW8cwdh6gMHGz0JYnFP ffCZsFSAiJ79+hK41wA7UQ+Ffu3BROjKZEfbakHIGS84r/fltnkz52j3Z12QEWeAuy9R jtqg== X-Received: by 10.180.90.106 with SMTP id bv10mr1227208wib.65.1376740287408; Sat, 17 Aug 2013 04:51:27 -0700 (PDT) Received: from [10.0.0.3] ([109.67.206.7]) by mx.google.com with ESMTPSA id ee5sm3006221wib.3.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 17 Aug 2013 04:51:26 -0700 (PDT) Message-ID: <520F63BC.7030808@gmail.com> Date: Sat, 17 Aug 2013 14:51:24 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 MIME-Version: 1.0 To: perpass@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [perpass] Mail encryption as an example X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Aug 2013 11:51:29 -0000 Hi, Stephen mentioned that S/MIME is not good enough because headers (to/from) are still exposed. But there's still tons of benefit when the content is encrypted, even if the metadata is exposed (provided users know that it is exposed, of course). E.g. I would like all my internal company email to be encrypted, even if tracing recipients is trivial for the attacker. In other words, is the scope of the mailing list/solutions limited to security of individuals, as opposed to organizations? From a deployment perspective, I think we know how to provide privacy ("identity protection") only by using heavyweight solutions, such as onion routing. But there's a whole lot of important things we could do (make S/MIME usable, standardize OTR, revive IPsec OE) if we remove this constraint. Are such items in scope of this discussion? Thanks, Yaron From stephen.farrell@cs.tcd.ie Sat Aug 17 04:52:44 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F07511E8106 for ; Sat, 17 Aug 2013 04:52:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ajYRljeWH4AL for ; Sat, 17 Aug 2013 04:52:39 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 83EA911E8104 for ; Sat, 17 Aug 2013 04:52:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id AAA10BE24; Sat, 17 Aug 2013 12:52:38 +0100 (IST) 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 GOggNji4IEv7; Sat, 17 Aug 2013 12:52:37 +0100 (IST) Received: from [10.87.48.8] (unknown [86.44.67.197]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 71572BE1C; Sat, 17 Aug 2013 12:52:37 +0100 (IST) Message-ID: <520F6405.6010102@cs.tcd.ie> Date: Sat, 17 Aug 2013 12:52:37 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: Ben Laurie References: <520E5684.1090005@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: perpass@ietf.org Subject: Re: [perpass] Getting started... X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Aug 2013 11:52:44 -0000 Hi Ben, On 08/17/2013 12:37 PM, Ben Laurie wrote: > On 16 August 2013 12:42, Stephen Farrell wrote: > >> what should we be doing? > > > Certificate Transparency is an anti-monitoring tool, amongst other useful > properties. Yep. Its a fine tool but more I guess directed at countering an active attacker who spoofs as a web site and then monitors or snarfs passwords or whatever. > The more generalised idea of a public, verifiable log of stuff is probably > useful in other ways, too. > > For example, DNSSEC Transparency (OK, hardly much different from CT). > > Someone mentioned default encrypting emails: sparse Merkle trees are an > efficient data structure for making a verifiable map of email addresses to > public keys... neat idea... maybe. However, that and other foo-transparency ideas also require clients to ask the log about stuff, in a way that the log can.... log. For CT, thats ok since the web site itself (or its auditors) can contact the CT log, but I wonder if that'd become a problem for other foo-transparency applications, e.g. how could an MUA query a log of public keys without exposing the meta-data that I'm sending you an encrypted message? > Yes, I have a hammer and I am looking for nails. :-) S. > > > > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > From stephen.farrell@cs.tcd.ie Sat Aug 17 04:59:28 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F5E511E8104 for ; Sat, 17 Aug 2013 04:59:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rzgLJ+9JHa1L for ; Sat, 17 Aug 2013 04:59:17 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 450B611E80F6 for ; Sat, 17 Aug 2013 04:59:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 6F455BE24; Sat, 17 Aug 2013 12:59:16 +0100 (IST) 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 ILhVpnQbfF-5; Sat, 17 Aug 2013 12:59:15 +0100 (IST) Received: from [10.87.48.8] (unknown [86.44.67.197]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 92C5CBE20; Sat, 17 Aug 2013 12:59:15 +0100 (IST) Message-ID: <520F6589.4060808@cs.tcd.ie> Date: Sat, 17 Aug 2013 12:59:05 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: Yaron Sheffer References: <520F63BC.7030808@gmail.com> In-Reply-To: <520F63BC.7030808@gmail.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: perpass@ietf.org Subject: Re: [perpass] Mail encryption as an example X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Aug 2013 11:59:28 -0000 On 08/17/2013 12:51 PM, Yaron Sheffer wrote: > Hi, > > Stephen mentioned that S/MIME is not good enough because headers > (to/from) are still exposed. Didn't really mean "not good enough", more that protecting those headers would be my favourite improvement to make. > But there's still tons of benefit when the > content is encrypted, even if the metadata is exposed (provided users > know that it is exposed, of course). E.g. I would like all my internal > company email to be encrypted, even if tracing recipients is trivial for > the attacker. > > In other words, is the scope of the mailing list/solutions limited to > security of individuals, as opposed to organizations? > > From a deployment perspective, I think we know how to provide privacy > ("identity protection") only by using heavyweight solutions, such as > onion routing. But there's a whole lot of important things we could do > (make S/MIME usable, standardize OTR, revive IPsec OE) if we remove this > constraint. Are such items in scope of this discussion? Absolutely. I think there is a qualitative difference between this discussion and our usual security protocol discussions - in the latter case (as you say above) we always aim for "strong" mechanisms, where even the weakest link is "strong." In this case, its not quite so clear - it could well be that less strong mechanisms would produce a better outcome - opportunistic encryption for example as you also mentioned above - if they for example increase the cost of pervasive passive monitoring sufficiently or change the set of endpoints at which such monitoring is doable so that those endpoints might not be seen as good partners with whom to co-operate, for folks who would like to monitor. S. > > Thanks, > Yaron > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > > From benl@google.com Sat Aug 17 05:04:27 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 058BC11E8103 for ; Sat, 17 Aug 2013 05:04:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.177 X-Spam-Level: X-Spam-Status: No, score=-1.177 tagged_above=-999 required=5 tests=[AWL=0.800, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p3Iooa4DGsx4 for ; Sat, 17 Aug 2013 05:04:26 -0700 (PDT) Received: from mail-qe0-x231.google.com (mail-qe0-x231.google.com [IPv6:2607:f8b0:400d:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id DF35911E80F6 for ; Sat, 17 Aug 2013 05:04:25 -0700 (PDT) Received: by mail-qe0-f49.google.com with SMTP id 1so1721390qec.22 for ; Sat, 17 Aug 2013 05:04:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/E/sA7gW8Q64xOYhgvob/GPlO/DV2h73Xr1ovMRuHvU=; b=JaQHon0HfL5XRfuqSDIX3GOvu28r5zf6DD8aeQI5ssfSqHZyhl/lxxLmZvg7QDVaZi roe8SRpQHV3I48HnQMVIfagTCZ/Hv6p2QirFd4RF0fBgvR5CAP+pqnopqaUhv3gnSrTe OhESmlcv23tAjC0/D021kiFuPpW8bvCvUstMRVmXm5AKxPHOuwaJBsfsjANED3AY/8e8 sy7w6T0ziFCaTTyLyyBeq39I7bnVwX3C7DooDee24bSnbmtOBerywvQTFTkCWyawOrTl TWmOSCmiFFvdStFohR8/zFtRNLzfFgTJ2BuqkwSttSRbuRwpY08evpVH7MuIYaQMA5mx 1hZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=/E/sA7gW8Q64xOYhgvob/GPlO/DV2h73Xr1ovMRuHvU=; b=gmXuZd0Xx49dWS4kVfLwT4TQQA4IlDZbEGgrrT5bNMNrnbmHFCfRQCnuekmTRYT2Ky n2Lha72zFB2AaDo4n87+4MrmtWXXx57iA+eQlu2qcwlOrz/XzlXyh9+Rw5M2aQlI2trj G/E+kb72CvNZfPn6mnTPG3LGnmZxsgSeDof5Klta50YlSC9F6T9UwHMV/kUowmuGCRsA 5trO67CrzQxq2bpYDnsOBMH8NqZd02Q/WWBrI3UcrdokmM4J5qjI/Q1MldFDmmJ6s+ox HmES+W0ydSZiVY8JFm3anQo7CGhqekcx3podZTLRwzBHyQcspG9Pyv0C5CDJBs2E3vmI WOZA== X-Gm-Message-State: ALoCoQnKbisremJIgJeCCEkJtuvjCMIt+Ay3de/0zuH02QQd9TbzWsBnOaE0lcu+NHYJ5r50giRt60bcGInu1HwM6Q0aH4kTGRUdofc5WuCAJ4BGaeE8uP0isGGf+6Ze3ZefC/n+Nxd7KEdTqBk/WeUM9YkXAR14uk/XBFGCzhGp/7wFpjaXerLy7FAAtTlhEs27bdVprPac MIME-Version: 1.0 X-Received: by 10.49.13.131 with SMTP id h3mr2930743qec.3.1376741065311; Sat, 17 Aug 2013 05:04:25 -0700 (PDT) Received: by 10.229.169.196 with HTTP; Sat, 17 Aug 2013 05:04:24 -0700 (PDT) In-Reply-To: <520F6405.6010102@cs.tcd.ie> References: <520E5684.1090005@cs.tcd.ie> <520F6405.6010102@cs.tcd.ie> Date: Sat, 17 Aug 2013 08:04:24 -0400 Message-ID: From: Ben Laurie To: Stephen Farrell Content-Type: multipart/alternative; boundary=047d7b6773b0257b2b04e423826a Cc: perpass@ietf.org Subject: Re: [perpass] Getting started... X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Aug 2013 12:04:27 -0000 --047d7b6773b0257b2b04e423826a Content-Type: text/plain; charset=ISO-8859-1 On 17 August 2013 07:52, Stephen Farrell wrote: > > Hi Ben, > > On 08/17/2013 12:37 PM, Ben Laurie wrote: > > On 16 August 2013 12:42, Stephen Farrell > wrote: > > > >> what should we be doing? > > > > > > Certificate Transparency is an anti-monitoring tool, amongst other useful > > properties. > > Yep. Its a fine tool but more I guess directed at countering > an active attacker who spoofs as a web site and then monitors > or snarfs passwords or whatever. > > > The more generalised idea of a public, verifiable log of stuff is > probably > > useful in other ways, too. > > > > For example, DNSSEC Transparency (OK, hardly much different from CT). > > > > Someone mentioned default encrypting emails: sparse Merkle trees are an > > efficient data structure for making a verifiable map of email addresses > to > > public keys... > > neat idea... maybe. > > However, that and other foo-transparency ideas also require > clients to ask the log about stuff, in a way that the log > can.... log. > So, Private Information Retrieval is a way around this issue. I don't know much about it, yet, but I'm told its fairly expensive. But I think not too expensive for this kind of operation. As it happens, I am planning to do some work with Ian Goldberg on the subject, and so will have more to say about it in a while. Also, it may be that simply retrieving the whole log is feasible. We're not talking about vast amounts of data. > > For CT, thats ok since the web site itself (or its > auditors) can contact the CT log, but I wonder if that'd > become a problem for other foo-transparency applications, > e.g. how could an MUA query a log of public keys without > exposing the meta-data that I'm sending you an encrypted > message? > I would observe that you already reveal that, unless you come up with some entirely novel way of delivering email. I am not suggesting that this means the problem should not be solved, but it seems that encrypting the payload routinely moves the needle a fair amount - enough to be worth doing while we figure out the whole thing. > > > Yes, I have a hammer and I am looking for nails. > > :-) > > S. > > > > > > > > > _______________________________________________ > > perpass mailing list > > perpass@ietf.org > > https://www.ietf.org/mailman/listinfo/perpass > > > --047d7b6773b0257b2b04e423826a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On 17 August 2013 07:52, Stephen Farrell <stephen.farrell@= cs.tcd.ie> wrote:

Hi Ben,

On 08/17/2013 12:37 PM, Ben Laurie wrote:
> On 16 August 2013 12:42, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
>
>> what should we be doing?
>
>
> Certificate Transparency is an anti-monitoring tool, amongst other use= ful
> properties.

Yep. Its a fine tool but more I guess directed at countering
an active attacker who spoofs as a web site and then monitors
or snarfs passwords or whatever.

> The more generalised idea of a public, verifiable log of stuff is prob= ably
> useful in other ways, too.
>
> For example, DNSSEC Transparency (OK, hardly much different from CT).<= br> >
> Someone mentioned default encrypting emails: sparse Merkle trees are a= n
> efficient data structure for making a verifiable map of email addresse= s to
> public keys...

neat idea... maybe.

However, that and other foo-transparency ideas also require
clients to ask the log about stuff, in a way that the log
can.... log.

So, Private Information Re= trieval is a way around this issue. I don't know much about it, yet, bu= t I'm told its fairly expensive. But I think not too expensive for this= kind of operation.

As it happens, I am planning to do some work with Ian G= oldberg on the subject, and so will have more to say about it in a while.

Also, it may be that simply retrieving the whole lo= g is feasible. We're not talking about vast amounts of data.
=A0

For CT, thats ok since the web site itself (or its
auditors) can contact the CT log, but I wonder if that'd
become a problem for other foo-transparency applications,
e.g. how could an MUA query a log of public keys without
exposing the meta-data that I'm sending you an encrypted
message?

I would observe that you alrea= dy reveal that, unless you come up with some entirely novel way of deliveri= ng email. I am not suggesting that this means the problem should not be sol= ved, but it seems that encrypting the payload routinely moves the needle a = fair amount - enough to be worth doing while we figure out the whole thing.=
=A0

> Yes, I have a hammer and I am looking for nails.

:-)

S.

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

--047d7b6773b0257b2b04e423826a-- From russw@riw.us Sat Aug 17 08:12:53 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AC7F11E813F for ; Sat, 17 Aug 2013 08:12:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ROJmnLXGu0TE for ; Sat, 17 Aug 2013 08:12:47 -0700 (PDT) Received: from da31.namelessnet.net (da31.namelessnet.net [74.124.205.66]) by ietfa.amsl.com (Postfix) with ESMTP id 84DFA21F8E85 for ; Sat, 17 Aug 2013 08:12:47 -0700 (PDT) Received: from cpe-174-106-045-093.ec.res.rr.com ([174.106.45.93] helo=RussPC) by da31.namelessnet.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1VAiBJ-0003cd-AM; Sat, 17 Aug 2013 08:12:46 -0700 From: "Russ White" To: "'Stephen Farrell'" , "'Randy Bush'" References: <520E5684.1090005@cs.tcd.ie> <6.2.5.6.2.20130816171144.0c01f738@resistor.net> <520F4AE1.5040403@cs.tcd.ie> <520F525C.5020800@cs.tcd.ie> In-Reply-To: <520F525C.5020800@cs.tcd.ie> Date: Sat, 17 Aug 2013 11:12:47 -0400 Message-ID: <022e01ce9b5c$3c471130$b4d53390$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQFhI7XZ7p27zrKKNxD6OpAghwzlGgJUokovAbiw3zcBpdXjNQIFy0ptmjanU6A= Content-Language: en-us X-Antivirus-Scanner: Seems clean. You should still use an Antivirus Scanner Cc: perpass@ietf.org Subject: Re: [perpass] Getting started... X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Aug 2013 15:12:53 -0000 > > i know bgp payload does not excite a lot of folk, but encrypting it > > makes ip space tracability just that much harder. and opportunistic > > encryption would be trivial to negotiate in the bgp open. and i am > > looking at bgpsec doing payload encryption. > > I think that's a great example of the kind of nob-obvious changes that could > be useful and doable. I'd welcome more... and since we're just starting out, > makng a list of those would maybe be a useful thing so it'd be great to get > suggestions for putting on that list... Are we talking hop-by-hop encryption of the payload along the lines of ipsec between peers? Or encrypting the payload by changing the actual BGP packet format? How much is on-the-wire monitoring of routing udpates an issue if there is a cooperating provider (or even an open route view server) mirroring the global table? Is it even practical to try and "hide" the global table in any meaningful sense? Beyond this, wouldn't any form of tunneling or proxy or NAT ruin the traceability anyway? Why not focus on providing proxies and the like to obfuscate the traffic path rather than trying to encrypt the routing table? > > i would love it if my email client ( well, normal email clients :-) > > automagically encrypted to the recipients for whom i have a public key. > > maybe the folk way up there at layer seven can come up with an even > > better idea. Thunderbird+Enigmail does this. I recently switched off Thunderbird, though, because of a complete lack of any reasonable calendar client... another part of this problem is sheer education. I know lots of folks with public keys, but they won't encrypt their email traffic, because "I have nothing to hide" --and complete bit of nonsense, but very prevelant. Russ From stephen.farrell@cs.tcd.ie Sat Aug 17 08:14:26 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B84A11E813D for ; Sat, 17 Aug 2013 08:14:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hD-THQ+UWX5N for ; Sat, 17 Aug 2013 08:14:21 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 5E54B11E813F for ; Sat, 17 Aug 2013 08:14:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 06B54BE24; Sat, 17 Aug 2013 16:14:19 +0100 (IST) 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 xMOYPsSw4jCz; Sat, 17 Aug 2013 16:14:17 +0100 (IST) Received: from [10.87.48.8] (unknown [86.44.76.14]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 1218ABE1C; Sat, 17 Aug 2013 16:14:17 +0100 (IST) Message-ID: <520F933E.4070309@cs.tcd.ie> Date: Sat, 17 Aug 2013 16:14:06 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: Ben Laurie References: <520E5684.1090005@cs.tcd.ie> <520F6405.6010102@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: perpass@ietf.org Subject: [perpass] mail tracking (was; Re: Getting started...) X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Aug 2013 15:14:26 -0000 Changed the subject... On 08/17/2013 01:04 PM, Ben Laurie wrote: > On 17 August 2013 07:52, Stephen Farrell wrote: > >> >> Hi Ben, >> >> On 08/17/2013 12:37 PM, Ben Laurie wrote: >>> On 16 August 2013 12:42, Stephen Farrell >> wrote: >>> >>>> what should we be doing? >>> >>> >>> Certificate Transparency is an anti-monitoring tool, amongst other useful >>> properties. >> >> Yep. Its a fine tool but more I guess directed at countering >> an active attacker who spoofs as a web site and then monitors >> or snarfs passwords or whatever. >> >>> The more generalised idea of a public, verifiable log of stuff is >> probably >>> useful in other ways, too. >>> >>> For example, DNSSEC Transparency (OK, hardly much different from CT). >>> >>> Someone mentioned default encrypting emails: sparse Merkle trees are an >>> efficient data structure for making a verifiable map of email addresses >> to >>> public keys... >> >> neat idea... maybe. >> >> However, that and other foo-transparency ideas also require >> clients to ask the log about stuff, in a way that the log >> can.... log. >> > > So, Private Information Retrieval is a way around this issue. I don't know > much about it, yet, but I'm told its fairly expensive. But I think not too > expensive for this kind of operation. Be interesting if that were the case. I'd otherwise have assumed it was too expensive but be interested if you find out better. > > As it happens, I am planning to do some work with Ian Goldberg on the > subject, and so will have more to say about it in a while. > > Also, it may be that simply retrieving the whole log is feasible. We're not > talking about vast amounts of data. I wondered about that. Anyone know how big the MIT PGP key server DB is for example? I'd say storing it locally would be fine, and probably figuring out some kind of sharding thing and then asking for a full shard rather than Ben's public key could work ok maybe. >> For CT, thats ok since the web site itself (or its >> auditors) can contact the CT log, but I wonder if that'd >> become a problem for other foo-transparency applications, >> e.g. how could an MUA query a log of public keys without >> exposing the meta-data that I'm sending you an encrypted >> message? >> > > I would observe that you already reveal that, unless you come up with some > entirely novel way of delivering email. I am not suggesting that this means > the problem should not be solved, but it seems that encrypting the payload > routinely moves the needle a fair amount - enough to be worth doing while > we figure out the whole thing. Sure. The point is if we added a log that serves up the public keys of my recipients, then I don't want to make that log yet another place where monitoring can easily be done. And aside from that you'd also want to clean up which mail headers are protected, run SMTP/TLS always (maybe with a flag in the header to say to barf if TLS isn't on) etc. Seems like there are a bunch of imperfect things here that could be pretty doable. I've no idea if people are really motivated to do 'em though. Nor am I sure if they'd add up to enough to make mail significantly more robust against monitoring. S. > > >> >>> Yes, I have a hammer and I am looking for nails. >> >> :-) >> >> S. >> >>> >>> >>> >>> _______________________________________________ >>> perpass mailing list >>> perpass@ietf.org >>> https://www.ietf.org/mailman/listinfo/perpass >>> >> > From randy@psg.com Sat Aug 17 08:58:23 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBA0911E8190 for ; Sat, 17 Aug 2013 08:58:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id puPlPbTZY32O for ; Sat, 17 Aug 2013 08:58:23 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id 3220F11E818A for ; Sat, 17 Aug 2013 08:58:23 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1VAitM-0000Zj-EE; Sat, 17 Aug 2013 15:58:16 +0000 Date: Sun, 18 Aug 2013 00:58:14 +0900 Message-ID: From: Randy Bush To: "Russ White" In-Reply-To: <022e01ce9b5c$3c471130$b4d53390$@riw.us> References: <520E5684.1090005@cs.tcd.ie> <6.2.5.6.2.20130816171144.0c01f738@resistor.net> <520F4AE1.5040403@cs.tcd.ie> <520F525C.5020800@cs.tcd.ie> <022e01ce9b5c$3c471130$b4d53390$@riw.us> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: perpass@ietf.org, 'Stephen Farrell' Subject: Re: [perpass] Getting started... X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Aug 2013 15:58:23 -0000 > Why not focus on providing proxies and the like to obfuscate the > traffic path rather than trying to encrypt the routing table? if it's cheap, do both. every cm we can raise the bar cheaply is a win >>> i would love it if my email client ( well, normal email clients :-) >>> automagically encrypted to the recipients for whom i have a public key. >>> maybe the folk way up there at layer seven can come up with an even >>> better idea. > Thunderbird+Enigmail does this. yep. trying to move family members and coworkers to that mode. but, as i hinted, i use a horribly irregular emacs-based email client. > I know lots of folks with public keys, but they won't encrypt their > email traffic, because "I have nothing to hide" --and complete bit of > nonsense, but very prevelant. i am hoping the frogs will notice the rising water temperature. foolish of me, probably. but this is one reason why i suggested privacy by default. From randy@psg.com Sat Aug 17 09:59:49 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7B5311E8228 for ; Sat, 17 Aug 2013 09:59:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.543 X-Spam-Level: X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g5ZjDXhuzW+b for ; Sat, 17 Aug 2013 09:59:49 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id 6EE1611E81F8 for ; Sat, 17 Aug 2013 09:59:49 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1VAjqZ-0000f3-9F; Sat, 17 Aug 2013 16:59:27 +0000 Date: Sun, 18 Aug 2013 01:59:26 +0900 Message-ID: From: Randy Bush To: Stephen Farrell In-Reply-To: <520F933E.4070309@cs.tcd.ie> References: <520E5684.1090005@cs.tcd.ie> <520F6405.6010102@cs.tcd.ie> <520F933E.4070309@cs.tcd.ie> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: perpass@ietf.org, Ben Laurie Subject: Re: [perpass] mail tracking (was; Re: Getting started...) X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Aug 2013 16:59:49 -0000 > I wondered about that. Anyone know how big the MIT PGP key server > DB is for example? > > I'd say storing it locally would be fine and doing what? trusting it? puhleeze! randy From benl@google.com Sat Aug 17 10:08:31 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D00A211E8229 for ; Sat, 17 Aug 2013 10:08:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.337 X-Spam-Level: X-Spam-Status: No, score=-1.337 tagged_above=-999 required=5 tests=[AWL=0.640, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ta0F-g53kGDv for ; Sat, 17 Aug 2013 10:08:29 -0700 (PDT) Received: from mail-qa0-x22b.google.com (mail-qa0-x22b.google.com [IPv6:2607:f8b0:400d:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 1147E11E8227 for ; Sat, 17 Aug 2013 10:08:24 -0700 (PDT) Received: by mail-qa0-f43.google.com with SMTP id cl20so1079693qab.9 for ; Sat, 17 Aug 2013 10:07:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=MGJTMZWP8qVqJxIEtNOFqQZt2qupNLyTAbZlnAe+RNY=; b=PtYnRYfx96Au7TadVkZ73QdzRfd6XiK6b1mZOyXyGQE14SG+0iPdBS/rlBKncJDgNw QLoUjRGTjtEaPIz0Z3sA11xMVpM9BV/hZ23nHzy6IjxNU0crxWLgBYE+WeCGiH/bB6+R zMVQV8sustxJ6UnP5LZeFFdzlPsfMisNFDPRC000nP2EqY7owKzPQAmUfFqQpm6dZRJL k3+zu2PxQ1mTe5TIMyCYX7AmTVJM5rpYBI5QC0DkU9jx+terrlCiDxsVP7zsIse9AxqE 5d0fHhETrD4E8CVlshR7TthfSu0A5x9WoVmYI7KzTW22C7xQN+PFoiO/yIAqG8LhsUVK NJ1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=MGJTMZWP8qVqJxIEtNOFqQZt2qupNLyTAbZlnAe+RNY=; b=FEJtCW+hdanwWjBu7VbrP+qSnWswl78yijj/frlF0S06YcEltQmfZ6B/5aax1o/zbb f05xgzZjiy3F9iks6lDEKDGuEhlVeQpyfVlF7O2ydUF23N+2dNVzPtjU6IZQBkDLQUGA vdSjDaM1QK5obJcXhUk+iWypl7uYy0TVcB2ISZRPVt+hqb/MMc0CsKxBMYl1Kkljb5g0 +8uH4S05Kfwhm2PxREZJXQLLeE560cfYQewAGWF/niOjCjyQWu0KrW3qO4T3zo7qcR18 DWDE6OqEKrZ8NjvW/JhiYwCDUUcchmWRx4XJjJQaD93cTU9QPE6pV4qpYmEJyzhr/oE6 UNlw== X-Gm-Message-State: ALoCoQmJUzpPzPQJR53kNHmh8R06R09z4u2iJCjXQ8Lg3lNRQ0i5YpC+lHNMeZp2Lk59DN7IvytYW57YxyOmrxrXMKpjQIV2P/RppnfCZhPLjQedV4N7vXaBAMvIGksAduXVWh58Z1bvO81xsC/miG3WSkNPPTrOxSfnX58GTslnSvs1iTKHZO+Fa9kv/ZiZ/EIx3tFmyMek MIME-Version: 1.0 X-Received: by 10.49.15.97 with SMTP id w1mr4327567qec.13.1376759278901; Sat, 17 Aug 2013 10:07:58 -0700 (PDT) Received: by 10.229.169.196 with HTTP; Sat, 17 Aug 2013 10:07:58 -0700 (PDT) In-Reply-To: References: <520E5684.1090005@cs.tcd.ie> <520F6405.6010102@cs.tcd.ie> <520F933E.4070309@cs.tcd.ie> Date: Sat, 17 Aug 2013 13:07:58 -0400 Message-ID: From: Ben Laurie To: Randy Bush Content-Type: multipart/alternative; boundary=047d7bb042e2c2bd5d04e427bff0 Cc: perpass@ietf.org, Stephen Farrell Subject: Re: [perpass] mail tracking (was; Re: Getting started...) X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Aug 2013 17:08:31 -0000 --047d7bb042e2c2bd5d04e427bff0 Content-Type: text/plain; charset=ISO-8859-1 On 17 August 2013 12:59, Randy Bush wrote: > > I wondered about that. Anyone know how big the MIT PGP key server > > DB is for example? > > > > I'd say storing it locally would be fine > > and doing what? trusting it? puhleeze! > This is precisely why you want a _verifiable_ map. So you don't have to trust it. > > randy > --047d7bb042e2c2bd5d04e427bff0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On 17 August 2013 12:59, Randy Bush <randy@psg.com> wr= ote:
> I wondered about that. Anyone know how big the MIT P= GP key server
> DB is for example?
>
> I'd say storing it locally would be fine

and doing what? =A0trusting it? =A0puhleeze!
This is precisely why you want a _verifiable_ map. So you don&#= 39;t have to trust it.
=A0

randy

--047d7bb042e2c2bd5d04e427bff0-- From paul@cypherpunks.ca Sat Aug 17 10:20:24 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5FAD21F85B4 for ; Sat, 17 Aug 2013 10:20:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sMeAL749RXaN for ; Sat, 17 Aug 2013 10:20:18 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id BB50911E81FE for ; Sat, 17 Aug 2013 10:20:18 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3cHSp63wqFz8P for ; Sat, 17 Aug 2013 13:20:14 -0400 (EDT) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id F_t0V5_VSNBI for ; Sat, 17 Aug 2013 13:20:13 -0400 (EDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by mx.nohats.ca (Postfix) with ESMTP for ; Sat, 17 Aug 2013 13:20:13 -0400 (EDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id 6FD1A80EE1; Sat, 17 Aug 2013 13:20:14 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 63152804AB for ; Sat, 17 Aug 2013 13:20:14 -0400 (EDT) Date: Sat, 17 Aug 2013 13:20:13 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: perpass@ietf.org In-Reply-To: <6.2.5.6.2.20130816171144.0c01f738@resistor.net> Message-ID: References: <520E5684.1090005@cs.tcd.ie> <6.2.5.6.2.20130816171144.0c01f738@resistor.net> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: Re: [perpass] Getting started... X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Aug 2013 17:20:24 -0000 On Fri, 16 Aug 2013, SM wrote: > "Privacy by default" has, up to now, been a failure in the IETF. It has been a conscious choice though. For example, compare IKEv1 versus IKEv2. The privacy of the ID against passive attackers was sacrificed to save a single RTT. I know "we" (the freeswan people) did not agree, but everyone else considered speed more important. I think we have learned since, that with things like session resumption, we can perhaps get both privacy and speed, although the session resumption in itself could also be an information leak. > Discussions about monitoring is a sensitive subject. Indeed. Many years ago when in The Netherlands, lawful interception became a reality for ISPs, and a tapping specification (TIIT) came into existence, ISPs were forced to install commercial "black boxes" that complied to the spec. I tried to get funding to make an open source implementation. I quickly found that no one wanted to be known for sponsoring an interception device. Everyone agrees an opensource box is better than a blackbox, but everyone was afraid of misinterpretation. Paul From dhc@dcrocker.net Sat Aug 17 10:32:54 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B18211E8197 for ; Sat, 17 Aug 2013 10:32:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.578 X-Spam-Level: X-Spam-Status: No, score=-6.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gKP2VLS6UBDa for ; Sat, 17 Aug 2013 10:32:49 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0945521F99BE for ; Sat, 17 Aug 2013 10:32:49 -0700 (PDT) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r7HHWbQn023238 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 17 Aug 2013 10:32:41 -0700 Message-ID: <520FB3A0.1020508@dcrocker.net> Date: Sat, 17 Aug 2013 10:32:16 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: SM References: <520E5684.1090005@cs.tcd.ie> <6.2.5.6.2.20130816171144.0c01f738@resistor.net> In-Reply-To: <6.2.5.6.2.20130816171144.0c01f738@resistor.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Sat, 17 Aug 2013 10:32:43 -0700 (PDT) Cc: perpass@ietf.org Subject: Re: [perpass] Getting started... X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Aug 2013 17:32:54 -0000 >> The only thing to add to that for now is that since the kinds of >> monitoring we're considering can be done at many layers, we should >> not only be considering the web, or application layer or just >> security protocols, but the full suite of protocols and areas in >> which the IETF works. > > "Privacy by default" has, up to now, been a failure in the IETF. As you > pointed out things do not happen unless someone volunteers to do the > work. There has been a lack of volunteers. I don't know why. I don't > know who is trying to fix that. We probably should draw a bright line between basic, classic "confidentiality" mechanisms, versus whatever we mean by "privacy". (The IAB was explicit in not being willing to choose a specific definition for its RFC on the topic -- however we might want to settle on one, to assist technical guidance.) Better confidentiality mechanisms (eg, content encryption) might facilitate better privacy, but keeping the two constructs clearly distinct will probably aid both group focus and clarity about the work when communicating to others. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From paul@cypherpunks.ca Sat Aug 17 10:37:45 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A220E11E822B for ; Sat, 17 Aug 2013 10:37:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sW11bJ-lZpz1 for ; Sat, 17 Aug 2013 10:37:35 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id 9DFDF11E81D0 for ; Sat, 17 Aug 2013 10:37:35 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3cHTB34ztcz8P for ; Sat, 17 Aug 2013 13:37:31 -0400 (EDT) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id PF3q1Y0UmBAw for ; Sat, 17 Aug 2013 13:37:30 -0400 (EDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by mx.nohats.ca (Postfix) with ESMTP for ; Sat, 17 Aug 2013 13:37:30 -0400 (EDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id CF73180EE1; Sat, 17 Aug 2013 13:37:30 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id C32E5804AB for ; Sat, 17 Aug 2013 13:37:30 -0400 (EDT) Date: Sat, 17 Aug 2013 13:37:30 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: perpass@ietf.org In-Reply-To: Message-ID: References: <520E5684.1090005@cs.tcd.ie> <6.2.5.6.2.20130816171144.0c01f738@resistor.net> <520F4AE1.5040403@cs.tcd.ie> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [perpass] Getting started... X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Aug 2013 17:37:46 -0000 On Sat, 17 Aug 2013, Randy Bush wrote: > i would love it if my email client ( well, normal email clients :-) > automagically encrypted to the recipients for whom i have a public key. We should run a mailserver on localhost and have that support encryption to OPENPGP/SMIME keys from DNSSEC. That way, we don't have to wait another decade for mail clients not to support encryption in a way that the masses can use. And it can run on everyone's phone. Paul From housley@vigilsec.com Sat Aug 17 11:25:56 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 113C921F8EC3 for ; Sat, 17 Aug 2013 11:25:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.567 X-Spam-Level: X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HraPA7Tiqev5 for ; Sat, 17 Aug 2013 11:25:51 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 7BE5311E81D9 for ; Sat, 17 Aug 2013 11:25:50 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 56B46F24038; Sat, 17 Aug 2013 14:25:58 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id bY3j0aVHugQt; Sat, 17 Aug 2013 14:25:48 -0400 (EDT) Received: from [192.168.0.8] (75-139-113-21.dhcp.mant.nc.charter.com [75.139.113.21]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 5549AF24032; Sat, 17 Aug 2013 14:25:56 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: <520F63BC.7030808@gmail.com> Date: Sat, 17 Aug 2013 14:25:46 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <7BCB3CC3-3E06-41F2-B2AE-CC8A697F45CF@vigilsec.com> References: <520F63BC.7030808@gmail.com> To: Yaron Sheffer X-Mailer: Apple Mail (2.1085) Cc: perpass@ietf.org Subject: Re: [perpass] Mail encryption as an example X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Aug 2013 18:25:56 -0000 There is a technique for protecting the subject line for S/MIME, but the = recipients MUST be exposed for the mail to b delivered. This exposure = can be limited to the clients and various mail servers if SMTP/POP/IMAP = are run over TLS. Russ On Aug 17, 2013, at 7:51 AM, Yaron Sheffer wrote: > Hi, >=20 > Stephen mentioned that S/MIME is not good enough because headers = (to/from) are still exposed. But there's still tons of benefit when the = content is encrypted, even if the metadata is exposed (provided users = know that it is exposed, of course). E.g. I would like all my internal = company email to be encrypted, even if tracing recipients is trivial for = the attacker. >=20 > In other words, is the scope of the mailing list/solutions limited to = security of individuals, as opposed to organizations? >=20 > =46rom a deployment perspective, I think we know how to provide = privacy ("identity protection") only by using heavyweight solutions, = such as onion routing. But there's a whole lot of important things we = could do (make S/MIME usable, standardize OTR, revive IPsec OE) if we = remove this constraint. Are such items in scope of this discussion? >=20 > Thanks, > Yaron > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass From sm@resistor.net Sat Aug 17 12:31:49 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BD1611E8209 for ; Sat, 17 Aug 2013 12:31:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.469 X-Spam-Level: X-Spam-Status: No, score=-102.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jLwFnMBDf88D for ; Sat, 17 Aug 2013 12:31:48 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E67911E8186 for ; Sat, 17 Aug 2013 12:31:48 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r7HJVW1r020879; Sat, 17 Aug 2013 12:31:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1376767897; bh=CY+iXIDc2IZAdOw6fLCbpwUYZV/KPVajg7kcugkizVA=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=LKp1l6K1nqHrCjWVH0sjPeJa2jQdwTs894DMmns7LVhLl8WLQZB2GM3cRLFJmhpg6 fvPZK5iB3i4F6NWvvch3SMFjyzZkBtgcqsA8R4UEEyB1IARndIfgvjK9mQsphITXa9 ZEUMvwN4kOBjDc8xQ0sj3d8z9zglbWkwkWbO4Jy8= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1376767897; i=@resistor.net; bh=CY+iXIDc2IZAdOw6fLCbpwUYZV/KPVajg7kcugkizVA=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=ed6DzxzbW/V97tieO01/zqDRHA2jWhrbr/dKAP2+9VeM4kRdsqq94VKRdusyiBqXc +DVUkGaSJ5Ud7cukmkECHsor7wR7c6Cfp5yb9e5HTwtGG0jO2Jb/Yawq5AOQqbf3N4 JyROPJvxhBgM8GAAoQ/cYirqW/6Lgk3BwBEHNzos= Message-Id: <6.2.5.6.2.20130817115835.0b88a148@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 17 Aug 2013 12:30:12 -0700 To: Paul Wouters From: SM In-Reply-To: References: <520E5684.1090005@cs.tcd.ie> <6.2.5.6.2.20130816171144.0c01f738@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: perpass@ietf.org Subject: Re: [perpass] Getting started... X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Aug 2013 19:31:49 -0000 Hi Paul, At 10:20 17-08-2013, Paul Wouters wrote: >I think we have learned since, that with things like session resumption, >we can perhaps get both privacy and speed, although the session >resumption in itself could also be an information leak. Maybe the IETF could look at this from a "what have we learned" angle since then and how we can privacy together with the features we would like to have. To say it different, if there is a trade-off between privacy and something else, do we sacrifice privacy in making that trade-off? >Indeed. Many years ago when in The Netherlands, lawful interception >became a reality for ISPs, and a tapping specification (TIIT) came into >existence, ISPs were forced to install commercial "black boxes" that >complied to the spec. I tried to get funding to make an open source >implementation. I quickly found that no one wanted to be known for >sponsoring an interception device. Everyone agrees an opensource box >is better than a blackbox, but everyone was afraid of misinterpretation. It's bad PR and that's the angle people value more. The benefit of having an open source implementation is that anyone who wants to know what is being done can read the source code instead of relying on rumors which lead to fear and deception. By the way, you might have tried to implement too early, i.e. people may not have understood the value of what you were trying to do. It's also difficult to get funding for anything that isn't mainstream if you happen to be in the wrong country. Regards, -sm From fenton@bluepopcorn.net Sat Aug 17 13:43:57 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0DE911E816D for ; Sat, 17 Aug 2013 13:43:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QLz+ZBSw-kRm for ; Sat, 17 Aug 2013 13:43:56 -0700 (PDT) Received: from kernel.bluepopcorn.net (ipv6.bluepopcorn.net [IPv6:2001:470:1f05:bfe:21a:70ff:fe11:c889]) by ietfa.amsl.com (Postfix) with ESMTP id B673D11E8156 for ; Sat, 17 Aug 2013 13:43:56 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by kernel.bluepopcorn.net (8.14.4/8.14.4/Debian-2.1ubuntu1) with ESMTP id r7HKhtl7000871 for ; Sat, 17 Aug 2013 13:43:55 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1376772235; bh=0hpcsLWQ94axVf9EV0Bs7svbQFJ7j4zFcOL3pQ7kJoQ=; h=Date:From:To:Subject:From; b=ka5IOjCg2LahbTw1EI+1WK9zp4+5KbdowILfcD3kir5RmHnKfIk4NhN/els3cLBfj s7PKon4vadYxhuIOtrLV7/T8Ey7c9ls/PE7DhvSTLFwsxNwFVB0hIbhSTeBNXngcKO mR4hwTlrti8pv2H7W0DeF9m+yR9T5tgYg0bXLR1A= Message-ID: <520FE08B.80005@bluepopcorn.net> Date: Sat, 17 Aug 2013 13:43:55 -0700 From: Jim Fenton User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: perpass@ietf.org X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [perpass] Another mail-related proposal X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Aug 2013 20:43:57 -0000 When I read the purpose of this mailing list, an idea that had been in the back of my brain came to mind, and I wonder if it fits with that purpose. To Dave Crocker's point, I'm not sure whether you'd characterize this as a privacy enhancement or confidentiality enhancement, but here goes: SMTP is biased in favor of delivering the message if at all possible. While some MTAs use TLS to communicate, many do not, so TLS is negotiated by mutual consent, but if that doesn't work out the message is sent in the clear. So if TLS breaks for some reason, people frequently don't notice. There might be times when I'm interested in sending a message that I'd rather not be in the clear on the wire, and I'd rather that the message bounce rather than be sent in the clear. How about an SMTP option that allows a sender to specify whether the message transmission requires (1) TLS and (2) that the receiving MTA also enforce this option. It could also specify whether the recipient MTA is required to have a certificate trusted (e.g., via trust chain) by the sending MTA, or whether any TLS negotiation (e.g., self-signed cert) is OK. This of course doesn't address a threat model that includes the MTAs themselves, since they have the message in the clear. So, - Is this proposal the sort of thing this list is for? - If so, any thoughts on the proposal? -Jim From paul@cypherpunks.ca Sat Aug 17 14:26:19 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E67AF11E8178 for ; Sat, 17 Aug 2013 14:26:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gDlTPXXZUN81 for ; Sat, 17 Aug 2013 14:26:14 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id 0C9C411E8159 for ; Sat, 17 Aug 2013 14:26:14 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3cHZFg588pz30V; Sat, 17 Aug 2013 17:25:59 -0400 (EDT) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id r7Uo2ER1rTBl; Sat, 17 Aug 2013 17:25:57 -0400 (EDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by mx.nohats.ca (Postfix) with ESMTP; Sat, 17 Aug 2013 17:25:57 -0400 (EDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id 413EC80EE1; Sat, 17 Aug 2013 17:25:58 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 358A5804AB; Sat, 17 Aug 2013 17:25:58 -0400 (EDT) Date: Sat, 17 Aug 2013 17:25:58 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Jim Fenton In-Reply-To: <520FE08B.80005@bluepopcorn.net> Message-ID: References: <520FE08B.80005@bluepopcorn.net> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: perpass@ietf.org Subject: Re: [perpass] Another mail-related proposal X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Aug 2013 21:26:20 -0000 On Sat, 17 Aug 2013, Jim Fenton wrote: > There might be times when I'm interested in sending a message that I'd > rather not be in the clear on the wire, and I'd rather that the message > bounce rather than be sent in the clear. How about an SMTP option that > allows a sender to specify whether the message transmission requires (1) > TLS and (2) that the receiving MTA also enforce this option. It could > also specify whether the recipient MTA is required to have a certificate > trusted (e.g., via trust chain) by the sending MTA, or whether any TLS > negotiation (e.g., self-signed cert) is OK. I'd argue it the other way. If you publish a OPENPGPKEY/SMIMEKEY record, then you ONLY want to receive encrypted email. The problem is trying to prevent receiving it, as most email servers are message based and they have to accept the full message before rejecting it, at which point the cleartext has gone over the network and the NSA has a copy even if you don't. The postfix TLSA record fails hard for this reason - but that's the transport security, not data security. Paul From fenton@bluepopcorn.net Sat Aug 17 23:05:59 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7FDD11E8224 for ; Sat, 17 Aug 2013 23:05:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cGUapjw8Qo9t for ; Sat, 17 Aug 2013 23:05:58 -0700 (PDT) Received: from kernel.bluepopcorn.net (ipv6.bluepopcorn.net [IPv6:2001:470:1f05:bfe:21a:70ff:fe11:c889]) by ietfa.amsl.com (Postfix) with ESMTP id 1037A11E821E for ; Sat, 17 Aug 2013 23:05:57 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by kernel.bluepopcorn.net (8.14.4/8.14.4/Debian-2.1ubuntu1) with ESMTP id r7I65pBU003229; Sat, 17 Aug 2013 23:05:52 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1376805952; bh=/DrozxSJwg/bQA7ASMnJLHPrqD0U5f7qpD2kFcjGn5g=; h=Date:From:To:CC:Subject:References:In-Reply-To:From; b=JpZhCtAy85cZa3L95DFPUViYJRFF+H5TZTWubPIke8ow/DcxjOq248z6gPLE/3umD 6FVRsCBBnlkToYy0Mg6bhEbl9XBz6vQWjhRdVTqqg7FGhmooQOr34Vtf/31eEr42mj rSwhEdqiOBIY+IP77FoLhwUPcgTKdXrhtI1hItSk= Message-ID: <5210643F.8030709@bluepopcorn.net> Date: Sat, 17 Aug 2013 23:05:51 -0700 From: Jim Fenton User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: Paul Wouters References: <520FE08B.80005@bluepopcorn.net> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: perpass@ietf.org Subject: Re: [perpass] Another mail-related proposal X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Aug 2013 06:05:59 -0000 On 08/17/2013 02:25 PM, Paul Wouters wrote: > On Sat, 17 Aug 2013, Jim Fenton wrote: > >> There might be times when I'm interested in sending a message that I'd >> rather not be in the clear on the wire, and I'd rather that the message >> bounce rather than be sent in the clear. How about an SMTP option that >> allows a sender to specify whether the message transmission requires (1) >> TLS and (2) that the receiving MTA also enforce this option. It could >> also specify whether the recipient MTA is required to have a certificate >> trusted (e.g., via trust chain) by the sending MTA, or whether any TLS >> negotiation (e.g., self-signed cert) is OK. > > I'd argue it the other way. If you publish a OPENPGPKEY/SMIMEKEY record, > then you ONLY want to receive encrypted email. The problem is trying to > prevent receiving it, as most email servers are message based and they > have to accept the full message before rejecting it, at which point the > cleartext has gone over the network and the NSA has a copy even if you > don't. > > The postfix TLSA record fails hard for this reason - but that's the > transport security, not data security. I was, in fact, thinking about transport security, not data security. And I was thinking about being to set the preference on a message-by-message basis. If I'm sending a message to my neighbors announcing a block party, I would want the (existing) bias toward message delivery. OTOH, if I'm sending a message to my accountant, I might want to make sure it goes over a TLS-encrypted transport. I'm having more trouble coming up with use cases where I'd want to reject messages that don't use PGP or S/MIME. The originator of a message is in a better position to decide whether it contains sensitive information. And as the receiver you can't generally protect against the message traversing the network in the clear -- SMTP is often more than one hop and an earlier hop (or submission) could have been in the clear, even if you did require TLS for the last hop. -Jim From randy@psg.com Sun Aug 18 00:37:56 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39C7611E825E for ; Sun, 18 Aug 2013 00:37:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4gXfzI0JF5Mm for ; Sun, 18 Aug 2013 00:37:53 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id C786811E81C3 for ; Sun, 18 Aug 2013 00:37:52 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1VAxYd-0002K3-93; Sun, 18 Aug 2013 07:37:51 +0000 Date: Sun, 18 Aug 2013 16:37:50 +0900 Message-ID: From: Randy Bush To: Jim Fenton In-Reply-To: <5210643F.8030709@bluepopcorn.net> References: <520FE08B.80005@bluepopcorn.net> <5210643F.8030709@bluepopcorn.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: perpass@ietf.org Subject: Re: [perpass] Another mail-related proposal X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Aug 2013 07:37:57 -0000 > I'm having more trouble coming up with use cases where I'd want to > reject messages that don't use PGP or S/MIME. visualize a future world where e2e message privacy is the default. in that world, some parties could view an unencrypted message as an attack. > The originator of a message is in a better position to decide whether > it contains sensitive information. And as the receiver you can't > generally protect against the message traversing the network in the > clear -- SMTP is often more than one hop and an earlier hop (or > submission) could have been in the clear, even if you did require TLS > for the last hop. i do what is in my power to do. just because there might be a weakness in the system n hops away does not mean i should indulge in weakness. randy From schlitt@theworld.com Sun Aug 18 07:02:41 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 473B911E8292 for ; Sun, 18 Aug 2013 07:02:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.98 X-Spam-Level: X-Spam-Status: No, score=-2.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BXM93-iuDc-P for ; Sun, 18 Aug 2013 07:02:36 -0700 (PDT) Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id 8486C11E828F for ; Sun, 18 Aug 2013 07:02:36 -0700 (PDT) Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r7IE21V2011163; Sun, 18 Aug 2013 10:02:07 -0400 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r7IE20Ik1306465; Sun, 18 Aug 2013 10:02:00 -0400 (EDT) Received: from localhost (schlitt@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) with ESMTP id r7IE20qm1296762; Sun, 18 Aug 2013 10:02:00 -0400 (EDT) X-Authentication-Warning: shell01.TheWorld.com: schlitt owned process doing -bs Date: Sun, 18 Aug 2013 10:01:59 -0400 From: Dan Schlitt To: Randy Bush In-Reply-To: Message-ID: References: <520FE08B.80005@bluepopcorn.net> <5210643F.8030709@bluepopcorn.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Jim Fenton , perpass@ietf.org Subject: Re: [perpass] Another mail-related proposal X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Aug 2013 14:02:41 -0000 I thought that I was long ago taught that encrypting only messages with "sensitive information" in them was bad security. The encrypted messages called attention to them and even if they could not be read were subject to traffic analysis. /dan -- Dan Schlitt schlitt@world.std.com On Sun, 18 Aug 2013, Randy Bush wrote: >> I'm having more trouble coming up with use cases where I'd want to >> reject messages that don't use PGP or S/MIME. > > visualize a future world where e2e message privacy is the default. in > that world, some parties could view an unencrypted message as an attack. > >> The originator of a message is in a better position to decide whether >> it contains sensitive information. And as the receiver you can't >> generally protect against the message traversing the network in the >> clear -- SMTP is often more than one hop and an earlier hop (or >> submission) could have been in the clear, even if you did require TLS >> for the last hop. > > i do what is in my power to do. just because there might be a weakness > in the system n hops away does not mean i should indulge in weakness. > > randy > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > From fenton@bluepopcorn.net Sun Aug 18 09:34:00 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E17111E8135 for ; Sun, 18 Aug 2013 09:34:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ek8cwMBLYnQT for ; Sun, 18 Aug 2013 09:33:59 -0700 (PDT) Received: from kernel.bluepopcorn.net (ipv6.bluepopcorn.net [IPv6:2001:470:1f05:bfe:21a:70ff:fe11:c889]) by ietfa.amsl.com (Postfix) with ESMTP id 683F211E8125 for ; Sun, 18 Aug 2013 09:33:59 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by kernel.bluepopcorn.net (8.14.4/8.14.4/Debian-2.1ubuntu1) with ESMTP id r7IGXrSJ005457; Sun, 18 Aug 2013 09:33:53 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1376843636; bh=mygwKvp770ZTBhYnMMK3zMwIzit1SGeg77qZhI1S0RE=; h=Date:From:To:CC:Subject:References:In-Reply-To:From; b=N115A3KxOxvwhb0ksXsyEH+vjbNumLMicNr/tjx7K8QeyD768uC/1PX7FiYCgHm0c BG7IaM2FEp9sP5+DvssPpmKDJrwUUbrZ9lPWliSIHer1hLWx6A6liyL88r+wg/V++J DWFwFHGsvAQwhMJSfj7fBB6B88+qUd+n5zkkYams= Message-ID: <5210F771.9090600@bluepopcorn.net> Date: Sun, 18 Aug 2013 09:33:53 -0700 From: Jim Fenton User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: Randy Bush References: <520FE08B.80005@bluepopcorn.net> <5210643F.8030709@bluepopcorn.net> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: perpass@ietf.org Subject: Re: [perpass] Another mail-related proposal X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Aug 2013 16:34:00 -0000 On 08/18/2013 12:37 AM, Randy Bush wrote: >> I'm having more trouble coming up with use cases where I'd want to >> reject messages that don't use PGP or S/MIME. > visualize a future world where e2e message privacy is the default. in > that world, some parties could view an unencrypted message as an attack. I'm curious what sort of attack you're envisioning here: what are the motives of the attacker, and what is the harm to the attacked party? I have one idea -- a bit of a stretch IMO -- see below. But I wonder if there are others. > >> The originator of a message is in a better position to decide whether >> it contains sensitive information. And as the receiver you can't >> generally protect against the message traversing the network in the >> clear -- SMTP is often more than one hop and an earlier hop (or >> submission) could have been in the clear, even if you did require TLS >> for the last hop. > i do what is in my power to do. just because there might be a weakness > in the system n hops away does not mean i should indulge in weakness. Here's a possible attack: someone sends you a message in the clear falsely quoting you as conspiring criminally with them or some third party. This might be part of a blackmail scheme, or simply from someone who doesn't like you, analogous to the problems Brian Krebs has had with some Russians (http://www.onthemedia.org/2013/aug/02/russia-love-and-heroin/ ). The attacker's intent would be to encourage some party doing passive monitoring to subject you to additional (perhaps invasive) scrutiny. But since email isn't necessarily directly from originating to recipient MTA, your policy about requiring encrypted email doesn't necessarily succeed. The attacker sends the message to the intermediate MTA in the clear, the monitoring takes place, and your policy had no effect. We're going down a very speculative path because we're nowhere near e2e message privacy being the default. Personally, I'd rather focus on improvements that we can make given the current situation, not some possible future state of affairs. -Jim From stephen.farrell@cs.tcd.ie Sun Aug 18 09:42:15 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86F2B21F9B8D for ; Sun, 18 Aug 2013 09:42:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iSaFZ+WxQuHu for ; Sun, 18 Aug 2013 09:42:09 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 901EF21F9A15 for ; Sun, 18 Aug 2013 09:42:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 65596BE39; Sun, 18 Aug 2013 17:42:06 +0100 (IST) 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 HCbq88y0SImP; Sun, 18 Aug 2013 17:42:05 +0100 (IST) Received: from [10.128.56.104] (unknown [88.128.80.10]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 5E758BE33; Sun, 18 Aug 2013 17:42:05 +0100 (IST) Message-ID: <5210F95D.4060008@cs.tcd.ie> Date: Sun, 18 Aug 2013 17:42:05 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: Jim Fenton References: <520FE08B.80005@bluepopcorn.net> <5210643F.8030709@bluepopcorn.net> <5210F771.9090600@bluepopcorn.net> In-Reply-To: <5210F771.9090600@bluepopcorn.net> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Randy Bush , perpass@ietf.org Subject: Re: [perpass] Another mail-related proposal X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Aug 2013 16:42:15 -0000 Just on this particular attack: On 08/18/2013 05:33 PM, Jim Fenton wrote: > Here's a possible attack: someone sends you a message in the clear > falsely quoting you as conspiring criminally with them or some third > party. I think that's maybe on the boundaries of the scope here. Even if the sender and recipient both think the message is innocuous, the monitoring folks might not, so I'm not sure that specific malicious content like that is what we ought be worrying about in this context. Put another way, that's an attack that's enabled by monitoring, since if the monitoring wasn't likely or easy, the attacker probably wouldn't try this method. S. From fenton@bluepopcorn.net Sun Aug 18 09:44:05 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B668021F9B90 for ; Sun, 18 Aug 2013 09:44:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Th9gDtI+eKDs for ; Sun, 18 Aug 2013 09:44:05 -0700 (PDT) Received: from kernel.bluepopcorn.net (ipv6.bluepopcorn.net [IPv6:2001:470:1f05:bfe:21a:70ff:fe11:c889]) by ietfa.amsl.com (Postfix) with ESMTP id 1DC3B21F9B8D for ; Sun, 18 Aug 2013 09:44:05 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by kernel.bluepopcorn.net (8.14.4/8.14.4/Debian-2.1ubuntu1) with ESMTP id r7IGi3C4005527; Sun, 18 Aug 2013 09:44:03 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1376844244; bh=XvJvlcL6iDQxjvWyLBF915d5AiyhVyB/XqDYLzaWJ3w=; h=Date:From:To:CC:Subject:References:In-Reply-To:From; b=OfWzKttwqUwalmGmpl+4n9XXChsPfRC6Hw30L56cevJcFG4dR3JUc8wiKmfbVsvcy bVwbZAAojVc2tBo7lvGanKRgls9wwqFoZ3TCWy1NlLqmYDATmkbb/r88FU9LDebpGK qZudE3Q/0zJ8HKX6nWquSJPxP3NQH9eRJu0TYt+0= Message-ID: <5210F9D3.5010302@bluepopcorn.net> Date: Sun, 18 Aug 2013 09:44:03 -0700 From: Jim Fenton User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: Dan Schlitt References: <520FE08B.80005@bluepopcorn.net> <5210643F.8030709@bluepopcorn.net> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: perpass@ietf.org Subject: Re: [perpass] Another mail-related proposal X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Aug 2013 16:44:05 -0000 On 08/18/2013 07:01 AM, Dan Schlitt wrote: > > I thought that I was long ago taught that encrypting only messages > with "sensitive information" in them was bad security. The encrypted > messages called attention to them and even if they could not be read > were subject to traffic analysis. > What I'm proposing is slightly different. We would still encrypt (at transport level) all messages when that's possible, and the sensitivity of the message would be visible only if the receiving MTA doesn't support TLS or offer this extension. The sending MTA would first STARTTLS, and if that fails would just QUIT, not giving a specific indication about why it didn't send a message (although there would be circumstantial evidence, of course). Interesting observation. -Jim From trammell@tik.ee.ethz.ch Sun Aug 18 11:45:36 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 272C521F92B8 for ; Sun, 18 Aug 2013 11:45:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r8bHZ8ND-nsI for ; Sun, 18 Aug 2013 11:45:31 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id B70CA21F8617 for ; Sun, 18 Aug 2013 11:45:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 5CD6ED930A for ; Sun, 18 Aug 2013 20:45:29 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id m+A0slc74WBp for ; Sun, 18 Aug 2013 20:45:29 +0200 (MEST) Received: from [10.0.27.100] (cust-integra-122-165.antanet.ch [80.75.122.165]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id D5805D9309 for ; Sun, 18 Aug 2013 20:45:28 +0200 (MEST) From: Brian Trammell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <2941892B-9F23-46F9-B993-446D7800A0DF@tik.ee.ethz.ch> Date: Sun, 18 Aug 2013 20:45:26 +0200 To: perpass@ietf.org Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [perpass] On the perfect passive adversary, men at the end, and configuration versus mechanism X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Aug 2013 18:45:36 -0000 Greetings, all, On the floor of my home directory, there are notes for a paper we never = finished called "The Perfect Passive Adversary"; intended as a survey of = the state of the network security and measurement literature and = practice to explain what is possible if one assumes an adversary which = can (1) observe every packet of every communication at every point = within a network but (2) does not have access to the endpoints beyond = the network interface (i.e. no keyloggers, and no bulk access to user = data at a service provider) and (3) cannot influence packet forwarding. = It grew to be rather too wide in scope and too paranoid in tone to have = a realistic chance at publication, so we dropped it, which in retrospect = seems a silly choice. I would propose that we consider this as one of the threat models we = address; the exercise I propose is to examine the protocols we're = familiar with and think about (1) what's in the payload, (2) what can be = inferred from identifying metadata (IP addresses and port numbers, = application-layer addresses (email addresses, URLs, etc) (3) what can be = inferred from non-identifying metadata (data volume and packet counts, = interarrival times, control information such as sequence numbers, and = so on). It looks like this conversation is already well underway on the email = side of the house, which is good. :) What follows are some further = musings on the limitations of this approach. In general, increasing use of end-to-end transport encryption[1] = mitigates the threat of eavesdropping by a man in the middle; indeed, = threat models involving intermediate eavesdropping are at this point = extremely well understood, and well defended against, barring problems = with the crypto protocols that I'm not a good enough cryptographer to = understand. A perfect passive adversary generally won't even bother = trying to break this link: it's too strong, a testament to the attention = that's been paid to it over the decades. Such an adversary could look = for unprotected side-channels (e.g., SSH keystroke timing attacks, = static HTTPS content size/timing fingerprints), or could give up on = payload altogether and attempt to make inferences just from the flow = keys (this being the point of large-scale metadata collection). There are defenses against this: we can certainly work to increase the = cost of inference, through guidelines to inject randomness into = non-identifying metadata (at the cost of latency and throughput) in = protocols where the identifying metadata and content are already = effectively cryptographically protected. End systems and end users still = need to be identified by enough of an address to route packets and = messages to them, though, and these addresses can generally be mapped to = some set of real-world entities as well as a set of real-world = locations, so there are limits to how far we can go within the present = architecture. (Randy's suggestion to encrypt BGP to make passive network = topology observation more difficult might help here -- though the = prospect dismays me as a network researcher with an interest in keeping = data as open as possible, it's intriguing from a privacy and security = standpoint.) However, being a perfect passive adversary is terribly expensive and = doesn't work nearly as well as just compromising the end systems, = whether through the traditional phishing, social engineering, rootkits = and keyloggers or through cooperation and court orders, as recent = revelations have shown. This illustrates the first limitation: (1) The most serious threats today reside outside the scope of the = network and its protocols. It's not the men in the middle we should be = worried about, it's the men at the end. It's not clear that we can do = anything about this at all. The tools of monitoring themselves are also applicable to operations and = management, which is where I got started in the IETF, working on the = protocols that are perhaps most directly applicable to network = monitoring at the scale applicable to pervasive passive surveillance, = IPFIX (RFC5101 and draft-ietf-ipfix-protocol-rfc5101bis) and PSAMP = (RFC5474-5477). Here, we've defined protocols that by _necessity_ enable = large-scale passive data collection. That's what they were designed to = do, though of course they were designed with a rather more limited = applicability in mind, focusing on billing, capacity planning, = troubleshooting, and forensics and security monitoring on enterprise = networks. It was through working on these protocols that I remember that the IETF = made a policy statement on passive surveillance in the form of = wiretapping (full content delivery to a third party) thirteen years ago. = RFC 2804 states, in essence, that requirements for wiretapping are not = to be considered in the creation and maintenance of IETF standards, = though the reasoning presented behind this is rather more motivated by = practical concerns than an inherent desire to protect communications.=20 RFC 2804 has been generally cited as "we don't do wiretapping here", to = the extent that the security considerations of RFC 5476 (PSAMP) state = that "[t]he PSAMP Device SHOULD NOT export the full payload of = conversations, as this would mean wiretapping [RFC2804]. The PSAMP = Device MUST respect local privacy laws" -- in effect, though this is not = the _spirit_ of the statement, we say that a device in a jursidiction = with weak privacy laws with a full-payload sampling probability of 0.99 = is compliant, while one with a sampling probability of 1.00 is not. This = illustrates a second issue, which I think can be generalized (but maybe = I only think this because I'm a measurement geek): (2) Most (perhaps all) technologies that can be applied to passive = network measurement for operations and management purposes can be = applied to pervasive passive network surveillance: the only difference = is one of configuration and deployment. To me, this indicates we'll probably end up focusing more on = configuration and implementation guidance than on changing protocols, = except in those cases where protocols need specific support for = cryptography which they presently lack. This is probably a good thing. We spent a good deal of time thinking about these issues a few years ago = in the FP7-PRISM project (http://fp7-prism.eu) (no, not that PRISM; yes, = I appreciate the irony). PRISM essentially placed all configuration = decisions for measurement in the hands of a "privacy-preserving = controller", which would issue certificates bound to configuration = operations only if these passed a verification of the operation, = identity of the requestor, and purpose for which the request was made. = It also had the ability to degrade passive measurement configurations = (i.e. "you want full flow data, but have stated no purpose for which = that is allowed; here are 5-minute bins grouped by AS instead"). The = main problem with making something like this work is you need a formal = language to define all the possible things you can do with = passively-obtained measurement data so that you can do the verification. = You also need a trusted privacy-preserving controller which can sanction = a requestor for stating a false purpose -- in PRISM, we presumed this = would be a national data projection authority. But the architectural = principles may be applicable to "privacy by default" management = infrastructures. As far as the impact of management protocols on passive surveillance, we = can certainly issue more concrete statements about the IETF's position = on the use of such protocols, a la 2804, that we do not endorse = configurations supporting surveillance activities, but at the same time = it would be hard to redefine these protocols in a way to make their = misuse for surveillance more difficult without fundamentally disabling = them for their legitimate purposes. People are free to roundly ignore = any configuration advice we give, and generally will when there's no = interoperability benefit not to, so it's not clear that this would have = a great deal of impact. In general, though, focusing on protocols where necessary, configuration = where possible, and advice everywhere else seems like a good approach. Best regards, Brian [1] on one of the networks I'm doing research on, I was happily = surprised to see Port 443 flows very slightly outnumber Port 80 flows = for the first time in April of this year: HTTPS everywhere seems to be = having its intended effect. :)= From ynir@checkpoint.com Sun Aug 18 11:50:06 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BD9511E8184 for ; Sun, 18 Aug 2013 11:50:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.561 X-Spam-Level: X-Spam-Status: No, score=-10.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WYGyzgigkm8L for ; Sun, 18 Aug 2013 11:49:54 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 5192511E8174 for ; Sun, 18 Aug 2013 11:49:50 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r7IInlKF032757; Sun, 18 Aug 2013 21:49:47 +0300 X-CheckPoint: {5211174B-17-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.105]) by DAG-EX10.ad.checkpoint.com ([169.254.3.223]) with mapi id 14.02.0342.003; Sun, 18 Aug 2013 21:49:45 +0300 From: Yoav Nir To: Jim Fenton Thread-Topic: [perpass] Another mail-related proposal Thread-Index: AQHOm4qE4/ehqlydKEC7ZVdJ6iTZi5mZt1oAgACRQYCAABmzAIAAlcWAgAAl/AA= Date: Sun, 18 Aug 2013 18:49:45 +0000 Message-ID: References: <520FE08B.80005@bluepopcorn.net> <5210643F.8030709@bluepopcorn.net> <5210F771.9090600@bluepopcorn.net> In-Reply-To: <5210F771.9090600@bluepopcorn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.83] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean x-cpdlp: 11841697a4f4d29a8315acb7043052ef5624c4f6e1 Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Randy Bush , "" Subject: Re: [perpass] Another mail-related proposal X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Aug 2013 18:50:06 -0000 On Aug 18, 2013, at 7:33 PM, Jim Fenton wrote: > On 08/18/2013 12:37 AM, Randy Bush wrote: >>> I'm having more trouble coming up with use cases where I'd want to >>> reject messages that don't use PGP or S/MIME. >> visualize a future world where e2e message privacy is the default. in >> that world, some parties could view an unencrypted message as an attack. >=20 > I'm curious what sort of attack you're envisioning here: what are the > motives of the attacker, and what is the harm to the attacked party? I > have one idea -- a bit of a stretch IMO -- see below. But I wonder if > there are others. Here's one. You and Randy are exchanging some emails. They're all encrypted= , so listening in on your conversation is either impossible or prohibitivel= y expensive. But the attacker finds some bug in your mail client, that make= s it forget (or distrust) Randy's public key. Absent a public key, your mai= l client sends in the clear, and because of some BC code from the days when= not all mail was encrypted, Randy's mail client displays the message. Beca= use we all quote extensively, getting your side of the conversation is enou= gh. So the unencrypted message is not in itself an attack, but it is evidence o= f an attack. Does that mean it should be rejected? On the one hand, it's be= st to stop the conversation because it's not protected (and evidently is of= some interest to someone). On the other hand, it makes no sense that the l= ast message should be only available to an attacker. If some server in the = middle is set up to drop all messages that are not encrypted (and the recei= ver has published a public key), this server may end up being before the po= int where the attacker is listening, foiling the attack. So I guess that co= uld be an argument for dropping. Yoav From stephen.farrell@cs.tcd.ie Sun Aug 18 14:47:34 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB64D21F9CAC for ; Sun, 18 Aug 2013 14:47:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ldnzZT9r2HEv for ; Sun, 18 Aug 2013 14:47:30 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 1306921F9CB1 for ; Sun, 18 Aug 2013 14:47:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C2DEABE33; Sun, 18 Aug 2013 22:47:27 +0100 (IST) 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 CU2RF9qGrIak; Sun, 18 Aug 2013 22:47:25 +0100 (IST) Received: from [10.128.56.104] (unknown [88.128.80.10]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 75493BE2F; Sun, 18 Aug 2013 22:47:25 +0100 (IST) Message-ID: <521140EE.1080309@cs.tcd.ie> Date: Sun, 18 Aug 2013 22:47:26 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: Brian Trammell References: <2941892B-9F23-46F9-B993-446D7800A0DF@tik.ee.ethz.ch> In-Reply-To: <2941892B-9F23-46F9-B993-446D7800A0DF@tik.ee.ethz.ch> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: perpass@ietf.org Subject: Re: [perpass] On the perfect passive adversary, men at the end, and configuration versus mechanism X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Aug 2013 21:47:35 -0000 Hi Brian, First, thanks for the thoughtful post. You make some good points. A few responses below. Might be better to follow up in separate mails, since you raise too many interesting points probably:-) On 08/18/2013 07:45 PM, Brian Trammell wrote: > Greetings, all, > > On the floor of my home directory, there are notes for a paper we > never finished called "The Perfect Passive Adversary"; intended as a > survey of the state of the network security and measurement > literature and practice to explain what is possible if one assumes an > adversary which can (1) observe every packet of every communication > at every point within a network but (2) does not have access to the > endpoints beyond the network interface (i.e. no keyloggers, and no > bulk access to user data at a service provider) and (3) cannot > influence packet forwarding. It grew to be rather too wide in scope > and too paranoid in tone to have a realistic chance at publication, > so we dropped it, which in retrospect seems a silly choice. So publish it! As an I-D even:-) But if you have a version that you're happy to share, that'd be great to see. > I would propose that we consider this as one of the threat models we > address; the exercise I propose is to examine the protocols we're > familiar with and think about (1) what's in the payload, (2) what can > be inferred from identifying metadata (IP addresses and port numbers, > application-layer addresses (email addresses, URLs, etc) (3) what can > be inferred from non-identifying metadata (data volume and packet > counts, interarrival times, control information such as sequence > numbers, and so on). Taking a look at [1] would be good also for folks who weren't at the TLS wg session in Berlin - an 83% probability of identifying users based on the size of their FB avatar images as sent over TLS is an interesting result I think. [1] http://www.ietf.org/proceedings/87/slides/slides-87-tls-3.pdf But I absolutely agree that if we can somehow inventory the protocols which we know (each of us having different knowledge) from this pov that'd be valuable. (I'm hoping someone jumps in now to say they're interested in writing that up as an I-D or wiki or something.) > It looks like this conversation is already well underway on the email > side of the house, which is good. :) What follows are some further > musings on the limitations of this approach. > > In general, increasing use of end-to-end transport encryption[1] > mitigates the threat of eavesdropping by a man in the middle; indeed, > threat models involving intermediate eavesdropping are at this point > extremely well understood, and well defended against, barring > problems with the crypto protocols that I'm not a good enough > cryptographer to understand. A perfect passive adversary generally > won't even bother trying to break this link: it's too strong, a > testament to the attention that's been paid to it over the decades. > Such an adversary could look for unprotected side-channels (e.g., SSH > keystroke timing attacks, static HTTPS content size/timing > fingerprints), or could give up on payload altogether and attempt to > make inferences just from the flow keys (this being the point of > large-scale metadata collection). Well... the DNS records you look up, the .js & .jpg files you download (and when), the src/dest/port of various things... seems like there's maybe a lot that's there today. Not to mention the times when how to do crypto stuff is well defined but not used (RADIUS/Diameter as an example?) I think the inventory you suggest would be a fine thing were it to emerge from this list, esp. with a pervasive passive monitor in mind - which I don't think most of us have usually included in our threat models. > > There are defenses against this: we can certainly work to increase > the cost of inference, Yes, that's a good goal. But we also need to try understand how effective it might be, and at what cost. > through guidelines to inject randomness into > non-identifying metadata (at the cost of latency and throughput) in > protocols where the identifying metadata and content are already > effectively cryptographically protected. End systems and end users > still need to be identified by enough of an address to route packets > and messages to them, though, and these addresses can generally be > mapped to some set of real-world entities as well as a set of > real-world locations, so there are limits to how far we can go within > the present architecture. (Randy's suggestion to encrypt BGP to make > passive network topology observation more difficult might help here > -- though the prospect dismays me as a network researcher with an > interest in keeping data as open as possible, it's intriguing from a > privacy and security standpoint.) Agree. > > However, being a perfect passive adversary is terribly expensive and > doesn't work nearly as well as just compromising the end systems, > whether through the traditional phishing, social engineering, > rootkits and keyloggers or through cooperation and court orders, as > recent revelations have shown. One interpretation of the current news stories might be that its not so expensive to compromise some almost random but "nearby" end systems and have those contribute to your monitoring network. I could believe that its more expensive to very specifically target an attack at one end-system, particularly if you want to disguise the fact that you tried. > This illustrates the first > limitation: > > (1) The most serious threats today reside outside the scope of the > network and its protocols. It's not the men in the middle we should > be worried about, it's the men at the end. It's not clear that we can > do anything about this at all. I'd quibble a bit there. We spec protocols at many layers, and what's an endpoint for one, is the middle for others. > > The tools of monitoring themselves are also applicable to operations > and management, which is where I got started in the IETF, working on > the protocols that are perhaps most directly applicable to network > monitoring at the scale applicable to pervasive passive surveillance, Yep, that's a real issue - to what extent is it possible to be more robust against a pervasive passive monitor without buggering up n/w mgmt. I don't know the answer, but that's where the E in IETF should come into play. > IPFIX (RFC5101 and draft-ietf-ipfix-protocol-rfc5101bis) and PSAMP > (RFC5474-5477). Here, we've defined protocols that by _necessity_ > enable large-scale passive data collection. That's what they were > designed to do, though of course they were designed with a rather > more limited applicability in mind, focusing on billing, capacity > planning, troubleshooting, and forensics and security monitoring on > enterprise networks. > > It was through working on these protocols that I remember that the > IETF made a policy statement on passive surveillance in the form of > wiretapping (full content delivery to a third party) thirteen years > ago. RFC 2804 states, in essence, that requirements for wiretapping > are not to be considered in the creation and maintenance of IETF > standards, though the reasoning presented behind this is rather more > motivated by practical concerns than an inherent desire to protect > communications. > > RFC 2804 has been generally cited as "we don't do wiretapping here", > to the extent that the security considerations of RFC 5476 (PSAMP) > state that "[t]he PSAMP Device SHOULD NOT export the full payload of > conversations, as this would mean wiretapping [RFC2804]. The PSAMP > Device MUST respect local privacy laws" -- in effect, though this is > not the _spirit_ of the statement, we say that a device in a > jursidiction with weak privacy laws with a full-payload sampling > probability of 0.99 is compliant, while one with a sampling > probability of 1.00 is not. This illustrates a second issue, which I > think can be generalized (but maybe I only think this because I'm a > measurement geek): > > (2) Most (perhaps all) technologies that can be applied to passive > network measurement for operations and management purposes can be > applied to pervasive passive network surveillance: the only > difference is one of configuration and deployment. > > To me, this indicates we'll probably end up focusing more on > configuration and implementation guidance than on changing protocols, > except in those cases where protocols need specific support for > cryptography which they presently lack. This is probably a good > thing. > > We spent a good deal of time thinking about these issues a few years > ago in the FP7-PRISM project (http://fp7-prism.eu) (no, not that > PRISM; yes, I appreciate the irony). Are there any of the publications/deliverables from that that'd be a good read for folks on this list? (The site has too much to digest tonight:-) Cheers, S. > PRISM essentially placed all > configuration decisions for measurement in the hands of a > "privacy-preserving controller", which would issue certificates bound > to configuration operations only if these passed a verification of > the operation, identity of the requestor, and purpose for which the > request was made. It also had the ability to degrade passive > measurement configurations (i.e. "you want full flow data, but have > stated no purpose for which that is allowed; here are 5-minute bins > grouped by AS instead"). The main problem with making something like > this work is you need a formal language to define all the possible > things you can do with passively-obtained measurement data so that > you can do the verification. You also need a trusted > privacy-preserving controller which can sanction a requestor for > stating a false purpose -- in PRISM, we presumed this would be a > national data projection authority. But the architectural principles > may be applicable to "privacy by default" management > infrastructures. > > As far as the impact of management protocols on passive surveillance, > we can certainly issue more concrete statements about the IETF's > position on the use of such protocols, a la 2804, that we do not > endorse configurations supporting surveillance activities, but at the > same time it would be hard to redefine these protocols in a way to > make their misuse for surveillance more difficult without > fundamentally disabling them for their legitimate purposes. People > are free to roundly ignore any configuration advice we give, and > generally will when there's no interoperability benefit not to, so > it's not clear that this would have a great deal of impact. > > In general, though, focusing on protocols where necessary, > configuration where possible, and advice everywhere else seems like a > good approach. > > Best regards, > > Brian > > > [1] on one of the networks I'm doing research on, I was happily > surprised to see Port 443 flows very slightly outnumber Port 80 flows > for the first time in April of this year: HTTPS everywhere seems to > be having its intended effect. :) > _______________________________________________ perpass mailing list > perpass@ietf.org https://www.ietf.org/mailman/listinfo/perpass > From randy@psg.com Sun Aug 18 17:08:25 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75C4111E8198 for ; Sun, 18 Aug 2013 17:08:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.563 X-Spam-Level: X-Spam-Status: No, score=-2.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3CnS+MXWYL72 for ; Sun, 18 Aug 2013 17:08:25 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id E709421F994C for ; Sun, 18 Aug 2013 17:08:24 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1VBD1D-0003M7-Ae; Mon, 19 Aug 2013 00:08:23 +0000 Date: Mon, 19 Aug 2013 09:08:22 +0900 Message-ID: From: Randy Bush To: Jim Fenton In-Reply-To: <5210F9D3.5010302@bluepopcorn.net> References: <520FE08B.80005@bluepopcorn.net> <5210643F.8030709@bluepopcorn.net> <5210F9D3.5010302@bluepopcorn.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: perpass@ietf.org Subject: Re: [perpass] Another mail-related proposal X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 00:08:25 -0000 > What I'm proposing is slightly different. We would still encrypt (at > transport level) all messages when that's possible and the nsa pwns the disk drives of the smtp relays. e2e, please, in addition to transport. in 1984, all data and traffic should be encrypted. randy From stpeter@stpeter.im Sun Aug 18 18:44:04 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FED421F9C78 for ; Sun, 18 Aug 2013 18:44:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.545 X-Spam-Level: X-Spam-Status: No, score=-102.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PpbMLSgDdG5C for ; Sun, 18 Aug 2013 18:44:00 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id F263721F9C86 for ; Sun, 18 Aug 2013 18:43:58 -0700 (PDT) Received: from ergon.local (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id ADC49414F7; Sun, 18 Aug 2013 19:47:10 -0600 (MDT) Message-ID: <52117862.7050501@stpeter.im> Date: Sun, 18 Aug 2013 19:44:02 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Stephen Farrell References: <2941892B-9F23-46F9-B993-446D7800A0DF@tik.ee.ethz.ch> <521140EE.1080309@cs.tcd.ie> In-Reply-To: <521140EE.1080309@cs.tcd.ie> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: perpass@ietf.org, Brian Trammell Subject: Re: [perpass] On the perfect passive adversary, men at the end, and configuration versus mechanism X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 01:44:04 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 8/18/13 3:47 PM, Stephen Farrell wrote: > > On 08/18/2013 07:45 PM, Brian Trammell wrote: >> >> I would propose that we consider this as one of the threat models >> we address; the exercise I propose is to examine the protocols >> we're familiar with and think about (1) what's in the payload, >> (2) what can be inferred from identifying metadata (IP addresses >> and port numbers, application-layer addresses (email addresses, >> URLs, etc) (3) what can be inferred from non-identifying metadata >> (data volume and packet counts, interarrival times, control >> information such as sequence numbers, and so on). > > Taking a look at [1] would be good also for folks who weren't at > the TLS wg session in Berlin - an 83% probability of identifying > users based on the size of their FB avatar images as sent over TLS > is an interesting result I think. > > [1] http://www.ietf.org/proceedings/87/slides/slides-87-tls-3.pdf > > But I absolutely agree that if we can somehow inventory the > protocols which we know (each of us having different knowledge) > from this pov that'd be valuable. I've thought about this over the last few months in relation to XMPP-based instant messaging. My conclusions are (a) XMPP cannot be made into a privacy-protecting technology (even if we could settle on a sustainable approach to end-to-end encryption) and (b) we'll need to develop new technologies that are universally encrypted, don't rely on DNS-based addresses, a federated network of servers, etc. I still think there is value in pushing for universal TLS for both client-to-server and server-to-server connections in XMPP, publishing an RFC for OTR and encouraging more implementations thereof, and so on. However, I'm not confident that such improvements will address the fundamental issues that have arisen over the last few months. > (I'm hoping someone jumps in now to say they're interested in > writing that up as an I-D or wiki or something.) Right now I'm more interested in helping out on code and spec work related to a project that I think has promise. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSEXhhAAoJEOoGpJErxa2pHNAP/3zKGs+2eXnSK8s4UmJHu/eU dGW53BXkk8nJDBsj0qQsWwuvPRH/9hjRhpJXErRVKfKSB+lVPqL16HF/RBCvHZC7 WHlKxIHqJ+pGqgS6WXSOtl/3IyWB4wHvkzKYjLRJGYn/rCevGMkzrjMZ1UncMkGC 6P5Rl5Itpz1opCBijxBxYIIVXTaZXt+s4qGLxOhL+18oPZ1ujwuUtHpY5Mlk+mxJ nHM2cebPIzJ38bI5MLqkTLvpSryydI+Hd6apq+U1yDWW4hr05wVDmsh3R0kH+9vU sdqrKzKLDL9UtKwWa98uAMs+bBt91lDLgEg1lestd1K6SZ7sEvnUVYQJB+AZ8WfE 06NfmJ0O6nIJ978oZ4DSDi+EsBWX2375TJYzTdXWtt+Hq1zT8dgl2qwQBgwp+zPg LYrHtlEPB3nug5GV0DU3JSRBXpd/Hqg+2IcSuUBME4SyYw6sirnhycl9WLJIGVjJ BKKV2pWA69lunKbP6EsXHYPzJoL8eKT65FpmZxCoMlBy7djZ1NQUo7iXquD6uteZ LutulZ2LNAopIxFoONcLs2JDKJmsmX6pAN7J1bduyaNXNqlt+aetlkT+jZ5VCPCv aQI2l166tsRIqXF3QFO6PrikgaJpxN4Hfx2gxsTwO9mVOrcbSQY/NyE8hiMELJdC Pwlo+M8Bp7gzlLtVQcO1 =TyeE -----END PGP SIGNATURE----- From randy@psg.com Sun Aug 18 20:14:42 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B07F11E81A7 for ; Sun, 18 Aug 2013 20:14:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5QI-jZrJzVKW for ; Sun, 18 Aug 2013 20:14:41 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id C41AF11E815C for ; Sun, 18 Aug 2013 20:14:41 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1VBFvR-00048i-I2 for perpass@ietf.org; Mon, 19 Aug 2013 03:14:37 +0000 Date: Mon, 19 Aug 2013 12:14:36 +0900 Message-ID: From: Randy Bush To: perpass User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Subject: [perpass] adding noise to browsing X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 03:14:42 -0000 https://chrome.google.com/webstore/detail/paranoid-browsing/hnfdeaekggfbgjljcfdbfdhffoeopmbe/ From trammell@tik.ee.ethz.ch Mon Aug 19 00:01:02 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2C6F21F98AD for ; Mon, 19 Aug 2013 00:01:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4drRNbwninN0 for ; Mon, 19 Aug 2013 00:00:57 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id D46A621F97E6 for ; Mon, 19 Aug 2013 00:00:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 7EFD6D930A; Mon, 19 Aug 2013 09:00:48 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 1hMBIQHlVg4H; Mon, 19 Aug 2013 09:00:48 +0200 (MEST) Received: from [10.0.27.100] (cust-integra-122-165.antanet.ch [80.75.122.165]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 2B337D9308; Mon, 19 Aug 2013 09:00:48 +0200 (MEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Brian Trammell In-Reply-To: <521140EE.1080309@cs.tcd.ie> Date: Mon, 19 Aug 2013 09:00:46 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <436E1732-663B-42BF-8CA9-DFE48724D1F6@tik.ee.ethz.ch> References: <2941892B-9F23-46F9-B993-446D7800A0DF@tik.ee.ethz.ch> <521140EE.1080309@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1508) Cc: perpass@ietf.org Subject: Re: [perpass] On the perfect passive adversary X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 07:01:02 -0000 hi Stephen, all, Yeah, sorry for the giant multitopic rant. I'll split this out into a = few threads to continue... On Aug 18, 2013, at 11:47 PM, Stephen Farrell = wrote: >=20 > Hi Brian, >=20 > First, thanks for the thoughtful post. You make some good points. > A few responses below. Might be better to follow up in separate > mails, since you raise too many interesting points probably:-) >=20 > On 08/18/2013 07:45 PM, Brian Trammell wrote: >> Greetings, all, >>=20 >> On the floor of my home directory, there are notes for a paper we >> never finished called "The Perfect Passive Adversary"; intended as a >> survey of the state of the network security and measurement >> literature and practice to explain what is possible if one assumes an >> adversary which can (1) observe every packet of every communication >> at every point within a network but (2) does not have access to the >> endpoints beyond the network interface (i.e. no keyloggers, and no >> bulk access to user data at a service provider) and (3) cannot >> influence packet forwarding. It grew to be rather too wide in scope >> and too paranoid in tone to have a realistic chance at publication, >> so we dropped it, which in retrospect seems a silly choice. >=20 > So publish it! As an I-D even:-) But if you have a version that > you're happy to share, that'd be great to see. I dusted this off and had a look at it last night, and it's in worse = shape than I'd thought as a coherent piece of work. But completing it = (to -00 I-D quality, at least) and publishing an I-D -- especially given = the scope of the conversation on this list -- seems like a great idea. = I'll get started. >> I would propose that we consider this as one of the threat models we >> address; the exercise I propose is to examine the protocols we're >> familiar with and think about (1) what's in the payload, (2) what can >> be inferred from identifying metadata (IP addresses and port numbers, >> application-layer addresses (email addresses, URLs, etc) (3) what can >> be inferred from non-identifying metadata (data volume and packet >> counts, interarrival times, control information such as sequence >> numbers, and so on). >=20 > Taking a look at [1] would be good also for folks who weren't at the > TLS wg session in Berlin - an 83% probability of identifying users > based on the size of their FB avatar images as sent over TLS is an > interesting result I think. >=20 > [1] http://www.ietf.org/proceedings/87/slides/slides-87-tls-3.pdf >=20 > But I absolutely agree that if we can somehow inventory the protocols > which we know (each of us having different knowledge) from this pov > that'd be valuable. (I'm hoping someone jumps in now to say they're > interested in writing that up as an I-D or wiki or something.) Wasn't at the TLS WG, thanks for the pointer! This is a specific case of = the general metadata fingerprinting problem (which, incidentally, is why = I don't believe in anonymization any more). It's good to see awareness = of this spreading. >> It looks like this conversation is already well underway on the email >> side of the house, which is good. :) What follows are some further >> musings on the limitations of this approach. >>=20 >> In general, increasing use of end-to-end transport encryption[1] >> mitigates the threat of eavesdropping by a man in the middle; indeed, >> threat models involving intermediate eavesdropping are at this point >> extremely well understood, and well defended against, barring >> problems with the crypto protocols that I'm not a good enough >> cryptographer to understand. A perfect passive adversary generally >> won't even bother trying to break this link: it's too strong, a >> testament to the attention that's been paid to it over the decades. >> Such an adversary could look for unprotected side-channels (e.g., SSH >> keystroke timing attacks, static HTTPS content size/timing >> fingerprints), or could give up on payload altogether and attempt to >> make inferences just from the flow keys (this being the point of >> large-scale metadata collection). >=20 > Well... the DNS records you look up, the .js & .jpg files you download > (and when), the src/dest/port of various things... seems like there's > maybe a lot that's there today. Not to mention the times when how to > do crypto stuff is well defined but not used (RADIUS/Diameter as an > example?) DNS radiates a _whole lot_ of information, and does so all over the = place: if you own the path to an anycast instance of a root server, you = get a 1/n sample of every query on the Internet not cached at a = recursive resolver. It's at least widely used in stateless censorship = (see Anonymous, "The Collateral Damage of Internet Censorship by DNS = injection", ACM CCR July 2012); we must assume it's in wide use for = pervasive monitoring as well. >=20 > I think the inventory you suggest would be a fine thing were it to > emerge from this list, esp. with a pervasive passive monitor in > mind - which I don't think most of us have usually included in our > threat models. I'll get started on the perfect passive adversary I-D -- at least to = define the threat model a bit -- hopefully in the coming couple of weeks = (under a bit of deadline pressure at the moment :/ ) I could certainly = also coordinate contributions of specific instances of information = radiation coming off of various protocols into this I-D. Best regards, Brian From trammell@tik.ee.ethz.ch Mon Aug 19 00:01:35 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A78C421F9931 for ; Mon, 19 Aug 2013 00:01:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ooAsIiMuoatJ for ; Mon, 19 Aug 2013 00:01:31 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 0D19021F97E6 for ; Mon, 19 Aug 2013 00:01:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 6E01AD930A; Mon, 19 Aug 2013 09:01:30 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 1e-DmZfeP0RD; Mon, 19 Aug 2013 09:01:30 +0200 (MEST) Received: from [10.0.27.100] (cust-integra-122-165.antanet.ch [80.75.122.165]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 20A42D9308; Mon, 19 Aug 2013 09:01:30 +0200 (MEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Brian Trammell In-Reply-To: <521140EE.1080309@cs.tcd.ie> Date: Mon, 19 Aug 2013 09:01:30 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <325C8B61-10C3-4138-AC28-124C93BB5CE4@tik.ee.ethz.ch> References: <2941892B-9F23-46F9-B993-446D7800A0DF@tik.ee.ethz.ch> <521140EE.1080309@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1508) Cc: perpass@ietf.org Subject: Re: [perpass] On configuration versus mechanism X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 07:01:35 -0000 hi Stephen, all, On Aug 18, 2013, at 11:47 PM, Stephen Farrell = wrote: >=20 > Hi Brian, >=20 > First, thanks for the thoughtful post. You make some good points. > A few responses below. Might be better to follow up in separate > mails, since you raise too many interesting points probably:-) >=20 > On 08/18/2013 07:45 PM, Brian Trammell wrote: >> The tools of monitoring themselves are also applicable to operations >> and management, which is where I got started in the IETF, working on >> the protocols that are perhaps most directly applicable to network >> monitoring at the scale applicable to pervasive passive surveillance, >=20 > Yep, that's a real issue - to what extent is it possible to be more > robust against a pervasive passive monitor without buggering up n/w > mgmt. I don't know the answer, but that's where the E in IETF should > come into play. One of the bits of relatively obvious guidance that came out of PRISM = was "throw away what you don't need as early as you can": an added bonus = is that this makes passive measurement scale a lot better too, because = you're not keeping around a lot of useless state. This is a little = contrary to the practice of science -- collect all you can and analyze = later -- but has a real impact on the privacy risk of these = technologies. In jurisdictions with serious privacy laws, it's the only = way to operate. For example (hey look, another anecdote! ;) ) a few = years ago [1], Google was cited by the German data protection authority = for driving Street View cars around and saving all the (open) wireless = traffic they saw -- including partial payload -- in order to do a later = analysis of BSSIDs seen for geolocation purposes. Presumably this was = either a packet capture misconfiguration or a bit of engineering = laziness, which could have been avoided simply by making the software in = the cars smarter about what they kept. In passive monitoring for management and operations, this means each = collection activity should have a specified purpose, and information = irrelevant to that purpose simply shouldn't be collected at the = observation point. This is admittedly easier for some things (passive = performance characterization) than for others (billing and = troubleshooting, both of which need to identify the endpoints).=20 There's a metarequirement here, which should be explicitly stated: = anything we do to protect a protocol against passive monitoring should = take the manageability of the result into account. >> IPFIX (RFC5101 and draft-ietf-ipfix-protocol-rfc5101bis) and PSAMP >> (RFC5474-5477). Here, we've defined protocols that by _necessity_ >> enable large-scale passive data collection. That's what they were >> designed to do, though of course they were designed with a rather >> more limited applicability in mind, focusing on billing, capacity >> planning, troubleshooting, and forensics and security monitoring on >> enterprise networks. >>=20 >> It was through working on these protocols that I remember that the >> IETF made a policy statement on passive surveillance in the form of >> wiretapping (full content delivery to a third party) thirteen years >> ago. RFC 2804 states, in essence, that requirements for wiretapping >> are not to be considered in the creation and maintenance of IETF >> standards, though the reasoning presented behind this is rather more >> motivated by practical concerns than an inherent desire to protect >> communications. >>=20 >> RFC 2804 has been generally cited as "we don't do wiretapping here", >> to the extent that the security considerations of RFC 5476 (PSAMP) >> state that "[t]he PSAMP Device SHOULD NOT export the full payload of >> conversations, as this would mean wiretapping [RFC2804]. The PSAMP >> Device MUST respect local privacy laws" -- in effect, though this is >> not the _spirit_ of the statement, we say that a device in a >> jursidiction with weak privacy laws with a full-payload sampling >> probability of 0.99 is compliant, while one with a sampling >> probability of 1.00 is not. This illustrates a second issue, which I >> think can be generalized (but maybe I only think this because I'm a >> measurement geek): >>=20 >> (2) Most (perhaps all) technologies that can be applied to passive >> network measurement for operations and management purposes can be >> applied to pervasive passive network surveillance: the only >> difference is one of configuration and deployment. >>=20 >> To me, this indicates we'll probably end up focusing more on >> configuration and implementation guidance than on changing protocols, >> except in those cases where protocols need specific support for >> cryptography which they presently lack. This is probably a good >> thing. >>=20 >> We spent a good deal of time thinking about these issues a few years >> ago in the FP7-PRISM project (http://fp7-prism.eu) (no, not that >> PRISM; yes, I appreciate the irony).=20 >=20 > Are there any of the publications/deliverables from that that'd > be a good read for folks on this list? (The site has too much to > digest tonight:-) Unfortunately, in the public deliverables, not really; they're all a bit = too wordy to jump into and really understand what's going on, and the = target moved a bit during the project, which makes it difficult to start = at the introductory material and understand where we ended up. = Originally, we were looking into using homomorphic encryption in network = monitoring -- projecting filtering and aggregation operations into = encrypted data space, and decrypting only the results -- but this turned = out (perhaps not surprisingly) not to scale very well. There's a very quick and inadequately detailed introduction to the = architecture in "An introduction to IPFIX", IEEE Communications = Magazine, April 2011. Sections 2 and 3.1 of = http://telscom.ch/wp-content/uploads/Prism/FP7-PRISM-WP2.2-D2.2.2.pdf = are reasonably understandable on their own; the rest of the document = gets very rapidly into the gory details. In any case, I'd suggest taking architectural guidance from the general = pattern of usage (separating measurement configuration control from = measurement configuration, protecting the channel with single-use = credentials) as opposed to trying to implement PRISM as is. Best regards, Brian [1] = http://googleblog.blogspot.ch/2010/05/wifi-data-collection-update.html From trammell@tik.ee.ethz.ch Mon Aug 19 00:03:12 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 379DC11E8204 for ; Mon, 19 Aug 2013 00:03:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kJvguRGa8Jdc for ; Mon, 19 Aug 2013 00:03:06 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 1FF0921F9926 for ; Mon, 19 Aug 2013 00:03:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 81EEED930B; Mon, 19 Aug 2013 09:03:05 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id fmmTBXBoBJGn; Mon, 19 Aug 2013 09:03:05 +0200 (MEST) Received: from [10.0.27.100] (cust-integra-122-165.antanet.ch [80.75.122.165]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 3FE0ED9308; Mon, 19 Aug 2013 09:03:05 +0200 (MEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Brian Trammell In-Reply-To: <521140EE.1080309@cs.tcd.ie> Date: Mon, 19 Aug 2013 09:03:04 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2941892B-9F23-46F9-B993-446D7800A0DF@tik.ee.ethz.ch> <521140EE.1080309@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1508) Cc: perpass@ietf.org Subject: Re: [perpass] On men at the end X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 07:03:12 -0000 hi Stephen, all, and on a third topic, briefly... On Aug 18, 2013, at 11:47 PM, Stephen Farrell = wrote: >=20 > Hi Brian, >=20 > First, thanks for the thoughtful post. You make some good points. > A few responses below. Might be better to follow up in separate > mails, since you raise too many interesting points probably:-) >=20 > On 08/18/2013 07:45 PM, Brian Trammell wrote: >>=20 >> However, being a perfect passive adversary is terribly expensive and >> doesn't work nearly as well as just compromising the end systems, >> whether through the traditional phishing, social engineering, >> rootkits and keyloggers or through cooperation and court orders, as >> recent revelations have shown.=20 >=20 > One interpretation of the current news stories might be that its > not so expensive to compromise some almost random but "nearby" end > systems and have those contribute to your monitoring network. I > could believe that its more expensive to very specifically target > an attack at one end-system, particularly if you want to disguise > the fact that you tried. True. Bots get more expensive the more specific you want to be about = where and what they are. But here you're compromising end systems and = using them as middle systems, which is a bit different than owning the = end host of a targeted individual, turning on his webcam, and having a = look around his flat. One of the points of the perfect passive adversary attack model is that = it illustrates that you don't really _need_ to compromise the ends to = get a _whole lot_ of information. When the passive monitoring is done at = the physical layer, you can't even detect its presence from the ends. = Sitting at the endpoints is infinitely more detectable, and you have to = conceal your presence through technical and/or legal countermeasures.=20 >> This illustrates the first >> limitation: >>=20 >> (1) The most serious threats today reside outside the scope of the >> network and its protocols. It's not the men in the middle we should >> be worried about, it's the men at the end. It's not clear that we can >> do anything about this at all. >=20 > I'd quibble a bit there. We spec protocols at many layers, and what's > an endpoint for one, is the middle for others. Point. I don't mean that it's useless to work on better securing the = middle -- anything we can do to increase the cost of indiscriminate, = pervasive passive surveillance is a Good Thing. I'm just saying that we = shouldn't be surprised when the reaction to the increased cost of = pervasive passive monitoring at layers 1 through 7 is a layer 9 attack: = new legislation compelling every access provider, service provider, and = blogger with comments on in a given jurisdiction to deliver detailed = application-level logging information to the authority designated for = the purpose. Best regards, Brian= From fenton@bluepopcorn.net Mon Aug 19 13:49:27 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D21111E82F3 for ; Mon, 19 Aug 2013 13:49:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KM-lyddRZI17 for ; Mon, 19 Aug 2013 13:49:24 -0700 (PDT) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4F0AB11E82EF for ; Mon, 19 Aug 2013 13:49:16 -0700 (PDT) Received: from splunge-2.local (70-90-161-117-ca.sfba.hfc.comcastbusiness.net [70.90.161.117]) (authenticated bits=0) by v2.bluepopcorn.net (8.14.3/8.14.3/Debian-9.4) with ESMTP id r7JIrdRL007444; Mon, 19 Aug 2013 11:53:40 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1376938420; bh=kOeHDXWWbjwfjBWzHkb3sqftp0A6JIIMubVFlEXc+IE=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=VwuKF5ucp6xEpB9rtok3Y211Aq2LdtkUZMEU0SRaUW6VyfdGGvIhVHZ1ng8tEa7bV 8azyO3RPh5UTh6aFVNtM71cnuSf8m7c5Jfl3wsISgF06BT2lilasR79IstI5whqJkr IQ1c9OCJLoIrnePC6IIObsIX6E+0eRKDRoGbks1Q= Message-ID: <521269AF.9010509@bluepopcorn.net> Date: Mon, 19 Aug 2013 11:53:35 -0700 From: Jim Fenton User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Yoav Nir References: <520FE08B.80005@bluepopcorn.net> <5210643F.8030709@bluepopcorn.net> <5210F771.9090600@bluepopcorn.net> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Randy Bush , "" Subject: Re: [perpass] Another mail-related proposal X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 20:49:27 -0000 On 8/18/13 11:49 AM, Yoav Nir wrote: > On Aug 18, 2013, at 7:33 PM, Jim Fenton > wrote: > >> On 08/18/2013 12:37 AM, Randy Bush wrote: >>>> I'm having more trouble coming up with use cases where I'd want to >>>> reject messages that don't use PGP or S/MIME. >>> visualize a future world where e2e message privacy is the default. in >>> that world, some parties could view an unencrypted message as an attack. >> I'm curious what sort of attack you're envisioning here: what are the >> motives of the attacker, and what is the harm to the attacked party? I >> have one idea -- a bit of a stretch IMO -- see below. But I wonder if >> there are others. > Here's one. You and Randy are exchanging some emails. They're all encrypted, so listening in on your conversation is either impossible or prohibitively expensive. But the attacker finds some bug in your mail client, that makes it forget (or distrust) Randy's public key. Absent a public key, your mail client sends in the clear, and because of some BC code from the days when not all mail was encrypted, Randy's mail client displays the message. Because we all quote extensively, getting your side of the conversation is enough. > > So the unencrypted message is not in itself an attack, but it is evidence of an attack. Does that mean it should be rejected? On the one hand, it's best to stop the conversation because it's not protected (and evidently is of some interest to someone). On the other hand, it makes no sense that the last message should be only available to an attacker. If some server in the middle is set up to drop all messages that are not encrypted (and the receiver has published a public key), this server may end up being before the point where the attacker is listening, foiling the attack. So I guess that could be an argument for dropping. > That's an interesting use case, in part because something similar happened to me the other day. I had sent a PGP-encrypted message to someone who (not Randy of course) replied in the clear, quoting much of my original message. The message wasn't all that sensitive, and my correspondent was a new PGP user, but it seemed like a breach of etiquette. In your example, the attack is only foiled if the attacker has not monitored the link between the originator and the server in the middle, which will not be the case if monitoring is indeed pervasive. Transport encryption might help with this. One of the difficulties I see is that the policy (perhaps not the best word) for expressing a desire for all mail to be e2e encrypted is very fine grained -- probably down to the individual email address. Publishing and querying that information is likely to involve a whole new set of of privacy concerns. Note, for example, that I'm not suggesting that we publish that preference with WebFinger. -Jim From fenton@bluepopcorn.net Mon Aug 19 13:49:27 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0FE511E82EF for ; Mon, 19 Aug 2013 13:49:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hE5sADt8fFOV for ; Mon, 19 Aug 2013 13:49:27 -0700 (PDT) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) by ietfa.amsl.com (Postfix) with ESMTP id BDA1011E82FE for ; Mon, 19 Aug 2013 13:49:19 -0700 (PDT) Received: from splunge-2.local (70-90-161-117-ca.sfba.hfc.comcastbusiness.net [70.90.161.117]) (authenticated bits=0) by v2.bluepopcorn.net (8.14.3/8.14.3/Debian-9.4) with ESMTP id r7JITw4G007402; Mon, 19 Aug 2013 11:30:00 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1376937000; bh=zqD5SqQbFbHZcHTDDZ+hTX5zlmbi94ZKOO3fLiwgfFk=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=IZ7jldQPV8+FWguVT7bv4p1jLDNdI9uts4l+k+CsWY3/bKMX89ET49fbAsGK8lvb2 7beJS8sBsYmbIKEmOWLeAjS91t0Xjupm3wK6abGfRRVi7A+WzJKQBaNLEtvGBrlCXf jv31k29TF320cq+dECr5pcrSg1DQYMBO3anV7o2w= Message-ID: <52126423.2050209@bluepopcorn.net> Date: Mon, 19 Aug 2013 11:29:55 -0700 From: Jim Fenton User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Randy Bush References: <520FE08B.80005@bluepopcorn.net> <5210643F.8030709@bluepopcorn.net> <5210F9D3.5010302@bluepopcorn.net> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: perpass@ietf.org Subject: Re: [perpass] Another mail-related proposal X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 20:49:27 -0000 On 8/18/13 5:08 PM, Randy Bush wrote: >> What I'm proposing is slightly different. We would still encrypt (at >> transport level) all messages when that's possible > and the nsa pwns the disk drives of the smtp relays. e2e, please, in > addition to transport. in 1984, all data and traffic should be > encrypted. > That goes to the question I had in my original message on this thread: what is the threat model we are attempting to address? In the short term at least, I consider transport-level encryption of email to be helpful, because it raises the required attack complexity. I also wonder if pwning the disk drives of the smtp relays is really a passive attack. But I don't have the context of the discussions in Berlin, so perhaps 'passive' is being interpreted broadly. -Jim From randy@psg.com Mon Aug 19 17:38:50 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F97911E81E6 for ; Mon, 19 Aug 2013 17:38:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.95 X-Spam-Level: X-Spam-Status: No, score=-1.95 tagged_above=-999 required=5 tests=[AWL=-0.591, BAYES_00=-2.599, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ns+S0b3N4PA9 for ; Mon, 19 Aug 2013 17:38:49 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id 21CEF11E80A2 for ; Mon, 19 Aug 2013 17:38:49 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1VBZy9-0005qs-Rm; Tue, 20 Aug 2013 00:38:46 +0000 Date: Tue, 20 Aug 2013 09:38:44 +0900 Message-ID: From: Randy Bush To: Jim Fenton In-Reply-To: <52126423.2050209@bluepopcorn.net> References: <520FE08B.80005@bluepopcorn.net> <5210643F.8030709@bluepopcorn.net> <5210F9D3.5010302@bluepopcorn.net> <52126423.2050209@bluepopcorn.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: perpass@ietf.org Subject: Re: [perpass] Another mail-related proposal X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 00:38:50 -0000 >> and the nsa pwns the disk drives of the smtp relays. e2e, please, in >> addition to transport. in 1984, all data and traffic should be >> encrypted. > That goes to the question I had in my original message on this thread: > what is the threat model we are attempting to address? In the short term > at least, I consider transport-level encryption of email to be helpful, > because it raises the required attack complexity. i agree transport should be encrypted. and, as someone has pointed out, we should know when that negotiation is not successful and be able to make some decisions. smtp is hop by hop. just because A encrypts to B, A has zero assurance that B encrypts to C. hence, e2e encryption is pretty much mandatory against a purely passive attacker. randy From randy@psg.com Mon Aug 19 17:43:16 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9503811E830F for ; Mon, 19 Aug 2013 17:43:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.537 X-Spam-Level: X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lk+SD2KbQAke for ; Mon, 19 Aug 2013 17:43:16 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id 3745A11E8303 for ; Mon, 19 Aug 2013 17:43:16 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1VBa2M-0006Fx-O7; Tue, 20 Aug 2013 00:43:07 +0000 Date: Tue, 20 Aug 2013 09:43:05 +0900 Message-ID: From: Randy Bush To: Jim Fenton In-Reply-To: <521269AF.9010509@bluepopcorn.net> References: <520FE08B.80005@bluepopcorn.net> <5210643F.8030709@bluepopcorn.net> <5210F771.9090600@bluepopcorn.net> <521269AF.9010509@bluepopcorn.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: "" , Yoav Nir Subject: Re: [perpass] Another mail-related proposal X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 00:43:16 -0000 > I had sent a PGP-encrypted message to someone who (not Randy of > course) replied in the clear, quoting much of my original message. [ i never make mistakes. and pigs fly ] one analog which worries me is muas which decide whether to encrypt outbound depending on whether the inbound was encrypted. if i do not pay attention when responding, and i add confidential information in my response. if the inbound was not encrypted, my mua is not gonna encrypt the reply by default. randy From fenton@bluepopcorn.net Mon Aug 19 22:24:16 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FD9B11E8165 for ; Mon, 19 Aug 2013 22:24:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.359 X-Spam-Level: X-Spam-Status: No, score=-1.359 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vs5zQbUEBSPg for ; Mon, 19 Aug 2013 22:24:11 -0700 (PDT) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) by ietfa.amsl.com (Postfix) with ESMTP id 97D4411E8101 for ; Mon, 19 Aug 2013 22:24:10 -0700 (PDT) Received: from [68.164.244.154] (kernel.bluepopcorn.net [68.164.244.154]) (authenticated bits=0) by v2.bluepopcorn.net (8.14.3/8.14.3/Debian-9.4) with ESMTP id r7K5O4HV001944 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Aug 2013 22:24:07 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1376976248; bh=b/sCOjTT58pHAQrWUXI2k6dJntParmV6mr95342e/zE=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=UYS9f8T3OVwFTqQcH8kRYbBfc3cwkEkOjXVsbVVKAfNUW6PJ3prVnJIuel5arHrIz 9rNXSJTcRlEixDnWer4+ZlN734S5bYPiu+F5Zle2FnkY8SV7pEquQPCpUMcxzY6huZ wiiBj09UEc1ZzAGCuYMi7WH5qPh0pSqEhTXbOWLc= Message-ID: <5212FD71.6060200@bluepopcorn.net> Date: Mon, 19 Aug 2013 22:24:01 -0700 From: Jim Fenton User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: Randy Bush References: <520FE08B.80005@bluepopcorn.net> <5210643F.8030709@bluepopcorn.net> <5210F9D3.5010302@bluepopcorn.net> <52126423.2050209@bluepopcorn.net> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: perpass@ietf.org Subject: Re: [perpass] Another mail-related proposal X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 05:24:16 -0000 On 08/19/2013 05:38 PM, Randy Bush wrote: >>> and the nsa pwns the disk drives of the smtp relays. e2e, please, in >>> addition to transport. in 1984, all data and traffic should be >>> encrypted. >> That goes to the question I had in my original message on this thread: >> what is the threat model we are attempting to address? In the short term >> at least, I consider transport-level encryption of email to be helpful, >> because it raises the required attack complexity. > i agree transport should be encrypted. and, as someone has pointed out, > we should know when that negotiation is not successful and be able to > make some decisions. > > smtp is hop by hop. just because A encrypts to B, A has zero assurance > that B encrypts to C. hence, e2e encryption is pretty much mandatory > against a purely passive attacker. > ...which goes back to the original thing I was suggesting: that A should be able to signal to B that it should only relay the message (e.g., to C) if the channel is also encrypted and that C also will observe the restriction if it needs to relay the message further. Not as good as end-to-end encryption, but an improvement nonetheless. I believe the military folks might call this "Encrypt For Transmission Only". -Jim From randy@psg.com Mon Aug 19 22:27:39 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91EE311E8165 for ; Mon, 19 Aug 2013 22:27:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.543 X-Spam-Level: X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FRB-PF84tc5v for ; Mon, 19 Aug 2013 22:27:39 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id 63E3D11E80FD for ; Mon, 19 Aug 2013 22:27:38 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1VBeTh-0006iY-Jj; Tue, 20 Aug 2013 05:27:37 +0000 Date: Tue, 20 Aug 2013 14:27:36 +0900 Message-ID: From: Randy Bush To: Jim Fenton In-Reply-To: <5212FD71.6060200@bluepopcorn.net> References: <520FE08B.80005@bluepopcorn.net> <5210643F.8030709@bluepopcorn.net> <5210F9D3.5010302@bluepopcorn.net> <52126423.2050209@bluepopcorn.net> <5212FD71.6060200@bluepopcorn.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Cc: perpass@ietf.org Subject: Re: [perpass] Another mail-related proposal X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 05:27:39 -0000 >> smtp is hop by hop. just because A encrypts to B, A has zero assurance >> that B encrypts to C. hence, e2e encryption is pretty much mandatory >> against a purely passive attacker. > ...which goes back to the original thing I was suggesting: that A should > be able to signal to B that it should only relay the message (e.g., to > C) if the channel is also encrypted and that C also will observe the > restriction if it needs to relay the message further. and A trusts B and B's software and configuration why? transport encryption by default good. e2e encryption by default gooder. both great. randy From fenton@bluepopcorn.net Mon Aug 19 23:26:25 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A870911E81C8 for ; Mon, 19 Aug 2013 23:26:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tn16XihaQ9X9 for ; Mon, 19 Aug 2013 23:26:25 -0700 (PDT) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2438311E8101 for ; Mon, 19 Aug 2013 23:26:25 -0700 (PDT) Received: from [10.10.20.3] (c-50-136-244-117.hsd1.ca.comcast.net [50.136.244.117]) (authenticated bits=0) by v2.bluepopcorn.net (8.14.3/8.14.3/Debian-9.4) with ESMTP id r7K6QJCi002093 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Aug 2013 23:26:21 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1376979982; bh=KarKnOrhkVVbqTKZbclV+72gHN93A8Dr9xSa6mzLDQM=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=ewmGWUaxDZOH/z65hl2keR/RdGvO3ZDAvYM1aZt+7M7qikSvQY5AtNOael9SeDzkZ 6iw+i+8IiiGMgZjB4zNKI627W/kypTOL+ahYsQPRWy5J5GGVK5NvQb5ieOuEMLzN+b 1HU9BnvQE1jPgD69NjarNzcQ22fjxARCL7venXBA= Message-ID: <52130C0D.6000508@bluepopcorn.net> Date: Mon, 19 Aug 2013 23:26:21 -0700 From: Jim Fenton User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: Randy Bush References: <520FE08B.80005@bluepopcorn.net> <5210643F.8030709@bluepopcorn.net> <5210F9D3.5010302@bluepopcorn.net> <52126423.2050209@bluepopcorn.net> <5212FD71.6060200@bluepopcorn.net> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: perpass@ietf.org Subject: Re: [perpass] Another mail-related proposal X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 06:26:25 -0000 On 08/19/2013 10:27 PM, Randy Bush wrote: >>> smtp is hop by hop. just because A encrypts to B, A has zero assurance >>> that B encrypts to C. hence, e2e encryption is pretty much mandatory >>> against a purely passive attacker. >> ...which goes back to the original thing I was suggesting: that A should >> be able to signal to B that it should only relay the message (e.g., to >> C) if the channel is also encrypted and that C also will observe the >> restriction if it needs to relay the message further. > and A trusts B and B's software and configuration why? transport > encryption by default good. e2e encryption by default gooder. both > great. > A trusts B and B's software and configuration for the same reasons it's willing to send a message to B at all. Usually either because B acts on behalf of A as an outgoing MTA, or because the recipient has designated B to receive mail (directly or indirectly) for them. It's not a huge stretch from there for A to trust B to get the transport encryption right too. I agree on the good/gooder/great scale. But sometimes the best we can do is "good". -Jim From stephen.farrell@cs.tcd.ie Wed Aug 21 09:04:59 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E4F711E8223 for ; Wed, 21 Aug 2013 09:04:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HY8VxfopFbUd for ; Wed, 21 Aug 2013 09:04:54 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id AFA4D11E80E3 for ; Wed, 21 Aug 2013 09:04:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 4DA74BE76 for ; Wed, 21 Aug 2013 17:04:53 +0100 (IST) 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 08JVzXToL61z for ; Wed, 21 Aug 2013 17:04:53 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 3710EBE74 for ; Wed, 21 Aug 2013 17:04:53 +0100 (IST) Message-ID: <5214E525.7020702@cs.tcd.ie> Date: Wed, 21 Aug 2013 17:04:53 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: perpass@ietf.org X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [perpass] relevant LISP discussion X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2013 16:04:59 -0000 Hi, FYI, there's a thread on the LISP wg list [1] that also seems relevant here. S. [1] http://www.ietf.org/mail-archive/web/lisp/current/msg04659.html From kent@bbn.com Wed Aug 21 10:01:37 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CED5811E8248 for ; Wed, 21 Aug 2013 10:01:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.556 X-Spam-Level: X-Spam-Status: No, score=-106.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hJIBEG7Ur-St for ; Wed, 21 Aug 2013 10:01:31 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id B0E8911E822E for ; Wed, 21 Aug 2013 10:01:17 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:51273) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1VCBmX-000666-7F for perpass@ietf.org; Wed, 21 Aug 2013 13:01:17 -0400 Message-ID: <5214F25D.6070707@bbn.com> Date: Wed, 21 Aug 2013 13:01:17 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: perpass@ietf.org References: <5214E525.7020702@cs.tcd.ie> In-Reply-To: <5214E525.7020702@cs.tcd.ie> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [perpass] relevant LISP discussion X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2013 17:01:37 -0000 I might be more impressed if the sender of the message understood that one does not use EC(DH) to encrypt/decrypt anything! > Hi, > > FYI, there's a thread on the LISP wg list [1] that also seems > relevant here. > > S. > > [1] http://www.ietf.org/mail-archive/web/lisp/current/msg04659.html > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > From stephen.farrell@cs.tcd.ie Wed Aug 21 10:26:05 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A53DF11E80FA for ; Wed, 21 Aug 2013 10:26:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.203 X-Spam-Level: X-Spam-Status: No, score=-101.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QCCCD2Ve1aG1 for ; Wed, 21 Aug 2013 10:26:00 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 00E3011E8262 for ; Wed, 21 Aug 2013 10:25:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 9B16DBE77; Wed, 21 Aug 2013 18:25:52 +0100 (IST) 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 zXkboFOpTbHV; Wed, 21 Aug 2013 18:25:48 +0100 (IST) Received: from [10.87.48.7] (unknown [86.42.16.220]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id CFEEFBE61; Wed, 21 Aug 2013 18:25:48 +0100 (IST) References: <5214E525.7020702@cs.tcd.ie> <5214F25D.6070707@bbn.com> Mime-Version: 1.0 (1.0) In-Reply-To: <5214F25D.6070707@bbn.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <367DA241-3B40-4731-9FA0-1CE7C5BBC901@cs.tcd.ie> X-Mailer: iPhone Mail (10B329) From: Stephen Farrell Date: Wed, 21 Aug 2013 18:25:47 +0100 To: Stephen Kent Cc: "perpass@ietf.org" Subject: Re: [perpass] relevant LISP discussion X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2013 17:26:05 -0000 On 21 Aug 2013, at 18:01, Stephen Kent wrote: > I might be more impressed if the sender of the message understood that one= does not use > EC(DH) to encrypt/decrypt anything! Well, help with fixing stuff like that's the kind of help we can get for peo= ple. More interesting (for me) would be if lisp could be a useful basis for h= iding some higher layer information. I'm not sure if it works or not but sou= nds worth a look. (And btns might also be worth another look too of course) S >> Hi, >>=20 >> FYI, there's a thread on the LISP wg list [1] that also seems >> relevant here. >>=20 >> S. >>=20 >> [1] http://www.ietf.org/mail-archive/web/lisp/current/msg04659.html >> _______________________________________________ >> 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 nick@lupine.me.uk Wed Aug 21 11:02:45 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D12DC11E83D0 for ; Wed, 21 Aug 2013 11:02:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id geU5-e-gxV13 for ; Wed, 21 Aug 2013 11:02:32 -0700 (PDT) Received: from oak.forest.a5775.uk0.bigv.io (lupine.me.uk [IPv6:2001:41c8:51:8:feff:ff:fe01:101]) by ietfa.amsl.com (Postfix) with ESMTP id 02CD711E83A6 for ; Wed, 21 Aug 2013 11:02:31 -0700 (PDT) Received: from [213.138.102.178] by oak.forest.a5775.uk0.bigv.io with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1VCCjl-0002nD-Hr; Wed, 21 Aug 2013 19:02:29 +0100 Message-ID: <521500B4.7040107@lupine.me.uk> Date: Wed, 21 Aug 2013 19:02:28 +0100 From: Nick Thomas User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130704 Icedove/17.0.7 MIME-Version: 1.0 To: perpass@ietf.org References: <5214E525.7020702@cs.tcd.ie> <5214F25D.6070707@bbn.com> In-Reply-To: <5214F25D.6070707@bbn.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [perpass] relevant LISP discussion X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2013 18:02:45 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi Stephen, On 21/08/13 18:01, Stephen Kent wrote: > I might be more impressed if the sender of the message understood that > one does not use > EC(DH) to encrypt/decrypt anything! Thanks for the input. I am cryptographically naive, yes. The intention here isn't to impress anyone; but to hammer out something that might actually work in the real world. So the contention is that sha256( ecdh( public, private ) ) is not an appropriate to use as the secret key for a symmetric block cipher like aes256... in general? Only for long-lived keys? What happens if peers change those keys daily, or every T/G/MB? Or should I just forget about that, and use the ecdh shared secret to encrypt a separate private key... for each packet? On a certain timescale? When I first came up with the idea, a L/ISP control plane wasn't part of it, so I tried to avoid anything with even a whiff of session establishment. /Nick -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iF4EAREIAAYFAlIVALIACgkQREz3uGI6tdy+7gD8DAuR+Ww9fQyShzdTsAB/dNl/ eoeeADWbS/paKuwBPbIA/RbC5h5XAaPFci+kME+GU/9oHAaRVYgPdrbhYm+buvhj =TRHk -----END PGP SIGNATURE----- From nick@lupine.me.uk Wed Aug 21 11:31:19 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9263F1F0EE6 for ; Wed, 21 Aug 2013 11:31:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RalmDB0-H05J for ; Wed, 21 Aug 2013 11:31:18 -0700 (PDT) Received: from oak.forest.a5775.uk0.bigv.io (lupine.me.uk [IPv6:2001:41c8:51:8:feff:ff:fe01:101]) by ietfa.amsl.com (Postfix) with ESMTP id 8A2461F0EDA for ; Wed, 21 Aug 2013 11:31:18 -0700 (PDT) Received: from [213.138.102.178] by oak.forest.a5775.uk0.bigv.io with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1VCDBb-0002po-D5; Wed, 21 Aug 2013 19:31:15 +0100 Message-ID: <52150774.9050009@lupine.me.uk> Date: Wed, 21 Aug 2013 19:31:16 +0100 From: Nick Thomas User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130704 Icedove/17.0.7 MIME-Version: 1.0 To: perpass@ietf.org References: <5214E525.7020702@cs.tcd.ie> <5214F25D.6070707@bbn.com> <521500B4.7040107@lupine.me.uk> In-Reply-To: <521500B4.7040107@lupine.me.uk> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [perpass] relevant LISP discussion X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2013 18:31:19 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 21/08/13 19:02, Nick Thomas wrote: > Or should I just forget about that, and use the ecdh shared secret > to encrypt a separate private key... for each packet? On a certain > timescale? to encrypt a separate shared secret*, I should say. /Nick -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iF4EAREIAAYFAlIVB3QACgkQREz3uGI6tdyOfAD/cHlgMC8car53exjsbpXs8HCJ 0Ew/peur8DLVINMY1oEA+wUcaM/dc6dGBd9DPC/RcZZlvo9QmPyOFqWUc3eoRr8t =v5dA -----END PGP SIGNATURE----- From kent@bbn.com Wed Aug 21 12:23:05 2013 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6401121F9EEC for ; Wed, 21 Aug 2013 12:23:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.559 X-Spam-Level: X-Spam-Status: No, score=-106.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id llqak8s1qAkB for ; Wed, 21 Aug 2013 12:22:50 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 8ACC521F9BB5 for ; Wed, 21 Aug 2013 12:22:50 -0700 (PDT) Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:51744) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1VCDzV-0007Pc-0m; Wed, 21 Aug 2013 15:22:49 -0400 Message-ID: <52151388.80006@bbn.com> Date: Wed, 21 Aug 2013 15:22:48 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: nick@lupine.me.uk References: <5214E525.7020702@cs.tcd.ie> <5214F25D.6070707@bbn.com> <521500B4.7040107@lupine.me.uk> In-Reply-To: <521500B4.7040107@lupine.me.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: perpass@ietf.org Subject: Re: [perpass] relevant LISP discussion X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2013 19:23:05 -0000 Nick, > On 21/08/13 18:01, Stephen Kent wrote: >> I might be more impressed if the sender of the message understood that >> one does not use >> EC(DH) to encrypt/decrypt anything! > Thanks for the input. I am cryptographically naive, yes. The intention > here isn't to impress anyone; but to hammer out something that might > actually work in the real world. > > So the contention is that sha256( ecdh( public, private ) ) is not an > appropriate to use as the secret key for a symmetric block cipher like > aes256... in general? Only for long-lived keys? What happens if peers > change those keys daily, or every T/G/MB? My comment is that DH (EC or otheriwse) is a key agreement alg, and thus does not encrypt/decrypt anything. It generates a shared, secret bit string that can be processed to yield a key for a symmetric encryption or integrity alg. A function used to generate such keys is called a KDF (key derivation function). A symmetric alg with with such a key is used might or might not be a block cipher. If one wants to generate a different (symmetric) encryption key frequently, changing a DH key bound to an entity via a repository is not a viable approach. Instead, one uses a random value as an additional input to the KDF (a value sometimes referred to as a UKM, e.g., in the CMS spec). Steve