Re: [Cfrg] Curve selection revisited

Robert Moskowitz <rgm-sec@htt-consult.com> Mon, 28 July 2014 20:05 UTC

Return-Path: <rgm-sec@htt-consult.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 1DB721A016C for <cfrg@ietfa.amsl.com>; Mon, 28 Jul 2014 13:05:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id toPHHVI4pmv1 for <cfrg@ietfa.amsl.com>; Mon, 28 Jul 2014 13:05:28 -0700 (PDT)
Received: from klovia.htt-consult.com (klovia.htt-consult.com [IPv6:2607:f4b8:3:0:218:71ff:fe83:66b9]) by ietfa.amsl.com (Postfix) with ESMTP id 5025B1A0126 for <cfrg@irtf.org>; Mon, 28 Jul 2014 13:05:28 -0700 (PDT)
Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id DFF5462A9F; Mon, 28 Jul 2014 20:05:25 +0000 (UTC)
X-Virus-Scanned: amavisd-new at localhost
Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GSvPbuArrFcn; Mon, 28 Jul 2014 16:05:15 -0400 (EDT)
Received: from lx120e.htt-consult.com (nc4010.htt-consult.com [208.83.67.156]) (Authenticated sender: rgm-sec@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 3A18D62A76; Mon, 28 Jul 2014 16:05:15 -0400 (EDT)
Message-ID: <53D6ACFA.20002@htt-consult.com>
Date: Mon, 28 Jul 2014 16:05:14 -0400
From: Robert Moskowitz <rgm-sec@htt-consult.com>
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 <stephen.farrell@cs.tcd.ie>, Michael Jenkins <m.jenkins.364706@gmail.com>
References: <CA+Vbu7xroa68=HOZtbf=oz7kK2EeUv_z1okpnjxHPR0ZtHD5cA@mail.gmail.com> <53D66506.4080809@htt-consult.com> <CAC2=hnfsZHAmnzmVAkQeKN3P1rrO+CfrJSjjWjKCb9awsrUGYA@mail.gmail.com> <53D692A8.6040105@htt-consult.com> <53D69BD5.1040904@cs.tcd.ie>
In-Reply-To: <53D69BD5.1040904@cs.tcd.ie>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/PEPXZg9fmOggjagJruDzopAGcRo
Cc: "cfrg@irtf.org" <cfrg@irtf.org>
Subject: Re: [Cfrg] 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: 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.