Re: [TLS] Data volume limits

Martin Thomson <martin.thomson@gmail.com> Wed, 16 December 2015 02:40 UTC

Return-Path: <martin.thomson@gmail.com>
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 60A341A1AE8 for <tls@ietfa.amsl.com>; Tue, 15 Dec 2015 18:40:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RfHza7-yl7Rk for <tls@ietfa.amsl.com>; Tue, 15 Dec 2015 18:40:42 -0800 (PST)
Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D2E81A1AD9 for <tls@ietf.org>; Tue, 15 Dec 2015 18:40:42 -0800 (PST)
Received: by mail-ig0-x229.google.com with SMTP id to4so45990119igc.0 for <tls@ietf.org>; Tue, 15 Dec 2015 18:40:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=y7NSi4PlR8fVJiWQSry/a1/MC/tynG18M0NmZ/6hm80=; b=bBL+yIKYuJefQAvO33bBAiLCRllRV8OUujE0g5HC1U1uQb1VmsL9VQfLQl82Gm/ICt 1PLcJzEOe8RsZo257zdgt307wnhc8x1zv65reaL9WS+U1IaTBQQDjGRJRx3Cd/MHw0iQ ehLixhIl8qaEW8XlGs70ze05C2EHVQwjz3fr2kMfAb89RvEPLqGZriXE0q+tEe7Nfqaj 7ticufZPVDQQ5YyanrqVBOGi4TASSwDuwkYJNOhWdEvn7xntLncWwDGoh5Yo/QEJ/FmE dY4Uv+T9KGFXnt4KDDuIii74V/cbpfxZmXcatoZvMuB1lGPoOtTGZ+UiavA7HeX9ZNiE C7WA==
MIME-Version: 1.0
X-Received: by 10.50.6.104 with SMTP id z8mr7928908igz.58.1450233641536; Tue, 15 Dec 2015 18:40:41 -0800 (PST)
Received: by 10.36.149.130 with HTTP; Tue, 15 Dec 2015 18:40:41 -0800 (PST)
In-Reply-To: <CABcZeBNR76DqPo0Mukf5L2G-WBSC+RCZKhVGqBZq=tJYfEHLUg@mail.gmail.com>
References: <CABcZeBNR76DqPo0Mukf5L2G-WBSC+RCZKhVGqBZq=tJYfEHLUg@mail.gmail.com>
Date: Wed, 16 Dec 2015 13:40:41 +1100
Message-ID: <CABkgnnU67_rsVEWKg_ckaYXcZhiXNEgku4ntaZTF3nTYSMZGsg@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Content-Type: text/plain; charset=UTF-8
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/ZdT1LPvNQMJ7IiyzfCIYPvPgda8>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Data volume limits
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: <https://mailarchive.ietf.org/arch/browse/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, 16 Dec 2015 02:40:43 -0000

On 16 December 2015 at 08:14, Eric Rescorla <ekr@rtfm.com> wrote:
>
> I wanted to get people's opinions on whether that's actually what we want
> or whether we should (as is my instinct) allow people to use ChaCha
> for longer periods.


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

If 2^36 is the number, then I can see that being reached in some
applications.  That means that we need the rekey feature to exist.  If
we are going to have that feature, then we need to make sure that it
works.  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.

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.