IETF Logo Mail Archive

Re: [TLS] Last Call: draft-ietf-tls-renegotiation

Chris Newman <Chris.Newman@Sun.COM> Thu, 03 December 2009 04:44 UTC

Return-Path: <Chris.Newman@Sun.COM>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F94B3A690B for <tls@core3.amsl.com>; Wed, 2 Dec 2009 20:44:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.986
X-Spam-Level:
X-Spam-Status: No, score=-5.986 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qIMelJgIQlUB for <tls@core3.amsl.com>; Wed, 2 Dec 2009 20:44:54 -0800 (PST)
Received: from sca-es-mail-1.sun.com (sca-es-mail-1.Sun.COM [192.18.43.132]) by core3.amsl.com (Postfix) with ESMTP id 0BF7D3A67E4 for <tls@ietf.org>; Wed, 2 Dec 2009 20:44:53 -0800 (PST)
Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id nB34ijFL026507 for <tls@ietf.org>; Wed, 2 Dec 2009 20:44:46 -0800 (PST)
MIME-version: 1.0
Content-transfer-encoding: 7bit
Content-disposition: inline
Content-type: text/plain; CHARSET="US-ASCII"; format="flowed"
Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KU2009007RDU400@fe-sfbay-09.sun.com> for tls@ietf.org; Wed, 02 Dec 2009 20:44:45 -0800 (PST)
Received: from [192.168.15.4] ([unknown] [71.92.75.71]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KU200FLZ7UJJO70@fe-sfbay-09.sun.com>; Wed, 02 Dec 2009 20:44:45 -0800 (PST)
Date: Wed, 02 Dec 2009 20:44:08 -0800
From: Chris Newman <Chris.Newman@Sun.COM>
In-reply-to: <4B170D1D.7070401@jacaranda.org>
Sender: Chris.Newman@Sun.COM
To: David-Sarah Hopwood <david-sarah@jacaranda.org>, tls@ietf.org
Message-id: <B2805AE67F5C908EC8E4014C@446E7922C82D299DB29D899F>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
References: <200912021419.nB2EJr13019589@fs4113.wdf.sap.corp> <357DD72C025D423B8C814E16@446E7922C82D299DB29D899F> <4B170D1D.7070401@jacaranda.org>
Subject: Re: [TLS] Last Call: draft-ietf-tls-renegotiation
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Dec 2009 04:44:55 -0000

--On December 3, 2009 0:58:05 +0000 David-Sarah Hopwood 
<david-sarah@jacaranda.org> wrote:
>> The issue with middleboxes was raised by others and is a straw man.
>> There are government standards that have a fixed list of cipher suites
>> and most clients can be configured to comply with those standards
>> today.  Given the TLS standards available at the time, a middlebox which
>> enforced the presence of just those cipher suites and no others in the
>> TLS handshake would reasonably be expected to be forwards compatible.
>
> That is not true. Any such middlebox would already have been broken
> numerous times by browser implementors adding new cipher suites to the
> list that they offer. I agree with Martin; this objection is based on a
> completely implausible premise.

The purpose of such a government standard (and any middlebox which enforced 
it) is to require all the browsers to be configured with a fixed cipher 
suite list of the approved cipher suites.  As major browsers support such 
configuration (often via enterprise management tools), the default list of 
ciphers in a browser is irrelevant to the scenario.

> (BTW, I don't think "straw man" is what you meant to say.
> <http://en.wikipedia.org/wiki/Straw_man>)

I meant <http://en.wikipedia.org/wiki/Straw_man_proposal>.  Or more 
precisely, I do not know if such boxes exist, but it is reasonable to 
postulate that they do and other people on the list have so postulated.

>>> I consider this a defect in draft-ietf-tls-renegotiation-01.
>>> There should be exactly **ONE** signaling mechanism for the initial
>>> ClientHello on a connection so that extensions-tolerant but
>>> extensions-free Servers will not be force to wade through lists
>>> of extensions sent by clients.
>>
>> I'd be fine with one signaling mechanism as long as it's the mechanism
>> that's been standardized since 2006 and backwards-compatible with
>> correct implementations since 1999 (TLS 1.0).  If we're misusing a
>> cipher suite value as a protocol extensibility flag, an issue I'm
>> willing to compromise on despite the lack of strong evidence it's
>> necessary, we unfortunately need two signaling mechanisms: one that's
>> standard that we know will work with modern correct implementations, and
>> one a kludge that works with very old software, but might break
>> good-faith modern implementations (like the middlebox straw man above).
>
> If the argument about middleboxes is simply wrong (which it is), then
> this argument is also wrong.

I reject that the middlebox argument is wrong.  Even if it was, it is only 
one example of a bad consequence from unpredictable misuse of a standardize 
protocol field and thus would not invalidated the argument.

> There is no need for two client->server
> signalling mechanisms; it's unnecessary complexity.

I have no problem with dropping the cipher suite value mechanism from the 
spec as there is no strong evidence it is necessary; that would result in a 
single symmetric negotiation mechanism; one that's using the predictable 
and standardized extensibility feature.  I can live with the cipher suite 
value as a compromise as long as we're not _required_ to misuse that 
standardized protocol field in a way that implementers could not reasonably 
anticipate.

		- Chris

v2.23.0 | Report a Bug | By Email