Re: [TLS] Proposal for hybrid solution using most of the ideas

[Martin Rex <mrex at sap.com>]

Nasko Oskov wrote:
> > 
> >I think we agree that an upgraded finished calculation is not a dirty hack.
> >This is what future versions of TLS will use by default.
> 
> Agreed.

So far it is actually an upgraded handshake message hash calculation for
the renegotiation handshake.  TLS extension RI uses two extra layers
of wrapping

ExtendenServerHello(
   TLS-extension-RI(
      previous.Client.Finished.verify_data
      | previousServer.Finished.verify_data
   )
)

where as I'm prefering a more environmentalist approach, adding
the verify_data of the previous Client.Finished and Server.Finished
directly to the handshake message hash without any gift wrapping.


> 
> Yes, we might be missing something else. The reason I picked the Certificate
> message is that it is dynamic size by default, so we don't have to alter
> existing data, just append.

To me that feels very wrong to use the Certificate message.
I'm convinced that it should go into the ServerHello.  I'm not
questioning that ServerHello is the correct place for all of the
cryptographic parameters _and_ the TLS extensions.


The Certificate message is not part of TLS handshakes with
server-anonymous ciphersuites and it is equally missing on
TLS session resume handshakes and I _really_ want to have
the server signal on each and every TLS handshake!

I would not even try to think about justifications why it might
be OK to omit it on some of the handshakes (My intuition says,
this is going to come back at us one way or the other if we did this).


> 
> I realize I could've been more precise in my initial proposal. This is
> exactly the essence of it. Finished calculations are the same across the
> board, just signaling is different. TLS to use extensions, SSLv3 to use
> whatever hack we agree on.

This would add the complexity of the solution and double the
interop testing scenarios.

Why use two signaling mechanism where one is perfectly sufficient?

-Martin