Re: [TLS] First TLS cached information draft posted
Stefan Santesson <stefan@aaa-sec.com> Tue, 16 June 2009 14:59 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 276353A6A5E for <tls@core3.amsl.com>; Tue, 16 Jun 2009 07:59:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.162
X-Spam-Level:
X-Spam-Status: No, score=-2.162 tagged_above=-999 required=5 tests=[AWL=0.087, 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 4MZN0gsaOf4N for <tls@core3.amsl.com>; Tue, 16 Jun 2009 07:59:04 -0700 (PDT)
Received: from s87.loopia.se (s87.loopia.se [194.9.95.112]) by core3.amsl.com (Postfix) with ESMTP id 737563A6B6A for <tls@ietf.org>; Tue, 16 Jun 2009 07:59:01 -0700 (PDT)
Received: (qmail 22893 invoked from network); 16 Jun 2009 14:58:03 -0000
Received: from s34.loopia.se (HELO s24.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>; 16 Jun 2009 14:58:03 -0000
Received: (qmail 79853 invoked from network); 16 Jun 2009 14:57:57 -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 s24.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <simon@josefsson.org>; 16 Jun 2009 14:57:57 -0000
User-Agent: Microsoft-Entourage/12.19.0.090515
Date: Tue, 16 Jun 2009 16:57:53 +0200
From: Stefan Santesson <stefan@aaa-sec.com>
To: Simon Josefsson <simon@josefsson.org>, martin.rex@sap.com
Message-ID: <C65D7F91.2A72%stefan@aaa-sec.com>
Thread-Topic: [TLS] First TLS cached information draft posted
Thread-Index: AcnuktMJCk5cfk/uv0y6UlzsicIQUg==
In-Reply-To: <87hbynajhs.fsf@mocca.josefsson.org>
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: Tue, 16 Jun 2009 14:59:05 -0000
Hi, I have now carefully read through this thread and spent some time thinking of it. I don't like the extra complexity of the proposed structure and I fail to see the problem of recognizing the hash as replacement of data. First of all, the worse case scenario if everything fails miserably and client mistake a hash for real data or the other way around, is a failed handshake. This is followed by a normal handshake where the client will reset it's cash for that server. This safe fallback allows us to accept reasonable risk of failure. Now, how hard is it to recognize a hash as replacement for cashed data and what is the risk of collision? In my world this is not hard at all. The hash code is a unique identification key, provided by the client. If these bits appear where the cached data was supposed to appear, it is a clean replacement. This is not hard to detect and risk of collision is negligible. It is totally irrelevant if the hash in theory can take the form of legal ASN.1, XML or anything. We know where the bits start in the handshake protocol, the hash bits was further chosen by the client and if the server or MitM tries to change them, it will only result in a failed handshake. In the sum of all, I would like to keep the current protocol syntax. /Stefan On 09-06-10 11:04 PM, "Simon Josefsson" <simon@josefsson.org> wrote: > Martin Rex <Martin.Rex@sap.com> writes: > >> What you could do, is to unconditionally use an additional framing >> for that being-cached parts of the TLS handshake messages for >> for which the Client requested caching in the ClientHelloExtension >> and and the Server acknowledged caching support in the >> ServerHelloExtension. >> >> (I'm not really accustomed to TLS spec language, so please >> apply common sense / corrections yourself): >> >> enum { >> original_data(1), >> hash_over_original_data(2), >> omitted_hash_over_original_data(3), >> original_data_and_suggestion_to_not_cache(4), >> (255) >> } CacheControlContentType; >> >> struct { >> CacheControlContentType type; >> opaque content<0..2^16-1>; >> } CacheControlContent; >> >> >> ...and drop the things that are not needed (but mentioned for completeness) >> >> >> This approach would unconditionally change the (affected) PDU if caching is >> negotiated but hashes do not match (as well). It facilitates to omit >> the actual hash value at this point in a non-ambiguous fashion >> (the hash should be part of the handshake once, but having it >> three times looks like waste). > > I like this approach, it addresses both your and my original concerns. > Stefan, what do you think? > > The resulting protocol is more complex with the above, but given that > the original proposal is unreliable, I think the complexity is warranted > here. > > /Simon > _______________________________________________ > 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