Re: [TLS] The risk of misconfiguration

On Tue, May 6, 2014 at 5:24 PM, Viktor Dukhovni
<viktor1dane@dukhovni.org> wrote:
> On Wed, May 07, 2014 at 01:01:39AM +0100, Alyssa Rowan wrote:
>
>> > The OpenSSL cipherlist is
>>
>> ...um. The word I'd use would be: hairy.
>>
>> In practice, unfortunately way too hairy for the average developer;
>> whence passing the buck to the average end-user; whence the average
>> end-user taking the cipherlist as copypasta from the first Google
>> result they found that actually worked.
>>
>> We've all seen the end results.
>
> We must not confuse implementation user-interface issues with
> protocol issues.  The protocol supports many different use-cases.
> Interfaces for cipher selection in implementations are not protocol
> issues.  The OpenSSL cipherlist interface is beginning to get some
> attention.  That issue belongs on openssl-dev@openssl.org, not
> tls@ietf.org.

Agreed, but it's an example of the hazard that insecure modes present.
OpenSSL is not an outlier: with 100+ possible ciphersuites, with
strange omissions and inclusions, and completely lacking information
about which curve to use, designing a good configuration system to
pick TLS ciphersuites is hard. PolarSSL takes the exact opposite tack,
forcing users to subset a single preference order. It is entirely
possible that legitimately desired ciphersuites cannot be chosen in
PolarSSL: I know they cannot be reordered.

No matter how the choice is presented to end-users or application
developers, so long as it is possible to misconfigure TLS, it will be
misconfigured. You can blame the end user or the programmer or the
library writer all you want, but unless a library is willing to forgo
supporting null ciphers, they will be used inadvertently. Why include
something that should virtually never be used, when using it has bad
consequences?

We've recognized the need for guidance on how to use TLS, hence
formation of UTA. We're punting on implementation, although I recently
got an email about the C standards body wanting to standardize APIs
for networks, which, if they included TLS with a sane API would be
wonderful. But the complexity that OpenSSL reveals is real: there is
no way to support all possible combinations of ciphersuites without
something this nasty to pick between them.

Sincerely,
Watson Ladd

> --
>         Viktor.
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin