Re: [TLS] TLS Digest, Vol 65, Issue 76

[Ravi Ganesan <[e-mail]>]

> I do agree with you there.  Unless the saved session mechanism also
> triggers the functionality and checks that a full handshake would, but
> I think that's too much to hope for.
>
> -Kyle H


I know everyone on this thread knows otherwise, but the way the terms get
used, can easily result in confusion between "full handshake", "abbreviated
handshake" and "renegotiated full handshake".  The attack only applies of
course to last category, and NOT to the abbreviated handshake.

To be pedantic, in the "full" handshake the two sides (or at least the
Server) prove identity to each other using their private keys and
certificates chaining to mutually trusted roots, and exchange the
"master_secret" which is really the "session key". This "master_secret" can
be used by the "abbreviated handshake" to create many (including parallel)
subsequent sessions with each party proving identity here by proving
possession of the session key (the "master secret"). During the abbreviated
handshake one simply CANNOT do all the checks in the full handshake, not
because the developer chose not to do it, but because there is no question
of public key credentials...the abbreviated handshake is relying purely on
the shared secret (via the server.verify and client.verify).

Sorry if this is so obvious to those on this thread, but a lot about SSL is
*not* obvious to the world at general, and unfortunately a number of people
are convinced that the attack discovered a flaw in session resumption or
opening parallel sessions using the abbreviated handshake. If it did, I
missed it perhaps.  If not, perhaps language in text clarifying this
'obvious' point might be useful.

Thanks,

Ravi
-- 
Ravi Ganesan
[e-mail]
www.findravi.com