Re: [TLS] CCS and key reset and renegotiation

Yoav Nir <ynir.ietf@gmail.com> Thu, 05 June 2014 18:59 UTC

Return-Path: <ynir.ietf@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20D451A00FC for <tls@ietfa.amsl.com>; Thu, 5 Jun 2014 11:59:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ew0EjRfS5L8Y for <tls@ietfa.amsl.com>; Thu, 5 Jun 2014 11:59:28 -0700 (PDT)
Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CAF91A02CB for <tls@ietf.org>; Thu, 5 Jun 2014 11:59:24 -0700 (PDT)
Received: by mail-wg0-f52.google.com with SMTP id l18so1599738wgh.23 for <tls@ietf.org>; Thu, 05 Jun 2014 11:59:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:message-id:mime-version:subject:date:references :to:in-reply-to; bh=AVmb+VR2+O1vqUKhG2RPiV8a0Lu8xJ7UFckPhEx4kDE=; b=YYawFTnjObLCYsvRT7RKuZecmHq5vj97lXKv8XcBcnrw8bU/m0vXwlbCxKgF+tWVar f/IgOCyb9wGkNrmTH+4ZLkv0sZWwc+HAoqnVqG1v0eA4UcDHKr9oHR941DiDN8xEXSbb AnFeLtWucrsPTaz+jBGTV5Okq2/7M0I6xno+GwtEPbptiL/+z7czRrCLbrGnWrV/C4WD KlOPHcACgmT02cyGPT+Iq4VdXdCWh+jfbQcKpYpLub3HdQYXHPjzt4uNwVgoePPgLQIh FcszJsJioictgRQc1S1FXph8vzFuZgbF3OQ0Vn+i2T+nBGTPo6IUYkbFV+TDYwb65H5R Yxeg==
X-Received: by 10.180.211.146 with SMTP id nc18mr528241wic.53.1401994757459; Thu, 05 Jun 2014 11:59:17 -0700 (PDT)
Received: from [192.168.1.102] (bzq-84-109-50-18.red.bezeqint.net. [84.109.50.18]) by mx.google.com with ESMTPSA id na4sm55619112wic.21.2014.06.05.11.59.16 for <tls@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Jun 2014 11:59:16 -0700 (PDT)
From: Yoav Nir <ynir.ietf@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_08FFAD85-31FF-4B20-AE6F-FC33D37F61DF"
Message-Id: <3255D953-9F23-4F98-AA60-2C844B9E41A8@gmail.com>
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
Date: Thu, 5 Jun 2014 21:59:12 +0300
References: <2A0EFB9C05D0164E98F19BB0AF3708C7130F434981@USMBX1.msg.corp.akamai.com> <CACsn0c=O5Xp82JqsxXsik+4NEG5h-0HSJ-NM1zhywJVg_oX1Dg@mail.gmail.com> <20140605164241.GJ27883@mournblade.imrryr.org> <3211431A-4A22-487F-B23B-1794BCFFB009@gmail.com> <20140605174312.GL27883@mournblade.imrryr.org>
To: tls@ietf.org
In-Reply-To: <20140605174312.GL27883@mournblade.imrryr.org>
X-Mailer: Apple Mail (2.1878.2)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/sT0_7-V5bgiyY6EY9A7Lhj5ZF7A
Subject: Re: [TLS] CCS and key reset and renegotiation
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Jun 2014 18:59:30 -0000

On Jun 5, 2014, at 8:43 PM, Viktor Dukhovni <viktor1dane@dukhovni.org> 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.