Re: [openpgp] AEAD Chunk Size

Tobias Mueller <muelli@cryptobitch.de> Sun, 03 March 2019 18:36 UTC

Return-Path: <muelli@cryptobitch.de>
X-Original-To: openpgp@ietfa.amsl.com
Delivered-To: openpgp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BD14128CF3 for <openpgp@ietfa.amsl.com>; Sun, 3 Mar 2019 10:36:14 -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 autolearn_force=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 MUd5mhy86_m4 for <openpgp@ietfa.amsl.com>; Sun, 3 Mar 2019 10:36:12 -0800 (PST)
Received: from bitbox.cryptobit.ch (cryptobit.ch [188.40.138.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57E5F130DE7 for <openpgp@ietf.org>; Sun, 3 Mar 2019 10:36:12 -0800 (PST)
Received: from unibox (p5B0F56A4.dip0.t-ipconnect.de [91.15.86.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail.cryptobit.ch (Postfix) with ESMTPSA id 44CBgX5W03z12jXm; Sun, 3 Mar 2019 19:36:08 +0100 (CET)
Message-ID: <2a014c4a103ba7f52535546f7e77277ea2bdabdf.camel@cryptobitch.de>
From: Tobias Mueller <muelli@cryptobitch.de>
To: "Neal H. Walfield" <neal@walfield.org>, Jon Callas <joncallas@icloud.com>
Cc: Bart Butler <bartbutler@protonmail.com>, "openpgp@ietf.org" <openpgp@ietf.org>, Vincent Breitmoser <look@my.amazin.horse>
Date: Sun, 03 Mar 2019 19:36:08 +0100
In-Reply-To: <87r2brf0f1.wl-neal@walfield.org>
References: <87mumh33nc.wl-neal@walfield.org> <F9VLV9HZWH.3RYL3UM3BN873@my.amazin.horse> <3WZ7-hy9V7TOy53p1gP5EXELzHJIqjouV9x0YTN3PWsBZedKkqvVCRm-2XzGZy-FYAYdTqP1-7YV4wbTWMWAYhSujQA6NmrnIuXfZLRHkdQ=@protonmail.com> <CAB941EE-6961-4CAB-9632-DFF738980467@icloud.com> <87h8co2t4v.wl-neal@walfield.org> <35C892F7-18A8-401E-828D-5CE180A3A731@icloud.com> <87r2brf0f1.wl-neal@walfield.org>
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.28.5-0ubuntu0.18.04.1
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/-9zfg3Ngk6yFPZB17gq65MonKKA>
Subject: Re: [openpgp] AEAD Chunk Size
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.29
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: Sun, 03 Mar 2019 18:36:15 -0000

Hi,

On Fri, 2019-03-01 at 09:45 +0100, Neal H. Walfield wrote:
> I think that security concerns should be our first priority.  And, any
> flexibility increases our bug potential.  As such, I'm not convinced
> that we shouldn't use a fixed chunk size.

Note that introducing "chunks" diverts from authenticated encryption and
increases the bug potential.  That is, an implementation may more easily
release plaintext although the ciphertext has been modified.
The AE mode is OpenPGP's chance to become a protocol which enjoys the
strong security guarantees of AE and catch up with S/MIME.

By fixing a "chunk size" you take away the ability to benefit from AE
for messages bigger than that size.
Implementations could easily collect all chunks and only release the
plaintext once all chunks check out successfully. But that could go
wrong. And depending on implementations to get things right and clients
to use those implementations correctly is exactly what enabled Efail to
become an issue. I think it'd be much nicer if the protocol already
ensures that my emails do indeed enjoy protection against modification
rather than me having to rely too much on clients getting it right.

Having said that, I understand the desire for fixing a chunk size to
reduce complexity for implementers.  My desire as a user is to have a
strong and resilient protocol.  As such I prefer producing messages that
enjoy strong protection against modification.  That includes my emails
or backups larger than 16kB, 256kB, or whatever size you come up with.

Is there another way to do real AE?


Cheers,
  Tobi