[Cfrg] Questions regarding new draft-irtf-cfrg-voprf-00 from A. Davidson, N. Sullivan and Chr. Wood // Will we need to consider IPR issues here?

Björn Haase <bjoern.m.haase@web.de> Wed, 10 July 2019 20:24 UTC

Return-Path: <bjoern.m.haase@web.de>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 4454412012A for <cfrg@ietfa.amsl.com>; Wed, 10 Jul 2019 13:24:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=web.de
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id oJiH9wkY3kbg for <cfrg@ietfa.amsl.com>; Wed, 10 Jul 2019 13:24:49 -0700 (PDT)
Received: from mout.web.de (mout.web.de []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AF1212004A for <cfrg@irtf.org>; Wed, 10 Jul 2019 13:24:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=dbaedf251592; t=1562790275; bh=8h8ny5ISDRUsOLhRqe7WSP3ItxHpcxorCeDJaPba4X4=; h=X-UI-Sender-Class:From:Subject:To:Date; b=aphugVh2HjB06mSj+vmwaZKJJokdD7tIGr3w5rZtPTAk57kO1WBZQvYtidFafJIAy C1MNmYS/0pcWp/+IP+CkIx8R3rwl2Vi6njdzPWGp8wTpfHFhDPTYt/smMMvhoBfvbb nlmnTZ2NT04iNnFn4tVYxysHwEHDD2extG+6yL8I=
X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9
Received: from [] ([]) by smtp.web.de (mrweb101 []) with ESMTPSA (Nemesis) id 0MddBI-1i8LoE3K0a-00PM3t; Wed, 10 Jul 2019 22:24:35 +0200
From: =?UTF-8?Q?Bj=c3=b6rn_Haase?= <bjoern.m.haase@web.de>
To: adavidson@cloudflare.com, cfrg@irtf.org, nick@cloudflare.com, cawood@apple.com
Message-ID: <ab7423fd-81db-072d-37ef-09f9c51b6d61@web.de>
Date: Wed, 10 Jul 2019 22:24:36 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:p0NBImoqT/rsn4Grf/u1IfWFHMXlYobzZlSZ4X8hEV32V9v0Rrg Sk8HeD/RLrx5kpXWbaNrYbzoLxsBbVvPQHqKt3qR7gQxmY/n2InIlJkrxwj7VJfh4LanS+c 1iuqTP18SBqR15nh7SrM4WqqpshUgmPWmnEKLlHyvr/lOfbOzb/gS5Y1JHhu0yzGRqXt2B2 P+LR9S9TePLCW7cnIIN7Q==
X-UI-Out-Filterresults: notjunk:1;V03:K0:zNGqkH7Py2Q=:tVMkH0xNlAsVR/41bBlEkb XlvQ3PIPP31pLfKgVca9eGkluq/Vu3M5cffhWUZccByPaalpvWC7N8bF/2R4CreAmg9us3T4X 7NXIZS7JR+rUEpWtnu7ss1zdXedUvDoUbJSR1XXTDUCXWKPtY8HBVD1aGm0OZi5yUE1O65lUb 5f/i3HJMUPiCZkpFyEZYU56ED9Vej3g3ZOxTkYLKJ/GayUvH0OedpD3GuqdYOl/Kd6iVyqXbd RawzcNAwj+YFEAGvrhlTYUNlL8s0ZEcfTEAzjBslAzy/cWjvDZjm9S4lM4GYDT0mGsOFENB2p nRBzdlWxfKKjSWQPA7RaXT/YygDbbNqgfTusgtaiIS4pHXqJFJs9D3/Nka1IkvetfaMFyd8/W p3oteSow8wNLNwI4CiSaGyLIdmV/9VPnHDGeZdx4xoUBHfhiLwcoUNYgsW7oswg5LLCP/HT+m W0lmTvYv7eOzgYVf707HE5bvPU928FWCi7y34LDBRfX3UHa0c3bp0OwCTKuUQj5HnsXm967t8 N8pLbcw4LTx5MNdZIPov2U0eqDbeS0TaWo19R6EBHpilrWVTnJA1sbPMPdwr7r2bjQpXvdLEw rkQtqLOYyprQyF3s+dUjZMF9JvKhL2uRonPcfay0LE+L5gKzX+wwJGVscJjUe01oC+Z+ceKcL V+MbdO68lzH2bDXlfbV0EmizZUaid1IH+YUUAQm4lCJjk9oQFY8HiltyHNdHixWNLL4T4TZOs dl7AQ9xbw/5KA7C2A1aqX8yYE2WuqUN2LPp5/x9XdimB9SaHPaT+/6BzJABwE18jyOvliR6Gw 3f6lHWzrQk4YsNcnHKSbQTHqO6r2yWEd6xBjDZ1DLlaRQNmfIDwvP6NvAaYKWKLzDL49wQcRw w0iQQ1LRArE/jbzCY3qOGwQVDYUAfgS3JwaO4fBf5sRVtBCzGatJBTvgTAZF65qWlRKrUiEyw fvXcAfpt1LgBPaSBMZQIVPSBmPTqWf9iPLvyDyOUiXV8Ql6PE1+M/2dx9U/KZEAoWaXItF0qc 7LjsD7FN2Z+tvqEWYIG1SG80L2biqsS7wZb5LAQTJsFgpFoxniPfYE9Rv/jOFULkX6QPfEf6p u3PV05TeUO/zjBCpwpyW4ebmxjX96hNJCn0
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/6HsHRRe79ONhiYOxlHu2KQtda_E>
Subject: [Cfrg] Questions regarding new draft-irtf-cfrg-voprf-00 from A. Davidson, N. Sullivan and Chr. Wood // Will we need to consider IPR issues here?
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: Wed, 10 Jul 2019 20:24:51 -0000

Hello to all,

I have just read your recent VOPRF draft from
"https://tools.ietf.org/html/draft-irtf-cfrg-voprf-00" and first, I'd
like to thank the authors for their work. I believe that the OPRF
constructions might become a central primitive for password-based
operations such as PAKE.

In this mail, I would like to raise an unpleasant but maybe un-avoidable
topic: Intellectual property rights regarding efficient hashing to
elliptic curve groups.

For the constructions "OPAQUE" and "strong AuCPace" that Hugo and I did
nominate as candidates for the CFRG PAKE selection process the OPRF is
one important building block and used for keeping the salt value
confidential. In my opinion it is crucial to review and address possible
patent pitfalls regarding the OPRF construction. I also think that it
might be a good idea to prepare workarounds that we could pull out of
our desk -- in case of need.

In the VOPRF draft from July 7th it is suggested to use the
H2C-P256-SHA256-SSWU primitive for NIST P-256. I fully agree with the
authors that using the algorithm SWU *is* the right thing to do security
and efficiency-wise.

However, having worked on PAKE protocols for quite some time, I have
learned the painful lesson, that we need to carefully consider patents
here. I am aware of a patent family claiming priority from FR2946819B1
that claims rights in the context of SWU (for a version in english
language, see e.g. EP2443787B1).  The anticipated expiration will be in
2030. In my opinion this (or possibly other) IPRs are the main
motivation for seemingly strange work-arounds, e.g. in the PACE protocol
constructed by Bender, Kügler and FIschlin as used in electronic travel
documents. Also, I believe that the fact that the SPAKE, TBPEKE and
SESPAKE protocol families requires a trusted setup (with elliptic curve
points having an unknown discrete log relationship) might have come in
solely as part of a patent circumvention strategy.

In order to avoid a mis-understanding. I don't want to state that I
believe that H2C-P256-SHA256-SSWU is rightfully covered by patents.
(Moreover, I am convinced that H2C-Curve25519-SHA512-Elligator2 is not
covered by IPR.) However, I believe that we might seriously consider
this aspect and develop a clear strategy and opinion how to deal with
IPR. I think that it is important to specifically consider the case of
the important curve NIST-P-256.

I would therefore like to ask you whether the IPR aspect has been
considered already and I would like to hear your opinions.

I am not a lawyer, but I believe that there might be circumventions for
the patents also for SWU use on P-256. Still in my own proposal for the
CFRG PAKE selection process, I considered it important to have a
backup-solution readily available for the event that an in
depth-analysis comes to the conclusion that we won't get around the
patent. My suggestion for this case is to use the SPAKE2/TBPEKE/SESPAKE
circumvention approach (and live with the unpleasent need for a trusted
setup of some elliptic curve points).

Last week I have worked on the security proof for the OPRF extension for
"strong AuCPace" and came to the conclusion that (at least for the PAKE
use-case of strong AuCPace) the Diffie-Hellman OPRF construction should
remain secure also when replacing the hash2point(x) result with a point
(C^x * D) with two points with unknown discrete-log relationship. (As
stated in the paper, this will come with slight reductions regarding the
security guarantees due to the trusted setup and an emerging committment
problem in the UC proof restricting security to static adversaries).

I have added the proof as Appendix C in the AuCPace paper
(https://eprint.iacr.org/2018/286) and the patent-circumvention
construction is described in Appendix A. I did not carry out the proof
for the general case, but I believe that the circumvention approach from
Appendix A might also work with Hugo's OPAQUE nomination.

I would really your feedback on these points and again a "sorry" for
bringing up this rather unpleasent topic :-(.