Re: [TLS] CCS and key reset and renegotiation

[Yoav Nir <[e-mail]>]

On Jun 5, 2014, at 8:43 PM, Viktor Dukhovni <[e-mail]> wrote:

> On Thu, Jun 05, 2014 at 08:23:46PM +0300, Yoav Nir wrote:
> 
>>> I don't recall whether this idea got dropped, or whether
>>> STOPTLS might yet happen in TLS 1.3.  Anyone care to bring me up
>>> to speed?
>> 
>> Sure. 
> 
> Thanks.
> 
>> StopTLS would need some mechanism to prevent a Dispensa/Ray/Rex
>> prefix injection attack.
> 
> Would it suffice to ban application-data messages after STOPTLS
> before a new handshake completes, and to require a subsequent
> handshake to be a resumption of the previous session (or a new
> session handshake in cleartext, but channel-bound to the previous
> session).

The Ray/Dispensa/Rex attack would be a MitM starting a TLS connection, sending to the server “GET /form.html?Button=Shutdown HTTP/1.0\nx-fake-header: “ and then sending a StopTLS and forwarding the client’s real ClientHello. The server would see this:

GET /form.html?Button=Shutdown HTTP/1.0
x-fake-header: GET /form.html?Button=Status HTTP/1.1
Cookie: authorization=wxvr7Z7hL8GXSQLqaIU6Cg==

And the client’s cookie would authorize the attacker’s request and the device would shut down. Yes, this was a real application, and yes, the attack worked.

As you say, binding the new handshake to the old handshake should suffice, whether it’s done through the channel binding or through the resumption cache. On a more philosophical level we might want to consider whether providing the application with a single, steady stream regardless of rekeying/renegotiation/new state is the right thing. In other words, it’s not clear to me that these events should not be reflected to the application so that application context does not flow from one TLS context to another.

> 
> The purpose of STOPTLS would not be a downgrade to cleartext data
> tranfer, but rather a transition from one key-set to another via
> a cleartext handshake that can happen with minimal crypto-state
> transfer (saved session object or some opaque shared secret
> sufficient).
> 
>> It's not currently a part of any plan for any version of TLS.
> 
> If it does come back, I can put it to good use.
> 
> -- 
> 	Viktor.