Re: [TLS] Proposed text for removing renegotiation

Brian Smith <> Wed, 28 May 2014 19:59 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 9404F1A068F for <>; Wed, 28 May 2014 12:59:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tZBV_Epwx2EE for <>; Wed, 28 May 2014 12:59:36 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7AA801A068B for <>; Wed, 28 May 2014 12:59:36 -0700 (PDT)
Received: by with SMTP id j5so19485700qga.14 for <>; Wed, 28 May 2014 12:59:32 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=GEDcZzAAn0pDwlGhzBisSwz9g8Abdj7TD4lZ3Pk8lFo=; b=mjT5F74+Gg9lMyreQj/LRTcW15l2ALlAJ82CrDheKOyLv9kwIFtsPKyM+cyujy9MTM 4bV19hGHUTzyDlGyiNKGb6KmArZEcPSCwPheped3cUOIIs4/69aYSzwCwUWS5htfGOq+ gcwAOCcJQUjeAMm1VHjQi0sVF2YF1/2nNzX6QLEwmEQEjowvdt9TxQH14k3a36fjQgGd gTK5bqVv0S5mQ9MU2+eOYnpCGg8SEf37GgxZWaJ50Kl1A3/d4aHbjjlL+5xb8KUpkYZ5 /KvbMYkNkyO6k66nNgCXi1i76EMPeQ4liFYyPHB9cJBq9JeibCcOkueRydltWgUUgwF/ Mrbg==
X-Gm-Message-State: ALoCoQli/5GVfFJ1GPcyD19YI/m07FMrHusXWer0yu54xGoYzeeQ3IfOBce0ciZHOOkQeaV+9mrM
MIME-Version: 1.0
X-Received: by with SMTP id e4mr3128867qcj.16.1401307172435; Wed, 28 May 2014 12:59:32 -0700 (PDT)
Received: by with HTTP; Wed, 28 May 2014 12:59:32 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
Date: Wed, 28 May 2014 12:59:32 -0700
Message-ID: <>
From: Brian Smith <>
To: Martin Thomson <>
Content-Type: multipart/alternative; boundary="001a1133bb583c0e4704fa7b40ff"
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 19:59:37 -0000

On Wed, May 28, 2014 at 9:38 AM, Martin Thomson <>wrote:

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

Understood. However, as I implied in my other responses today, I don't
think TLS is the place to support that use case. It is enough for the TLS
implementation to be only responsible for ensuring that we don't use a key
beyond safe limits for its usage. How the application recovers from that
limit being reached can be delegated to the application. The advantage with
this is that only the applications that need to deal with this problem are
impacted by it.

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

I understand the idea is that both sides could throw away the old master
secret right away and then nobody would be able to decrypt the traffic
protected by that old master secret. However, the "master secret
advancement" mechanism you proposed is calculated using only the old master
secret plus public nonces, which raises some risk of related-key attacks.
As Martin Rex was saying, the advantage of TLS-1.2-style renegotiation is
that the new master secret is clearly (could be made to be) completely
unrelated to the the previous master secret so that related key attacks
aren't (could be made to not be) an issue.

Thus, while a simpler rekeying mechanism definitely makes the protocol
simpler, we'd be trading a useful cryptographic property for that
simplicity. And, most implementations that would support it would actually
become more complicated by having to support both TLS < 1.3 renegotiation
AND TLS 1.3 rekeying.

Consequently, I still think we should keep trying to get rid of
renegotiation without adding anything new in TLS to replace it.