Re: [TLS] simplistic renego protection

[Martin Rex <[e-mail]>]

Michael D'Errico wrote:
> 
> > 2) Is that we seem to agree that TLS 1.3 will have an updated finished
> > calculation anyway, not requiring the use of extensions. If we define that
> > "future" finished calculation now and use it in the simplistic approach,
> > then that would actually be closer to future versions of TLS, compared with
> > an extension approach.
> 
> This is one of the reasons I so dislike RI.  The alternative presented
> modifies the Finished calculation in a way that is forward-compatible;
> it can be the default for future TLS versions, and that is the way it
> is implemented in my code now.  If people don't like adding the previous
> verify_data to the stream of handshake messages so it gets hashed along
> with the rest, then please suggest a better way.
> 
> One note: at first I didn't like the idea of inserting the verify_data
> immediately after the ServerHello, but when I implemented it, that was
> actually the most natural place to put it.

For the client, it is _the_ position where it reliably is in the posession
of the Server.Finished from the previous TLS handshake. (Think of
optimizing an renegotiation in order to protect the client identity,
where one wants to piggy back the ClientHello of the immediate
renegotiation onto the Client.Finished message.

Does anyone remeber that the TLS WG gave the advice to people asking
for identity protection to perform an initial client-anonymous
TLS handshake directly followed by a renegotiation with client-cert
authentication?

(a related discussion what about gss-api authentication
 around 20-dec-2006, Subject: [TLS] Comments on TLS identity protection)


-Martin