Re: [TLS] Abbreviated Handshake != Renegotiated Handshake

[Michael D'Errico <[e-mail]>]

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

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