Re: [TLS] Triple Handshake Fix.

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

I also note that the draft leaves out the (last?) 'certificate verify'
> message, is that intentional?  Are there any security consequences?
>

CertificateVerify is not part of the handshake_messages on purpose, since
the SSL 3.0 CertificateVerify message uses the master secret.
So, to be backward compatible with SSL 3.0, we need to compute the master
secret before this message.

Is there a ciphersuite where the CertificateVerify message carries new
contextual information that is not present in the previous messages?
In the key exchanges we have looked at, excluding this message seems to be
safe (e.g. the client certificate is in a previous Certificate message).

-K

>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>