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

[Eric Blake <eblake@redhat.com>]

On 07/02/2018 02:52 AM, Daniel P. Berrangé wrote:

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

We can still check in the initial PSK implementation in time for soft 
freeze, then fix conditionals during the freeze but prior to the release 
as bug fixes, if that makes life easier (although we also want to 
minimize known-broken builds - if the CI tools fail to compile an 
unconditional use, for example, it's harder to justify committing the 
code just to meet freeze deadlines).

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org