Re: [TLS] Triple Handshake Fix.

[Geoffrey Keating <[e-mail]>]

Karthik Bhargavan <[e-mail]> writes:

> > I read this and couldn't work out how it interacted with
> > renegotiation.  I'm surprised there's no discussion of renegotiation
> > at all in section 3.  Does 'handshake_messages' include:
> >
> > a) Only the first handshake; or
> >
> 
> for each session, handshake_messages includes messages in the full
> handshake that set up the session.
> each full renegotiation handshake sets up a new session and hence a new
> session hash.
> 
> the session hash countermeasure is meant to link resumed connection with
> the original connections where the session was created.
> independently, we still need renegotiation indication (rfc4726) to link
> different handshakes on the same connection.
> in other words, the session hash complements rfc5746, it does not replace
> it.

So, I think the draft actually means b out of my original list of
choices.  I would not have guessed that.

The draft definitely needs to explain this.

The draft should also say something about requiring RFC5746.

Would it be better if we tweaked this draft so that if you use it you
don't need RFC5746?  It would be easy to do so and would make the
analysis simpler.  You could just include the previous Finished
messages in the hash, I think.

There should also be something in the security considerations section
about message sequence.  Some implementations might accept, say, a
second ServerCertificate message before the Finished, which would probably
be bad.