Re: [openpgp] AEAD Chunk Size

"Neal H. Walfield" <> Fri, 01 March 2019 08:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 77C081311F5 for <>; Fri, 1 Mar 2019 00:45:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 3.101
X-Spam-Level: ***
X-Spam-Status: No, score=3.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_SUMOF=5, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id N6-133OiBItF for <>; Fri, 1 Mar 2019 00:45:28 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 851DB130E11 for <>; Fri, 1 Mar 2019 00:45:28 -0800 (PST)
Received: from [] ( by with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.86_2) (envelope-from <>) id 1gzdnH-0004Us-La; Fri, 01 Mar 2019 08:45:23 +0000
Date: Fri, 01 Mar 2019 09:45:22 +0100
Message-ID: <>
From: "Neal H. Walfield" <>
To: Jon Callas <>
Cc: Jon Callas <>, Bart Butler <>, "" <>, Vincent Breitmoser <>
In-Reply-To: <>
References: <> <> <> <> <> <>
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-2022-JP
Archived-At: <>
Subject: Re: [openpgp] AEAD Chunk Size
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 01 Mar 2019 08:45:31 -0000

At Thu, 28 Feb 2019 10:39:17 -0800,
Jon Callas wrote:
> > On Feb 28, 2019, at 12:51 AM, Neal H. Walfield <> wrote:
> >> 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?
> No, I don’t think a hard upper limit is a bad idea. In the text you quote above, I said a *small* hard upper limit. And no, I don’t know what small means. I think 16K is small. 256K might be small. AES-GCM has issues about 64G. One might argue that’s a reasonable large upper limit. Me, I think anything in the few megabytes to a gigabyte-ish is just fine.
> Let me rewind a bit and get to my real point which I don’t think I’m making well.
> When one creates a standard, one needs to be careful with
> parameters, particularly the MUSTs. Seemingly sensible things can
> have downstream effects that convince people to use some other
> protocol. Worse, someone’s angry blog post about something can
> quickly go into “not even wrong” territory and embed itself into
> folklore and you can’t get it out. There are plenty of bad ideas
> that someone else has a really reasonable use case for.

There are always going to be haters.

> ...

> This has never caused a problem that I’m aware of. I’m sure it caused a problem that none of us are aware of, and the implementors just solved it on their own. It is this experience that has me wondering about what the restrictions out to be.
> The best way to deal with it in a standard is to have non-normative guidance. It is non-normative guidance that I was suggesting. Let me write an example bit of non-normative guidance below:
>  ...

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.  If in a few years, if we
decide that the size is wrong, then we can just define a new mode,
which uses a different chunk size.  In my opinion, it should be
impossible represent something that we want to disallow.

If we are really worried about the haters, then let's just deflect the
criticism: let's use 16 kiB chunks like TLS, as Marcus previously
pointed out:

From RFC 8446:

  5.2.  Record Payload Protection

    length:  The length (in bytes) of the following
      TLSCiphertext.encrypted_record, which is the sum of the lengths of
      the content and the padding, plus one for the inner content type,
      plus any expansion added by the AEAD algorithm.  The length
      MUST NOT exceed 2^14 + 256 bytes.  An endpoint that receives a
      record that exceeds this length MUST terminate the connection with
      a "record_overflow" alert.

(A record the approximate equivalent of a chunk.)

> The Partial Body Lengths that OpePGP has had from the beginning have no restrictions on them. There’s non-normative guidance that pretty much says you shouldn’t even use them, but there’s no restriction on size.

I just reread and I don't think it suggests that Partial Body Lengths
should not be used.

Can you point me to this guidance?  This is the first time I hear that
chunking is considered to be a bad idea.


:) Neal