Re: [Lwip] [E] [IoT-DIR] Iotdir early review of draft-ietf-lwig-curve-representations-08

"Chakrabarti, Samita" <samita.chakrabarti@verizon.com> Mon, 28 October 2019 16:35 UTC

Return-Path: <samita.chakrabarti@verizon.com>
X-Original-To: lwip@ietfa.amsl.com
Delivered-To: lwip@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22B9A1200CD for <lwip@ietfa.amsl.com>; Mon, 28 Oct 2019 09:35:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=verizon.com header.b=OVrBNoYk; dkim=pass (2048-bit key) header.d=verizon-com.20150623.gappssmtp.com header.b=SgCHRSKN
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 q_7buuPVB9wI for <lwip@ietfa.amsl.com>; Mon, 28 Oct 2019 09:34:59 -0700 (PDT)
Received: from mx0b-0024a201.pphosted.com (mx0b-0024a201.pphosted.com [148.163.153.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45AA812013A for <lwip@ietf.org>; Mon, 28 Oct 2019 09:34:59 -0700 (PDT)
Received: from pps.filterd (m0115886.ppops.net [127.0.0.1]) by mx0b-0024a201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id x9SGDfC1058529 for <lwip@ietf.org>; Mon, 28 Oct 2019 12:24:35 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.com; h=mime-version : references : in-reply-to : from : date : message-id : subject : to : cc : content-type; s=corp; bh=BJLG0f4UOvgE8fNYyrvG9tRG2dujR/bC+8yBLLpiQVY=; b=OVrBNoYk+U2o3unKtoTVbEISNMLpAzuZlrXSmEwsnGZbMq9ddTh2uXbNK4v4amPkP/QJ 1634JWu3zhDHOkqYZFCMqZhtk9nZ7qYWQt9J4Awuoc1Yv0D/6cWHervf+26JbI4OCxqB E5UIgrgg2ms8uW/tERiYSVwgzqkXaY87XOQ=
Received: from mail-oi1-f197.google.com (mail-oi1-f197.google.com [209.85.167.197]) by mx0b-0024a201.pphosted.com with ESMTP id 2vw361muuh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for <lwip@ietf.org>; Mon, 28 Oct 2019 12:24:35 -0400
Received: by mail-oi1-f197.google.com with SMTP id x125so4986123oig.7 for <lwip@ietf.org>; Mon, 28 Oct 2019 09:24:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BJLG0f4UOvgE8fNYyrvG9tRG2dujR/bC+8yBLLpiQVY=; b=SgCHRSKNKTqHavAjvPSDbFYwfYLUC57mjqYvrnSB4juuQgn3Ovb7vwGyVKepttK9qh 5UI8OSdK3ZH6v9SHZVzPgZH1uqxkeyhy48jU3AA9udRzcdCmJd0LfEhrDYTGqPXYQLMr yIpFXAHzJgPc+5R8nZYqimQaNe3Eshr0Jp5/kVR9PLMyHnjAdynvYajev2eqtrjHEvj3 pKA7QoTataqeJ4UY5mj5ABikjf4647NEsQvmAimnS2WiCyG8B3CODjl/x2gU+QCMM7S7 8JAIjn7wqS7yGJ+TqKvzE4qwtRyEqFpvqdzCM25rprHODKAIk4D1qHtw5zzKr3+RqHJO +3XQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=BJLG0f4UOvgE8fNYyrvG9tRG2dujR/bC+8yBLLpiQVY=; b=Tu0EV4SYmk2KlTW5tF6pieXmgsP9SlPRgk3YEbDGUyT5JhHPQ+LxIR2GefwwqntcUh dqyGevkRa4G+84GAcn5gDTi99iREJN9j++flgGabH1+PfXQOpS1NASAmxkNzcEtbUgg5 DcPf1Ua64EQ1BsywPzziDISB5Xd6ZoufJKgZbBFbvatXZ8uD/LXw+QU364dzpkOUBNoo 9CdGmqPP0/NBNGhNqYdJOKOi/Op1J7t1cnYSO8ZmQ/Hp4sfnd2N21g4eOxqyw7H857HW IdOiAPF6ZdEN5ek41giSw5+60hOU+mhTbqz8rgFmQOQP5McIK+RU1oSFqFaPhaP1c2QB dzpw==
X-Gm-Message-State: APjAAAWcPuvk3aRypmZMFbPMPNTGhhm0hWJMYB5D3PozK8rPtXuxEMjT Vh/yMGEBTQszVbRa8h0skQvyCPexZPdgEosL6zuqD9l8V+aNwo6C3osZ9amCdJREQkEBp5VqEJF t+sEFpNmJOlU5NrfP5CRA
X-Received: by 2002:aca:58c2:: with SMTP id m185mr114094oib.128.1572279874493; Mon, 28 Oct 2019 09:24:34 -0700 (PDT)
X-Google-Smtp-Source: APXvYqyBnHACL+QlPvnbjsADs6E9JpLepsoCODyUvpmWZ+QwDQUoHbO41d80tq4yYhTlyT/aYEzdFKRQAN9Jr6LJU4s=
X-Received: by 2002:aca:58c2:: with SMTP id m185mr114069oib.128.1572279874021; Mon, 28 Oct 2019 09:24:34 -0700 (PDT)
MIME-Version: 1.0
References: <157202868751.4563.7383848744505767056@ietfa.amsl.com>
In-Reply-To: <157202868751.4563.7383848744505767056@ietfa.amsl.com>
From: "Chakrabarti, Samita" <samita.chakrabarti@verizon.com>
Date: Mon, 28 Oct 2019 12:24:22 -0400
Message-ID: <CAHYRG6NUMQMq3d_6ttqdn9sk7=c7jJwbU=9ROzmtaubAVuqNmQ@mail.gmail.com>
To: Daniel Migault <daniel.migault@ericsson.com>
Cc: Iot-dir@ietf.org, lwip@ietf.org, draft-ietf-lwig-curve-representations.all@ietf.org
Content-Type: multipart/alternative; boundary="00000000000060fe1b0595faef6d"
X-mailroute: internal
X-Proofpoint-Spam-Details: rule=out_spam_notspam policy=out_spam score=0 impostorscore=0 bulkscore=0 malwarescore=0 priorityscore=1501 lowpriorityscore=0 suspectscore=0 adultscore=0 phishscore=0 mlxscore=0 spamscore=0 mlxlogscore=999 clxscore=1011 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1910280161
Archived-At: <https://mailarchive.ietf.org/arch/msg/lwip/zp5mn9V4QWu8hLDZYkSvz8VeJyY>
Subject: Re: [Lwip] [E] [IoT-DIR] Iotdir early review of draft-ietf-lwig-curve-representations-08
X-BeenThere: lwip@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Lightweight IP stack. Official mailing list for IETF LWIG Working Group." <lwip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lwip>, <mailto:lwip-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lwip/>
List-Post: <mailto:lwip@ietf.org>
List-Help: <mailto:lwip-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lwip>, <mailto:lwip-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 28 Oct 2019 16:35:02 -0000

Hi Daniel,
Your review of the document is very much appreciated in order to move this
draft forward!
Since you already provided the review, please close the review request
assignment as completed.

Best regards,
-Samita

On Fri, Oct 25, 2019 at 2:38 PM Daniel Migault via Datatracker <
noreply@ietf.org> wrote:

> Reviewer: Daniel Migault
> Review result: Almost Ready
>
> Hi,
>
> I have reviewed this document as part of the IoT directorate's
> ongoing effort to review all IETF documents being processed by the
> IESG.  These comments were written primarily for the benefit of the
> internet area directors.  Document editors and WG chairs should treat
> these comments just like any other last call comments.
>
> The summary of the review is Almost Ready
>
> Overall I believe the document is well written with a lot of useful
> information. Though I have not carefully reviewed the annexes, I believe
> the
> document could be re-organized to  provide more implementation details of
> Wei25519 and its potentially the implementation of the isogeny between
> Wei25519.-3 and Wei25519. Note that the latest point may depend on the
> implementation status of NIST curves.
>
> Please find my review, which I hope will help to move the document to be
> moved
> forward.
>
> Yours,
> Daniel
>
> Abstract
>
>    This document specifies how to represent Montgomery curves and
>    (twisted) Edwards curves as curves in short-Weierstrass form and
>    illustrates how this can be used to carry out elliptic curve
>    computations using existing implementations of, e.g., ECDSA and ECDH
>    using NIST prime curves.
>
> <mglt>
> Overall I have the impression the document's intent is to define Wei25519
> for
> COSE. The current document is very well documented and nicely written on
> the
> generic methodology used, that is using the Weierstrass models of curves
> using
> other models that is in our case twisted-Edward/Montgomery curves. My
> reading
> of the document is that it might benefit by being re-focused on Wei25519
> and
> provide the necessary details in the main body - that is not the annex to
> implement: * Wei25519 - the domains parameters * the isogeny between
> Wei25519.-3 and Wei25519 - as this is necessary for reusing NIST curve
> implementation when a hard coded. That said, this depends on the
> implementation
> status of NIST curves and may be left in the annex.
>
> Specification is sufficient to assign code points which is sufficient with
> an
> Informational status.
>
> I would even have Wei25519 in the title. In my opinion the title is too
> generic
> and the scope should be narrow down a bit. </mglt>
>
> <mglt>
> The document introduces some notations, I believe these notations should be
> specified, and maybe use the same notation as RFC7748, if possible to avoid
> that we have one notation per document. </mglt>
>
> 1.  Fostering Code Reuse with New Elliptic Curves
>
>    It is well-known that elliptic curves can be represented using
>    different curve models.
>
> <mglt>
> nits: It might be preferred to remain factual and simply say "Elliptic
> curves
> can be represented using different models." </mglt>
>
>    Recently, IETF standardized elliptic curves
>    that are claimed to have better performance and improved robustness
>    against "real world" attacks than curves represented in the
>    traditional "short" Weierstrass model.
>
> <mglt>
> Not being a native english speaker, the sentence above may lead the reader
> to
> think that Weierstrass representation is one reason for less robustness and
> performance. If that were the case, the reader may wonder why do we want to
> move to that representation.
>
> I believe that before Montgomery or Edwards curves have been introduced
> curves
> with Weierstrass model were widely deployed and implemented. </mglt>
>
>    This document specifies an
>    alternative representation of points of Curve25519, a so-called
>    Montgomery curve, and of points of Edwards25519, a so-called twisted
>    Edwards curve, which are both specified in [RFC7748], as points of a
>    specific so-called "short" Weierstrass curve, called Wei25519.  We
>    also define how to efficiently switch between these different
>    representations.
>
> <mglt>
> I understand the switch can be performed in two ways, it might help the
> reader
> to distinguish two scenario one with a being a parameter and one with a
> being
> hard coded.
>
> We may also briefly expose why Curve25519 cannot be "proxied" by Ed-to-Wei
> followed by Wei25519. In which case Wei25519 would be an implementation
> detail.
> This would justify the need to add code points for Wei25519. </mglt>
>
>    Use of Wei25519 allows easy definition of new signature schemes and
>    key agreement schemes already specified for traditional NIST prime
>    curves, thereby allowing easy integration with existing
>    specifications, such as NIST SP 800-56a [SP-800-56a], FIPS Pub 186-4
>    [FIPS-186-4], and ANSI X9.62-2005 [ANSI-X9.62], and fostering code
>    reuse on platforms that already implement some of these schemes using
>    elliptic curve arithmetic for curves in "short" Weierstrass form (see
>    Appendix C.1).
>
> <mglt>
> Not being a cryptographer at all. I am wondering if the definition of "new"
> signature scheme is correct. At least it sounds a dangerous slope. I think
> the
> text wants to say it allows to re-use signature scheme defines for the NIST
> curves using another curves Wei25519, namely ECDSA in our case. </mglt>
>
> 2.  Specification of Wei25519
>
>    For the specification of Wei25519 and its relationship to Curve25519
>    and Edwards25519, see Appendix E.
>
> <mglt>
> If we are defining Wei25519, it seems that at least the definition of
> Wei25519
> needs to be part of the main draft. A deep explanation as well as other
> information may be left in the annexe. I would thus probably recommend to
> add
> the necessary domain parameters that are needed to instantiate Wei25519.
> </mglt>
>
>    For further details and background
>    information on elliptic curves, we refer to the other appendices.
>
>    The use of Wei25519 allows reuse of existing generic code that
>    implements short-Weierstrass curves, such as the NIST curve P-256, to
>    also implement the CFRG curves Curve25519 and Edwards25519.  We also
>    cater to reusing of existing code where some domain parameters may
>    have been hardcoded, thereby widening the scope of applicability.  To
>    this end, we specify the short-Weierstrass curves Wei25519.2 and
>    Wei25519.-3, with hardcoded domain parameter a=2 and a=-3 (mod p),
>    respectively; see Appendix G.  (Here, p is the characteristic of the
>    field over which these curves are defined.)
>
> <mglt>
> The text needs here a bit more more explanations. As I understood, we are
> not
> simply changing the representation but also considering the constraint of
> the
> NIST curves implementations. My understanding is that NIST curves have hard
> coded a=-3, so we need to work around this with the isogeny. The
> construction
> is, in my opinion, a bit different from what simple isomorphism. It might
> also
> be good to have that overview stated in the introduction section.
>
> Annexes are good, but the necessary information for an implementation may
> be
> moved up to the main body.
>
> </mglt>
>
> 3.  Use of Representation Switches
>
>    The curve Wei25519.-3 (which has hardcoded domain parameter a=-3 (mod
>    p)) is not isomorphic to the curve Wei25519, but is related in a
>    slightly weaker sense: the curve Wei25519 is isogenous to the curve
>    Wei25519.-3, where the mapping of Appendix G.2 is an isogeny of
>    degree l=47 that maps the specified base point G of Wei25519 to the
>    specified base point G' of Wei25519.-3 and where the so-called dual
>    isogeny (which maps Wei25519.-3 to Wei25519) has the same degree
>    l=47, but does not map G' to G, but to a fixed multiple hereof, where
>    this multiple is l=47.  Consequently, a public-private key pair
>    (k,R:=k*G) for Wei25519 corresponds to the public-private key pair
>    (k, R':= k*G') for Wei25519.-3 (via the l-isogeny), whereas the
>    public-private key pair (k, R':=k*G') corresponds to the public-
>    private key pair (l*k, l*R=l*k*G) of Wei25519 (via the dual isogeny).
>    (Note the extra scalar l=47 here.)
>
> <mglt>
> This is just a comment that ascii does not help reading 1=47... but there
> is no
> much we can do. </mglt>
>
>    Alternative curve representations can, therefore, be used in any
>    cryptographic scheme that involves computations on public-private key
>    pairs, where implementations may carry out computations on the
>    corresponding object for the isomorphic or isogenous curve and
>    convert the results back to the original curve (where, in case this
>    involves an l-isogeny, one has to take into account the factor l).
>    This includes use with elliptic-curve based signature schemes and key
>    agreement and key transport schemes.
>
> <mglt>I believe we should specify somewhere that changing the
> representation
> does not ease the ECDLP for a given prime/curve</mglt>
>
> 4.  Examples
>
> <mglt>
> I do not believe these are example regarding the focus of the document. Of
> course, the document could be more generic, but here we focus on 25519, so
> I
> would rename Example as Implementation. Or move subsection to one level,
> that
> is 4.1 -> 4. 4.2->5... </mglt>
>
> 8.  Security Considerations
>
>    Elliptic curves are generally used as objects in a broader
>    cryptographic scheme that may include processing steps that depend on
>    the representation conventions used (such as with, e.g., key
>    derivation following key establishment).  These schemes should
>    (obviously) unambiguously specify fixed representations of each input
>    and output (e.g., representing each elliptic curve point always in
>    short-Weierstrass form and in uncompressed tight MSB/msb format).
>
> <mglt>
> I think it might be worth mentioning here that while the scheme used in
> this
> document may be applied for other curves that 25519, not all modules are
> isomorphic to Weierstrass. In addition not all Weierstrass representation
> can
> be switched to a Montgomery representation. </mglt>
>
>    To prevent cross-protocol attacks, private keys SHOULD only be used
>    with one cryptographic scheme.  Private keys MUST NOT be reused
>    between Ed25519 (as specified in [RFC8032]) and ECDSA25519 (as
>    specified in Section 4.3).
>
>    To prevent intra-protocol cross-instantiation attacks, ephemeral
>    private keys MUST NOT be reused between instantiations of ECDSA25519.
>
>
> _______________________________________________
> IoT-DIR mailing list
> IoT-DIR@ietf.org
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_iot-2Ddir&d=DwICAg&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=pWMzx7FsqijEJPyfMBfn-HJss-wVVTf0K5y-cxCTXL8&m=R9xgGynpGpZuri6EHdEishW9HbS2jbstDEFk6i38v8w&s=H5LPk8KFQpEY0jiHVeVBFFvDXAG_39OKXhO_tyizQUg&e=
>