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

[David-Sarah Hopwood <[e-mail]>]

Ravi Ganesan wrote:
>> 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.
> 
> 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.

Well, it also applies to a renegotiated abbreviated handshake (where a
renegotiating handshake resumes an existing session). The spec should
probably point out that this case is possible, and that exactly the same
attacks and defences apply.

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

It's relying on the fact that those checks were done correctly in the
session that is being resumed.

-- 
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com