Re: [TLS] security levels for TLS

Eric Rescorla <ekr@networkresonance.com> Mon, 08 October 2007 15:36 UTC

Return-path: <tls-bounces@lists.ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ieuer-0004K7-5b; Mon, 08 Oct 2007 11:36:37 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ieueq-0004Hm-5a for tls@lists.ietf.org; Mon, 08 Oct 2007 11:36:36 -0400
Received: from [74.95.2.169] (helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ieueh-0002dh-RO for tls@lists.ietf.org; Mon, 08 Oct 2007 11:36:36 -0400
Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id DAEBB33C21; Mon, 8 Oct 2007 08:32:18 -0700 (PDT)
Date: Mon, 08 Oct 2007 08:32:18 -0700
From: Eric Rescorla <ekr@networkresonance.com>
To: Nikos Mavrogiannopoulos <nmav@gnutls.org>
Subject: Re: [TLS] security levels for TLS
In-Reply-To: <c331d99a0710080621g7c0ec91et35c46553c23f4402@mail.gmail.com>
References: <c331d99a0710080621g7c0ec91et35c46553c23f4402@mail.gmail.com>
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20071008153218.DAEBB33C21@delta.rtfm.com>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5
Cc: tls@lists.ietf.org
X-BeenThere: tls@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/tls>
List-Post: <mailto:tls@lists.ietf.org>
List-Help: <mailto:tls-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=subscribe>
Errors-To: tls-bounces@lists.ietf.org

At Mon, 8 Oct 2007 16:21:42 +0300,
Nikos Mavrogiannopoulos wrote:
> 
> Hello,
>  It seems that in TLS the security level of a connection relies on
> several factors including the ciphersuite. In certificate
> authentication the certificate plays also a large factor in the
> security, and especially the public key of it, plus the signer's
> public key.
> 
> This is not visible and neither understandable in everyday work with
> TLS by typical users. For example a browser connection to a site with
> a 512 bit RSA key that negotiated an 128 bit ciphersuite will not
> differ to a connection with a 2048 bit RSA key and the same
> ciphersuite, with regard to visible user data. This makes difficult
> for users to judge the security level of the connection and one must
> never assume that a user would understand what a 512 bit RSA key
> means.
> 
> For this reason I think using some form of uniform security levels to
> indicated TLS security would be useful in end-applications. Those
> levels could be defined in steps (as in [0]), based on objective
> information of the key sizes in the certificates, the DHE prime and
> generator sizes (if applicable), the MAC output size of the
> ciphersuite as well as the key size of the cipher.
> 
> Then the security level could be printed either as a number (70 bits
> of security) or as "weak, low, medium, high" based on some definitions
> of these terms... I could make it more detailed if there is some
> interest. What do you think?

I think this is something that the TLS WG should avoid getting involved
in.

1. It's not really possible to come up with a single figure of merit
   in an uncontroversial way. To take the simplest possible case, what
   security level should we assign to TLS_RSA_WITH_NULL_SHA1 when the
   key is 1024 bits? What's the security level of TLS_RSA_DHE_* 
   when the RSA key is 1024 bits and the DH key is 512? How about
   the other way around? 
2. These numbers change over time as attacks get better. Unfortunately,
   those changes aren't straightforward. For instance, it's not
   really that easy to assess the security of HMAC-MD5 right now,
   especially if the question you're interested in asking is how
   secure it will be in a year (and the horizon you'd need to be
   thinking about is more like 5 years).
3. It seems likely that once you get past a fairly modest algorithm
   strength (40 bits? 64 bits?) the dominant security predictor
   about a given system is implementation quality (remotely exploitable
   vulns, RNG quality, ...), not algorithm strength. I don't know how
   to assess that.
   
-Ekr



_______________________________________________
TLS mailing list
TLS@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls