Re: [TLS] Comments on draft-rescorla-tls-renegotiation-01.txt

[Nicolas Williams <[e-mail]>]

On Tue, Nov 24, 2009 at 03:22:57PM -0800, Kyle Hamilton wrote:
> This is absolutely essential.  TLS extensions exist, but SSL 3 is
> still commonly used.  There's no reason why SSL 3 shouldn't benefit
> from anything that happens after-the-fact, even though it was never an
> actual IETF protocol.

There is no fixing re-negotiation without protocol changes.

As far as SSLv3 goes the only real issue is: how hard are protocol
changes to implement?  (And that's assuming that there are SSLv3
implementors who will bother patching, as opposed to telling their
customers to just upgrade.)

> The only issue I see is... we've got an issue in signalling back to
> the client that it knows how to do the updated handshake.  Would a
> slightly modified HelloRequest do it?

For initial negotiations:

 - The C->S signal has to be a client hello extension.

 - The S->C signal can be either or both of a server hello extension
   and/or a server Finished message verify_data computation change.

   (Note that either way you can fallback on unsafe behavior, if you
   like.)

We do need signalling in both directions during the initial
negotiations.

For re-negotiations:

 - No signal is needed -- just modify the client and server Finished
   message verify_data computation to include a channel binding.

    - The RI proposal does this via hello extensions carrying parts of
      the channel binding, which indirectly gets them into the Finished
      message verify_data computation.

      The advantage to the RI approach is that if you have a TLS 1.1+
      stack then this change just fits the existing extensibility model
      that the stack was written for.

      The disadvantages to the RI approach are: it doesn't fit as well
      for pre-TLS 1.1 implementations, and, more importantly, it
      requires that the peers check the hello extension data sent.
      Whereas just adding the data to the verify_data computation
      without actually sending doesn't require any such checking.

Nico
--