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

From: Watson Ladd <[email-masked]>
Date: Thu, 31 Oct 2013 13:30:33 -0700

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

---

From: Nico Williams <[email-masked]>
Date: Thu, 31 Oct 2013 18:09:59 -0500

My list:

 - It should be deployable, that's first; in particular, it needs to be
   deployable with ECDH PFS key exchanges.

   This means that the mess of *DHE* ciphersuite and group/curve
   negotiation urgently needs a revamp.  We need to de-explode the
   cipher suite registry by separating negotiation of key exchange, KDF,
   and server authentication algorithms/methods from each other and from
   the symmetric cipher/modes.  This should have the bonus of yielding
   smaller hello messages (except during the transition to 1.3, natch).

 - It needs to use modern cipher modes for AES and friends: GCM, CCM,
   and *maybe* an option for AEAD by generic composition (AES-CBC-SHA3
   or AES-CBC-HMAC-SHA256, encrypt-then-mac, ... with random IV
   chaining).

 - Many fewer nonce bytes and random IVs where possible.  Nonce payloads
   should be sent when needed, if needed.  For example, to derive a
   session key from an DHE shared secret one does not really need
   nonces.  This means that counter modes are better, for example, than
   CBC modes.

   <aside>
   
   Perry Metzger recently proposed (I'm extrapolating a bit) a
   random-IV-free CBC-like cipher mode where instead of a nonce one
   sends a [small] counter which must be encryted to recover the IV
   for use as the first block in the CBC decryption of the ciphertext.
   I kinda like this.

   CBC has some advantages over counter modes.  However, for this
   particular application (TLS and DTLS) it's easy enough to avoid (and
   detect) counter reuse that counter modes' disadvantages are
   tolerable.

   </aside>

 - Renegotiation should be replaced with an NPN-like extension that
   provides privacy to the TLS client principal name.

 - Design-in channel bindings from the get-go.

Nico
--