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

[Jouko Orava]

> Ouch. I cannot test them now (may take some time), but if you add a test
> in tests/ would speed up things. The test can simply use gnutls-cli -l
> --priority XXX, for few typical strings and some corner cases, and
> verify that the expected values are present.

Right. I did not test the patch yet, because I wanted to make sure the
approach is acceptable first.

I do not want to hurry, because including the optional '+' patch
might make the latter part of the overall task here harder.
Currently, the syntax of the priority strings GnuTLS accepts is
very strict; we still have the option to make it a lot more versatile,
while keeping full compatibility with existing valid strings.
Making '+' optional makes that a lot harder.

> > In other words, priority string
> > 	TLS_RSA_AES_256_CBC_SHA1
> > should have the same effect as
> > 	+RSA:+AES_256_CBC:+SHA1
>
> That's dangerous. TLS_RSA_AES_256_CBC is very different from +TLS1.0
> +RSA +AES-256-CBC. The latter sets the order for the individual ciphers
> while the former only for that specific ciphersuite.

Yes, exactly. That's why I don't think my suggested patch
(that is, perhaps excluding the remove_prio() fix and making '+' optional)
should be considered further at all.

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

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
	or fail
	Use TLS1.0 or TLS1.2 (and no other versions)
	without compression
	using x.509 certificates
with the cipher suites taken from recommendations, logs, or internal
documentation. The string they seem to start with looks something like
	TLS_RSA_AES_256_CBC_SHA256:TLS_RSA_AES_256_CBC_SHA1:\
	TLS_RSA_CAMELLIA_256_CBC_SHA1:TLSv1.0:TLSv1.2

Usually the reasons for restricting the cipher suite is not
cryptographical, but practical; related to implementation issues
or organizational politics. (Unfortunate, I know. Actual security
seems to rarely be a true priority; the appearance of security
seems to be enough.)

> However, setting specific ciphersuites was my reason for switching to
> priority strings (even though it was never implemented). It needs some
> work, but the main idea is to generate the list of ciphersuite numbers
> in gnutls_priority_set(), and later be used in the handshake.
>
> Now the current behavior is to generate the ciphersuite numbers during
> the handshake.
>
> 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.

Right now, I'm still trying to write a set of logic rules how
the priority string should be parsed, so that it would be intuitive
and easy for users to understand, and construct, preferably
keeping the interpretation of current priority strings intact.
The code is straightforward to write after that.

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.

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.

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.

Regards,
  Jouko