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.​