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

Stephen Farrell <stephen.farrell@cs.tcd.ie> Thu, 12 September 2019 19:28 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
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 D3AF412080D for <secdispatch@ietfa.amsl.com>; Thu, 12 Sep 2019 12:28:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.299
X-Spam-Level:
X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
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 c-sKL56t2FdJ for <secdispatch@ietfa.amsl.com>; Thu, 12 Sep 2019 12:28:20 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EFBE120251 for <secdispatch@ietf.org>; Thu, 12 Sep 2019 12:28:20 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 95380BE2E; Thu, 12 Sep 2019 20:28:18 +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 6fPmOAuIwNKe; Thu, 12 Sep 2019 20:28:16 +0100 (IST)
Received: from [10.244.2.138] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 60A15BE24; Thu, 12 Sep 2019 20:28:16 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1568316496; bh=qND+ux1BD4vUtqFMCcZiJFKRnfT+kcd+CIKnZ6IDzoY=; h=Subject:To:References:From:Date:In-Reply-To:From; b=E0NvaOG69nhaFCXjxbb4YF2QYivjdY3cXkrTJMuLTEul4ejSVvlrbgnBdgNZXm4cj ORJ0ynAlilRgrA+gHv1vGp0WIHxUDhCefxNjmbWNItuZvfALgX9nhy1JlMUm2ayJrW oxTb6vjAcvkN8dBTDJ5O58JxsySjjqkNxrgU2x+8=
To: "Scott Fluhrer (sfluhrer)" <sfluhrer@cisco.com>, "Dr. Pala" <madwolf@openca.org>, "secdispatch@ietf.org" <secdispatch@ietf.org>
References: <a2e32c33-8589-f3fb-97e5-c5977dfc64b4@openca.org> <BL0PR11MB317285DF599EC58CCF26FD5EC1B00@BL0PR11MB3172.namprd11.prod.outlook.com>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url=
Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw==
Message-ID: <87ef491b-0faa-06b4-e0f4-61673cba3914@cs.tcd.ie>
Date: Thu, 12 Sep 2019 20:28:15 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <BL0PR11MB317285DF599EC58CCF26FD5EC1B00@BL0PR11MB3172.namprd11.prod.outlook.com>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="2PUwQDariZEHyFAdKlILLjUHnd4cjV2PF"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdispatch/DIbVi9aeBAXqpB-0MaMPT1cUMdM>
Subject: Re: [Secdispatch] 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 19:28:24 -0000

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> On Behalf Of Dr.
> Pala Sent: Thursday, September 12, 2019 10:39 AM To:
> 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 
> https://www.ietf.org/mailman/listinfo/secdispatch
>