[gnutls-devel] [RFC] Relaxing cipher suite (priority) string requirements

Nikos Mavrogiannopoulos nmav at gnutls.org
Mon Jan 28 02:17:48 CET 2013

On 01/27/2013 08:45 AM, Jouko Orava wrote:

> On Sat, 26 Jan 2013, Nikos Mavrogiannopoulos wrote:
>> Yes, but for these people the priorities NORMAL, PERFORMANCE or SECURE
>> should be clearly advertised by the applications.
> Right, and that's what I too recommend for users. For example, for the
> OpenLDAP bug I recently reported (libldap crashes in starttls if linked
> against GnuTLS and given an invalid priority string), I suggest using
> "SECURE256" in particular.

SECURE256 is pretty high security for today's standards. Most probably
with such a priority string you wouldn't be able to connect to many servers.

> The only real problem I can see is in finding out a suitable set
> of logical rules. For example, if the cipher suite specifies both
> cipher suites, and cipher algorithms, how these interact?

> I'm leaning towards adding cipher suites based on cipher-mac-kx separately
> from named cipher suites, but removal being common, and operating only
> up to that point in the priority string. It seems to feel most intuitive,
> and lead to sane code.

It could be two different modes. One that you specify explicitly
ciphersuites, and the other that is like now (level+ciphers,macs etc.).

Does this make sense?

>>> A third option would be to enhance the current priority string
>>> parsing, but in a way that allows automatic conversion between
>>> GnuTLS and OpenSSL priority strings
>> That would be interesting for programs that switched from openssl to
>> gnutls, but I think this no longer happens. Programs now either start
>> with gnutls or not. In any case, that again couldn't be part of gnutls.
>> It could be part of gnutls-openssl library or so.
> I was thinking more about larger organizations, where most of the servers
> tend to be of the RHEL/CentOS/ScientificLinux variety (using OpenSSL),
> and workstations of the Debian/Ubuntu/Mint variety (using GnuTLS),
> and keeping configurations compatible.
> Given the configured priority string on one, the tool could describe
> the effects in human-readable terms, and show compatible rule in the
> other. Preferably with recommendations (like "PERFORMANCE" or "SECURE256"
> for GnuTLS).

It sounds reasonable.


More information about the Gnutls-devel mailing list