Re: [Curdle] Quantum computer resistance? (Re: I-D Action: draft-ietf-curdle-gss-keyex-sha2-00.txt)
Hubert Kario <hkario@redhat.com> Tue, 23 May 2017 10:20 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 F37BA129466 for <curdle@ietfa.amsl.com>; Tue, 23 May 2017 03:20:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.923
X-Spam-Level:
X-Spam-Status: No, score=-6.923 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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 Z9PVQ0WlefCJ for <curdle@ietfa.amsl.com>; Tue, 23 May 2017 03:20:17 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0632C124C27 for <curdle@ietf.org>; Tue, 23 May 2017 03:20:17 -0700 (PDT)
Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 9367B8047D; Tue, 23 May 2017 10:20:16 +0000 (UTC)
DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 9367B8047D
Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=hkario@redhat.com
DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 9367B8047D
Received: from pintsize.usersys.redhat.com (dhcp-0-115.brq.redhat.com [10.34.0.115]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 373EC5C541; Tue, 23 May 2017 10:20:16 +0000 (UTC)
From: Hubert Kario <hkario@redhat.com>
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: curdle@ietf.org
Date: Tue, 23 May 2017 12:20:09 +0200
Message-ID: <8089232.lOomSp7LcR@pintsize.usersys.redhat.com>
In-Reply-To: <20170523020830.GU39245@kduck.kaduk.org>
References: <149347252355.2923.13177496291079730679@ietfa.amsl.com> <1674834.KTPl0iozjd@pintsize.usersys.redhat.com> <20170523020830.GU39245@kduck.kaduk.org>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart1714443.sBf9JYRMPM"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Tue, 23 May 2017 10:20:16 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/curdle/u5WpNR5V8xYQQORjiQMSm15QojM>
Subject: Re: [Curdle] Quantum computer resistance? (Re: I-D Action: draft-ietf-curdle-gss-keyex-sha2-00.txt)
X-BeenThere: curdle@ietf.org
X-Mailman-Version: 2.1.22
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: Tue, 23 May 2017 10:20:19 -0000
On Tuesday, 23 May 2017 04:08:30 CEST Benjamin Kaduk wrote: > On Mon, May 22, 2017 at 03:27:47PM +0200, Hubert Kario wrote: > > On Sunday, 21 May 2017 22:13:50 CEST Benjamin Kaduk wrote: > > > On Tue, May 02, 2017 at 03:54:21PM +0200, Hubert Kario wrote: > > > > 3). should we multiply the kex options further and provide > > > > QC-resistant > > > > variants of all the GSSAPI kex algorithms? > > > > > > it seems like it would make more sense to have a separate document > > > that creates a new family of gss-pq-<group>-<hash> keyex schemes, > > > though probably only of the new ones from this document and not the > > > SHA1 ones. > > > > yes, using sha-1 for PQ is quite silly. For gss-pq-* key exchanges I was > > thinking of something that is truly PQ, that is, provides PFS even against > > quantum computers. That means something that uses Ring-LWE or > > supersingular > > isogeny DH, not something that uses FFDH or ECDH. Even if that FFDH or > > ECDH is slightly augmented to provide minimum of QC resistance. > > > > In other words, the intention was to make the hopeless situation > > survivable > > and provide a proper fix only after a clear winner for PQ KEX has been > > established. > > > > Creating 3 documents is probably overdoing it. > > But yes, 3 documents is probably overdoing it, and there is > something of a desire to get a sha1 alternative out quickly so it > can be implemented and those implementations have a chance to > trickle out into deployment. So maybe we will just hold off until > there is a winner for PQ KEX. Ease of upgrade to SHA-2 was the primary reason we decided to propose the simple version of the draft. > > > > As for technical details, I was thinking of adding a step in which the > > > > peers each choose a random value, GSS_Wrap it, send it to peer, > > > > GSS_Unwrap peers value and append their value and the peers decrypted > > > > value to HASH input. > > > > > > That probably suffices; I would have to think a bit harder about > > > where there is any value gained from using such wrapped random > > > values as input to GSS_Pseudo_random(), or whether just passing the > > > HASH inputs as the prf_in input would suffice (which would mean less > > > data going on the wire). > > > > Yes, not requiring changes to the on-the-wire messages is a definite plus. > > OTOH, I'd assume that all GSS-API implementations support GSS_Wrap() and > > GSS_Unwrap(), I don't know what's the support level for > > GSS_Pseudo_random(). Given the notes in RFC 7802, I see there were some > > problems with > > interoperability in Kerberos... > > Yeah, it is not as widely implemented/adopted as the original GSS > APIs. But there is software out there actually using it, commercial > software even, so there has been some progress on that front. The > two big open-source C Kerberos implementations have had it for a few > years (MIT and Heimdal), but I don't have a sense for whether (e.g.) > Java or the various closed-source GSSAPI implementations have picked > it up. At least one Java library claims that it supports it https://github.com/ cconlon/kerberos-java-gssapi and given it's a MIT wrapper, it should have no problems interoperating. I couldn't find anything for the MS implementation... Anyway, the PQ stuff will require new crypto implementations, so we probably should be OK with requiring the GSS_Pseudo_random() to go along with it. -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
- [Curdle] I-D Action: draft-ietf-curdle-gss-keyex-… internet-drafts
- [Curdle] Quantum computer resistance? (Re: I-D Ac… Hubert Kario
- Re: [Curdle] Quantum computer resistance? (Re: I-… Benjamin Kaduk
- Re: [Curdle] Quantum computer resistance? (Re: I-… Hubert Kario
- Re: [Curdle] Quantum computer resistance? (Re: I-… Benjamin Kaduk
- Re: [Curdle] Quantum computer resistance? (Re: I-… Hubert Kario