Re: [ipwave] AH with NIST quantum resistant new algo, a possibility

Alexandre Petrescu <alexandre.petrescu@gmail.com> Tue, 18 August 2020 13:32 UTC

Return-Path: <alexandre.petrescu@gmail.com>
X-Original-To: its@ietfa.amsl.com
Delivered-To: its@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE9253A0A86 for <its@ietfa.amsl.com>; Tue, 18 Aug 2020 06:32:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.278
X-Spam-Level:
X-Spam-Status: No, score=-0.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.949, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no 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 mJtJ0EkIux_Q for <its@ietfa.amsl.com>; Tue, 18 Aug 2020 06:32:41 -0700 (PDT)
Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B77AF3A0A2E for <its@ietf.org>; Tue, 18 Aug 2020 06:32:40 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 07IDWcwf021691 for <its@ietf.org>; Tue, 18 Aug 2020 15:32:38 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 916A020382F for <its@ietf.org>; Tue, 18 Aug 2020 15:32:38 +0200 (CEST)
Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 86DA820382B for <its@ietf.org>; Tue, 18 Aug 2020 15:32:38 +0200 (CEST)
Received: from [10.8.35.150] (is154594.intra.cea.fr [10.8.35.150]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 07IDWcP4019316 for <its@ietf.org>; Tue, 18 Aug 2020 15:32:38 +0200
To: IPWAVE WG <its@ietf.org>
References: <155169869045.5118.3508360720339540639@ietfa.amsl.com> <D8D5F0B7.2F2BB8%sgundave@cisco.com> <D8D5F510.2F2BC8%sgundave@cisco.com> <3e716b4b-8236-0488-309c-7cd3a54db7b5@gmail.com> <D8D7B1E7.2F2CA2%sgundave@cisco.com> <CAD8vqFfSGKhw_ou3VB98C8r1gq=4WD8+f8C5P53C46k-0V+XuA@mail.gmail.com> <66e7c810-45a5-5244-59dc-4b764b6fb346@gmail.com> <1a6599ee-88f9-42d9-a208-918ba6711612@gmail.com> <11645738-6f95-82e5-48f1-ebc3ce54423e@gmail.com> <0ae10089-4b1a-f85c-1a3d-15e712cb7547@gmail.com> <084449fd-2693-0cfb-6589-0cf67cf9ffe6@gmail.com> <D8DA8E15.2F2F73%sgundave@cisco.com> <f93b8084-cd78-a7b0-9f06-cca1b88d44d0@gmail.com> <CAND9ES381RfVKnbqMWF73tUqKXSh5SVTDgR4Qo-qG69zCbO76A@mail.gmail.com> <5801f10e-6b38-2375-2c9b-83027df547b0@gmail.com> <CAND9ES1JUL+c9pue6CAyML=9na_5P_prtUxUcAhHk_4pPXh0sg@mail.gmail.com> <adafa93e-e4f9-5bf4-8b52-bf56f99dbc5c@gmail.com> <CAND9ES3m1=7cCAuAnADVGeqSd_EM1ascwQSJAw35AOHUuTUZ4w@mail.gmail.com>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <524e66fc-7223-e276-6942-58b494108d48@gmail.com>
Date: Tue, 18 Aug 2020 15:32:38 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0
MIME-Version: 1.0
In-Reply-To: <CAND9ES3m1=7cCAuAnADVGeqSd_EM1ascwQSJAw35AOHUuTUZ4w@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: fr
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/its/mbRuCeKCtIsUQ1iAX3Rs8oNgHfY>
Subject: Re: [ipwave] AH with NIST quantum resistant new algo, a possibility
X-BeenThere: its@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF <its.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/its>, <mailto:its-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/its/>
List-Post: <mailto:its@ietf.org>
List-Help: <mailto:its-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/its>, <mailto:its-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Aug 2020 13:32:48 -0000

Hi,

I thought the other day about this possibility.

In order to support more deployment of IPv6-over-OCB in vehicular
environments: make it better than BSM security by speculating on the future.

We would speculate on the successful selection of a NIST quantum
resistant candidate algorithm, implement it open source in linux, put
its output in the Authentication Header of IPv6, and write a draft in
the process.

If one does not like to speculate, then one could also take the few
candidates and implement them all for AH, so the end user has a choice.

Thoughts?

Alex

Le 16/04/2019 à 12:33, William Whyte a écrit :
> But none of that explains why the BSM type is in scope for this
> group. That seems like a different work item.
> 
> - sent from my phone
> 
> On Tue, Apr 16, 2019, 12:28 PM Alexandre Petrescu 
> <alexandre.petrescu@gmail.com <mailto:alexandre.petrescu@gmail.com>>
> wrote:
> 
> 
> 
> Le 16/04/2019 à 12:12, William Whyte a écrit :
>> That's a decision made further up the stack. It's not part of the
> scope
>> of this group.
>> 
>> For what it's worth: In the US, the BSM-based applications are
> based on
>> SAE J2945/1 and SAE J2735-2016 and sent over WSMP. In Europe, 
>> cooperative awareness using CAM is based on EN 302 637-2 and sent
> over
>> BTP. But even if BSMs were sent over IP, the version of BSM used
> would
>> be out of scope for this group. That's how layered systems work.
> 
> I agree layered systems are good to focus, and interfaces.
> 
> I think that an overarching CAM-BSM message put on UDP/IP specified
> at IETF may get benefits beyond just layering and interfaces.
> 
> Such a spec would tell, for example, that in worst case the cars
> MUST accept both EtherTypes (dont drop either), by the principle of
> being conservative on what to accept.  And in best case expect an
> IPv6 EtherType that carrying an IP datagram carrying an overarching
> BSM-CAM.
> 
> That could probably improve safety in some situations.
> 
> It is also true that that is a standpoint of IP packets being the
> same all over the world, whereas cars are not really the same.  E.g.
> in America the cars are allowed to have both left and right yellow
> lights turned on permanently, but not in other parts of the world.
> 
> So I am really not sure whether an idea of an overarching CAM-BSM
> over IP can ever fly, even though I like it.
> 
> Alex
> 
>> 
>> William
>> 
>> - sent from my phone
>> 
>> On Tue, Apr 16, 2019, 11:45 AM Alexandre Petrescu 
>> <alexandre.petrescu@gmail.com
> <mailto:alexandre.petrescu@gmail.com> 
> <mailto:alexandre.petrescu@gmail.com 
> <mailto:alexandre.petrescu@gmail.com>>> wrote:
>> 
>> Which network/transport do BSMs use?
>> 
>> Alex
>> 
>> Le 16/04/2019 à 11:40, William Whyte a écrit :
>>> I don't fully understand why IPWAVE, which is about network /
>> transport
>>> protocols, needs to have an opinion about what form of BSM
> to use.
>>> 
>>> Cheers,
>>> 
>>> William
>>> 
>>> On Tue, Apr 16, 2019 at 10:58 AM Alexandre Petrescu 
>>> <alexandre.petrescu@gmail.com
> <mailto:alexandre.petrescu@gmail.com>
>> <mailto:alexandre.petrescu@gmail.com
> <mailto:alexandre.petrescu@gmail.com>>
>> <mailto:alexandre.petrescu@gmail.com
> <mailto:alexandre.petrescu@gmail.com>
>> <mailto:alexandre.petrescu@gmail.com
> <mailto:alexandre.petrescu@gmail.com>>>> wrote:
>>> 
>>> Sri,
>>> 
>>> Thank you very much for the email.
>>> 
>>> I would like to take this opportunity to discuss
> publicly a
>> particular
>>> topic in your email, that we already touched upon in
> private
>> a few
>>> months ago.
>>> 
>>> I purposefully keep the other ideas of you out of this
> email,
>> but I do
>>> agree with very many of them.
>>> 
>>> Le 16/04/2019 à 05:11, Sri Gundavelli (sgundave) a écrit : [...]
>>>> From the point of view of vehicular safety, its about
>> exchange of
>>>> BSM (Basic Safety Messages) between vehicles as per
> SAEJ735
>>>> standard.
>>> 
>>> Sri, but there are at least three versions of BSM.
>>> 
>>> Which BSM do you mean?
>>> 
>>> Why SAE and not ISO?  Both have 'International' in
> their names.
>>> 
>>> Why SAE 2016 and not SAE 2009?
>>> 
>>> - SAEJ2735 version 2009 (free access), (google hits "SAE J2735") 
>>> - SAEJ2735 version 2016 (paid access, cca 100 USD), (google hits
>>> "SAE J2735") - and the ISO/CEN/ETSI versions (free access): 
>>> https://www.tc278.eu/cits 
>>> https://standards.iso.org/iso/ts/19091/addgrp_c
>>> 
>>> (remark I dont mention ETSI CAM, which is ITS safety
> in Europe).
>>> 
>>> The three seem to be different in contents, to a few
> people.
>> Myself I
>>> identified the first and second to be distinct.
>>> 
>>> Ideally, safety would be just one standard, right?
> Something
>> like a
>>> combination of all BSM versions with the CAM version
> running on a
>>> transport that is common to all.
>>> 
>>> A safe car would need to be able to understand all
> these CAM
>> and BSM
>>> versions; if it misses just one because of some syntax
> error,
>> well,
>>> safety would be at stake.
>>> 
>>>> [...] and for very good reason IEEE WAVE standards
> did not
>> bother to
>>>> require IPv6 transport for carrying these messages.
>>> 
>>> I doubt that reason.
>>> 
>>> Alex
>>> 
>>> _______________________________________________ its mailing list 
>>> its@ietf.org <mailto:its@ietf.org> <mailto:its@ietf.org
> <mailto:its@ietf.org>> <mailto:its@ietf.org <mailto:its@ietf.org>
>> <mailto:its@ietf.org <mailto:its@ietf.org>>>
>>> https://www.ietf.org/mailman/listinfo/its
>>> 
>>> 
>>> 
>>> --
>>> 
>>> ---
>>> 
>>> I may have sent this email out of office hours. I never
> expect a
>>> response outside yours.
>> 
>