Re: [TLS] some questions for your draft

yangqinqin <yangqinqin@huaweisymantec.com> Wed, 25 November 2009 08:45 UTC

Return-Path: <yangqinqin@huaweisymantec.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 E1B963A6895 for <tls@core3.amsl.com>; Wed, 25 Nov 2009 00:45:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.399
X-Spam-Level: ***
X-Spam-Status: No, score=3.399 tagged_above=-999 required=5 tests=[AWL=3.894, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 xYeCaVhCC59s for <tls@core3.amsl.com>; Wed, 25 Nov 2009 00:45:53 -0800 (PST)
Received: from mta2.huaweisymantec.com (unknown [218.17.155.15]) by core3.amsl.com (Postfix) with ESMTP id 0CD853A686B for <TLS@ietf.org>; Wed, 25 Nov 2009 00:45:53 -0800 (PST)
MIME-version: 1.0
Content-transfer-encoding: 7bit
Content-type: text/plain; charset="UTF-8"
Received: from hstml02-in.huaweisymantec.com ([172.26.3.42]) by hstga02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0KTN00L43PO1YLA0@hstga02-in.huaweisymantec.com> for TLS@ietf.org; Wed, 25 Nov 2009 16:45:38 +0800 (CST)
Received: from y00144023 ([10.27.154.91]) by hstml02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTPA id <0KTN00G64PO1Y320@hstml02-in.huaweisymantec.com> for TLS@ietf.org; Wed, 25 Nov 2009 16:45:37 +0800 (CST)
Message-id: <009a01ca6dab$a90765f0$5b9a1b0a@china.huawei.com>
From: yangqinqin <yangqinqin@huaweisymantec.com>
To: Marsh Ray <marsh@extendedsubset.com>
References: <C7316509.25DEC%dispensa@phonefactor.com> <001101ca6d63$7bf73970$5b9a1b0a@china.huawei.com> <4B0C7C4E.8010600@extendedsubset.com> <003701ca6d6d$515ea360$5b9a1b0a@china.huawei.com> <4B0C897C.8010904@extendedsubset.com>
Date: Wed, 25 Nov 2009 16:45:37 +0800
X-Priority: 3
X-MSMail-priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3598
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
Cc: TLS@ietf.org
Subject: Re: [TLS] some questions for your draft
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, 25 Nov 2009 08:48:46 -0000

Marsh,

Thank you for your reply. I have just joined the mailing list.

In your draft, 
 "If the other end attempts to authenticate with a different identity, the renegotiation MUST fail."

How do you achieve it in the renegotiation?  

You also wrote in the draft,  "For certificate based cipher suites, this means bitwise equality of the end-entity certificate. " 

This increases authentication steps. But original TLS renegotiation protocol has not this step. 

 
Thanks,

Qinqin Yang

----- Original Message ----- 
From: Marsh Ray 
To: yangqinqin 
Cc: Steve Dispensa ; Nasko Oskov ; Eric Rescorla 
Sent: Wednesday, November 25, 2009 9:33 AM
Subject: Re: some questions for your draft


yangqinqin wrote:
> Thank you for your reply.
> But I have not joined the mailing list.  And I didn' t find it in the
> archives of the [TLS] mailing list. There are  too many mails related to
> this question. Moreover, english is not my native language. So I hope
> you will give me answer.

Here's one message I can find:

http://www.ietf.org/mail-archive/web/tls/current/msg04136.html
> I really don't like to allow both, change of identities during
> renegotiation _and_ arbitrary interleaving of application data
> with the renegotiation handshake messages.  Applications
> may get this wrong easily

It sounds like the wording is motivated in part by the ambiguity of
application data transmitted between the Change Cipher Spec and Finished
messages.

I suspect it's also a recognition that many applications are expecting
authentication to strengthen across renegotiation, but not change entirely.

- Marsh