I have now uploaded a new version that should address most of the issues as per my previous reply.

Dear Burt,

Sincerely,<= /div>

> Technical Comments

> T1. General: The specific= ation frequently computes one-octet constants as an explicit algorithm step= , e.g., "one_string =3D 0x01 =3D I2OSP(1, 1), a single octet with valu= e 1".=C2=A0 Suggest defining the notation "0x" as in [RFC801= 7] and then using constants such as 0x01 directly in the algorithms rather = than computing them, to avoid the superfluous steps. (The ECVRF algorithms = use int_to_string which is suite-specific, but the single-octet output is t= he same for all suites.)

Done [in this commit](https://github.com/cfrg/draft-irtf-cfrg-vrf/commit/ee5fd0eb353d5d53= c09bc274bbd796fd0de762d5)

> T2. Sec. 4, "Parameters used= :" / "K - RSA private key": Suggest to add note that represe= ntation of K is implementation-dependent

Done [in this commit](https://github.com/cfrg/draft-irtf-cfrg-vrf/commit/= 7d6cf6e49277db5c546e0179e3f36da4b38f02c9)

> T3. Sec. 4.3, ste= p 2: Suggest adding error handling for the case that s >=3D n, in which = case RSAVP1 will return "signature representative out of range" a= nd the algorithm should output "INVALID"

=C2=A0Done [in th= is commit](https://github.com/cfrg/draft-irtf-= cfrg-vrf/commit/7d6cf6e49277db5c546e0179e3f36da4b38f02c9)

> T= 4. Sec. 4.3, step 3: Suggest adding error handling for the case that m >= =3D 2^(8(k-1)), in which case I2OSP will return "integer too large&quo= t; and the algorithm should output "INVALID".=C2=A0 Alternatively= , instead of computing EM from m and comparing EM to EM', compute m'= ; from EM' (as m' =3D OS2IP(EM')) and compare m to m'

**Done [in this commit]( https://github.com/cf=
rg/draft-irtf-cfrg-vrf/commit/7d6cf6e49277db5c546e0179e3f36da4b38f02c9)=
**

> T5. Sec. 5, "Fixed options" / "2n": Sugges= t adding an explanation why n is introduced this way. Based on the security= analysis in [PWHVNRG17], n appears to correspond to the security level $\e= ll$, as both are the lengths of the challenge c (in octets vs. bits). It= 9;s not clear why the parameter n is defined here in terms of the length of= a field element, rather than the size of group G. Although the security le= vel is affected by the size of the field, it is not necessarily related to = the length in octets of a field element (if this is understood to be the le= ngth if the octet string representing the field element, which may be imple= mentation-defined). Also, the choice of field is not discussed outside this= section of the document, although it is implied by the selection of curve = parameters elsewhere. Suggest instead to introduce a new parameter such as = cLen for the length in octets of the challenge c, and then in the security = considerations, comment on the relationship between cLen, qLen, hash functi= on output sizes, and security levels, much as is done in [PWHVNRG17].

**Introduced appropriate length parameters and included a discussion of sec=
urity levels [in this commit](https://github.c=
om/cfrg/draft-irtf-cfrg-vrf/commit/ef6e178af4fa088ad7b2ce3c5aac685236e835de=
)**

> T6. Sec. 5, "Fixed options:": Suggest adding EC= VRF_hash_points as another fixed option after ECVRF_nonce_generation. (See = comment below regarding the name of this technique.)

Agree with rena= ming this technique (see below, T11). Decided not to list as a fixed option= , because fixed options are specified in a ciphersuite, but there is no rea= son to specify it as part of the ciphersuite. Just like ECVRF_prove and ECV= RF_verify, it calls functions that are specified as part of the ciphersuite= , but it itself does not need to be specified as part of the ciphersuite.

> T7. Sec. 5.4.1.1, "Fixed option:" / "arbitrary_st= ring_to_point" (and elsewhere): =C2=A0The term "arbitrary" i= s a misnomer in that it is applied to a string that has already been hashed= . Moreover, one of the two options supported for this function in Sec. 5.5 = requires the string to be exactly 32 octets, and the other requires it to b= e at least 32 octets (in a suite that uses SHA-512, so the string will be e= xactly 64 octets). This contrasts with [PWHVNRG17]'s idea in Appendix A= of "a hash function H1 that maps arbitrary-length strings to points o= n an elliptic curve". Indeed, the "hash to curve" functions = in the document are the actual "arbitrary string to point" mappin= gs. One possible solution would be to replace "arbitrary_string_to_poi= nt" with a newly defined "encode", following the model given= by 5.4.1.2. "string_to_hash" would be computed as "suite_st= ring || one_string || PK_string || alpha_string || ctr_string || zero_strin= g", i.e., step 6B without the hashing, and passed to "encode"= ;. Instantiations of the "encode" option would be defined in Sec.= 5.5.

>

> An instantiation would include both the hashing and t= he existing conversion of the hash value to an elliptic curve point.

=C2=A0Renamed "arbitrary_string_to_point" to "interpret= _hash_value_as_a_point" [in this commit](= https://github.com/cfrg/draft-irtf-cfrg-vrf/commit/577972f341bf530330915eb0= b8838f953a6fa9e6)

=C2=A0> T8. Sec. 5.4.2: After "not com= patible with each other", suggest adding "and are intended for sp= ecific suite(s)".

=C2=A0Rephrased [in this commit](https://github.com/cfrg/draft-irtf-cfrg-vrf/commit/577972f= 341bf530330915eb0b8838f953a6fa9e6)

> T9. Sec. 5.4.2.1 (also 5= .4.2.2), "Output:" / "k": Suggest adding "nonce&qu= ot; before "an integer" to clarify purpose of k.

Done [in = this commit](https://github.com/cfrg/draft-irt= f-cfrg-vrf/commit/577972f341bf530330915eb0b8838f953a6fa9e6)

>= T10. Sec. 5.4.2.1, next to last para: Suggest adding a note that qlen, the= length in bits of q in RFC6979, is not to be confused with qLen, the lengt= h in octets of q in this document.

=C2=A0Done [in this commit](https://github.com/cfrg/draft-irtf-cfrg-vrf/commit/= 577972f341bf530330915eb0b8838f953a6fa9e6)

> T11. Sec. 5.4.3 (= and elsewhere): Suggest redefining "ECVRF_hash_points" as "E= CVRF_challenge_generation", limiting to four inputs (H, Gamma, U, and = V), and labeling output as "challenge value" rather than "ha= sh value". Rationale: ECVRF_hash_points is only used in this document = for mapping the four specified inputs to the challenge c, so it is similar = to ECVRF_nonce_generation in its limited purpose. The suggested change does= not affect the value computed by the function on the specified inputs, onl= y the way the function is specified.=C2=A0 The benefit of the change is tha= t it simplifies implementation. In particular, implementations only need to= be able to handle four points, not an arbitrary number M. Calls to the alg= orithm would need to be updated similarly. (If the function is not redefine= d as suggested here, then a note should be added to indicate that implement= ations MUST be able to handle the case M =3D 4; other cases are optional.)<= br>

Done [in this commit](https://github.co= m/cfrg/draft-irtf-cfrg-vrf/commit/577972f341bf530330915eb0b8838f953a6fa9e6<= /a>)

> T12. Sec. 7.6: Suggest moving the final sentence to its ow= n section, titled "Dependence of challenge on generator and public key= ". The sentence explains why the challenge c still depends on all six = points (B, H, Y, Gamma, U, and V) as per the formal specification in [PWHVN= RG17], rather than just the four points input to ECVRF_hash_points. This di= scussion is important from a security proof perspective and it is separate = from the prehashing considerations. Suggest adding "via the point H&qu= ot; to the end of the sentence.

Done [in this commit](https://github.com/cfrg/draft-irtf-cfrg-vrf/commit/577972f34= 1bf530330915eb0b8838f953a6fa9e6)

> Editorial Comments

=

--00000000000067572d05d5e2a0a4--
From nobody Wed Jan 19 06:08:14 2022
Return-Path: Thank you f=
or your detailed and thoughtful comments. We have addressed them all and fe=
el that the draft has improved as a result. The new version is here https://github.com/cfrg/dr=
aft-irtf-cfrg-vrf.

Details on how we have addr=
essed the specific comments are below.

To others w=
ho have submitted comments that we have not yet addressed: we are working t=
hrough them and will respond shortly. Thank you!

=C2=A0Sincerely,<= /div>

=C2=A0Leo

> Technical Comments

> T1. General: The specific= ation frequently computes one-octet constants as an explicit algorithm step= , e.g., "one_string =3D 0x01 =3D I2OSP(1, 1), a single octet with valu= e 1".=C2=A0 Suggest defining the notation "0x" as in [RFC801= 7] and then using constants such as 0x01 directly in the algorithms rather = than computing them, to avoid the superfluous steps. (The ECVRF algorithms = use int_to_string which is suite-specific, but the single-octet output is t= he same for all suites.)

Done [in this commit](https://github.com/cfrg/draft-irtf-cfrg-vrf/commit/ee5fd0eb353d5d53= c09bc274bbd796fd0de762d5)

> T2. Sec. 4, "Parameters used= :" / "K - RSA private key": Suggest to add note that represe= ntation of K is implementation-dependent

Done [in this commit](https://github.com/cfrg/draft-irtf-cfrg-vrf/commit/= 7d6cf6e49277db5c546e0179e3f36da4b38f02c9)

> T3. Sec. 4.3, ste= p 2: Suggest adding error handling for the case that s >=3D n, in which = case RSAVP1 will return "signature representative out of range" a= nd the algorithm should output "INVALID"

=C2=A0Done [in th= is commit](https://github.com/cfrg/draft-irtf-= cfrg-vrf/commit/7d6cf6e49277db5c546e0179e3f36da4b38f02c9)

> T= 4. Sec. 4.3, step 3: Suggest adding error handling for the case that m >= =3D 2^(8(k-1)), in which case I2OSP will return "integer too large&quo= t; and the algorithm should output "INVALID".=C2=A0 Alternatively= , instead of computing EM from m and comparing EM to EM', compute m'= ; from EM' (as m' =3D OS2IP(EM')) and compare m to m'

> T5. Sec. 5, "Fixed options" / "2n": Sugges= t adding an explanation why n is introduced this way. Based on the security= analysis in [PWHVNRG17], n appears to correspond to the security level $\e= ll$, as both are the lengths of the challenge c (in octets vs. bits). It= 9;s not clear why the parameter n is defined here in terms of the length of= a field element, rather than the size of group G. Although the security le= vel is affected by the size of the field, it is not necessarily related to = the length in octets of a field element (if this is understood to be the le= ngth if the octet string representing the field element, which may be imple= mentation-defined). Also, the choice of field is not discussed outside this= section of the document, although it is implied by the selection of curve = parameters elsewhere. Suggest instead to introduce a new parameter such as = cLen for the length in octets of the challenge c, and then in the security = considerations, comment on the relationship between cLen, qLen, hash functi= on output sizes, and security levels, much as is done in [PWHVNRG17].

> T6. Sec. 5, "Fixed options:": Suggest adding EC= VRF_hash_points as another fixed option after ECVRF_nonce_generation. (See = comment below regarding the name of this technique.)

Agree with rena= ming this technique (see below, T11). Decided not to list as a fixed option= , because fixed options are specified in a ciphersuite, but there is no rea= son to specify it as part of the ciphersuite. Just like ECVRF_prove and ECV= RF_verify, it calls functions that are specified as part of the ciphersuite= , but it itself does not need to be specified as part of the ciphersuite.

> T7. Sec. 5.4.1.1, "Fixed option:" / "arbitrary_st= ring_to_point" (and elsewhere): =C2=A0The term "arbitrary" i= s a misnomer in that it is applied to a string that has already been hashed= . Moreover, one of the two options supported for this function in Sec. 5.5 = requires the string to be exactly 32 octets, and the other requires it to b= e at least 32 octets (in a suite that uses SHA-512, so the string will be e= xactly 64 octets). This contrasts with [PWHVNRG17]'s idea in Appendix A= of "a hash function H1 that maps arbitrary-length strings to points o= n an elliptic curve". Indeed, the "hash to curve" functions = in the document are the actual "arbitrary string to point" mappin= gs. One possible solution would be to replace "arbitrary_string_to_poi= nt" with a newly defined "encode", following the model given= by 5.4.1.2. "string_to_hash" would be computed as "suite_st= ring || one_string || PK_string || alpha_string || ctr_string || zero_strin= g", i.e., step 6B without the hashing, and passed to "encode"= ;. Instantiations of the "encode" option would be defined in Sec.= 5.5.

>

> An instantiation would include both the hashing and t= he existing conversion of the hash value to an elliptic curve point.

=C2=A0Renamed "arbitrary_string_to_point" to "interpret= _hash_value_as_a_point" [in this commit](= https://github.com/cfrg/draft-irtf-cfrg-vrf/commit/577972f341bf530330915eb0= b8838f953a6fa9e6)

=C2=A0> T8. Sec. 5.4.2: After "not com= patible with each other", suggest adding "and are intended for sp= ecific suite(s)".

=C2=A0Rephrased [in this commit](https://github.com/cfrg/draft-irtf-cfrg-vrf/commit/577972f= 341bf530330915eb0b8838f953a6fa9e6)

> T9. Sec. 5.4.2.1 (also 5= .4.2.2), "Output:" / "k": Suggest adding "nonce&qu= ot; before "an integer" to clarify purpose of k.

Done [in = this commit](https://github.com/cfrg/draft-irt= f-cfrg-vrf/commit/577972f341bf530330915eb0b8838f953a6fa9e6)

>= T10. Sec. 5.4.2.1, next to last para: Suggest adding a note that qlen, the= length in bits of q in RFC6979, is not to be confused with qLen, the lengt= h in octets of q in this document.

=C2=A0Done [in this commit](https://github.com/cfrg/draft-irtf-cfrg-vrf/commit/= 577972f341bf530330915eb0b8838f953a6fa9e6)

> T11. Sec. 5.4.3 (= and elsewhere): Suggest redefining "ECVRF_hash_points" as "E= CVRF_challenge_generation", limiting to four inputs (H, Gamma, U, and = V), and labeling output as "challenge value" rather than "ha= sh value". Rationale: ECVRF_hash_points is only used in this document = for mapping the four specified inputs to the challenge c, so it is similar = to ECVRF_nonce_generation in its limited purpose. The suggested change does= not affect the value computed by the function on the specified inputs, onl= y the way the function is specified.=C2=A0 The benefit of the change is tha= t it simplifies implementation. In particular, implementations only need to= be able to handle four points, not an arbitrary number M. Calls to the alg= orithm would need to be updated similarly. (If the function is not redefine= d as suggested here, then a note should be added to indicate that implement= ations MUST be able to handle the case M =3D 4; other cases are optional.)<= br>

Done [in this commit](https://github.co= m/cfrg/draft-irtf-cfrg-vrf/commit/577972f341bf530330915eb0b8838f953a6fa9e6<= /a>)

> T12. Sec. 7.6: Suggest moving the final sentence to its ow= n section, titled "Dependence of challenge on generator and public key= ". The sentence explains why the challenge c still depends on all six = points (B, H, Y, Gamma, U, and V) as per the formal specification in [PWHVN= RG17], rather than just the four points input to ECVRF_hash_points. This di= scussion is important from a security proof perspective and it is separate = from the prehashing considerations. Suggest adding "via the point H&qu= ot; to the end of the sentence.

Done [in this commit](https://github.com/cfrg/draft-irtf-cfrg-vrf/commit/577972f34= 1bf530330915eb0b8838f953a6fa9e6)

> Editorial Comments

=

> E1. Sec. 1.1, para 1, line 3: "with corres=
ponding" --> "with the corresponding"

Done in [thi= s commit](https://github.com/cfrg/draft-irtf-c= frg-vrf/commit/07a2008bc94c7372b0fe28236ba6462c40f31fff)

> E2= . Sec. 1.1, para 2, line 2: "on data" --> "of data"?=

Changed to make more sense in [this commit](https://github.com/cfrg/draft-irtf-cfrg-vrf/commit/07a2008bc94c7372b0= fe28236ba6462c40f31fff)

> E3. Sec. 2, last para, line 3: &quo= t;the VRF also comes" --> "the VRFs defined in this document a= lso come" (to match the model discussed in the prior paras where beta = can be derived from pi, and to recognize that there are multiple VRFs in th= e document)

Done in [this commit](https= ://github.com/cfrg/draft-irtf-cfrg-vrf/commit/07a2008bc94c7372b0fe28236ba64= 62c40f31fff)

> E4. Sec. 3.1, para 3, line 3: "it must on= ly hold if" --> "it is only required to hold if" (see nex= t)

Rephrased (slightly differently) in response to comments from Chr= is Wood, [here](https://github.com/cfrg/draft-i= rtf-cfrg-vrf/commit/91b83b6d68d84b04963dd89e8afa42424ecaae98#diff-382a26a0b= cccb52bc8c6ab7c862ed0ee8848df81772776e9fae86b36e5b1be11R670)

>= ; E5. Sec. 3.2, para 3, line 3: "it holds only if" --> "i= t is only required to hold if" (to clarify that the property may also = hold if the condition is not met)

Rephrased (slightly differently) i= n response to comments from Chris Wood [here](h= ttps://github.com/cfrg/draft-irtf-cfrg-vrf/commit/91b83b6d68d84b04963dd89e8= afa42424ecaae98#diff-382a26a0bcccb52bc8c6ab7c862ed0ee8848df81772776e9fae86b= 36e5b1be11R677)

> E6. Sec. 3.3, next to last para, line 2: &q= uot;knows the valid VRF proof" --> "knows a valid VRF proof&qu= ot; (ECVRF has multiple valid proofs, one for each k)

=C2=A0Done in = [this commit](https://github.com/cfrg/draft-ir= tf-cfrg-vrf/commit/07a2008bc94c7372b0fe28236ba6462c40f31fff)

>= ; E7. Sec. 4, para 2, line 3: "parametrized" --> "paramet= erized"

Done in [thi= s commit](https://github.com/cfrg/draft-irtf-c= frg-vrf/commit/07a2008bc94c7372b0fe28236ba6462c40f31fff)

> E2= . Sec. 1.1, para 2, line 2: "on data" --> "of data"?=

Changed to make more sense in [this commit](https://github.com/cfrg/draft-irtf-cfrg-vrf/commit/07a2008bc94c7372b0= fe28236ba6462c40f31fff)

> E3. Sec. 2, last para, line 3: &quo= t;the VRF also comes" --> "the VRFs defined in this document a= lso come" (to match the model discussed in the prior paras where beta = can be derived from pi, and to recognize that there are multiple VRFs in th= e document)

Done in [this commit](https= ://github.com/cfrg/draft-irtf-cfrg-vrf/commit/07a2008bc94c7372b0fe28236ba64= 62c40f31fff)

> E4. Sec. 3.1, para 3, line 3: "it must on= ly hold if" --> "it is only required to hold if" (see nex= t)

Rephrased (slightly differently) in response to comments from Chr= is Wood, [here](https://github.com/cfrg/draft-i= rtf-cfrg-vrf/commit/91b83b6d68d84b04963dd89e8afa42424ecaae98#diff-382a26a0b= cccb52bc8c6ab7c862ed0ee8848df81772776e9fae86b36e5b1be11R670)

>= ; E5. Sec. 3.2, para 3, line 3: "it holds only if" --> "i= t is only required to hold if" (to clarify that the property may also = hold if the condition is not met)

Rephrased (slightly differently) i= n response to comments from Chris Wood [here](h= ttps://github.com/cfrg/draft-irtf-cfrg-vrf/commit/91b83b6d68d84b04963dd89e8= afa42424ecaae98#diff-382a26a0bcccb52bc8c6ab7c862ed0ee8848df81772776e9fae86b= 36e5b1be11R677)

> E6. Sec. 3.3, next to last para, line 2: &q= uot;knows the valid VRF proof" --> "knows a valid VRF proof&qu= ot; (ECVRF has multiple valid proofs, one for each k)

=C2=A0Done in = [this commit](https://github.com/cfrg/draft-ir= tf-cfrg-vrf/commit/07a2008bc94c7372b0fe28236ba6462c40f31fff)

>= ; E7. Sec. 4, para 2, line 3: "parametrized" --> "paramet= erized"

I will appeal to the authority o=
f the Merriam-Webster and American Heritage Dictionaries, which [allow](https://ww=
w.merriam-webster.com/dictionary/parameterize) [both](https://www.ahdic=
tionary.com/word/search.html?q=3Dparameterize).

> E8. Sec. 4,= "Primitives used:" / "RSASP1": "secret key" = --> "private key", "secret RSA exponent" --> &quo= t;private RSA exponent" (to match "RSA private key" paramete= r and terminology in [RFC8017])

Done [in this commit](https://github.com/cfrg/draft-irtf-cfrg-vrf/commit/7d6cf6e49= 277db5c546e0179e3f36da4b38f02c9)

> E9. Sec. 4.3, "Input:= " / "pi_string": "length k" --> "length n&= quot;

I think you mean "length n" --> "length k&qu= ot;. Fixed. [in this commit](https://github.co= m/cfrg/draft-irtf-cfrg-vrf/commit/7d6cf6e49277db5c546e0179e3f36da4b38f02c9<= /a>)

> E10. Sec. 5.3: Reverse order of "pi_string", &qu= ot;alpha_string" in ECVRF_verify function call and "Input:" = list (to match API in Sec. 2)

Done in [this commit](https://github.com/cfrg/draft-irtf-cfrg-vrf/commit/07a2008bc94= c7372b0fe28236ba6462c40f31fff)

> E11. Sec. 5.6.1, step 14: &q= uot;bad_pk[0]...bad_pk[6]" --> "[bad_pk[0], ...,bad_pk[6]] (to= use set notation rather than concatenation -- compare with step 3 in Sec. = 5.4.3)

Done =C2=A0in [this commit](http= s://github.com/cfrg/draft-irtf-cfrg-vrf/commit/07a2008bc94c7372b0fe28236ba6= 462c40f31fff)

> E12. Sec. 7.5, line 5: "Initialized"= ; --> "Initialize"

Done in [this commit](https://github.com/cfrg/draft-irtf-cfrg-vrf/commit/07a2008bc= 94c7372b0fe28236ba6462c40f31fff)

> E13. Sec. 7.7, next to las= t para: "RSA VRF" --> "RSA-FDH-VRF"

Done in [= this commit](https://github.com/cfrg/draft-irt= f-cfrg-vrf/commit/07a2008bc94c7372b0fe28236ba6462c40f31fff)

>= E14. Sec. 7.7, last para, "elliptic curve VRF" --> "ECVR= F"

Done =C2=A0in [this commit](htt= ps://github.com/cfrg/draft-irtf-cfrg-vrf/commit/07a2008bc94c7372b0fe28236ba= 6462c40f31fff)

> E8. Sec. 4,= "Primitives used:" / "RSASP1": "secret key" = --> "private key", "secret RSA exponent" --> &quo= t;private RSA exponent" (to match "RSA private key" paramete= r and terminology in [RFC8017])

Done [in this commit](https://github.com/cfrg/draft-irtf-cfrg-vrf/commit/7d6cf6e49= 277db5c546e0179e3f36da4b38f02c9)

> E9. Sec. 4.3, "Input:= " / "pi_string": "length k" --> "length n&= quot;

I think you mean "length n" --> "length k&qu= ot;. Fixed. [in this commit](https://github.co= m/cfrg/draft-irtf-cfrg-vrf/commit/7d6cf6e49277db5c546e0179e3f36da4b38f02c9<= /a>)

> E10. Sec. 5.3: Reverse order of "pi_string", &qu= ot;alpha_string" in ECVRF_verify function call and "Input:" = list (to match API in Sec. 2)

Done in [this commit](https://github.com/cfrg/draft-irtf-cfrg-vrf/commit/07a2008bc94= c7372b0fe28236ba6462c40f31fff)

> E11. Sec. 5.6.1, step 14: &q= uot;bad_pk[0]...bad_pk[6]" --> "[bad_pk[0], ...,bad_pk[6]] (to= use set notation rather than concatenation -- compare with step 3 in Sec. = 5.4.3)

Done =C2=A0in [this commit](http= s://github.com/cfrg/draft-irtf-cfrg-vrf/commit/07a2008bc94c7372b0fe28236ba6= 462c40f31fff)

> E12. Sec. 7.5, line 5: "Initialized"= ; --> "Initialize"

Done in [this commit](https://github.com/cfrg/draft-irtf-cfrg-vrf/commit/07a2008bc= 94c7372b0fe28236ba6462c40f31fff)

> E13. Sec. 7.7, next to las= t para: "RSA VRF" --> "RSA-FDH-VRF"

Done in [= this commit](https://github.com/cfrg/draft-irt= f-cfrg-vrf/commit/07a2008bc94c7372b0fe28236ba6462c40f31fff)

>= E14. Sec. 7.7, last para, "elliptic curve VRF" --> "ECVR= F"

Done =C2=A0in [this commit](htt= ps://github.com/cfrg/draft-irtf-cfrg-vrf/commit/07a2008bc94c7372b0fe28236ba= 6462c40f31fff)

Dear CFRG,

We've received many stro=
ng applications for the Crypto Review Panel for the new term, and we are=C2=
=A0very thankful for all nominations.

Alexey, Nick=
and I are happy to announce the members of the Crypto Review Panel for 202=
2-2023.

- Scott Fluhrer =
- Russ Housley=C2=A0
- Bjoern Tackmann
- Chloe Martinda= le
- Julia Hesse
- Karthikeyan Bhargavan
- Thomas P= ornin=C2=A0
- Jean-Philippe Aumasson=C2=A0=
- Jon Callas
- Virendra Kumar
- Ludovic Perret=

The information about Crypto Review Panel can be found=
at=C2=A0https://trac.ietf.org/trac/irtf/wiki/Crypto%20Revi=
ew%20Panel

Dear Crypto=
Review Panel members!=C2=A0

Since some Panel reviews in the past=
were sent to different mailing lists, we would like to ask you about the f=
ollowing: please send all reviews (including the reviews provided for ISE o=
r IETF WGs) to c=
rypto-panel@irtf.org=C2=A0and, in addition to that, please send all rev=
iews=C2=A0of CFRG-related documents to the CFRG mailing list (cfrg@irtf.org).

<=
br>

Best regards,

Stanislav (on behalf o=
f CFRG Chairs)

On Mon, 6 Dec 2021 at 09:49, Stanislav V. Smyshlyaev &l=
t;smyshsv@gmail.com> wrote:

=

=

Dear CFRG,

As Alexey,=C2=A0Nick=C2=A0and I announced= during the recent CFRG meeting at IETF 112,=C2=A0the term of the current C= rypto Review Panel membership expires in December 2021, therefore we would = like to solicit nominations (including self-nominations) for the new term (= 2022-2023).=C2=A0Please send them to=C2=A0cfrg-chairs@ietf.org=C2=A0before December= 15th.

Nominations should include an e-mail address and a couple of = paragraphs of rationale (outlining relevant experience and skills). The information about Crypto Review Panel can be found at= =C2=A0https://trac.ietf.org/trac/irtf/wiki/Crypto%20Review%= 20Panel

Regards,

Stanislav (for the chairs)

Dear Chris and Jiayu and the rest of CFRG=
,

=C2=A0Leo

Thank you so much for the very thoughtful comments. Th=
ey have now been addressed. Details below.

I will =
respond to the remaining last call comments shortly.

Hello, Jiayu=
Xu and I have two additional remarks about the current ECVRF draft, specif=
ically Sections 5.4.1 and 5.6.

<= /div>

Non-identity H is used in the published proof of uniqueness (both=
trusted and full): if H is identity, then discrete logs with base H are no=
t well defined and the proof doesn't make=C2=A0sense as written.

<=
div>However, it interestingly turns out that non-identity H =
is not a *necessary* requirement for uniqueness; the existing proof=C2=A0ea=
sily extends to deal with this case. Essentially, if a cheating prover atte=
mpts to provide some Gamma for which cofactor*Gamma is (incorrectly) not id=
entity, then there is only one possible value of the hash-challenge c for w=
hich the prover can succeed. This is exactly the same situation as when a p=
rover attempts to provide an incorrect Gamma when H is not identity.

<=
div>The published proofs of collision resistance (trusted an=
d full) and pseudorandomness also do not require H to be non-identity.

So, there is an option to drop this non-identity requi=
rement, or at least provide further clarity about it. (Perhaps it will be n=
eeded for some future security property we have yet to contemplate.)

<=
div>Indeed, this requireme=
nt is not needed, and I will at some point soon update the proof on eprint.=
I have removed the word "finite" from the descriptions in 5.4.1 =
because it is not relevant anymore. See [this commit](https://github.com/cfrg/draft-irtf-cfrg-vrf/commit/46d449caa0bbd8e0=
f73a0133e0cb8e91724bdb9d)

=C2=A0

Section 5= .6 says:=C2=A0 =C2=A0In order to obtain "= ;full uniqueness" and "full collision resistance" (which pro= vide protection against a malicious VRF public key), the Verifier MUST perf= orm the following additional validation procedure upon receipt of the publi= c VRF key. [The procedure simply rejects any public key that belongs to the= small-order "torsion" subgroup.]This t= ext is formally true but somewhat confusing. The validation is needed only = for "full collision resistance," not "full uniqueness."= (Details follow.) So, we suggest removing the mention of "full unique= ness" from the above.For collision resistanc= e, there is an easy attack if the public key is invalid.However, full uniqueness holds as long as the public key is a valid = elliptic curve point --- even if it is in the torsion subgroup, or is even = the identity element. This is essentially because a valid proof ensures tha= t=C2=A0 =C2=A0cofactor*Gamma =3D dlog_B(cofactor*= pubkey) * H .(This holds even if the dlog on the = right-hand side is zero.) So the LHS, and hence the function output, is uni= quely defined.

=C2=A0

--00000000000025437005d623dd57--
From nobody Fri Jan 21 20:10:41 2022
Return-Path: Thank you also for these comments, which I also addre=
ssed.

On Fri, Nov 12, 2021 at 12:57 PM Christopher Peikert <christopher.p=
eikert=3D40algorand.com@dm=
arc.ietf.org> wrote:

Hello, Jiayu Xu and I have noticed a few more = subtle presentational issues (none serious) with the current VRF draft (dra= ft-irtf-cfrg-vrf09).1. ECVRF_hash_points (Section 5.4.3= ) is specified to take as input "P1...PM - EC points in G."=However, this function is applied to EC points that may= only be elements of the larger group=C2=A0E (of all EC points), and not el= ements of G. For example,=C2=A0ECVRF_verify (Section 5.3) calls=C2=A0ECVRF_= hash_points(H, Gamma, U, V), where Gamma, U, V may only belong to E, not G.=Suggested fix: drop "in G" from the= input description.This appears to be the actual = intent, since the definition of ECVRF_hash_points just applies=C2=A0point_t= o_string to the input points, and works for any EC points (not just ones in= G).

Indeed!=C2=
=A0Fixed [in this commit](https://github.com/c=
frg/draft-irtf-cfrg-vrf/commit/857071d514dc532bb45b2bf4c5ea779dd19077ed=
)

=C2=A0

<= div dir=3D"ltr">2. Section 5.4.1 says: "The ECVRF_hash= _to_curve algorithm takes in the VRF input alpha and converts it to H, an E= C point in G."Suggested change: "... ta= kes in a public key Y (an EC point) and the VRF input alpha ..." This = matches the actual=C2=A0interfaces of the functions defined and used elsewh= ere.In addition, in Section 5.4.1.2 we suggest sw= apping the order of the documented inputs, to put Y first, as it is everywh= ere else.

This b=
rought up a few changes: changed Y to PK_string to avoid unnecessary type c=
onversions, and added an explanation of why it is even there (7.10). See [t=
his commit](https://github.com/cfrg/draft-irtf=
-cfrg-vrf/commit/857071d514dc532bb45b2bf4c5ea779dd19077ed)

Dear CFRG,

Thank you for all the review=
s and comments on this draft. The last call was successful and the draft wi=
ll be moved forward towards publication.

Authors, =
please review the final PR and submit a new version of the draft.=C2=A0

<=
div>Nick (for the chairs)

On Tue, Nov 16, 2021 at 9:38 =
PM Leonid Reyzin <reyzin@cs.bu.edu> wrote:

Thanks to everyone who chimed in o= n the last call. Particular thanks to Chris Peikert, Jiayu Xu, Riad Wahby, = Chris Wood, Burt Kaliski, Antonio Marcedone, and Brian Chen for the detaile= d reading and comments! We have responded to some comments already; we will= work through the rest and produce an=C2=A0updated draft shortly.Best,=C2=A0LeoDear=C2=A0CFRG=C2=A0participants,<= div>The=C2=A0VRF=C2=A0draft has received=C2=A0s= ignificant reviews from the RG and the crypto panel and is=C2=A0ready for a= second last call. This email commences a last=C2=A0call=C2=A0for this docu= ment that will end on the last day of IETF 112 Online (12 Nov 2021):<= div>If you've read the= document by the end of this period and think that it is ready (or not read= y) for publication as an RFC, please send a=C2=A0message=C2=A0in reply to t= his email. Detailed comments would be helpful. You can reach out directly t= o=C2=A0CFRG=C2=A0chairs (cfrg-chairs@ietf.org) if you have questions about the process.<= /div>_______________________________________________Thank you,Nick, Stanislav & Ale= xey

CFRG mailing list

CFRG@irtf.org

https://www.irtf.org/mailman/listinfo/cfrg

Thank you,=C2=A0CFRG chairs!

--000000000000c42d5105d67d04d4--
From nobody Wed Jan 26 06:33:53 2022
Return-Path: We accepte=
d this PR.

There are still a few outstanding comme=
nts we are fixing. We will complete this work shortly, respond to the comme=
nts on this list, and submit a new version.

Best,<=
/div>

=C2=A0Leo

On Tue, Jan 25, 2022=
at 10:49 AM Nick Sullivan <nick@=
cloudflare.com> wrote:

Dear CFRG,Thank you for = all the reviews and comments on this draft. The last call was successful an= d the draft will be moved forward towards publication.=Authors, please review the final PR and submit a new version of the dr= aft.=C2=A0Nick (for the chairs)On Tue, Nov 16, 2021 at 9:38 PM Leonid Reyzin <reyzin@cs.bu.edu> wrote:

Thanks to everyone who chimed in on the last call. Partic= ular thanks to Chris Peikert, Jiayu Xu, Riad Wahby, Chris Wood, Burt Kalisk= i, Antonio Marcedone, and Brian Chen for the detailed reading and comments!= We have responded to some comments already; we will work through the rest = and produce an=C2=A0updated draft shortly.Best,==C2=A0Leo_______________________________________________On Mon= , Oct 25, 2021 at 3:11 PM Nick Sullivan <nick=3D40cloudflare.com@dmarc.ietf.or= g> wrote:Dear=C2=A0CFRG=C2=A0participants,The= =C2=A0VRF=C2=A0draft has received=C2=A0significant reviews fro= m the RG and the crypto panel and is=C2=A0ready for a second last call. Thi= s email commences a last=C2=A0call=C2=A0for this document that will end on = the last day of IETF 112 Online (12 Nov 2021):If you've read the document by the end o= f this period and think that it is ready (or not ready) for publication as = an RFC, please send a=C2=A0message=C2=A0in reply to this email. Detailed co= mments would be helpful. You can reach out directly to=C2=A0CFRG=C2=A0chair= s (cfrg-chairs@ie= tf.org) if you have questions about the process.Thank you, Nick, Stanislav & Alexey

CFRG mailing list

CFRG@irtf.org

https://www.irtf.org/mailman/listinfo/cfrg

Dear Antonio and Brian,

=

Thank you for your thorough reading of the document and detailed=
and thoughtful feedback. Responses below.

> He=
llo CFRG,

>=C2=A0

> Here is some additional feedback on draft-i= rtf-cfrg-vrf-09.

>=C2=A0

> In general we think the draft is wel= l-written and helpful to implement the VRF functionality. We support its pu= blication as an RFC, but have some concrete suggestions that we feel would = clarify the specification, increase interoperability, and reduce the potent= ial for bad parameter choices.

>=C2=A0

> Technical comments:

>

> - Lack of well-defined RSA-FDH ciphersuites: The specificatio= n (and the references quoted) do not seem to recommend a specific hash func= tion, or a specific RSA modulus length. Therefore a compliant implementatio= n might accept weak keys (that are too short), or there might be confusion = around other parameters. We suggest adding a section specifying RSA ciphers= uites, similarly to how it is done for ECVRF. In particular, defining ciphe= rsuites with a fixed size for the RSA modulus and a specific hash function = would reduce ambiguity and help to quickly determine whether different impl= ementations of this standard can interoperate. To directly parallel Section= 5, we could add a section 4.4 called =E2=80=9CRSA-FDH-VRF Ciphersuites=E2= =80=9D, and add a reference to this section in the =E2=80=9CFixed options= =E2=80=9D of Section 4.

The case of RSA-FDH-VRF is quite different f= rom the case of ECVRF, where many parameters must be chosen to work togethe= r. In particular, there is no reason to fix specific key lenghts, as typica= l RSA implementations can handle variable-length keys, and security levels = are often chosen based on the importance of the key. We therefore decided t= o include three ciphersuites, using SHA-256, SHA-384, and SHA-512 hash func= tions, but not specify key lengths. See [this commit](https://github.com/cfrg/draft-irtf-cfrg-vrf/commit/2e414c74d5d3f964= 48e7c2f3179ce8843d906585)

> - ECVRF PK Validation: The PK val= idation procedure for ECVRF seems like a likely thing for implementers to f= orget to do, especially given the way it is described in the standard. Even= if a library claimed to implement ECVRF-P256-SHA256-TAI exactly according = to the spec, it would be unclear if the implementation performs this check = or not, which may cause confusion and security issues in cases where this c= heck is important. We suggest mandating that compliant implementations MUST= perform this check in all cases, as opposed to only when full uniqueness a= nd full collision resistance are deemed necessary. Another option might be = to have ciphersuites that turn this on explicitly, and others which don=E2= =80=99t.

>

> Adding an additional test vector including a bad = public key that the implementation should reject would ensure implementatio= ns correctly cover this case.

Validation is not needed in some appli= cations and may be very expensive in curves with a large cofactor (such as = pairing-friendly curves). As noticed by Chris Peikert and Jiyayu Xu in thei= r last call response, key validation is not needed for full uniqueness; it&= #39;s needed only for full collision-resistance, which is not a property re= quired for many applications. We do not wish to mandate a potentially expen= sive and unnecessary step. Making key validation part of the ciphersuite al= so seems imprudent, because different ciphersuites produce incompatible out= puts, while there are scenarios when the need to validate depends on the ve= rifier. We have, however, edited the draft to make key validation an explic= it input to the Verification requirement. The changes are spread over two c= ommits [one was overly complex](https://github= .com/cfrg/draft-irtf-cfrg-vrf/commit/a739d8c9c65867371c45dcd177ebc9812a8381= d1) and the [second one simplified it](htt= ps://github.com/cfrg/draft-irtf-cfrg-vrf/commit/966557c6c3b4d3cc35b1a81e0e3= 3bc901f984355). Test vectors don't seem to be right the vehicle her= e, since all public keys that are bad are explicitly specified in the secon= d algorithm of 5.4.5.

>=C2=A0

> Here is some additional feedback on draft-i= rtf-cfrg-vrf-09.

>=C2=A0

> In general we think the draft is wel= l-written and helpful to implement the VRF functionality. We support its pu= blication as an RFC, but have some concrete suggestions that we feel would = clarify the specification, increase interoperability, and reduce the potent= ial for bad parameter choices.

>=C2=A0

> Technical comments:

>

> - Lack of well-defined RSA-FDH ciphersuites: The specificatio= n (and the references quoted) do not seem to recommend a specific hash func= tion, or a specific RSA modulus length. Therefore a compliant implementatio= n might accept weak keys (that are too short), or there might be confusion = around other parameters. We suggest adding a section specifying RSA ciphers= uites, similarly to how it is done for ECVRF. In particular, defining ciphe= rsuites with a fixed size for the RSA modulus and a specific hash function = would reduce ambiguity and help to quickly determine whether different impl= ementations of this standard can interoperate. To directly parallel Section= 5, we could add a section 4.4 called =E2=80=9CRSA-FDH-VRF Ciphersuites=E2= =80=9D, and add a reference to this section in the =E2=80=9CFixed options= =E2=80=9D of Section 4.

The case of RSA-FDH-VRF is quite different f= rom the case of ECVRF, where many parameters must be chosen to work togethe= r. In particular, there is no reason to fix specific key lenghts, as typica= l RSA implementations can handle variable-length keys, and security levels = are often chosen based on the importance of the key. We therefore decided t= o include three ciphersuites, using SHA-256, SHA-384, and SHA-512 hash func= tions, but not specify key lengths. See [this commit](https://github.com/cfrg/draft-irtf-cfrg-vrf/commit/2e414c74d5d3f964= 48e7c2f3179ce8843d906585)

> - ECVRF PK Validation: The PK val= idation procedure for ECVRF seems like a likely thing for implementers to f= orget to do, especially given the way it is described in the standard. Even= if a library claimed to implement ECVRF-P256-SHA256-TAI exactly according = to the spec, it would be unclear if the implementation performs this check = or not, which may cause confusion and security issues in cases where this c= heck is important. We suggest mandating that compliant implementations MUST= perform this check in all cases, as opposed to only when full uniqueness a= nd full collision resistance are deemed necessary. Another option might be = to have ciphersuites that turn this on explicitly, and others which don=E2= =80=99t.

>

> Adding an additional test vector including a bad = public key that the implementation should reject would ensure implementatio= ns correctly cover this case.

Validation is not needed in some appli= cations and may be very expensive in curves with a large cofactor (such as = pairing-friendly curves). As noticed by Chris Peikert and Jiyayu Xu in thei= r last call response, key validation is not needed for full uniqueness; it&= #39;s needed only for full collision-resistance, which is not a property re= quired for many applications. We do not wish to mandate a potentially expen= sive and unnecessary step. Making key validation part of the ciphersuite al= so seems imprudent, because different ciphersuites produce incompatible out= puts, while there are scenarios when the need to validate depends on the ve= rifier. We have, however, edited the draft to make key validation an explic= it input to the Verification requirement. The changes are spread over two c= ommits [one was overly complex](https://github= .com/cfrg/draft-irtf-cfrg-vrf/commit/a739d8c9c65867371c45dcd177ebc9812a8381= d1) and the [second one simplified it](htt= ps://github.com/cfrg/draft-irtf-cfrg-vrf/commit/966557c6c3b4d3cc35b1a81e0e3= 3bc901f984355). Test vectors don't seem to be right the vehicle her= e, since all public keys that are bad are explicitly specified in the secon= d algorithm of 5.4.5.

>=C2=A0

> Minor technical comm= ents:

>

> - The suggestion of increasing the security parameter= for applications concerned about tightness of cryptographic reduction cann= ot really apply to ECVRF, as the curves are fixed by the spec. If you decid= e to accept our previous suggestions and define parameters for the RSA base= d version, the same would apply there too. In that case, maybe clarify that= this is more of a forward-looking suggestion for future versions of the sp= ec?

Clarified, and also added a quantitative explanation [in this co= mmit](https://github.com/cfrg/draft-irtf-cfrg-= vrf/commit/524a4fb97a07c55599e5a0d80379491eccd88e74)

> - Sect= ion 4: Should the size of the modulus n (or a bound on it) be a =E2=80=9CFi= xed option=E2=80=9D like hLen?

As discussed above, we do not feel we= should be getting into the business of RSA key sizes. (Getting into EC key= sizes is necessary for ciphersuites, so we have no choice.)

> - = Domain separation and notation: Section 7.7 implies that constants like one= _string and two_string that are often used as inputs to the hash functions = are for domain separation. In the RSA case, domain separation is trivial to= check, as these different octets are at the beginning of inputs to both MG= F1 and proof_to_hash. The only thing we would recommend is perhaps naming t= he constants in a way that makes this intent self-evident, such as defining= TAG_PROOFTOHASH=3D0x01 and TAG_MGF1=3D0x02.

> On the other hand, in = the ECVRF case things are a bit more complex, as these octets appear at dif= ferent positions in different hash functions (sometimes they are in second = position, sometimes in the last), and in some cases aren=E2=80=99t even the= re (and we rely on the hash inputs being only known to honest parties). We = wonder if perhaps using a distinct octet (defined as a constant with a desc= riptive name) as the first octet of the input to each hash function would m= ake both intent and reasoning easier.

We are, unfortunately, stuck w= ith certain compatibility constraints with other standards and drafts that = have forced us to have the somewhat more cumbersome approach to domain sepa= ration than we wanted. We explain domain separation rationale in Section 7.= 9. We have named the constants as you suggest. See [this commit](https://github.com/cfrg/draft-irtf-cfrg-vrf/commit/dd39d= 85d3d9aa4ea4e5d58735dac7a0064c8f5d6).

> - Section 5.4.1.1: Suggest mentioning that arbitrary_string_to_po= int is allowed to return =E2=80=9CINVALID=E2=80=9D when it=E2=80=99s first = defined, e.g., by inserting =E2=80=98or =E2=80=9CINVALID=E2=80=9D =E2=80=99= after =E2=80=9Cconversion of an arbitrary octet string to an EC point.=E2= =80=9D On a first reading, the current definition seems to suggest that it = already maps every octet string to a valid EC point. The fact that there ar= e both a string_to_point and an arbitrary_string_to_point functions that se= em to serve similar purposes is a bit confusing: as others have noted, the = name doesn=E2=80=99t convey the difference.

We changed the name to i= nterpret_hash_value_as_a_point and made clear it's allowed to return IN= VALID [in this commit](https://github.com/cfrg= /draft-irtf-cfrg-vrf/commit/3e3c18195d869780108bfab977618aa9f93f1f3a).<= br>

> - Section 5.4.1.1, step 6: The loop is slightly suspicious in t= hat it seems potentially unbounded; ctr looks like it can just keep going p= ast a single octet, causing int_to_string to fail internally in a way that = is not obviously handled. Suggest one sentence of clarification such as =E2= =80=9CThe loop in step 6 errors if ctr reaches 256, but for all ciphersuite= s in Section 5.5, this is overwhelmingly unlikely.=E2=80=9D, which may be h= elpful for implementers.

Added a note [in this commit](https://github.com/cfrg/draft-irtf-cfrg-vrf/commit/3e3c1819= 5d869780108bfab977618aa9f93f1f3a).

>

> Minor editorial = comments:

>

> - Abstract: The text talks about =E2=80=9Cseveral= VRF constructions=E2=80=9D. But then =E2=80=9COne VRF uses RSA and the oth= er VRF uses...=E2=80=9D. It could say =E2=80=9CSome VRFs are based on RSA a= nd others on Elliptic Curves (EC).=E2=80=9D

Fixed [in this commit](<= a href=3D"https://github.com/cfrg/draft-irtf-cfrg-vrf/commit/58ed2ae724af43= 5ff210c8a0b6c0c45d9397434b">https://github.com/cfrg/draft-irtf-cfrg-vrf/com= mit/58ed2ae724af435ff210c8a0b6c0c45d9397434b)

> - Implicit de= finition of the Key Generation algorithm. Section 2 explicitly defines a sy= ntax for the VRF_hash, VRF_prove, VRF_proof_to_hash, =E2=80=A6, but only im= plicitly defines the need for a key generation algorithm (there is no VRF_k= eygen or similar). We think that explicitly mentioning this algorithm (with= its inputs and outputs both in the EC case and the RSA case) would improve= the clarity of the document, even if its actual implementation is deferred= to some other specification.

Key generation is not specified as an = explicit algorithm in RFC 8017, and we are trying to follow this example fo= r the RSA-FDH-VRF. Key generation for the ECVRF outputs slightly different = versions of the key depending on the ciphersuite. The text in section 5 mak= es it clear that it's specified in the ciphersuites.

> - Sect= ion 3.4: Suggest elaborating slightly on what =E2=80=9Ccertain VRF applicat= ions=E2=80=9D are, in addition to the provided references. A concrete propo= sal: =E2=80=9C(such as preventing bias when selecting participants in some = consensus protocols as in [GHMVZ17] and [DGKR18])=E2=80=9D.

Fixed [i= n this commit](https://github.com/cfrg/draft-i= rtf-cfrg-vrf/commit/58ed2ae724af435ff210c8a0b6c0c45d9397434b)

&g= t; - Section 4, under Primitives: Add a short parenthetical sentence about = what MGF1 does to match the other primitives above it, for example: =E2=80= =9C(given a seed, which is an octet string, and a length, deterministically= produce a pseudorandom octet string of the specified length)=E2=80=9D

= =C2=A0

Fixed [in this commit](https://githu= b.com/cfrg/draft-irtf-cfrg-vrf/commit/58ed2ae724af435ff210c8a0b6c0c45d93974= 34b)

> - Section 4.1: The RSAFDHVRF_prove algorithm explicitl= y uses the RSA modulus n and its length k. Although these can be recomputed= /extracted from K as in RFC8017, these are not formally inputs to the algor= ithm and so this makes the description hard to follow. Maybe we could add a= step to explicitly extract n and k from K (as in Step 1 of ECVRF_prove), o= r add n as an explicit input.

Fixed [in this commit](https://github.com/cfrg/draft-irtf-cfrg-vrf/commit/58ed2ae724= af435ff210c8a0b6c0c45d9397434b)

> - The concatenation operato= r || is listed as notation in section 4 and as a primitive in section 5. In= general the two sections are not organized consistently in terms of notati= on. We realize that this is to use a similar notation to other unrelated RF= Cs, but contents in the two sections do not flow organically.

Indeed= , there is a choice to be internally consistent or to be consistent to prio= r work that the readers are more likely to be familiar with. We found more = value in the first choice. Also, the two VRFs have very different parameter= s and notation, and we felt that organizing it in a way that is most logica= l for each VRF is better than artificially striving for parallel structure.=

> - The & operator in step 5 of the algorithm to validate ke= ys in ed25519 (Section 5.6.1) is not defined, as well as the notation strin= g[int] to indicate individual octets in a string. Given that * and || are d= efined, we suggest defining those too.

We focused on defining notati= on that is nonstandard or ambiguous (ECs can be written multiplicatively or= additively; ^ can mean XOR or exponentiation; || can mean "or" o= r concatenation). The bitwise "and" and string indexing are stand= ard enough that we didn't feel it was necessary to define them.

= > - Section 3.4: The text says =E2=80=9CAdditionally, the ECVRF is belie= ved to also satisfy this property ...=E2=80=9D with respect to the random-o= racle-like unpredictability property. The language doesn=E2=80=99t make it = clear if this is just a conjecture or if a proof of this (in some formal mo= del) exists in the literature. A more concrete reference would help.

Fixed [in this commit](https://github.com/cfr= g/draft-irtf-cfrg-vrf/commit/58ed2ae724af435ff210c8a0b6c0c45d9397434b)<= br>

> - Section 5.4.2.2 implicitly assumes that Hash has at least a 6= 4 bytes output. Indeed, in RFC8032 Hash is fixed to be SHA512. If the inten= t is to use the same steps as the Signature algorithm from RFC8032, perhaps= it would be worth explicitly fixing Hash here as well.

Added "= To use this algorithm, hLen MUST be at least 64."

> Typo= s:

> - Section 5.4.1.1: Right before i= ts description, ECVRF_hash_to_try_and_increment -> ECVRF_hash_to_curve_t= ry_and_increment

Fixed [in this commit](https://github.com/cfrg/draft-irtf-cfrg-vrf/commit/3e3c18195d869780108bfab= 977618aa9f93f1f3a).

> - Sec 7.7: =E2=80=9Cinputs all the hash= functions used=E2=80=9D -> =E2=80=9Cinputs to all the hash functions us= ed=E2=80=9C

Fixed

> Note that we did not check the test ve= ctors.

>=C2=A0

> Sincerely yours in cryptography,

> Anton= io Marcedone and Brian Chen

> Zoom Video Communications

> Note:= these are our own views and do not reflect those of our employer

CFRG will be meeting at IETF 113. = We have requested two hours for our session.

If you would like to pre= sent or to propose a topic for discussion, please contact=C2=A0cfrg-chairs@ietf.org.

Thank you,

Stanislav, Alexey, Nick --000000000000f9532205d6ab5caa-- From nobody Sat Jan 29 18:10:57 2022 Return-Path: