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

Jérôme Härri <Jerome.Haerri@eurecom.fr> Thu, 15 April 2021 10:35 UTC

Return-Path: <Jerome.Haerri@eurecom.fr>
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 B131C3A1A5D for <its@ietfa.amsl.com>; Thu, 15 Apr 2021 03:35:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 a0JYv8jbK8_J for <its@ietfa.amsl.com>; Thu, 15 Apr 2021 03:35:42 -0700 (PDT)
Received: from smtp.eurecom.fr (smtp.eurecom.fr [193.55.113.210]) by ietfa.amsl.com (Postfix) with ESMTP id 297323A1A5A for <its@ietf.org>; Thu, 15 Apr 2021 03:35:41 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.82,223,1613430000"; d="scan'208";a="2908337"
Received: from monza.eurecom.fr ([192.168.106.15]) by drago1i.eurecom.fr with ESMTP; 15 Apr 2021 12:35:39 +0200
Received: from portege33 (unknown [192.168.200.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by monza.eurecom.fr (Postfix) with ESMTPSA id 681581C7 for <its@ietf.org>; Thu, 15 Apr 2021 12:35:39 +0200 (CEST)
From: =?iso-8859-1?B?Suly9G1lIEjkcnJp?= <Jerome.Haerri@eurecom.fr>
To: "'IPWAVE WG'" <its@ietf.org>
References: <acc0f475-7f7b-bfbe-1099-913f0cef4de6@gmail.com>
In-Reply-To: <acc0f475-7f7b-bfbe-1099-913f0cef4de6@gmail.com>
Date: Thu, 15 Apr 2021 12:35:38 +0200
Organization: EURECOM
Message-ID: <01d601d731e3$140e2ed0$3c2a8c70$@eurecom.fr>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQGNE4eOrl1DVgZsmuuV5v0KN1fNOKtJm4nQ
Content-Language: en
Archived-At: <https://mailarchive.ietf.org/arch/msg/its/h3jh6bDf2Pjx_q9OwdubAZJv0qE>
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: Thu, 15 Apr 2021 10:35:47 -0000

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