Re: [TLS] Abbreviated Handshake != Renegotiated Handshake

[Ravi Ganesan <[e-mail]>]

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 <[e-mail]>wrote:

> At Sat, 19 Dec 2009 13:43:00 -0800,
> > 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 don't see any text in 5246 that seems to forbid this.
>
>
> > -  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.
>
> 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.
>
>
> > - 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!!!
>
> 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
>
>
>


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