Re: [TLS] Data volume limits

Brian Smith <> Wed, 16 December 2015 03:01 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 60E041A1B91 for <>; Tue, 15 Dec 2015 19:01:35 -0800 (PST)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1cJ0H3DLsxw1 for <>; Tue, 15 Dec 2015 19:01:34 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EE9C01A1B89 for <>; Tue, 15 Dec 2015 19:01:33 -0800 (PST)
Received: by with SMTP id i186so17433625oia.2 for <>; Tue, 15 Dec 2015 19:01:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Tzqw2Wvk4CPE8/xEcCxVHo+Ch9g2X6XxOK5G3+1ahPw=; b=y3qa7fyhgzJSjurB521dVdKi8BhhEg+IBAPw1b3fLk5kARUSc8/LmFm5Nk7RolszrS Y/CcFLlaAcg0nSy12mOEUQi5JvrCPB7iVLmHtl/PnfY+L2B1CiS6ezikuWexpZYZLf5M CC7gIwFwAPqZgfORlB/SNUv3er5rHNzPhJeinARSsatIg//MdhgEa5oLrqkAQYStaXgp XVCmpwO4uyh1oJxNlISEgOWCZ93RqT1DPWHTkOheqSZzv3V9gtOai5XQKLtJHMuq3Af+ pFaUDMF6ZG9n9tOHfm2tm7/+117pI4n75Q6w5Rz8c5K9f0QZ2fapDDwto3AjRotwpxKh CssA==
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=Tzqw2Wvk4CPE8/xEcCxVHo+Ch9g2X6XxOK5G3+1ahPw=; b=l1k/z6lx23r0CPYKHZrMMFYgfV5neA2p5tzEj1J8Fkg1Zvs+69BrcrJwulBjRdUX/W rHd8etIi45L5ncc8T34jAPXaHeV40j9Xo3OXtsxkIHI1bBz9uBfoiOj5P+nNSAkPDhC4 sznPkCuCZ45nwl+pyE1Q11jzrw4xidnWIzb2bF5S0KvcPgX2itBpg/n4fjWyF3vcQgO1 o4RHfrdkbiIYTyeicjfSumkUg2D2sXIZv7/WdMSL8AoaWNw7KcG2fSW3LMFkh0/dMyDf 1dhJp2DcVZeuj/F5jXPvA/j4QwV6inoX3n1ZckdxARPINkAepj/gfEvINoWoUgYD5F/D 30LA==
X-Gm-Message-State: ALoCoQnVmguVNVklE9o0OG9pEKsWlP+UXlFC0SSFGpPCGROh6U90AdQ+K7Q4D5EcMSgIWwiCF8TB1nqbcXXwO+TbmUFmhq+dYQ==
MIME-Version: 1.0
X-Received: by with SMTP id j186mr31361516oia.70.1450234893350; Tue, 15 Dec 2015 19:01:33 -0800 (PST)
Received: by with HTTP; Tue, 15 Dec 2015 19:01:33 -0800 (PST)
In-Reply-To: <>
References: <> <>
Date: Tue, 15 Dec 2015 17:01:33 -1000
Message-ID: <>
From: Brian Smith <>
To: Martin Thomson <>
Content-Type: multipart/alternative; boundary=001a113cd33ca8d48b0526fb1fd7
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] Data volume limits
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, 16 Dec 2015 03:01:35 -0000

Martin Thomson <> wrote:

> Whatever the actual limits are, I think that implementatios should be
> encouraged to rekey more strongly.


> And suggesting a stupidly high limit (e.g., ChaCha being
> greater than 2^96) leaves people thinking that they can skip
> implementation and testing of the rekey facility; or it just goes
> unused.  If it's not in use, then we'll have a good chance of creating
> a protocol feature we can't rely on if it really is needed.

I think this is exactly why the limit matters. If we are not in danger of
reaching the limit, then we don't need the rekeying mechanism and it should
be removed. The rekeying mechanism adds considerable complexity and that
complexity needs to be justified.

Alternatively, we'd need a new justification for the rekeying mechanism.
The new justification would affect the design of the rekeying mechanism.
For example, if the purpose of the rekeying mechanism is to get similar
effects to, say, the Axolotl ratchet, then we should ensure that the
rekeying mechanism actually has similar properties to Axolotl.

In light of that, the actual limits don't matter that much to me.  As
> David McGrew suggested, set a limit at 2^32 and avoid having to think
> too hard about how close to the failure point you might be.

First, let's figure out why TLS 1.3 needs a rekeying mechanism, if it does.
Then we can figure out how frequently we should suggest rekeying occur
based on sound reasoning.