Re: [openpgp] AEAD Chunk Size

"Neal H. Walfield" <neal@walfield.org> Thu, 28 February 2019 08:56 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 8BCE0130E74 for <openpgp@ietfa.amsl.com>; Thu, 28 Feb 2019 00:56:07 -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=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 OJ_NuMfIBJmu for <openpgp@ietfa.amsl.com>; Thu, 28 Feb 2019 00:56:05 -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 BD0BE130DE4 for <openpgp@ietf.org>; Thu, 28 Feb 2019 00:56:05 -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 1gzHU2-0008JC-P8; Thu, 28 Feb 2019 08:56:02 +0000
Date: Thu, 28 Feb 2019 09:56:02 +0100
Message-ID: <87ef7s2swt.wl-neal@walfield.org>
From: "Neal H. Walfield" <neal@walfield.org>
To: Bart Butler <bartbutler@protonmail.com>
Cc: Jon Callas <joncallas@icloud.com>, "openpgp@ietf.org" <openpgp@ietf.org>, Vincent Breitmoser <look@my.amazin.horse>
In-Reply-To: <gqB_oCEBF2U1CDCY7IaW8pLh0SMtaVydDa5b8CD5Q-tE_4mbQgwlUVSgtWGHptl9flfb8N2L3tcdU5yY9O-TOkvFbjzf_hk3E4Hp1AMBVrk=@protonmail.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> <HBifY5kv2OqoajWurbHh_-NyZaBUZGabUpbxfhLlw8lTEuJVAiaHr-hhL_v5jKI-uqfeTIKD2S8VbEKvImC2sxhSlxD3GsT8LBzXKaOeHLI=@protonmail.com> <431339C1-8DDA-47D0-B233-9B7F49F0692A@icloud.com> <gqB_oCEBF2U1CDCY7IaW8pLh0SMtaVydDa5b8CD5Q-tE_4mbQgwlUVSgtWGHptl9flfb8N2L3tcdU5yY9O-TOkvFbjzf_hk3E4Hp1AMBVrk=@protonmail.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=US-ASCII
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/AtbUwqMoB0k_uOajACPdJwZDMDM>
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:56:07 -0000

On Thu, 28 Feb 2019 01:45:52 +0100,
Bart Butler wrote:
> It does, and normally on this kind of thing I would completely agree with you, but in this case I think there are two mitigating factors:
> 
> 1. AEAD chunk size does not limit message/file size in any meaningful way assuming we set the upper limit chunk size to something reasonable like 1024 kiB, you just use multiple chunks, which is the idea anyway.
> 2. Abuse potential in an open standard
> 
> It's #2 which is really compelling for me for exactly the reason that we DO want this to be usable for arbitrary uses and message sizes in federated contexts, and for that to be possible we need to try to set reasonable limits to prevent malicious or careless users from creating bad-but-legal payloads.


I fully agree with #2.  I am convinced that it is imperative that we
avoid introducing potential attack surfaces that have no value.