Re: [CFRG] Second RGLC on draft-irtf-cfrg-pairing-friendly-curves

Watson Ladd <watsonbladd@gmail.com> Tue, 14 September 2021 03:19 UTC

Return-Path: <watsonbladd@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 B0F653A02C1 for <cfrg@ietfa.amsl.com>; Mon, 13 Sep 2021 20:19:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 wayxEOYBHGDK for <cfrg@ietfa.amsl.com>; Mon, 13 Sep 2021 20:19:20 -0700 (PDT)
Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) (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 44EC33A017E for <cfrg@irtf.org>; Mon, 13 Sep 2021 20:19:20 -0700 (PDT)
Received: by mail-ed1-x532.google.com with SMTP id c22so16128445edn.12 for <cfrg@irtf.org>; Mon, 13 Sep 2021 20:19:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=bcJK3DwrhX2lIpgmil5GwfK3Mj6Ae4UagFrrlC2C9dI=; b=K9kHhecIjjMeDOFqN4Y1jbsoTAooLc+JScyMV6VUM6TzyFUrU974UxRaN/ZsNBRIKD X+CQVd67mwfaHZ7RT1AHEna48hqD+VmjTu1QzquY46C3mOsLKlFGy4MXRbOc+qksWAG4 aNfQS35Ck1tygvVlH9TNAlOTyTa8VGcQldcgijRrWbQnF6cpiBPNsdZL/WAI/ailLLlN Qt0s+yK/W95kcNZ0mYFb80SJR1i1LyqjQzazZubu4+sZOMOt5803wVBs6e6dSnh84oTF 3zQSzsmLzrnw0wioySquCxhK8H7WJQkf/9/Zg2WtDVAzzkcKODUHdmtecmoswfpjQK7m gcZg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=bcJK3DwrhX2lIpgmil5GwfK3Mj6Ae4UagFrrlC2C9dI=; b=x07zVENzAm7+uIwxbdsN93slNtb6Wiao06G5fej0JDEUU1fdjO4Ky2kyN1QAY0SecJ sK5c5frW/uO5jDyzXhqEbRUSubJjA1k5oghprfvq4IlI5dTyvD8ad8pFi0++r4BnSqf8 Zxz7D/qxQdEt1Fv5Sl76cnhRUmAUx3t/fdzawWE2foMbJlu/41aO9C9AalumcIwT1VAO pwisgN5NCFkAGhC5MEjk1SnvmTL40GRGmx7QCqchG6h7j4lCtibEom2ZN+qrd1xhZa8l /ikhjUAEqcxluHZcXxVORUmAAk9ipd+RZ8Yi+gurjWJDfW/hLfhkvZgEnsuzpUTbFVCS gmew==
X-Gm-Message-State: AOAM530DqXASyq5sUQwiY96s6+vA7qpjmec9t176R5ygcHYJfzNelR8Y GPRbmxZR0bHn5y5t8eLW1Za4EISG6l0sUt3aW24=
X-Google-Smtp-Source: ABdhPJwpoz8+VeLNMjDSvPSykQ4XDSkQIo8qVxfKsjSxKUL+7OUrnIcQ3eXhlAhKhOX9IzjV1Vh0K036nRPMyLwLR3Q=
X-Received: by 2002:aa7:c7cb:: with SMTP id o11mr16832623eds.137.1631589557681; Mon, 13 Sep 2021 20:19:17 -0700 (PDT)
MIME-Version: 1.0
References: <CAMr0u6kV-YsAuAMRh6OVArhZ6DftZSCumqYNOQQ5BWq0cgxW3Q@mail.gmail.com> <CACsn0ckkXdVk2maphAoOGm9K6pYkBUOQ+H8sNtpQ5X5Y1k4Yxw@mail.gmail.com> <CAA4D8KZ4=_1qv64MadxeBK85X-oqdwgraGVg2oe0byF2nHeYJQ@mail.gmail.com>
In-Reply-To: <CAA4D8KZ4=_1qv64MadxeBK85X-oqdwgraGVg2oe0byF2nHeYJQ@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
Date: Mon, 13 Sep 2021 20:19:06 -0700
Message-ID: <CACsn0cmHEMedCFpHeyzq+XirMWR4qdC+3MgGYCM+qP3Oxq1uBA@mail.gmail.com>
To: Yumi Sakemi <yumi.sakemi@infours.co.jp>
Cc: Rene Struik <rstruik.ext@gmail.com>, "Stanislav V. Smyshlyaev" <smyshsv@gmail.com>, CFRG <cfrg@irtf.org>, cfrg-chairs@ietf.org, SAITO Tsunekazu <tsunekazu.saito.hg@hco.ntt.co.jp>, Tetsutaro Kobayashi <tetsutaro.kobayashi.dr@hco.ntt.co.jp>, "Riad S. Wahby" <rsw@cs.stanford.edu>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/KmqSMLWzuj7MSGNuv3PiReZ-jVE>
Subject: Re: [CFRG] Second RGLC on draft-irtf-cfrg-pairing-friendly-curves
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: Tue, 14 Sep 2021 03:19:26 -0000

On Mon, Sep 13, 2021 at 11:43 AM Yumi Sakemi <yumi.sakemi@infours.co.jp> wrote:
>
> Dear Rene and Watson
>
> I'm so sorry for my late reply.
> Thank you for your comments.
> I checked and discussed with my co-authors about comments from Rene and Watson.
> As a result, we came up with the idea that the position of our I-D
> might be different from what Rene and Watson commented on our I-D.
> Below are the stances we understand when making comments from Rene and
> Watson and the positions/stances of our I-D.
>
> - Rene's stance
> It is the point of view that the I-D should be for educational
> purposes regarding pairing.
> For example, the quality of the I-D is inadequate for a textbook and
> inappropriate for an IRTF draft.
>
> - Watson's stance
>  Standardization of pairing implementation.
>  For example, there is a lack of detailed explanation of the
> implementation method in the I-D.
>
> To be clarified by Prof. Colin and Stanislav in the 2nd RGLC, the
> stance of our activities is to make an informational RFC
> about “secure parameters of pairing-friendly curves” promoting Secure
> Pairing Cryptography on the Internet.

What does it take to actually achieve this goal?
- Agreement on a few commonly used parameters
- Descriptions of how to represent them
- Descriptions of the algorithms to achieve the result

Ala RFC 6090, SEC1, RFC7748 etc.

This draft has none of that material. It has lots of irrelevant
material that's not really appropriate for an RFC. How does a protocol
designer use this draft to inform implementors what to do? Until you
can answer that I don't think the answer is worth publishing, because
it doesn't make it easier for protocol designers to use as a
reference.

Sincerely,
Watson Ladd

--
Astra mortemque praestare gradatim