Re: [Cfrg] RGLC on draft-irtf-cfrg-pairing-friendly-curves-07

rsw@jfet.org Wed, 08 July 2020 21:59 UTC

Return-Path: <rswatjfet.org@gmail.com>
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 3D6C13A0784 for <cfrg@ietfa.amsl.com>; Wed, 8 Jul 2020 14:59:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Level:
X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8CqsvMvIK7O5 for <cfrg@ietfa.amsl.com>; Wed, 8 Jul 2020 14:59:19 -0700 (PDT)
Received: from mail-pl1-f176.google.com (mail-pl1-f176.google.com [209.85.214.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 421D93A07B7 for <cfrg@irtf.org>; Wed, 8 Jul 2020 14:59:19 -0700 (PDT)
Received: by mail-pl1-f176.google.com with SMTP id w17so4285736ply.11 for <cfrg@irtf.org>; Wed, 08 Jul 2020 14:59:19 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=7B2i/ZCEEaUHs7yfnVvdR61TpqhD0nfFLd7ymuRu+YA=; b=NOK/qEURgU+WT7qbRWyNERTxpANXjU1J4dD1eqC1jrbpopZ4T3pk6bffU4EZAwwCGb Kgg734lHaUisnFp628EeAV1wCK5OWJ6XdyF/cKmLKNwEdP1iIzZPkxZUdnBEmn6lndNF IbzQ6bnv0s4zVQ6TQDvaX5JoMqKmy4XAkxOgYxHgNLIoFp3ZqR6CHNLjkmIjKJDguStx SDLNtewT9fyPgRLOwIPgrqrShvHZRXmX+qR4yIBqS/IUR6eFQ9hyk31JRTS2o8VMnE2h YWZIDS62fQvQqr93VOcwVTo5ij1XtBjVAf0d4VMNNI4Dj4P+/mC/nRpfPFnG8zoSo/Gd k8ag==
X-Gm-Message-State: AOAM531Yw+n8m4feZLmzXVPXgCx0avr35UyudHmMPq9AQP8L9oYHxmn6 LgUh8LuQtxssiJoo3D0u1gg=
X-Google-Smtp-Source: ABdhPJxkl9rVVfSNGWRpcsBv7tVii3wDXHo4RZ7idY/7hMQj5RexGd5hzS/W27XCuDb+Dv62+05Jog==
X-Received: by 2002:a17:90a:e28c:: with SMTP id d12mr12351186pjz.122.1594245558659; Wed, 08 Jul 2020 14:59:18 -0700 (PDT)
Received: from localhost (graviton.stanford.edu. [171.67.76.22]) by smtp.gmail.com with ESMTPSA id m1sm431452pjr.56.2020.07.08.14.59.17 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Wed, 08 Jul 2020 14:59:17 -0700 (PDT)
Date: Wed, 8 Jul 2020 14:59:16 -0700
From: rsw@jfet.org
To: Armando Faz <armfazh=40cloudflare.com@dmarc.ietf.org>
Cc: cfrg@irtf.org, cfrg-chairs@ietf.org
Message-ID: <20200708215916.xbdvyak6etncqxwj@muon>
References: <CABZxKYmyYbOXG9Lo8vNZANn=x+DhZR0qztAg+JbYnLdoxVrsTQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CABZxKYmyYbOXG9Lo8vNZANn=x+DhZR0qztAg+JbYnLdoxVrsTQ@mail.gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/pYMwStzVVnWY4cTn3BDMusZo3hg>
Subject: Re: [Cfrg] RGLC on draft-irtf-cfrg-pairing-friendly-curves-07
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.29
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: Wed, 08 Jul 2020 21:59:20 -0000

Hello CFRG,

Armando, thanks for the careful feedback.

One quick question for the whole group:

Armando Faz <armfazh=40cloudflare.com@dmarc.ietf.org> wrote:
> My second suggestion is to include suites for hashing to G1 and
> G2 because this is a common requirement in cryptographic protocols.
> (Methods are already defined in the hash_to_curve draft, so it might
> just require to define the corresponding suites).

Since neither hash-to-curve nor pairing-friendly-curves is finalized,
it seems like these hash-to-curve suites could go in either document.

Stating the obvious:

- one advantage of putting them in p-f-c is that it decouples the
  two documents somewhat---if p-f-c changes after h-2-c is finalized
  there's no problem updating the suites.

- on the other hand, putting the suites in h-2-c might make them
  slightly easier to discover down the road; but maybe this issue
  can be addressed by adding a pointer from h-2-c to p-f-c.

In either case, it seems like the BLS12-381 suite currently defined
in h-2-c ought to live in the same place as the suites for the other
curves that are defined in p-f-c, no?

Further thoughts would be appreciated!

Best regards,

-=rsw