Re: [TLS] CCS and key reset and renegotiation

Yoav Nir <ynir.ietf@gmail.com> Thu, 05 June 2014 17:24 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 290091A021A for <tls@ietfa.amsl.com>; Thu, 5 Jun 2014 10:24:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Level:
X-Spam-Status: No, score=-1.4 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, J_CHICKENPOX_21=0.6, SPF_PASS=-0.001] autolearn=no
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 33Vhf-HMAyhc for <tls@ietfa.amsl.com>; Thu, 5 Jun 2014 10:24:02 -0700 (PDT)
Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92FEA1A017F for <tls@ietf.org>; Thu, 5 Jun 2014 10:24:02 -0700 (PDT)
Received: by mail-we0-f170.google.com with SMTP id u57so1520580wes.29 for <tls@ietf.org>; Thu, 05 Jun 2014 10:23:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=/8Uy2Ez954XNVmMvdwv9RF9VDisoDSXOnWfrf0fxMYo=; b=mzwLCzcbjdL1Y2QlwiBPOM9NcIb1rUEmzkC8mBrQ6VIcI4amHsF+3EO29RX/pi0ZG8 zPuvLsuLZBjMYL7OxgF1J9PQUWV90oCf3ewD5ugdbd38Em78IoFGmMkToGwFB9cLyIiP FE3dMfSp6TtVD8X/c8ay4o8Z1RBBk1NwrKPqAhZ95brEyFz3otAAM257OqGD5xvolo3j c3oNbaoLr5vlkUDWTKiTQftTsYO2sKh7v6T+VPse5yjbGbEnNom5+dB0Q1Mxqh0Im5r8 tPKloOjRoXZqTs4aWbZt5eWLrZ/yPhoWNp6uCJEtz8TxaETJzTeB8gllG1x5tKfNVwFa yarw==
X-Received: by 10.180.13.113 with SMTP id g17mr17994722wic.48.1401989032954; Thu, 05 Jun 2014 10:23:52 -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 b19sm16632674wic.5.2014.06.05.10.23.51 for <tls@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Jun 2014 10:23:52 -0700 (PDT)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Yoav Nir <ynir.ietf@gmail.com>
In-Reply-To: <20140605164241.GJ27883@mournblade.imrryr.org>
Date: Thu, 5 Jun 2014 20:23:46 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <3211431A-4A22-487F-B23B-1794BCFFB009@gmail.com>
References: <2A0EFB9C05D0164E98F19BB0AF3708C7130F434981@USMBX1.msg.corp.akamai.com> <CACsn0c=O5Xp82JqsxXsik+4NEG5h-0HSJ-NM1zhywJVg_oX1Dg@mail.gmail.com> <20140605164241.GJ27883@mournblade.imrryr.org>
To: tls@ietf.org
X-Mailer: Apple Mail (2.1878.2)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ehbELPXw2YEcPpNEDxcnJkLMZhQ
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 17:24:04 -0000

On Jun 5, 2014, at 7:42 PM, Viktor Dukhovni <viktor1dane@dukhovni.org> wrote:

> On Thu, Jun 05, 2014 at 08:25:26AM -0700, Watson Ladd wrote:
> 
>>> I think it adds weight to my concern about using ChangeCipherSpec to do
>>> key reset.  I still prefer the trade-offs of having a ?slow the TLS but
>>> keep the TCP layer open? and starting over.  Much simpler to prove it?s
>>> correct.
>> 
>> What can change when that happens? Furthermore, rekeying is a matter of
>> getting more PRF output: how does that introduce security concerns.
> 
> Whether or not rekeying is easier to implement with a STOPTLS, or
> by switching directly from one keyset to another, without an
> intermediate transition to cleartext, a STOPTLS feature has additional
> upside.  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. 

StopTLS is just an idea I threw around ([1]) in response to some other idea that someone said in the room (no idea who and don’t remember what) in pretty much the last minute of the Interim meeting. I think it was a response to some other suggestions to get rid of renegotiation for rekeying, such as requiring everyone to start a new connection (StopTLS saves a round-trip), or various kinds of abbreviated handshake (StopTLS is simpler). 

StopTLS would need some mechanism to prevent a Dispensa/Ray/Rex prefix injection attack.

It’s not currently a part of any plan for any version of TLS.

Yoav

[1] http://www.ietf.org/jabber/logs/tls/2014-05-16.html  at time 19:40:04