Re: [TLS] Verify data in the RI extension?

[Martin Rex <[e-mail]>]

[e-mail] wrote:
> 
> For simplicity, the current draft is already very simple, and IMHO
> it's not clear that continuing to tweak it has a positive return
> on investment, considering it delays the publication. 

Not really.

I ask this before: what should the original designers of the
SSLv3 renegotiation have done from the beginning to make it
secure.  Invent TLS extensions and then a TLS extension RI
is definitely _not_ the answer.  They would have fixed the
handshake message hash from the beginning.

The "dirty ugly" signaling is a patch for a "dirty ugly" security problem
in "dirty old" implementations of a "dirty old" protocol.
We need it to distinguish old from updated implementations and for
supporting interop with old -- otherwise we could just change
both handshake algorithms (like including different finished
labels) and make the fix entirely without on-the-wire changes,
no signaling, but also no interop with the installed base.

> 
> About future versions of TLS, IMHO it's quite difficult to predict which
> would be most compatible. What if, e.g., the next version of TLS
> decides that sending certificates in the clear wasn't that great idea,
> and nowadays we can afford to do Diffie-Hellman before doing any
> authentication? This could completely change all the handshake
> messages after ClientHello, and the current functionality of "Finished"
> could be done in quite different way.. 

If it does not retain (Extended)ServerHello, then it will actually
kill a lot of the existing SSL/TLS protocol features
-- and reliably kill TLS extension RI with it.

The handshake message hash is one of the basic concepts of the
SSL/TLS protocol.  If that is changed, then you basically have
none of the original protocol left.


Therefore directly feeding into the handshake message hash is
the more conservative and forward compatible approach.


-Martin