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

[<[e-mail]>]

Martin Rex 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.

I think "what would the SSLv3 designers have done" (almost 15 years
ago) and "what should we today" are two completely different
questions, which may have completely different answers.

> 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.

We haven't had *any* discussions in the WG about what the next version
of TLS could or should or might change, so I don't think we can have
even any "informed guesses" about it.

So while your proposal may be conservative, IMHO claiming it's
"forward compatible" cannot be based on anything except totally
wild guesses... (and other people making totally wild guesses
about the topic might reasonably guess very differently)

Best regards,
Pasi
(not wearing any hats)