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

Stephen Farrell <stephen.farrell@cs.tcd.ie> Tue, 17 September 2019 15:07 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 B1491120059 for <secdispatch@ietfa.amsl.com>; Tue, 17 Sep 2019 08:07:24 -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 nbjhzvx6-HZh for <secdispatch@ietfa.amsl.com>; Tue, 17 Sep 2019 08:07:21 -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 B06D6120045 for <secdispatch@ietf.org>; Tue, 17 Sep 2019 08:07:20 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E40D1BE2F; Tue, 17 Sep 2019 16:07:18 +0100 (IST)
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 hSctMO-KRyKk; Tue, 17 Sep 2019 16:07:18 +0100 (IST)
Received: from [134.226.36.93] (unknown [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A1517BE2E; Tue, 17 Sep 2019 16:07:18 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1568732838; bh=QkjdNZzkK4rGQGaDlQ0doy1GaQUvvXiGnDmxNZ5luPU=; h=Subject:To:References:From:Date:In-Reply-To:From; b=WF2EsU4tGKKGFrq88QqZn9zi8+/Gmb6lJ0zMYTclo7vOERX8YvUQO2zE17Uum9i4v 3JsfvjyoNqb40yOpGR1T6yqqmphAQZwDdy8QNj27sCKRIxs+wpUFxPKiYzm71qF0Hx S2hVXHtZnpT4BpvStpyuoat42Cv3f+4zTBEhxxKM=
To: Mike Ounsworth <Mike.Ounsworth@entrustdatacard.com>, "secdispatch@ietf.org" <secdispatch@ietf.org>
References: <a2e32c33-8589-f3fb-97e5-c5977dfc64b4@openca.org> <BL0PR11MB317285DF599EC58CCF26FD5EC1B00@BL0PR11MB3172.namprd11.prod.outlook.com> <28224.1568427573@dooku.sandelman.ca> <cf1a301c-47d6-7565-ddc7-69048e3c08f3@cs.tcd.ie> <5F8D32EB-CE27-4ECD-997F-D0AAE4B798B5@akamai.com> <2b87f695-314c-5aed-14a4-9877fe254161@ericsson.com> <CAN40gStdbJ0TNoeL0VFU4Tx1F5ubtAdJnz+QJXYFFAP7W2OV7w@mail.gmail.com> <3cfa21d8-efe2-1a69-5268-0a39e9171fe1@cs.tcd.ie> <8e67edddf9154537b438db96ac86e2f8@PMSPEX05.corporate.datacard.com> <e3d7556b-10a4-a9d8-147e-28f177d8122d@cs.tcd.ie> <3048353759814820b0c0a289caee038c@PMSPEX05.corporate.datacard.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: <e1d8362d-f53d-d4c0-2f1f-05af42e9e693@cs.tcd.ie>
Date: Tue, 17 Sep 2019 16:07:17 +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: <3048353759814820b0c0a289caee038c@PMSPEX05.corporate.datacard.com>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Q5DsLfmSf3RdMRVIvQPIm3PvFtxynuFlP"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdispatch/85_Vtr2DsWqyt8K2nSuEOyIiBEE>
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: Tue, 17 Sep 2019 15:07:25 -0000

Hiya,

On 17/09/2019 15:51, Mike Ounsworth wrote:
> Hi Stephen,
> 
> I want to point out that while this discussion and existing came from
> LAMPS, and therefore are X.509 / PKIX in nature, the "Composite"
> proposal in my Problem Statement draft is lower level than X.509 and
> could be applied to any protocol that uses octet strings for public
> keys and signatures.
> 
> 
> I've posted a new version with minor tweaks to make that more clear.
> 
> https://datatracker.ietf.org/doc/draft-pq-pkix-problem-statement/

Fair enough. We can chat about it all at IETF106 :-)

Cheers,
S.

PS: Just while I think of it - ISTM hard to v. hard
to cater for stateful signatures in any of this, e.g.
using RFC8391 or RFC8554. Not asking for an answer
from you now, but it's another factor to consider.
That may argue against embedding any of this in
x.509 - notAfter could be meaningless to dangerous
for such algs. It may also be another argument to
wait and see what the NIST competition produces but
again we can talk about it at IETF106.

> 
> - - - Mike Ounsworth | Office: +1 (613) 270-2873
> 
> -----Original Message----- From: Stephen Farrell
> <stephen.farrell@cs.tcd.ie> Sent: Monday, September 16, 2019 4:57 PM 
> To: Mike Ounsworth <Mike.Ounsworth@entrustdatacard.com>om>;
> secdispatch@ietf.org Subject: Re: [EXTERNAL]Re: [Secdispatch] Problem
> statement for post-quantum multi-algorithm PKI
> 
> 
> Hiya,
> 
> On 16/09/2019 22:37, Mike Ounsworth wrote:
>> Hi Stephen,
>> 
>> I feel like we're arguing in circles here and not making any
>> progress.
> 
> I don't think we're arguing in circles. (When one of us says that
> again, you may have a case:-)
> 
>> Re: figuring out "hybrid signature authentication" in parallel with
>>  NIST; You seem to be implying that we can't work on defining
>> message structures to hold multiple keys and signatures until we
>> know the exact encodings of the NIST winners. I'm not sure I follow
>> the reason why.
> 
> "can't work" is not what I said. I argued it'd be unwise. My
> experience of the output of NIST competitions is that it seems often
> followed by a year or so of confusion as to how to represent
> algorithm parameters and as to how many variants of algorithms are
> defined. I also recall the NULL AlgorithmIdentifier parameters fun
> with x.509 going on for years. I bet if you went to stackexchange
> you'd find quite recent questions resulting from that decades old
> lack of clarity in defining such things.
> 
>> 
>> Currently, something like, for example, CMS (RFC 5652)  is
>> abstracted away from the encodings of a given algorithm; an
>> algorithm can choose any method it wishes to turn its public key
>> and signature into an octet string; how it does it is an internal
>> detail of the algorithm and has no bearing on the CMS spec. This is
>> abstraction between protocol and crypto is a core part of crypto
>> agility. Surely we can start thinking about how to properly combine
>> multiple signatures before we know exactly what those signatures
>> will be.
> 
> Sure, chatting about that last is fine and I'm happy to engage. 
> Starting from an assumption that that mixing is done inside x.509 is
> begging the question though.
> 
>> Re: "Why X.509?" You seem to be expecting me to justify why X.509
>> is worth keeping. I'm expecting you to propose an alternative and
>> justify why it's better. We're at a stalemate.
> 
> No. We're keeping x.509 (sadly:-). Yes, I'm asking for reasons why it
> is necessary to modify x.509 for a PQ PKI. If you don't have any
> argument to that effect that's fine, you're then arguing that this
> design is easier for you. That's a sane argument for what could be
> considered a not-sane outcome:-)
> 
>> Since X.509 is the accepted standard, I think the ball's in your
>> court here to justify why it should be binned.
> 
> Multiple algs/keys per cert requires everyone who uses x.509 now to
> change. That is not warranted by wishes for a PQ PKI at this point,
> and perhaps never.
> 
> That and it's an ~30 year old not very good technology, so yeah,
> maybe I'm just fed up with it having first written code for x.509 in
> about 1992;-)
> 
> Cheers, S.
> 
>> 
>> 
>> - - - Mike Ounsworth | Office: +1 (613) 270-2873
>> 
>> -----Original Message----- From: Secdispatch 
>> <secdispatch-bounces@ietf.org> On Behalf Of Stephen Farrell Sent: 
>> Monday, September 16, 2019 3:59 PM To: secdispatch@ietf.org
>> Subject: [EXTERNAL]Re: [Secdispatch] Problem statement for
>> post-quantum multi-algorithm PKI
>> 
>> 
>> Hiya,
>> 
>> Replying to various folks at once...
>> 
>> On 15/09/2019 15:29, Ira McDonald wrote:
>>> Hi,
>>> 
>>> Thanks for the link to Kenny's talk.
>>> 
>>> Stephen - The hard problem for automotive vehicles is that, even
>>> if Quantum Computing never comes to pass, algorithms and various
>>>  implementations go on having new weaknesses found over time. But
>>>  decent performance requires hardware assist, in many cases. But
>>>  automotive ECUs are very unlikely to start have large FPGAs
>>> added soon.  Replacing 100s of expensive ECUs in fielded vehicles
>>> to allow practical algorithm agility is not going to happen.
>>> This issue that Michael Richardson mentioned is at the top of the
>>> list for the automotive cybersecurity community.
>> 
>> I don't understand how devices that are not going to be updated can
>>  support algorithm agility. Perhaps you mean that you want to
>> deploy those devices soon and not update for a couple of decades or
>>  something? If so, that sound like a bad plan to me, and one that'd
>> be better to not cater to really. (RFC8240 has lots of discussion
>> of that.)
>> 
>> 
>> On 16/09/2019 17:05, Mike Ounsworth wrote:
>>> My Goal: multi-vendor interop on PQ certificates.
>> 
>> That seems to beg the question again as to why x.509 is needed at
>> all as part of a PQ solution.
>> 
>>> I'm coming from the perspective of a CA; it can take years to 
>>> distribute a root cert to all the places it needs to be before
>>> you can really start using it. Plus, people want to playing with
>>> these things ASAP to understand the scope of infrastructure
>>> changes required. There's the time pressure.
>>> 
>>> I think you're right that to really deploy any meaningful 20 year
>>>  root using, for example the small lattice schemes, we'll need to
>>> wait for the NIST PQC algs to stop having so much churn.
>>> 
>>> That said, laying the groundwork for the "hybrid" property in 
>>> certificates that the NIST PQC community is calling for will
>>> require much debate and a few RFCs. This work is necessary and
>>> independent of the choice of algorithm from the NIST PQC
>>> competition, so why should we wait until 2023 to _start_ thinking
>>> about it? Why not do it in parallel, be able to offer alpha test
>>> versions of PKI products before the conclusion of the NIST PQC,
>>> and be ready to drop-in the NIST winners the day they're ready?
>> 
>> One reason to not do it in parallel is that we don't know how the 
>> winning algorithm parameters will look. I can easily imagine NIST 
>> modifying how those are encoded and/or introducing new variations,
>>  after basic algorithms have been picked, leading to things having
>> to be re-done.
>> 
>> (Sorry if the quoting is messed up below, if so, it was messed up
>> in my MUA before I started is my excuse:-) On 16/09/2019 19:06,
>> Daniel Van Geest wrote:
>>> Can we support multiple signatures inside a certificate? I don't
>>>  think so.
>>> 
>>> Why not?  Mike’s problem statement draft has two potential
>>> technical solutions doing just that, each with advantages and
>>> disadvantages. Or is there more of a logistical or other issue? 
>>> Knowing why you think we can’t support multiple signatures inside
>>> a certificate could help refine the problem statement.
>> 
>> Again, that assumes that x.509 is a sensible part of a solution. We
>>  should first question that. (Mike's draft [1] doesn't.)
>> 
>> Secondly, even if x.509 additions were useful somehow for backwards
>>  compatibility (which I find hard to believe TBH) then dealing
>> with
>>> 1 certificate is likely far easier than messing about inside
>>> certs
>> and thereby breaking all the lovely/horrible x.509 code out there.
>> So Mike's section 2.1 [1] is way easier than the 2.[2|3]
>> approaches, despite it being the one with no specific drafts.
>> 
>> Again, all that said, I do understand why it may be attractive for
>>  those who produce certificates to argue for putting the PQ magic
>> beans inside x.509. There are costs elsewhere implied in doing
>> that, so it ought not be a starting-out assumption.
>> 
>> I don't consider the question as to why a PQ x.509 is needed nor
>> why now has been satisfactorily answered so far.
>> 
>> Cheers, S.
>> 
>> [1] https://tools.ietf.org/html/draft-pq-pkix-problem-statement
>> 
> _______________________________________________ Secdispatch mailing
> list Secdispatch@ietf.org 
> https://www.ietf.org/mailman/listinfo/secdispatch
>