Re: [TLS] Wrapping up cached info
Michael D'Errico <mike-list@pobox.com> Wed, 19 May 2010 15:03 UTC
Return-Path: <mike-list@pobox.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 2B5113A68C5 for <tls@core3.amsl.com>; Wed, 19 May 2010 08:03:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.712
X-Spam-Level:
X-Spam-Status: No, score=-0.712 tagged_above=-999 required=5 tests=[AWL=-0.713, BAYES_50=0.001]
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 0sHfCWAHdxon for <tls@core3.amsl.com>; Wed, 19 May 2010 08:03:06 -0700 (PDT)
Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by core3.amsl.com (Postfix) with ESMTP id 5E55E3A66B4 for <tls@ietf.org>; Wed, 19 May 2010 08:03:06 -0700 (PDT)
Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id F36A5B4698; Wed, 19 May 2010 11:02:58 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=g5pKl6rX/BAY qLK9PFGr8gAtiQk=; b=oBvJYFc5rnUq3V6Bh0YxMGBv52pLpYGqcdG67TAhS9cs U8ZZp46tVkLTjyqhwVI2FdEgYSFhbcad9E5GBWRbnATw0MhGA2N57bI3VZhLgYv9 JeIBkRbLVmLMciXl0J/IlZRj7l6cslzkY8z/VK5QjoLNLPgpcYzLXtSLBfqqyRM=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=faD2dL rpnKVkMSvzkqEo+QNX6/aqGwUL+Jvs6d4Cgz7WVCN0OiWhrtEcGK7kS5kkrD1dgG cq2iSytFBaOKgJ9I6FKyeP8NTmFfiuFOUU2j0kd0px91Q7/7mNCtUEgPh48OjN4L QVa1jlKTjVLQB0kKGAE70nW8vwUu0vZCvZ4kY=
Received: from a-pb-sasl-quonix. (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id D952AB4697; Wed, 19 May 2010 11:02:57 -0400 (EDT)
Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id C93A9B468F; Wed, 19 May 2010 11:02:55 -0400 (EDT)
Message-ID: <4BF3FD9C.3040206@pobox.com>
Date: Wed, 19 May 2010 08:02:52 -0700
From: Michael D'Errico <mike-list@pobox.com>
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: Stefan Santesson <stefan@aaa-sec.com>
References: <C819B76D.AF2B%stefan@aaa-sec.com>
In-Reply-To: <C819B76D.AF2B%stefan@aaa-sec.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Pobox-Relay-ID: 9C37A81A-6357-11DF-B8C9-D033EE7EF46B-38729857!a-pb-sasl-quonix.pobox.com
Cc: tls@ietf.org
Subject: Re: [TLS] Wrapping up cached info
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, 19 May 2010 15:03:11 -0000
Stefan Santesson wrote: > Not sure how I should interpret the silence? > > I guess it means that everyone agrees with me :) Then by that logic everyone also agrees with me to use http caching as the model! Seriously, I think that the current draft might be too simple. For example, consider caching the list of certificate_authorities in a CertificateRequest message. A web application might have several different lists of certificate_authorities based on what the resource is and who is trying to access it. If cached-info can only cache one object of any particular type, then it will not be very helpful for such an application. Also, exactly how would you hash the Diffie-Hellman parameters in a ServerKeyExchange message? You can't just hash the message since it also contains a unique Ys which changes frequently if not every handshake. Allowing the server to instead name the objects, and keep track of timestamps for each object, allows you to handle these two cases. In the multiple-CA-list example above, the server might have USER and ADMIN lists. If it can't be sure when exactly those lists were created, the timestamp can simply be when the server was started or when it last read its configuration. When the server forces the client to renegotiate when accessing a protected resource as an ADMIN for example, the server's cached info extension would contain: type=cert_req_ca_list,name=ADMIN,timestamp=20100519123456789 When requesting a less-sensitive, but not public resource, the server would send: type=cert_req_ca_list,name=USER,timestamp=20100519123456789 If the client's cached-info extension contained an exact match, then the server would omit that data from the handshake. This is sort of like cipher suite selection. The client sends a list of possible matches and the server selects one from the list. It differs in that there might be no match, in which case the server just sends the info for the object it decided to send in the handshake. I'm sure there are more details to be worked out, but I think it would be a good idea to entertain this approach. Mike > To repeat in short. Here is what I suggest based on the latest traffic: > > 1) A client, caching information also caches what hash algorithm was used to > calculate the finished message at the time of caching. > > 2) On repeated connections, the client indicate cached info by sending a > hash of the cached object using the cached hash algorithm. (No use of FNV > hash) > > 3) The server accepts by returning the received hash instead of the cached > data. > > 4) The only hash agility provided is that the client will send a hash > algorithm identifier with the hash. > > 5) The client MUST NOT send more than one hash per cached object, and MUST > used the cached hash algorithm. > > > This solves all issues raised (securely binds the cached data to the > finished calculation) and removes the need for hash agility > Syntactically it just requires adding a hash identifier and adjusting the > vector length for hash data. > > So I basically wander: > - Would this be acceptable? > - Who could NOT live with this solution? > - Who think it is worth the effort to agree on a better solution, and why? > > Regards > > > > > On 10-05-18 12:24 AM, "Stefan Santesson" <stefan@aaa-sec.com> wrote: > >> As Martin pointed out to me privately, the hash used in the finished >> calculation becomes known to the client only after receiving the serer >> hello. >> >> It would therefore be natural for the client to use the hash function used >> to calculate the finished message at the time when the data was cached. >> >> The client would then indicate which hash algorithm it used and upon >> acceptance, the server will honor the request. >> >> /Stefan >> >> >> On 10-05-17 10:34 PM, "Stefan Santesson" <stefan@aaa-sec.com> wrote: >> >>> Guys, >>> >>> Where I come from we have a say "don't cross the river to get to the water". >>> And to me this proposal to change the finished calculation is just that. >>> >>> Look at it. >>> >>> The proposal is to bind the cached data by adding a hash of the cached data >>> to the finished calculation. >>> >>> The proposal is further to avoid hash agility by picking the hash algorithm >>> used by TLS's Finished message computation. >>> >>> >>> Now there are two ways to achieve this goal. >>> >>> 1) The crossing the river to get water approach: Exchange FNV hashes of the >>> cached data in the handshake protocol exchange and then inject hashes of the >>> same data into the finished calculation through an alteration of the TLS >>> protocol. >>> >>> >>> 2) The simple approach: Use the hash algorithm of the finished calculation >>> to hash the cached data (according to the current draft). >>> >>> >>> Alternative 2 securely bind the hashed data into the finished message >>> calculation without altering the algorithm. >>> >>> Alternative 2 requires at most a hash algorithm identifier added to the >>> protocol, if at all. We don't need to add negotiation since we always use >>> the hash of the finished message calculation. Adding this identifier would >>> be the only change made to the current draft. >>> >>> Alternative 2 don't require additional security analysis. If the hash used >>> to calculate the finished message is broken, then we are screwed anyway. >>> >>> /Stefan >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On 10-05-17 9:16 PM, "Martin Rex" <mrex@sap.com> wrote: >>> >>>> Joseph Salowey wrote: >>>>> I agree with Uri, that if you determine you need SHA-256 then you should >>>>> plan for hash agility. TLS 1.2 plans for hash agility. >>>>> >>>>> What about Nico's proposal where a checksum is used to identify the >>>>> cached data and the actual handshake contains the actual data hashed >>>>> with the algorithm used in the PRF negotiated with the cipher suite? >>>>> >>>>> This way we don't have to introduce hash agility into the extension, but >>>>> we have cryptographic hash agility where it matters in the Finished >>>>> computation. Does it solve the problem? >>>> Yes, I think so. >>>> This approach should solve the issue at the technical level. >>>> >>>> Going more into detail, one would hash/mac only the data that got >>>> actually replaced in the handshake, each prefixed by a (locally computed) >>>> length field. >>>> >>>> -Martin >>>> _______________________________________________ >>>> TLS mailing list >>>> TLS@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tls >>> >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >> > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
- Re: [TLS] Wrapping up cached info Blumenthal, Uri - 0668 - MITLL
- [TLS] Consensus Call: FNV vs SHA1 Joseph Salowey (jsalowey)
- Re: [TLS] Consensus Call: FNV vs SHA1 Simon Josefsson
- Re: [TLS] Consensus Call: FNV vs SHA1 Blumenthal, Uri - 0668 - MITLL
- Re: [TLS] Consensus Call: FNV vs SHA1 Adam Langley
- Re: [TLS] Consensus Call: FNV vs SHA1 Marsh Ray
- Re: [TLS] Consensus Call: FNV vs SHA1 Robert Dugal
- Re: [TLS] Consensus Call: FNV vs SHA1 Stefan Santesson
- Re: [TLS] Consensus Call: FNV vs SHA1 Nicolas Williams
- Re: [TLS] Consensus Call: FNV vs SHA1 Stefan Santesson
- Re: [TLS] Consensus Call: FNV vs SHA1 Martin Rex
- Re: [TLS] Consensus Call: FNV vs SHA1 Jeffrey A. Williams
- Re: [TLS] Consensus Call: FNV vs SHA1 Paul Hoffman
- [TLS] Collisions (Re: Consensus Call: FNV vs SHA1) Nicolas Williams
- [TLS] Nico's suggestions - Re: Consensus Call: FN… Stefan Santesson
- Re: [TLS] Collisions (Re: Consensus Call: FNV vs … Blumenthal, Uri - 0668 - MITLL
- [TLS] Collisions (Re: Nico's suggestions - Re: Co… Nicolas Williams
- Re: [TLS] Collisions (Re: Consensus Call: FNV vs … Nicolas Williams
- Re: [TLS] Consensus Call: FNV vs SHA1 Simon Josefsson
- [TLS] Collisions (Re: Consensus Call: FNV vs SHA1) Nicolas Williams
- Re: [TLS] Collisions (Re: Consensus Call: FNV vs … Nicolas Williams
- Re: [TLS] Collisions (Re: Nico's suggestions - Re… Stefan Santesson
- Re: [TLS] Collisions (Re: Nico's suggestions - Re… Nicolas Williams
- Re: [TLS] Collisions (Re: Consensus Call: FNV vs … Simon Josefsson
- Re: [TLS] Collisions (Re: Nico's suggestions - Re… Stefan Santesson
- Re: [TLS] Collisions (Re: Nico's suggestions - Re… Nicolas Williams
- Re: [TLS] Collisions (Re: Consensus Call: FNV vs … Stefan Santesson
- Re: [TLS] Collisions (Re: Nico's suggestions - Re… Stefan Santesson
- Re: [TLS] Consensus Call: FNV vs SHA1 Hovav Shacham
- Re: [TLS] Collisions (Re: Consensus Call: FNV vs … Simon Josefsson
- Re: [TLS] Consensus Call: FNV vs SHA1 Yoav Nir
- Re: [TLS] Collisions (Re: Nico's suggestions - Re… Martin Rex
- Re: [TLS] Collisions (Re: Nico's suggestions - Re… Nicolas Williams
- Re: [TLS] Collisions (Re: Nico's suggestions - Re… Stefan Santesson
- Re: [TLS] Collisions (Re: Nico's suggestions - Re… Nicolas Williams
- Re: [TLS] Consensus Call: FNV vs SHA1 Nicolas Williams
- Re: [TLS] Collisions (Re: Nico's suggestions - Re… Stefan Santesson
- Re: [TLS] Consensus Call: FNV vs SHA1 Simon Josefsson
- Re: [TLS] Collisions (Re: Nico's suggestions - Re… Nicolas Williams
- Re: [TLS] Consensus Call: FNV vs SHA1 Michael D'Errico
- Re: [TLS] Collisions (Re: Nico's suggestions - Re… Martin Rex
- Re: [TLS] Consensus Call: FNV vs SHA1 Kemp, David P.
- Re: [TLS] Collisions (Re: Nico's suggestions - Re… Nicolas Williams
- Re: [TLS] Consensus Call: FNV vs SHA1 Nicolas Williams
- Re: [TLS] Consensus Call: FNV vs SHA1 Blumenthal, Uri - 0668 - MITLL
- Re: [TLS] Consensus Call: FNV vs SHA1 Nicolas Williams
- Re: [TLS] Collisions (Re: Nico's suggestions - Re… Martin Rex
- Re: [TLS] Collisions (Re: Consensus Call: FNV vs … Kemp, David P.
- Re: [TLS] Collisions (Re: Nico's suggestions - Re… Kemp, David P.
- Re: [TLS] Collisions (Re: Consensus Call: FNV vs … Marsh Ray
- Re: [TLS] Collisions (Re: Nico's suggestions - Re… Nicolas Williams
- Re: [TLS] Collisions (Re: Consensus Call: FNV vs … Nicolas Williams
- Re: [TLS] Collisions (Re: Nico's suggestions - Re… Marsh Ray
- Re: [TLS] Collisions (Re: Nico's suggestions - Re… Marsh Ray
- Re: [TLS] Collisions (Re: Nico's suggestions - Re… Nicolas Williams
- Re: [TLS] Collisions (Re: Consensus Call: FNV vs … Marsh Ray
- Re: [TLS] Collisions (Re: Consensus Call: FNV vs … Nicolas Williams
- Re: [TLS] Collisions (Re: Nico's suggestions - Re… Marsh Ray
- Re: [TLS] [POSSIBLE SPAM] Re: Collisions (Re: Nic… Kemp, David P.
- Re: [TLS] Collisions (Re: Nico's suggestions - Re… Nicolas Williams
- Re: [TLS] [POSSIBLE SPAM] Re: Collisions (Re: Nic… Marsh Ray
- Re: [TLS] [POSSIBLE SPAM] Re: Collisions (Re: Con… Kemp, David P.
- Re: [TLS] Collisions (Re: Nico's suggestions - Re… Marsh Ray
- Re: [TLS] Collisions (Re: Consensus Call: FNV vs … Stefan Santesson
- Re: [TLS] [POSSIBLE SPAM] Re: Collisions (Re: Con… Marsh Ray
- Re: [TLS] Collisions (Re: Nico's suggestions - Re… Stefan Santesson
- Re: [TLS] Collisions (Re: Consensus Call: FNV vs … Marsh Ray
- Re: [TLS] Collisions (Re: Consensus Call: FNV vs … Stefan Santesson
- Re: [TLS] Collisions (Re: Consensus Call: FNV vs … Marsh Ray
- Re: [TLS] Collisions (Re: Nico's suggestions - Re… Simon Josefsson
- Re: [TLS] Collisions (Re: Nico's suggestions - Re… Brian Smith
- Re: [TLS] Collisions (Re: Nico's suggestions - Re… Marsh Ray
- [TLS] Justification Michael D'Errico
- Re: [TLS] Justification Simon Josefsson
- Re: [TLS] Justification Adam Langley
- Re: [TLS] Justification Brian Smith
- Re: [TLS] Justification Michael D'Errico
- Re: [TLS] Justification Adam Langley
- Re: [TLS] Justification Marsh Ray
- Re: [TLS] Justification Brian Smith
- Re: [TLS] [POSSIBLE SPAM] Re: Collisions (Re: Con… Kemp, David P.
- Re: [TLS] Justification Michael D'Errico
- Re: [TLS] Justification Adam Langley
- [TLS] Use HTTP (Re: Justification) Nicolas Williams
- Re: [TLS] Justification Nicolas Williams
- Re: [TLS] Justification Michael D'Errico
- Re: [TLS] Justification Nicolas Williams
- Re: [TLS] Justification Michael D'Errico
- Re: [TLS] Justification Nicolas Williams
- Re: [TLS] Justification Michael D'Errico
- Re: [TLS] Justification Nicolas Williams
- Re: [TLS] Justification Yoav Nir
- Re: [TLS] Justification Michael D'Errico
- Re: [TLS] Justification Martin Rex
- Re: [TLS] Justification Marsh Ray
- Re: [TLS] Justification Stefan Santesson
- Re: [TLS] Justification Martin Rex
- Re: [TLS] Collisions (Re: Nico's suggestions - Re… Yoav Nir
- Re: [TLS] Collisions (Re: Nico's suggestions - Re… Stefan Santesson
- Re: [TLS] Justification Nicolas Williams
- Re: [TLS] Wrapping up cached info Marsh Ray
- Re: [TLS] Collisions (Re: Nico's suggestions - Re… Marsh Ray
- Re: [TLS] Justification Dean Anderson
- [TLS] Wrapping up cached info Stefan Santesson
- Re: [TLS] Wrapping up cached info Nicolas Williams
- Re: [TLS] Wrapping up cached info Simon Josefsson
- Re: [TLS] Wrapping up cached info Nicolas Williams
- Re: [TLS] Justification Stefan Santesson
- Re: [TLS] Justification Nicolas Williams
- Re: [TLS] Justification Nicolas Williams
- Re: [TLS] Wrapping up cached info Marsh Ray
- Re: [TLS] Wrapping up cached info Joseph Salowey (jsalowey)
- Re: [TLS] Wrapping up cached info Marsh Ray
- Re: [TLS] Wrapping up cached info Nicolas Williams
- Re: [TLS] Wrapping up cached info Ben Laurie
- Re: [TLS] Wrapping up cached info Yoav Nir
- Re: [TLS] Wrapping up cached info Nicolas Williams
- Re: [TLS] Wrapping up cached info Marsh Ray
- Re: [TLS] Wrapping up cached info Marsh Ray
- Re: [TLS] Wrapping up cached info Ben Laurie
- Re: [TLS] Wrapping up cached info Martin Rex
- [TLS] Possible alternative to current cached info… Michael D'Errico
- Re: [TLS] Wrapping up cached info (and PRF WTF) Kemp, David P.
- Re: [TLS] Wrapping up cached info (and PRF WTF) Martin Rex
- Re: [TLS] Wrapping up cached info Stefan Santesson
- Re: [TLS] Wrapping up cached info (and PRF WTF) Nicolas Williams
- Re: [TLS] Wrapping up cached info Stefan Santesson
- Re: [TLS] Wrapping up cached info Stefan Santesson
- Re: [TLS] Wrapping up cached info Joseph Salowey (jsalowey)
- Re: [TLS] Wrapping up cached info Stefan Santesson
- Re: [TLS] Wrapping up cached info Michael D'Errico
- Re: [TLS] Wrapping up cached info Marsh Ray
- Re: [TLS] Wrapping up cached info Joseph Salowey (jsalowey)
- Re: [TLS] Wrapping up cached info Joseph Salowey (jsalowey)
- Re: [TLS] Wrapping up cached info Marsh Ray
- Re: [TLS] Wrapping up cached info Nicolas Williams
- Re: [TLS] Wrapping up cached info Stefan Santesson
- Re: [TLS] Wrapping up cached info Michael D'Errico
- Re: [TLS] Wrapping up cached info Michael D'Errico
- Re: [TLS] Wrapping up cached info Kemp, David P.
- Re: [TLS] Wrapping up cached info Nicolas Williams
- Re: [TLS] Wrapping up cached info Nicolas Williams
- Re: [TLS] Wrapping up cached info Ben Laurie
- Re: [TLS] Wrapping up cached info Brian Smith
- Re: [TLS] Wrapping up cached info Stefan Santesson
- Re: [TLS] Wrapping up cached info Martin Rex
- Re: [TLS] Wrapping up cached info Brian Smith
- Re: [TLS] Wrapping up cached info Nicolas Williams
- Re: [TLS] Wrapping up cached info Stefan Santesson
- Re: [TLS] Wrapping up cached info Brian Smith
- Re: [TLS] Wrapping up cached info Brian Smith
- Re: [TLS] Wrapping up cached info Nicolas Williams