Re: [TLS] FWD: First TLS cached information draft posted
Simon Josefsson <simon@josefsson.org> Tue, 09 June 2009 06:27 UTC
Return-Path: <simon@josefsson.org>
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 CD1143A6C4E for <tls@core3.amsl.com>; Mon, 8 Jun 2009 23:27:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 9Lsp9h+DyY+Q for <tls@core3.amsl.com>; Mon, 8 Jun 2009 23:27:17 -0700 (PDT)
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id 5DBEC3A6C36 for <TLS@ietf.org>; Mon, 8 Jun 2009 23:27:16 -0700 (PDT)
Received: from mocca.josefsson.org (c80-216-29-127.bredband.comhem.se [80.216.29.127]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n596Qu46026497 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 9 Jun 2009 08:26:58 +0200
From: Simon Josefsson <simon@josefsson.org>
To: Sean Shen <sshen@huawei.com>
References: <001201c9e89d$5db40c40$800c6f0a@china.huawei.com>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090609:tls@ietf.org::6OfHIr4Y3imkABgH:85v
X-Hashcash: 1:22:090609:sshen@huawei.com::kDBpuKMwVb9ENxNS:5SWw
Date: Tue, 09 Jun 2009 08:26:55 +0200
In-Reply-To: <001201c9e89d$5db40c40$800c6f0a@china.huawei.com> (Sean Shen's message of "Tue, 09 Jun 2009 08:58:13 +0800")
Message-ID: <87vdn5kjm8.fsf@mocca.josefsson.org>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.94 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
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 06:27:18 -0000
Sean Shen <sshen@huawei.com> writes: > 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. /Simon