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

Michael Richardson <mcr@sandelman.ca> Sat, 14 September 2019 02:53 UTC

Return-Path: <mcr@sandelman.ca>
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 3644A1200E3 for <secdispatch@ietfa.amsl.com>; Fri, 13 Sep 2019 19:53:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 TLybZNjKo6-Y for <secdispatch@ietfa.amsl.com>; Fri, 13 Sep 2019 19:53:01 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEE261200B4 for <secdispatch@ietf.org>; Fri, 13 Sep 2019 19:53:00 -0700 (PDT)
Received: from dooku.sandelman.ca (unknown [142.169.78.188]) by relay.sandelman.ca (Postfix) with ESMTPS id 071481F459; Sat, 14 Sep 2019 02:52:59 +0000 (UTC)
Received: by dooku.sandelman.ca (Postfix, from userid 179) id 2A0D0488B; Sat, 14 Sep 2019 03:53:37 +0100 (WEST)
From: Michael Richardson <mcr@sandelman.ca>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
cc: "secdispatch\@ietf.org" <secdispatch@ietf.org>
In-reply-to: <cf1a301c-47d6-7565-ddc7-69048e3c08f3@cs.tcd.ie>
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>
Comments: In-reply-to Stephen Farrell <stephen.farrell@cs.tcd.ie> message dated "Sat, 14 Sep 2019 03:28:00 +0100."
X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature"
Date: Sat, 14 Sep 2019 04:53:37 +0200
Message-ID: <29967.1568429617@dooku.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdispatch/UxZHfbg_EcnDjeo9COLAaMe6TyM>
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: Sat, 14 Sep 2019 02:53:03 -0000

Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
    > On 14/09/2019 03:19, Michael Richardson wrote:
    >> 
    >> > 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.
    >> 
    >> No, we really don't have plenty of time.  Some suggest that it is
    >> actually already rather *late*
    >> 
    >> Long-lived devices (such as automobiles) are being designed today, for
    >> production in mid-2020s, and many will be on the road until 2040.

    > Count me unconvinced.

    > Either those devices will have s/w update or they're screwed already

If QM mechanisms take a lot more ram or a lot more bandwidth, then
software updates aren't going to help them.
My understanding is that safety critical systems in cars are authenticating
to each other over the internal buses (CAN, etc.) already.

    > even without requiring the putative existence of a quantum
    > computer. And we are discussing authentication here, mostly of origins
    > I guess, and not confidentiality, so post-facto attacks don't count
    > afaics.

    > I'd appreciate if someone could explain the specifics of the pressing
    > issue here that requires us to not wait for e.g., the outcome of the
    > NIST competition.

I'm not saying that we can't wait to finalize things.
I'm saying that we shouldn't wait for it to be finalized to start.

Can we support multiple signatures inside a certificate? I don't think so.
So what can we do?

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [