[Secdispatch] Quantum Resiliant

Phillip Hallam-Baker <phill@hallambaker.com> Mon, 23 September 2019 16:03 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 02F10120137 for <secdispatch@ietfa.amsl.com>; Mon, 23 Sep 2019 09:03:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.916
X-Spam-Level:
X-Spam-Status: No, score=-1.916 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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 dHxvNHPkbLob for <secdispatch@ietfa.amsl.com>; Mon, 23 Sep 2019 09:03:03 -0700 (PDT)
Received: from mail-ot1-f50.google.com (mail-ot1-f50.google.com [209.85.210.50]) (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 A453212013A for <secdispatch@ietf.org>; Mon, 23 Sep 2019 09:03:03 -0700 (PDT)
Received: by mail-ot1-f50.google.com with SMTP id c10so12563536otd.9 for <secdispatch@ietf.org>; Mon, 23 Sep 2019 09:03:03 -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:from:date:message-id:subject:to; bh=KcGH+wF/439oLXsiON31LVVZVfx3Ebaskg9aVCeo+GU=; b=QQ++CJzN2aYt8hf/s4YKEJKvozFjWOqXK+NiA8FEWMijeA6jCpIe/RNMEpsLqjFYKo jbJYEaayRBv3+iS9SBzXQD+zp9hQKf7nliOEjaZHGWo0GiuvHA2BnTb8Ht9HE30YAUX7 4B3Fhl6IMuCTqLEcqyIREAkHVxHQF96EKXCJ3NSk6Lf24+t6CNNQiHIEiNnXLGldYrKj scEE1u0qE8cHj6ZhwjWsVBsgpKIl11Ja37oGex54alpNyUVNyAInOpdYaij7V6TEp7dd Q7/6utriNMMUV2+wh87Gqo2Pi6iJNUGa1I/uQGxL31H4K+ooXs04ogsAtUH28gsQrU1c QeHQ==
X-Gm-Message-State: APjAAAWFMc/ZmFVaeyjklngoZVORPKJpwnEKAS5NKN/hSygwMFNkwKeE D41PlQxHSLrdFwjeFOZ4C/Dgk104HUQhJSQ7Jo/13k2/
X-Google-Smtp-Source: APXvYqzX5jK7CeGWILJ/K9pofV5j9GP6Xxi4bAogjtS8317DIpN+5kFo4sf3WpwltqVBFnfh1YAy1ImcEtCySxd4M6g=
X-Received: by 2002:a05:6830:14c5:: with SMTP id t5mr501938otq.112.1569254582229; Mon, 23 Sep 2019 09:03:02 -0700 (PDT)
MIME-Version: 1.0
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Mon, 23 Sep 2019 12:02:51 -0400
Message-ID: <CAMm+LwgL4szAN0Su441_XdCRGEY-O5peAAW=quB+C_LfNzt7Gg@mail.gmail.com>
To: IETF SecDispatch <secdispatch@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000ef9f8e05933a8d4d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdispatch/CbUaKwPwu1MG4OeqnEWgEXqHLDI>
Subject: [Secdispatch] Quantum Resiliant
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, 23 Sep 2019 16:03:06 -0000

We have a lot of interest in building PKI architectures that are secure
against quantum cryptanalysis. I see three different levels at which this
can be achieved.

Class 1: The system uses a quantum cryptanalysis secure public key
algorithm that provides all the same capabilities as traditional public key
algorithms.

Class 2: The system uses symmetric key based security with a significant
impact on capabilities as it is only possible to establish trust after
first establishing a shared secret. (e.g. Kerberos, Lamport signatures).

Class 3: The system is a traditional PKI modified to mitigate the
consequences of quantum cryptanalysis without modifications that
significantly affect traditional use. (e.g. use of hash chain notary to
protect signatures, use of shared secret KDF mixins).

As a field, we have to explore all three. And it might well be that the
short term interest is in the last. For protocol designers like myself, the
class 1 is not an interesting problem and won't be until we know how
quantum resistant public key algorithms differ from traditional PKI. We are
assuming that the problem is solved without the need for any protocol
re-engineering or with minor tweaks.

Class 2 presents some very interesting challenges as Lamport signatures are
statefull so we need a way to manage the state. Another approach that could
be interesting is to attempt a federated version of Kerberos. CAs become
Kerberos ticket granters.

So lets say I am trying to contact Amazon.com, I do this using a ticket I
have acquired from TicketCo which has a shared ticket with both of us.
Easy! OK, but how do I establish that shared ticket? Well I am going to
have to meet each CA in person or rely on some sort of federated
introduction infrastructure and we end up with multiple inputs to KDFs or
Shamir secret sharing and the like.

Class 3 looks like it is the least interesting but it is the new
'constrained device' case for PKI and that makes it a fascinating challenge
as you have to provide as much quantum security in the context of
traditional PKI approaches.