Re: [TLS] Proposed text for removing renegotiation

Martin Thomson <martin.thomson@gmail.com> Wed, 28 May 2014 22:45 UTC

Return-Path: <martin.thomson@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 2973B1A0721 for <tls@ietfa.amsl.com>; Wed, 28 May 2014 15:45:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, 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 n-pXZFu5Vkjo for <tls@ietfa.amsl.com>; Wed, 28 May 2014 15:45:24 -0700 (PDT)
Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C16D71A071D for <tls@ietf.org>; Wed, 28 May 2014 15:45:23 -0700 (PDT)
Received: by mail-wg0-f50.google.com with SMTP id x12so11821652wgg.33 for <tls@ietf.org>; Wed, 28 May 2014 15:45:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=YUOZQL9eCnvA/Py01+UgEL/O1Np7kh3KogpMXvAe0lM=; b=HfrH8Qz30QjDkN1TFgrrEXUyF7DjNl0Azq1nKTDeOxiYDq+LE9YJxQSsc9nBaTyFSw qSAAViveEzzqLQJJMRSk32jNyAF71rdccNPxdj2Bl7mPfE+FzFl6PzrFfIALpFurTxZ+ Cwzho022Gnc3qXj5/tLIioOP/cF/0zS3ADkJubjP8cQ67tveHkpoulk3IzFbgoBPJKLH y/Kv0YDUR+iBR/6T2D/gLXn0NEWmjPR09Qc1jOo44tciR2UPRpIJRohthSvXC9ZZH9d8 6Qlelumwy83+yR5Ct589h8Fz8L6OItEpZem2kQQdCyR58zp/pyfnPJoPYx6kqwh62/6x nw4A==
MIME-Version: 1.0
X-Received: by 10.194.133.1 with SMTP id oy1mr3787071wjb.87.1401317119018; Wed, 28 May 2014 15:45:19 -0700 (PDT)
Received: by 10.194.235.163 with HTTP; Wed, 28 May 2014 15:45:18 -0700 (PDT)
In-Reply-To: <m2vbspv8w1.fsf@localhost.localdomain>
References: <CABkgnnXaLKmxXL01hQEdxHSNGt3nZQQNBLDD5H2LqBzTo3vK4g@mail.gmail.com> <CAFewVt5GCmH8wSdUYLy_Q9RNEtAggzG3_k-9E8ME-nP9jZNX3Q@mail.gmail.com> <CABkgnnW0YAhsbMoN0JSdWWpxt9TsOWpvq3c67cw8_eyt4mprbA@mail.gmail.com> <m2vbspv8w1.fsf@localhost.localdomain>
Date: Wed, 28 May 2014 15:45:18 -0700
Message-ID: <CABkgnnWfM8eDALtGmpHBeHScy21fzTqv8+C0ajnDhAO=OBziZg@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Geoffrey Keating <geoffk@geoffk.org>
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/_scw3Dm4Aly8R0x54iNC5J_KsB8
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Proposed text for removing 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: Wed, 28 May 2014 22:45:25 -0000

On 28 May 2014 15:25, Geoffrey Keating <geoffk@geoffk.org> wrote:
> I think this should be handled by TLS, not by having the application
> request rekeying or renegotiation.  If TLS handles it, I don't see why
> there's a need for a special 'renegotiate' or 'change key' message; it
> can quietly change the key when the appropriate limit is hit.

I wasn't proposing that the application be in control of when rekeying
occurs.  (Yes, if an app needs an explicit break in continuity, then
opening a new connection is a perfectly reasonable way to achieve that
goal.)

Yes, you could just roll on through, identify a point where rekeying
is necessary and automatically do it.  That's even more aggressively
spartan than what I've proposed.

A message enables more than just necessary rekeying.  It also allows
for read and write states to be kept in sync.

It also means that you don't have to go to great lengths to contrive a
rekeying scenario in your testing.  I certainly don't want rekeying to
be rare enough that it breaks the first time that it ever actually
happens.  That's a surefire plan for backup generator syndrome.