[prev in list] [next in list] [prev in thread] [next in thread]
List: cfrg
Subject: Re: [CFRG] [irsg] Spencer Dawkins' No Objection on draft-irtf-cfrg-hash-to-curve-14: (with COMMENT)
From: Colin Perkins <csp () csperkins ! org>
Date: 2022-06-17 12:35:58
Message-ID: 63689378-A467-4202-AE7D-321F63BAF34E () csperkins ! org
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Thanks!
Colin
On 16 Jun 2022, at 17:26, Spencer Dawkins at IETF wrote:
> Hi, Colin,
>
> On Wed, Jun 15, 2022 at 8:52 AM Colin Perkins <csp@csperkins.org>
> wrote:
>
>> Hi Spencer,
>>
>> The draft-irtf-cfrg-hash-to-curve-16 just submitted looks to address
>> these
>> comments. Can you please review and confirm?
>>
>
> It does. Thanks to the authors for considering my comments.
>
> Best,
>
> Spencer
>
>
>> Thanks!
>> Colin
>>
>>
>>
>> On 13 May 2022, at 5:50, Spencer Dawkins via Datatracker wrote:
>>> 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 …
>>
[Attachment #5 (text/html)]
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/xhtml; charset=utf-8">
</head>
<body><div style="font-family: sans-serif;"><div class="plaintext" \
style="white-space: normal;"><p dir="auto">Thanks! <br>
Colin</p>
<br><br><p dir="auto">On 16 Jun 2022, at 17:26, Spencer Dawkins at IETF wrote:</p>
</div><blockquote class="embedded" style="margin: 0 0 5px; padding-left: 5px; \
border-left: 2px solid #5855D5; color: #5855D5;"><div \
id="07FEF8E8-17A9-49A1-A64D-24B1540BCAC4">
<div dir="ltr">
<div dir="ltr">Hi, Colin, </div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Wed, Jun 15, 2022 at 8:52 AM Colin Perkins \
<<a href="mailto:csp@csperkins.org">csp@csperkins.org</a>> wrote:<br></div> \
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex">Hi Spencer,<br> <br>
The draft-irtf-cfrg-hash-to-curve-16 just submitted looks to address these comments. \
Can you please review and confirm?<br></blockquote> <div><br></div>
<div>It does. Thanks to the authors for considering my comments. </div>
<div><br></div>
<div>Best,</div>
<div><br></div>
<div>Spencer</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex">Thanks!<br> Colin<br>
<br>
<br>
<br>
On 13 May 2022, at 5:50, Spencer Dawkins via Datatracker wrote:<br>
> Spencer Dawkins has entered the following ballot position for<br>
> draft-irtf-cfrg-hash-to-curve-14: No Objection<br>
><br>
> When responding, please keep the subject line intact and reply to all<br>
> email addresses included in the To and CC lines. (Feel free to cut this<br>
> introductory paragraph, however.)<br>
><br>
><br>
><br>
> The document, along with other ballot positions, can be found here:<br>
> <a href="https://datatracker.ietf.org/doc/draft-irtf-cfrg-hash-to-curve/" \
rel="noreferrer" target="_blank">https://datatracker.ietf.org/doc/draft-irtf-cfrg-hash-to-curve/</a><br>
><br>
><br>
><br>
> ----------------------------------------------------------------------<br>
> COMMENT:<br>
> ----------------------------------------------------------------------<br>
><br>
> I'm only vaguely aware of how this stuff works, so please keep that in mind,<br>
> when reading my comments. I hope they are somewhat helpful.<br>
><br>
> In this text from the Introduction,<br>
><br>
> Unfortunately for implementors, the precise hash function that is suitable \
for<br> > a given protocol implemented using a given elliptic curve is often \
unclear from<br> > the protocol's description. Meanwhile, an incorrect choice of \
hash function can<br> > have disastrous consequences for security.<br>
><br>
> I'm not sure I understand (at this point in the document) what the problem \
is<br> > ("why it's not OK to just pick a hash function"), other than "if you do \
that,<br> > bad things will happen"). Is there a reference you could include here, \
or even<br> > a forward pointer if there's a good place to point to in the draft, \
so that us<br> > non-experts can follow along?<br>
><br>
> I learned a lot from googling "rejection sampling methods" while reading \
this<br> > text<br>
><br>
> This document does not cover rejection sampling methods, sometimes referred \
to<br> > as "try-and-increment" or "hunt-and-peck,"<br>
><br>
> But the text didn't tell me enough to understand rejection sampling methods.<br>
> Perhaps a half-sentence explanation, or a reference, would be helpful.<br>
><br>
> This is nit-ish, but it confused me.<br>
><br>
> 5.1. Security considerations, is only for section 5, is that right? \
There's<br> > another Security Considerations - section 10 - which starts with \
these two<br> > sentences:<br>
><br>
> Section 3.1 describes considerations related to domain separation. See \
Section<br> > 10.4 for further discussion.<br>
><br>
> Section 5 describes considerations for uniformly hashing to field elements; \
see<br> > Section 10.2 and Section 10.3 for further discussion.<br>
><br>
> I found myself wondering why some security considerations seem to be in \
Section<br> > 3.1 (which isn't called Security considerations), and others seem to \
be in<br> > Section 5 (shouldn't the second sentence refer to Section 5.1, which \
IS called<br> > Security considerations?), and these considerations outside \
Section 10 aren't<br> > complete. If I was looking for all the Security \
considerations, I'd expect to<br> > find them together, and probably in Section \
10.<br> ><br>
> Do the right thing, of course.<br>
><br>
> I'm not picking on BCP 14 language in most of the text, but in Section 7,<br>
><br>
> Note that in this case scalar multiplication by the cofactor h does not<br>
> generally give the same result as the fast method, and SHOULD NOT be used.<br>
><br>
> I'm not understanding why this is not a MUST - when is it OK to use scalar<br>
> multiplication, if it usually gives a different result?<br>
><br>
> I have roughly the same question in Section 8.5,<br>
><br>
> This section defines ciphersuites for curve25519 and edwards25519 [RFC7748].<br>
> Note that these ciphersuites SHOULD NOT be used when hashing to ristretto255<br>
> [I-D.irtf-cfrg-ristretto255-decaf448]. See Appendix B for information on how \
to<br> > hash to that group.<br>
><br>
> What if I DO use these ciphersuites inappropriately?<br>
><br>
> Very similar text is in 8.6, so I have a very similar question.<br>
><br>
> This section defines ciphersuites for curve448 and edwards448 [RFC7748]. \
Note<br> > that these ciphersuites SHOULD NOT be used when hashing to decaf448<br>
> [I-D.irtf-cfrg-ristretto255-decaf448]. See Appendix C for information on how \
to<br> > hash to that group.<br>
><br>
> Do the right thing, of course.<br>
><br>
> In section 8.9,<br>
><br>
> The RECOMMENDED way to define a new hash-to-curve suite is:<br>
><br>
> <snipped down to><br>
><br>
> When hashing to an elliptic curve not listed in this section, corresponding<br>
> hash-to-curve suites SHOULD be fully specified as described above.<br>
><br>
> As a nit, "not listed in this section" might reasonably be read as "not \
listed<br> > in section 8.9". I think you might better say "not listed elsewhere \
in section<br> > 8".<br>
><br>
> But beyond that, I don't think you mean "RECOMMENDED" in the BCP 14 sense. \
If<br> > this text said<br>
><br>
> For elliptic curves not listed elsewhere in section 8, a new hash-to-curve<br>
> suite can be defined by <steps 1-8 as they appear in the draft><br>
><br>
> You wouldn't need any of the BCP 14 language in this section, with the<br>
> attendant "why is this not a MUST", "in what cases would you not do this", \
and<br> > "if you don't do this, what happens?" questions that reviewers can't \
help<br> > asking …<br></blockquote>
</div>
</div></div></blockquote>
<div class="plaintext" style="white-space: normal;">
</div>
</div>
</body>
</html>
_______________________________________________
CFRG mailing list
CFRG@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic