Re: [openpgp] Intent to deprecate: Insecure primitives

Phillip Hallam-Baker <phill@hallambaker.com> Wed, 18 March 2015 13:36 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 856C11A0120 for <openpgp@ietfa.amsl.com>; Wed, 18 Mar 2015 06:36:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level:
X-Spam-Status: No, score=-1.277 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, HTML_MESSAGE=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 W90a1R217axf for <openpgp@ietfa.amsl.com>; Wed, 18 Mar 2015 06:36:51 -0700 (PDT)
Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) (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 6F9D81A00E0 for <openpgp@ietf.org>; Wed, 18 Mar 2015 06:36:51 -0700 (PDT)
Received: by lamx15 with SMTP id x15so36206206lam.3 for <openpgp@ietf.org>; Wed, 18 Mar 2015 06:36:49 -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=0HJzUXe2avLN8TmiAU+B07MwfoT9T4nxN0RJq65Gmtk=; b=vx7t0fuj7ifXiw8aOp3mhMpcyCxOHawkGnz+cC8HWu8I+do9WsktauAfnn0bbj8Usz XQtTec7DHkg1DNvtK0EADdUa6BCBRPmakt7RRq1XwHHcnk/aSOi1y82n1hB6uS8QfZ8I ugzLn8p2pb5WJVEZOiPd+DUfnE2IX6kbVQZWmSJSeBS3ir+F5AyB9XPyXUHq72kCtdUg 6sJdW6ID/iRVEUSgi9ProYk+7FBjlmaFPnMu20pWhXPNM0UtsN+QsVt87vGREeIQM33g 8YH6hTJ2oE1oP0WZTDrbP1XmOQUztSJ0xIEvS9vjMXNf+L4QR+nQZefW5M5x/TMX8MVm lGQw==
MIME-Version: 1.0
X-Received: by 10.153.6.35 with SMTP id cr3mr37358768lad.79.1426685809583; Wed, 18 Mar 2015 06:36:49 -0700 (PDT)
Sender: hallam@gmail.com
Received: by 10.112.45.203 with HTTP; Wed, 18 Mar 2015 06:36:49 -0700 (PDT)
In-Reply-To: <sjmmw3bk6lt.fsf@securerf.ihtfp.org>
References: <r422Ps-1075i-0DF0A0ED5D364ECAABA63F541D9C6A16@Williams-MacBook-Pro.local> <sjmmw3bk6lt.fsf@securerf.ihtfp.org>
Date: Wed, 18 Mar 2015 09:36:49 -0400
X-Google-Sender-Auth: 14i6nRjLLjzejf5U2yMmU-iZQzQ
Message-ID: <CAMm+Lwi5QBPn+2VZXvG+T59V9=d9HkOXhQJ9MGH_gxHyCfX86A@mail.gmail.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
To: Derek Atkins <warlord@mit.edu>
Content-Type: multipart/alternative; boundary=001a11349e2ce2eb570511902c59
Archived-At: <http://mailarchive.ietf.org/arch/msg/openpgp/7cJWih0d6WZhvHzBlfLAYbVOy8U>
Cc: dgil@yahoo-inc.com, Werner Koch <wk@gnupg.org>, IETF OpenPGP <openpgp@ietf.org>, David Leon Gil <coruus@gmail.com>, Bill Frantz <frantz@pwpconsult.com>
Subject: Re: [openpgp] Intent to deprecate: Insecure primitives
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: Wed, 18 Mar 2015 13:36:53 -0000

On Tue, Mar 17, 2015 at 11:04 AM, Derek Atkins <warlord@mit.edu> wrote:

> Bill Frantz <frantz@pwpconsult.com> writes:
>
> > On 3/16/15 at 6:51 AM, warlord@MIT.EDU (Derek Atkins) wrote:
> >
> >>Oh, you expected me to decrypt/re-encrypt my encrypted email as I got
> it???
> >
> > For many uses, decrypting from the wire format and re-encrypting in
> > the "data at rest" security format makes excellent sense. Having only
> > one encryption scheme for long-term storage allows easy (relatively)
> > upgrade and helps to ensure that the data is still accessible,
> > i.e. the decryption still works. I probably have a bunch of old PGP
> > encrypted email I can't read anymore because I don't have the secret
> > key, or its passphrase. If that mail had been re-encrypted in a format
> > that I decrypt every day, I would still be able to read the
> > mail. Encryption that isn't regularly exercised gets rusty.
>
> Show me an MUA that does this, please?  None of the OpenPGP-aware MUAs
> I've ever used have this feature, as far as I know.  I suppose I could
> go out of my way to replace the encrypted email with a
> re-encrypted/plaintext email.
>
> But frankly I'd like my encryption software to just maintain the ability
> to decrypt it later.
>
> > Cheers - Bill
>
> -derek
>

The only thing I have seen done that is similar is re-signing documents
under a stronger signature key. But that is now obsolete since the
Harber-Stornetta patents expired and hash chain type schemes are possible.

We have considered the underlying problem quite a bit on the cryptography
list. There are many problems of key management. For example, do I want
people to be able to read some of my emails on death? In an enterprise
scenario, I don't want the bank to lose all the emails I sent to my broker
because she fell under a bus.

There are also many complicating factors. Phones get stolen or lost, etc.
etc.


This led me to an approach in which each user has a personal PKI hierarchy.
This is probably going to look excessive. But solving the use cases
requires every bit. If you want to be able to have some part of your
communications be proof against court warrants, you need more.

1) A personal offline key signing key. [R]
2) A personal offline recovery encryption key. [R]

3) A personal online key signing key with expiry ~ 10 years
4) A personal mail encryption key [R] that is rotated monthly and escrowed
under the personal offline recovery encryption key.

In addition each device has a personal message signing key and a key
distribution key that are unique to that device and never leave it.

So in PRISM-PROOF, the standard configuration begins with six keygens(!)

The keys marked [R] may have recovery support. To do this we encrypt the
message and store the bits in the cloud. This means we only need to escrow
the decryption key somehow. In the case of (1) and (2) this is done with
key shares printed out onto paper (and as QR codes). In the case of (4) the
key is escrowed under key (2).

Each key is wrapped in X.509. Yes, I hate it as much as anyone else. But
doing that allows me to use the keys in S/MIME and enroll them in TRANS
logs.


Yes, there is a lot of complexity. But the user does not see any of it. I
would rather have more code complexity than user experience complexity.

The user's fingerprint is the hash of (1) which is intended to be
potentially a life long master key. By which I mean that it should work for
a person's whole life though it is possible it might be superseded in
certain circumstances.


Now this is probably not something people want to be thinking about in
OpenPGP vNext. But it is something you might want to consider as a future
convergence possibility.