From nobody Mon Aug 25 11:52:27 2014 Return-Path: X-Original-To: endymail@ietfa.amsl.com Delivered-To: endymail@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92E941A01BA for ; Mon, 25 Aug 2014 11:50:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] 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 qIRIHgkctUXj for ; Mon, 25 Aug 2014 11:50:48 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 0B5031A0295 for ; Mon, 25 Aug 2014 11:50:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 02F90BDD8 for ; Mon, 25 Aug 2014 19:50:44 +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 KVuh-5rMQgDV for ; Mon, 25 Aug 2014 19:50:42 +0100 (IST) Received: from [10.87.48.7] (unknown [86.41.56.186]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 79EE7BDD6 for ; Mon, 25 Aug 2014 19:50:42 +0100 (IST) Message-ID: <53FB8582.7010505@cs.tcd.ie> Date: Mon, 25 Aug 2014 19:50:42 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: endymail@ietf.org References: <53FB7EEB.5000906@cs.tcd.ie> In-Reply-To: <53FB7EEB.5000906@cs.tcd.ie> X-Forwarded-Message-Id: <53FB7EEB.5000906@cs.tcd.ie> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/hsdgpxgGN86VPTPx1fEB23h8JAc X-Mailman-Approved-At: Mon, 25 Aug 2014 11:52:22 -0700 Subject: [Endymail] Fwd: Fwd: [saag] new list for discussion of end-to-end email security/privacy improvements X-BeenThere: endymail@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 18:50:49 -0000 Just so's the archive is not empty... -------- Forwarded Message -------- Subject: Fwd: [saag] new list for discussion of end-to-end email security/privacy improvements Date: Mon, 25 Aug 2014 19:22:35 +0100 From: Stephen Farrell To: IESG FYI -------- Forwarded Message -------- Subject: [saag] new list for discussion of end-to-end email security/privacy improvements Date: Mon, 25 Aug 2014 19:20:41 +0100 From: Stephen Farrell To: saag@ietf.org Hi all, Following on from discussion in Toronto in appaswg and saag, and a subsequent request, we've created a mailing list for discussing this topic. Pete Resnick and I will initially manage the list. If you're interested, please subscribe. Once Pete and I figure there's a good enough set of folks subscribed we'll fire off a starter email. That usually takes a few days, so probably Wed-Thu this week. The list [1] description is: There is significant interest in improving the privacy-related properties of Internet mail. One focus of current efforts is on the per-hop (connection-based) protections provided by TLS. However a wide range of other work has a focus on end-to-end protection, at the Internet scale of billions of end users and perhaps millions of operators. Such work typically involves new forms of mail header or body protection, new public key management (compared to S/MIME or PGP), and security mechanisms more appropriate for mobile/web user-agents. Other security-relevant approaches may be discussed if needed. Various proposals and development efforts on this topic are underway outside the IETF. This mailing list provides an IETF venue for discussion of elements that might be commonly needed by such efforts and to identify work that the IETF could do to aid in achieving better end-to-end security deployed for Internet email. Cheers, S. [1] https://www.ietf.org/mailman/listinfo/endymail _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From nobody Mon Aug 25 13:59:23 2014 Return-Path: X-Original-To: endymail@ietfa.amsl.com Delivered-To: endymail@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 567891A0332; Mon, 25 Aug 2014 13:55:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JlUCNhEUv9W3; Mon, 25 Aug 2014 13:55:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F3D1B1A0346; Mon, 25 Aug 2014 13:54:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: IETF Announcement List X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140825205459.15407.3312.idtracker@ietfa.amsl.com> Date: Mon, 25 Aug 2014 13:54:59 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/uzN55k6KMeyD_U8c1sJaof3TXYI X-Mailman-Approved-At: Mon, 25 Aug 2014 13:59:22 -0700 Cc: presnick@qti.qualcomm.com, endymail@ietf.org, stephen.farrell@cs.tcd.ie Subject: [Endymail] New Non-WG Mailing List: Endymail X-BeenThere: endymail@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 20:55:02 -0000 A new IETF non-working group email list has been created. List address: endymail@ietf.org Archive: http://www.ietf.org/mail-archive/web/endymail/ To subscribe: https://www.ietf.org/mailman/listinfo/endymail Purpose: There is significant interest in improving the privacy-related properties of Internet mail. One focus of current efforts is on the per-hop (connection-based) protections provided by TLS. However a wide range of other work has a focus on end-to-end protection, at the Internet scale of billions of end users and perhaps millions of operators. Such work typically involves new forms of mail header or body protection, new public key management (compared to S/MIME or PGP), and security mechanisms more appropriate for mobile/web user-agents. Other security-relevant approaches may be discussed if needed. Various proposals and development efforts on this topic are underway outside the IETF. This mailing list provides an IETF venue for discussion of elements that might be commonly needed by such efforts and to identify work that the IETF could do to aid in achieving better end-to-end security deployed for Internet email. For additional information, please contact the list administrators. From nobody Tue Aug 26 15:34:42 2014 Return-Path: X-Original-To: endymail@ietfa.amsl.com Delivered-To: endymail@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 733521A004C for ; Tue, 26 Aug 2014 15:34:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.669 X-Spam-Level: X-Spam-Status: No, score=-7.669 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ma9PRKqtXEEP for ; Tue, 26 Aug 2014 15:34:39 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA5AB1A008F for ; Tue, 26 Aug 2014 15:34:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1409092479; x=1440628479; h=message-id:date:from:mime-version:to:subject:sender: content-transfer-encoding; bh=YVg1YTwuc9gBbi0p7LXnO+lrGbC1dKIEcPBvo7gnRGc=; b=zjvYlnzrJlwlYoZpVEJ3Ydxccr6yDybuC8tdCK2L+WCEqxLfeTyTNGUa Dcd46R4HCLsuUvTRHqqUadbZqhzD4Ahg6D9WOJkzktsuiny6AS7Uv+0HG laZLGD2dGoBZFtEBHM3YYIjEy2gVgOs+Zfv35I6YLtld8oY4lSjcUoWxO 8=; X-IronPort-AV: E=McAfee;i="5600,1067,7542"; a="60681931" Received: from ironmsg01-lv.qualcomm.com ([10.47.202.180]) by wolverine01.qualcomm.com with ESMTP; 26 Aug 2014 15:34:39 -0700 X-IronPort-AV: E=Sophos;i="5.04,406,1406617200"; d="scan'208";a="31158270" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by ironmsg01-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 26 Aug 2014 15:34:38 -0700 Received: from presnick-mac.local (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 26 Aug 2014 15:34:38 -0700 Message-ID: <53FD0B7D.8070705@qti.qualcomm.com> Date: Tue, 26 Aug 2014 15:34:37 -0700 From: Pete Resnick , Stephen Farrell User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Sender: Pete Resnick Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.48.1] Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/tv3V3-gB3X9Te2e9n0_cj78_Bvg Subject: [Endymail] Off we go... X-BeenThere: endymail@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 22:34:41 -0000 Hi all, We've got 88 people subscribed now, which is pretty quick for a list like this. Seems like there really is interest in the topic, which is good. What we'd suggest is to start off with some sharing about what folks are/have-been doing in this space. We know there are a range of projects and proposals and it'd be good to get some information/pointers on those we all know about. Its probably worth stating now that this list is *not* intended to pick a winner amongst those, nor to anoint one as the "official" IETF thing, so luckily we don't need to have a bunfight about which is the shiniest proposal of them all. :-) Rather a goal of this list is to identify bits of work that the IETF could do to help such projects/proposals so they could achieve significant deployment. So if there are common bits to some projects/proposals that'd be interesting and especially if there'd be value in having those bits standardized. Or if there are other ways in which we could help things along that's fair game for discussion too. And I suppose its inevitable that we'll discuss requirements and the real-world constraints on solutions too. And even get new and possibly radical proposals for how to do better in this space. And those are also OK and interesting for this list. Success here will be when/if we identify some bit(s) of work that the IETF could credibly do that'd improve the real-world end-to-end security and privacy of email. And note that "credible" there requires stuff to be both technically sane and to have a sufficient set of capable folks interested and willing to do work. When/if we do identify such, we'd probably want to start a new WG/list to actually do the work identified at which point this list could languish or continue on with more discussion of the next good thing(s) to do. So off we go... What projects are folks working on, and what should the IETF be doing in this space? Cheers, Pete & Stephen From nobody Tue Aug 26 19:20:50 2014 Return-Path: X-Original-To: endymail@ietfa.amsl.com Delivered-To: endymail@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26DCE1A0371 for ; Tue, 26 Aug 2014 19:20:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wI_gQ0iVFKHB for ; Tue, 26 Aug 2014 19:20:45 -0700 (PDT) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCB5D1A036A for ; Tue, 26 Aug 2014 19:20:45 -0700 (PDT) Received: by mail-ie0-f171.google.com with SMTP id at1so12688873iec.30 for ; Tue, 26 Aug 2014 19:20:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=VUxOGoTeTEheRMhXgF0Y0ldcnPj5bbpIaWPauR8VwtY=; b=uuDgxk4XAxgFnMrtLUd4ZxiRU7n7wookxdpgQOIrSBs/IRwAEaY6vGVSfQbmq6eFHA NALw9vluzklG2gKko2TzbLZQYnLD0njYTkUn3lsnQFNtbpRS4ILtkSjj+rbrWQ66Z0eF PMOoj+2kiAHciNaDolCxoNzvzNVtvpFOiJa0g= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=VUxOGoTeTEheRMhXgF0Y0ldcnPj5bbpIaWPauR8VwtY=; b=Wv4Pgt9tcFKILLfzP68j7IJ0kPtlXZf/3WqtyBKWQcmtykmcUZCvx7W8W39HTEBL3T 2WwIR3Lqqo4/CMmXVRNcjv838DLIi7a7KOG1Cp5D1LcaSlSlfQYQhPHP/5zXC2qBLrU9 HKrSdhXPjOQmsjsxgSeLLVkuRl+c4uyejoDtxMmVvA5MsmbrhYm4xUr8JqEb5CaPa2U4 +Z1xAARc01Lo1cHFQKoSQie8I27esZVJqdrlz05wudnBcUVglRWbJpRablYTJlPDsvap HozTVoNNoefEdjxvVnC3ucibQZEqqfVaED5JTrIDYEnwnYouU1QDMvj6SYlE9AN3XxrO fgAg== X-Gm-Message-State: ALoCoQm7ezvHfGcVwTK1qVuU5v02tCIkRxMZVLVOPzcym/rfUeKZLdv9UuW1zaQXVsEdlsMUGGj1 X-Received: by 10.43.167.196 with SMTP id nf4mr31447155icc.22.1409106045090; Tue, 26 Aug 2014 19:20:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.10.104 with HTTP; Tue, 26 Aug 2014 19:20:25 -0700 (PDT) In-Reply-To: <53FD0B7D.8070705@qti.qualcomm.com> References: <53FD0B7D.8070705@qti.qualcomm.com> From: Tom Ritter Date: Tue, 26 Aug 2014 21:20:25 -0500 Message-ID: To: endymail@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/gtMD-Dj4r4QTkbr0VNWzjo1ApyY Subject: Re: [Endymail] Off we go... X-BeenThere: endymail@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 02:20:47 -0000 On 26 August 2014 17:34, Pete Resnick wrote: > So off we go... What projects are folks working on Prior to Snowden's revelations, a friend and I had given some thought[0] to a system that supported provider-to-provider encryption, where the end could be extended on either side to end-to-provider or end-to-end encryption. Along the way we thought about distributing keys over HTTPS vs DNS[1], authenticity[2], a report-only deployment mode[3], and other stuff. We shelved our proposal, but published our thoughts in a document that we hoped would add some thoughts and context to future discussions. Full spec is at https://github.com/tomrittervg/uee I can't claim to be working on this, but I'm excited about https://datatracker.ietf.org/doc/draft-ietf-dane-smtp-with-dane/ I'm also tangentially involved (through my job) with NCC Group's .trust initiative[4]. There are a lot of policy controls, but also technical ones. Some of the guarantees you will have when communicating with a domain in the .trust gTLD will be that the domain will have valid TLS certificates for StartTLS, will have StartTLS available, will use DNSSEC, DKIM, and a host of other technical requirements. -tom [0] https://ritter.vg/blog-uee_email_encryption.html [1] https://github.com/tomrittervg/uee/blob/master/appendix-key-distro-choice.md [2] https://github.com/tomrittervg/uee/blob/master/proposal.md#key-authenticity [3] https://github.com/tomrittervg/uee/blob/master/proposal.md#report-only-mode [4] https://www.nccgroup.com/media/112014/trust-faq.pdf From nobody Tue Aug 26 19:23:10 2014 Return-Path: X-Original-To: endymail@ietfa.amsl.com Delivered-To: endymail@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49C901A036A for ; Tue, 26 Aug 2014 19:23:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.422 X-Spam-Level: * X-Spam-Status: No, score=1.422 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f36C1FwBbQej for ; Tue, 26 Aug 2014 19:23:05 -0700 (PDT) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 585551A0059 for ; Tue, 26 Aug 2014 19:23:04 -0700 (PDT) Received: by mail-la0-f48.google.com with SMTP id gl10so15752021lab.21 for ; Tue, 26 Aug 2014 19:23:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=RTpWtcIJOD4vjA1aH5EJaNJJFP1eAP4fT3smIXS9xJE=; b=Q7wGmcFdTM/t8eHbsXRehyoOsyyYSCeog6NNQYz8WoDkxft+n/C78bEzo4Ar158AH1 BYkNESFsbUZ1b9Byx0INfhImbSvfVyd9AhnuPfBiFEle9nI+fuMGJotnf9PxcemI6xpM fA9x8LpPgGwiFT1SI5t+YskHF5iBpLXOydOpgPmt15zAh8IwdvPvrN1aQJSbmvKP+Qac ACS/v117QpfZ7rDkPPsUN7/Y0DGluNsD8ZGJ2tcN7vGIZmPopcMMKA4fYbvDIDcZbVbS o7QuwXZT/Va4ZY7sDD7Gm+ZcJ2SOGUayPBKwcNThQhwyWpPOHIO6FiRfY9SbxASTtYhc 8dvA== MIME-Version: 1.0 X-Received: by 10.112.157.132 with SMTP id wm4mr191243lbb.89.1409106182597; Tue, 26 Aug 2014 19:23:02 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.122.50 with HTTP; Tue, 26 Aug 2014 19:23:02 -0700 (PDT) In-Reply-To: <53FD0B7D.8070705@qti.qualcomm.com> References: <53FD0B7D.8070705@qti.qualcomm.com> Date: Tue, 26 Aug 2014 22:23:02 -0400 X-Google-Sender-Auth: v0Bg0pmSy35jgGfB0Z1mxdyCBes Message-ID: From: Phillip Hallam-Baker To: Pete Resnick , Stephen Farrell Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/JSH7WYV-2uNYnE5UvEAYW8h6QWE Cc: endymail@ietf.org Subject: Re: [Endymail] Off we go... X-BeenThere: endymail@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 02:23:08 -0000 On Tue, Aug 26, 2014 at 6:34 PM, Pete Resnick wrote: > Hi all, > > We've got 88 people subscribed now, which is pretty quick for a list like > this. Seems like there really is interest in the topic, which is good. > > What we'd suggest is to start off with some sharing about what folks > are/have-been doing in this space. We know there are a range of projects and > proposals and it'd be good to get some information/pointers on those we all > know about. My work is described on the PrismProof.org web site. I have been looking at the reasons people don't use end to end encrypted mail. I see the following problems: 1) Every system currently available has chronic usability problems. They are too difficult to configure and too much hassle to use. This is true of both S/MIME and PGP. 2) The standards battle between PGP and S/MIME has run into a stalemate with no victor. 3) The CA trust model does not really deliver value for end entity certificates unless the certificates are being issued by an LRA that knows the key holder. The Web of Trust model does not scale due to the Moore bound. To illustrate just how unnecessarily hard it is to send S/MIME mail today, this is what it takes to install a certificate in Thunderbird on Windows. 1) Discover that the feature exists 2) Select a CA to issue the certificate, Comodo offers free certs but you will only find them if you are looking for them. 3) Fill in a Web form to apply for the certificate 4) Respond to the email challenge 5) Install the certificate into the Windows keystore using the Web browser but this will only work if you use the same Web browser as you used to apply for the certificate 6) Export the certificate from the Windows store 7) Import the certificate into the Thunderbird cert store which is not the same as the firefox one 8) Configure Thunderbird to use the certificate 9) Repeat this whole process every 12 months And before you start off telling me about PGP, getting that to work proved so tedious I gave up. The problem was that the client I tried to use was from the 'mushroom' school of usability and does not tell the user anything they need to know to use PGP. Not even their fingerprint and not the key server they use either. And it insisted on encrypting the key under a strong passphrase which is idiotic, it should use the machine trust store. I also have an existence proof for a solution to the usability problem. The PPE key manager generates a personal PKI hierarchy and configures Windows Live Mail to use it without any user intervention at all. There are some things that I would like the user to be able to select such as the choice of a service provider to gateway their key to other forms of PKI. Strong email addresses are conceptually just a PGP fingerprint bolted onto the front of a regular email address. So we now have one identifier that specifies the address to sent the message and the means to validate the security policy under which it is sent. This effectively enables the use of the de-facto PGP trust model of key fingerprints in the S/MIME world. The reason I am basing my work on S/MIME is that that is the standard supported by all the mail clients. So building on that gives access to a vast base of installed software. All we need to do is to write easy to use tools to configure them. Or alternatively shame the providers into fixing the absolutely dreadful usability of their current product. Lets get one thing straight, you don't need to have a usability lab to spot these usability problems. > Its probably worth stating now that this list is *not* intended to pick a > winner amongst those, nor to anoint one as the "official" IETF thing, so > luckily we don't need to have a bunfight about which is the shiniest > proposal of them all. :-) I disagree. I think the problem divides into two parts, how you decide which key to use and how to apply that key to a message. The first part is the area where I don't want to come to one agreement because there isn't one single trust model that works for every application. It is a research area where we can do some really interesting things. This is the place where I think Certificate Transparency like concepts really do pay off. But innovating in the key selection space should not require people to develop their own message format or embed it in MIME. We already have that problem solved and deployed: S/MIME works great as a message format and it has decades of testing in the deployed email infrastructure and every email vendor makes sure that they don't break it. The biggest cost to me as a researcher in the key selection space is having to 'enable' all those email clients. Which is why I want to separate out the code into two parts 1) A Common core that goes in the client that has web services sockets to talk to key services in the cloud 2) Key services in the cloud that do 'the interesting stuff'. This is not going to be end to end security as people think of it on day one. But this separation allows us to tweek the trust models and update them without having to roll out new generations of email clients. We only embed the trust model into the client endpoints after it is proven to work. > Success here will be when/if we identify some bit(s) of work that the IETF > could credibly do that'd improve the real-world end-to-end security and > privacy of email. And note that "credible" there requires stuff to be both > technically sane and to have a sufficient set of capable folks interested > and willing to do work. Defining a common platform on which we can build new trust models would be one of those bits of work: From nobody Wed Aug 27 08:26:06 2014 Return-Path: X-Original-To: endymail@ietfa.amsl.com Delivered-To: endymail@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 504F81A0ADD for ; Wed, 27 Aug 2014 08:26:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HDOYae4cXTcL for ; Wed, 27 Aug 2014 08:26:02 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A441E1A0ACA for ; Wed, 27 Aug 2014 08:26:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2916; q=dns/txt; s=iport; t=1409153162; x=1410362762; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=ojJOb6v3Xaqp1gGQfzexBYN7zLyZPKKSmSbnC7AnX+Y=; b=W81Z+22H7axHzlvZZZt3d14kpHEG2YrrKTUjTg9ozLeKQzkAr/C12BzU datElqI471QQnL55CFk52x9FsYxgPEFooAbvgigw6MFIi2WxTV2OOgIbV ANLGeNWXo34Ya7W2FhdLV2CggjPqf57QvVYrCYvWcwGs4eAMovZTTdXs5 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah0FAD73/VOtJA2G/2dsb2JhbABbgw1TVwSCeMkiDIZ6UwEZeRZ3hAQBAQICAQEBIBE6GwIBCBgCAiYCAgIlCxUQAgQBEohCDapPlEEXgSyNbTqCeTaBHQWRL4QthnyBW5M/g15sAYFHgQcBAQE X-IronPort-AV: E=Sophos;i="5.04,412,1406592000"; d="scan'208";a="350705139" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-5.cisco.com with ESMTP; 27 Aug 2014 15:26:00 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s7RFQ0jx027842 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 27 Aug 2014 15:26:00 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.68]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0195.001; Wed, 27 Aug 2014 10:26:00 -0500 From: "Joe Hildebrand (jhildebr)" To: Tom Ritter , "endymail@ietf.org" Thread-Topic: [Endymail] Off we go... Thread-Index: AQHPwX34ogzl9fkBREe+zwM4ZgKLRZvkC8GAgAB2+IA= Date: Wed, 27 Aug 2014 15:25:59 +0000 Message-ID: References: <53FD0B7D.8070705@qti.qualcomm.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/15.3.0.140730 x-originating-ip: [10.21.86.162] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/2kj7AfRPfrs7azubFSBJWh_DflA Subject: Re: [Endymail] Off we go... X-BeenThere: endymail@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 15:26:04 -0000 Rm9yIGRpc3RyaWJ1dGluZyBrZXlzLCBQT1NIIHNlZW1zIGxpa2UgaXQgd291bGQgYmUgYWxzbyBi ZSBpbnRlcmVzdGluZzoNCg0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi14 bXBwLXBvc2gtMDENCg0KDQpBcyBkb2VzIFJGQyA3MDMzIChXZWJGaW5nZXIpLCBib3RoIG9mIHdo aWNoIHJlbHkgb24gZXh0ZW5kaW5nIHRydXN0IGZyb20gDQpIVFRQUyB0byBvdGhlciBkb21haW5z Lg0KDQpPbiA4LzI3LzE0LCAyOjIwIEFNLCAiVG9tIFJpdHRlciIgPHRvbUByaXR0ZXIudmc+IHdy b3RlOg0KDQo+T24gMjYgQXVndXN0IDIwMTQgMTc6MzQsIFBldGUgUmVzbmljayA8cHJlc25pY2tA cXRpLnF1YWxjb21tLmNvbT4gd3JvdGU6DQo+PiBTbyBvZmYgd2UgZ28uLi4gV2hhdCBwcm9qZWN0 cyBhcmUgZm9sa3Mgd29ya2luZyBvbg0KPg0KPlByaW9yIHRvIFNub3dkZW4ncyByZXZlbGF0aW9u cywgYSBmcmllbmQgYW5kIEkgaGFkIGdpdmVuIHNvbWUNCj50aG91Z2h0WzBdIHRvIGEgc3lzdGVt IHRoYXQgc3VwcG9ydGVkIHByb3ZpZGVyLXRvLXByb3ZpZGVyIGVuY3J5cHRpb24sDQo+d2hlcmUg dGhlIGVuZCBjb3VsZCBiZSBleHRlbmRlZCBvbiBlaXRoZXIgc2lkZSB0byBlbmQtdG8tcHJvdmlk ZXIgb3INCj5lbmQtdG8tZW5kIGVuY3J5cHRpb24uICBBbG9uZyB0aGUgd2F5IHdlIHRob3VnaHQg YWJvdXQgZGlzdHJpYnV0aW5nDQo+a2V5cyBvdmVyIEhUVFBTIHZzIEROU1sxXSwgYXV0aGVudGlj aXR5WzJdLCBhIHJlcG9ydC1vbmx5IGRlcGxveW1lbnQNCj5tb2RlWzNdLCBhbmQgb3RoZXIgc3R1 ZmYuICBXZSBzaGVsdmVkIG91ciBwcm9wb3NhbCwgYnV0IHB1Ymxpc2hlZCBvdXINCj50aG91Z2h0 cyBpbiBhIGRvY3VtZW50IHRoYXQgd2UgaG9wZWQgd291bGQgYWRkIHNvbWUgdGhvdWdodHMgYW5k DQo+Y29udGV4dCB0byBmdXR1cmUgZGlzY3Vzc2lvbnMuICBGdWxsIHNwZWMgaXMgYXQNCj5odHRw czovL2dpdGh1Yi5jb20vdG9tcml0dGVydmcvdWVlDQo+DQo+SSBjYW4ndCBjbGFpbSB0byBiZSB3 b3JraW5nIG9uIHRoaXMsIGJ1dCBJJ20gZXhjaXRlZCBhYm91dA0KPmh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtZGFuZS1zbXRwLXdpdGgtZGFuZS8NCj4NCj5JJ20g YWxzbyB0YW5nZW50aWFsbHkgaW52b2x2ZWQgKHRocm91Z2ggbXkgam9iKSB3aXRoIE5DQyBHcm91 cCdzDQo+LnRydXN0IGluaXRpYXRpdmVbNF0uICBUaGVyZSBhcmUgYSBsb3Qgb2YgcG9saWN5IGNv bnRyb2xzLCBidXQgYWxzbw0KPnRlY2huaWNhbCBvbmVzLiBTb21lIG9mIHRoZSBndWFyYW50ZWVz IHlvdSB3aWxsIGhhdmUgd2hlbg0KPmNvbW11bmljYXRpbmcgd2l0aCBhIGRvbWFpbiBpbiB0aGUg LnRydXN0IGdUTEQgd2lsbCBiZSB0aGF0IHRoZSBkb21haW4NCj53aWxsIGhhdmUgdmFsaWQgVExT IGNlcnRpZmljYXRlcyBmb3IgU3RhcnRUTFMsIHdpbGwgaGF2ZSBTdGFydFRMUw0KPmF2YWlsYWJs ZSwgd2lsbCB1c2UgRE5TU0VDLCBES0lNLCBhbmQgYSBob3N0IG9mIG90aGVyIHRlY2huaWNhbA0K PnJlcXVpcmVtZW50cy4NCj4NCj4tdG9tDQo+DQo+DQo+WzBdIGh0dHBzOi8vcml0dGVyLnZnL2Js b2ctdWVlX2VtYWlsX2VuY3J5cHRpb24uaHRtbA0KPlsxXSANCj5odHRwczovL2dpdGh1Yi5jb20v dG9tcml0dGVydmcvdWVlL2Jsb2IvbWFzdGVyL2FwcGVuZGl4LWtleS1kaXN0cm8tY2hvaWNlLg0K Pm1kDQo+WzJdIA0KPmh0dHBzOi8vZ2l0aHViLmNvbS90b21yaXR0ZXJ2Zy91ZWUvYmxvYi9tYXN0 ZXIvcHJvcG9zYWwubWQja2V5LWF1dGhlbnRpY2l0DQo+eQ0KPlszXSANCj5odHRwczovL2dpdGh1 Yi5jb20vdG9tcml0dGVydmcvdWVlL2Jsb2IvbWFzdGVyL3Byb3Bvc2FsLm1kI3JlcG9ydC1vbmx5 LW1vZA0KPmUNCj5bNF0gaHR0cHM6Ly93d3cubmNjZ3JvdXAuY29tL21lZGlhLzExMjAxNC90cnVz dC1mYXEucGRmDQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj5FbmR5bWFpbCBtYWlsaW5nIGxpc3QNCj5FbmR5bWFpbEBpZXRmLm9yZw0KPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZW5keW1haWwNCj4NCg0KDQotLSANCkpv ZSBIaWxkZWJyYW5kDQoNCg0KDQo= From nobody Wed Aug 27 08:58:48 2014 Return-Path: X-Original-To: endymail@ietfa.amsl.com Delivered-To: endymail@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 202DA1A0AF8 for ; Wed, 27 Aug 2014 08:58:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9zCNHWY-gR3N for ; Wed, 27 Aug 2014 08:58:43 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BC371A0AEF for ; Wed, 27 Aug 2014 08:58:43 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 215A52AB2C0; Wed, 27 Aug 2014 15:58:42 +0000 (UTC) Date: Wed, 27 Aug 2014 15:58:42 +0000 From: Viktor Dukhovni To: endymail@ietf.org Message-ID: <20140827155841.GO14392@mournblade.imrryr.org> References: <53FD0B7D.8070705@qti.qualcomm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53FD0B7D.8070705@qti.qualcomm.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/Fv0bwpuIjwBY7hbj_OsG4oaAR7c Subject: Re: [Endymail] Off we go... X-BeenThere: endymail@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: endymail@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 15:58:45 -0000 On Tue, Aug 26, 2014 at 03:34:37PM -0700, Pete Resnick wrote: > So off we go... What projects are folks working on, and what should the IETF > be doing in this space? If we get the email backbone broadly protected with TLS, the greatest remaining risk is data at rest (messages delivered to the user's mailbox). For me, the first step towards protecting messages at rest, is to encrypt them on delivery to the message store, where key management is simplest, because that store only needs the public keys of the recipient. So I'd like to see support for delivery-time encryption in LMTP servers (dovecot, ...). This gets the recipient's mail protected in storage regardless of the payload encryption capabilities of the sender. Yes, this is not an end-to-end mechanism, and it may be too late if at some point en-route the message was transmitted in the clear. Such support can gradually be moved closer to the edge, with payload encryption at the inbound gateway (roughly as far as many enterprises can allow it, since otherwise they lose visibility into the message content for anti-virus, data-leakage, regulatory archiving, ...). Beyond inbound gateway encryption, there is also an opportunity for gateway-to-gateway message encryption, but frankly I don't see much reason to do that rather than TLS. Finally, there is an opportunity to have end-to-end payload encryption, but seemingly at the cost of many of the features for which users trade-in their privacy with the major consumer email providers. Server-side anti-spam and search for example. With today's technologies we know that "Johnny can't encrypt", if we improve the technology, what will it take for "Johnny" to be willing to encrypt? What's the sweet-spot for protection of messages at rest that does not unacceptably impact usability? Unlike IM conversations, that users expect to be largely ephemeral, people tend to "hoard" email as a long-term record of communication. So with each technology or design discussed on this list, perhaps it might be helpful to understand where it fits into the protection spectrum and what are the usability trade-offs and the target audience. My take, is that with mobile devices and the like, which do not attempt to maintain a complete locally searchable archive of email (as one might with IMAP on a dedicated personal computer) there is strong incentive for email content management at the server, and end-to-end just can't compete. The usability constraints may be far too tight. I don't use any of the major providers for email, and don't synchronize smart-phones and the like to my self-hosted IMAP mailbox. So I can work with the quite decent search and anti-spam capabilities in the desktop/laptop IMAP client. I am very much the exception to the rule. So I am somewhat skeptical that the competing demands in this space can be met simultaneously, and my guess is that usability will win hands down for most users. It would be nice for my hunch to be proved wrong. -- Viktor. From nobody Wed Aug 27 09:22:22 2014 Return-Path: X-Original-To: endymail@ietfa.amsl.com Delivered-To: endymail@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCC5C1A0B0B for ; Wed, 27 Aug 2014 09:22:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.725 X-Spam-Level: X-Spam-Status: No, score=0.725 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_DBL_ABUSE_REDIR=0.001, URIBL_DBL_REDIR=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ei1E7AaP9B2K for ; Wed, 27 Aug 2014 09:22:18 -0700 (PDT) Received: from mail-yh0-f44.google.com (mail-yh0-f44.google.com [209.85.213.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5484C1A0233 for ; Wed, 27 Aug 2014 09:22:18 -0700 (PDT) Received: by mail-yh0-f44.google.com with SMTP id f73so455024yha.17 for ; Wed, 27 Aug 2014 09:22:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=BUIEE/39MXOw/FJ8o/QOfQbErPgyDxmuGrL0C7nWHBM=; b=mLTccKtcLrpd1pybYmBKyVQerHoJkn8+vvrb51lpr6plafvPoCFI6eNh0yRll9Q/31 ee9vaQWVFO+T20s8dYUipEMsyNGoIcgKcrSxJTT76wQfzpZRVm7p87On6BAob6DE2Nn6 SqucobBGWIB5m9tbhsUWS7TvrOnW434pz4aa16XlTKPXkf8tG5i9BEVEAlhotD3fzFMt Q/fPgqseWrh6CZQ9mW82VT3uo9SoXFtM/L0X3zBxFC588tWAzf7NuJQexEQfCoczKLnk HT3qzII3Noee5vjEcjK84vZs4kNwsT79KId1UGIMJwpykxqnFwYOaBLNOH69Grf7xrLW 3QLQ== X-Gm-Message-State: ALoCoQm/HEjGOKvpbTdwGbh4rMM3L45R6D3rqMqwFOGThhgnZzfCcUgxfSqJNKSvsBybHZ+Az+iJ X-Received: by 10.220.59.138 with SMTP id l10mr1693012vch.59.1409156536234; Wed, 27 Aug 2014 09:22:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.221.49.194 with HTTP; Wed, 27 Aug 2014 09:21:56 -0700 (PDT) X-Originating-IP: [24.84.235.32] From: Tim Bray Date: Wed, 27 Aug 2014 09:21:56 -0700 Message-ID: To: endymail@ietf.org Content-Type: multipart/alternative; boundary=001a11c25182c691cd05019ed267 Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/ypdaT2xJrz87KM4T4EBZrmqJ1dQ Subject: [Endymail] Another view of the problem and what the IETF could do X-BeenThere: endymail@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 16:22:21 -0000 --001a11c25182c691cd05019ed267 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I think the inclusion of the string =E2=80=9Cmail=E2=80=9D in the list titl= e is perhaps unduly limiting. I exchange a lot of messages on the Internet and, yeah, some are email but a lot aren=E2=80=99t; various social-media and chat mess= aging services. It seems to me that more or less anything that can interchange text between humans in an end-to-end way should be able to carry an end-to-end encrypted payload, and that the IETF should help facilitate this. Suppose a piece of messaging software wants to make it easy for me to encrypt something for a particular recipient at the other end. The following steps are necessary: 1. Find a public key for the user that the sender=E2=80=99s prepared to tru= st. 2. Encrypt the message 3. Get the message there, then=E2=80=A6 4. The recipient uses their private key to decrypt the message 5. Display the message appropriately, depending what it is I think it=E2=80=99s important that this is not a hypothetical. Right now = on Android, there are crypto apps (in particular I know of OpenKeychain, but there are others) that use Android=E2=80=99s =E2=80=9CSharing=E2=80=9D syst= em to good effect, so you can do this: a. Start with anything: Some text, a picture, a video, whatever, in some ap= p b. Hit the app=E2=80=99s =E2=80=9CShare=E2=80=9D button c. In the list of Share targets is =E2=80=9CEncrypt with =E2=80= =9D d. pops up, you pick a recipient from the list of public keys you=E2=80=99ve stored e. encrypts, asks you how you want to share the encrypted message (mail, chat, whatever) f. Person receives encrypted message. Hits =E2=80=9Cshare=E2=80=9D. Sends = it to . Crypto app asks for private-key passphrase, decrypts, either displays result or lets them share it to a more appropriate app. This works. Nobody ever sees a hex digit. Going back to the first list: 1. Find a public key for the user that the sender=E2=80=99s prepared to tru= st. This is a big problem. The PGP Web of Trust has failed, and we=E2=80=99ve a= ll heard the griping about the CA biz. Joe Hildebrand mentioned POSH & WebFinger and they=E2=80=99re both interesting. I=E2=80=99m also interested in the n= otion of a key directory with associated proofs that you don=E2=80=99t have to trust, for = example the one from https://keybase.io. In particular see https://keybase.io/docs/server_security WORK FOR IETF: Get pro-active on key discovery/trust work? Standardize key search APIs? 2. Encrypt the message and 4. The recipient uses their private key to decrypt the message These are sort of solved by various OpenPGP implementations, and also see https://minilock.io/ Except for, many people live in the browser and their lives would be improved if they could do the crypto there. This means trusting network-delivered JavaScript code, which is a conundrum; I wrote about it at some length at http://goo.gl/KsKe6u WORK FOR IETF: Well, maybe, but it feels more like W3C or WHAT or TC39 stuff. Could we help with code-signature specs? 3. Get the message there, then=E2=80=A6 Solved nicely by all sorts of internet tools. WORK FOR IETF: Nope. 5. Display the message appropriately, depending what it is This is a problem. Lots of the messages I want to send are movies or songs or pictures, and if there=E2=80=99s no way to communicate the Media Type, i= t=E2=80=99s less useful to the recipient. WORK FOR IETF: Maybe revive draft-moscaritolo-openpgp-literal ? --=20 - Tim Bray (If you=E2=80=99d like to send me a private message, see https://keybase.io/timbray) --001a11c25182c691cd05019ed267 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I t= hink the inclusion of the string =E2=80=9Cmail=E2=80=9D in the list title i= s perhaps unduly limiting. I exchange a lot of messages on the Internet and= , yeah, some are email but a lot aren=E2=80=99t; various social-media and c= hat messaging services. =C2=A0It seems to me that more or less anything tha= t can interchange text between humans in an end-to-end way should be able t= o carry an end-to-end encrypted payload, and that the IETF should =C2=A0hel= p facilitate this.

Suppose a piece of messaging s= oftware wants to make it easy for me to encrypt something for a particular = recipient at the other end. =C2=A0The following steps are necessary:

1. Find a public key for the u= ser that the sender=E2=80=99s prepared to trust.
2. Encrypt the message
3. Get the message there, then=E2=80=A6
4. The recipient uses their private key to= decrypt the message
5. Display the messa= ge appropriately, depending what it is

I think it=E2=80=99s important that this is not a hypothetical. =C2=A0Right= now on Android, there are crypto apps (in particular I know of OpenKeychai= n, but there are others) that use Android=E2=80=99s =E2=80=9CSharing=E2=80= =9D system to good effect, so you can do this:

a. Start with anything: Some t= ext, a picture, a video, whatever, in some app
b. Hit the app=E2=80=99s =E2=80=9CShare=E2=80=9D button
c. In the list of Share targets is= =E2=80=9CEncrypt with <crypto app>=E2=80=9D
d. <Crypto app> pops up, you pick= a recipient from the list of public keys you=E2=80=99ve stored
e. <Crypto app>= ; encrypts, asks you how you want to share the encrypted message (mail, cha= t, whatever)
f. Person receives e= ncrypted message. =C2=A0Hits =E2=80=9Cshare=E2=80=9D. Sends it to <crypt= o app>. Crypto app asks for private-key passphrase, decrypts, either dis= plays result or lets them share it to a more appropriate app.

This works. =C2=A0Nobody ever = sees a hex digit.

Going back to the fi= rst list:

<= /div>
1. Find a public key for the user that the sender=E2=80=99s prepared to tru= st.

This is a big problem. The PGP Web of Trust has failed, and we=E2=80= =99ve all heard the griping about the CA biz. =C2=A0Joe Hildebrand mentione= d POSH & WebFinger and they=E2=80=99re both interesting. =C2=A0I=E2=80= =99m also interested in the notion of a key directory with associated proof= s that you don=E2=80=99t have to trust, for example the one from https://keybase.io. =C2=A0In pa= rticular see=C2=A0https://keybase.io/docs/server_security
WORK FOR IETF: Get pro-active on key discovery= /trust work? Standardize key search APIs?
=C2=A0
2. Encrypt the me= ssage and=C2=A0
4. The recipient uses the= ir private key to decrypt the message
These are sort of solved by various OpenPGP implementations, and also see <= a href=3D"https://minilock.io/">https://minilock.io/
Except f= or, many people live in the browser and their lives would be improved if th= ey could do the crypto there. This means trusting network-delivered JavaScr= ipt code, which is a conundrum; I wrote about it at some length at=C2=A0http://goo.gl/KsKe6u=C2= =A0
WORK FOR IETF: Well, maybe, but it= feels more like W3C or WHAT or TC39 stuff. Could we help with code-signatu= re specs?

3. Get the message there, then=E2=80=A6
Solved nicely by all sort= s of internet tools. =C2=A0
WORK FOR IETF: Nope.

5. Display= the message appropriately, depending what it is
This is a problem. =C2=A0Lots of the = messages I want to send are movies or songs or pictures, and if there=E2=80= =99s no way to communicate the Media Type, it=E2=80=99s less useful to the = recipient.=C2=A0
WORK FOR IETF: Maybe= revive draft-moscaritolo-openpgp-literal ?

--
- Tim Bray (If you=E2=80=99d like to send me a private message, see https://keybase.io/timbra= y)
--001a11c25182c691cd05019ed267-- From nobody Wed Aug 27 10:02:57 2014 Return-Path: X-Original-To: endymail@ietfa.amsl.com Delivered-To: endymail@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A2F71A003A for ; Wed, 27 Aug 2014 10:02:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.781 X-Spam-Level: X-Spam-Status: No, score=0.781 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SpDjPKCixab2 for ; Wed, 27 Aug 2014 10:02:53 -0700 (PDT) Received: from nekare.kjorling.se (nekare.kjorling.se [89.221.249.175]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5F921A0019 for ; Wed, 27 Aug 2014 10:02:52 -0700 (PDT) Received: by nekare.kjorling.se (Postfix, from userid 1001) id 785A8114075; Wed, 27 Aug 2014 17:02:50 +0000 (UTC) X-Spam-Details: BAYES_00=-1.9, SPF_FAIL=0.001 (nekare.kjorling.se) Received: from yeono.kjorling.se (h-9-65.a328.priv.bahnhof.se [46.59.9.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "yeono", Issuer "yeono" (not verified)) by nekare.kjorling.se (Postfix) with ESMTPS id BA81C114067 for ; Wed, 27 Aug 2014 17:02:41 +0000 (UTC) Received: from yeono.kjorling.se (localhost [127.0.0.1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by yeono (Postfix) with ESMTPS id 5AF10140031 for ; Wed, 27 Aug 2014 19:02:41 +0200 (CEST) Date: Wed, 27 Aug 2014 17:02:40 +0000 From: Michael =?utf-8?B?S2rDtnJsaW5n?= To: endymail@ietf.org Message-ID: <20140827170240.GN7149@yeono.kjorling.se> References: <53FD0B7D.8070705@qti.qualcomm.com> <20140827155841.GO14392@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20140827155841.GO14392@mournblade.imrryr.org> Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/QRxBaifEgFIT33Gh1goiiTl8hdI Subject: Re: [Endymail] Off we go... X-BeenThere: endymail@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 17:02:55 -0000 On 27 Aug 2014 15:58 +0000, from ietf-dane@dukhovni.org (Viktor Dukhovni): > So I'd like to see support for delivery-time encryption in LMTP > servers (dovecot, ...). This gets the recipient's mail protected > in storage regardless of the payload encryption capabilities of > the sender. Yes, this is not an end-to-end mechanism, and it may > be too late if at some point en-route the message was transmitted > in the clear. > What's the sweet-spot for protection of messages at rest that does > not unacceptably impact usability? Unlike IM conversations, that > users expect to be largely ephemeral, people tend to "hoard" email > as a long-term record of communication. On the reverse side of the generally small, stamped, disk-shaped metallic object to which we ascribe monetary value, otherwise known as a coin, these to me both sound like implementation concerns. There would be little stopping me from, today, taking an appropriate library and adding it to the LMTP delivery chain code of my favorite software. I could even almost certainly do something like the first basically by chaining together procmail and gnupg/openssl/whatever on the LMTP server and end user client side. Presto, email security at rest server-side. No IETF work needed. With a few relatively simple modifications, it should be possible to make the software guarantee that (as far as the OS can guarantee it) a message never leaves server RAM unencrypted. (We already have POP3 and IMAP4 over both SSL and STARTTLS; it should be a relatively trivial change allowing encrypted at rest messages to not be downloaded over an insecure connection.) UAs can cache decryption keys for whatever period of time is deemed reasonable, and the length of that period of time (and the allowed use of cached keys without reauthentication) can be made configurable by the user likely without overwhelming even relatively new users. ("Allow searching secure email without requiring a password" and "Allow displaying secure email without requiring a password" could be a start.) It wouldn't be perfect; for example, someone with a debugger running on the system in question would be able to gain access to the decryption keys; but then again at that point it's quite possible that the user's system is rooted anyway, in which case transport security doesn't help. (That needs quite different steps to mitigate, which would seem to me to be outside of the scope of this discussion list.) An issue that any end-to-end message encryption scheme would more or less have to address, though, as I see it, is _how do I know that I am encrypting to the right individual?_ Yes, computers could take care of that part, especially once communications is established, but somehow Alice still needs to know that she is sending that first message (and encrypting it to) Bob Bravo, who uses bobb@example.net because Mallory snatched bob@example.net. Considering that e-mail address mistypes are quite common in the wild, and may very well result in the message actually being delivered to the wrong person, initial establishment of secure communications seems like something that would need addressing (figuratively _and_ literally). -- Michael Kjörling • https://michael.kjorling.se • michael@kjorling.se OpenPGP B501AC6429EF4514 https://michael.kjorling.se/public-keys/pgp “People who think they know everything really annoy those of us who know we don’t.” (Bjarne Stroustrup) From nobody Thu Aug 28 13:57:42 2014 Return-Path: X-Original-To: endymail@ietfa.amsl.com Delivered-To: endymail@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67F651A01AC for ; Thu, 28 Aug 2014 13:57:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] 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 ZBljsvDR20Vo for ; Thu, 28 Aug 2014 13:57:36 -0700 (PDT) Received: from daboo.name (daboo.name [173.13.55.49]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01D511A0099 for ; Thu, 28 Aug 2014 13:57:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 2C148768B17; Thu, 28 Aug 2014 16:53:01 -0400 (EDT) X-Virus-Scanned: amavisd-new at example.com Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Ny5g89cK_4E; Thu, 28 Aug 2014 16:52:59 -0400 (EDT) Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id A3566768AF7; Thu, 28 Aug 2014 16:52:57 -0400 (EDT) Date: Thu, 28 Aug 2014 16:57:25 -0400 From: Cyrus Daboo To: Phillip Hallam-Baker , Pete Resnick , Stephen Farrell Message-ID: <9ECDC905D01276A63A779E35@caldav.corp.apple.com> In-Reply-To: References: <53FD0B7D.8070705@qti.qualcomm.com> X-Mailer: Mulberry/4.1.0b1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=491 Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/GGHV29zGzs3tzzjdnb0uDCRXi8I Cc: endymail@ietf.org Subject: Re: [Endymail] Off we go... X-BeenThere: endymail@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 20:57:38 -0000 Hi Phillip, --On August 26, 2014 at 10:23:02 PM -0400 Phillip Hallam-Baker wrote: > And before you start off telling me about PGP, getting that to work > proved so tedious I gave up Right, but some major players are getting onboard with OpenPGP, as per . So one would hope they will tackle usability given the broad scope of their user base. -- Cyrus Daboo From nobody Thu Aug 28 14:43:10 2014 Return-Path: X-Original-To: endymail@ietfa.amsl.com Delivered-To: endymail@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D86CE1A6F28 for ; Thu, 28 Aug 2014 14:43:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.58 X-Spam-Level: X-Spam-Status: No, score=-3.58 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_SOFTFAIL=0.665] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jrgnc8c2NlWP for ; Thu, 28 Aug 2014 14:43:02 -0700 (PDT) Received: from cm01fe.IST.Berkeley.EDU (cm01fe.IST.Berkeley.EDU [169.229.218.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90B491A6F26 for ; Thu, 28 Aug 2014 14:43:02 -0700 (PDT) Received: from mail-ie0-f179.google.com ([209.85.223.179]) by cm01fe.ist.berkeley.edu with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.76) (auth plain:frankli@berkeley.edu) (envelope-from ) id 1XN7TB-0004uo-3S for endymail@ietf.org; Thu, 28 Aug 2014 14:43:02 -0700 Received: by mail-ie0-f179.google.com with SMTP id tr6so1704848ieb.24 for ; Thu, 28 Aug 2014 14:43:00 -0700 (PDT) X-Received: by 10.50.88.72 with SMTP id be8mr41005004igb.26.1409262180286; Thu, 28 Aug 2014 14:43:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.128.96 with HTTP; Thu, 28 Aug 2014 14:42:40 -0700 (PDT) In-Reply-To: <9ECDC905D01276A63A779E35@caldav.corp.apple.com> References: <53FD0B7D.8070705@qti.qualcomm.com> <9ECDC905D01276A63A779E35@caldav.corp.apple.com> From: Frank Li Date: Thu, 28 Aug 2014 14:42:40 -0700 Message-ID: To: Cyrus Daboo Content-Type: multipart/alternative; boundary=089e013cbeb4a6ca1b0501b76bd4 Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/kGhA3Z26ALxeqipzOwh-Ir1Umpo Cc: Pete Resnick , Phillip Hallam-Baker , endymail@ietf.org, Stephen Farrell Subject: Re: [Endymail] Off we go... X-BeenThere: endymail@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 21:43:09 -0000 --089e013cbeb4a6ca1b0501b76bd4 Content-Type: text/plain; charset=UTF-8 (Unrelated to previous discussion) Food for thought: One thought I had a while back was the merits of hash-based email addressing, where the address is a relatively short hash of an account's public key (just like PGP fingerprints). The idea was that the email address itself can validate the PK, and the PK can be automatically retrieved from anywhere (key servers, mail provider). This could allow a mail client to completely transparently handle key management and email encryption/decryption/signing. While the email address is non-human-sensible, the mail client can provide local user-chosen bindings, similar to how a contact book on a phone maps a name to phone #s. Certainly there are other usability challenges as well though. Perhaps proper user interfaces can make dealing w/ a hash-address not too much of a burden. Ultimately this is not really different from PGP; we're merging an email address and fingerprint in PGP into a single "hash-based" email. But the idea was that in this scheme people would only conceptually deal w/ an email address (granted non-sensible). They don't need to be aware of keys, fingerprints, or web of trust, which might help usability. Certainly the idea has issues though, food for thought. On Thu, Aug 28, 2014 at 1:57 PM, Cyrus Daboo wrote: > Hi Phillip, > > > --On August 26, 2014 at 10:23:02 PM -0400 Phillip Hallam-Baker < > phill@hallambaker.com> wrote: > > And before you start off telling me about PGP, getting that to work >> proved so tedious I gave up >> > > Right, but some major players are getting onboard with OpenPGP, as per < > http://www.pcworld.com/article/2462852/yahoo-mail-to- > support-end-to-end-pgp-encryption-by-2015.html>. So one would hope they > will tackle usability given the broad scope of their user base. > > -- > Cyrus Daboo > > > _______________________________________________ > Endymail mailing list > Endymail@ietf.org > https://www.ietf.org/mailman/listinfo/endymail > --089e013cbeb4a6ca1b0501b76bd4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
(Unrelated to previous discussion)

Food= for thought:

One thought I had a while back was t= he merits of hash-based email addressing, where the address is a relatively= short hash of an account's public key (just like PGP fingerprints). Th= e idea was that the email address itself can validate the PK, and the PK ca= n be automatically retrieved from anywhere (key servers, mail provider). Th= is could allow a mail client to completely transparently handle key managem= ent and email encryption/decryption/signing.=C2=A0

While the email address is non-human-sensible, the mail= client can provide local user-chosen bindings, similar to how a contact bo= ok on a phone maps a name to phone #s. Certainly there are other usability = challenges as well though. Perhaps proper user interfaces can make dealing = w/ a hash-address not too much of a burden.=C2=A0

Ultimately this is not really different from PGP; we= 9;re merging an email address and fingerprint in PGP into a single "ha= sh-based" email. But the idea was that in this scheme people would onl= y conceptually deal w/ an email address (granted non-sensible). They don= 9;t need to be aware of keys, fingerprints, or web of trust, which might he= lp usability. Certainly the idea has issues though, food for thought.



On Thu, Aug 28, 2014 at 1:57 PM, Cyrus Daboo <cyrus@daboo.name> wrote:
Hi Phillip, Right, but some major players are getting onboard with OpenPGP, as per <= http://www.pcworld.c= om/article/2462852/yahoo-mail-to-support-end-to-end-pgp-encryption-by-2015.html>. So one would hope they will tackle usabi= lity given the broad scope of their user base.

--
Cyrus Daboo


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

--089e013cbeb4a6ca1b0501b76bd4-- From nobody Thu Aug 28 14:44:16 2014 Return-Path: X-Original-To: endymail@ietfa.amsl.com Delivered-To: endymail@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D06A01A6F24 for ; Thu, 28 Aug 2014 14:44:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u72vkDJF0u2M for ; Thu, 28 Aug 2014 14:44:11 -0700 (PDT) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3371F1A6F0F for ; Thu, 28 Aug 2014 14:44:11 -0700 (PDT) Received: by mail-la0-f41.google.com with SMTP id gi9so1753175lab.0 for ; Thu, 28 Aug 2014 14:44:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=eVw1jGDtJhIyBZAo9IkLX0TynjSzk8ozzO6QsyXfHto=; b=O7pFLSkYG/u6ky4lvu+/PPs4/xfqLGcb/7gqv3PsuCZPYZXEi6THUlHkNeukWwTmGM ABKKEgu18T6FWhKtdYUu6SK0WhQS//fre8fdb++K24T/Sw2HsLX4L+UAJKva6uu1pCm5 BhYRlkmomsA2pb3xSNuWMrkFK3cejCgSWy9iezsjrawtVZMJVOpX0BSmx0dZzUSVtuqN a7g/c6XRpiPG9P3bWbxosbNF1PeXqqC7K5Wf8lh2KuD9a3vi0PGmoFn8sq2MG2mt90fW dsd3W4HdJ+d1BkaSVjiyiQzu7E5ote+V68oKzS+E8/OK1BMgSSEeFB5EzTz18TNL+PFc douw== MIME-Version: 1.0 X-Received: by 10.112.24.104 with SMTP id t8mr1764874lbf.46.1409262249461; Thu, 28 Aug 2014 14:44:09 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.122.50 with HTTP; Thu, 28 Aug 2014 14:44:09 -0700 (PDT) In-Reply-To: <9ECDC905D01276A63A779E35@caldav.corp.apple.com> References: <53FD0B7D.8070705@qti.qualcomm.com> <9ECDC905D01276A63A779E35@caldav.corp.apple.com> Date: Thu, 28 Aug 2014 17:44:09 -0400 X-Google-Sender-Auth: UMOzPHBDlZxZNPOvt5b-xwcJCu4 Message-ID: From: Phillip Hallam-Baker To: Cyrus Daboo Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/hbU1b8HcQCbja7Y5M1kCcj46q6k Cc: Pete Resnick , endymail , Stephen Farrell Subject: Re: [Endymail] Off we go... X-BeenThere: endymail@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 21:44:12 -0000 On Thu, Aug 28, 2014 at 4:57 PM, Cyrus Daboo wrote: > Hi Phillip, > > > --On August 26, 2014 at 10:23:02 PM -0400 Phillip Hallam-Baker > wrote: > >> And before you start off telling me about PGP, getting that to work >> proved so tedious I gave up > > > Right, but some major players are getting onboard with OpenPGP, as per > . > So one would hope they will tackle usability given the broad scope of their > user base. So far I don't see a supported product from either. The problem with usability is that there is a naive version which amounts to 'hide all the cruft from the user so they don't notice'. In furniture terms this is like sticking veneer over everything so people don't notice its made from chipboard. Calling chipboard engineered wood doesn't change things either. To make either PGP or S/MIME usable we need to address the structural issues that are making it hard to use. In particular: * Easy way to migrate encryption keys into new devices. * Key recovery mechanisms so people don't loose their mail by accident. * Easy key rollover These are not hard to do if they are considered problems that have to be solved. But what has happened in the past is that they have been shuffled under the mat as 'advanced user problems'. From nobody Thu Aug 28 15:05:05 2014 Return-Path: X-Original-To: endymail@ietfa.amsl.com Delivered-To: endymail@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C658D1A000F for ; Thu, 28 Aug 2014 15:05:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R9H-mM19yvI9 for ; Thu, 28 Aug 2014 15:04:57 -0700 (PDT) Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 528F21A0002 for ; Thu, 28 Aug 2014 15:04:56 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id k14so1327487wgh.28 for ; Thu, 28 Aug 2014 15:04:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=H9FXgf4YQZR5H/fpXRYRzuwyv0YU4sHxoa6jrAi2aE0=; b=EtOQwbVi+dZUaamUtRj0ibfK1Eh2b975AHD0T22i8W4o/dJtJzZzhr/UaZlXhK2XkO 3V71EHTLLRI4IZeuqR2I22Vq9v5KNXkfV7m7InKhN7SIW+qxYLvQD6ukmPW8VjwDchhI VC+a2To4Yd6M0gXoUY2eipftxOUj+WtzZAGT2e/T+A6D9rhEwthspXqgw6g9pxkOIxcY Eojx+DvaWHU1IaHl25mTLYvepkIz0F1a2o7NTUeuPwWLQpN4CQoaFVzf5Pw914+J1Ms2 G9sfo1gLuBaXzdtg7vVkpfIdl6aZdpEOI4qUWdW5RjASrr6P9Rla8JgSOAOqJSFGUX00 /3ww== X-Gm-Message-State: ALoCoQkzo8EC2wXZM+SwKgt7HA1Y+sETwEbkZru89+63Ae1yepct2jgRTxLbN3wuqq+/vMqDfecs X-Received: by 10.194.3.106 with SMTP id b10mr8820551wjb.3.1409263495465; Thu, 28 Aug 2014 15:04:55 -0700 (PDT) Received: from vegoda.org (v6only.vegoda.org. [2a00:1098:0:86:1000:26:0:1]) by mx.google.com with ESMTPSA id o10sm3716715wia.0.2014.08.28.15.04.53 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Thu, 28 Aug 2014 15:04:54 -0700 (PDT) Date: Thu, 28 Aug 2014 23:04:45 +0100 From: Leo Vegoda To: Frank Li Message-ID: <20140828220445.GA5864@vegoda.org> References: <53FD0B7D.8070705@qti.qualcomm.com> <9ECDC905D01276A63A779E35@caldav.corp.apple.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/8q3wKTxUQY1Asf6oe6tIMuXGwVE Cc: endymail@ietf.org Subject: Re: [Endymail] Off we go... X-BeenThere: endymail@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 22:05:05 -0000 On Thu, Aug 28, 2014 at 02:42:40PM -0700, Frank Li wrote: [...] > While the email address is non-human-sensible, the mail client can provide > local user-chosen bindings, similar to how a contact book on a phone maps a > name to phone #s. Certainly there are other usability challenges as well > though. We are still at a point in time where people need to write down e-mail addresses with a pen or pencil for later transcription, or spell them out loud. Unless we can come up with something that is typo-proof, I think that usage will be problematic. From nobody Thu Aug 28 16:23:25 2014 Return-Path: X-Original-To: endymail@ietfa.amsl.com Delivered-To: endymail@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 837C31A00F2 for ; Thu, 28 Aug 2014 16:23:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cLMQJDiJmsUK for ; Thu, 28 Aug 2014 16:23:22 -0700 (PDT) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 404641A00F0 for ; Thu, 28 Aug 2014 16:23:21 -0700 (PDT) Received: by mail-lb0-f179.google.com with SMTP id l4so1737502lbv.10 for ; Thu, 28 Aug 2014 16:23:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type; bh=B75T8KsM4KkMgoNV9sLz+CqYhp2TBZHp604rVLlMxs0=; b=OX1CZb1UyY18SkyMT2+5A+Jj5WCf+xGCH5L/j6HuPF8h/i/hNZiJ652iYJgTrCFUVl YDFw4VetOILGM9HzXGl/5tan5CJ33C3dTzuJvdA9ukHYzOWC3sMysfIdIC3PEdXNrsyz 5O47c0HYjjZTfE/XXhQhkUuzYWAaOpuPJDDzGT+ebTs17nWBtemSNzlP9n1KMAtHIHW+ XiwPCYLCkGvJBjcaEh7aFOOeSSGtJdqQPC8At2eHXZpnLqijo2p7XFMQVSg5MS99W5cu 2ignK5YfioZFj4R9jD0RH0ukcTlCs7/YXMW3t64qn9fF3KVdEhShY85LNoFmS17VKzcx b2mw== MIME-Version: 1.0 X-Received: by 10.112.199.42 with SMTP id jh10mr7368778lbc.49.1409268200365; Thu, 28 Aug 2014 16:23:20 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.122.50 with HTTP; Thu, 28 Aug 2014 16:23:20 -0700 (PDT) Date: Thu, 28 Aug 2014 19:23:20 -0400 X-Google-Sender-Auth: BRfyvy_KycPrVtvVQH8tg2l820A Message-ID: From: Phillip Hallam-Baker To: Leo Vegoda Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/dE31GRq9iOOJd3U3HTH4Yo96pvQ Cc: endymail , Frank Li Subject: [Endymail] Hashes of key as addresses X-BeenThere: endymail@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 23:23:23 -0000 Using hashes of keys as addresses is very powerful. There are basically three types of address in such schemes: 1) traditional human readable 2) hash of key 3) Traditional human readable + hash of key. So in PPE we use all three in different situations: 1) ACAIEA-FONPAC-5AC6LFA-K4ACHC-EAJWAHN-VPAM4A-COYPAO-VAA 2) alice@example.com 3) ACAIEA-FONPAC-5AC6LFA-K4ACHC-EAJWAHN-VPAM4A-COYPAO-VAA?alice@example.com We can apply the same approach with value to other situations. Lets say Alice owns example.com. We can create a strong domain name in the same way: ACAIEA-FONPAC-5AC6LFA-K4ACHC-EAJWAHN-VPAM4A-COYPAO-VAA?example.com Note here that unlike in the PGP world where we generally use the hash of the encryption key, PPE almost always uses the hash of a master key that signs the encryption/authentication/etc key. This might have been considered impractical in 1992 when machines were CPU limited but it isn't a problem today. Making this separation solves a lot of usability problems down the line. Now obviously nobody is going to want to read out a strong email address over the phone. But if we have the right discovery infrastructure in place they don't need to. And this is where TRANS/CT might come in (or something like it). Because one of the things you would want to do with a freshly minted key is to record the public part and some binding assertion in a notary service. So it is natural to have a feature in the key manager that allows you to say 'generate a key and register it with notary xyz.com.' I don't think I want to be registering my key with multiple notaries as I think they should be talking to each other in the manner of USENET of old. So one publication point should be enough. But once the key is registered we have also created the raw material that a key publication scheme might use. From nobody Thu Aug 28 18:34:24 2014 Return-Path: X-Original-To: endymail@ietfa.amsl.com Delivered-To: endymail@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38C1E1A023E for ; Thu, 28 Aug 2014 18:34:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2sn3VV70G_Ww for ; Thu, 28 Aug 2014 18:34:20 -0700 (PDT) Received: from mail-pa0-f46.google.com (mail-pa0-f46.google.com [209.85.220.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3A7D1A0208 for ; Thu, 28 Aug 2014 18:34:20 -0700 (PDT) Received: by mail-pa0-f46.google.com with SMTP id eu11so4872583pac.33 for ; Thu, 28 Aug 2014 18:34:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=PuNP0KCXoULltbNl2W7Fg5t0CQft9Oho1Xg051WMl1Y=; b=LcypyXHBGJdV4IiNW9n7mGTaIVpnzPRMqO5dQGXuTN01bHogG3UaxSBxMMjCPiEiAV WAJSedMa1a+x78JONVS5XqGp3IRAnlg0KzkFUFWmkIFTPBMswSO4k+nQEE5fYfd7OtmZ +K1YzrV6b3ZeTT37MrOv1vjkmcgWlilmIf8Hnh0t761qaRIjPiO+xo1fRD4MT7hpkFC1 kSOKFX0Rh+IRyDAL9IGKvZfTSlLB9+GYRhSWYlhoepBKdCQmsYQZAY712RMEJUSq98tp xE+noTaM/Ax4NQDolcZP/xnJvZhT/1PB63icPNejmSSeqqlT51YVCqBK1rT+zgj5M4C8 4G9Q== X-Gm-Message-State: ALoCoQm8qONpEZ09+tMJ0oCEtfjOv1uzv8hDTaHPn1sT+fwWr26oviRCPjTOsqdYA49msOHJJLwN X-Received: by 10.68.68.207 with SMTP id y15mr11242491pbt.25.1409276059866; Thu, 28 Aug 2014 18:34:19 -0700 (PDT) Received: from vegoda.org ([2605:e000:5903:f500:51a5:879:b5a3:7560]) by mx.google.com with ESMTPSA id lu15sm18258139pab.5.2014.08.28.18.34.18 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Thu, 28 Aug 2014 18:34:19 -0700 (PDT) Date: Thu, 28 Aug 2014 18:34:16 -0700 From: Leo Vegoda To: Phillip Hallam-Baker Message-ID: <20140829013416.GA27739@vegoda.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/7KorchJWBht9-kmrvGUlyzbBees Cc: endymail Subject: Re: [Endymail] Hashes of key as addresses X-BeenThere: endymail@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 01:34:22 -0000 On Thu, Aug 28, 2014 at 07:23:20PM -0400, Phillip Hallam-Baker wrote: [...] > Now obviously nobody is going to want to read out a strong email > address over the phone. But if we have the right discovery > infrastructure in place they don't need to. Can you please expand on this point? I think that if this is solved then public key information would be far easier but that without it we'll really struggle to communicate the secure form of an e-mail address. Thanks, Leo From nobody Thu Aug 28 19:02:43 2014 Return-Path: X-Original-To: endymail@ietfa.amsl.com Delivered-To: endymail@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4079E1A0290 for ; Thu, 28 Aug 2014 19:02:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.621 X-Spam-Level: X-Spam-Status: No, score=0.621 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wMCbwVZJm8Co for ; Thu, 28 Aug 2014 19:02:36 -0700 (PDT) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D4C31A0275 for ; Thu, 28 Aug 2014 19:02:33 -0700 (PDT) Received: by mail-lb0-f182.google.com with SMTP id u10so1849660lbd.13 for ; Thu, 28 Aug 2014 19:02:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Ckzs5ilItIz3jm0J575jdwiqkKq1gODjU7ocpIf9a7o=; b=tvgfuD2qFC6azVcaItCkND82+GIqlcR9BDgVqXmIFZlSZlmpEgSnw/B5D8XITVd4jO wv1ShIIHZoVlPKQEJU747QIyXOUhQ88s+TOndm4KlZiVwMF/tYS3XVBif2aKVFIgj4sV ahHQYBTQOVYs98EHAM2XSWxDzqXvjOOH/Gz6RCigSkRmTd1C29XXCr1WNJihWGJE4NTz n3ZTJ6Kft4Qm1JgQsrPmQ1iWsgNcoABplSHOG41Ar7gs2yoMgxwaovUhmav23uHmzuQk 8SC9GwPoL/6OaZm1BMwdy+WVJz6YNFjYPxH5hI+XNlakWxOMQ4ZgUyFNEsMRhvWnVXt7 3ZPg== MIME-Version: 1.0 X-Received: by 10.112.8.99 with SMTP id q3mr7823821lba.85.1409277751591; Thu, 28 Aug 2014 19:02:31 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.122.50 with HTTP; Thu, 28 Aug 2014 19:02:31 -0700 (PDT) In-Reply-To: <20140829013416.GA27739@vegoda.org> References: <20140829013416.GA27739@vegoda.org> Date: Thu, 28 Aug 2014 22:02:31 -0400 X-Google-Sender-Auth: 9V291Ec-04Ai9WwP2xSoug3jrMY Message-ID: From: Phillip Hallam-Baker To: Leo Vegoda Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/v26C6tPENWfqVrYZq0rc-6uSNH0 Cc: endymail Subject: Re: [Endymail] Hashes of key as addresses X-BeenThere: endymail@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 02:02:39 -0000 On Thu, Aug 28, 2014 at 9:34 PM, Leo Vegoda wrote: > On Thu, Aug 28, 2014 at 07:23:20PM -0400, Phillip Hallam-Baker wrote: > > [...] > >> Now obviously nobody is going to want to read out a strong email >> address over the phone. But if we have the right discovery >> infrastructure in place they don't need to. > > Can you please expand on this point? I think that if this is solved > then public key information would be far easier but that without it > we'll really struggle to communicate the secure form of an e-mail > address. Well first off, this is obviously an area where there are likely to be many ideas. So this is not something I want to weld into the client right now. The proper place therefore for the capability would be in a Web Service. In the past I worked on XKMS with Stephen and others. But these days curly brackets are more fashionable than angle braces so I think we want to go for a JSON service. I have two specs defining an interface to the services: 1) OmniPublish: A Web service used by the key holder to manage their keys. So this is the interface to the key publication mechanism, notarization, certification, recovery and similar services. 2) OmniQuery: A Web service used by a party wanting to establish a connection to an Internet end point which may be a Service or an account. These are both designed to support a broad spectrum of uses. But as it turns out end to end email turns out to be the hardest security problem to solve and so pretty much all the features are used. [Links to all this stuff is on prismproof.org] These specifications are designed to be as generic as possible and not make constraining assumptions. But for there to be a system there obviously needs to be some sort of infrastructure that takes the information published though OmniPublish, processes it in some fashion and delivers it on request in response to an OmniQuery. As I said, I think there will be many ideas and this is a good thing. But lets get one thing straight, lets make it so anyone who has a good idea on how to join the two interfaces up just needs to write that part of the code and not have to write their own email clients to test it out. The idea of OmniQuery is that it is a Web Service that acts like a meta-directory on steroid. The OmniQuery broker can obtain the information it returns in any way that makes sense. So that said, here are some examples of how the two can be connected: 1) CA based certificate issue CA issued email certs don't address every use case. In particular they don't address use cases where the trust relationships are non-hierarchical. But that does not change the fact that we have about 5 million users of S/MIME, most of whom work in organizations that are hierarchical and issued certificates accordingly. There have been many proposals for directories that map domains to certificate servers. And an OmniQuery broker could acquire information through those sources. 2) Certificate Transparency Notary Service Lets say that a self-signed certificate is generated and published to some party that enrolls it in a CT notary log and the log is public and the OmniQuery service reads the log. The OmniQuery service now has raw material that it could use to respond to key queries. 3) Combination of 1 and 2. Lets say I set up a CT service for self signed email certs. Given that Comodo offers free email certs, why not return them a freebie cert so that they can use their S/MIME mail to sign mail? Alternatively, won't a party running a log want to verify that a request comes from the actual holder of the email address? If so they will act like a CA even if they don't have all the process, audits etc. 4) Web of Trust. I really can't do justice to this here but the brief version is that the PGP Web of Trust is a crock because it does not scale. But add in a CT notary type service and a small number of CA validated links and suddenly you get a Web of Trust that is stronger than either the PKIX or Web of Trust model on its own. [Been talking about this for several months BTW]. From nobody Fri Aug 29 02:11:53 2014 Return-Path: X-Original-To: endymail@ietfa.amsl.com Delivered-To: endymail@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF2FE1A06E7 for ; Fri, 29 Aug 2014 02:11:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, J_CHICKENPOX_14=0.6, J_CHICKENPOX_41=0.6, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UrEz_OXZGrnh for ; Fri, 29 Aug 2014 02:11:46 -0700 (PDT) Received: from nekare.kjorling.se (nekare.kjorling.se [89.221.249.175]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C13921A06DF for ; Fri, 29 Aug 2014 02:11:45 -0700 (PDT) Received: by nekare.kjorling.se (Postfix, from userid 1001) id 012B6114075; Fri, 29 Aug 2014 09:11:42 +0000 (UTC) X-Spam-Details: BAYES_00=-1.9, SPF_FAIL=0.001 (nekare.kjorling.se) Received: from yeono.kjorling.se (h-9-65.a328.priv.bahnhof.se [46.59.9.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "yeono", Issuer "yeono" (not verified)) by nekare.kjorling.se (Postfix) with ESMTPS id E79F2114073 for ; Fri, 29 Aug 2014 09:11:34 +0000 (UTC) Received: from yeono.kjorling.se (localhost [127.0.0.1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by yeono (Postfix) with ESMTPS id 765A2140031 for ; Fri, 29 Aug 2014 11:11:34 +0200 (CEST) Date: Fri, 29 Aug 2014 09:11:33 +0000 From: Michael =?utf-8?B?S2rDtnJsaW5n?= To: endymail@ietf.org Message-ID: <20140829091133.GA25723@yeono.kjorling.se> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/mSmLHfs0kzZNE9LaYdBDjHtN8ok Subject: Re: [Endymail] Hashes of key as addresses X-BeenThere: endymail@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 09:11:51 -0000 On 28 Aug 2014 19:23 -0400, from phill@hallambaker.com (Phillip Hallam-Baker): > Using hashes of keys as addresses is very powerful. There are > basically three types of address in such schemes: > > 1) traditional human readable > > 2) hash of key > > 3) Traditional human readable + hash of key. > > > So in PPE we use all three in different situations: > > 1) ACAIEA-FONPAC-5AC6LFA-K4ACHC-EAJWAHN-VPAM4A-COYPAO-VAA > > 2) alice@example.com > > 3) ACAIEA-FONPAC-5AC6LFA-K4ACHC-EAJWAHN-VPAM4A-COYPAO-VAA?alice@example.com > > > We can apply the same approach with value to other situations. Lets > say Alice owns example.com. We can create a strong domain name in the > same way: > > ACAIEA-FONPAC-5AC6LFA-K4ACHC-EAJWAHN-VPAM4A-COYPAO-VAA?example.com Does this scheme not imply that everyone who wants to validate an address, or know to where to pass a message given an address, needs to either (a) query some form of central repository where all address (hash)es are registered, or (b) have a local cache of all valid address (hash)es? Whether architectured in a distributed or centralized fashion, would such a registry not become problematic? Lookups would be comparatively costly (since even though it would be possible to split the storage, you'd still be looking at what basically amounts to a sequential search through some, likely relatively large, amount of data), if this catches on it would soon grow very large, and imagine what spammers would do if they could get their hands on a copy of that database. Someone who is in control of such a database would have the potential for massive (though not necessarily total) insight into who is communicating with whom. We know that breaches happen, even with the best of intentions (even the NSA can't keep their data safe from breaches, as evidenced), so it would appear that an architecture that creates such a valuable target should be discouraged. Initial mapping from a human-friendly (no matter what format) to a hash (no matter what format) address would also seem to present the problem of ensuring that you are mapping the correct human-friendly address. You could, given an appropriate design, after that point be certain that you are communicating with the _same_ person that you started out communicating with, but could you be certain that you are communicating with the _intended_ person (as opposed to someone else by mistake, and as opposed to a MITMer)? If the human-friendly address is enough to uniquely identify the recipient, then why would we need a hash-based address scheme at all? If it isn't, then how is Joe R. User, who wants to send a message securely to Alice Journalist, expected to pick between "Alice Journalist, ACAIEA FONPAC 5AC6LFA K4ACHC EAJWAHN VPAM4A COYPAO VAA" and "Alice Journalist, GJEIWO FMCPTE 9NM2GME X0AZZE XMDLWLF LLCP2K UHXHYM LHE", let alone between the first and "Alice Journalist, ACAIEA F0NPAC 5AC6LFA K4ACHC EAJWAHN VPAM4A COYPAO VAA"? Compare SMTP where the originating SMTP server can do preliminary validation (on the order of ensuring that the address is well-formed, the domain exists and has a MX or address record) while the receiving SMTP server does final address validation (local-part/hostname pair exists and points to a valid mailbox) in an interactive dialog between the servers, allowing reasonably good error reporting back to the originating sender without any one entity having a complete address registry. Since DNS is also highly distributed, no one entity even has a complete list of all valid domain or fully qualified host names. -- Michael Kjörling • https://michael.kjorling.se • michael@kjorling.se OpenPGP B501AC6429EF4514 https://michael.kjorling.se/public-keys/pgp “People who think they know everything really annoy those of us who know we don’t.” (Bjarne Stroustrup) From nobody Fri Aug 29 06:37:28 2014 Return-Path: X-Original-To: endymail@ietfa.amsl.com Delivered-To: endymail@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C04881A035F for ; Fri, 29 Aug 2014 06:37:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.121 X-Spam-Level: ** X-Spam-Status: No, score=2.121 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_41=0.6, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ki6U7i17sQUM for ; Fri, 29 Aug 2014 06:37:25 -0700 (PDT) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B53861A035D for ; Fri, 29 Aug 2014 06:37:24 -0700 (PDT) Received: by mail-la0-f51.google.com with SMTP id gl10so2722055lab.10 for ; Fri, 29 Aug 2014 06:37:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=J9e2+NgL1wmbOmIMIXCme+6q+dK9i+nBWQV2b9h1r2w=; b=yGQYCUTSNnS/9WT6gIPl4EMJ9O38aean85xmOs96TC/x1Fwr+cxZdvrf7iqH27ji0X eVPbsE+X0lXmh75mtvge589+hP0df59RIA7br6Xw9kTK5foCAQ3ykt0KLytLdudXVzk3 V1ESy3wRVget3/y+ELA0Ge3l6GRk2swSCe4moIiZ/PwHBGWoIaSMtCcgGP9CMEDpsle7 p5Alfd5UN78O8UsgX0CbdLlMoxACs+DrLw27G0RNbhmKFAdNu/XOk2mlQ+Abi02UhwXx a1tfdqNAMV8+/MFXMEmVl6KI93OR7NYNhofbface7L7AFylZzd5xjuAsqg4Yti097feZ gTbQ== MIME-Version: 1.0 X-Received: by 10.152.20.168 with SMTP id o8mr11587323lae.4.1409319442951; Fri, 29 Aug 2014 06:37:22 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.122.50 with HTTP; Fri, 29 Aug 2014 06:37:22 -0700 (PDT) In-Reply-To: <20140829091133.GA25723@yeono.kjorling.se> References: <20140829091133.GA25723@yeono.kjorling.se> Date: Fri, 29 Aug 2014 09:37:22 -0400 X-Google-Sender-Auth: 2knQookpNi4fo9Lmo7_SDVUJp4A Message-ID: From: Phillip Hallam-Baker To: =?UTF-8?Q?Michael_Kj=C3=B6rling?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/2XTLsDwKF28yn9eqkyKEbKlnC2Y Cc: endymail Subject: Re: [Endymail] Hashes of key as addresses X-BeenThere: endymail@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 13:37:26 -0000 On Fri, Aug 29, 2014 at 5:11 AM, Michael Kj=C3=B6rling wrote: > On 28 Aug 2014 19:23 -0400, from phill@hallambaker.com (Phillip Hallam-Ba= ker): >> Using hashes of keys as addresses is very powerful. There are >> basically three types of address in such schemes: >> >> 1) traditional human readable >> >> 2) hash of key >> >> 3) Traditional human readable + hash of key. >> >> >> So in PPE we use all three in different situations: >> >> 1) ACAIEA-FONPAC-5AC6LFA-K4ACHC-EAJWAHN-VPAM4A-COYPAO-VAA >> >> 2) alice@example.com >> >> 3) ACAIEA-FONPAC-5AC6LFA-K4ACHC-EAJWAHN-VPAM4A-COYPAO-VAA?alice@example.= com >> >> >> We can apply the same approach with value to other situations. Lets >> say Alice owns example.com. We can create a strong domain name in the >> same way: >> >> ACAIEA-FONPAC-5AC6LFA-K4ACHC-EAJWAHN-VPAM4A-COYPAO-VAA?example.com > > Does this scheme not imply that everyone who wants to validate an > address, or know to where to pass a message given an address, needs to > either (a) query some form of central repository where all address > (hash)es are registered, or (b) have a local cache of all valid > address (hash)es? No, it implies some mechanism for resolving the hashes. But that does not need to be centralized. Right now what the PPE proxy does is to strip out the domain component of the email address and performs a HTTP WKS query for the phingerprint block. So it would look up http://example.com/.well-known/phb/ACAIEAFONPAC5AC6LFAK4ACHCEAJWAHNVPAM4ACO= YPAOVAA The dashes are removed as they have no semantic information. They are purely for convenience. > Whether architectured in a distributed or centralized fashion, would > such a registry not become problematic? Lookups would be comparatively > costly (since even though it would be possible to split the storage, > you'd still be looking at what basically amounts to a sequential > search through some, likely relatively large, amount of data), if this > catches on it would soon grow very large, and imagine what spammers > would do if they could get their hands on a copy of that database. > Someone who is in control of such a database would have the potential > for massive (though not necessarily total) insight into who is > communicating with whom. No, the system is no worse than DNS and that scales. No sequential searches, its a hash table lookup and so extremely fast. Should not require more than 6 lookups. Each person's PHB is only a few KB so we are talking about 10 Tb or so of data if everyone has a key. That is very manageable. It would need a business model of course but so does every scheme that proposes infrastructure. > We know that breaches happen, even with the best of intentions (even > the NSA can't keep their data safe from breaches, as evidenced), so it > would appear that an architecture that creates such a valuable target > should be discouraged. \The infrastructure is not trusted except for service. An attacker cannot substitute an end-entity key because the key has to be signed by the master key that matches the hash. > Initial mapping from a human-friendly (no matter what format) to a > hash (no matter what format) address would also seem to present the > problem of ensuring that you are mapping the correct human-friendly > address. You could, given an appropriate design, after that point be > certain that you are communicating with the _same_ person that you > started out communicating with, but could you be certain that you are > communicating with the _intended_ person (as opposed to someone else > by mistake, and as opposed to a MITMer)? If the human-friendly address > is enough to uniquely identify the recipient, then why would we need a > hash-based address scheme at all? If it isn't, then how is Joe R. > User, who wants to send a message securely to Alice Journalist, > expected to pick between "Alice Journalist, ACAIEA FONPAC 5AC6LFA > K4ACHC EAJWAHN VPAM4A COYPAO VAA" and "Alice Journalist, GJEIWO FMCPTE > 9NM2GME X0AZZE XMDLWLF LLCP2K UHXHYM LHE", let alone between the first > and "Alice Journalist, ACAIEA F0NPAC 5AC6LFA K4ACHC EAJWAHN VPAM4A > COYPAO VAA"? That is the trust problem and there are various ways to address it. The first step though is to have a set of addresses that can be used to specify the trust relationship explicitly. Once we have that the trust problem is reduced to achieving the mapping. One way that works very well is to use QR codes in an in-person meeting. Web of Trust never worked the way PhilZ wanted. But we didn't carry supercomputers with cameras (aka smartphones) then. > Compare SMTP where the originating SMTP server can do preliminary > validation (on the order of ensuring that the address is well-formed, > the domain exists and has a MX or address record) while the receiving > SMTP server does final address validation (local-part/hostname pair > exists and points to a valid mailbox) in an interactive dialog between > the servers, allowing reasonably good error reporting back to the > originating sender without any one entity having a complete address > registry. Since DNS is also highly distributed, no one entity even has > a complete list of all valid domain or fully qualified host names. Well what you are doing is proposing the simplest solution to the problem and showing why it is inadequate. There does not need to be a central repository. There does not even need to be global connectivity. From nobody Fri Aug 29 08:22:11 2014 Return-Path: X-Original-To: endymail@ietfa.amsl.com Delivered-To: endymail@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1FF21A0503 for ; Fri, 29 Aug 2014 08:22:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.422 X-Spam-Level: * X-Spam-Status: No, score=1.422 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SPO_gyOioZEi for ; Fri, 29 Aug 2014 08:22:03 -0700 (PDT) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DCF81A04FA for ; Fri, 29 Aug 2014 08:22:03 -0700 (PDT) Received: by mail-la0-f46.google.com with SMTP id pv20so2874852lab.5 for ; Fri, 29 Aug 2014 08:22:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=xOIl8/8txGCZu4DvARFqhEKsLfAHi1/FIB065kFPjoA=; b=Z6RjzgEnG0exJHM8RmpRepIcUfhwTvg4I9qNzRb6IxpJjZ1gOgmRKqY82zZ+RwA9NY 4T9/uvVF8L3kcUnnMHsw52pcZjTM4Hg+KDdHHMMyf7RrdQ4ka4D6dpkeU0c6q+GICVJi w3wWGCABuY0rtsLv+B4Kc+devEwIzo8L/F9xmMyQpmqQMnNGJAb44RSFZ0Sc2YCDVTyX dmND9JRh3V3bcNR7vIgU8uVndnRSoB7OZwEsFdZEU+VVWT50VYqOqZuSiyQjN1K0FkZW KdBnxRekpmD0oD2R4jx0E3E1pvfDjEb4MnfnCC77Tq4mqFcAjamtI6nU7sqkIeSni+va 4m5A== MIME-Version: 1.0 X-Received: by 10.153.4.39 with SMTP id cb7mr11804761lad.19.1409325721794; Fri, 29 Aug 2014 08:22:01 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.122.50 with HTTP; Fri, 29 Aug 2014 08:22:01 -0700 (PDT) Date: Fri, 29 Aug 2014 11:22:01 -0400 X-Google-Sender-Auth: m0NaE6J0LWD4StJvYk1muZAeAgg Message-ID: From: Phillip Hallam-Baker To: endymail Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/5K_WniqSvjmLiVAtbOBrwzEVvJc Subject: [Endymail] Concealing the email address of the subscriber. X-BeenThere: endymail@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 15:22:04 -0000 Problem: Allow an email sender who knows an email address to locate a record giving key information without disclosing address to an attacker. To simplify the argument we are only considering this part of the puzzle here and hypothesizing that there is a separate infrastructure whose sole purpose is matching email addresses to records. Obviously if we are using CT with this then any information that goes into this infrastructure has to be validated in CT but that can be via a hash of the data which is non-disclosing. Approach 1: Let email address be a=C3=A7 Locator is H( "alice@example.com" ) Service maps Locator to record. Strength: Simple Weakness: Attacker can derive the email address by brute force. Approach 2: We have two locators each of which contain only part of the email address. Locator1 is H( "lice@example.com" ) Locator2 is H( "alic@example.com" ) Each locator is presented to a service which returns a set of opaque locators V1, V2. There is a possibility of collisions here. Final locator is the XOR of V1, V2... Nah, combinatorics would be horrendous. Approach 3: Anyone got something better that does not allow the brute force attack - other than simply increasing the linear work factor for the attacker? From nobody Fri Aug 29 08:50:34 2014 Return-Path: X-Original-To: endymail@ietfa.amsl.com Delivered-To: endymail@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A3A51A0503 for ; Fri, 29 Aug 2014 08:50:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5lidxZV3lCCR for ; Fri, 29 Aug 2014 08:50:31 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECF7A1A048E for ; Fri, 29 Aug 2014 08:50:29 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id e4so2766048wiv.8 for ; Fri, 29 Aug 2014 08:50:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ya3xihe9nTmwc5KelpxF+VL75WsVYolfRsi+ScWgntg=; b=ZmBcLFTG7lewsBIZmypUOdGSEXTg6QUQJuuTh4bpl6L+HYRYkkSMEUhBjzjMcJ6qe4 odXbvvFHSSPed4qposhW/5El+nvJ8Ku1JtWsCbpetWS7AaA7qoJiVub8sRYPhlpv0HWW ZRe/mmI4rz9/ScqRbMbw9A4C23x1+KXOz6BzKp35yLcujarfhkOg2EI95AktjSKxWHcZ WUhKbOpKQo3vLSy70ABKri4hxPJMNvmLJNHHHN5H2c2doIimks5VW0SR3n2pozvvonRa dXoaeWX8ddvjkNPKTaFYUZxCNCwdL2FzJvPu0EZQOk6EoaSZdkE1kkTSJpL7kCGYjRgJ pnYA== MIME-Version: 1.0 X-Received: by 10.194.123.1 with SMTP id lw1mr14644962wjb.4.1409327428530; Fri, 29 Aug 2014 08:50:28 -0700 (PDT) Received: by 10.194.23.39 with HTTP; Fri, 29 Aug 2014 08:50:28 -0700 (PDT) Received: by 10.194.23.39 with HTTP; Fri, 29 Aug 2014 08:50:28 -0700 (PDT) In-Reply-To: References: Date: Fri, 29 Aug 2014 17:50:28 +0200 Message-ID: From: Natanael To: Phillip Hallam-Baker Content-Type: multipart/alternative; boundary=089e0122860abffa620501c69c9b Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/dRB-7JpyLOM38WiU_UErWNH2GCc Cc: endymail Subject: Re: [Endymail] Concealing the email address of the subscriber. X-BeenThere: endymail@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 15:50:32 -0000 --089e0122860abffa620501c69c9b Content-Type: text/plain; charset=UTF-8 Den 29 aug 2014 17:22 skrev "Phillip Hallam-Baker" : > > Problem: Allow an email sender who knows an email address to locate a > record giving key information without disclosing address to an > attacker. > > To simplify the argument we are only considering this part of the > puzzle here and hypothesizing that there is a separate infrastructure > whose sole purpose is matching email addresses to records. > > Obviously if we are using CT with this then any information that goes > into this infrastructure has to be validated in CT but that can be via > a hash of the data which is non-disclosing. Bitcoin SPV clients which need servers / trusted nodes for blockchain lookups to verify the balance at its own addresses are using bloom filters for privacy (intentionally high false positive rate). Isn't all too costly in most cases. --089e0122860abffa620501c69c9b Content-Type: text/html; charset=UTF-8


Den 29 aug 2014 17:22 skrev "Phillip Hallam-Baker" <phill@hallambaker.com>:
>
> Problem: Allow an email sender who knows an email address to locate a
> record giving key information without disclosing address to an
> attacker.
>
> To simplify the argument we are only considering this part of the
> puzzle here and hypothesizing that there is a separate infrastructure
> whose sole purpose is matching email addresses to records.
>
> Obviously if we are using CT with this then any information that goes
> into this infrastructure has to be validated in CT but that can be via
> a hash of the data which is non-disclosing.

Bitcoin SPV clients which need servers / trusted nodes for blockchain lookups to verify the balance at its own addresses are using bloom filters for privacy (intentionally high false positive rate). Isn't all too costly in most cases.

--089e0122860abffa620501c69c9b--