Re: [openpgp] AEAD Chunk Size

Benjamin Kaduk <kaduk@mit.edu> Sat, 30 March 2019 16:58 UTC

Return-Path: <kaduk@mit.edu>
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 4359512001B for <openpgp@ietfa.amsl.com>; Sat, 30 Mar 2019 09:58:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 RGoMtSOc6f5k for <openpgp@ietfa.amsl.com>; Sat, 30 Mar 2019 09:58:01 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 EB2F4120158 for <openpgp@ietf.org>; Sat, 30 Mar 2019 09:58:00 -0700 (PDT)
Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x2UGvlwk028008 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 30 Mar 2019 12:57:49 -0400
Date: Sat, 30 Mar 2019 11:57:47 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: Bart Butler <bartbutler@protonmail.com>
Cc: "openpgp@ietf.org" <openpgp@ietf.org>, "Neal H. Walfield" <neal@walfield.org>, Peter Gutmann <pgut001@cs.auckland.ac.nz>, Justus Winter <justuswinter@gmail.com>, Jon Callas <joncallas@icloud.com>, Jon Callas <joncallas=40icloud.com@dmarc.ietf.org>
Message-ID: <20190330165747.GB35679@kduck.mit.edu>
References: <87mumh33nc.wl-neal@walfield.org> <878swzp4fb.fsf@europa.jade-hamburg.de> <E65F6E9D-8B0B-466D-936B-E8852F26E1FF@icloud.com> <87d0m9hl62.wl-neal@walfield.org> <FEE9711C-3C64-493C-8125-89696B882E0A@icloud.com> <2di2bK8m-7HtDeoUEH9oPqs-bL-IKSE0CjkgFShPMLOlUyeDBVkVGApdjnIpS6YRAeKU3ibGCZCtwLden-N6zK5W4fqIghRGDa5dU720nEs=@protonmail.com> <20190330150438.GS35679@kduck.mit.edu> <Bdt5b69HJ3vlmqlOuUI88JdGW8jqDnB1easOaEJdEFtysGIMgSnSH9mwshEGe6xdPib9z6OnlZv72wWRODJ1hvkXhIruch9fUk4w7IhAla0=@protonmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Bdt5b69HJ3vlmqlOuUI88JdGW8jqDnB1easOaEJdEFtysGIMgSnSH9mwshEGe6xdPib9z6OnlZv72wWRODJ1hvkXhIruch9fUk4w7IhAla0=@protonmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/8q4hm-3o-j7PodFsA7BP2Rr4PRQ>
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: Sat, 30 Mar 2019 16:58:03 -0000

On Sat, Mar 30, 2019 at 04:42:19PM +0000, Bart Butler wrote:
> Hi Ben,
> 
> > One concern that I have (and is only tangentially related to this quoted
> > part) is that I want to make it easy for implementations to "do the right
> > thing" when ciphertext is modified, i.e., return an error, and specifically
> > to return an error without releasing any plaintext that originates from the
> > modified ciphertext. The current openpgp ecosystem does not seem to be
> > very compliant to that desired behavior, and part of that may be due to a
> > lack of philosophical support/help from the spec.
> > 
> 
> 
> If you mean 'modified ciphertext' to equal 'modified chunk', and are OK with releasing previously unauthenticated chunks, then I completely agree. The alternative is is just no streaming.

Right.  (I think  I heard some  people argue that they were not okay with
releasing previously unauthenticated chunks, to be clear.  That seems like
something of a philosophical question, though perhaps there is some better
agreement to have.

-Ben

> > I'm still not sure I understand the point of very large chunks, since once
> > they get really big an implementation is choosing between streaming
> > plaintext from potentially modified ciphertext or return an error without
> > even attempting to process the chunk. I'm not convinced that the second
> > will win out in implementations if we alow very large chunks.
> > 
> 
> 
> Agreed. Part of the rationale with a smaller chunk limit is not forcing implementations to make this choice. The guidance becomes very simple--never release unauthenticated chunks, full stop.