Re: Scope for self-destructing email?
Phillip Hallam-Baker <phill@hallambaker.com> Thu, 17 August 2017 03:21 UTC
Return-Path: <hallam@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AF3413245C for <ietf@ietfa.amsl.com>; Wed, 16 Aug 2017 20:21:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.398
X-Spam-Level:
X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nyd0vMTOR1Uk for <ietf@ietfa.amsl.com>; Wed, 16 Aug 2017 20:21:55 -0700 (PDT)
Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47E4213208E for <ietf@ietf.org>; Wed, 16 Aug 2017 20:21:55 -0700 (PDT)
Received: by mail-lf0-x22d.google.com with SMTP id d17so24211341lfe.0 for <ietf@ietf.org>; Wed, 16 Aug 2017 20:21:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to; bh=GlhtzllWNVntDbEi3v+88GgDhgyqsYLKGA1joGsagSo=; b=PybQSYKP7YaAs5Q3qpAt54xhHlsaNKWFbhcw5UKkCAEmdgxHZLqBYM6Py1ORBlkYw5 eSdIKeWpoYQJ/KO0IkZrtxSh3KClldmejz1Kg/HxF6dd/skikZ8xr2KKQeziCZO+7kaq +WFVz/7CnLHJhaCDlqmEXSmVpXgcj2ZgsAiUK49xd12/qV7nQbsZYU5JxpjRVWMU37z3 7k7ZSTdhmyasCowsVL2y3MeAxIx33uub+Y1XTeF+HQcUmVRBtcEoWbHr6cmEYBqf6NsV 0UaPbTJQuRI9SKPkyOkteWRrP6/OgAmeqwLYxveKTYnU9Gkk6UqYFR9tXzt98S9ElWz5 ZqNA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to; bh=GlhtzllWNVntDbEi3v+88GgDhgyqsYLKGA1joGsagSo=; b=UHALn5voXSPe85SKPnSKeuAEx1fqoJGMXQGlNyVNDKuuodLsn5TQp6wXSSZpHaTWxY w5yxYDGp9U23sBzs32Sa/cfCa7JL74BMWI61uMGZxpWLlTO768/sgNjEulz+Erfri1j1 0drHCdiGVVumP6ouYdTjUmHZhiHxL2NaVslr4kMfNoJbgRyyCETniSACqws9o9Jssn0S str/vZZVdNdNCTYcxanL9ulhJKA3qZybnhyeyuwHMYherANgb4IrhR38y8whmGzctQIp G/zsSChMy6TN5cOiNkQW0scRR+CRosywls2N6FQBmVmFdeGpu+ex5SAc03oEQz9IcFVE 22Zw==
X-Gm-Message-State: AHYfb5gB3Xq8bQvkvbiLQdhMl6iZA4HlWj6SUVWSTIIxvzQaoWYxA7pw wgHKYHrusVgGhv7aPrvYfcF5j03zfHlG
X-Received: by 10.25.150.130 with SMTP id y124mr1450199lfd.202.1502940113289; Wed, 16 Aug 2017 20:21:53 -0700 (PDT)
MIME-Version: 1.0
Sender: hallam@gmail.com
Received: by 10.25.142.199 with HTTP; Wed, 16 Aug 2017 20:21:52 -0700 (PDT)
In-Reply-To: <39610B4F-8DE6-4E19-A6C8-5FAB882DD524@orthanc.ca>
References: <20170816225637.4431.qmail@ary.lan> <7352544b-8626-fb30-b74f-48b62110b7cf@gmail.com> <39610B4F-8DE6-4E19-A6C8-5FAB882DD524@orthanc.ca>
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Wed, 16 Aug 2017 23:21:52 -0400
X-Google-Sender-Auth: DagK_cQsxmjN1N_CiCvS3FmcFqY
Message-ID: <CAMm+LwgqnPx2VBaoaWuU_YW547oRhQDTo48t4BokcwKqRSO+bw@mail.gmail.com>
Subject: Re: Scope for self-destructing email?
To: IETF Discussion Mailing List <ietf@ietf.org>
Content-Type: multipart/alternative; boundary="001a114025a69247280556ea8348"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/Lx0vJ_nWGm-OiUqweNgtCc-30pk>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Aug 2017 03:21:58 -0000
This is a problem I have been considering for some time. And everyone in this thread is right. Right on the facts at least. Most are wrong on the implications. When the Web was launched in 1992, it was dismissed by the network hypertext crowd because it did not solve the problem of referential transparency that Ted Nelson insisted was really really important. It was not, the Web worked fine with 404 not found. In fact it didn't work fine, it worked *better*. It was this insight that led me to propose Confidential Document Control (CDC) as a subset of the Digital Rights Management (DRM) Problem. I have a draft if you are interested in the math or just like looking at the pretty SVG pictures we can use in HTML: http://prismproof.org/Documents/draft-hallambaker-mesh-recrypt.html What I realized was that there are two difficult problems in the DRM problem: 1) Restricting initial distribution of confidential data to the set of authorized parties. 2) Preventing disclosure by authorized parties to others. These are both challenging technical problems that cannot be solved with the cryptographic toolset used in OpenPGP and S/MIME. Mesh/Recrypt addresses the first. It uses cryptography that can be understood by high school students but it is cryptography that nobody had worked out how to apply in practice that way until now[1]. Solving the first problem really wasn't impossible. I am pretty sure that many others could have done what I have. But I rather suspect the reason they did not is that the whole field of DRM has been poisoned by two facts: 1) Preventing disclosure by authorized parties to others requires the use of trustworthy hardware and no hardware is 100% trustworthy. 2) The whole field of DRM has been poisoned by anti-copyright enforcement ideology. The problem that began this thread, 'burn after 24 hours' is simply another type of attribute describing a restriction we wish to enforce on the use of the document. At the moment, Mesh/Recrypt is deliberately limited to solving only the first part of the CRM problem. It only addresses the initial distribution of the documents. This is the subset I call Confidential Document Control. One reason for this limitation is that authorization policy languages is a whole different patent minefield to navigate. But the other is that I get 95% of the value of a full DRM system with just my CDC component. Consider recent US government breaches: * Did Snowden need to read any of the Powerpoint files? * Did Chelsea Manning need to have access to 250,000 cables? * Did everyone working in the CIA need access to the website with the malware tools? * Should the Secretary of State have reasonably considered the GSA mail services secure when it is likely thousands of personnel and contractors had access to them? When we drill down, the number of leaks by a person with a need to know the material in question is a tiny fraction of the people who have access today. Without a practical, standards based means of performing data level encryption, the leaks are going to continue. It is the same in the enterprise. While it is possible that the criminal gangs that attacked HBO to leak Game of Thrones did so by suborning an insider, it is vastly more likely that they compromised a machine on the corporate network and leveraged it. CDC rather than full DRM would almost certainly have been sufficient. So what then of DRM? Am I saying it has absolutely no use? Absolutely not. Because security is risk control, not risk elimination. It is not necessary to provide an absolute guarantee that the data will not leak in any possible circumstance to provide value. Trustworthy hardware does not need to be 100% trustworthy to provide useful risk control in the enterprise. In fact, there is only one area in which DRM has to be 100% and that is copyright enforcement and that is because it is break once run anywhere. So I can certainly help HBO stop their shows leaking before show date but I am not going to promise anything after they have shared their secret with ten million of their closest friends. For early adopter purposes, the hardware used to distribute material need not be any more trustworthy than an iPad Pro. Of course you or I or any number of folk could probably work out how to bypass that level of security given physical access to the device. But the fact is that what most people want is for the machine to help them not leak stuff accidentally. They have absolutely no intention of jailbreaking their corporate phone or tablet. So here is what I propose. Let us start this journey by working on a solution to the CDC part of the problem. Which will take us some time. Solving the CDC problem is a subset of the enterprise DRM problem. And if we win, then its like pinball - you win, you get to play again. Adding a security policy language to describe permitted uses is a trivial engineering task. The hard part would be the prior art search. PHB [1] Well I hope this is the case as I am going to be doing just that later this year.
- Scope for self-destructing email? vaibhav singh
- Re: Scope for self-destructing email? Matthias Merkel
- Re: Scope for self-destructing email? Dave Cridland
- Re: Scope for self-destructing email? Matthias Merkel
- Re: Scope for self-destructing email? Matthew Pounsett
- Re: Scope for self-destructing email? Warren Kumari
- Re: Scope for self-destructing email? Matthias Merkel
- Re: Scope for self-destructing email? Randy Presuhn
- Re: Scope for self-destructing email? Martin Rex
- Re: Scope for self-destructing email? Brian E Carpenter
- Re: Scope for self-destructing email? John C Klensin
- Re: Scope for self-destructing email? John Levine
- Re: Scope for self-destructing email? joel jaeggli
- RE: Scope for self-destructing email? Michel Py
- Re: Scope for self-destructing email? John Levine
- Re: Scope for self-destructing email? Theodore V Faber
- Re: Scope for self-destructing email? vaibhav singh
- Re: Scope for self-destructing email? Ted Hardie
- Re: Scope for self-destructing email? Matthias Merkel
- Re: Scope for self-destructing email? John C Klensin
- Re: Scope for self-destructing email? Matthias Merkel
- Re: Scope for self-destructing email? John C Klensin
- Re: Scope for self-destructing email? Warren Kumari
- Re: Scope for self-destructing email? Ted Hardie
- Re: Scope for self-destructing email? Brian E Carpenter
- Re: Scope for self-destructing email? Lyndon Nerenberg
- Re: Scope for self-destructing email? Phillip Hallam-Baker
- Re: Scope for self-destructing email? Deen, Glenn (NBCUniversal)
- Re: Scope for self-destructing email? Phillip Hallam-Baker
- Re: Scope for self-destructing email? Christian Huitema
- Re: Scope for self-destructing email? Gary E. Miller
- Re: Scope for self-destructing email? Michael Richardson
- Re: Scope for self-destructing email? John C Klensin
- Re: Scope for self-destructing email? Phillip Hallam-Baker
- Re: Scope for self-destructing email? John Levine
- Re: Scope for self-destructing email? ned+ietf
- Re: Scope for self-destructing email? Adam Roach
- Re: Scope for self-destructing email? Phillip Hallam-Baker
- Re: Scope for self-destructing email? Phillip Hallam-Baker
- Re: Scope for self-destructing email? John R Levine
- Re: Scope for self-destructing email? Toerless Eckert
- Re: Scope for self-destructing email? Lloyd Wood
- Email client APIs. features. amd siupport (was: R… John C Klensin
- Re: Email client APIs. features. amd siupport (wa… Toerless Eckert
- Re: Email client APIs. features. amd siupport (wa… Phillip Hallam-Baker