[CFRG] Review of draft-irtf-cfrg-voprf-12

[Julia Hesse <[e-mail]>]

Hi all,

this is a review of draft-irtf-cfrg-voprf-12.

Disclaimer: I did not implement the scheme, and hence did not go through 
the test vector section. I work with Stas Jarecki, Chris Wood and Hugo 
Krawczyk, whose works this draft is based upon, and Chris is an author 
of it.

Overall I find the draft in very good shape. There are only a few things 
I would like to see clarified in the document. Detailed comments follow.

- "Verifiable POPRF": the verifiability property is not optional in the 
draft, but the fact that it is sometimes called "verifiable POPRF" hints 
that it is. Why not avoid any confusion by calling it VPOPRF throughout 
the document?

- The introduction mentions POPRFs have been used for PPSS in JKK14, but 
that paper uses only VOPRFs explicitly and I cannot spot implicit use of 
a partially oblivious protocol in their PPSS construction.

- Section 1.3 introduces PrivateInput and PublicInput as the exact same 
data types. What distinguishes them? The terms Private and Public hint 
at something, but it seems never spelled out in the document.

- In general the distinction between "Input" and "Parameters" in the 
function descriptions confused me. What are the semantics here? First I 
thought Parameters are implementation-wide and fixed objects, like the 
Group, but then the OPRF key skS appears as a Parameter of 
BlindEvaluate. Since the document also hints that keys can be updated 
during the run of the protocol ("key rotation"), skS does not seem to be 
a long-term parameter to me. Sometimes both the terms Input and 
Parameter are  mixed, for example when "PublicInput contextString" 
appears under Parameters. Another example is in the flow diagram of 
POPRF, where both Inputs (info) and Parameters (pkS,skS) appear in 
parantheses after a party's name.
Overall it would be good to clarify why the function descriptions 
distinguish between "Inputs" and "Parameters", as otherwise implementors 
might interpret their own meaning to these terms.

- The document uses both "base point" and "group generator". Maybe unify?

- Member functions of the group are sometimes referred to as 
Group.function() and sometimes just as function(). Some of the 
appearances, e.g., of Order() in 4.1.4, do appear in the context of a 
group Group, so the write-up could be clarified by putting Group.Order() 
instead.

- First paragraph of 2.2.1 "k*C[i]==D[i] for each element in the list." 
Better "for each i in {1,...,m}".

- Explain the list notation []

- Section 3, protocol overviews: skS and pkS appear as input to the 
parties but are not used in the protocols. E.g., it should be 
BlindEvaluate(skS,blindedElement) instead of BlindEvaluate(blindedElement).

- Still protocol overviews: I find the term "evaluatedElement" computed 
by the server a bit misleading, as it sounds like the server is learning 
the evaluation. On the other hand I don't have a better idea. 
BlindedEvaluatedElement would indicate more precisely what happens, but 
is probably too long.

- "client and server augment the pkS and skS, respectively, using the 
info value": this could be modified to explain the (otherwise 
unexplained) "tweakedKey" term that appears in the protocol overview. 
Maybe "client and server tweak their pkS and skS, respectively, using 
the info value"?

- *If* I would implement this, I would wonder about Input "opaque 
seed[Ns]". Ns is an integer, and this seed appears to be a list of Ns 
opaque values. In the text it says "randomly generated seed". The seeds 
suggested in the test vector section do not appear very random to me ;) 
Not sure if this is underspecified or just common knowledge.

- The terms (functions?) OPRFServerContext, VOPRFClientContext etc. do 
not seem to be defined.

- "Recall that servers may batch multiple client inputs to 
BlindEvaluate." - Maybe one more sentence how this is done? Just 
repeated execution of BlindEvaluate and concatenating the 
evaluatedElements in the message to the client?

- "certain public inputs that map to invalid public keys for server 
evaluation." I could not parse "public key for server evaluation" here.

- Section 4.1.1 and following: some numbers are missing "bytes", e.g., 
the Nh values, L = 48,...

- I could not make any sense of 5.2, but again, not an implementor...

- Section 6, first paragraph, has one POPRF that should be VOPRF

- 6.1 Pseudorandomness: pull "for a random sampling of k" to the first 
part of the sentence.

- "with infinite compute" - infinite computing power?

- "Additionally, for the.... additional" - remove the first one?

- Partial obliviousness: I don't understand this definition. Everything 
but the last sentence are properties of any OPRF, as described already 
in the other properties. The sentence "Both client and server learn the 
public input (info)" does not seem to have any meaning, since info is 
*input* to both parties and hence they of course learn it. The partial 
obliviousness property rather seems to enforce usage of info in an 
evaluation.
I was also surprised that partial obliviousness is equivalent to 
unlinkability. Are OPRFs linkable, in the sense of linkability described 
in the draft?

- "One-More Gap Computational Diffie Hellman (CDH)" This is not what CDH 
usually stands for.

- Risking a few hits on my head: JKK14 does *not* give a security proof 
for the VOPRF protocol in Section 6.1. JKK14 requires session 
identifiers and is in the random oracle model. Unless, e.g., hash domain 
separation is put as a MUST in the draft, the analysis of JKK14 does not 
apply to the protocol in Section 6.1.

- "variant is based on" - are based on?

- In reference [SJKS17] typos in Jareckiy, Krawczykz

Best,
Julia