Re: [Secdispatch] [EXTERNAL]Re: Problem statement for post-quantum multi-algorithm PKI

Daniel Van Geest <Daniel.VanGeest@isara.com> Thu, 12 September 2019 20:14 UTC

Return-Path: <Daniel.VanGeest@isara.com>
X-Original-To: secdispatch@ietfa.amsl.com
Delivered-To: secdispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78A6812001B for <secdispatch@ietfa.amsl.com>; Thu, 12 Sep 2019 13:14:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 AJCz-7AXNjyx for <secdispatch@ietfa.amsl.com>; Thu, 12 Sep 2019 13:14:10 -0700 (PDT)
Received: from esa1.isaracorp.com (esa1.isaracorp.com [207.107.152.166]) (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 F0195120018 for <secdispatch@ietf.org>; Thu, 12 Sep 2019 13:14:09 -0700 (PDT)
IronPort-SDR: apOXzwe6uPUnGAwkA09GC5wbFuqBDZ2N4Cni43++lh9kxWGNY71WSNuDepyLq5bYjYkpcn5gPz e5KqBqLoQDfm65kpccteIQww+RuR5l5QeYvWkAV/mL5siMyyH4OlRjOxyaKD2CQC0VUNaOTUlw 8VgJAhCmTVrC7mpW4LxGFVAkPOTlCM7l1ggoRqLnuq01VVqWAL1b9vqD1wDOXumN2mV1xiA0xE NWcaWi0sAX3zq+Lkwl/UX3pxM7ZUu3EgAvuX0pFLKyuXKRQN1hTgRgHwNZZquy8KQcI7uMMSpb SaM=
Received: from unknown (HELO V0501WEXGPR01.isaracorp.com) ([10.5.8.20]) by ip1.isaracorp.com with ESMTP; 12 Sep 2019 20:13:55 +0000
Received: from V0501WEXGPR01.isaracorp.com (10.5.8.20) by V0501WEXGPR02.isaracorp.com (10.5.9.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1779.2; Thu, 12 Sep 2019 16:14:57 -0400
Received: from V0501WEXGPR01.isaracorp.com ([fe80::d802:5aec:db34:beba]) by V0501WEXGPR01.isaracorp.com ([fe80::d802:5aec:db34:beba%7]) with mapi id 15.01.1779.002; Thu, 12 Sep 2019 16:14:57 -0400
From: Daniel Van Geest <Daniel.VanGeest@isara.com>
To: Mike Ounsworth <Mike.Ounsworth@entrustdatacard.com>, Stephen Farrell <stephen.farrell@cs.tcd.ie>, "Scott Fluhrer (sfluhrer)" <sfluhrer@cisco.com>, "Dr. Pala" <madwolf@openca.org>, "secdispatch@ietf.org" <secdispatch@ietf.org>
Thread-Topic: [Secdispatch] [EXTERNAL]Re: Problem statement for post-quantum multi-algorithm PKI
Thread-Index: AQHVaaMJ/6jQAETZZ0yqoTJT6GRHFqcoeeuA
Date: Thu, 12 Sep 2019 20:14:57 +0000
Message-ID: <9A0D239F-B81B-4324-A66D-B652B63E9CED@isara.com>
References: <a2e32c33-8589-f3fb-97e5-c5977dfc64b4@openca.org> <BL0PR11MB317285DF599EC58CCF26FD5EC1B00@BL0PR11MB3172.namprd11.prod.outlook.com> <87ef491b-0faa-06b4-e0f4-61673cba3914@cs.tcd.ie> <aaf03217f920480589eb396a6fbf6e43@PMSPEX05.corporate.datacard.com>
In-Reply-To: <aaf03217f920480589eb396a6fbf6e43@PMSPEX05.corporate.datacard.com>
Accept-Language: en-CA, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.31.5.52]
Content-Type: multipart/alternative; boundary="_000_9A0D239FB81B4324A66DB652B63E9CEDisaracom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdispatch/CvmxiyObbFnsMzt85ngUh_2FSTM>
Subject: Re: [Secdispatch] [EXTERNAL]Re: Problem statement for post-quantum multi-algorithm PKI
X-BeenThere: secdispatch@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Dispatch <secdispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdispatch>, <mailto:secdispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdispatch/>
List-Post: <mailto:secdispatch@ietf.org>
List-Help: <mailto:secdispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdispatch>, <mailto:secdispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Sep 2019 20:14:12 -0000

Hi,

On 2019-09-12, 3:48 PM, "Secdispatch on behalf of Mike Ounsworth" <secdispatch-bounces@ietf.org<mailto:secdispatch-bounces@ietf.org> on behalf of Mike.Ounsworth@entrustdatacard.com<mailto:Mike.Ounsworth@entrustdatacard.com>> wrote:

Hi Stephen,

That's an exciting solution space that's orthogonal to the ones that I wrote up in my Problem Statement draft. Do you have some concretes on what such a "replace X.509" proposal might look like?

I suggest that even with full support for such a proposal, it would still make sense to standardize a "less change to the 1980s baggage" so that existing systems have something they can do in the short term. Speaking as a PKI vendor, this is starting to be an uncomfortably hot issue with our customers who are deploying 20 year lifetime devices and want post-quantum protection on them like now with like no code changes.

So exactly as you say "people invested in x.509-based PKI may reasonably prefer less-change to more-change" :P

+1.  We’ve heard from organizations interested in tools like these but from a “we still haven’t finished the ECDSA migration yet” perspective.  Inertia may not be the best reason to pursue an idea, but I think there is demand for a solution within X.509.

Not that we shouldn’t also take this opportunity to do things right for those able to adapt more rapidly, so that they can drop the 1980s baggage (and not saddle themselves with new 2020s baggage as well :-) ).  It is an either/or proposition?  If it’s “both”, is there desire to actually work on both, or will one inevitably end up consuming all the interest/resources?

Daniel

- - -
Mike Ounsworth | Office: +1 (613) 270-2873

-----Original Message-----
From: Secdispatch <secdispatch-bounces@ietf.org<mailto:secdispatch-bounces@ietf.org>> On Behalf Of Stephen Farrell
Sent: Thursday, September 12, 2019 2:28 PM
To: Scott Fluhrer (sfluhrer) <sfluhrer@cisco.com<mailto:sfluhrer@cisco.com>>; Dr. Pala <madwolf@openca.org<mailto:madwolf@openca.org>>; secdispatch@ietf.org<mailto:secdispatch@ietf.org>
Subject: [EXTERNAL]Re: [Secdispatch] Problem statement for post-quantum multi-algorithm PKI


Hiya,

On 12/09/2019 20:08, Scott Fluhrer (sfluhrer) wrote:
I agree that this is an important problem to solve.

Depending, on the "this," I agree or disagree:-)

Discussion of how to get what PKI offers in a world where current asymmetric algorithms might be weak and where quantum-resistant, but new, algorithms are emerging, is an excellent topic to start to consider.

I also think it seems a bit mad to consider x.509 as the main thing to consider so I'm not at all keen on seeing this problem space as being one where all we need is yet another sticking plaster for x.509. That said, I do get that people invested in x.509-based PKI may reasonably prefer less-change to more-change, I just think we may be sad if we miss another opportunity to move on leaving behind some of this 1980's baggage.

Cheers,
S.

One might think we have plenty of time, given that Real Quantum
Computers are, more than likely, more than 10 years away, and even
once you have one, you cannot use your Quantum Computer to break the
authentication of recorded conversations.
On the other hand, authentication also brings in additional issues;
instead of having a two party system (where as long as both the client
and the server support a postquantum algorithm, they can negotiate
it), we now have an (at least) three party system, the client, the
server, and the CA.  this additional party makes the upgrade path more
complicated.  So, while we have more time, we may need it.
I don’t think it’s too early to start thinking about the issues..
From: Secdispatch <secdispatch-bounces@ietf.org<mailto:secdispatch-bounces@ietf.org>> On Behalf Of Dr.
Pala Sent: Thursday, September 12, 2019 10:39 AM To:
secdispatch@ietf.org<mailto:secdispatch@ietf.org> Subject: Re: [Secdispatch] Problem statement for
post-quantum multi-algorithm PKI
Hi SecDispatch, Mike,
Our industry (Cable) is working on this problem already - some of our
members have started investigating few things in the post-quantum
field and in particular how to protect our PKIs in this uncertain
environment.
With few billions certificates issued across the industry, we heavily
rely on certificates for device authentication and, therefore, we need
to work on a solution today.
For us, the use of Composite Crypto is quite an interesting path to
pursue because it provides an easy way to protect today our PKIs
against the factorization threat (not only certificates, but all the
data structures for PKIX) thus allowing to verify the authentication
with Post-Quantum algorithms when we will need to make the switch
(deferred Algorithm Agility).
We intend to support this idea and actively deploy it for our PKIs and
eventually expand the adoption of this approach in other environments
we are engaged in (e.g., medical devices, cellular networks, WiFi
Alliance and WBA, etc.)
Looking forward to find a good home for this project within the IETF
- a simple but powerful tool for our "PKI toolboxes"
Cheers, Max
Hi SecDispatch,
This got bounced here from LAMPS because the scope is potentially more
than a "limited" pkix change, and because this needs multi-WG
visibility to decide on a category of solution.
Background / history
--------------------
The Post-Quantum community (for example, surrounding the NIST PQC
competition), is pushing for "hybridized" crypto that combines RSA/ECC
with new primitives in order to hedge our bets against both quantum
adversaries, and also algorithmic / mathematical breaks of the new
primitives.
A year and a half ago, a draft was put to LAMPS for putting PQ public
key and signatures into X.509v3 extensions. This draft has been
allowed to expire, but is being pursued at the ITU.
https://datatracker.ietf.org/doc/draft-truskovsky-lamps-pq-hybrid-x509
/

Earlier this year, a new draft was put to LAMPS for defining
"composite" public key and signature algorithms that, essentially,
concatenate multiple crypto algorithms into a single key or signature
octet string. This draft stalled in LAMPS over whether it is the
correct overall approach.
https://datatracker.ietf.org/doc/draft-ounsworth-pq-composite-sigs/
Now I'm taking a step back and submitting a draft that acts as a
semi-formal problem statement, and an overview of the three main
categories of solutions.
https://datatracker.ietf.org/doc/draft-pq-pkix-problem-statement/
My Opinion
----------
Personally, I'm fairly agnostic to the chosen solution, but feel that
we need some kind of standard(s) around the post-quantum transition
for certificates and PKI. Personally, I feel that Composite is mature
enough as an idea to standardize as a tool in our toolbox for contexts
where it makes sense, even if a different mechanism is preferred for
TLS and IPSEC/IKE.
Requested action from SECDISPATCH
---------------------------------
1. Feedback on the problem statement draft.
https://datatracker.ietf.org/doc/draft-pq-pkix-problem-statement/
2. Discussion of how to progress this.
PS I'm a new IETF'er, please be gentle :P
Thanks,
- - -
Mike Ounsworth | Software Security Architect
Entrust Datacard
-- Best Regards, Massimiliano Pala, Ph.D. OpenCA Labs Director [OpenCA
Logo]
_______________________________________________ Secdispatch mailing
list Secdispatch@ietf.org<mailto:Secdispatch@ietf.org>
https://www.ietf.org/mailman/listinfo/secdispatch
_______________________________________________
Secdispatch mailing list
Secdispatch@ietf.org<mailto:Secdispatch@ietf.org>
https://www.ietf.org/mailman/listinfo/secdispatch