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

[Andy Lutomirski <[e-mail]>]

On 11/01/2013 02:21 PM, Robert Ransom wrote:
> 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.)

I've yet to see one that's remotely competitive in both performance and
message size.  IIRC, the NTRU algorithms have some serious security
questions and the LWE and McEliece-like algorithms have enormous public
keys.

That being said, being ready for quantum computers if and when they show
up is a good idea.  (Note that everything will need to be upgraded to
256-bit security if real quantum computers show up, regardless of
public-key breaks.)

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

Renegotiation is a really heavy-weight way to do this.  Just have both
sides apply some irreversible transformation to the master secret every
now and then.  (For example, they could hash the keys and throw away the
originals.)


OTOH, using renegotiation to request a client certificate after you've
seen the URL is useful.  But this doesn't actually need a change of
cipher -- it just needs the client to prove its identity.

--Andy

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