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

[Nikos Mavrogiannopoulos]

On 01/26/2013 12:43 PM, Jouko Orava wrote:


>> The idea of setting
>> priorities for individual ciphers was to avoid even introducing the
>> notion of ciphersuites to the users/admins. They don't need to know and
>> everyone (hopefully) knows the individual ciphers.
> Unfortunately, in my experience -- meaning looking at what kind of issues
> administrators I know are having -- users seems to be aware of
> ciphersuites, whereas ciphers, message authentication codes, and key
> exchange algorithms are just underlying details they find hard to grasp.


Yes, but for these people the priorities NORMAL, PERFORMANCE or SECURE
should be clearly advertised by the applications. Otherwise they are
going to search google on what to put on this priority string field and
end up with obscure strings that make no much sense (that is the
impression I get from watching people configure mod_ssl).

> In other words, my experience is the exact opposite. They know the
> ciphersuites, but not the individual ciphers or key exchange algorithms
> or message authentication schemes, at all.

> In practical terms, I see administrators wanting to specify something like
> 	Use AES_256_CBC with RSA key exchange and SHA256 MAC
> 	or AES_256_CBC with RSA key exchange and SHA1 MAC
> 	or CAMELLIA_256_CBC with RSA key exchange and SHA1 MAC


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.

[possibly in some later version of gnutls such priority strings should enforce

the acceptable certificate and DH key size - possibly using new strings]

>> So if ciphersuite names are to be allowed in the string, the above has
>> to be done.
> 
> Ah, I came to the same conclusion, I think.
> 
> Basically, the functionality of lib/algorithms/ciphersuites.c:
> _gnutls_supported_ciphersuites() should be moved into
> lib/gnutls_priority.c:gnutls_priority_init(), with
> 	priority_st cipher;
> 	priority_st mac;
> 	priority_st kx;
> in struct gnutls_priority_st replaced with
> 	priority_st ciphersuite;
> 
> The ciphersuite integer keys could be e.g. 1 + index of cs_algorithm
> entry, or perhaps (id[0] + 256*id[1]). I have no preference, but
> I suspect the former will lead to cleaner code.


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

> Another option would be to revamp the priority string parsing
> entirely, and move to one that allows reasonable compatibility
> with OpenSSL priority strings. A lot of users would love that,
> as it would reduce the configuration differences in applications
> that can be linked against either one -- for example, OpenLDAP.


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.

> 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, for example with a special
> conversion tool. It might have to be linked against both libraries,
> to be fully reliable, though, as it might have to examine the
> internal data structures to find out if the two are really comparable.


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.

> Unless someone has already considered what the logical rules
> for parsing the priority string (including cipher suite names)
> should be, I shall try to cook some up, and report to the list.


Thank you.

regards,
Nikos