Re: [openpgp] AEAD Chunk Size

Werner Koch <wk@gnupg.org> Fri, 08 March 2019 15:40 UTC

Return-Path: <wk@kerckhoffs.g10code.com>
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 3801912865D for <openpgp@ietfa.amsl.com>; Fri, 8 Mar 2019 07:40:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.593
X-Spam-Level:
X-Spam-Status: No, score=-3.593 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_96_XX=3.405, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gnupg.org
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 Fzg1wou-dWIM for <openpgp@ietfa.amsl.com>; Fri, 8 Mar 2019 07:40:12 -0800 (PST)
Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (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 22DB9129570 for <openpgp@ietf.org>; Fri, 8 Mar 2019 07:40:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnupg.org; s=20181017; h=Content-Type:MIME-Version:Message-ID:to:References:Date: In-Reply-To:Subject:From:Sender:Reply-To:Cc:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=1/cPjeCBuoXWW2LxPWZFtlRxDNWVSIrfOqb5dK9P0UU=; b=XlNtj5E5DES6TUeEqzw3ZV4wjA hemKttW6rOqcMoYnsDy1o7u3CW0R6bRgBW3FwleTSYdk2MZOqaiyn2nbL/WpIvDEMQkrSxgxLQ8Tc 6DXZsvFHMVoqmcdnH5b0rxqaVRXeOa+cuT2QtUbOAiEzqMXMpyBNCCR7/r/5RXAciWM4=;
Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.89 #1 (Debian)) id 1h2HbV-0007Jn-9R for <openpgp@ietf.org>; Fri, 08 Mar 2019 16:40:09 +0100
Received: from wk by wheatstone.g10code.de with local (Exim 4.84 #3 (Debian)) id 1h2HZx-0005VJ-Pn for <openpgp@ietf.org>; Fri, 08 Mar 2019 16:38:33 +0100
From: Werner Koch <wk@gnupg.org>
In-Reply-To: <87mumh33nc.wl-neal@walfield.org> (Neal H. Walfield's message of "Wed, 27 Feb 2019 11:51:51 +0100")
Date: Fri, 01 Mar 2019 15:50:15 +0100
References: <87mumh33nc.wl-neal@walfield.org>
User-Agent: Gnus/5.13 (Gnus v5.13)
to: openpgp@ietf.org
Organisation: GnuPG e.V.
X-message-flag: Mails containing HTML will not be read! Please send only plain text.
Mail-Followup-To: "Neal H. Walfield" <neal@walfield.org>, openpgp@ietf.org
Message-ID: <87d0n174w6.fsf@wheatstone.g10code.de>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/J428Mqq3-pHTU4C76EgP5sPkvtA>
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, 08 Mar 2019 15:40:15 -0000

Hi!

[The mail got stuck somewhere in the IETF mail system - resending]

On Wed, 27 Feb 2019 11:51, neal@walfield.org said:

> Consequently, I propose not only imposing a reasonable ceiling on the
> chunk size that even small embedded devices with a cortex M0 could
> handle, but to simply fix the parameter to 16 KiB.  It's not clear to

Without sufficient storage a smaller chunk size does not help you in any
way.  You can still run a truncation attack and by that time the
preceding chunks have already been processed in some way because, well,
there was no way to store the entire message.  Without the final chunk
you have an incomplete and thus unauthenticated message because the
sender authenticated the entire message and not certain parts of it.

If you like to adhere in your _implementation_ to some _API_ proposal,
go ahead and use it but the API is not a _protocol_ thing.

Let me repeat it again: The chunking was introduced for just one
purpose: To be able to detect rare transmission errors earlier than at
the end of the message.  For large pipes large chunks are a sensible
choice.

Changing the protocol in a way as suggested by you is not an option
anymore.  We can change recommendations, though.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.