Re: [TLS] Comments on draft-rescorla-tls-renegotiate

[Martin Rex <[e-mail]>]

Nicolas Williams wrote:
> 
> Comments:
> 
> 1) The rest of this comment can be ignored if the use of protocol
>    extensions in draft-rescorla-tls-renegotiate is deemed to not be a
>    problem.
> 
>    I believe this problem can be fixed without using protocol extensions
>    at all.  All that has to be done is this: for re-negotiations the
>    Finished message computation changes from this:
> 
>     PRF(master_secret, finished_label, Hash(handshake_messages))
>        [0..verify_data_length-1];
> 
>    to:
> 
>     PRF(master_secret, finished_label,
> 	    Hash(handshake_messages || outer_connection_client_finished))
>        [0..verify_data_length-1];
> 
>    where outer_connection_client_finished is the client Finished message
>    for the previous/old/outer TLS connection
> 
>    There is no need to signal this!

If you do not signal, then your client will not be able to detect
whether it is talking to an old server, in which case the clients
initial handshake might still be proxied into the renegotiation
of that old server.

If there is a signaling in both directions available, and the
client does not receive an indicator in the ServerHello that it
is talking to an Updated Server, then it can never warn and offer
to not connect (some people seem to want that option).

Similarly, if you do not get a feedback in the ServerHello telling
you whether that server is an updated server or not, then your
client can not agree to an old insecure renegotiation (there
might be environments where the connectivity and possibility
to renegotiate is desired, and the MITM-susceptibility not
considered a problem.


If you want to provide the consumers those options, you will
need signaling.  When changing the calculation of the verify_data
of the finished messages for renegotiation, then the only information
that needs to be signaled is that the other side is updated.

Apparently there are some network monitoring folks that would like
to be able to distinguish patched from unpatched TLS implementations.
They might want signaling.

You could have the servers signal with the highest bit of the
protocol server_version in the ServerHello that they're using a
secured (i.e. different from the base protocol version) finished
message calculation for renegotiations, provided that the
client has indicated support for recognizing this modified
server_version in the ServerHello, indicating that the client
is actually talking to an updated server.

For TLS v1.3, the secure renegotiation Finished message calculation
could be made the default, and then it would no longer be necessary
to have the server modify its protocol version number for
protocol versions >=1.3.

Old clients would still get the old protocol version back
on the ServerHello.

Updated clients asserting the special ciphersuite ID would receive:

  server_version

  0x03,0x00     unpatched server, SSLv3 protocol, original finished calc
  0x03,0x01     unpatched server, TLSv1.0 protocol, original finished calc
  0x03,0x02     unpatched server, TLSv1.1 protocol, original finished calc
  0x03,0x03     unpatched server, TLSv1.2 protocol, original finished calc

  0x83,0x00     patched server, SSLv3 protocol, secure renego finished
  0x83,0x01     patched server, TLSv1.0 protocol, secure renego finished 
  0x83,0x02     patched server, TLSv1.1 protocol, secure renego finished  
  0x83,0x03     patched server, TLSv1.2 protocol, secure renego finished 


and in the future:
  0x03,0x04     new server, TLSv1.3 protocol, secure renego finished

If we're modifying the calculation for the finished messages for
the renegotiation handshake to include the verify_data of the
previous session, then this is a protocol change, and indicating
this in the protocol version of the ServerHello is _no_ abuse. :)

If the client wants to (a) still talk or somewhat dangerous (b) still
renegotiate in the unprotected traditional fashion with an old server,
it can do so, because it determine from the server_version in ServerHello
whether the server is patched and which Finished message calculation
the server will be using.


-Martin