Re: [TLS] The risk of misconfiguration

On Tue, May 6, 2014 at 7:00 PM, Viktor Dukhovni
<viktor1dane@dukhovni.org> wrote:
> On Tue, May 06, 2014 at 06:08:52PM -0700, Watson Ladd wrote:
>
>> > 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.
>
>> 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.
>
> In Postfix the user chooses a "cipher-grade" that sets the floor
> on the set of enabled cipher-suites.  The levels are monotone.
> This is a simple interface that is rather difficult to mess up.

Actually, it makes the same mistake as OpenSSL does:enabling anonymous
ciphers even when configured to send a server certificate and use 128
bit encryption, without an additional option set. (Source:
http://www.postfix.org/TLS_README.html, search for the Server-Side
Cipher Controls section)

At least the documentation notes that this happens, and tells you the
option you really need. Of course, the sad state of TLS for email
prevents this from being a problem in practice. Postfix is one of the
better-written applications out there, with a team that gets it. That
does not apply to all applications. It doesn't even apply to mobile
banking applications.

> The underlying definitions of these grades is also configurable,
> but I strongly discourage users from attempting to touch these
> without expert advice.
>
> This has worked well for nearly a decade with no evidence of
> significant user confusion or misguided misconfiguration.
>
> User interfaces need to make the simple things easy and the
> complicated things possible.
>
>> 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?
>
> The above is just a rhetorical rant.  Risk cannot be banned out of
> existence, but systems can be designed with greater safety in mind.
>
>> 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.
>
> The above is plainly false.  Good systems offer many layers of
> controls, some for naive users some for experts.  They have high
> and low level APIs, with the latter offering more fine-grained
> control when needed.  OpenSSL should be improved not neutered.
> Software that only dumbs everything down is not progress, we need
> software that is both usable and flexible.

I'm a Hobbsean: our role is to assure the safety of encrypted traffic,
even if people can't do what they want as a result. How many
ciphersuites do you really need? Not 314, soon to increase with the
addition of ChaCha20+Poly1305. (Which surprisingly we do need: very
few of the block ciphers are side channel resistant) This number is
actually an underestimate: ECDH and ECDHE indicate curve support
separately from ciphersuite. In TLS 1.3 we've decided to take a vast
number to the woodshed: the question now is to reenable null
encryption.

Maybe it's possible to make a configuration system that enables a
considerable number of these ciphersuites without letting people blow
their leg off accidentally. Experimental evidence largely indicates
otherwise.

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