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

[Hubert Kario <[e-mail]>]

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:
> > On Saturday, 29 April 2017 15:28:43 CEST [e-mail] 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.]

Yes, the change is necessary, but not sufficient, for QC resistance.

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

GSS_Pseudo_random() could be a neat solution. But I have some reservations, 
see below.

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

What I was thinking, is that -sha1 ones are becoming insecure either way. So 
lets make sure that the only ones that remain have the same properties (and 
they are a superset of the -sha1 ones).
 
> > 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.
 
> > 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...
-- 
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