From nobody Mon Sep 1 03:16:49 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 C29B71A031F for ; Mon, 1 Sep 2014 03:16:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-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 Gr6V8MNcZZXi for ; Mon, 1 Sep 2014 03:16:44 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A965A1A0282 for ; Mon, 1 Sep 2014 03:16:44 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1XOOfC-0002gj-Ho for ; Mon, 01 Sep 2014 12:16:42 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.82 #3 (Debian)) id 1XOOZw-0004Pq-8a; Mon, 01 Sep 2014 12:11:16 +0200 From: Werner Koch To: Phillip Hallam-Baker References: <53FD0B7D.8070705@qti.qualcomm.com> <9ECDC905D01276A63A779E35@caldav.corp.apple.com> Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: id=1E42B367; url=finger:wk@g10code.com Date: Mon, 01 Sep 2014 12:11:15 +0200 In-Reply-To: (Phillip Hallam-Baker's message of "Thu, 28 Aug 2014 17:44:09 -0400") Message-ID: <87d2bfps58.fsf@vigenere.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/n5EtDoHi7O5PCf0vB4q16G8aFLk Cc: Cyrus Daboo , 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: Mon, 01 Sep 2014 10:16:46 -0000 On Thu, 28 Aug 2014 23:44, phill@hallambaker.com said: > * Easy way to migrate encryption keys into new devices. > > * Key recovery mechanisms so people don't loose their mail by accident. These are closely related. It is commonly known as backup/restore. Fortunately we only need to care about the secret key which means we need to backup 32 bytes plus an identification of 20 or 32 bytes for the public key. This can easily be achieved using a QR code. Print it out and for restore take a photo of it. Right, this opens new paths for local attacks on the secret key but if an attacker already has control over the local device, we are anyway in game over state. And it would be a good start to make that easier. The current protocols do not allow for an abbreviated backup scheme of the secret key but it won't not be too complicated to do that. As long as we can assume that the public key is really public. Data protection rules may be a problem here. > * Easy key rollover In case of key compromise or for forward security? The latter is more problematic because you need to take the key offline but if you still want to decrypt old messages (may be just 1 week, 1 month old) there needs to be an easy way to restore them. > be solved. But what has happened in the past is that they have been > shuffled under the mat as 'advanced user problems'. Yeah. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Mon Sep 1 03:26:46 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 2B7BA1A0337 for ; Mon, 1 Sep 2014 03:26:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.001 X-Spam-Level: X-Spam-Status: No, score=-5.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_HI=-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 7lL9hGeEg7Ka for ; Mon, 1 Sep 2014 03:26:43 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82D5A1A0336 for ; Mon, 1 Sep 2014 03:26:43 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1XOOos-0002jg-0d for ; Mon, 01 Sep 2014 12:26:42 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.82 #3 (Debian)) id 1XOOn2-0004S5-1H; Mon, 01 Sep 2014 12:24:48 +0200 From: Werner Koch To: Tim Bray References: Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: id=1E42B367; url=finger:wk@g10code.com Date: Mon, 01 Sep 2014 12:24:47 +0200 In-Reply-To: (Tim Bray's message of "Wed, 27 Aug 2014 09:21:56 -0700") Message-ID: <878um3prio.fsf@vigenere.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/Iz5qPNGb2cbyiE1iqJUV9ercVRo Cc: endymail@ietf.org Subject: Re: [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: Mon, 01 Sep 2014 10:26:45 -0000 On Wed, 27 Aug 2014 18:21, tbray@textuality.com said: > This is a big problem. The PGP Web of Trust has failed, and we=E2=80=99ve= all heard It did not fail; it is just as inconvenient as paying a CA for a questionable service. Any extra inconveniences are not good for mass use of encrypted mails. > 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= notion of a key They requires that you are always online and thus the service provides my track even signature verifications. Without an anonymity guaranteeing infrastructure this may only be an intermediate solution. > 5. Display the message appropriately, depending what it is > This is a problem. Lots of the messages I want to send are movies or son= gs > or pictures, and if there=E2=80=99s no way to communicate the Media Type,= it=E2=80=99s less > useful to the recipient. You mean for the encrypted data or for the cleartext? OpenPGP has a feature to convey the media type - not much options right now but it is easy to extend. Or use the standard way and encrypted the MIME container. Shalom-Salam, Werner p.s. BTW, a few years ago we came up with the http://g10code.com/steed.html proposal. Unfortunately it didn't worked out because the mail providers had zero interest in supporting even a prototype. --=20 Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Mon Sep 1 03:48: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 44B4E1A0367 for ; Mon, 1 Sep 2014 03:48:51 -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 4NegxaDJi_Lg for ; Mon, 1 Sep 2014 03:48:50 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85F2A1A0361 for ; Mon, 1 Sep 2014 03:48:49 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 5E3D5FA000A; Mon, 1 Sep 2014 10:48:46 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1409568525-20915-20914/12/24; Mon, 1 Sep 2014 10:48:45 +0000 From: Arnt Gulbrandsen To: endymail@ietf.org Date: Mon, 1 Sep 2014 12:48:45 +0200 User-Agent: Trojita/v0.4.1-243-g4a74770; Qt/4.8.4; X11; Linux; Ubuntu 13.10 Mime-Version: 1.0 Message-Id: In-Reply-To: <878um3prio.fsf@vigenere.g10code.de> References: <878um3prio.fsf@vigenere.g10code.de> Content-Type: text/plain; charset=utf-8; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/lOGcOHkFXHP3IchDxL6LFUii7MM Subject: Re: [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: Mon, 01 Sep 2014 10:48:52 -0000 The web of trust hasn't failed? The number of people with email addresses has grown to perhaps a quarter of humanity. Meanwhile, the number of people who use PGP seems to have been more or less stable for the past 15 years (I'd love to see better numbers on that, but who might be in a position to collect that?). What's the threshold for success then? Arnt From nobody Mon Sep 1 09:32:51 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 711821A035E for ; Mon, 1 Sep 2014 09:32:49 -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 n6p2ImTn0Jrn for ; Mon, 1 Sep 2014 09:32:45 -0700 (PDT) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA7DF1A0326 for ; Mon, 1 Sep 2014 09:32:44 -0700 (PDT) Received: by mail-la0-f52.google.com with SMTP id ty20so6330614lab.39 for ; Mon, 01 Sep 2014 09:32:43 -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=2cZ6KbQGR0sfOxxvFHpkFWRPlUv3p+obdmsfWI2nDhs=; b=Q4gQXM2kMUA156Zi7cD8oxgNQw8rINHyXFzpjUWfY8/k69MI4VjF+Y/AMW5sW4aEHB uteNJWPglPCGCqN+vAYl+7Zk6R27EtVQSDfWDVQAn8nZTUw5UAjNDuxeDKpb9yUhCeI4 KItcgUqAf4NzBhi3iV+FCC83DIL0V+3nVpwe2t+zhcK5pztlSzNpjHWYXnCZy/H8cqV3 estrmCyVzMd3KZiznOGRWE9JKgam9W70z+qwLsRzxdUGGBVk/tYpYgxyDIKjQ2c1Z8zd xwOwQo4mReRQ16HTtr+nsHpcghpOHZf9/ala7lg5htBuo+we8YthWlVTXN8oVcP5tgAq rsCA== MIME-Version: 1.0 X-Received: by 10.153.4.39 with SMTP id cb7mr29603920lad.19.1409589163206; Mon, 01 Sep 2014 09:32:43 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.122.50 with HTTP; Mon, 1 Sep 2014 09:32:43 -0700 (PDT) In-Reply-To: References: <878um3prio.fsf@vigenere.g10code.de> Date: Mon, 1 Sep 2014 12:32:43 -0400 X-Google-Sender-Auth: ndeEIrmGw-6_fXhS2Q9bEoVOOIo Message-ID: From: Phillip Hallam-Baker To: Arnt Gulbrandsen Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/otOExOs9R1c2VqcglhaaFGM8rP4 Cc: endymail Subject: Re: [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: Mon, 01 Sep 2014 16:32:50 -0000 On Mon, Sep 1, 2014 at 6:48 AM, Arnt Gulbrandsen wrote: > The web of trust hasn't failed? > > The number of people with email addresses has grown to perhaps a quarter of > humanity. Meanwhile, the number of people who use PGP seems to have been > more or less stable for the past 15 years (I'd love to see better numbers on > that, but who might be in a position to collect that?). What's the threshold > for success then? One of the main reasons PGP failed is that people wanted it to succeed so desperately. So nobody would speak up about the problems. As if wishful thinking alone would solve everything. Robert Owen, the father of the factory system set up a socialist utopian commune in the US which was the first of its kind. It failed in the exact same ways that numerous later attempts also failed. Because people didn't want to question the ideology and acknowledge the problems which is the first step to solving them. Other communes did look at the problems and did not fail in the same ways. No one trust model is going to fit every need. Which is why the trust model mechanics should be separated out from the client for the time being. One very powerful tool for addressing the problem is that we distinguish the first contact use case from the continued contact use case. Alice is sending a message to Bob, she has never met Bob in person, she has only got his email address from a Web site. But it is Bob she wants to talk to and this might not be bob@example.com. So in this situation I don't think she is going to be immediately sending Bob really confidential secrets. I think it is going to be perfectly adequate to use key distribution mechanisms such as key servers and the like for establishing this connection. Securing further conversation is quite a bit easier. We can exchange a fingerprint in band and make Alice enter it manually or we can use strong email addresses which are just a bit of syntactic sugar (aka usability) thrown on top. We can even send the contact information inband in email headers: To: From: Reply-To: Encrypt-To: Hi Bob, wanna talk to me? Unlike PEM headers, we are not sending several Kb of extra data per message. We are only sending the information required to locate the cert chain and validate it. We are not sending unnecessary data. From nobody Mon Sep 1 09:49:45 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 00F141A0366 for ; Mon, 1 Sep 2014 09:49:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.168 X-Spam-Level: X-Spam-Status: No, score=-15.168 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 1pC8cizxtg5Z for ; Mon, 1 Sep 2014 09:49:42 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A28A31A02FF for ; Mon, 1 Sep 2014 09:49:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5870; q=dns/txt; s=iport; t=1409590181; x=1410799781; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=zqvIKKGnTj6PwItWh5fh0m/28xHZFIFAD9+zACqaGCE=; b=GQhHtMIuGq/DOFYtbKCepBaC31hreRyvXc31hRj8w0ym3K4PfDIk24Am iud6lXzADRNod7iPx/OQkBGfR80eGABWB+6qTk9hUxjYMWNAtCChgFEsn Wda/mdVEhsw/IwY53e4fQqG1ObEbvVfHwf4X91h5yMy3cIiaG0iBBx7QP I=; X-Files: signature.asc : 486 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlwGAFWjBFStJssW/2dsb2JhbABZg2BXgnzFA4dNBAIBgSx3hAQBAQQjVRELBAoKCRYLAgIJAwIBAgFFBgEMCAEBiD4NpH2UWgETBI5rEQFXgnmBUwEEkzeBSl6GfYc3jWeDYzsvgQ+BQAEBAQ X-IronPort-AV: E=Sophos;i="5.04,443,1406592000"; d="asc'?scan'208,217";a="161418374" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 01 Sep 2014 16:49:31 +0000 Received: from [10.61.212.165] ([10.61.212.165]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s81GnVo6008702; Mon, 1 Sep 2014 16:49:31 GMT Message-ID: <5404A3A3.9050506@cisco.com> Date: Mon, 01 Sep 2014 18:49:39 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Tim Bray , endymail@ietf.org References: In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ovCeTA65R2vAuwHjR2Ib4UgPOrvCQuVtA" Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/MwQCikuiJqiL4harlyDLMSryf0Q Subject: Re: [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: Mon, 01 Sep 2014 16:49:44 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ovCeTA65R2vAuwHjR2Ib4UgPOrvCQuVtA Content-Type: multipart/alternative; boundary="------------020706050606030900090303" This is a multi-part message in MIME format. --------------020706050606030900090303 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Tim, You've written in narrative a great table of tasks. But... On 8/27/14, 6:21 PM, Tim Bray wrote: > > 1. Find a public key for the user that the sender=E2=80=99s prepared to= trust. > > This is a big problem. The PGP Web of Trust has failed, and we=E2=80=99= ve all > heard the griping about the CA biz. Joe Hildebrand mentioned POSH & > WebFinger and they=E2=80=99re both interesting. I=E2=80=99m also inter= ested in the > notion 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? If the IETF could solve but this problem such that it scales to the size of the Internet, everything else on your list would I think fall into place. Unfortunately, key management really wasn't on your list, and that has to be addressed as well. Also, I suspect that email programs probably need to evolve a bit to cope with all of this. Case and point: I'm pretty sure I've lot one or two private keys along the way. And, at least compared to your average Joe, I'm good at this. BTW, it all has to happen without asking for matching keys. Enigmail does a pretty good job of that already. That's a pretty good model for UI (I hazard a guess), and so stay focused on how to get it to function to scale. It may make sense to use some form of OTR for end-to-end transit. But again I wouldn't want to count on OTR for data at rest. Eliot --------------020706050606030900090303 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Tim,

You've written in narrative a great table of tasks.=C2=A0 But...

On 8/27/14, 6:21 PM, Tim Bray wrote:

1. Find a public key for the user that the sender=E2=80=99s p= repared to trust.

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 mentioned POSH & WebFing= er and they=E2=80=99re both interesting. =C2=A0I=E2=80=99m also = interested in the notion of a key directory with associated proofs that you don=E2=80=99t have to trust, for example the one from https://keybase.io. =C2=A0In particul= ar see=C2=A0https://keybase.io/docs/server_security
WORK FOR IETF: Get pro-active on key discovery/trust work? Standardize key search APIs?

If the IETF could solve but this problem such that it scales to the size of the Internet, everything else on your list would I think fall into place.=C2=A0 Unfortunately, key management really wasn't on= your list, and that has to be addressed as well.=C2=A0 Also, I suspec= t that email programs probably need to evolve a bit to cope with all of this.=C2=A0 Case and point: I'm pretty sure I've lot one or two private keys along the way.=C2=A0 And, at least compared to your aver= age Joe, I'm good at this.

BTW, it all has to happen without asking for matching keys.=C2=A0 Enigmail does a pretty good job of that already.=C2=A0 That's a prett= y good model for UI (I hazard a guess), and so stay focused on how to get it to function to scale.=C2=A0 It may make sense to use some form= of OTR for end-to-end transit.=C2=A0 But again I wouldn't want to count = on OTR for data at rest.

Eliot
--------------020706050606030900090303-- --ovCeTA65R2vAuwHjR2Ib4UgPOrvCQuVtA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQEcBAEBAgAGBQJUBKOjAAoJEIe2a0bZ0nozlB8H/1zSL08WbUxtvGcsZwyMZmuE FDdFn9B2qeGP1oyiypj6Inxa+mNmnUySkniX7A86kdFvvrS7OV8kmRdAfj1oA/sL qynlOOHZvpNCGbSkUualMtnwymBv7Gt/aTkt+MxgdlnbRZ4g18+NJbVcbkX2GgAN LX5m2vqHMFYCCKuy6aOdnDJkNS/geumMva1np5TA4jSkFN5S4TEq1ldt81CUdX5N u9eYb5iO/I9wP6GXOhe86NyDE7AUON9MZ20+QoW0wXPpTXPRNEr9YtIHvfQVfUd9 jWpGPyy+cqsak1/C99qKqC8lx4Iebv/JYGnkeuqJPUeBhHVPhe8rcp8f76IqvhI= =ntLz -----END PGP SIGNATURE----- --ovCeTA65R2vAuwHjR2Ib4UgPOrvCQuVtA-- From nobody Mon Sep 1 10:16: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 3F2391A03DE for ; Mon, 1 Sep 2014 10:16:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.522 X-Spam-Level: X-Spam-Status: No, score=0.522 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-0.7] 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 FXjaEe97wKed for ; Mon, 1 Sep 2014 10:16:41 -0700 (PDT) Received: from mail-vc0-f171.google.com (mail-vc0-f171.google.com [209.85.220.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 254781A0537 for ; Mon, 1 Sep 2014 10:16:33 -0700 (PDT) Received: by mail-vc0-f171.google.com with SMTP id id10so5803528vcb.30 for ; Mon, 01 Sep 2014 10:16:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=v4a+DeVP62kluVNvEF8kSsDsx3gAwCrGfiSI+o2XdJ4=; b=NfQv+Vij0cTW/MPXHvE5bnkyx3Imw00GETxiaREXYKtKR+28vBEzExPiiOx77mJrQF kmuzTzr0v/sAcARfG/YiRlU/rJxJ4lbk12EAg/GylmXTBOAQ50viYhxaS9UV1Wj4s/80 vLd6UaIMiLwL7QE82ToIVoAn3kXkSspr+D+o/vbTyrZWdKI4CyvLTaIAqqTccym8K/T9 7AjOE3+bGg+GYEQsTY+LleR8yr0wqJ3wxr0d7lLYrXd0RTropeGt1IwFwL4gIsmH3DBp wGFS2qxXgWYs4HC7WWyZi9vfVWleWyZ0KibzZRcUYn9yKNV4q8XLMYZbf8K9y+glecjx MgIg== X-Gm-Message-State: ALoCoQm9D/keMOMHYadNYUgOMFSV0CjDlN/7PoMDjjw2EAjaY3FDb9QLooK14K8nvJlu0pmp9e9j X-Received: by 10.220.202.9 with SMTP id fc9mr1499076vcb.40.1409591792183; Mon, 01 Sep 2014 10:16:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.214.4 with HTTP; Mon, 1 Sep 2014 10:16:12 -0700 (PDT) X-Originating-IP: [24.84.235.32] In-Reply-To: <5404A3A3.9050506@cisco.com> References: <5404A3A3.9050506@cisco.com> From: Tim Bray Date: Mon, 1 Sep 2014 10:16:12 -0700 Message-ID: To: Eliot Lear Content-Type: multipart/alternative; boundary=001a11c1c3e00d40520502042a35 Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/p2UNjuXqREoY7PpN5wrD7viZ434 Cc: endymail@ietf.org Subject: Re: [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: Mon, 01 Sep 2014 17:16:42 -0000 --001a11c1c3e00d40520502042a35 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Sep 1, 2014 at 9:49 AM, Eliot Lear wrote: > 1. Find a public key for the user that the sender=E2=80=99s prepared to t= rust. > ... > > If the IETF could solve but this problem such that it scales to the size of > the Internet, everything else on your list would I think fall into place. =E2=80=8BThese days, I=E2=80=99m all excited about the keybase.io model. S= ince I=E2=80=99ve already held forth=E2=80=8B on this, let me just add that anyone who=E2=80= =99s interested in a closer look, it=E2=80=99s in closed beta but I have loads of invites, = shoot me an email and I=E2=80=99ll ask you in. NOTE: I haven=E2=80=99t developed an opinion yet about the actual keybase.i= o project itself because I don=E2=80=99t fully understand what they=E2=80=99r= e trying to be. But I find the model genuinely exciting. > Unfortunately, key management really wasn't on your list, and that has to be > addressed as well. Good point, I agree 100%. I=E2=80=99m aware of some mobile apps that are t= aking a seriously-good run at solving the UX part of the problem; obviously, that= =E2=80=99s just as hard/important as the crypto and data security and so on. I=E2=80= =99m starting to wonder if maybe hardware-based approaches along the lines of what the FIDO people are working on are the best approach: Your data is key is on your keychain; physically, in your pocket, right beside your house key. Also, I suspect that email programs probably need to > evolve a bit to cope with all of this. Case and point: I'm pretty sure I've > lot one or two private keys along the way. And, at least compared to you= r > average Joe, I'm good at this. > > BTW, it all has to happen without asking for matching keys. Enigmail does a > pretty good job of that already. That's a pretty good model for UI (I > hazard a guess), and so stay focused on how to get it to function to scale. > It may make sense to use some form of OTR for end-to-end transit. But again > I wouldn't want to count on OTR for data at rest. > > Eliot --=20 - Tim Bray (If you=E2=80=99d like to send me a private message, see https://keybase.io/timbray) --001a11c1c3e00d40520502042a35 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Sep 1, 2014 at 9:49 AM, Eliot Lear <lear@cisco.com> wrote:
&= gt; 1. Find a public key for the user that the sender=E2=80=99s prepared to= trust.
>
...
>
> If the IETF could solve but this problem such that it scales to the si= ze of
> the Internet, everything else on your list would I think fall= into place.=C2=A0

=E2=80=8BThese days, I=E2=80=99m all excited about the keybase.io model. =C2=A0Since I=E2=80=99ve = already held forth=E2=80=8B on this, let me just add that anyone who=E2=80= =99s interested in a closer look, it=E2=80=99s in closed beta but I have lo= ads of invites, shoot me an email and I=E2=80=99ll ask you in. =C2=A0=C2=A0=

NOTE: I haven=E2=80=99t develo= ped an opinion yet about the actual keybase.io project itself because I don=E2=80=99t fully unders= tand what they=E2=80=99re trying to be. =C2=A0But I find the model genuinel= y exciting.

> Unfortunately, key management really wasn't on your= list, and that has to be
> addressed as well.=C2=A0
=

= Good point, I agree 100%. =C2=A0I=E2=80=99m aware of some mobile apps that = are taking a seriously-good run at solving the UX part of the problem; obvi= ously, that=E2=80=99s just as hard/important as the crypto and data securit= y and so on. =C2=A0 I=E2=80=99m starting to wonder if maybe hardware-based = approaches along the lines of what the FIDO people are working on are the b= est approach: Your data is key is on your keychain; physically, in your poc= ket, right beside your house key.





=C2=A0= Also, I suspect that email programs probably need to
> evolve a bit t= o cope with all of this. =C2=A0Case and point: I'm pretty sure I've=
> lot one or two private keys along the way. =C2=A0And, at least com= pared to your
> average Joe, I'm good at this.
>
> BTW, it all has to = happen without asking for matching keys. =C2=A0Enigmail does a
> pret= ty good job of that already. =C2=A0That's a pretty good model for UI (I=
> hazard a guess), and so stay focused on how to get it to function = to scale.
> It may make sense to use some form of OTR for end-to-end transit. =C2= =A0But again
> I wouldn't want to count on OTR for data at rest.<= br>>
> Eliot



--
- Tim Bray (If you=E2=80=99d li= ke to send me a private message, see https://keybase.io/timbray)
--001a11c1c3e00d40520502042a35-- From nobody Tue Sep 2 00:56:49 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 52DD51A00B7 for ; Tue, 2 Sep 2014 00:56:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-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 aHyAr-HgH5g3 for ; Tue, 2 Sep 2014 00:56:46 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53FF81A00D9 for ; Tue, 2 Sep 2014 00:56:46 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1XOixI-0003Gi-Ig for ; Tue, 02 Sep 2014 09:56:44 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.82 #3 (Debian)) id 1XOitq-0007ZI-NS; Tue, 02 Sep 2014 09:53:10 +0200 From: Werner Koch To: Arnt Gulbrandsen References: <878um3prio.fsf@vigenere.g10code.de> Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: id=1E42B367; url=finger:wk@g10code.com Date: Tue, 02 Sep 2014 09:53:10 +0200 In-Reply-To: (Arnt Gulbrandsen's message of "Mon, 1 Sep 2014 12:48:45 +0200") Message-ID: <87y4u2laqh.fsf@vigenere.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/l76WEooex7_wKn-82rJ-CAJ2ynY Cc: endymail@ietf.org Subject: Re: [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: Tue, 02 Sep 2014 07:56:48 -0000 On Mon, 1 Sep 2014 12:48, arnt@gulbrandsen.priv.no said: > The web of trust hasn't failed? The WoT is only a part of OpenPGP and actually never specified. Sure, mass-acceptance of encrypted mail failed but not due to the WoT. If you ask OpenPGP users you will notice that most of them entirely ignore the key validity issue and at best use local signature to mark keys valid. Does this help? No, people still complain that encryption looks too complicated and they turn over to the next hottest surveillance service claiming that there they have nothing to hide anyway. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Tue Sep 2 01:11:58 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 2BF381A00F5 for ; Tue, 2 Sep 2014 01:11:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.9 X-Spam-Level: X-Spam-Status: No, score=-8.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_HI=-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 ECgCHyQfvN6o for ; Tue, 2 Sep 2014 01:11:46 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A317A1A797C for ; Tue, 2 Sep 2014 01:11:45 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1XOjBo-0003ZW-3e for ; Tue, 02 Sep 2014 10:11:44 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.82 #3 (Debian)) id 1XOj7l-0007cF-Pm; Tue, 02 Sep 2014 10:07:33 +0200 From: Werner Koch To: Eliot Lear References: <5404A3A3.9050506@cisco.com> Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: id=1E42B367; url=finger:wk@g10code.com Date: Tue, 02 Sep 2014 10:07:33 +0200 In-Reply-To: <5404A3A3.9050506@cisco.com> (Eliot Lear's message of "Mon, 01 Sep 2014 18:49:39 +0200") Message-ID: <87tx4qla2i.fsf@vigenere.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/W9kXDgJBuld7K71YUknYbkXg-ZA Cc: Tim Bray , endymail@ietf.org Subject: Re: [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: Tue, 02 Sep 2014 08:11:53 -0000 On Mon, 1 Sep 2014 18:49, lear@cisco.com said: > BTW, it all has to happen without asking for matching keys. Enigmail > does a pretty good job of that already. That's a pretty good model for > UI (I hazard a guess), and so stay focused on how to get it to function It has been told so often in all kind of media that Enigmail is the best tool to use. I suggested its use myself up until I helped out at a crypto party and figured that the UI is still made for geeks and not for users. For example, one participant assumed that he had decrypted a mail after having entered his passphrase 3 times. Then wondered why there was only this BEGIN PGP MESSAGE and some rubbish. He didn't realized that he entered the wrong passphrase 3 times in a row. The fix would be obvious: Print the "wrong passphrase" in bold and red letters and after the 3 tries show an explanations what happened in the content window. But how can we expect to get things better with only two spare time developers for Enigmail and just me taking care of the backend stuff? Business models around solid encryption have always failed. > to scale. It may make sense to use some form of OTR for end-to-end > transit. But again I wouldn't want to count on OTR for data at rest. I fully agree. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Tue Sep 2 03:42:33 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 9F1111A000F for ; Tue, 2 Sep 2014 03:42:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 uUCYWQ1f2M-D for ; Tue, 2 Sep 2014 03:42:28 -0700 (PDT) Received: from forward7l.mail.yandex.net (forward7l.mail.yandex.net [84.201.143.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E56A71A000E for ; Tue, 2 Sep 2014 03:42:27 -0700 (PDT) Received: from smtp3o.mail.yandex.net (smtp3o.mail.yandex.net [37.140.190.28]) by forward7l.mail.yandex.net (Yandex) with ESMTP id 21348BC1031; Tue, 2 Sep 2014 14:42:23 +0400 (MSK) Received: from smtp3o.mail.yandex.net (localhost [127.0.0.1]) by smtp3o.mail.yandex.net (Yandex) with ESMTP id 82D341E2B8C; Tue, 2 Sep 2014 14:42:22 +0400 (MSK) Received: from unknown (unknown [82.113.106.133]) by smtp3o.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id RVMOqmmLsu-gLWCaxOH; Tue, 2 Sep 2014 14:42:21 +0400 (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (Client certificate not present) X-Yandex-Uniq: 91594e8b-053a-42a1-8a4f-d62089669da7 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.com; s=mail; t=1409654541; bh=mJnFOdXb1ILhHkqmFJMKoEIgxzkD59Ocnmy3xT3mXzw=; h=Date:From:To:Cc:Subject:Message-ID:References:In-Reply-To: User-Agent:MIME-Version:Content-Type:Content-Transfer-Encoding; b=RLcNcqHlRKA5u6P0yegQ8rCxdbcMSheOomL653ckGSTFNOzHqpy5433QznMFD0d0s SG4Vl25SsPuPDYNX7Vu1lACK7VrBPZjhEvrpe6m92J3FxWpURqZjGRS6H5sjWtjj/1 ylq9nFRnZtYiaHsdXB4uoKKC5ts1km/O1M/D3Nfc= Authentication-Results: smtp3o.mail.yandex.net; dkim=pass header.i=@yandex.com Date: Tue, 02 Sep 2014 12:42:17 +0200 From: Steffen Nurpmeso To: endymail@ietf.org Message-ID: <20140902114217.lp_a_yD8%sdaoden@yandex.com> References: <878um3prio.fsf@vigenere.g10code.de> <87y4u2laqh.fsf@vigenere.g10code.de> In-Reply-To: <87y4u2laqh.fsf@vigenere.g10code.de> User-Agent: s-nail v14.7.6-15-gc1887ab MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/OkedzQQpGjjjjhi7TEU5mdv9O3w Cc: Werner Koch , Arnt Gulbrandsen Subject: Re: [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: Tue, 02 Sep 2014 10:42:31 -0000 Werner Koch wrote: |On Mon, 1 Sep 2014 12:48, arnt@gulbrandsen.priv.no said: |> The web of trust hasn't failed? | |The WoT is only a part of OpenPGP and actually never specified. | |Sure, mass-acceptance of encrypted mail failed but not due to the WoT. |If you ask OpenPGP users you will notice that most of them entirely |ignore the key validity issue and at best use local signature to mark |keys valid. Does this help? No, people still complain that encryption |looks too complicated and they turn over to the next hottest If with introduction of the new german passport every receiver had also obtained a set of usable PGP and OpenSSL S/MIME keys and/or certificates -- at best with a small info flyer which would have shown how to import those into the tools of the most widespread operating systems -- the situation would surely be better in Germany. Not that this means that some kind of people won't go with hypes anymore, but i am sure for most people, Germans that is, WoT had to be something from the "ultimate" (or only real) authority, and would then be used just the same way as one uses the passport. Note that this would also cutdown the complexity of key handling, the sheer amount of keys to be managed, which can be kind of frightening if you're unlucky. So unfortunately that didn't happen, and "ca-certificates" does no longer include CACert.org because people are playing games or misusing their anonymity for whatever reason, so where does a normal person get their free S/MIME environment from (the list already has seen those approaches that are not really usable for a normal person). Providers could include a free certificate with each account, which would enable their users to choose security by themselves (on a per-provider basis). A SMTP-server-chain-of-trust can prevent STARTTLS MITM by simply assuming TLS (which didn't become SMTPS via port 465 for reasons that i don't know, yet NetBSD's /etc/services still lists this relationship and my free mail provider offers the service as such). I personally never liked DNSSEC; UDP packet sizes can be enlargened etc., but usage of TCP is in the protocol, and then protected right away via TLS i would have preferred, and ca-certificates are installed wherever i am. Of course my opinion is rude and simple and doesn't deliver. --steffen From nobody Tue Sep 2 09:02:21 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 44F6E1A06EE for ; Tue, 2 Sep 2014 09:02:20 -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 ZIdeQnwlAYyI for ; Tue, 2 Sep 2014 09:02:18 -0700 (PDT) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AEB21A064F for ; Tue, 2 Sep 2014 09:02:18 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id x12so7017573wgg.21 for ; Tue, 02 Sep 2014 09:02:16 -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=gPMSe/mPtKrGxSHdLQIeqDGK1hpdLQ+GWd6+GFQHLeI=; b=D3o5nJvO8ibMtE/Fx8el4JyM9wWLboLpyd6hDIEuMZSHxBpU9CV7B4VUu4TmWoK6TR W23DeTPOmTpRNvSR1ErS4mtPUQ79TVs4Eya5rvAgQxg+eyVc/BrXZXKBLgQM3QeyRN64 QQLtW/lYQ/xHf1leUwY0lhLxvqimoc4+UXprTzaqp88r0N1OSVa47JALHL8Dl4AZVYoH zX8tE+JnukYevry2BIzXbL9blvKhNuIp0xLUxmQHyeY/PwiDXbLC+/N8V9qdP11ChHLm rGyvmJIExdV9XsI2ovOwpMpp+PcgTXxxTXnpZa0/OqtCoU7n484SxXQ6IzKuvnVsGdwe kM4w== X-Gm-Message-State: ALoCoQkdpscZLLg44MJCqxIIIfK85u/NpbLOXfuvQAhfGs3FIBmN2qZcQsLVpXsl6Y8t1JnzyCRH X-Received: by 10.180.149.244 with SMTP id ud20mr29162077wib.55.1409673736674; Tue, 02 Sep 2014 09:02:16 -0700 (PDT) Received: from vegoda.org (v6only.vegoda.org. [2a00:1098:0:86:1000:26:0:1]) by mx.google.com with ESMTPSA id ky3sm10320060wjb.39.2014.09.02.09.02.15 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Tue, 02 Sep 2014 09:02:15 -0700 (PDT) Date: Tue, 2 Sep 2014 17:02:06 +0100 From: Leo Vegoda To: Steffen Nurpmeso Message-ID: <20140902160206.GA7900@vegoda.org> References: <878um3prio.fsf@vigenere.g10code.de> <87y4u2laqh.fsf@vigenere.g10code.de> <20140902114217.lp_a_yD8%sdaoden@yandex.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20140902114217.lp_a_yD8%sdaoden@yandex.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/zBuoiV_AFbX_tdkaMlzG2xhvI-Y Cc: Werner Koch , Arnt Gulbrandsen , endymail@ietf.org Subject: Re: [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: Tue, 02 Sep 2014 16:02:20 -0000 On Tue, Sep 02, 2014 at 12:42:17PM +0200, Steffen Nurpmeso wrote: [...] > If with introduction of the new german passport every receiver had > also obtained a set of usable PGP and OpenSSL S/MIME keys and/or > certificates -- at best with a small info flyer which would have > shown how to import those into the tools of the most widespread > operating systems -- the situation would surely be better in > Germany. I think it is much easier to impersonate someone by e-mail when you have the private key to their identity than when you steal a passport. The picture in the passport means that most men cannot use a stolen woman's passport, and most kids cannot use an older person's passport, and so on. But with the private key to an identity someone can be impersonated over e-mail by almost anyone. For these reasons, I do not think that handing out cryptographic identities would be responsible unless there was a suitable key management framework for people to use and they knew how to use it. [...] > Providers could include a free certificate with each account, > which would enable their users to choose security by themselves > (on a per-provider basis). Do you mean providers of e-mail services? Handing out cryptographic identity certificates or similar to people who do not understand the risks or benefits and do not have a suitable key management framework doesn't seem a great idea to me. I think it makes more sense to start with the fundamentals rather than hoping they'll come along some time after widespread deployment. From nobody Tue Sep 2 09:22: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 54E211A05D3 for ; Tue, 2 Sep 2014 09:22:21 -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 AUcy_RGo3UoP for ; Tue, 2 Sep 2014 09:22:20 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id CB1281A0311 for ; Tue, 2 Sep 2014 09:22:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 21048BF01; Tue, 2 Sep 2014 17:22:19 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4O5RH3023YjD; Tue, 2 Sep 2014 17:22:17 +0100 (IST) Received: from [10.87.48.9] (unknown [86.42.23.36]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B754FBEFF; Tue, 2 Sep 2014 17:22:17 +0100 (IST) Message-ID: <5405EEB8.1060107@cs.tcd.ie> Date: Tue, 02 Sep 2014 17:22:16 +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: Leo Vegoda , Steffen Nurpmeso References: <878um3prio.fsf@vigenere.g10code.de> <87y4u2laqh.fsf@vigenere.g10code.de> <20140902114217.lp_a_yD8%sdaoden@yandex.com> <20140902160206.GA7900@vegoda.org> In-Reply-To: <20140902160206.GA7900@vegoda.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/Qs_drMQ1tg5TaiLJPSwzx8MTvNc Cc: Werner Koch , Arnt Gulbrandsen , endymail@ietf.org Subject: Re: [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: Tue, 02 Sep 2014 16:22:21 -0000 I'm not quite sure I'm reading this correctly, but just in case... On 02/09/14 17:02, Leo Vegoda wrote: > Handing out cryptographic identity certificates or similar to people > who do not understand the risks or benefits and do not have a > suitable key management framework doesn't seem a great idea to me. If this list concludes that an Internet-scale key management framework is required where all key holders are strongly authenticated before they get any functional benefit, then that makes life easy - we have 20+ years of evidence that there's no point in bothering to try construct that;-) Similarly, if the list concludes that users have to understand keys then that's also easy - we know that will never happen and so could also call it a day. Luckily I don't think most folks are making those mistakes but we really shouldn't spend any more time than absolutely needed on discussion that assumes that the Internet only has strongly authenticated keys or only has users who understand cryptographic keys. If someone reading this is not convinced already, please mail me offlist and I'll try set you right, but let's not reinvent X.400 email security here please? (Or PEM, or MOSS, or S/MIME or PGP or STANAG 4406 or the various national or proprietary variations etc.) S. From nobody Tue Sep 2 11:14:15 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 576981A0537 for ; Tue, 2 Sep 2014 11:14:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 dp5PPzgi_YX7 for ; Tue, 2 Sep 2014 11:14:12 -0700 (PDT) Received: from mail-yh0-x230.google.com (mail-yh0-x230.google.com [IPv6:2607:f8b0:4002:c01::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95F401A04BC for ; Tue, 2 Sep 2014 11:14:12 -0700 (PDT) Received: by mail-yh0-f48.google.com with SMTP id b6so4483020yha.35 for ; Tue, 02 Sep 2014 11:14:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adamcaudill.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=Xf8oVzvFmq1PssBU94zoYtko2/euZZAQZLly6FeJg+o=; b=RgrfeXsszX4eMMc95ocyaKPAoqpJPH8ogCLOWqsC/3V7TPyuNaSk0rZEEbcPAGqCtU U4awel+U2RirgLeoJ60FHRwJpB1NiJhsxsjpKrnlF/LNmFWgvGyJ3D7Fjk1bDDB5YZlu f3V3cOL4Y/TW/SU1V8zsUbx8b281xw9qXXMIQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=Xf8oVzvFmq1PssBU94zoYtko2/euZZAQZLly6FeJg+o=; b=AFx3UEBx2WflRSYEc17WWT6/zLSsgIxXt0kfGhhlv23+v6gQ4nb6uSMmFx3i2P/bP1 ndX90zKu80ETHCC3y14XYDYR5pWETWFJlfQSh6QU+aR8N4Ndsp37wCY0KO5HFvGskeZt yx5RUme401Tsuxh0gYHnD0e/GkxJui/IHBNwb53TbbIl6RdkoIZ1F/pNKjYQIqZtLFKs UdOiE6X1d7byRCK4rQ4aicuvGcipRY+3oPQfPzaTZNBtcoejIm85sm3CNSNPdTUTAzCA OEIUZ63Fzz2jdGbXHNFNIaT58hXQiTEIzPcqm+8OhRxBvxzA1m86LP3IHxDT0v4721ak 6vVw== X-Gm-Message-State: ALoCoQmE5ZbF5MfpJEkumyUP1RGQG/jGq1ssjulcXwUvoqanuQsIxYnAIwopk2KX/pN6GCzOEw1a X-Received: by 10.236.148.209 with SMTP id v57mr3506916yhj.140.1409681651708; Tue, 02 Sep 2014 11:14:11 -0700 (PDT) Received: from [10.0.0.4] (c-50-142-69-73.hsd1.tn.comcast.net. [50.142.69.73]) by mx.google.com with ESMTPSA id d32sm672563yhq.29.2014.09.02.11.14.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 02 Sep 2014 11:14:10 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_69F2E095-B7C5-41F6-97A0-2310DDC71227"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Adam Caudill In-Reply-To: <53FD0B7D.8070705@qti.qualcomm.com> Date: Tue, 2 Sep 2014 14:14:08 -0400 Message-Id: References: <53FD0B7D.8070705@qti.qualcomm.com> To: endymail@ietf.org X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/9q5IgDmDKeeYVR-4pwgSZxp6aUU Cc: Pete Resnick 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: Tue, 02 Sep 2014 18:14:14 -0000 --Apple-Mail=_69F2E095-B7C5-41F6-97A0-2310DDC71227 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Aug 26, 2014, at 6:34 PM, Pete Resnick = wrote: > So off we go... What projects are folks working on, and what should = the IETF be doing in this space? >=20 > Cheers, > Pete & Stephen I=92ve been working on a project I call SMIMP[0], it=92s a completely = new design to meet the use cases of email using modern technologies. I = gave a short talk[1] about it at the DEFCON CryptoVillage, slides & = notes are online. It=92s still a work in progress, there are a number of = open issues[2] around items that I=92m not entirely sure what the best = way to handle is (mailing lists are a particularly complex issue). In a nutshell, it=92s an end to end encrypted messaging system, = encrypted via curve25519 / XSalsa20, signing via Ed25519, transported = over HTTPS using a REST-like API. At every step, the goal is to make it = secure, and easy to implement, to minimize the risks of developer = mistakes. It=92s broken up into two major parts, Identity Management, and = Messaging (there are a few details left out for brevity; for all of the = details see [0]): Identity Management: To get the public key for a user, a sender calls an = API that returns the full profile history for the user; when a user = makes a change, it=92s signed and includes the hash of the prior change, = creating a chain from the time the account was created to the most = recent. So if Alice wants to send a message to bob@example.com, she = would ask the server at example.com for Bob=92s profile history, and = validate that everything is signed, and that the chain is intact. Alice = will save both the oldest and newest public keys for future checks = (TOFU). In the future, Alice will ask the server for the most recent = public key for Bob, and if it matches what she has, she will proceed to = send the message, otherwise she will request the full history to see if = it=92s been updated with a new key, or if something malicious is going = on (profile replaced / truncated). Messaging: Alice will connect to the example.com server, and request an = ephemeral public curve25519 key and validate that it was signed by Bob=92s= Ed25519 private key. Alice will then request parameters to perform a = hashcash-like proof of work as an anti-spam measure; this includes a = session specific nonce to prevent the POW from being calculated offline. = Once the POW is calculated, Alice will encrypt the message using the = ephemeral key, including the POW and other values, and send it to the = example.com server. The server will perform validations to make sure = that it=92s signed correctly, the POW is correct, and the message is in = the correct format. Once the message is accepted, the server will store = the message for later access by Bob. The messaging API also includes = basic mailbox management methods. The system supports multiple message types that are handled a bit = differently by the server, such as email, short text (MMS like), and = application specific message types, so new messaging applications (think = WhatsApp or SnapChat) could use this infrastructure, instead of using a = custom system. This is a very short overview of the system, I encourage you to look at = the full specification if you are interested. [0] = https://github.com/smimp/smimp_spec/blob/master/smimp_specification.md [1] = https://adamcaudill.com/2014/08/16/smimp-at-the-defcon-cryptovillage/ [2] https://github.com/smimp/smimp_spec/issues --=20 Adam Caudill adam@adamcaudill.com http://adamcaudill.com/ --Apple-Mail=_69F2E095-B7C5-41F6-97A0-2310DDC71227 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJUBgjwAAoJENMzqGjemG5Muv8P/27aEMNprgWdAdyue7BFj6qR PER5zWsiufG5vDRtiAT7dMlCyVK9mryeqXesq/etxRTvsb5K0He2DS8eXzLGKFTb X+qBxJmJzbLwoqrbwApCH9VvXCOqYSS6Lx5a8bZqaTtXUJfoc+G4Htb0YE6DchGR yoyG9P7LJNQtIQEExcvjv1+d4eefv1vtGA6G+gVhltJoMdrAXupVp3R9+Le756jw UftJaKh75fX7lKJM2lvkE0R2A1MX9FXhycP02cMNkT+bOIMpK/ZorvDAd8OEayFi zQArgjIPjzfxlhSvC11Si24DuCd5icgYIyzqjJLSWBmR6fZTyANOMvASj2vuARuW EoeNBBCCXqkLc1nVKqFXJzfT+tn5oUlE+uIw/WUYR/lgQ/UjKy9J/mhdyuYL7Kht mPAO72dK+eRye5CGcAmJNOiY2J/dBt/YDfgTgVzbPXn+2G0qaWqfsARmlapMTlFy xSF/u0HniYM31uMWdl9p+vdqmW/4gO1aQv1VvuLYjCY2OQw73QnZMJ7wnVHUn39P SEno/Vz9A94pnORmxkXru/vMDGXs9zPiVV6WujQrKJrxkGrRiXc1fdFicoESBFG4 dKa5XAbD+chuNwa5KpuDkcMhmZbjYxrWnrHr2yZVa9Jlu5jrZPJxfuBjVc+5VeB6 jNHwh/TYH6VCy1sTc6Da =Hh70 -----END PGP SIGNATURE----- --Apple-Mail=_69F2E095-B7C5-41F6-97A0-2310DDC71227-- From nobody Tue Sep 2 12:31:59 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 EB2F71A068A for ; Tue, 2 Sep 2014 12:31:57 -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 RN4onjzfIrdX for ; Tue, 2 Sep 2014 12:31:56 -0700 (PDT) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 569B41A0680 for ; Tue, 2 Sep 2014 12:31:56 -0700 (PDT) Received: by mail-la0-f45.google.com with SMTP id pn19so8465589lab.32 for ; Tue, 02 Sep 2014 12:31:54 -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; bh=al5vsxuTKC83k+bp2hGKCVPE2eK98BG74CePBnrZvqw=; b=YAisva/e0EDEtzdls/oD0rjnww0ThXe2H8X4Mf0UOifOzQmtFXQ25q2zWibP7DmN9r FVKwmz0iKnpE41MeigP79injkeUK4qXbP+4cl6/cNs1ljY/+zu9cKTe7sFF72ntqgb8h A9cEUQt/eNMMYbZ7kHjZ3jNaLFeoJJW8AUUne5pbSvmFu8aJAYnTkS9sJ+gitjCii2o6 I7li+8HlAmefENaDVAT5vYz//HCc1IuNgiov4YEduOdD00XQt4ZqNJm/9PiS/ntnp81t UDj7iXWrNJTbYh4e4S12JHsdLCaivJG2xmamCRWWMzoy6vLiaRx0ffoAnmireICKS/2r Hing== MIME-Version: 1.0 X-Received: by 10.152.26.202 with SMTP id n10mr16051404lag.4.1409686314356; Tue, 02 Sep 2014 12:31:54 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.122.50 with HTTP; Tue, 2 Sep 2014 12:31:54 -0700 (PDT) Date: Tue, 2 Sep 2014 15:31:54 -0400 X-Google-Sender-Auth: xbktA76eD9zAPUr0Nk4FhjzX1LA Message-ID: From: Phillip Hallam-Baker To: endymail Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/F3e3E2-b_MWEfq4nlHtDMkd8AXM Subject: [Endymail] Parts of the problem - managing private keys 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, 02 Sep 2014 19:31:58 -0000 Lets drill down on some of the parts of the problem that are not 'trust'. One of the biggest problems for end users is managing private keys. And quite often this problem gets exported back into the 'trust' area by deciding the answer to 'what happens if the user forgets a passphrase' be 'let them reboot their trust network from scratch'. I like the concept of using a fingerprint of a public key as the lynch-pin for the trust infrastructure. Every trust infrastructure proposed to date can deliver a key fingerprint as output. They are short and convenient. What I don't like is having to work out mechanisms for rebooting the trust network in the case that a passphrase is forgotten or the like. So I want to give the end user the tools that allow them to make that as infrequent as possible. I want it to be possible for a user to keep their master public key life long. Email isn't the only thing that we are going to hang off this infrastructure. Lets imagine our user decides to take nude pictures of themselves and store them in the cloud. If they are sensible, they likely want to have some form of encryption in place. When I looked at the set of requirements that result, they look pretty much the same as the requirements for running an embedded root key for a CA because, well that is what we are doing. We are giving the end user a personal PKI hierarchy with themselves at the root of trust. So this is the current hierarchy I give people. [NB please just assume I don't do anything stupid here as this is an abbreviated version] Master key - self signed cert valid 30 years Sub key - cert signed by master, valid 10 years Use keys (Minimum) all signed by sub key * Common encryption key valid 3 months * Per device signature key valid 5 years for use in authentication * Per device encryption key for use in distributing keys. Now this might seem to be a lot of keys but it isn't a problem because the user does not need to be aware of this complexity. As far as they are concerned they just have one key. Separating the concerns like this solves a lot of problems. I don't worry too much about revocation because we can deal with that by rotating the encryption keys. Just stop giving the device new decryption keys if it is lost. I make no assumptions about how the keys are stored on the machine. I do not approve of mandatory passphrases. If people really have secrets so important they worry if they lose their device then they will use the locking function on their device. The only key I escrow right now is the master key. And that is encrypted under a session key which is then split in two. Right now we are just using 2 way XOR splitting and BASE-32 encoding. But QR codes would be better. I am currently working on the code for an escrow scheme where the encrypted private key would be stored on a service which will only release it to someone who can provide proof they know the decryption key. This eliminates the need to depend on the user not loosing their encrypted key blob. Moving keys from one device to another is just a matter of sending each device a message with the new decryption key encrypted under their per device encryption key. What I have not yet really looked into is how we escrow the encryption keys for messages. I was thinking we would have a master decryption key and escrow that. But I can imagine people wanting to have multiple keys for different email accounts with different policies attached. So for example if you are a journalist you might well want to not use escrow at all. There are also concerns for what happens when you die. So for example you might want your heirs to know where you buried aunt Miranda's jewelry and give then the info on how to retrieve that key. But you would likely want to take where you buried Aunt Miranda to the grave with you. So I am now thinking of adding in additional keys that would be encryption escrow keys that were backed up in the same way as the master. i.e. encrypted in the cloud by default but with the option of keeping the binary blob yourself. From nobody Tue Sep 2 12:47: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 E35161A887F for ; Tue, 2 Sep 2014 12:47:17 -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 H4Ly_9Nu2k_r for ; Tue, 2 Sep 2014 12:47:13 -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 D04871A8862 for ; Tue, 2 Sep 2014 12:47:12 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id k14so7298144wgh.28 for ; Tue, 02 Sep 2014 12:47:11 -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=5eHXqEQEBdAi02WN7fQLh0XqL1vUPD2rKXyChcZn5Fo=; b=DtuHPGM8TMNhO1OfXhFlornzyYs+1T7ANs7LMsZCjI+4LvpyMSk3GWm/nExxtvWx16 TcoV38Lm7kTSwfVvypJ1rpQynldv/+3m0LVhqlGlCKc1wMQJLhTgRxOwKKmhI4dwfSg1 SkGNchLa53B4XmWwLXILIBOZ+x4zoKA1jfoDPmcYuPYvc0eXvlz0OHpYUBLzJpr/JEiu Kyz8Kuxz57Sgf47vL1w8SRhV1bKg6Kp8ETZfXK2k4nhJ4jdkj7OynPTYhQon1sYKdMz4 9v/z2qj2SBrt6TRdMmfU2zRukX1X0jcnkAHyB0tJSR1cSMO9ppYnd+IgJsUCtibE31tc J4MQ== X-Gm-Message-State: ALoCoQmnUKuuGkYCUvvUy6wwm6ZTI5vEs3/etF3iB8aib+jieIdhIuB8V7IC/Df9LAeGEy0bt+Ly X-Received: by 10.194.60.240 with SMTP id k16mr4966829wjr.109.1409687231467; Tue, 02 Sep 2014 12:47:11 -0700 (PDT) Received: from vegoda.org (v6only.vegoda.org. [2a00:1098:0:86:1000:26:0:1]) by mx.google.com with ESMTPSA id h6sm11495149wjb.33.2014.09.02.12.47.09 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Tue, 02 Sep 2014 12:47:10 -0700 (PDT) Date: Tue, 2 Sep 2014 20:47:06 +0100 From: Leo Vegoda To: Stephen Farrell Message-ID: <20140902194706.GC8044@vegoda.org> References: <878um3prio.fsf@vigenere.g10code.de> <87y4u2laqh.fsf@vigenere.g10code.de> <20140902114217.lp_a_yD8%sdaoden@yandex.com> <20140902160206.GA7900@vegoda.org> <5405EEB8.1060107@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <5405EEB8.1060107@cs.tcd.ie> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/CvMJEhuwxrtSpmCE0S4hJ8lmGE8 Cc: Werner Koch , Steffen Nurpmeso , Arnt Gulbrandsen , endymail@ietf.org Subject: Re: [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: Tue, 02 Sep 2014 19:47:18 -0000 On Tue, Sep 02, 2014 at 05:22:16PM +0100, Stephen Farrell wrote: > > I'm not quite sure I'm reading this correctly, but just in > case... > > On 02/09/14 17:02, Leo Vegoda wrote: > > Handing out cryptographic identity certificates or similar to people > > who do not understand the risks or benefits and do not have a > > suitable key management framework doesn't seem a great idea to me. > > If this list concludes that an Internet-scale key management > framework is required where all key holders are strongly > authenticated before they get any functional benefit, then > that makes life easy - we have 20+ years of evidence that > there's no point in bothering to try construct that;-) That's not quite what I meant. What I meant is that if there is an authority handing out certificates then it should do so in a responsible way. Cryptographic certificates are sufficiently different from photographic identity documents that pre-existing assumptions need to be changed to avoid disappointment. This does not need to be hierarchical but it does need some infrastructure support and either some really outstandingly good user interface design or education. If users receive encrypted e-mail and then loose the corresponding private key then they loose the ability to read old messages. People working for organizations handing out X.509 certificates for S/MIME use get training and their keys might well be escrowed. But ordinary individuals are unlikely to get training and they do expect to be able to read old e-mails. I think this is the sort of basic usability issue that requires some kind of user friendly key management. Whether it needs to be Internet-scale - well I don't know - but it needs to be good enough that the key is reasonably secure if a laptop or tablet is lost or stolen. I expect that in most cases strong authentication is not required but people will need some kind of mechanism for evaluating how much trust to assign a new key they have not seen before and that will also require some kind of education or another superb user interface. Most people will be new to cryptography and will need some help. Leo From nobody Tue Sep 2 13:03:47 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 750A41A06A7 for ; Tue, 2 Sep 2014 13:03:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 p8ZRIjaKvnW9 for ; Tue, 2 Sep 2014 13:03:43 -0700 (PDT) Received: from mail-yk0-x234.google.com (mail-yk0-x234.google.com [IPv6:2607:f8b0:4002:c07::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C16A41A0699 for ; Tue, 2 Sep 2014 13:03:43 -0700 (PDT) Received: by mail-yk0-f180.google.com with SMTP id 9so4368397ykp.25 for ; Tue, 02 Sep 2014 13:03:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adamcaudill.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=oaF9becFw/M+qbJwd6ytXz3OM7i3PVBoi4lpuiHGWUo=; b=mGdsb5gYLT7mxUE/LaMX7ANE1AijuK+vl1pm9WkBRMxxYAwNjx6TtrdmzvqsixW/NX q4Qr2fDeQmJgm6Ynar+EpYoYwlwYNd+Vrscp44ZU8T0j0UGw5HKNfChYYHog1/NaayWq G1jaaT1/t52lYR+PjSj3UXCZ9rYmf4t6QFMZs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=oaF9becFw/M+qbJwd6ytXz3OM7i3PVBoi4lpuiHGWUo=; b=aqFE0+esdRjkhIWVm7VGu4UOI8Plb+7P2FIf6dKcaeXifo8oV+QcxUG2fwB3daILgd Khip8AUInp6q7Q45WrUY2lK4qs8E1dS5xUPRDd9WpTpvTubG3jmf505LawvpFrr0WdWN XUJhACAp5vKT44rAWKqpQQAyYKSM6W9Mq8lzuzEiR88lTbh9gT5Dsn9EUPagy/89GwRF TsZTfPJLzr6T4a8568BBs8I5yJ5fd8tOkE9HbOIH2UdDuWepQ8+P94A3c4yNSszO9Q23 mP6GoZKu+aA/W3yvYR1bPxMOYOFfoHGNqITZ0Uo3MFRRYtBXGG9frQh9J4Fn3QYcUIO7 LL/A== X-Gm-Message-State: ALoCoQn3T42Abwt0cVtmDoplLemvcQEbJeAQmKPNQuoKZUMXKrzZCIVFiAKqsrPzp1u8AqimBbp6 X-Received: by 10.236.138.198 with SMTP id a46mr4290615yhj.145.1409688222977; Tue, 02 Sep 2014 13:03:42 -0700 (PDT) Received: from [10.0.0.4] (c-50-142-69-73.hsd1.tn.comcast.net. [50.142.69.73]) by mx.google.com with ESMTPSA id n68sm2793592yha.10.2014.09.02.13.03.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 02 Sep 2014 13:03:42 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_71BB6E44-2BD1-4739-B264-B38D29320BFB"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Adam Caudill In-Reply-To: <5404A3A3.9050506@cisco.com> Date: Tue, 2 Sep 2014 16:03:39 -0400 Message-Id: References: <5404A3A3.9050506@cisco.com> To: Eliot Lear X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/5GJmfEC80xSsHySgeS3az_WHido Cc: Tim Bray , endymail@ietf.org Subject: Re: [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: Tue, 02 Sep 2014 20:03:45 -0000 --Apple-Mail=_71BB6E44-2BD1-4739-B264-B38D29320BFB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Sep 1, 2014, at 12:49 PM, Eliot Lear wrote: > On 8/27/14, 6:21 PM, Tim Bray wrote: >>=20 >> 1. Find a public key for the user that the sender=92s prepared to = trust. >>=20 >> This is a big problem. The PGP Web of Trust has failed, and we=92ve = all heard the griping about the CA biz. Joe Hildebrand mentioned POSH & = WebFinger and they=92re both interesting. I=92m also interested in the = notion of a key directory with associated proofs that you don=92t 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? >=20 > If the IETF could solve but this problem such that it scales to the = size of the Internet, everything else on your list would I think fall = into place. Unfortunately, key management really wasn't on your list, = and that has to be addressed as well. Also, I suspect that email = programs probably need to evolve a bit to cope with all of this. Case = and point: I'm pretty sure I've lot one or two private keys along the = way. And, at least compared to your average Joe, I'm good at this. No matter what the path forward is for secure messaging, key discovery = (and reasonable key management) will be the cornerstone. If we don=92t = have solid public key discovery, then I fear we=92ll just end up = reinventing PGP. For a system to scale to the same level email as we = know it has, there needs to be transparent key discovery so that the = average user need not be aware it=92s even happening. In the design I=92ve been working on, it=92s the responsibility of the = messaging service provider to host a user directory, with signed updates = that senders can use to get the proper key for a user (so, example.com = would provide the sender with the info they need to send to = bob@example.com). I really think this needs to be a primary focus, and as Tim pointed out, = this is something that makes sense for the IETF to work on. If we can = establish a solid solution here, I agree completely with Eliot here, the = rest will fall into place - and will open the door to many good options. --=20 Adam Caudill adam@adamcaudill.com http://adamcaudill.com/ --Apple-Mail=_71BB6E44-2BD1-4739-B264-B38D29320BFB Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJUBiKcAAoJENMzqGjemG5MZyEP/013AXD/Smi7lVhgQswCr7dM YRKTPPR5yG1ZaRkUyBW+2T97qZdtZOO8c6y7P15vooLb0VqmQP1eazXUu97jsJSk 6h5sE5VbUNJUF5CZjMAxWse8mswXZFcy8DiTYAoFkGFdhu5M5DkCO4jA8HGIE+wQ 8UDBuMf//k2fvmrDYmZ6Zzhq7i1d/mAn+X/xa2AKmJPyhiAdPUfQp3Vv02hzg/1N FXtCOIjnWWJgvvSrhKGykLVz1jXaCrrBdj00ywFDW0M7Ms7Ig7oO1po1F0MObHlK J8CuZNjBw3fs89mTkYLBHnNhpPYzYn4esk2sFXoVJXk0h6W1mHTADpZekAbgr8zu 4hVGKe36LQDhuNEBFeTB8iGIN39wgik/VhOqL6U3qv7QngOS4zBpz6EuCr360LRe W5rot9wa2wWUc7pyPhCJD5TO1gNgF8ikpRnvxPVyCvMFdgFX4Pfruj17gvDK4h/j /rh8mjRbmE2gXQPP9TM92NGxMp98vT1qLwlHNgfGTulgv1zDyAUzENdrNDrtVDLS EPPPHZdhBOoOppDoic3cnnXEI7zeEOzWNlJitn3sd78zfsj9rc8Tcl1ns/I26Eea 3Ss/jZfbEbIwJyaDFX8Ogl8rT7mXNV3DnLzrS6+4Y03VAllxAWd/nbE4c3/rVhcg tWZ7wy4oFeIH5WAacwHV =OEIK -----END PGP SIGNATURE----- --Apple-Mail=_71BB6E44-2BD1-4739-B264-B38D29320BFB-- From nobody Tue Sep 2 13:36:56 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 CF0601A0494 for ; Tue, 2 Sep 2014 13:36:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YVjK_LAMsSyv for ; Tue, 2 Sep 2014 13:36:00 -0700 (PDT) Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d: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 73CEE1A88C8 for ; Tue, 2 Sep 2014 13:36:00 -0700 (PDT) Received: by mail-qg0-f51.google.com with SMTP id i50so7319329qgf.10 for ; Tue, 02 Sep 2014 13:35:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=AuDDZ/RnAlvRwmY1ehrvVgd6a+aufuGO88DLh4PkoqE=; b=uEABksH9oL1406056wG22MWI9v7MTw/4gEd5kn9LrJ9PNI0O9H9vJ9exUZDvi3AIa4 pmPzRWXOk7ugePOGHDmQKiF82auJvyMcJF6wvFMZC4MxqKyTo+5tU+onR37qQHAnQTUq Ycq0Q09/97ydC3ad2oIywTDyhhyhza7pp9TatLJrXpwS4/IwnHDirFIf/hKZfMIipxIj xqbyp3eYVnJhpMCm7T53yFNuMwlomCDc0nmc/ZyvG79lZ8bTsmmd0NVg6mQ4VW4U7by3 OUZbQg2AalaoFcuVvInuhHvPgkw2/k/JWHXE2uB9+0iEB87vm9BxzxyA4LnCoZH/VDtG lBuA== X-Received: by 10.224.134.202 with SMTP id k10mr60767820qat.19.1409690159625; Tue, 02 Sep 2014 13:35:59 -0700 (PDT) Received: from [33.142.53.161] ([172.56.23.23]) by mx.google.com with ESMTPSA id l7sm12537715qae.45.2014.09.02.13.35.58 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 02 Sep 2014 13:35:58 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Phillip Hallam-Baker X-Mailer: iPad Mail (11B651) In-Reply-To: Date: Tue, 2 Sep 2014 16:36:04 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <3093EBC2-B370-4675-B53D-20162E3D0CC9@gmail.com> References: <5404A3A3.9050506@cisco.com> To: Adam Caudill Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/-thjWSF2e-zLr20Z_ZhuecRF0FE X-Mailman-Approved-At: Tue, 02 Sep 2014 13:36:54 -0700 Cc: Tim Bray , "endymail@ietf.org" , Eliot Lear Subject: Re: [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: Tue, 02 Sep 2014 20:36:05 -0000 On the key discovery problem, there are several separate questions: 1) I want to send email to Alice Splunge, what is her email address and what= is her trust anchor 2) I know Alice Splunge has email address, alice.splunge@example.com, what i= s her trust anchor 3) I know Alice's trust anchor and email address, what public key should Bob= Cratchet use to send her email? Some of these questions are easier to answer than others. Which is why I dis= tinguish trust anchor discovery (i.e. discovering the hash of a key that sig= ns a security policy) from key discovery.=20 Since spam is a concern, we might well not want to answer question 1, or at l= east not to just anyone. But we might distribute keys through social network= s. So I my might not publish my email address on my Web site (I do actually)= but I might put it on my linked in profile complete with my trust anchor. For in person trust anchor exchange, QR codes are the way to go. Sent from my iPad > On Sep 2, 2014, at 4:03 PM, Adam Caudill wrote: >=20 >> On Sep 1, 2014, at 12:49 PM, Eliot Lear wrote: >>=20 >>> On 8/27/14, 6:21 PM, Tim Bray wrote: >>>=20 >>> 1. Find a public key for the user that the sender=E2=80=99s prepared to t= rust. >>>=20 >>> This is a big problem. The PGP Web of Trust has failed, and we=E2=80=99v= e all heard the griping about the CA biz. Joe Hildebrand mentioned POSH & W= ebFinger and they=E2=80=99re both interesting. I=E2=80=99m also interested i= n the notion of a key directory with associated proofs that you don=E2=80=99= t 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 k= ey search APIs? >>=20 >> If the IETF could solve but this problem such that it scales to the size o= f the Internet, everything else on your list would I think fall into place. = Unfortunately, key management really wasn't on your list, and that has to b= e addressed as well. Also, I suspect that email programs probably need to e= volve a bit to cope with all of this. Case and point: I'm pretty sure I've l= ot one or two private keys along the way. And, at least compared to your av= erage Joe, I'm good at this. >=20 > No matter what the path forward is for secure messaging, key discovery (an= d reasonable key management) will be the cornerstone. If we don=E2=80=99t ha= ve solid public key discovery, then I fear we=E2=80=99ll just end up reinven= ting PGP. For a system to scale to the same level email as we know it has, t= here needs to be transparent key discovery so that the average user need not= be aware it=E2=80=99s even happening. >=20 > In the design I=E2=80=99ve been working on, it=E2=80=99s the responsibilit= y of the messaging service provider to host a user directory, with signed up= dates that senders can use to get the proper key for a user (so, example.com= would provide the sender with the info they need to send to bob@example.com= ). >=20 > I really think this needs to be a primary focus, and as Tim pointed out, t= his is something that makes sense for the IETF to work on. If we can establi= sh a solid solution here, I agree completely with Eliot here, the rest will f= all into place - and will open the door to many good options. >=20 > --=20 > Adam Caudill > adam@adamcaudill.com > http://adamcaudill.com/ >=20 >=20 >=20 > _______________________________________________ > Endymail mailing list > Endymail@ietf.org > https://www.ietf.org/mailman/listinfo/endymail From nobody Tue Sep 2 15:54:30 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 18EDB1A88CD for ; Tue, 2 Sep 2014 15:54:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, SPF_FAIL=0.001, SPF_HELO_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 DC7g1IHYFFtq for ; Tue, 2 Sep 2014 15:54:26 -0700 (PDT) Received: from herm.doylem.co.uk (herm.doylem.co.uk [IPv6:2001:41c8:51:5b0:feff:ff:fe00:17d2]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77A591A88C9 for ; Tue, 2 Sep 2014 15:54:26 -0700 (PDT) Received: from timdeb.doylem.co.uk ([2001:8b0:17a:0:20e:cff:fe77:4b8e]) by herm.doylem.co.uk with esmtpsa (Exim 4.80 #2 (Debian)) id 1XOwxy-0006od-Cj for ; Tue, 02 Sep 2014 23:54:22 +0100 Message-ID: <54064A9D.4050405@kooky.org> Date: Tue, 02 Sep 2014 23:54:21 +0100 From: Tim Bray User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.7.0 MIME-Version: 1.0 To: endymail@ietf.org References: <878um3prio.fsf@vigenere.g10code.de> <87y4u2laqh.fsf@vigenere.g10code.de> <20140902114217.lp_a_yD8%sdaoden@yandex.com> <20140902160206.GA7900@vegoda.org> <5405EEB8.1060107@cs.tcd.ie> In-Reply-To: <5405EEB8.1060107@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SA-Do-Not-Run: Yes X-SA-Exim-Connect-IP: 2001:8b0:17a:0:20e:cff:fe77:4b8e X-SA-Exim-Mail-From: tim@kooky.org X-SA-Exim-Scanned: No (on herm.doylem.co.uk); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/4KjHQuoaKAMlXBA8XAJBQEXd_sE Subject: Re: [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: Tue, 02 Sep 2014 22:54:28 -0000 Just to add another 2p in the pile. Does anybody have a view on https://telegram.org/ It is a whatsapp clone which claims to have reasonably strong encyption, with optional end to end encryption. They make some fairly bold claims about security on their website. The client side is open source. It is one of the best to use IM on your phone apps I've used. I'm told there are some scathing writeups about the encryption. I'm not enough of a crypto person to be able to reason about these. Telegram do store (non secure) chats on their server side, and they sync between devices very well. Downside for crypto/intercept. Good for usability. The server side isn't open source, and is run by the service operator. You can't install your own, and no server to server comms. But, it is a very very usable service. It does what it says on the tin. It is how a service aimed at a mass user base has to be. I'm not suggesting telegram is an answer. Just something to look at for inspiration. Tim -- Tim Bray tim@kooky.org | +44 7966 479015 | http://www.kooky.org Huddersfield, UK From nobody Wed Sep 3 00:27:14 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 E307D1A0048 for ; Wed, 3 Sep 2014 00:27:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.3 X-Spam-Level: X-Spam-Status: No, score=-6.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_HI=-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 zx4988EUQpTO for ; Wed, 3 Sep 2014 00:27:07 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 539EE1A001C for ; Wed, 3 Sep 2014 00:26:46 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1XP4xo-0002lu-0K for ; Wed, 03 Sep 2014 09:26:44 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.82 #3 (Debian)) id 1XP4tp-0003ec-P9; Wed, 03 Sep 2014 09:22:37 +0200 From: Werner Koch To: Stephen Farrell References: <878um3prio.fsf@vigenere.g10code.de> <87y4u2laqh.fsf@vigenere.g10code.de> <20140902114217.lp_a_yD8%sdaoden@yandex.com> <20140902160206.GA7900@vegoda.org> <5405EEB8.1060107@cs.tcd.ie> Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: id=1E42B367; url=finger:wk@g10code.com Date: Wed, 03 Sep 2014 09:22:37 +0200 In-Reply-To: <5405EEB8.1060107@cs.tcd.ie> (Stephen Farrell's message of "Tue, 02 Sep 2014 17:22:16 +0100") Message-ID: <87egvtjhhe.fsf@vigenere.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/X4wUk0AivXkXkKMd0qbB2u9f-No Cc: Steffen Nurpmeso , Arnt Gulbrandsen , endymail@ietf.org, Leo Vegoda Subject: Re: [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, 03 Sep 2014 07:27:11 -0000 On Tue, 2 Sep 2014 18:22, stephen.farrell@cs.tcd.ie said: > Similarly, if the list concludes that users have to understand > keys then that's also easy - we know that will never happen > and so could also call it a day. Users do understand mail addresses and thus a key should be identified by the mail address and not by any other property. > reinvent X.400 email security here please? (Or PEM, or MOSS, What problem do you see with MOSS? Except for the commonly ignored micalg parameter it is a well working part of MIME and not a problem at all. This is true for S?MIME as well as for PGP/MIME. We are still talking about mail, tight? Or is the goal of the list to replace the rfc822 mail format - that will never happen in the foreseeable future. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Wed Sep 3 03:53: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 57CE51A02D4 for ; Wed, 3 Sep 2014 03:53:42 -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 Fq4Dzth1wvq6 for ; Wed, 3 Sep 2014 03:53:39 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 6EE411A02BC for ; Wed, 3 Sep 2014 03:53:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 0FAFABE10; Wed, 3 Sep 2014 11:53:38 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id amLLJmjtUYqI; Wed, 3 Sep 2014 11:53:37 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B7FE9BE0F; Wed, 3 Sep 2014 11:53:37 +0100 (IST) Message-ID: <5406F333.4040006@cs.tcd.ie> Date: Wed, 03 Sep 2014 11:53:39 +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: Werner Koch References: <878um3prio.fsf@vigenere.g10code.de> <87y4u2laqh.fsf@vigenere.g10code.de> <20140902114217.lp_a_yD8%sdaoden@yandex.com> <20140902160206.GA7900@vegoda.org> <5405EEB8.1060107@cs.tcd.ie> <87egvtjhhe.fsf@vigenere.g10code.de> In-Reply-To: <87egvtjhhe.fsf@vigenere.g10code.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/HQYDGuNaq--LBema9iT1JgMrefE Cc: Arnt Gulbrandsen , Leo Vegoda , endymail@ietf.org Subject: Re: [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, 03 Sep 2014 10:53:42 -0000 On 03/09/14 08:22, Werner Koch wrote: >> > reinvent X.400 email security here please? (Or PEM, or MOSS, > What problem do you see with MOSS? Its irrelevance:-) Is it actually used for anything? I note the RFC [1] is now historic and as far as I know its not in use. I'm not saying its technically good or bad, (more good than bad is my recollection but I've not re-read it) but it failed in terms of adoption. S. [1] https://tools.ietf.org/html/rfc1848 From nobody Wed Sep 3 04:12:04 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 E25D61A86F7 for ; Wed, 3 Sep 2014 04:11:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-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 s2dF4uZLFCB2 for ; Wed, 3 Sep 2014 04:11:46 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F36B1A86FD for ; Wed, 3 Sep 2014 04:11:46 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1XP8TY-0005bE-PX for ; Wed, 03 Sep 2014 13:11:44 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.82 #3 (Debian)) id 1XP8Q3-0004Og-Op; Wed, 03 Sep 2014 13:08:07 +0200 From: Werner Koch To: Stephen Farrell References: <878um3prio.fsf@vigenere.g10code.de> <87y4u2laqh.fsf@vigenere.g10code.de> <20140902114217.lp_a_yD8%sdaoden@yandex.com> <20140902160206.GA7900@vegoda.org> <5405EEB8.1060107@cs.tcd.ie> <87egvtjhhe.fsf@vigenere.g10code.de> <5406F333.4040006@cs.tcd.ie> Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: id=1E42B367; url=finger:wk@g10code.com Date: Wed, 03 Sep 2014 13:08:07 +0200 In-Reply-To: <5406F333.4040006@cs.tcd.ie> (Stephen Farrell's message of "Wed, 03 Sep 2014 11:53:39 +0100") Message-ID: <8761h5j71k.fsf@vigenere.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/n-CUR7VPI6c0IvZfzhCX4yN1QsE Cc: Arnt Gulbrandsen , endymail@ietf.org, Leo Vegoda Subject: Re: [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, 03 Sep 2014 11:11:55 -0000 On Wed, 3 Sep 2014 12:53, stephen.farrell@cs.tcd.ie said: > On 03/09/14 08:22, Werner Koch wrote: > I note the RFC [1] is now historic and as far as I know Oops my fault. For the last 15 or so years I used the term MOSS for 1847 "Security Multiparts for MIME" in my mails, talks, and slides. That was clearly wrong. I entirely forgot that MOSS (1848) was an protocol based on 1847. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Wed Sep 3 07:56:33 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 AA0BA1A03C2 for ; Wed, 3 Sep 2014 07:56:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 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, J_CHICKENPOX_14=0.6, 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 feqwAzguyyHU for ; Wed, 3 Sep 2014 07:56:27 -0700 (PDT) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF4CF1A03E6 for ; Wed, 3 Sep 2014 07:55:37 -0700 (PDT) Received: by mail-la0-f47.google.com with SMTP id el20so1408857lab.34 for ; Wed, 03 Sep 2014 07:55:36 -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=EM0si6C2bdhrEmX4J3vNkGlwT32V/75ztPWr1OSntO8=; b=dJEyA/iPxJjFnSZnm494EInjPLUzy603sbhc+RZ+mLG9V/DE3lugI17MsmHGBXu3OF ijEytM0AFxRpeDWiFkZ+u2bA0ZdoUazjxySuWbhJMNfcmfJecYTL8YQpO5M6xYxMScP/ HDLkVlQ8OORu2IcLmd3iaNvi1y5Ex0RUw17Y5xzNYEoYGQ2sO4/XMxfcCeNfP3tyRYz3 GwecTBIUXBzzydp8zHQoL/lOEB3bUl+bjAQtAUifwXktf7k/avV3G6ray83JCy7Etyhr cOHGo7tUq6iw7yjKCQyCavS4eHClkPcaKBK5QA0k8Ar+ndACpMlVnZQz1b0ZdFIo76nZ Bl2w== MIME-Version: 1.0 X-Received: by 10.112.169.35 with SMTP id ab3mr39334281lbc.41.1409756135975; Wed, 03 Sep 2014 07:55:35 -0700 (PDT) Received: by 10.112.64.170 with HTTP; Wed, 3 Sep 2014 07:55:35 -0700 (PDT) In-Reply-To: <87egvtjhhe.fsf@vigenere.g10code.de> References: <878um3prio.fsf@vigenere.g10code.de> <87y4u2laqh.fsf@vigenere.g10code.de> <20140902114217.lp_a_yD8%sdaoden@yandex.com> <20140902160206.GA7900@vegoda.org> <5405EEB8.1060107@cs.tcd.ie> <87egvtjhhe.fsf@vigenere.g10code.de> Date: Wed, 3 Sep 2014 10:55:35 -0400 Message-ID: From: Kathleen Moriarty To: Werner Koch Content-Type: multipart/alternative; boundary=001a11c2696ab46f9c05022a6d65 Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/y082tFH4ue7KY6hH5ReSumxLNrk Cc: Arnt Gulbrandsen , Leo Vegoda , endymail@ietf.org, Stephen Farrell Subject: Re: [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, 03 Sep 2014 14:56:31 -0000 --001a11c2696ab46f9c05022a6d65 Content-Type: text/plain; charset=UTF-8 On Wed, Sep 3, 2014 at 3:22 AM, Werner Koch wrote: > On Tue, 2 Sep 2014 18:22, stephen.farrell@cs.tcd.ie said: > > > Similarly, if the list concludes that users have to understand > > keys then that's also easy - we know that will never happen > > and so could also call it a day. > > Users do understand mail addresses and thus a key should be identified > by the mail address and not by any other property. > > > reinvent X.400 email security here please? (Or PEM, or MOSS, > > What problem do you see with MOSS? Except for the commonly ignored > micalg parameter it is a well working part of MIME and not a problem at > all. This is true for S?MIME as well as for PGP/MIME. We are still > talking about mail, tight? Or is the goal of the list to replace the > rfc822 mail format - that will never happen in the foreseeable future. > I think we should be open to a possible change for messaging in general and not limit ourselves to mail. > > > Salam-Shalom, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > > _______________________________________________ > Endymail mailing list > Endymail@ietf.org > https://www.ietf.org/mailman/listinfo/endymail > -- Best regards, Kathleen --001a11c2696ab46f9c05022a6d65 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Wed, Sep 3, 2014 at 3:22 AM, Werner Koch <<= a href=3D"mailto:wk@gnupg.org" target=3D"_blank">wk@gnupg.org> wrote:
On Tue,=C2=A0 2 Sep 2014 18:= 22, stephen.farrell@cs.tcd.ie<= /a> said:

> Similarly, if the list concludes that users have to understand
> keys then that's also easy - we know that will never happen
> and so could also call it a day.

Users do understand mail addresses and thus a key should be identifie= d
by the mail address and not by any other property.

> reinvent X.400 email security here please? (Or PEM, or MOSS,

What problem do you see with MOSS?=C2=A0 Except for the commonly igno= red
micalg parameter it is a well working part of MIME and not a problem at
all.=C2=A0 This is true for S?MIME as well as for PGP/MIME.=C2=A0 We are st= ill
talking about mail, tight?=C2=A0 Or is the goal of the list to replace the<= br> rfc822 mail format - that will never happen in the foreseeable future.
<= /blockquote>

I think we should be open to a possible cha= nge for messaging in general and not limit ourselves to mail.=C2=A0


Salam-Shalom,

=C2=A0 =C2=A0Werner

--
Die Gedanken sind frei.=C2=A0 Ausnahmen regelt ein Bundesgesetz.

_____________________________= __________________
Endymail mailing list
Endymail@ietf.org
https://www.ietf.org/mailman/listinfo/endymail



--
=

Best regards,
Kathleen
--001a11c2696ab46f9c05022a6d65-- From nobody Wed Sep 3 11:32:13 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 7AF0D1A069A for ; Wed, 3 Sep 2014 11:32: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 6xATKNxff7A5 for ; Wed, 3 Sep 2014 11:32:11 -0700 (PDT) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13E001A0691 for ; Wed, 3 Sep 2014 11:32:10 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id hz20so10394582lab.31 for ; Wed, 03 Sep 2014 11:32:09 -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; bh=F4oI7B9O5dLCvbx4EoXG4W6I4VKuxlfnH806m5OQ01s=; b=ZF24h2bn+Qlju0oSj4XxMsqV6hluBD1LOhaD67ZNVBj02sB5cAR43VxsIL+3P22Hdu pgFqbY8ap3FbuqSt1m1mLWO0w3kiDRdeVCBZBzrbIweVNWtZfhGYytrf0faxDdJ6K9Qo BcFfI3bDAuYiKR6jzu0fZjAELHMH1Xjpb+3TxnfP7x4/Bca2liNrY0lC4yL2AvhydbSu JtQYj92mAcxLg/8NugZqxoQ4n19vmvNWc7kIzQ2XDw9EqM3IPEAIXyHPH3/OMgsohEdQ H5aMqOwnX+IH8c8DCJd5JjyQEAu/Xfsr/mYCEcvcEPn3887sB/fPWdaGSMCzWUSFcrxq a4YA== MIME-Version: 1.0 X-Received: by 10.152.37.168 with SMTP id z8mr28894922laj.24.1409769129320; Wed, 03 Sep 2014 11:32:09 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.122.50 with HTTP; Wed, 3 Sep 2014 11:32:09 -0700 (PDT) Date: Wed, 3 Sep 2014 14:32:09 -0400 X-Google-Sender-Auth: 2qWXWk8WaFUkYzbd2aqJ7YoUTSY Message-ID: From: Phillip Hallam-Baker To: endymail Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/sZb1Z0CEihnCvpsGvGA9jaPR6yI Subject: [Endymail] HKP Draft 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, 03 Sep 2014 18:32:12 -0000 Is there a more recent version of the HKP (Http Key Protocol) specification than this? http://tools.ietf.org/html/draft-shaw-openpgp-hkp-00 The draft is ten years old and much water has flowed underneath bridges since. But it is always good to have the existing infrastructure well specified so that we can do the next thing. I would like to see a similar protocol that offers better privacy controls. From nobody Wed Sep 3 11:54:54 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 7277B1A070C for ; Wed, 3 Sep 2014 11:54:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.678 X-Spam-Level: X-Spam-Status: No, score=-0.678 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, J_CHICKENPOX_14=0.6, 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 BOpbWvVCfNgW for ; Wed, 3 Sep 2014 11:54:45 -0700 (PDT) Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C08CC1A068F for ; Wed, 3 Sep 2014 11:54:44 -0700 (PDT) Received: by mail-lb0-f178.google.com with SMTP id v6so10089715lbi.37 for ; Wed, 03 Sep 2014 11:54:43 -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=0lPpZ/IJwQdnnsic8STVDy8KyjaTxDmPwYwbt8BeyYQ=; b=ZfiK1LbuKqSJ5aABWikyvyO0P/yg/6MZ+MO+3BoeCmH29yCRN0Yt0qltqnBlXtr8HD AMzdjOU9EkbHKA4g06SXpwaaXcMAnG+nvPq12b2r2acNgot7gKGZ84KyQXjf0sC8tNwE Kb3YQJtxKxJRP/u37NOHo+dlFKfEqG3QATXr6CqkxX/H+RJYhc2I/VmSuXcAZIS40M+M SH0Wv7fONuJdeYdUbss8r9hT8k7lL3wB8/wrmuHhVs/BaN49I5s7aKL9enPMgD8M17+/ jWTJLDMvnJxDgY8UTgVd1AhHfOPkkEqiu0hFPZcqSig1zczL/xQdAQahV3OL7LKCAwNv xWAg== MIME-Version: 1.0 X-Received: by 10.152.45.1 with SMTP id i1mr4445469lam.97.1409770482968; Wed, 03 Sep 2014 11:54:42 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.122.50 with HTTP; Wed, 3 Sep 2014 11:54:42 -0700 (PDT) In-Reply-To: References: <878um3prio.fsf@vigenere.g10code.de> <87y4u2laqh.fsf@vigenere.g10code.de> <20140902114217.lp_a_yD8%sdaoden@yandex.com> <20140902160206.GA7900@vegoda.org> <5405EEB8.1060107@cs.tcd.ie> <87egvtjhhe.fsf@vigenere.g10code.de> Date: Wed, 3 Sep 2014 14:54:42 -0400 X-Google-Sender-Auth: 2HliLzusyeWN1I25PijW9rpU3cY Message-ID: From: Phillip Hallam-Baker To: Kathleen Moriarty Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/mJyBRpe2xs4ygW9bF3gEzI4VhKo Cc: Werner Koch , Arnt Gulbrandsen , endymail , Leo Vegoda , Stephen Farrell Subject: Re: [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, 03 Sep 2014 18:54:46 -0000 On Wed, Sep 3, 2014 at 10:55 AM, Kathleen Moriarty wrote: > > > > On Wed, Sep 3, 2014 at 3:22 AM, Werner Koch wrote: >> >> On Tue, 2 Sep 2014 18:22, stephen.farrell@cs.tcd.ie said: >> >> > Similarly, if the list concludes that users have to understand >> > keys then that's also easy - we know that will never happen >> > and so could also call it a day. >> >> Users do understand mail addresses and thus a key should be identified >> by the mail address and not by any other property. >> >> > reinvent X.400 email security here please? (Or PEM, or MOSS, >> >> What problem do you see with MOSS? Except for the commonly ignored >> micalg parameter it is a well working part of MIME and not a problem at >> all. This is true for S?MIME as well as for PGP/MIME. We are still >> talking about mail, tight? Or is the goal of the list to replace the >> rfc822 mail format - that will never happen in the foreseeable future. > > > I think we should be open to a possible change for messaging in general and > not limit ourselves to mail. Totally and I think changing messaging in general is likely to be the area where we eventually end up changing application protocols. If we are just fixing email security then obviously we play SMTP. If we are doing messaging then we just layer security onto Jabber. But if we decide that we are doing security for messaging in general, both synchronous and asynchronous, bilateral and multilateral then cutting out the cruft and going to a consistent JSON based messaging infrastructure with security built in from the start and a key service that doubles as a presence service starts to look a lot simpler than ad hoc backfixes to each protocol in turn. But. The reason I am sticking with email right now is that it is the single hardest problem and if we can solve that one, we can leverage the solution for every other area as well. What makes email hard is that it is asynchronous and the store and forward protocols don't separate content and data channels. So all control signaling takes place in the content space or not at all. These days increasingly not at all, I don't see bounce messages very often any more. From nobody Thu Sep 4 06:19:14 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 8CA4C1A889F for ; Thu, 4 Sep 2014 06:19:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.519 X-Spam-Level: X-Spam-Status: No, score=-0.519 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 VAVxCVj9hzcO for ; Thu, 4 Sep 2014 06:19:10 -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 1576A1A8891 for ; Thu, 4 Sep 2014 06:19:08 -0700 (PDT) Received: by nekare.kjorling.se (Postfix, from userid 1001) id 2D07E114075; Thu, 4 Sep 2014 13:19:06 +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 0A37D114073 for ; Thu, 4 Sep 2014 13:18:58 +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 88E7E140031 for ; Thu, 4 Sep 2014 15:18:57 +0200 (CEST) Date: Thu, 4 Sep 2014 13:18:56 +0000 From: Michael =?utf-8?B?S2rDtnJsaW5n?= To: endymail@ietf.org Message-ID: <20140904131856.GM603@yeono.kjorling.se> References: <5404A3A3.9050506@cisco.com> <3093EBC2-B370-4675-B53D-20162E3D0CC9@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <3093EBC2-B370-4675-B53D-20162E3D0CC9@gmail.com> Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/qIjDw--NOtG0JFbqHJHvbHKVPeM Subject: Re: [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: Thu, 04 Sep 2014 13:19:12 -0000 On 2 Sep 2014 16:36 -0400, from hallam@gmail.com (Phillip Hallam-Baker): > Since spam is a concern, we might well not want to answer question > 1, or at least not to just anyone. This is one of the points I raised in [1], and which frankly I felt went unaddressed. > For in person trust anchor exchange, QR codes are the way to go. Only if you're willing to basically limit "whatever we end up discussing" to people who have the ability to process a random encountered QR code in the field. While smartphones and ubiquitous networking is common in many Western countries, designing a protocol around only that seems rather excluding. Just to mention one example, I myself would have no way to process that QR code, and found myself in a discussion on a non-technical mailing list the other day where several people commented about either not having cell phones at all, or having only old "dumb phone" style phones. Do we want to exclude those people from establishing that trust anchor? [1] Fri, 29 Aug 2014 09:11:33 +0000 http://mailarchive.ietf.org/arch/msg/endymail/mSmLHfs0kzZNE9LaYdBDjHtN8ok -- 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 Sep 4 06:27: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 21A241A88C1 for ; Thu, 4 Sep 2014 06:27:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, 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 9i22yczUvArp for ; Thu, 4 Sep 2014 06:27:21 -0700 (PDT) Received: from mail-pd0-f171.google.com (mail-pd0-f171.google.com [209.85.192.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 170D51A88BA for ; Thu, 4 Sep 2014 06:27:13 -0700 (PDT) Received: by mail-pd0-f171.google.com with SMTP id y13so13565562pdi.16 for ; Thu, 04 Sep 2014 06:27:11 -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 :content-transfer-encoding:in-reply-to:user-agent; bh=hBjRuPY2WwOsyNr74GGVKADwXUfEGqZFQgkypNBAJys=; b=E6B1L6/uer6ugEJjzlCtqjzHt8mexL9y/XzFKBp32rrpuOtsIB0O+eu5TcMLaKt+4y OhQdUQCdGc56MyzL3zALBAy5zuA1DOyUs8+fPaOQ3EOKy9E6RiRnYURZdKsYtPSCyrl4 v66UaZF2etcvdSIorrUbfNPI2PGV1Is+DCnvC8W/YPOglkZjaQUftiRFplt1ESuqt11u qM4oweARmSTY3PPmcoZMX7n/I61VircZOfozUx9rCnNPaisdV+dS1BykPOUB8uwkiR9L Blji8237/TD1inqjXi20SeD3VRuf3Yisd+yPk8Y1ZW8wnz5FLyKaejeQP2vGddI2h5d5 aIrA== X-Gm-Message-State: ALoCoQkF8tbA+9iI1ehgPE9xQcZ2dQze6zFlR37XugBUQS8BS3oJ43dTboA3g7qwrd7ZYZlewjb9 X-Received: by 10.70.43.100 with SMTP id v4mr7911669pdl.108.1409837230286; Thu, 04 Sep 2014 06:27:10 -0700 (PDT) Received: from vegoda.org ([2605:e000:5903:f500:e866:25bb:bff:933]) by mx.google.com with ESMTPSA id pn13sm1725436pdb.53.2014.09.04.06.27.09 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Thu, 04 Sep 2014 06:27:09 -0700 (PDT) Date: Thu, 4 Sep 2014 06:27:05 -0700 From: Leo Vegoda To: Michael =?utf-8?B?S2rDtnJsaW5n?= Message-ID: <20140904132705.GC3277@vegoda.org> References: <5404A3A3.9050506@cisco.com> <3093EBC2-B370-4675-B53D-20162E3D0CC9@gmail.com> <20140904131856.GM603@yeono.kjorling.se> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20140904131856.GM603@yeono.kjorling.se> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/gAa2wgf6zvdjNIgxIa8S4VaTiiA Cc: endymail@ietf.org Subject: Re: [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: Thu, 04 Sep 2014 13:27:23 -0000 On Thu, Sep 04, 2014 at 01:18:56PM +0000, Michael Kjörling wrote: [...] > > For in person trust anchor exchange, QR codes are the way to go. > > Only if you're willing to basically limit "whatever we end up > discussing" to people who have the ability to process a random > encountered QR code in the field. While smartphones and ubiquitous > networking is common in many Western countries, designing a protocol > around only that seems rather excluding. Just to mention one example, > I myself would have no way to process that QR code, and found myself > in a discussion on a non-technical mailing list the other day where > several people commented about either not having cell phones at all, > or having only old "dumb phone" style phones. > > Do we want to exclude those people from establishing that trust > anchor? Is it sensible to design a technology based around currently deployed capabilities or oshould the design assumptions extend to those capabilities that are likely to exist at the conclusion of the work or shortly afterwards? I know there are reasons that people might not want to use cameraphones in some industries, and that might well limit the utility of QR codes. However, it seems reasonable to anticipate cameraphone technology reducing in price and becoming more widespread in the next five years. From nobody Thu Sep 4 06:30: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 AE76A1A88B5 for ; Thu, 4 Sep 2014 06:30:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 LAxTBHec8muX for ; Thu, 4 Sep 2014 06:30:08 -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 8389F1A889F for ; Thu, 4 Sep 2014 06:30:07 -0700 (PDT) Received: by nekare.kjorling.se (Postfix, from userid 1001) id D04ED114075; Thu, 4 Sep 2014 13:30:05 +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 DB7CE114073 for ; Thu, 4 Sep 2014 13:29:56 +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 736D7140031 for ; Thu, 4 Sep 2014 15:29:56 +0200 (CEST) Date: Thu, 4 Sep 2014 13:29:55 +0000 From: Michael =?utf-8?B?S2rDtnJsaW5n?= To: endymail@ietf.org Message-ID: <20140904132955.GN603@yeono.kjorling.se> References: <20140829091133.GA25723@yeono.kjorling.se> 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/o26Z6e1nEj6Nb5wKx4otZeD6oCM 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: Thu, 04 Sep 2014 13:30:09 -0000 On 29 Aug 2014 09:37 -0400, from phill@hallambaker.com (Phillip Hallam-Baker): > On Fri, Aug 29, 2014 at 5:11 AM, Michael Kjörling wrote: >> 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 >> >> 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. Fair enough, but how would you resolve such a hash without connectivity? We know that traffic analysis is being done on a massive scale, and have good reason to believe that encrypted traffic is routinely and specifically targeted for storage for possible later analysis. As it stands, with SMTP, assuming transport security (_proper_ STARTTLS, for example), it seems about the most someone listening in can figure out is that someone is sending e-mail to a particular domain (say, by matching DNS MX RR lookups with subsequent SMTP TCP connections). This leaks a small amount of metadata, but that can be mitigated by sharing SMTP hosting and email address domains with others. I would argue that any replacement (the purpose of which is end-to-end security) should not leak _more_ metadata to any reasonable attacker, ideally including an active attacker able to do network packet injection. > 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. Far from everyone does, even today. [1] Should the protocol be designed to essentially require such? > There does not need to be a central repository. There does not even > need to be global connectivity. Then how would you propose to validate a hash, or given a hash, send a message to it, without some sort of connectivity to some sort of hash repository? [1] Thu, 4 Sep 2014 13:18:56 +0000, http://mailarchive.ietf.org/arch/msg/endymail/qIjDw--NOtG0JFbqHJHvbHKVPeM -- 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 Sep 4 06:58:29 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 EABC01A88CD for ; Thu, 4 Sep 2014 06:58:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.268 X-Spam-Level: X-Spam-Status: No, score=-2.268 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, 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 jBkfbpTIZGwh for ; Thu, 4 Sep 2014 06:58:23 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 2013C1A88D7 for ; Thu, 4 Sep 2014 06:58:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 737BDBE0F; Thu, 4 Sep 2014 14:58:14 +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 xaFTOfOkhLjJ; Thu, 4 Sep 2014 14:58:13 +0100 (IST) Received: from [10.87.48.3] (unknown [86.42.16.156]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 17EAEBE0E; Thu, 4 Sep 2014 14:58:13 +0100 (IST) Message-ID: <54086FF3.5020305@cs.tcd.ie> Date: Thu, 04 Sep 2014 14:58:11 +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: =?UTF-8?B?TWljaGFlbCBLasO2cmxpbmc=?= , endymail@ietf.org References: <20140829091133.GA25723@yeono.kjorling.se> <20140904132955.GN603@yeono.kjorling.se> In-Reply-To: <20140904132955.GN603@yeono.kjorling.se> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/OVDJ47NcTZkrKWKlxJiEpNvKq0w 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: Thu, 04 Sep 2014 13:58:26 -0000 Hiya, In the hope of heading off a rathole discussion (about who has what devices with what capabilities)... On 04/09/14 14:29, Michael Kjörling wrote: >> > 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. > Far from everyone does, even today. [1] Should the protocol be > designed to essentially require such? We're nowhere near the point where what's "required" is being discussed really. I doubt PHB meant that QR codes ought be the one and only way of doing anything. And even if he did, (which I know he doesn't:-) that wouldn't matter so much now, and its ok to regard 'em just an example of what might work in some cases. That kind of "what to make mandatory to implement" discussion would be needed later for sure, but we're not there yet. Cheers, S. From nobody Thu Sep 4 08:10:39 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 7333C1A8919 for ; Thu, 4 Sep 2014 08:10:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 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, 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 0J3ZS0NYovyd for ; Thu, 4 Sep 2014 08:10:32 -0700 (PDT) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99ADE1A890C for ; Thu, 4 Sep 2014 08:10:18 -0700 (PDT) Received: by mail-lb0-f171.google.com with SMTP id 10so3013478lbg.2 for ; Thu, 04 Sep 2014 08:10:16 -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=8BThwuqo62KuL/o4V1REmW6HPAoyilHFrYcwHhhQ3so=; b=lIcMdxmcpEjgxFri+OkLu13UjMTbIR8L4iOCNGNoPhUbD7VNqQy/KpK7S6NndPxEq/ 5kCBDrLHZD60UHDcKC60Kb/Dg6a9Qmz6AArajbA0pxv2pT9FSzzgFlWJyYmYdpTtyfVt 0RYJVA8Af3wmPZrlFxguh7pXRSJFJjtSeYxN9xulj/P9eK5usVId93GoGDWzMpzXuuYa e/nYq2C6zlAALeSFDL4imPsPT/slxH9RJ6EttDCSYCTYN0I6vw7CMmPY8dk72qQuD4w9 LFg7+gIU9ohTP6GbhlF0y4FkCGx8qdP2EYpnTWbVnMSs7ynvkvLpKcKimvSnmA3Mlvva Nm/Q== MIME-Version: 1.0 X-Received: by 10.112.24.104 with SMTP id t8mr5157033lbf.46.1409843416697; Thu, 04 Sep 2014 08:10:16 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.122.50 with HTTP; Thu, 4 Sep 2014 08:10:16 -0700 (PDT) In-Reply-To: <20140904132955.GN603@yeono.kjorling.se> References: <20140829091133.GA25723@yeono.kjorling.se> <20140904132955.GN603@yeono.kjorling.se> Date: Thu, 4 Sep 2014 11:10:16 -0400 X-Google-Sender-Auth: FdSSnm1mk_b7rJZmdHiu9zxfGn8 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/mxdGs0KTil0438BWiYhmFtlf1wM 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: Thu, 04 Sep 2014 15:10:34 -0000 On Thu, Sep 4, 2014 at 9:29 AM, Michael Kj=C3=B6rling = wrote: > On 29 Aug 2014 09:37 -0400, from phill@hallambaker.com (Phillip Hallam-Ba= ker): >> 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-= 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@exampl= e.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. > > Fair enough, but how would you resolve such a hash without > connectivity? How does the email get sent at all without connectivity? Now clearly there are circumstances in which a client has a compromised email only connection. But these are actually pretty rare these days and I don't see a problem with saying that we can't do end to end directly in that situation. In my current implementation the email can be composed offline as normal. The S/MIME enhancement takes place in an outbound SMTP proxy as the mail is being sent. > We know that traffic analysis is being done on a massive scale, and > have good reason to believe that encrypted traffic is routinely and > specifically targeted for storage for possible later analysis. Which is why we need STARTTLS even in an endymail world. >> 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. > > Far from everyone does, even today. [1] Should the protocol be > designed to essentially require such? Well it is working right now without any QR code implemtnation. >> There does not need to be a central repository. There does not even >> need to be global connectivity. > > Then how would you propose to validate a hash, or given a hash, send a > message to it, without some sort of connectivity to some sort of hash > repository? The repository does not need to be unified or global. Right now the so-called 'repository' consists of posting files to a web site of the email address holder's choice. I do object when people insert pejorative terms like 'global repository' into a scheme. I think it very likely that a global repository will emerge naturally because it is convenient to do and I expect 95% of keys to end up in it. But I do not expect it to ever be complete. From nobody Thu Sep 4 09:52:58 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 488C91A8747 for ; Thu, 4 Sep 2014 09:52:55 -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 22dIXgp43y8J for ; Thu, 4 Sep 2014 09:52:53 -0700 (PDT) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B128D1A8789 for ; Thu, 4 Sep 2014 09:51:30 -0700 (PDT) Received: by mail-lb0-f169.google.com with SMTP id p9so1389025lbv.14 for ; Thu, 04 Sep 2014 09:51:27 -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; bh=LVl6Jz6MBphKopVCv+4G8Awims6b4bOIgwzapDDSVwQ=; b=WlIDusf5TLwDjpcKU8RnNU8YlpHiBSEtghGsxvsKulMwSFCHhPUY30AZKDROBwIrKs XAN8cWnGA1pwzKOL3SnbL+n1orUY5d47WmBflXRbr+yoiAGA/RhodnLL2cAv92Ym0eK6 bpbhG21NmStU0UPQKECO4qTfUOjrZPTqthcWZ/flrHlk8MBLbK6O1boZ77Jqag7yycZ4 BPor/QFMjyrFvhn7aMuyfe+e+TFjC1no+6xW4HVIUJ3xHLA5BBSx9AmJsCPM9a6sjSGw aWVx1H207R5IZZGI+FlPDLSEeWaLxk/uU3u+csHxCJCKj7cRm8W+RqQ4k94IGZ8UEpUE apug== MIME-Version: 1.0 X-Received: by 10.153.4.39 with SMTP id cb7mr5831695lad.19.1409849487533; Thu, 04 Sep 2014 09:51:27 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.122.50 with HTTP; Thu, 4 Sep 2014 09:51:27 -0700 (PDT) Date: Thu, 4 Sep 2014 12:51:27 -0400 X-Google-Sender-Auth: xiK1NkSV1Cp-URtuba-OPGpOwfI Message-ID: From: Phillip Hallam-Baker To: endymail Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/ofQqpqbN_M_YShoZKXZZxHkxDKU Subject: [Endymail] How an endymail eco-system might incorporate web of trust features 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, 04 Sep 2014 16:52:55 -0000 [We don't have a name for the person sending Alice spam, I suggest Spaulding] As I see it, we are a long way away from deciding on a trust model. If in fact we ever do chose the one perfect trust model. But it does keep coming up so this is the way I think web of trust models and TTP models might interact in an endymail ecosystem. First off, I assume that each participant has at least one personal PKI which for the purposes of this discussion we can consider to last their lifetime. [In practice of course some people will have more than one, some people will screw up and lose control of their master secret, some people will go into witness protection programs, etc. etc. But the starting point for sanity is that we don't force unnecessary changes onto people.] One of the core principles of PPE is that sending encrypted mail is as easy to do as sending regular mail. So there is a usability layer on top of the raw crypto. But in order to set up the requirements for that usability layer I have to first explain the security requirements in raw crypto. So please suspend disbelief for the usability side of things as you read, it will become clear as we go along. So Alice has her personal PKI and the phingerprint of her master key, how might someone use that to communicate with Alice? The first point of departure from conventional PKI is that how Bob communicates with Alice might not be the same as how Carol communicates. Alice and Bob have known each other 40 years now. They are very very good friends. So I think it rather likely that Alice would be prepared to whitelist Bob as not a spammer. Also they spend so much time exchanging secret info, Alice is probably rather more concerned about the confidentiality of her emails from Bob than from Carol. And as for Spaulding, she does not want him to be sending endymail at all. So lets imagine Alice has a couple of laptops, a mobile phone, a couple of tablets and three desktops she has configured to read mail from. And now lets imagine she works for the National Security Bureau (NSB) which is the little heard about US agency charged with competently keeping government secrets secret. Does Alice really want every one of those devices to be able to read her Tippy-Top Secret messages? I think not. But she wants to be able to access 'Somewhat Secret' messages on all of them. So in practice Alice has the following mail confidentiality configuration, some of which is configured for her by her employers at the NSB and some of which she has set up: NSB Bulk Key: 'alice@nsb.gov' The encryption key of the NSB spam filter. NSB Alice key: 'alice@nsb.gov' An endymail key for Alice, the decryption key is on all her devices. NSB Alice confidential key: 'alice-tts@nsb.gov' An endymail key for Alice, the decryption key is only on her phone. Personal Alice Key: 'alice@webmail.com' An endymail key Alice uses for personal correspondence. Only some of these keys are publicly visible. And use of certain keys likely requires a message to be signed and meet specific access controls. Alice has four keys but only three accounts. This is because the choice between using the NSB bulk key and the NSB alice key can and therefore MUST be taken by the infrastructure. A mail sender knows if they have been pre-approved to send endymail or not. The choice of using one of the other accounts has to be left to the sender because they have distinct semantics. Bob knows that sending a message to Alice in her NSB role is different to sending her personal mail. Hence a different account is required. In other words, we are using three different email accounts to represent three different email security policies. Alice has four mail accounts but only one life long phingerprint. And that phingerprint could in theory be used with any of her email addresses. If Bob wants to be absolutely sure that the message goes to Alice he should be using her phingerprint. But this is not the only consideration. If Bob is sending a message on official business he would be at least as concerned that the message is going to someone who is currently employed at the NSB as that it goes to Alice. So in this case it is more appropriate to use the phingerprint of the NSB to determine the governing policy. Authenticating organizations such as the NSB or banks is something we already have an infrastructure built out to perform, its the WebPKI. I would very much like to go further and make use of PKIX logotypes and EV certificates with authenticated logos inside them to really nail down this relationship. Authenticating Alice in her personal capacity is rather more challenging. This is because corporations are not people, they only exist through government action. Thus government issued credentials are perfect for authenticating them. People do not exist as a result of government action, government credentials can be forged and there is a vast underground industry dedicated to forging them. Many people do go through events where we might potentially checkpoint their credentials however. Let us imagine that Alice creates her personal PKI at 18 when she starts college. Her name at this point is Alice Splunge. The college issues her an email account and she creates an encryption key to use with it. The college provided PKI gateway issues her a certificate in the college hierarchy and checkpoints it against the global TRANS notary infrastructure. [Note here that the use of the definite article in talking about catenate notary infrastructures is a recognition of the inevitability that there can be only one. Wherever there are two infrastructures it is inevitable that data objects from infrastructure A will be cross registered in infrastructure B and vice versa. And it is mutually beneficial that they do. And when they do so the two infrastructures become equivalent in terms of trustworthiness] At this point we have an assertion about the identity of Alice that might have been forged very cheaply when she was a student in 1984. But an attacker who decides that they want to impersonate Alice today, 30 years later would need a time machine or a way to break the encryption. The work factor for an attacker goes to essentially infinity after the notarization takes place. So it is my belief that we will establish a significant population of people with keys that have been enrolled in a notary service at some point in the past and this will create a significant work factor for an attacker trying to impersonate one of those people. Many of those users will have keys that have been enrolled numerous times. We are not going to get 100% coverage this way but we can probably get to 10% without too much difficulty. Now lets imagine I am one of the 90%, how do I get a key established? One way would be to find a member of the 10% and get them to endorse my key. Or better find several members. Here is how endymail is a huge advance on PGP. In the PGP web of trust, who you get endorsed by determines who you can communicate with. If you live in Kansas then it is highly unlikely you will find a trust path to someone in Siberia. This limitation goes away in the endymail scheme because the attacker can't feasibly impersonate a 30 year established key. An attacker can be a person with a 30 year established key but making fraudulent or negligent endorsements opens them up to accountability. As for mechanisms for endorsement, QR codes are only one mechanism that might be used. It is a pretty good one however. I recently bought a cell phone for my children. $5 each. They have two cameras. I don't see getting a smart phone would be an unreasonable requirement for endymail even if it was essential but it isn't. The way I see endymail working for an end user is that their mail client would have the following as information stores: 1) Contacts directory with entries for strong email addresses (i.e. address plus phingerprint) of people I know 2) A Web Service provider chosen by the user that provides key discovery services. 3) A local cache of previous queries to the Web Service (including negative results). The email client is going to periodically scan its contacts directory to attempt to pre-fetch keys. This activity improves performance and reduces the value of traffic analysis. Whenever an email message is sent, the client attempts to apply encryption if possible. This means: 1) It can find an endymail encryption key for the recipient. 2) The recipient has asserted that they prefer mail encrypted. The key discovery Web Service is going to be accumulating information from multiple sources: 1) The notary service log files 2) Public directories (possibly including DANE) 3) Policy information taken from SMTP headers. One of the big problems a lot of people seem to have is distinguishing the risk introduced in a 'first contact' situation from future risks. Imagine that we have a large square sheet of plywood, 2 meters on each side and a hole 2cm in diameter in the middle. The plywood is held roughly horizontal by a series of motors that are tilting and twisting it constantly causing several thousand marbles 1cm in diameter to roll across the surface. Given that set up it would probably take a very long time for the marbles to all drop through the hole. Now rout some channels in a spiraling pattern ending at the hole into the plywood. The marbles drain a lot faster. The point here is to capture as much Internet email traffic as possible and put it on rails that guide it to the endymail hole. From nobody Fri Sep 5 11:27:21 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 04FF81A0B0F for ; Fri, 5 Sep 2014 11:27:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 5ajE1IgkZ8qB for ; Fri, 5 Sep 2014 11:27:17 -0700 (PDT) Received: from forward6l.mail.yandex.net (forward6l.mail.yandex.net [84.201.143.139]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 772D41A0B00 for ; Fri, 5 Sep 2014 11:27:17 -0700 (PDT) Received: from smtp1o.mail.yandex.net (smtp1o.mail.yandex.net [37.140.190.26]) by forward6l.mail.yandex.net (Yandex) with ESMTP id 7484514E0D68 for ; Fri, 5 Sep 2014 22:27:15 +0400 (MSK) Received: from smtp1o.mail.yandex.net (localhost [127.0.0.1]) by smtp1o.mail.yandex.net (Yandex) with ESMTP id 14685DE2AA8 for ; Fri, 5 Sep 2014 22:27:14 +0400 (MSK) Received: from unknown (unknown [82.113.121.124]) by smtp1o.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id Br8w2KqowM-RDVClJ33; Fri, 5 Sep 2014 22:27:14 +0400 (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (Client certificate not present) X-Yandex-Uniq: 76fdd399-ebc1-4657-81b6-35fa364e0428 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.com; s=mail; t=1409941634; bh=O4ANdPRoLw3GScNauIIdZxnwbgEqdq+31YAiE+aF854=; h=Date:From:To:Subject:Message-ID:References:In-Reply-To:User-Agent: MIME-Version:Content-Type:Content-Transfer-Encoding; b=mHBrXdXXpV2qOEnOA3JLraYOKxKUdTGMApvKLjZ00P0PGBKQ8iYYE5yATuycDe8cm tj898TE6W0LOYJ9xM9UgD3XiHhe5NqbC2371ZpOboh03R8ZOj3ibYMrTzHhF61+z7U Jzfxr96YOhOutEwuRxFDjaZn6Rwt6+97GR3ihuG0= Authentication-Results: smtp1o.mail.yandex.net; dkim=pass header.i=@yandex.com Date: Fri, 05 Sep 2014 20:27:12 +0200 From: Steffen Nurpmeso To: endymail@ietf.org Message-ID: <20140905192712.XG2Xmr5N%sdaoden@yandex.com> References: <20140829091133.GA25723@yeono.kjorling.se> <20140904132955.GN603@yeono.kjorling.se> In-Reply-To: <20140904132955.GN603@yeono.kjorling.se> User-Agent: s-nail v14.7.6-15-gc1887ab MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/D-EMvv2G-gB_OYUXoZ85m2iWif4 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, 05 Sep 2014 18:27:20 -0000 |As it stands, with SMTP, assuming transport security (_proper_ |STARTTLS, for example) I don't know how many messages are sent over SMTP each day, but it would be interesting to know how much energy all those useless roundtrip packets consume which are necessary to get upgrade a SMTP session via STARTTLS, and how many percent of those connections could also instantiate a non-existent SMTPS instead, not requiring these upgrades. Imagine all those billion indic kids treadle the dynamos to produce the necessary electricity; granted it improves the quality of their organs, too, so win-win here. And in my world there was no support for DNSSEC, but omnipresent support for TLS over TCP. It would take a day to extend the resolver, with fewest additional code, based on external crypto / ssl/tls libraries which get used trillion times each day. And with a caching resolver and/or a local DNS cache that additional cost on the DNS side would be balanced out by the savings of the much more often occurring SMTPS connections. Oh well, it is much too late for this nagging, of course. And there are really some domains which use DNSSEC today; my bank does not however, and unfortunately ;-)) But of course their website is protected via https, after so much phishing, ..say. I wonder wether that sorts out the problem. --steffen From nobody Fri Sep 5 14:10:01 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 C7D121A00BF for ; Fri, 5 Sep 2014 14:09:58 -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 AYXeCWHnns3Y for ; Fri, 5 Sep 2014 14:09:54 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 179D41A00B8 for ; Fri, 5 Sep 2014 14:09:54 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 7416BFA000A; Fri, 5 Sep 2014 21:09:51 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1409951390-20915-20914/12/83; Fri, 5 Sep 2014 21:09:50 +0000 From: Arnt Gulbrandsen To: endymail@ietf.org Date: Fri, 5 Sep 2014 23:09:50 +0200 User-Agent: Trojita/v0.4.1-243-g4a74770; Qt/4.8.4; X11; Linux; Ubuntu 13.10 Mime-Version: 1.0 Message-Id: <3f2f1eb8-c723-47d0-9c77-e3b35341d865@gulbrandsen.priv.no> In-Reply-To: <20140905192712.XG2Xmr5N%sdaoden@yandex.com> References: <20140829091133.GA25723@yeono.kjorling.se> <20140904132955.GN603@yeono.kjorling.se> <20140905192712.XG2Xmr5N%sdaoden@yandex.com> Content-Type: text/plain; charset=utf-8; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/bB6mO0pTZqb12Yfgx1tYlnmAM0Y 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, 05 Sep 2014 21:09:59 -0000 On Friday, September 5, 2014 8:27:12 PM CEST, Steffen Nurpmeso wrote: > I don't know how many messages are sent over SMTP each day, but it > would be interesting to know how much energy all those useless > roundtrip packets consume which are necessary to get upgrade > a SMTP session via STARTTLS, and how many percent of those > connections could also instantiate a non-existent SMTPS instead, > not requiring these upgrades. Practically zero and who cares. TLS negotiation doesn't grow more expensive if you send a few bytes of cleartext before the client hello. Arnt From nobody Fri Sep 5 14:25:46 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 7DE771A02E1 for ; Fri, 5 Sep 2014 14:25:45 -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 nCOOCgS0qvGq for ; Fri, 5 Sep 2014 14:25:44 -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 868AC1A0305 for ; Fri, 5 Sep 2014 14:25:38 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 00C6D2AB2C5; Fri, 5 Sep 2014 21:25:37 +0000 (UTC) Date: Fri, 5 Sep 2014 21:25:37 +0000 From: Viktor Dukhovni To: endymail@ietf.org Message-ID: <20140905212537.GY26920@mournblade.imrryr.org> References: <20140829091133.GA25723@yeono.kjorling.se> <20140904132955.GN603@yeono.kjorling.se> <20140905192712.XG2Xmr5N%sdaoden@yandex.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140905192712.XG2Xmr5N%sdaoden@yandex.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/WUGyINbVTeMqJMI2iI8Q7ai9dGM 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, 05 Sep 2014 21:25:45 -0000 On Fri, Sep 05, 2014 at 08:27:12PM +0200, Steffen Nurpmeso wrote: > I don't know how many messages are sent over SMTP each day, but it > would be interesting to know how much energy all those useless > roundtrip packets consume which are necessary to get upgrade > a SMTP session via STARTTLS, and how many percent of those > connections could also instantiate a non-existent SMTPS instead, > not requiring these upgrades. SMTP is not that latency sensitive. Because SMTP starts in cleartext, servers can and do refuse to STARTTLS with clients they are going to reject due to poor IP reputation. There are other advantages. For example, the server learns the client's EHLO name before TLS, allowing it to base TLS policy (like requests for the client certificate) on the the client's EHLO name. And of course clients that fail to interoperably negotiate TLS can fall back to cleartext. All told, STARTTLS is a good fit for SMTP, which unlike HTTP is not nearly as sensitive to latency. -- Viktor. From nobody Fri Sep 5 14:59:20 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 1ADD71A01A5 for ; Fri, 5 Sep 2014 14:59:16 -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 PUyqHL8Tt7UV for ; Fri, 5 Sep 2014 14:59:14 -0700 (PDT) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67DB81A017C for ; Fri, 5 Sep 2014 14:59:14 -0700 (PDT) Received: by mail-lb0-f175.google.com with SMTP id u10so14054487lbd.20 for ; Fri, 05 Sep 2014 14:59:12 -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=AdTyN7ImjhDh5Tt62IyabdsLMOwnflmQvrRQWbW4r2w=; b=ZzBOexLqlICWUlmJp8g/G05KLGrcll90ZnpCNG8a0pv5OvsOi1KK4SjjQdSzwDRurl aU0ImLutAcuEODpIqiDm3NqL3CTKDvJQjaYO2+zuGnap80VNMdfKvm2MjyBMfDo/r9u8 0M80WcdyrF3jTFUUtIdadUAZUGnoINeQMgzIqkxj7GaW1hgC42Fj70Lp3yFRIxGKLN7X n9BimxCUpam2DtQ4NPI7pJLF/UL0jOqlPFm/U1snQeDNsSyjmjbQ8oRFG1WeCehrt0PX KSRi1+LJEfnCLznpGUpZslAzh7pGZNAGdO+XB88MNr/A042mT3hUvCTAQUWMexGNb1RL Lb5A== MIME-Version: 1.0 X-Received: by 10.152.36.101 with SMTP id p5mr14417425laj.31.1409954352612; Fri, 05 Sep 2014 14:59:12 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.122.50 with HTTP; Fri, 5 Sep 2014 14:59:12 -0700 (PDT) In-Reply-To: <20140905212537.GY26920@mournblade.imrryr.org> References: <20140829091133.GA25723@yeono.kjorling.se> <20140904132955.GN603@yeono.kjorling.se> <20140905192712.XG2Xmr5N%sdaoden@yandex.com> <20140905212537.GY26920@mournblade.imrryr.org> Date: Fri, 5 Sep 2014 17:59:12 -0400 X-Google-Sender-Auth: chi2Sgzxnpy8vsquKGcd6PzASsI Message-ID: From: Phillip Hallam-Baker To: Viktor Dukhovni Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/4YM2lnCGnPzQwi-KTMmXTosr-oo 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, 05 Sep 2014 21:59:16 -0000 On Fri, Sep 5, 2014 at 5:25 PM, Viktor Dukhovni wrote: > On Fri, Sep 05, 2014 at 08:27:12PM +0200, Steffen Nurpmeso wrote: > >> I don't know how many messages are sent over SMTP each day, but it >> would be interesting to know how much energy all those useless >> roundtrip packets consume which are necessary to get upgrade >> a SMTP session via STARTTLS, and how many percent of those >> connections could also instantiate a non-existent SMTPS instead, >> not requiring these upgrades. > > SMTP is not that latency sensitive. Because SMTP starts in cleartext, > servers can and do refuse to STARTTLS with clients they are going > to reject due to poor IP reputation. > > There are other advantages. For example, the server learns the > client's EHLO name before TLS, allowing it to base TLS policy (like > requests for the client certificate) on the the client's EHLO name. > And of course clients that fail to interoperably negotiate TLS can > fall back to cleartext. > > All told, STARTTLS is a good fit for SMTP, which unlike HTTP is > not nearly as sensitive to latency. Very good points and points that designers of DNS privacy approaches would do to bear in mind. Any protocol that has a server performing a public key transaction without any form of authentication on the request is going to end up being killed by DoS. So the trick is to pull the authentication out of the DNS query loop so it can be amortized. From nobody Fri Sep 5 15:10:18 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 579F61A0392 for ; Fri, 5 Sep 2014 15:10:16 -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 pV2vvbdwyqdS for ; Fri, 5 Sep 2014 15:10:14 -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 7CA101A0393 for ; Fri, 5 Sep 2014 15:10:13 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 38F082AB2C0; Fri, 5 Sep 2014 22:10:12 +0000 (UTC) Date: Fri, 5 Sep 2014 22:10:12 +0000 From: Viktor Dukhovni To: endymail Message-ID: <20140905221012.GC26920@mournblade.imrryr.org> References: <20140829091133.GA25723@yeono.kjorling.se> <20140904132955.GN603@yeono.kjorling.se> <20140905192712.XG2Xmr5N%sdaoden@yandex.com> <20140905212537.GY26920@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/mJ1kAdKbf38sLpE0VbecGWpc6xY Subject: Re: [Endymail] Hashes of key as addresses X-BeenThere: endymail@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: endymail List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 22:10:16 -0000 On Fri, Sep 05, 2014 at 05:59:12PM -0400, Phillip Hallam-Baker wrote: > > SMTP is not that latency sensitive. Because SMTP starts in cleartext, > > servers can and do refuse to STARTTLS with clients they are going > > to reject due to poor IP reputation. > > > > There are other advantages. For example, the server learns the > > client's EHLO name before TLS, allowing it to base TLS policy (like > > requests for the client certificate) on the the client's EHLO name. > > And of course clients that fail to interoperably negotiate TLS can > > fall back to cleartext. > > > > All told, STARTTLS is a good fit for SMTP, which unlike HTTP is > > not nearly as sensitive to latency. > > Very good points and points that designers of DNS privacy approaches > would do to bear in mind. Any protocol that has a server performing a > public key transaction without any form of authentication on the > request is going to end up being killed by DoS. Postfix can also rate limit run-away clients that rapidly create uncached sessions, rather than reuse established sessions. This behaviour can be "stress-dependent", when the service process limit has recently been reached. While not widely deployed by default, such counter-measures are good to have up one's sleeve. > So the trick is to pull the authentication out of the DNS query loop > so it can be amortized. Similiar ammortization ideas in DJB's MinimaLT, suggestions for short-term re-use of ECDH exponents with 25519, ... Also in much more mundane process-reuse in Postfix, where each service handles 100 or so requests by default before exiting, ammortizing start-up cost. -- Viktor. From nobody Fri Sep 5 23:38:56 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 487C91A6F6D for ; Fri, 5 Sep 2014 23:38:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.253 X-Spam-Level: X-Spam-Status: No, score=-14.253 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.652, 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 VGXYgqzseOpQ for ; Fri, 5 Sep 2014 23:38:52 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 574A41A00E4 for ; Fri, 5 Sep 2014 23:38:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1290; q=dns/txt; s=iport; t=1409985532; x=1411195132; h=message-id:date:from:mime-version:to:subject; bh=qoTBw7gl6w6ez6eOZ+UUAq9WDQS5mzdj4kCPZRh7CPc=; b=ePNJTvZ3MhRNlMZpkvf71cA4EWpehGKXM7hj7iAaVN7Y1eDXWS3UdLa3 AzaX+9s3DL7wznYxInXH5gsh8jDTH2gL6zHPKX/7mA86BcIw8BwK2V0MY xvJfWWHZ+iNhoTwnjB4f/vpIlRiLbGAk8ZCOdOGNq0EpsM79ffaNRSPYM Q=; X-Files: signature.asc : 486 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoQLACGrClStJssW/2dsb2JhbABagyU7V4J8smCTTIhnd4QtVT0WCwILAwIBAgE/GQgBAYg+DZpXjy+VKgETBI58AQFsgmOBUwEEhQoCjjiBSmCGfoc8jWqDYzsvgQ+BQAEBAQ X-IronPort-AV: E=Sophos;i="5.04,478,1406592000"; d="asc'?scan'208";a="167989426" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 06 Sep 2014 06:38:49 +0000 Received: from [10.61.93.218] (ams3-vpn-dhcp7643.cisco.com [10.61.93.218]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s866cmsE005929 for ; Sat, 6 Sep 2014 06:38:49 GMT Message-ID: <540AABF8.8000605@cisco.com> Date: Sat, 06 Sep 2014 08:38:48 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: endymail@ietf.org Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XgDnW7GugIejroda5WRvRC9FHW4lRaeQe" Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/hhkjyvDWBJcS6uEqsDXeqFCEeIk Subject: [Endymail] spam versus cleartext 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: Sat, 06 Sep 2014 06:38:54 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --XgDnW7GugIejroda5WRvRC9FHW4lRaeQe Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi everyone, In the early days fo perpass we had lengthy discussions about the tension between privacy and ability of security systems to reduce spam.=20 Below is an article from a gentleman who used to work at Google, which I thought this group might find interesting. https://moderncrypto.org/mail-archive/messaging/2014/000780.html Eliot --XgDnW7GugIejroda5WRvRC9FHW4lRaeQe Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQEcBAEBAgAGBQJUCqv5AAoJEIe2a0bZ0nozFnsIANTSg1mtR3q/XNhJjxt5szzs JEGVFhXiL7NDNXDCc/C/8GndsnqtzLdiyL13QIJWHuyxWEHz7JL4L/9tZp6r2UI9 9tBrBy7AEwwq4Yv0PzXkkWWUwPOEhp7S59snrnhEip674rEVI4m3/vtKgYJnglXf um5q8yZOsA6PDs1g98/gkzeW8piz90MStM4ezJ4qYZyLOoGX8F42yvI0+ThwvpNa 2qQAIA3Vr4O1Z1biXMU80+3+KtWifgqaiTXcrVeoUG2OU4m0JwKBUYxaPWkPBkQJ U8dBBpAhY0tViJndqlPFsz7N95Ty+lfsrk4mJ2wiCeW9TlmtgR57e9862PLFq5Q= =BAmK -----END PGP SIGNATURE----- --XgDnW7GugIejroda5WRvRC9FHW4lRaeQe-- From nobody Sat Sep 6 05:34:29 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 2E2091A0368 for ; Sat, 6 Sep 2014 05:34:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 45FooXMoC87L for ; Sat, 6 Sep 2014 05:34:26 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id D7AD31A0361 for ; Sat, 6 Sep 2014 05:34:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 41835BE10; Sat, 6 Sep 2014 13:34:25 +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 9oUIZ5MlEBVt; Sat, 6 Sep 2014 13:34:23 +0100 (IST) Received: from [10.87.48.3] (unknown [86.46.29.100]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id C1A55BE0F; Sat, 6 Sep 2014 13:34:23 +0100 (IST) Message-ID: <540AFF4F.30407@cs.tcd.ie> Date: Sat, 06 Sep 2014 13:34:23 +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: Eliot Lear , endymail@ietf.org References: <540AABF8.8000605@cisco.com> In-Reply-To: <540AABF8.8000605@cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/P4c6jqOSwwKN5iNuTC4Ju1phciQ Subject: Re: [Endymail] spam versus cleartext 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: Sat, 06 Sep 2014 12:34:27 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hiya, On 06/09/14 07:38, Eliot Lear wrote: > Hi everyone, > > In the early days fo perpass we had lengthy discussions about the > tension between privacy and ability of security systems to reduce > spam. Below is an article from a gentleman who used to work at > Google, which I thought this group might find interesting. > > https://moderncrypto.org/mail-archive/messaging/2014/000780.html That's a good posting all right. And I agree that anyone who's trying to offer a solution in this space has to meet the really hard challenge of producing a system that doesn't allow spam to take over. But recall that this list is not here to design or pick a solution, but rather to see what bits of IETF work might enable some solutions to evolve successfully. So it is valid to e.g. say that some key management foo or message format bar work would be needed and valuable to standardise even while we don't have a solution available for the spam problem. Cheers, S. > > Eliot > > > > _______________________________________________ Endymail mailing > list Endymail@ietf.org > https://www.ietf.org/mailman/listinfo/endymail > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJUCv9LAAoJEC88hzaAX42iSUcH/i4nqy5yxnSp4Yjs+bqZb61D gMrpS4KPC4gjDUQsuwaorMnpeyqStoInVGvJu+ZTMr5gC2uYLwMIKsDCWocZXfER J28Co/UyBvu/FIvaNrn1GcNcGGjzd7DyiaiPa0n+pEN9uDKiZOeC97gaNd7PgHl1 DDaEQhWZpcadcyjD4y95WXHPaXwOiw56oTDzXNnW1xDGXYr1qLJLZhE4UNDUGqsp qVXZ4qiwqFTm8JCnHayJ68OoYfm0ZB+KynGRgH/T9DEYBctv4yVo2AH028btTKxE baKDNuuIy/EPPps+gd0V2G/4w+umYja/QYI0mr0qdLARp8QS6pkXaN/8wE9nZBY= =6Njx -----END PGP SIGNATURE----- From nobody Sat Sep 6 06:16:08 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 7BB051A0382 for ; Sat, 6 Sep 2014 06:16:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.152 X-Spam-Level: X-Spam-Status: No, score=-16.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.652, 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 IQlck2xBIxpf for ; Sat, 6 Sep 2014 06:16:06 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73A491A031D for ; Sat, 6 Sep 2014 06:16:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5909; q=dns/txt; s=iport; t=1410009365; x=1411218965; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=t8konL9skVxJRo+QcVgJqSoIdHSkopfmJ1pjtkM4VIY=; b=ealUUQHWa6Yk945JdNIm/1Gf8LoZwZ2hPMvPFJDTXIfXgpqcK5VMqPgZ 1EIjMILwNlmMjwExC1BIFzm9IYwTw3RjO3o2H8dIzoCDax+CABXSgdkQ1 KtoioHpMNp3yzxAGZ9J2p9aZ6m+CJfyoSG2zdX9GyK0uT7wSfnWnrPZCs U=; X-Files: signature.asc : 486 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApQLAJ8IC1StJssW/2dsb2JhbABZgyU7V4J8sniTQgEJhnlTAYEWd4QDAQEBAwEBAQEgSwoGCwsEFAkWCwICCQMCAQIBFTAGAQwGAgEBF4gfCA2pBZUkARMEjnwBAVaCeYFTAQSFCgKOOIFKYIZ+hzyNaoNjOy+BD4FAAQEB X-IronPort-AV: E=Sophos;i="5.04,479,1406592000"; d="asc'?scan'208,217";a="163591818" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 06 Sep 2014 13:16:03 +0000 Received: from [10.61.93.218] (ams3-vpn-dhcp7643.cisco.com [10.61.93.218]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s86DG24v011715; Sat, 6 Sep 2014 13:16:02 GMT Message-ID: <540B0911.9050105@cisco.com> Date: Sat, 06 Sep 2014 15:16:01 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Stephen Farrell , endymail@ietf.org References: <540AABF8.8000605@cisco.com> <540AFF4F.30407@cs.tcd.ie> In-Reply-To: <540AFF4F.30407@cs.tcd.ie> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="U1B7Rfsm4Q6kXTh21WW8KN7imAtSgoeXI" Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/UcDaB2dR6QAz9rksGcA2zeZrvNE Subject: Re: [Endymail] spam versus cleartext 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: Sat, 06 Sep 2014 13:16:07 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --U1B7Rfsm4Q6kXTh21WW8KN7imAtSgoeXI Content-Type: multipart/alternative; boundary="------------020207070509040601050107" This is a multi-part message in MIME format. --------------020207070509040601050107 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Stephen, While I think it would be fun to talk with the gentleman about his bitcoin thinking, the key part that I intended for this group was the situational analysis involving spam and how bad guys behave. Eliot On 9/6/14, 2:34 PM, Stephen Farrell wrote: > > Hiya, > > On 06/09/14 07:38, Eliot Lear wrote: > > Hi everyone, > > > In the early days fo perpass we had lengthy discussions about the > > tension between privacy and ability of security systems to reduce > > spam. Below is an article from a gentleman who used to work at > > Google, which I thought this group might find interesting. > > > https://moderncrypto.org/mail-archive/messaging/2014/000780.html > > That's a good posting all right. And I agree that anyone who's > trying to offer a solution in this space has to meet the really > hard challenge of producing a system that doesn't allow spam to > take over. > > But recall that this list is not here to design or pick a solution, > but rather to see what bits of IETF work might enable some > solutions to evolve successfully. So it is valid to e.g. say that > some key management foo or message format bar work would be > needed and valuable to standardise even while we don't have a > solution available for the spam problem. > > Cheers, > S. > > > > > Eliot > > > > > _______________________________________________ Endymail mailing > > list Endymail@ietf.org > > https://www.ietf.org/mailman/listinfo/endymail > > > _______________________________________________ > Endymail mailing list > Endymail@ietf.org > https://www.ietf.org/mailman/listinfo/endymail > > --------------020207070509040601050107 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Stephen,

While I think it would be fun to talk with the gentleman about his bitcoin thinking, the key part that I intended for this group was the situational analysis involving spam and how bad guys behave.

Eliot


On 9/6/14, 2:34 PM, Stephen Farrell wrote:

Hiya,

On 06/09/14 07:38, Eliot Lear wrote:
> Hi everyone,

> In the early days fo perpass we had lengthy discussions about the
> tension between privacy and ability of security systems to reduce
> spam. Below is an article from a gentleman who used to work at
> Google, which I thought this group might find interesting.
=
> https://moderncrypto.org/mail-a= rchive/messaging/2014/000780.html

That's a good posting all right. And I agree that anyone who's
trying to offer a solution in this space has to meet the really
= hard challenge of producing a system that doesn't allow spam to
= take over.

But recall that this list is not here to design or pick a solution,
but rather to see what bits of IETF work might enable some
solutions to evolve successfully. So it is valid to e.g. say that some key management foo or message format bar work would be
needed and valuable to standardise even while we don't have a
solution available for the spam problem.

Cheers,
S.



> Eliot



> _______________________________________________ Endymail mailing
> list Endymail@ietf.org
> https://www.ietf.org/mailman/listinfo/endyma= il

>
> _______________________________________________
> Endymail mailing list
> Endymail@ietf.org
> https://www.ietf.org/mailman/listinfo/endyma= il
>
>


--------------020207070509040601050107-- --U1B7Rfsm4Q6kXTh21WW8KN7imAtSgoeXI Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQEcBAEBAgAGBQJUCwkRAAoJEIe2a0bZ0nozoJ8IALriEJfoY+1mM3fNrAGRsRzp Zb2L6xEXcLmargUqXYFbqb8wzeaD0RnMiNwmbHg2RjHd1Ttqj/lfr8UEAu5XqkL+ 46/2l/tUAtQ5QRc9OXXobZRFJExRx2ygD9y6ypfFX/hg5pboy8FhDh/4ZNhRUpJ9 FXiyBAAKqxofRHZzR57mPSW4wFT9rGMbZ51cl5rs0AK/FIK5GaKwh3Mz8G0FD/IW IYH4TejG0T6Kz07LsyBX1JQie//WwTu8/ihE+DJ5N0p6nu24LjruXmprynbzSUCx YB7F5u0mOUNGpi6zFEB+QlaHtlc/oxYn2tKi0qkX0F+RY+wSUzr2wVSmFUIzwrw= =Z9R+ -----END PGP SIGNATURE----- --U1B7Rfsm4Q6kXTh21WW8KN7imAtSgoeXI-- From nobody Sat Sep 6 07:54:12 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 BABF91A0416 for ; Sat, 6 Sep 2014 07:54:11 -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 CNAARV0K6F4m for ; Sat, 6 Sep 2014 07:54:10 -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 934D61A040F for ; Sat, 6 Sep 2014 07:54:10 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id E58592AB2AC; Sat, 6 Sep 2014 14:54:09 +0000 (UTC) Date: Sat, 6 Sep 2014 14:54:09 +0000 From: Viktor Dukhovni To: endymail@ietf.org Message-ID: <20140906145409.GI26920@mournblade.imrryr.org> References: <540AABF8.8000605@cisco.com> <540AFF4F.30407@cs.tcd.ie> <540B0911.9050105@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <540B0911.9050105@cisco.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/--GtDB1cfri5gS9vsARMxEC0duM Subject: Re: [Endymail] spam versus cleartext 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: Sat, 06 Sep 2014 14:54:11 -0000 On Sat, Sep 06, 2014 at 03:16:01PM +0200, Eliot Lear wrote: > While I think it would be fun to talk with the gentleman about his > bitcoin thinking, the key part that I intended for this group was the > situational analysis involving spam and how bad guys behave. For many users there are parties to their email service that want to apply additional content security policies beyond the immediate personal security interests of the user. Sometimes it is a service to user (less spam), other times it is corporate security policy (block malware, detect data leakage, comply with regulatory email archiving requirements, ...). This is why I generally think of protecting email as two separate problems: * data in motion * data at rest for data in motion, I am working on more flexibility and security with STARTTS. For data at rest, I'd like to see LMTP servers that support S/MIME encryption at time of final delivery, which still allows various processing of email before it is deposited into the mailbox. This extends PFS to email already delivered before any warrants are served to intercept content. Of course it does not protect email received while under surveillance. While truly end-to-end email is used already, and may be used more widely in the future, I don't expect mass adoption, there are many obstacles beyond just the key management. -- Viktor. From nobody Sat Sep 6 09:23: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 7AC731A048D for ; Sat, 6 Sep 2014 09:23:04 -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 03zOQ5Lhhoz1 for ; Sat, 6 Sep 2014 09:23:03 -0700 (PDT) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38F3D1A045C for ; Sat, 6 Sep 2014 09:23:03 -0700 (PDT) Received: by mail-la0-f47.google.com with SMTP id el20so6965427lab.34 for ; Sat, 06 Sep 2014 09:23:01 -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=Q/l3pPcMhBIcxOTJ4gNeuXBseFf2tJibZP1jtq5Z2X8=; b=CPcKLXMkEPE/z2tkL8d+1PUyAXoAH5tOhzI5DNJImQAj44T4gD4FpUtqX120Pd5UhV JiI2Cv64HRru4Hz2iFzwcRTVxEKAVxhBEN/qmBUXbvqgB40lEbl+PDnnX/JfHLcz1woQ /rNihSs9sqWTMQiJBaBzrAaUjqrFZIsBWWMW0WF9e7pbqw19oRu1xlqjiH14uXN+aozq F++Ab1KNBFSSiSX+x+i9OUojMll4va4JGvXOqO5T3rN3Kbp1hKrgKng2T29Mrt5128Kl NHMeIlghh6GmHNah4tAnqNzhSM5NIw9dyHYjmI2o0CEf4Io2cfcoYezBCfKXsGevnxT8 euUQ== MIME-Version: 1.0 X-Received: by 10.152.19.5 with SMTP id a5mr18459972lae.21.1410020581431; Sat, 06 Sep 2014 09:23:01 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.122.50 with HTTP; Sat, 6 Sep 2014 09:23:01 -0700 (PDT) In-Reply-To: <540B0911.9050105@cisco.com> References: <540AABF8.8000605@cisco.com> <540AFF4F.30407@cs.tcd.ie> <540B0911.9050105@cisco.com> Date: Sat, 6 Sep 2014 12:23:01 -0400 X-Google-Sender-Auth: -JzYUDXAbwdv1Ugg01JoRKgKFwY Message-ID: From: Phillip Hallam-Baker To: Eliot Lear Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/_et3hZQRrV2ysXb6IueB0StYAPc Cc: endymail , Stephen Farrell Subject: Re: [Endymail] spam versus cleartext 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: Sat, 06 Sep 2014 16:23:04 -0000 On Sat, Sep 6, 2014 at 9:16 AM, Eliot Lear wrote: > Hi Stephen, > > While I think it would be fun to talk with the gentleman about his bitcoin > thinking, the key part that I intended for this group was the situational > analysis involving spam and how bad guys behave. Well spam prevention is where a lot of the proof of work stuff got its start. I don't have an implementation for this yet but this is my strategy * An endy-key is a key that is held by an end user at their device. * All mail is encrypted at the message layer when possible but not all mail is encrypted under an endy-key. * Domains may publish keys for use where an endy-key is not available or use is not authorized. * Use of an endy-key has to be specifically authorized. This is because (1) I have to read my mail on every device I use and that isn't practical till I can install decryption keys easily and (2) to enable abuse filtering. * The only normal user interaction here would be identifying mail as spam. * Users with really extreme privacy concerns like Greenwald/Snowden might exchange per user endykeys but this would be the exception, not the rule. From nobody Sat Sep 6 12:33: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 7BDB51A0167 for ; Sat, 6 Sep 2014 12:33:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.563 X-Spam-Level: * X-Spam-Status: No, score=1.563 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, 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 yCEZ0qadcXrJ for ; Sat, 6 Sep 2014 12:33:39 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C78D31A00C6 for ; Sat, 6 Sep 2014 12:33:37 -0700 (PDT) Received: (qmail 52890 invoked from network); 6 Sep 2014 19:33:35 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 6 Sep 2014 19:33:35 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=21e5.540b618f.k1409; i=johnl@user.iecc.com; bh=vf0UBDtVp3+l8lbMR8d0FJN9ED+WND031twqVGLfeMY=; b=JHkmiEtTM7a0Wxo05Femxrhb4gBRmOLudfaUdlLUDm+9KOeVGEzhndtWadZ8O7MeJI6H06O+azJ6FPPtObgwVLlUYExTGQpzyHSxxTpQil7llnRQQCccx1epCswEK+ey5dLQPc1t8/qOfvBof1WFGaprH8gqxo2Oq8ddrQVgBLM3h24oZVnMsnj/+29fd8F3R9Tg4Esb76WAZzvVZpmoUeIghz5sRKyHeqFFXYaKQvsYMyCJ0r+yd5TqBOlq83kF DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=21e5.540b618f.k1409; olt=johnl@user.iecc.com; bh=vf0UBDtVp3+l8lbMR8d0FJN9ED+WND031twqVGLfeMY=; b=Fzlxus5dNISSJz7CY5tFdsTyBWwaM7Emobf+SSiJunlhn8LtDxKBR88hEmCPaie/nyU2nN9zWk3Kj5/6MgWHbeTIJh0qdfuVjlxJ5ZSjlARBCuJBx3c59hYFA2IyZHj57hfvePydB6qF7WJfn4FL1q5sEaZb2nTv1/KO8xUtOuezEhcJ/WsUCZ/JJbQHaqwTPqo8eH8ki76S6chQHSYBjgGveJnHhqRlm834Fp7MxP12abrGN1VW0qHepk/9I2QE Date: 6 Sep 2014 19:33:13 -0000 Message-ID: <20140906193313.8676.qmail@joyce.lan> From: "John Levine" To: endymail@ietf.org In-Reply-To: <540B0911.9050105@cisco.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/I9n7VSbTlqtKr7fzOseKDo5Cx14 Cc: lear@cisco.com Subject: Re: [Endymail] spam versus cleartext 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: Sat, 06 Sep 2014 19:33:40 -0000 >While I think it would be fun to talk with the gentleman about his >bitcoin thinking, the key part that I intended for this group was the >situational analysis involving spam and how bad guys behave. The historical discussion is pretty good, give or take some minor sequencing errors. (Web mail is a lot older than he makes it out to be, for example.) The bit at the end with bitcoins and reputation bonds is just nonsense. (It's longstanding nonsense -- back in 2009, one of Satoshi's first messages to the cryptography list suggested using them for epostage, and I responded saying that wasn't likely to be a good idea, thereby making me a bitcoin pioneer in the eyes of the Wall Street Journal.) I will spare you the long rant about why it won't work, but the rant touches on the facts that bad guys have access to more computing power than good guys, that bitcoin transactions are not fast and not inherently cheap, and bad guys are just as creative as good guys and are good at subverting systems intended to keep them out. What I think will actually happen is twofold. Many mail operators will tell their users that if they let the mail system look at their mail under tightly controlled conditions (for some definitions of tight and control) their spam filtering will be a lot better, and about 95% of the users will say yes. For free webmail systems, it'll be a condition of service, since the tight control will include using the mail contents to target ads. For the other 5%, strong crypto will presumably include a hard to forge signature from the sender, so they can whitelist senders with some painful way to get new senders into your local whitelist. I think it's a very open question whether E2E crypto on mail will turn out to be so painful that people won't bother, outside of small clusters of people who already know each other and so can exchange keys in ways that are formally hopeless but in practice work OK. R's, John From nobody Sun Sep 7 06:21:47 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 826EA1A035F for ; Sun, 7 Sep 2014 06:21:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.653 X-Spam-Level: X-Spam-Status: No, score=-8.653 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=-1.652, 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 Swq2oJkMYM8a for ; Sun, 7 Sep 2014 06:21:42 -0700 (PDT) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF5181A033D for ; Sun, 7 Sep 2014 06:21:42 -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=1410096102; x=1441632102; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=F7SJvhuNYN1nlc4YPPzTERb/yEimqV3rLPTFXOKCzGo=; b=jsBUl6riCpG5XnoUx2+cOp3LVhFL88hNTLQX0wGIBnZbFN/vFWAdR0x6 /KMWDcnaGYWmNTKiapFbrptVaL9CXmUx2OGL596h/ojZlKYNTpUdkx9M8 SiA5k6SoMvVpMyu+ZHUdqjJWUrAUeLjxYbb4Ri/1kDtwHwGghayv60G0S U=; X-IronPort-AV: E=McAfee;i="5600,1067,7553"; a="73651729" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by sabertooth01.qualcomm.com with ESMTP; 07 Sep 2014 06:21:42 -0700 X-IronPort-AV: E=Sophos;i="5.04,482,1406617200"; d="scan'208";a="745967311" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 07 Sep 2014 06:21:42 -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; Sun, 7 Sep 2014 06:21:41 -0700 Message-ID: <540C5BE1.6010405@qti.qualcomm.com> Date: Sun, 7 Sep 2014 10:21:37 -0300 From: Pete Resnick 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: Eliot Lear References: <540AABF8.8000605@cisco.com> In-Reply-To: <540AABF8.8000605@cisco.com> 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/Hkv0vfehbsZhsiW1SEcsZQ9SLyE Cc: endymail@ietf.org Subject: Re: [Endymail] spam versus cleartext 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: Sun, 07 Sep 2014 13:21:44 -0000 On 9/6/14 3:38 AM, Eliot Lear wrote: > In the early days fo perpass we had lengthy discussions about the > tension between privacy and ability of security systems to reduce spam. > Below is an article from a gentleman who used to work at Google, which I > thought this group might find interesting. > > https://moderncrypto.org/mail-archive/messaging/2014/000780.html > Along similar lines to what John Levine said,: Obviously doing e2e crypto gets you signatures. Since we are blue-skying here, I think it is perfectly plausible to say, "If you want to send me e2e encrypted messages, you also have to send me signed messages, and you don't or your signature is not in my contacts list already, your encrypted mail is going to bounce." I think it's possible that in the fullness of time, many users go to a contact-list model of email (a la IM) where the mail simply bounces unless it has a signature that is already in the contacts list. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Sun Sep 7 07:09:47 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 659351A04B7 for ; Sun, 7 Sep 2014 07:09:45 -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 jM1yFqENZ9Qs for ; Sun, 7 Sep 2014 07:09:44 -0700 (PDT) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010: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 DE5B11A04B0 for ; Sun, 7 Sep 2014 07:09:43 -0700 (PDT) Received: by mail-la0-f43.google.com with SMTP id gi9so4873962lab.16 for ; Sun, 07 Sep 2014 07:09:42 -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=GMBD/U2PhqOEvlLDV/7RoyWOTpmg4Kc2vNmuS5Ct5+c=; b=YUhec5nTscnXlwq+OX0dIYyW1PcaLOIUKFsAj7jzQp5RXtM01yaFnXWRZ1WL3C8j7Z Hbnu7pZswHWGxegB7U87c9NyK4HSoxtONzcqmj3PMjJQNaRbmPO2YUL4qjrjUFY9/8v4 KCstFZk6ksoxUUqPeYRog80jUcqkJ6u4dVYNvFZtLhz67E1aZBuB8Bqp+q/+4seCa1HW S2fFIAI0aW8lfUzC4fbb6xon6C+CD+8fPe4iYgZklr6kwRJEM6ncjmWcCaG9lLIG25YX jSo7HHdZcIgnudt+mv8J6fCQzgR/0SCctKebEnSvCzUTcjbuvcAwXcKVY8G5yAu+DKqE 0CKA== MIME-Version: 1.0 X-Received: by 10.152.26.133 with SMTP id l5mr10366359lag.4.1410098982074; Sun, 07 Sep 2014 07:09:42 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.122.50 with HTTP; Sun, 7 Sep 2014 07:09:41 -0700 (PDT) In-Reply-To: <540C5BE1.6010405@qti.qualcomm.com> References: <540AABF8.8000605@cisco.com> <540C5BE1.6010405@qti.qualcomm.com> Date: Sun, 7 Sep 2014 10:09:41 -0400 X-Google-Sender-Auth: X2UTWreP1Oul2CoMlGJb-9uhYjg Message-ID: From: Phillip Hallam-Baker To: Pete Resnick Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/q2JtLozr0U_E45_NQLYRY01Oogo Cc: endymail , Eliot Lear Subject: Re: [Endymail] spam versus cleartext 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: Sun, 07 Sep 2014 14:09:45 -0000 On Sun, Sep 7, 2014 at 9:21 AM, Pete Resnick wrote: > On 9/6/14 3:38 AM, Eliot Lear wrote: >> >> In the early days fo perpass we had lengthy discussions about the >> tension between privacy and ability of security systems to reduce spam. >> Below is an article from a gentleman who used to work at Google, which I >> thought this group might find interesting. >> >> https://moderncrypto.org/mail-archive/messaging/2014/000780.html >> > > > Along similar lines to what John Levine said,: Obviously doing e2e crypto > gets you signatures. Since we are blue-skying here, I think it is perfectly > plausible to say, "If you want to send me e2e encrypted messages, you also > have to send me signed messages, and you don't or your signature is not in > my contacts list already, your encrypted mail is going to bounce." I think > it's possible that in the fullness of time, many users go to a contact-list > model of email (a la IM) where the mail simply bounces unless it has a > signature that is already in the contacts list. I think that is right, but not the whole picture. I see endymail as a subset of mail. All mail should be encrypted at the message layer but only whitelisted mail would be e2e encrypted. This can be done automatically as follows: A) Some sort of discovery infrastructure maps email addresses to key hashes. B) Some sort of discovery infrastructure maps key hashes to keys. C) Inbound mail server has an encryption key D) User has an endymail encryption key. 1) Alice sends a message to Bob , she doesn't know him yet. Alice's email client uses infrastructure A and B to pull the best public data for bob. This turns out to be a domain level record with the mail server key (C). Mail is opportunistically encrypted under the mail server key (C). Mail server decrypts then (optional) re-encrypts message for delivery to Bob. The sent mail includes a header with Alice's encryption key fingerprint. It is signed using either DKIM or S/MIME depending on the settings specified in the key record. 2) Bob receives message 2a) Bob reads message hits the 'spam' key 2b) Bob reads message, does nothing 2c) Bob replies to message Only 2c is going to result in Bob's client whitelisting Alice. His response contains the key fingerprint that Bob needs to perform retrieval of the key using infrastructure B. 3) Alice sends another message to Bob after his reply Client notes that it is whitelisted and pulls the key from infrastructure B. Note: 1) This whole process is completely frictionless. Neither Alice nor Bob has to do anything differently. 2) This is only one point on the security spectrum. In other applications we might allow easier access to the endy key or might not allow access at all. 3) The reason for decoupling the key from the system via a key hash is that it enables key rollover. One question left open in the above is how we prevent the use of infrastructure A as a means to obtain email addresses. I am currently working on efficient ways to do that. From nobody Sun Sep 7 07:13: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 9D25E1A04B7 for ; Sun, 7 Sep 2014 07:13:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OHRYjFJ0XaEX for ; Sun, 7 Sep 2014 07:13:07 -0700 (PDT) Received: from mail-qg0-x22d.google.com (mail-qg0-x22d.google.com [IPv6:2607:f8b0:400d:c04::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7C941A04C5 for ; Sun, 7 Sep 2014 07:13:05 -0700 (PDT) Received: by mail-qg0-f45.google.com with SMTP id j107so1195516qga.18 for ; Sun, 07 Sep 2014 07:13:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=MkBrfMdShNcW4AC4/cnhv6ET6NnjodIBEMDp+ayTWBo=; b=QVDrKHRSzyvzeoy3+4+hb9VrLzezBWWgL9AA00zEJkB4dNZAqWy5ht+ekd4fuewZo7 VNkS7pRcOo30Bxp4IdwykRmrUEAxdEtt+yIcn83VPmye6IIplOQm9kzZfpB1MftTbfeB uJ+sYD1v2DcN9S5FntqKaZl6px0p7Zvx6bJJ0midJg25wFYwEez2tz/sM7ALBB0+eA0e RBQPp8BRtGDNHC/wxBvLm8AHFzmZqd4q/kqcp14kf+0xB2WpZE4In6fXGhGqya+vSJ75 mTpK8tW1aKFNZVxLemRPC1f1vxCEOUq8LL6/jHIdTjVDHCyQfB/me8Pqb1idD8YRdwVf fh8Q== X-Received: by 10.229.68.131 with SMTP id v3mr34229955qci.10.1410099184883; Sun, 07 Sep 2014 07:13:04 -0700 (PDT) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net. [76.218.8.156]) by mx.google.com with ESMTPSA id w9sm5474134qad.31.2014.09.07.07.13.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 07 Sep 2014 07:13:04 -0700 (PDT) Message-ID: <540C6731.7040805@gmail.com> Date: Sun, 07 Sep 2014 07:09:53 -0700 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Pete Resnick References: <540AABF8.8000605@cisco.com> <540C5BE1.6010405@qti.qualcomm.com> In-Reply-To: <540C5BE1.6010405@qti.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/52N4LR4DRz-QYePQl1wXzpGnvlM Cc: endymail@ietf.org Subject: Re: [Endymail] spam versus cleartext 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: Sun, 07 Sep 2014 14:13:12 -0000 On 9/7/2014 6:21 AM, Pete Resnick wrote: > Obviously doing e2e > crypto gets you signatures. No it doesn't. As a matter of practice, it probably will, but the technology does not require it. Sigs are an entirely independent action when doing object encryption. > Since we are blue-skying here, I think it is > perfectly plausible to say, "If you want to send me e2e encrypted > messages, you also have to send me signed messages, So you want to eliminate anonymous communications? Anonymity has historical importance for some kinds of communication. > and you don't or > your signature is not in my contacts list already, your encrypted mail > is going to bounce." I think it's possible that in the fullness of time, > many users go to a contact-list model of email (a la IM) where the mail > simply bounces unless it has a signature that is already in the contacts > list. The Procrustean bed always makes things simpler, and with only a few, uhhh... shortcomings. My point is not that signing is bad or checking against address books is bad, but that mandating such things constrains legitimate communication in important ways. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sun Sep 7 07:34:13 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 833861A0503 for ; Sun, 7 Sep 2014 07:34:12 -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 XRpZlp8mu7hl for ; Sun, 7 Sep 2014 07:34:11 -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 886C61A04B9 for ; Sun, 7 Sep 2014 07:34:11 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 5EA152AB2C0; Sun, 7 Sep 2014 14:34:10 +0000 (UTC) Date: Sun, 7 Sep 2014 14:34:10 +0000 From: Viktor Dukhovni To: endymail@ietf.org Message-ID: <20140907143410.GN26920@mournblade.imrryr.org> References: <540AABF8.8000605@cisco.com> <540C5BE1.6010405@qti.qualcomm.com> <540C6731.7040805@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <540C6731.7040805@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/S9ZN8GCPBLDN6DcdA_yAWzdO50o Subject: Re: [Endymail] spam versus cleartext 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: Sun, 07 Sep 2014 14:34:12 -0000 On Sun, Sep 07, 2014 at 07:09:53AM -0700, Dave Crocker wrote: > > Since we are blue-skying here, I think it is > > perfectly plausible to say, "If you want to send me e2e encrypted > > messages, you also have to send me signed messages, > > So you want to eliminate anonymous communications? Anonymity has > historical importance for some kinds of communication. Signatures can be pseudonymous. In the scheme Phillip proposed, where whitelisting for encryption is an action akin to adding to the contact list or replying with an attached key, ... There is nothing that requires Alice's signature to assert her "true" identity. Since email already carries identifying information in the form of the reply mailbox address (also pseudonymous). The signature does not add new constraints. Thus to send mail that is encrypted all the way to the user, not just the gateway, the sender needs a pseudonymous mailbox with an associated signature plus a willingness by the recipient to whitelist an initial communication that is not e2e. -- Viktor. From nobody Sun Sep 7 07:54:54 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 D70F81A04F8 for ; Sun, 7 Sep 2014 07:54:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.653 X-Spam-Level: X-Spam-Status: No, score=-8.653 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=-1.652, 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 D2Y-volOHT1b for ; Sun, 7 Sep 2014 07:54:50 -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 3731E1A04B9 for ; Sun, 7 Sep 2014 07:54:50 -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=1410101690; x=1441637690; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=MtXu+SyaUw8SS22rssPFAEQgAdmpJh+wNuG7cgTjmIs=; b=VVCnKz3AXPb1FTUfDIS4Xu+2RAFvAB7bUS30GjY4AWyD4u91oq4bW1Jq /+/y4KaytSvtqVoubmQ+yt1TeTyKwhV2tVo4i2w5yyfnN8K0b4g9Gk1av DnKF1/lvVMNOGkNZuezVReFEIWwpprGUy2trikxk62XNZCSxRlyGFVMoH s=; X-IronPort-AV: E=McAfee;i="5600,1067,7553"; a="65301833" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by wolverine01.qualcomm.com with ESMTP; 07 Sep 2014 07:54:32 -0700 X-IronPort-AV: E=Sophos;i="5.04,482,1406617200"; d="scan'208";a="745990956" Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 07 Sep 2014 07:54:31 -0700 Received: from presnick-mac.local (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.3.181.6; Sun, 7 Sep 2014 07:54:30 -0700 Message-ID: <540C71A2.20104@qti.qualcomm.com> Date: Sun, 7 Sep 2014 11:54:26 -0300 From: Pete Resnick 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: Dave Crocker References: <540AABF8.8000605@cisco.com> <540C5BE1.6010405@qti.qualcomm.com> <540C6731.7040805@gmail.com> In-Reply-To: <540C6731.7040805@gmail.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.39.5] Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/OrqF8UsFUsyoplAQ72WxKYJQjQ4 Cc: endymail@ietf.org Subject: Re: [Endymail] spam versus cleartext 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: Sun, 07 Sep 2014 14:54:52 -0000 On 9/7/14 11:09 AM, Dave Crocker wrote: > On 9/7/2014 6:21 AM, Pete Resnick wrote: > >> Obviously doing e2e >> crypto gets you signatures. >> > No it doesn't. As a matter of practice, it probably will, but the > technology does not require it. Sigs are an entirely independent action > when doing object encryption. > Signatures, just like encryption, are part of cryptography. If you are doing cryptography (in the way we normally do so for e2e encryption), you can do signatures too. That's all I meant. >> Since we are blue-skying here, I think it is >> perfectly plausible to say, "If you want to send me e2e encrypted >> messages, you also have to send me signed messages, >> > So you want to eliminate anonymous communications? Anonymity has > historical importance for some kinds of communication. > Pseudonymity (i.e., a signature that is not attached to a particular human identity) may be sufficient for most cases. Doing so would still require a prior-to-real-communication step of me allowing that signature into my whitelist/contact list/whatever. For my personal email, I am perfectly willing to say, "You get two choices: (1) You set up a prior relationship with me with your signature, and only then do you get to encrypt e2e; or (2) you only get to encrypt as far as my spam scanning service." Now, to take a recent example, the only way for Snowden to contact me encrypted, unbrokered, and anonymously would involve a rather interesting maneuver to get into my whitelist. But I think I can live with that. >> and you don't or >> your signature is not in my contacts list already, your encrypted mail >> is going to bounce." I think it's possible that in the fullness of time, >> many users go to a contact-list model of email (a la IM) where the mail >> simply bounces unless it has a signature that is already in the contacts >> list. >> > The Procrustean bed always makes things simpler, and with only a few, > uhhh... shortcomings. > Indeed. And that is true of both this future environment where I would bounce mail without a required signature, and my current environment that requires me (or my agent) to accept, scan, review, and otherwise deal with anonymous mail. Each has....shortcomings. > My point is not that signing is bad or checking against address books is > bad, but that mandating such things constrains legitimate communication > in important ways. Let's not miss the point that we are *currently* constraining legitimate communication in important ways, as my weekly hunt through my spam folder and my occasional out-of-band, "Why did my mail bounce?" complaint amply demonstrate. I choose my tradeoffs, I get the advantages and disadvantages of those tradeoffs. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Sun Sep 7 08: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 EF4D71A0406 for ; Sun, 7 Sep 2014 08:02:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.153 X-Spam-Level: X-Spam-Status: No, score=-16.153 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=-1.652, 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 ePhJx-F_8yBY for ; Sun, 7 Sep 2014 08:02:54 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DDA41A0537 for ; Sun, 7 Sep 2014 08:02:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1206; q=dns/txt; s=iport; t=1410102175; x=1411311775; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=0PWXJ9C4N6FgMIGoHDRlpYfH1QqQK31mn7qoeroVUoY=; b=DKUK0tCcl6g2HB7ukyGRMSAqFOc1MZ4oT91PRBKtw7QtpJkmyPKUKLk7 53c68TqYBWRbf3dwqOJhamr7bmBn/dTJybJAyfU1dM4eQjUW/DcW5srN4 kkAJclX/3Qvpmfc4DdzIbUNYbTXNI++rO4VnYzxLX3KxeQhzx10S6+EkR E=; X-Files: signature.asc : 486 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsYGALxyDFStJssW/2dsb2JhbABZhzOKRcN2AYEYeIQEAQEEI1UBEAsOExYLAgIJAwIBAgFFBg0BBwEBiD6md5UBAReOaxEBUAeCeYFTAQSTRoFKh2KHQY1rg2M7gT6BQAEBAQ X-IronPort-AV: E=Sophos;i="5.04,482,1406592000"; d="asc'?scan'208";a="164895941" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 07 Sep 2014 15:02:51 +0000 Received: from [10.61.197.219] ([10.61.197.219]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s87F2oVa012647; Sun, 7 Sep 2014 15:02:50 GMT Message-ID: <540C7399.3060901@cisco.com> Date: Sun, 07 Sep 2014 17:02:49 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Pete Resnick References: <540AABF8.8000605@cisco.com> <540C5BE1.6010405@qti.qualcomm.com> In-Reply-To: <540C5BE1.6010405@qti.qualcomm.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="MGFKUMXjVUqFtUXXB5iH07VidTBetv5R1" Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/4bzKM1fRDIDjdikGPfc_9scXyq4 Cc: endymail@ietf.org Subject: Re: [Endymail] spam versus cleartext 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: Sun, 07 Sep 2014 15:02:56 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --MGFKUMXjVUqFtUXXB5iH07VidTBetv5R1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Let's talk constraints for a moment. Does the problem get easier if we say, =E2=80=9Clet's not even attempt to address transactional email=E2=80= =9D, and focus exclusively on h2h? Also, is it a goal to completely do away with spam? Is that a non-goal? Eliot --MGFKUMXjVUqFtUXXB5iH07VidTBetv5R1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQEcBAEBAgAGBQJUDHOaAAoJEIe2a0bZ0nozQewIAJ74VQc1rVUyRPyQsHaabr8P 9XBP7sDbRmtJVQOCswmrN1KQ1vE94Vil/vFN5Zj5zi3VeDuzlWL0Q9J2RzzqUSWZ QmIN59PyNNLxkx4XL/+G/6E6hC+F0E+6Cw3ctfdVzJYnDjEigvWcBbHqdhqHGtTP 1TcBL6FZWKQfFcOPwANuUFbiEBP1u8OQTEG+QNWMbuweusnZTeAjVcfYoJLOlKe7 oxP14NHCiyS36QjQAyuaYw8lYQgMt1SkvPqWPa0vv/X2Q0w+ADbsqnJZVTEqRbhO v298IlTHlwX8sanYeCqwLcEqqkTaHFq59uLQrOaY+fza+qBK0pGIHmZgsxeGO/Y= =FXSP -----END PGP SIGNATURE----- --MGFKUMXjVUqFtUXXB5iH07VidTBetv5R1-- From nobody Sun Sep 7 08:10:47 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 0A65C1A00D2 for ; Sun, 7 Sep 2014 08:10:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yi9ptlYpT2p0 for ; Sun, 7 Sep 2014 08:10:27 -0700 (PDT) Received: from mail-qa0-x233.google.com (mail-qa0-x233.google.com [IPv6:2607:f8b0:400d:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D41561A0412 for ; Sun, 7 Sep 2014 08:10:26 -0700 (PDT) Received: by mail-qa0-f51.google.com with SMTP id j7so12813480qaq.24 for ; Sun, 07 Sep 2014 08:10:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=W0XbkCp9DF6U2lW3OCudRaDUoAtcf8gggaqNnQhoXzI=; b=a7TpirQNLqWeuoPd+zcPVZ2gbqa9Q7LsBFgovs9I9diHcVmzOARkXVtE/W0CVxvEia R/mXPovPtmOBKgPF6ap3wKEMYxn+5p11qH7O3H2IP77pUEM3JvM38TnhyxA394SmHtQI 1PzgY4TBkeVuV51KCp9IrUWLokifo7smWJ45CDjrcMGR1GJH9XYgeHpDDLlU4BCokwsA Z+4vz0ggZxCaTiBugRuNn6D2rmuRgur0Hvd4Yv3wz/9ydZQofjG04FTXdmvF8XnpqDY1 KP0CXOZfKYVvLTlqofrpsbc6mg2OF2+UbX9tg4ClYR0STd2fn5Ca7x3vRMJP+2Hj0I+W dMBg== X-Received: by 10.229.57.138 with SMTP id c10mr1856414qch.30.1410102625960; Sun, 07 Sep 2014 08:10:25 -0700 (PDT) Received: from [192.168.1.3] (209-6-114-252.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.114.252]) by mx.google.com with ESMTPSA id y7sm5242086qgd.49.2014.09.07.08.10.24 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 07 Sep 2014 08:10:24 -0700 (PDT) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (11D257) In-Reply-To: Date: Sun, 7 Sep 2014 11:10:25 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <29088157-04F4-4E22-A604-A35C3B217C98@gmail.com> References: <540AABF8.8000605@cisco.com> <540C5BE1.6010405@qti.qualcomm.com> To: Phillip Hallam-Baker Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/aNcexsDrQ9AXxUlq5rFV59oWMBo Cc: Pete Resnick , Eliot Lear , endymail Subject: Re: [Endymail] spam versus cleartext 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: Sun, 07 Sep 2014 15:10:33 -0000 Sent from my iPhone > On Sep 7, 2014, at 10:09 AM, Phillip Hallam-Baker w= rote: >=20 >> On Sun, Sep 7, 2014 at 9:21 AM, Pete Resnick w= rote: >>> On 9/6/14 3:38 AM, Eliot Lear wrote: >>>=20 >>> In the early days fo perpass we had lengthy discussions about the >>> tension between privacy and ability of security systems to reduce spam. >>> Below is an article from a gentleman who used to work at Google, which I= >>> thought this group might find interesting. >>>=20 >>> https://moderncrypto.org/mail-archive/messaging/2014/000780.html >>=20 >>=20 >> Along similar lines to what John Levine said,: Obviously doing e2e crypto= >> gets you signatures. Since we are blue-skying here, I think it is perfect= ly >> plausible to say, "If you want to send me e2e encrypted messages, you als= o >> have to send me signed messages, and you don't or your signature is not i= n >> my contacts list already, your encrypted mail is going to bounce." I thin= k >> it's possible that in the fullness of time, many users go to a contact-li= st >> model of email (a la IM) where the mail simply bounces unless it has a >> signature that is already in the contacts list. >=20 >=20 > I think that is right, but not the whole picture. >=20 > I see endymail as a subset of mail. All mail should be encrypted at > the message layer but only whitelisted mail would be e2e encrypted. It seems the point of the original posting may have been lost. Folks are ju= mping right back to solution design instead of thinking through operational c= osts of various approaches. How does handing not only spam, but other attac= k like phishing and spear phishing evolve when e2e messaging is the norm? W= e may have increased privacy, but have we helped the attacker? End points/u= sers can't address these and other attacks on their own. We need to think t= hrough operational practices and try to understand how changes will effect t= hese practices to then influence what design choices make sense. >=20 > This can be done automatically as follows: >=20 >=20 > A) Some sort of discovery infrastructure maps email addresses to key hashe= s. > B) Some sort of discovery infrastructure maps key hashes to keys. > C) Inbound mail server has an encryption key > D) User has an endymail encryption key. >=20 >=20 > 1) Alice sends a message to Bob , she doesn't know him ye= t. >=20 > Alice's email client uses infrastructure A and B to pull the best > public data for bob. This turns out to be a domain level record with > the mail server key (C). >=20 If anyone can search for a key, spammers and spear phishing attackers have t= his capability too. > Mail is opportunistically encrypted under the mail server key (C). > Mail server decrypts then (optional) re-encrypts message for delivery > to Bob. >=20 > The sent mail includes a header with Alice's encryption key > fingerprint. It is signed using either DKIM or S/MIME depending on the > settings specified in the key record. >=20 What happens when Alice's email is compromised? This is a common tactic tod= ay and may only increase with e2e. I'm not arguing against e2e, but rather that we think through the effect cha= nges will have understanding today's operational and security/incident respo= nse practices. Best regards, Kathleen=20 >=20 > 2) Bob receives message >=20 > 2a) Bob reads message hits the 'spam' key > 2b) Bob reads message, does nothing > 2c) Bob replies to message >=20 > Only 2c is going to result in Bob's client whitelisting Alice. His > response contains the key fingerprint that Bob needs to perform > retrieval of the key using infrastructure B. >=20 >=20 > 3) Alice sends another message to Bob after his reply >=20 > Client notes that it is whitelisted and pulls the key from infrastructure B= . >=20 >=20 > Note: >=20 > 1) This whole process is completely frictionless. Neither Alice nor > Bob has to do anything differently. >=20 > 2) This is only one point on the security spectrum. In other > applications we might allow easier access to the endy key or might not > allow access at all. >=20 > 3) The reason for decoupling the key from the system via a key hash is > that it enables key rollover. >=20 >=20 > One question left open in the above is how we prevent the use of > infrastructure A as a means to obtain email addresses. >=20 > I am currently working on efficient ways to do that. >=20 > _______________________________________________ > Endymail mailing list > Endymail@ietf.org > https://www.ietf.org/mailman/listinfo/endymail From nobody Sun Sep 7 08:20:33 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 B86271A0538 for ; Sun, 7 Sep 2014 08:20:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eq_sokLn190f for ; Sun, 7 Sep 2014 08:20:29 -0700 (PDT) Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d: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 07CF21A0537 for ; Sun, 7 Sep 2014 08:20:28 -0700 (PDT) Received: by mail-qg0-f51.google.com with SMTP id e89so848779qgf.38 for ; Sun, 07 Sep 2014 08:20:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=sBcxDugnX9C1yTcYCYT6Kh9Bj/TI6ywIZKB2lZ8ns/k=; b=slMYLh88BP5ONsgVJNgYxYztayIVPQLWX/6CVCxNG9bCxyB2Zp/mtNPxF/RN9I22aH F9448RYQDxTBc2oqKa36QhHk+JJ9Fe7fp4JeMP6P0FvMRTopiZRFVJzTNz7Rbt+O3sSR ZxYz4tWRKyG0QjPS9eUE60EU41nV+qDI4dyF2/D1HpWajhBsCBrsinHor2LIffCWgM8p uLpovnyFmbXXefzZPg/v1kQEUW1UXpVN04u+MhtlNSZpGZaVyprXnwDyaVtIUw0PPDc5 TuPLsysnt+Spz2Y1ortmRUiNIthITa7pYHQDRobXs55gK1yMxQqvvUiUFNTKuTO1//5J dL4g== X-Received: by 10.224.157.7 with SMTP id z7mr33058647qaw.26.1410103227904; Sun, 07 Sep 2014 08:20:27 -0700 (PDT) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net. [76.218.8.156]) by mx.google.com with ESMTPSA id k4sm5609249qaf.0.2014.09.07.08.20.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 07 Sep 2014 08:20:27 -0700 (PDT) Message-ID: <540C76FC.2050106@gmail.com> Date: Sun, 07 Sep 2014 08:17:16 -0700 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Pete Resnick References: <540AABF8.8000605@cisco.com> <540C5BE1.6010405@qti.qualcomm.com> <540C6731.7040805@gmail.com> <540C71A2.20104@qti.qualcomm.com> In-Reply-To: <540C71A2.20104@qti.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/gvpEppK33XxcbPE100eTDa4KZBI Cc: endymail@ietf.org Subject: Re: [Endymail] spam versus cleartext 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: Sun, 07 Sep 2014 15:20:30 -0000 On 9/7/2014 7:54 AM, Pete Resnick wrote: > On 9/7/14 11:09 AM, Dave Crocker wrote: > Signatures, just like encryption, are part of cryptography. If you are > doing cryptography (in the way we normally do so for e2e encryption), At the level of "if you can get keys you can do either", sure. Arguably the nature of the trust assessment issues is different for the two, but that could get esoteric. >> So you want to eliminate anonymous communications? Anonymity has >> historical importance for some kinds of communication. > > Pseudonymity (i.e., a signature that is not attached to a particular > human identity) may be sufficient for most cases. Might. Might not. We have little operational experience with some of these constructs in the practical world. I'm pushing back about all this because we need much more cautious language about the efficacy and risks of these approaches. In effect, I suggest approaches be characterized as (potentially) useful options, rather than likely or certain "solutions". Given the way these topics tend to be discussed, that distinction is fundamental. > Doing so would still > require a prior-to-real-communication step of me allowing that signature > into my whitelist/contact list/whatever. For my personal email, I am > perfectly willing to say, You (and I and everyone else on this list) are not representative users. Most of the human factors experience in this realm is that average users don't appreciate the extra hassle and don't perform well with the additional tasks. So if you want these mechanisms to scale, they require thinking very differently about end-user load. >> My point is not that signing is bad or checking against address books is >> bad, but that mandating such things constrains legitimate communication >> in important ways. > > Let's not miss the point that we are *currently* constraining legitimate > communication in important ways, as my weekly hunt through my spam > folder and my occasional out-of-band, "Why did my mail bounce?" > complaint amply demonstrate. I choose my tradeoffs, I get the advantages > and disadvantages of those tradeoffs. You haven't heard me suggest maintaining the technical or operational status quo and ignoring the problem, nevermind the amount of time I spend in the world of m3aawg.org and more recently Levison's effort. Again, my concern is ensuring adequate caution about unintended (as well as intended) consequences. The very consistent tendency of folk making proposals in this space is to be quite cavalier about the human communication downsides from imposing excessive constraints. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sun Sep 7 08:30:46 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 D50331A041F for ; Sun, 7 Sep 2014 08:30:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3BxtNepYasEy for ; Sun, 7 Sep 2014 08:30:43 -0700 (PDT) Received: from mail-qc0-x22f.google.com (mail-qc0-x22f.google.com [IPv6:2607:f8b0:400d:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78A9B1A010C for ; Sun, 7 Sep 2014 08:30:43 -0700 (PDT) Received: by mail-qc0-f175.google.com with SMTP id c9so14342939qcz.20 for ; Sun, 07 Sep 2014 08:30:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=uUpYODOdk7M5ZKVsQvH5905SQjH+YIB9LvWmiMZ1ekg=; b=0h7NQFBjHL43/qYPshrF2Hbc5CTihv8ZliIB+Av6kOGSdrF8YdZgqdukGy3yosywyz 5+5SP3QoJjslwgqt7vxNHUezCwn4oKPpqIM4ENIj3yCx0o7v3jzHbj2LHjlvz9/vY+dm GTPwJ661rNzzhUWSfkV1nqiXZbW2qYeuwGHtlLW+DHeX2YyZXNmwyCQXjF5iwrzXixxV i7mjVUsKOPs/5BI4lfkXbWcamgsvRm3ZUyJEL65Ai7xwXFCb7KAKOTXT6sodpuMVIcuL 8YV6HIWj0HpfZfKOwwOcQEjf9ZCQDWfcZGVBXPqu799TnaDapGeoFGckxZ9It56U4cx9 FK6w== X-Received: by 10.224.80.65 with SMTP id s1mr33846130qak.41.1410103842592; Sun, 07 Sep 2014 08:30:42 -0700 (PDT) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net. [76.218.8.156]) by mx.google.com with ESMTPSA id o1sm5608768qaa.19.2014.09.07.08.30.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 07 Sep 2014 08:30:41 -0700 (PDT) Message-ID: <540C7963.8040204@gmail.com> Date: Sun, 07 Sep 2014 08:27:31 -0700 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: endymail References: <540AABF8.8000605@cisco.com> <540C5BE1.6010405@qti.qualcomm.com> <29088157-04F4-4E22-A604-A35C3B217C98@gmail.com> In-Reply-To: <29088157-04F4-4E22-A604-A35C3B217C98@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/XH-2Egu0JQ9h2scgbyl4ouHvxvM Subject: Re: [Endymail] spam versus cleartext 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: Sun, 07 Sep 2014 15:30:45 -0000 On 9/7/2014 8:10 AM, Kathleen Moriarty wrote: > How does handing not only spam, but other attack like phishing and spear phishing evolve when e2e messaging is the norm? Spam and other abuse continue to occupy 90-98% of the email traffic across the net. Life is tolerable only because the receiving operators have gotten quite good at keeping these barbarians outside of the gate. Note that a change of only a few percent in filtering efficacy will likely double the amount of spam/abuse the receivers sees. And double is a best case scenario. Modern filtering engines use an amazing array of information to assess incoming mail. IP Address, message meta data, content, traffic analysis, etc. Some of the filtering does not require looking at any content (envelope, header, body). Some does. To the extent that particular content is hidden from the filtering engine, that portion of the engine is useless. (This observation is in the realm of "duh", but it's needed for the sequence here.) If that efficacy is to be retained/recovered, we need to find a way to give the filtering engine access to that data, but without compromising the confidentiality model. As this has been discussed in other conversations, the only way I see that happening is to move the relevant portions of the engine into the recipient's MUA, and then have that sub-engine consult with the main engine. ("Consult" is a code word for needing an open protocol between the MUA and the filtering engine.) This will let more bad mail get to the inbox, but would still limit how much actually burdens the recipient. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sun Sep 7 08:44:58 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 B175B1A0538 for ; Sun, 7 Sep 2014 08:44:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gH8ckTYtw6ka for ; Sun, 7 Sep 2014 08:44:53 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id F1C201A0535 for ; Sun, 7 Sep 2014 08:44:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 94EBFBE09; Sun, 7 Sep 2014 16:44:51 +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 YfEB9iKFXGYo; Sun, 7 Sep 2014 16:44:50 +0100 (IST) Received: from [10.87.48.8] (unknown [86.42.17.17]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 8685FBE02; Sun, 7 Sep 2014 16:44:50 +0100 (IST) Message-ID: <540C7D72.7060306@cs.tcd.ie> Date: Sun, 07 Sep 2014 16:44:50 +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: Dave Crocker , endymail References: <540AABF8.8000605@cisco.com> <540C5BE1.6010405@qti.qualcomm.com> <29088157-04F4-4E22-A604-A35C3B217C98@gmail.com> <540C7963.8040204@gmail.com> In-Reply-To: <540C7963.8040204@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/5tV29stxHU3UQD1X5HJgdXS-Y0w Subject: Re: [Endymail] spam versus cleartext 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: Sun, 07 Sep 2014 15:44:55 -0000 On 07/09/14 16:27, Dave Crocker wrote: > > As this has been discussed in other conversations, the only way I see > that happening is to move the relevant portions of the engine into the > recipient's MUA, and then have that sub-engine consult with the main > engine. ("Consult" is a code word for needing an open protocol between > the MUA and the filtering engine.) I think Dave's is a fine example of what we might get from this list - identifying work that the IETF can do that'd potentially help a number of different e2e email solutions. Cheers, S. From nobody Sun Sep 7 09:09:19 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 BE7DF1A064B for ; Sun, 7 Sep 2014 09:09:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c7VwN7sSmGgL for ; Sun, 7 Sep 2014 09:09:16 -0700 (PDT) Received: from mail-qa0-x22c.google.com (mail-qa0-x22c.google.com [IPv6:2607:f8b0:400d:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 691371A040E for ; Sun, 7 Sep 2014 09:09:16 -0700 (PDT) Received: by mail-qa0-f44.google.com with SMTP id j7so13133047qaq.3 for ; Sun, 07 Sep 2014 09:09:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=bCg8lfSj21DZYAt1qG8x+rlZqn9YLqRxfxRSkG9I1vc=; b=0rLlmammpbzJdU496QM4kEZrjP7TyXMfRTxUnKG0UQXOLZd261LX9bMrQk6gH2usxs RjNYRp2vwi08es/XHakvTtnIatB3XswFa3TfgK920GIBVLS3uhLSd4pBWb3dB6sfknt1 yEBrPCRfm1FAfNYtlGUnfxanovT3htnT+vyDMy4yrdD7mtuRlS9316sjXUXzTbEbHPBe 1pnV12PtYt4geaPuiU8VfSVvsTQ4rIxQk+pWx+0iMVP4O7gDN8nqz97FAmIvi3bK4ECy d1ZizdvIgYP8J+HkLR8OsLFjnOVI1WhjdJWBbjxwi44my48Cv49JRZ2/ZXCq6PRiby3O UTTQ== X-Received: by 10.140.86.147 with SMTP id p19mr33689250qgd.66.1410106154507; Sun, 07 Sep 2014 09:09:14 -0700 (PDT) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net. [76.218.8.156]) by mx.google.com with ESMTPSA id j74sm5370918qgd.0.2014.09.07.09.09.13 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 07 Sep 2014 09:09:13 -0700 (PDT) Message-ID: <540C826B.9060408@gmail.com> Date: Sun, 07 Sep 2014 09:06:03 -0700 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Eliot Lear References: <540AABF8.8000605@cisco.com> <540C5BE1.6010405@qti.qualcomm.com> <540C7399.3060901@cisco.com> In-Reply-To: <540C7399.3060901@cisco.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/-DwbnJq2AZlmOQgY21th2JULG7M Cc: endymail@ietf.org Subject: Re: [Endymail] spam versus cleartext 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: Sun, 07 Sep 2014 16:09:18 -0000 On 9/7/2014 8:02 AM, Eliot Lear wrote: > Let's talk constraints for a moment. Does the problem get easier if we > say, “let's not even attempt to address transactional email”, and focus > exclusively on h2h? Also, is it a goal to completely do away with > spam? Is that a non-goal? Eliot, I've no idea what characteristics of 'transactional mail' -- as compared with... personal mail, or ? -- worth distinguishing. So while it's a category that is often interesting to distinguish in email security and abuse discussions, what do you have in mind here, exactly? MTA-to-MTA (or, rather, Boundary MTA to Boundary MTA) is almost certainly an interesting distinction from author to recipient. For example, that's why DKIM has succeeded at Internet scale, where PGP and S/MIME have not. But we need to be clear about what benefits it gets us and what it doesn't. If, for example, one is worried about their email operator being compelled to produce keys for decrypting user mail... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sun Sep 7 09:40:52 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 986FD1A064B for ; Sun, 7 Sep 2014 09:40:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.563 X-Spam-Level: * X-Spam-Status: No, score=1.563 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, 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 IOMaK21Sq8nu for ; Sun, 7 Sep 2014 09:40:49 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09E6C1A046A for ; Sun, 7 Sep 2014 09:40:48 -0700 (PDT) Received: (qmail 64176 invoked from network); 7 Sep 2014 16:40:47 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 7 Sep 2014 16:40:47 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=3973.540c8a8f.k1409; i=johnl@user.iecc.com; bh=bgfnBsvEYL2G72abDJzjml1L0gDlnWc07azEiI0aLok=; b=wMpDYxOdE6gIKnDc04E38QTmOtjWgQLbYD1Rr8OIEBUfwXuLifbJalXYv5QA5cBvdDqCvy7r8k+LAku0Hsp+vVCu56vmpBnM08CcOkjAb4FFeGQmoSxmT1PAwECKObXjqwAN9lc2vunnsy5L79Be9RSSwMXjD+ziut63TTxq18EQncJyzuLpm6krFaH1+tfA8gEw41juPfejfFy1vc5igJNjho91tTYJd37bf4n5UK3UF2bPNXNHThEPK/+5xkJ2 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=3973.540c8a8f.k1409; olt=johnl@user.iecc.com; bh=bgfnBsvEYL2G72abDJzjml1L0gDlnWc07azEiI0aLok=; b=CXxQNX89G/YtBXFr3xXXf3NUN0OXQt9K1fozfDEQeyVb3mARYJSUUY8rpFQTkcw+JKUwsckxKSUu3DWECImAAIkU4SdRdYLpMbMJAHYSo0f0KpRLvXL77eDqyE1YaEgPKdng/16CJJMuh0oofpLcSJ7SDPIEsKopn8gPTntGE59aIVzHJ0rEJNHr6D3x0bGuPQlDkNyxvZWmB8t0iOS8LFC73he2YyIGsjkGPzysivh/NvKg/zoUHh7b+/li/mFv Date: 7 Sep 2014 16:40:25 -0000 Message-ID: <20140907164025.14706.qmail@joyce.lan> From: "John Levine" To: endymail@ietf.org In-Reply-To: <540C826B.9060408@gmail.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/X7pk3sheZXPhsocUsCUoBqPIoYA Cc: dcrocker@gmail.com Subject: Re: [Endymail] spam versus cleartext 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: Sun, 07 Sep 2014 16:40:50 -0000 >I've no idea what characteristics of 'transactional mail' -- as compared >with... personal mail, or ? -- worth distinguishing. It only goes in one direction. My bank writes to me all the time, but I never write back. This rules out any approach that uses an exchange of messages to establish mutual trust. An obvious kludge would be some way for the bank to send you their key out of band, analogous to the notes on websites now that say please add our address notify@bigbank.ru to your address book. R's, John From nobody Sun Sep 7 09:47:35 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 326B51A046B for ; Sun, 7 Sep 2014 09:47:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 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, J_CHICKENPOX_46=0.6, 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 SQ-veZm2eG0h for ; Sun, 7 Sep 2014 09:47:33 -0700 (PDT) Received: from mail-qc0-x235.google.com (mail-qc0-x235.google.com [IPv6:2607:f8b0:400d:c01::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0C651A046A for ; Sun, 7 Sep 2014 09:47:32 -0700 (PDT) Received: by mail-qc0-f181.google.com with SMTP id i17so14410785qcy.26 for ; Sun, 07 Sep 2014 09:47:31 -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=Oly/e+QPvqnTAmj9ZUC4FxU717/qs2LM9xKB7zkPTKk=; b=SoIQfkOYXQ/CkSS/P4u7ruLrY3SbEiEjOwqqOcae1kPC9uAmpQaDnsLsZlkgOmciBm 5zIFV/nKLwKYjJ8XWYM47l5N5yXebY9LhCciOGAdT2dHMLtnK+06P1CAtKgRcZKr8zDG uK6l8Hb9vdlxJDi0PXUXj8HZiRcPb6QDov6Hw+/BKmYMVTVuyKbVX6zDfS0bnJmS5oNH ZIJXOC9EzUzHcyvoL1MTQVitShDfxHthdmp/uIH1LwzFVs8vBXewQmmvb8Y4oPi5wzee M5NyDC37aH7tRtG5IOBkvwNZwW7UQNOCz6DtNhTb7bw6FLTD2wRssbyBPfe+PIHIbRLw Vukg== MIME-Version: 1.0 X-Received: by 10.140.20.151 with SMTP id 23mr11252612qgj.24.1410108451806; Sun, 07 Sep 2014 09:47:31 -0700 (PDT) Received: by 10.140.32.134 with HTTP; Sun, 7 Sep 2014 09:47:31 -0700 (PDT) In-Reply-To: <540C7963.8040204@gmail.com> References: <540AABF8.8000605@cisco.com> <540C5BE1.6010405@qti.qualcomm.com> <29088157-04F4-4E22-A604-A35C3B217C98@gmail.com> <540C7963.8040204@gmail.com> Date: Sun, 7 Sep 2014 09:47:31 -0700 Message-ID: From: Watson Ladd To: Dave Crocker Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/Avjfh8eOEG6CrxLLDreuzIm6W-4 Cc: endymail Subject: Re: [Endymail] spam versus cleartext 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: Sun, 07 Sep 2014 16:47:34 -0000 On Sun, Sep 7, 2014 at 8:27 AM, Dave Crocker wrote: > On 9/7/2014 8:10 AM, Kathleen Moriarty wrote: >> How does handing not only spam, but other attack like phishing and spear phishing evolve when e2e messaging is the norm? > > > Spam and other abuse continue to occupy 90-98% of the email traffic > across the net. Life is tolerable only because the receiving operators > have gotten quite good at keeping these barbarians outside of the gate. > Note that a change of only a few percent in filtering efficacy will > likely double the amount of spam/abuse the receivers sees. And double > is a best case scenario. > > Modern filtering engines use an amazing array of information to assess > incoming mail. IP Address, message meta data, content, traffic > analysis, etc. Some of the filtering does not require looking at any > content (envelope, header, body). Some does. > > To the extent that particular content is hidden from the filtering > engine, that portion of the engine is useless. (This observation is in > the realm of "duh", but it's needed for the sequence here.) > > If that efficacy is to be retained/recovered, we need to find a way to > give the filtering engine access to that data, but without compromising > the confidentiality model. > > As this has been discussed in other conversations, the only way I see > that happening is to move the relevant portions of the engine into the > recipient's MUA, and then have that sub-engine consult with the main > engine. ("Consult" is a code word for needing an open protocol between > the MUA and the filtering engine.) To connect to server side filtering, the filtering engine on the server just needs to put probabilities it thinks that the message is spam in the headers, as well as have a standardized means for the client to report spam or ham. This doesn't seem that complicated: just a double and some sort of forwarding info to get the backchannel. (This assumes naive Bayes as a filter design) > > This will let more bad mail get to the inbox, but would still limit how > much actually burdens the recipient. True: how much does DKIM+sender based blacklists do vs. filtering based on content? For mobile someone raised the issue of excessive notifications and battery life, so we do need to worry a little about server-side. But I think it's clear we can engineer a solution to spam that doesn't look much different than today. Sincerely, Watson Ladd > > d/ > > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net > > _______________________________________________ > Endymail mailing list > Endymail@ietf.org > https://www.ietf.org/mailman/listinfo/endymail -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Sun Sep 7 10:02:35 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 609BE1A02FC for ; Sun, 7 Sep 2014 10:02:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.163 X-Spam-Level: ** X-Spam-Status: No, score=2.163 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_46=0.6, 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 9N1Co4YeG66A for ; Sun, 7 Sep 2014 10:02:32 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 127681A0476 for ; Sun, 7 Sep 2014 10:02:31 -0700 (PDT) Received: (qmail 65895 invoked from network); 7 Sep 2014 17:02:29 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 7 Sep 2014 17:02:29 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=3a29.540c8fa5.k1409; i=johnl@user.iecc.com; bh=llF5RGPcbmY3u8+Pkol7FRCk01nZpis1wVrsyVunJ4U=; b=zscptxdY9mz79s/B/dS6QQYM+dQ1jsiD4ml/eZ/5Kpogm0khaEgDkhzYasn2GM4FZF8cIlgp5UkUfpObfz/Tqg2EGmDzBlMIYRV63ZS6Muttfghh9WFrnqqRY0bGR2buxQkXRPFgGxte5clrxUYrlVzy0yZTLvX9IWQL3KVhX8JSFNDejELH23zrRq0JyyqWrM7xCjkPQDXldoSkPt/gM4gUo88tG2szTggep1E6JH1BNiOj6xuTl5WveUxeckJ4 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=3a29.540c8fa5.k1409; olt=johnl@user.iecc.com; bh=llF5RGPcbmY3u8+Pkol7FRCk01nZpis1wVrsyVunJ4U=; b=dE0B+b8uCdFp19cRokC4C5vWBl5Rtkjn/KPoa8WrnKRUrmLT2vhWl3EDr/GDZN9yWIQur7345hqQ7VbG8kL0B1x+FL7vbyB0MTBAtC7lqccXJlddvE51nbjJ1hsz5L94ERmnWyGg9exABQXvhR4Ic8LEg+FdDy63LzxYw4YW2Oqml7GMuZmYvWLsXCw24cslvukpZLYa965xEA6aTdUH6UHTTYYbgz92qudclugJSvn/78AM2iunbnB7Ap6j0YyJ Date: 7 Sep 2014 17:02:07 -0000 Message-ID: <20140907170207.14888.qmail@joyce.lan> From: "John Levine" To: endymail@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/Y_UzBNQnhAToprUHLwoE6B9OFLc Cc: watsonbladd@gmail.com Subject: Re: [Endymail] spam versus cleartext 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: Sun, 07 Sep 2014 17:02:33 -0000 >To connect to server side filtering, the filtering engine on the >server just needs to put probabilities it thinks that the message is >spam in the headers, as well as have a standardized means for the >client to report spam or ham. This doesn't seem that complicated: just >a double and some sort of forwarding info to get the backchannel. >(This assumes naive Bayes as a filter design) Keeping in mind that upwards of 90% of mail is spam, you're going to be downloading an order of magnitude mail if you do the filtering on the end device. On a desktop with a cable connection that's probably OK. On my phone, it's not. >True: how much does DKIM+sender based blacklists do vs. filtering >based on content? In terms of volume, IP blacklists are still by far the most effective, since they knock out most botnet spam. Other than DMARC, which is a separate can of worms, I don't know of anyone who does message rejection based on DKIM signatures. There's a whole lot of body filtering going on. R's, John From nobody Sun Sep 7 10:04:03 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 E0B231A0476 for ; Sun, 7 Sep 2014 10:04:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.153 X-Spam-Level: X-Spam-Status: No, score=-16.153 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=-1.652, 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 TEKT5Lok2pkZ for ; Sun, 7 Sep 2014 10:04:01 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FD0F1A02FC for ; Sun, 7 Sep 2014 10:04:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2020; q=dns/txt; s=iport; t=1410109440; x=1411319040; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=9tH3a9DZeddPU5NLoSprnClISAMjPTNGF/k8EFKolEo=; b=eRD3/Ah11h5/0ikgbqDT/oXBwfjT6OOdPQ0cRKi8E6a5UiY+aWoi0wga FnimncpQnknobvXA5YsacLU1gaKMtd239BjsF8AFQCqw6cNkY8sOdg2fd iYK3byo/0vrpDIEvKodljGvB3HaMGq8JbaWqOBtMA+peTtsXa3nx+WcRZ U=; X-Files: signature.asc : 486 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqEEAPOODFStJssW/2dsb2JhbABYhzPOOwGBGHiEBAEBAwEjVhALDhMhAgIPAkYGDQEHAQGINgimW5UAAReOaxACAU8HgnmBUwEEjyuEG4FKh2KHQY1rg2M7gn4BAQE X-IronPort-AV: E=Sophos;i="5.04,483,1406592000"; d="asc'?scan'208";a="164993342" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 07 Sep 2014 17:03:47 +0000 Received: from [10.61.197.219] ([10.61.197.219]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s87H3lcc001426; Sun, 7 Sep 2014 17:03:47 GMT Message-ID: <540C8FF1.80104@cisco.com> Date: Sun, 07 Sep 2014 19:03:45 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Dave Crocker References: <540AABF8.8000605@cisco.com> <540C5BE1.6010405@qti.qualcomm.com> <540C7399.3060901@cisco.com> <540C826B.9060408@gmail.com> In-Reply-To: <540C826B.9060408@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="nNAIL7xelVWQD8ljJALw58gDHd6CTUfaU" Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/MXaC8wbpJoDZpQgGyRLTzQMoFk0 Cc: endymail@ietf.org Subject: Re: [Endymail] spam versus cleartext 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: Sun, 07 Sep 2014 17:04:02 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --nNAIL7xelVWQD8ljJALw58gDHd6CTUfaU Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, > > Eliot, > > I've no idea what characteristics of 'transactional mail' -- as compare= d > with... personal mail, or ? -- worth distinguishing. So while it's a > category that is often interesting to distinguish in email security and= > abuse discussions, what do you have in mind here, exactly? human to human versus other. > > MTA-to-MTA (or, rather, Boundary MTA to Boundary MTA) is almost > certainly an interesting distinction from author to recipient. For > example, that's why DKIM has succeeded at Internet scale, where PGP and= > S/MIME have not. How blue sky do we want to be in this discussion? If the answer is "very", then we should even leave the above terminology aside =E2=80=93 f= or the moment. But now that I see a large object headed straight toward me... > > But we need to be clear about what benefits it gets us and what it does= n't. Yes. > > If, for example, one is worried about their email operator being > compelled to produce keys for decrypting user mail... As a very important example.=20 Eliot --nNAIL7xelVWQD8ljJALw58gDHd6CTUfaU Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQEcBAEBAgAGBQJUDI/xAAoJEIe2a0bZ0nozZ9EH/0aU6GFu0KKdB6u1Z1ATi5wt T/LF54RDxLj0XzgCSNS/cpR69NDeyvFr3jOdgzqyIPqsQw10dF0H9XFXVEXEcOzO BuxORF/TynJx84085SayflX+2vRxuVT64LMqp2kQ9cvNURO5Iby0zvKbjU4QJTRZ C/QnE9ZpVDTVn/0AktRsOf4ZRksmKOIeyWhIz4Wjd4kTOOCp8PKWyIZcncBfeQYI kuNc183fF7ZBqINuZEFCz7JQxj6QSKyu2NJ9hZVNNW4NylMh0QUfu6SZSat0CE51 pUnzvLs4wdgtshAN5jtGa5SSkWGQyLJMpOOQ3OnxpwbGhBcje8uyp9CN8jgC+os= =80Tc -----END PGP SIGNATURE----- --nNAIL7xelVWQD8ljJALw58gDHd6CTUfaU-- From nobody Sun Sep 7 10:08:08 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 BEF891A0476 for ; Sun, 7 Sep 2014 10:08:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.852 X-Spam-Level: X-Spam-Status: No, score=-0.852 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-1.652] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XUChAQaTwLga for ; Sun, 7 Sep 2014 10:08:01 -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 287631A02FC for ; Sun, 7 Sep 2014 10:08:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 0D927859320; Sun, 7 Sep 2014 13:02:20 -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 TdIpvGFjz5kZ; Sun, 7 Sep 2014 13:02:18 -0400 (EDT) Received: from [10.0.1.22] (unknown [173.13.55.49]) by daboo.name (Postfix) with ESMTPSA id A82BA859309; Sun, 7 Sep 2014 13:02:17 -0400 (EDT) Date: Sun, 07 Sep 2014 13:07:56 -0400 From: Cyrus Daboo To: John Levine , endymail@ietf.org Message-ID: In-Reply-To: <20140907170207.14888.qmail@joyce.lan> References: <20140907170207.14888.qmail@joyce.lan> 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=790 Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/Qe8qRXsbbPwSV78sgp-t1kQE7JI Cc: watsonbladd@gmail.com Subject: Re: [Endymail] spam versus cleartext 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: Sun, 07 Sep 2014 17:08:05 -0000 Hi John, --On September 7, 2014 at 5:02:07 PM +0000 John Levine wrote: > Keeping in mind that upwards of 90% of mail is spam, you're going to > be downloading an order of magnitude mail if you do the filtering on > the end device. On a desktop with a cable connection that's probably > OK. On my phone, it's not. True - which likely means you are going to want your desktop client to always be on and actively filtering your email so the mobile device is not forced to download something that will eventually get removed. That basically implies you are running a server (though you could call it an "agent") on your desktop and would want guarantees of uptime, etc. That is basically only a small step away from running your own mail server... -- Cyrus Daboo From nobody Sun Sep 7 10:19:17 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 A61311A02FC for ; Sun, 7 Sep 2014 10:19:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.301 X-Spam-Level: * X-Spam-Status: No, score=1.301 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_46=0.6, 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 ak45_A_R5mv3 for ; Sun, 7 Sep 2014 10:19:13 -0700 (PDT) Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B80421A0476 for ; Sun, 7 Sep 2014 10:19:12 -0700 (PDT) Received: by mail-la0-f53.google.com with SMTP id q1so7594336lam.40 for ; Sun, 07 Sep 2014 10:19:11 -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=XToCGh+bNzGkWniOEKAfcnYgZB3xOEwP0Z0u/7/mE30=; b=SU2+T50R8d5r5H2rtiByPPnv+lXDhoEEbEOk4FShh3Q6gJJ+6T6wYaD0d/qTDaxjrA c+0oOYuLD1WNMv2eTSf8/ozk0HQ+LQ/vTFN4YZ/GabTqnsC4P0dsvpMHzkx81U6e1kOA LPjPQf5mjTW/21YTzqfdmTPNv5ePq9SzYKS6mWi7PDmhX8SUkDJS62xdOJylMwWUk6LL CJJ4ajdgDTv5FuLuJSR3zPAB5jo7/UQpq42KKiU1sMrMFDc9jp5rnlDtHqdQxUFntanE vMU5RsUM7saTlnsCllnN6EjvLSWcBSLPlJbXj4PiP1HQ8v2PORuo3JTYC2b5uDDtPytI sORA== MIME-Version: 1.0 X-Received: by 10.152.87.170 with SMTP id az10mr901928lab.20.1410110350877; Sun, 07 Sep 2014 10:19:10 -0700 (PDT) Received: by 10.112.64.170 with HTTP; Sun, 7 Sep 2014 10:19:10 -0700 (PDT) In-Reply-To: <20140907170207.14888.qmail@joyce.lan> References: <20140907170207.14888.qmail@joyce.lan> Date: Sun, 7 Sep 2014 13:19:10 -0400 Message-ID: From: Kathleen Moriarty To: John Levine Content-Type: multipart/alternative; boundary=001a11c223b68ee6ef05027ce679 Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/SX385kLqUhumChaL9a9IAc_tFIA Cc: watsonbladd@gmail.com, endymail@ietf.org Subject: Re: [Endymail] spam versus cleartext 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: Sun, 07 Sep 2014 17:19:14 -0000 --001a11c223b68ee6ef05027ce679 Content-Type: text/plain; charset=UTF-8 On Sun, Sep 7, 2014 at 1:02 PM, John Levine wrote: > >To connect to server side filtering, the filtering engine on the > >server just needs to put probabilities it thinks that the message is > >spam in the headers, as well as have a standardized means for the > >client to report spam or ham. This doesn't seem that complicated: just > >a double and some sort of forwarding info to get the backchannel. > >(This assumes naive Bayes as a filter design) > > Keeping in mind that upwards of 90% of mail is spam, you're going to > be downloading an order of magnitude mail if you do the filtering on > the end device. On a desktop with a cable connection that's probably > OK. On my phone, it's not. > > I think it would be worthwhile to detail out the operational practices used today for phishing and spear phishing as well. The APWG does a lot of good work with their members to help combat this problem. Their members include financial institution (affected by these attacks), vendors (help with take-down services in combination with law enforcement and service providers of mail servers, malware distributions points linked in phishing emails, etc.) and others venders/service providers assist with maintaining and distributing up-to-date block lists - not just for email, but also for the malware distribution servers linked in email through the help of browser vendors. Understanding what they need to get their jobs done today and trying to figure out what changes make sense could be very useful. E2e may just change their approach, and that may be fine, but I do think it's important to understand the current environment and side impacts (good & bad) as we move forward. Maybe someone involved int he APWG can help here in a way similar to the email that started this thread? Thanks, Kathleen >True: how much does DKIM+sender based blacklists do vs. filtering > >based on content? > > In terms of volume, IP blacklists are still by far the most effective, > since they knock out most botnet spam. Other than DMARC, which is a > separate can of worms, I don't know of anyone who does message > rejection based on DKIM signatures. There's a whole lot of body > filtering going on. > > Same thing for malware distribution points in phishing attacks, blacklists provided through web browsers is very effective. It uses very few analytic (human) resources and impacts every browser user (enterprise or home). The changes in operational handling of phishing may not be as bad if end users are relied upon most anyway to report, but it would be good to understand how we might be changing things. Thanks, Kathleen > R's, > John > > _______________________________________________ > Endymail mailing list > Endymail@ietf.org > https://www.ietf.org/mailman/listinfo/endymail > -- Best regards, Kathleen --001a11c223b68ee6ef05027ce679 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Sun, Sep 7, 2014 at 1:02 PM, John Levine <<= a href=3D"mailto:johnl@taugh.com" target=3D"_blank">johnl@taugh.com>= wrote:
>To co= nnect to server side filtering, the filtering engine on the
>server just needs to put probabilities it thinks that the message is >spam in the headers, as well as have a standardized means for the
>client to report spam or ham. This doesn't seem that complicated: j= ust
>a double and some sort of forwarding info to get the backchannel.
>(This assumes naive Bayes as a filter design)

Keeping in mind that upwards of 90% of mail is spam, you're goin= g to
be downloading an order of magnitude mail if you do the filtering on
the end device.=C2=A0 On a desktop with a cable connection that's proba= bly
OK.=C2=A0 On my phone, it's not.


I think it wou= ld be worthwhile to detail out the operational practices used today for phi= shing and spear phishing as well. =C2=A0The APWG does a lot of good work wi= th their members to help combat this problem. =C2=A0Their members include f= inancial institution (affected by these attacks), vendors (help with take-d= own services in combination with law enforcement and service providers of m= ail servers, malware distributions points linked in phishing emails, etc.) = and others venders/service providers assist with maintaining and distributi= ng up-to-date block lists - not just for email, but also for the malware di= stribution servers linked in email through the help of browser vendors.

Understanding what they need to get their jobs done t= oday and trying to figure out what changes make sense could be very useful.= =C2=A0E2e may just change their approach, and that may be fine, but I do t= hink it's important to understand the current environment and side impa= cts (good & bad) as we move forward. =C2=A0

Ma= ybe someone involved int he APWG can help here in a way similar to the emai= l that started this thread?

Thanks,
Kath= leen


>True: how much does DKIM+sender based blacklists do vs. filtering
>based on content?

In terms of volume, IP blacklists are still by far the most effectiv= e,
since they knock out most botnet spam.=C2=A0 Other than DMARC, which is a separate can of worms, I don't know of anyone who does message
rejection based on DKIM signatures.=C2=A0 There's a whole lot of body filtering going on.

Same thing for malware distribution points in phishin= g attacks, blacklists provided through web browsers is very effective. =C2= =A0It uses very few analytic (human) resources and impacts every browser us= er (enterprise or home).

The changes in operationa= l handling of phishing may not be as bad if end users are relied upon most = anyway to report, but it would be good to understand how we might be changi= ng things.

Thanks,
Kathleen
= =C2=A0
R's,
John

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



--
=

Best regards,
Kathleen
--001a11c223b68ee6ef05027ce679-- From nobody Sun Sep 7 10:54:52 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 D0A791A048F for ; Sun, 7 Sep 2014 10:54:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.563 X-Spam-Level: * X-Spam-Status: No, score=1.563 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, 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 HzlS57cEq-7R for ; Sun, 7 Sep 2014 10:54:49 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B31641A048C for ; Sun, 7 Sep 2014 10:54:48 -0700 (PDT) Received: (qmail 71073 invoked from network); 7 Sep 2014 17:54:46 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 7 Sep 2014 17:54:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=3b4f.540c9be6.k1409; i=johnl@user.iecc.com; bh=TLxCc6plNYYTslTh2ad8CVxqV/3fU+sewfnWdLEhtzI=; b=D1U9sg9SFjFKYFZqcNihFiDEANIy4xdbQKWcObNcGIh8rf0be500i0bMJRSBUx4r6AxahOISLNgc8XdSBr9jVYsJrYb0Cg3Obpun9uVtrHEoIFD4AoYhIFgBFesbMxxvkfR9CQaabqWD8LKnsCrChCcCRjRwQTT7Y3vBzlDpUKFekWF1ow8Szn0fNupoTFrIX7fXNBfp8MjVYM5HEDOZzPBctlC1anYHHPjyoQn9scjyqmW/GdePuYsBjLpLkEMX DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=3b4f.540c9be6.k1409; olt=johnl@user.iecc.com; bh=TLxCc6plNYYTslTh2ad8CVxqV/3fU+sewfnWdLEhtzI=; b=xepHe6ImJ+2fS437VmP00Qkkt0MdG7rqnccgkaS2Qn0qIT6+Y+ir5TVlT7VB4Sw7xKK0nGBMcuYRPQtCoZAkpzMUrfh9V9hBrDfJW7XRGWVkUND9fbGk8GGjyQUS6XI4ygYHgFkX9M8xCmMkxisax6EgRAUrjemJ/fARQBfA6Tgf1vMwtK1xTftcT7sURlrVKE3b/PryEVLYXS4GqXYEOSs0/twYG/vZgzr/yWmxCDH2LdtZGBaLJ9yFxPxjUxxG Date: 7 Sep 2014 17:54:24 -0000 Message-ID: <20140907175424.15182.qmail@joyce.lan> From: "John Levine" To: endymail@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/SBhRDq2Zg8R0V1wzek6MoIzpYvk Cc: cyrus@daboo.name Subject: Re: [Endymail] where's the end, was spam versus cleartext 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: Sun, 07 Sep 2014 17:54:50 -0000 >True - which likely means you are going to want your desktop client to >always be on and actively filtering your email so the mobile device is not >forced to download something that will eventually get removed. That >basically implies you are running a server (though you could call it an >"agent") on your desktop and would want guarantees of uptime, etc. That is >basically only a small step away from running your own mail server... This sounds very unlike a design that has any chance of being implemented for millions of civilians. My daughter has a laptop that she carries between her apartment where she uses it on the building's shared broadband, and her school where she uses it on the school's network. She uses a Gmail account, which she also checks from her phone, particularly when she's in transit and the laptop is turned off. At a company where I consult, there's a similar setup, they give everyone a laptop which they use on their desk, typically with an external screen, mouse, and keyboard, and can and do take home or on trips. So there isn't anything on which to usefully run a mail server. It seems to me that for any sort of E2E encryption, each user is going to have some computer somewhere that they have to trust to hold the keys and do the decryption. Different people will make different decisions about which computer that is, and it's not always going to one they can physically touch. A lot of people are likely to decide that their mail provider is reliable enough to use as their end. From nobody Sun Sep 7 10:55: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 C6DA91A0491 for ; Sun, 7 Sep 2014 10:55:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lECTW_hmG--x for ; Sun, 7 Sep 2014 10:55:47 -0700 (PDT) Received: from mail-yh0-x22e.google.com (mail-yh0-x22e.google.com [IPv6:2607:f8b0:4002:c01::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8FD51A048F for ; Sun, 7 Sep 2014 10:55:47 -0700 (PDT) Received: by mail-yh0-f46.google.com with SMTP id f73so278155yha.33 for ; Sun, 07 Sep 2014 10:55:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=YC2rK+0Pnap9UKhkF4FY+PBPk/wRQF2NXHaA390yrjk=; b=h+T/TBKgn0yWGCDtA0+4tQpSsiZyy6k2tU5nAQvH+KCmplE4qn8e51gTblRcpZ4bve ecmxmyRkb6cI9AqNzjiwgLgO/WSG+n2K536hPT5il4MtGddQvBgyv5JAau2UAPabwtM+ 3G/EQKaohIGg28k9b3bsB6RxeeFScx+snif1fE21q7YcvM40gYHA+2NP8mr9EIc5cjc/ BMO7/D4DLl2373a7bs5LpIgyIKk4f2qw7k3l8WlPbUnR0xO8kSJI6QGClxL6qwJdHFls VNgFhxniLlIhFxw3fosBG7Ad7cPSf/afT2rg8bWAJrvFwfZp7jPotuvA5zxfq3XbWHKo 6YRw== MIME-Version: 1.0 X-Received: by 10.236.85.208 with SMTP id u56mr36731774yhe.48.1410112546982; Sun, 07 Sep 2014 10:55:46 -0700 (PDT) Received: by 10.170.207.216 with HTTP; Sun, 7 Sep 2014 10:55:46 -0700 (PDT) Date: Sun, 7 Sep 2014 10:55:46 -0700 Message-ID: From: Watson Ladd To: endymail Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/wp1nGOmG3RvidXgJn3TrFz0OCjw Subject: [Endymail] What are the problems? 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: Sun, 07 Sep 2014 17:55:48 -0000 Dear all, Let's back up from spam. If we look at E2E encryption, S/MIME is widely supported and deployed. It's way more heavyweight than it needs to be. PGP same story, but add in completely weird crypto. (I don't actually know what S/MIME does cryptographically: my tolerance for ASN.1 is only so high) Both are unnecessarily complicated. So why aren't they used more? I can think of a few issues. The first issue is UI: nothing much we can do about it here. But if we reduce the complexity of the protocols by subsetting them, the UI doesn't need to expose so much, and so conceivably be simpler. The second issue is multidevice usage. Here we have questions about transporting keys, removing keys from devices (hard), but the core protocols will work. The third issue is webmail: I'm part of the problem here, but I think browser extensions (ugh) can solve it: I don't think we need new protocols. The fourth issue is key discovery. For S/MIME I don't know how this works. For PGP the keyservers work, but the control ensuring you get the right key is the WoT, which is very hard to use, and most people don't do it. In practice the keys get put on websites served over TLS, or tweeted. We should really think about the merits of the Public File: it's very close to what we have with PGP, and would resolve a lot of concerns about CA subversion. Sincerely, Watson Ladd From nobody Sun Sep 7 11:10:12 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 6260A1A05D1 for ; Sun, 7 Sep 2014 11:10:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.423 X-Spam-Level: * X-Spam-Status: No, score=1.423 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, LOTS_OF_MONEY=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 fj02oE_4dNQF for ; Sun, 7 Sep 2014 11:10:05 -0700 (PDT) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 130971A0572 for ; Sun, 7 Sep 2014 11:10:04 -0700 (PDT) Received: by mail-la0-f52.google.com with SMTP id b8so5044731lan.11 for ; Sun, 07 Sep 2014 11:10:03 -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=CBPIq1Pe+kOFW807+uNSsReH/qD/+bq/SgsQZ5dh/Yg=; b=RHJNOzPbxquGR8AAo9ubqIBTLeKMgq4abNNyrW7sl/PRm3QrIGYYQhk3PRD/Twa5HV 7rhsDEeubh5k69xmbnmUU5B0F2zFf6b1da+1cAoBeTIYoAAolKz8Y8ipRTBfR/Jfw9MY F7G0R/BGL4RWJ2KGsOo4UXv8H5M99qYt08d3HxBQ2lXLAknvWJ7CY6UQYrPuMH2R9tAJ D4Hfc8aZgiHCPXXVc1fXn1imku7zkgomYReW7MIn1zq2YrTltHOARSkSFtzYPHvS+7MY sH4Bl0Mg4aT45cXSiKnPeNffolIcxgrxq4BjEOImaeLWKciqzB86cB522GGRx8HUUdZJ 50tQ== MIME-Version: 1.0 X-Received: by 10.152.1.137 with SMTP id 9mr852506lam.85.1410113402881; Sun, 07 Sep 2014 11:10:02 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.122.50 with HTTP; Sun, 7 Sep 2014 11:10:02 -0700 (PDT) In-Reply-To: <540C7399.3060901@cisco.com> References: <540AABF8.8000605@cisco.com> <540C5BE1.6010405@qti.qualcomm.com> <540C7399.3060901@cisco.com> Date: Sun, 7 Sep 2014 14:10:02 -0400 X-Google-Sender-Auth: hS2rzmWCzDVEGjnoWgjnfpsV3SU Message-ID: From: Phillip Hallam-Baker To: Eliot Lear Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/cv7g2PaOxjacKaX_mCXH3vBV47w Cc: Pete Resnick , endymail Subject: Re: [Endymail] spam versus cleartext 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: Sun, 07 Sep 2014 18:10:06 -0000 On Sun, Sep 7, 2014 at 11:02 AM, Eliot Lear wrote: > Let's talk constraints for a moment. Does the problem get easier if we > say, =E2=80=9Clet's not even attempt to address transactional email=E2=80= =9D, and focus > exclusively on h2h? Also, is it a goal to completely do away with > spam? Is that a non-goal? Transactional mail is the easiest to do and has the biggest payoff. So no, not doing it does not help in the slightest. I don't think we are going to be using this scheme to complete transactions. But it has to be possible to use it for applications such as: * Correspondence between lawyers and clients. * Sending statements for bank and brokerage accounts. * Sending invoices. We need those applications because they are applications that will enable a lot of trade and drive a lot of commercial transactions. And if you want to deploy an infrastructure that is going to cost $10 million+++ / yr to run you better have a story that you can deliver benefits in the $ billions. I don't think we need to solve the spam problem. But we can't open up a hole that the spammers can drive a truck through. From nobody Sun Sep 7 11:16:35 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 E4ED21A064B for ; Sun, 7 Sep 2014 11:16:33 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, UNPARSEABLE_RELAY=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 z-Q4SMkYorLW for ; Sun, 7 Sep 2014 11:16:32 -0700 (PDT) Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 864581A063C for ; Sun, 7 Sep 2014 11:16:32 -0700 (PDT) Received: from berryeater.riseup.net (berryeater-pn.riseup.net [10.0.1.120]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.riseup.net", Issuer "Gandi Standard SSL CA" (not verified)) by mx1.riseup.net (Postfix) with ESMTPS id 5856252658 for ; Sun, 7 Sep 2014 11:16:31 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: elijah) with ESMTPSA id 307D942A6F Message-ID: <540CA101.2010000@leap.se> Date: Sun, 07 Sep 2014 11:16:33 -0700 From: Elijah Sparrow 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: In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.98.4 at mx1 X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/XFmva7l85VvcVuzj_FmICsuSvp4 Subject: Re: [Endymail] What are the problems? 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: Sun, 07 Sep 2014 18:16:34 -0000 On 09/07/2014 10:55 AM, Watson Ladd wrote: > Let's back up from spam. I have attempted to enumerate the major issues involved in end-to-end email in this report: https://github.com/OpenTechFund/secure-email It also includes a brief summary of each of the major projects working on 'new generation' end-to-end encrypted email (in general, these projects all seek something less difficult, more automatic, and sometimes with greater security than existing openpgp or s/mime). Phillip may note that the report does not include PPE. I haven't had the chance to update the report with a PPE entry since PPE was posted. Pull requests welcome. The darkmail entry is also out of date, now that they have a new architecture. -elijah From nobody Sun Sep 7 11:23:15 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 E7B5F1A0661 for ; Sun, 7 Sep 2014 11:23:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yJ1VRSU0_B0x for ; Sun, 7 Sep 2014 11:23:12 -0700 (PDT) Received: from mail-yh0-x230.google.com (mail-yh0-x230.google.com [IPv6:2607:f8b0:4002:c01::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 765191A064F for ; Sun, 7 Sep 2014 11:23:12 -0700 (PDT) Received: by mail-yh0-f48.google.com with SMTP id b6so8546541yha.35 for ; Sun, 07 Sep 2014 11:23:11 -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 :content-type; bh=RhBYwjMFAh+cYgAEOvJqq6dbQ3hLKjczGLmViCwdnAw=; b=yvo0woErvq9QxhLtEXLxr4MnfuOtrxZw2/H7QzB9PAeRtz113sQaSZhWtvHKfv6rYQ TqelD61n1FPe1d8NXmwyQx765/BKuPwCfuGWgpuiYnB6mI7i20q53rSaZDBf/6zoT4Zj usujWgO9r1yB0bCY2QqmLWHhOZos7h3BEGIDyTR/kYzbgZq8NXaEFn52qNX2swWKNL8W KxFGwqaYwy8S3vQ79Xi566T705sUHY545uNQ5wE2p6nRSLgRf6gTwSDubFedx2x6eF2G q8H/0jVjPoYuVeFOY3G8WV+yGbTSaHYe+yJN4QnNCDmiKWJShKnSsbLfn1Mq6Vwy/U1/ kQ6g== MIME-Version: 1.0 X-Received: by 10.236.39.178 with SMTP id d38mr1898831yhb.121.1410114191794; Sun, 07 Sep 2014 11:23:11 -0700 (PDT) Received: by 10.170.207.216 with HTTP; Sun, 7 Sep 2014 11:23:11 -0700 (PDT) In-Reply-To: References: <20140907175424.15182.qmail@joyce.lan> Date: Sun, 7 Sep 2014 11:23:11 -0700 Message-ID: From: Watson Ladd To: John R Levine , endymail Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/E8DqP5JEDD4RDDzFIT73cmWwiLc Subject: Re: [Endymail] where's the end, was spam versus cleartext 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: Sun, 07 Sep 2014 18:23:14 -0000 On Sun, Sep 7, 2014 at 11:07 AM, John R Levine wrote: >> So what's wrong with the phone not seeing all mail, because it might >> be spam? 90% of the emails I get come from few sending sites, who I >> know don't spam. > > > I see you're a gmail user. You have no idea how much spam Gmail is > rejecting or discarding before it ever gets anywhere near your inbox. It doesn't matter how much spam is rejected overall: what matters is how much ham is rejected, and how early the spam can be rejected, and, in the case of the phone, how much more tightly we can draw the filtering compared to a desktop machine. Much of the spam in the spam folder doesn't have SPF or DKIM indications, or comes from such venerable institutions as winning.net. Even if the content was encrypted, it would be possible to filter a significant amount of spam through these indications. This can be easily quantified in the case of naive Bayesian classifiers, by looking at the entropy gain of each signal, and doing the usual sort of threshold picking analysis. > >> Furthermore, emails are small > > > Yours may be. I see megabyte spams all the time in my spam folder. And I don't see megabyte emails in my inbox that I want to read. I guess my phone can ignore all of those then. > >> Furthermore, a laptop absolutely can grab a bunch of messages and >> filter them: the fact that it isn't on all the time doesn't make it >> unable to do this. > > > The whole point of having a mail client on my phone is that I can check my > mail when my laptop is turned off. Do you care if you receive a message from someone who may be a spammer a bit late, compared to a message from someone you email back and forth regularly? Email is not reliable. > > As a general rule, whatever your or my mail flow may be, it's not typical of > everyone's, and a design that appears to work for one of us is likely not to > work in general. Sure, but the question is "how much won't it work"? > > Regards, > John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail. -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Sun Sep 7 11:27: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 253C91A066B for ; Sun, 7 Sep 2014 11:27:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.762 X-Spam-Level: X-Spam-Status: No, score=0.762 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, 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 QEcO5rGeSBxO for ; Sun, 7 Sep 2014 11:27:32 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B1D61A0664 for ; Sun, 7 Sep 2014 11:27:32 -0700 (PDT) Received: (qmail 73874 invoked from network); 7 Sep 2014 18:27:31 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=12091.540ca393.k1409; bh=DI106In9bMlo7woVfvtBv9Avh5rEs494x+KKEwjyw3g=; b=GSItyxZlKPzJ1j06gwjjFmSS0GqjbL4oHL4/Vg4bsq9EzZnPV6tDExBGLBf7a+B7WGPYhe35E/FQ0Pkpa7YLSpG3B0rdl/7UGE2M2V5JTJE9zpxBUJY4GlNst28lV+xKb9yNo8ToDj13wVj8FM9ezePEF3MUt0xIaEeacMgaquL75vwyxn6i/Shp3RU+n8tdcOnVYLTO5iz2PyIcwTHy4LlMn8C0PXPVJzzJB1dKfb/tzhDE3d3VhVIO3ZBG13HG DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=12091.540ca393.k1409; bh=DI106In9bMlo7woVfvtBv9Avh5rEs494x+KKEwjyw3g=; b=7HWuVqfdp5dGoowrdUvPJSAzg0bQksyU2rzY8+8ryYH7Q5AWnJSRs4R0jAre08y25mmKDpQXhe4aLf6ZvWQ1NizAQHxjxWGPxfv9he4ZoJcNNZ9WVhN4v5qLoB7S/VZXCRqZmiSXbD0znBuTcIQTxZ0ilnVjhwV1EFQhYPJr3NKV8k6f4+xX+xRbAgKT76eA3ZX5AY7wHzZiyjUrCQQtW21Ey4wwEwcLerEyQ3BftS3Y4HaIi26jGmD9IY7li7OJ Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 07 Sep 2014 18:27:30 -0000 Date: 7 Sep 2014 14:27:30 -0400 Message-ID: From: "John R Levine" To: "Watson Ladd" In-Reply-To: References: <20140907175424.15182.qmail@joyce.lan> User-Agent: Alpine 2.11 (BSF 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/OhyyY15Zq645ZHzQ2xRA2MAbQCc Cc: endymail Subject: Re: [Endymail] where's the end, was spam versus cleartext 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: Sun, 07 Sep 2014 18:27:33 -0000 >> I see you're a gmail user. You have no idea how much spam Gmail is >> rejecting or discarding before it ever gets anywhere near your inbox. > > It doesn't matter how much spam is rejected overall: what matters is > how much ham is rejected, and how early the spam can be rejected, and, > in the case of the phone, how much more tightly we can draw the > filtering compared to a desktop machine. ... Really, you cannot assume that the mail you get at your gmail account is typical of anything. You also have no idea how much spam Gmail doesn't even put in your spam folder, based on content analysis they didn't tell you about. > This can be easily quantified in the case of naive Bayesian > classifiers, by looking at the entropy gain of each signal, and doing > the usual sort of threshold picking analysis. Um, have you ever talked to people who run large mail systems about the way their spam filtering really works? Many of us here have done so, and it's a lot more complicated than it might seem. R's, John From nobody Sun Sep 7 14:12:52 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 5A07C1A067D for ; Sun, 7 Sep 2014 14:12:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.653 X-Spam-Level: X-Spam-Status: No, score=-8.653 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=-1.652, 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 6VKWDg6fJw1X for ; Sun, 7 Sep 2014 14:12:46 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C41A11A00F1 for ; Sun, 7 Sep 2014 14:12:46 -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=1410124366; x=1441660366; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=vFGy3myhxEV1xFEcoIPV8iAh5kg0P7OuOFUHFbxHX2s=; b=sRD1cIt4O3tAjVQ1p1R5+zSsfzG00FFS2mpTXlcmUCU3mQ1C9yKOWA9S QPPFfrzWgbGLV6fg9XaQDwP8NkIkdpJ7L/dl/IpWdFAYP4d75IdpKAhf8 2Yh1NQVf/qur9jdmrLXhUHoIO2SFyxxI0GBg+6QSbPYwKZ6hs8RfD2nkX Q=; X-IronPort-AV: E=McAfee;i="5600,1067,7554"; a="157004330" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by wolverine02.qualcomm.com with ESMTP; 07 Sep 2014 14:12:46 -0700 X-IronPort-AV: E=Sophos;i="5.04,483,1406617200"; d="scan'208";a="746093355" Received: from nasanexhc14.na.qualcomm.com ([172.30.48.23]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 07 Sep 2014 14:12:46 -0700 Received: from nasanexhc05.na.qualcomm.com (172.30.48.2) by nasanexhc14.na.qualcomm.com (172.30.48.23) with Microsoft SMTP Server (TLS) id 14.3.181.6; Sun, 7 Sep 2014 14:12:45 -0700 Received: from presnick-mac.local (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.2) with Microsoft SMTP Server (TLS) id 14.3.181.6; Sun, 7 Sep 2014 14:12:45 -0700 Message-ID: <540CCA3E.8020505@qti.qualcomm.com> Date: Sun, 7 Sep 2014 18:12:30 -0300 From: Pete Resnick 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: Phillip Hallam-Baker References: <540AABF8.8000605@cisco.com> <540C5BE1.6010405@qti.qualcomm.com> In-Reply-To: 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/imP1Q5btuY8r3n3rp7A8zEItEIA Cc: Eliot Lear , endymail Subject: Re: [Endymail] spam versus cleartext 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: Sun, 07 Sep 2014 21:12:48 -0000 On 9/7/14 11:09 AM, Phillip Hallam-Baker wrote: > On Sun, Sep 7, 2014 at 9:21 AM, Pete Resnick wrote: > > >> Along similar lines to what John Levine said,: Obviously doing e2e crypto >> gets you signatures. Since we are blue-skying here, I think it is perfectly >> plausible to say, "If you want to send me e2e encrypted messages, you also >> have to send me signed messages, and you don't or your signature is not in >> my contacts list already, your encrypted mail is going to bounce." I think >> it's possible that in the fullness of time, many users go to a contact-list >> model of email (a la IM) where the mail simply bounces unless it has a >> signature that is already in the contacts list. >> > > I think that is right, but not the whole picture. > A tangential up-level: I haven't gotten through all of the mail on the list yet (travel and other things have slowed me down), but I do notice that there has been quite a bit of "whole picture" discussion. I think that's fine, as blue-skying does involve thinking about how all of the pieces fit together. But as Stephen and I said in the first message, the thing we're looking for on this list is to "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." So while it's *possible* that a forklift replacement of email as we know it might be one of those "bits of work", separating out some smaller work items that could eventually be fit together into a shiny new system are probably the more interesting ideas. :-) That said, a couple of questions that have been rattling around in my brain: > I see endymail as a subset of mail. All mail should be encrypted at > the message layer but only whitelisted mail would be e2e encrypted. > > This can be done automatically as follows: > > > A) Some sort of discovery infrastructure maps email addresses to key hashes. > B) Some sort of discovery infrastructure maps key hashes to keys. > I've been wondering about this. When I think about using crypto (whether encryption or signatures), it seems like requiring a discovery mechanism was increasing the burden. For many of my correspondents, with whom I'm currently communicating in the clear, a TOFU key exchange in those emails (authenticated out-of-band) might be a plausible mechanism. When we think about this, do we really need to assume that we either use the old or the new, and never the twain shall meet? pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Sun Sep 7 14:44:20 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 098BE1A0712 for ; Sun, 7 Sep 2014 14:44:20 -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 PbcQ8L1jAAFe for ; Sun, 7 Sep 2014 14:44:18 -0700 (PDT) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FB621A0711 for ; Sun, 7 Sep 2014 14:44:18 -0700 (PDT) Received: by mail-lb0-f177.google.com with SMTP id l4so3202731lbv.8 for ; Sun, 07 Sep 2014 14:44:16 -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=CWnGMkfH6l4u0laMeQvzqPV6PHcm0tAZaY1NUAqdrWY=; b=YkdBmeHNaCdEy4TwhGfLoAYY3eeY6SPAvfkfxZjdZJQU+0bsq7Vhcev6hUfOfa/VKF ijUMH8ODdLuazwlPFImNetOQB+qcL76uqmmJIDtIrvkj0SkQlQ3+sVq36NpZDkl18n6T Q87VPG4AdPreD8UtSddK0TWTIrKZpyD25n/6dfhOozCmMi1xxInSCh6kZVg+3VRVbG+L UjjYIUiNEFwzB4AEraQP9EHZijQr7aylsPktFGt7PCR2V+q4Zt9WHRe3Hl90ZcjIOzoD lVBD4jptiivGVRlTjXNSDjm1YM4Y5goAAaFRNJeoXZKAn2Em6QTL+IxNAfV9N6u/uWEY bA8A== MIME-Version: 1.0 X-Received: by 10.112.202.106 with SMTP id kh10mr23813450lbc.66.1410126256632; Sun, 07 Sep 2014 14:44:16 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.122.50 with HTTP; Sun, 7 Sep 2014 14:44:16 -0700 (PDT) In-Reply-To: <540CCA3E.8020505@qti.qualcomm.com> References: <540AABF8.8000605@cisco.com> <540C5BE1.6010405@qti.qualcomm.com> <540CCA3E.8020505@qti.qualcomm.com> Date: Sun, 7 Sep 2014 17:44:16 -0400 X-Google-Sender-Auth: uWEr1MNjy9IpC981nGLqdPHwUm0 Message-ID: From: Phillip Hallam-Baker To: Pete Resnick Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/dtk5aI2mmSQ8UXmGyU-5FQJwuzI Cc: Eliot Lear , endymail Subject: Re: [Endymail] spam versus cleartext 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: Sun, 07 Sep 2014 21:44:20 -0000 On Sun, Sep 7, 2014 at 5:12 PM, Pete Resnick wrote: > On 9/7/14 11:09 AM, Phillip Hallam-Baker wrote: >> >> On Sun, Sep 7, 2014 at 9:21 AM, Pete Resnick >> wrote: >> >> >>> >>> Along similar lines to what John Levine said,: Obviously doing e2e crypto >>> gets you signatures. Since we are blue-skying here, I think it is >>> perfectly >>> plausible to say, "If you want to send me e2e encrypted messages, you >>> also >>> have to send me signed messages, and you don't or your signature is not >>> in >>> my contacts list already, your encrypted mail is going to bounce." I >>> think >>> it's possible that in the fullness of time, many users go to a >>> contact-list >>> model of email (a la IM) where the mail simply bounces unless it has a >>> signature that is already in the contacts list. >>> >> >> >> I think that is right, but not the whole picture. >> > > > A tangential up-level: I haven't gotten through all of the mail on the list > yet (travel and other things have slowed me down), but I do notice that > there has been quite a bit of "whole picture" discussion. I think that's > fine, as blue-skying does involve thinking about how all of the pieces fit > together. But as Stephen and I said in the first message, the thing we're > looking for on this list is to "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." So while it's *possible* that a forklift > replacement of email as we know it might be one of those "bits of work", > separating out some smaller work items that could eventually be fit together > into a shiny new system are probably the more interesting ideas. :-) I don't think we can get rid of SMTP right now. But any system that allows a sender to decide between sending encrypted and sending in plaintext can easily contain a slot that makes it *really easy* to swap out SMTP if desired. The bit that I really don't want to redo is the S/MIME messaging layer. That works fine for packaging up the bytes. It works with attachments and all the stuff we expect from modern mail. Any new mail security standard has to be able to serve as a replacement for both S/MIME and PGP. Otherwise we will just continue the standards stalemate. It is easier to graft PGP functions onto the fully developed S/MIME message format than to try to get PGP/MIME up to a similar level of support. But we do have to make sure PGP users don't get left behind and they have to be able to achieve the same level of security they can achieve today without being required to use a CA. > That said, a couple of questions that have been rattling around in my brain: > >> I see endymail as a subset of mail. All mail should be encrypted at >> the message layer but only whitelisted mail would be e2e encrypted. >> >> This can be done automatically as follows: >> >> >> A) Some sort of discovery infrastructure maps email addresses to key >> hashes. >> B) Some sort of discovery infrastructure maps key hashes to keys. >> > > > I've been wondering about this. When I think about using crypto (whether > encryption or signatures), it seems like requiring a discovery mechanism was > increasing the burden. For many of my correspondents, with whom I'm > currently communicating in the clear, a TOFU key exchange in those emails > (authenticated out-of-band) might be a plausible mechanism. > > When we think about this, do we really need to assume that we either use the > old or the new, and never the twain shall meet? Well the discovery mechanism could be as minimal as 'take a domain name and a hash of the key, pull the key from http:///.well-known/phb/ I don't want to put anything more complicated in the client though. Because as you point out, there are likely to be lots of ideas. And in particular there will be ideas based on TRANS like infrastructures. >From a trust point of view, the expiry of the Harber-Stornetta patents is a very big deal. Putting keys and/or certs into notary logs gives a huge amount of leverage. It also means that you will want some sort of infrastructure fishing keys out of the logs. But just don't weld any of that into clients yet... From nobody Sun Sep 7 16:07:02 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 DFB941A0860 for ; Sun, 7 Sep 2014 16:06:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.762 X-Spam-Level: X-Spam-Status: No, score=0.762 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, 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 VCZInBuFRP48 for ; Sun, 7 Sep 2014 16:06:57 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 315821A0842 for ; Sun, 7 Sep 2014 16:06:56 -0700 (PDT) Received: (qmail 99354 invoked from network); 7 Sep 2014 23:06:55 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=18419.540ce50f.k1409; bh=I2lFDV7xe02SsTpq1/Fq7yh+L2XJO3ZB2AoVwQhzXLQ=; b=LY8HaRVDVHxncylDizYPJkDW2m1eupq/jOJvqX7LxHcJsT8P2tQVcBM66eM3nCyyKTowDZLBCgGUwaFPtsrg9qJeRQ28LdAM0yhBRKHgjUPaLtQ6VfO7ihGvYV5CH5v1jGL0D8x8qxJ4BlATKSWUYn5PSDUlFb42b2vPYypwhVhgcH41C0YUZf4DPfDEajs7FqzdCJ2Rui9TWUlnhsnpeXGR0jS/v2D1CYjizDXlEwesxrdVmFISxAyGVmS8hXD7 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=18419.540ce50f.k1409; bh=I2lFDV7xe02SsTpq1/Fq7yh+L2XJO3ZB2AoVwQhzXLQ=; b=bAGQcqlBfShaK6uHVNfksUSO3FQeRkDPJLtBMMBUe/dC+XVfDI8YtoUH18KJAUVYnQ9O95YkIqPDjPmquS82BwzipnMC90oNPdWTvtZ7imK/P9CyEpgpCj2w8hHp6KV1jTxxuUAyvHzKMCTkVaRzGOTR1eRUuNB63Zdzc52zpk2evqVB0yWM5fiQTHAe9oUH+HO8Ck3aN1lTrRE1Px90RblXOm/B+mV4qitxnXhrakUjKHZtaZLaZy0+BqQXm10H Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 07 Sep 2014 23:06:55 -0000 Date: 7 Sep 2014 19:06:54 -0400 Message-ID: From: "John R Levine" To: "Pete Resnick" In-Reply-To: <540CCA3E.8020505@qti.qualcomm.com> References: <540AABF8.8000605@cisco.com> <540C5BE1.6010405@qti.qualcomm.com> <540CCA3E.8020505@qti.qualcomm.com> User-Agent: Alpine 2.11 (BSF 23 2013-08-11) MIME-Version: 1.0 Content-Type: MULTIPART/signed; protocol="application/pkcs7-signature"; micalg=sha1; BOUNDARY="3825401791-2067031743-1410131215=:16169" Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/htSwS9oXfMHky5xe8LUnEtYBxZY Cc: endymail Subject: Re: [Endymail] spam versus cleartext 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: Sun, 07 Sep 2014 23:06:59 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --3825401791-2067031743-1410131215=:16169 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed >I've been wondering about this. When I think about using crypto (whether >encryption or signatures), it seems like requiring a discovery mechanism >was increasing the burden. For many of my correspondents, with whom I'm >currently communicating in the clear, a TOFU key exchange in those >emails (authenticated out-of-band) might be a plausible mechanism. Take current implementations of S/MIME and adjust them to allow self-signed certificates in addition to (or instead of) ones signed by a list of CAs configured into the MUA. All done. In my experience, the main problems with S/MIME are key distribution and key discovery. For key distribution, you need to go to someplace like Comodo or Startcom to get a signed cert, which goes into your browser, and then you need to do some grotty software specific thing to export it from the browser and import it into the MUA. For key discovery, in practice everyone populates their keystores with certs from incoming signed mail, which is supposed to be safe because it only accepts keys that are signed. It is supposed to be possible to get keys via LDAP from a key server, but people don't do that. A system with key discovery, so you can send all mail encrypted to someone, including the first one, seems more useful than one that requires an insecure handshake first. Key distribtion via DANE could be a reasonable approach. R's, John --3825401791-2067031743-1410131215=:16169 Content-Type: APPLICATION/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: BASE64 Content-Description: S/MIME Cryptographic Signature Content-Disposition: attachment; filename=smime.p7s MIII7gYJKoZIhvcNAQcCoIII3zCCCNsCAQExCzAJBgUrDgMCGgUAMAsGCSqG SIb3DQEHAaCCBh8wggYbMIIFA6ADAgECAgMJWEYwDQYJKoZIhvcNAQELBQAw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTAeFw0xNDAzMTgxOTQ3NDdaFw0xNTAzMjAwMDU2MDBaMDoxGDAW BgNVBAMMD2pvaG5sQHRhdWdoLmNvbTEeMBwGCSqGSIb3DQEJARYPam9obmxA dGF1Z2guY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAnMGH 52DBxB4jb86Sxi3VvgOjirvLveIVP7zvqxBDpJzxrF02wCYwnQuxi3S3U5ge 3iHihzhM9qP+N03frkr4KH6Spgec88YjMioVQStTQZcrogTdHweZOgT8tckg HEmHCF8uHBjD0HbfDk+9zYFtaE3QPk5aGm02Id0fNNM5WmSQSxVwF0Ddryq5 vIU0AHbB/1kok1zJpwWA06SgHenlnYngnSpNWlOn+SxboiD28m2XTWDP5ULL e1b040VtkQMzpuVXzAHWVQYQWUevJ4y8mrUsqAyGuYSb5pTU28D+NExVAYxn WD94rzgBpkXgC4Xxcp3TmyfMaLMF4M9ef0nu+QIDAQABo4IC1TCCAtEwCQYD VR0TBAIwADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsG AQUFBwMEMB0GA1UdDgQWBBSpNAr06FueusUfmbDdecnZ1kznsTAfBgNVHSME GDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAaBgNVHREEEzARgQ9qb2hubEB0 YXVnaC5jb20wggFMBgNVHSAEggFDMIIBPzCCATsGCysGAQQBgbU3AQIDMIIB KjAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5 LnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlv biBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3Vl ZCBhY2NvcmRpbmcgdG8gdGhlIENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJl bWVudHMgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeSwgcmVsaWFuY2Ugb25s eSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29tcGxpYW5jZSBvZiB0 aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wNgYDVR0fBC8wLTAroCmg J4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYI KwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRz c2wuY29tL3N1Yi9jbGFzczEvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRw Oi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MxLmNsaWVudC5j YS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0G CSqGSIb3DQEBCwUAA4IBAQC3OSsHtuc1se2JPbLqI1b31i0EER3UX6Ep2Zuy FkACIpk/i8mPi0KIfMWWiDlNmqeQEq8308i0/2mVcMVdgKWIUMJdZb3CmNfs 3qtTlrdXXYXT7ZLjL6a1Bbh/lKUm35JYRH8zf3rqDbLkpiA92vc7uTQcbDay 1sQ4CSTvOWuq0CIwMXqJePhHf/runG7ndDuX2yFagHlxhsvn7raw5NQuu4Sj ofwbNiszwkryB7ZYUxq2Pg2i1m2XlgMbNEfw8deAZOyHGKKGz25Ei1KvJofH 1izh0WDU+ueJum6RHm8/o/i53MbYZN4Il64aBD1HPqQow3jHQBhAc8XN85hH csS2MYIClzCCApMCAQEwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZp Y2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDCVhGMAkGBSsOAwIaBQCggdgw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTQw OTA3MjMwNjU0WjAjBgkqhkiG9w0BCQQxFgQUyPVFp296Bl0ym1Wmv0QKRkOh 8V0weQYJKoZIhvcNAQkPMWwwajALBglghkgBZQMEASowCwYJYIZIAWUDBAEW MAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcN AQEBBQAEggEANgCyJO3b0+5vuT4vTwZkSttHPrzBieb+SR8OACoZMxUu2cpE 87TziJRcrVS8sJiRWD4Hxy0b+/pq+oONLPJDGvE22rumHnrddQZQM/cdYjhW kppI3BauBrxCJrxMJDFhr6pSZswlu70S5quWxCH+HR8WYJ/JPxRMefce1ZvR S9uLc4aDbQiSZX80Hb+FeiY1hSKs2eJrWkiDJaOezIr4Gf6WnVzgjcGbBM88 UVIHubbHAJazsMljy3kwqKNoBZQY8qmpWVq3nfdDahu9aPVfF3v5KCu00xFZ RzxrVWbUzGZRQS5HA6MXEaIX1U+BBje0+mUNjRu9ftbPR3Wasptx9w== --3825401791-2067031743-1410131215=:16169-- From nobody Sun Sep 7 19:21:15 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 DD5B61A0B81 for ; Sun, 7 Sep 2014 19:21:12 -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 Q1C-ajHfBe5a for ; Sun, 7 Sep 2014 19:21:10 -0700 (PDT) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 136441A0B7E for ; Sun, 7 Sep 2014 19:21:09 -0700 (PDT) Received: by mail-la0-f45.google.com with SMTP id pn19so16647215lab.32 for ; Sun, 07 Sep 2014 19:21:08 -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=IkMs9maqU4QtZHN3SS0xZuXfz/H9dqE5K85+3dh2Ybo=; b=yhNyumRKztHqZ2PHaO1U2N8N2akXqWpmY4nAmT8ACriz2XbRHiSLaaT9YTdGFZ1WRn QOueAkkPSeUL94Agxvw11feFGGASAkLzE0mAcJtMwE0xN0sW59JJl2mmiI//ywskuYAt YRhRtOCf+8WD3koIppq5NjcC5F4r8fc/r1paXB0WNl3gkv+URtK/8iyN4IFizrndtLfY kIEI9dUjkLzFDkwzixolC5HnEtvOtn0C62zLMXqzKE20p+mPYZXnlGugaXH4+r4+CJrs 33GQ2gtMSEZ/gC5VfgcPHylR0o8h3HSRVmgGytsv5g7mATH+iCO0Q23gxdAo9Dbdjin6 1G2A== MIME-Version: 1.0 X-Received: by 10.152.18.165 with SMTP id x5mr7061110lad.42.1410142868179; Sun, 07 Sep 2014 19:21:08 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.122.50 with HTTP; Sun, 7 Sep 2014 19:21:08 -0700 (PDT) In-Reply-To: References: Date: Sun, 7 Sep 2014 22:21:08 -0400 X-Google-Sender-Auth: O3nFNkPBXR3itTOjOXEjzhsAbzE Message-ID: From: Phillip Hallam-Baker To: Watson Ladd Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/E3JMF-J5T7pHeTLKrneifboTfZY Cc: endymail Subject: Re: [Endymail] What are the problems? 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, 08 Sep 2014 02:21:13 -0000 On Sun, Sep 7, 2014 at 1:55 PM, Watson Ladd wrote: > Dear all, > Let's back up from spam. > > If we look at E2E encryption, S/MIME is widely supported and deployed. > It's way more heavyweight than it needs to be. PGP same story, but add > in completely weird crypto. (I don't actually know what S/MIME does > cryptographically: my tolerance for ASN.1 is only so high) Both are > unnecessarily complicated. So why aren't they used more? I can think > of a few issues. > > The first issue is UI: nothing much we can do about it here. But if we > reduce the complexity of the protocols by subsetting them, the UI > doesn't need to expose so much, and so conceivably be simpler. While S/MIME is horribly complicated to implement, thats not the cause of the UI disaster. The implementation complication is due to the use of ASN.1 which is a nightmare to program and if you do it the usual way requires a monstrously complex compiler with a big obese run time. But all of that bit is hidden from the user. > The second issue is multidevice usage. Here we have questions about > transporting keys, removing keys from devices (hard), but the core > protocols will work. This is the part where the legacy code is just insane. With PPE, all you do to configure Windows Live mail to accept encrypted mail is run the key generator and post the file it generates to a Web site. If you give it the domain of a crypto service then the service will do the post to a web site for you as well. Without PPE what you have to do is * Find a CA * Find the S/MIME page at the CA site, fill in lots of forms * Respond to an email challenge, here it is essential that you go back to the CA web site with the same browser or it won't work. * Start Windows Live Mail, find the security configuration tab on the account * Tell Windows Live Mail to use the certificate Thats ten minutes if you are lucky. Now Thunderbird on the other hand you have all of those steps only you also have to export the key and certificate out of your Windows certificate manager and then import it into the Thunderbird key manager as well. On iPhone you can use S/MIME but the mechanism for importing a certificate and key was documented nowhere I can find. I had to ask an Apple employee. Apparently you send an email message to yourself with the encrypted key attached. Then you can open the message and it will import the key. Again, this is a one button operation without Web service support and only a little harder with web service support (and then only if you are using the open source version of the code, I would guess if there is a Comodo branded version of the key manager it will automatically connect up to Comodo and so the user won't have to enter anything.) Point is that there is absolutely no reason that the UI can't be fixed. The failure is in the integration into the product. It does not take a usability lab to spot these problems. They should be obvious to anyone with a brain. The whole process is just makework for the user. Another big problem is that pretty much every multi-platform program tends to insist on managing keys itself rather than using operating features for the purpose. The inevitable result is a really shit user experience and gaping security holes. Windows and Mac both have mechanisms in place for protecting keys in a user's account. So they don't need to enter a passphrase to read each mail. Thunderbird tries to use its own and does a horrible job of it. > The third issue is webmail: I'm part of the problem here, but I think > browser extensions (ugh) can solve it: I don't think we need new > protocols. Well reading mail is easy enough, just pop out a viewer that pulls the user's key from the machine keystore. > The fourth issue is key discovery. For S/MIME I don't know how this > works. For PGP the keyservers work, but the control ensuring you get > the right key is the WoT, which is very hard to use, and most people > don't do it. In practice the keys get put on websites served over TLS, > or tweeted. > > We should really think about the merits of the Public File: it's very > close to what we have with PGP, and would resolve a lot of concerns > about CA subversion. > > Sincerely, > Watson Ladd > > _______________________________________________ > Endymail mailing list > Endymail@ietf.org > https://www.ietf.org/mailman/listinfo/endymail From nobody Sun Sep 7 20:09:51 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 9D90F1A6ED8 for ; Sun, 7 Sep 2014 20:09:48 -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 h5esrpl3eiyE for ; Sun, 7 Sep 2014 20:09:44 -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 64ED51A1F20 for ; Sun, 7 Sep 2014 20:09:44 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 592532AB2D0; Mon, 8 Sep 2014 03:09:41 +0000 (UTC) Date: Mon, 8 Sep 2014 03:09:41 +0000 From: Viktor Dukhovni To: endymail@ietf.org Message-ID: <20140908030941.GT26920@mournblade.imrryr.org> References: <540AABF8.8000605@cisco.com> <540C5BE1.6010405@qti.qualcomm.com> <540CCA3E.8020505@qti.qualcomm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/dhf3OmhQAi0owI36ZYrsuZyHIls Subject: Re: [Endymail] spam versus cleartext 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: Mon, 08 Sep 2014 03:09:48 -0000 On Sun, Sep 07, 2014 at 07:06:54PM -0400, John R Levine wrote: > Take current implementations of S/MIME and adjust them to allow > self-signed certificates in addition to (or instead of) ones signed by > a list of CAs configured into the MUA. Apple's desktop Mail.app allows one (via Keychain) to bind a particular (self-signed or not) key to a particular sender. With Outlook the only choice is to trust the issuing CA for all addresses. As for what the IETF can do, maybe address sign-then-encrypt vs. encrypt-then-sign in S/MIME unless I missed the memo and this is no longer an issue. The SMIMEA draft is not yet published, I don't recall seeing a mechanism there to explicitly publish domain (gateway) keys, in addition to or instead of keys for each user. Perhaps wildcard DNS entries can simulate gateway keys. When SMIMEA records supply only the hash of a trust anchor, or of a user certificate, rather than the key, then the relevant public keys would have to be conveyed in band. For example via a reply from the user as suggested by Phillip Hallam-Baker. Thus SMIMEA is compatible with various more detailed models of key distribution. SMIMEA might not directly expose the actual public keys of individual users or even their hashes, rather it could simply publish a fixed certification authority that issues X.509 email certificates to the users of a domain. This can make the initial contact leaf of faith more secure. It might be useful to define message headers that an MSA or border outbound MTA should use to infer e2e encryption policy, for example by sending mail only when a suitable encryption key is available for a recipient. Gateways could send signed, but unencrypted contact requests to such users requesting a signed response (which could be verified via SMIMEA). Receiving user agents could respond directly with a signed message, or insert similar headers to have the recipient's gateway provide the requisite signature and public key certs. So mostly what's missing is new MUA code to support new key management models. Implementations may unearth the need for new headers or other relevant standards that enable the new feature set, but my guess is that for now what is missing is new code more than new standards. Perhaps this list will produce something unexpected that will lead the way to new implementations, but my guess is that it will be other way around. -- Viktor. From nobody Mon Sep 8 06:53: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 699DD1A87E4 for ; Mon, 8 Sep 2014 06:53:41 -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 qH8eWVpxpSM4 for ; Mon, 8 Sep 2014 06:53:39 -0700 (PDT) Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 490071A0336 for ; Mon, 8 Sep 2014 06:53:39 -0700 (PDT) Received: by mail-la0-f53.google.com with SMTP id ge10so97926lab.12 for ; Mon, 08 Sep 2014 06:53:36 -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:content-type; bh=G0R7QiKkPI3w/epMBvK2CFZyxxo9xZ1WbXCvxn8efLI=; b=GaTyxwGsZjjpFf2XDLo5Uv7RYpa8gQ/4uETPS40VGV9jSW4Get4FtIBE5in3z9ULI6 PzImFRo3vacDuTNlAKCVCKwPwAbsT6tBuVfrEK2D9hz4baD7e2xFrq8MQjNZvxPHU8fb rHG4Zyy/HlJvb5wKxZAzWkjJ+z1EdyrCzE8SiUWubksaFw/FLhND1kkEi/zFvBcxSWHA 88zaTnMK6t+9IzRrkk8Hp11lGCPksjGkwM9aItpDbdwNFg0jpnv2UXmU8bO2oiM5PM6N wZE8nJ4/wDBOI+PRYJ/MGeiuoLmCjgD00RF77vwo47nzyrgnwIqyFiQUee0waNgDp1vg RO3Q== MIME-Version: 1.0 X-Received: by 10.112.157.162 with SMTP id wn2mr26001869lbb.18.1410184414592; Mon, 08 Sep 2014 06:53:34 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.122.50 with HTTP; Mon, 8 Sep 2014 06:53:34 -0700 (PDT) In-Reply-To: <20140908030941.GT26920@mournblade.imrryr.org> References: <540AABF8.8000605@cisco.com> <540C5BE1.6010405@qti.qualcomm.com> <540CCA3E.8020505@qti.qualcomm.com> <20140908030941.GT26920@mournblade.imrryr.org> Date: Mon, 8 Sep 2014 09:53:34 -0400 X-Google-Sender-Auth: QPTAZmcDl-JUmdF2YbIHPOzUa4k Message-ID: From: Phillip Hallam-Baker To: endymail Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/WMq68HYH2K3PgPSfSW3tGo5isTE Subject: Re: [Endymail] spam versus cleartext 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, 08 Sep 2014 13:53:41 -0000 On Sun, Sep 7, 2014 at 11:09 PM, Viktor Dukhovni wrote: > On Sun, Sep 07, 2014 at 07:06:54PM -0400, John R Levine wrote: > >> Take current implementations of S/MIME and adjust them to allow >> self-signed certificates in addition to (or instead of) ones signed by >> a list of CAs configured into the MUA. > > Apple's desktop Mail.app allows one (via Keychain) to bind a > particular (self-signed or not) key to a particular sender. With > Outlook the only choice is to trust the issuing CA for all addresses. > > As for what the IETF can do, maybe address sign-then-encrypt vs. > encrypt-then-sign in S/MIME unless I missed the memo and this is > no longer an issue. > > The SMIMEA draft is not yet published, I don't recall seeing a > mechanism there to explicitly publish domain (gateway) keys, in > addition to or instead of keys for each user. Perhaps wildcard > DNS entries can simulate gateway keys. http://tools.ietf.org/html/draft-hoffman-dane-smime-01 > When SMIMEA records supply only the hash of a trust anchor, or of > a user certificate, rather than the key, then the relevant public > keys would have to be conveyed in band. For example via a reply > from the user as suggested by Phillip Hallam-Baker. Thus SMIMEA > is compatible with various more detailed models of key distribution. My Omnibroker architecture could pull key information from the DNS. But I don't see that as a very useful approach for anything finer than domain level granularity. The problem is that DNS is a host and service management infrastructure and email accounts are a user infrastructure. Most enterprises don't want to mix the two and with good reason. The EU 'privacy' issues are remarkably similar to user concerns about spam. If you don't want or need finer granularity than the domain, then putting the records in the DNS is a fine approach - see DKIM. But for the same reason that the DANE folk ignored DKIM and did their own thing, I can't see DANE as a very useful starting point. If we were going to go anywhere then surely going back to DKIM for another email infrastructure would make more sense. There is also a difference between use of keys for signature and use of keys for encryption. With signature verification you already start from a signed document and that can carry the key. With encryption you start from the address of the person you want to contact and have to assemble all the rest of the info somehow. > SMIMEA might not directly expose the actual public keys of individual > users or even their hashes, rather it could simply publish a fixed > certification authority that issues X.509 email certificates to > the users of a domain. This can make the initial contact leaf of > faith more secure. That is certainly one viable approach. And it is probably a good one for some applications. But it only really works for the existing enterprise use case of S/MIME. If we have alice@google.com then she is a google employee and if I am talking to her on Google company business then it makes all good sense to use the Google CA. One of the weaknesses of the PGP model was that the design ignored the fact that in many circumstances we are in hierarchical organization structures that the CA model matches very well. If we have alice@gmail.com, which could be the same Alice as before but in her personal capacity then it might make really good sense for Google to run up a CA for gmail (or contract out to a CA) and issue a certificate for her validated key. But the certificate issued is only authenticating alice@gmail.com, it isn't authenticating Alice. The distinction here is critical if Alice changes email providers or wants to use her certificate to exchange mail with her bank or a whole host of similar activities. [If is also quite possible that gmail.com has separate non-endy keys which can be used for message level security.] > So mostly what's missing is new MUA code to support new key management > models. Implementations may unearth the need for new headers or > other relevant standards that enable the new feature set, but my > guess is that for now what is missing is new code more than new > standards. Perhaps this list will produce something unexpected > that will lead the way to new implementations, but my guess is > that it will be other way around. No, what is missing is new Web Service code to implement the prototype of those systems. Changing MUAs is hard. It is hard for developers and hard for users. Which is why I have architected my testbed so that it has an open source proxy for outbound mail which applies message encryption under the direction of a trusted Web service. People use a large number of mail clients - Outlook, Windows Live Mail, Apple Mail, iOS Mail, Thunderbird, MUTT etc. etc. The only way to work out if a trust infrastructure is viable is to try it out on a large scale. Do you really want to have to update seven mail clients each time we try a test? Splitting out the trust decisions into a Web Service mean that you can develop your idea of a trust infrastructure and I can develop mine and we can make both available to people who use the same code. I would very much prefer the code that is currently in the proxy to be in the MUA but right now I want to decouple MUA development and trust architecture development as far as we can. We can always migrate functions into the MUA once we understand what they should be. What I would like to get fixed in MUAs right now is the part that is handled abysmally on every client I have tried so far: Key management. From nobody Mon Sep 8 11:46: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 BECD31A02F7 for ; Mon, 8 Sep 2014 11:46:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-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 qTQtQJ7WriYq for ; Mon, 8 Sep 2014 11:46:48 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDED41A02C2 for ; Mon, 8 Sep 2014 11:46:47 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1XR3xe-0005ig-Az for ; Mon, 08 Sep 2014 20:46:46 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.82 #3 (Debian)) id 1XR3t1-0002LZ-OR; Mon, 08 Sep 2014 20:41:59 +0200 From: Werner Koch To: Phillip Hallam-Baker References: <540AABF8.8000605@cisco.com> <540C5BE1.6010405@qti.qualcomm.com> <540CCA3E.8020505@qti.qualcomm.com> <20140908030941.GT26920@mournblade.imrryr.org> Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: id=1E42B367; url=finger:wk@g10code.com Date: Mon, 08 Sep 2014 20:41:59 +0200 In-Reply-To: (Phillip Hallam-Baker's message of "Mon, 8 Sep 2014 09:53:34 -0400") Message-ID: <87egvm7y4o.fsf@vigenere.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/fnzquLLNLQidkJexPRtyffWuQ98 Cc: endymail Subject: Re: [Endymail] spam versus cleartext 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, 08 Sep 2014 18:46:48 -0000 On Mon, 8 Sep 2014 15:53, phill@hallambaker.com said: > to use the Google CA. One of the weaknesses of the PGP model was that > the design ignored the fact that in many circumstances we are in > hierarchical organization structures that the CA model matches very Which was fixed 16 years ago with OpenPGP (RFC-2440). OpenPGP actually provide a superset of the features you require to implement the X.509 model. It does not demand its use as it also does not demand the use of the WoT or any other key validation model - this is all left to the implementation. Both major implementations support the hierarchical model. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Mon Sep 8 14:14:01 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 ECD261A02FF for ; Mon, 8 Sep 2014 14:13:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.03 X-Spam-Level: X-Spam-Status: No, score=-3.03 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, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.652, 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 fWFfCdumjkFY for ; Mon, 8 Sep 2014 14:13:58 -0700 (PDT) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DC651A02A6 for ; Mon, 8 Sep 2014 14:13:58 -0700 (PDT) Received: by mail-ig0-f175.google.com with SMTP id uq10so3507636igb.14 for ; Mon, 08 Sep 2014 14:13:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=eUkSG3y6e5kfDDeaqotlv88EMHPjF/z1eVoCBBx9xpA=; b=pzhTYULnoGDM22Q7+qf8OCUXGJsx2TF0ZjBc8LwOFSlX7XO8RERz61AqnEyNY0Lhqx MDKgbqqVaFV9RPj/1zsV4BM8HzUZfRADP8a4uZanzP6ZwesDCqalp3f32Z+ejPWEN67Z 1nfR8XZu7wiKZjgEsnKiYZJwl3ofrs/cm7NFGW7lF4q3hOMcGJsiC3lm0rnT5WrHbtMj yCE1n7Nb9kuL4z1VGdfN7nfRuuPcJtc9ZsvAF+Mh6Bsngh4usrD30hkALeA3iZQ7Xijs JqJzkc/E2Bn+n5dvhfr06eV5yTzCiHQWRMhx8aup9uixKzdj2Vporft5XSaMQoSZJoBn mVvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=eUkSG3y6e5kfDDeaqotlv88EMHPjF/z1eVoCBBx9xpA=; b=ShtEiShNfV6DfzOIFzdnQ0oJaTKoLmSVtZfa0wpN6rFnkkFcwmIRmY/LkiGr0WlNdX a/6ysWE9hrXIeWSfhV7lcp18Mign1BEh/OYmSZ7RWGU7g3p36ArX+ie80NqiojBoKy3Q VJsDb/Qa4pKoUTyfzeBcVG4b0pfOC/HcroZBaLrrRF9Rt5gO7Fis7mgQvZm2Wj0ivNMI jKJMmFa5GdDBgQWKJsKE//w7xB8JlWY+niDECB1m48/fdkdb3r1fIPerCCmLlnNC5MBV h2G86CK6s+Nk7JNgoijpfuVkJklTqWyYS3WDQ2mJYlZlUnYxgms/CstgAX7pM2CuHzBC GoSQ== X-Gm-Message-State: ALoCoQlFf/ieoufHvZ/15bqbAPQT9vkmv/yc+0EJm8KbdR9eqdIGouAz7lIFUGTlKluSs5HYyniO MIME-Version: 1.0 X-Received: by 10.50.72.43 with SMTP id a11mr26555917igv.23.1410210836877; Mon, 08 Sep 2014 14:13:56 -0700 (PDT) Received: by 10.64.62.78 with HTTP; Mon, 8 Sep 2014 14:13:56 -0700 (PDT) In-Reply-To: References: <540AABF8.8000605@cisco.com> <540C5BE1.6010405@qti.qualcomm.com> <540C7399.3060901@cisco.com> Date: Mon, 8 Sep 2014 14:13:56 -0700 Message-ID: From: Brandon Long To: Phillip Hallam-Baker Content-Type: multipart/alternative; boundary=047d7bdc15e0fe09a10502944b7f Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/vnQ8-aDs1tSdY7qARNrgys-3GyU Cc: Pete Resnick , endymail , Eliot Lear Subject: Re: [Endymail] spam versus cleartext 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, 08 Sep 2014 21:14:00 -0000 --047d7bdc15e0fe09a10502944b7f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sun, Sep 7, 2014 at 11:10 AM, Phillip Hallam-Baker wrote: > On Sun, Sep 7, 2014 at 11:02 AM, Eliot Lear wrote: > > Let's talk constraints for a moment. Does the problem get easier if we > > say, =E2=80=9Clet's not even attempt to address transactional email=E2= =80=9D, and focus > > exclusively on h2h? Also, is it a goal to completely do away with > > spam? Is that a non-goal? > > Transactional mail is the easiest to do and has the biggest payoff. So > no, not doing it does not help in the slightest. > > I don't think we are going to be using this scheme to complete > transactions. But it has to be possible to use it for applications > such as: > > * Correspondence between lawyers and clients. > * Sending statements for bank and brokerage accounts. > * Sending invoices. > In particular, it would be great if we could "solve" the problem such that entities are willing to send things via email that they currently won't. For example, my bank won't send me a copy of my monthly statement to my email address, only a notification to look at it on their site. This "hole" seems to be the largest in the email as the solution to paperless postal mail. Brandon --047d7bdc15e0fe09a10502944b7f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Sep 7, 2014 at 11:10 AM, Phillip Hallam-Baker <phill@halla= mbaker.com> wrote:
On Sun, Sep 7, 2014 at 11:02 AM, Eliot Lear= <lear@cisco.com> wrote:
> Let's talk constraints for a moment.=C2=A0 Does the problem get ea= sier if we
> say, =E2=80=9Clet's not even attempt to address transactional emai= l=E2=80=9D, and focus
> exclusively on h2h?=C2=A0 Also, is it a goal to completely do away wit= h
> spam?=C2=A0 Is that a non-goal?

Transactional mail is the easiest to do and has the biggest pay= off. So
no, not doing it does not help in the slightest.

I don't think we are going to be using this scheme to complete
transactions. But it has to be possible to use it for applications
such as:

* Correspondence between lawyers and clients.
* Sending statements for bank and brokerage accounts.
* Sending invoices.

In particular, it w= ould be great if we could "solve" the problem such that entities = are willing to send things via email that they currently won't. =C2=A0F= or example, my bank won't send me a copy of my monthly statement to my = email address, only a notification to look at it on their site. =C2=A0This = "hole" seems to be the largest in the email as the solution to pa= perless postal mail.

Brandon=C2=A0
--047d7bdc15e0fe09a10502944b7f-- From nobody Mon Sep 8 14:35:08 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 709021A032F for ; Mon, 8 Sep 2014 14:35:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3fyv3nwwBTE8 for ; Mon, 8 Sep 2014 14:35:04 -0700 (PDT) Received: from mail-qg0-x235.google.com (mail-qg0-x235.google.com [IPv6:2607:f8b0:400d:c04::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B39B1A03C0 for ; Mon, 8 Sep 2014 14:35:03 -0700 (PDT) Received: by mail-qg0-f53.google.com with SMTP id z107so15997578qgd.40 for ; Mon, 08 Sep 2014 14:35:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=toPQ/T1dt0TLe4y7g6TYpUfSoqgLcqPS7DHW9gzfDj0=; b=IZ6bccLy0nMP9eW5XPD8izDtCFw1BoAmYUGHzvPoP7fLFWXaUXynX4DlvZpiXVhhW+ QzDdoOTYG8D45N6DkDOJYvw+1/vPN3r2UP2+5friA8/JeCT5b4234Bg2lAZVLA6/TRGN sXEV4jjPJqQ1zO7fkPoTEbuspd1QuXvoiNQGTsgNsunJ8AmYN4eNXFoVyLUS3NmyZL4N IHm820haeH5pOILHDSwq+YoG81cdubgvmhQXC8FiSsWdUci9AhKYiqcN4DDSeRDyhl4N F2t2VbqpYN3TF0e9c577qWeb/1nisDmU8tP7iBKcxmT6OX/e/Ozm0C2pR+wWZr24PXwr hTwQ== X-Received: by 10.224.15.201 with SMTP id l9mr45671560qaa.27.1410212102304; Mon, 08 Sep 2014 14:35:02 -0700 (PDT) Received: from [33.140.142.57] ([172.56.22.212]) by mx.google.com with ESMTPSA id r7sm1347329qai.15.2014.09.08.14.34.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 08 Sep 2014 14:34:59 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-9EC2142D-ABE8-4B34-B787-0A3C96ABB707 Mime-Version: 1.0 (1.0) From: Phillip Hallam-Baker X-Mailer: iPad Mail (11B651) In-Reply-To: Date: Mon, 8 Sep 2014 17:34:59 -0400 Content-Transfer-Encoding: 7bit Message-Id: <2F64C55C-C3D3-4DA3-8037-1D2A9077922A@gmail.com> References: <540AABF8.8000605@cisco.com> <540C5BE1.6010405@qti.qualcomm.com> <540C7399.3060901@cisco.com> To: Brandon Long Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/0cdsJjJHMx-cdr8c12j9n-BCdn8 Cc: Pete Resnick , Phillip Hallam-Baker , endymail , Eliot Lear Subject: Re: [Endymail] spam versus cleartext 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, 08 Sep 2014 21:35:06 -0000 --Apple-Mail-9EC2142D-ABE8-4B34-B787-0A3C96ABB707 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable TLS has enabled e-commerce which is generally held responsible for adding an= extra trillion dollars a year to global GDP. Email security is not going to be so dramatic but it allows a lot of the hol= es in the e-commerce interface to be filled in. And that could be worth a fe= w percent extra growth of e-commerce. Lets say it is 1 percent, or rather, lets say that we can make people think i= t is 1 percent. That is ten billion dollars a year. 1% of that is a hundred million and we can buy a lot of servers and other in= frastructure with that. If we get the security in the specs we can easily make transactions machine r= eadable. Sent from my iPad > On Sep 8, 2014, at 5:13 PM, Brandon Long wrote: >=20 >=20 >=20 >> On Sun, Sep 7, 2014 at 11:10 AM, Phillip Hallam-Baker wrote: >> On Sun, Sep 7, 2014 at 11:02 AM, Eliot Lear wrote: >> > Let's talk constraints for a moment. Does the problem get easier if we= >> > say, =E2=80=9Clet's not even attempt to address transactional email=E2=80= =9D, and focus >> > exclusively on h2h? Also, is it a goal to completely do away with >> > spam? Is that a non-goal? >>=20 >> Transactional mail is the easiest to do and has the biggest payoff. So >> no, not doing it does not help in the slightest. >>=20 >> I don't think we are going to be using this scheme to complete >> transactions. But it has to be possible to use it for applications >> such as: >>=20 >> * Correspondence between lawyers and clients. >> * Sending statements for bank and brokerage accounts. >> * Sending invoices. >=20 > In particular, it would be great if we could "solve" the problem such that= entities are willing to send things via email that they currently won't. Fo= r example, my bank won't send me a copy of my monthly statement to my email a= ddress, only a notification to look at it on their site. This "hole" seems t= o be the largest in the email as the solution to paperless postal mail. >=20 > Brandon=20 --Apple-Mail-9EC2142D-ABE8-4B34-B787-0A3C96ABB707 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
TLS has enabled e-commerce which is ge= nerally held responsible for adding an extra trillion dollars a year to glob= al GDP.

Email security is not going to be so dramat= ic but it allows a lot of the holes in the e-commerce interface to be filled= in. And that could be worth a few percent extra growth of e-commerce.
=

Lets say it is 1 percent, or rather, lets say that we ca= n make people think it is 1 percent. That is ten billion dollars a year.

1% of that is a hundred million and we can buy a lot o= f servers and other infrastructure with that.


<= /div>
If we get the security in the specs we can easily make transaction= s machine readable.


Sent from my iPad

On Sep 8, 2014, at 5:13 PM, Brandon Long <blong@google.com> wrote:



On Sun, Sep 7, 2014 at 11:10 AM, Phillip Hallam-Baker <phil= l@hallambaker.com> wrote:
On Sun, Sep 7, 2014 at 11:02 AM, Eliot L= ear <lear@cisco.com> wrote:
> Let's talk constraints for a moment.  Does the problem get easier i= f we
> say, =E2=80=9Clet's not even attempt to address transactional email=E2=80= =9D, and focus
> exclusively on h2h?  Also, is it a goal to completely do away with=
> spam?  Is that a non-goal?

Transactional mail is the easiest to do and has the biggest payo= ff. So
no, not doing it does not help in the slightest.

I don't think we are going to be using this scheme to complete
transactions. But it has to be possible to use it for applications
such as:

* Correspondence between lawyers and clients.
* Sending statements for bank and brokerage accounts.
* Sending invoices.

In particular, it wo= uld be great if we could "solve" the problem such that entities are willing t= o send things via email that they currently won't.  For example, my ban= k won't send me a copy of my monthly statement to my email address, only a n= otification to look at it on their site.  This "hole" seems to be the l= argest in the email as the solution to paperless postal mail.

=
Brandon 
= --Apple-Mail-9EC2142D-ABE8-4B34-B787-0A3C96ABB707-- From nobody Mon Sep 8 14:40:36 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 684CF1A03CA for ; Mon, 8 Sep 2014 14:40:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nnGQlOs-otvC for ; Mon, 8 Sep 2014 14:40:33 -0700 (PDT) Received: from mail-qc0-x230.google.com (mail-qc0-x230.google.com [IPv6:2607:f8b0:400d:c01::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78DA81A03BE for ; Mon, 8 Sep 2014 14:40:33 -0700 (PDT) Received: by mail-qc0-f176.google.com with SMTP id x3so3261173qcv.35 for ; Mon, 08 Sep 2014 14:40:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ihA/DcT76PKg2CCqDUFtPg52OyKycKQWRGTvvfeGbzs=; b=Dv/WRdIzyg90DaZ1HZ3GThea81Wxagh6Q+P6cWvanF75f4HcCROV/wUeIgzbZy4z2r h2Lyx2ZXHBewOB+4BQtTg2TUt/LBGr7NBNZ07jfRmbOwdkvXspxp/ULKyfCQncelpFIt wlcyHPv0r+iTNQjfxYAHbfAUaRDsydI+JuzrnEwN23P1tfSjSuDg036lnpxFKcLjXb24 WG1CjI5idMzRceHdmPYAeLaM0RQ1oAq1LdGprA6/A+o7r96sRTLY1e96/vYdRtLORCqD coe1hLaqEwN6DSESD+SeqfRh12iOHbdlTemuCfdwkXqsh7o6GVCKMWSsVh/Yopfj52Mj W1tg== X-Received: by 10.229.33.202 with SMTP id i10mr45534940qcd.2.1410212432724; Mon, 08 Sep 2014 14:40:32 -0700 (PDT) Received: from [33.140.142.57] ([172.56.22.212]) by mx.google.com with ESMTPSA id v90sm8260461qge.31.2014.09.08.14.40.30 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 08 Sep 2014 14:40:30 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Phillip Hallam-Baker X-Mailer: iPad Mail (11B651) In-Reply-To: <87egvm7y4o.fsf@vigenere.g10code.de> Date: Mon, 8 Sep 2014 17:40:30 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4955A873-0457-4089-A289-5F5240CA44A2@gmail.com> References: <540AABF8.8000605@cisco.com> <540C5BE1.6010405@qti.qualcomm.com> <540CCA3E.8020505@qti.qualcomm.com> <20140908030941.GT26920@mournblade.imrryr.org> <87egvm7y4o.fsf@vigenere.g10code.de> To: Werner Koch Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/x9EEwIhtYMY_IczsugWWDKNp2as Cc: Phillip Hallam-Baker , endymail Subject: Re: [Endymail] spam versus cleartext 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, 08 Sep 2014 21:40:35 -0000 yes and no. yes you can do that sort of thing with PGP, but being able to to it and havi= ng one way to do it that everyone follows are very different things. It is entirely possible to configure pgp to give online/offline key separati= on as well. But the amount of effort required is non-trivial and the value i= s negligible if there is no code that would make use of it. Support for the model requires all the issue infrastructure support for the h= ierechical issuers. Sent from my iPad > On Sep 8, 2014, at 2:41 PM, Werner Koch wrote: >=20 > On Mon, 8 Sep 2014 15:53, phill@hallambaker.com said: >=20 >> to use the Google CA. One of the weaknesses of the PGP model was that >> the design ignored the fact that in many circumstances we are in >> hierarchical organization structures that the CA model matches very >=20 > Which was fixed 16 years ago with OpenPGP (RFC-2440). OpenPGP actually > provide a superset of the features you require to implement the X.509 > model. It does not demand its use as it also does not demand the use of > the WoT or any other key validation model - this is all left to the > implementation. Both major implementations support the hierarchicalthere > model. >=20 >=20 > Shalom-Salam, >=20 > Werner >=20 > --=20 > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. >=20 From nobody Tue Sep 9 08:56:02 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 2BE2E1A6FF3 for ; Tue, 9 Sep 2014 08:55:53 -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 9p-5LtsWFf64 for ; Tue, 9 Sep 2014 08:55:49 -0700 (PDT) Received: from mail-we0-f179.google.com (mail-we0-f179.google.com [74.125.82.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4469E1A6FF6 for ; Tue, 9 Sep 2014 08:55:46 -0700 (PDT) Received: by mail-we0-f179.google.com with SMTP id u56so3188641wes.24 for ; Tue, 09 Sep 2014 08:55:45 -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=PiDkobs4fk88L3hjE3Kf2RuUvqYLjIY07WDMLnoy+l4=; b=AFy/sWVz9SoRd57sDnORzgkA7DbKhs6+QgOlx7YCJvU+NcedN0hgpdLr9kOYDtXxJr 76eLS+M7e5JCDkjjXWZ7C8VLxPha9an/FsAEtD4VYO/tY4P6IPiIvoGE1SwVT5oa5bWn 6P7rL92RVMvtCOUevkc2JgBlbgDRSQ/XOhyzOaRD7v3DQxMtg8Rm4cyOWF4Niri3gqEY u4ZGg7MYMi4mbLDZZqGMIN/YA/ZIeTBAHD7v41ZFztxuHSM1bmQ+RTocl2Id0ftFHtMy WDkIL0owKvlM5XTm8V+faSpAK6yjiKiRYENyAnIeB3FdSXWU5ujbS6yFbvIwzSfeFZaz mioQ== X-Gm-Message-State: ALoCoQlaNvgkyWFUpiX2RZTBzFseH+Y5LtIJ+wbPvJCxlrjJ9LDi71+YE8XngWHIogNpAh+B+l0T X-Received: by 10.194.6.195 with SMTP id d3mr5798408wja.107.1410278145549; Tue, 09 Sep 2014 08:55:45 -0700 (PDT) Received: from vegoda.org (vps.ldn.vegoda.org. [2001:67c:1b8:100f::2]) by mx.google.com with ESMTPSA id dc9sm16056771wib.5.2014.09.09.08.55.44 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Tue, 09 Sep 2014 08:55:44 -0700 (PDT) Date: Tue, 9 Sep 2014 16:55:41 +0100 From: Leo Vegoda To: Phillip Hallam-Baker Message-ID: <20140909155541.GF19979@vegoda.org> References: <540AABF8.8000605@cisco.com> <540C5BE1.6010405@qti.qualcomm.com> <540CCA3E.8020505@qti.qualcomm.com> <20140908030941.GT26920@mournblade.imrryr.org> 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/0Hpu8EP2Xg15H75807FlgCUyyd0 Cc: endymail Subject: Re: [Endymail] spam versus cleartext 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, 09 Sep 2014 15:55:53 -0000 On Mon, Sep 08, 2014 at 09:53:34AM -0400, Phillip Hallam-Baker wrote: [...] > But the certificate issued is only > authenticating alice@gmail.com, it isn't authenticating Alice. That's quite a subtle distinction. Experience shows that most people do not understand the difference between a web browser and a search engine[1]. How likely do you think it is that people will understand the difference between the authentication of an e-mail address and the person controlling that address? Leo [1] https://www.youtube.com/watch?v=o4MwTvtyrUQ From nobody Tue Sep 9 09:11:26 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 32F9B1A7001 for ; Tue, 9 Sep 2014 09:11:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.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 AZ4AJez-UPpJ for ; Tue, 9 Sep 2014 09:11:18 -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 E14701A7004 for ; Tue, 9 Sep 2014 09:10:40 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id BD48C2AACFF; Tue, 9 Sep 2014 16:10:38 +0000 (UTC) Date: Tue, 9 Sep 2014 16:10:38 +0000 From: Viktor Dukhovni To: endymail@ietf.org Message-ID: <20140909161038.GW26920@mournblade.imrryr.org> References: <540AABF8.8000605@cisco.com> <540C5BE1.6010405@qti.qualcomm.com> <540CCA3E.8020505@qti.qualcomm.com> <20140908030941.GT26920@mournblade.imrryr.org> <20140909155541.GF19979@vegoda.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140909155541.GF19979@vegoda.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/Rtr1ATMJr2BezUtIcBwezzi7Lhg Subject: Re: [Endymail] spam versus cleartext 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: Tue, 09 Sep 2014 16:11:20 -0000 On Tue, Sep 09, 2014 at 04:55:41PM +0100, Leo Vegoda wrote: > > But the certificate issued is only > > authenticating alice@gmail.com, it isn't authenticating Alice. > > That's quite a subtle distinction. Experience shows that most people > do not understand the difference between a web browser and a search > engine[1]. How likely do you think it is that people will understand > the difference between the authentication of an e-mail address and > the person controlling that address? And if I want to send an email with sensitive business materials to Alice's work email address, I don't expect to securely deliver it to "Alice", rather it is intended for Alice's "at work" mailbox. Which is not to say that it might not be interesting to have some types of keys that are bounnd to a particular person, and allow that person to establish related identities hosted by various email providers. But even then Alice might prefer certain types of messages to be delivered to some addresses and not to others (Alice's fetish emails should perhaps not be sent to the office). So the picture is rather complex, ... Neither a pure "person" identity nor a pure "role" identity is right for all cases. -- Viktor. From nobody Tue Sep 9 09:25:02 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 96D4C1A6FF0 for ; Tue, 9 Sep 2014 09:24:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H4AX8HnzdkAL for ; Tue, 9 Sep 2014 09:24:49 -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 968E01A6FE1 for ; Tue, 9 Sep 2014 09:24:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id C4ACF87F22C for ; Tue, 9 Sep 2014 12:18:54 -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 WV8F9xou1KmU for ; Tue, 9 Sep 2014 12:18:52 -0400 (EDT) Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id 1781287F221 for ; Tue, 9 Sep 2014 12:18:51 -0400 (EDT) Date: Tue, 09 Sep 2014 12:24:42 -0400 From: Cyrus Daboo To: endymail@ietf.org Message-ID: In-Reply-To: <20140909161038.GW26920@mournblade.imrryr.org> References: <540AABF8.8000605@cisco.com> <540C5BE1.6010405@qti.qualcomm.com> <540CCA3E.8020505@qti.qualcomm.com> <20140908030941.GT26920@mournblade.imrryr.org> <20140909155541.GF19979@vegoda.org> <20140909161038.GW26920@mournblade.imrryr.org> 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=558 Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/27Om3JTDS2Ocs4W7EJIz-Ieyoi4 Subject: Re: [Endymail] spam versus cleartext 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, 09 Sep 2014 16:24:52 -0000 Hi Viktor, --On September 9, 2014 at 4:10:38 PM +0000 Viktor Dukhovni wrote: > So the picture is rather complex, ... Neither a pure "person" > identity nor a pure "role" identity is right for all cases. Yes, endymail has to cope with typical "corporate" work practices. In particular, when Alice goes on vacation, her boss, co-worker, assistant etc should be able to read her email. The legal department probably needs access to everyone's email. Do we want endymail to be compatible with such requirements? -- Cyrus Daboo From nobody Tue Sep 9 09:36:18 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 899251A8033 for ; Tue, 9 Sep 2014 09:36:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LCOjxpe9NVDL for ; Tue, 9 Sep 2014 09:36:15 -0700 (PDT) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C7BD1A7008 for ; Tue, 9 Sep 2014 09:36:14 -0700 (PDT) Received: by mail-la0-f42.google.com with SMTP id hz20so4818415lab.1 for ; Tue, 09 Sep 2014 09:36:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:in-reply-to:mime-version:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=FOkuExZZ+sb1MWsFEsWZDJjPTaKJWDGRPdRKWUUafQY=; b=cEIQFXfngKkDa/QDoviC4bbJeHRLuBCKDCjrcCy/muDK7gBRU6M/YiAQAh8FIlw+9H RepA3e98LhTIpuMeBTh/8to7gQUpFu3JxxQyp33QULzfdsYX1WYGwgbZldI6bVcBZYnx h1ez0+dL/zcQG2oyS3nwz639VcdylpGoRsaWoaCTthhnOMpcGgcnJszpwAVnCnzInbEK aBJPY8kRFw2xFzwiwX06n+LWN9k9GrIFKlywhRTzdwZ2NYz5SLvOCLrtGoV0GkEjQwTh tPYYQ5Mb+BfaF09Gor1UCuc+lkgD/LZ8e734M4Ggjz1MQoGnHE1i4NV66ySAl5bU2WIm /HJg== X-Received: by 10.153.11.132 with SMTP id ei4mr29171084lad.24.1410280572727; Tue, 09 Sep 2014 09:36:12 -0700 (PDT) References: <540AABF8.8000605@cisco.com> <540C5BE1.6010405@qti.qualcomm.com> <540CCA3E.8020505@qti.qualcomm.com> <20140908030941.GT26920@mournblade.imrryr.org> <20140909155541.GF19979@vegoda.org> <20140909161038.GW26920@mournblade.imrryr.org> In-Reply-To: Mime-Version: 1.0 (1.0) From: Phillip Hallam-Baker Date: Tue, 9 Sep 2014 12:36:11 -0400 Message-ID: <-3927362445992988491@unknownmsgid> To: Cyrus Daboo Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/TNCdHpphIz1TTgDpPKeQGGYMABw Cc: "endymail@ietf.org" Subject: Re: [Endymail] spam versus cleartext 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, 09 Sep 2014 16:36:16 -0000 Yes Endymail has to be compatible. But mail with a hole in it won't be Endymail= . The important thing is users can tell the difference iff it matters Smime with a gap is still far better than what we have now. It just can't be the only option Sent from my difference engine > On Sep 9, 2014, at 12:25 PM, Cyrus Daboo wrote: > > Hi Viktor, > > --On September 9, 2014 at 4:10:38 PM +0000 Viktor Dukhovni wrote: > >> So the picture is rather complex, ... Neither a pure "person" >> identity nor a pure "role" identity is right for all cases. > > Yes, endymail has to cope with typical "corporate" work practices. In par= ticular, when Alice goes on vacation, her boss, co-worker, assistant etc sh= ould be able to read her email. The legal department probably needs access = to everyone's email. Do we want endymail to be compatible with such require= ments? > > -- > Cyrus Daboo > > _______________________________________________ > Endymail mailing list > Endymail@ietf.org > https://www.ietf.org/mailman/listinfo/endymail From nobody Tue Sep 9 10:37:04 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 1DC051A802B for ; Tue, 9 Sep 2014 10:36:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pAx-KcWS2Vei for ; Tue, 9 Sep 2014 10:36:54 -0700 (PDT) Received: from mail-qa0-x22d.google.com (mail-qa0-x22d.google.com [IPv6:2607:f8b0:400d:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 939611A700B for ; Tue, 9 Sep 2014 10:36:54 -0700 (PDT) Received: by mail-qa0-f45.google.com with SMTP id s7so727939qap.32 for ; Tue, 09 Sep 2014 10:36:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=I2LsXWq0A/U9WJOsd03MGAAP3QHzHok1In4iPM0swNc=; b=i9md/ynRZJl6NruqsXlwpSgbwfmK8y10k8p7Cf6hGVJ1yc3ZQn8jT6h5bEkRYuBr3q lJTlkco/I3h9kAwERHbNzIBdRIzU1suNL1/+fgctf/CQIi/ftIC8O/9MfzJKqvXyV8hb Rolaixb5HjetIT/xl+XaEnkcJ1z0UWqLvFDcAcLahuhBEdbSZ08o7RNN4WEp30dsfY6H EGb3V2/2wV9/xOShCCmcRKxPnTmptXgNucyWXD328EReUfuxggOYs3Aprwro/C8UcIiI 7ibU+zfxuGs87ZJvSxqiMwa2RXD2ygb4E0brb9LuFD/Dt7vm6RTfzzb+DggbIKbEHmiQ 5a3A== X-Received: by 10.224.46.67 with SMTP id i3mr20422568qaf.90.1410284213631; Tue, 09 Sep 2014 10:36:53 -0700 (PDT) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net. [76.218.8.156]) by mx.google.com with ESMTPSA id k52sm10310638qge.42.2014.09.09.10.36.52 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Sep 2014 10:36:52 -0700 (PDT) Message-ID: <540F39F2.1040801@gmail.com> Date: Tue, 09 Sep 2014 10:33:38 -0700 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: John Levine , endymail@ietf.org References: <20140907170207.14888.qmail@joyce.lan> In-Reply-To: <20140907170207.14888.qmail@joyce.lan> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/tmG_MozXT6zb6Kb5KUWENjnGEuE Cc: watsonbladd@gmail.com Subject: Re: [Endymail] spam versus cleartext 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, 09 Sep 2014 17:36:56 -0000 On 9/7/2014 10:02 AM, John Levine wrote: > I don't know of anyone who does message > rejection based on DKIM signatures Google and Yahoo say that they use DKIM signatures as part of reputation assessment. That's distinct from any use of DMARC. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Sep 9 10:53: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 923FD1A0008 for ; Tue, 9 Sep 2014 10:53:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, 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 Qh9C7-odfhRB for ; Tue, 9 Sep 2014 10:53:19 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D23B01A0007 for ; Tue, 9 Sep 2014 10:53:18 -0700 (PDT) Received: (qmail 75753 invoked from network); 9 Sep 2014 17:53:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=127e8.540f3e8d.k1409; bh=qqS4B23yGXdyvmwXn3VvyAql0j1u2zLGR2kODqM5K14=; b=XNqRGtrOoizxx3b1LwVWBKs84ZLw5t9bzNqFl+i0btia4Vb7KBI+VTCXhU25w4gMaIb99Esf6pWKldP9I+hv38FutyH72H/V7/iIiz752LWCoz0SdHbgj+e9NYGZgjiyHFXarVPA/gsdUu/efywQo2UwnCeJ2G6jlXDcc/QSUDBNnMeN35az0tosboZTVgk1hsSqjLRTK90n7S1GsPAVvGFhWXfejYxU9Q2Dn7Vbg/tuFPF2HKAO6V9EF1R6mAJs DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=127e8.540f3e8d.k1409; bh=qqS4B23yGXdyvmwXn3VvyAql0j1u2zLGR2kODqM5K14=; b=3N/DtDrc3A+ybh0K0/PA1elhI6vE+qdQ01UfXk8hFxHzC04B71yJctowGYrm9NydB48xNLaEaa0VMms8aKtNCy4x/IleWZCmMTykMdR08gidBjmN5GCZdVgmq8fzz+RE+TPUIHQxxGhMBVNGvEplq8S23NYdMZi7yU6lYOGIrug4u1+NrH+dWPL1K9L54s2TGNU/vkKKy0g0TldVNFpsEPOafcodkSJb6+xevXZzdGL7Bv3OR9NtFEmj//aXQIzU Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 09 Sep 2014 17:53:17 -0000 Date: 9 Sep 2014 13:53:17 -0400 Message-ID: From: "John R Levine" To: "Dave Crocker" In-Reply-To: <540F39F2.1040801@gmail.com> References: <20140907170207.14888.qmail@joyce.lan> <540F39F2.1040801@gmail.com> User-Agent: Alpine 2.11 (BSF 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/1HNOlWSJPm4gsWhgfQgR6aSHz7U Cc: endymail@ietf.org Subject: Re: [Endymail] spam versus cleartext 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, 09 Sep 2014 17:53:20 -0000 > On 9/7/2014 10:02 AM, John Levine wrote: >> I don't know of anyone who does message >> rejection based on DKIM signatures > > Google and Yahoo say that they use DKIM signatures as part of reputation > assessment. That's distinct from any use of DMARC. Oh, sure, but now that's just part of content based analysis: look at the message text, add special sauce, and decide whether to deliver to the inbox or the spam folder. I suppose we can put DKIM in the very small category of content analysis that could still be useful with encrypted mail bodies, along with some checks for header defects typical of spambots. R's, John From nobody Tue Sep 9 11:04:26 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 7B2761A0020 for ; Tue, 9 Sep 2014 11:04:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MvrWIa6ALJjO for ; Tue, 9 Sep 2014 11:04:24 -0700 (PDT) Received: from mail-qg0-x236.google.com (mail-qg0-x236.google.com [IPv6:2607:f8b0:400d: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 1D51D1A0026 for ; Tue, 9 Sep 2014 11:04:23 -0700 (PDT) Received: by mail-qg0-f54.google.com with SMTP id z60so2452379qgd.27 for ; Tue, 09 Sep 2014 11:04:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=lVZLvU6mWvFWsbFnXAzsojIvjDY4O7cgIAaKtFqv+34=; b=HPZdYwrPjhjj+pHvBkjbw/uI7Yx5hUOwvfpVdB/2PlHPmNWrXldHAMxVMYGouZxnGz 40JBd6NIFb2Z0+2N2qt18wUDpx3D/2qZPnopao2gsjjfKXPLA+Iy0N5uYhoh3SJg/fwn 4BGm3LurqOxWTZ8L7cxI+LPG7200X7maBqQO72y+OwisrD2Cb1AhX2zV4afkkFB3tOyA Jd6qsOOTulPOHOa2v/sLsuxtlveAoLo/Kxlyyk2/kpPhmkhZpYISL/wzw20lh+P3jtt7 5aSe0pzk52u1f0obUhGFWi+PeeJnvkQGxiPxHaaTQlo6B9RLmZ1cTWCNqr6F7lIPSToH f0+Q== X-Received: by 10.229.38.3 with SMTP id z3mr53149858qcd.17.1410285862898; Tue, 09 Sep 2014 11:04:22 -0700 (PDT) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net. [76.218.8.156]) by mx.google.com with ESMTPSA id g5sm10849366qaz.39.2014.09.09.11.04.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Sep 2014 11:04:21 -0700 (PDT) Message-ID: <540F4063.5080304@gmail.com> Date: Tue, 09 Sep 2014 11:01:07 -0700 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: John R Levine References: <20140907170207.14888.qmail@joyce.lan> <540F39F2.1040801@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/A0-bI7EBXffUzWBIGRMiFuev38A Cc: endymail@ietf.org Subject: Re: [Endymail] spam versus cleartext 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, 09 Sep 2014 18:04:25 -0000 On 9/9/2014 10:53 AM, John R Levine wrote: >> On 9/7/2014 10:02 AM, John Levine wrote: >>> I don't know of anyone who does message >>> rejection based on DKIM signatures >> >> Google and Yahoo say that they use DKIM signatures as part of reputation >> assessment. That's distinct from any use of DMARC. > > Oh, sure, but now that's just part of content based analysis: You made a simple, flat assertion. Since the context of all email filtering these days is within an elaborate engine, a purely isolated, literal and simplistic interpretation of your statement wouldn't make much sense. I queried about the claim and got back counter data. > I suppose we can put DKIM in the very small category of content analysis Reputation assessment is a complex game, involving many factors. But that's not the question at hand. The question here is whether such assessments are made against DKIM-validated names. The answer is yes. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Sep 9 11:19: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 CA8021A8850 for ; Tue, 9 Sep 2014 11:19:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, 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 Mq7-MEXRCUTo for ; Tue, 9 Sep 2014 11:19:25 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40E1C1A884C for ; Tue, 9 Sep 2014 11:19:24 -0700 (PDT) Received: (qmail 79263 invoked from network); 9 Sep 2014 18:19:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=1359e.540f44ab.k1409; bh=9CTQ+R8ahpkkGeqYFciZ3kh298Tp9IBKeW4i84w/mv0=; b=dbor7h3TWojodIYTFlmW9x97whDM4LjidJpKqI44R8MjGJDsDwX1TJPWpp7CYN51cr8M+u/sA5WZVLL6cXaGGr9WnHFzE4RhARgUDb5WCJYo1pI0ab4i6zZ1+4orAy4YxEWuSzmA9dyXa2OdmEVM4Gpc/QR+K7PMMdylOK1Ag6e6vW9yI0MKUvj55M6vmsHoKOpjxVVBeX3kIXC6INedeUdkMebnvtpBfqyzMn6YiqIyNfMZM6EHyPcGphtoMsLq DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=1359e.540f44ab.k1409; bh=9CTQ+R8ahpkkGeqYFciZ3kh298Tp9IBKeW4i84w/mv0=; b=sW1IhFVuEn3CcH1f5iYC/+NJbiqq6/f96ngmzAI3xSx240/dyWZdja7V0ziGtpY3P/NP0iHSzAH8d7tVLAsHyrFlVKf2TjDZZaUvAATO2XoNgy/ZjVVuF5CnRNxIcUweDDb7lkeSuX1Rub7QScRQQiEqLwcNWE33zLF0UKwAGjjHQ2hRkOyaCi77aC87VGJ8/J5r3plIpK7zDhVVczbW0CGvU4itiPDQeCVM40TzG5y0yFlU4g0mDSDj9HVAl1La Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 09 Sep 2014 18:19:23 -0000 Date: 9 Sep 2014 14:19:22 -0400 Message-ID: From: "John R Levine" To: "Dave Crocker" In-Reply-To: <540F4063.5080304@gmail.com> References: <20140907170207.14888.qmail@joyce.lan> <540F39F2.1040801@gmail.com> <540F4063.5080304@gmail.com> User-Agent: Alpine 2.11 (BSF 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/cbah-GrijmeO7O3WG9yo2qwd1yY Cc: endymail@ietf.org Subject: Re: [Endymail] spam versus cleartext 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, 09 Sep 2014 18:19:25 -0000 > You made a simple, flat assertion. Yup, about SMTP time rejection based just on DKIM failure. Other than DMARC, I don't know anyone who does that. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Tue Sep 9 11:22:41 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 160211A885F for ; Tue, 9 Sep 2014 11:22:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2aOlrs7kh9lH for ; Tue, 9 Sep 2014 11:22:36 -0700 (PDT) Received: from mail-qg0-x22a.google.com (mail-qg0-x22a.google.com [IPv6:2607:f8b0:400d:c04::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51CEE1A8873 for ; Tue, 9 Sep 2014 11:22:32 -0700 (PDT) Received: by mail-qg0-f42.google.com with SMTP id q107so7874122qgd.15 for ; Tue, 09 Sep 2014 11:22:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=Z9ESQDxLdiUig4kTjUrSv1u47C2R4HAhPMjku/x/aeo=; b=Eqpyp8cfsZgIeOuizE28yXrCHhWkt7wSeGvdYj1l7FBFVPdSb2zrQ8YfZRKLXvpz6+ tguRgdz2jcSSVoYsgpC4H1QwmWRK8r2N8go89zaRTLiuElMdxYI0bnohDMxgbLGrlZbq 3whxNCR8RNTmONl6XEW6T/V1YasyTmCyMQ08sWXfw2EKlHVtywpQl6grRnNiA8qZ3xWP ijAi3iGD7dwyXnfY4YARuhRyp7hf7Q8BnW8OT2u96yps9o9MCIqGGnE1i5vQfuPbEWdq vHC5zppAk5KrbVuPfIsYLwwrSkpyjELhHH5vTjiFjdX6G7GS5DY4mxNtPfEKFs3V7eGA 8X0g== X-Received: by 10.140.94.1 with SMTP id f1mr24556864qge.41.1410286951333; Tue, 09 Sep 2014 11:22:31 -0700 (PDT) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net. [76.218.8.156]) by mx.google.com with ESMTPSA id g52sm10423416qgg.17.2014.09.09.11.22.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Sep 2014 11:22:30 -0700 (PDT) Message-ID: <540F44A4.50206@gmail.com> Date: Tue, 09 Sep 2014 11:19:16 -0700 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: John R Levine References: <20140907170207.14888.qmail@joyce.lan> <540F39F2.1040801@gmail.com> <540F4063.5080304@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/FQnDBjBE69_5pjdkvdkWlAo8xjw Cc: endymail@ietf.org Subject: Re: [Endymail] spam versus cleartext 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, 09 Sep 2014 18:22:38 -0000 On 9/9/2014 11:19 AM, John R Levine wrote: > Yup, about SMTP time rejection based just on DKIM failure. Oh? Well, that would have been nice to include with the assertion. And no, it isn't obvious from either the context of your message or the rest of the content of that message. Given the nature of DKIM, SMTP-time use should be expected to be minimal, at best. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Fri Sep 12 10:48:31 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 302DC1A7D83 for ; Fri, 12 Sep 2014 10:48:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.03 X-Spam-Level: X-Spam-Status: No, score=-3.03 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, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.652, 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 XgBmMbzGES-e for ; Fri, 12 Sep 2014 10:48:29 -0700 (PDT) Received: from mail-qg0-x22b.google.com (mail-qg0-x22b.google.com [IPv6:2607:f8b0:400d:c04::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6B0E1A6F66 for ; Fri, 12 Sep 2014 10:48:28 -0700 (PDT) Received: by mail-qg0-f43.google.com with SMTP id a108so1098089qge.2 for ; Fri, 12 Sep 2014 10:48:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=16zqJAAZB3W/UcMUi3fDjYsRvh8bA73TNwo+rug1B44=; b=NJ/ZMv7GsAHrnK0dziZzaNInZV7ULwo5sIG8VFNfzvs04La2aOZFmlO5mIbaP+Gbbe WLlpLhCkFU0vSArfFAHw/McC7N48sdx+6t23jRHCCu1W72P4t4RFwC2hlgnYn2fSBUvD KbET2/422Ljz/inMXWsuJui6FkaX+I2GaXYu27I1m9ztW1zdn565KEbZnPHkfMFMKj9v VXS+Xr3phkXwACtVjSCQee4YOwzbHOXQcRQkRm/JQswPiHCQrb3hW7yhjrGFbDC/CoTD OkLV33KL3rqG4Cy0RWT6MPVgJ8mh3BZYMLiS1Xpz48A89P8LncIX1IdJS19LUTh0IpM4 E+OQ== 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=16zqJAAZB3W/UcMUi3fDjYsRvh8bA73TNwo+rug1B44=; b=cCAczGWCHLwoUJbMVS0TUfsgdulzL/X/f+L9BTZjxi79cRuemw+UAwORH/POHf6+eT NUbrbYPIFykpjmLmh392a2Au+2uab6a6USRydgYIF/O8VNLMg3yntQEaZ/AFom03zeMa nk2XkYD67yhB9dMoL1RjGRLLhyLAtmfnK+OkECRikp77VXACWE5fR8HmphZiUPw+RQKj 3gCNy6Z7rBYZe4TdnchQYfPNOJbpdMqNvsv1tfoYgc/AcwiNGpQWv6Br6CnvJmKGnMtp XQYYglGZ793M/drTEB9Y4CdDr0p91baq5c3WW5WHuXY1/YTpBlgaVl9onuUgC+j9PGtW 5QTw== X-Gm-Message-State: ALoCoQnyF5FzYV3YptM8o2UoJJApEctfGq7Oh0iEIzlnFdgz8KUTTvn4BYP3/srSxerUYkQJxiLr X-Received: by 10.140.104.162 with SMTP id a31mr14883446qgf.104.1410544107124; Fri, 12 Sep 2014 10:48:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.116.71 with HTTP; Fri, 12 Sep 2014 10:48:07 -0700 (PDT) From: Wei Chuang Date: Fri, 12 Sep 2014 10:48:07 -0700 Message-ID: To: endymail@ietf.org Content-Type: multipart/alternative; boundary=001a1135568472240a0502e1e4c9 Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/kZsYtpKdXrMfdYCZ9jAXzAOs3jg Subject: [Endymail] Improvements to S/MIME 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, 12 Sep 2014 17:48:30 -0000 --001a1135568472240a0502e1e4c9 Content-Type: text/plain; charset=ISO-8859-1 Hi all, I would like to propse that endymail list seems like a good place to compile future IETF work for improving S/MIME (RFC5751). I know the S/MIME WG has been concluded for awhile, and it would be uncertain as to when such work could be done, but perhaps if there is enough interest, then something could be spun up. For quiet awhile I've been wondering about two issues with S/MIME, (and if I'm mistaken I would love to hear the solution): 1) S/MIME doesn't fully protect users mail envelope metadata. For example the recipient and envelope-sender must be visible to the intermediate SMTP MTA servers or even in the clear if the transport isn't over TLS. Could work be done to allow for anonymize the sender and recipient to a domain level? 2) The sender can't really specify to the recipient a forwarding/reply security and privacy policy. For example the sender may wish that subsequent derivative mails be signed/encrypted, done so with a minimum ciphers, or perhaps even request that no forwarding be done. Should there be work to describe a recommended security policy to the recipients? thanks, -Wei --001a1135568472240a0502e1e4c9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi all,

I would like to propse that end= ymail list seems like a good place to compile future IETF work for improvin= g S/MIME (RFC5751).=A0 I know the S/MIME WG has been concluded for awhile, = and it would be uncertain as to when such work could be done, but perhaps i= f there is enough interest, then something could be spun up. =A0
=
For quiet awhile I've been wondering about two issues wi= th S/MIME, (and if I'm mistaken I would love to hear the solution):
1) S/MIME doesn't fully protect users mail envelope metadata.=A0= For example the recipient and envelope-sender must be visible to the inter= mediate SMTP MTA servers or even in the clear if the transport isn't ov= er TLS.=A0 Could work be done to allow for anonymize the sender and recipie= nt to a domain level?
2) The sender can't really specify to t= he recipient a forwarding/reply security and privacy policy.=A0 For example= the sender may wish that subsequent derivative mails be signed/encrypted, = done so with a minimum ciphers, or perhaps even request that no forwarding = be done.=A0 Should there be work to describe a recommended security policy = to the recipients?

thanks,
-Wei
--001a1135568472240a0502e1e4c9-- From nobody Fri Sep 12 11:14: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 20A321A8710 for ; Fri, 12 Sep 2014 11:14:05 -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 IRlCVuBjO5h8 for ; Fri, 12 Sep 2014 11:14:03 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A048A1A7D81 for ; Fri, 12 Sep 2014 11:12:34 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 4C3F4FA0081; Fri, 12 Sep 2014 18:12:31 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1410545550-20915-20914/12/155; Fri, 12 Sep 2014 18:12:30 +0000 From: Arnt Gulbrandsen To: endymail@ietf.org, Wei Chuang Message-Id: <3f5714b98514a5fc21cf872c798bc3445317968b88bf5ebac39505df09b11475.sha-256@android.antelope.email> References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Date: Fri, 12 Sep 2014 18:12:30 +0000 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/FJ21_j4fRf4Q_cXpwZZJ5_bVvgE Subject: [Endymail] Improvements to S/MIME 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, 12 Sep 2014 18:14:05 -0000 Just a question... I heard someone say at one IETF conference that = S/MIME is the only standard with more implementations than users. Why = has it suffered that fate? Surely not because of the two problems you = mention. Arnt From nobody Fri Sep 12 11:30: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 E6C7A1A8710 for ; Fri, 12 Sep 2014 11:30:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a09Wmf9tzQmJ for ; Fri, 12 Sep 2014 11:30:22 -0700 (PDT) Received: from mail-qa0-x22f.google.com (mail-qa0-x22f.google.com [IPv6:2607:f8b0:400d:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BA2D1A6FC4 for ; Fri, 12 Sep 2014 11:30:10 -0700 (PDT) Received: by mail-qa0-f47.google.com with SMTP id dc16so1125498qab.6 for ; Fri, 12 Sep 2014 11:30:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=gN4djHyXUDLokg7F33HafMLix9RtSB/1uiZZZy6Z9c8=; b=mTZUaNLFr7ex6Ju02pRoy428Yatzsb+p1PxQxC0rB/Cmj0a8Ryn9sD50uUyk+8uG4f 8clij7kyv0kdQH9jd+CfFGtTqMw2XMuhmenQGpJ5EqvoRt7j2RqMjDp8dNKlSQTg7u45 7i5Qv6bSGxib9StxS6arstvmu155xSOIYTN6CWEzckMqgbThLovWJl6zGJ7dxzV29sFG ecu0PEHoaTkl1SeRu6kT1CQ0XXfn4U6luQBfcWVFyLDARm2ph3OOKJBhIp0U4xWV3kRY hHe64mYHJq8K3KOY8TfIMn8PPc3ssygsfXwW/w6Gir8eoTbwoUISvkZRF3aZkeTJPpSQ sAZQ== X-Received: by 10.229.40.3 with SMTP id i3mr9091590qce.30.1410546606225; Fri, 12 Sep 2014 11:30:06 -0700 (PDT) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net. [76.218.8.156]) by mx.google.com with ESMTPSA id o92sm3543487qgd.0.2014.09.12.11.30.04 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 12 Sep 2014 11:30:05 -0700 (PDT) Message-ID: <54133AE2.2080301@gmail.com> Date: Fri, 12 Sep 2014 11:26:42 -0700 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Wei Chuang , endymail@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/62_y2KCM-LNAaEd9hCeftMonxps Subject: Re: [Endymail] Improvements to S/MIME 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, 12 Sep 2014 18:30:24 -0000 On 9/12/2014 10:48 AM, Wei Chuang wrote: > I would like to propse that endymail list seems like a good place to > compile future IETF work for improving S/MIME (RFC5751). Let me suggest that there is a task that needs to come before that. The task is gaining agreement on the nature of the operation of end2end encryption and how it might be different from previous operations. Think of it as a meta-gap analysis, since it would not be specific to s/mime. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Fri Sep 12 11:39:21 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 4F9361A7035 for ; Fri, 12 Sep 2014 11:39:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jnr4ILZOjReS for ; Fri, 12 Sep 2014 11:39:19 -0700 (PDT) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E82841A7028 for ; Fri, 12 Sep 2014 11:39:18 -0700 (PDT) Received: by mail-qg0-f48.google.com with SMTP id q108so1233597qgd.35 for ; Fri, 12 Sep 2014 11:39:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=qg3z7/Ydapax9VKcvZQuU9GxTTO4PeOapcSW0+oiBpU=; b=n0QlmhKLG9YBPwTBQSAk20VyGwKJG5yk9HFrxOpIY1UkkYARryNmcfwzAUi0slcnTX A2QPhzdfZ1k/63HdjP0LNunF+vSsW1fx4hnWGdRJwFpITdYvHRhOJoKYgHNhvbqClajD m1n2PA/v8m1IfPEgPaMM+yXIZVRLDQZGd/yga0s8EJIUBJUhmO2nZ+tVYL0Z3HLOcfRY vJTqspvRWg9m2ZyKYPmZZVusMWe3YjkLyHOdVVqMInpiDafD/ILdlS9ZIUB0LYR6LCFT BamZqZBVE+vcAvrZovBid+V44ps6m0Vxgm83FOmw3Egbb/tBiym9gaWfAJ22SVIM+57X 6fJQ== X-Received: by 10.224.104.1 with SMTP id m1mr14893042qao.81.1410547156070; Fri, 12 Sep 2014 11:39:16 -0700 (PDT) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net. [76.218.8.156]) by mx.google.com with ESMTPSA id f91sm3554253qgf.6.2014.09.12.11.39.14 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 12 Sep 2014 11:39:15 -0700 (PDT) Message-ID: <54133D0A.10603@gmail.com> Date: Fri, 12 Sep 2014 11:35:54 -0700 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Arnt Gulbrandsen References: <3f5714b98514a5fc21cf872c798bc3445317968b88bf5ebac39505df09b11475.sha-256@android.antelope.email> In-Reply-To: <3f5714b98514a5fc21cf872c798bc3445317968b88bf5ebac39505df09b11475.sha-256@android.antelope.email> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/Zz9gHrjtFcFsrM6I8qrFRsTrV2k Cc: endymail@ietf.org Subject: Re: [Endymail] Improvements to S/MIME 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, 12 Sep 2014 18:39:20 -0000 On 9/12/2014 11:12 AM, Arnt Gulbrandsen wrote: > Just a question... I heard someone say at one IETF conference that > S/MIME is the only standard with more implementations than users. Why > has it suffered that fate? Surely not because of the two problems you > mention. Generic discussions about challenges in gaining use of end2end security at Internet scale seem to be applicable to S/Mime. They note: 1. We don't have an existence proof for workable key management at scale. 2. We don't have an existence proof for usability (UX, HCI, etc.) at Internet scale, which means workable for non-geeks who have no extra motivation. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Fri Sep 12 11:52:01 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 5BFD01A06FC for ; Fri, 12 Sep 2014 11:51:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.03 X-Spam-Level: X-Spam-Status: No, score=-3.03 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, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.652, 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 om1uiAbp0jS8 for ; Fri, 12 Sep 2014 11:51:56 -0700 (PDT) Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d: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 BF62D1A0011 for ; Fri, 12 Sep 2014 11:51:56 -0700 (PDT) Received: by mail-qg0-f51.google.com with SMTP id e89so1204065qgf.10 for ; Fri, 12 Sep 2014 11:51:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=hdK6Xw3SYWq4mog05mDkRpuUGFcs63u20baJC5LDhK4=; b=BWTC3dLSgkoBRjeHsggzeHMwDlJJyVKUbxCLR0sayLFq9VLBxYA0Fk+Z1IVMAgs93b S/lLTbwWZub/rEMpSQrd/pY5aSwM5+4OC5oCVxIT0kSnh7jdiCP4zZ4mt/+lgGGEn1jN 3LSTl9Jyz3Y0KL5HYQMxe1B3usx7Bk6tJmwtQBX9e+Jji4OxPx/QGfvRzhVZW0M6yeDJ XEM+O2DJwX9IsUHL/SKHOtmVbHFEMYmTueujdKkk9+tmk5VuhMp7UPPdon/bzVjiTJvK XB2gUBd1/jb1DRwKNOwpK4/VAokYW5g7/Hc7KJYblUjsYrrb4W/uWws2PstTCmKDrdnn U/Hg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=hdK6Xw3SYWq4mog05mDkRpuUGFcs63u20baJC5LDhK4=; b=GspAglCf+er7Y+CHhooHyK1OVUbhOQj2+oOFy/fjFQbIdJEqUSRVkv6NTnYVsnDkyH +X5s6usEKGaFNRL455TkbKs2JNzeC30bBSbySTGdg41nWgDxpLYZApai9x7LI8YqD3RY CCuLowV2E1IoHocFhX8FchxZxcy4VYDwlu/VjbfMjd2D119zl487WTUSsRd4VHeUXfaV IBq6KY8LvT+tOKnYWwI6/qQBntGG+2ay0ROkN+S/d6jgruyMAT/ExodsjleS7RigkCf4 0wX8MFFQrFa00IcSVDhkNvIglK2rLTMijJNIT0WGlWTl8zcB09T3xzpU2ZzSnR0kYd+M mSsg== X-Gm-Message-State: ALoCoQknzlrL1ztMsNUYehk0yLR//xzePg/pULQ2b/RguwkP5/xBxXHnPKSUnU9x8mfbQuhFuus4 X-Received: by 10.140.101.118 with SMTP id t109mr15375556qge.101.1410547914444; Fri, 12 Sep 2014 11:51:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.116.71 with HTTP; Fri, 12 Sep 2014 11:51:34 -0700 (PDT) In-Reply-To: <3f5714b98514a5fc21cf872c798bc3445317968b88bf5ebac39505df09b11475.sha-256@android.antelope.email> References: <3f5714b98514a5fc21cf872c798bc3445317968b88bf5ebac39505df09b11475.sha-256@android.antelope.email> From: Wei Chuang Date: Fri, 12 Sep 2014 11:51:34 -0700 Message-ID: To: Arnt Gulbrandsen Content-Type: multipart/alternative; boundary=001a11c16afc6143cb0502e2c7cc Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/CyykgHLJD1X1lOLCNjJAxwl17dw Cc: endymail@ietf.org Subject: Re: [Endymail] Improvements to S/MIME 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, 12 Sep 2014 18:51:58 -0000 --001a11c16afc6143cb0502e2c7cc Content-Type: text/plain; charset=ISO-8859-1 On Fri, Sep 12, 2014 at 11:12 AM, Arnt Gulbrandsen wrote: > Just a question... I heard someone say at one IETF conference that S/MIME > is the only standard with more implementations than users. Why has it > suffered that fate? Surely not because of the two problems you mention. My two problems relate to privacy problems I see with S/MIME. More to your point, if you can make concrete the issues that cause lack of S/MIME usage, those can be added to the list and the community will prioritize the list by importance. -Wei > > Arnt > --001a11c16afc6143cb0502e2c7cc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Fri, Sep 12, 2014 at 11:12 AM, Arnt Gulbrandsen &l= t;arnt@gulbra= ndsen.priv.no> wrote:
Just = a question... I heard someone say at one IETF conference that S/MIME is the= only standard with more implementations than users. Why has it suffered th= at fate? Surely not because of the two problems you mention.

My two problems relate to privacy problems I see with S/M= IME. =A0 More to your point, if you can make concrete the issues that cause= lack of S/MIME usage, those can be added to the list and the community wil= l prioritize the list by importance.

-Wei



Arnt

--001a11c16afc6143cb0502e2c7cc-- From nobody Fri Sep 12 11:52: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 468361A7028 for ; Fri, 12 Sep 2014 11:52:27 -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 TNH1-dBtV7-J for ; Fri, 12 Sep 2014 11:52:26 -0700 (PDT) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F6CB1A6F85 for ; Fri, 12 Sep 2014 11:52:26 -0700 (PDT) Received: by mail-lb0-f175.google.com with SMTP id v6so1425386lbi.20 for ; Fri, 12 Sep 2014 11:52:24 -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=K7cAyTrWqCkdZcxGJXRwuKj2iFMNAe2fXzJgv72iomE=; b=EUUPo6cmH3QCp5HALFQ/wsqtic7UZM5ICzCCsr8BCU7VOlaDJpaB2PdsX+N1aIvRSP LLFkbb85Dvvs0/9yqr22wo2JTpzi6leTHm3aorHfhxWFVL9S+5TbqLotX8qsNCFF2zKF /MZzjEOiOmYn7oeDtWvY561d3yHyLvF1V34WXTwNwi442OlyfXNC267swR001Fqx3dup IYo4+YOOxiZEYV0AvtE2Cy3sTzASj8Z54rH1MujT0iz3tZd04kTWzFk408dcU4eVD7GO rRUke7hc4eY3fXhOzqtNFTN2YlpEO8PnDYDPomb4pJ7PTWSW7Un66vplmcMuCKPNGR2q mTDw== MIME-Version: 1.0 X-Received: by 10.152.1.137 with SMTP id 9mr10963228lam.85.1410547944493; Fri, 12 Sep 2014 11:52:24 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.122.51 with HTTP; Fri, 12 Sep 2014 11:52:24 -0700 (PDT) In-Reply-To: <54133D0A.10603@gmail.com> References: <3f5714b98514a5fc21cf872c798bc3445317968b88bf5ebac39505df09b11475.sha-256@android.antelope.email> <54133D0A.10603@gmail.com> Date: Fri, 12 Sep 2014 14:52:24 -0400 X-Google-Sender-Auth: hgvrhM0i7xwTVsd-3lkDE10grbk Message-ID: From: Phillip Hallam-Baker To: Dave Crocker Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/pVsI1WHWJou4X2_B5Syd63U1pis Cc: Arnt Gulbrandsen , endymail Subject: Re: [Endymail] Improvements to S/MIME 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, 12 Sep 2014 18:52:27 -0000 On Fri, Sep 12, 2014 at 2:35 PM, Dave Crocker wrote: > On 9/12/2014 11:12 AM, Arnt Gulbrandsen wrote: >> Just a question... I heard someone say at one IETF conference that >> S/MIME is the only standard with more implementations than users. Why >> has it suffered that fate? Surely not because of the two problems you >> mention. > > > Generic discussions about challenges in gaining use of end2end security > at Internet scale seem to be applicable to S/Mime. > > They note: > > 1. We don't have an existence proof for workable key management at > scale. > > 2. We don't have an existence proof for usability (UX, HCI, etc.) at > Internet scale, which means workable for non-geeks who have no extra > motivation. For once I agree with Dave, sort of. It is important to keep note of such issues. But solving them is not very difficult. Making S/MIME cover the whole message is trivial: Just extract the whole message including the content headers, encrypt it and stick it in an attachment. Job done. The only problem here then is knowing if the recipient supports this S/MIME format. Which is one of the systemic problems that makes S/MIME unusable: there is no negotiation mechanism and no way for the sender to know what the receiver can accept. There are many pieces of data a sender needs to know: 1) Should encryption be used in preference to plaintext? 2) Does the receiver support AES? 3) Does the receiver support PGP message format? 4) Does the receiver support S/MIME message format? 5) Versions, options on the above. But what is critical is that if we do end up deploying one of the proposals that solves these problems - and we already have a working proof of concept, we have to make sure that the 'encrypt entire message' issue is not forgotten. But given that PGP has the same problem, I think this particular feature could well be a point that gets the two camps to agree on convergence. Because surely we can all agree that not encrypting the subject line was a ridiculous limitation that makes the specs toybox implementations. From nobody Sat Sep 13 10:56:54 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 F2DA51A0052 for ; Sat, 13 Sep 2014 10:56:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.5 X-Spam-Level: X-Spam-Status: No, score=-5.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_HI=-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 YtfMgjf1PL9E for ; Sat, 13 Sep 2014 10:56:50 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD4D81A004D for ; Sat, 13 Sep 2014 10:56:50 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1XSrZ2-0004kD-Mq for ; Sat, 13 Sep 2014 19:56:48 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.82 #3 (Debian)) id 1XSrWM-0001q3-CS; Sat, 13 Sep 2014 19:54:02 +0200 From: Werner Koch To: Wei Chuang References: Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: id=1E42B367; url=finger:wk@g10code.com Date: Sat, 13 Sep 2014 19:54:02 +0200 In-Reply-To: (Wei Chuang's message of "Fri, 12 Sep 2014 10:48:07 -0700") Message-ID: <87sijvmmo5.fsf@vigenere.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/Fp9PPLXt2qYM0TOhP0nu1qZXoRw Cc: endymail@ietf.org Subject: Re: [Endymail] Improvements to S/MIME 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: Sat, 13 Sep 2014 17:56:53 -0000 On Fri, 12 Sep 2014 19:48, weihaw@google.com said: > 1) S/MIME doesn't fully protect users mail envelope metadata. For example > the recipient and envelope-sender must be visible to the intermediate SMTP If you want that, it is easy to put the messaqge into a message/rfc822 mail container and use faked subject and other mailer header. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Sat Sep 13 11:46:31 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 801A11A005E for ; Sat, 13 Sep 2014 11:46:28 -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 ridAFAXsq41b for ; Sat, 13 Sep 2014 11:46:27 -0700 (PDT) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 296531A007C for ; Sat, 13 Sep 2014 11:46:26 -0700 (PDT) Received: by mail-la0-f47.google.com with SMTP id mc6so2639610lab.6 for ; Sat, 13 Sep 2014 11:46:25 -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=U1UsClGRYLfKFXIHx8Rtpw8+Pz7Sm/ya+HuhwObPO3w=; b=g89LmfRYv83N+YUkQVGlW7lT9K7ZFz2c3Xh096y3WFHnQHiM+WU0sTt5WZcXmu56aw 7M/H16Pig7gxn31u+96TqJF92+lqqp0REjgBCIN0lY9S5YCNEoIBERKrqCqNeAMSonyH lza8KKm/jlcHkK4+AITAvN02m3+/g3p4u8ZeDZ8UQJcy0Dm0421Z/C9/XAO6Rhwfln9D zHUIEhrH6qR+LdQyJptfg3088/ZQyAe1BKGnoWf3TyV2OfAVq0bXcHlWFwaubb4GlM8M Wu+/6+z6uvWWRSuvnKf4y7JRIhXdWmzBT+MYrSGpx8ckryC5GG2rDVo3UjNUViXS+gRH SW+w== MIME-Version: 1.0 X-Received: by 10.153.11.132 with SMTP id ei4mr17717875lad.24.1410633985501; Sat, 13 Sep 2014 11:46:25 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.122.51 with HTTP; Sat, 13 Sep 2014 11:46:25 -0700 (PDT) In-Reply-To: <87sijvmmo5.fsf@vigenere.g10code.de> References: <87sijvmmo5.fsf@vigenere.g10code.de> Date: Sat, 13 Sep 2014 14:46:25 -0400 X-Google-Sender-Auth: HluOiNbyb9kShY1a6UetxDwP9wc Message-ID: From: Phillip Hallam-Baker To: Werner Koch Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/aGEgTQP-RQqs9gl0iQTad1c84dw Cc: Wei Chuang , endymail Subject: Re: [Endymail] Improvements to S/MIME 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: Sat, 13 Sep 2014 18:46:28 -0000 On Sat, Sep 13, 2014 at 1:54 PM, Werner Koch wrote: > On Fri, 12 Sep 2014 19:48, weihaw@google.com said: > >> 1) S/MIME doesn't fully protect users mail envelope metadata. For example >> the recipient and envelope-sender must be visible to the intermediate SMTP > > If you want that, it is easy to put the messaqge into a message/rfc822 > mail container and use faked subject and other mailer header. Again there is a difference between what you can do and a standard. I think that 80% of what we need to do could be done in a profile of S/MIME that says stuff like * MUST support AES-128, AES-256 * MUST support [choose order of encrypt + sign] * MUST support domain level certs for end entity * MUST support message/rfc822 encrypted payload What we need to add on top is really not so difficult: * Mechanism for discovering recipient encryption preference, format support (PGP/SMIME), algorithm support and encryption key * Mechanism for direct trust, aka key fingerprint * Mechanism for private key maintenance But for any of it to work, we all have to do the same thing. From nobody Sun Sep 14 01:13:33 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 E3A751A02DA for ; Sun, 14 Sep 2014 01:13:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.03 X-Spam-Level: X-Spam-Status: No, score=-3.03 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, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.652, 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 bWuc10Vod-WV for ; Sun, 14 Sep 2014 01:13:29 -0700 (PDT) Received: from mail-qa0-x22e.google.com (mail-qa0-x22e.google.com [IPv6:2607:f8b0:400d:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2C2C1A017D for ; Sun, 14 Sep 2014 01:13:28 -0700 (PDT) Received: by mail-qa0-f46.google.com with SMTP id k15so2509296qaq.5 for ; Sun, 14 Sep 2014 01:13:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=u8lRB3YSrEYp3jMq9+UlNdmNUlqt70GEqxXcqYzVCAY=; b=YqyoXbs7GO/P9Fwu3f0NpDI9B4yGZzRgK2FYgAryQiXyyb22SmRkIDOV1vwdhKpBzK fygV0EU+YjIuH10MNt03Z5mowkCJ3U1cive1V2zIkSAU9Rt/kYaBklDedVdtpnc86CSK Z4mm/1PCQV8RRlfYfxaRv8nTpr2+DCjw2XkMmqGeq0dYXT5W3wmSRRW41rT26X/Scqps a9cQlrUjz/KWQEADKzAamtGXm3Ht1IPiqo11e3RFIZra42oxBThXHuNxxwO72qzfgfqx UpB4G6J+e9V5FZZchuJKGgYwMbWGadlGUKvmkKHzIpEmrF/g/Oezhoz6kAmX0YmRyfqs vxmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=u8lRB3YSrEYp3jMq9+UlNdmNUlqt70GEqxXcqYzVCAY=; b=Hd5gIDChbYLlF2i5AKBKdKG5H9N96g/d/OgnEQi5xh+hwnwor5W+4DhpZpoL3oTXMH 1/tf4vd3SCGKHla+umUXVIx1oOzQHne6GLb99phZh0DQnv1wLYz4Eabl/N6+W8QFPqKK ebYSIs9Zkbrxr8SZ68Gz9ZOjI82pOPn+/zqalNpJfjLznxuSDI5pnp2OPwgr5Aqzejg6 rZtq1RmoFcqbmUhMongzjK2Kqf2sC9sxYFgL+3bprWNTJujPfkQhcqJd5wITVunyd9lB ns01OAxqZVBK+Mv8+PK+YSjDRrmuhm+JmtVE3OH06NvI6KPQuHpjV2OLyNQNQlffADM4 7+NQ== X-Gm-Message-State: ALoCoQnUOHlaoN7mhZoC317PATLdSrRLuNDFFRWcD+XYRb+o8Dv4rIhZNUJlbEAb2tYJwpXh14ye X-Received: by 10.140.38.231 with SMTP id t94mr7571973qgt.3.1410682407963; Sun, 14 Sep 2014 01:13:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.116.71 with HTTP; Sun, 14 Sep 2014 01:13:07 -0700 (PDT) In-Reply-To: <87sijvmmo5.fsf@vigenere.g10code.de> References: <87sijvmmo5.fsf@vigenere.g10code.de> From: Wei Chuang Date: Sun, 14 Sep 2014 01:13:07 -0700 Message-ID: To: Werner Koch Content-Type: multipart/alternative; boundary=001a11c13ed0d1941b0503021742 Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/9r7Kpm9TyCjQ9-BQziNYmbBTHAQ Cc: endymail@ietf.org Subject: Re: [Endymail] Improvements to S/MIME 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: Sun, 14 Sep 2014 08:13:31 -0000 --001a11c13ed0d1941b0503021742 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Sep 13, 2014 at 10:54 AM, Werner Koch wrote: > On Fri, 12 Sep 2014 19:48, weihaw@google.com said: > > > 1) S/MIME doesn't fully protect users mail envelope metadata. For > example > > the recipient and envelope-sender must be visible to the intermediate > SMTP > > If you want that, it is easy to put the messaqge into a message/rfc822 > mail container and use faked subject and other mailer header. > Right I agree that there is a RFC5751 sec 3.1 ( http://tools.ietf.org/html/rfc5751#page-18 ) that mentions the message/rfc822, but unless I'm missing something one still has to specify the intended recipient, and a return path. Even if the body and most headers were wrapped hence private, an adversary could still find the sender/recipient information very useful. Another issue albeit a small one with message/rfc822, was what to do if the headers conflicted between the outer and inner messages. -Wei > > > Salam-Shalom, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > > --001a11c13ed0d1941b0503021742 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Sat, Sep 13, 2014 at 10:54 AM, Werner Koch <wk@gnupg.org> = wrote:
On Fri, 12 Sep 2014 19:48, weihaw@google.com said:

> 1) S/MIME doesn't fully protect users mail envelope metadata.=A0 F= or example
> the recipient and envelope-sender must be visible to the intermediate = SMTP

If you want that, it is easy to put the messaqge into a message/rfc8= 22
mail container and use faked subject and other mailer header.

Right I agree that there is a RFC5751 sec 3.1 (http://tools.ietf.org/htm= l/rfc5751#page-18 ) that mentions the message/rfc822, but unless I'= m missing something one still has to specify the intended recipient, and a = return path.=A0 Even if the body and most headers were wrapped hence privat= e, an adversary could still find the sender/recipient information very usef= ul.

Another issue albeit a small one with message/= rfc822, was what to do if the headers conflicted between the outer and inne= r messages.

-Wei
=A0


Salam-Shalom,

=A0 =A0Werner

--
Die Gedanken sind frei.=A0 Ausnahmen regelt ein Bundesgesetz.


--001a11c13ed0d1941b0503021742-- From nobody Sun Sep 14 01:21:45 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 7A4BD1A02DB for ; Sun, 14 Sep 2014 01:21:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.03 X-Spam-Level: X-Spam-Status: No, score=-3.03 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, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.652, 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 lYJo3DOISAB8 for ; Sun, 14 Sep 2014 01:21:42 -0700 (PDT) Received: from mail-qg0-x229.google.com (mail-qg0-x229.google.com [IPv6:2607:f8b0:400d:c04::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 062131A02DA for ; Sun, 14 Sep 2014 01:21:41 -0700 (PDT) Received: by mail-qg0-f41.google.com with SMTP id a108so2664011qge.14 for ; Sun, 14 Sep 2014 01:21:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=mUXkgo16Pdb32VLb/sz6JanUuhehn8m9Olalh4dN0OE=; b=RITrOiGzXn/dTswoW406QAYQ35pX8W+ET4Mw/Fp3fRci6NFBynaKCcfcB/KmjtoiMh QODtC+t6sN8d/ZoeBFGTgY5auQ2XgnIghFxLYcfXdWoM3U3s6rnjOm6B3ud2DXE6aokE 8pIAHI0HlE2bPWnifzrA6QEFl41UOvzfNQknxSGxRy/GW43IVG0m56b/0Ypi7ElfvgH0 WD2mGcOwUohq3U6wCRyFHUtx9I20E6hsALQBC7qEhKrjezvA3z3NGDy6o8+zmEA+WWOB 1mjvCBoACmfxe9Jdx1bWcRY5ZmcxjZFAewLI77KvZz3WYzhW2PFu3nEomQt3bTgSV0MV zh6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=mUXkgo16Pdb32VLb/sz6JanUuhehn8m9Olalh4dN0OE=; b=Tpk7I+JtXh9ywM66LiWAyD2LEbeO1hZqKz6Mwpv8I2kLnJzOe6/xut0O8Fv1QJHvSq D3QYx1vRhTcy4n2/ATDTBSqNBsUfN+MncPXB6HAm/g0o/HXlAP590pwzdsk6mYXF9qOG 0EpqAGq17YPp2B8+3be+BBt66yWVw27TEPpTYfzHVrjI6UL9qLGOs9xZa5McBBxPadIp l1MFPSHlkSifdWH1ExsmZTUaF8qUSlYfOPmviC0IQt643wCCm7O9nbjsbyBGStezXLEp ACfdtEAPx3Ponk0yoI335VNU/vDimSRUo5H1M7N1e0/Mr002ukcxmr1u6eGNpxk2X3lG FyQg== X-Gm-Message-State: ALoCoQke9NfVJycUCz9WDmsTFvz99AiHKwFmBzwKU4ZIW6lw+cPR8B98t1tfKkdkX2u0egqbwBoN X-Received: by 10.140.96.200 with SMTP id k66mr28445390qge.78.1410682900961; Sun, 14 Sep 2014 01:21:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.116.71 with HTTP; Sun, 14 Sep 2014 01:21:19 -0700 (PDT) In-Reply-To: References: <87sijvmmo5.fsf@vigenere.g10code.de> From: Wei Chuang Date: Sun, 14 Sep 2014 01:21:19 -0700 Message-ID: To: Phillip Hallam-Baker Content-Type: multipart/alternative; boundary=001a113968463402220503023516 Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/u4c0IYaRLDcihfn8AfHQZoC-WVA Cc: Werner Koch , endymail Subject: Re: [Endymail] Improvements to S/MIME 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: Sun, 14 Sep 2014 08:21:43 -0000 --001a113968463402220503023516 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Sep 13, 2014 at 11:46 AM, Phillip Hallam-Baker < phill@hallambaker.com> wrote: > On Sat, Sep 13, 2014 at 1:54 PM, Werner Koch wrote: > > On Fri, 12 Sep 2014 19:48, weihaw@google.com said: > > > >> 1) S/MIME doesn't fully protect users mail envelope metadata. For > example > >> the recipient and envelope-sender must be visible to the intermediate > SMTP > > > > If you want that, it is easy to put the messaqge into a message/rfc822 > > mail container and use faked subject and other mailer header. > > Again there is a difference between what you can do and a standard. > > I think that 80% of what we need to do could be done in a profile of > S/MIME that says stuff like > > * MUST support AES-128, AES-256 > * MUST support [choose order of encrypt + sign] > * MUST support domain level certs for end entity > * MUST support message/rfc822 encrypted payload > > What we need to add on top is really not so difficult: > > * Mechanism for discovering recipient encryption preference, format > support (PGP/SMIME), algorithm support and encryption key > Two ideas: 1) DNS (either new TXT entry or new record type) 2) EHLO SMTP extension > * Mechanism for direct trust, aka key fingerprint > * Mechanism for private key maintenance > Is this issue key rotation? -Wei --001a113968463402220503023516 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Sat, Sep 13, 2014 at 11:46 AM, Phillip Hallam-Baker <phill@hall= ambaker.com> wrote:
On Sat, Sep 13, 2014 at 1:54 PM, Werner Koch <wk@gnupg.org> wrote:
> On Fri, 12 Sep 2014 19:48, weihaw= @google.com said:
>
>> 1) S/MIME doesn't fully protect users mail envelope metadata.= =A0 For example
>> the recipient and envelope-sender must be visible to the intermedi= ate SMTP
>
> If you want that, it is easy to put the messaqge into a message/rfc822=
> mail container and use faked subject and other mailer header.

Again there is a difference between what you can do and a standard.<= br>
I think that 80% of what we need to do could be done in a profile of
S/MIME that says stuff like

* MUST support AES-128, AES-256
* MUST support [choose order of encrypt + sign]
* MUST support domain level certs for end entity
* MUST support message/rfc822 encrypted payload

What we need to add on top is really not so difficult:

* Mechanism for discovering recipient encryption preference, format
support (PGP/SMIME), algorithm support and encryption key
<= div>
Two ideas:
1) DNS (either new TXT entry or new= record type)
2) EHLO SMTP extension
=A0
* Mechanism for direct trust, aka key fingerprint
* Mechanism for private key maintenance

Is this issue key rotation?

-Wei

--001a113968463402220503023516-- From nobody Sun Sep 14 02:06:56 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 CEA0B1A02FF for ; Sun, 14 Sep 2014 02:06:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-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 lsezh3ygMDIS for ; Sun, 14 Sep 2014 02:06:51 -0700 (PDT) Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE1B61A02F7 for ; Sun, 14 Sep 2014 02:06:50 -0700 (PDT) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1XT5lh-0002kw-81 for ; Sun, 14 Sep 2014 11:06:49 +0200 Received: from wk by vigenere.g10code.de with local (Exim 4.82 #3 (Debian)) id 1XT5ht-00040A-0O; Sun, 14 Sep 2014 11:02:53 +0200 From: Werner Koch To: Wei Chuang References: <87sijvmmo5.fsf@vigenere.g10code.de> Organisation: g10 Code GmbH X-message-flag: Mails containing HTML will not be read! Please send only plain text. OpenPGP: id=1E42B367; url=finger:wk@g10code.com Date: Sun, 14 Sep 2014 11:02:52 +0200 In-Reply-To: (Wei Chuang's message of "Sun, 14 Sep 2014 01:13:07 -0700") Message-ID: <87bnqimv5v.fsf@vigenere.g10code.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/l07NqrZYUrAOOSpxFAGvhiKX1t8 Cc: endymail@ietf.org Subject: Re: [Endymail] Improvements to S/MIME 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: Sun, 14 Sep 2014 09:06:53 -0000 On Sun, 14 Sep 2014 10:13, weihaw@google.com said: > Right I agree that there is a RFC5751 sec 3.1 ( > http://tools.ietf.org/html/rfc5751#page-18 ) that mentions the > message/rfc822, but unless I'm missing something one still has to specify > the intended recipient, and a return path. Even if the body and most Mixmaster does this for ages. Mutt has support for Mixmaster for more than 15 years. Changing this to work at all levels using MIME containers won't be too hard. For stronger anonymity the MTAs may use TOR or similar. Agreed, this is not a problem of standards but of doing the work. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nobody Sun Sep 14 06:46: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 66C301A038A for ; Sun, 14 Sep 2014 06:46:21 -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 DoBtHXhc0KRo for ; Sun, 14 Sep 2014 06:46:20 -0700 (PDT) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 882D51A0380 for ; Sun, 14 Sep 2014 06:46:19 -0700 (PDT) Received: by mail-la0-f50.google.com with SMTP id ty20so3289784lab.9 for ; Sun, 14 Sep 2014 06:46:17 -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=IlPhkwo2sZ8BOBkVRn+1b+eQfrf2R2SkpkLnU2qIA5k=; b=VzEr5NGybKOcR5f5Ys3mIqAoaRZhGASs2n/as5RbBCIXstZNlZl6j1j6omaIT1oRan 1S2yn5wAv7j3t4RkNLuO1fQP8g2Sx/vTWEq7lUJZPUpU9oiF3tPpivzNbk/ujB3g/obz 47qITJB6QpHGOv7aIKefxJTmv1LbIjZksPaM64tkLsi9cixBUDYHcHEkeVyP3ijAUZcg uTh3knL/e9T1rXYV4iMBqEtKF3+mMjv99oTXBxNnXm5SC47NIEVV+cqAGyNADO6CXLcP pAW2OA6mRTb2v4YBnHKxN2x8RL03pRrxnIlVk8aL28V1UqMD5lReQSGhVNH68baYbasM E8gw== MIME-Version: 1.0 X-Received: by 10.112.210.138 with SMTP id mu10mr2193591lbc.81.1410702377873; Sun, 14 Sep 2014 06:46:17 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.122.51 with HTTP; Sun, 14 Sep 2014 06:46:17 -0700 (PDT) In-Reply-To: References: <87sijvmmo5.fsf@vigenere.g10code.de> Date: Sun, 14 Sep 2014 09:46:17 -0400 X-Google-Sender-Auth: 8kzV5mFf7fAI8cYmR08L4gqvOSI Message-ID: From: Phillip Hallam-Baker To: Wei Chuang Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/V74xyQqHtpzbLW9HXBWqiEjZ5g8 Cc: Werner Koch , endymail Subject: Re: [Endymail] Improvements to S/MIME 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: Sun, 14 Sep 2014 13:46:21 -0000 On Sun, Sep 14, 2014 at 4:13 AM, Wei Chuang wrote: > > > On Sat, Sep 13, 2014 at 10:54 AM, Werner Koch wrote: >> >> On Fri, 12 Sep 2014 19:48, weihaw@google.com said: >> >> > 1) S/MIME doesn't fully protect users mail envelope metadata. For >> > example >> > the recipient and envelope-sender must be visible to the intermediate >> > SMTP >> >> If you want that, it is easy to put the messaqge into a message/rfc822 >> mail container and use faked subject and other mailer header. > > > Right I agree that there is a RFC5751 sec 3.1 > (http://tools.ietf.org/html/rfc5751#page-18 ) that mentions the > message/rfc822, but unless I'm missing something one still has to specify > the intended recipient, and a return path. Even if the body and most > headers were wrapped hence private, an adversary could still find the > sender/recipient information very useful. I suggest that we stick to exchanging endymail with disclosure of the routing information before we go on to the traffic analysis prevention problem. It is possible to prevent traffic analysis but that is a transport issue pretty much by definition. So it would suggest we look at S/MIME + TLS rather than one alone. And if they don't serve then we look at Tor and Mixmaster... From nobody Sun Sep 14 07:14:56 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 BC5561A03AD for ; Sun, 14 Sep 2014 07:14:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YmiI77zHahRr for ; Sun, 14 Sep 2014 07:14:52 -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 A29CC1A03AB for ; Sun, 14 Sep 2014 07:14:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id CAC318EFB45; Sun, 14 Sep 2014 10:14:47 -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 SbKFUTlDKWRr; Sun, 14 Sep 2014 10:14:47 -0400 (EDT) Received: from [10.0.1.16] (unknown [173.13.55.49]) by daboo.name (Postfix) with ESMTPSA id B9F878EFB3E; Sun, 14 Sep 2014 10:14:46 -0400 (EDT) Date: Sun, 14 Sep 2014 10:14:49 -0400 From: Cyrus Daboo To: Wei Chuang , Phillip Hallam-Baker Message-ID: <777AF78C7D6D8A868249F5B5@cyrus-4.local> In-Reply-To: References: <87sijvmmo5.fsf@vigenere.g10code.de> 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=370 Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/PemlOO4IxwEYsGkPE9BDbkYkLF0 Cc: Werner Koch , endymail Subject: Re: [Endymail] Improvements to S/MIME 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: Sun, 14 Sep 2014 14:14:53 -0000 Hi Wei, --On September 14, 2014 at 1:21:19 AM -0700 Wei Chuang wrote: >> * Mechanism for discovering recipient encryption preference, format >> support (PGP/SMIME), algorithm support and encryption key >> > > Two ideas: > 1) DNS (either new TXT entry or new record type) > 2) EHLO SMTP extension What about Webfinger - RFC7033? -- Cyrus Daboo From nobody Sun Sep 14 07:26: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 268B51A03C4 for ; Sun, 14 Sep 2014 07:26:09 -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 IcxNpTuuy4Zy for ; Sun, 14 Sep 2014 07:26:08 -0700 (PDT) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010: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 C8E8B1A03C3 for ; Sun, 14 Sep 2014 07:26:07 -0700 (PDT) Received: by mail-la0-f43.google.com with SMTP id gi9so3379984lab.30 for ; Sun, 14 Sep 2014 07:26:06 -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=HA+Cwz+VWxS4ILkwgUUQvcBOA7xn51xIjfijAQmmPh8=; b=C8mNf7VTUPYHPpgEdZVd/kH+h6io9cHXNftg0ThC0LHNXCNNMGkRA2Q2IiaYtzLDtS ZPusEpc0hq7f/OwmFpeW8EygNoPbT7zDIh1SVANsUJOMzpXUJbhZmBLwdcw/JAGB9G00 qXnSreauOiVytgW99MM2vy/IzURRqTj00N0P2usr457h87mMt9C+Hk1tPsUHdHawplj7 sR8SRBhWxqJo24E6PkkYfkj42RWapOi0z4cAvAAVYrcl8JgnpA1r413qz4NOwVOio5Z4 V5zo++RcDWX9T09ajWX+eCbIPqsK55ULfneKsBW5EfrZVMtSQADXdyUSnZul+n/P25Xk ptdA== MIME-Version: 1.0 X-Received: by 10.112.157.162 with SMTP id wn2mr20841918lbb.18.1410704766150; Sun, 14 Sep 2014 07:26:06 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.122.51 with HTTP; Sun, 14 Sep 2014 07:26:06 -0700 (PDT) In-Reply-To: <777AF78C7D6D8A868249F5B5@cyrus-4.local> References: <87sijvmmo5.fsf@vigenere.g10code.de> <777AF78C7D6D8A868249F5B5@cyrus-4.local> Date: Sun, 14 Sep 2014 10:26:06 -0400 X-Google-Sender-Auth: BbYGc46qCvJ4cdRsyazQmBLTC9U 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/eEba_dEvaMswDBCVcp-bb1hXWuk Cc: Wei Chuang , Werner Koch , endymail Subject: Re: [Endymail] Improvements to S/MIME 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: Sun, 14 Sep 2014 14:26:09 -0000 On Sun, Sep 14, 2014 at 10:14 AM, Cyrus Daboo wrote: > Hi Wei, > > --On September 14, 2014 at 1:21:19 AM -0700 Wei Chuang > wrote: > >>> * Mechanism for discovering recipient encryption preference, format >>> support (PGP/SMIME), algorithm support and encryption key >>> >> >> Two ideas: >> 1) DNS (either new TXT entry or new record type) >> 2) EHLO SMTP extension > > What about Webfinger - RFC7033? Well design of a JSON Web Service is hardly difficult. Webfinger infrastructure might be one of the places we look for information, so is the DNS, so is the emergent Trans notary infrastructure. First we should decide on what the information flows between the client and service need to be. Then we can decide what the realization should be. A Web Service is just an API after all, reuse of an API is sometimes good and sometimes very bad. Trying to reuse a 2D API for 3D graphics was a very bad plan for the company that tried it. From mitch@niftyegg.com Sun Sep 14 21:21:29 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 C229B1A0572 for ; Sun, 14 Sep 2014 21:21:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IXKh3a0rHPh5 for ; Sun, 14 Sep 2014 21:21:28 -0700 (PDT) Received: from mail-oa0-f49.google.com (mail-oa0-f49.google.com [209.85.219.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E0351A01E0 for ; Sun, 14 Sep 2014 21:21:28 -0700 (PDT) Received: by mail-oa0-f49.google.com with SMTP id m19so2168454oag.36 for ; Sun, 14 Sep 2014 21:21:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=951N9P2epLEOISKHCuSZO/dGyQFIHrIq2fa5K35BMoY=; b=Rn/7pa4qCgzKV+qZZekx4RCbtn34jUPT0D0c9h7O0QytzS+udweMjgzA0JEMxfblw6 clgInMXMgC/MuoWTEECIjadD0wpZDR+XQUuzL7lL37hUt1zK4df8BxKnL6Ww1AM7U+pw 6RpYvdb+skey09liO0PabtlR539Vp+0/r0/VlXp9E0X2H9ahVMekm4/USSe6cZ6imIA6 UHtXPcFub7rMPsWPtYCat/XHWkgxz34X0aZhXKL15A2Yon4EQnTHsw+JEaEJMK8aoPwE r5T61ljma1H03LEdImeYs/s0OPhDtxaxriDNCOOINMsiq9bKjlcuV1G8pk13/oU8JrdA aOMA== X-Gm-Message-State: ALoCoQkw9Dr3RgerQCMWrIpqa1ElPM1hY155BzRt58M8WWs53DNXZGOWvdF7Yo5HclRE5xZ6gNH4 MIME-Version: 1.0 X-Received: by 10.60.130.170 with SMTP id of10mr24781879oeb.10.1410754887725; Sun, 14 Sep 2014 21:21:27 -0700 (PDT) Received: by 10.182.98.48 with HTTP; Sun, 14 Sep 2014 21:21:27 -0700 (PDT) In-Reply-To: References: <87sijvmmo5.fsf@vigenere.g10code.de> Date: Sun, 14 Sep 2014 21:21:27 -0700 Message-ID: From: Tom Mitchell To: Phillip Hallam-Baker Content-Type: multipart/alternative; boundary=089e013a110ef2cbb6050312f7d5 Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/chGBe-qrPH_oEVhSctmRsuaHdc8 Cc: Wei Chuang , Werner Koch , endymail Subject: Re: [Endymail] Improvements to S/MIME 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, 15 Sep 2014 04:24:14 -0000 --089e013a110ef2cbb6050312f7d5 Content-Type: text/plain; charset=UTF-8 On Sun, Sep 14, 2014 at 6:46 AM, Phillip Hallam-Baker wrote: > On Sun, Sep 14, 2014 at 4:13 AM, Wei Chuang wrote: > > On Sat, Sep 13, 2014 at 10:54 AM, Werner Koch wrote: > >> On Fri, 12 Sep 2014 19:48, weihaw@google.com said: > >> > >> > 1) S/MIME doesn't fully protect users mail envelope metadata. For > >> > example > >> > the recipient and envelope-sender must be visible to the intermediate > >> > SMTP > >> > >> If you want that, it is easy to put the messaqge into a message/rfc822 > >> mail container and use faked subject and other mailer header. > > > > > > Right I agree that there is a RFC5751 sec 3.1 > > (http://tools.ietf.org/html/rfc5751#page-18 ) > ........... > I suggest that we stick to exchanging endymail with disclosure of the > routing information before we go on to the traffic analysis prevention > problem. Yes... One of the issues important hint for spam identification is routing information that is impossible from the stated sender. Prior to eliminating routing information it seems important that the message be self identifying and contain enough validation information to make opening a message from "Bob" a safe bet that it is infact from "Bob". If done correctly transport software can inspect a message and safely ignore adding or checking headers because crypto and message type removes this need. The reverse is not true as it opens a door for spam abuse. -- T o m M i t c h e l l --089e013a110ef2cbb6050312f7d5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= un, Sep 14, 2014 at 6:46 AM, Phillip Hallam-Baker <phill@hallambaker.c= om> wrote:
On Sun, Sep 14, = 2014 at 4:13 AM, Wei Chuang <weihaw= @google.com> wrote:
> On Sat, Sep 13, 2014 at 10:54 AM, Werner Koch <wk@gnupg.org> wrote:
>> On Fri, 12 Sep 2014 19:48, we= ihaw@google.com said:
>>
>> > 1) S/MIME doesn't fully protect users mail envelope metad= ata.=C2=A0 For
>> > example
>> > the recipient and envelope-sender must be visible to the inte= rmediate
>> > SMTP
>>
>> If you want that, it is easy to put the messaqge into a message/rf= c822
>> mail container and use faked subject and other mailer header.
>
>
> Right I agree that there is a RFC5751 sec 3.1
> (http://tools.ietf.org/html/rfc5751#page-18 )
...........
I suggest that we stick to exchanging endymail with disclosure of the
routing information before we go on to the traffic analysis prevention
problem.

Yes...
One of the issues= important hint for spam identification is routing information that =C2=A0i= s impossible
from the stated sender. =C2=A0 Prior to eliminating = routing information it seems important that
the message be self i= dentifying and contain enough validation information to make opening
<= div>a message from "Bob" a safe bet that it is infact from "= Bob". =C2=A0If done correctly transport
software can inspect= a message and safely ignore adding or checking headers because=C2=A0
=
crypto and message type removes this need.

Th= e reverse is not true as it opens a door for spam abuse.
--
=C2=A0 T o m =C2=A0 =C2=A0M i t c h e l l
--089e013a110ef2cbb6050312f7d5-- From nobody Sun Sep 14 21:25:26 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 7C9A71A0572 for ; Sun, 14 Sep 2014 21:25:24 -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 f-k0KxsQo1QV for ; Sun, 14 Sep 2014 21:25:23 -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 AA8B91A01E0 for ; Sun, 14 Sep 2014 21:25:22 -0700 (PDT) Received: by mail-lb0-f182.google.com with SMTP id u10so89954lbd.13 for ; Sun, 14 Sep 2014 21:25:21 -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=721JbcMAWyZKtRxZEZIZBhZOlPnaayHVqw4hhcyVg+Y=; b=Z2U/6UsC7EEC0D5hXlSvkO662zej6T6HcRl62ekNCf+0WiVWi55OmJUzG6efqx7irL 3HiaGzp6NHk1VmvqhzJPQU3fBnRi65SWBpoVXg7v9kKfKfBqyMXw30BpKWrQNh29dptY ZVbaIhW0bPRW6cUw3V3jhYcpgJwdB0s/9Dx/mwFBPVrjefFcMaQHJMg66LxzqqpSyvgH M/ObeyoGtB6XdLR8vk3IzUbVEEWa+b1LWVpUfKYPEsSgPl2Pg5w9OVVOQACBRR9lMOdU 483YiL/bXimqadw0xmL0B+448uHbwoHfm0rxh5Uy8LpEPUO7Rhyms05/MA7QelvBxKO/ 85PA== MIME-Version: 1.0 X-Received: by 10.112.48.100 with SMTP id k4mr134347lbn.95.1410755120993; Sun, 14 Sep 2014 21:25:20 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.122.51 with HTTP; Sun, 14 Sep 2014 21:25:20 -0700 (PDT) In-Reply-To: References: <87sijvmmo5.fsf@vigenere.g10code.de> Date: Mon, 15 Sep 2014 00:25:20 -0400 X-Google-Sender-Auth: tTi5fwckdUAOxXcMd5j8CN7rZsU Message-ID: From: Phillip Hallam-Baker To: Tom Mitchell Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/_OqGKIhvjj3X1SPQcl8M-LGtQxs Cc: Wei Chuang , Werner Koch , endymail Subject: Re: [Endymail] Improvements to S/MIME 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, 15 Sep 2014 04:25:24 -0000 On Mon, Sep 15, 2014 at 12:21 AM, Tom Mitchell wrote: > On Sun, Sep 14, 2014 at 6:46 AM, Phillip Hallam-Baker > wrote: >> >> On Sun, Sep 14, 2014 at 4:13 AM, Wei Chuang wrote: >> > On Sat, Sep 13, 2014 at 10:54 AM, Werner Koch wrote: >> >> On Fri, 12 Sep 2014 19:48, weihaw@google.com said: >> >> >> >> > 1) S/MIME doesn't fully protect users mail envelope metadata. For >> >> > example >> >> > the recipient and envelope-sender must be visible to the intermediate >> >> > SMTP >> >> >> >> If you want that, it is easy to put the messaqge into a message/rfc822 >> >> mail container and use faked subject and other mailer header. >> > >> > >> > Right I agree that there is a RFC5751 sec 3.1 >> > (http://tools.ietf.org/html/rfc5751#page-18 ) > > ........... >> >> I suggest that we stick to exchanging endymail with disclosure of the >> routing information before we go on to the traffic analysis prevention >> problem. > > > Yes... > One of the issues important hint for spam identification is routing > information that is impossible > from the stated sender. Prior to eliminating routing information it seems > important that > the message be self identifying and contain enough validation information to > make opening > a message from "Bob" a safe bet that it is infact from "Bob". If done > correctly transport > software can inspect a message and safely ignore adding or checking headers > because > crypto and message type removes this need. > > The reverse is not true as it opens a door for spam abuse. That is a good argument, but the one I was making is that we can't hope to solve routing security anyway unless we have volume. It is much easier to hide in a jungle or a forest than a flat featureless plain. From nobody Mon Sep 15 01:39:04 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 CADE71A01E1 for ; Mon, 15 Sep 2014 01:39:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.03 X-Spam-Level: X-Spam-Status: No, score=-3.03 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, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.652, 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 hLEz4XKcUCbU for ; Mon, 15 Sep 2014 01:39:00 -0700 (PDT) Received: from mail-qg0-x22b.google.com (mail-qg0-x22b.google.com [IPv6:2607:f8b0:400d:c04::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5D1C1A017A for ; Mon, 15 Sep 2014 01:39:00 -0700 (PDT) Received: by mail-qg0-f43.google.com with SMTP id a108so3613057qge.30 for ; Mon, 15 Sep 2014 01:38:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=4u3ToQN7qE+pn+Rn6t88NC+Q9zjYwjFnrC5mBkT/Cms=; b=p3ZnMyDdnrSbOLeAKM5umaf33JFSUIDWjegfufpuw0TXTldUXNC9DqYeHCFb3/7c8m hX8jUNWXI4JLrTUqSB2VKQlM+y9SPLWN8ld4rCNgdk+hWYkCnNOMhalIRgTaWIpk+hme xZ6PDBMfLELCCw4eusztNFMSqDM+G/zTzqKBHW/7fr+oDPIzTLZENtPdyBo4Kr6OuGWV eUdMi6XRZt8dmDUxJHYYG53UtqyAX44z+gJLm4vQFd36qi4gbDdq2JXAHr2b40xbhxR3 ykJA2/o9GLj90/xqE2+G9Ze+YcvP72xWh4Q2srPxwzKVUzHfrsRsRnjc0RG41+aHz03g Dy8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=4u3ToQN7qE+pn+Rn6t88NC+Q9zjYwjFnrC5mBkT/Cms=; b=jpREu265hPCMesohy2oBwfXepz4wF56ewpVFhZFcbKowGk2pYfxy9GZSH/WnCkdppy fceCF9cEK/JUeP3rRNIFqzQ2lF1kHM8bvxBcJi8leAfrch7PuUKWM1mgO1nBE/cmRSxV 58BVSoXOohwTpHI6sYpuzB/iPkUvTD9l00ZadVBponvDYaentgfYfRLecYpFEEO4J8zP IFLIeNyC7QBcnRejR3iaPavRIJ7LlxUeoT8bGUSZWPhPXuZPgx9AfBRbnohwqPG1RsZS S24a+OVn6njmND6uOs5r/SVAHrtWj/IfmKJNI8EGrGmVE0THA+aQQgvm3DUcXwTSBXFM hTMA== X-Gm-Message-State: ALoCoQkWdCAOtP/jE0bw8JCrm8QexIEDCCCug0bO4jLNxseE2/nwdSDytJlNZjhkFLcTeZMfxPrC X-Received: by 10.224.162.196 with SMTP id w4mr33318051qax.60.1410770339845; Mon, 15 Sep 2014 01:38:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.116.71 with HTTP; Mon, 15 Sep 2014 01:38:38 -0700 (PDT) In-Reply-To: References: <87sijvmmo5.fsf@vigenere.g10code.de> <777AF78C7D6D8A868249F5B5@cyrus-4.local> From: Wei Chuang Date: Mon, 15 Sep 2014 01:38:38 -0700 Message-ID: To: Phillip Hallam-Baker Content-Type: multipart/alternative; boundary=089e012946b6f7a19305031690cf Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/HJ5ReG-ZBwOViF5nK3fbEo6nmq8 Cc: Cyrus Daboo , Werner Koch , endymail Subject: Re: [Endymail] Improvements to S/MIME 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, 15 Sep 2014 08:39:03 -0000 --089e012946b6f7a19305031690cf Content-Type: text/plain; charset=ISO-8859-1 On Sun, Sep 14, 2014 at 7:26 AM, Phillip Hallam-Baker wrote: > On Sun, Sep 14, 2014 at 10:14 AM, Cyrus Daboo wrote: > > Hi Wei, > > > > --On September 14, 2014 at 1:21:19 AM -0700 Wei Chuang < > weihaw@google.com> > > wrote: > > > >>> * Mechanism for discovering recipient encryption preference, format > >>> support (PGP/SMIME), algorithm support and encryption key > >>> > >> > >> Two ideas: > >> 1) DNS (either new TXT entry or new record type) > >> 2) EHLO SMTP extension > > > > What about Webfinger - RFC7033? > Agreed another idea to examine (as all have interesting trade offs). > > Well design of a JSON Web Service is hardly difficult. > > Webfinger infrastructure might be one of the places we look for > information, so is the DNS, so is the emergent Trans notary > infrastructure. > This is related to Certificate Transparency right? Granted I'm not really that familiar with CT which I had thought was for attestation of the validity of a certificate. Is there a pointer to some discussion / description on how one might use the Trans Notary infrastructure to broadcast the configuration information? -Wei --089e012946b6f7a19305031690cf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Sun, Sep 14, 2014 at 7:26 AM, Phillip Hallam-Baker <phill@halla= mbaker.com> wrote:
On Sun, Sep 14, 2014 at 10:14 AM, Cyrus Daboo <cyrus@daboo.name> wrote:
> Hi Wei,
>
> --On September 14, 2014 at 1:21:19 AM -0700 Wei Chuang <weihaw@google.com>
> wrote:
>
>>> * Mechanism for discovering recipient encryption preference, f= ormat
>>> support (PGP/SMIME), algorithm support and encryption key
>>>
>>
>> Two ideas:
>> 1) DNS (either new TXT entry or new record type)
>> 2) EHLO SMTP extension
>
> What about Webfinger - RFC7033?

<= /div>
Agreed another idea to examine (as all have interesting trade off= s). =A0=A0
=A0

Well design of a JSON Web Service is hardly difficult.

Webfinger infrastructure might be one of the places we look for
information, so is the DNS, so is the emergent Trans notary
infrastructure.

This is related to Cert= ificate Transparency right?=A0 Granted I'm not really that familiar wit= h CT which I had thought was for attestation of the validity of a certifica= te.=A0 Is there a pointer to some discussion / description on how one might= use the Trans Notary infrastructure to broadcast the configuration informa= tion? =A0=A0
=A0
-Wei

--089e012946b6f7a19305031690cf-- From nobody Mon Sep 15 01:51:17 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 6F6B61A0276 for ; Mon, 15 Sep 2014 01:51:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.03 X-Spam-Level: X-Spam-Status: No, score=-3.03 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, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.652, 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 vpvc0F92eoYj for ; Mon, 15 Sep 2014 01:51:14 -0700 (PDT) Received: from mail-qa0-x22f.google.com (mail-qa0-x22f.google.com [IPv6:2607:f8b0:400d:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F09941A026F for ; Mon, 15 Sep 2014 01:51:13 -0700 (PDT) Received: by mail-qa0-f47.google.com with SMTP id dc16so3443948qab.6 for ; Mon, 15 Sep 2014 01:51:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=yjF9fhuS8soIIUvAh/DRPwxECARxq3b0WNH4JvCxMwE=; b=EwQNWzbakVrZQIRbXtVWYULpfogfI43gxjuTRbDyMTRs6oTfvSaW0JjCWFHdsXtwTn o33PMD9znuZn9dxQAGSZZ8Xz3TBLyIun0OVuYhP8jaz9DM7qTlQvGPhrNrb4JwKXx8yE 50T7V9L4hYcw34BIcTjVRiyjZFAi80NuhPLVa6MMfMllXK0bYa11RdxyKWR5funERbO8 qYWm8dPFlOQF/iSQlwaVBwNH0sT0ZSj/Cu5MMeRbK5Pn0vfvBPnXLCqFIUfavgHwgM0j 32FHaiohTl4utM/0rL8ICa1Kx5XBL0m8GrhrMMUosPxvCL1XqykQms6dmAKD6dyeyIfi b99A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=yjF9fhuS8soIIUvAh/DRPwxECARxq3b0WNH4JvCxMwE=; b=HVa2yF8WI3mR5OTZxKO14K9hM4CRmEMttWqT1qd7cwvX0MeNI5dqoxaDspsBqVUCvO 28mNoqjSxn/31MARKNaGunFTsrYVJzIrR4ziv3UKg1Y44fibdGgmIPqv5kx1m4nXx6Mo 6RW3Dv/abw1T3QH8rtOZx3HgaDvHlJAUnkaNaaSl12f/ErF2n8uR6k4x1fJaTe+lZvr4 qDGuGGLxlbtiz+/ALV338b16isz/5XICUtTUWy7s9DAWi9+B5mIBO48WSeYGhIaGkQfi 9P2Db4qCZ419Yb+D66jzAGX8Vhz8qNFw3jm/yY5oqaU4fq7IQ1BMC+l449bGlmfqVbQP F75w== X-Gm-Message-State: ALoCoQntBj1ThVUZ9f4v9jJqFaDdFPMu9igmQdtCeG8jXbXn6h7FxoJXAziwLg3vTdMQLYv5MMKA X-Received: by 10.140.42.77 with SMTP id b71mr34730474qga.52.1410771073051; Mon, 15 Sep 2014 01:51:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.116.71 with HTTP; Mon, 15 Sep 2014 01:50:51 -0700 (PDT) In-Reply-To: References: <87sijvmmo5.fsf@vigenere.g10code.de> From: Wei Chuang Date: Mon, 15 Sep 2014 01:50:51 -0700 Message-ID: To: Phillip Hallam-Baker Content-Type: multipart/alternative; boundary=001a11c1293eab7470050316bc71 Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/nMr-uH_eMVFX6GZe6EP8W2p0FH8 Cc: Werner Koch , endymail Subject: Re: [Endymail] Improvements to S/MIME 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, 15 Sep 2014 08:51:15 -0000 --001a11c1293eab7470050316bc71 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Sep 13, 2014 at 11:46 AM, Phillip Hallam-Baker < phill@hallambaker.com> wrote: > On Sat, Sep 13, 2014 at 1:54 PM, Werner Koch wrote: > > On Fri, 12 Sep 2014 19:48, weihaw@google.com said: > > > >> 1) S/MIME doesn't fully protect users mail envelope metadata. For > example > >> the recipient and envelope-sender must be visible to the intermediate > SMTP > > > > If you want that, it is easy to put the messaqge into a message/rfc822 > > mail container and use faked subject and other mailer header. > > Again there is a difference between what you can do and a standard. > > I think that 80% of what we need to do could be done in a profile of > S/MIME that says stuff like > > * MUST support AES-128, AES-256 > * MUST support [choose order of encrypt + sign] > * MUST support domain level certs for end entity > * MUST support message/rfc822 encrypted payload > > What we need to add on top is really not so difficult: > > * Mechanism for discovering recipient encryption preference, format > support (PGP/SMIME), algorithm support and encryption key > * Mechanism for direct trust, aka key fingerprint > * Mechanism for private key maintenance > It occurs to me that acceptable X509 certificate profiles could be another i.e. does recipient require - CA path constraints - support certain revocation methods - accepted x509 versions, signature algorithm+keylength - accepted root CAs etc. -Wei --001a11c1293eab7470050316bc71 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Sat, Sep 13, 2014 at 11:46 AM, Phillip Hallam-Baker <phill@hall= ambaker.com> wrote:
On Sat, Sep 13, 2014 at 1:54 PM, Werner Koch <wk@gnupg.org> wrote:
> On Fri, 12 Sep 2014 19:48, weihaw= @google.com said:
>
>> 1) S/MIME doesn't fully protect users mail envelope metadata.= =A0 For example
>> the recipient and envelope-sender must be visible to the intermedi= ate SMTP
>
> If you want that, it is easy to put the messaqge into a message/rfc822=
> mail container and use faked subject and other mailer header.

Again there is a difference between what you can do and a standard.<= br>
I think that 80% of what we need to do could be done in a profile of
S/MIME that says stuff like

* MUST support AES-128, AES-256
* MUST support [choose order of encrypt + sign]
* MUST support domain level certs for end entity
* MUST support message/rfc822 encrypted payload

What we need to add on top is really not so difficult:

* Mechanism for discovering recipient encryption preference, format
support (PGP/SMIME), algorithm support and encryption key
* Mechanism for direct trust, aka key fingerprint
* Mechanism for private key maintenance

It occurs to me that acceptable X509 certificate profiles could be another= i.e. does recipient require
- CA path constraints
- su= pport certain revocation methods
- accepted x509 versions, signat= ure algorithm+keylength
- accepted root CAs
etc.
<= div>
-Wei
--001a11c1293eab7470050316bc71-- From nobody Tue Sep 16 10:06:30 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 D66021A885D for ; Tue, 16 Sep 2014 10:06:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.03 X-Spam-Level: X-Spam-Status: No, score=-3.03 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, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.652, 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 lo2crfcmXzW6 for ; Tue, 16 Sep 2014 10:06:26 -0700 (PDT) Received: from mail-qg0-x236.google.com (mail-qg0-x236.google.com [IPv6:2607:f8b0:400d: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 D6A621A8870 for ; Tue, 16 Sep 2014 10:06:25 -0700 (PDT) Received: by mail-qg0-f54.google.com with SMTP id z60so206910qgd.27 for ; Tue, 16 Sep 2014 10:06:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=hFKIvg1P8Iv74nXFd6lhxnJ+leISf0ZlAAN5ekdZxAU=; b=Vzkl/nifTN52SQZln3q0wYSvB0nT5Pn4ySuXeR7bQnwX2JUomVihO9HIvtCEdcz3fH ftWhgH3IPTylg+TOqTycudSpdej4qJL9zZ5a3Mb0TG4qDQIIIZm3zS1L6wx0FpI5vUU3 1BYNa5JinfIUjiAs/DOzFTI0pN3/YK/72Q8hdYCQdQjD69HaXft0mGFoPXVffDbN3y0d GY4MMHqyh9s9vDSZNMA6rZcvwZi15ohEvQBqyFVomqYRCtp/JtSPFNOLPmNyfsCO4mGX PHxlonMCzIu+HEmJbRq1c/9Atw6VfF+xLR7NuT7ECIP3pk6R5wI6YBkMGDjzyqgZ52mD 1xYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=hFKIvg1P8Iv74nXFd6lhxnJ+leISf0ZlAAN5ekdZxAU=; b=EWrhVkiJkppYNTzrA1IF4SQqS7tdcownLRuZnXTXtKzAbHE7fXLy/7ozElaoZHAW1q Wmz30cfzF5ZOkXbbompgAsaOFHtMW7uYyTqpX56KKv6XEQCNCtjUFKPqYc3ja++CP0c1 8DVjYj1qkQuzFzzP9gibxdMhBdQxjAarkcv5Q2GnNsd4jQdxyGnOrXmBnPmuhKImsDMp gz4DejYgVOSIe2yYTGPf4rw7rBfLaRjeFuVHRYc2drgvIwZjrLAdWgUoyaPGvGaCDS+r TafzFwcfrNpansXB8vmL6LYYVwXCXlUDYfFd4WWV/Eo9++uakr9+gr9cabEifIkk2GRa MxtA== X-Gm-Message-State: ALoCoQnvagOUyUO9AE11QnVs0NVC++OGngS8jbCtzJUlxqbeCSiIg6YFk3bVaaDOieO3KuTwpaQb X-Received: by 10.140.42.246 with SMTP id c109mr53133329qga.9.1410887185018; Tue, 16 Sep 2014 10:06:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.116.71 with HTTP; Tue, 16 Sep 2014 10:06:04 -0700 (PDT) In-Reply-To: References: <87sijvmmo5.fsf@vigenere.g10code.de> From: Wei Chuang Date: Tue, 16 Sep 2014 10:06:04 -0700 Message-ID: To: Werner Koch Content-Type: multipart/alternative; boundary=001a113a7bda7b63e7050331c5ec Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/xT0micTDkA3J6iGvSt12eFsnqdc Cc: endymail Subject: Re: [Endymail] Improvements to S/MIME 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, 16 Sep 2014 17:06:29 -0000 --001a113a7bda7b63e7050331c5ec Content-Type: text/plain; charset=ISO-8859-1 On Sun, Sep 14, 2014 at 1:13 AM, Wei Chuang wrote: > > > On Sat, Sep 13, 2014 at 10:54 AM, Werner Koch wrote: > >> On Fri, 12 Sep 2014 19:48, weihaw@google.com said: >> >> > 1) S/MIME doesn't fully protect users mail envelope metadata. For >> example >> > the recipient and envelope-sender must be visible to the intermediate >> SMTP >> >> If you want that, it is easy to put the messaqge into a message/rfc822 >> mail container and use faked subject and other mailer header. >> > > Right I agree that there is a RFC5751 sec 3.1 ( > http://tools.ietf.org/html/rfc5751#page-18 ) that mentions the > message/rfc822, but unless I'm missing something one still has to specify > the intended recipient, and a return path. Even if the body and most > headers were wrapped hence private, an adversary could still find the > sender/recipient information very useful. > > Another issue albeit a small one with message/rfc822, was what to do if > the headers conflicted between the outer and inner messages. > Just wanted to point out that wrapping using message/rfc822 may have problems. In another thread regarding DMARC damage, one proposed mitigation is also to wrap the message but was noted that this could open the recipient to phishing attacks due to mishandling of headers by the recipients MUA. See http://www.ietf.org/mail-archive/web/ietf/current/msg89601.html John Levine suggested there using other options for mitigating against DMARC. In the S/MIME context I don't think that's possible to avoid wrapping if one wants to protect the headers, so work will have to be done to prevent opening a phishing vector. -Wei > > -Wei > > >> >> >> Salam-Shalom, >> >> Werner >> >> -- >> Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. >> >> > --001a113a7bda7b63e7050331c5ec Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Sun, Sep 14, 2014 at 1:13 AM, Wei Chuang <weihaw@google.com>= wrote:


On Sat, Sep 13, 201= 4 at 10:54 AM, Werner Koch <wk@gnupg.org> wrote:
On Fri, 12 Sep 2014 19:48, weihaw@google.com said:

> 1) S/MIME doesn't fully protect users mail envelope metadata.=A0 F= or example
> the recipient and envelope-sender must be visible to the intermediate = SMTP

If you want that, it is easy to put the messaqge into a message/rfc8= 22
mail container and use faked subject and other mailer header.

Right I agree that there is a RFC5751 sec 3.1= (= http://tools.ietf.org/html/rfc5751#page-18 ) that mentions the message/= rfc822, but unless I'm missing something one still has to specify the i= ntended recipient, and a return path.=A0 Even if the body and most headers = were wrapped hence private, an adversary could still find the sender/recipi= ent information very useful.

Another issue albeit = a small one with message/rfc822, was what to do if the headers conflicted b= etween the outer and inner messages.

Just wanted to point out that wrapping using message/rfc8= 22 may have problems.=A0 In another thread regarding DMARC damage, one prop= osed mitigation is also to wrap the message but was noted that this could o= pen the recipient to phishing attacks due to mishandling of headers by the = recipients MUA.


John Levi= ne suggested there using other options for mitigating against DMARC.=A0 In = the S/MIME context I don't think that's possible to avoid wrapping = if one wants to protect the headers, so work will have to be done to preven= t opening a phishing vector.

-Wei
=A0=A0=

=
-Wei
=A0


Salam-Shalom,

=A0 =A0Werner

--
Die Gedanken sind frei.=A0 Ausnahmen regelt ein Bundesgesetz.



--001a113a7bda7b63e7050331c5ec-- From nobody Tue Sep 23 09:41:31 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 799CA1A1B34 for ; Tue, 23 Sep 2014 09:41:29 -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 RXkhNaJL1tGR for ; Tue, 23 Sep 2014 09:41:27 -0700 (PDT) Received: from mail-qg0-x22f.google.com (mail-qg0-x22f.google.com [IPv6:2607:f8b0:400d:c04::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F2A21A1B23 for ; Tue, 23 Sep 2014 09:41:27 -0700 (PDT) Received: by mail-qg0-f47.google.com with SMTP id z107so4715755qgd.6 for ; Tue, 23 Sep 2014 09:41:26 -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; bh=MVVoE1IrKtKfmc59Eb7/8wSiyXXBjgYM5it6kJtRHKw=; b=gvFH84aTWLLf4W366oOH5DPcmkThU48FBnnEE7PlM/3z+79o+cRgWQMHMIPrG5kK2g hJ+huxbeVvDN+NfJS7TFZ1K7MTJp8e8Ipow9r1wOvQ5Jw4e1/fm/W8Jj9JbZgPBQb7JX aftVoV77GUJ/xHUogiVCFUd9DNWszwspT/FRDvCBSDFan2551frViUPGQFaQQ+4Gq0kC Gppjfq9exZz2T8imGIgFqgPtViPQ/OXNtHiZuoQTq6DuVPljMq7t7iq5QQPQcG0Gz51o lSa9MwMSuXqHxf06XpMR/IVcSrrfngKJkbkGizWYohgZzjz3PcdqKf7clUM6zyMbsKeD YqvQ== MIME-Version: 1.0 X-Received: by 10.224.10.198 with SMTP id q6mr1001118qaq.55.1411490486782; Tue, 23 Sep 2014 09:41:26 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.140.95.232 with HTTP; Tue, 23 Sep 2014 09:41:26 -0700 (PDT) Date: Tue, 23 Sep 2014 12:41:26 -0400 X-Google-Sender-Auth: 9jghyYTin0VCO0GZKfMkaWeci28 Message-ID: From: Phillip Hallam-Baker To: endymail Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/GlfHEeqqhclm5JhBugtPL91dImc Subject: [Endymail] Could we converge on one message format? 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, 23 Sep 2014 16:41:29 -0000 At the moment we have S/MIME, PGP and PGP/MIME bindings. None is completely satisfactory as implemented in the running code. All the formats pass the subject header in the clear for a start. PGP is highly unsatisfactory as it does not support attachments and PGP/MIME addresses that problem in theory but does not have all the testing S/MIME has. Is it possible we could converge on one message format that would be adopted as the common spec for future implementations? The reason I am raising this is that right now some folk are working on WebMail that is end to end. And surprising as it might seem, it is quite practical to have end-to-end WebMail. We do have to extend the Web specs however. If we make a decision now, it could potentially be a point of convergence. The email world has adopted HTML from the Web, they will pull in a message format. BUT only if they can do that in a straightforward way and whatever message format is chosen supports PKIX keying and attachments. Right/wrong track? From nobody Sun Sep 28 07:59: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 E7CB51A1AF8 for ; Sun, 28 Sep 2014 07:59:12 -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 FPUtvl9gZ3k1 for ; Sun, 28 Sep 2014 07:59:09 -0700 (PDT) Received: from mail-pd0-f179.google.com (mail-pd0-f179.google.com [209.85.192.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D1D71A1AEB for ; Sun, 28 Sep 2014 07:59:08 -0700 (PDT) Received: by mail-pd0-f179.google.com with SMTP id r10so1137500pdi.24 for ; Sun, 28 Sep 2014 07:59:08 -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=rBPPO54xEpHu+AvCfZjo/Rt76jj9kRp/KrOspBOjpQ8=; b=O6ug0U/w+Ewz6oWnAtIgkDhDP8cNQdeDCaCF18fi1+Nj8eFBNqXY8XD6EEzqJPPZYZ bSAuLC0Ui3RB291pWIXu+DZftVFI5bstFUo92Yqxv1/qNtBzq2XcMjR1hL8UYISQ50Ji q3HhKyGMNB0ILCnelSx51KBW4J0R5pmSV1HcsK8FgzhIhA9IEerhCZIqTXLRWVEhjfR2 koFcyfTUwTRPuaNOYJxslZqCCAE006tawLueGQ0tkzisvHieVJV6/+XDBl9rA5cV/oW0 okwx5OYS5bd4AXq7gXaODpI6pcLmepcqWgd9or04/ONk/qoaWaT1yKNPnN30PamWNi9A rK5g== X-Gm-Message-State: ALoCoQkOByq4oG4iVn5FzVlXHb4ZMUjeY+Ik/Ri0bRTj07ToyHkwKRPm4VxfqJq6ZoNRgutmsYgz X-Received: by 10.66.90.137 with SMTP id bw9mr51125720pab.7.1411916348480; Sun, 28 Sep 2014 07:59:08 -0700 (PDT) Received: from vegoda.org ([2605:e000:5903:f500:d3c:fb74:4971:419c]) by mx.google.com with ESMTPSA id uf6sm10025531pac.16.2014.09.28.07.59.06 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 28 Sep 2014 07:59:07 -0700 (PDT) Date: Sun, 28 Sep 2014 07:59:04 -0700 From: Leo Vegoda To: Phillip Hallam-Baker Message-ID: <20140928145904.GB3548@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.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/YBe3PL9kmKjzn6oPpvQLN3cZdok Cc: endymail Subject: Re: [Endymail] How an endymail eco-system might incorporate web of trust features 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: Sun, 28 Sep 2014 14:59:14 -0000 Hi Phillip, On Thu, Sep 04, 2014 at 12:51:27PM -0400, Phillip Hallam-Baker wrote: [...] > First off, I assume that each participant has at least one personal > PKI which for the purposes of this discussion we can consider to last > their lifetime. Does this mean that each person needs to create a key that will remain cryptographically secure for the duration of their life? Is it practcal to expect a key created today to be cryptographically secure in 2074? Separately, how practical is it to expect non-geeks to keep their private key safe but accessible when necessary for multiple decades? Regards, Leo From nobody Sun Sep 28 08:21:52 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 03EFB1A1B20 for ; Sun, 28 Sep 2014 08:21:50 -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 Vb3uqvg7F2D5 for ; Sun, 28 Sep 2014 08:21:48 -0700 (PDT) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DE9B1A1B1E for ; Sun, 28 Sep 2014 08:21:48 -0700 (PDT) Received: by mail-la0-f42.google.com with SMTP id mk6so451416lab.15 for ; Sun, 28 Sep 2014 08:21:46 -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=fW7tl49wdlmi2BiuSfHqhETIBr4FPhe9uj25V5XXVFw=; b=MCok6YWAyivLXeR7V7CqNfqzaUrv6IYdwM258Ql5sRNPL6nqp9dYCZ+lWWs4LS8rzB 49G/m7E3isR4AyctMc1j0sZ0YgZ4/zcgqmbofzz/s4f8pwfTVgSMDDesBvNlxqg4ZCIs nYnb7C2jl4CRb6lwXf22NheCaRfLLYCQ6zjY30D0h7GWJSkF0nlAK/RC5KTvz61ekFxR UQpduSq2oYqj9L1pEbsaUwtx2BjlE7PfWKIiWFsOYIjHnwyDX1AOCfq0mNIotEWymSba 3Mek5hCZJMqOBcW3t2pBI/jqCTcQF0uwi/mD0pKAmMYBnvlTQa+lXWIDTAjLj/YBVTaK ohaQ== MIME-Version: 1.0 X-Received: by 10.112.171.202 with SMTP id aw10mr31140451lbc.52.1411917706625; Sun, 28 Sep 2014 08:21:46 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.122.14 with HTTP; Sun, 28 Sep 2014 08:21:46 -0700 (PDT) In-Reply-To: <20140928145904.GB3548@vegoda.org> References: <20140928145904.GB3548@vegoda.org> Date: Sun, 28 Sep 2014 11:21:46 -0400 X-Google-Sender-Auth: YRbQVe56cEtvXxDg7JkLwmT6jhE 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/ZRa-4q8XRuWbbGaY-yOXoiSqSWs Cc: endymail Subject: Re: [Endymail] How an endymail eco-system might incorporate web of trust features 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: Sun, 28 Sep 2014 15:21:50 -0000 On Sun, Sep 28, 2014 at 10:59 AM, Leo Vegoda wrote: > Hi Phillip, > > On Thu, Sep 04, 2014 at 12:51:27PM -0400, Phillip Hallam-Baker wrote: > > [...] > >> First off, I assume that each participant has at least one personal >> PKI which for the purposes of this discussion we can consider to last >> their lifetime. > > Does this mean that each person needs to create a key that will > remain cryptographically secure for the duration of their life? Is > it practcal to expect a key created today to be cryptographically > secure in 2074? No, the expectation is not that the key will be secure lifelong. The point is that the architecture does not assume that problems can be solved by waiting for it to expire. Assuming email certs expire annually really sweeps most of the hard problems under the rug while making the system unusable. Obviously, there has to be a key succession scheme. But checkpointing the keys in a Trans like architecture allows a lot of problems to be avoided. The transition scheme would be something like, generate the new stronger key, sign it with the old, get the transition statement notarized in the Big Log. > Separately, how practical is it to expect non-geeks to keep their > private key safe but accessible when necessary for multiple decades? Quite practical if the problem is posed in that way. First, lets reduce the problem by encrypting the private key and storing it in the cloud. Now all we need to do is to manage the decryption key, which is a lot fewer bytes. We can print that out on paper. We can do key splitting into 2 shares or 3 of 5 or whatever. The part I have not worked out yet is how to manage escrow of decryption keys. Which is an essential requirement that is in conflict with other requirements. It is easy enough to make a scheme escrowed or escrow free. What is hard is to allow the user to easily choose between them. From nobody Mon Sep 29 05:56:41 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 63FBB1A1BD7 for ; Mon, 29 Sep 2014 05:56:25 -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 FlCPSkSxmy4t for ; Mon, 29 Sep 2014 05:56:16 -0700 (PDT) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 938401A872A for ; Mon, 29 Sep 2014 05:56:16 -0700 (PDT) Received: by mail-oi0-f44.google.com with SMTP id x69so1697550oia.31 for ; Mon, 29 Sep 2014 05:56:16 -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=el3JU0+LxLQWGxgED+hmpck7G0U7CsaIoRcEewf8T3s=; b=d3ZSIzMgwjTPQ/YUXnIh3WSy+5Ffifb6rwD2cElph60NAP1MnBc2c7Sxw1Db6ZJCzm X/ng0w6jBYYQ17DOD1iYMHp8GMaZDsukFul7/+F9kE1RKYhUHZsuXGaB4VPQ+dgFYqQl IeUAV2IfNXcrdmVYzpEJKeOpA77Il1yKDWhjFs2cFRY7NUbino1qlwIpAFUcrKqGrSKx hJ52+01NrRrgmZ2fVm3wBtRQt0KpzQ65JiFGWiuEo2/46TpI99wl4IrjH4uNjTelMiXx UJOKuoprMvHh2t49qYlbX/kFbpmwbPFkVK4jE/PznLJ11Kky27yy6UvgCArDP1dYLZwv awCQ== MIME-Version: 1.0 X-Received: by 10.182.29.101 with SMTP id j5mr40037006obh.20.1411995375988; Mon, 29 Sep 2014 05:56:15 -0700 (PDT) Received: by 10.182.66.137 with HTTP; Mon, 29 Sep 2014 05:56:15 -0700 (PDT) Received: by 10.182.66.137 with HTTP; Mon, 29 Sep 2014 05:56:15 -0700 (PDT) In-Reply-To: References: <20140928145904.GB3548@vegoda.org> Date: Mon, 29 Sep 2014 14:56:15 +0200 Message-ID: From: Natanael To: Phillip Hallam-Baker Content-Type: multipart/alternative; boundary=001a11c200cacf7e67050433caf1 Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/GHp82sMak8-NfqwLsgrtcBVLU-E Cc: Leo Vegoda , endymail Subject: Re: [Endymail] How an endymail eco-system might incorporate web of trust features 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, 29 Sep 2014 12:56:26 -0000 --001a11c200cacf7e67050433caf1 Content-Type: text/plain; charset=UTF-8 Den 28 sep 2014 17:21 skrev "Phillip Hallam-Baker" : > > The part I have not worked out yet is how to manage escrow of > decryption keys. Which is an essential requirement that is in conflict > with other requirements. It is easy enough to make a scheme escrowed > or escrow free. What is hard is to allow the user to easily choose > between them. Don't escrow private key material. Allow for specification of which entities that have the authority to declare a new key as the successor of your previous one, and conditions such as n-of-m chosen entities is required and that the declaration must be put in that Big Log. I've got a bunch of other ideas of this kind I'm going to write down in a long email to these crypto related lists soon-ish. --001a11c200cacf7e67050433caf1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Den 28 sep 2014 17:21 skrev "Phillip Hallam-Baker"= <phill@hallambaker.com>= :
>
> The part I have not worked out yet is how to manage escrow of
> decryption keys. Which is an essential requirement that is in conflict=
> with other requirements. It is easy enough to make a scheme escrowed > or escrow free. What is hard is to allow the user to easily choose
> between them.

Don't escrow private key material. Allow for specificati= on of which entities that have the authority to declare a new key as the su= ccessor of your previous one, and conditions such as n-of-m chosen entities= is required and that the declaration must be put in that Big Log.

I've got a bunch of other ideas of this kind I'm goi= ng to write down in a long email to these crypto related lists soon-ish. --001a11c200cacf7e67050433caf1-- From nobody Mon Sep 29 06:09:17 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 4E3EC1A1BA9 for ; Mon, 29 Sep 2014 06:09:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.678 X-Spam-Level: X-Spam-Status: No, score=-0.678 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, J_CHICKENPOX_12=0.6, 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 kGSVQGqJLapB for ; Mon, 29 Sep 2014 06:09:04 -0700 (PDT) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4E231A0371 for ; Mon, 29 Sep 2014 06:09:03 -0700 (PDT) Received: by mail-la0-f42.google.com with SMTP id mk6so1700941lab.29 for ; Mon, 29 Sep 2014 06:09: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=hOyTYdwvhBLfXd1u3l8cTaCCpqrTCw0HvJIRUv+tMYA=; b=iJErbp+TfiS9xQ9J3S2F7AQYUOvpsutTvm0lvaUd2Uiim+OkIOYjGD3fQ0m+rC9t/F t8m5tXBWHEQMaoFQmLgdkwTO2O5SEQeGXz3PU3MESOTnGF9uUdEjiBkr1imstsQz6j4X D7F07RRt2d3l7Vwyn4iGxTNGs0n0e3s7DjoUHZgvlR8TADJoOwvMMdYUULwRAv9f5qFE cgk8oFBuR3FvCM7OZWPJdCtcztTyYCxRtshjEllAXFWY/1yHoReJ7mgF5yr/DRUxcLx2 blw6hTLgL9YANOnaLqGA1zT0Ual0bJBEl7Jq8CiMp0YKxSr9bmalShXNv2n5R2WeLmum gSrg== MIME-Version: 1.0 X-Received: by 10.152.19.225 with SMTP id i1mr39371883lae.21.1411996142026; Mon, 29 Sep 2014 06:09:02 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.122.14 with HTTP; Mon, 29 Sep 2014 06:09:01 -0700 (PDT) In-Reply-To: References: <20140928145904.GB3548@vegoda.org> Date: Mon, 29 Sep 2014 09:09:01 -0400 X-Google-Sender-Auth: 5uuFQYb2q7LyCOFBS3DLoepCFas Message-ID: From: Phillip Hallam-Baker To: Natanael Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/tlf8bYLbCPboZG5-d3CYy2F5fGM Cc: Leo Vegoda , endymail Subject: Re: [Endymail] How an endymail eco-system might incorporate web of trust features 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, 29 Sep 2014 13:09:05 -0000 On Mon, Sep 29, 2014 at 8:56 AM, Natanael wrote: > Den 28 sep 2014 17:21 skrev "Phillip Hallam-Baker" : >> >> The part I have not worked out yet is how to manage escrow of >> decryption keys. Which is an essential requirement that is in conflict >> with other requirements. It is easy enough to make a scheme escrowed >> or escrow free. What is hard is to allow the user to easily choose >> between them. > > Don't escrow private key material. Allow for specification of which entities > that have the authority to declare a new key as the successor of your > previous one, and conditions such as n-of-m chosen entities is required and > that the declaration must be put in that Big Log. If you want regular people to use end to end encrypted email, the risk that they lose access to their data and their pics is vastly more serious than the risk of government intercept. What I did think of though was a scheme where the private keys are stored in a 'deniable' format. So lets say that we generate a key pair, ke, kd, an identifier I and recovery code R. We store pairs [I, E( kd, R)] in a hash database. to recover the data, the client presents I and gets back E(kd, R). We can form I at random or we can derive it from the recovery code I = H(R). Point is that we can't know whether or not kd is escrowed. It may be but it might not.