IETF Logo Mail Archive

Re: [TLS] TLS Client Puzzles

Brian Sniffen <bsniffen@akamai.com> Tue, 07 July 2015 15:17 UTC

Return-Path: <bsniffen@akamai.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 0A8201A88D0 for <tls@ietfa.amsl.com>; Tue, 7 Jul 2015 08:17:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.462
X-Spam-Level: *
X-Spam-Status: No, score=1.462 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, SPF_SOFTFAIL=0.665] 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 L8YIxVkg6cZ7 for <tls@ietfa.amsl.com>; Tue, 7 Jul 2015 08:17:45 -0700 (PDT)
Received: from prod-mail-xrelay07.akamai.com (unknown [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id E56791A88C2 for <tls@ietf.org>; Tue, 7 Jul 2015 08:17:44 -0700 (PDT)
Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id E0F8E48C3E; Tue, 7 Jul 2015 15:17:53 +0000 (GMT)
Received: from prod-mail-relay07.akamai.com (prod-mail-relay07.akamai.com [172.17.121.112]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id C8ECA48B87; Tue, 7 Jul 2015 15:17:53 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=akamai.com; s=a1; t=1436282273; bh=pg4h81t02XoR3rXWqIDv9VTpjV2Yqd9Hkt5y7cZWLoM=; h=From:To:CC:Subject:In-Reply-To:References:Date:From; b=r7+wv6CHYDzOEZ8eVpdznDM+0xDOvA25kwn01Nm7qFJe3IxcI8B0OnKcPh91ALhB8 N12qG4+SbnjWUDw+DJ2gR/jeiZdOkM9aETXT9KLndn/WU3S530fTCAXG/D3WsXjagc rYl3/WlLxJh61RyKBrCU3otF82cJB7r7xQn18AtQ=
Received: from email.msg.corp.akamai.com (ecp.msg.corp.akamai.com [172.27.123.34]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id 90F4880087; Tue, 7 Jul 2015 15:17:43 +0000 (GMT)
Received: from USMA1EX-CAS1.msg.corp.akamai.com (172.27.123.30) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Tue, 7 Jul 2015 11:17:43 -0400
Received: from bos-mpeve.local (172.19.44.26) by USMA1EX-CAS1.msg.corp.akamai.com (172.27.123.30) with Microsoft SMTP Server (TLS) id 15.0.1076.9 via Frontend Transport; Tue, 7 Jul 2015 11:17:43 -0400
From: Brian Sniffen <bsniffen@akamai.com>
To: Watson Ladd <watsonbladd@gmail.com>, Erik Nygren <erik+ietf@nygren.org>
In-Reply-To: <CACsn0c=NFUCCSUL=03Uf6+rQHgUEwxxsqfOuc2a3HSoFsu3MWg@mail.gmail.com>
References: <CAKC-DJjfq_Lw6ovX=sVFt3=4q_4CYo_N79PZFx+LrGj7DbLK+w@mail.gmail.com> <CAHOTMVKYS75xqeVsHmmuxRFMRqgAVJ_U-1c825LMn8+h+QmOdA@mail.gmail.com> <CAKC-DJgcaPmB9svO7GYZvurDprGPYNcWR=iAHGi21ZrcmaC4gg@mail.gmail.com> <CACsn0c=NFUCCSUL=03Uf6+rQHgUEwxxsqfOuc2a3HSoFsu3MWg@mail.gmail.com>
User-Agent: Notmuch/0.19 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-apple-darwin13.4.0)
Date: Tue, 07 Jul 2015 11:18:10 -0400
Message-ID: <m2615wm1xp.fsf@usma1mc-0csx92.kendall.corp.akamai.com>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/kKykbZQhww-XCDxjahCUblleGs8>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] TLS Client Puzzles
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: Tue, 07 Jul 2015 15:17:46 -0000

> At these rates you saturate gigabit ethernet connections, which
> puzzles will not help with. In fact, they will make the problem worse.

It's now normal to deploy one 10GbE NIC per CPU.  CPU load is definitely
still the bottleneck.

> What about improving performance? That avoids any protocol changes,
> and brings about the benefits you seem to want.

By all means!  But it'll take 10-20 years to get those performance
benefits out to the ends of the Earth.  I hope we can have some
conversations using that technology in 2-5 years, but we should expect
to be supporting RSA-2048 at least through 2025 (or a few years after
it's discovered to be broken), and NIST curves through 2030.

I'm not happy (or sad) about those dates, but if we think we're going to
go faster than final death of SSLv2, MD5, and similar, we should be able
to explain why that would be.

-Brian

v2.23.0 | Report a Bug | By Email