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

[Nico Williams <[e-mail]>]

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
--