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

Mike Ounsworth <Mike.Ounsworth@entrustdatacard.com> Tue, 17 September 2019 20:30 UTC

Return-Path: <prvs=15631f794=Mike.Ounsworth@entrustdatacard.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 4B368120873 for <secdispatch@ietfa.amsl.com>; Tue, 17 Sep 2019 13:30:56 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 OWFoCph40lLv for <secdispatch@ietfa.amsl.com>; Tue, 17 Sep 2019 13:30:54 -0700 (PDT)
Received: from mx2.entrustdatacard.com (mx2.entrustdatacard.com [204.124.80.222]) (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 3E82D12010D for <secdispatch@ietf.org>; Tue, 17 Sep 2019 13:30:54 -0700 (PDT)
IronPort-SDR: kGd8kvZHA9ihRsV8bTcirLptMM8a5ammqqNGUpUFfMeQfN2FOvMHJ0RwlAd87KTY0GFqgblmNY cPdgY0uLaNTw==
X-IronPort-AV: E=Sophos;i="5.64,518,1559538000"; d="scan'208";a="1529444"
Received: from pmspex04.corporate.datacard.com (HELO owa.entrustdatacard.com) ([192.168.211.51]) by pmspesa04inside.corporate.datacard.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA384; 17 Sep 2019 15:30:52 -0500
Received: from PMSPEX05.corporate.datacard.com (192.168.211.52) by PMSPEX04.corporate.datacard.com (192.168.211.51) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 17 Sep 2019 15:30:51 -0500
Received: from PMSPEX05.corporate.datacard.com ([fe80::8084:293e:7f03:4ab2]) by PMSPEX05.corporate.datacard.com ([fe80::8084:293e:7f03:4ab2%12]) with mapi id 15.00.1497.000; Tue, 17 Sep 2019 15:30:51 -0500
From: Mike Ounsworth <Mike.Ounsworth@entrustdatacard.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, Michael Richardson <mcr+ietf@sandelman.ca>, "secdispatch@ietf.org" <secdispatch@ietf.org>
Thread-Topic: [EXTERNAL]Re: [Secdispatch] Problem statement for post-quantum multi-algorithm PKI
Thread-Index: AQHVbNthOdoofKwsjk2c8e3+BFoTgKcvQ3sAgAEvQQCAABdVAP//x0DA
Date: Tue, 17 Sep 2019 20:30:51 +0000
Message-ID: <3a26dc442a3b4dce801cb9dfe909386f@PMSPEX05.corporate.datacard.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> <CAN40gSseUfKyJo8SZzLVQGnoSOKPHQJysx7zz_w=n_SGuckfSw@mail.gmail.com> <45237418-7C96-4823-A7C6-39E92586756E@akamai.com> <CAN40gSuzC2hQsFmB2SFd8CnicLWfyiqgePf0pTYsHXZ=s5FV-g@mail.gmail.com> <E55FFB18-ABB5-442A-B41A-CC7678076C26@akamai.com> <CAN40gSvy4kcR1RwdJxoD+HSWc6eskTGHkrQ1=7iro2cieB-_rQ@mail.gmail.com> <6013.1568740878@localhost> <33fd71b9-cb6f-28c0-8182-7f2b71d5db24@cs.tcd.ie>
In-Reply-To: <33fd71b9-cb6f-28c0-8182-7f2b71d5db24@cs.tcd.ie>
Accept-Language: en-CA, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.1.43.131]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdispatch/X14CQOJKJ88DX3kqLa2wUupgFX8>
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 20:30:56 -0000

Hi Stephen,

I think we're making progress towards common understanding! Hurray!

> Seems like existing x.509 libraries do not need to change, and nor 
> should they. We'd be breaking them horribly if we tried to 
> retrofit multiple algs/keys/sigs into x.509. Instead handle new 
> things outside x.509, so as to avoid introducing significant 
> vulnerabilities into what's now a more or less working system.


It sounds like what you're proposing will end up lining up with the still-yet-to-be-defined solution of "just use multiple cert chains", which requires no change to X.509 itself, and which I described in my Problem Statement draft as

2.2.1.  Multiple Certificate Chains

   If you want multiple public keys on multiple cryptographic
   algorithms, then get multiple certificates from multiple PKIs.  The
   protocol has control of negotiating which algorithms get used, how to
   encapsulate the large PQ data, etc.  In many ways, this is the most
   obvious solution.



Also, what I present as "2.1.  "Composite" concatenated keys and signatures" does not retrofit X.509 at all, except for defining new algorithmIDs, which is unavoidable.

And what I present as "2.2.2.  "Hybrid" v3 extensions" (and has an almost accepted ITU-T spec) only retrofits X.509 insofar as it adds a new v3 extension, which since X.509v3 was made to be extended, hardly seems like a retrofit. Also, by design, certs with these extensions can happily be parsed by non-upgraded X.509 libraries.


TL;DR: "We'd be breaking them horribly" seems like an unfair characterization of the proposals before us.

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

-----Original Message-----
From: Secdispatch <secdispatch-bounces@ietf.org> On Behalf Of Stephen Farrell
Sent: Tuesday, September 17, 2019 1:45 PM
To: Michael Richardson <mcr+ietf@sandelman.ca>ca>; secdispatch@ietf.org
Subject: [EXTERNAL]Re: [Secdispatch] Problem statement for post-quantum multi-algorithm PKI


Hiya,

Just to be clear that is not my position.

On 17/09/2019 18:21, Michael Richardson wrote:
> 
> Encode ASN.1 in CBOR (CBOR encoding rules for ASN.1) if we think the 
> ASN.1 is worth keeping, switch to CDDL if not.  We probably need to keep the semantics.

Seems like the semantics has to change with stateful signature schemes with wall-clock time expiry is no longer appropriate for public keys.

Seems like the semantics has to change if N of M signatures must verify compared to 1 of 1, esp if some alg may become "dubious" for say a number of years before we find out that a break exists for that alg.
(The dubious alg may be due to a QC attack on a classic alg, or, and maybe more likely, a classical attack on a new nad supposedly QC resistant alg.)

Seems like existing x.509 libraries do not need to change, and nor should they. We'd be breaking them horribly if we tried to retrofit multiple algs/keys/sigs into x.509. Instead handle new things outside x.509, so as to avoid introducing significant vulnerabilities into what's now a more or less working system.

And I dispute the urgency for authentication. Long-lived devices that cannot be updated in 20 years will be hugely vulnerable to things that are nothing to do with quantum computers. It isn't worthwhile trying to "fix" that now when it's too early to know what might or might not be a good plan for dealing with authentication in a world that has a working quantum computer - better to ensure those devices can be updated and then do the best one can as needs arise. The probability of a recall due to a vuln in a non-updatable device seems far higher than anything else here.

Instead of all those bad plans - we should start to discuss what may be needed for authentication in 20+ years time, part of which would be quantum resistant algs. Another part may be an equivalent to CT which turned out to be needed due to certificate mis-issuance, so the discussion I'd be interested in wouldn't only be about quantum computers. (But would overlap with that.)

Cheers,
S.