Re: [TLS] Proposed text for removing renegotiation

Geoffrey Keating <geoffk@geoffk.org> Wed, 28 May 2014 22:25 UTC

Return-Path: <geoffk@geoffk.org>
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 C39351A06E8 for <tls@ietfa.amsl.com>; Wed, 28 May 2014 15:25:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-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 mDGUZEF7Ge8T for <tls@ietfa.amsl.com>; Wed, 28 May 2014 15:25:06 -0700 (PDT)
Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [216.129.105.14]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 731951A04B6 for <tls@ietf.org>; Wed, 28 May 2014 15:25:06 -0700 (PDT)
Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id A388533D002; Wed, 28 May 2014 22:25:02 +0000 (UTC)
Sender: geoffk@localhost.localdomain
To: Martin Thomson <martin.thomson@gmail.com>
References: <CABkgnnXaLKmxXL01hQEdxHSNGt3nZQQNBLDD5H2LqBzTo3vK4g@mail.gmail.com> <CAFewVt5GCmH8wSdUYLy_Q9RNEtAggzG3_k-9E8ME-nP9jZNX3Q@mail.gmail.com> <CABkgnnW0YAhsbMoN0JSdWWpxt9TsOWpvq3c67cw8_eyt4mprbA@mail.gmail.com>
From: Geoffrey Keating <geoffk@geoffk.org>
Date: 28 May 2014 15:25:02 -0700
In-Reply-To: <CABkgnnW0YAhsbMoN0JSdWWpxt9TsOWpvq3c67cw8_eyt4mprbA@mail.gmail.com>
Message-ID: <m2vbspv8w1.fsf@localhost.localdomain>
Lines: 38
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/EHmCXQekykm8_d5B_Oe0st1lcbo
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:25:09 -0000

Martin Thomson <martin.thomson@gmail.com> writes:

> On 27 May 2014 22:47, Brian Smith <brian@briansmith.org> 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.

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.

For sequence numbers, rollover also should (indeed must) be handled by
DTLS.  There are many possibilities, but the easiest is that if we're
removing renegotiation, so the cipher state can change at most once,
so in DTLS we can remove the epoch counter and make the sequence
number 64-bit, and say that if the 64-bit counter is exceeded (will
probably never happen) it is an error and the connection should close.

> 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.

This definitely seems like a case where you want to close the
connection and open a new one, directed by the application.