Re: [Cfrg] (SPAM) Re: FourQ draft now available

Hanno Böck <hanno@hboeck.de> Fri, 23 September 2016 16:35 UTC

Return-Path: <hanno@hboeck.de>
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 2623812B922 for <cfrg@ietfa.amsl.com>; Fri, 23 Sep 2016 09:35:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 IRK72Qol1fPk for <cfrg@ietfa.amsl.com>; Fri, 23 Sep 2016 09:35:51 -0700 (PDT)
Received: from zucker.schokokeks.org (zucker.schokokeks.org [178.63.68.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9EA012B8C8 for <cfrg@irtf.org>; Fri, 23 Sep 2016 09:35:50 -0700 (PDT)
Received: from localhost.localdomain ([2001:2012:115:3d00:8e6b:8908:764f:9343]) (AUTH: LOGIN hanno-default@schokokeks.org, TLS: TLSv1/SSLv3, 256bits, ECDHE-RSA-AES256-GCM-SHA384) by zucker.schokokeks.org with ESMTPSA; Fri, 23 Sep 2016 18:35:46 +0200 id 000000000000009E.0000000057E559E3.000068E6
Date: Fri, 23 Sep 2016 18:35:45 +0200
From: Hanno Böck <hanno@hboeck.de>
To: Erwann Abalea <Erwann.Abalea@docusign.com>
Message-ID: <20160923183545.53387e8c@hboeck.de>
In-Reply-To: <0C5FC580-11F9-488F-865D-DBEEF28590BE@docusign.com>
References: <CACsn0cnhf2MBm2uBB=-LgwJYM7_tB_3B9DHdAhvU9sZkwD4MGA@mail.gmail.com> <20160923084927.2fdaf023@hboeck.de> <0C5FC580-11F9-488F-865D-DBEEF28590BE@docusign.com>
X-Mailer: Claws Mail 3.14.0 (GTK+ 2.24.31; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=_zucker.schokokeks.org-26854-1474648547-0001-2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/ie4wPTEu2s2TWYfLIyWjAfDNMK8>
Cc: "cfrg@irtf.org" <cfrg@irtf.org>
Subject: Re: [Cfrg] (SPAM) Re: FourQ draft now available
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
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, 23 Sep 2016 16:35:53 -0000

On Fri, 23 Sep 2016 14:11:00 +0000
Erwann Abalea <Erwann.Abalea@docusign.com> wrote:

> Maybe that doesn’t count as a « major protocol », or even as an
> Internet use, but I see a potential benefit in the C-ITS domain
> (Cooperative Intelligent Transport Systems), where cars and
> infrastructure broadcast signed messages up to 10 times per second,
> maybe more frequently in some specific use-cases. With a 300m
> reception range in urban areas, that’s a lot of signed messages to
> check each second, with safety concerns. Current standards (IEEE 1609
> and ETSI ITS) use ECDSA under NIST-P256 curve, some are pushing for
> Brainpool (guess who?), a few people would like to see something new
> but see resistance. In the corresponding working groups, cryptography
> is often seen as very costly (bandwidth, CPU, hardware, …), it’s good
> to see progress in some of these costs.

I don't see this as a very convincing case. First of all this strikes
me as a "this may be useful for X" argument, highly speculative and
very different from a "we want to use this in X once it's standardized".

If they currently use P256 and consider switching to brainpool then
probably performance isn't their biggest concern, because it's well
known that the brainpool curves are amongst the slowest options. (I
have some guesses why brainpool is considered, but that has probably
more to do with nationalism than with technology arguments.) I also
wonder if the people who see cryptography as costly base their opinion
on real numbers or just myths (I see this a lot in the TLS space where
people often have unrealistically high ideas about the performance
costs).

Given that my trust in these industries to implement cryptography in a
careful way is limited I'd consider giving them a safer option (aka
curve25519) is probably smarter than giving them one that has
implementation pitfalls.


-- 
Hanno Böck
https://hboeck.de/

mail/jabber: hanno@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42