Re: [TLS] Abbreviated Handshake != Renegotiated Handshake

[Marsh Ray <[e-mail]>]

Ravi Ganesan wrote:
> 
>     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.
> 
>     David-Sarah Hopwood  ?  http://davidsarah.livejournal.com
> 
> 
> This may be  my ignorance, but I assumed the purpose of renegotiation
> was a fresh exchange of authentication and/or keying material.

Forget 'purpose', that's largely an application layer thing.

The TLS spec defines mechanisms: what MAY, SHOULD, and MUST happen.

Whether it's freshening keys, changing auth, etc. what others do with a
basic feature like renegotiation is up to them.

> The
> renego for instance can (infamously) require client-auth while the
> original did not. Or switch ciphersuites.

My belief is that that was one of the original intended purposes for
renegotiation: allow Netscape clients and servers to handle
per-directory client certificate and crypto configuration.

> The abbreviated handshake cannot achieve any of this. It does not
> involve certs or ciphersuites.

Sure, why not? Why couldn't a client offer resumption of a previously
client-authed session in response to a server-initiated renegotiation?

> I thought historically its purpose
> versus: the full handshake exchanges the master-secret in the context of
> a particular TCP-socket.

No, that's the mechanism.

> If the Client wants to use that same master
> secret in the context of a new ( or a million parallel) TCP sockets,
> then use the abbreviated handshake (avoiding the PKI heavy lifting).

Saving computation is probably the most common use of session resumption.

> The
> same thing applies if the binding underneath is not TCP.  The
> abbreviated handshake really has only one purpose in life -- it binds
> the new SSL session (say the new TCP socket) to the old one,

Sort of. If the resumption is successful, it ends up being just one
session which is instantiated on multiple connections.

I haven't heard anyone thinking of it so much in terms of "binding" two
TCP connections. Since you can't usually guarantee that session
resumption will be successful, application protocols usually don't give
it any semantic meaning.

> by each
> party proving knowledge of the original master secret. (exactly what the
> renegotiated handshake chose not to do).

A renegotiation handshake can resume a session if client and server
agree on it.

> Examples  would  be a messengering client that negotiates a full
> handshake with a switch and then each time a new socket is opened for a
> new message uses the abbreviated handshake. Or a page with many many SSL
> protected objects that are independently retrieved.  So in this context
> a "renegotiated abbreviated handshake" seems strange.

It's not clear what the use case is for doing session resumption on a
renegotiation.

But it really just falls naturally out of the basic design of TLS. The
spec doesn't have to call it out as a special case.

> But regardless even if there is something in existence called a
> "renegotiated abbreviated handshake", I think the distinction between
> 'abbreviated handshakes without renegoitation' which are very very
> widely used should not be confused with 'renegotiated handshakes of any
> kind'.

Nowhere in the draft does it talk about "abbreviated handshakes".
Whether or not a handshake is "abbreviated" has absolutely nothing to do
with whether or not it is an initial or a renegotiation handshake.

You could just as easily single out some other protocol feature, say
Diffie-Hellman key exchange, and say there's an under-appreciated
distinction between initial DH handshakes and every other kind of handshake.

> It would be very helpful if the draft made this point.

The bug and the fix are about renegotiation and have absolutely nothing
to do with session resumption. Nevertheless, we already reiterate this
point a couple of times in the draft.

http://www.ietf.org/id/draft-ietf-tls-renegotiation-02.txt:

"The above rules apply even when TLS session resumption is used."

"... with every ClientHello, including ClientHellos where session
resumption is being offered."

- Marsh