Re: [TLS] Unifying tickets and sessions

Hubert Kario <hkario@redhat.com> Wed, 22 October 2014 12:57 UTC

Return-Path: <hkario@redhat.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 861731A8AFE for <tls@ietfa.amsl.com>; Wed, 22 Oct 2014 05:57:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.912
X-Spam-Level:
X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 MKPVqf8QOmAq for <tls@ietfa.amsl.com>; Wed, 22 Oct 2014 05:57:08 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D24E1A90F6 for <tls@ietf.org>; Wed, 22 Oct 2014 05:57:08 -0700 (PDT)
Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s9MCujKH015522 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 22 Oct 2014 08:56:46 -0400
Received: from pintsize.usersys.redhat.com (vpn1-7-116.ams2.redhat.com [10.36.7.116]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s9MCufBc027308 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Oct 2014 08:56:43 -0400
From: Hubert Kario <hkario@redhat.com>
To: tls@ietf.org
Date: Wed, 22 Oct 2014 14:56:40 +0200
Message-ID: <1659862.HPNNz8lRhl@pintsize.usersys.redhat.com>
User-Agent: KMail/4.14.1 (Linux/3.16.6-200.fc20.x86_64; KDE/4.14.1; x86_64; ; )
In-Reply-To: <CAA7UWsVmxAmBtdCvpE_+c2e7brJNkPrQ5_69FDXzy2csg6EsyA@mail.gmail.com>
References: <2A0EFB9C05D0164E98F19BB0AF3708C71D3A8C48AF@USMBX1.msg.corp.akamai.com> <544606E5.2070807@fussenegger.info> <CAA7UWsVmxAmBtdCvpE_+c2e7brJNkPrQ5_69FDXzy2csg6EsyA@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/YuqsYC_wrkElnNtuens_VE-9zRg
Subject: Re: [TLS] Unifying tickets and sessions
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: <http://www.ietf.org/mail-archive/web/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, 22 Oct 2014 12:57:12 -0000

On Tuesday 21 October 2014 14:33:43 David Leon Gil wrote:
> On Tue, Oct 21, 2014 at 3:10 AM, Richard Fussenegger, BSc
> 
> <richard@fussenegger.info> wrote:
> > I'm [. . .] glimpsing over to the fact that the
> > cryptography community agrees that 128 bit security will be enough for the
> > next 10 to 20 years.[2]
> 
> This really isn't true. See djb's "matching AES security" at
> https://www.ietf.org/mail-archive/web/cfrg/current/msg04820.html
> 
> Summarizing: The workfactor of a multi-target attack is much lower for
> symmetric-key crypto than for attacks against asymmetric-key crypto.
> This is exactly the sort of attack that is useful for mass
> surveillance.
> 
> We need to start moving away from AES-128 now, not in 10 years.
> 
> (Note that a number of cryptographers think that 2^90 operations per
> year is feasible today; djb is lowballing the number a bit.)

That assumes that you have the space to store all those communications, most 
of which will be utter garbage for you (spdy/HTTP2.0 as a whole and HTTP1.1 
keep alive connections), then you need to have the ability to reference all 
those 2^50 keys in close to real time.

Yes, it doesn't require "hard" computation, but it does require massive 
amounts of relatively fast memory.

It's a classic memory-time tradeoff, isn't it?

And looking at current computers, time is cheaper and is getting cheaper 
faster than memory is, as it has for at least past 20 years...

-- 
Regards,
Hubert Kario