Re: [openpgp] AEAD Chunk Size

Marcus Brinkmann <marcus.brinkmann@ruhr-uni-bochum.de> Fri, 29 March 2019 11:48 UTC

Return-Path: <marcus.brinkmann@ruhr-uni-bochum.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 56DB11202ED for <openpgp@ietfa.amsl.com>; Fri, 29 Mar 2019 04:48:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ruhr-uni-bochum.de
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 yk641AovqVoj for <openpgp@ietfa.amsl.com>; Fri, 29 Mar 2019 04:48:09 -0700 (PDT)
Received: from out3.mail.ruhr-uni-bochum.de (out3.mail.ruhr-uni-bochum.de [IPv6:2a05:3e00:8:1001::8693:359b]) (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 505EC120456 for <openpgp@ietf.org>; Fri, 29 Mar 2019 04:48:07 -0700 (PDT)
Received: from mx3.mail.ruhr-uni-bochum.de (localhost [127.0.0.1]) by out3.mail.ruhr-uni-bochum.de (Postfix mo-ext) with ESMTP id 44W0Ng1f3vz8SqZ for <openpgp@ietf.org>; Fri, 29 Mar 2019 12:48:03 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ruhr-uni-bochum.de; s=mail-2017; t=1553860083; bh=8Sat+CnntjQX+qcyDZz+o63V5g3fTzf+vA8kyYaq6vY=; h=Subject:To:References:From:Date:In-Reply-To:From; b=PBx+hs/INc2Zg2IsjXM4vkx/nMb2sAkbzYsw3NWDKhfQcLEKfYhfNFG13msfatXVa Blwq8p0UbcLdSykL5bWx7s6r59yDd8izZvteTrdJDQ+lYxuuyX5L0lGTWH43IpSbq1 elJrUS/eHWlyq7FvBpN2cENyVlaLrxf6LxL5CUJo=
Received: from out3.mail.ruhr-uni-bochum.de (localhost [127.0.0.1]) by mx3.mail.ruhr-uni-bochum.de (Postfix idis) with ESMTP id 44W0NX1nLTz8SdG for <openpgp@ietf.org>; Fri, 29 Mar 2019 12:47:56 +0100 (CET)
X-Envelope-Sender: <marcus.brinkmann@ruhr-uni-bochum.de>
X-RUB-Notes: Internal origin=134.147.42.227
Received: from mail1.mail.ruhr-uni-bochum.de (mail1.mail.ruhr-uni-bochum.de [134.147.42.227]) by out3.mail.ruhr-uni-bochum.de (Postfix mi-int) with ESMTP id 44W0NV2fZ1z8Snx for <openpgp@ietf.org>; Fri, 29 Mar 2019 12:47:53 +0100 (CET)
Received: from [IPv6:2a05:3e00:1:59:d34a:df34:3a81:7663] (dyn-366718a343fda43d95001000.eduroam.ipv6.ruhr-uni-bochum.de [IPv6:2a05:3e00:1:59:d34a:df34:3a81:7663]) by mail1.mail.ruhr-uni-bochum.de (Postfix) with ESMTPSA id 44W0NT6QKjzytX for <openpgp@ietf.org>; Fri, 29 Mar 2019 12:47:53 +0100 (CET)
To: openpgp@ietf.org
References: <87mumh33nc.wl-neal@walfield.org> <878swzp4fb.fsf@europa.jade-hamburg.de> <E65F6E9D-8B0B-466D-936B-E8852F26E1FF@icloud.com> <8736n63bav.wl-neal@walfield.org> <DD6BD098-A048-4513-BAAC-913BF52CDB1D@icloud.com>
From: Marcus Brinkmann <marcus.brinkmann@ruhr-uni-bochum.de>
Openpgp: preference=signencrypt
Message-ID: <3d86539c-c9de-2194-bbfb-1442bdc8c327@ruhr-uni-bochum.de>
Date: Fri, 29 Mar 2019 12:47:52 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1
MIME-Version: 1.0
In-Reply-To: <DD6BD098-A048-4513-BAAC-913BF52CDB1D@icloud.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.99.4 at mail1.mail.ruhr-uni-bochum.de
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/qvUZSXkEZgCMQ3Q496YIx_PywE8>
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: Fri, 29 Mar 2019 11:48:19 -0000

On 3/29/19 3:19 AM, Jon Callas wrote:
> I wrote a point-by-point reply and decided that that’s not productive. I’m going to try to cut to the chase on this, so forgive me if I have dodged an important point. I’m happy to come back to it later.
> 
> Like some interim replies, particularly Bart Butler, I thought we had a rough consensus and that it was approximately:
> 
> * MUST support 16KB chunks.
> * SHOULD support 256K chunks, as these are common (Protonmail).
> * MAY support larger up to the present very large size.
> * MAY reject or error out on chunks larger than 16KB, but repeating ourselves, SHOULD support 256K.
> 
> I think it’s also reasonable to just simplify it by making be MUST support up to 256K. I don’t like getting rid of the SHOULD clause, thus making it be either 16K or off in squishy land, but I wouldn’t wring my wrists, I’d merely be a bit unhappy.
> 
> I could also get behind a hard limit of 2^30 on the grounds that that’s what we had for partial body lengths, but I understand the comment that there are things like multi-terabyte S3 buckets and out and out forbidding those to be single-chunk is a bit churlish, but only a bit.
> 
> If we really want to tie a bow around everything, then define some notation or other marker so that an implementation can mark in a key what the max chunk size is.
> 
> How’s that?

FWIW, I think that's reasonable. It is very similar to the original
OpenPGP AEAD proposal by Brian M. Carlson, which just had "MUST support
up to 64KB chunks" and "MAY support larger chunks".  That original
proposal is simpler than yours, but given that Protonmail already uses
larger chunk sizes, that's ok.  From the perspective of mobile and
desktop devices, 64KB and 256KB are similarly reasonable.

There is a little bit of tension here, because any increase in the MUST
area may give trouble to constraint devices, who should be able to hold
a single chunk in memory if they are interested in non-malleability.
The difference between 16KB and 256KB can matter here.  So, I guess I
understand why you introduced the SHOULD requirement, although it makes
things more complicated.

Thanks,
Marcus