Re: [TLS] [Cfrg] Data limit to achieve Indifferentiability for ciphertext with TLS 1.3 GCM, and the 2nd paragraph of Section 5.5

Martin Thomson <> Sun, 13 November 2016 23:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E602C12969A; Sun, 13 Nov 2016 15:54:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rCZ7GtVSBNPl; Sun, 13 Nov 2016 15:54:23 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C8F5712968E; Sun, 13 Nov 2016 15:54:22 -0800 (PST)
Received: by with SMTP id n21so78359762qka.3; Sun, 13 Nov 2016 15:54:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jOBBQY8obNo/71Ywzqd49r+pzmsmwnA9uJ5FZjT3orM=; b=cJhCeqwvgHZU9C2/Nu0CBiEuUqVKec0hwtEBs/gdXuvlPfLc9xe5CfECbC5/hx/ItY UK1UvooMEoI+O9Bc3lkKJrP5LhsZE0ACk1gjwO7gW7qhByQkCgXjL9SAfJnH31GUdwEi WVbjYOtrdv0vV/H61RIS/n6Cko3RQIUgGDV6t73A+tttkQ/mMCZ73GR0NC5EuclnEAxv UCbEzUufHuHW0joj8jIF9XY9MLERVcy5Zaipfr9UI3Lf4DOAlUFjxZJYq3RKVJC5OBL1 mcnrOLNiUb0b4XOqr8TzuSOofSGf2CKGRJSvZClOIm+kFjt/wYhZxDBywpwzGCVCvrkN x8Ig==
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:from:date :message-id:subject:to:cc; bh=jOBBQY8obNo/71Ywzqd49r+pzmsmwnA9uJ5FZjT3orM=; b=dtWdX9jlcf43ZBB3VNH5CiC4BXA+YcZSnXSNWN1ltJXXn9Adx7d22r/sJiXltWgj78 E4aYNtJ9NNwcNyYuAOaNonE4dkqmWqMTvhhEXpy4zC3rps9XYsez4bWAf0trGTaPt25M jtBdF/A0pOdT/mZEJ3CZQYjwX+qR1mFSoPGi+24N1aXO+SlD5+GE0hmGTbmerTNt+lMN uMRAsTse/VCOskBfIHukIT/Zm3fcG1qtLCem4GB7noTT9zKziJlipYmh0Wwu2toiounp tUyoGhRuIeIGjacNJtMF3DUSfyda00YLtwYOOlFKiNPwgOM+4jq3KPVmb5UqHum7JiiW gpqA==
X-Gm-Message-State: ABUngvfcwRpvRESkMUIiLomd/TWGnpxkT6Bpdykdc6e3ufLfIjS1+rSmapByZPa+Gqfw1aOW0kiBAR4sIZ2tmw==
X-Received: by with SMTP id 2mr14058151qkm.68.1479081261915; Sun, 13 Nov 2016 15:54:21 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Sun, 13 Nov 2016 15:54:21 -0800 (PST)
In-Reply-To: <>
References: <>
From: Martin Thomson <>
Date: Mon, 14 Nov 2016 08:54:21 +0900
Message-ID: <>
To: "Dang, Quynh (Fed)" <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Cc: "" <>, "" <>
Subject: Re: [TLS] [Cfrg] Data limit to achieve Indifferentiability for ciphertext with TLS 1.3 GCM, and the 2nd paragraph of Section 5.5
X-Mailman-Version: 2.1.17
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: Sun, 13 Nov 2016 23:54:26 -0000

These are intentionally very conservative.  Having implemented this, I
find it OK.  The text cites its sources.  Reading those sources
corrects any misapprehension.

The key point here is that we want to ensure that the initial - maybe
uninformed - inferences need to be for the safe thing.  We don't want
to have the situation where we have looser text and that leads to

For instance, someone could deploy code that assumes a certain
"average" record size based on a particular deployment and hence a
larger limit.  If the deployment characteristics change without the
code changing we potentially have an issue.

You really need to demonstrate that there is harm with the current
text.  if rekeying happens on that timescale (which is still very
large), that's not harmful.  I'm concerned that we aren't going to
rekey often enough.  I don't agree that it will create any negative
perception of GCM.

On 14 November 2016 at 05:48, Dang, Quynh (Fed) <> wrote:
> Hi Eric and all,
> Regardless of the actual record size, each 128-bit block encryption is
> performed with a unique 128-bit counter which is formed by the 96-bit IV and
> the 32-bit counter_block value called CB in NIST SP 800-38D under a given
> key as long as the number of encrypted records is not more than 2^64.
> Assuming a user would like to limit the probability of a collision among
> 128-bit ciphertext-blocks under 1/2^32, the data limit of the ciphertext (
> or plaintext) is 2^(96/2) (= 2^48) 128-bit blocks which is 2^64 bytes.
> Reading the 2nd paragraph of section 5.5, a user might feel that he/she
> needs to rekey a lot more quicker than he/she needs. Putting an
> unnecessarily low data limit of 2^24.5 full-size records (2^38.5 bytes) also
> creates an incorrect negative impression (in my opinion) about GCM.
> I would like to request the working group to consider to revise the text.
> Regards,
> Quynh.
> _______________________________________________
> Cfrg mailing list