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

[Benjamin Kaduk <[e-mail]>]

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

Ah, I see the point better now.

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

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

-Ben