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

[Robert Ransom <[e-mail]>]

On 11/1/13, Watson Ladd <[e-mail]> wrote:
> On Nov 1, 2013 2:21 PM, "Robert Ransom" <[e-mail]> 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.)
>>
> The PQ transition involves reworking the PKI as well. We also don't know if
> NTRU or something else will win. A proffered version byte to avoid
> downgrades could work, but I would not want to commit to the future.

If I believed that a 'PQ transition' would be needed, I would argue
for implementing it *now*.  This is purely for performance purposes,
if PQ cryptosystems turn out to be faster than ECDH in at least some
implementations.

>> 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.
> After one zettabyte according to a simple calculation.

For counter mode with a non-GCM-like MAC, yes.  Other modes have other
security bounds.

>> * 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.
> If reconnecting is cheap enough that works. Designers need to deal with
> connection death anyway.

Reconnecting allows relatively simple network eavesdropping logs (e.g.
logs which contain connection endpoint addresses, start and end time,
and amount of data transferred) to record more information about the
application's behaviour.

Apart from that, applications should not need to cause connection
death in order to obtain forward secrecy.

>> * 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.
> What does renegotiation get here?

Renegotiation can be used to prevent the untrusted device from
decrypting the user's password in order to use it to authorize a later
TLS connection.

> The untrusted device can do everything unless it is being monitored by a
> trusted device.

The untrusted device cannot do anything after the TLS connection is closed.

>> * 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.
> TOR could send a temporary outer signature and an inner proof.

It's "Tor", not "TOR".

That's what it does now, using a custom authentication protocol with a
custom channel-binding  at the application layer, because the TLS
renegotiation mechanisms available at the time were too problematic.

> I agree this
> is a weakness, but CurveCP like mechanisms only work thanks to some known
> key.

Or the server could send the blob authenticating its (EC)DH public key
inside the (EC)DH secure channel.  (I mentioned this as an application
of renegotiation because you did not specify that server credentials
would be concealed, not because there is no special-purpose hack to
get around the lack of renegotiation.)


I agree that some of the problems that I know renegotiation can solve
can be addressed using other mechanisms.  I don't see the attraction
of designing and implementing a different protocol feature to solve
each problem when a single secure, well-designed renegotiation
protocol would solve all of them at once.


Robert Ransom