Re: [TLS] security levels for TLS

Eric Rescorla <ekr@networkresonance.com> Fri, 12 October 2007 20:04 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 1IgQjz-0000EM-6M; Fri, 12 Oct 2007 16:04:11 -0400
Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1IgQjx-0000E1-UW for tls-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 16:04:09 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgQjx-0000Dt-L3 for tls@lists.ietf.org; Fri, 12 Oct 2007 16:04:09 -0400
Received: from [209.213.211.195] (helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgQjw-0002oF-E3 for tls@lists.ietf.org; Fri, 12 Oct 2007 16:04:09 -0400
Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 7B05733C21; Fri, 12 Oct 2007 12:59:52 -0700 (PDT)
Date: Fri, 12 Oct 2007 12:59:51 -0700
From: Eric Rescorla <ekr@networkresonance.com>
To: Mike <mike-list@pobox.com>
Subject: Re: [TLS] security levels for TLS
In-Reply-To: <470FC52E.6080707@pobox.com>
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> <470FC52E.6080707@pobox.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: <20071012195952.7B05733C21@delta.rtfm.com>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2
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 Fri, 12 Oct 2007 12:04:14 -0700,
Mike wrote:
> 
> >> 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. 

Say rather that I would rather not make unnecessary modifications
to a stable standard.

As for the claim that "no argument will suffice", the message you
replied to pretty clearly spelled out what would suffice, so
I'll take this message as meaning that you don't have any 
real evidence along these lines.


> How long do you think it would take
> to add this extension to a TLS toolkit? 

This does not seem to me to be a relevant consideration.

-Ekr


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