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

Phillip Hallam-Baker <phill@hallambaker.com> Wed, 18 September 2019 23:34 UTC

Return-Path: <hallam@gmail.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 6CE251200B5 for <secdispatch@ietfa.amsl.com>; Wed, 18 Sep 2019 16:34:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.203
X-Spam-Level:
X-Spam-Status: No, score=0.203 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, LOTS_OF_MONEY=0.001, MALFORMED_FREEMAIL=1.103, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.026, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 foQyRfu8v7Z0 for <secdispatch@ietfa.amsl.com>; Wed, 18 Sep 2019 16:34:00 -0700 (PDT)
Received: from mail-oi1-f182.google.com (mail-oi1-f182.google.com [209.85.167.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 528061200B3 for <secdispatch@ietf.org>; Wed, 18 Sep 2019 16:34:00 -0700 (PDT)
Received: by mail-oi1-f182.google.com with SMTP id i16so1161326oie.4 for <secdispatch@ietf.org>; Wed, 18 Sep 2019 16:34:00 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:cc; bh=/NYrCULYcdORqOIzwpqsBCMJFc5ccU1PjPm8OxDiCfA=; b=dq7h0hgPpo7lKl+PsWK+RWIB181r6h5ylCWNav9J+C3fH5ZGfdID85mp1U2u5H3Mmu xS7A/8IKhUH1Es1OCz54mDaiV8zAPqA8t5ofyquvyKtb4gmSKVm2x5xhkMMB/bTD/SB6 jXpLgkVc5z2jX+KKmo5BzihnVSBwKygks6k79bK1+4d4cqaYIb3fA5R/ul5VQfhkm3TT CX861VNeA78fNVr3CuU6oejb5dOwfDri+FQgV/r/DVLOz25DljQKJa4cQ/rJpe8rWpxq M0Kr84BN4NAHuyaRAYPgxFYOmD3SZYBKmBX/D49qPaYqmOGwX7U84fqMEP9vLRh3ocJe LgwA==
X-Gm-Message-State: APjAAAW0si744FxavwwWncQigBp3cD5dxBsIaf3XGcvIKEAEw0vtSTXK vkDWmq/sc5kHX5ewCLzz5/ZlUm0LXXDYj/9sbEA0nA==
X-Google-Smtp-Source: APXvYqy6zqZD+2D25leV2M4qDaJfuo5ihGhdbFNE71kBT6p9mCop1WbbrJuY0oUtonvMn2n8TbS6oOHwCZP8D9tguvI=
X-Received: by 2002:aca:c458:: with SMTP id u85mr345943oif.100.1568849639249; Wed, 18 Sep 2019 16:33:59 -0700 (PDT)
MIME-Version: 1.0
References: <2e753a7983bf40b490b4fcbb75550da3@PMSPEX05.corporate.datacard.com>
In-Reply-To: <2e753a7983bf40b490b4fcbb75550da3@PMSPEX05.corporate.datacard.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Wed, 18 Sep 2019 19:33:46 -0400
Message-ID: <CAMm+Lwg2xr7JbrLB+WMjCRFgS570CQkbSJk_VNy+VHzNUKO4+A@mail.gmail.com>
Cc: "secdispatch@ietf.org" <secdispatch@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000741ceb0592dc4537"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdispatch/lfC5zDkSQq90UAwGTRRLPYqPiDs>
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: Wed, 18 Sep 2019 23:34:02 -0000

OK, so yes, I have to finish the Mesh before I start on anything new. But I
do think I can solve a few of the use cases raised with the technology I
developed for the Mesh and in particular the question of how to manage an
embedded device.

Recall that a few years ago, I proposed a scheme 'omnibroker' that was a
delegated trust service. If device X wants to connect to party Y via
protocol Z, it asks the omnibroker and back come all the crypto parameters
required. In the TLS case it would get back an IP address, port, cert path
and OCSP token.

The omnibroker could in principle perform the actual key exchange and pass
back a Kerberos ticket to the client in response to the request. So what we
have here is a point of leverage. Alice deploys her $20,000 worth of IoT
devices into the walls of her new mansion. They each connect to her
personal Mesh Service which provides them with the necessary credential to
communicate with her personal Omnibroker. That credential could be a
Kerberos like ticket meaning that the device to Omnibroker connection is
QCR.

If it becomes known that a Quantum Computer of appreciable size has been
built, all Alice needs to do is to drop in a new Omnibroker service that
can support the new modes of interaction, new Quantum Resistant algorithms
and so on. So she has to make a $100 (or less) upgrade instead of a $20,000
one.

This is not going to solve every problem of course. It is not going to
allow a constrained device to be put onto the Internet. But I still
consider that a silly idea. In the age of the $5 PiZero, constrained
devices should have connections that are mediated by decently performant
devices.

Again, this is not a line of research that is currently my top priority. If
someone wants to make it my top priority, there is a protocol for that.

My current priority is to solve the three problems I see as critical for
deploying the last generation of end-to-end crypto: Provisioning every
device with a private key pair, publishing the corresponding public keys in
a useful fashion and protecting data at rest.