IETF Logo Mail Archive

Re: [TLS] Data Volume Limits Analysis

Aaron Zauner <azet@azet.org> Wed, 23 March 2016 12:41 UTC

Return-Path: <azet@azet.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18B0C12D544 for <tls@ietfa.amsl.com>; Wed, 23 Mar 2016 05:41:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
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, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=azet.org
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 WvX0WCJJtVVs for <tls@ietfa.amsl.com>; Wed, 23 Mar 2016 05:41:21 -0700 (PDT)
Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (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 BC2CC12DC38 for <tls@ietf.org>; Wed, 23 Mar 2016 05:31:24 -0700 (PDT)
Received: by mail-wm0-x22f.google.com with SMTP id r129so133973270wmr.1 for <tls@ietf.org>; Wed, 23 Mar 2016 05:31:24 -0700 (PDT)
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-disposition:in-reply-to:user-agent; bh=eLk2vMWKuhv/iPO3tF7/viyBKoEaMKGlNcP/fRISwzY=; b=VPJLhUP7dCr3XZKUERqWhQ5/0QEaWkQZMfB4bBjM44hknSBStoMIGumtxZhdHBe7FH A3qqr/ckYTqY4fDoqgWTHIamiSmKfYRthcy5mWoIe7mdKAvr5XDPFkiNqonvYPKqYIpE c2teFwlbp+dgoSndeKjBCpo70jmi4o41BFSe0=
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-disposition:in-reply-to:user-agent; bh=eLk2vMWKuhv/iPO3tF7/viyBKoEaMKGlNcP/fRISwzY=; b=a50NAVgV3bITavyGgd1tOQ/GVQH/seDaY6PFXqdRzB52ZlBALbyQ3My5VM2pgh4Iy1 tWEEQQSjnCELySAFfzdSYn3dkbXOhPNtAXSpj+WOAqwIiWtTLHfbjZsAbvv5olvywAef DCJCnCTATRtOt0HWrr9dYqhQR3ir/gT9IlB6mf4MQgIKHnRUgHawBpnICc+kPcqbv91o co3grLdXHU/UQGRggnToKkNMA802sbERnAIXk005E/qkvR4v5XWJfn2qusJEDonAbPQw +YxL65yuY9A5/idg3VAWazkLNppcWbyiwP6Jk2S2gWeBEzqnZsbO0yXEylzDw7yb0Mif 4y2A==
X-Gm-Message-State: AD7BkJKnm+Qmp1+Zb0mxkcGCGpQ0L5V5GDv02rEo2zqLkyZ/XNmagpiGWrcrxjjHiQOHMA==
X-Received: by 10.28.131.141 with SMTP id f135mr25350007wmd.33.1458730022308; Wed, 23 Mar 2016 03:47:02 -0700 (PDT)
Received: from typhoon.azet.org (chello080108049181.14.11.vie.surfer.at. [80.108.49.181]) by smtp.gmail.com with ESMTPSA id jo6sm1908349wjb.48.2016.03.23.03.47.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 23 Mar 2016 03:47:00 -0700 (PDT)
Date: Wed, 23 Mar 2016 11:46:59 +0100
From: Aaron Zauner <azet@azet.org>
To: aluykx <Atul.Luykx@esat.kuleuven.be>
Message-ID: <20160323114457.2d269ae6a9@24e3576741335c9>
References: <78f6d6778c608a99e276c2efa561d2ab@esat.kuleuven.be> <CABcZeBPhtdjvduRBK2ibFCiapuEJsQjtJwsWg_Ac8swyONUGVg@mail.gmail.com> <0b6588fb0237c89d71192560b3487e11@esat.kuleuven.be>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="uAKRQypu60I7Lcqm"
Content-Disposition: inline
In-Reply-To: <0b6588fb0237c89d71192560b3487e11@esat.kuleuven.be>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/LwANk-POErYnRyVohnxUsNYeJ8U>
Cc: tls@ietf.org
Subject: Re: [TLS] Data Volume Limits Analysis
X-BeenThere: tls@ietf.org
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." <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, 23 Mar 2016 12:41:40 -0000

* aluykx <Atul.Luykx@esat.kuleuven.be> [23/03/2016 09:12:02] wrote:
> >Finally, and this calls for an opinion: do you believe that given these
> >results
> >we should include a KeyUpdate feature in TLS 1.3?
> 
> Ideally it would be better to include a KeyUpdate feature, but the added
> complexity could risk introducing vulnerabilities worse than what happens
> when the bounds are not respected, since all of these attacks require
> adversaries to monitor large amounts of data. If KeyUpdate is simple, then
> include it, but otherwise it might not be worth the risk.

Thinking about this a bit before I read your reply, I came to the
same conclusion. It could be useful if it's well done and
implementations update securely. But that's hard :)

Aaron

v2.23.0 | Report a Bug | By Email