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

"Panos Kampanakis (pkampana)" <pkampana@cisco.com> Mon, 16 September 2019 21:35 UTC

Return-Path: <pkampana@cisco.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 2FF7F1200C7 for <secdispatch@ietfa.amsl.com>; Mon, 16 Sep 2019 14:35:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level:
X-Spam-Status: No, score=-14.501 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_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=UBIaVTpp; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=CiIe9Bf8
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 mUUxtPLRPSEu for <secdispatch@ietfa.amsl.com>; Mon, 16 Sep 2019 14:35:51 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB814120041 for <secdispatch@ietf.org>; Mon, 16 Sep 2019 14:35:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6622; q=dns/txt; s=iport; t=1568669750; x=1569879350; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=y5+nyU6untfCLeNV/YkdQK9git28fT3gzZ9UY8z/ISg=; b=UBIaVTppKQSVS8rz5gmoJU77GUKFhGHnXgJHNAhAsrYz2eGy3CGGZG79 b17WEfTSO+lDuvwEasn/9gLsJd6+33emXLH0izTOqf7JoLMdznbwEjEhY GrriazTLKoytqSCn1UdZNVygsQ18yxTAftNz45NFMZKiGMxAqHgHPUN0E c=;
IronPort-PHdr: =?us-ascii?q?9a23=3A1r+jgxQZxSVHT584YfiP6TbzAdpsv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESXBNfA8/wRje3QvuigQmEG7Zub+FE6OJ1XH1?= =?us-ascii?q?5g640NmhA4RsuMCEn1NvnvOjQ5FcFaXVls13q6KkNSXs35Yg6arw=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AiAgAS/39d/4YNJK1mGwEBAQEDAQE?= =?us-ascii?q?BBwMBAQGBZ4FFUANtViAECyqEIYNHA4pxTYIPl3GCUgNUCQEBAQwBASMKAgE?= =?us-ascii?q?BhD8CF4JYIzgTAgMJAQEEAQEBAgEFBG2FLgyFSgEBAQECARILBhEMAQE4BAc?= =?us-ascii?q?EAgEIEQQBAQECAiYCAgIwFQgIAgQBEggMBweDAYFqAw4PAQIMolUCgTiIYXO?= =?us-ascii?q?BMoJ9AQEFhQ0YghcDBoEMKIt4GIFAP4ERRoJMPoJhAQEDgWAVgnQygiaMREc?= =?us-ascii?q?SgjGcMm4KgiKHBY4WgjWWZIRIiUGBOIZUjRWDYQIEAgQFAg4BAQWBaSGBPxE?= =?us-ascii?q?IcBU7gmyCQgwXg0+FFIU/c4Epj00BAQ?=
X-IronPort-AV: E=Sophos;i="5.64,514,1559520000"; d="scan'208";a="630375774"
Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 16 Sep 2019 21:35:49 +0000
Received: from XCH-ALN-006.cisco.com (xch-aln-006.cisco.com [173.36.7.16]) by alln-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id x8GLZnil011212 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 16 Sep 2019 21:35:49 GMT
Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-ALN-006.cisco.com (173.36.7.16) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 16 Sep 2019 16:35:48 -0500
Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 16 Sep 2019 16:35:48 -0500
Received: from NAM03-DM3-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 16 Sep 2019 17:35:47 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dmJTnbHenbypCxo0R1Mr4icBGsEDzxCTOlCJ0aIwXGmm65jduJmXUFTzGvz+iIyeBHgjwWlZIwoKTXuiFBtqrNBASAT3h+XHGnjwPwxL8KPoJnYEzpKwKfmVWLJokxxbJd8jJeakDrjI3VHieRPbKIgF63Mq0gSduwIgXYX6pQzj36Byv9X5VquqAAPtj4h84BqecEqJ11XTdpcNTPzKVkGx3sCQtWKf4ML8sZ4XqUPQ56xuPhqlqXeOTLe3Nh3Aoz3o/Zh5k5C7iS/ZsHDNVxr2AfRLr/eNWXKgTaWYg6mcDIEx4OOqgzkoeddjdC999/Xku7YA9/Kak/JzbV5PUw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=y5+nyU6untfCLeNV/YkdQK9git28fT3gzZ9UY8z/ISg=; b=c6tS1v5+FTsUOrqARrI/YCdYyL2qRTmLDT3qaDmn3VsfcxPWZbmzzhs7f3zmmGOUEOzd2tkRccd+4UF5ArdtEMv7QR4f6eU7GAoBGmxct6iVIBo43hiPewaPblRT6pUhzA5v3PKJngGNWGKByRyqMTUwomeZR6vr0+44FSP+Ifr65O9GFZ4WxnHPQ/DIRwHCnDe9TheYLkR1IEhUtiJLcMJZS898Ico7ycXpTc88CrolI0lpnSUMlCyaagyj9toIkmFweXhjA44f8409aG9Jv/RBLOT81mAYsKTZkBVyTcxvzGB1jZr6eZsV+bqoO+BCzc1NR0DTxcM8WRdfp/B3jA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=y5+nyU6untfCLeNV/YkdQK9git28fT3gzZ9UY8z/ISg=; b=CiIe9Bf8lXLnklHkjIYDQWDXplKxDu+Q3ERQ3ieez7RmJPYt5SlCL+cTB2UkYA4S7nI0MbvM9lrZftPquSpxiLObn9YYl05XeoyADyZ/T3k2tXLBXwfBYoeGgi0ZEV8Ui0MYG/acXM2YqdYWNMwePiiKE5c8Ej0kpm1Bl4jWjKw=
Received: from BN7PR11MB2547.namprd11.prod.outlook.com (52.135.255.146) by BN7PR11MB2627.namprd11.prod.outlook.com (52.135.255.31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2263.23; Mon, 16 Sep 2019 21:35:46 +0000
Received: from BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::20df:b3df:537d:fd20]) by BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::20df:b3df:537d:fd20%7]) with mapi id 15.20.2263.023; Mon, 16 Sep 2019 21:35:46 +0000
From: "Panos Kampanakis (pkampana)" <pkampana@cisco.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, "secdispatch@ietf.org" <secdispatch@ietf.org>
Thread-Topic: [Secdispatch] Problem statement for post-quantum multi-algorithm PKI
Thread-Index: AQHVaXfguOLYcR2lakuySIEKtpaW76coaBSAgAIKrYCAAAJdAIAAAaMAgAI8h4CAAB3FAIAB/xSAgAABVvA=
Date: Mon, 16 Sep 2019 21:35:46 +0000
Message-ID: <BN7PR11MB2547F76FF7FBAE9ECBBA8E0BC98C0@BN7PR11MB2547.namprd11.prod.outlook.com>
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>
In-Reply-To: <3cfa21d8-efe2-1a69-5268-0a39e9171fe1@cs.tcd.ie>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=pkampana@cisco.com;
x-originating-ip: [2001:420:c0c4:1008::26]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: bdf5e1b4-ba1d-499c-c2e7-08d73aedd606
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600167)(711020)(4605104)(1401327)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:BN7PR11MB2627;
x-ms-traffictypediagnostic: BN7PR11MB2627:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: <BN7PR11MB2627D89DF242E75337888CB7C98C0@BN7PR11MB2627.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0162ACCC24
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(376002)(366004)(346002)(39860400002)(396003)(51914003)(13464003)(189003)(199004)(9686003)(55016002)(99286004)(6306002)(446003)(7736002)(74316002)(305945005)(110136005)(296002)(86362001)(66476007)(2906002)(6506007)(6246003)(476003)(102836004)(53546011)(186003)(11346002)(52536014)(76116006)(316002)(66446008)(64756008)(66556008)(66946007)(76176011)(46003)(7696005)(53936002)(5660300002)(6116002)(8676002)(14444005)(486006)(81166006)(71190400001)(2501003)(229853002)(71200400001)(256004)(6436002)(81156014)(8936002)(14454004)(966005)(478600001)(33656002)(25786009); DIR:OUT; SFP:1101; SCL:1; SRVR:BN7PR11MB2627; H:BN7PR11MB2547.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: xfw77vYmKJRUYFNIMLxrbSps2DyQesZfsUCPPJ5l6+WZK9lDD36xy3O8tF9XxuXqIJdtOCGGRMcW4IRM78hk7qcOTgJ1fkIqnRlOE0YLU5k8/DOT2COAeS/Bdkw2WjLugaxcBbZ2pdYr55lpbR1gXBaEWvPElxa5sFU96grKtnAnRr4oszvzFBj8tY6FUpA3H6nes1r2YcAi8+rjhfXSRqLqNI7TMW/i92C4y32luQAjdBaJR0xd2k7qkNsmIAmbBJbxmQ1GgumHWut0j030QwgeJZQIgnpENHbF2w0gjFI6xmSKcPy9+OdlU7v3ogSscqRzhO+/pJkzP60B6ZZLTxXs91sKLNDmCgI4A3QSbrK+w4pWE5hwIhrgTOGtsRHq7YBWzZyRZsLp98UjCR8xxg1eTTUw/05ZzccNYetfvcI=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: bdf5e1b4-ba1d-499c-c2e7-08d73aedd606
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Sep 2019 21:35:46.8022 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: Ios7rIrLH6v6Ia37v2MEqz5zXEVIl8b99xSn7ubV55K30qqeNK9ahTdbJCcLQ0gO5nKAe/EGBNY55vs8PbYoDg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2627
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.16, xch-aln-006.cisco.com
X-Outbound-Node: alln-core-12.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdispatch/pcmZJDdrb8ASOKo7pTKFcWPITsE>
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: Mon, 16 Sep 2019 21:35:55 -0000

> That seems to beg the question again as to why x.509 is needed at all as part of a PQ solution. 

Because there is nothing else as widely adopted. You haven't articulated what would replace X.509 and how the world would migrate away from such a ubiquitous standard. 
Composite classic+PQ X.509 may not be the way to go, but replacing X.509 altogether with something new is not a realistic goal imo. 




-----Original Message-----
From: Secdispatch <secdispatch-bounces@ietf.org> On Behalf Of Stephen Farrell
Sent: Monday, September 16, 2019 4:59 PM
To: secdispatch@ietf.org
Subject: 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