Re: [openpgp] The combinatorial complexity of OpenPGPv4

Derek Atkins <warlord@MIT.EDU> Tue, 17 March 2015 15:27 UTC

Return-Path: <derek@ihtfp.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 4FDD01A1BF3 for <openpgp@ietfa.amsl.com>; Tue, 17 Mar 2015 08:27:38 -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 d5Ux_aFPw1as for <openpgp@ietfa.amsl.com>; Tue, 17 Mar 2015 08:27:36 -0700 (PDT)
Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:4830:143:1::3a11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CE081A1B8B for <openpgp@ietf.org>; Tue, 17 Mar 2015 08:27:36 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 3E1EBE2039; Tue, 17 Mar 2015 11:27:35 -0400 (EDT)
Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 04074-01; Tue, 17 Mar 2015 11:27:32 -0400 (EDT)
Received: from securerf.ihtfp.org (unknown [IPv6:fe80::ea2a:eaff:fe7d:235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id 5F31FE2038; Tue, 17 Mar 2015 11:27:32 -0400 (EDT)
Received: (from warlord@localhost) by securerf.ihtfp.org (8.14.8/8.14.8/Submit) id t2HFRTgm027284; Tue, 17 Mar 2015 11:27:29 -0400
From: Derek Atkins <warlord@MIT.EDU>
To: David Leon Gil <coruus@gmail.com>
References: <55038CBE.7070608@iridiumlinux.org> <1160541985.95679.1426305437936.JavaMail.yahoo@mail.yahoo.com> <sjm3855m4r8.fsf@securerf.ihtfp.org> <CAA7UWsVocUNzUvK_oxSG8G6nq7s_qGhwZdewBnfmzQQpXcuAMw@mail.gmail.com>
Date: Tue, 17 Mar 2015 11:27:29 -0400
In-Reply-To: <CAA7UWsVocUNzUvK_oxSG8G6nq7s_qGhwZdewBnfmzQQpXcuAMw@mail.gmail.com> (David Leon Gil's message of "Mon, 16 Mar 2015 14:58:08 -0700")
Message-ID: <sjmbnjrk5jy.fsf@securerf.ihtfp.org>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Virus-Scanned: Maia Mailguard 1.0.2a
Archived-At: <http://mailarchive.ietf.org/arch/msg/openpgp/QgK-0c0TwAcEWP656FQ57N3Rckk>
Cc: David Gil <dgil@yahoo-inc.com>, "openpgp@ietf.org" <openpgp@ietf.org>, Falcon Darkstar Momot <falcon@iridiumlinux.org>
Subject: Re: [openpgp] The combinatorial complexity of OpenPGPv4
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: Tue, 17 Mar 2015 15:27:38 -0000

David Leon Gil <coruus@gmail.com> writes:

> On Monday, March 16, 2015, Derek Atkins <warlord@mit.edu> wrote:
[snip]
>     Having implemented it myself, I disagree completely.  It is absolutely
>     possible to create a modular implementation.  See my Usenix Security
>     Talk on the PGP Message Processing Pipeline from.... 1996??
>
> Well, first: You're Derek Atkins. Not everyone is as good of a coder.

*blush*

> Second: It is hard to *prove* modularity, because of how complicated the
> semantics are. (I have been trying, off-and-on, using Frama-C, for a while.)

Yes, the structure is complicated (my parser state machine had something
like 150-200 states).  But the processing itself is completely modular.
You just need concepts like split and join along the pipeline to handle
it.  Proof by existance?

>     [snip]
>     >> Protocol modularity is not evil.
>     >
>     > Modularity is neutral. "Agility", as folks like to call it, is evil.
>    
>     Well, it's a damn good thing we've had agility otherwise we'd have been
>     stuck with 3DES, SHA1 (or MD5!!), and probably either RSA or maybe
>     DSA/Elgamal.
>
> No: The reason there hasn't been any urgency to fix things like the CFB mode
> problems, or the MDC, is that the current standard is too flexible.

I don't agree with this statement.  It wasn't flexibility that stopped
changing CFB, it was that CTR mode was relatively new when the group was
working on 4880 (I'm not sure it even existed when we did 2440).  And
compatibility was always (generally) paramount.  I.e., if it ain't
completely broke let's not fix it..  and where it is broke, let's fix it
in the most compatible way.

Were I do start from scratch today then yes, I'd just use GCM.  We could
certainly add a GCM mode and a preference to specify support for it.
But for interop I don't think we could drop CFB support completely from
implementations.

I'll also point out that CFB vs "something else" (i.e., "mode agility")
is completely orthogonal to algorithm agility.  OpenPGP does NOT have
decent mode agility; we would need to add a new packet type for that.

> I hate to use TLS as an exemplar of anything, but they have done a much better
> job in this regard recently.
>
> Where it is easy to provide flexibility, it is rarely useful. Where it is
> useful, it is rarely feasible to provide. (E.g., a parameter to choose SIV,
> encrypt-then-MAC, or robust AE.)

It's easy to add it if you think about it ahead of time (and put in the
parameterization).  It's harder to add it after-the-fact.  This is true
in both TLS and OpenPGP.

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord@MIT.EDU                        PGP key available