Re: [TLS] Comparative cipher suite strengths

Nicolas Williams <Nicolas.Williams@sun.com> Wed, 22 April 2009 16:51 UTC

Return-Path: <Nicolas.Williams@sun.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 37E073A6D8A for <tls@core3.amsl.com>; Wed, 22 Apr 2009 09:51:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.877
X-Spam-Level:
X-Spam-Status: No, score=-5.877 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
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 sfJUiYPoNiaK for <tls@core3.amsl.com>; Wed, 22 Apr 2009 09:51:19 -0700 (PDT)
Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by core3.amsl.com (Postfix) with ESMTP id 0988C28C267 for <tls@ietf.org>; Wed, 22 Apr 2009 09:50:42 -0700 (PDT)
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n3MGpxB8024571 for <tls@ietf.org>; Wed, 22 Apr 2009 16:51:59 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n3MGpxlK057841 for <tls@ietf.org>; Wed, 22 Apr 2009 10:51:59 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n3MGgRp3016166; Wed, 22 Apr 2009 11:42:27 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n3MGgQwE016165; Wed, 22 Apr 2009 11:42:26 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f
Date: Wed, 22 Apr 2009 11:42:26 -0500
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: carlyoung@keycomm.co.uk
Message-ID: <20090422164226.GH1500@Sun.COM>
References: <51912.1240398992@keycomm.co.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <51912.1240398992@keycomm.co.uk>
User-Agent: Mutt/1.5.7i
Cc: TLS <tls@ietf.org>
Subject: Re: [TLS] Comparative cipher suite strengths
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
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/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, 22 Apr 2009 16:51:20 -0000

On Wed, Apr 22, 2009 at 12:16:32PM +0100, carlyoung@keycomm.co.uk wrote:
> Thanks for all the responses. I think the following text is a better
> way of describing what I meant and why I was asking:
> 
> We have a customer that mandated that we utilize AES-256 for the
> symmetric encryption keys used on our TLS sessions, so we have
> complied, and this works fine. Looking at implementation details from
> the customer, I found that they are using static X.509v3 certificates
> (CA issued), where the public key size is only 1024 bits.

As you surmise the weak link in the chain then is the RSA key size.
There's always going to be a weak link, but there's no sense in making
the other links stronger so far out of proportion to the weakest link.

Either the customer should revise their requirement that AES-256 be used
or they should deploy larger RSA keys.  But even so, going whole hog to
15kbit key lengths is not really practical.  Therefore I'd recommend
raising the RSA key size to 2048.

> So, I would want to recommend to the customer that if they want a more
> secure TLS session, then they need to increase the RSA key sizes to
> "match" the symmetric key strength, as the overall security 'strength'
> of their TLS sessions comes down to their RSA key size [as it's lower
> comparably to AES-256].
> 
> Does this seem reasonable and make more sense than my original question?

Yes, but by my experience your customer's security policy people are not
likely to agree or will be averse to any change.  Here's how this sort
of thing goes:

SECURITY: the policy is <fill in the blank> (and "it's needed for SOX
compliance")
INTERNAL AUDIT: you're not doing what the policy requires
YOU: the policy is stupid^H^H^H^H^H^Hbroken, here's why
SECURITY: <crickets>

If you get past that you then run into other walls.  E.g., say you
convince the policy ppl that they should raise the RSA key size, but
then the business people complain that performance sucks, or that
deploying new certs will cost too much, so they ask their regulators for
a waiver -- and then you're back at square one (the policy has changed
but reality hasn't).

See also Dilbert.

Nico
--