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

"Martin Thomson" <mt@lowentropy.net> Wed, 18 September 2019 03:19 UTC

Return-Path: <mt@lowentropy.net>
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 E6BF1120096 for <secdispatch@ietfa.amsl.com>; Tue, 17 Sep 2019 20:19:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=jOTLLCpc; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=JS8Ha6Bw
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 y_UWnt-Ai6wC for <secdispatch@ietfa.amsl.com>; Tue, 17 Sep 2019 20:19:14 -0700 (PDT)
Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 721D7120073 for <secdispatch@ietf.org>; Tue, 17 Sep 2019 20:19:14 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id A1D8F56F for <secdispatch@ietf.org>; Tue, 17 Sep 2019 23:19:13 -0400 (EDT)
Received: from imap7 ([10.202.2.57]) by compute1.internal (MEProxy); Tue, 17 Sep 2019 23:19:13 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type:content-transfer-encoding; s=fm3; bh=Bs+H2 p7EB+/zk2ur5mx/Le1UOEEuWDHYBIOo0If+WWw=; b=jOTLLCpc7VGlxVj1MeeV1 Jf2cZ8D1YbwLeQdxroJopS1oA9ErM38ixxcN6I2qg8pv8YrEgut7XMtREcVL/ZDo /fgRK6vMff9alVbiBT/bEoGIXkVt8r2CDgCikyZ9M9pHrnH2CeUHx1H0/VLYOSQQ 2/2vhgsZoQ+13gbVpRHHQKWEUZvIa8CoaDCYNc4ssf+cIbOqwwdRR7zqw/oR/EjV pNnzbj+pZ8WLoEEeOFcJfUQgsLgIu2iT8Ugo7VXyRk6h4Id8kpO3jusHe7CNUde/ Jby06H41yJLsjMys17VU7jrVmQmz8I12NMqKytc9JOvsBfhiMOGgPYKAFckU8xL7 Q==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=Bs+H2p7EB+/zk2ur5mx/Le1UOEEuWDHYBIOo0If+W Ww=; b=JS8Ha6Bw8U0wXKbEJzcuVI4h++VNKImyG6w+anE1Fb3qe8XCkz95sOU9t muY/7u4yqM4ssey3z0QABNV+UPeTpnt0K7UDMrlr1vlPaPwN60/1g7KMcN/bMwUz 9z17jIYAZzrs1THk1U4K9OuGA6bf/4hjXeyQguuPBnQZNp6oEHllLg5MiszhNieZ d9AUpp8YR9SlopMDBSdUEs91gWQLyolLgYlQ+Huk/hqMS/EZo/Uwbe9ZPkG3+pRD +KDO2guia8ecvWrsfKroxN+gPIa2seeVNrvo2f9l9vfYk6Q5oRhWuTctAHFOscOP vUdchQZbN94Z8mMyWh1df4jsEdsmg==
X-ME-Sender: <xms:MKKBXWnXk4Fq5tUgI_ovXTk1awQwFZGB3GR1oeQdZFfpI5drYtMqMA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudejgdejtdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgfgsehtqh ertderreejnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucffohhmrghinhepihgvthhfrdhorhhgpdhophgvnh hquhgrnhhtuhhmshgrfhgvrdhorhhgnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmthes lhhofigvnhhtrhhophihrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd
X-ME-Proxy: <xmx:MKKBXbobZ3uGsP0v2Yljp200FUd8Uv-OYfnPD23uJNcNWgzV9TPEuQ> <xmx:MKKBXfEfibZn20PuNLAdliGEPFJmaYK8ysfoJvH5NQBj2LwqIXlNPA> <xmx:MKKBXXxt16kbEBKD784ZG3vpMCJfqROFv5E8sUn1HA5oB3-KhPXZsQ> <xmx:MaKBXXjs96xyYrJNUzwxdNyWHwTEo234bcnFKwlZs0El4ORYy5KsjA>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id B4C651C0001; Tue, 17 Sep 2019 23:19:12 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.7-238-g170a812-fmstable-20190913v1
Mime-Version: 1.0
Message-Id: <61f35d44-63bf-4b17-8c65-6dcc2bdeeff6@www.fastmail.com>
In-Reply-To: <CAL02cgSO7pOSwyB5xXxK8KhkQOpMYY6uG+Q5a0hCqRY+0nv75A@mail.gmail.com>
References: <CAFBh+ST+VxPoR6gZD3ssZxhORKChE0tz_QpZPn-hoAwjiuk80w@mail.gmail.com> <CAL02cgSO7pOSwyB5xXxK8KhkQOpMYY6uG+Q5a0hCqRY+0nv75A@mail.gmail.com>
Date: Wed, 18 Sep 2019 13:18:53 +1000
From: "Martin Thomson" <mt@lowentropy.net>
To: secdispatch@ietf.org
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdispatch/PVvekwNWQIou1cPNhA7xrW3ia6o>
Subject: Re: [Secdispatch] =?utf-8?q?Problem_statement_for_post-quantum_multi?= =?utf-8?q?-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 03:19:17 -0000

I'll add that while it is clear that there are some hard research-y pieces to this (like finding decent primitives), much of the work we might decide to do is straight-up engineering.  The work that Douglass has done for TLS is a great example of that.  We might not have reached conclusions on some of the finer points, but thanks to the work already done, we're down to making what are fundamentally just engineering decisions.  Here I say "just" advisedly, because have well-established processes for resolving any disagreements of that nature.

On Wed, Sep 18, 2019, at 02:14, Richard Barnes wrote:
> +1 on the last point here -- we should get started on PQ stuff now 
> (including transition strategies), and should not waste time on 
> unrelated things, like replacing X.509.
> 
> --Richard
> 
> On Tue, Sep 17, 2019 at 10:10 AM Douglas Stebila <dstebila@gmail.com> wrote:
> > I'm a little late to the discussion, and new to the secdispatch mailing list, but hopefully not too late. I think this is an important problem to address, and sooner rather than later. NIST is still a few years away from having an outcome, but we can start laying the framework for how we'll use the resulting algorithms. Although not everyone is convinced by "hybrid" / "multi-algorithm", there seems to be sufficient interest for it (e.g., the panel discussion at the NIST PQC standardization conference last month), that it's worth investing the time to investigate further. I'm involved in a draft about hybrid key exchange in TLS for which there is no clear path, but lots of opinions and discussion worth having. I'm also involved in an open source project (openquantumsafe.org) where we are already wanting to prototype hybrid authentication in protocols relying on X.509, and we'd be happy to coordinate with others wanting to do so. It would be really unfortunate if deployment of quantum-resistant algorithms was delayed even further because we spend 3-5 years struggling with network protocols and standards *after* NIST picks some algorithms, when we could have started that aspect earlier.
> > 
> > Douglas
> > 
> > 
> > On Wed, 11 September 2019, Mike Ounsworth <Mike.Ounsworth@entrustdatacard.com> wrote:
> > 
> >> Hi SecDispatch,
> >> This got bounced here from LAMPS because the scope is potentially more than a "limited" pkix change, and because this needs multi-WG visibility to decide on a category of solution.
> >> 
> >> 
> >> Background / history
> >> --------------------
> >> The Post-Quantum community (for example, surrounding the NIST PQC competition), is pushing for "hybridized" crypto that combines RSA/ECC with new primitives in order to hedge our bets against both quantum adversaries, and also algorithmic / mathematical breaks of the new primitives.
> >> 
> >> A year and a half ago, a draft was put to LAMPS for putting PQ public key and signatures into X.509v3 extensions. This draft has been allowed to expire, but is being pursued at the ITU.
> >> https://datatracker.ietf.org/doc/draft-truskovsky-lamps-pq-hybrid-x509/
> >> 
> >> Earlier this year, a new draft was put to LAMPS for defining "composite" public key and signature algorithms that, essentially, concatenate multiple crypto algorithms into a single key or signature octet string. This draft stalled in LAMPS over whether it is the correct overall approach.
> >> https://datatracker.ietf.org/doc/draft-ounsworth-pq-composite-sigs/
> >> 
> >> Now I'm taking a step back and submitting a draft that acts as a semi-formal problem statement, and an overview of the three main categories of solutions.
> >> https://datatracker.ietf.org/doc/draft-pq-pkix-problem-statement/
> >> 
> >> 
> >> 
> >> My Opinion
> >> ----------
> >> Personally, I'm fairly agnostic to the chosen solution, but feel that we need some kind of standard(s) around the post-quantum transition for certificates and PKI. Personally, I feel that Composite is mature enough as an idea to standardize as a tool in our toolbox for contexts where it makes sense, even if a different mechanism is preferred for TLS and IPSEC/IKE.
> >> 
> >> 
> >> 
> >> Requested action from SECDISPATCH
> >> ---------------------------------
> >> 1. Feedback on the problem statement draft. https://datatracker.ietf.org/doc/draft-pq-pkix-problem-statement/
> >> 2. Discussion of how to progress this.
> >> 
> >> 
> >> 
> >> PS I'm a new IETF'er, please be gentle :P
> >> Thanks,
> >> - - -
> >> Mike Ounsworth | Software Security Architect
> >> Entrust Datacard
> >  _______________________________________________
> >  Secdispatch mailing list
> > Secdispatch@ietf.org
> > https://www.ietf.org/mailman/listinfo/secdispatch
> _______________________________________________
> Secdispatch mailing list
> Secdispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/secdispatch
>