Re: [Cfrg] Curve selection revisited

Stephen Farrell <stephen.farrell@cs.tcd.ie> Mon, 28 July 2014 18:52 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
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 CB17E1A0A6D for <cfrg@ietfa.amsl.com>; Mon, 28 Jul 2014 11:52:08 -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 JJt8uU3zO98l for <cfrg@ietfa.amsl.com>; Mon, 28 Jul 2014 11:52:07 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 809DB1A083D for <cfrg@irtf.org>; Mon, 28 Jul 2014 11:52:07 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 8F639BE01; Mon, 28 Jul 2014 19:52:06 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wUBQrwG5xcP9; Mon, 28 Jul 2014 19:52:05 +0100 (IST)
Received: from [10.87.48.11] (unknown [86.44.64.225]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 433EABE4D; Mon, 28 Jul 2014 19:52:05 +0100 (IST)
Message-ID: <53D69BD5.1040904@cs.tcd.ie>
Date: Mon, 28 Jul 2014 19:52:05 +0100
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: Robert Moskowitz <rgm-sec@htt-consult.com>, 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>
In-Reply-To: <53D692A8.6040105@htt-consult.com>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/IFWvLdo9EW8VAkfJz3HLsaQHbDM
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 18:52:09 -0000

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.

S.