Re: [Cfrg] ISE seeks help with some crypto drafts

Peter Gutmann <pgut001@cs.auckland.ac.nz> Mon, 11 March 2019 00:08 UTC

Return-Path: <pgut001@cs.auckland.ac.nz>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 709851277CD for <cfrg@ietfa.amsl.com>; Sun, 10 Mar 2019 17:08:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz
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 G1-JGUmpTGM7 for <cfrg@ietfa.amsl.com>; Sun, 10 Mar 2019 17:08:03 -0700 (PDT)
Received: from mx4-int.auckland.ac.nz (mx4-int.auckland.ac.nz [130.216.125.246]) (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 99A30126C87 for <cfrg@irtf.org>; Sun, 10 Mar 2019 17:08:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1552262882; x=1583798882; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ok0WQIlVtiI8/sXlk+2IXa4N92pryHwEkABBQdxIsQ4=; b=30SiiRQpEddsMsGz6Fn6iSSwT7NPB+IxQydJVrehYzRdfuxgmFExnDMJ qzrfiZrwKTqrGXUsITVHZKpU6WJN6KOIlm9DAoOuERoURdDUY9hX9+qGt UEdxTYTygbpVUjVhqWdTZ6vm0c8hLTq3r+nMKf52J5DhbssAgwlUqjimN Zg5IqYz0xKdZhK9gdWeUBJ6KfjPWPkeuwnbBP+K+9NA9OlfrktLoRfGiG JNcczrjMJGvh4AQpgPNiq7qyHAA0I5O5d/qytc4b8k7tYYzoy567HXxA9 G671Sfw+gX/gLqrE2s/h+7zfrDnpDqP48YImC/VRgfzBPx6llopoX9KuN A==;
X-IronPort-AV: E=Sophos;i="5.58,466,1544439600"; d="scan'208";a="51162501"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 10.6.2.5 - Outgoing - Outgoing
Received: from exchangemx.uoa.auckland.ac.nz (HELO uxcn13-ogg-d.UoA.auckland.ac.nz) ([10.6.2.5]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 11 Mar 2019 13:07:57 +1300
Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 11 Mar 2019 13:07:57 +1300
Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) with mapi id 15.00.1395.000; Mon, 11 Mar 2019 13:07:57 +1300
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: Tony Arcieri <bascule@gmail.com>, Paul Hoffman <paul.hoffman@vpnc.org>
CC: "sec-ads@ietf.org" <sec-ads@ietf.org>, CFRG <cfrg@irtf.org>, "RFC ISE (Adrian Farrel)" <rfc-ise@rfc-editor.org>, secdir <secdir@ietf.org>
Thread-Topic: [Cfrg] ISE seeks help with some crypto drafts
Thread-Index: AQHU1dNDCBNdVgHjrEegvYcYB1zY5aYBKtUAgAAEIACAAGSggIAAFskAgAComICAAAaMgIAAqgQAgAACvICAAomNCQ==
Date: Mon, 11 Mar 2019 00:07:57 +0000
Message-ID: <1552262834078.2554@cs.auckland.ac.nz>
References: <1d8de489fc976b63a911573300a431d4.squirrel@www.amsl.com> <EDCE0340-E79A-4464-B4A6-F539C694601C@akamai.com> <B536DE62-B202-4484-91AE-DDF7C3DD9503@gmail.com> <F5A25573-D7B5-4F0A-AE7A-7ACF9D613C9C@ericsson.com> <CAHOTMVJSazerng82T7LGZqQ9H5ODrLOacKKYMXrqGYJ42sDm+A@mail.gmail.com> <38FEBE5B-B60E-49DD-B048-A8A08EBF7FB4@azet.org> <C99F53D2-FC9C-468E-BB02-2BE4B4BDE7A7@azet.org> <F6D6DE1B-DAD9-4F91-9420-B32F7DAC1C56@vpnc.org>, <CAHOTMV+v2dtG_eHA41Xi5_HnTVaCb1sygppe0JMHiYzzG3ZYqg@mail.gmail.com>
In-Reply-To: <CAHOTMV+v2dtG_eHA41Xi5_HnTVaCb1sygppe0JMHiYzzG3ZYqg@mail.gmail.com>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/iX6tf3SffvtBFKNqBjqWa7LrLJk>
Subject: Re: [Cfrg] ISE seeks help with some crypto drafts
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Mar 2019 00:08:06 -0000

Tony Arcieri <bascule@gmail.com> writes:

>"Phillip Rogaway offers a royalty-free non-exclusive license to all claims of
>the referenced patents needed to realize a fully compliant implementation of
>any IETF standards-track protocol supporting AES-OCB (RFC 7253)."

That's still not going to work, for two reasons.  This first is that it
misunderstands how an implementation of, say, TLS works.  Virtually all TLS
implementations aren't a monolithic TLS-only code block but are built on top
of a general-purpose crypto library, for Windows CryptoAPI, for everything
else OpenSSL, Crypto++, mbedTLS, PKCS #11, my own cryptlib, etc. Taking the
vendor-neutral PKCS #11 as an example, what the above is requiring is an
implementation of Maxwell's demon in software, that a PKCS #11 library be able
to tell whether the handle from C_CreateObject( &handle, { CKA_KEY_TYPE, key,
CKK_AES_OCB } ) will be used to encrypt TLS data (OK) or non-TLS data (not
OK).

The second is legal.  Any commercial user of whatever the crypto library is is
going to get their lawyers to look at that requirement and have a fit, not
even because of the above very technical problem but just from the knowledge
that they'll be running code that, at the slightest glitch, will potentially
expose them to a patent lawsuit.  I've seen companies spend 1-2 years debating
whether using generic permissive BSD-licensed code is safe, and now they'll be
asked to decide whether the risk in the above is worthwhile because blah blah
geekspeak geekspeak, for which the answer will most likely be "no".

I'd love to use OCB, it's a really nice, elegant mode, but unfortunately
unless the usage conditions are "freely available without restrictions" I
can't.  And that's not from rabid freetardism, it's from pragmatism, it's too
risky legally.

Peter.