Re: [Curdle] Quantum Resistant SSH connections

Hubert Kario <hkario@redhat.com> Thu, 01 October 2020 16:25 UTC

Return-Path: <hkario@redhat.com>
X-Original-To: curdle@ietfa.amsl.com
Delivered-To: curdle@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E54F3A10EC for <curdle@ietfa.amsl.com>; Thu, 1 Oct 2020 09:25:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.297
X-Spam-Level:
X-Spam-Status: No, score=-3.297 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhat.com
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 IUTh3xaWtYho for <curdle@ietfa.amsl.com>; Thu, 1 Oct 2020 09:25:55 -0700 (PDT)
Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 286CF3A10E6 for <curdle@ietf.org>; Thu, 1 Oct 2020 09:25:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1601569554; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=k6u8K2k9r7X1tVOZ76o0AJPIyoc8SXRt5Wtw5ddI2Hs=; b=G1Q7D1tq0N5fu6hBCQGkIaNvUUA1WzmQU0MScq+Pa6ngchm+U3wXwmtM6lWA9itU4x4IzO jpDqHNt1bPl+2Ry6H6q1zs0CYi0nv28AWZsWlmnasaUF1wyCVaSToW3qjoPnzNgv0crs26 LTaUGPawg3fjxBMB/XLKqnqLSrubgj4=
Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-183-6htIphMlO1-b4C78PMEqFA-1; Thu, 01 Oct 2020 12:25:46 -0400
X-MC-Unique: 6htIphMlO1-b4C78PMEqFA-1
Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id C9071802B51; Thu, 1 Oct 2020 16:25:45 +0000 (UTC)
Received: from localhost (unknown [10.40.208.76]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 0EC2F19C78; Thu, 1 Oct 2020 16:25:44 +0000 (UTC)
From: Hubert Kario <hkario@redhat.com>
To: "Mark D. Baushke" <mdb@juniper.net>
Cc: curdle@ietf.org
Date: Thu, 01 Oct 2020 18:25:42 +0200
MIME-Version: 1.0
Message-ID: <d466dc09-c5a2-4fae-ba7f-1f2bd16daf77@redhat.com>
In-Reply-To: <8817.1601568417@eng-mail01.juniper.net>
References: <0132f221-44c7-40f0-a4f8-134379f4c6e5@redhat.com> <8817.1601568417@eng-mail01.juniper.net>
Organization: Red Hat
User-Agent: Trojita/0.7-git; Qt/5.13.2; xcb; Linux; Fedora release 31 (Thirty One)
X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23
Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=hkario@redhat.com
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/curdle/c0c6Q1ktmkET0-itXlO09U0jQBM>
Subject: Re: [Curdle] Quantum Resistant SSH connections
X-BeenThere: curdle@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "List for discussion of potential new security area wg." <curdle.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/curdle>, <mailto:curdle-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/curdle/>
List-Post: <mailto:curdle@ietf.org>
List-Help: <mailto:curdle-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/curdle>, <mailto:curdle-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Oct 2020 16:25:58 -0000

On Thursday, 1 October 2020 18:06:57 CEST, Mark D. Baushke wrote:
> Hi Hubert,
>
> Hubert Kario <hkario@redhat.com> writes:
>
>> Hi everybody,
>> 
>> As it's fairly easy, and common, to configure Kerberos infrastructure
>> to be resistant against quantum computers, I'd like to submit a new
>> key exchange for SSH that leverages that quantum resistance to make
>> quantum resistant SSH connections. ...
>
> Thank you for the pointers.
>
> Related to Quantum-Resistant and Quantum-Safe algorithms, you may find
> these pointers useful as well:
>
> There is a github project under an MIT licesnse:
>
>     https://github.com/open-quantum-safe/liboqs
>
> which provides for various Quantum-Safe cryptographic algorithms.
>
> There is also a paper published last year:
>
>     Prototyping post-quantum and hybrid key exchange and authentication in
>     TLS and SSH
>     by Eric Crockett and Christian Paquin and Douglas Stebila
>     URL: https://eprint.iacr.org/2019/858
>
> which may be of interest as a hybrid mechanism may be more acceptable as
> a transition to PQ than a direct move for some implementers.
>
> 	Be safe, stay healthy,
> 	-- Mark

Yes, I'm aware of those projects and this research.

The reason why I went with stright-up kerberos is becasue:
1. There is no single quantum safe algorithm widely agreed as the best
2. It may be good few years before we will get one
3. It may require few more years still before those algorithms become 
acceptable
   to national or international standard bodies (FIPS, PCI-DSS, Common
   Criteria, etc.)
4. Backporting completely new cryptographic algorithms to existing 
deployments
   is usually hard, if not impossible. Not to mention it may take years 
before
   we have something that's secure against side-channel attacks in 
practice.

This I-D proposes a mechanism that doesn't use any new cryptography and
requires minimal changes to a SSH implementation (and uses just two new 
methods
from GSSAPI). Which should make it very easy to add in new deployments and
isn't very hard to backport to old deployments.

In other words, I don't consider it a replacement for proper quantum-safe
kex, but a stepping stone that will tide us over until quantum-safe 
algorithms
are widely deployed.
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic