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

[Robert Ransom <[e-mail]>]

On 10/31/13, Watson Ladd <[e-mail]> wrote:

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

This protocol should be designed to allow future extension to use
post-quantum encryption and/or key encapsulation cryptosystems.  (I
don't believe that quantum computers will become a threat, but some PQ
cryptosystems may be faster than ECDH.)

It also needs to either allow session resumption without the
possibility of reusing any key used to encrypt or authenticate
application-level data, or explicitly forbid session resumption.


> Renegotiation should be killed: it serves no purpose.

Renegotiation is a critical feature of TLS, which serves multiple purposes.

* Renegotiation allows rekeying of a session.  This is absolutely
required for any ciphersuite based on a block cipher with a 128-bit or
smaller block, because block cipher modes' security properties degrade
after they are used for more than some number of blocks.

* Applications can also use renegotiation-based rekeying to improve
forward secrecy; for example, the Mixminion specification
(<https://github.com/nmathewson/mixminion-doc/blob/a661212831d2afc3200339b2634ca16452e3aeec/spec/minion-spec.txt>,
section 4, line 1040) requires that relay-to-relay TLS connections be
rekeyed using renegotiation every 15 minutes for this purpose.

* A TLS connection can be established by a fully trusted device which
knows a password or other application-layer authorization credential,
authorized to perform some operations using messages within the TLS
connection, and then transferred with the help of renegotiation to a
less trusted device to actually perform those operations.  This is
similar to the preceding use, but to provide 'sideways secrecy' rather
than forward secrecy.

* One version of the Tor 'link protocol' (Tor's term for its outer
TLS-based connection protocol) uses renegotiation to provide secrecy
for the server's certification chain against purely passive attackers.
 The purposes above could be served by applying a one-way function to
the originally derived key material, then discarding the old keys;
this purpose cannot.


Robert Ransom