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

[Jouko Orava]

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.

The problems with priority strings only occur when there are extraneous
requirements, for example to use a specific cipher suite, or to not use
a specific ciphers or cipher suites.
Often these are political, not technical.

> Do they want to specify that, or do they want to set a certain security
> level? I think the reason they try to set that is because of how mod_ssl
> expects things. As an administrator I wouldn't want to specify that
> stuff. I'd like to specify a certain security level such as SECURE128 or
> SECURE192.

A vast majority of users should ever use the level in the priority
strings, I agree.

However, when that is not sufficient, yes, the users do wish to specify
individual cipher suites.

A particular example is where an LDAP server has to support a large number
of cipher suites due to a wide variety of clients and connections.
(For example, some clients are known to be in a trusted part of a network,
 others use e.g. wireless.)

Restricting the cipher suites on the server is not feasible,
so it has to be done on a per-client (per client type) basis.

Again, most of that is not really a security issue, but political.

For example, if an organization can configure all their workstations
connected wirelessly to use TLS_RSA_CAMELLIA_256_CBC_SHA1 on TLS1.0
connections only, it is simple to document, monitor (ie. only one cipher,
mac, kx, and TLS version to monitor for security advisories), and
report to non-technical pointy-haired bosses.

Let me reiterate: I find the levels extremely useful, and will always
use and recommend them myself. However, for the other cases,
like requiring a specific cipher suite, GnuTLS priority strings
are very complicated to get exactly right.

(For Ubuntu, which still uses GnuTLS-2.12, with the OpenLDAP StartTLS
 bug when compiled against GnuTLS, I had to write a small ldapsearch-like
 program that also accepts the priority string as a command line
 parameter, to experimentally find a suitable priority string
 for a colleague.)

> Yes. Note that during the handshake, the server and the client would
> need to process this list and remove the ciphersuites that are not
> compatible with their keys (but if an index is used as you propose that
> would be pretty efficient).

My thoughts exactly.

gnutls_priority_init() would still have to internally keep cipher, mac,
and kx priority lists, in case the priority string specifies those,
and select applicable cipher suites added to the list.
That is not a problem, as it is just a variant of the code in
lib/algorithms/ciphersuites.c:_gnutls_supported_ciphersuites().

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.

> > Another option would be to revamp the priority string parsing
> > entirely, and move to one that allows reasonable compatibility
> > with OpenSSL priority strings.
>
> No, openssl priority strings aren't any better (and are harder to
> understand if you know what's going on). OpenLDAP with gnutls is a long
> story. They use gnutls but they expect the openssl behavior and API.
> Gnutls isn't an LGPL port of openssl. It's another library and I don't
> think there is any reason to change that.

Yes, I'm not really in favour of that option myself, either.
I just wanted to state it, because it is an option often expressed in
bug reports and similar complaints with e.g. OpenLDAP.

I'd much rather have a clear set of logical rules,
that would be easy to use.

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

Best regards,
  Jouko