Re: [TLS] Proposed text for removing renegotiation

Martin Thomson <> Wed, 28 May 2014 16:38 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 791601A0164 for <>; Wed, 28 May 2014 09:38:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zOXDbNbdMyyW for <>; Wed, 28 May 2014 09:38:54 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C588C1A0450 for <>; Wed, 28 May 2014 09:38:53 -0700 (PDT)
Received: by with SMTP id cc10so4004161wib.16 for <>; Wed, 28 May 2014 09:38:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Jmayhroh/CPr0i1Ird7nmUcox7nUkwQLNlItBOiA7+A=; b=vbIadrdJJ7bMLJLr/nounjuFFvGN3XwsRZpA7JjhlyzdUBfk6Z9Ah4G3P39v0JeuOt 9hqsU5g8yYBu/4in/rFcVAB2Ehtod0d8rT7CuorQTzqZ4eV0GwRo+40v6IfIXmwhLHRe vduK0ZOsZLla+mi9akUT4TOGnF74JHh/Lj5rki0A99c2ZDh/olCOM1QYyxjNfCshsqwM loxk0IcECQ6WHGpv38ylslUsOyAJtxyWwbNWLpIkiImVg+liyQToUbQi2j2eWP3ZSQue HovJDDA8ip/XuqGTtmJMBSMyZSAKd5w8zfYw0a6wwqksqwMTuaOfexyyN6sCLka6zL0Q faKA==
MIME-Version: 1.0
X-Received: by with SMTP id g19mr50844411wiv.44.1401295127275; Wed, 28 May 2014 09:38:47 -0700 (PDT)
Received: by with HTTP; Wed, 28 May 2014 09:38:47 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Wed, 28 May 2014 09:38:47 -0700
Message-ID: <>
From: Martin Thomson <>
To: Brian Smith <>
Content-Type: text/plain; charset="UTF-8"
Cc: "" <>
Subject: Re: [TLS] Proposed text for removing renegotiation
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 28 May 2014 16:38:59 -0000

On 27 May 2014 22:47, Brian Smith <> wrote:
>> It's not possible to just remove renegotiation.
> Why not? What is the motivation for keeping any form of renegotiation, even
> rekeying? It isn't clear from the public mailing list discussions what is
> motivating the rekeying feature. (Perhaps I overlooked something; if so, a
> link to the past decision on this would be appreciated.)

That statement was merely referring to the fact that there are other
considerations that removing renegotiation exposes:

AES-GCM (for example) can't be used with the same key indefinitely.
2^32 records is the limit apparently.  We have reports of services
that use the same connection for up to months with high volumes of
traffic.  Over that period, the sequence number might roll over, even
if the keys are still good.  Rekeying allows for those uses.

It also provides a measure of forward security in that old keys can be
thrown away.  A break of a server only allows the attacker to gain the
plaintext of a connection back to the last rekeying event.

Then there's the use of renego for HTTP, but we've discussed that
already and the tentative plan is to push on HTTPbis to come up with a
solution that doesn't depend on TLS.  Failing that, or in the event
that we discover other users of spontaneous client authentication, we
will build something into TLS.  That will probably be something
lightweight that doesn't cause the sorts of issues Martin (R) doesn't
think are worth worrying about.

>> The current and pending states for both read and write
>> direction are integral parts of the spec.
>I don't think documenting/managing those states would be integral at all if we didn't need to support rekeying.

That's right.  That's a presentation consideration, as alluded to
above.  As much as possible, I tried to make them non-integral in my
proposed text.