[gnutls-devel] [RFC] Relaxing cipher suite (priority) string requirements
nmav at gnutls.org
Fri Feb 1 14:36:09 CET 2013
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> ::= "-" | "!"
> <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:
> 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.
> 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
More information about the Gnutls-devel