Re: [TLS] security levels for TLS

Mike <mike-list@pobox.com> Sat, 13 October 2007 01:13 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 1IgVZG-0003sr-Rn; Fri, 12 Oct 2007 21:13:26 -0400
Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1IgVZF-0003sk-Pl for tls-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 21:13:25 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgVZF-0003os-GG for tls@lists.ietf.org; Fri, 12 Oct 2007 21:13:25 -0400
Received: from sceptre.pobox.com ([207.106.133.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgVZ8-0005ed-BZ for tls@lists.ietf.org; Fri, 12 Oct 2007 21:13:19 -0400
Received: from sceptre (localhost.localdomain [127.0.0.1]) by sceptre.pobox.com (Postfix) with ESMTP id 0B6122EF for <tls@lists.ietf.org>; Fri, 12 Oct 2007 21:13:11 -0400 (EDT)
Received: from [192.168.1.8] (wsip-24-234-114-35.lv.lv.cox.net [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sceptre.sasl.smtp.pobox.com (Postfix) with ESMTP id B9A46899D8 for <tls@lists.ietf.org>; Fri, 12 Oct 2007 21:13:10 -0400 (EDT)
Message-ID: <47101BFE.6020300@pobox.com>
Date: Fri, 12 Oct 2007 18:14:38 -0700
From: Mike <mike-list@pobox.com>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: tls@lists.ietf.org
Subject: Re: [TLS] security levels for TLS
References: <c331d99a0710080621g7c0ec91et35c46553c23f4402@mail.gmail.com> <470FC52E.6080707@pobox.com> <p06240828c3357a914a76@[192.168.1.3]> <200710122237.30517.nmav@gnutls.org> <20071012200032.70EEA33C23@delta.rtfm.com> <4710000A.7020006@pobox.com> <20071013000010.F21A233C21@delta.rtfm.com>
In-Reply-To: <20071013000010.F21A233C21@delta.rtfm.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da
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

>> I think there is some mis-communication going on.  I have never
>> even mentioned the IETF standardizing an "indicator" of security
>> level.  Someone else may have, but I reject that idea as well.
> 
> Well, two things seem to be being discussed simultaneously:
> 
> 1. Standardizing simplified "levels" of security which correspond to 
>    cipher suites and key sizes.
> 
>     This is purely a documentation issue and doesn't require any
>     on-the-wire changes to TLS. 
> 
> 2. Modifying TLS to allow the client to indicate the size of the
>    keys/group it would like for each asymmetric algorithm. This
>    is an on-the-wire protocol change. 
> 
> As I understand your messages, you've been endorsing both of these.

I said above that I reject the idea of standardizing levels.  Why
don't you believe that?  You must be attributing someone else's
statements with me.

> I'm against both of these, for related, but distinct reasons.
> 
> I'm against the former because I think it's actually very hard to
> produce any reasonable standardized account of which algorithms and
> key sizes fit into which level. In any case, this is something that an
> implementation can easily offer without any standard, it simply will
> not necessarily have the same level->algorithm mapping as another
> implementation.

I said in one of my first messages that this would be implementation
dependent.

> I'm against the second because I believe it adds marginal benefit
> at a significant cost to interoperability and complexity. An 
> extension like this only makes sense if:
> 
> 1. Servers have a number of different kinds of keying material
>    of different strengths.
> 2. Clients are in a position to make intelligent choices about
>    which asymmetric key strengths are appropriate.
> 
> In my experience, neither is true. Moreover, it's worth noting
> that in the current environment any client which attempts to
> request a key > 1024 bits will find that it can connect to
> practically nobody. To a first order, this is just another
> way to create interop problems. 

Well if you implement TLS 1.1 and expect to connect to anyone,
you will be disappointed, and yet we're working even on TLS 1.2.
There is always a transition period with new capabilities.

> With regard to key lengths: as I indicated before, the dominant
> security issue in systems of this kind is quality of implementation
> and maintenance. If you don't trust the server to choose appropriate
> key sizes, why on earth would you trust that it's not chock full
> of remote vulnerabilities?

Perhaps the server has different goals than you do -- it might
want to maximize transactions.  But maybe it would let you select
better security if you asked for it.  Currently there is no way
to ask.

Mike


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