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

[Jouko Orava]

> > Consider
> >         PERFORMANCE:-EXPORT
> > for those who really dislike the ciphers in the export level.
>  EXPORT isn't a subset of PERFORMANCE, so this string would pretty
> much be identical to PERFORMANCE.

Ah, bad example, then. It just seems that
	"Performant algorithms, but none of that export crap"
and similar configuration strings seem very intuitive for users.

I can see no downside in supporting that (assuming my view that users
do find that intuitive and useful is correct).

> I don't know what you mean with a closed set here. In all types of the
> supplied strings you must have one (at least one cipher/mac etc.).

I understand. I believe users see it differently, as an extra
option that can be added; not an integral feature.

At least it surprised the heck out of me when I realized I must
explicitly enable no compression. It just felt unexpected and
weird to me.

> Nevertheless I understand that this is an complication for many, so
> there could be a new level that contains it?

Right; that sounds much better than changing existing behaviour.
I feel a bit silly for not realizing that earlier .. :)

> As I understand from your previous description, you add the
> ciphersuite name in addition to all existing options, plus some
> changes regarding the '+'? Couldn't this be added over the current
> priority string format?

Lets see.

Assume we keep the current behaviour regarding priority strings,
but with cipher, key exchange, and MAC priority lists converted
to cipher suite priority list at the end of gnutls_priority_init().

Make "+" prefix optional, so we have
	<add-prefix> ::= "+" | nothing
	<del-prefix> ::= "-" | "!"

Allow
	<del-prefix> <level>
to remove cipher suites present in <level>,
making it easier for users to combine levels.

(Even if the levels do not overlap, it may be useful
 in non-technical terms for the user to be able to
 specify that. For example, using "PERFORMANCE:!EXPORT"
 you can unequivocably state to pointy-haired-bosses that
 weak export-grade ciphers are not used,
 even if technically "PERFORMANCE" by itself already does that.)

Allow
	<add-prefix> <cipher-suite>
	<del-prefix> <cipher-suite>
to add and remove cipher suites.

Thus far this looks excellent to me.

One issue remains: How should the
	<del-prefix> <cipher>
	<del-prefix> <mac>
	<del-prefix> <key exchange>
interact with the cipher suites?
I think I have a workable suggestion:

When removing a cipher, mac, or key exchange,
apply the removal directly to BOTH the internal
priority list, and existing cipher suite list.

Consider, for example:
	SECURE256:!AES_256_CBC:TLS_RSA_AES_256_CBC_SHA1
This would result in allowing TLS_RSA_AES_256_CBC_SHA1,
but not allowing any other cipher suite using AES_256_CBC cipher.
Very logical and intuitive, in my opinion.

Better yet, this can be proven to not change the interpretation
of current configurations!

I would be happy to write a more detailed logical spec of this
to the list, if you think this is a possible avenue to go forward
with. Do you prefer BNF, or free-form/human readable?

Best regards,
  Jouko