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

From: "Paterson Kenneth" <[email-masked]>
Date: Tue, 7 May 2019 15:44:54 +0000

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)

---

From: Rene Struik <[email-masked]>
Date: Tue, 7 May 2019 17:01:00 -0400

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:
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/cfrg

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

---

From: "Paterson Kenneth" <[email-masked]>
Date: Wed, 8 May 2019 07:34:19 +0000

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 <[email-masked]>
Date: Tuesday, 7 May 2019 at 23:01
To: Paterson Kenneth <[email-masked]>, CFRG <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
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

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.

Dear CFRG,

Thanks,

Kenny (for the chairs)

Cfrg mailing list

[email-masked]<mailto:[email-masked]>

--

email: [email-masked]<mailto:[email-masked]> | Skype: rstruik

---

From: Alex Davidson <[email-masked]>
Date: Thu, 9 May 2019 10:44:13 +0100

Hi all,

I’m one of the authors of this draft.

> 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).

The only hard dependency of this draft is on the specification of the hash-to-curve algorithm that is made in https://tools.ietf.org/html/draft-irtf-cfrg-hash-to-curve-03 <https://tools.ietf.org/html/draft-irtf-cfrg-hash-to-curve-03>. The dependency on the Ristretto draft is made only as a plausible cryptographic configuration for using OPRFs. We are happy to remove the dependency on Ristretto and specify a different set of ciphersuites focusing only on the NIST curves and others such as Curve25519, for example. In general, it would be useful for us to have a wider discussion with the community on what parameter/curve settings are suitable for our use-case.

> https://petsymposium.org/2018/files/papers/issue3/popets-2018-0026.pdf <https://petsymposium.org/2018/files/papers/issue3/popets-2018-0026.pdf>
Other applications that feature OPRFs as dependencies include password-protected secret-sharing (https://eprint.iacr.org/2014/650.pdf <https://eprint.iacr.org/2014/650.pdf>), password-authenticated key-exchange (https://tools.ietf.org/html/draft-krawczyk-cfrg-opaque-01 <https://tools.ietf.org/html/draft-krawczyk-cfrg-opaque-01>) and hiding password-storage (http://webee.technion.ac.il/~hugo/sphinx.pdf <http://webee.technion.ac.il/~hugo/sphinx.pdf>). In particular, the current version of the OPAQUE draft (draft-krawczyk-cfrg-opaque) lists draft-sullivan-cfrg-voprf as a dependency. There are also many applications in general secure computation research literature (such as constructions of protocols for private set intersection).

Thanks,
Alex

---

From: David Wong <[email-masked]>
Date: Tue, 14 May 2019 08:22:32 -0700

Hey all,

I’m very interested in the verifiability of the OPRF.
Note that OPAQUE also mentions this draft currently: https://tools.ietf.org/html/draft-krawczyk-cfrg-opaque-01 <https://tools.ietf.org/html/draft-krawczyk-cfrg-opaque-01>
I would be interested in knowing why OPAQUE doesn’t want to use a VOPRF

I support the adoption of this draft.

Cheers,
David

> On May 9, 2019, at 2:44 AM, Alex Davidson <adavidson=[email-masked]> wrote:
> 
> Hi all,
> 
>> https://petsymposium.org/2018/files/papers/issue3/popets-2018-0026.pdf <https://petsymposium.org/2018/files/papers/issue3/popets-2018-0026..pdf>

---

From: Richard Barnes <[email-masked]>
Date: Fri, 17 May 2019 11:01:34 +0200

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 <[email-masked]>
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
> ):
>
>
>
>
>
> slides:
> https://datatracker.ietf.org/meeting/101/materials/slides-101-cfrg-4-voprfs-00
>
> 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.
>
> 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:
>
>
>
> 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 <[email-masked]>
> *Date: *Tuesday, 7 May 2019 at 23:01
> *To: *Paterson Kenneth <[email-masked]>, CFRG <[email-masked]>
> *Cc: *"[email-masked]" <
> [email-masked]>
> *Subject: *Re: [Cfrg] Adoption call for draft-sullivan-cfrg-voprf
>
>
>
> Hi Kenny:
>
>
>
> 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
>
>
>
> and reviewing uses of cryptographic mechanisms, both for network security
> in general and for the IETF in particular.
>
> 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
>

---

From: Marek Jankowski <[email-masked]>
Date: Sat, 18 May 2019 05:09:11 +0200

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 <[email-masked]> wrote:

>> 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
>> general philosophy nowadays ("more is better" vs. "less is more", protocols
>> with wide applicability vs. specialized, etc, etc.)?
>>
>>
>>
>> Best regards, Rene
>>
>>
>>

---

From: Hugo Krawczyk <[email-masked]>
Date: Mon, 20 May 2019 16:48:44 -0400

I strongly support adopting   draft-sullivan-cfrg-voprf as a CFRG draft.  OPRFs
are finding very useful applications including those noted in the draft
(including  OPAQUE) and others. Defining the OPRFs in a dedicated RFC is
much better than having each application describe them separately. I sent
comments to the authors for their consideration and revision.

Hugo

On Tue, May 7, 2019 at 11:46 AM Paterson Kenneth <[email-masked]>
wrote:

> 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.
>

---

From: Hugo Krawczyk <[email-masked]>
Date: Mon, 20 May 2019 16:54:58 -0400

Hi David, to use a V-OPRF the client needs to store the public key Y=kG
corresponding to the server's OPRF key k. In the OPAQUE setting we do not
assume that the user carries any public key with her. The only information
the user carries is the password (and account information where to login).
This makes OPAQUE immune to PKI failures.

Hugo

On Tue, May 14, 2019 at 11:23 AM David Wong <[email-masked]>
wrote:

> Note that OPAQUE also mentions this draft currently:
> https://tools.ietf.org/html/draft-krawczyk-cfrg-opaque-01
> On May 9, 2019, at 2:44 AM, Alex Davidson <
> adavidson=[email-masked]> wrote:
>
> Hi all,
>
> The only hard dependency of this draft is on the specification of the
> hash-to-curve algorithm that is made in
> https://tools.ietf.org/html/draft-irtf-cfrg-hash-to-curve-03. The
> dependency on the Ristretto draft is made only as a plausible cryptographic
> configuration for using OPRFs. We are happy to remove the dependency on
> Ristretto and specify a different set of ciphersuites focusing only on the
> NIST curves and others such as Curve25519, for example. In general, it
> would be useful for us to have a wider discussion with the community on
> what parameter/curve settings are suitable for our use-case.
>
>
> *https://petsymposium.org/2018/files/papers/issue3/popets-2018-0026.pdf
> <https://petsymposium.org/2018/files/papers/issue3/popets-2018-0026...pdf>*
>
>
> Other applications that feature OPRFs as dependencies include
> password-protected secret-sharing (https://eprint.iacr.org/2014/650.pdf),
> password-authenticated key-exchange (
> https://tools.ietf.org/html/draft-krawczyk-cfrg-opaque-01) and hiding
> password-storage (http://webee.technion.ac.il/~hugo/sphinx.pdf). In
> particular, the current version of the OPAQUE draft
> (draft-krawczyk-cfrg-opaque) lists draft-sullivan-cfrg-voprf as a
> dependency. There are also many applications in general secure computation
> research literature (such as constructions of protocols for private set
> intersection).
>
> Thanks,
> Alex
>

---

From: Kobi Gurkan <[email-masked]>
Date: Fri, 24 May 2019 14:12:40 +0300

I support adopting the draft. VOPRFs, and especially ECVOPRFs, have 
interesting applications, such as Privacy Pass and variants of the idea 
involving blind token distribution for, e.g., authentication. There are 
some tricky parts in the protocol, so implementers of the protocol would 
benefit greatly from having a document describing a well-defined 
protocol description, secure instantiations (which describe components 
such as hash-to-curve) and security considerations.

---

From: David Wong <[email-masked]>
Date: Mon, 27 May 2019 16:15:19 -0700

> On May 20, 2019, at 1:54 PM, Hugo Krawczyk <[email-masked]> wrote:
> 
> Hi David, to use a V-OPRF the client needs to store the public key Y=kG corresponding to the server's OPRF key k. In the OPAQUE setting we do not assume that the user carries any public key with her. The only information the user carries is the password (and account information where to login). This makes OPAQUE immune to PKI failures. 
> 
> Hugo

Hey Hugo,

thank you for providing an answer to my question! Why are we assuming that the user does not carry the server’s public key? For some mobile client code, the application should be able to pin the server’s public key. For web, I’m not sure how this can be done besides using a PKI indeed.

Also, what are the consequences of not being able to verify the server’s operation? Intuitively it sounds like the server can target users and force them to use a weak key.

David

---

From: Hugo Krawczyk <[email-masked]>
Date: Tue, 28 May 2019 23:14:24 -0400

On Mon, May 27, 2019 at 7:15 PM David Wong <[email-masked]>
wrote:

> thank you for providing an answer to my question! Why are we assuming that
> the user does not carry the server’s public key? For some mobile client
> code, the application should be able to pin the server’s public key. For
> web, I’m not sure how this can be done besides using a PKI indeed.
>

It is fine if the user, for a given application, needs to carry a public
key. What I was saying is that OPAQUE does not require to do so. Just
having the password and basic account information is sufficient for OPAQUE
to work securely.

Also, what are the consequences of not being able to verify the server’s
> operation? Intuitively it sounds like the server can target users and force
> them to use a weak key.
>

In OPAQUE, if the user connects to the wrong server (by mistake, by
misconfiguration, by attack, or whatever reason), the password is not at
risk. The server will learn *nothing* about the password and a channel will
not be established since the server will not be able to authenticate to the
user (OPAQUE creates a mutually authenticated channel that only the user
with the correct password and the server with whom the account and password
were initially established can pass authentication).

Hugo