IETF Logo Mail Archive

Re: [TLS] COMMENT: draft-ietf-tls-renegotiation

Steven Bellovin <smb@cs.columbia.edu> Wed, 16 December 2009 18:57 UTC

Return-Path: <smb@cs.columbia.edu>
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 5853D3A69EB; Wed, 16 Dec 2009 10:57:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 s8cUQwz6InfG; Wed, 16 Dec 2009 10:57:26 -0800 (PST)
Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id 86DB03A6842; Wed, 16 Dec 2009 10:57:26 -0800 (PST)
Received: from dyn-209-2-209-237.dyn.columbia.edu (dyn-209-2-209-237.dyn.columbia.edu [209.2.209.237]) (user=smb2132 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.3/8.14.3) with ESMTP id nBGIv8kQ000120 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 16 Dec 2009 13:57:08 -0500 (EST)
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: text/plain; charset="us-ascii"
From: Steven Bellovin <smb@cs.columbia.edu>
In-Reply-To: <C74D0344.A8D3%dispensa@phonefactor.com>
Date: Wed, 16 Dec 2009 13:57:08 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <F4226376-55FD-44AA-9F3E-4C4B37B9A422@cs.columbia.edu>
References: <C74D0344.A8D3%dispensa@phonefactor.com>
To: Steve Dispensa <dispensa@phonefactor.com>
X-Mailer: Apple Mail (2.1077)
X-No-Spam-Score: Local
X-Scanned-By: MIMEDefang 2.68 on 128.59.29.8
Cc: iesg@ietf.org, tls@ietf.org
Subject: Re: [TLS] COMMENT: 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: Wed, 16 Dec 2009 18:57:27 -0000

On Dec 15, 2009, at 10:11 AM, Steve Dispensa wrote:

> On 12/15/09 4:43 AM, "Ben Laurie" <benl@google.com> wrote:
>> On Mon, Dec 14, 2009 at 7:19 PM, Russ Housley <housley@vigilsec.com> wrote:
>>> Comment:
>>> 
>>>  As a protocol climbs the IETF standards-track maturity ladder, we
>>>  sometimes drop features.  I would rather see renegotiation dropped
>>>  from TLS than see this complexity added to TLS protocol.
>> 
>> That would break any website that does per-directory client
>> certificates. Which may not be many, but its far more than zero.
>> 
> Also, it breaks support for varying crypto strength requirements (e.g., some
> docs require DES/MD5, some require AES/SHA-1). I certainly wouldn't specify
> a new system this way, but I'm sure there are existing systems that do this.
> 
I'm hard-put to justify a protocol feature for that scenario.  It's not just improbable, it's probably bad application design -- the performance differences in the different algorithms are just too small to justify it, and we don't have to support it just to deal with this niche case.  Ben's scenario is more compelling and bears further thought.

		--Steve Bellovin, http://www.cs.columbia.edu/~smb

v2.23.0 | Report a Bug | By Email