IETF Logo Mail Archive

Re: [TLS] security levels for TLS

Mike <mike-list@pobox.com> Fri, 12 October 2007 19:03 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 1IgPmp-0004ry-UY; Fri, 12 Oct 2007 15:03:03 -0400
Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1IgPmp-0004rt-28 for tls-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 15:03:03 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgPmo-0004jG-OT for tls@lists.ietf.org; Fri, 12 Oct 2007 15:03:02 -0400
Received: from rune.pobox.com ([208.210.124.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgPmY-0000YG-NX for tls@lists.ietf.org; Fri, 12 Oct 2007 15:02:55 -0400
Received: from rune (localhost [127.0.0.1]) by rune.pobox.com (Postfix) with ESMTP id 5DA3C147540 for <tls@lists.ietf.org>; Fri, 12 Oct 2007 15:02:48 -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 rune.sasl.smtp.pobox.com (Postfix) with ESMTP id 30ACC147309 for <tls@lists.ietf.org>; Fri, 12 Oct 2007 15:02:47 -0400 (EDT)
Message-ID: <470FC52E.6080707@pobox.com>
Date: Fri, 12 Oct 2007 12:04:14 -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> <470FB525.7010308@pobox.com> <20071012180445.1D22D33C21@delta.rtfm.com>
In-Reply-To: <20071012180445.1D22D33C21@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: d6b246023072368de71562c0ab503126
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

>> 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.
> 
> Yes, but it's unconvincing to me for reasons I've already stated.
> When I start to hear stories about repeated client reconnect
> probes due to key size mismatches *for reasons other than obvious
> server config errors*, I'll get interested in this.

Apparently no argument will suffice, and you would rather keep the
status quo than be proactive.  How long do you think it would take
to add this extension to a TLS toolkit?  In my own code, I could
probably do it in less than a day, with time left over to get in a
round of 18 holes.

Mike


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

v2.23.0 | Report a Bug | By Email