Re: [TLS] Proposed text for removing renegotiation

Brian Smith <> Wed, 28 May 2014 20:47 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 56B251A0227 for <>; Wed, 28 May 2014 13:47:46 -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 DYxvWkVlSHjq for <>; Wed, 28 May 2014 13:47:45 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E854F1A020B for <>; Wed, 28 May 2014 13:47:44 -0700 (PDT)
Received: by with SMTP id 63so19626951qgz.16 for <>; Wed, 28 May 2014 13:47:40 -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=GseFhq3iy8iK0NFkqy4urL0Hnoof9pkBfKi9q2LAMI0=; b=Br3tjh5kCXU5zh6U6vg2sQ5Rfuv6tK8ynVRtQCtB50hC2SceHMMPYlnl9BKOEbztyc 88tTzYacrbsoYnGBoIvdl2NfQD6LdkoH5+JREk74Q5gBtSg/oOuX1AEzyTEMKfqnzwVB yi02pJ8ReKVmDunqnG2S9R4NTa0no97mw6z7yRvXZq2+JdBCj1aktjuxQFq2K4iJxBEl kBMjiARC5dp6ABdxiLwsQEcbTUhQ/ZafQO331ddbzOFYIc0NrO+LfkajcGHtb9o4UEpa Wk3Pc8aWx4bYjEDMWoJUvXrqbg4hjxWebBqVS6RKk41xtSzq8rLLfm+EP4effg/VBEqI jUFw==
X-Gm-Message-State: ALoCoQlzg29FAWRud+TIVTOrR1bjaUG6FeGDrvnx4kzAgWVriK2PPu5vAWpDlAa4oSIpIem8cMh8
MIME-Version: 1.0
X-Received: by with SMTP id 3mr3001350qgy.71.1401310060641; Wed, 28 May 2014 13:47:40 -0700 (PDT)
Received: by with HTTP; Wed, 28 May 2014 13:47:40 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <>
Date: Wed, 28 May 2014 13:47:40 -0700
Message-ID: <>
From: Brian Smith <>
To: "Salz, Rich" <>
Content-Type: multipart/alternative; boundary="001a113a34e462932904fa7bec96"
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 20:47:46 -0000

On Wed, May 28, 2014 at 1:05 PM, Salz, Rich <> wrote:

> Ø  The advantage with this is that only the applications that need to
> deal with this problem are impacted by it.
> Strongly disagree.  This requires applications to know way to much about
> the TLS layer:  what cipher is being used, how SSL is packing things into
> records, and how often a cipher needs to be “reset” and what that entails.

The application would only have to be aware that the connection may at some
point become unusable because the TLS implementation did something like
simulating a RST when some crypto limit is reached. Applications that are
exchanging more than 2^32 records per connection already have to cope
somehow with these long-lived connections being reset below the TLS layer.

And/or such applications could choose to use cipher suites that aren't
limited to 2^32 records. I have just re-read SP-800-38D section 8.3 which
sets the limit on the number of invocations of AES-GCM with a given key.
SP-800-38D doesn't actually limit AES-GCM to 2^32 invocations as long as
the deterministic construction is used and as long as the invocation field
is larger than 32 bits, if I am reading it correctly. The birthday attack
issue on the 64-bit invocation field used in AES-GCM cipher suites could be
mitigated by tightening the requirements for AES-GCM in TLS 1.3 and/or by
defining new AES-GCM cipher suites that are required to have IVs generated
using the deterministic construction with large(r) invocation fields.

And/or, implementations that send/receive large amounts of data on a single
connection could tune their TLS stacks so that they will never (or almost
never) get close to whatever limit the cipher suite has.

And/or the TLS implementation could optionally provide some kind of simple
notification mechanism to tell the application that the connection will
become unusable "soon," so that an application could start a new
connection/session before the old one stops working, to minimize the
performance impact.