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 _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev