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
- [TLS] COMMENT: draft-ietf-tls-renegotiation Russ Housley
- Re: [TLS] COMMENT: draft-ietf-tls-renegotiation Steven Bellovin
- Re: [TLS] COMMENT: draft-ietf-tls-renegotiation Nicolas Williams
- Re: [TLS] COMMENT: draft-ietf-tls-renegotiation Russ Housley
- Re: [TLS] COMMENT: draft-ietf-tls-renegotiation Peter Saint-Andre
- Re: [TLS] COMMENT: draft-ietf-tls-renegotiation Kemp, David P.
- Re: [TLS] COMMENT: draft-ietf-tls-renegotiation Peter Gutmann
- Re: [TLS] COMMENT: draft-ietf-tls-renegotiation Stefan Santesson
- Re: [TLS] COMMENT: draft-ietf-tls-renegotiation Pasi.Eronen
- Re: [TLS] COMMENT: draft-ietf-tls-renegotiation Huang Min
- Re: [TLS] COMMENT: draft-ietf-tls-renegotiation Ben Laurie
- Re: [TLS] COMMENT: draft-ietf-tls-renegotiation Robert Dugal
- Re: [TLS] COMMENT: draft-ietf-tls-renegotiation Badra
- Re: [TLS] COMMENT: draft-ietf-tls-renegotiation Robert Dugal
- Re: [TLS] COMMENT: draft-ietf-tls-renegotiation Steve Dispensa
- Re: [TLS] COMMENT: draft-ietf-tls-renegotiation Ran Canetti
- Re: [TLS] COMMENT: draft-ietf-tls-renegotiation Marsh Ray
- Re: [TLS] COMMENT: draft-ietf-tls-renegotiation Peter Saint-Andre
- Re: [TLS] COMMENT: draft-ietf-tls-renegotiation Martin Rex
- Re: [TLS] COMMENT: draft-ietf-tls-renegotiation Nelson Bolyard
- Re: [TLS] COMMENT: draft-ietf-tls-renegotiation Nicolas Williams
- Re: [TLS] COMMENT: draft-ietf-tls-renegotiation Martin Rex
- Re: [TLS] COMMENT: draft-ietf-tls-renegotiation Martin Rex
- Re: [TLS] COMMENT: draft-ietf-tls-renegotiation Steven Bellovin
- Re: [TLS] COMMENT: draft-ietf-tls-renegotiation Steve Dispensa