Re: [TLS] FWD: First TLS cached information draft posted
Sean Shen <sshen@huawei.com> Tue, 09 June 2009 09:09 UTC
Return-Path: <sshen@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 705C228C161 for <tls@core3.amsl.com>; Tue, 9 Jun 2009 02:09:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.593
X-Spam-Level: *
X-Spam-Status: No, score=1.593 tagged_above=-999 required=5 tests=[AWL=2.088, 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 k5WiJ5eMELId for <tls@core3.amsl.com>; Tue, 9 Jun 2009 02:09:25 -0700 (PDT)
Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 90D5128C12B for <TLS@ietf.org>; Tue, 9 Jun 2009 02:09:25 -0700 (PDT)
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 <0KKY00F7CRRWWM@szxga04-in.huawei.com> for TLS@ietf.org; Tue, 09 Jun 2009 17:02:20 +0800 (CST)
Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KKY00I49RRW7O@szxga04-in.huawei.com> for TLS@ietf.org; Tue, 09 Jun 2009 17:02:20 +0800 (CST)
Received: from s00102542 ([10.111.12.128]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KKY00IP5RRV9I@szxml04-in.huawei.com> for TLS@ietf.org; Tue, 09 Jun 2009 17:02:20 +0800 (CST)
Date: Tue, 09 Jun 2009 17:02:19 +0800
From: Sean Shen <sshen@huawei.com>
In-reply-to: <87vdn5kjm8.fsf@mocca.josefsson.org>
To: 'Simon Josefsson' <simon@josefsson.org>
Message-id: <003a01c9e8e0$febb83f0$800c6f0a@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="us-ascii"
Content-transfer-encoding: 7bit
Thread-index: Acnoy3XaZhGo0pJKTqiT76bFQIFHAAAFGGHA
Cc: TLS@ietf.org
Subject: Re: [TLS] FWD: First TLS cached information draft posted
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, 09 Jun 2009 09:09:26 -0000
> > Hi, Stefan, > > I support the idea and like the benefit of not transporting Certs. > > The drafts looks good and clear to me, except that I get some > > questions regarding the following part in section 4: > > > > Servers that receive an extended client hello containing a > > "cached_information" extension, MAY indicate that they > support one or > > more of the cached information objects by including an > extension of > > type "cached_information" in the (extended) server > hello, which SHALL > > contain at least one CachedObject received from the client. The > > CachedObject's returned by the server MUST include the types the > > server supports and has accepted to replace with a hash > of the cached > > data. > > > > It gives me impression that server's reply can include > items that is > > beyond cached items which clients provide. Is it possible > (or leagal) > > for clients to use those items which he did not mentioned but were > > indicated usable by server? > > For example clients provides items {A, B}, server replied {B, C}. > > B has been confirmed by both sides, C is confirmed only by > Server. If > > B and C are both acceptable, but the two negotiation base are not > > quite same, will there be a problem ? > > Not quite sure it would > > cause trouble or not though, but wondering whether it will. > > Good point. I don't see how that could work -- how would the > server know whether the client supported C? The client needs > to understand C in order to parse the handshake properly. Right, this is another reason that replying extra items beyond client's proposal is not a good idea. So I suggest that server should only reply with items chosen from client's proposal, the current wording in the draft does allow that happens. Sean