Skip to main content

Hashing to Elliptic Curves
draft-irtf-cfrg-hash-to-curve-14

Yes

Colin Perkins
Melinda Shore

No Objection

Brian Trammell
David Oran
Mat Ford

Recuse

Christopher Wood

No Record

Aaron Falk
Alexey Melnikov
Allison Mankin
Ari Keränen
Carsten Bormann
Dave Plonka
Dirk Kutscher
Eve Schooler
Jana Iyengar
Jane Coffin
Jen Linkova
Jianfei(Jeffrey) HE
Jérôme François
Lars Eggert
Laurent Ciavaglia
Leandro Navarro
Lixia Zhang
Mallory Knodel
Marie-Jose Montpetit
Mirja Kühlewind
Nick Sullivan
Rodney Van Meter
Sara Dickinson
Shivan Sahib
Sofia Celi
Stanislav Smyshlyaev
Stephen Farrell
Vincent Roca
Wojciech Kozlowski

Summary: Has enough positions to pass.

Ballot question: "Is this draft ready for publication in the IRTF stream?"

Colin Perkins Yes

Melinda Shore Yes

Brian Trammell No Objection

David Oran No Objection

Mat Ford No Objection

Spencer Dawkins No Objection

Comment (2022-05-12)
I'm only vaguely aware of how this stuff works, so please keep that in mind, when reading my comments. I hope they are somewhat helpful. 

In this text from the Introduction, 

Unfortunately for implementors, the precise hash function that is suitable for a given protocol implemented using a given elliptic curve is often unclear from the protocol's description. Meanwhile, an incorrect choice of hash function can have disastrous consequences for security.

I’m not sure I understand (at this point in the document) what the problem is (“why it’s not OK to just pick a hash function”), other than “if you do that, bad things will happen”). Is there a reference you could include here, or even a forward pointer if there's a good place to point to in the draft, so that us non-experts can follow along?

I learned a lot from googling “rejection sampling methods” while reading this text

This document does not cover rejection sampling methods, sometimes referred to as "try-and-increment" or "hunt-and-peck,"

But the text didn’t tell me enough to understand rejection sampling methods. Perhaps a half-sentence explanation, or a reference, would be helpful.

This is nit-ish, but it confused me. 

5.1.  Security considerations, is only for section 5, is that right? There’s another Security Considerations - section 10 - which starts with these two sentences: 

Section 3.1 describes considerations related to domain separation. See Section 10.4 for further discussion.

Section 5 describes considerations for uniformly hashing to field elements; see Section 10.2 and Section 10.3 for further discussion.

I found myself wondering why some security considerations seem to be in Section 3.1 (which isn’t called Security considerations), and others seem to be in Section 5 (shouldn’t the second sentence refer to Section 5.1, which IS called Security considerations?), and these considerations outside Section 10 aren’t complete. If I was looking for all the Security considerations, I’d expect to find them together, and probably in Section 10. 

Do the right thing, of course. 

I’m not picking on BCP 14 language in most of the text, but in Section 7, 

Note that in this case scalar multiplication by the cofactor h does not generally give the same result as the fast method, and SHOULD NOT be used.

I’m not understanding why this is not a MUST - when is it OK to use scalar multiplication, if it usually gives a different result?

I have roughly the same question in Section 8.5,

This section defines ciphersuites for curve25519 and edwards25519 [RFC7748]. Note that these ciphersuites SHOULD NOT be used when hashing to ristretto255 [I-D.irtf-cfrg-ristretto255-decaf448]. See Appendix B for information on how to hash to that group.

What if I DO use these ciphersuites inappropriately? 

Very similar text is in 8.6, so I have a very similar question. 

This section defines ciphersuites for curve448 and edwards448 [RFC7748]. Note that these ciphersuites SHOULD NOT be used when hashing to decaf448 [I-D.irtf-cfrg-ristretto255-decaf448]. See Appendix C for information on how to hash to that group.

Do the right thing, of course.

In section 8.9, 

The RECOMMENDED way to define a new hash-to-curve suite is:

<snipped down to>

When hashing to an elliptic curve not listed in this section, corresponding hash-to-curve suites SHOULD be fully specified as described above.

As a nit, “not listed in this section” might reasonably be read as “not listed in section 8.9”. I think you might better say “not listed elsewhere in section 8”. 

But beyond that, I don’t think you mean “RECOMMENDED” in the BCP 14 sense. If this text said 

For elliptic curves not listed elsewhere in section 8, a new hash-to-curve suite can be defined by 
<steps 1-8 as they appear in the draft>

You wouldn’t need any of the BCP 14 language in this section, with the attendant “why is this not a MUST”, “in what cases would you not do this”, and “if you don’t do this, what happens?” questions that reviewers can’t help asking …

Christopher Wood (was Yes) Recuse

Aaron Falk No Record

Alexey Melnikov No Record

Allison Mankin No Record

Ari Keränen No Record

Carsten Bormann No Record

Dave Plonka No Record

Dirk Kutscher No Record

Eve Schooler No Record

Jana Iyengar No Record

Jane Coffin No Record

Jen Linkova No Record

Jianfei(Jeffrey) HE No Record

Jérôme François No Record

Lars Eggert No Record

Laurent Ciavaglia No Record

Leandro Navarro No Record

Lixia Zhang No Record

Mallory Knodel No Record

Marie-Jose Montpetit No Record

Mirja Kühlewind No Record

Nick Sullivan No Record

Rodney Van Meter No Record

Sara Dickinson No Record

Shivan Sahib No Record

Sofia Celi No Record

Stanislav Smyshlyaev No Record

Stephen Farrell No Record

Vincent Roca No Record

Wojciech Kozlowski No Record