IETF Logo Mail Archive

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

David-Sarah Hopwood <david-sarah@jacaranda.org> Thu, 03 December 2009 00:58 UTC

Return-Path: <djhopwood@googlemail.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 904A128C0FC for <tls@core3.amsl.com>; Wed, 2 Dec 2009 16:58:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
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 XIUj+1wAjQDo for <tls@core3.amsl.com>; Wed, 2 Dec 2009 16:58:22 -0800 (PST)
Received: from mail-ew0-f214.google.com (mail-ew0-f214.google.com [209.85.219.214]) by core3.amsl.com (Postfix) with ESMTP id 3E6D128C0F0 for <tls@ietf.org>; Wed, 2 Dec 2009 16:58:22 -0800 (PST)
Received: by ewy6 with SMTP id 6so904870ewy.29 for <tls@ietf.org>; Wed, 02 Dec 2009 16:58:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=LeoNwgfZvWpuRZwaUkCm6lRsW5q+IFsPxxZFYaa7z9Q=; b=HDDAKYijqhBv1HwqnmSdnr8Z9CHOdciF9WZThoZVec1GmTivoLoHNKOkno7rNqF7ha puDQ/Cs8HLUB8VA8Y08Lz/Ll7hpuoNAYE3arVQLJnyiR5N56baT4yOKeh4tP+f3WbRho TJFQYj1oizT/vd+T4qAYVxoXXxbFVTVJdQuAs=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type; b=wN9UN9hPQJC9NztZ9dOK9n+nYltBwikJnec6XQJUfvwXNrHFoi0CeVgrkmHFiR892N BHjFHHXiKX0a7a6uEuiqk6tvXSW3RdIR4CNTFv5JzULaabJvKMfa0ClIeoX7c1wNxjXq umVbuK3AUrul2ob2L4mnB/QBjyXjE4/sdutYE=
Received: by 10.213.24.9 with SMTP id t9mr8149107ebb.92.1259801889164; Wed, 02 Dec 2009 16:58:09 -0800 (PST)
Received: from ?192.168.0.2? (5adcc5d2.bb.sky.com [90.220.197.210]) by mx.google.com with ESMTPS id 5sm2831304eyh.40.2009.12.02.16.58.08 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 02 Dec 2009 16:58:08 -0800 (PST)
Sender: David-Sarah Hopwood <djhopwood@googlemail.com>
Message-ID: <4B170D1D.7070401@jacaranda.org>
Date: Thu, 03 Dec 2009 00:58:05 +0000
From: David-Sarah Hopwood <david-sarah@jacaranda.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666
MIME-Version: 1.0
To: tls@ietf.org
References: <200912021419.nB2EJr13019589@fs4113.wdf.sap.corp> <357DD72C025D423B8C814E16@446E7922C82D299DB29D899F>
In-Reply-To: <357DD72C025D423B8C814E16@446E7922C82D299DB29D899F>
X-Enigmail-Version: 0.96.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="------------enigC04CAEEBBD993B26A45ADAE3"
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 00:58:23 -0000

Chris Newman wrote:
> --On December 2, 2009 15:19:53 +0100 Martin Rex <mrex@sap.com> wrote:
>>> 4. The mrex proposal requires use of TLS_RENEGO_PROTECTION_REQUEST in
>>> some  circumstances.  That approach is untested in the field and I have
>>>    concerns it will negatively impact middleboxes.
>>
>> Huh?  That sounds extremely unbelievable.
> 
> First, I'll reiterate that I found both proposals acceptable, so the
> four points I made were all matters of design preference for this
> situation and not issues I find strongly compelling.
> 
> 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.

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

>> 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. There is no need for two client->server
signalling mechanisms; it's unnecessary complexity.

-- 
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com

v2.23.0 | Report a Bug | By Email