Re: [TLS] security levels for TLS

Eric Rescorla <ekr@networkresonance.com> Mon, 08 October 2007 16:26 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 1IevQp-0006X3-30; Mon, 08 Oct 2007 12:26:11 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IevQn-0006Wx-Qw for tls@lists.ietf.org; Mon, 08 Oct 2007 12:26:09 -0400
Received: from [74.95.2.169] (helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IevQm-00044g-Jc for tls@lists.ietf.org; Mon, 08 Oct 2007 12:26:09 -0400
Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 5788B33C21; Mon, 8 Oct 2007 09:22:08 -0700 (PDT)
Date: Mon, 08 Oct 2007 09:22:07 -0700
From: Eric Rescorla <ekr@networkresonance.com>
To: Nikos Mavrogiannopoulos <nmav@gnutls.org>
Subject: Re: [TLS] security levels for TLS
In-Reply-To: <200710081914.29437.nmav@gnutls.org>
References: <c331d99a0710080621g7c0ec91et35c46553c23f4402@mail.gmail.com> <20071008153218.DAEBB33C21@delta.rtfm.com> <200710081914.29437.nmav@gnutls.org>
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: <20071008162208.5788B33C21@delta.rtfm.com>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88
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 19:14:28 +0300,
Nikos Mavrogiannopoulos wrote:
> 
> On Monday 08 October 2007, Eric Rescorla wrote:
> 
> > I think this is something that the TLS WG should avoid getting involved
> > in.
> I do agree that there is a lot of complexity in this issue, but the
> TLS WG is the only WG that could do this at least for TLS.

Yes, but just because we are the only ones who could do it does
not mean that we should?


> > 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?
> 
> This cannot be 100% objective by definition, but it can be based on a rational 
> process. Of course the security level of those cryptosystems should be 
> calculated using the weakest of the used algorithms.

So, the security level of null encryption is 0 because the weakest
algorithm (the confidentiality algorithm) has a zero-length key?
If that's so, what's the security level of an X.509 certificate signed with
a 1024-bit RSA key. That doesn't offer any confidentiality either.


> I've thought about that while reading "Selecting cryptographic key sizes" 
> (available at http://www.win.tue.nl/~klenstra/key.pdf)
> Which gives an answer to your questions above. 

I'm familiar with this work. It does not answer my questions above,
and the reason it does not is that they are questions that depend
critically on the operational environment and the threat model.
Cryptosecurity is about a lot more than key size.



> > 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).
> 
> I'm not talking about assessing individual algorithms, but rather give an 
> estimation of security based on objective facts as the key size etc. Of 
> course one cannot give precise security levels. 

So, HMAC-CRC with a key size of 1000 bits would have what security
level in this scheme?


> > 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.
> 
> Indeed, but having at least an estimation of security based on some objective 
> factor I think it is a good step forward. 

I don't. When most of the variance is in some other factor, then
measuring security of whatever factor you happen to be able to
measure is extremely misleading.

-Ekr


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