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 … >>
- [CFRG] Spencer Dawkins' No Objection on draft-irt… Spencer Dawkins via Datatracker
- Re: [CFRG] [irsg] Spencer Dawkins' No Objection o… Colin Perkins
- Re: [CFRG] [irsg] Spencer Dawkins' No Objection o… Spencer Dawkins at IETF
- Re: [CFRG] [irsg] Spencer Dawkins' No Objection o… Colin Perkins