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

[Hubert Kario <[e-mail]>]

On Saturday, 29 April 2017 15:28:43 CEST [e-mail] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This draft is a work item of the CURves, Deprecating and a
> Little more Encryption of the IETF.
> 
>         Title           : GSS-API Key Exchange with SHA2
>         Authors         : Simo Sorce
>                           Hubert Kario
> 	Filename        : draft-ietf-curdle-gss-keyex-sha2-00.txt
> 	Pages           : 16
> 	Date            : 2017-04-28
> 
> Abstract:
>    This document specifies additions and amendments to SSH GSS-API
>    Methods [RFC4462].  It defines a new key exchange method that uses
>    SHA-2 for integrity and deprecates weak DH groups.  The purpose of
>    this specification is to modernize the cryptographic primitives used
>    by GSS Key Exchanges.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-curdle-gss-keyex-sha2/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-curdle-gss-keyex-sha2-00
> https://datatracker.ietf.org/doc/html/draft-ietf-curdle-gss-keyex-sha2-00

One of the nice properties of Kerberos, because it uses only symmetric 
cryptography, is that it is secure against quantum computer attacks.

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
2). should we prioritise ease of upgrade to SHA-2, ECDH, bigger primes (and 
forget about QC-resistance - that's the current draft), or
3). should we multiply the kex options further and provide QC-resistant 
variants of all the GSSAPI kex algorithms?


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