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

"brian m. carlson" <sandals@crustytoothpaste.net> Fri, 27 October 2017 00:18 UTC

Return-Path: <sandals@crustytoothpaste.net>
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 0F08D13A302 for <openpgp@ietfa.amsl.com>; Thu, 26 Oct 2017 17:18:50 -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 (3072-bit key) header.d=crustytoothpaste.net
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 gvhFvCvGp-op for <openpgp@ietfa.amsl.com>; Thu, 26 Oct 2017 17:18:48 -0700 (PDT)
Received: from injection.crustytoothpaste.net (injection.crustytoothpaste.net [192.241.140.119]) (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 61300139F44 for <openpgp@ietf.org>; Thu, 26 Oct 2017 17:18:48 -0700 (PDT)
Received: from genre.crustytoothpaste.net (unknown [IPv6:2001:470:b978:101:254c:7dd1:74c7:cde0]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by injection.crustytoothpaste.net (Postfix) with ESMTPSA id 70D5C6044A for <openpgp@ietf.org>; Fri, 27 Oct 2017 00:18:16 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crustytoothpaste.net; s=default; t=1509063496; bh=CzQAenB3S9WYtPdIwPgr0wN4iCMjelhAw4YmwGvYsvE=; h=Date:From:To:Subject:References:Content-Type:Content-Disposition: In-Reply-To:From:Reply-To:Subject:Date:To:CC:Resent-Date: Resent-From:Resent-To:Resent-Cc:In-Reply-To:References: Content-Type:Content-Disposition; b=qQXfqYsrmmwYsuUXcmHZNHILDOh82o552gkVjn79AZXBMNQGLonnKmrkSuJBPpDBI S3k5qz2DyzrV/xaKgF2zyBtLTaSMo7YiglxUevSJsFquW3NTgFLaCOVNhK6qVJs31l IaJ8IeBdDUpTNGLYYGf4R1jfPYCwb0Qdw2ZP6H/U1Bvjh58JO4U2+U/z7tyEy1ATgI ECtWg6NJ6dGZnyTKJENBACrMB5n8akNyfQMV+6ITZVFzwzf6xe2dZ9ZyJkKqbtOxTm U46AMqy2cX2aH/xAMpx6ceTHIO9mfjMM+AL2vCUS8FECeq+BnKuaRSNeJbXgU4Yy99 ekselzVjURPVdwlJYwV2qaPDZf7Jro3h04zK/q6pjKo8BU6yl/QTYEYoZV46+slTA4 zwEXepNcS6do+Fjgek9xTZ4PIVBwu6JXQT0RiLoqYIgyRwX4iRrBKQdTGpLkD02jIw lzY5Ode/kkPWQ48ontPjJgPHe5t4nJvLVQBYw8ZhZBa0X1GLp/4
Date: Fri, 27 Oct 2017 00:18:10 +0000
From: "brian m. carlson" <sandals@crustytoothpaste.net>
To: openpgp@ietf.org
Message-ID: <20171027001810.sr5invirfy2zqjia@genre.crustytoothpaste.net>
References: <D0505748-E376-4CF9-8906-9AD77838FB23@ribose.com> <1508981649515.71466@cs.auckland.ac.nz> <07C9EFDF-C8C2-4433-A9F9-DC3D7AFD5499@ribose.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="5smgcopjai4xd47g"
Content-Disposition: inline
In-Reply-To: <07C9EFDF-C8C2-4433-A9F9-DC3D7AFD5499@ribose.com>
X-Machine: Running on genre using GNU/Linux on x86_64 (Linux kernel 4.13.0-1-amd64)
User-Agent: NeoMutt/20170609 (1.8.3)
X-Scanned-By: MIMEDefang 2.79 on 127.0.1.1
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/5A9ZUAlD5bwfUYPmgoqs7J4ISz8>
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 00:18:50 -0000

On Thu, Oct 26, 2017 at 02:03:02AM +0000, Ronald Tse wrote:
> Perhaps I could clarify that the OCB patent is limited in regional
> scope and does not apply outside of the US. For example, the NZ
> military could order a pizza using OCB.

Unfortunately, a patent anywhere is an impediment everywhere in the age
of the Internet.

> The OCB licenses provided on Rogaway’s page is very clear that open
> source usage, such as in OpenSSL and any products based on OpenSSL, is
> strictly allowed — which means that military and hardware usage of OCB
> through OpenSSL is already allowed.

It's my reading of Rogaway's license that linking an open-source library
against closed source software violates the patent license, even though
it might not violate the library license.  If a distro ships an
OCB-enabled crypto library, it can't be used for any closed-source
software shipped on that system (Chrome, Slack) or any non-open-source
custom-built apps (say, an internal Rails app).

Since crypto libraries like OpenSSL are very frequently linked against
other software on the system, this is a terrible idea.

The fact that it's this hard to understand the patent issues makes it
really obvious why OCB is a bad idea.

> I think we are slightly confusing an optional algorithm, which OCB is
> proposed to be, with a mandatory one. A user should be able to specify
> in their preferences that they don’t accept OCB. A .mil email address
> will probably specify they do not want OCB in this case.

I'm generally opposed to including algorithms, even optional ones, which
are patent-encumbered.  The fact that an IPR declaration exists for an
RFC is enough to scare off many companies from implementing it.

I personally hate having to meet with company lawyers, even extremely
knowledgable ones, about the type of crypto we use and the legal impacts
of it.  Adding OCB to the spec is going to cause a lot of those
conversations that don't need to happen.

> Given OpenPGP is supposed to be “open”, people should be able to state
> their preferences as well as do what they want with it.
> 
> For example, Chinese cryptography law strictly forbids AES usage in
> hardware. Does that mean Intel needs to drop AES-NI for chips sold in
> China? The answer is no. People simply don’t use it because of these
> regulations.
> 
> This is the same with OCB — if you don’t like it, don’t want it, just
> don't use it. It only enables people who want it to use it.

Practically, a patent-encumbered algorithm is not likely to be
implemented.  The patent problems with OCB make it unlikely that it will
be suitable for inclusion into the Red Hat or Debian archives.  That
means that most open-source implementations will not include it, and
those that do will not interoperate with those that don't.

Why should we add an algorithm which is likely to get little practical
usage?  OCB doesn't provide useful crypto agility, but it does provide
yet another option, which we've tried to avoid in the specification.
Additional algorithms are hard to deprecate and are a source of
potential security bugs in implementations.

I'm not saying OCB isn't a great block cipher mode, just that it's going
to be practically unused because of the patent situation.

> +=========================================================+
> This message may contain confidential and/or privileged
> information.  If you are not the addressee or authorized to
> receive this for the addressee, you must not use, copy,
> disclose or take any action based on this message or any
> information herein.  If you have received this message in
> error, please advise the sender immediately by reply e-mail
> and delete this message.  Thank you for your cooperation.
> +=========================================================+

If your mails are confidential, you probably want to stop sending them
to a public mailing list.  If not, you'll want to omit this message.
-- 
brian m. carlson / brian with sandals: Houston, Texas, US
https://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: https://keybase.io/bk2204