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

[Nicolas Williams <Nicolas.Williams at sun.com>]

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!

   Either both, the client and the server will do this, or not do it, in
   which case the Finished messages will check out on both sides, or one
   will do it and the other won't, in which case the Finished messages
   will fail to check out on both sides.  If there's a MITM and the
   client and server both do this, then the MITM will be detected.

   I.e., channel binding is the solution, but there's no need to
   negotiate it -- the server wouldn't accept re-negotiation from
   clients that don't support the fix anyways.

   If there's no need to negotiate the fix, then there's no need to use
   Hello extensions.

   Also, this scheme allows both, the client and the server, to securely
   determine whether the other implemented the fix or not.  This is
   potentially a good or bad thing, depending on your point of view,
   since it allows for implementations to have an option to fallback on
   insecure behavior.

2) I believe the I-D, if the fix is not modified, should have the
   following INFORMATIVE text added:

   "
   This solution is akin to channel binding [RFC5056] using the
   'tls-unique-for-telnet' channel binding type
   [I-D.altman-tls-channel-bindings].  This is not a generic
   channel binding facility however.
   "

   RFC5056 and draft-altman-tls-channel-bindings-07.txt should be
   added as informative references.  (draft-altman-tls-... is currently
   listed as a normative reference.)


Nico
--