Re: [TLS] TLS, PKI,

Martin Rex <mrex@sap.com> Wed, 21 July 2010 21:04 UTC

Return-Path: <mrex@sap.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 005283A6B8B for <tls@core3.amsl.com>; Wed, 21 Jul 2010 14:04:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.435
X-Spam-Level:
X-Spam-Status: No, score=-9.435 tagged_above=-999 required=5 tests=[AWL=0.814, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WyWwPlUsuDG8 for <tls@core3.amsl.com>; Wed, 21 Jul 2010 14:04:56 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id BD5553A6B97 for <tls@ietf.org>; Wed, 21 Jul 2010 14:04:54 -0700 (PDT)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id o6LL595E001143 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 21 Jul 2010 23:05:09 +0200 (MEST)
From: Martin Rex <mrex@sap.com>
Message-Id: <201007212105.o6LL588O009654@fs4113.wdf.sap.corp>
To: asteingruebl@paypal.com
Date: Wed, 21 Jul 2010 23:05:08 +0200
In-Reply-To: <5EE049BA3C6538409BBE6F1760F328ABEA9A471FBF@DEN-MEXMS-001.corp.ebay.com> from "Steingruebl, Andy" at Jul 14, 10 04:49:45 pm
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal07
X-SAP: out
Cc: tls@ietf.org
Subject: Re: [TLS] TLS, PKI,
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: mrex@sap.com
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/listinfo/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, 21 Jul 2010 21:04:58 -0000

Steingruebl, Andy wrote:
> 
> Actually, I think that the recent work that the Google guys did
> - http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html
> - might have some impact on this.  There is some cost to using TLS.   

Of course there is some cost to using TLS, but computationally it
has been marginal for common web uses for many years.  Where you
notice it is with downloads of large amounts of data (several MBytes)
over high-speed links (100 MBit/s+), because the raw encryption
speed of the symmetric ciphers becomes visible.

The performance of TLS with software-crypto was perfectly acceptable
6 years ago on x86 and x86_64 bit Hardware platforms.  I 
All performance problem I've seen so far were the result of bugs
and software design flaws, but not problems of the technology or
lack of speed of the underlying hardware (maybe with the exception
of a few RISC-based unix boxen for which a decent crypto speed with
portable C code has been notoriously difficult to achieve).

The most difficult issue with larger servers is not the crypto,
but correct and efficient TLS session cache manangement.

And there still is a lot of (non-browser) software out there where
TLS session caching doesn't work, is defective in certain
configurations (Microsoft IIS) or is not implemented (apache mod_proxy).


-Martin