Re: [TLS] Data volume limits

Aaron Zauner <azet@azet.org> Fri, 01 January 2016 18:25 UTC

Return-Path: <azet@azet.org>
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 243AC1ACE39 for <tls@ietfa.amsl.com>; Fri, 1 Jan 2016 10:25:15 -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] 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 yKJVI6XMdIRt for <tls@ietfa.amsl.com>; Fri, 1 Jan 2016 10:25:13 -0800 (PST)
Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::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 73D5A1ACE37 for <tls@ietf.org>; Fri, 1 Jan 2016 10:25:13 -0800 (PST)
Received: by mail-wm0-x22d.google.com with SMTP id l65so108607988wmf.1 for <tls@ietf.org>; Fri, 01 Jan 2016 10:25:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=azet.org; s=gmail; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=FcDitDBx6Ub0TF+YWm0bVfQ1GgDUcG+d6r2waGG9YI8=; b=cpc22ccJBa+baaLYF50UG2XL6LnWdEJvQ+WFFE6VgIprlB/3VRbdsy5NZ87BDf/3L8 hgKOUqX5PKnbx5YZusFQC2sxvVrgTOVW6y7S5TADCuDUYBzkJ+k6NJWzhqpgyaLrCc1L 0HlREu2kp2Kw4b2TJBO5YS4Ai/txHRr605XmU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=FcDitDBx6Ub0TF+YWm0bVfQ1GgDUcG+d6r2waGG9YI8=; b=cJ3vQKADuPwYOTa9Ozl8ztaXpmReMBzBx6AtrHjVyZNWnOhlp1PQdHFKdd79KWHwCp TvX8fsrKUv6EbGYPehLDZ2FeVTsSMlWU4/nXYcIAe7ssAual1fDSFTz2gfx6xvljwYs/ TXXWdvPn+x/oo9UZYa8Q+GpEXhv++DD3x0iOQyTkYqyEpM7wMkso/1yW725fZ2eNFllV sIKNHh2FEYTmejntgolMScmBMn7r6fPhIkoFy6NBCNH7NgAF/uKCz1D+GbDE267+Gl6f V5fIBtlbxC2T05Kw6WYAIb+b5BsCEEddLqUY054fu+mCphTDfaDzJ4Mr0rV1+1GFnKAp 5kAQ==
X-Gm-Message-State: ALoCoQnTBLZ2qEdsx4Q4lNxfzpj32BnE/vQPkQs78QfcHd5hdIW0jhbSoTFp6kj260S7064dQpeqwNPVSSvM+0Pz+PusJKmqYQ==
X-Received: by 10.28.64.131 with SMTP id n125mr86192488wma.103.1451672711994; Fri, 01 Jan 2016 10:25:11 -0800 (PST)
Received: from typhoon.azet.org (chello080108049181.14.11.vie.surfer.at. [80.108.49.181]) by smtp.gmail.com with ESMTPSA id w80sm45101961wme.17.2016.01.01.10.25.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Jan 2016 10:25:10 -0800 (PST)
Date: Fri, 1 Jan 2016 19:25:22 +0100
From: Aaron Zauner <azet@azet.org>
To: sneves@dei.uc.pt
Message-ID: <20160101191936.62107c1c1c@f374df84e9aa7e5>
References: <CABcZeBNR76DqPo0Mukf5L2G-WBSC+RCZKhVGqBZq=tJYfEHLUg@mail.gmail.com> <87twnibx5p.fsf@latte.josefsson.org> <20160101073508.4dd10442c5@ebeb88ce88adeb8> <56866098.2010803@dei.uc.pt> <20160101165821.6cc8a962c4@1620a90cf4e0c0b> <20160101171630.15796qivr4d264xa@mail.dei.uc.pt>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="W/nzBZO5zC0uMSeA"
Content-Disposition: inline
In-Reply-To: <20160101171630.15796qivr4d264xa@mail.dei.uc.pt>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/dHIlDGG_bVf-Drmktm65E9ji7qs>
Cc: 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: Fri, 01 Jan 2016 18:25:15 -0000

Hi,

* sneves@dei.uc.pt <sneves@dei.uc.pt> [01/01/2016 18:19:26] wrote:
> The contention with GCM in this thread has been, so far, focused on
> confidentiality. This is because, by a result of Bernstein [1] (see also
> Appendix C of [2]), after q = 2^60 messages sent, plus q' = 2^60 attempted
> forgeries by an attacker with messages at most l_A = 2^16 blocks long, the
> probability of an attacker to forge a message is still ~2^-52. This does not
> present a data volume problem at the moment for the authentication part of
> AES-GCM.
> 

Interesting - I was not aware of that. Thanks for taking the time to
explain.

> On the other hand, after 2^60 OCB messages of 2^16 blocks (and thus 2^76
> total blocks), a block collision is almost guaranteed to have happened,
> enabling the aforementioned forgeries.

Sure. Would you see any way to improve this situation in the draft,
i.e. give implementation recommendations or similar?

> What you may be thinking of is the GCM behavior on _nonce reuse_. In this
> case, we are able to recover the authentication key by root finding and
> forge messages at will. This is also the case with OCB---on nonce reuse, we
> can forge any message that has the same checksum as a valid message.

No. Nonce-reuse is a seperate issue, the one I addressed in my
commit on the draft linked to in an earlier message. The
construction used in the chacha20/poly1305 draft is very elegant I
think: if you do not implement a proper nonce the implementation
will not interoperate with other implementation conforming to spec.

Thanks again,
Aaron