Re: [TLS] Abbreviated Handshake != Renegotiated Handshake

[Ravi Ganesan <[e-mail]>]

Comments:

i) The term "abbreviated handshake"  (which appears only in the title of
figure of said handshake on Pg. 32 of RFC 5246, and in numerous references
on the web.  It seems to be used synonymously with  'session resumption'
(which appears many more times in the same RFC). I prefer abbreviated, as
one can open a million parallel connections with a master_secret that is
once exchanged, which the term 'resumption' does not quite convey.

ii) You say: "Why couldn't a client offer resumption of a previously
client-authed session in response to a server-initiated renegotiation?". In
re-reading RFC 5246 my take away is that this is implicitly forbidden, but
maybe that is just my reading. I feel it really MUST be forbidden.  As an
example:
-  imagine an application requirement to change key material every 24 hours,
because after that an attacker gathers up enough ciphertext or chosen
plaintext to render continuing to use the same key material dangerous.
- app developer instructs his (server) SSL stack to do 'renegotiation' every
24 hours.
- applications (server) SSl stack sends renegottation message'.
- In your scenario (client) stack at other end says "oh come on, not all
over again, lets just resume" and commences abbreviated handshake using same
master_secret.
- In your scenario the (server) SSL stack proceeds, and the app "thinks" it
is refreshing key material every 24 hours, and in fact it is not!!!
My recommendation would be to say a Client MUST NOT offer session resumption
in response to a renegotiation, and if it chooses to do so, the server MUST
NOT accept it.  It would be useful if any of those originally involved with
RFC 5246 can clarify intent of renegotiation and if any why there is indeed
some use case where one allows Client to respond with abbreviated handshake.
Like Marsh, I cannot think of any use case, and per my example above it
seems dangerous. If one agrees the draft to fix the renego-attack would be
great place to fix this too.

iii) OK back to abbreviated handshakes. As part of my work with the MashSSL
Alliance (www.mashssl.org) I end up explaining the abbreviated handshake
again and again and again, as it is a HUGE benefit of starting with SSL to
fix the problem we are trying to address. Here is what I have to report: Of
those who know enough about SSL to ask, *ALL* immediately confuse it with
"renegotiation" and ask about the impact of your attack (currently MashSSL
does not even have renegotiation!).  Now your draft has no obligation to
change its wording to help a different if related effort (though it would be
nice :-)). I am simply reporting back that almost everyone is mixed up on
'resumption' versus 'renegotiation'. And it would help a lot of people if
your reply to me  below, namely, "The bug and the fix are about
renegotiation and have absolutely nothing to do with session resumption."
made it into the draft.

iv) Finally, your choice of words on 'binding' captures what I was trying to
say; I just said it poorly.

Cheers,

Ravi

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


On Sat, Dec 19, 2009 at 11:00 AM, Marsh Ray <[e-mail]>wrote:

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