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

Colin Perkins <csp@csperkins.org> Fri, 17 June 2022 12:36 UTC

Return-Path: <csp@csperkins.org>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19451C15AAF9; Fri, 17 Jun 2022 05:36:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.108
X-Spam-Level:
X-Spam-Status: No, score=-2.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=csperkins.org
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3_Mi-CFowtvr; Fri, 17 Jun 2022 05:36:11 -0700 (PDT)
Received: from mx1.mythic-beasts.com (mx1.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0B97C15AAF8; Fri, 17 Jun 2022 05:36:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=csperkins.org; s=mythic-beasts-k1; h=Date:Subject:To:From; bh=dH0F/veDL2BrrxBEh5/r8iLtqaSigXuhFeTt2wgspTg=; b=Nc7hv7PT3vXbLxe3/57N4VBxZy AX4qbY7BiRt5E486zmjyJkKiFBilYT6AKnPZG51lWitbvBiwJBqsSfbhPjTelAYnaF63V+Q5efbTL 6436ciUF9fI0Gl2bZq1f+vbFEDaHFmn4HuS+7kRzWXxv2iPiKKA+C74gXMpxe43f1Nmszp0hgmDNo AyG2PbIeP3VUTAonl2SqlhSTOKC+8tb3+DZz4AQmptKWMTzquz0Fp4tBVqMYyc3xJMatnmPmj6+z4 NvRQ+RTTWKMGOHLIaUULLfIQCQpbaVAH3rL+WawrOOkotts8msRVabTGM8sR1plYL8dkIebExwDbL 3LiS1GVg==;
Received: from [130.209.247.112] (port=59036) by mailhub-cam-d.mythic-beasts.com with esmtpsa (TLS1.2) tls TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <csp@csperkins.org>) id 1o2BCp-007T37-Gb; Fri, 17 Jun 2022 13:36:08 +0100
From: Colin Perkins <csp@csperkins.org>
To: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Cc: The IRSG <irsg@irtf.org>, draft-irtf-cfrg-hash-to-curve@ietf.org, cfrg@ietf.org, cfrg-chairs@ietf.org
Date: Fri, 17 Jun 2022 13:35:58 +0100
X-Mailer: MailMate (1.14r5898)
Message-ID: <63689378-A467-4202-AE7D-321F63BAF34E@csperkins.org>
In-Reply-To: <CAKKJt-fw5xQyXUcC=FgLyWQYixsvXQxEzJKhAxOBjNF2Rk-tyw@mail.gmail.com>
References: <165241742117.56042.6412978239153135198@ietfa.amsl.com> <EF83878F-FDCD-49DF-8BBE-E460E213E4B5@csperkins.org> <CAKKJt-fw5xQyXUcC=FgLyWQYixsvXQxEzJKhAxOBjNF2Rk-tyw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_MailMate_D770618C-BC02-4D71-B294-FE4D02757C0E_="
Content-Transfer-Encoding: 8bit
Embedded-HTML: [{"plain":[75, 5593], "uuid":"07FEF8E8-17A9-49A1-A64D-24B1540BCAC4"}]
X-BlackCat-Spam-Score: 0
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/woE6U0NHdOmJTq-Hkp_e5dRQCGs>
Subject: Re: [CFRG] [irsg] Spencer Dawkins' No Objection on draft-irtf-cfrg-hash-to-curve-14: (with COMMENT)
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 Jun 2022 12:36:15 -0000

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 …
>>