Subject: [TLS] Abbreviated Handshake != Renegotiated Handshake

From: Ravi Ganesan <[email-masked]>
Date: Sat, 19 Dec 2009 09:13:14 -0800

>
>
> Ravi Ganesan wrote:
>
> > 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.
>
> 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. The renego for
instance can (infamously) require client-auth while the original did not. Or
switch ciphersuites.

The abbreviated handshake cannot achieve any of this. It does not involve
certs or ciphersuites.  I thought historically its purpose versus: the full
handshake exchanges the master-secret in the context of a particular
TCP-socket. 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). 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, by each party proving knowledge of the
original master secret. (exactly what the renegotiated handshake chose not
to do).

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.

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

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

---

From: Marsh Ray <[email-masked]>
Date: Sat, 19 Dec 2009 13:00:22 -0600

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

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

---

From: Ravi Ganesan <[email-masked]>
Date: Sat, 19 Dec 2009 13:43:00 -0800

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
[email-masked]
www.findravi.com

---

From: Michael D'Errico <[email-masked]>
Date: Sat, 19 Dec 2009 14:14:23 -0800

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

The server is under no obligation to resume a session offered by the
client.  If your server application requires a full handshake every 24
hours, then it should ignore the session ID and simply continue with a
full handshake.

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

I don't think these restrictions are necessary.  It is up to the
particular application to determine when resumption is allowed and
when it isn't.  The client can force a full handshake by not sending
a session ID, and the server can force a full handshake by ignoring
a session ID if the client sent one.

> iii) OK back to abbreviated handshakes. As part of my work with the 
> MashSSL Alliance (www.mashssl.org <http://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.

Renegotiation and session resumption are orthogonal.  You can resume a
session on an initial handshake or when renegotiating.  I'm not sure
your text is quite correct since you can be vulnerable to a man-in-the-
middle when resuming a session on an initial handshake (the server sees
it as a renegotiation).

Mike

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 19 Dec 2009 14:14:15 -0800

At Sat, 19 Dec 2009 13:43:00 -0800,
> maybe that is just my reading.

I don't see any text in 5246 that seems to forbid this. 

> plaintext to render continuing to use the same key material dangerous.

IMO, this is a bogus requirement:

1. Modern ciphers do not suffer from key exhaustion. You should be able
   to use the same key for effectively any plausible amount of ciphertext.
2. To the exten to which you *are* worried about key exhaustion (or
   something like CBC rollover), then merely re-deriving the keys from
   the original master secret is quite sufficient. There is no need
   to do a new public key exchange.

> is refreshing key material every 24 hours, and in fact it is not!!!

Either side has the option to decide to do a full handshake. If they
want that, then either the client should not offer resumption or the
server should not accept it. It's not clear to me why such a restriction
would need to be in TLS proper.

-Ekr

---

From: Ravi Ganesan <[email-masked]>
Date: Sat, 19 Dec 2009 15:07:26 -0800

I agree completely with the comments below, and those of Mike, that a smart
app completely aware of the doings of the ssl stack, can ensure the ssl
stack underneath it does not do something unexpected. One could by the same
token claim that a smart app aware of the doings of the ssl stack would not
have mixed up the before and after of the 'pizza order' in your exposition
of the original attack. I figured the goals were to save a not-so-smart app
from itself to extent possible.

Anyway, for my taste, if one side says I want to renegotiate, and the other
responds with a message that results in NON-renegotiation it makes no sense
to allow it within TLS itself.  I have not seen any use case where this
peculiar behaviour should be tolerated. And if such a use case does not
exist, it might be wise to be parsimonious and disallow it.

On Sat, Dec 19, 2009 at 2:14 PM, Eric Rescorla <[email-masked]>wrote:

> In
> hours,
> every
> same
> it

-- 
Ravi Ganesan
[email-masked]
www.findravi.com

---

From: Michael D'Errico <[email-masked]>
Date: Sat, 19 Dec 2009 15:33:52 -0800

Ravi Ganesan wrote:
> I agree completely with the comments below, and those of Mike, that a 
> smart app completely aware of the doings of the ssl stack, can ensure 
> the ssl stack underneath it does not do something unexpected. One could 
> by the same token claim that a smart app aware of the doings of the ssl 
> stack would not have mixed up the before and after of the 'pizza order' 
> in your exposition of the original attack. I figured the goals were to 
> save a not-so-smart app from itself to extent possible.

Preventing session resumption is (or should be) easy for the server. Just
set a maximum session lifetime in your session cache.  If the client
attempts to resume a session older than that, the server won't find it in
the cache and will be forced into a full handshake.

> Anyway, for my taste, if one side says I want to renegotiate, and the 
> other responds with a message that results in NON-renegotiation it makes 
> no sense to allow it within TLS itself.  I have not seen any use case 
> where this peculiar behaviour should be tolerated. And if such a use 
> case does not exist, it might be wise to be parsimonious and disallow it.

You've confused renegotiation with resumption.  The peers DO renegotiate,
but they perform a full handshake if either side doesn't want to resume
a previous session.

Mike

---

From: Martin Rex <[email-masked]>
Date: Sun, 20 Dec 2009 00:34:41 +0100 (MET)

> exist, it might be wise to be parsimonious and disallow it.

Both sides can prevent a TLS session resume from happening during
renegotation, so there is absolutely no problem at the protocol level.

If the client does not want to resume a previous session during
renegotiation, then it sends an empty TLS session ID in ClientHello.

If the server does not want to resume a previous session during
renegotiation, then it simply ignores the TLS session ID proposed
in the ClientHello and performs a full TLS handshake.

The HelloRequest handshake message does not carry an indicators
why a server requests renegotiation, so a client can only guess.
The most commonly known usage in popular applications on
the internet seems the request for a client certificate after
having seen the clients request.

As EKR already mentioned, with old ciphers (short blocksize),
doing renegotiation only for rekeying would be most efficient
through TLS session resume, because it does not have PKI
overhead (and also no certificate path validation overhead),
only new encryption and MAC keys for both directions are
newly derived (existing master secret plus client.random and
server.random) and the 64-bit sequence numbers are reset.

-Martin

---

From: David-Sarah Hopwood <[email-masked]>
Date: Sun, 20 Dec 2009 00:29:15 +0000

Ravi Ganesan wrote:
> David-Sarah Hopwood wrote:
>> Ravi Ganesan wrote:
>>
> The abbreviated handshake cannot achieve any of this.

Yes it can; a renegotiation with an abbreviated handshake using the
same session ID as the previous handshake, has the effect of refreshing
keys.

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

As long as it does so in a way that doesn't add further confusion, yes.

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

---

From: Ravi Ganesan <[email-masked]>
Date: Sat, 19 Dec 2009 16:56:50 -0800

> having seen the clients request.

Sure, and in this case if the Client responds with a Client Hello with the
initial session ID then the server has to anyway respond with a full
handshake server-hello (else it cannot get client-auth).

My only point is that we are relying on app that requests a "renegotiate" of
its underlying SSL stack to differentiate between two cases: (i) where the
renegotiate with full handshake really happens and (ii) when a previous
session is resumed. If there is no need for case (ii) it seemed to me to be
better to not let this happen, and hope the app can tell the difference.

Sounds like everyone else thinks this is fine -- so be it.

Cheers,

Ravi

---

From: Martin Rex <[email-masked]>
Date: Mon, 21 Dec 2009 15:21:40 +0100 (MET)

> > widely used should not be confused with 'renegotiated handshakes of any

Ravi, your terminology is slightly confusing.  Renegotiation refers
to a TLS handshake that is performed under protection of an existing
TLS session, so the two things you could distinguish are:

  - renegotiation with a full handshake
  - renegotiation with an abbreviated handshake (aka session resume)

> Nowhere in the draft does it talk about "abbreviated handshakes".

That might be considered a defect, because it is the terminology
established by RFC-5246 7.3 Handshake Protocol Overview, Figure 2

http://tools.ietf.org/html/rfc5246#page-37

> with whether or not it is an initial or a renegotiation handshake.

Correct.

-Martin