From nobody Mon Sep 15 07:56:49 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E34A61A0380 for ; Mon, 15 Sep 2014 07:56:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VBT0Rk5NUBOA for ; Mon, 15 Sep 2014 07:56:45 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id F12771A037A for ; Mon, 15 Sep 2014 07:56:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id B7906BE35 for ; Mon, 15 Sep 2014 15:56: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 fCtgdplI4L3F for ; Mon, 15 Sep 2014 15:56:39 +0100 (IST) Received: from [172.18.1.46] (62-50-201-3.client.stsn.net [62.50.201.3]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 00017BE17 for ; Mon, 15 Sep 2014 15:56:38 +0100 (IST) Message-ID: <5416FE26.7090705@cs.tcd.ie> Date: Mon, 15 Sep 2014 15:56:38 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: perpass Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/perpass/UYFVAKeuBuivSMSB5vw0EpBMiZA Subject: [perpass] IAB security/privacy programme PM draft X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 14:56:48 -0000 Hi all, Richard and a few folks started work on documenting a problem statement [1] some time ago. As I think was stated here before it seems like a good plan for that to be progressed as part of the IAB's re-factored security/privacy programme. So Brian Trammell has picked up the pen and pushed out [2]. Comments very welcome (I've still to read it myself so will send my comments here too when I've had a chance), Cheers, S. [1] http://tools.ietf.org/html/draft-barnes-pervasive-problem [2] https://tools.ietf.org/html/draft-iab-privsec-confidentiality-threat From nobody Mon Sep 22 15:28:58 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50D271A1B43 for ; Mon, 22 Sep 2014 15:28:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q3sRH-HWHAIR for ; Mon, 22 Sep 2014 15:28:53 -0700 (PDT) Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1E141A1B50 for ; Mon, 22 Sep 2014 15:28:53 -0700 (PDT) Received: from berryeater.riseup.net (berryeater-pn.riseup.net [10.0.1.120]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.riseup.net", Issuer "Gandi Standard SSL CA" (not verified)) by mx1.riseup.net (Postfix) with ESMTPS id 59CB254494 for ; Mon, 22 Sep 2014 15:28:52 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: elijah) with ESMTPSA id 307F842750 Message-ID: <5420A2A9.4030504@leap.se> Date: Mon, 22 Sep 2014 15:28:57 -0700 From: Elijah Sparrow User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: perpass@ietf.org References: <20140828160043.76ae962f@latte.josefsson.org> In-Reply-To: <20140828160043.76ae962f@latte.josefsson.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.98.4 at mx1 X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/perpass/F2x8ZML1BZNQy4MNrIACSCLOkcQ Subject: Re: [perpass] OpenPGP mail/news header X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 22:28:55 -0000 On 08/28/2014 07:00 AM, Simon Josefsson wrote: > I have updated a six (!) year old document describing the OpenPGP > mail/news header field. As it encourages and promotes use of > encrypted/signed email, I thought it would be relevant to this list. > All feedback is appreciated, either directly to me or here. > > http://tools.ietf.org/html/draft-josefsson-openpgp-mailnews-header-07 I am excited to see that you have resumed work on this. There are a ton of projects working on new forms of 'easy' secure email, and they are all experimenting with, or planning to experiment with, new forms of key discovery and validation [1]. The nearly universal goal is automatic key management without the need for user intervention. I think that the OpenPGP header, or something like it, could plan an important role in bridging what we have now to some of the ambitious schemes proposed for the future (e.g. ppe, nyms.io, CT for email, dime, etc). There are some things that some projects have said they plan to do that are problematic, for example attach the sender's public key in every outgoing email or use the fingerprint from the signature of signed messages to discover keys (since these are easily spoofed by a MiTM). Everyone wants to get away from the WoT and from CAs. I think this is good, and that an OpenPGP header could help facilitate this, if it was written with a slightly different intent. Currently, the goal with OpenPGP header is simple untrusted advertisement. As the draft makes clear: > Because the mail header is typically not integrity protected, the > information conveyed in the OpenPGP header field MUST NOT be trusted > without additional verification With some slight modifications, I think the OpenPGP header could support the kind of thing that many of the new generation of email security projects are looking for, namely a secure in-band user-to-user mechanism for key discovery and a way to validate this key with the service provider when supported. Although it is *usually* the case that headers are not integrity protected, they certainly can be with DKIM, which is growing in popularity (as gmail is going to effectively be forcing it on everyone). Even without a DKIM signature, a client could validate the advertised key with the provider if the header provided some clues as to how this could be done. Unfortunately, I don't think these 'how to validate clues' can take the form of an arbitrary URL. As you note, arbitrary URLs are problematic in that they can effectively be used as 'email bugs', tracking who received the message and when it was received. Also, an arbitrary URL can be completely bogus. For example, something like: provider-endorsement: webfinger, dane is better than provider-endorsement: https://example.org/.well-known/webfinger?resource=acct%3Acarol%40example.org Even if the headers are completely unsigned, a client can be smart enough to say, "aha, I understand webfinger, so I will contact the domain in the 'from' email address and query webfinger via https". Provider endorsement of keys is not ideal, but I think it is an important stepping stone toward what we eventually want, and also it is much better than plain TOFU with zero attempt to validate. Once clients are accustomed to provider endorsement, these same clients can be written to audit their providers to ensure they are not advertising bogus keys on their behalf. In what form this auditing will take is the topic of much discussion (everything from network perspective, n-of-m consensus, or a Certificate Transparency style append only log), but it would be good to create an OpenPGP header that can lead us in that direction. Many people will rightly object that provider endorsement is limited because it requires participation from the provider. On the other hand, there is a rapidly growing list of provider who plan to offer OpenPGP encrypted email (including, of course, gmail and yahoo). Many of these models are not great, and the private key is not kept secret from the provider, but provider endorsement could still be useful in these cases in the interest of interoperability. Perhaps what I am describing warrants a separate header. I think it is close enough that it would make sense to combine with OpenPGP header. In the case of LEAP, we have implemented support for the OpenPGP header in the automatic key manager of our client, both sending and receiving, but we are not going to support arbitrary URLs or key ids. It is 2014, after all, and there is no reason to not use the full fingerprint, especially since this is intended to be read by machines. -elijah [1] https://github.com/OpenTechFund/secure-email (pull requests welcome)