Re: [Curdle] Quantum computer resistance? (Re: I-D Action: draft-ietf-curdle-gss-keyex-sha2-00.txt)

Benjamin Kaduk <kaduk@mit.edu> Sun, 21 May 2017 20:13 UTC

Return-Path: <kaduk@mit.edu>
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 743F912944A for <curdle@ietfa.amsl.com>; Sun, 21 May 2017 13:13:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.502
X-Spam-Level:
X-Spam-Status: No, score=-1.502 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 djhXupHL_ohy for <curdle@ietfa.amsl.com>; Sun, 21 May 2017 13:13:57 -0700 (PDT)
Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9168A129443 for <curdle@ietf.org>; Sun, 21 May 2017 13:13:57 -0700 (PDT)
X-AuditID: 12074422-4dfff7000000196e-43-5921f5036adc
Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id EA.D3.06510.305F1295; Sun, 21 May 2017 16:13:56 -0400 (EDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id v4LKDsBS011337; Sun, 21 May 2017 16:13:54 -0400
Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v4LKDo8a021768 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 21 May 2017 16:13:53 -0400
Date: Sun, 21 May 2017 15:13:50 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: Hubert Kario <hkario@redhat.com>
Cc: curdle@ietf.org
Message-ID: <20170521201350.GP39245@kduck.kaduk.org>
References: <149347252355.2923.13177496291079730679@ietfa.amsl.com> <2602201.lV3Rmsh2R0@pintsize.usersys.redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
In-Reply-To: <2602201.lV3Rmsh2R0@pintsize.usersys.redhat.com>
User-Agent: Mutt/1.7.1 (2016-10-04)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkleLIzCtJLcpLzFFi42IRYrdT12X5qhhp0LGIx2LrwlnMFre+HWZ1 YPJYsuQnk8f7fVfZApiiuGxSUnMyy1KL9O0SuDK+bf3GXDBTuOLS7WlsDYyH+bsYOTkkBEwk vt3+xdrFyMUhJLCYSWLl1tfsEM5GRomFs2+yQThXmSR+zFrKBNLCIqAqsWrvG3YQm01ARaKh +zIziC0CZJ891QlmMwsIS/z73ApUz8EhLJAnsfBGOEiYF2jbv1+vWUBsIYEyiXlT3zNCxAUl Ts58wgLRqiVx499LsFZmAWmJ5f84IMLaEssWvmYGCXMK2EpsvpcIEhYVUJb4e/geywRGwVlI Bs1CMmgWwqBZSAYtYGRZxSibklulm5uYmVOcmqxbnJyYl5dapGuql5tZopeaUrqJERzSLko7 GCf+8zrEKMDBqMTD+2KuQqQQa2JZcWXuIUZJDiYlUd5XM4FCfEn5KZUZicUZ8UWlOanFhxgl OJiVRHi3XFWMFOJNSaysSi3Kh0lJc7AoifOKazRGCAmkJ5akZqemFqQWwWRlODiUJHg7PgM1 ChalpqdWpGXmlCCkmTg4QYbzAA1vAKnhLS5IzC3OTIfIn2JUlBLnPQiSEABJZJTmwfWCUo5E 9v6aV4ziQK8I87p+AariAaYruO5XQIOZgAZbP5MHGVySiJCSamBkfrJzyoTt1x8L2riyTV7a E8e8jmW1p8c7dss5nHvDPRJC+PpPfn+yqmeqYIeAdmDOAZ73sgriHy7/im6226vy5cJ7C4fJ 9kLe9xZcLtx07JEXv/2LqHKXHV+mObUU55x4H83/vP2C3CH267zfJnT9X8NSnC20p0tszVZp W/V2vb+X9gh8s+1QYinOSDTUYi4qTgQATkWGnhQDAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/curdle/cebkefEcLkkBEt5HFLIwV0kgGMk>
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: Sun, 21 May 2017 20:13:59 -0000

On Tue, May 02, 2017 at 03:54:21PM +0200, Hubert Kario wrote:
> On Saturday, 29 April 2017 15:28:43 CEST internet-drafts@ietf.org wrote:
> 
> One of the nice properties of Kerberos, because it uses only symmetric 
> cryptography, is that it is secure against quantum computer attacks.

[obligatory note that the GSS-API is generic, i.e., there are
non-Kerberos GSS mechanisms, some of which are even used with ssh
today.  AIUI, the GSI mech does not use symmetric crypto and could
not reasonably become quantum-computer-resistant.]

> Unfortunately, neither the previous gss-api kex scheme, nor the one we 
> proposed here (as it is essentially the same), maintain that property.
> This is because the input to the HASH function, with one exception, are 
> transferred in clear. That only secret input is the value calculated using 
> algorithm vulnerable to quantum computers - FF or EC version of Diffie-Hellman
> 
> Thus my question are, 
> 1). should we change the input provided to HASH to provide quantum computer 
> resistance, or

We should probably provide a scheme that has some additional input(s) to
HASH, perhaps with a GSS_Pseudo_random() (RFC 4401) or a
GSS_Wrap()'d random value.

> 2). should we prioritise ease of upgrade to SHA-2, ECDH, bigger primes (and 
> forget about QC-resistance - that's the current draft), or

But, I'm not convinced that we want to make "gss-<group>-<hash>"
have different global semantics based on the particular group+hash
combination; 

> 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.

> 
> 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).

-Ben