Re: [TLS] Data limit for GCM under a given key.

Eric Rescorla <ekr@rtfm.com> Sat, 07 November 2015 03:54 UTC

Return-Path: <ekr@rtfm.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 A63691ACEE5 for <tls@ietfa.amsl.com>; Fri, 6 Nov 2015 19:54:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level:
X-Spam-Status: No, score=-1.277 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] autolearn=no
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 0NrRCsboZVpP for <tls@ietfa.amsl.com>; Fri, 6 Nov 2015 19:54:43 -0800 (PST)
Received: from mail-yk0-x22d.google.com (mail-yk0-x22d.google.com [IPv6:2607:f8b0:4002:c07::22d]) (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 4ED971ACEE6 for <tls@ietf.org>; Fri, 6 Nov 2015 19:54:42 -0800 (PST)
Received: by ykba4 with SMTP id a4so204613264ykb.3 for <tls@ietf.org>; Fri, 06 Nov 2015 19:54:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm_com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=msJvbzqXhdtLRJf9GnOI9aTxE5por2PiJPYb8ZbaYb0=; b=Hw/JFqXQnZl3ZauX6iOxsO0VG4FrXQELQIpKImPH3ozwF3sA3KcBgn10fKcjwRyWaZ rzw5qvqTNAsX2fHzRKjk6+ydatoNADnVZMHlgfh8E/iEKh2cQurhXEiHh5ellDEizm5/ RWWjks4Hm4M0zNgUVyuzElW0DWZLpKtawvAttiURSk5HM9vHB/WtWy140sNEBw4eAP8B TZbo//RRr1sy0zorrS4XC35cUBN+gWWeyylYd34AzSGqD1Cs61j49mhW0mzjecYdJBeZ yE9KWvFa2PheJ4XRhJ9pWsnVjCK38WshfvVs5o5GblQidJ9LCyG/LJ3LN2VIAFHzZDfT uaPg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=msJvbzqXhdtLRJf9GnOI9aTxE5por2PiJPYb8ZbaYb0=; b=KxDq0H6xQh1kpp2fWidga6iqcukYsHz1tTCVTwzZuFKxA8H4b/4Wk8i3FScZpSTtG8 TYIaohq3z/HKlLE8N4KvV2FAeyXcExz2og53JbEFNGVtiaCRbMlcz+K4gqa0Xi7MYOqX bBuIr0PVgTC8INT0IC6c5rvO5nc/jIHwr94kW09ocLDbHYUUObk0Vvgi22ygRAJGeKr7 EgmQYsAsgmSkOlnq30v9H46f2BLqykG8I9PKkrwhL0fwq/g9xCxGtc6m9HKBzhfjHtQa bauLKxRj6f/UZ6I2p2WdMhgWpBT1oP9A5GZNO+iyy8nXd8wj6oSP5xeOw9SoBofKFRQf NMBQ==
X-Gm-Message-State: ALoCoQk4TmtkRE1E5EWUnXC4TZYAkg21WhFTj498QlK16ImWik/CezMrQbZBYYywxsIs72mv8COi
X-Received: by 10.13.236.10 with SMTP id v10mr16181051ywe.231.1446868481627; Fri, 06 Nov 2015 19:54:41 -0800 (PST)
MIME-Version: 1.0
Received: by 10.13.221.203 with HTTP; Fri, 6 Nov 2015 19:54:02 -0800 (PST)
In-Reply-To: <201511062139.11139.davemgarrett@gmail.com>
References: <CABcZeBODjk8rapgbNTST8bmFFVzKqB4tJyrvje-CTgk1=gfqFw@mail.gmail.com> <CAHOTMV++hODJgstmROMv6BPUveDQgH=+KoN8UKCecRxtQQ+N9g@mail.gmail.com> <CABcZeBN749=rdOD3fsqwV3hj1X538G_-hbh2QvSmbMj6qWwOvA@mail.gmail.com> <201511062139.11139.davemgarrett@gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Fri, 06 Nov 2015 19:54:02 -0800
Message-ID: <CABcZeBO-G_De91e-oaRsqiR+01HbGMW_Eh27-FyjGqXnCFEzpw@mail.gmail.com>
To: Dave Garrett <davemgarrett@gmail.com>
Content-Type: multipart/alternative; boundary="94eb2c0889dce287b70523eb51af"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/dg9FSthVCGh09CGqWmDbYFt5gZg>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Data limit for GCM under a given key.
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: Sat, 07 Nov 2015 03:54:44 -0000

On Fri, Nov 6, 2015 at 6:39 PM, Dave Garrett <davemgarrett@gmail.com> wrote:

> On Friday, November 06, 2015 08:13:44 pm Eric Rescorla wrote:
> > Update: we discussed this extensively in Yokohama and based on Watson's
> > feedback and offline comments from David McGrew, the consensus was that
> we
> > needed to add some sort of rekeying mechanism to support long-lived
> flows.
> > Expect a PR on this next week.
> >
> > Note: We'll still need guidance to implementations on when to re-key, but
> > we don't expect to have a hard protocol limit.
>
> If re-keying is back up for discussion, let me restate my request for it
> to be routine, rather than only an niche-case feature. Any re-key schedule
> should be considered valid, but the spec should set a "SHOULD"-level
> requirement that the minimum be once every N hours or M terabytes,
> whichever comes first (where N & M are some bike-shedable numbers with some
> expectation of randomization in values for each period).


As I said above, I agree that the specification should provide some
guidance on how often you should re-key for a given cipher based on the
number of records/cipher blocks (whatever is more convenient for analysis).
This guidance should be derived from the kind of analysis Watson and Dave
McGrew have done for these algorithms, and, as Watson's analysis suggests,
is likely to be algorithm specific.

I don't believe time-based guidance is useful here, given that it's highly
situation specific rather than derived from reasoning about the properties
of the cipher.

-Ekr