Re: [Qemu-block] [PATCH v5] crypto: Implement TLS Pre-Shared Keys (PSK).

[Daniel P . Berrangé]

On Fri, Jun 29, 2018 at 06:40:29PM +0100, Richard W.M. Jones wrote:
> On Fri, Jun 29, 2018 at 06:03:43PM +0100, Daniel P. Berrangé wrote:
> > On Thu, Jun 28, 2018 at 07:46:24PM +0100, Richard W.M. Jones wrote:
> > > diff --git a/crypto/tlssession.c b/crypto/tlssession.c
> > > index 96a02deb69..50df64e0a9 100644
> > > --- a/crypto/tlssession.c
> > > +++ b/crypto/tlssession.c
> > > @@ -21,6 +21,7 @@
> > >  #include "qemu/osdep.h"
> > >  #include "crypto/tlssession.h"
> > >  #include "crypto/tlscredsanon.h"
> > > +#include "crypto/tlscredspsk.h"
> > >  #include "crypto/tlscredsx509.h"
> > >  #include "qapi/error.h"
> > >  #include "qemu/acl.h"
> > > @@ -88,6 +89,8 @@ qcrypto_tls_session_pull(void *opaque, void *buf, 
> > > size_t len)
> > >      return session->readFunc(buf, len, session->opaque);
> > >  }
> > >  
> > > +#define TLS_PRIORITY_ADDITIONAL_ANON "+ANON-DH"
> > > +#define TLS_PRIORITY_ADDITIONAL_PSK  "+ECDHE-PSK:+DHE-PSK:+PSK"
> > 
> > Unfortunately in testing this I learn ECDHE-PSK is only supported when
> > using GNUTLS >= 3.0, so can you make this conditional based on 
> > GNUTLS_VERSION_MAJOR  >= 3
> 
> GnuTLS 3.0 was released in 2011, and the last 2.x version seems to be
> from 2009.  Do we need to support such old versions?

With our recently introduced platform support guidelines, I think we can
likely drop 2.x. The issue is timing though - feature freeze deadline is
tomorrow, and I really want to get your PSK patch included without more
delay. So just making it conditional is the simplest way to achieve it.

> I looked at the configure script.  It seems as if we will try to use
> any version of GnuTLS, even ancient ones (although other sub-features
> require later versions of GnuTLS).  But if I'm understanding it
> correctly, by forcing both GnuTLS >= 3.0.0 and Nettle we could
> eliminate all the conditionals there, except for one Nettle test.

We still need support for gcrypt unfortunately, since nettle is not covered
by FIPS certs. So while we will be able to delete a bunch of compat code,
we'll need to refactor much of the configure test logic. I don't want to
risk doing that the day before feature freeze.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|