IETF Logo Mail Archive

Re: [openpgp] Proposal to include AEAD OCB mode to 4880bis

Werner Koch <wk@gnupg.org> Fri, 27 October 2017 11:14 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 D589713F4D3 for <openpgp@ietfa.amsl.com>; Fri, 27 Oct 2017 04:14:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] 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 ZpjjMfTM9tTh for <openpgp@ietfa.amsl.com>; Fri, 27 Oct 2017 04:14:04 -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 A2E9B13B109 for <openpgp@ietf.org>; Fri, 27 Oct 2017 04:14:04 -0700 (PDT)
Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.89 #1 (Debian)) id 1e82aR-0004QS-Gj for <openpgp@ietf.org>; Fri, 27 Oct 2017 13:14:03 +0200
Received: from wk by wheatstone.g10code.de with local (Exim 4.84 #3 (Debian)) id 1e82UO-0004YD-LU; Fri, 27 Oct 2017 13:07:48 +0200
From: Werner Koch <wk@gnupg.org>
To: Hanno Böck <hanno@hboeck.de>
Cc: openpgp@ietf.org
References: <D0505748-E376-4CF9-8906-9AD77838FB23@ribose.com> <1508981649515.71466@cs.auckland.ac.nz> <07C9EFDF-C8C2-4433-A9F9-DC3D7AFD5499@ribose.com> <6AC83857-62D9-45DF-9DAE-928CF0E45A96@nohats.ca> <87she556tv.fsf@wheatstone.g10code.de> <1509093954061.51049@cs.auckland.ac.nz> <36023233-856C-4A6D-BAF9-28037B4DA0F7@ribose.com> <20171027123826.693047e6@pc1>
Organisation: The GnuPG Project
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: Fri, 27 Oct 2017 13:07:48 +0200
In-Reply-To: <20171027123826.693047e6@pc1> ("Hanno Böck"'s message of "Fri, 27 Oct 2017 12:38:26 +0200")
Message-ID: <87she44znf.fsf@wheatstone.g10code.de>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=red_noise_JPL_doctrine_Gazprom_CID_ammunition_AMW_UNSCOM_Qaddafi_swe"; micalg="pgp-sha256"; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/ynjm_v0rdt-yZqF4QJCEqmpZN10>
Subject: Re: [openpgp] Proposal to include AEAD OCB mode to 4880bis
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.22
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, 27 Oct 2017 11:14:07 -0000

On Fri, 27 Oct 2017 12:38, hanno@hboeck.de said:

> Don't add multiple algorithms unless there isn't a very good reason for
> it. Add one that is good for everything. Having a "may" algorithm only

There is a good reason for adding a MAY mode:

- We want an AEAD mode.
- The WG seems not to like OCB for political (patent) reasons.
- Thus the proposed solution is to require EAX but prepare for other
  modes.
- OCB has been suggested as such another mode.
- We can add it to rfc4880bis as MAY mode to give a specification in
  case someone will implement it anyway.

Consider what will happen if we don't do this: OCB may be implemented
anyway but at best an I-D extending RFC4880bis is used as specification.
Or worse, there is no spec at all and everyone implements it in slightly
different ways.

Also: The first revisions of I-Ds for RFC6637 (ECC for OpenPGP)
specified _only_ NIST curves and didn't allowed for any other curves.
This has been challenged and fortunately RFC6637 allows for arbitrary
curves, albeit less well specified.  Without that semi-MAY we would not
have been able to deploy software using modern curves.  Patents on ECC
are still a minefield but nevertheless everyone is moving towards ECC.

> The GPG protocol is far more complex than it has to be.

You mean OpenPGP.


Shalom-Salam,

   Werner

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

v2.23.0 | Report a Bug | By Email