[CFRG] Spencer Dawkins' No Objection on draft-irtf-cfrg-hash-to-curve-14: (with COMMENT)

[Spencer Dawkins via Datatracker <[e-mail]>]

Spencer Dawkins has entered the following ballot position for
draft-irtf-cfrg-hash-to-curve-14: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)



The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-irtf-cfrg-hash-to-curve/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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 …