I'm new to SSL/TLS and I'm staring as a new security researcher. It appears to me that SSL/TLS protocol is needlessly complex for arriving at a shared secret. The complexity results in so many bugs (e.g., downgrade attacks, implementation bugs) What is the reason?

If I come up with a simple key-exchange protocol (without all the fancy features and no backwards compatibility), but is proven to be secure (both protocol and implementation via formal verification), would organizations, browsers start adopting it?


closed as primarily opinion-based by e-sushi Jul 5 '17 at 2:06

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 5
    $\begingroup$ No they would not. Those protocols (e.g. CurveCP or noise) already exist. TLS is complicate due to a mix of history balast, design-by-committee and being overly flexible. $\endgroup$ – CodesInChaos Nov 6 '15 at 19:02
  • 1
    $\begingroup$ Chances are you can't make it more simple if you want to keep all the fancy features and TLS does have security proofs (at protocol level). As for the reason: Compatibility. People didn't want to break their old crap, they wanted to patch it so they don't have to spend alot money on starting from scratch again. $\endgroup$ – SEJPM Nov 6 '15 at 19:04
  • 2
    $\begingroup$ It's also not as simple as just "backwards compatibility", different organizations will have valid security / policy / use-case reasons for choosing one algorithm over another (RSA vs ECC, certificate-based DH vs DHE, ansix9p521r1 vs brainpoolP512t1, etc). So you really have to support everything. If you built software that did all this, it would end up looking an awful lot like TLS. $\endgroup$ – Mike Ounsworth Nov 6 '15 at 19:12