Re: [TLS] First TLS cached information draft posted
Stefan Santesson <stefan@aaa-sec.com> Sun, 07 June 2009 08:46 UTC
Return-Path: <stefan@aaa-sec.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 CFB233A6879 for <tls@core3.amsl.com>; Sun, 7 Jun 2009 01:46:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.109
X-Spam-Level:
X-Spam-Status: No, score=-2.109 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, HELO_EQ_SE=0.35]
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 i5Ii9IPEcT1k for <tls@core3.amsl.com>; Sun, 7 Jun 2009 01:46:54 -0700 (PDT)
Received: from s87.loopia.se (s87.loopia.se [194.9.95.112]) by core3.amsl.com (Postfix) with ESMTP id 68E753A67A4 for <TLS@ietf.org>; Sun, 7 Jun 2009 01:46:51 -0700 (PDT)
Received: (qmail 82389 invoked from network); 7 Jun 2009 08:46:56 -0000
Received: from s34.loopia.se (HELO s19.loopia.se) ([194.9.94.70]) (envelope-sender <stefan@aaa-sec.com>) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for <TLS@ietf.org>; 7 Jun 2009 08:46:56 -0000
Received: (qmail 15881 invoked from network); 7 Jun 2009 08:46:52 -0000
Received: from 213-64-142-21-no153.business.telia.com (HELO [192.168.0.17]) (stefan@fiddler.nu@[213.64.142.21]) (envelope-sender <stefan@aaa-sec.com>) by s19.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <stefan@aaa-sec.com>; 7 Jun 2009 08:46:52 -0000
User-Agent: Microsoft-Entourage/12.17.0.090302
Date: Sun, 07 Jun 2009 10:46:52 +0200
From: Stefan Santesson <stefan@aaa-sec.com>
To: Stefan Santesson <stefan@aaa-sec.com>, martin.rex@sap.com, Simon Josefsson <simon@josefsson.org>
Message-ID: <C6514B1C.27CA%stefan@aaa-sec.com>
Thread-Topic: [TLS] First TLS cached information draft posted
Thread-Index: AcnmRIKZ8VcrZfh87UavqXY8qgfrGgBB/4iC
In-Reply-To: <C64F9034.27AD%stefan@aaa-sec.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Cc: TLS@ietf.org
Subject: Re: [TLS] 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: Sun, 07 Jun 2009 08:46:54 -0000
I think I have to try to clarify this The client send a cached_information extension which contains a list of CachedObject structures. Each ChachedObject element contains: - type identifier (CachedInformationType type) - a list of hash values (CachedInformationHash hashes) Each CachedInformationHash contains: - Algorithm identifier (HashAlgorithm hash) - Hash value (opaque hash_value) There are a number of issues that need to be specified or clarified in the draft: 1) Is it allowed to send over multiple CachedObject elements containing the same type identifier? Proposed answer = No (you can already include multiple hashes for each type) 2) What should the server return in its server hello message for each acceptable CachedObject? Alternative 1 = The CachedObject element, exactly as it was received by the client (with all hashes) Alternative 2 = The CachedObject element, but only containing the CachedInformationHash elements that is recognize and support. Proposed answer = Alternative 1 (This allows the server to say YES in principle without analyzing the hash values at the time of Hello exchange) 3) Is the server REQUIRED to honor its support of a CachedObject by replacing the identified handshake data with a received hash? Proposed answer = NO (for reasons raised by Martin) 4) What does the server send as replacement for the replaced handshake data? Proposed answer = One opaque hash_value (without hash type identifier) that was received by the client, which MUST contain a valid hash over the replaced data. Do you agree? /Stefan On 09-06-06 3:17 AM, "Stefan Santesson" <stefan@aaa-sec.com> wrote: > Martin, > > I liked Simon's suggestion as he expressed my original thought that the > Server would know beforehand the hashes for acceptable information objects. > > However, what you suggest actually makes sense to me. > > I also found another minor error as the draft refer to hash_value (single > hash) when I should refer to the "hashes" (multiple hash) element. > > We have to think through the concept of sending over multiple hashes and > what the appropriate response from the server is. > > 1) The server accepts replacement in principle, but does not know at the > time of sending the server hello if any of the hashes match. > > 2) The server accepts one or more hashes from the client hello (for one > object type) and includes the hashes it accepts in the server hello > > 3) The server accepts one or more hashes from the client hello (for one > object type) but includes only 1 (the preferred one) hash for that object > type in the server hello. > > Once we can agree on this, I will update and submit a new version of the > draft. > > /Stefan > > > > > On 09-06-05 10:55 PM, "Martin Rex" <Martin.Rex@sap.com> wrote: > >> Simon Josefsson wrote: >>> >>> First, this paragraph: >>> >>> 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 intention here appears under-specified. What does it mean if the >>> client sent two CachedObject's and the server just returned one of them? >>> One plausible interpretation would be that the server did not support >>> the hash/type-combination that were not returned. Enforcing that >>> interpretation is needed to resolve my second concern. >>> >>> I suggest to add a sentence: >>> >>> The CachedObject's returned by the server MUST include the types the >>> server supports and has accepted to replace with cached data. >> >> I don't know whether I correctly understand the suggestion >> that you're making. But I'm very unhappy with one possible >> interpretation that I see in your poposal. >> >> Having the TLS server indicate for which objects its TLS implementation >> supports the caching _in_principle_ is fine with me. >> >> Requiring the server to already know the hash values of >> parts the contents of future SSL handshake messages, specifically >> the to-be-cached data at the time when composing the ServerHello >> handshake message is something I would definitely not like. >> >> The impact on implementations of TLS should be as small as possible. >> To me, a requirement for a TLS server to precompute hashes over >> parts of future handshake messages during ServerHello looks like >> a significant additional burden, and personally, I do not yet see >> any benefit this might provide. >> >> >> -Martin > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls
- Re: [TLS] First TLS cached information draft post… Stefan Santesson
- Re: [TLS] First TLS cached information draft post… Simon Josefsson
- Re: [TLS] First TLS cached information draft post… Stefan Santesson
- Re: [TLS] First TLS cached information draft post… Martin Rex
- [TLS] First TLS cached information draft posted Stefan Santesson
- Re: [TLS] First TLS cached information draft post… Simon Josefsson
- Re: [TLS] First TLS cached information draft post… Stefan Santesson
- Re: [TLS] First TLS cached information draft post… Stefan Santesson
- Re: [TLS] First TLS cached information draft post… Simon Josefsson
- Re: [TLS] First TLS cached information draft post… Simon Josefsson
- Re: [TLS] First TLS cached information draft post… Simon Josefsson
- Re: [TLS] First TLS cached information draft post… Simon Josefsson
- Re: [TLS] First TLS cached information draft post… Martin Rex
- Re: [TLS] First TLS cached information draft post… Simon Josefsson
- Re: [TLS] First TLS cached information draft post… Martin Rex
- Re: [TLS] First TLS cached information draft post… Simon Josefsson
- Re: [TLS] First TLS cached information draft post… Martin Rex
- Re: [TLS] First TLS cached information draft post… Martin Rex
- Re: [TLS] First TLS cached information draft post… Simon Josefsson
- Re: [TLS] First TLS cached information draft post… Simon Josefsson
- Re: [TLS] First TLS cached information draft post… Simon Josefsson
- Re: [TLS] First TLS cached information draft post… Min Huang
- Re: [TLS] First TLS cached information draft post… Min Huang
- Re: [TLS] First TLS cached information draft post… Simon Josefsson
- Re: [TLS] First TLS cached information draft post… Martin Rex
- Re: [TLS] First TLS cached information draft post… Simon Josefsson
- Re: [TLS] First TLS cached information draft post… Stefan Santesson
- Re: [TLS] First TLS cached information draft post… Stefan Santesson
- Re: [TLS] First TLS cached information draft post… Stefan Santesson
- Re: [TLS] First TLS cached information draft post… Stefan Santesson
- Re: [TLS] First TLS cached information draft post… Martin Rex
- Re: [TLS] First TLS cached information draft post… Martin Rex
- Re: [TLS] First TLS cached information draft post… Stefan Santesson
- Re: [TLS] First TLS cached information draft post… Stefan Santesson