[openssl-dev] Proposed cipher changes for post-1.0.2

[Daniel Kahn Gillmor]

On Wed 2015-02-11 10:15:11 -0500, Salz, Rich wrote:
>> Note that for most applications the correct approach to configuring
>> ciphersuites should be to start with DEFAULT and subtract what they don't
>> want.  The library is then responsible for a generally sensible default order
>> and default exclusions.
>
> I strongly disagree.  Most applications should explicitly list the
> ciphers they DO want.  That is the only way an application can be sure
> of what it is getting, without consulting external parties or
> configuration.  Otherwise, when the next Crime or Poodle or
> NameOfTheWeek comes out, you have no idea if you are vulnerable or not
> unless you look at something like the OpenSSL source code.
>
> For what it's worth, I believe that "security levels" make this
> problem much worse.

I disagree with you here, Rich.  There is ongoing evolution of our
understanding of TLS best practices, including standards, cryptanalysis,
and interoperability.  This dynamic situation seems unlikely to be come
static at any point in the future (changes in standards, cryptanalysis,
and the state of the network will continue to occur).  Even those of us
who spend a lot of time thinking about these matters have a hard time
keeping up.

As a larger ecosystem, we have maybe three main options to manage this
dynamism:

  0) every adminstrator of every TLS-using network service and every
     user of every TLS-using client needs to fiddle with TLS parameter
     selection as changes happen.

  1) every developer of every TLS-using tool (client or server) needs to
     fiddle with TLS parameter selection as changes happen.

  2) every library that implements TLS needs to fiddle with TLS
     parameter selection as changes happen.

Situation (0) is clearly untenable (it's also what we are valiantly
attempting today, e.g. https://bettercrypto.org/, because the other
things haven't happened effectively).

And situation (1) is just plain unlikely to happen.  Most software
developers *want* TLS to be "magic sauce" that they can sprinkle on and
have it Just Work.  They do not want to keep track of which parameters
are considered a bad idea this month, and they certainly don't want to
release new versions of their software just because someone says "hey,
you need to update your cipherstring".

On the other hand, the people who are experts in this situation and who
understand the dynamics best are going to be the folks tapped for the
work in (2).  This is why these kinds of things should be done by
default in the TLS implementations.

That doesn't mean that integer-based "security levels" is the right
approach (is there documentation on what the OpenSSL semantics should be
for these other than doc/ssl/SSL_CTX_set_security_level.pod?) -- it's
possible that "common use cases" would be better.  Then there could be
an "opportunistic" use case that meets Viktor's goals, and a "standard"
use case that hews closer to TLS BCP.

    --dkg