Re: [Cfrg] Curve selection revisited

Robert Moskowitz <> Mon, 28 July 2014 20:05 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1DB721A016C for <>; Mon, 28 Jul 2014 13:05:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id toPHHVI4pmv1 for <>; Mon, 28 Jul 2014 13:05:28 -0700 (PDT)
Received: from ( [IPv6:2607:f4b8:3:0:218:71ff:fe83:66b9]) by (Postfix) with ESMTP id 5025B1A0126 for <>; Mon, 28 Jul 2014 13:05:28 -0700 (PDT)
Received: from localhost (unknown []) by (Postfix) with ESMTP id DFF5462A9F; Mon, 28 Jul 2014 20:05:25 +0000 (UTC)
X-Virus-Scanned: amavisd-new at localhost
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GSvPbuArrFcn; Mon, 28 Jul 2014 16:05:15 -0400 (EDT)
Received: from ( []) (Authenticated sender: by (Postfix) with ESMTPSA id 3A18D62A76; Mon, 28 Jul 2014 16:05:15 -0400 (EDT)
Message-ID: <>
Date: Mon, 28 Jul 2014 16:05:14 -0400
From: Robert Moskowitz <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0
MIME-Version: 1.0
To: Stephen Farrell <>, Michael Jenkins <>
References: <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "" <>
Subject: Re: [Cfrg] Curve selection revisited
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 28 Jul 2014 20:05:30 -0000

On 07/28/2014 02:52 PM, Stephen Farrell wrote:
> Hi Bob,
> On 28/07/14 19:12, Robert Moskowitz wrote:
>> Some of it is NOT internet protocols.  IEEE 1609.4 WSMP is a MAC direct
>> protocol.  In 1609, it is all about broadcast messages, as every car
>> needs to receive it and there is NO time for any setup. Sign the
>> message, get your channel allocation and send.  There is IP for some
>> stuff, but most of that is V2R (roadside).  If we tackle a proper CANbus
>> (now there is an interesting non-protocol) replacement, most of it will
>> be a MAC message format.  And then there is SMS.  I can keep coming up
>> with cases where there is no IP (IEEE 11073), or IP only occurs at the
>> gateway (pacemaker (IEEE 802.15.6) to hospital).
>> The lack of an Internet layer, and maybe even a transport layer with
>> only a message (session) layer or just MACsec, does not mean no
>> security.  Security happens at many layers other than IP (IPsec) or
>> Transport (TLS, DTLS, SRTP (or is that session)).
> I think it'll be interesting to see if the work done on new curves
> here maps well or badly to lower layers. I do not think that's a
> reason to hold up this work though - most lower layer ECC is afaik
> done in h/w that is not amenable to change and for which I don't
> know of any desire for change. If someone doing 1609 in h/w really
> wanted some new curves that'd be interesting for sure, but again
> I do not think we should hold up this work for that purpose. Given
> the relative timing and differing modus operandi of the various
> SDOs involved, trying to incorporate such requirements could easily
> add 6 months or more of nothing but delay.

Well some in ETSI wanted the inclusion of Brainpool curves in 1609, but 
so far that has not gained any significant push.

I get your concern about timing, but If a tie-breaker is needed, 
consider these points.