Re: [http-auth] CFRG Curves in Mutual

大岩寛 <y.oiwa@aist.go.jp> Wed, 02 December 2015 05:30 UTC

Return-Path: <y.oiwa@aist.go.jp>
X-Original-To: http-auth@ietfa.amsl.com
Delivered-To: http-auth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E35971A1BF3 for <http-auth@ietfa.amsl.com>; Tue, 1 Dec 2015 21:30:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.298
X-Spam-Level: *
X-Spam-Status: No, score=1.298 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 X4kDFloDP11m for <http-auth@ietfa.amsl.com>; Tue, 1 Dec 2015 21:30:52 -0800 (PST)
Received: from APC01-HK2-obe.outbound.protection.outlook.com (mail-hk2apc01on0043.outbound.protection.outlook.com [104.47.124.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDFEB1A1BED for <http-auth@ietf.org>; Tue, 1 Dec 2015 21:30:51 -0800 (PST)
Received: from OS1PR01MB0200.jpnprd01.prod.outlook.com (10.161.230.139) by OS1PR01MB0199.jpnprd01.prod.outlook.com (10.161.229.19) with Microsoft SMTP Server (TLS) id 15.1.331.20; Wed, 2 Dec 2015 05:30:47 +0000
Received: from OS1PR01MB0200.jpnprd01.prod.outlook.com ([10.161.230.139]) by OS1PR01MB0200.jpnprd01.prod.outlook.com ([10.161.230.139]) with mapi id 15.01.0331.023; Wed, 2 Dec 2015 05:30:47 +0000
From: 大岩寛 <y.oiwa@aist.go.jp>
To: Ilari Liusvaara <ilariliusvaara@welho.com>, "http-auth@ietf.org" <http-auth@ietf.org>
Thread-Topic: [http-auth] CFRG Curves in Mutual
Thread-Index: AQHRHuDgKmDBqMK0hkCEjVPWBvumO563OmSg
Date: Wed, 02 Dec 2015 05:30:47 +0000
Message-ID: <OS1PR01MB02000962E47A7D362D937B01A00E0@OS1PR01MB0200.jpnprd01.prod.outlook.com>
References: <20151114133159.GA31664@LK-Perkele-V2.elisa-laajakaista.fi>
In-Reply-To: <20151114133159.GA31664@LK-Perkele-V2.elisa-laajakaista.fi>
Accept-Language: ja-JP, en-US
Content-Language: ja-JP
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=y.oiwa@aist.go.jp;
x-originating-ip: [1.79.30.166]
x-microsoft-exchange-diagnostics: 1; OS1PR01MB0199; 5:b3tTYi6/YgCxbdLyB+KrVvAr+w7Of5taPYA8tYAR+RA3rNbP30FcnDnbSQZW4I7UqYE/yQjb9NVRRt+SCFLhqn3/+341uOppGcnx1DfW3nN6XVuEHlHK+S54CUJt9CelSnA9+bA2+fw9vHmuNVA8bA==; 24:FhiNumQiqcrtrvX6rHVzvLYdLZ/nuA+f7S5dobrqz3Ydo14fjwzO0Rax7MHNyXijv5N1RHk87IjzbZXnEhXpf2S8khQH0AQ1Bhr0tQztGjA=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:OS1PR01MB0199;
x-microsoft-antispam-prvs: <OS1PR01MB01996A990ABEC5B9D40DB5FEA00E0@OS1PR01MB0199.jpnprd01.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(58186630543729);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(2401047)(5005006)(520078)(8121501046)(3002001)(10201501046); SRVR:OS1PR01MB0199; BCL:0; PCL:0; RULEID:; SRVR:OS1PR01MB0199;
x-forefront-prvs: 077884B8B5
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(189002)(13464003)(377454003)(199003)(11100500001)(5008740100001)(85182001)(86362001)(102836003)(15975445007)(5004730100002)(77096005)(76576001)(5001770100001)(76176999)(3846002)(50986999)(2950100001)(586003)(74482002)(122556002)(6116002)(2900100001)(40100003)(87936001)(105586002)(74316001)(92566002)(19580405001)(54356999)(1220700001)(66066001)(5002640100001)(106116001)(33656002)(5003600100002)(2501003)(5001960100002)(1096002)(97736004)(19580395003)(107886002)(81156007)(189998001)(101416001)(10400500002)(106356001); DIR:OUT; SFP:1101; SCL:1; SRVR:OS1PR01MB0199; H:OS1PR01MB0200.jpnprd01.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None (protection.outlook.com: aist.go.jp does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: aist.go.jp
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Dec 2015 05:30:47.2004 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 18a7fec8-652f-409b-8369-272d9ce80620
X-MS-Exchange-Transport-CrossTenantHeadersStamped: OS1PR01MB0199
Archived-At: <http://mailarchive.ietf.org/arch/msg/http-auth/hmklVTBS3jfl5TphIDlgsEQU8Gs>
Subject: Re: [http-auth] CFRG Curves in Mutual
X-BeenThere: http-auth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: HTTP authentication methods <http-auth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/http-auth>, <mailto:http-auth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/http-auth/>
List-Post: <mailto:http-auth@ietf.org>
List-Help: <mailto:http-auth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/http-auth>, <mailto:http-auth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Dec 2015 05:30:56 -0000

Dear Ilari,

sorry for the late reply.

If someone provides voluntary work for both implementing and defining the
spec for Edwards curve, I'll be happy to consider it for merger, 
upon some decisions/suggestions from the WG.
In my current stance, working for new curve (especially for Edwards curves)
can be done with a separate algorithm specification, just like adding a new
ciphersuite for TLS.

We have once discussed the elliptic curve choices in the past with our WG and
CFRGs, and I understood that it is too early to decide one curve or two, and
it is important (at this time) to have modularity (ability to switch)
for future decisions.
That's why our Mutual spec have separated the Weierstrass curve spec
to the "algorithms" draft, so that we can easily write a "new" draft
for any new curves.
(Also, I personally think that the current spec is enough for "demonstrating"
 ability for incorporating EC-based key exchanges to implement.)

Of course, if one has a chance to promote Mutual to the Standards Track in future,
we should make some decision on the "must-to-implement" algorithms then.


Regarding to point formats, current definition is designed only considering
Weierstrass curves, and if it does not fit well for a curve with
different characteristics, we should have another representation.

Chain-shifting is, yes, one performance caveat in the current definition, but
I think it is not critical and is the easiest to understand for Weierstrass curves.
If we would have some defined "standards" on the representations of
curve points (e.g. for Edwards curves), we will happily adapt that.

-- 
Yutaka OIWA, Ph.D.       Leader, Cyber Physical Architecture Research Group
                                  Information Technology Research Institute
    National Institute of Advanced Industrial Science and Technology (AIST)
                      Mail addresses: <y.oiwa@aist.go.jp>, <yutaka@oiwa.jp>
OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D  3139 8677 9BD2 4405 46B5]

> -----Original Message-----
> From: http-auth [mailto:http-auth-bounces@ietf.org] On Behalf Of Ilari
> Liusvaara
> Sent: Saturday, November 14, 2015 10:32 PM
> To: http-auth@ietf.org
> Subject: [http-auth] CFRG Curves in Mutual
> 
> Should CFRG curves (Edwards25519 and Edwards448) be added to Mutual spec?
> 
> The curves (but no point formats) are defined by CFRG-CURVES, which has been
> sent to the RFC Editor (currently being copyedited).
> 
> The existing point format in the Mutual draft is rather bad[1] (especially for
> these curves), but as far as I can tell, it is not mathematically unworkable.
> 
> (The point decoding may also divide by zero. Fortunately all the points where
> this happens are of order 4 and as such invalid anyway).
> 
> 
> [1] Putting the y sign bit at LSB position makes one chainshift the entiere
> thing. And for Edwards curves, usually y is written in full and x is compressed
> to one bit, not the vice versa that is usually done with Weierstrass curves.
> 
> 
> -Ilari
> 
> _______________________________________________
> http-auth mailing list
> http-auth@ietf.org
> https://www.ietf.org/mailman/listinfo/http-auth