Re: [openpgp] AEAD Chunk Size

Vincent Breitmoser <look@my.amazin.horse> Mon, 18 March 2019 12:23 UTC

Return-Path: <look@my.amazin.horse>
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 1B7A212797D for <openpgp@ietfa.amsl.com>; Mon, 18 Mar 2019 05:23:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=my.amazin.horse
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 IikmRdc_492g for <openpgp@ietfa.amsl.com>; Mon, 18 Mar 2019 05:23:13 -0700 (PDT)
Received: from mail.mugenguild.com (mugenguild.com [5.135.189.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F013B127963 for <openpgp@ietf.org>; Mon, 18 Mar 2019 05:23:12 -0700 (PDT)
Received: from localhost (dhcp229-087.wlan.rz.tu-bs.de [134.169.229.87]) by mail.mugenguild.com (Postfix) with ESMTPSA id 8CE425FAFF; Mon, 18 Mar 2019 13:23:10 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=my.amazin.horse; s=mail; t=1552911790; bh=vixvCDX0G7o1INJHlSxig/M9rSCs36FHKbm36euuido=; h=Date:From:To:Subject:Autocrypt:From; b=NxHnu/APtw/IXmk4LF6zSeb4g3+zQNoBQYaKmX36PrxM5DQhqwYQ8xxsaHYFaFEnV SeG2YFiqAGsq1X2ChQJYyzXXpQtaVX0RSlSMC3Xs3rU2FqM30ANstzI6sFiqdb6SC2 k2xpppqWh2b9UfP+K2HLl3sLjpnKeOjNmzl7gVnQ=
Message-Id: <2HK22F68FITOF.35CB8RFLBNB8W@my.amazin.horse>
In-Reply-To: <e558f5729bc81eed952671ce4199b427dc3b7f1a.camel@cryptobitch.de>
References: <e558f5729bc81eed952671ce4199b427dc3b7f1a.camel@cryptobitch.de> <87mumh33nc.wl-neal@walfield.org> <F9VLV9HZWH.3RYL3UM3BN873@my.amazin.horse> <3WZ7-hy9V7TOy53p1gP5EXELzHJIqjouV9x0YTN3PWsBZedKkqvVCRm-2XzGZy-FYAYdTqP1-7YV4wbTWMWAYhSujQA6NmrnIuXfZLRHkdQ=@protonmail.com> <CAB941EE-6961-4CAB-9632-DFF738980467@icloud.com> <87h8co2t4v.wl-neal@walfield.org> <35C892F7-18A8-401E-828D-5CE180A3A731@icloud.com> <87r2brf0f1.wl-neal@walfield.org> <2a014c4a103ba7f52535546f7e77277ea2bdabdf.camel@cryptobitch.de> <90a28b7c-1b02-abbb-eb8d-bec5263a9f89@fh-muenster.de>
Date: Mon, 18 Mar 2019 13:23:07 +0100
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Vincent Breitmoser <look@my.amazin.horse>
To: Tobias Mueller <muelli@cryptobitch.de>
Cc: Sebastian Schinzel <schinzel@fh-muenster.de>, openpgp@ietf.org
Autocrypt: addr=look@my.amazin.horse; keydata=mQINBFAB3UABEADCyB/vbIBA3m1Bwc yjTieEMLySwYgt54EQ2hglOocdtIhqC+b05t6sLSkwx2ukxrU2cegnCBkdyF/FZ/+Et638CUEBbf 4bjplwpt2IPLazQgjkwjMuhz0OcYDpMhwimTvh3mIl+0wzpOts6mEmMw0QZdl3RXvIW+NSynOn7q mz/fAv4Htt6lv2Ka0s6R2voyi+5U7CcIqizPad5qZVn2uxmovcFreTzFt6nk37ZbbTfvA3e5F0bR RQeH3viT5XxpJF4Y76v/Ua+5N3Kd18K0sX85rD1G7cmxR2CZ5gW1X24sDqdYZdDbf10N39UIwjJH PTeuVMQqry792Ap0Etyj135YFCE0loDnZYKvy2Y1i0RuEdTUIonIHrLhe2J0bXQGbQImHIyMgB9/ lva8D+yvy2gyf2vjRhmJEEco7w9FdzP7p3PhKrUiTjRsjHw8iV8LOCFx9njZOq9mism9ZZ16tZpx 9mXOf11HcH1RtVuyyQRS/4ytQPzwshXdSDDW6Btkmo9AbZQKC54/hSyzpp3Br2T2xDH7ecnonDB/ jv8rWuKXSTbX3xWAIrNBNDcTYaNe4jkms4HF7jJE19eRlqsXMMx6Fxvrh4TtKICwJYJ3AUmXrK3X Ti/mjqYfJ1fpBn54rWs8nhSR1fuZPD+aMlcP8BDUPlNKPKtj0DGSh3/VlnnwARAQABtClWaW5jZW 50IEJyZWl0bW9zZXIgPGxvb2tAbXkuYW1hemluLmhvcnNlPokCOAQTAQIAIgUCVTNZmgIbAwYLCQ gHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQe9GDIN6t+hHcVg//aeiijNqsQ3pjbFQn3VvND7hNfJ vrVcLZ+U4kOzXPF818aVdOnDyNXyE17vBDDcvaZ730sCsZIRZJ3KhUJ+nPvdttKjUIGLARmx+pA3 Jl3IIv2uLtOb3I0TMuyfIGJVGF+q10/CeDMKVjKlmyOVrR0opkel+KEoN7VLq3Hf3zPKENO1HBgp LHeP31tlb9cgs+u4o2wLrVe9myHbuFBW7EjWbSvdz2zliwbsFeFVLMNcWrKAU0GkkiH69SgnwmXU RkhGma4L27GLtkHHufsxfbcPqPtmtCttsGZU4EmrghGUqVyDOxnn8ZqybzLrRfpin+OCIX+aHJz5 r2L8qtrP0LorNMX3Gopd26vfhNvq/wq8xk++bW1R5FmkaUhx9h+DhO2ybcg7p/E8JHc8zrWv+bb3 0o9lkrOaU8GxXrgtb1cjtbb+MxFvjm0Elw7MSZDG7sF/APFU6cwuIA9Nai/OGAUCSt/W2ecS8Zox cWWbGSEiDvjtEctkpmHjfVuGoL34966Olm41VdH+NjgoSYUJKx4Mty8DRcZxdyoXll84LvDkEEYK ZqOIACsJf8CDFvUkmhXc+moCj15Yxtj3/RslRVEiOUyrpDwB72zWcZG8YnzoyGxhcRIc/gFejO/y SI8bzCpYngeuTb5NjFG+ChGiInHbQcFeHBlaHtKi2o/B5axIO5Ag0EVDvOgQEQALJby/ztliToGE u1lslvWQUQ6teKZVUQ7hy9bM4N83G0AGLatUBHtY6PkJBe4XkIw3sK7LoFCV2W4GSt4zWp9l+kG3 /J8Ow7EFjN0F7DrCg0M0lMg9dQz9jYSoBR8skaH3BRzCq9AKIVKV94poL/G65289L7zKDHoZnnyF qbBtedYZir0SZx+kiouZ1qnmxRPaYmH2fkuiuvYEAyzLDLYM8F5gQhdZM4YVtuvSICYPet0z4CDi JX/vZmDi3AzzoEVaKeAM/0H9f9Ni547J2+8dZSllgTrA+fq0aMJVScAObIxTAQtEq0DoNBzPpVrm W10b4bmgePrAvNkifqSr5StymSBgwvoeW6GrJiyN4XhoLOadZzwgjqioR1nXw5tXtrr5sYdkZ06b 1WWHkxtu1hFTdLC7RYNxY07ytLNM+C2lplCwCwlWB7RwI9BL1Dhre4kv8uaaX2Gksaq9mDf9MSDW qQ0TJ/RAiwMGmFrzBEYI1J2Oyeshi/dqW4/OiZAukOIlxOnt6u8zU2KL6Qjxqqna0oTbS4Zv3fRd YkuUCL6CDEJdkuRAiW+Gw+lKcMjXqApEqixhaDkoB/kwtu+2gIFTzAxMfwFN1YtNc0kJZWnFkGIW MrrwTcOwAFzlFz7wn/EyMFtg+ERcqMX0+olXDwM8MODI2+BzulPuEDEteCw09hABEBAAGJAh8EGA ECAAkFAlQ7zoECGwwACgkQe9GDIN6t+hFjuQ//UQyg49f8TytUYQaBb8R0UfI+KhQFs1Nsz2z8a3 0CD1MeiHHYWdAcomVvTkg4g5LbnYHVDrj/XagY3FN/AIE97usFbsTG+rsWAOLi7N2dN2ehWZ634k MvrgyC9uTiOdkw31+B8K5MpyySgD8e6SAzRfiu06/bcQOUyJifw8Hudpj9by4uyGhSH+kHu4afrp OduUighbsGFtcuRwwQ/w/oSk68XvPUgiOQWMZh/pVoXdFyFvrt/hgArCi8dfy5UPK58nl7jPnu/I uQXrJ50nNAFIIxPVeo2/B83KAnEZPU+qWZsdba0V+FIIQQVizLtQFMuJJk4/UTAOfJ2tBpQ9PADX 6/scqDE7unXNWdxcHTjK7KmWjXC8CyhGOx8V/rb7Ial4mZo4cTED6SNlO7dV1XYwnSctL2HCYNM3 RUe4eJ7JWuu7/Nbf6yip2eq7BQKZ9hAH/se/OSZNYsEkZ4pxUc8W5U3uAZImUwC6L74SM0jBZIuD mQhOYX6sZZ6urIn/MYlj4/hqSBFS4vTK7nXRLmtr7+5T5U5srVseUiYc+l9pu9/XD8zGIu+M2xEd 41NwP44GDQTQm0bFljRv5fSblwmi56YHPFQUIh2RZNX3kOJgeyQ3enw5uY+7ocKRVP38hpnffliL lJcO6TtHWnElS3pACbTQM0RHJox3zqU3q6K3c=
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/V-Y_vw0rhTsqpqGxlgble4nHYrk>
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: Mon, 18 Mar 2019 12:23:15 -0000

Hi,

a lot that Tobias is bringing up here resonates with me, I feel like we should
be thinking more about the fully vs partially authenticated use cases, not just
chunking on its own.

(As an aside, I'm not convinced the early integrity check should have much
bearing on this discussion.  Transmission errors are (and should be) handled on
other layers in mostly all cases, and noticing errors earlier than at the end of
data that was going to be buffered anyways is not that big of a gain. In cases
where this is a concern (like uh, tape drives?), a tool should be used that is
actually meant for the job, e.g. par2)

Ideally, a receiver won't ever output unauthenticated plaintext, hence ideally
all of the chunking discussions would be moot. What chunking brings to the table
is to give the *sender* of a message the option to *allow* the *receiver* to
emit partially authenticated plaintext, trading a truncation vulnerability for
the ability to process data on a smaller buffer size than the entire plaintext.
This is useful for $large amounts of data, or streamed workflows with unknown
data sizes.

While following the discussion I've gone back and forth a couple of times
between favoring the case for fully authenticated plaintext, or for supporting
streamed workflows with fixed-size chunks (while sacrificing truncation). Both
seem equally valid to me. However, I can't see a good use case for variable size
chunking: it adds complexity to spec and implementations in particular on the
receiving side, and pushes the onus on reasoning about chunk sizes to the
implementations, which is basically impossible in the face of interoperability
concerns.

I'd like to bring up a new proposal then: Support either no chunking, or
fixed-size chunking. The advantage would be that the sender's position on
authentication is made more explicit: If they don't do chunking, they expect the
receiver to fully buffer and authenticate before processing, which could
currently only be achieved implicitly via a large chunk size. If they use the
fixed-size chunking, they explicitly offer the option to emit partially
authenticated plaintext.

 - V