Re: [TLS] The risk of misconfiguration

On May 7, 2014 5:15 PM, "Viktor Dukhovni" <viktor1dane@dukhovni.org> wrote:
>
> On Wed, May 07, 2014 at 04:48:02PM -0700, Watson Ladd wrote:
>
> > I think the null encryption cipher should definitely stay out: the
> > only use I've heard of is extremely niche, namely large datasets with
> > slow CPUs on both ends.
>
> Any bulk transfer application that wants to work at wire rates to
> move already encrypted data with authentication of the endpoints.
>
> The solution to avoid accidental use of NULL ciphers is in the
> client API, no client HELLO should ever include a mixture of NULL
> and non-NULL ciphers-suites.

Why not make that a MUST in the RFC, and the same for anonymous DH? I
think this solves most of the configuration issues without making any
uses impossible.

To those who haven't been following along that means the following:
1: Your ciphersuite list can have either authenticated or
unauthenticated ciphers, but cannot have both.
2: It can have null encryption or use encryption, but not both.
3: If you try to break the above rules, the remote side (assuming it
is compliant) bails out.

I can live with that: it makes accidental misconfiguration cause
everything to stop working, thus preventing a quiet misconfiguration
incident.
>
> The "let's remove everything that I personally don't use" crusade
> seems rather heavy-handed.  Successful general-purpose protocols
> have more knobs than niche protocols.  That's the cost of success.

Maybe if TLS wasn't "successful" we wouldn't have had the terrible
track record on security, because it would be simple enough to
understand and see the problems. That's vastly preferable to having
problems that will continue to bite us for years because broken
versions of the protocol were widely deployed.

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