[openpgp] Option 4: Requirements vs. Solutions.

Phillip Hallam-Baker <phill@hallambaker.com> Thu, 02 April 2015 18:26 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: openpgp@ietfa.amsl.com
Delivered-To: openpgp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 048D81A0191 for <openpgp@ietfa.amsl.com>; Thu, 2 Apr 2015 11:26:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.122
X-Spam-Level:
X-Spam-Status: No, score=0.122 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 q5KkGUV7bf16 for <openpgp@ietfa.amsl.com>; Thu, 2 Apr 2015 11:26:31 -0700 (PDT)
Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) (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 7292B1A0092 for <openpgp@ietf.org>; Thu, 2 Apr 2015 11:26:31 -0700 (PDT)
Received: by lbdc10 with SMTP id c10so65205040lbd.2 for <openpgp@ietf.org>; Thu, 02 Apr 2015 11:26:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type; bh=RpENStnYWAdVcw71izJERMqG3WNlY3F4aAV9dLbXNaU=; b=rBppcp3CtNZdIbAuQlmeTx3HAA43JfaEvAZPIJAlYm2mDq27Le0D9K5A1RiGuyyT/2 zBUlCnKMCWfgdEjXO/BctFbRiO5EE+qd1O4V6Dte40Z9TuASQnNy0wQo+uJ6UVg+bAex hOcZiJUHYALk26Ff0B0F9UgDNG6qPjiYJOhEryZ3ztYsv+mXAdWAB2G1FwVcdVKb/Ul+ LX/zEw/ubzPzkBLA4eEWJGMY9Za+ftXgJN6FUowgEDp0cU9c4Fw8SWofcwNRpetf+rfM /NyHfGb0rKIMtzgsVKuXURHtwFec/fM9NNLvZtaIG9UWW7JOWulQtEhZ0sG5V/Rqhydr QOdQ==
MIME-Version: 1.0
X-Received: by 10.152.18.225 with SMTP id z1mr42526528lad.124.1427999189786; Thu, 02 Apr 2015 11:26:29 -0700 (PDT)
Sender: hallam@gmail.com
Received: by 10.112.147.165 with HTTP; Thu, 2 Apr 2015 11:26:29 -0700 (PDT)
Date: Thu, 02 Apr 2015 14:26:29 -0400
X-Google-Sender-Auth: 7PC6UCFcloXsCWMq5T1iWy_rnz8
Message-ID: <CAMm+Lwg2B=8+9qnDwbzGNJ8M5R9M2XMNhdyXT_24QZ-f+8jVfw@mail.gmail.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
To: ianG <iang@iang.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/openpgp/g8NKkrPe2DyY-mfmpWw77TpE2XE>
Cc: IETF OpenPGP <openpgp@ietf.org>
Subject: [openpgp] Option 4: Requirements vs. Solutions.
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <openpgp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/openpgp>, <mailto:openpgp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/openpgp/>
List-Post: <mailto:openpgp@ietf.org>
List-Help: <mailto:openpgp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/openpgp>, <mailto:openpgp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Apr 2015 18:26:33 -0000

On Thu, Apr 2, 2015 at 1:55 PM, ianG <iang@iang.org> wrote:
> On 26/03/2015 03:56 am, Phillip Hallam-Baker wrote:

> Storage has changed:  we no longer consider a message over the wire as the
> same thing as a message at rest on disk.  We do/don't keep video chat, we
> do/don't take naughty snaps using screen shots.  We do/don't share huge
> files (movies) for which OpenPGP is entirely unsuited because it assumes
> everything is a datagram, and 16G datagrams aren't supported by any other
> software.

OK, so lets agree to a distinction here between requirements and
solutions when it comes to scope.

Contrary to what most folk accuse me of, I am very focused when it
comes to solutions. Where I insist on a broad scope is when we
consider requirements.

So I don't want to work on design of a start from scratch messaging
infrastructure in PGPvNext. However I do want PGPvNext to support the
type of requirements that sort of work might anticipate. I find it
really annoying when someone says 'there is no difference between
options A and B, my friends and I prefer A so thats what we will do'
and then when I point out that there are actually a lot of differences
between the two because A can't support a large number of use cases
that B does. Then they say "well those are not in scope".

All requirements are always in scope as far as I am concerned. I might
not be able to meet all of them. But having them on the table helps
thinking about the problem at the right level of abstraction.


So I don't want to do a protocol that combines push email (SMTP) with
pull (e.g. dropbox) for a couple of years so certain patents expire
(among other reasons). Or add real time video messaging, jabber etc.
But I would like to make sure we don't foreclose the option. In
particular I would like to see:

* Convergence on JSON as the data model and JSON based encoding.
* Data formats that handle very large chunks of data
* Data formats that support real time streaming

By large chunks of data, I mean Terabytes and up. If protocol
convergence is achieved, I should be able to transfer the contents of
my RAID-6 NAS with 4x6Tb drives by emailing them to its successor.

I don't propose that we design such a protocol now. Unless you are
living in one of the six houses served by the Google 100Gbs Ethernet
you are going to be waiting a long time for ten Tb to move. But I do
know folk at CERN who already have that size of problem and it won't
be long before it does become relevant.


> Evidence has changed:  we do/don't keep transcripts around for evidence.  We
> do/don't think of digsigs as human signatures.  We do/don't worry about
> removal of files.  We do/don't consider the wire to be a threat and we
> do/don't consider our counterparty to be a threat.

Looking at the current state of the art for collecting and maintaining
digital evidence, I am appalled. The requirements for criminal cases
are poor and the requirements for civil are practically non existent.