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

[Nikos Mavrogiannopoulos]

On Fri, Feb 1, 2013 at 12:02 PM, Jouko Orava <jouko.orava at helsinki.fi> wrote:
>> > 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).
[...]
> (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.)

I do believe that this will cause more confusion with the currently
available levels, but could be useful when we have more levels that
act more like a group of ciphers.

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

Let's then rename level to cipher-group (or ciphersuite-group) to
signify better it's purpose.

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

Indeed.

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

I think the best would be a description that could be part of the
manual (so that there is no double work to port it there). However,
would you be interested in implementing it? I could help with that if
needed.

regards,
Nikos