Re: [openpgp] AEAD Chunk Size

"Neal H. Walfield" <neal@walfield.org> Thu, 28 February 2019 08:51 UTC

Return-Path: <neal@walfield.org>
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 5DD83130E66 for <openpgp@ietfa.amsl.com>; Thu, 28 Feb 2019 00:51:18 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable 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 rYaEl747VjlQ for <openpgp@ietfa.amsl.com>; Thu, 28 Feb 2019 00:51:16 -0800 (PST)
Received: from mail.dasr.de (mail.dasr.de [217.69.77.164]) (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 444B7130E89 for <openpgp@ietf.org>; Thu, 28 Feb 2019 00:51:16 -0800 (PST)
Received: from p54abd93f.dip0.t-ipconnect.de ([84.171.217.63] helo=grit.huenfield.org.walfield.org) by mail.dasr.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from <neal@walfield.org>) id 1gzHPN-0008GT-2d; Thu, 28 Feb 2019 08:51:13 +0000
Date: Thu, 28 Feb 2019 09:51:12 +0100
Message-ID: <87h8co2t4v.wl-neal@walfield.org>
From: "Neal H. Walfield" <neal@walfield.org>
To: Jon Callas <joncallas=40icloud.com@dmarc.ietf.org>
Cc: Bart Butler <bartbutler@protonmail.com>, "openpgp@ietf.org" <openpgp@ietf.org>, Vincent Breitmoser <look@my.amazin.horse>, Jon Callas <joncallas@icloud.com>
In-Reply-To: <CAB941EE-6961-4CAB-9632-DFF738980467@icloud.com>
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>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/24.5 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=ISO-8859-7
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/kl2wziH-odvtFbIXA3yLMS_fldk>
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: Thu, 28 Feb 2019 08:51:19 -0000

On Wed, 27 Feb 2019 23:37:20 +0100,
Jon Callas wrote:
> Moreover, forbidding it says that we state now that no one could
> ever have a reasonable use; my experience is that categorical
> statements like that are just asking the fates to bite us in an
> uncomfortable place. Amazon S3 increased their max object size to
> 5TB a few years ago. I’m not saying it should be that large, but I
> think this is a pretty convincing argument that 16K is too small.

I think you misunderstand the point of the chunk size parameter.

Modulo perhaps performance, the chunk size is not visible to the
application.  That is, messages encrypted using AEAD can
(theoretically) still be 4 exibyte large when using a 16 kiB chunk
size; a message can consist of any number of chunks.  Chunk size is
like HTTP's chunked transfer encoding or OpenPGP's partial body
lengths.

The reason that we don't want large chunk sizes is that when
decrypting a chunk, the chunk MUST (RFC 5116) be buffered.  Since the
encryptor generally doesn't know the context in which the decryption
will occur, it must be conservative and choose a small chunk size.
Otherwise, a decryptor will inevitably encounter a chunk size that it
can't buffer and gratuitously fail.  Alternatively, it violates the
must and outputs the decrypted data without first verifying it thereby
resulting in the next EFAIL.

> So I think that a SHOULD is the right way to put it. I care less
> about what the SHOULD limit should be, but a small hard limit sounds
> like a bad idea.

Do you still think a hard upper limit is a bad idea?