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

[Hubert Kario <[e-mail]>]

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