Re: [TLS] Data limit for GCM under a given key.
Quynh Dang <quynh97@gmail.com> Sat, 07 November 2015 07:16 UTC
Return-Path: <quynh97@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 366DB1B2BAA for <tls@ietfa.amsl.com>; Fri, 6 Nov 2015 23:16:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Level:
X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-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 WWkJ8BlZ6HhD for <tls@ietfa.amsl.com>; Fri, 6 Nov 2015 23:16:29 -0800 (PST)
Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::235]) (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 591291B2BA9 for <tls@ietf.org>; Fri, 6 Nov 2015 23:16:29 -0800 (PST)
Received: by obctp1 with SMTP id tp1so108853897obc.2 for <tls@ietf.org>; Fri, 06 Nov 2015 23:16:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=i7oJqV/GQKC+2Pl5nSWFQmFW/a1lJKZjGaZPDSsB3Hk=; b=uRwDb1Q/V44slOicV3XgFgEgKLh8ZNx367rLFfOL+R2oF1lM/pDRyGUR4NSt1+GXRU xaUAH+W8nVRrFnyJtysLnZSchghMxvl7L3HDw+FDv8xaAkKCTKoqdmEnDY0YKBEfddyT wbvKplcEJuJC+B5WQYN96WWvbX7+d4isLKlqRhh6MB7wPM0kY955PE7XOH7ev36eBsqB FIEU1h13skFGF/pkj6x4CIkBnatASrNGXyWnkfPSGVotYUWrhK+V7nDXvezFpHVptB8p q5HUPnGkP97QfQuXrHjdPBmR1mJK4ctjn9r9B1doL8CVIDZAJ5VqR1i04CzftaMHzrcf TPXA==
X-Received: by 10.60.143.74 with SMTP id sc10mr10435625oeb.79.1446880588773; Fri, 06 Nov 2015 23:16:28 -0800 (PST)
MIME-Version: 1.0
Received: by 10.202.48.193 with HTTP; Fri, 6 Nov 2015 23:16:09 -0800 (PST)
In-Reply-To: <CABcZeBPTiVNk5EQU+tx9FdzbLTqDrf8+NmZqWu-1uHHtSiko=Q@mail.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> <5FA3B020-DDCC-4745-B969-9A54A98C9948@gmail.com> <CABcZeBPTiVNk5EQU+tx9FdzbLTqDrf8+NmZqWu-1uHHtSiko=Q@mail.gmail.com>
From: Quynh Dang <quynh97@gmail.com>
Date: Sat, 07 Nov 2015 16:16:09 +0900
Message-ID: <CAE3-qLQc3cK2eEUm+GCkwZ+jZdUVVCs6Jxcvkwkgr=sMZoaBVA@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>, Watson Ladd <watsonbladd@gmail.com>
Content-Type: multipart/alternative; boundary="047d7b33c67c86c0830523ee2361"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/mmPuFvPnrxrrWn-R-HWgbJn8BBE>
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 07:16:31 -0000
Hi Eric and Watson, On Sat, Nov 7, 2015 at 12:50 PM, Eric Rescorla <ekr@rtfm.com> wrote: > > > On Fri, Nov 6, 2015 at 7:46 PM, Yoav Nir <ynir.ietf@gmail.com> wrote: > >> >> > On 7 Nov 2015, at 11:39 AM, 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). >> >> N and M will be different depending on the algorithms, no? >> >> I think before we start with pull requests we should be certain of what >> the requirements are for this rekeying. >> > > These were discussed extensively both in the interim and at IETF. The > purpose of rekeying in this context is to deal with cryptographic > exhaustion, namely having more ciphertext under the same key than is safe > for a > given algorithm (where safe is defined by an analysis like the one Watson > has posted upthread). > You basically said here was that what I described was not safe. Show me how to break the following: I encrypt 2^64 plaintext blocks with 2^64 different IVs with AES (with the same key), then give you the 2^64 ciphertext blocks. Show me an attack that you can recover any of the plaintext blocks. All of the plaintext blocks can be the same block, they can be all different or some of them are repeated block(s) of other block(s). > > > >> Are we OK with just generating new keys from the same internal state (so >> the handshake message is pretty much only “rekey now”), > > > I believe this is what we agreed both in Seattle and in Prague. > > -Ekr > > > >> or >> Do we want freshness (usually in the form of new mutual nonces, or >> Do we want forward secrecy so another diffie-hellamn exchange? >> >> Yoav >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls I support rekeying often to avoid disaster to keep going on just in case there is something wrong with the key or IV as I stated before. Quynh.
- [TLS] Version in record MAC Eric Rescorla
- Re: [TLS] Version in record MAC Colm MacCárthaigh
- Re: [TLS] Version in record MAC David Benjamin
- Re: [TLS] Version in record MAC Martin Thomson
- Re: [TLS] Version in record MAC Eric Rescorla
- Re: [TLS] Version in record MAC Martin Thomson
- Re: [TLS] Version in record MAC Eric Rescorla
- Re: [TLS] Version in record MAC Martin Thomson
- Re: [TLS] Version in record MAC Russ Housley
- Re: [TLS] Version in record MAC Adam Langley
- Re: [TLS] Version in record MAC Eric Rescorla
- Re: [TLS] Version in record MAC David McGrew (mcgrew)
- Re: [TLS] Version in record MAC Eric Rescorla
- Re: [TLS] Version in record MAC Eric Rescorla
- Re: [TLS] Version in record MAC Ilari Liusvaara
- Re: [TLS] Version in record MAC Eric Rescorla
- Re: [TLS] Version in record MAC Adam Langley
- Re: [TLS] Version in record MAC Eric Rescorla
- Re: [TLS] Version in record MAC Eric Rescorla
- [TLS] Collision issue in ciphertexts. Dang, Quynh
- Re: [TLS] [Cfrg] Collision issue in ciphertexts. Watson Ladd
- Re: [TLS] [Cfrg] Collision issue in ciphertexts. Dang, Quynh
- [TLS] Data limit for GCM under a given key. Dang, Quynh
- Re: [TLS] Data limit for GCM under a given key. Watson Ladd
- Re: [TLS] Data limit for GCM under a given key. Dang, Quynh
- Re: [TLS] Data limit for GCM under a given key. Watson Ladd
- Re: [TLS] Data limit for GCM under a given key. Tony Arcieri
- Re: [TLS] Data limit for GCM under a given key. Eric Rescorla
- Re: [TLS] Data limit for GCM under a given key. Yoav Nir
- Re: [TLS] Data limit for GCM under a given key. Dave Garrett
- Re: [TLS] Data limit for GCM under a given key. Eric Rescorla
- Re: [TLS] Data limit for GCM under a given key. Eric Rescorla
- Re: [TLS] Data limit for GCM under a given key. Eric Rescorla
- Re: [TLS] Data limit for GCM under a given key. Dave Garrett
- Re: [TLS] Data limit for GCM under a given key. Dang, Quynh
- Re: [TLS] Data limit for GCM under a given key. Quynh Dang
- Re: [TLS] Data limit for GCM under a given key. Yoav Nir