Re: [openpgp] Need to publish bis-05

Werner Koch <wk@gnupg.org> Tue, 24 July 2018 15:03 UTC

Return-Path: <wk@gnupg.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 48D35131117 for <openpgp@ietfa.amsl.com>; Tue, 24 Jul 2018 08:03:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level:
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, URIBL_BLOCKED=0.001] 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 69G_MwlSkzld for <openpgp@ietfa.amsl.com>; Tue, 24 Jul 2018 08:03:47 -0700 (PDT)
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 92DC2131110 for <openpgp@ietf.org>; Tue, 24 Jul 2018 08:03:47 -0700 (PDT)
Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.89 #1 (Debian)) id 1fhyqn-00082W-Gz for <openpgp@ietf.org>; Tue, 24 Jul 2018 17:03:45 +0200
Received: from wk by wheatstone.g10code.de with local (Exim 4.84 #3 (Debian)) id 1fhyee-0000BE-Oe; Tue, 24 Jul 2018 16:51:12 +0200
From: Werner Koch <wk@gnupg.org>
To: Hanno Böck <hanno@hboeck.de>
Cc: openpgp@ietf.org
References: <87va95f5q6.fsf@wheatstone.g10code.de> <20180724135744.6972c8d3@computer>
Organisation: GnuPG e.V.
X-message-flag: Mails containing HTML will not be read! Please send only plain text.
Mail-Followup-To: Hanno Böck <hanno@hboeck.de>, openpgp@ietf.org
Date: Tue, 24 Jul 2018 16:51:12 +0200
In-Reply-To: <20180724135744.6972c8d3@computer> ("Hanno Böck"'s message of "Tue, 24 Jul 2018 13:57:44 +0200")
Message-ID: <87in54g00v.fsf@wheatstone.g10code.de>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=kilderkin_chameleon_man_class_struggle_NATO_ammunition_e-bomb_DRM=Gu"; micalg="pgp-sha256"; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/NBJcC41n35Psoc347e4Q7krMIBk>
Subject: Re: [openpgp] Need to publish bis-05
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.27
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: Tue, 24 Jul 2018 15:03:50 -0000

On Tue, 24 Jul 2018 13:57, hanno@hboeck.de said:

> This does not seem to reflect the lessons to be learned from efail.

Sorry, that remark does not make any sense.  We have explained in detail
why it was bot possible to hard fail on MDC and we can do this only know
with the “support” of EFFail.  The major points of Efail are bad
integration and in-correct use of tools.  You can shoot into your foot
even with simple standard toools like cat.

> I think it is very important to hard-restrict the chunk size to a
> manageable size, also manageable for small devices (i.e. even 128 mb is
> far too much), so that authenticating before any output is produced is

If you have a small device you don't have a way to store large amounts
of data and thus even a lower limit does not make sense because it won't
be reached.  The only option an implementation hast to trow up the hands
and say : message too large to decrypt. That is even before checking the
message.

> I.e. I propose to change it to a MUST NOT and to have a smaller
> maximum chunk size (I think something in the kilobyte range is a good

A kilobyte is - sorry I have no other words for this - stupid.  We are
talking about gigs and not a single memory page.  I think 128 MiB is a
good compromise - in particular for small device which suffer more for
the expensive steps of the chunk processing.  For large amounts of data
that is acceptable high.


Salam-Shalom,

   Werner

-- 
#  Please read:  Daniel Ellsberg - The Doomsday Machine  #
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.