IETF Logo Mail Archive

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

"Robert Dugal" <rdugal@certicom.com> Tue, 15 December 2009 11:46 UTC

Return-Path: <rdugal@certicom.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 8CFBA3A694F for <tls@core3.amsl.com>; Tue, 15 Dec 2009 03:46:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.203
X-Spam-Level:
X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 Y8WwBthqVRX5 for <tls@core3.amsl.com>; Tue, 15 Dec 2009 03:46:20 -0800 (PST)
Received: from mhs04ykf.rim.net (mhs04ykf.rim.net [216.9.243.82]) by core3.amsl.com (Postfix) with ESMTP id 7B8A13A6818 for <tls@ietf.org>; Tue, 15 Dec 2009 03:46:20 -0800 (PST)
X-AuditID: 0a666446-b7bb5ae000000a04-22-4b2776fea56f
Received: from XCH39YKF.rim.net ( [10.64.31.40]) by mhs04ykf.rim.net (RIM Mail) with SMTP id 94.0C.02564.EF6772B4; Tue, 15 Dec 2009 06:46:06 -0500 (EST)
Received: from XCH57YKF.rim.net ([10.64.31.54]) by XCH39YKF.rim.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 15 Dec 2009 06:46:06 -0500
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
content-transfer-encoding: quoted-printable
Date: Tue, 15 Dec 2009 06:46:05 -0500
Message-ID: <7E1DF37F1F42AB4E877E492C308E6AC402D31A78@XCH57YKF.rim.net>
In-Reply-To: <20091214194431.GO1516@Sun.COM>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [TLS] COMMENT: draft-ietf-tls-renegotiation
Thread-Index: Acp89uvn5Ffw0pyCTDWmUIcpoTCCGwAg/rNQ
References: <20091214191959.427A53A6A27@core3.amsl.com> <20091214194431.GO1516@Sun.COM>
From: Robert Dugal <rdugal@certicom.com>
To: tls@ietf.org
X-OriginalArrivalTime: 15 Dec 2009 11:46:06.0102 (UTC) FILETIME=[2F926360:01CA7D7C]
X-Brightmail-Tracker: AAAABAAAAZESBPV4EgT2vhIE9r8=
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: Tue, 15 Dec 2009 11:46:21 -0000

The server based gaming specs require renegotiation periodically in order to refresh TLS session keys. 
A lot of the requirements in the gaming specs are to meet legislatorial requirements.
I'm not sure where the renegotiation requirements come from but it's in the spec and I suspect they are going to be resistant to dropping it.

-- 
Robert Dugal		Senior Software Developer
Certicom Corp.		A Subsidiary of Research In Motion 
rdugal@certicom.com
direct        905.501.3848
fax             905.507.4230
www.certicom.com


-----Original Message-----
From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of Nicolas Williams
Sent: Monday, December 14, 2009 2:45 PM
To: Russ Housley
Cc: iesg@ietf.org; tls@ietf.org
Subject: Re: [TLS] COMMENT: draft-ietf-tls-renegotiation

On Mon, Dec 14, 2009 at 11:19:57AM -0800, Russ Housley wrote:
>   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.

I would like to agree.  There's no real-world need to re-negotiate for
re-keying nowadays: with the advent of 128-bit block block ciphers
there's little need.

But re-negotiation remains useful for other purposes.  Probably the most
obvious ones are optional authentication and privacy protection for
client credentials.  I'm not sure those are sufficiently useful or
important to warrant keeping the feature, but if not then dropping the
feature does seem like a better option than fixing it.

Nico
-- 
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

v2.23.0 | Report a Bug | By Email