Re: [ipwave] RFC8902 - TLS with ITS Certificates, EXPERIMENTAL, and the one PKI and one Internet

Alexandre Petrescu <alexandre.petrescu@gmail.com> Mon, 26 April 2021 15:03 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 9C0D33A22FD for <its@ietfa.amsl.com>; Mon, 26 Apr 2021 08:03:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.632
X-Spam-Level:
X-Spam-Status: No, score=-1.632 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.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, 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 EWeuypkL8790 for <its@ietfa.amsl.com>; Mon, 26 Apr 2021 08:03:13 -0700 (PDT)
Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (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 02F1F3A22FC for <its@ietf.org>; Mon, 26 Apr 2021 08:03:12 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 13QF39rQ030257; Mon, 26 Apr 2021 17:03:09 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 658792031B9; Mon, 26 Apr 2021 17:03:09 +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 5580D201860; Mon, 26 Apr 2021 17:03:09 +0200 (CEST)
Received: from [10.14.5.141] ([10.14.5.141]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 13QF38SL028537; Mon, 26 Apr 2021 17:03:08 +0200
To: Russ Housley <housley@vigilsec.com>, =?UTF-8?B?SsOpcsO0bWUgSMOkcnJp?= <Jerome.Haerri@eurecom.fr>
Cc: IPWAVE WG <its@ietf.org>
References: <acc0f475-7f7b-bfbe-1099-913f0cef4de6@gmail.com> <01d601d731e3$140e2ed0$3c2a8c70$@eurecom.fr> <A4088CEC-DD21-40C0-8998-FE4715FA59DC@vigilsec.com>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <5d251ef1-ffb0-0a3e-346a-9077517c6a40@gmail.com>
Date: Mon, 26 Apr 2021 17:03:07 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0
MIME-Version: 1.0
In-Reply-To: <A4088CEC-DD21-40C0-8998-FE4715FA59DC@vigilsec.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/26CjNv625xAvEhYIw3Umm8jRdls>
Subject: Re: [ipwave] RFC8902 - TLS with ITS Certificates, EXPERIMENTAL, and the one PKI and one Internet
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: Mon, 26 Apr 2021 15:03:18 -0000


Le 15/04/2021 à 13:46, Russ Housley a écrit :
> Alex and Jérôme:
> 
> First, the IETF did not publish RFC 8902.

Who published RFC8902 if not the IETF?

> That went through the independent stream.

I think independent streams are fine as long as they dont risk hurting.

> Second, this was briefed to the TLS WG and the IPWAVE WG.  The
> presentation to IPWAVE was at IETF 104.  The minutes say, in part:
> 
> WW introduces TLS authentication using certificates in the format 
> defined in ETSI ITS and IEEE WAVE.  The objective is to enable 
> client/server authentication these certificates.  TLS WG has no 
> interest, so WW proposes the work in IPWAVE WG.
> 
> The IPWAVE WG also did not have an interest in this work.  So, it it
> not at all surprising that the people that are using the ETSI ITS and
> IEEE WAVE certificates took another path.

It is a private path.  I do not disagree with private paths.

Alex

> 
> Russ
> 
> 
>> On Apr 15, 2021, at 6:35 AM, Jérôme Härri
>> <Jerome.Haerri@eurecom.fr> wrote:
>> 
>> Dear Alex,
>> 
>> Thanks. Indeed such discrepancies is particularly an issue when it
>> comes to merging wireless and wired (V2I). For example, you send a
>> DENM over 5G reaching a MEC. It will remove the ETSI KPI and do
>> something on its own (not fully sure what exactly), or if you use
>> MQTT type of interaction, where it is even less clear (what a
>> broker will do on a DENM sent over JSON is not fully clear to keep
>> track of any kind of security/data integrity...
>> 
>> For that matter, there was one effort from C-ROAD to develop
>> something called 'Facilities' PKI, saying that the ITS KPI are at
>> facilities layer and no longer at geonet. The advantage is that at
>> least now, you do not need to remove the KPI when moving and
>> exchanging DENM (or else) in backend. But I am not sure of the
>> current status or even if this WI is actually active.
>> 
>> Now, I do not fully agree with you with the equivalence of the
>> internet KPI and ITS KPI. Indeed, the principle is the same, but in
>> the test you mention, the trust chain is not guaranteed (you edit
>> your own root-CA for the purpose of the tests, but for example in
>> one of our cross-border deployment (e.g. DE-FR), this solution does
>> not work, as a German car will not recognize the CA from a French
>> root-CA. So, the key issue I see is not really (or only) on 
>> security but on Trust. The ITS KPI is one option, there might be
>> others, but 'open ssl' strategies still face the trust-chain
>> issue.
>> 
>> Best Regards,
>> 
>> Jérôme
>> 
>> -----Original Message----- From: its <its-bounces@ietf.org> On
>> Behalf Of Alexandre Petrescu Sent: Thursday, 15 April 2021 12:20 
>> To: IPWAVE WG <its@ietf.org> Subject: [ipwave] RFC8902 - TLS with
>> ITS Certificates, EXPERIMENTAL, and the one PKI and one Internet
>> 
>> Hi, IPWAVErs,
>> 
>> A colleague pointed me to this recently issued RFC 8902 about TLS
>> with ITS Certificates.
>> 
>> This RFC is of an EXPERIMENTAL Category.
>> 
>> It might be in agreement with other IEEE standards such as 1609.2.
>> 
>> But I must say that I think it further deepens the discrepancy
>> between what is PKI in the Internet and what is the closed PKI for
>> ITS.  That is a discrepancy that exists for a long time, and I must
>> share that - IMHO - I am surprised that the IETF issues an RFC that
>> further promotes such a discrepancy.
>> 
>> This discrepancy is the following: in a few trials I participated,
>> and some about I heard of, people use normal PKI with openssl and
>> normal certificates in cars, over IP, on cellular links like 4G.
>> They work fine.  The CA is a local CA (not a commercial CA), but
>> the concept _is_ compatible with normal CAs.  These dont use the
>> ETSI ITS-specific certificates, neither the 1609.2 certificates.
>> 
>> I think there are more such trial deployments using local (but
>> standard, openssl PKIs and certificates) than there are trials
>> using ETSI ITS certificates or 1609.2 certificates.  The reason is
>> because the former is all open source software and freely
>> accessible standards, whereas 1609.2 are closed documents and ETSI
>> ITS certificate software is not integrated in mainline software
>> like openssl.
>> 
>> There are many easily accessible CAs (Certificate Authorities) that
>> are integrated in the Internet and in main web browsers, whereas
>> the ITS-specific CAs are closed, hard to access and the certificate
>> are expensive.  Many strong oppinions maintain that it should stay
>> that way: cars PKI different than Internet PKI.
>> 
>> There should be one Internet, and that means one trust, and one
>> PKI.
>> 
>> Everything else should not be done at IETF, I think; hence my
>> comment about this particular RFC.
>> 
>> That is my humble oppinion.
>> 
>> I would like to hear other oppinions?  Maybe I miss something...
>> 
>> Alex
>> 
>> _______________________________________________ its mailing list 
>> its@ietf.org https://www.ietf.org/mailman/listinfo/its
>> 
>> _______________________________________________ its mailing list 
>> its@ietf.org https://www.ietf.org/mailman/listinfo/its
>