Re: [TLS] security levels for TLS

Mike <mike-list@pobox.com> Fri, 12 October 2007 17:54 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 1IgOiu-0007oI-6U; Fri, 12 Oct 2007 13:54:56 -0400
Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1IgOit-0007nj-4o for tls-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 13:54:55 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgOis-0007PO-QA for tls@lists.ietf.org; Fri, 12 Oct 2007 13:54:54 -0400
Received: from sceptre.pobox.com ([207.106.133.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgOif-0006wZ-Pw for tls@lists.ietf.org; Fri, 12 Oct 2007 13:54:46 -0400
Received: from sceptre (localhost.localdomain [127.0.0.1]) by sceptre.pobox.com (Postfix) with ESMTP id A19672F0 for <tls@lists.ietf.org>; Fri, 12 Oct 2007 13:54:21 -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 6DC2F89737 for <tls@lists.ietf.org>; Fri, 12 Oct 2007 13:54:21 -0400 (EDT)
Message-ID: <470FB525.7010308@pobox.com>
Date: Fri, 12 Oct 2007 10:55:49 -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> <p0624082fc331b0ed0ecc@[192.168.1.100]> <FA998122A677CF4390C1E291BFCF59890849871E@EXCH.missi.ncsc.mil> <470D0243.3050009@pobox.com> <20071010180324.7ABC533C21@delta.rtfm.com> <470E4399.3010008@pobox.com> <20071011155829.965C733C28@delta.rtfm.com> <470EF76B.5050102@pobox.com> <20071012045718.DE16033C21@delta.rtfm.com>
In-Reply-To: <20071012045718.DE16033C21@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: 0a7aa2e6e558383d84476dc338324fab
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

>> Right now all cipher suites are under-specified.  If we had,
>> for example:
>>
>>      TLS_DHE_1024_RSA_2048_WITH_AES_128_CBC_SHA
>>
>> we would probably not be talking about this.  I proposed that
>> we let clients "fill in the blanks" that the cipher suites
>> don't specify.  Isn't it better to tell the server exactly
>> what you want in terms of security, than to leave it up to
>> chance?
> 
> Arguably, it would have been, but it's not the way that the
> system is now....

I thought of an easier way to achieve this that should be less
controversial and simple to implement.  As an extension, it
would be completely optional as well, but I believe it would
be widely implemented:

     enum {
         diffie_hellman_parameter (0),
         server_rsa_key           (1),
         ca_rsa_key               (2),
         server_dsa_key           (3),
         ca_dsa_key               (4),
         ....
         (65535)
     } KeyType;

     struct {
         KeyType    key_type;
         uint24     preferred_size;
     } PreferredKeySize;

     struct {
         PreferredKeySize sizes<0..2^16-1>;
     } PreferredKeySizeExtension;

A server that understands this extension would reply with an
empty extension_data.  The server would do its best to select
keys, certificate chains, and DH parameters to satisfy the
client's request.  If it is unable or unwilling to do so, the
negotiation should proceed giving the client the opportunity
to accept weaker parameters than it asked for.  (Or a boolean
value could be added to the extension indicating whether the
client might accept weaker parameters; if not, the server
could immediately send a fatal insufficient_security alert.)

 > and I haven't seen an argument that this
 > needs to change..

The server's response would let the client know that it would
be a waste of time to try negotiating again with different
cipher suites if it found the key lengths to be unacceptable.
Clients and servers would spend less time performing fruitless
renegotiations, which would reduce server throughput.  This
seems like a good argument to me.

Mike


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