Re: [Cfrg] Adoption call for draft-sullivan-cfrg-voprf

Marek Jankowski <mjankowski309@gmail.com> Mon, 20 May 2019 14:20 UTC

Return-Path: <mjankowski309@gmail.com>
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 3F743120089 for <cfrg@ietfa.amsl.com>; Mon, 20 May 2019 07:20:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.748
X-Spam-Level:
X-Spam-Status: No, score=-0.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 yTcqUkZe_7Yz for <cfrg@ietfa.amsl.com>; Mon, 20 May 2019 07:20:18 -0700 (PDT)
Received: from mail-it1-x132.google.com (mail-it1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (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 2705A1201A8 for <cfrg@irtf.org>; Mon, 20 May 2019 07:20:18 -0700 (PDT)
Received: by mail-it1-x132.google.com with SMTP id u186so23392414ith.0 for <cfrg@irtf.org>; Mon, 20 May 2019 07:20:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qyVwx55QergNWTlzFb+V/U3XKBLWTU7sDFq/mfpT1xs=; b=lK0wSpkJXTlDDfqJaJGf+AbJieACwLQNZb7OM3Xz/6y9MAlFjVT60FcnCOYBvjjlH0 IA+5F3e/uhJ6HtYpe1ObSvhyY+wotl+NK59mW6G86yhUjvTSUkRTiKW/4u4Vzzt9Ghwl qjOfE3v/dyYCrbGr8d5/4sa0DPVgJCK7p62nQalX2athTcI6jdAWP/KpH4xmiG7jB7lk wqixlxg1mX5KLEbMnMLd/hwo8/8uOYTYwujClKVOjHPtWJWmLDJCNCF1YxxKQ8B0pulb qzPe+6s2i42UMNoWhl7FIDyVfdjmSA4OKGVbAQTfMm+nsyHsVS6tDSajcpDPzl7I7LWe 8Ajw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qyVwx55QergNWTlzFb+V/U3XKBLWTU7sDFq/mfpT1xs=; b=O4AiYso3QQzKF6dGEe3MauBY2TV79q+fuNWx3vXCaS9a76Df7EDkd3V0uzdr1X0hVn jJwY8T0fH2B0+Ztq8WpW4xRfYNi7OfxaKwDAbHQuX9YoBvWI91tmmwsSOSIu9+UpERre Qin/iNsEz6UTTRFyv9l0b0C7Gl/lR7x22DgwMDcODAchKkY8B0tGD2Q7Ly+sVYsQ+Jy/ BBak5aTIMCVvH73EugJ4QCcPRN3zjbI3JAPmC7AErbAHgzJ0Pl4vgWPJNOIUJkUMI1pu o/zaKNTpTN22gJGUXkP2j6lziTgvL0kbEspQ0hGxOsal5un7qoDgYoCjgtZZMh9N9PFv nUqg==
X-Gm-Message-State: APjAAAWYyBxn/GdfZq40IVe18hNMw+a1QzQv8wIW2TyiUIp38z7DOugA UYEkxcjLLuA7vVPix/UTB5dA8ARnJIivE/DpFCw=
X-Google-Smtp-Source: APXvYqzkeHgJ/gBieVn6lBqa5VPI8UFmyOTTqlR3QGGdRcCLhyarY/tfEQmqwd/v4dmASOTKpgz7czHUNjpk28rKk94=
X-Received: by 2002:a24:c4d7:: with SMTP id v206mr28091954itf.102.1558362017166; Mon, 20 May 2019 07:20:17 -0700 (PDT)
MIME-Version: 1.0
References: <54235333-9FEA-4543-93B6-2D4B1C8FCC2D@inf.ethz.ch> <0a67411b-9a2d-9e08-ca06-08ea938c0c89@gmail.com> <B62E70D5-9BAE-4332-8CE4-4AB0E3B229C8@inf.ethz.ch> <CAL02cgSm5ZcMX00kOoGK5wP6dEctJLTJd=K18_-imCdSYsiqzg@mail.gmail.com>
In-Reply-To: <CAL02cgSm5ZcMX00kOoGK5wP6dEctJLTJd=K18_-imCdSYsiqzg@mail.gmail.com>
From: Marek Jankowski <mjankowski309@gmail.com>
Date: Sat, 18 May 2019 05:09:11 +0200
Message-ID: <CAMCcN7Tr3MjV=7F978PQtkFw0WMTyPfAhr287DkNt-C6u4Petg@mail.gmail.com>
To: Richard Barnes <rlb@ipv.sx>
Cc: Paterson Kenneth <kenny.paterson@inf.ethz.ch>, CFRG <cfrg@irtf.org>, "draft-sullivan-cfrg-voprf.authors@ietf.org" <draft-sullivan-cfrg-voprf.authors@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000076f8bf0589526eaf"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/nPDayhfr4yAJuiyp6cxyFqjYLSw>
Subject: Re: [Cfrg] Adoption call for draft-sullivan-cfrg-voprf
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, 20 May 2019 14:20:22 -0000

Hello,

In Section 2 (Background) an example of a blind signature scheme is given
for RSA signature.
Please note that the scheme is described somewhat incorrectly: V cannot
perform step 3, as he needs r^(-1) (mod phi(N)) which is, I believe,
equivalent to factoring N (as knowledge of N and phi(N) leads to factoring
of N).
A better solution would be one where V sends m' = m * r^e, receives from P
s' = (m * r^e)^d = m^d * r, and computes s = s' * r^(-1) (mod N).

Marek.

On Fri, May 17, 2019 at 11:02 AM Richard Barnes <rlb@ipv.sx> wrote:

> I agree with Kenny’s analysis here.
>
> This seems like a problem area that has overlap a few applications within
> the usual CFRG customer space (IETF, but also internet infrastructure
> things more broadly).  I have reviewed the document, and it seems like a
> reasonable starting point.  I support its adoption.
>
> —Richard
>
>
> On Wed, May 8, 2019 at 09:36 Paterson Kenneth <kenny.paterson@inf.ethz.ch>
> wrote:
>
>> Hi Rene,
>>
>>
>>
>> You’re right that there’s not been much discussion on the list about this
>> draft. It was presented at IETF 101 and there was some discussion in person
>> at the meeting; below is a relevant extract from the minutes of the meeting
>> (
>> https://datatracker.ietf.org/meeting/101/materials/minutes-101-cfrg-00.pdf
>> ):
>>
>>
>>
>>
>>
>> Verifiable Oblivious Pseudorandom Functions (VOPRFs)
>>
>> ====================================================
>>
>> presenter: Nick Sullivan
>>
>> slides:
>> https://datatracker.ietf.org/meeting/101/materials/slides-101-cfrg-4-voprfs-00
>>
>> draft: https://datatracker.ietf.org/doc/draft-sullivan-cfrg-voprf/
>>
>>
>>
>> Sullivan introduced a draft that constructs VOPRF based on Elliptic
>> Curves.
>>
>>
>>
>> Q: (): What is the contents of the draft -- I didn't read it.  You
>> discussed several crypto primitives.
>>
>> A: (Sullivan): A generic description of VOPRFs and a specific
>> instantiation.
>>
>>
>>
>> Q: (Melnikov): What are you interest in having happen to this draft?
>>
>> A: (Sullivan): CFRG adoption.
>>
>> A: (Paterson): How do you you see this and the above draft progressing
>> given the dependency?
>>
>> A: (Sullivan): They can proceed in parallel.
>>
>>
>>
>> Q: (Gillmor): One of the concerns is how the key remains constant?
>>
>> A: (Sullivan): You're noting the tagging attack.  The signer’s public key
>> needs public verifiability -- maybe a transparency log or consensus
>> protocol.  Those are outside of the scope of the draft.
>>
>> A: (Gillmor): I was hoping to hear that they should be separate.
>>
>> A: (Sullivan): We'll add language to the draft.
>>
>> A: (Melnikov): Let's take further discussion to the mailing list.
>>
>>
>>
>>
>>
>> Perhaps the draft’s authors can clarify here on the extent to which there
>> is a dependency on other drafts, especially the ristretto draft (which is
>> not a CFRG document, currently).
>>
>>
>>
>> I think this draft does fit with the CFRG charter, in that VOPRFs are an
>> emerging cryptographic mechanism that at least some people here see as
>> being useful in contexts traditionally associated with IETF. Again, the
>> authors of the draft can explain their intended applications better than
>> me, but I think a good starting point if you are interested in knowing more
>> would be:
>>
>>
>>
>> https://petsymposium.org/2018/files/papers/issue3/popets-2018-0026.pdf
>>
>>
>>
>>
>>
>> My personal take on the “CFRG philosophy” is that we should respond to
>> the interests and needs of the CFRG community, interpreted broadly. So if
>> people express a willingness to work on something, there is general support
>> for adoption, and the technical content is cryptographic and useful in
>> contexts traditionally associated with IETF, then we should do it. Of
>> course, the previous sentence is deliberately imprecise, and a case-by-case
>> judgement call on the part of the chairs is needed. The mechanism of having
>> a call for adoption provides key input to that decision-making process.
>>
>>
>>
>> I hope this helps – happy to discuss further of course, but perhaps the
>> more general discussion should be on a different thread to this adoption
>> call.
>>
>>
>>
>> Best wishes,
>>
>>
>>
>> Kenny
>>
>>
>>
>>
>>
>> *From: *Rene Struik <rstruik.ext@gmail.com>
>> *Date: *Tuesday, 7 May 2019 at 23:01
>> *To: *Paterson Kenneth <kenny.paterson@inf.ethz.ch>ch>, CFRG <cfrg@irtf.org>
>> *Cc: *"draft-sullivan-cfrg-voprf.authors@ietf.org" <
>> draft-sullivan-cfrg-voprf.authors@ietf.org>
>> *Subject: *Re: [Cfrg] Adoption call for draft-sullivan-cfrg-voprf
>>
>>
>>
>> Hi Kenny:
>>
>>
>>
>> I had some trouble finding recent discussions on this document. The
>> document seems to have dependencies on other drafts (e.g., Ristretto) for
>> which it is very hard to find any discussion either (and are not that easy
>> to read ). If you could point to this, that would be great.
>>
>>
>>
>> Could you explain how this fits within CFRG's charter? What is the
>> general philosophy nowadays ("more is better" vs. "less is more", protocols
>> with wide applicability vs. specialized, etc, etc.)?
>>
>>
>>
>> Best regards, Rene
>>
>>
>>
>> [excerpted from https://datatracker.ietf.org/rg/cfrg/about/]
>>
>>
>>
>> The Crypto Forum Research Group (CFRG) is a general forum for discussing
>> and reviewing uses of cryptographic mechanisms, both for network security
>> in general and for the IETF in particular.
>>
>> The CFRG serves as a bridge between theory and practice, bringing new
>> cryptographic techniques to the Internet community and promoting an
>> understanding of the use and applicability of these mechanisms via
>> Informational RFCs (in the tradition of, e.g., RFC 1321 (MD5) and RFC 2104
>> (HMAC). Our goal is to provide a forum for discussing and analyzing general
>> cryptographic aspects of security protocols, and to offer guidance on the
>> use of emerging mechanisms and new uses of existing mechanisms. IETF
>> working groups developing protocols that include cryptographic elements are
>> welcome to bring questions concerning the protocols to the CFRG for advice.
>>
>> Meetings and Membership
>>
>> The CFRG meetings, membership, and mailing list are open to all who wish
>> to participate.
>>
>>
>>
>> On 5/7/2019 11:44 AM, Paterson Kenneth wrote:
>>
>> Dear CFRG,
>>
>>
>>
>> This email starts a 2-week adoption call for:
>>
>>
>>
>> https://datatracker.ietf.org/doc/draft-sullivan-cfrg-voprf/
>>
>> Oblivious Pseudorandom Functions (OPRFs) using Prime-Order Groups
>>
>>
>>
>> Please give your views on whether this document should be adopted as a CFRG draft, and if so, whether you'd be willing to help work on it/review it.
>>
>>
>>
>> (We have two other adoption calls running concurrently; they will end this Friday, May 10th.)
>>
>>
>>
>> Thanks,
>>
>>
>>
>> Kenny (for the chairs)
>>
>>
>>
>>
>>
>> _______________________________________________
>>
>> Cfrg mailing list
>>
>> Cfrg@irtf.org
>>
>> https://www.irtf.org/mailman/listinfo/cfrg
>>
>>
>>
>> --
>>
>> email: rstruik.ext@gmail.com | Skype: rstruik
>>
>> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
>>
>> _______________________________________________
>> Cfrg mailing list
>> Cfrg@irtf.org
>> https://www.irtf.org/mailman/listinfo/cfrg
>>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg
>