Re: [openpgp] Modernizing the OpenPGP Format draft

ianG <iang@iang.org> Mon, 02 November 2015 22:05 UTC

Return-Path: <iang@iang.org>
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 E0B171A888F for <openpgp@ietfa.amsl.com>; Mon, 2 Nov 2015 14:05:56 -0800 (PST)
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 497DjGHtQmxv for <openpgp@ietfa.amsl.com>; Mon, 2 Nov 2015 14:05:55 -0800 (PST)
Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 132211A8894 for <openpgp@ietf.org>; Mon, 2 Nov 2015 14:05:55 -0800 (PST)
Received: from tormenta.local (iang.org [209.197.106.187]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by virulha.pair.com (Postfix) with ESMTPSA id 784796D73D; Mon, 2 Nov 2015 17:05:53 -0500 (EST)
To: openpgp@ietf.org
References: <CALq76CJiL6r1RFvcW3P5UE2buH181bCMsTR4MCbQNVDuJotTfg@mail.gmail.com>
From: ianG <iang@iang.org>
Message-ID: <5637DE40.4080109@iang.org>
Date: Mon, 02 Nov 2015 22:05:52 +0000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <CALq76CJiL6r1RFvcW3P5UE2buH181bCMsTR4MCbQNVDuJotTfg@mail.gmail.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/openpgp/pzmXM-l4OYQA_3Q94aNft0eHm9Q>
Subject: Re: [openpgp] Modernizing the OpenPGP Format draft
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: <https://mailarchive.ietf.org/arch/browse/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: Mon, 02 Nov 2015 22:05:57 -0000

Excellent start!

On 31/10/2015 08:50 am, Bryan Ford wrote:
> Title: Modernizing the OpenPGP Message Format
> URL: https://datatracker.ietf.org/doc/draft-ford-openpgp-format/
> Abstract:
>     This draft proposes and solicits discussion on methods of modernizing
>     OpenPGP's encrypted message format to support more state-of-the-art
>     authenticated encryption schemes, and optionally to protect format
>     metadata as well as data via metadata encryption and judicious
>     padding.


I object to the use of the word "identity" in the text.  Wrong layer. 
I'd suggest either integrity or authentication?

I like the absolute separation of the the AEAD Protected Data packet - 
makes it easier to squash all the old stuff.

"additional data" == 0.  I'm fine with that.

nonce as 0 for non-reuse - disagree.  I would strongly prefer the nonce 
to always be there and always be randomly generated by requirement, 
because we can't trust the rest of the software.  Multiple, redundant 
protections are great when they are free.  Which they are in this case. 
  Nonce to be always present, big and random, and the secret key should 
not be re-used.


2.2 looks great!  Never heard of MonkeyDunkey but happy to endorse it 
sight unseen ;-)


> It covers two topics, the first being the AEAD evolution, the second
> being a somewhat more ambitious idea to provide better metadata
> protection and anonymization properties at the "outer-wrapper" level;
> see the draft for (some more, still sketchy) details.


2.3 also good, I'm very keen on that. The "bucket expansion" scheme is 
likely to signal which tool was used, unless we can convince other 
packages to do that (pretty unlikely).



iang