[TLS] What would make TLS cryptographically better for TLS 1.3

[Watson Ladd <[e-mail]>]

Print out the documentation of TLS as it stands. Then take an ax to it.
There are too many options that need to be supported. This leads to 2
implementations
which people use in the real world, both of which are horrible,
horrible nightmares to inspect and audit. We should include only those
options required by major users today.

The current MACs are all problematic. If you want to keep
authenticate-then-encrypt, make
the MAC include the requisite padding. This simplifies the job of
implementers tremendously by preventing timing attacks. Or better yet,
do encrypt-then-authenticate. Ask Rogaway for details.

We do not need CBC. Counter mode is better in every way, especially
with modern hardware support that depends on parallelizability for
maximal performance. Intel's AES instructions can have high latency,
necessitating having several encryptions in flight for performance.
Counter mode is never worse in performance. If we keep CBC, we should
do it correctly with explicit random IV.

TLS 1.3 should significantly reduce the number of round trips
required. To this end I propose the following obviously secure scheme:
the client sends a point on a curve in ClientHello and the server
responds with certificates (or some other authentication thing) and a
point on a curve, so that when the client speaks again, it is with a
negotiated, authenticated shared secret. Before everyone screams about
needing one signature per connection, note the server can use a time
based secret key, so only has to do one exponentiation per client.

Renegotiation should be killed: it serves no purpose.

RC4 must be eliminated to prevent the temptation of ever using it again.

If we must have options, to prevent deployment hassles, they must be
arranged and implementations forced to always ensure a common option
exists. Options should be included in the key derivation or signed to
prevent downgrade attacks.

Sincerely,
Watson Ladd