[Cfrg] IEEE 1609 requirements (was Re: Curve selection revisited)

William Whyte <wwhyte@securityinnovation.com> Tue, 29 July 2014 04:00 UTC

Return-Path: <wwhyte@securityinnovation.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50CAD1A002A for <cfrg@ietfa.amsl.com>; Mon, 28 Jul 2014 21:00:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Level:
X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] autolearn=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 JE48Tfl4oDdr for <cfrg@ietfa.amsl.com>; Mon, 28 Jul 2014 21:00:01 -0700 (PDT)
Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAD351A0020 for <cfrg@irtf.org>; Mon, 28 Jul 2014 21:00:00 -0700 (PDT)
Received: by mail-qg0-f49.google.com with SMTP id j107so9838565qga.36 for <cfrg@irtf.org>; Mon, 28 Jul 2014 21:00:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=securityinnovation.com; s=google; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=ZhTMjzogwLlRHZO7qYbFfMPJcOq/j/MsPpP9H709eis=; b=LytqWTYZ63fgsQLEUedZ84aBnbhntDHacOIdgwcMLox5rBy8XOY3H4wd4q28XbK41j ibF1dJcZAGdMesaSI3AVflr+xRKdw920SmicLpYuUit1VCH6cXzP8uR4Fbm/D7rT28vg XqN8qV/pliY3scbQWxSqPYVdi1Qfar/eo2Z58=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc :content-type; bh=ZhTMjzogwLlRHZO7qYbFfMPJcOq/j/MsPpP9H709eis=; b=cgfvHqpK1DO1n0EseJPUGBVE63cVmc9glKvVONDaJFo0EWjQ1Zetd9tibpQX338IX5 rn+LABOmLOxCuuWSzBB8EJ71jL55E7cBNiZodYZwOWulf+JQqoo+gNG/vNfpolmujjmq yy+mTICO9sEGNtPfgYwZnTgkAOCsoByWDdBAIZB2ya3kxjTJ7wlr8ZuADly52A3a8XA0 ZQ1md05pH/VLJijxILNOKkX5g7oMLrn9UIALJUrxSH8uZLWpIcfWuttpFhwXnenonnYM 6Od1lejmt12ZHmliXzSG2qd9qywQRMdXHjXuPFKSp7EjobXqpV+TE6PvqmeQEnnZOgJ9 OE9A==
X-Gm-Message-State: ALoCoQmUfukydlfxOMQ6XCoktnTF9ylZXtsKpnq9vHzk+dwCBhACUtgm8s5y+EEPt16Kq1ciyy2v
MIME-Version: 1.0
X-Received: by 10.224.123.8 with SMTP id n8mr66780465qar.40.1406606400007; Mon, 28 Jul 2014 21:00:00 -0700 (PDT)
Received: by 10.96.172.194 with HTTP; Mon, 28 Jul 2014 20:59:59 -0700 (PDT)
Date: Mon, 28 Jul 2014 23:59:59 -0400
Message-ID: <CACz1E9qP04tnXuCWtiGFrT3FGSR_9SrYpBQQe3F07k3+T2DBZw@mail.gmail.com>
From: William Whyte <wwhyte@securityinnovation.com>
To: Robert Moskowitz <rgm-sec@htt-consult.com>
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/BiOOLMo0FmH070dHNItcpDifs_Y
Cc: "cfrg@irtf.org" <cfrg@irtf.org>
Subject: [Cfrg] IEEE 1609 requirements (was Re: Curve selection revisited)
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Jul 2014 04:00:04 -0000

Hi all,

Some notes on Bob's comments in the context of vehicle-to-vehicle
communications. He's on point in general but I have a few corrections,
below.

One thing to say in general about the V2V safety communications: these
are devices that, as Bob says, have a very long lifetime and may be
hard to upgrade in the field. They also need to be produced in
reasonable volumes and be durable. These all push the groups working
on V2X communications in the direction of using crypto technology
that's already widespread, so both the US and the EU groups working on
this are currently using NIST p256 and it would be difficult to
persuade them to change at this point (with some exceptions, see
below).

Personally, I regret that we're using the NIST curves, given the poor
quality of their generation process, but I don't see the marketplace
as yet having picked a winner from the alternatives.

> 8 bit processors are the norm, and NO, Dr. Moore is NOT going to change
> that.

It's not clear that this is the case for V2V safety communications.
Collision prediction is fairly processor-intensive. All the prototypes
I know of have been on 32-bit processors. I don't see an ability to
support 8-bit processors as particularly important.

> Hardware acceleration is acceptable, but that could
> make in-field corrections impossible.

One potential bottleneck bottleneck is verification of incoming
messages. There may be 1000 incoming messages per second. Verifying
all of these requires hardware acceleration on any realistic
automotive device and for any choice of curve that I'm aware of.
Another alternative is to only verify certain messages, for example
from cars that might potentially cause a hazard. Hardware acceleration
is possible, but raises costs and risks locking in a particular crypto
solution. Europe and the US are taking different approaches to this:
in the European system, the intent is that every message is verified,
while in the US the emphasis is more on verify on demand.

> 1) Low over-the-air demands.  Every BIT counts.  We have to live with 32
> bytes; but 64 bytes may be too much.

Spectrum is another very constrained resource. If we could potentially
shave 16 bytes off every signature that's something we could be very
interested in.

> 3) Performance on an 8 bit  processor.  Performance is measured in time and
> energy.

As above, I don't think 8-bit performance is huge for V2V communications.

> 4) preserving ECDSA and ECDHE.  This is what is currently in use, and in
> some cases written into regulations (urgh), so we have to still keep them
> working.  But if something 'new' and provably good makes a big difference in
> one of the previous needs I suspect there will be an attentive audience.

If the expert judgement of the technical working groups is that a
different algorithm than ECDSA is better, we don't believe there would
be a regulatory barrier to using that other algorithm.

> But please just don't solve this for TLS on octo-core 64-bit systems.

Yes! In particular, whatever choice is made by CFRG is likely to be
more widely supported in hardware than any alternative, so CFRG's
choice will be the strongest candidate to replace ECDSA if it has
sufficient advantages.

Cheers,

William