[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.
regards,
Nikos
More information about the Gnutls-devel
mailing list