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

Huang Min <huangmin123@huawei.com> Tue, 15 December 2009 10:41 UTC

Return-Path: <huangmin123@huawei.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 014783A69D0; Tue, 15 Dec 2009 02:41:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.294
X-Spam-Level: **
X-Spam-Status: No, score=2.294 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CN_BODY_35=0.339, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.1]
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 L9yLtV0dvvAU; Tue, 15 Dec 2009 02:41:02 -0800 (PST)
Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 2EBC53A67C0; Tue, 15 Dec 2009 02:41:02 -0800 (PST)
Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KUO00MP2WBQC2@szxga04-in.huawei.com>; Tue, 15 Dec 2009 18:40:38 +0800 (CST)
Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KUO00CCJWBQQ4@szxga04-in.huawei.com>; Tue, 15 Dec 2009 18:40:38 +0800 (CST)
Received: from h00104745 ([10.27.154.97]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KUO00JR3WBP1F@szxml04-in.huawei.com>; Tue, 15 Dec 2009 18:40:38 +0800 (CST)
Date: Tue, 15 Dec 2009 18:40:36 +0800
From: Huang Min <huangmin123@huawei.com>
In-reply-to: <mailman.5029.1260848783.32729.tls@ietf.org>
To: 'Stefan Santesson' <stefan@aaa-sec.com>, 'Nicolas Williams' <Nicolas.Williams@sun.com>, 'Russ Housley' <housley@vigilsec.com>
Message-id: <000601ca7d73$0a0289d0$619a1b0a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset="gb2312"
Content-transfer-encoding: quoted-printable
Thread-index: Acp9OSrozfSrMVuyTS+SIY0wS6uDkQAMryhg
Cc: tls@ietf.org, iesg@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: Tue, 15 Dec 2009 10:41:03 -0000

 
Hi, Stefan

I don't agree the point that unpatched renegotiation could be still used and
all the problems solved by applications.
The vunerability is brought by SSL/TLS protocol itself, it MUST solved by
itslef. We could not give this protocol to other upper applications,and say:
"hi, here is a protocol you could use, but there is a vunerability in the
protocol which can be used for a MITM attack, so you SHOULD do A, B, C,
D.....to avoid it, if you want to use this protocol. " It is not
responsible. 

Discarding renegotiation mechanism or fixing the vunerability are both more
acceptable than leaving this problem to upper application layer. 

regards,
Min Huang


-----邮件原件-----


Date: Tue, 15 Dec 2009 02:37:01 +0100
From: Stefan Santesson <stefan@aaa-sec.com>
Subject: Re: [TLS] COMMENT: draft-ietf-tls-renegotiation
To: Nicolas Williams <Nicolas.Williams@sun.com>,	Russ Housley
	<housley@vigilsec.com>
Cc: iesg@ietf.org, tls@ietf.org
Message-ID: <C74CA6CD.740F%stefan@aaa-sec.com>
Content-Type: text/plain;	charset="US-ASCII"

The fact that it is used for legitimate purposes makes me worried about the
consequences of just abandoning it without fixing it.

Perhaps a middle way is to not fix it and not to remove it, but simply
clarify it's security properties. I'm still not convinced you can't use
unpatched renegotiation securely if applications simply don't accept
messages sent before completed renegotiation as being delivered under the
context of the renegotiated connection. Other's have suggested the same.

/Stefan